Free DHTML scripts provided by
Dynamic Drive
Programming badly - what's wrong in programming languages?
The programming blog to conclude all blog sites. Here you will be introduced the worst code, programs, programming languages and programmers ever. This is a humoristic approach to programming world and its strange inhabitants - like myself.
July 10, 2011
Keyboard afterlife
So you have a keyboard that has served you loyally its time, but instead of a conventional recycling burial it seems to deserve another life? You are not alone. There are others that think exactly like you.
May 23, 2011
Let's sing a song
Here's an algorithm for a song, released free for use.
First thing that comes to my mind is that the above algorithm could be optimised.
Second thing that comes to my mind that if I really spend my evenings doing this, things have gone terribly wrong.
Vector<Action> actions = new Vector<Action>(); actions.add( new ClapHandsAction() ); actions.add( new StompFeetAction() ); actions.add( new ShoutAction("Hooray") ); CompositeAction allThree = new CompositeAction(); allThree.add( new ClapHandsAction() ); allThree.add( new StompFeetAction() ); allThree.add( new ShoutAction("Hooray") ); actions.add(allThree) for(Action a: actions) { if (person.state() == Person.HAPPY && person.knownState() == person.state()) { person.apply(a);
person.face().reflectState(person.state()); } }
First thing that comes to my mind is that the above algorithm could be optimised.
Second thing that comes to my mind that if I really spend my evenings doing this, things have gone terribly wrong.
May 07, 2011
Evolution of the FOR loop
The history of FOR loop is long and interesting. Nearly every high-level programming language has developed an own variant of the FOR loop, for making it easy for the programmer to iterate a variable through numeric sequences and ranges. Here we are going to compare how each programming language has done it, and we will see that the syntax has not necessarily always gone to a better direction.
One interesting point is that nearly all languages also have some kind of implementation of foreach - means to iterate through a list. But this syntax seems to differ very little between languages. Maybe the reason for that is that when talking about foreach, it is quite obvious what the programmer is up to, whereas with regular for, it is not that clear.
Let's have a look how COBOL did it.
Now the syntax is a disaster. There is an awful lot of typing for the simplest thing. This loops variable a from 0 to 99, and - after a quick count - it takes 53 keypresses to achieve that simple loop.
Now what do we have in C ?
A lot more compact, have to admit. But logically, it is a mess. I never really understood the reason for including for loop into C language anyway. It looks like misters Kernighan and Ritchie had added this syntax the last day before publishing their book in a terrible hurry. You can write perfectly good code without it. The syntax is nothing but a handy access to a regular while loop, adding some extra complexity and removing readability. Syntax like this requires the programmer to know EXACTLY in which phases of the loop the different segments are evaludated. Stupid syntax, and should be deprecated.
Python does the same thing like this:
Now I can't think of anything to improve in here. First of all, it is easy to write and easy to understand. And there is one more very important point about the syntax: Python combines here the for and foreach syntaxes in one. If the programmer wants a regular loop, he will just need to create an instant throwaway array to iterate through. So Python has avoided the "unclear for loop problem" by removing the regular for keyword completely, offering only a foreach -type of solution, and then a function to support "regular" looping when user just wants to repeat something. From programmer's point of view this is most esthetic, and if this can be optimized, an extremely elegant solution.
One interesting point is that nearly all languages also have some kind of implementation of foreach - means to iterate through a list. But this syntax seems to differ very little between languages. Maybe the reason for that is that when talking about foreach, it is quite obvious what the programmer is up to, whereas with regular for, it is not that clear.
Let's have a look how COBOL did it.
PERFORM VARYING A FROM 0 BY 1 UNTIL A=99
...
END-PERFORM
Now the syntax is a disaster. There is an awful lot of typing for the simplest thing. This loops variable a from 0 to 99, and - after a quick count - it takes 53 keypresses to achieve that simple loop.
Now what do we have in C ?
for(int a; a<100; ++a) { ... }
A lot more compact, have to admit. But logically, it is a mess. I never really understood the reason for including for loop into C language anyway. It looks like misters Kernighan and Ritchie had added this syntax the last day before publishing their book in a terrible hurry. You can write perfectly good code without it. The syntax is nothing but a handy access to a regular while loop, adding some extra complexity and removing readability. Syntax like this requires the programmer to know EXACTLY in which phases of the loop the different segments are evaludated. Stupid syntax, and should be deprecated.
Python does the same thing like this:
for a in range(0, 100): ...
Now I can't think of anything to improve in here. First of all, it is easy to write and easy to understand. And there is one more very important point about the syntax: Python combines here the for and foreach syntaxes in one. If the programmer wants a regular loop, he will just need to create an instant throwaway array to iterate through. So Python has avoided the "unclear for loop problem" by removing the regular for keyword completely, offering only a foreach -type of solution, and then a function to support "regular" looping when user just wants to repeat something. From programmer's point of view this is most esthetic, and if this can be optimized, an extremely elegant solution.
April 26, 2011
Alisp in wonderland
Lisp is great, I love it. It is so different from everything else that it just astonishes you. Everybody should learn lisp. If not for any other reason, then just to widen their perspective in programming, and finally to regain their respect to the language they are currently programming.
Lisp is for list processing, naturally. But that's not the point. Where most languages - so called procedural languages - say what should the computer do, in which order, and in which conditions, Lisp concentrates on rules on evaluation: what each variable evaluates into in which conditions. And finally, your program concludes in one root element, or variable, which is then evaluated by running the program.
Because everything in Lisp is about evaluation and there is no sequence of doing things, Lisp as a language does not define structural loops. For todays pgogrammer this is quite odd. (Ok, some lisp variant have some kind of loop macros, but those are some kind of add-on, and that's not the lisp spirit) So when you want to repeat something, you will implement recursion. Therefore you can not talk about lisp without speaking about recursion. I would say half of all lisp functions are calling themselves recursively. Isn't that just ridiculous.
Although Lisp is so different from procedural languages, it has made its impact to popular languages today. Have you ever noticed one particular syntax in C programming language, and wondered why it is so dramatically different from everything else you see in C?
There is a reason. It has been taken from Lisp. That explains its peculiarity. Actually, using above mechanism and recursion, you could make C code look quite a lot like Lisp. Take a look at below example:
Yes this is a wannabe-Lisp C function. Notice the function has only one line, which starts with return and ends with a semicolon. No procedural thinking; the function directly returns something which then evaluates into a decision tree. And no, I did not try to compile it. It's just an example. You are free to comment your findings.
And what else have I done with Lisp then? Years back when I was at school I coded a game AI algorithm that calculated the best possible move in a board game. It was much fun, but the code turned out to be horrible. Maybe all lisp code turns out to be that. If I remember correctly, my professor gave me a rather high grade for this one, but maybe he was just fond of board games.
Lisp is for list processing, naturally. But that's not the point. Where most languages - so called procedural languages - say what should the computer do, in which order, and in which conditions, Lisp concentrates on rules on evaluation: what each variable evaluates into in which conditions. And finally, your program concludes in one root element, or variable, which is then evaluated by running the program.
Because everything in Lisp is about evaluation and there is no sequence of doing things, Lisp as a language does not define structural loops. For todays pgogrammer this is quite odd. (Ok, some lisp variant have some kind of loop macros, but those are some kind of add-on, and that's not the lisp spirit) So when you want to repeat something, you will implement recursion. Therefore you can not talk about lisp without speaking about recursion. I would say half of all lisp functions are calling themselves recursively. Isn't that just ridiculous.
Although Lisp is so different from procedural languages, it has made its impact to popular languages today. Have you ever noticed one particular syntax in C programming language, and wondered why it is so dramatically different from everything else you see in C?
(a ? b : c)
There is a reason. It has been taken from Lisp. That explains its peculiarity. Actually, using above mechanism and recursion, you could make C code look quite a lot like Lisp. Take a look at below example:
int days_per_month(int year, int month) {
return (month==1||month==3||month==5||month==7||month==8||month==10||month==12 ? 31 :
(month==4||month==6||month==9||month==11 ? 30 :
(month==2 ?
(year>0 && year%4==0 && ( year%100!=0 || year%400==0 ) ? 29 : 28 )
0
)
)
);
}
Yes this is a wannabe-Lisp C function. Notice the function has only one line, which starts with return and ends with a semicolon. No procedural thinking; the function directly returns something which then evaluates into a decision tree. And no, I did not try to compile it. It's just an example. You are free to comment your findings.
And what else have I done with Lisp then? Years back when I was at school I coded a game AI algorithm that calculated the best possible move in a board game. It was much fun, but the code turned out to be horrible. Maybe all lisp code turns out to be that. If I remember correctly, my professor gave me a rather high grade for this one, but maybe he was just fond of board games.
April 18, 2011
Do you remember Fortran?
Do you remember Fortran? I do. I have a headache when I even think about it. Trust me, I know what I'm talking about, I have programmed Fortran, although it was not a real IBM like in the picture above, it was an ordinary PC but it was a nightmare anyway.
I think people that wrote Fortran were just simply playing a practical joke to their colleagues when they made the rule in the language that every single line in the code MUST BE INDENTED with exactly 7 space characters. If you try 6 or 8 characters, the program just does not compile. And with a smile on their face they named the language "Fortran 77". Just for the sake of being cruel.
And the capital letters. Oh yeah. Programmers can be nasty when they are not given their bonuses, you know. READ, WRITE, IF, GOTO and other reserved words work only in capital, not in lowercase. Of course not.
Yes I know, now you people that have been reading mathematics start mocking me and claim that Fortran is the only language that introduces a native support for complex number calculation. If computers regularly introduce numeric types for integers and floats, Fortran does three; integers, floats and complexes, by the reserved keywords INTEGER, REAL and COMPLEX. But what's wrong in using libraries? Oh yeah... Fortran did not support libraries. Another headache.
Next week about Lisp... my head hurts already.
April 17, 2011
Programming badly ?
Hi all! Things that we most love are most often the same that we find most annoying. At least I have made that observation. For me it is this thing about software. Now don't get me wrong, I love software and especially I love programming, I really do. But it comes with a cost. Not all people share your eye on code beauty and perfectionism. Of course, tolerating this is called "ability to work as member of a group". Doesn't that just kill you!
The same goes with programming languages. There are some aspects about them that are really great, but some things about them are just so freaking annoying that I just can not stand it.
This blog is dedicated to those who have a love-hate relationship to programming. It is a humoristic approach to a serious thing, or vice versa, how you like it. If you don't have a clue what I'm talking about, just go on and read another blog, but if you share my feelings - who knows, you might even like it?
The same goes with programming languages. There are some aspects about them that are really great, but some things about them are just so freaking annoying that I just can not stand it.
This blog is dedicated to those who have a love-hate relationship to programming. It is a humoristic approach to a serious thing, or vice versa, how you like it. If you don't have a clue what I'm talking about, just go on and read another blog, but if you share my feelings - who knows, you might even like it?
Subscribe to:
Posts (Atom)