Pages

Monday, March 05, 2007

Why do most people seem to use inferior programming-languages?

If you read discussions about programming languages, one topic is quite common: "Why do people use an inferior language like Java/C++/what-the-hell and not a superior language like Lisp/Haskell/Python/you-name-it"?

The reason is: The language is only a small piece a the big scheme. Todays languages aren't that different at all, productivity wise. While some things have a certain impact (having a garbage collector for example), most things in the language don't really matter in practice to a big degree and are largely overshadowed by the real important things: The availability of tools, libraries, documentation and the performance of the resulting code.

Imagine two competing car-companies A and B. A decides to invest in better automation buying robots, while B shys away from it because if the initial investment and continues to use human workers. After 2 years the investment of A starts to pay out: Productivity increases, the quality of the products gets better and the production costs are reduced. To stay competitive, B now simply has to catch up or lose market share and eventually even disappear.

I don't see a reason why software production is different: If company A can be more productive with a certain language, then the competition has to catch up or lose. That's how capitalism works. As long as we have relativly free markets, all companies have to strife for the best tools to do a job. And this really shows: Not so much time ago, most programming was done in C and later C++. But today Java is the most used language. The industry is obviously able to change to a different language if it really gives an advantage. But why has it moved to Java and not to Lisp, Haskell or Smalltalk?

There are some people who seem to think that most people simply are to stupid to grasp the complexity of those languages and thus using the more simple Java. But this is a fallacy, because Lisp and Smalltalk's simply are not more difficult to use. In fact Smalltalk is a much more easy to use language than Java. You can learn Smalltalk in a day and be quite productive after 2 weeks, something which is impossible in Java.

