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."

Comments

PHP

[sethadam1]

What he hates about PHP doesn't sound so bad, and doesn't seem like anything that won't be corrected in PHP5.

I knew there was a reason I liked it.

Re:PHP

[DonkeyJimmy]

What!? # is so cool looking though.

As a perl programmer I just read that as "What!? "

Re:PHP

[sethadam1]

Hate to tell you - but all three of those work in PHP. In fact, lots of good PHP programmers use all three for different kinds of comments -

// is for instructions

# is for copyrights

/* is for
multiple lines */

Re:PHP

[Hentai]

syntaces.

And 'anal-retentive' is hyphenated as a noun, but unhyphenated as an adjective - unless it is seperated from the noun it modifies.

Re:PHP

[sethadam1]

I think PHP coders generally lack the ego that non-PHP'ers have. Case in point...parent

Re:PHP

[uberdave]

"You don't tug on Superman's cape.
You don't spit into the wind.
You dont't pull the mask of the ol' Lone Ranger..."
...and you don't make yourself the target of a programming language flame war.

That's right...

[xeon4life]

...we should all use Scheme.

Re:That's right...

[DonkeyJimmy]

...we should all use Scheme.

What I think you meant to say was:
(define language? (lambda (x) 'scheme'))

Re:That's right...

[Bendebecker]

...we should all use Scheme.
They say that a langauge can be judged partly on how many people use it. As such, some other versions of Lisp are probably better since they are a lot common.

Re:That's right...

[Anonymous Coward]

Except that you messed it up. The question mark should indicate a boolean return value.

