Well, no because there is one factor that dwarfs all others: what are my friends or the people in my field using? If everyone you know (personally or professionally) is using language X then there will be collective experience you can tap, documentation, mailing lists and howtos, lots of code already written, etc. It doesn't matter if you have a "better" language if there's no-one you can talk to or whose code you can reuse.
Remember, a programming language is not a technology. It's a community. Choose the community you want to join, then use what they use.
[This refers to Gaius's comment at http://news.ycombinator.com/item?id=446136. I note this because I've seen "threads" broken because some comments in the middle rise to the top].
Why was this comment downmodded to zero? (I've upmodded it to one). It is well written, thoughtful and makes a good point. I understand people disagreeing with it, but downmodding it to zero is just insane. I've seen this phenomenon increasing on HN recently and have "rescued" a couple of comments (i didn't agree with them but thought they didn't deserve the severe downmodding).
If PG were to allow scripting HN, like he said he would, I'd probably write a script to tag a commenter as "someone I'd like to follow" and let me know when they got downmodded into oblivion!
I totally agree on the downmodding (although I disagree with the comment you refer to). Apparently some people find the use of words challenging.
There is a big difference between the use of voting for filtering large amounts of content and using it as a way to express opinion. The former is serverd perfectly well by upvoting. The latter is unworthy of intelligent beings in my view.
"Remember, a programming language is not a technology. It's a community. Choose the community you want to join, then use what they use."
I can't disagree with this enough. Why do you need to talk to people? Why do you need to reuse other peoples code?
Perhaps for some people, the community matters, but I don't think that's common.
Obviously you need to have decent language documentation, but that's not a community, it's just the specs.
Maybe you are at the point now that you can implement any application in any language without ever running into problems, writing every library routine you ever need from scratch, porting the compiler/runtime to a new platform if you need to, and you also have complete mastery over your application area, say aeronautical engineering or bioinformatics, able to solve any problem in code without ever speaking to another living soul.
If so, my hat is off to you my friend. But that's not me, after 15 years as a professional and two degrees, and I'll wager that's not anyone else reading this either. In my experience, the community around a language trumps all other factors for getting stuff done.
If you run into issues, you need to be able to solve them. If the language is well documented, you can use that. If there are tons of books on the language, you can pick up a book.
I'd say asking the community is usually a last resort. Ever asked the PHP or Javascript community questions? Most of them have no idea. They'll give you terrible, often incorrect answers. Ever asked the Java community? Most will recommend you use XML to create a FactoryFactoryGenerator pattern on Jetty using enterprise beans. Ask the lisp community? They'll burn your house down for assuming you're worthy of asking them a question.
Obviously these are generalizations, and I'm sure there are some great javascript,php,java,lisp etc communities around.
Choosing the language based on the community amounts to just following the other sheep, rather than taking an unbiased decision about which language best fits the job required based on factors including libraries available, books, maintainability, ease of hiring people in later etc etc
Also I'd say communities like this (Hacker news) are far more valuable than specific language communities.
"Community" includes turning to the person at the next desk and saying, hey, have you seen this before? Or asking on a mailing list inside your organization. That's why I said "people you know personally or professionally".
It really depends on your application domain. Someone knowing that the complex thing I want to do is already in NumPy and she used it herself yesterday and here's a snippet of code pasted into my IM is priceless. Similarly I might say, oh, I wrote some code that does nearly your thing, you could just change this one line. Pretty much anything I need I could code up myself in a half a day or a day, but all those half days add up.
More than one project I've started in Lisp here (not to pick on Lisp, just as an example) and run into an issue that I could implement myself in time T or do the whole lot in Python in time T/10. It's a no-brainer. For non-trivial tasks to be completed within fixed periods, striking out on your own with a new language is a meaningless risk.
PS I guess it varies between languages, but the wider community lists I'm on (Python, cx_Oracle, Matplotlib-users, Caml-list, a few others) are full of smart and helpful people.
Libraries are separate from community IMO,
Sure, if there's a well made library out there that does exactly what I need I'll use it, but it's not the main factor.
That's a good point, but I'll address both points.
- What are my friends using?
Each of these languages has online communities that are ready to help. Some more than others, but they all minimize the need to have real life friends who use the given language. Physical groups can be beneficial, but thanks to the internet they are no longer strictly necessary. Also, in most cities there are usergroups if you'd like to interact in person with the community.
- What are the people in my field using?
There are advantages associated with using a language or DSL/framework that's popular within your field - there is no denying that. But you shouldn't underestimate the competitive advantage that a more obscure language that's better suited for the task can give you over your competitors. PG used Common Lisp without a relational database for Viaweb. Yet in part that was the secret to his success. I suspect that using Lisp or Haskell in places where everyone else still use C++ or Java, may be a major competitive advantage thanks to the increased productivity and more robust code you can write with them.
yeah but anybody who asks what language they should learn is an idiot. the answer is all of them, except the ones from Microsoft. everybody knows that.
Pick Arc if: You want a 100 year language and you’re willing to wait that long.
I know it was a cheap shot but I couldn't help but laugh when I got to that point in the article. The relative lack of activity on http://arclanguage.org/forum makes me think the best reason to choose Arc at this point is to run news.arc.
I'm doing a presentation today where I say that Arc is a failure and I always feel guilty about that. But the thing is, I think the real reason for the fail is in the book "Art and Fear." If you focus on quality, you end up with inferior quality compared to people who focus on quantity. You have a much better chance of creating a 100-year language if you create a 100 languages in a year.
Remember, Lisp is at least a 50-year language, and Lisp was originally created as a joke or a teaching example or something. The great bearded wonder, the one that Lisp guys make shirts of, Schultz or McCarthy or whatever his name was, only wrote up the spec to make a point, some kind of math thing iirc, and somebody egged him on and they ended up implementing it. But it wasn't that he just had this magic ability to build a great language. He made a thousand other snarky points in his life, and this one just happened to be so well phrased, mathematically, that it trumps all other languages, in the opinion of many people. That's not a one-time stroke of luck in the language design department; it's the results of decades honing his craft as a master of snark.
Previously over the last 6 years I've coded in PERL, PHP, JAVA, and C#.
I'm currently 'retraining' myself over to Python for scripting and web programming (django).
I plan to stick with Java and C# for the time (our shop is about 50/50 split over SOA boundaries). And I want to keep fresh in these as my bread winner languages until I get out on my own. (Not to mention with the advent of Jython/IronPython, and Clojure it might not be bad to really dig some heels into the JVM/CLR idea.)
BUT, after I finishing working through AIAMA in Python. I want to get to work on picking up a lisp dialect and work through SICP. So I was curious, what would be a better angle of attack: Scheme, CL, or Clojure. I'm drawn to the idea of Scheme as it's been painted as a simple language to explore 'deep CS' concepts. But, Clojure sticks with the JVM/CLR strategry.
Would I be missing out if I didn't start with CL? (it sounds like the Latin of programming languages)
Are Lisp dialects (at least those mentioned above) more similar than different; or, How difficult is it to switch dialects?
Is Clojure specifically a bad choice for working through SICP?
Clojure is what you'll want to be using if you ever start doing "real programming" in a useful, expressive Lisp. Don't start with it, though.
In the following order:
1) Learn Scheme and get through SICP. Wind up with
enough of an appreciation of Scheme that you could
write real programs in it, given enough patience.
2) Attempt to learn Common Lisp.
3) Become frustrated and give up on Common Lisp.
4) Learn Clojure instead, and become overjoyed at the
real work you can get done.
I'm mostly joking about steps 2 and 3. They're based on my own experience with CL (and Elisp) and might not apply to you. Going from Scheme to Clojure will be a bit of a shock, though, because the former is absolutely as sparse as possible with lexical punctuation, and the latter is totally littered with it (particularly stuff that's borrowed from Perl and Ruby). If you've written enough Perl, though, you might not care.
By the way: Scheme is Latin, and CL is Ancient Greek. ;)
Hate to be another person to chime in with "What about language X?", but I feel Lua fits decently well in the Javascript category. I would say these are true "scripting" languages, because they are intentionally built for scripting the behavior of an application, and they both have very minimal implementations that support the prototype model for objects.
1. Reading through the Matz book on Ruby (http://oreilly.com/catalog/9780596516178/index.html), there's a very good explanation as to why Ruby/Python/Perl are "scripting" languages as opposed to "programming" languages: no main! That is, whichever file is fed to the interpreter is run (with some exceptions) in order. So these are, and probably always will be, scripting languages.
2. The author vastly underestimates the importance of Javascript...
So if you can just put the main program statements into the file without wrapping it in a function or anything, it's a "scripting language", but if you have to wrap it in a main() function or something, it's not? That's a definition of "scripting language" that includes x86 assembly for MS-DOS .COM files as a "scripting language", but excludes VBScript macros for Microsoft Word, I think.
Now, I don't know what you think, but these two languages seem to me to be almost perfect exemplars of the opposite extremes from how this definition would classify them. x86 assembly for .COM files has no type checking, no type coercion, no strings, no hash tables, very little in the way of runtime support (it pretty much owns the whole machine when it's running, under actual MS-DOS anyway, and you have to build everything yourself), takes months to learn enough about a computer to program in, typically is only used by fairly hard-core programmers, and there are no compatible interpreter implementations. VBScript is strongly dynamically typed, has strings, is used to "script" an existing application, runs in an interpreter, and is typically used by people who don't think of themselves as programmers.
So I suggest that Matz's definition may not really express what people are normally thinking of when they say "scripting languages".
Yes, but then people are conflating notions of type-system/runtime/vm/etc. with the notion of script vs. program. The key distinction is this: In a programming language you can only have one entry point (the "main()" function), regardless of how the individual files are linked. In a scripting language the entry point depends on which file the interpreter starts with, and the execution model can change depending on how the script is invoked.
For example, the Ruby community uses this trick quite often so that one file can be a library if included by another source file, but can be an executable if invoked by the interpreter directly. See: http://gist.github.com/51337. If you run "ruby a.rb" you'll get something different than if your run "ruby b.rb", even though both are the result of "linking" a.rb and b.rb together.
This is a different distinction than the one the other poster reported that Matz proposes, but it's not useful either. You can do it in C, even without using the preprocessor; see http://gist.github.com/51416, which does it with weak symbols. Worse, whether C is a "scripting language" or not depends only on the presence or absence of such trivial features.
Your distinction would make Java a "scripting language," because every class can have its own main function, and still leaves x86 assembly as a "scripting language", and now it makes GNU C a "scripting language" too; and given the nondeterministic invocation order of the constructors of static objects, it makes any particular C++ implementation a "scripting language" too.
So, I think you're focusing too much on the specific example and not enough on the runtime distinction. The C runtime looks for "main()". If you trick it into looking in different places for it, that's a trick. Ruby (and other scripting languages) goes through the source file sequentially, executing statements and definitions as it goes. There isn't a specific symbol for it to look for. (Well, there is, but that just complicates matters.) The point I'm trying to make is that the distinction between scripting language and programming language shouldn't rely on how it's used, but rather on how it's formatted.
...and by the way, I would consider x86 assembly a scripting language. You're just scripting out the processor's actions...
I didn't mean to underestimate JavaScript, which is why I gave it its own section. Perhaps I was too brief? Implication that its only useful in the browser?
Javascript is a bit of an enigma. Usually, bad languages are made better (or at least tolerable) by the existence of good libraries (see C++, Perl). In the case of Javascript, it's a really elegant language made worse by being so often so dependent on the DOM and all of it's obscurities.
I admire Javascript because it covers so many paradigms, and yet is, at the core, very simple and straightforward. Much as Lisp is to lists, Javascript is to hashes. Also, there are some really interesting projects in early stages that are taking Javascript out of the browser. For example, when Google released the code for v8, Marc-André Cournoyer from the Ruby community slapped together a project that translated Ruby to JS and ran it through v8 (http://macournoyer.wordpress.com/2008/09/02/ruby-on-v8/).
Finally, I think it's worth noting that if you believe the "cloud" is the future, then Javascript is the de facto machine code of the "cloud"...
Yeah, it's strange how only 2 years ago or so, both ruby and javascript scored rock bottom on Alioth Shootout, with javascript scoring 4 times slower than ruby, and ruby 3 times slower than python. Two years later and there's 7 interpreters for ruby and 4 for javascript.
There's something to be said for trying to make an expressive language and worrying about how to make it efficient later. Only working with stuff you know you can do efficiently can lead to getting stuck in local maxima.
>> It is a functional straightjacket like Haskell and Erlang (no side-effects), appealing to functional programmers.
Not so. Clojure has three different mechanisms for judicious use of side-effects, including Software Transactional Memory. But yes, side-effects must be quite explicit.
The article is pretty light. I don't think it necessarily does any harm, but I think the article kind of misses the mark if you are someone that is really faced with this issue.
I would argue that picking the language also depends very much on the domain/platform/target you are writing software for. Is it a web application? Is it a desktop GUI app? Is it an RIA -- for web or desktop? Is it a scientific application that needs great math libraries? What are the performance characteristics? Does it need cross-platform support? Is it a distributed business enterprise system? Is it an embedded system? Is it a library? Do you want the library to be able to be used by many different platforms and languages? Does it have to integrate with other systems and what languages are those written in? What about 5 years down the road -- how do you think it will evolve?
Most likely -- answering the question on what the domain/platform/target will be will trim you to a very short-list of options. For example, if you are programming for an embedded system, you may have to use C because that's the only language you'll find compiler support for. Maybe there will be a C++ compiler -- but whether or not you choose it can depend on a lot of factors such as whether your team is comfortable with C++/OO...whether you even want to utilize OO...whether you can afford the additional memory/complexity associated with the features of C++...etc.
ML deserves mention here. It's not quite a functional strait-jacket, and was a source of many Haskell ideas, e.g. pattern matching.
Oddly enough, I tend to think of Ocaml as a "functional C". You can do low-level imperative stuff with it, if you wish, but you usually end up abstracting the unimportant details out and going functional quickly.
ML was the first language I ever learned. I didn't appreciate how cool it was back then though. The pattern matching concept makes for some really elegant code. It replaces a lot of control structure code.
A well reasoned and presented series of arguments in pro (mostly) of many language options.
However it is a bit confusing to me who the intended audience is. The decision criteria--choose this language if...--seem a little beyond what a novice or would-be programmer can answer with certainty ("Pick Perl if: ...your mind fits the mind of Perl.").
For someone looking to expand his/her programming repertoire, perhaps a goal-oriented approach would also be useful? (systems, Web, mobile, desktop programming, etc.)
And a seasoned hacker probably won't be in need of this help.
I enjoyed reading it, but then, I'm not at the moment trying to decide what language to pick.
Hmm, I should just restate my point rather than try to repurpose it from elsewhere.
TDD has enabled me to work in far smaller chunks than before. The ripples of this one fact are transformational, and so I place more emphasis on unit-test support than most aspects of a language/tool.
http://www.reddit.com/r/programming/comments/6sktz/a/c04r6i5
There's some enthusiasm for Groovy here, tho' we've not (yet) done any production work with it. I guess my main fear is that it's a dead-end like Cold Fusion, I don't feel it really has a critical mass behind it. What sort of work are people doing with it?
There's a lot happening with it ... I think it's main advantage is that it completely seamlessly integrates with java and inherits it's basic syntax from there, so anyone familiar with java or with existing stuff in java (and that's a lot of people) can get a flying start. Groovy on Grails is where the main action is - it's basically a rails clone, but built on a standard java stack so if you need it you can always peel back the covers and access it.
I too initially thought of it as a dead end - why choose a language that only runs on the JVM when you can choose a language that runs natively as well? But once I started using it I really liked it, and the integration with java is really superb (much more seamless than Jython, JRuby etc.). So it kind of stuck. (I use Django as well, but not as much).
I get the "what language should I learn" question pretty often. I think I'll point the asker to this article. Thanks for a very broad and easy-to-digest overview.
Fun and relatively comprehensive list, but where is Prolog? Admittedly it is not often practical, but when it is, it make some problem-domains so much easier to grasp.
i wonder why no one mentions Processing as a learning programming language. Its fun and quite capable of doing interesting things. more info at http://processing.org
Pick PHP if you're very concerned with being able to find a quick, cheap online host for your web-app and you don't want to bother with learning another language (or with learning how to deploy web-apps in other languages, which really isn't very hard).
I think he doesn't like all the upvotes for the snarky anti-PHP comment:
You don't really learn PHP so much as catch it. Like a disease.
At the risk of being modded down, the comment has some merit. PHP programmers usually gravitate to PHP without having much experience with related, but supposedly better, languages like Ruby, Python, Lua, etc. But PHP programmers who really dig into programming often leave for other languages. The Ruby and Python communities are full of ex-PHPers. But how many people from the Python or Ruby communities leave for PHP?
This isn't to say that PHP has no merit. It was my first web programming language. But maybe its merits don't stack up well against other languages, which is the subject of the original article.
I know I signed that as my final post, but I feel the need to assure you that I wouldn't be offended by something so silly.
Sometimes you just get bored with a place and feel like moving on :^)
I think I'll spend less time on sites like these and more playing this fine Buffet clarinet I picked up on Saturday. It's been a while, but my embouchure's returning already.
I guess that sort of works... but php is still serverside. Anyone doing web dev must learn javascript, but not necessarily php. Javascript would probably be competing with actionscript or any other client-side plugin stuff.