And Lisp can be quite simple, too (at least in the 'Scheme flavor'). Especially if we take a look at C++, the most used language not long ago, it becomes obvious that simplicity has nothing to do with it: Even Common Lisp is a piece of cake compared to C++. Not only the language is more easy to use, also the concepts used by the language are more simple (People who can use templates won't have problems with Lisp-macros after a short time of accustomization for example).

So if simplicity was really the reason to choose a certain language, nobody would ever have used C++ and the world would probably program in Scheme or Smalltalk today.

The next fallacy always heard of is the stupid manager who choose a language based on the 'marked leader'. But again this doesn't seem to be correct: When Sun created Java, it was no big market leader. The leader was Microsoft and MS used C++ and VB. But still Java made an impact and became the 'big thing'. MS has to actively fight against it, but still partly failed and had to jump on the bandwagon later by creating it's own 'Java' to get market share back. So it's quite short-sighted to use conspiracy theories where the 'market-leaders' make out which the 'next big thing' is and everybody else has to follow. If only a single company would abandon this 'agreement' and start to use a more productive tool, the others have no choice than to catch up, like our car-company B above.

The real reason why Java is still the number one language in the market is that it gives the highest overall productivity. Of course this isn't true in all areas, but it has to be true in the areas where the majority of developers work. But what are the reason for this?

I look at many programming languages and also try out a lot. I've done this for years. And still I use Java as my primary language. You can call me a stupid Java-Joe or whatever you like, but then you will overlook the real reason why I and many others still prefer Java despite the fact that they know most of those new, fancy, shining languages.

Before I used Java, my primary language was C++. I've switched to Java relatively late when version 1.3 came out. But the main reason I switched wasn't the language. I've looked at Java directly after it becomes available - and found it horrible. But years later I tried out JetBrains IDEA and it was unbelievable how much productivity this IDE gave me compared to VC++ I used for C++ development. While VC++ had 'Wizards' for code generation, those Wizards only created 'code-skeletons' which were only useful as a starting point but are no big things over the whole live cycle of a project. But in IDEA all those little helpers were usable in all phases of development. Many of the uglities the Java language has simply disappeared when I used this IDE, and I suddenly could concentrate on the problem instead of fighting with the language.

But maybe the biggest advantage was that the IDE removed the 'documentation-problem' I've to face in almost every other language. If you write code you constantly have to remember names, parameter order etc. By using IDEA with Java this wasn't necessary anymore. The very intelligent code-completion and the integrated documentation-lookup removed the necessity to remember all those things. Finding the right method or class was most often only a key-press away. And because of the real-time error-checking compile errors were nearly eliminated, too. In the end IDEA (and later also Eclipse) made Java a completely different language. Yes, the IDE matters. A lot. Just consider to write Lisp-Code without a REPL or Smalltalk-Code without the Smalltalk-Browser if you're a user of one of those languages.

So the real reason why I switched over to Java was not the language itself, it was the combination of the language, the IDE and the available, well documented and comprehensive libraries. In fact the language was the least important one of those reasons. This hasn't changed: Java without the tools is total crap. Most languages are better. But Java is so 'IDE-friendly' that it was possible to create an IDE like IDEA.

Not every language allows this. The dynamic ones like Python, Ruby, Lisp and Smalltalk always have the problem that it's mostly undecidable at compile-time which methods are available for a certain variable. But hey, that's not a bug, that's the big feature. It's the reason those languages are called 'dynamic', and an Java-IDE is in principle nothing else than an interactive extension to the compiler.

But there are other problems in certain languages. For example Haskell: It's a really nice language to create small, cute programs. The language is like a puzzle, it makes your brain hurt - but in a good way, like your muscles 'hurt good' after a good workout. But if I work to build a house, muscle-ache from to much lifting heavy stuff isn't that funny anymore. And the same is true for doing 'real stuff' in Haskell: Just look at the code of a big project implemented in Haskell, like the sources of the GHC. I don't see 'beauty' anymore in this code. It's hard to read and it's BIG. The type-checker of GHC alone is nearly as big as the whole code of Hugs - but Hugs is written in C while GHC is written in Haskell. Sure, GHC has some more extensions compared to Hugs, but this still should make you think. Also Haskell has a big documentation problem: The Haskell docs are absolutely insufficient on many levels. This alone is enough to ensure that Haskell will never become mainstream unless it changes.

And for other languages there is the performance problem. Yes, performance does matter. People sometimes spend hundreds of bucks to get a 50% performance increase of their hardware. Do you really think they wouldn't care if a program is 100 times slower because of using a certain language? Sure, if you write a script which is used once a week, it really doesn't matter it it takes 0.1sec or 10sec to finish. But if you look at web-apps, a factor of 100 can easily cost millions because you need to buy and maintain 100 times the number of servers.

For desktop application even Java is often still ruled out compared to C++ because of performance reasons. And Java is in average only 1.5-2 times slower than C++! So how could a language like Python or Ruby compete here? The answer is: They simply can't. You may use them in parts of a project, for example for scripting, but the majority work is still done in one of those boring 'previous-generation' languages. And again it's not because the developers are stupid, it's because nobody would buy a program which is as slow as if you made a step back in time to a 486, even if you have invested in a modern dual-core CPU.

And there are the libraries. Libs can make or break a language. And one of the most important one is the dreaded 'GUI-lib': If you want to create a desktop application and a language has no GUI-libs which allows to create good-looking(!!) and easy to use GUIs, the language is ruled out. And since most developers have to create GUI-apps from time to time and don't like to switch languages over and over again, no or only poor GUI-libs often means that the language won't be considered, even for projects which don't seems to need a GUI. This may be inconceivable for some people, but it's a fact of life: A language without good GUI-libs will never become mainstream. This also nearly broke Java's neck, because AWT was horrible and Swing took it's time to become useful, but with 1.3 Swing was decent and from 1.4 up it was good enough (if you use 3rd party look&feel libraries) for many purposes. But even if Swing is relativly good, its deficiencies (especially the non-native looks) still hinders Javas breakthrough on the desktop.

So even the best language can become totally useless if it lacks on of those: Competitive speed, good documentation, comprehensive libraries, necessary tools (like IDEs). If language fails to address those points (and really all of them) it won't become the 'next big thing'.

That's the big secret. Nothing more. Create a language as beautiful as you want. But without the necessary libs and comprehensive documentation: No chance. Slow: No chance. Not competitive if compared to other languages including tools like IDEs: Again, no chance.

So if you really want that your favorite language becomes more used or even mainstream: Help to solve those problems. Lamenting in blog-posts or online-discussions is as useless as spending lots of time writing tutorials explaining concepts from 'your' language to the world. The best tutorial and the most cunning style of discussion is useless in the moment a potential user discovers that there is no library for a certain problem he has to solve (like creating a GUI), or if the novice has to face incomprehensible and lacking documentation in the moment he/she tries to do something real with the language.

[Update:] I've written a follow-up article which discusses some comments and objections to this article. You can read it here .

26 comments:

Anonymous
said...

Although you make many good points one thing you don't mention is the vast difference in the cultures of coding servers vs sering desktop apps.

On the server world where you need 100% uptime we really should use something like erlang which is designed from the ground up to run in a 24X7 environment.

The IDE trully is a huge part of a programming language. If i had not found eclipse i do not think that i would still pr doing java at all.

I like what you said about that GUI packages. I attempted to learn things backwards, Java and then C++. Coming from Java i found C++ easy until i had to do GUI. I was totally lost and ended up throwing it away. Since my favorite part of programming HAS to be the GUI (i am not sure why i enjoy it so much) a language has to have a good GUI lib for me even consider learning.

"But maybe the biggest advantage was that the IDE removed the 'documentation-problem' I've to face in almost every other language ... Most languages are better. But Java is so 'IDE-friendly' that it was possible to create an IDE like IDEA... Not every language allows this. The dynamic ones like Python, Ruby, Lisp and Smalltalk always have the problem that it's mostly undecidable at compile-time which methods are available for a certain variable."

Yes. I agree that a good IDE can make all the difference. For instance, Wing IDE for Python has a pretty nice 'Source Assistant' that provides documentation for whatever thingie (it's a technical term) your cursor is on -- and whenever I type a dot at the end of an identifier I get a list of methods available. I believe that is because Python is pretty IDE Friendly too ;-)

I understand Ruby has a pretty good IDE (for .Net only I think) already too!

We all have our reasons for choosing our tools -- and since we all consider ourselves clever, I guess it is easy to think those who choose differently to be less clever. Of course, less clever people seem to use inferior programming languages :-)

well, i think, people pushing (superior) languages like haskell, lisp, erlang are just somewhere behind the 'i need a native looking GUI klickibunti thingi'. Everything they need to have fun is a commandline and additionaly some graphic rendering tool like a browser or an opengl window or some other kind of output.

There's more to it - successful languages create network effects through their libraries and communities. Consistent, comprehensive libraries that are available by default (i.e. not difficult to compile or configure) are probably the biggest factor in a language's success.

If Java didn't have the libraries it does in its default install, I doubt it would have been as successful as it was - the language, while an improved C++, isn't really any great shakes.

For one thing, companies ARE loath to adopt more advanced languages, and this is for a simple reason: scarcity of competent workforce. If you are using e.g. Haskell, chances are that you have really smart people working for you. Such people are scarce, which immediately means two things:

1) You have to pay them more

