Criteria #2 eliminates Smalltalk. There has been a revival of Smalltalk with Squeak/Gemstone/Seaside. You get very powerful features like continuations that make it easy to write web apps. But speed is a major concern and it also consumes humongous amount of memory.
This is a very bad sign right here for this article -- using hearsay and preconceived notions in place of facts. Smalltalk actually has one of the most efficient memory models for a high-level OO language, and beats Python and Ruby by a big margin. Gemstone is still one of the better VMs out there, and can run circles around Python and Ruby.
What Smalltalk doesn't have is mindshare. That's enough to reasonably eliminate it. Mindlessly parroting preconceived notions in contradiction to the facts is a very bad indicator for article quality.
What incompatibilities is Pharo or Squeak introducing? The ANSI Smalltalk standard is pretty weak, but it does enable a workable compatibility/translation scheme. You'll have to be more specific. Explain how this is any more of a problem than base-library extension name-collision incompatibilities between Rails and other libraries.
Ha! I didn't expect anyone to point out a scenario where someone did, in fact, have to choose just one tool.
That said, Leatherman-like multitools are pretty common among some people, though I'm not sure whether it's just so that they'd have a portable screwdriver, or because they actually need something like a Swiss army knife.
"I strongly recommend that you carry a multitool. There are dozens of species of these remarkable devices now, and for good reason. Do not show them off in a beltpack, because this marks you as a poorly-socialized geek. Keep your multitool hidden in the same discreet way that you would any other set of keys.
"That's because a multitool IS a set of keys. It's a set of possible creative interventions in your immediate material environment. That is why you want a multitool. They are empowering.
"A multitool changes your perceptions of the world. Since you lack your previous untooled learned-helplessness, you will slowly find yourself becoming more capable and more observant. If you have pocket-scissors, you will notice loose threads; if you have a small knife you will notice bad packaging; if you have a file you will notice flashing, metallic burrs, and bad joinery. If you have tweezers you can help injured children, while if you have a pen, you will take notes. Tools in your space, saving your time. A multitool is a design education.
"As a further important development, you will become known to your friends and colleagues as someone who is capable, useful and resourceful, rather than someone who is helpless, frustrated and visibly lacking in options. You should aspire to this better condition.
"Do not lug around an enormous toolchest or a full set of post-earthquake gear unless you are Stewart Brand..."
(the whole thing is well worth a read)
I think his reasons for carrying one a very similar to the reasons you might want a general-purpose, high-performance, relatively popular, high level and concise programming language in your back pocket. For those odd times when you need to consume an API, or decompose a high-dimensional matrix, or simulate traffic flow. You know, at a bar or something.
And of course, "do not lug around an enormous library of hand-rolled lisp macros unless you are Paul Graham."
I think the author conflated two different ideas: the best general purpose language and the best language for writing web apps. Most of the article talks about very general advantages and disadvantages but I have a feeling that the entire time it was written from the point of view of web application development, although it is never explicitly stated.
I will rule out C#. C# never really took off and hardly is the Java killer that it was touted to be.
Never really took off!?!? What planet is this guy living on? Most new Windows software by companies other than well-establish C++ workhouses + all indie work is being done in C# these days.
C# is more fun to work in with each release, as Microsoft courts programmers who can tell a closure from a hole in the ground. Unfortunately, it has a rather anemic community compared to many other languages.
You're looking at github, which is primarily for open source hackers...... most whose work isn't on Windows. While GitHub is representative of hackers' language preference, it's not representative of language popularity. You need to keep in mind that C# is really (mostly) a Windows-only language, and open source tends to be much more proliferative on non-Windows platforms where Java is a much more feasible option.
But, yeah, C# is becoming more and more exciting with its new anonymous methods, lambda expressions, and more :)
Github is probably representative of C# and Java among hackers.
But it isn't representative of hackers language preference for all languages. Github will almost certainly underrepresent both python and haskell, and bitbucket will overrepresent python.
My impression is that the Haskell community is tired of the lack of github-like darcs hosting, and are switching to Git for github. After all, you can losslessly convert between Darcs and Git, so even though the code is on github, they may be typing "darcs ..." to work on it.
This author is to be commended for such a fine example of how to use an apparently objective procedure to justify a pre-conceived notion. Developers: next time you make a presentation to senior management, study this article carefully for tips on how to get your way!
From the article, "2. Speed: It should be fast (should approach C in speed). It should preferably have a highly optimized compiler that can generate architecture specific binaries — no JIT can be faster than an optimized binary."
This is not, strictly speaking, true. In a best-case scenario, a just-in-time compiler has profiling information available that a static compiler won't have. In the right situations, Java JIT can produce performance on par with or slightly exceeding that of equivalent C code for this very reason.
The best I've heard of is approaching 50% native speed on benchmarks, but losing by a factor of 4 in real-world calculation-intensive apps. Langs on a JIT VM have been matching business app (network & DB bound) performance for over a decade already.
I think the technology is probably that old; it seems to take industry 30 years or so before they are willing to look at relevant research ;)
Anyway, the LLVM and JVM are good examples of JIT optimization. Tracemonkey also has some good ideas, and GHC and SBCL's VMs also show how to write static compilers that do better than C. (LLVM is interesting in that it compiles C to run on the VM, and this C does better than gcc's statically-compiled C. When C is faster than C, it kind of calls into question the validity of the "faster than C" criterion ;)
Why does it need to be fast anyway? How many programs will this one-language-programmer be writing that needs to be fast?
Programs are generally constrained by just one thing: either CPU, network bandwidth, network latency, user latency, disk I/O and so forth. Why focus on the CPU? Is this hypothetical programmer really going to be writing another git or a program to fold protein molecules, or is he more likely to be writing glue, user interface or one-shot data manipulation programs?
Similarly, multi-threaded programming is hard. If this hypothetical programmer is only learning one language (and thus, by the admission of the article, not very good), why is this suddenly a requirement?
The thought exercise is a bit silly, but it does reflect a real dilemma (so obvious to us that it isn't even mentioned in the text);
1 - people who write web apps can choose language what they want to use.
2 - PG and others claim that language choice can determine the success of a project.
3 - if you don't like PHP or the LAMP paradigm, at this stage of web history there aren't any clear winners.
4 - switching languages mid-project is perceived as a potential project killer, or at least not very fun.
I wonder though; do we have any empirical data to support #2 and #4? That is, do we know how big a factor language choice is for project success, and do we know if switching languages is really all that hard? Reddit switched languages, from Lisp to Python, and it was not a fatal blow.
I'm wondering if the right answer to "What language should I use" is just "Who cares? Start coding."
My day job is PHP, and I'm determined that my personal projects are not going to be PHP. Unlike the OP I am not as, um, decisive in the face of paucity of evidence, so I have gone down a rathole of evalling other langs (Haskell, Erlang, now looking at Scala).
I can't believe Ruby made it further than Smalltalk when ST was eliminated for performance reasons.
Also, it's too bad that Clojure is eliminated purely due to syntax. I find well-writte Clojure very easy to read after spending a bit of time with s-expressions. I think that some of its constructs (like loop and recur) are very elegant ways to describe a program. Also, recur, in tail position, is used to implement recursion without overflowing the stack so that's not really a problem for Clojure anymore.
Again with perl being hard to understand. Bad perl is hard to understand, but good perl is nearly unmatched for idiomatic clarity of expression. It's the only language I know where the style guidelines are less of "line up your braces like this so you don't lose one" and more of "put the essential or surprising thing at the beginning of the line so the code is easy to skim." It's the language that got me thinking in terms of clarity of expression in the first place.
It's a power you can use for lazy rather than good, and I'll admit the results of that are ugly.
But I find the persistent criticism confusing. Either people are confusing "looks ugly" with "hard to decode" or there's a lot more bad perl code out there than I think that is.
Or perhaps perl code is like fish. When it's good, it's good, but when it starts to go bad, it really goes.
My current best theory is that Perl is powerful, flexible, malleable, and practical enough that a dabbler can accomplish great things without having to think about clarity or design or encapsulation or maintainability. The language lets you get things done even if you make a mess.
(I believe Ward Cunningham has said that Smalltalk's tools are so good that you don't notice that you've made a mess until it's a huge mess.)
I can't take this article as it presents itself. He claims directly that his favorite language is Haskell and then procedes to "admittedly subjectively" eliminate everything except that one tiny corner of the current language ecosystem. It feels a lot like putting the conclusion before the reasoning --- much like most language advocation.
I'll disclaim that I agree with him: I too love Clojure/Haskell/Clean/Scala, but I also think his argument is terrible.
If you have to learn only one programming language, likely you are not a programmer, or someone who programs for a living. If I were to recommend only a single programming language for a non-programmer, it would probably be bash, on the basis that plenty of mundane user activities can be automated or more efficiently done with a shell scripting mindset.
The discussion around criteria might be useful. Yet another language thread probably is not.
The interesting things that I noted about criteria is that there wasn't a direct mention of installed userbase: languages with a million users have a tendency to have tremendous resources available while ones with small userbases have a tendency to have support limited to a few high priests.
Also I noted that many of these questions are dealt with in a yes/no fashion when in fact it's a relative thing. So, for instance, F# may run on mono which gives it cross-platform support, but performance might not be as good, which was enough to eliminate it here. I would have been happier if F# was given partial credit here. I'm sure that observation is true of some of the other points the author makes. It would have been better to use a weighted matrix.
This seems to be written for professional programmers, who really should know more than one language. I'd be more interested in an article which discusses which single language should people who aren't professional programmers but can still benefit from programming skill in their job should learn.
>>> 4. Support for Scripting:You shouldn’t have to learn one language for writing scripts and another for applications. This allows for rapid development in script-mode which can then can be compiled into an application, if required. <<<
This is indeed a very limited worldview. (I wanted to write something more harsh, but then I told myself to stay polite).
In my opinion, if the constraint is to learn only one language (without specifying why), it should be general purpose language, which allows to produce both scripts and full gui programms, maybe something along the lines of C, C++, C# etc.
I'm thinking it might be nice to make a late-binding optional-typing VM language with Go's general syntax. (For which a fully-typed code base would compile into Go.)
“Though it has a lot going for it, the Lisp syntax will still be an issue for most people (#8, #10).”
It is irritating to me that it is so. Most modern lisps have less matched decoration and only slightly (1-2 levels more) nesting that algol-derivative languages.
As far as I can tell, the sole real point in the “lisp syntax sucks” camp is that prefix arithmetic is unfamiliar. Which may be true (although it is more regular), but how often do people really sit around writing a lot of arithmetic code? For the vast majority of dock-this-with-that programmers, lots of +-*/ arithmetic is rare.
Seems go would only fail the mature requirement. Go's future is incredibly bright. Soon people will realize how trivial channels make some of the tremendously complicated plumbing that all weg/server/enterprise software eventually needs.
I have a hankering to produce a late-binding dynamic scripting language with optional typing and very similar syntax to Go. (Which would be identical when all typing is put into a program.)
For God's sake, if you want to help someone to improve his English, then privately email the guy. Keep HN for discussion of the contents of the article. Your distracting comment on the top annoys me much more than those few language errors. The only thing you achieve is that you publically draw attention to the fact that you noted the error and know the correct answer. Well, we just don't care. The guy probably isn't even a native English speaker.
For every article on HN, there are at least ten readers that can provide remotely related tidbits of information that are interesting to some of the other readers. Half the articles contain at least one language error. The result is that it's easy to drown insightful comments on the article's subject, which caused it to be submitted, in comments that may be interesting in themselves, but are relatively uninteresting in the context of the subject.
I appreciated tel's comment. It contributed something to the conversation that was constructive and informative for anyone who didn't know the usage difference. I tend to skim over that kind of comment quickly if it's something I already know, just like I would for any other content I was already familiar with.
Your angry comment, on the other hand really was distracting. If you have a problem helping out people, even non-native speakers, then don't do it yourself.
I would argue Java is not necessarily verbose, J2EE is usually, but Java not necessarily. And it can be quite productive using the write libraries so I wouldn't rule out #1 also.
Interestingly, to make a decision like that for which single programming language you'd have to learn, you'd have to know enough about each language in question to make a good choice.
Here's my revised method of picking:
* make a list of 5-10 languages that seem neat
* spend a few days on each one, learning the syntax and what it's useful for and what
libraries are available
* pick the one you like the best
I would choose what I want to do first (web, enterprise systems, mobile apps, etc) and then learn a language that is actually useful for that.. And of course the best language changes every 5 years, at least for web. The biggest part is learning the libraries and frameworks anyway, not just the language.
I logged in just to upvote this article, excellent! I don't have too much experience with several languages so I won't comment on the validity or merit of the arguments, but it is a very well-designed piece.
I agree with the point that you really do need to learn several languages to become a good programmer, though. I just don't think it's possible to be as well-rounded and knowledgeable without doing so.
This is a very bad sign right here for this article -- using hearsay and preconceived notions in place of facts. Smalltalk actually has one of the most efficient memory models for a high-level OO language, and beats Python and Ruby by a big margin. Gemstone is still one of the better VMs out there, and can run circles around Python and Ruby.
What Smalltalk doesn't have is mindshare. That's enough to reasonably eliminate it. Mindlessly parroting preconceived notions in contradiction to the facts is a very bad indicator for article quality.