Friday, September 17, 2010

Programming will never be “easy”

There seems to be this idea going around the internet that the reason someone isn’t able to program, is because languages aren’t good enough yet. A couple of people I have seen with have gone so far as to insinuate that the reason programming is to hard for most people, is because we design our languages to be too hard, just to keep people away from programming, and to secure our jobs. In reality, programmers are not trying to make their jobs harder, they are constantly trying to make their jobs easier. The truth of the matter is, programming is just hard.

Some people argue our current languages are too cryptic, other people argue that we need to abandon text-based languages all together, and just use GUI languages. What people don’t realize, is if GUI languages were actually easier, everyone would understand electrical engineering. Most people don’t understand electrical engineering, not because they don’t understand how to connect wires, but because they don’t understand the logic, math, and general engineering behind it.

As for the argument that programming languages are too cryptic, this is just a misunderstanding of what people really want. What people really want, is magic. So is an easy programming language impossible? No. Programming languages have plenty of room to get easier, and to evolve, however the act of programming itself, will never truly be easy, unless you are doing the most basic of tasks.

So just for amusement, what would the easiest programming language look like? Lets say we want to create a window with a table view that adds entries when someone clicks a button. What people would like, is to have a language that would understand some message such as

“Create a window with a table view, and then when someone clicks a button, add an entry to the table view”

While in theory its fully possible to parse a fully human-language, and then generate intermediate code based off of that, in reality, we don’t have that type of technology quite yet, as well as there isn’t near enough information given. What style of window? Initial position? Color? What about the table view? What type of data are the entries storing? How does the user interact directly with the table-view? What about menu items?

Also, what happens if we create two windows? How do we address first one, then address the second one? Well, we have to have some sort of variable naming convention, such as “Create a window named window1” wait, that’s going to be a challenge for the parser to interpret, are we naming the window window1, or are we setting a variable called window1? Lets redefine our variable definition syntax. “Create a window with title ‘Window 1’ and variable name wnd1”. Rather wordy, and already this language is getting complex.

What if we need to do something complex on an engineering level, such as create a scheduler? We can’t just go “Create a scheduler”, we have to figure out how its going to tie in the system, and fully understand the outcome of the code we write, as well as the internal code. So we’d have to describe every variable creation, and every action, to extreme details. It’d be easier to do it in a standard programming language, quite arguably.

All of this is not to say trying to advance programming languages is a bad idea, I’m just trying to explain, no matter how easy the programming language is, if you don’t understand the logic behind the code, you won’t be able to write it in any language.

Source: mdmstudios.wordpress.com

0 comments:

Post a Comment

 

boulevard of broken dreams © 2008. Chaotic Soul :: Converted by Randomness