2) You cannot let these people go easily

Arguably, neither should be a big problem. Those people will create superior software that will sell for a higher price, so you should be able to pay them more in turn; smart people are seldom greedy sell-outs, so you shouldn't really need to worry that they'll want to quit; and, finally, you wouldn't want to let them go because they're doing such a great job for you. That's what theory says, anyway.

In practice, companies are very upset by anything of the sort because:

1) They are only likely to pay high salaries to a bunch of misfits called "top management"

2) They see programmers as clerks -- too smart to be janitors, but too dumb to be in sales

3) They want to be in control of their workforce -- anyone who isn't quite their kind of guy must go, NOW

4) They want to be in control of "their" process -- anyone who is doing something they don't understand is too dangerous, and potential competition for managerial positions

5) They want to be in control of their risks -- anyone who is doing anything too important for the company is too dangerous, and potentially can be lost to the competition

In short, we programmers are the victims of present-day managerial practices and corporate wisdom. If we are to thrive through using the tools of our choice, we must first find the right companies to work for, and then pray for the extinction of the corporate beasts of our day.

'The real reason why Java is still the number one language in the market is that it gives the highest overall productivity.'

By productivity, do you mean writing reams of crap code that are difficult to maintain? I know exactly what you mean.

Being able to read source code is arguably more important than being able to write it, one area where java's excessive verbosity loses out to modern scripting languages. IDEs, documentation and libraries may help you write the software, but they do you no favors on the other side.

