Link Details

Link 858377 thumbnail
User 847899 avatar

By hzhou321
via hz2.org
Published: Oct 04 2012 / 11:55

The essential idea of programming is easy -- giving instructions to machines. We do harder tasks such as communicating to people all the time, programming should be easy compared to that -- except when programmers wrap up the simple nature and create and use technology words to describe every thing they do.
  • 6
  • 7
  • 1057
  • 954

Comments

Add your comment
User 368782 avatar

Martyr2 replied ago:

0 votes Vote down Vote up Reply

First of all the author of this article needs to do some spell checking. Second, programming can be easy if all the systems you interact with were also well designed. The problem is, often our programs have to interact with other programs which are not organized. They also take in input from users who are either misinformed or simply make mistakes.... to error is human after all. Third, software is often developed on top of other software (like the OS) which in itself may have complexities that we can't avoid. Take into account all these faucets and you end up with programs that may be more complex than you would like. Sure your concept was simple, but hardly ever is it simply that straight forward. Telling the computer instructions is easy.... it is dealing with other people and programs that makes programming hard.

User 847899 avatar

hzhou321 replied ago:

0 votes Vote down Vote up Reply

Marty2, you did not quite get the point. Talking is easy. Listening is easy. Talking and listening to a professor may not be that easy. It may well be very complex. But still, you don't hesitate to speak your idea and you don't hesitate to listen to assess other people's idea. Programming should be easy. But in current state, people hesitate to code their idea, and people hesitate to read other people's code. Code gets complex before the idea gets complex. I do have my take on the reasons and solutions, but the quick blog is just meant to start people thinking. Programming should be easy but it is not, why?

User 983885 avatar

infovation_Softwares replied ago:

0 votes Vote down Vote up Reply

its because programming is not like directory explorer, where one can see the overview of the system and then start clicking and expanding the code one at a time. although classes and procedures are meant to do that but its not like google maps.

User 847899 avatar

hzhou321 replied ago:

0 votes Vote down Vote up Reply

It could. Maps are not like google maps until google maps. You seem to suggest we need a more intelligent editor. However, google maps have two parts -- an organized data source and a smart presenter. Our current way of programming is not focused on logic level organization (it is rather more focused on compiler side), therefore it is really not ready for the sensible presentation. So I think we first need a programming renaissance - start embracing contexts and focusing on logic. Once the source code is in a logic form (where logic delimiters are first class marking, above, and therefore not interfered by context-free syntax), a reasonable editor will be just matter of time. Now I think about it, this is how we communicate. Recall the experience talking to a foreign speaker. They may mess up pronunciations and syntax a lot, but still we are able to continue the conversation because we can detect clear logic coherence. In current state, when we write code and read code, we are by far distracted by syntax. Imaging when we are speaking a newly learned foreign language and we are not allowed to continue until we get every syntax and spelling correct, how hard would that be! In fact, it will be difficult to speak our native language that way.

User 255539 avatar

sentinel101 replied ago:

0 votes Vote down Vote up Reply

I don't get your point neither. Talking & listening is easy when you know the language very well and the one you communicate with talks in the same language with the same style. Now when these "technical" prerequisites are fulfilled you can still have a complex topic that is hard to understand, no matter how easy it is to listen to the sentences that you hear. You probably need some time to grasp the meaning of what you have been told and if your lucky you will finally understand it. No, I don't think that programming is easy, at least when you reach a certain level of complexity. Your example is trivial. You don't mention the OS functions, the libraries that you use, asynchronous events that break the sequential structure, error handling and so on. All of this adds complexity that you cannot avoid unless you earn your money with "Hello World" programs. ,

User 847899 avatar

hzhou321 replied ago:

0 votes Vote down Vote up Reply

sentinel101: Complexity is made up from "simplexity", but when each "simplexity" is wrapped in an API layer with fancy names, or weaved with other "simplexity", the access to complexity is blocked. My example is trivial, but it represents how most interactive/event based programs work. At top level, the logic is simple as "trivial", then move down to how it setup states and respond to events, the program can be arbitrary complex -- yet still, at each component level, it is trivially simple. Say you are interested in vim, you open main.c, and read the code like in my example, you would immediately get it how the program works overall. Then you move down to individual components and if each components is spelled out as well then you won't have much trouble follow. On the other hand, when the main code is mixed with codes at different level, mixed with comments that refers you to different levels of details, and mixed option/portability switch, you don't see the simple code simple any more. In fact, you don't know where it is in the first place. As you mentioned asynchronous events, they are simple too. It is only not simple when you mix code that dealing with different events together. We as human deal with asynchronous events all the time, we just don't deal with it mixed. When we describe or give out instructions, we naturally speak in a logic coherent way. As in current state, we don't do that in coding.