(define language? (lambda (x) (equal? 'scheme)))

You can tell my code is better, because it has more trailing parentheses.

Re:That's right...

[drgnvale]

>>What I think you meant to say was:
>>(define language? (lambda (x) 'scheme'))

As someone already pointed out, ? indicates a predicate function, which returns #t or #f. And this function really doesn't take a parameter... so I'd actually just define it like this.
(define language 'scheme)

Re:That's right...

[drgnvale]

Well, you might want to call it as a function, so this would be better.
(define language (lambda () 'scheme))

Re:That's right...

[ctrimble]

I agree about the predicate function, but I understood the intention being whatever was passed in, the symbol scheme was returned. Which I then interpreted as meaning that scheme is the primordial language and every language is scheme under the covers. And then I thought that it's probably more accurate to say that Scheme is like Zelazny's Amber and that all the other programming languages are just shadows that differ in some flawed way. (C being somewhere down by the Courts of Chaos). And then I realised that I was out of new Mountain Dew LiveWire(tm) and should get my fifth bottle of the day. Oh, sweet nectar!

The real answer

[ucblockhead]

What I hate about your programming language is that it doesn't work like mine does.

Slash

[Malicious]

I hate your Grammer/Punctuation.

Re:Slash

[Malicious]

You are correct.
Slash isn't responsible. It's the fault of inferior poof reading.

Re:Slash

[Concerned Onlooker]

Please don't bring his grandmother into this.

I hate all the text...

[TheDormouse]

That's why I use Whitespace, of course!

Re:I hate all the text...

[sheetsda]

For those of you who like Whitespace, you might also take a look at Brainfuck. How can you go wrong with a 171 byte compiler? K.I.S.S. at its finest. :)

ummm..

[Pfhreakaz0id]

ASP isn't a language. You can use any number of scripting languages with it. Of course, most are done in VBScript, but many folks use JScript (javascript), because it is what they use for the client side script.

Re:ummm..

[(54)T-Dub]

sorry, i meant ASP in the general sense of VBScript. Just like when I say PC I refer to an x86 machine as apposed to a mac, even though both of them are 'Personal Computers'.

Firestarter

[Flounder]

I used to have a T-shirt that was designed to piss off everybody. It said "Nuke the Gay Unborn Baby Seals". That's what reading this article felt like. Tinder to start a flame war that everybody can join in on.

Re:Firestarter

[Reziac]

The article reminded me of this old gem:

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 * .o
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

I hate

[AvitarX]

I hate all your programming languages because they arn't just a .wav file of my dictating what I want it to do.

PS.
I don't program for a living

Re:I hate

[GlassHeart]

I hate .wav files. They're so inefficient.

Re:I hate

[bbc22405]

I wonder why he didn't pick AAC or Ogg Vorbis. What a doof. :-)

At the end of the day...

[gilesjuk]

Produce a language without some rules and you would end up with even messier code.

I wish some higher level languages would force the use of comments in code, make it part of the declaration for a class or function.

Re:At the end of the day...

[EvanED]

>>I wish some higher level languages would force the use of comments in code, make it part of the declaration for a class or function.

I'm not sure if that would help... how many "// fucking compiler requires this" comments would you see?

Re:At the end of the day...

[elmegil]

/* this is the mandatory comment */

Re:At the end of the day...

[flippet]

I wish some higher level languages would force the use of comments in code, make it part of the declaration for a class or function.

Better would be languages which are self-documenting... you don't need to read the comments because the purpose is clear anyway.

Class or package specifications are an improvement over having to plough through masses of functions; there are bound to be methods of making plain code easier to read in the specification of the language too.

Phil

Re:At the end of the day...

[los furtive]

Yeah, my favorite of all time:

/**
*
* Javadoc goes here
*/

Re:At the end of the day...

[xdroop]

Better would be languages which are self-documenting... you don't need to read the comments because the purpose is clear anyway.

I think that this won't happen, partially for Mr. Kringle's comment above, but mostly because there is a difference between what you do and why you did it (and again from why you didn't do it a different way). You can see function, but you can't necessarilly see the intent of the programmer. There are many times in my programs where a single line (often, less than 10 characters long) will result in several lines of comments explaining why it is done that way. That way, the poor boob who inheirits the job of extending/fixing the program (who is usually me) has a fighting chance of figuring out my intent, not just my procedure.

Re:At the end of the day...

[RevAaron]

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.

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 := 1. ":= is assignment"
obj + 2. "a binary message"
obj methodName. "a unary messsage"
obj methodName: argument. "a keyword message, unlim keywords"
[ :a :b | a + b ] "block creation- a block closure, aka anonymous subroutine"

[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.

Re:At the end of the day...

[Magura]

The University I used to teach at designed and implemented their own OO teaching language that did enforce comments as well as invariants (pre and post conditions on methods).

99% of the comments and invariants were just what the parent described. Sure, as markers we should have bounced more code back to the students, but heck, sometimes we just agreed with them!

Re:At the end of the day...

[mccoma]

An OO teaching language called Blue actually did require comments. It did have an interesting version of enumerators.

Re:At the end of the day...

[RevAaron]

Perhaps that (bad code available everywhere) is part of it... but a big part, perhaps more important, is the environment. Most programmers think an IDE is something that gets in the way, or simply gives you a hotkey for running make. With Smalltalk (or Lisp, Dylan and other languages with a badass IDE), the IDE very much contributes to this self-documenting aspect. Hell, I'd go so far as to say that a well-done IDE is 50% responsible for making a language self-documenting. Most of the rest if a simple language with sensical stylistic traditions.

But yeah, it certainly doesn't help when people simply download packages written by others which are poorly done. Especially when both the the interface/API is bad and the code is messy, no good.

Maybe he doesn't advocate a language, but ...

[codefool]

He does advocate a 'good text editor'.

I suppose tastes are individual in all things, languages and editors alike...

FlameRPL?

[SHEENmaster]

If no one has heard of it they can't make fun of it. Until they realize that I haven't gotten around to loops in the released version yet :-)

I think that varied languages are a necessity. It'll be better when .jar files can be executed from the console, J2dk for Linux/ppc version 1.4 is released, caffeine springs from trees, and C++ no longer requires the programmer to deal w/ pointers. Oh yeah, and all BASIC interpretters are dumped into Sol.

Pretty limited scope

[rpg25]

I looked at this article, and I was disappointed by what a limited set of languages chromatic had examined. Where was Prolog? ML? Common Lisp? SNOBOL? Smalltalk? Dylan? All the languages in the article are in the class of "imperative languages with varying amounts of object-oriented gravy." If you're talking about how languages embody a philosophy, why stick to languages that pretty much embody the same philosophy, with some minor tail-fins and chrome as their differences?

[I suppose that's some flame bait....]

Re:Pretty limited scope

[chromatic]

I didn't list specific gripes about the languages you describe because I don't really have enough practical experience with them to analyze them well. I do discuss languages such as Lisp and Smalltalk in the analysis section though, just as you mention.

Just to be fair, though, one of my gripes with Lisp is the idea that reducing all syntax to a Lambda form makes up for moving all the remaining complexity to built-ins and extensions. I certainly don't think in trees -- a little syntactic sugar is tasty. That doesn't make Lisp wrong; it just doesn't fit my brain as well.

Re:Pretty limited scope

[Usquebaugh]

Haskell, you didn't mention Haskell. How can you mention Dylan, ML without Haskell.

Eiffel, you didn't mention Eiffel. How can you mention Dylan, ML, Haskell without mentioning Eiffel.

Re:Pretty limited scope

[NetSettler]

I looked at this article, and I was disappointed by what a limited set of languages chromatic had examined.

Given the superficial and haphazard nature of the review, I was just as glad it didn't touch on those other languages. I really didn't get much of value out of the article and the only thing that would have been worse is an equally superficial treatment of my own languages of choice.

And anyway, one person's opinion is just one person's opinion. It's a pity the author didn't attempt to do any kind of survey. Even an unscientific survey might have been more interesting and/or informative than this was. In its present form, there's no way to detect hints of incompleteness, idiosyncracy, bias, ... other than to incompletely, idiosyncratically, and in biased form say "well, here's something I noticed that I disagree with".

I'm sorry if these remarks sound critical, but the entire article came across to me as flamebait and I'm not sure what positive quality I can draw from it. It started off as a nice idea--that language philophy can influence syntax or vice versa. But it diverged about halfway through from that to random, unmotivated jabs at this and that language and really ended up going nowhere with few, if any, useful takehome messages.

Maybe I was also put off by the fact that the author's statement, that "Lisp is very much the lambda calculus". As a matter of history, several decades ago, it might have been reasonable to say that Lisp was "inspired by" ideas of the language calculus (though some might say "misunderstandings of the lambda calculus"), but the language was a whole is really enormously different than that now. It is often used as a teaching vehicle for esoteric things like the lambda calculus because other languages can't stretch that far, but mainstream Lisp does not look or feel much at all like the lambda calculus, any more than "modern music is very much that of Elvis Presley", however much his break from the past may have been a founding influence on modern music. This failed allusion injured the author's credibility with me within the article almost irreparably.

Re:Pretty limited scope

[Anonymous Coward]

And how can you mention Dylan without mentioning the Mamas and the Papas? How can you mention Dylan without mentoining Woodie Guthrie?

Re:Pretty limited scope

[NetSettler]

I'd have trouble calling C's type system "strong", personally.

Well, there's strong like Gandhi and there's strong like a bull in a china shop... The term is a bit vague and so I don't begrudge them its use as long as Lisp gets to use another.

Re:Pretty limited scope

[Tom7]

Maybe I was also put off by the fact that the author's statement, that "Lisp is very much the lambda calculus".

Yeah, he pretty much lost all credibility with me there. Basically anyone who's used modern lisp knows that the language has mutated far beyond its initial inspiration by the lambda calculus. And, indeed, anyone who's studied the lambda calculus knows that lisp gets its static scope wrong--and in a language as minimal as the lambda calculus, that's enough to hardly make them related.

The author seems to name drop functional and logic programming languages to make it seem as if he has programmed in more than just C-derived languages, yet what little he mentions indicates that he doesn't have more than a general knowledge that such languages exist. (Functional languages have no variables??)

Re:Pretty limited scope

[NetSettler]

Static Weak: C
Static Strong: ML
Dynamic Weak: Perl5 (just say no, kids!)
Dynamic Strong: Scheme, CL (well, CL is "optional static")

Common Lisp (CL) is also optionally dynamic, in the sense that a declaration is considered to be what I guess would be called in law a "prima facie" case (rebuttable presumption) of truth.

That is, if I say that X is an integer and the compiler cannot prove otherwise, it must believe me. That means it doesn't do either static or dynamic checking, and bad data can screw things up. But the power of this is that if the dataflow is such that it would be impossible for the compiler to prove the truth, I don't have to suffer with slow code (which I think outsiders naively assume I have to do when they hear "dynamic strong").

If the compiler is very smart, of course, it is welcome to disprove any stated declaration--the CMU CL compiler does a great deal of work in this regard, and the resulting feel is very interesting. What's important is that the compiler is not required to do such checking, but it's allowed to do as much as it wants, so the language embraces ongoing/future work in proof technology in a graceful way, yet never changes the meaning of correct programs. It was very exciting to us as language designers to see CMU CL take this idea and run with it--the results are quite interesting, and I'd love to see more of this. One problem with static inference is that the langauge must be designed around the set of inferences that are within the scope of existing technology at the time of the language design; new static inferencing rules require new languages.

Typically, in Common Lisp, one leaves in the dynamic checks that are not in performance bottlenecks, but does more careful by-hand data flow analysis in situations of critical performance and then declares things that one thinks the compiler might not easily deduce. The result is generally the best of both worlds--you aren't beaten down by making scads of unnecessary declarations in development, and you aren't held back from quite efficient programs in production. The main difference is that in C, every program is (at least superficially, ignoring issues of algorithmic complexity) efficient or you can't write it; in CL, you can write inefficient programs long enough to test them without fussing over tons of declarations that might never matter because you're just going to later discard the whole program. When you get to a program you're going to keep in CL, then you want to optimize it. But managers of CL programmers need to know to plan extra time at this point, rather than earlier in a project, or they will be surprised. If (just for seeing actual numbers) you assume that declarations double the time of any code-writing, and if you assume that the first phase of development costs time P (for "prototyping"), and the last phase of development costs time F (for "finalization"), and if you assume T prototypes are needed before finding the right prototype to finalize, CL will take P*T+2*F to develop a product, while C will take 2*P*T+F to develop a product. If you assume that P and F are roughly equal in time, or that T is large, then you can understand why CL programmers prefer not to write declarations. I don't raise these formulas to start a big advocacy dialog here, but merely to show that the shape of the development curve is different for the two languages; even if you disagree with my off-the-cuff formulas, if you agree that the languages have different formulas, you're seeing the real essence of what I'm saying.

This is an example of something 'material' that a paper that talks about the relationship of 'syntax' and 'culture' should have addressed.

Two flame wars in one!

[evronm]

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!

Java and the operator overloading..

[Steveftoth]

He complains that the Java philosophy says 'Operator Overloading is bad,' and still overloads strings. However I think that its the wrong way to look at the concept of operator overloading. Because adding operator overloading to a language is like giving the programmer the ability to change and mutate the language to her desires. In other words, giving a programmer the ability to overload operators, gives them the ability to create their own subset of a language. Similar to macros, operator overloading adds a whole new layer of complexity to what was supposed to be a simpler, easier to understand way of programming.

Re:Java and the operator overloading..

[EvanED]

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.

Re:Java and the operator overloading..

[pohl]

It seems that complex math is always the example people pull out to support operator overloading. I've used complex math exactly once, when I was writing a fractal toy...that I didn't have operator overloading in Objective C didn't bother me. Are there any really compelling examples that don't resort to the tacit assumption that dealing with imaginary numbers is something all programmers deal with on a daily basis? I mean, talk about optimizing for an edge case.

Re:Java and the operator overloading..

[mongbot]

Yes, there are many situations where operator overloading is essential to writing concise and readable code.

* Streams. >> and graphically represent what is going on, and allow the chaining together of multiple elements.

* Strings. + represents concatenation better than a "concatenate" method could. Even Java agrees.

* Iterators. hasNext and Next is overly verbose and unnecessarily complicated, compared to ++ and *.

* Containers. Subscripting (a[i]) is a very common operation and looks much clearer with nte subscripts than a "at" method.

* Function objects. Having objects which can be called just like functions, "object(argument)", is crucial to creating generic algorithms.

* Assignment and Equality. Assigning from one class to another using = is better than an "assign" method. Testing for equality with == and != is much clearer than an "equals" method.

Anyway the whole "designing a new programming language" argument is wrong, because an operator is simply a function with a symbol and precedence. That is all. If operator overloading is defining a new language, then so is writing new functions.

Obviously people can misuse and overuse operator overloading, but that is true of any language feature and should be expected. You can design the perfect language, but it will always be possible for bad programmers to make a mess with it.

Re:Java and the operator overloading..

[0rbit4l]

Phew, yeah, that overloading just complicates things beyond the point of reason. I mean, wouldn't you rather use this form:

determinant = (b.multiply(b)).subtract( ((new BigDecimal(4.0)).multiply(a)).multiply(c));

than this:

determinant = b*b - 4*a*c;

Yeah... thank god there's no overloading! (hint: this is just an illustration - I know I can use builtin doubles rather than BigDecimal.) Forbidding operator overloading is just silly. To claim that "java is simple - see, no overloading!" while ignoring the pain it causes is equally silly.

Say What?

[fidget42]

Python programmers like indentation.

As a python programmer, I loath its indentation sensitivity. It is hard to find the end of a block and heaven help the people who use tabs rather than spaces for indentation.

The lack of good line termination (sorry, but a caridge return doesn't cut it) is another problem.

Re:Say What?

[los furtive]

Amen to that! I used to think that tabbing as a form of indent was a major sin, but since most IDEs these days (and every text editor worth its weight in salt) will allow you to adjust tab length/replace tabs with spaces/replace spaces with tabs, I don't see what the big deal is any more, and in fact I think tabs are a better choice.

Re:Say What?

[demi]

Yeah, I always forget if it breaks if you put a space after the \ character, and then I forget if you're supposed to indent another level or to the same level on the continued line. All of the other python programmers seem to have the same problem because all our Python code here is characterized by godawfully long lines.

Note to repliers: this isn't a question I'm looking for an answer to, and it's not a criticism of Python (well, okay, obviously it is, but I hope you won't take it personally).

HA! Missed me!

[secolactico]

No mention whatsoever of BASIC or Logo. Yes! At least he spared my languages of choice.

It's not always technical

[fishlet]

I don't think it's always technical. A few years ago it seemed like most comments in regard to Java were positive, but when it became evident that it wasn't really "free" in the same sense as is perl or python... then lots of people started bashing it. Though like many languages has it's flaws, it still remains a solid language. The same with VB, virtually no-one in *this* audience considers VB a great language, which is reinforced by the fact that no-one's really putting much effort into creating a VB like tool for Linux (albeit there are several dead projects that have tried). It's a shame because VB actually works quite well for a particular niche- quickly developing business apps. In the case of VB, I can safely predict most people here will not give it credit because of it's links to Monopolysoft.

Re:It's not always technical

[Sylver Dragon]

Actually, I kind of like VB for certain purposes. I am not, nor do I have any wish to be a programmer, but sometimes there are things you just can't do in a batch file, and dammit if VB isn't a nice way to get around this limitation. Not to mention that it looks a bit cleaner, and certainly less scary, to the average end user, than a command prompt. Plus the ability to send windows messages (logoff and the like) can be really damn useful.
So yes, VB is another MS product, but it can still be a very useful tool if you live in a windows world, and don't want to bother with becomming a programmer.

Re:It's not always technical

[aardvarkjoe]

Well, I rather suspect that the main reason why you see a lot more Java bashing is because most CS students used to have to learn C++; now they have to learn Java. Since /. is mostly high schoolers and college kids, you have a whole bunch of people that were forced to learn the language in the last few years. Obviously, you're going to end up with quite a few people that don't like it.

There's not really all that much bashing of any other non-free stuff (the exception being Microsoft, but that's mostly because they're still beating up on the penguin.) I don't see it as being the primary reason for Java bashing.

Re:It's not always technical

[Cynikal]

i'd have to say one of the things i hate the most about VB is the huge runtimes.
oh how much would i pay for the front end of VB that compiled to a stand alone exe comparable to asm coded executables.

Re:It's not always technical

[pi_rules]

I can safely predict most people here will not give it credit because of it's links to Monopolysoft.

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.

• Lack of short circuiting conditionals really started to eat me up. Mostly because every other language I used (except BASIC) would short-circuit conditionals. All too often I would find myself writing complex loops using short-circuits and then realize later on I had totally blown the algorithm. I wasn't the only one either. I saw experienced VB guys do stuff like: If (objRS IsNotNull AND objRS.RecordCount > 0) Then.... Not much fun when that blows up.
  
  
• Some consistency would be nice. I think Pascal is the only other language I've ever used that would let you declare a function in two different ways. One for returning data and one that didn't. The seperation of Sub and Function is a friggen mess. It's even worse when you realize later on you need to return a boolean out of your Sub and suddenly you have to track down everybody that called it and change the method of which you call it.... even the ones that could care less about it's true/false return. What's wrong with the return type void?
  
  
• No macros or a precompiler. VB didnt' clean up unused objects very well for itself and one point in time, if I recall correctly, which made developers (at least at where I was) make sure they always set objects to Nothing before a failed function would return. That's find and dandy, but I hated repeating the same awkward (due to lack of short-circuiting conditionals) cleanup code in function after function that were nearly identical. Think nearly identical functions with a bit of business logic in them passing data off to a data layer for the real DB access. Each function had maybe 3-4 lines of individual code, sometimes up to 20 though. Every function though was at least 30 lines long, with the same drivel repeated over and over again. How much better it would have been to write:
  
  If (ErrorState = True) Then
  CLEANUPCOMMONOBJECTS
  End If
  
  If I had good exception and a good GC I wouldn't have even needed this though.
  
  
• That damned VARIANT type needed for COM. Okay, this is common amonst all COM enabled apps when going across boundaries, but it really stunk if you asked me.
  
  
• Little bugs. If you return a 'decimal' datatype from an ADODB.RecordSet and called IsNumeric() on it would you expect a true or false? Assuming the value in question wasn't Nothing, you'd assume it's true, right? Bzzzzzz!. IsNumeric(CStr(val)) would return true though. All because IsNumeric didn't understand all the possible variant datatypes that you could toss into it. Minor oversight, but it turned up a pretty decent and noticable bug in my code once. Err, wait, that was VBScript, anybody know if that happens in Real VB?
  

It's a short list, but it's been a while since I coded in it.

Re:It's not always technical

[radish]

OK, standard disclaimer: I did CS at a (very) good uni, and was taught the "proper" way to program, via Miranda, Modula, Smalltalk, Prolog, Turing etc. Never learnt C++ (all our lecturers hated it) - Java had only just come out at the time so did very little of that.

Went straight into the finance world - first 2 years or so were straight ksh/perl/sybase - you'd be amazed how much of the banking world is held together with that stuff (which I affectionatly term "sticky tape"). Don't get me wrong, perl is great in it's place - but for enterprise trading apps? Nope, sorry :) So anyhow I know that end of things pretty well. Then I moved onto front end apps - which as you point out are frequently VB. The ones I worked one were typical of the generation built 5-10 years ago, and which are now proving to be maintenance nightmares and getting ripped out. I'm speaking of the 2-tier, VB front end, Sybase/Oracle stored proc back end. Yuch - horrible stuff. VB is fine for GUIs, provided you only care about running on windows (which we do) and don't mind having to desktop installs (tolerable). But VB programmers tend to think the language is all powerful (don't ask me why) and build all the business logic in there to (or even worse, build it into a myriad of massive sprocs) - that's a big mistake. The language is too loosely typed, too vague, and basically too much of a mess to write important code (IMHO). Maybe things have improved (I know some things have been fixed), but when I was working with it you had virtually non-existant error/exception handling, no polymorphism, no inheritance - to be honest it's whole notion of objects was kind of broken. It just felt yucky to me, as a formally educated coder (not trying to say they're the best kind, just that's what I am). Even perl felt that at least it was being honest - it had it's strengths (and it's damn good at them) but it doesn't try to be more than it is.

So that brings me to now - and Java. Picked it up a few years ago - the language just makes sense to me. It's a simple language (and don't start on how big the class libs are - that's not the language), and it works. Sure some of the library classes aren't as wonderful as they could be, but they're being fixed pretty quickly (for instance nio, enhancements to collections, etc). The speed with which you can develop apps and - FAR more importantly - the level of correctness which you get at first round testing surpasses any other development platform I've come across. I'm currently heading up development on a (server side) project with 5 developers and 6 months of time. We've spent that time designing, churning out code, and testing. Not fixing bugs. There's none of the days spent chasing memory leaks or weird core dumps my colleagues working with C++ get. Are we better coders? No, the platform just seems more condusive to writing correct code the first time around. I've got people on my team who used to be C++ coders (and good ones at that), and when I ask them about implementing this project in C++ they just laugh. Honestly.

Oh and as for microsoft, I haven't had a chance to spend much time with C# yet, but I look forward to doing so. So what did this have to do with VB? Very little...sorry for rambling :)

Re:It's not always technical

[Steve G Swine]

Scary thing is, all the things you mention are gone now in VB.NET.

AndAlso/OrElse for short circuits, subs and functions all take parens to call, real exceptions, variants are dead, and they took the VBScript IsNumeric oddities to the grave with them (though you were begging for pain when you relied on IsAnything with VBScript).

I mention this lest you think VB was crippled forever... Try the new stuff - it's like object oriented code with real words, instead of seventy different types of punctuation to make something simple look like some goddamn magic trick.

Re:It's not always technical

[wganz]

What about Kylix? Could it not be the "VB" for Linux?

I don't have the experience with Kylix as I do with VB to definitively say one way or the other. Cross platform to a certain extent. But the Delphi compiler for Windows is quite pricey.

my $0.02

Re:It's not always technical

[Microlith]

Borland Delphi

Sure it's not BASIC, but then that's not exactly a bad thing.

Compiles down to a standalone executeable.

Re:He likes JavaScript???

[kervel]

i disagree. he did not complain about the lack about regexes in java, he complained about the fact the interpreter and standard library are one big package.

also i think he correctly talked about 3 key issues: syntax, usage, and extra features (libraries/tools). what's important about a language besides that ?

something cool that I like about .NET

[fine09]

This just brought to mind the .NET CLR.

I have done a little bit with this, coded a couple apps where a member on my team really really liked VB and myself a java guy liked J#.

We could work well together without having to worry about learning a syntax that we didn't feel comfortable with.

Calling Card of a Horrid Developer:

[WndrBr3d]

<%@ Language=VBScript %>

Is you see this, please call Crime Stoppers at (888)580-TIPS.

Re:Calling Card of a Horrid Developer:

[nutbar]

Is you see this, please call Crime Stoppers at (888)580-TIPS.

But what's TBL's mom's number?

But

[Timesprout]

As the article points out many languages have a lot of quirks. While the pragmatic programmer is one of my favourite books on coding I dont think learning a new language every year is a particularly useful thing to do. There is a world of difference between just 'learning' a language and gathering the experience over an extended period of time to become truly proficient in it. I already code in serval languages and while I might have a passing interest in reviewing a couple more just to see how they work I really dont want to invest the time required to learn them properly when I dont see them appear in job adverts.

Believe it or not...

[Anonymous Coward]

...I work at a company that uses an early 1970's mainframe (won't divulge any details). We use punchcards (yes punchcards) to program the beast in FORTRAN. As you may or may not know, FORTRAN was originally adapted to punch cards, hence the 80 column limit and the 6 column space prior to issuing commands. (These limitations have been relaxed in FORTRAN 90/95). Of course, I also program on other, more modern systems using other languages, mostly C++ and Perl. However, I still find myself writing programs that basically mimic FORTRAN's style. I prefer short lines no longer than 80 characters and capitalized command names, etc. Once I actually rewrote some of gcc's source code so that reserved words like for, while, switch, etc. were changed to FOR, WHILE, SWITCH, etc. I also capitalized the functions in the standard library (!). Since then, I've gotten over my capitalization fetish, but FORTRAN's code still looks better to me. I guess old habits never die.

As a novice programmer...

[Anonymous Coward]

I love Squeak. It's SmallTalk, OO, Realtime, runs on anything, and is easy to cope with.

Check it out, if you are older, like me, and getting into programming but have never programmed much before:

http://www.squeak.org/

Can't anybody get C right?

[Animats]

C is the syntactical ancestor of many programming languages today, but none of them get it right.

ANSI C itself is at least stable. The procedural part of the language is generally accepted (it's basically the same in Java, C++, etc.) The declaration syntax has problems. It's broken for historical reasons. Originally, C was LALR(1), but then came "typedef", and it went downhill from there with "class", etc. Nobody has been able to fix this properly. This is why the parser gets lost in so many error situations.

C++ suffers from some early bad design decisions. Templates came late. Strostrup knew about templates, and decided not to put them in. This led to great pain and ugly code, templates went in, and it's taken a decade to clean up that mess.

Java was supposed to clean this all up, but now Java is getting generics, which it wasn't supposed to need. So it's going down the same path as C++, but with a new set of mistakes.

Other attempts to fix C include Objective C (which still has a following) "C+@" (a Bell Labs product that predates Java), "C#", a Microsoft variant, and several others with tiny market share such as "D". None are enormously better than C.

I'd like to see C++ cleaned up, but the ANSI committee is more interested in putting in obscure features for template writers.

Re:Can't anybody get C right?

[be-fan]

I think the main problem with C++ is that you *can't* clean it up. It took an agonizing 5 years for compilers to finally support the C++ '98 standard, and any breaks in compatibility at this point will have developers up in arms. Also, remember that there are many large software systems written in C++ than Java or Python, so they can't afford to change things in a way that would break that code. Heck, given the pains Sun is going through to implement generics, I'd say that even Sun is having problems because of the need to mantain compatibility.

So right now, the standards committie is trying to fix what it can. Since template metaprogramming is a aspect of C++ without a lot of compatibility issues they can afford to change around stuff a little bit without pissing too many people off. And god knows the template mechanism needs some attention. Template metacode is rather ugly. Some of the suggested features in C++ 0x, like template typedefs and typeof will greatly help in making template code easier to read.

Re:BASIC

[flippet]

I hate to break it to you, but compiled BASIC is very very old, long before VB. I remember compiling eBASIC startrek games in 1979 on CDOS (a CP/M variant from Cromemco).

Shhh, he's having a Microsoft bashing moment... it could be dangerous to interrupt slashdotters whilst in this state, you never know what they might do...

Phil

Re:Great article!

[chromatic]

My only complaint about the article is that his condemnation of XSLT isn't rabid and acidic enough for my tastes.

I've used it to great effect. It does what it says it does. Combined with XPath, the syntax makes my eyes hurt, but it's stunningly effective.

I think I'd rather see s-exps or even Python's indentations than a sea of angle brackets, but the choice of XML for syntax actually makes sense.

Re:You are probably the worst programmer you ever

[neurostar]

you'll be stuck running your code on a microsoft server

http://www.apache-asp.org/

Currently just supports perl scripting though.

neurostar

Language indepedant: Debugging

[CuteAlien]

Actually i enjoy programming in a lot of languages and, as problably most who programmed for a while, the problem is seldom the language (otherwise you chose the wrong for the job).

But it always get's ugly when it comes to debugging. You're in a bad mood anyway (it's a bug - probably your bug - and it will cost you, very probably, even more time than programming the whole f**king function).

No matter which language, after a while you start hating your debugger. You're programming 3D and have a problem with vectors - all u see variables with some numbers. You're programming a database and the results don't fit.. all you see are variables with wrong result. Etc...

It's always like your car broke down and you get messages like iron content of bumper 100%, mass of bumper 1.4, foo.ineedtorenamethis 1.5...

And then you gotta dig through the dirt :(

Re:He likes JavaScript???

[notfancy]

JavaScript is a really nice language. For starters, Waldemar Horwat sure knows his stuff. He seems to give a lot of thought to new features before introducing them (check out the project page) and has managed to write an interpreter that can be configured to accept varying language versions (as in language="JavaScriptXXX"). Then, the whole idea of a prototype-based object-oriented language becoming mainstream should have made the Self team green with envy. It supports very powerful constructs, like dynamically attaching behavior to built-in objects via __prototype.

Besides, JavaScript inconsistencies between browsers is mainly a DOM issue, not a language one. Chromatic should have blamed the browsers, not the language.

Re:He likes JavaScript???

[moof1138]

It is easy to rip on an article with the sort of vacuous criticisms you fired off, but you really did not address a single real issue in the article. First off, you make it sound like he is advocating JS, which in reading the article is clearly not the case.

Secondly, covering your criticisms:

When he said that working with anonymous structures or structures by reference can be ugly, you interpreted 'ugly' as 'looks like.' But the ugliness in 'my $count = keys %{ $self->{groups}[HACKERS] };' is ugly in more than just looks.

The poster above already pointed out your gross oversimplifications regarding Java.

Finally, your point that "there are much worse things to complain about languages, besides syntax, and inappropriate usage," is correct, and the article itself does just that.

In short, your analysis is overly simplistic, and full of fluff.

Reactionary languages

[SimHacker]

Many languages weren't designed, they were just reactions to the mistakes of other languages.

Perl is a reaction to the flaws of many different languages. Unfortunately it reacted by imitating all the worst flaws of all the worst languages. People who think Perl is great are totally ignorant of other languages, and have extremely bad taste. They are desparate about their job security, which is why Perl is the best choice for corporate parasites looking to drum up busy-work to justify their salary.

PHP is a reaction to Perl, used by amateurs who were burned by Perl, but actually want to get work done, however they don't know any better languages. Perl (mis)taught them that programming languages were extremely difficult to learn. But they couldn't stand Perl, so they switched to PHP because it seemed "simpler", without realizing how much better other programming languages are. So they stick with PHP because they're afraid to learn another programming language, having been traumatized by Perl, and tranquilized by the incredible mediocrity of PHP. PHP was designed to recruit disillusioned Perl programmers.

C++ is a baroque overreaction to C, whose designers were obviously ignorant about programming language design, learnability, usability, readability and maintainability. So all those lessons had to be (mis)learned again, the hard way. Which brings us to...

Java is a moderate reaction to C++, that still ignored much about programming language design that C++ designers never bothered to learn (so as not to drive off C++ converts by forcing them to learn new concepts). So if you know C++ but don't know Lisp or any other reasonable language, you think Java is great. Java was designed to recruite disillusioned C++ programmers.

So PHP is to Perl as Java is to C++. The lesson: You can't fix a badly designed, fatally flawed language by imitating it.

-Don

Re:Reactionary languages

[mbrubeck]

Paul Graham put together a brief list along those lines, titled What Languages Fix.

Re:Reactionary languages

[Bendebecker]

I know Lisp, Java, C, C++, PHP, and Prolog. First, I think your view of PHP and Perl is correct but don't ignore that fact that they are very powerful and very useful languages, regardless of their flaws. Just because PHP is simple doesn't take anything away from it, it was meant to be simple. Every language was designed with a use in mind and PHP in that theater has its uses that make it better than other languages. People don't just use PHP becuase "they are afraid to learn other programming languages." Rather most poeple use PHP because it is the best tool for the job.

As for the rest it just seems that your pissed off that people perfer languages that aren't Ada. C++ is sort of a mess, I'll give you that, but that is mostly because they tried to keep too much of C in it. As for Java, it is a grea language. It is very readable, it is easy to write, it's OOP design (if implementing a good modularized design) makes it very easy to maintain, etc.. The developers didn't ignore programming language design, they made choices as all developers must. They had certian goals for the language in mind and they met those goals. Just because you don't like their design choices doesn't mean they didn't know how to design. You have to make trade offs as well. You can't have your cake and eat it too. I have programmed in Lisp. Java is still great. Java is an object oriented language, Lisp is a functional langauge. They have different design issues for different paradigms. As for readibility, writibility, and maintainability consider this: how many versions of Java re tehre? How many verison sof Lisp are there? Ever try to write a Lisp program that could runb in all implementations of Lisp. How about teh fact that Lisp goes crazy with (). Every try to read a Lisp program with twenty nested function calls? Even writing them and trying toi keep track of all those () are a pain in the ass.

Go read "Programming Languages" by Kenneth Louden.

Re:Reactionary languages

[frodmann]

Some very strong comments. It appears that you have dabbled in these languages but not used them for anything serious.

I use perl and its not because I'm ignorant of other languages. I've built applications using many different languages including functional languages like Haskell, logic languages like Prolog, strongly typed OO languages like Java and C++ and scripting languages like tcl, bash and perl.

Perl has some extreme strengths, I find it useful from complex shell script and trolling log files for useful information. The wealth of modules available make it extremely easy to perform almost any task in very little programming time.

I admit that for larger applications I would prefer to use Java as the need for more robust, reliable and maintainable applications become more important than quick development time. Java is great but you definitly need a reasonable IDE like Netbeans or Eclipse to improve your efficiency, otherwise even simple tasks can take some time.

What I want is...

[Bendebecker]

A programming language where I don't have to do any work. One where I can just decide, "hey, I have a great idea for a program" and then discover that my computer had already programmed it for me.

Language is irrelevant

[The Bungi]

As long as you have a good library and support of some type (community or corporate).

Other than that, the language is just like the favorite couch - it doesn't really matter where you sit, but that one just happens to be more comfortable.

That's one of the reasons .NET is cool. It provides a unified runtime library that caters to any number of languages, as long as someone has bothered to port them. The end result should always be the same. We joke about COBOL.NET, but the reality is, it's made possible by this - dare I say - revolutionary idea. Soon we'll have Python.NET, Perl.NET, Ruby.NET, PHP.NET, etc, etc.

You will be assimilated =)

Re:Language is irrelevant

[Laplace]

I think that the gcc group had that figured out first. gcc uses front ends to translate the c, c++, fortran, java, and whatever other languages it can use to intermediate files, which are then compiled to assembly then machine code.

Once again, Microsoft "innovates" themselves into territory where others have lead them.

Re:Language is irrelevant

[Lazarus Short]

Soon we'll have Python.NET, Perl.NET, Ruby.NET, PHP.NET, etc, etc.

Actually, that's unlikely.

This blog entry by Dan Sugalski gives an expanation:

First things first--both the JVM and .NET are perfectly capable of being target machines. They're fully turing complete, so it's not an issue of capability. But, like the Infocom Z machine, which is also turing complete, the issue is one of speed.

Perl 5 has two big features that make using the JVM or .NET problematic--closures and polymorphic scalars. Perl 6 adds a third (which Ruby shares) in continuations, and a fourth (which Ruby doesn't) of co-routines. (Though arguably once you've got continuations, everything else is just a special case) Python has similar issues, though I'm not the guy to be making statements about Python, generally.

Wrong, Wrong, and Wrong

[avdi]

C++ suffers from some early bad design decisions. Templates came late. Strostrup knew about templates, and decided not to put them in. This led to great pain and ugly code, templates went in, and it's taken a decade to clean up that mess.

Bjarne wanted to put generics in from the very beginning.

Java was supposed to clean this all up, but now Java is getting generics, which it wasn't supposed to need. So it's going down the same path as C++, but with a new set of mistakes.

Java "cleans up" nothing, it simply strips out all the more powerful features of C and C++ which novices tend to stub their toes on. Oh, and it adds one important feature: inner classes. Unfortunately the result is a language whose omitions actually make it more verbose and harder to maintain than C++.

Other attempts to fix C include Objective C (which still has a following) "C+@" (a Bell Labs product that predates Java), "C#", a Microsoft variant, and several others with tiny market share such as "D". None are enormously better than C.

Neither ObjC nor C# is an attempt to "fix" C; Objective C is an attempt to embed a Smalltalk object system in C, and C# is an attempt to fix Java. Neither of them are applicable to the same problem domains as C.

I'd like to see C++ cleaned up, but the ANSI committee is more interested in putting in obscure features for template writers.

Everything in C++ belongs there, and most of it was intended to go in from a very early stage. The only thing that needs to be "cleaned up" is the C preprocessor. Templates could use easier syntax but no one has come up with anything signifigantly better than the current syntax.

Re:Wrong, Wrong, and Wrong

[the gnat]

Unfortunately the result is a language whose omitions actually make it more verbose and harder to maintain than C++.

I disagree with this a little; I find uncommented Java code easier to understand than commented C code. Regardless, I'm not a huge Java fan, partly because I've always found the class library to be a pain in the ass. The first Java project I worked on, I spent hours trying to figure out how to manipulate dates properly. Writing the code in Python or Perl instead would have been much shorter, easier to understand, and took me a few minutes to figure out. I've never figured out how Java's anal retentive typing is supposed to make this type of thing "better".

It's not plus, it's equals-equals!

[the-matt-mobile]

It seems that complex math is always the example people pull out to support operator overloading

I was just thinking the same thing as I read the parent comment. Everyone uses complex numbers as an example. But, when programming in Java, it's not being able to overload == and != (and even sometimes [] if we're talking about collections) that drives me up a wall!

Take for example a class which contains both native types and objects. In order to implement the equals(object obj) method, you have to do the following:

return this.intType == obj.intType && this.objectType.Equals(obj.objectType) && this.byteType == obj.byteType && this.objectType2.Equals(obj.objectType2); // etc. etc. etc.

Yes... it's functional. No, it's not pretty. And that's where operator overloading is most sorely missed in my book.

Re:BASIC

[sketerpot]

It wasn't so bad because it was nearly dead, rather than a huge thing that gets packaged with most office software and goes wandering around like a zombie of a language that just won't die. Why can't it be replaced by a good language like Python? (I also hear good things about Ruby, and the example programs look pretty clean. I haven't gotten around to learning it yet.) I mean, who wants to keep writing "dim" statements until the end of their days?

Curse you, Microsoft, for resurrecting Basic.

Don't get me started about machine language.

[Anonymous Coward]

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.

Re:Don't get me started about machine language.

[sean23007]

Oh I know! One time I accidentally pressed '2' and my computer grew a leg and kicked me in the nuts. Who knew?

Visual C++

[ucblockhead]

Probably about as many as the number of "// TODO: Place code here" in Visual C++ projects.

Self-documenting?

[steveha]

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

Re:Self-documenting?

[geckofiend]

After more than a few commerical projects where people don't know the meaning of whitspace (or commnets for that matter) I'll take Python's forced whitespace any day.

Re:Self-documenting?

[Bob Munck]

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 allows you to write what your program does as code. Most other languages make you kind of sneak up sideways on what you want the program to do, tricking the language into doing your desire. Then you have to add comments to say what it is you really wanted. I write quite a few comments in programs to remind myself (and in some circumstances others) what the program does. In Ada, I'll write the code, look at it, realize that it says what it does, and not need to write comments. My best code has no comments, and no need for them. (Except for hypertext pointers to design and requirements documents.)

I don't understand about the "hemmed in on all sides by language rules." Ada has fewer rules than, for example, Java. That is, the syntax and semantics can be expressed in significantly fewer definition constructs (BNF, VDL, whatever). For me, moving back to Ada after a stint programming in Java or C++ is like coming out of a dark and stuffy room into a nice spring afternoon.

Python was designed by a guy who is both a computer geek and a math geek.

So was APL. Ever seen APL? It's essentially encrypted at the source.

Re:Self-documenting?

[Mooncaller]

I really don't care if no one uses Ada right now. It has got so many advantages over C that it is well worth learning. I use it for my personal coding. I have several projects cooking. Once they are stable ( and documented, even Ada need good documentation!) I will be releasing them GPLed. If the community ignors them because of the language, so be it. I don't care. I want secure maintainable code. The only real problem with Ada is that which is common to all strongly typed languages and that is it is easy to get carried away defining types. As more project leaders come to the conclusion that the most of the problems with modern code can be traced to errors that are a direct result of the characteristics of C/C++, the appeal of Ada will increase. The only other contender is Java but it carries too much baggage.

Re:Self-documenting?

[Suidae]

My intent is that a person who doesn't know Ada at all, who has had maybe a single Pascal course (and who speaks English), will be able to understand my programs because of the choice of names, structures, and constructs.

Excellent! I love coming across code that has been written that way (and try to do so myself as often as possible). Often I find that choosing names for things is one of the the hardest parts of getting a good design. Probably an indicator that I need to study more design patterns :)

Re:Thanks for examples, dickhead.

[Anonymous Coward]

jerk off.

I will, thank you.

Unlike programming languages, jerking off is something we can ALL enjoy.

Redefining a language is essential.

[rjh]

Ask any LISP programmer how well they could work if they weren't allowed to redefine the language (redefine it on-the-fly, even). Operator overloading is not bad; it's reckless use of overloading which is bad.

If you overload + so that it suddenly means "Multiply by 34 and truncate to the nearest prime", that's not the language's fault: that's your own fault for being a damnfool idiot. Just like if you overload + for complex numbers so that it does complex arithmetic, it's not to the language's credit: it's to your credit that you used an appropriate overload.

Look at LISP, in which pretty much any part of the language can be overloaded. Nobody's ever complained that this linguistic flexibility has harmed LISP; in fact, this linguistic flexibility is almost universally hailed as one of LISP's strengths.

Parting thought for the overloading-is-bad crowd:

C overloads, too.

After all, you can do:

float pi = 3.14159;
float e = 2.71828;
float result_float;
float result_int;
int constant = 1;

// + defined for addition of two floats
result_float = pi + e;
// + defined for addition of two ints
result_int = constant + 0;
// + defined for addition of a float and an int
result_float = pi + constant;

... I mean, come on. C overloads, so "overloading is evil" is a meme which you really ought to know better than to propagate.

Overloading isn't evil.

Stupid overloading is evil.

And you will never, never, never, succeed in creating a programming language in which it is impossible to do stupid things.

Re:Redefining a language is essential.

[rjh]

While technically right, this misses the point.

McCarthy's LISP 1.5 was never meant to be used by industry. (In fact, it was never meant to be a computer language at all; McCarthy's LISP was meant as a simpler model of the Turing Machine, and it was only turned into a proper programming language by an enterprising grad student.)

MacLISP, ZetaLISP, etc., were all attempts to take a purely theoretical language and turn it into a language useful for productive tasks. Why do you consider this to be an example of LISP's flexibility causing forks? If LISP wasn't that flexible, it would have never been able to make the leap out of the laboratory and into the real world.

Once people had experience at making LISP work in the Real World, then Common LISP came about. This is the way languages evolve, and that's just the way it should be.

No language ever springs from a designer's head full-blown and perfect, like Athena erupting from Zeus' skull. A cycle of languages diverging and then converging is a sure sign that the language is healthy and alive.

Looking at it from the reader's perspective

[Ilan Volow]

One fault I find with the author's assessment is that he is evaluating the language only from the standpoint of the one who is writing in it. I think a better language assessment would also evaluate a language from the viewpoint of the poor bastard who actually has to read someone else's code written in that langage. Does the language have the tendency to produce code that is readable and understandable by the person who didn't write it? Or does the language have the tendency to produce code that is readable/understandable by only its original author?

For example, Perl allows the programmer who writes a perl program try to make their code as terse and unreadable as possible, fitting everything on one line by exploiting some bizarre behavior of the perl interpreter. While this "expressiveness" might be wonderful to the person who's writing the code, it's really going to be a problem for a second person who might want to contribute to it or maintain the project after the original author threw in the towel or got hit by a bus.

Another example is operator overloading. Perhaps operator overloading is useful to the first person writing the code, as it provides a nice little shortcut where they can do foo + bar as opposed to something like foo.add(bar). But if there's another person who's decided to work on this project, and they're not very familiar with the code and they are trying to get the idea of how it works, how can they tell whether foo+bar is a mathematical operation or some sort of concatenation? Yes, if they look over the code enough, they can understand it. But perhaps that extra amount of fuss and the extra amount of time wasted trying to make sense of things will convince that person it would be easier to write their own stuff than try to reuse someone else's.

A final area I wish the author focused on is documentation. Does the language support some sort of embedded and standardized documentation that make it easier for the first programmer to provide information that would help a second programmer make sense of the code, or is documentation at the discretion and mercy of the first programmer and whatever bizarre and non-standard documentation system they might use?

I would suspect that projects using languages that make it harder on the person who has to read the code have higher incidences of duplication of effort and a great NIH (Not Invented Here) tendency.

But that's just my opinion.

Re:He likes JavaScript???

[notfancy]

A side note: I've seem to have commited the sin of misattribution. Waldemar Horwat is not the current driver (or a peer) of the JS module at Mozilla: Brendan Eich (the original author at Netscape) is. Mr. Horwat seems to have been one of the redactors of the ECMA standard, though.

Re:Thanks for examples, dickhead.

[larry bagina]

Unlike programming languages, jerking off is something we can ALL enjoy.

I don't have any hands you insensitive clod!

Scheme -vs- Common Lisp

[SimHacker]

Scheme is the intersection of all Lisps.

Common Lisp is the union of all Lisps.

It's not a matter of one sucking and the other ruling. They're both much better than most other languages. Because missions come in different sizes, it's great having a choice between a light fast sports car and a huge urban assult vehicle.

Python's design was wisely inspired by Lisp. It's somewhere between Scheme and Common Lisp in complexity, and rates extremely high on the practicality scale (integration, library support, community, portability, footprint, design focus, long term plan, etc). But Python isn't as useful as Lisp for metaprogramming (because it doesn't have a real macro system).

-Don

Delphi..

[jagilbertvt]

What we can conclude from this article is that Delphi roxors :)