There is a point of contention I find in your writing, and that is that Python is undocumented. That is a statement is not correct.

If you run the interpreter you quickly find that applying the dir() function to any object gives you a listing of all of its methods and member data. Of particular note is the docstring found in the object.__doc__ member, which is a string that properly formatted code includes to describe a function or class.

I do think there's an underlying tone in your essay of "the market has to be right by definition." That somehow the market as a whole has to make optimal decisions.

So your essay reads as "the market makes the best choice. It made this choice. So the only thing left to analyze is why it is the best choice."

And if you start from this premise, you find what you seek. If the market chooses Java, there must be a good reason. So you look for the reason and you find IDEs and libraries. Aha! That's why!!

But it turns out the IDEs and libraries followed Java, not the other way around. If you read The Wisdom of Crowds, you see that the crowd does make optimal decisions, but only under certain circumstances.

One of the preconditions for an optimal decision is independence, the individuals in the crowd must make their choices without knowing what others have chosen.

That is not the case with choosing a language. In fact, choosing tools resembles groups achieving consensus, because there are strong network effects and there are partnership incentives to the participants.

And a glance at "The Wisdom of Crowds" reveals that groups seeking consensus usually end up with worse results than individuals acting independently.

So I would personally be very surprised if the "marketplace" was able to choose tools that optimize for competitive advantage.

I do not believe that competitive pressure will force bad tools out and good tools in, because the mechanism for making choices is flawed.

None of this detracts from your excellent essay. And your points on what pragmatic choices people can make in the face of this reality are unreproachable.

>The real reason why Java is still >the number one language in the >market is that it gives the highest >overall productivity. Of course this >isn't true in all areas, but it has >to be true in the areas where the >majority of developers work. But >what are the reason for this?

Hilarious assertion. You honestly believe that the reason Java has won out is because of it's overall productivity? Any productivity gains that the language provides gets killed by their over-engineered frameworks (J2EE being the biggest offender).

The best technology does not always win out and we have tons of examples for that (Beta lost to the VCR, keyboard layouts, etc).

Large corps and the US government have billions of dollars invested in infrastructure created on the back of Java, do you really think it's easy for them to look away and go another direction? Java is hanging on the coat tail of a 10 year legacy (for which it was probably the most productive at that time) and a billion dollar corporation.

Typing is mental overhead. Unnecessary abstractions are mental overhead. Bugs are generally proportional to the number of lines of code, so generated code is only adding bulk to the source base.

You want a language that is succinct. You want to type less but without losing meaning. You want the language to be readable.

So yes, Java may be an industry leader (has great development tools, lots of libraries, and a large backing), but you have to be nuts to think that it gives the highest overall productivity gain. Programmer spend an overwhelming amount of time creating code, and Java is just not as terse as the other academic languages.

The big number of comments (here and over there at reddit) makes it a bit pointless to answer as a bunch of comments. So I will use a followup-blog-post to answer the critique and counterarguments of the article instead.

BTW: Sorry that I had to enable moderation for comments, but there are simply to much spam comments in the moment.

So please have a bit patience if you're waiting for the publishing of your comment. I will of course publish everything as long it's no spam.