User 255539 avatar

sentinel101 replied ago:

0 votes Vote down Vote up Reply

I think what you're trying to express is one of the basic principle of a well layered design: provide good abstractions which hide the complexity. Out of such abstractions other higher-level abstraction can be produced and so on. Then at the top of these abstractions you have your simple programs that you mention. So this is nothing new but still, as nothing is perfect, we have to cope with leaky abstractions, broken layers, and so on.

User 847899 avatar

hzhou321 replied ago:

0 votes Vote down Vote up Reply

Thanks for continue the conversation. As you said, there is nothing new. We do that all the time whenever we explain things and give out instructions. As I said, it is easy, should be intuitive. As the current reality goes, it is not so. I was just reading the source code of vim which has a routine in fileio.c called readfile which according to comments is just to load file contents into buffer. It is almost 2500 lines! The problem is in part due to the limit of current programming language design, it is all based context free syntax, which is good at low or intermediate level which produces robust compilers that optimizes local code. However, at higher level, local correctness and optimization is not as important as logic organization, and we need context dependent system to do that efficiently just as how our natural language does. To be specific, context free necessitates passing context at each factorization which requires creation of interfaces. First of all, interfaces are extra complexity. Second, when we are complying with interfaces, elements cross logic level comes to interfere. To put it short, we all experience and are aware of the cost of these interfaces and we either avoid them (end up with 2500 line function body) or create such a complexity includes layers of abstract class that we need fight through before reaching any actual code. That is the state of problem, but the current focus in finding the next paradigm is missing the boat.

User 847899 avatar

hzhou321 replied ago:

0 votes Vote down Vote up Reply

Just a minor correction: the point is not to "hide" the complexity, but to factor the complexity, where each factor is simple. Large OOP framework does hide the complexity well, but that is not what I would like.

User 72237 avatar

tb74341 replied ago:

0 votes Vote down Vote up Reply

I think the technical term for this is 'rubbish'. I have the displeasure of working with legacy system and no documentation. I'm guessing whoever wrote that stuff at the moment of writing thought it's pretty self explanatory and definitely did not 'believe' in comments and/or documentation ;-)

User 847899 avatar

hzhou321 replied ago:

0 votes Vote down Vote up Reply

There are encryption algorithms or physics simulation programs that are complex by the idea itself. They don't need comments, they need papers/books to explain the idea. However, if the code needs comments/documentation to explain the code itself, the code is not done right. We live in a period that all of us have the displeasure of working with code that are not done right.

User 847899 avatar

hzhou321 replied ago:

0 votes Vote down Vote up Reply

Think about code as a domain-specific language to describe programs -- just as math is a domain-specific language to describe specific logic. Certain math works may need detailed paper/book to explain, but the math itself shouldn't need comments. So similarly, I do believe in explanations of algorithm/purpose/idea either in separate readme/doc/paper/book or block comments, but comments to explain what the specific code does is just evidence that the code is not done right. To describe what it does, code "should" be more straightforward than our native language.

User 72237 avatar

tb74341 replied ago:

0 votes Vote down Vote up Reply

... forgot to add that if large systems consisted of single file programs with few lines like his example, then indeed we would live in an ideal world. Show of hands where your job consists of working on such a program?

User 847899 avatar

hzhou321 replied ago:

0 votes Vote down Vote up Reply

By the way, if you have time and are interested, read my 2nd post "Fight Feature-Creep With Context" http://www.dzone.com/links/fight_featurecreep_with_context.html , I which I described some of my idea of dealing with complexity.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Apache Hadoop
Written by: Piotr Krewski
Featured Refcardz: Top Refcardz:
  1. Play
  2. Akka
  3. Design Patterns
  4. OO JS
  5. Cont. Delivery
  1. Play
  2. Java Performance
  3. Akka
  4. REST
  5. Java