Re:He likes JavaScript???

[Moonshadow]

Very true, and very good points.

I used to -despise- Javascript...then I started hacking on Mozilla/Firebird extensions. Once I realized that it was the provided API (via the browsers) that was crippled, and not the langauge, I really came to love it.

Of course, I still hate using it in webpages.

Re:Pascal?

[JohnQPublic]

When Knuth set out to reinvent publishing, he had to decide what language to write TeX et al. in, and wanted others to be able to use it (or he'd probably have coded in MIX). In later years, he explained that he asked everyone he respected to name their three favorite languages. There was a wide range of #1s, but most folks put Pascal as #2. So he wrote in the language that everyone liked less than something else.

On the other hand, if Pascal is good enough for the gods, it's good enough for us grunt coders.

Whitespace: a great macro language for Python

[SimHacker]

Somebody should write a Whitespace macro front-end for Python, then it will be better than Lisp!

Re:define "good"

[sethadam1]

In fairness, some IDEs color different comments different ways. I've seen people use the different comment styles to make different kinds of comments. There's no steadfast rule, it's just preference, and SOME people use them that way.

I understand what you're trying to say, but PHP doesn't really have a counterpart. You can't really compare it with Perl, Java, or C++. The closet we have to something that compares to PHP is ASP, which is hardly a substitute. Perl wasn't really designed for web use, althought it's found its way there.

Either way, you seem awfully angry about this. PHP is flexible and is meant for all programmers. Like the rest of the Linux debates, the camp that "hates" PHP is often the same people who are elitist about Linux in general.

OK, Here's My List

[avdi]

C
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++

• Manifest typing is so damn verbose! If the compiler's so clever, why can't it do a little type inferencing?
• Needs Java's inner classes to do typesafe pseudo-closures
• All C++ compilers suck. This in itself is not the problem; the problem is that all compilers suck differently.
• Templates are powerful, but ugly
• C++ code is full of juicy semantic information, which all IDEs uniformly fail to exploit, making coding far more painful than it should be in such a mature language.

Java

• In their haste to throw out every frightening piece of "complexity" from C++, the designers managed to throw out all the expressive power as well. The result is a langauge that is so syntactically impoverished that it is actually less readable than C++, the language it sets out to improve upon. See the bloated maintenance nightmares that are used to work around the lack of enums, just as one example.
• Ironically, by eschewing out C++'s "confusing" features, Java actually manages to be more error-prone than C++. For example, by forcing casts to be used everywhere, Java defers to runtime a whole class of errors that would never make it past the C++ compiler. This makes type errors much harder to track down, hardly a net gain for the novice programmer.

Perl

• Doing OO in Perl is like... doing OO in C. Sure, you can do it, but it probably won't work with anyone else's OO code, and you have to do a lot of the compiler's work yourself.
• Perl isn't as ugly as the Python fanatics claim it is; but there's still a hard limit on how readable it can ever be. Any language where the canonical way to sort an arbitrary list is expressed as @sorted = sort { $a <=> $b } @mylist; has readability issues.
• Figuring out what chain of braces, sigils, and arrows is needed to properly dereference a deeply nested data structure is a PITA.

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

I'm just an anonymous coward...

[Anonymous Coward]

So this probably won't see the light of day, but...

I thought that this was one of the best essays I've read in some time, even given its lack of technical substance.

The message of this article ultimately is that our languages of choice are often as much a matter of subjective personal preference as anything else.

A major theme of this article, then, was not to bash languages, but to celebrate the variety. The author's really trying to encourage us to explore our personal tastes.

Did anyone else note the link to pragmatic programmers, following admonishments to learn a new programming language each year?

How many on Slashdot try something like this? Maybe not every year, but on a regular basis? What's your experience been? Is it worth it? Anyone switch their language of choice because of it? Expand their respect for other languages?

What I Hate About What You Hate About Ruby

[Fweeky]

What I Hate About Ruby

The sigils that mark instance and class variables always stick out visually in an otherwise clean language.

Er, the use of @foo to define an object attribute is great; it means there's no need to type self. all the time, makes attributes obvious, and means you don't need to use lame prefixes like m_ObjectAttribute.

A much better hate would have been the awful Perl/sh-era pseudo globals ($_ $@ $! $| $" $' $1 - what were you thinking matz!?); we all hate those ;)

Re:He likes JavaScript???

[Molt]

I think you'll find this guy does know how to program.
As well as being well-respected within the Perl community (And possibly other languages too) he's the O'Reilly technical editor, the author of their "Extreme Programming Guide" and the chief author of "Writing Weblogs in Slash".
I have a feeling I may well have just been trolled, but I thought it worth dropping this here so people at least knew that this guy was not some random schoolkid knocking out half-formed opinionating.
My advice: Do a little research before posting

Re:Thanks for examples, dickhead.

[Cached Hit]

FINALLY, my sig becomes useful!

Why I like Python and SWIG

[SimHacker]

I thought Perl was cool when I read the manual and played around with it in 1989. I loved what it could do, but hated the syntax and overall design of the language, so I got over it quickly.

Why am I disappointed with Perl, and thrilled with Python and SWIG? I sent Larry Wall some fan mail in April of 89, enthusiastically asking about upcoming features, and describing what I wanted to do with it:

From: don@brillig.umd.edu (Don Hopkins)
Now what I'd *really* like would be a clean easy way to link in my own libraries and call them from Perl, and to be able to call Perl functions from my libraries. Instant extension language -- just add heavy water (and palladium)!

He replied:

From: lwall@devvax.Jpl.Nasa.Gov (Larry Wall)
Subject: Re: perl
To: don@brillig.umd.edu (Don Hopkins)
Date: Mon, 3 Apr 89 15:33:13 PDT

From: don@brillig.umd.edu (Don Hopkins)
Enclosed is a message about what I'd like to do with perl. Do you think it's the right language in which to write "liaison" (a connection manager, process server, pumping station, whatever -- described in the last paragraphs below)? I'd also want the server to doll out pty's, as well. Know of any work in that direction? (I think it could all be done with emacs, but that's too heavy handed a solution. I'd rather just run one multi-window emacs at once, and make connections between it and various liaisons running on different machines, to take care of my remote editing urges.)

Perl 3.0 will be better than 2.0 for that, since it supports binary data and will support sockets, as soon as I hack them in.

Larry

Python is extremely well designed to thoroughly solve the extension language problem -- on purpose, not as an afterthought! And SWIG makes it very easy to expose rich programming interfaces, structured data types and complex class libraries to extension languages.

Will someone who's intimately familar with how Perl has evolved over the past 14 years since I submitted that request, please describe how difficult it is using Perl as an embedded extension language, integrating Perl with pre-existing applications, extending Perl with libraries written in C and other languages, exposing complex data structures and class libraries to Perl?

-Don

To everyone who whines about Python's indentation:

[CoughDropAddict]

I can think of only two possible reasons why Python's whitespace-significant block structure would bother people:

• people are determined to write code that is not indented the way it looks (so that the parser will recognize a different block structure than the indentation implies)
• people feel warm and fuzzy staring at braces and "begin/end" keywords.

Someone please explain: why does this feature make you so upset? How could it possibly make your life more difficult to know for a fact that the interpreter sees the blocks the same way you do on the screen?

What does overloading look like in English?

[semios]

If operator overloading is defining a new language, then so is writing new functions.

I disagree. New functions are just that--they're new. They do not override any preconceived notions about what they're supposed to do. Operators, however, do have preconceived notions. Imagine if we applied the same reasoning to English and said, "the conjunctions 'and' and 'or' sometimes behave differently depending on the nouns they're chaining together." All of a sudden the sentence that reads, "Beer and dogs aren't pretty," is not comprehensible unless one refers to the dictionary, where it reads:

Beer, n.
1. A fermented liquor made from any malted grain, but
commonly from barley malt, with hops or some other
substance to impart a bitter flavor.
and:
1. drenched or to steep in moisture; to wet thoroughly;
to soak; to saturate with water or other liquid;
to immerse.

Now the sentence means, Dogs drenched in beer aren't pretty. Significantly different from the first.

I agree that overloading operators is more powerful for the code writer, but any reading of it will generally suffer, since it relies on knowing every other object's behavior.

Aww, no C#? I really like that one.

[Gldm]

Ok begin flaming me but I love what I've seen of C# so far. I'm not a very experienced programmer, but I was forced through C, C++, MIPS assembly, shellscripts, and Java in college. Since then I've done C# and PHP on my own. So far I like C# the best.

Why? C is an ancient ugly mess that needs to adapt or die. I'd hate to do more than a 200 line program in it because I'd get lost without objects. "Oh but you can use objects in C by doing blah blah struct blah blah kludge etc." No thanks, it took me years to figure out what the big deal with objects was and how to use them without overusing them, and I'm never going back now for anything serious.

C++ has objects you say, but they always feel like it's grafted on to C. Granted it works, and it's still reasonably portable, which is C's main advantage these days, but some things are still just ugly. How about an array who's size you don't know until runtime? Welcome back to pointers 101. Sure you can use new and delete instead of malloc and it looks nicer, but alot of things just don't have really elegant solutions, and the standard libraries are too sparse for what modern apps do with modern languages.

Java... everything you hate about C++ fixed the wrong way! Yay we have big useful libraries now... but they're constantly changing, bitching that what you just used is now "depreciated", doing things you're not allowed to do etc. No I do not want to use something called "vector" to replace a linked list, give me a freaking "linked list" object! Even if it's just a renamed vector at least it doesn't confuse people into thinking I'm going to have calculus and matrices popping out in the next few lines. This may have been the fault of my instructor but he loved crap like this. "Don't use the Stack class, use vector to make your own stack!" Oh and just because I don't want to do something with pointers if I can help it doesn't mean I don't EVER want to use pointers, I'd like to code without a babysitter please. If I screw up at least it's me to blame. Everything must be a class! Umm yeah that's great when I just want a struct with an int and a float so I don't have to write half a dozen methods to implement a "proper" class with private data and constructor and operators and copy... Put up with all this and you're rewarded with 10x slower performance and maybe cross-platform execution on alternate tuesdays when it's raining and the moon is waxing.

PHP seems nice, though I haven't really written much of anything in it yet. Some things kinda weird me out like how nothing cares if your variable is an int, float, string, etc. It's kinda nifty but extremely unsettling at the same time. At least it's easy to spot variables since they all start with $. I really don't have much else to say about it yet.

By now everyone's waiting for why I like C#. I like it because it fixes the things I hate about C++ and Java and just seems to make everything work smooth. Want to use pointers? Sure, just put it in an unsafe section for the over paranoid. Want to use objects? It's easy. Want to do threading? We've got this easy to use library for it. How about resize an array? No problem. Arrays remember their own sizes. They can even sort themselves. They can even sort themselves and another array at the same time based on the values in the first array (someone PLEASE show me how to do this with qsort() in C++ elegantly). Networking? Got it. Performance? Eh, about 20% hit from C++ on my machine, less if you use ngen to precompile it. Still too bad? Ok, put your critical sections in C++, C, or even ASM libraries and link them seamlessly. GUI apps? Tons of easy to use stuff there, though it's mostly windows specific. The downside is you don't get the portability of other languages... yet.

Re:Aww, no C#? I really like that one.

[Tim]

"C++ has objects you say, but they always feel like it's grafted on to C....some things are still just ugly. How about an array who's size you don't know until runtime? Welcome back to pointers 101."

Uh...

std::vector v;
v.resize(some_value_from_somewhere_else);

I don't see a pointer anywhere in there.

WHY, not HOW

[gidds]

Better would be languages which are self-documenting... you don't need to read the comments because the purpose is clear anyway.

Even if you could program in plain English, that would still only tell you the how: the low level of what it's doing and how it does it. Those sort of comments are usually redundant or obsolete, anyway.

What's important to comment is why: the big picture of what's being done and how it fits into the rest of the system. Once you know that, then you can work out the rest, readable code or not, and work effectively. And that's what no amount of self-documenting code can do.

I'm Having An Affair w. Your Programming Language

[halfgeek]

This was a very interesting article. I natively speak Perl, C, and C++, know enough about PHP to get by, and still remember some Commodore 64 BASIC (10 ? CHR$(147)). I am also, as I believe I've said before, not afraid to learn things like Java, Python, Ruby, maybe even Visual Basic again (God forbid) should they prove exceedingly relevant to my case - in fact, I quite look forward to knowing (hopefully) all of them and then some. But never Pascal. (Just kidding.)

I've really found that the thing I hate most about programming in general is that no single language is the right one to use for any of my programs! I am very interested in any effort I ever come across to do functional merging of disparate environments. In addition to a couple of workarounds I've invented in the past for shoehorning Perl into PHP, I like reading about things like SWIG, the open CLR, and even COM (the concept more than the implementation), and a smile always comes to my face when I think about the Inline library written for Perl.

Now, the thing I really pine for is all of this interlanguage binding stuff being easy, fairly portable, more synactically simple, and less hacky. I know that these exist, but not quite completely together. If I write a program in Perl with use Inline C, I can never be sure that anyone else has all the development tools necessary to compile all the C on the fly. Writing a program in Visual Basic with a nice mouse-drawn GUI and an external component is really easy - but it's Visual Basic. Writing a component wrapper for Perl is fairly straightforward with SWIG, but some well-thought-out language features would make it easier. And COM... I'm going to have to try wrapping my head around that book again someday... I'm sure the ATL makes it all very simple, but can I use ATL from MinGW? From C? From Perl? And don't try to tell me that I need to learn yet another flavor of XML to make all of this work.

That's mis tus centavos.

(Note: I disclaim perfection. Don't hit me too hard; I admit I haven't done enough of my homework to claim this post isn't full of holes. Once I've looked this whole matter through, if ever, and if I still haven't come up with anything good, I may just have to take a deep breath, lay down a syntax, figure out how to use a lexer generator and a compiler compiler, and throw together some ghastly but very easy-to-use homogeneous aggregator system. Either that, or I wait for Parrot to interoperate with Mono...)

Re:He likes JavaScript???

[BZ]

This is all DOM, not Javascript. As in, you have a document object, some properties on it, form objects, element objects, reflected into JS. The actual syntax is JS. But the fact that document.forms["formName"] is the way you get a form is DOM, not JS. All the JS is doing is getting the "formName" property of the object that was returned when you got the "forms" property of the "document" object.

So my conclusion is that you have never done any real programming in JS as a general-purpose language, instead of just using it as an interface to a browser DOM.

What i HATE about your programming language

[digirave]

What i HATE about your programming language... is YOU!

bleh~!

Re:okay, fine, I'll explain it

[OneEyedApe]

I program in LISP, mostly for fun, and I don't worry that much about parens. A text editor that highlights matching parens and a bit of careful indentation allows me to mostly ignore the vast sea of ( and ).

Of course he had nothing bad to say about ...

[ironring]

FORTRAN, tcl or S (R). Am I dating myself?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Try this some day:

[avdi]

Take a hundred-line snippet of Python code. Stick it into a web page. Copy&paste the web page to an email. Post the email to a programming mailing list. Have a lengthy thread about the code, quoting and requoting the original.

Now, let an intermediate Python programmer try to take the mangled code from the end of that thread and reformat it so that it works as intended. If it were in a language with explicit block syntax, chances are it would run as intended with nothing more than the removal of any quoting prefixes that mail clients have added. And a decent programmer would be able to whip up a script that would automate the transformation from mangled code into nicely indented code. Not so for the Python code.

The problem is not so much that whitespace is signifigant by default; it's that there is no way to modify this behaviour in order to generate "portable" code which can survive whitespace mangling.

But frankly, all things considered, whitespace signifigance is by far the least of Python's worries.

coding in C is a premature optimization?!

[Pr0xY]

The notion of "coding in C is a premature optimization" is completely rediculous. While I'll admit that for different tasks, different languages are more appropriate, if you know C best, then you should probably do it in C.

Plus the notion that coding in C is an automatic optimization over other languages is absurd. It is true that do to the lower level nature of C, it can be used to make very efficient code. But in many cases I know I can write equally efficient code in C++ (or other languages) because of the nature of the problem.

Heh, starting to sound a bit hypocritical here aren't I? I guess what i am trying to say is. If you can do it best in a given language, do it in that language. I am however an advocate of learning as many languages as you can, so that you can make a better choice regarding this issue..on your own.

so don't go out of your way to do it in another language just because someone said you can do it slightly better if you took the time to learn about "language x."

General purpose languages are just that "general purpose", it is silly to force yourself to program in an "uncomfortable" language just because it may fit the problem better...you'll probably end up making worse code anyway.

proxy

It seems like Apple's "Objective C"...

[callipygian-showsyst]

It seems like Apple's "Objective C" is so irrelevant, it's not even on the list.

Please define a programming language.

[ressu]

What amazed me most in the article was that XSLT was included as a programming language. Even though the definition for programming language is as follows (from WordNet):

programming language
n : (computer science) a language designed for programming computers [syn: {programing language}]

And even if at some level XSLT matches that. I still think that XSLT is not a programming language and in such shouldn't be judged by it's format. eXtensible Stylesheet Language, is by it's name a way to define a style for an XML document, and it's not for programming applications.

Although, i agree that XML is not the best way of representing applications and XPath itself is quite complex to use for even the simplest queries.

Actually PHP is a hack of a language

[Imperator]

I code PHP every day, so I've become quite proficient at it. However, I constant find myself horrified at some newly-discovered inconsistency in its library. The language itself is not so terrible, but its library is a beast.

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>

The list didn't include Java...

[revividus]

...in which you shoot yourself in a reference to your foot, and pass a message back to your foot informing it to behave as though it has been shot.

You are unfair to C++

[master_p]

How about an array who's size you don't know until runtime?

If 'vector' is not enough for you, you can always typedef it(parentheses are used for illustration purposes only):

#include "vector";

typedef std::vector(int) IntArray;

IntArray intArray1;

but alot of things just don't have really elegant solutions

And what are those things ? you don't say. STL provides THE elegant solution. Remember, 'typedef' is your friend.

and the standard libraries are too sparse for what modern apps do with modern languages

I too wished that C++ had standards for gui, multitasking, databases, networking and other useful tasks. But... C++ is a language standard, it is not a run-time environment. If you want all this functionality, you can always use Qt(for example). C#, the specification is portable to other OSes, since it is an ECMA (?) standard, but the run-time isn't. So don't hold your breath taking your C# source code and compile it on Linux...on the contrary, any STL-based app will compile the same with almost every C++ compiler, and Qt is 100% source code compatible on every OS it supports.

Re:(define (language? x) (eq? x 'scheme))

[Piquan]

Of course, that syntax wasn't guaranteed to work until R5RS, and even then it was done to conform with IEEE's doing away with optional ("non-essential") features in their own standard.

Not to mention that even R5RS uses (define foo (lambda ...)) more often than (define (foo ...) ...)