This was an interesting article. A useful additional article I recommend The Economics of Programming Languages. There's the theory why some of the points expressed in the article need reconsideration -- especially the point about the free market forces.

Hi there, it was an interesting article, there were a few things that I didn't agree with, and a few minor grammatical nuances that I found a bit frustrating. I'll do the English bit first as it's easier. Well that's a perfect example. Easier is better than more easy. I hope that's ok.

On the language front, when I first read the article I sort of assumed it was written some years ago. I'm also not convinced Java has ever been the most popular language. It is popular, but you can't compare it to something like VC++ because that's much like looking for a PHP developer who can't write javascript. The Microsoft technologies are integrated and related. It sort of supports your argument that you use the right language for the job. There was also no mention of dotnet. Doing a quick Jobserve search, C# comes in very strongly, if you add VB.net (yuk), asp.net, suddenly Java doesn't seem so predominant.

let us also not forget the realm and context that c++ and c were used in. C is/was a systems level language. Writing device drivers, kernels, and fast libraries still is, and will be for some time, a systems language realm. Additionally, java would not have been appropriate for the machines of yesteryear where memory and transistors were expensive. I believe the adoption of c and c++ has a great deal to do with coding to the hardware available at the time. Only with the advent of better hardware has java become a viable option. Finally, though java is only 1.5-2x as slow on average as c++, its memory usage is an order of magnitude greater, and that cannot be overlooked. When 100MB turns into 1GB, the supposed performance parity of the two languages is a rather moot point.

I live in a completely different world than you do - embedded systems and network infrastructure equipment. But I have to agree with the points that you make. Most of the time I have no choice; in my world efficiency is everything so my choices are C or C++. When I'm working on network management applications and have the luxury I always prefer Java.

But again language is just a small part of the puzzle. I need to worry about the availability of things like source level debuggers and library support that application developers take for granted. Most application programmers don’t even think about the code generators in their compilers but I have to be aware of their strengths and weaknesses.

And don’t even think about garbage collection. How would you like it if when you dial your phone you heard a message saying “Please wait while reclaiming resources?”

I also agree that academic languages like Haskell. Earlier in my career I remember when we all started using Pascal (now I’m show my age). Pascal was simple and elegant but could not scale to large applications. The fad lasted about two years before we all discovered C and we’ve been mostly using that ever since.

Perl, Python, etc all have their place and PHP is used in a surprising number of web applications. Usually what drives these languages is the large base of libraries available for them.

So most of the time it’s not the language itself as you said. It’s all the support from IDEs, Debuggers, and libraries that drive the decisions. Except when you really need optimal performance your choices are C++, C, or assembly (in order of my preference) and I’m likely to use all three in any given month.

I realize that if you are learning English yourself it might be easier for you to read absolutely perfect English, but I think that instead of complaining about it you should acquire more fluency so that you have some fault tolerance.

"And there are the libraries. Libs can make or break a language. And one of the most important one is the dreaded 'GUI-lib': If you want to create a desktop application and a language has no GUI-libs which allows to create good-looking(!!) and easy to use GUIs, the language is ruled out."

I agree. If you're writing an application on the desktop which does any kind of user interaction, providing a GUI - and not just 'a good-looking' GUI but *the CORRECT platform-native GUI* - is not an optional extra, it's a basic fundamental requirement before you can even *begin* to evaluate a language.

The same goes for all other platform functions - libraries, processes, etc. If you don't provide language bindings to the platform, you're not going to get very far trying to write programs which are good platform citizens.

This is common sense, but it still amazes me how many languages don't rank 'be a good platform citizen on as many platforms as possible' as Job One and still attempt to become popular. There's a weird dynamic here I don't fully understand.

I mean, nobody writing Net apps seriously thinks 'okay, I can just mock up my own mail transfer protocol' and gets considered a professional. You code to the IETF specs or your program is Incorrect. It's not a matter of opinion or taste. You implement the protocol or you don't.

