Slashdot Mirror
What I Hate About Your Programming Language
chromatic writes "Perl programmers like punctuation. Python programmers like indentation. Every programming language has its own syntax, stemming from its philosophy. What I Hate About Your Programming Language examines the issues that shape languages as they grow. It's not advocacy, I promise."
What I hate about your programming language is that it doesn't work like mine does.
The cake is a pie
That's why I use Whitespace, of course!
What!? # is so cool looking though.
As a perl programmer I just read that as "What!? "
"Probably the toughest time in anyone's life is when you have to murder a loved one because they're the devil." -Philips
Anyone else noticed how, in the middles of the "my language is better than your language" flame war this guy was starting, he managed to slip in an editor flamewar by linking to vim?
Truly brilliant!
Follow the adventures of the new wandering jews
But, there are MANY times when operator overloading would make things sooo much easier. Which would you rather read:
complex z1(0,1);
complex z2(1,0);
complex z3 = z1+z2;
or
complex z1(0,1);
complex z2(1,0);
complex z3 = complexMath.Add(z1, z2);
?
(The second is still better than z3=z1.Add(z2) IMHO)
I'll take the first any day.
I can't stand machine language. I'll be typing along and accidently type a '0' when I meant to type a '1' and my program goes apeshit. They should fix that.
Better would be languages which are self-documenting...
There is no language that will force perfect code. There is always room for a poor programmer to produce hard-to-understand code. Functions that do two unrelated things, confusing control flow, bad variable names, broken code that was repeatedly patched instead of being cleaned up... the possibilities are endless.
Nonetheless, some languages have been designed with self-documenting code in mind; sometimes it even works.
If you look at languages like COBOL, they have long descriptive keyword names designed to make the code easy to read. But you get tired of looking at those long keywords.
I haven't used ADA, but I understand that it is somewhat designed for self-documenting code, and that as a result you are hemmed in on all sides by language rules. (ADA fans please comment here.)
The best language I have seen for this is Python. As a rule there is exactly one way to do things, so you don't trip over obscure hackish tricks that you have to puzzle out. The language doesn't force self-documenting or comments, but it does force indentation; everyone indents their Python pretty much the same (compare with the mess that is C indentation). The language is high-level enough, with lots of libraries, so you don't need to write 10 lines of code just to do one simple thing.
Python was designed by a guy who is both a computer geek and a math geek. The math geek in him led to a very tidy language design, and I like it very much. I think schools ought to be using Python to teach introductory programming classes.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I don't have any hands you insensitive clod!
Do you even lift?
These aren't the 'roids you're looking for.
This is probably true, and I'm as much as an anti-MS guy as you can get really, but I have my reasons for not liking VB. I did a few projects with it in the past year (ASP/VBScript with VB COM components, MTS, etc), so I speak from experience.
I went into it thinking it would suck, but I quickly found it being okay for gettings things done. "Hey, maybe these guys are onto something I think...". Then the project gets more complex and I realize why I like langauges that are far more strict regarding what you can and cannot do.
If (ErrorState = True) Then
CLEANUPCOMMONOBJECTS
End If
If I had good exception and a good GC I wouldn't have even needed this though.
It's a short list, but it's been a while since I coded in it.
Smalltalk is quite self-documenting. I'm sure most C/C++/java/Perl/Python programmers think you're joking when you talk about a "self-documenting language," but they're real.
:= 1. ":= is assignment" :a :b | a + b ] "block creation- a block closure, aka anonymous subroutine"
A simple langauge plus a decent code browser can equal a self-documenting language. Methods are organized into logical groups (e.g. "accessing" "initialization" etc), and clicking on a category will tell you the methods there. Especially when there is a tradition for short (7 lines or less is the rule) methods, as in Smalltalk- you can usually see what the entire method is doing just by looking at it, if you cannot guess at what is is for by looking at the name.
People may think this is an exageration, especially if they're used to systems that require various man pages, books, and on-line class lib references just to write some code. Other than one book on Smalltalk style, I've not read any books on Smalltalk. I read some tutorials when I began, but after you learn the basic syntax [1], the very basic ideas [2], and especially, how to browse classes, you learn as you go, finding out classes to use as you need them.
[1] All of Smalltalk's syntax can be summarized as-
a
obj + 2. "a binary message"
obj methodName. "a unary messsage"
obj methodName: argument. "a keyword message, unlim keywords"
[
[2] You don't even need to know anything about OOP or OOA/D- simpyl the rudiments of *object-based* programming... simply understand that an object is a chunk of data that can do certain things.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Let's start this off nice and flameworthy: what is the point of using C anymore? Nearly any valid C program is a valid C++ program, and C++ gives me the option of selectively using much higher-level abstractions than C can support, with little or no overhead, in a much safer and easire-to-debug way than any pure-C approximation. And most of the projects which are coded in C these days shouldn't even be coded in C++; they should be coded in something higher-level like Java or Python.
C++
Java
Perl
Python
By far the biggest problem with Python is the user community. There's something about Pythoneers that make them glom onto the language with religious zeal, and then go around telling every one else that their own language of choice isn't elegant enough. Many Python users have the mistaken impression that Python is a carefully worked-out work of modern programming cleanliness like Scheme. In fact, Python was an unremarkable in-house procedural "little language" that, rather than dying the graceful death that most such languages eventually experience, was hyped to a larger audience and has been loaded down with all kinds of trendy features. Unfortunetely, due to it's humble roots, these features have gone in rather awkwardly.
All this would be fine, in fact, it would be similar to Perl's story, if it weren't for the singular nature of Python apologists. Python is perhaps the only open-source language whose users will proudly and vehemently defend a language flaw as a feature. The best example is the post-facto rationalization of the extra "self" argument to methods, which the Python FAQ helpfully explains was simply an artifact of the way OO was hacked into an originally procedural language. This fact doesn't deter the fanatics however, who will happily tell you that it was an intentional feature and that it somehow makes Python better.
Other examples of Python's awkward growing pains and the inexplicable attitude of it's users: the fact that Pytho defines private variables as variables whose
--
CPAN rules. - Guido van Rossum
The article reminded me of this old gem:
.o
THE PROGRAMMER'S QUICK GUIDE TO THE LANGUAGES
The proliferation of modern programming languages (all of which seem to have stolen countless features from one another) sometimes makes it difficult to remember what language you're currently using. This handy reference is offered as a public service to help programmers who find themselves in such a dilemma.
=====> TASK: Shoot yourself in the foot.
C: You shoot yourself in the foot.
C++: You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."
FORTRAN: You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue with the attempts to shoot yourself anyway because you have no exception-handling capability.
Pascal: The compiler won't let you shoot yourself in the foot.
Ada: After correctly packing your foot, you attempt to concurrently load the gun, pull the trigger, scream, and shoot yourself in the foot. When you try, however, you discover you can't because your foot is of the wrong type.
COBOL: Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE. THEN return HANDGUN to HOLSTER. CHECK whether shoelace needs to be re-tied.
LISP: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds...
FORTH: Foot in yourself shoot.
Prolog: You tell your program that you want to be shot in the foot. The program figures out how to do it, but the syntax doesn't permit it to explain it to you.
BASIC: Shoot yourself in the foot with a water pistol. On large systems, continue until entire lower body is waterlogged.
Visual Basic: You'll really only _appear_ to have shot yourself in the foot, but you'll have had so much fun doing it that you won't care.
HyperTalk: Put the first bullet of gun into foot left of leg of you. Answer the result.
Motif: You spend days writing a UIL description of your foot, the bullet, its trajectory, and the intricate scrollwork on the ivory handles of the gun. When you finally get around to pulling the trigger, the gun jams.
APL: You shoot yourself in the foot, then spend all day figuring out how to do it in fewer characters.
SNOBOL: If you succeed, shoot yourself in the left foot. If you fail, shoot yourself in the right foot.
Unix:
% ls
foot.c foot.h foot.o toe.c toe.o
% rm *
rm:.o no such file or directory
% ls
%
Concurrent Euclid: You shoot yourself in somebody else's foot.
370 JCL: You send your foot down to MIS and include a 400-page document explaining exactly how you want it to be shot. Three years later, your foot comes back deep-fried.
Paradox: Not only can you shoot yourself in the foot, your users can, too.
Access: You try to point the gun at your foot, but it shoots holes in all your Borland distribution diskettes instead.
Revelation: You're sure you're going to be able to shoot yourself in the foot, just as soon as you figure out what all these nifty little bullet-thingies are for.
Assembler: You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.
Modula2: After realizing that you can't actually accomplish anything in this language, you shoot yourself in the head.
CLARION: You tell your computer to create a program for shooting y
~REZ~ #43301. Who'd fake being me anyway?
As a particular example, take PHP's error handling. The language has no real exceptions, which is forgivable--but it insists of making up for it by faking them.
It has something akin to sigaction(), but much less powerful. It allows you to provide one function to handle all errors, except for some that PHP insists on handling itself. At least that function can switch on the error, right? Nope! There are only 5 different error codes which your code can catch, only 3 of which you can actually throw (again, with a function instead of a language construct).
And if you thought this was bad, try the error handling in the library. Each set of functions seems to have its own function to check for errors, and you have to repeatedly check the manual to find out how a function indicates failure. I've seen the following different methods of indicating failure:
function returns FALSE
function returns TRUE
function prints a message to the browser
function returns 0
function returns 1
function returns nonzero
function returns negative
call another function to find out
functions returns something that can be fed into another function to find out
function raises an error condition you can catch (through fake exceptions described above)
function raises an error condition you can't catch
pass in a variable by reference and the result will be there
check if the returned array is empty, and if it is use a different function to find out whether that indicates an error or just a (legitimate in context) empty array
Don't even get me started on the naming conventions of functions, or the ordering of their arguments. (Check out the array functions if you want some good examples.)
PHP is a language that was designed for small, simple CGI scripts, and it does this well. It does not scale. PHP was never meant to be used from the command line, but how else can you write a cron job to do some nightly maintenance? (Write in another language? Sure, and give up all the libraries you've written for the project.) Sure, you can use lynx -dump http://example.com/nightly.php >/dev/null, but then you have to make sure no one but you can use that script, and it's just generally an ugly thing to do.
For all of its faults (and it has many), one of the thigs Perl does well is provide actual language features for things like merging arrays, sorting arrays with a user-provided comparison function, or declaring a variable with loop scope. PHP's libraries keep growing, which is nice, but the language itself is too small and too limited. I don't want to use library functions for everything, nor do I honestly care whether the language is even context-free. I just want a lanugage that doesn't suck.
</rant>
Gates' Law: Every 18 months, the speed of software halves.