But when it comes to interfacing with the user - complying with Human Interface Guidelines ans such - that's somehow often considered a distasteful, optional extra, or at the very least one which is up to the programmer to pick and choose how they implement it and what parts they do. Why's that?

Is it because for some reason we've bound user interface considerations (particularly GUIs are the worst offenders here) VERY tightly to some very particular languages?

It seems weird to me that if I want to write a GNOME app that's fully platform-native and meets HIG guidelines, I *have* to bind to some very specific C libraries - and for Qt or WxWidgets, I have to bind to some even more specific C++ ones. That immediately rules out the possibility of coding in a language which isn't precisely C++ ABI compatible. (See for instance the Factor UI notes).

We accept this as 'normal' platform behaviour for GUIs, and yet we don't place such tight language-binding restrictions on, eg, sending a TCP packet - it seems much easier to find a language which has full Sockets support.

Java offers "Productivity" because it is packaged with an API. Let me say again, JAVA offers "PRODUCTIVITY" because you don't have to CHOOSE your API... or read any sort of documentation! You can just be a total retard and kiddy script the whole GUI!

It's SIMPLE CAPITALISM to say "OpenOffice is slow as hell and looks like something a kiddy scripter made (seriously, death to flat buttons). MS Office 2000 is faster than OpenOffice, has all the features of OpenOffice, and is SMALLER than OpenOffice (not even including the JVM). I think I'll buy MS Office because it IS A BETTER PRODUCT.

Producing shitty programs faster doesn't change the fact that they're shitty programs. Producing WELL MADE and WELL OPTIMIZED programs SLOWER = MORE LONGTERM PROFIT. (Unfortunately, Microsoft has the problem of eventually making programs that are so well made that they make all subsequent releases worthless to buy... hence they're now making crappy stuff and flooding the market with it.)

Hell look, C++ hate comes because people don't understand the language and that uneducated programmers spread ill-found rumors about it.

Most of this is because C++ uses pointer implementation to allow true Polymorphism instead of Templates which isn't even close to polymorphism (though people understand it better).

THEN, of course, you have people treating C++ like JAVA which results in overly bulky programs. (Using vector instead of a SIMPLE array, for instance...)

But at the end of the day, any C++ program will run faster, be more stable, and have infinitely more flexibility than Java could ever dream of.

Why? Because what you're unwilling to disclose is that JAVA is an emulator in an emulator. Unlike a scripting language which simply executes what is written... java has to setup an Emulator->PC (and a PC->Emulator) THEN it has to separate the program from the emulator to "prevent malicious code"... it's an ugly thing.

C++, just like any REAL programming language, can be compiled to fit any architecture and execute native code... hell, you can compile your program to run in the JAVA VIRTUAL MACHINE if you cared to write the compiler... java, on the other hand, can't make the same claim. (Unless have no inputs or outputs [or use a kiddy scripters compiler that ignores the interface calls and treats them as their corresponding equivalents (system.out.print becoming printf instead of setting up a system object.)])

You should also note that Sun Microsystems have been on record for saying "Computers are Fast Enough to Make Code Optimization Worthless!"... and unlike a REAL programming language, you're a slave to the Java Virtual Machine... written by people who refuse to optimize their own code because "It's not productive to do so".

Don't start dismissing things you know nothing about. The industry IS NOT and WILL NEVER support Java... companies that are "looking for a piece of the pie" will use JAVA... either for cheap cross-platform profits or for just plain cheap profits.

Again, what you fail to announce is that those people who use java are usually people who aren't going to be making alot of money to begin with.

I mean... you REALLY SHOULD change the entire argument to

"I DO NOT KNOW HOW TO PROGRAM, HOW TO READ, OR HOW TO THINK. JAVA DOES THIS FOR ME AND IS THUS A SUPERIOR LANGUAGE"

Because your refusal to read documentation, of all things, only points out that you're nothing more than a kiddy scripter.