Ask HN: What language should I learn next?
So I've spent significant time in Node, Go, VB, and C#. I've got an "understanding" of Objective-C also.
I've toyed around with C and love it but haven't been able to think of a tool for myself to build as a project and that's really how I actually learn a language.
I have no interest in Cpp but other than that I'm very interested and open minded.
I used to hate Ruby and Python syntax but I am warming up to Python after experimenting some more. Ruby not so much ( what is it with the pipes when you iterate over something ) but I could be convinced.
All in all I'm open to suggestions and with a fairly diverse group here I imagine I could find some direction or at least some pointers ( no pun intended ).
Thanks everyone
53 comments
[ 2.7 ms ] story [ 63.7 ms ] threadI notice there's nothing functional on your list. Any functional programming should prove really interesting for you, and teach you a lot. Certainly learning a bit of Haskell has changed how I write in all other languages. I would go for Haskell because the strict type system is also a really interesting thing to learn, but alternatively you could go for Erlang which emphasises error handling/recovery for services with high uptime, or something like Scheme which has s-expressions and macros which are apparently really great to learn.
I experimented only very little with Erlang when I was setting up an XMPP server but the syntax was so confusing. I could get over it eventually as I imagine everyone faces that.
In fact, Haskell's syntax is quite beautiful and clear. If Haskell's syntax is mind-expanding, it is mostly in how much syntax other languages have, yet to seemingly so little effect at times, when a language with a great deal less syntax like Haskell turns out to have so much nicer ways of saying certain things.
But let me echo in general that even if you don't choose Haskell, you need to get out of the Algol language arena. From where I sit, you basically said you are familiar with about 1.5 distinct languages. C would force you into manual memory management, which is a real change, and I'd bump that number a bit, but still not a full language. Ruby and Python are basically redundant between VB and Node and I think I'd add 0.0 total. Erlang is, arguably, 70-80% redundant to Go; Erlang is a bad functional language so I wouldn't say it checks that box, and while there's still some nice aspects of the Erlang language as compared to Go, you've still gotten quite a bit of the Erlang value out of Go.
SICP is another excellent suggestion. You won't find it quite as mindblowing as someone coming solely from C, but there's still some great stuff in there for you, which will translate quite nicely into some of those languages you already know.
Do you have any arguments about Erlang’s syntax being “actively” clunky, whatever that “actively” means? Or is it just your personal opinion? (This comes immediately to mind: http://rvirding.blogspot.se/2014/01/erlang-syntax-again-and-...)
Another claim that you make without baking is that Erlang is 70-80% redundant “to” Go. Care to elaborate? How have you measured that number?
Let’s go to the next point where you claim that Erlang is a “bad” functional language. What does that mean? “Bad”? What is that? Maybe you mean that it isn’t a pure functional programming language? That’s not a bad thing, nor good, but it’s not bad. Erlang has never aimed to be a pure functional programming language, it aimed at solving a very specific set of problems. Erlang is a functional programming language, and its simplicity, the minimal syntax that you can pick up in a day, actually makes it a really good choice for introducing functional programming to someone who has never had contact with it.
Let me tell you something about Erlang and Go. Contrary to what you have read in the news, Erlang and Go are totally different. As a user of both languages I have no idea what you mean when you say “there's still some nice aspects of the Erlang language as compared to Go, you've still gotten quite a bit of the Erlang value out of Go”. What? What aspects/value? The only thing that these two languages may have in common is the fact that they both offer concurrency primitives as first-class language citizens. Even with that, the concurrency models are very different. Only someone without experience in the languages would say that the concurrency in Erlang is like the one in Go. On the other hand, none of the aspects that make Erlang an amazing language for its niche aren't present in Go. In Go you can mutate state, Erlang is immutable. In Go you use channels to communicate between processes by sending data, in Erlang you send messages. Erlang processes are garbage collected individually which makes it a perfect fit for soft real time systems, Go goroutines are not. Erlang has primitives for building distributed systems, you can spawn processes on remote nodes just as you would spawn processes locally, Go does not have this either. In Erlang you can reload code while the system is still running, in Go you cannot do that. I can go on and on. So, yeah, don’t trust the news, see for yourself before you “advertise” stuff that you have only read about in the news.
Of course it is. But contrary to the occasional Erlang syntax defender, after 8 years of use I still find it klunky. It's klunky enough that I find myself frequently having to override a desire to do something the easy, wrong way rather than the harder, right way. I consider this a great sin.
'Let’s go to the next point where you claim that Erlang is a “bad” functional language. What does that mean? “Bad”?'
It makes everything functional a real pain. Yes, you can pass functions around, but the syntax is klunky and annoying enough that you don't want to do it. Practical usage of Erlang ends up using it as an imperative language with a "strange" restriction against using the same variable twice (leading to the very common Result, Result1 = Something(Result), Result2 = SomethingElse(Result2), etc pattern), not as a functional language. Compare the structure of Erlang code with other functional languages; Erlang looks more like imperative code than functional code. It's a bad functional language. It's a decent enough language itself, but it's not a good functional language.
And let me pull that out and emphasize that... I'm not looking at the theoretical design issues of the language, I am looking at what code comes out in the real world. Erlang is not programmed functionally. In fact you could strip it out entirely, allow in-process "mutation", and as long as you prevented processes from being able to share any data, you would not notice the difference, excepting that your code might get simpler. As near as I can tell, virtually nothing would require any significant rearchitecting, or indeed even any API changes to speak of. It's entirely incidental to the real considerations of total process isolation and message passing. Erlang is programmed procedurally, with isolation between actors being the primary isolation tool.
'As a user of both languages I have no idea what you mean when you say “there's still some nice aspects of the Erlang language as compared to Go, you've still gotten quite a bit of the Erlang value out of Go”.'
In terms of learning multiple paradigms, if you're already intimately familiar with Go, Erlang won't teach you very much.
"Only someone without experience in the languages would say that the concurrency in Erlang is like the one in Go."
I have extensive experiences in both. On the grand scale of things, they are fairly similar. Locally they have a lot of differences, but designs come out fairly similar in both cases. Compare with the incredible differences that you get in Haskell designs, or conventional threading designs. With just a bit of grease code added to Go, you can straight-up port an Erlang design to a Go design. This would not be optimal in Haskell, and not be practical in a pthreads&locking-based world or an event-based world like Node, both of which would exert significant pressures to structure your code in other ways.
Again, I am looking at how the designs come out, not the theoretical considerations.
I think perhaps the perspective difference here is that I've also got a great deal more than just Erlang and Go under my belt. For all the superficial differences, if you already know one, if you're out to get a lot of experience in the different languages in the world, you're better off learning something else entirely than go learn the other. Erlang has some advantages on the crash-first front and multi-node stuff, but they aren't open-your-eyes perspective changing the way that, say, your first encounter with closures are, or a read-through of the SICP is.
You missed the biggest practical difference between the languages, which is that Go's synchronization primitives default to synchronous and Erlang's to asynchronous. I find that dominates most of the other differences you listed. As opposed to issues like garbage collection, which har...
What practical usage of Erlang are you talking about? I work in telco and I have yet to see that practical usage of Erlang ends up using it as an imperative language. What you are referring to can happen in many other functional languages when used by people without FP experience. I don’t see how this is related to Erlang in an explicit manner. I agree with you that it does not provide what Haskell does but it’s a functional programming language, wether you like it or not.
You talk too general. Again, which real world are you referring to, I am working in telco and the quality of the code is impressive in most of the areas. If you work in a startup where programmers used Node and Ruby until yesterday and today they are doing CRUD with Erlang then yeah, probably the quality of your real world Erlang lets to be desired or maybe not, but you get the point. However, the code that I had contact with so far was functional, easy to understand and reason about, despite being written in Erlang.
-- In fact you could strip it out entirely, allow in-process "mutation", and as long as you prevented processes from being able to share any data, you would not notice the difference, excepting that your code might get simpler. --
Erlang is a niche language, you can also prevent dangling pointers, that’s not the point though, people make mistakes. The fact that everything is immutable is very important in the domain that Erlang was conceived for. What do you mean that the code might get simpler? Are you sure? I guess it would get more complicated since you no longer have the immutability guarantee.
-- Erlang is programmed procedurally, with isolation between actors being the primary isolation tool. --
Says who? And which Erlang are we referring to?
-- In terms of learning multiple paradigms, if you're already intimately familiar with Go, Erlang won't teach you very much. --
It will teach you some functional programming concepts, requirements and architecture of real-world soft real-time distributed systems (given that you will not ignore OTP), the fail first concept. These are not light subjects. As I said earlier, I am very intimately familiar with Go. I contribute code to the project and use it almost daily, however I fail to see how Go would learn me anything about these issues, and this list is big and important enough for me so that it would make it worth to learn something about Erlang, probably not good enough for you and I understand that.
-- I have extensive experiences in both. --
Please allow me to have my doubts about that. What kind of systems have you built with Go, how about Erlang? Have you tried to implement 3GPP in Go for instance, how about Erlang? Are you confident that you could reimplement 3GPP in Go with minimal effort, and get back the same guarantees that you get for free in Erlang? If not, how can you reason that Erlang brings nothing new to the table if you already know Go.
-- On the grand scale of things, they are fairly similar. Locally they have a lot of differences, but designs come out fairly similar in both cases. --
No, they are not. They are completely different, the only commonality being that they offer concurrency primitives. Again, what kind of systems are we talking about? CRUD web apps?
-- With just a bit of grease code added to Go, you can straight-up port an Erlang design to a Go design. --
Right, I am really curious to see someone porting a distributed Erlang system to Go in the same amount of code, with the same safety guarantees, with “just a bit of grease code added“. I am not saying that it is not possible to achieve something similar, I am saying that you will probably need a lot more work than you imagine or describe here, a...
I can shout "learn assembler" until the cows go home, but if you want to go into AI and hate the idea of being an embedded programmer, then you'd be much better off learning LISP.
When I was a bit younger, everyone told me to learn PERL, because PERL was very powerful. I learned it, but never really needed it, because I never needed to write software that was heavy on text processing or system administration. If I were able to do it all over again, I would have picked R instead, because it would have been much more useful for my career path.
I would love to do desktop apps on Linux but it seems that my only real choice there is C++ and that has always seemed a language beyond what I could do.
node-webkit runs on Linux, that's a pretty reasonable choice for cross-platform development these days. Used by https://github.com/LightTable/LightTable and https://github.com/slate/slate, for example.
I agree with the suggestion to move to a functional language -- Ruby and Python wouldn't teach you much on top of Node and Go. Doesn't really matter which one -- Scheme, Haskell, Clojure, whichever.
Lots of Linux apps are also written in Python, so that might be something to look into.
You should definitely learn PHP.
That way you can partake in all the wonderful flame wars that pop every few weeks here.
You're being silly. To be best equipped for a PHP bashing one shouldn't know PHP or anything related to PHP.
Attribute this to my increased maturity if you want, but I've started web development again just over a month ago. Full-stack JS feels great to me. It's intuitive, unlike what PHP was. It feels clean, uncluttered, unlike what PHP was.
If you are learning just for fun I would suggest a bit of Prolog for logical programming, a Smalltalk derivative to see how the original OO is all about and the Xerox Parc concepts or a more pure FP language like F#, OCaml, Scala, Lisp derivative.
If on the other hand you intend to learn more with focus on a certain career path, then better look into what languages are being used in the fields you care about and learn one of those which you still don't know.
Python's syntax, by contrast, is simple, intuitive, and fairly standard. Python does have a few innovations over other languages -- the most important that come to mind are indentation-delimited blocks [1], tuple unpacking, list comprehensions, generators, args/kwargs, and access operator overloading. All of these are usually optional in your own code and easy to grok when you seem in others' code. When you are ready to use these syntax elements, you will find them easy to learn and quite practical in a variety of situations.
Python code can be concise without being unreadable. This greatly improves developer productivity, which is very important. Most projects are bottlenecked by developer time.
Python is a truly general purpose programming language, with excellent library support. People can and do use it for command-line utilities, web applications [2], math/science [3], and desktop applications [4].
[1] Using indentation to delimit blocks is a controversial "innovation" of Python. I suggest suspending judgment until you've written at least one medium-sized program in Python. As a matter of coding style, usually programs written in high-level languages also use indentation to denote blocks; when this indentation gets out of sync with the rules the language actually uses to delimit blocks, you can get hard-to-spot bugs like this one:
This will compile, but the if statement is a no-op, and myFunction() will always be called, which is probably not what the author intended. The above bug cannot happen in Python; since Python actually uses indentation to determine blocks, by definition the indentation cannot get out of sync with the way the compiler/interpreter sees your code.[2] For Python webapp development, I recommend writing a simple webapp with Flask first, then adding sqlalchemy for proper database support. Once you're comfortable with that combination, you'll want to switch to Django.
[3] Try Sage, IPython, numpy, and scipy.
[4] I recommend GTK+ for desktop apps, especially on Linux. http://python-gtk-3-tutorial.readthedocs.org/
This is actually not so much the case any more; many packages now support Python 3, and Python 2.7 is nearing end-of-life. However, many of the tutorials you will read have probably not updated their statements about Python 2/3 compatibility.
Python 2.x was indeed far better as far as library compatibility for quite some time after the (IMHO idiotic) decision not to use the proven Python way to introduce new features (from __future__ import), and instead have the 3.x release break backwards compatibility entirely.
My advice is to start with Python 3, then switch to Python 2 if you discover your project requires a specific library that does not yet support Python 3.
thats good. There are 10 kind of languages: Those nobody use, and those everybody hate. So a coder who does not curse a language has never used it.
Now the question what to learn next is depending if you want to learn languages that open your mind for new concepts, or do you want to learn a language that helps you in the job market?
For the first I would recommend:
Forth or Postscript to learn a stack oriented language.
Lisp or Scheme to learn a lambda calculus language.
Smalltalk to learn what real object orientation means.
Lua or Javascript to learn prototyping.
Haskell to learn functional programming.
Erlang to learn how to write massive parallel code.
Last improve your C skills, read "a little Smalltalk", and write your own programming language. Dont be shy. Ruby or Python code reads as if they also did read a little Smalltalk, decided that designing their own language is easy, and repeated all errors from the book. Always remember: Smalltalk was 35 years ahead of its time. Since then every year a new language is hyped, each of them one small step closer to Smalltalk.
If you want to learn for the job market, then learn Linux, Perl, PHP, Java, SQL, HTML, CSS and JavaScript.
I remember reading somewhere that the OO system for python was sort of bolted on after the language had been around for awhile. When I write classes in python, there is something awkward about it that I just can't put finger on. I remember thinking it was strange to have to pass in 'self' to member functions, and then realizing that it was like 'this' in c++. So why does c++ hide that implementation detail while python lets that detail leak out? I wonder if 'self' could be passed in behind the scenes and any references to local variables that haven't been declared in that scope can be assumed to be instance variables.
I'd recommend Erlang for its concurrency model (especially comparing how languages like Erlang, Scala, Go and JavaScript/Node handle concurrency and parallelism differently).
Haskell is good for functional concepts - understanding FP will help with functional stuff that is migrating into more mainstream languages.
Learning a Lisp (Common Lisp or Clojure) is good too.
Python is great for the mature community that's developed around scientific projects like machine learning, NLP and such.
I would encourage you to learn some Java (helps with understanding the ecosystem, and used in plenty of examples), and then focus on a JVM language. Scala and Clojure are obvious choices, because they come with their own ecosystems and contain new language paradigms.
My preference (since I do a lot of JVM work) and first recommendation is Scala, it has good libraries for all of the above, web, scientific, big data, and even Android development (and all Java / Clojure libraries you can find, as well as Jython, JRuby and even with Java 8, some Node.JS clone). Another reason I like it is that it let's you write both in a functional style and in a object oriented style without compromising or enforcing either. (it gives you a nudge towards functional style when possible, but let's you write imperative and OO code with the same ease). Cons - a bit long compile times (bearable for me) and some say it has a "too complex" type system, I think that for most programmers the type system complexity doesn't really have any impact.
If you like dynamic languages, I'd try Clojure, it's been very popular here and from the little I played with it I appreciate it's simple syntax and way of thinking. As others have mentioned your background is mostly imperative / OO background and Clojure is a great way to venture into functional programming (especially if you need a JVM language)
If you don't need a JVM language, try Haskell! (same reason - learn some functional programming paradigm for great good)
Out of the above 3 you can find paying jobs, but I have a feeling Scala will render more openings (though usually with Java experience requirement as well)
If you aim at Systems programming, I'd try d / Rust rather than C++.
If you want web orientation, Python and Ruby are a must (sorry) Ruby is a nice language once you let it grow on you, you'll get used to the pipes.
If you are into scientific programming, Python, Julia and even Scala are good choices.
If you want to get a fast high paying job - depends on where you are located, if in SF, go with Rails, Django, Node, knowing the framework is as important as knowing the used language (Ruby, Python and JavaScript respectively)
If you are in Atlanta, stay with the .NET stack or pick up Java.
In NY Java will serve you well (also in SF, but perhaps in less startups and more Google / Twitter kind of companies)
I think Java is good to know even if you hate it, it's everywhere (and with the new Java 8 it's almost bearable again to code in it)
My last point is that the programming language is the least of a developer's concerns. A developer needs so many more skills than knowing language X spec by heart. Things like SQL, Linux, Git, HTTP, HTML5, CSS3, Good design and coding standards (read the pragmatic programmer / clean code / code complete etc...) And most important - interview skills and other soft skills. All of the above are way more important that the language of choice IMHO. (I'm sure you have all these, but I think that the impact of which language to go with next has much less weight in making you a great developer than what people usually seem to depict. E.g. I don't see often a "which soft skills should I pick up next" or "which general design book should I read next". I think it's because programming languages are more interesting :) (at least to me) and simpler to define. They have strict rules, and you either like it or not. General programming skill and soft skills are so hard to quantify and not easy to explain I guess. But I work on myself to try and spend more time improving these, than learning yet another language. (I fail at this too often though)
Consumer-facing design has been one of my weak points but as far as system management, server maintenance, etc I manage cloud deployments of several (some my own, some not) for the company I work for out in PA.
That side of technology I am very comfortable with. It was only two years ago that I started coding but I've seen my own code evolve over time--significantly I might add.
I think I will end up getting into systems programming. I've got the rust compiler installed but it does seem a little young.
Go deeper, not broader. Another language can help you learn about stuff, but knowing languages is less important than understanding how they are used.
Learn about event handling. If you have toyed around with C, get an arduino and learn about hardware interrupts. Learn about concurrency and distributed systems. learn about semaphors and locks and other ways to deal with resource contention.
Understand memory. Know how a hash/dictionary works. Look at implementations of variable length arrays.
Write a toy database and driver. Now make it work when two programs are accessing it at the same time.
Write a server.
Take old horrible code in some language you know well, and update it to current standards with unit tests.
Read the code libraries you use often. Or try to implement your own version of the base case of a POSIX like tail.
Write a function to convert a string to a floating point number without taking advantage of the built in float or atof functions.
Learn about how compression algorithms work and implement a simple one.
These are not easy things. And you don't have to finish them or do well or do all of them. But you will get experience you can't get sticking with the basic features of a language that will serve you well.
[0]: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
Ruby, like many languages, has support for anonymous functions (lambdas, procs, blocks, etc.) The pipes are the delimiters for the formal parameters that the function receives. Most languages use parentheses for that. For instance, you might expect something that looks like this:
Here, a function body is defined and passed as an argument in the same place other arguments are listed. Also, the parameters of that function are defined outside the body of the function, within parentheses.In Ruby, the format is just different. You can bind a lambda to a variable and pass that variable in just like any other argument, but if you want to give an actual unbound function body as an argument, you have to use the Ruby block syntax, which delimits the block using either `do`...`end` or `{`...`}`, and immediately after the beginning delimiter, you can define formal parameters. The definition of the formal parameters of the block is delimited by pipe `|` characters. The other strange part is that the block is not presented as an argument quite the same as the others: it is outside the list of formal parameters for the function receiving the block. The previous example in Ruby is
The name of the function now is slightly misleading since in Ruby, every function can receive a block (although it may not do anything with it).I can assure you that after working with the language for a while, that syntax is not a problem at all. I had, in fact, completely forgotten that I thought it was strange when I first learned Ruby. There are things much more annoying in Ruby than that syntax, like an abundance of slightly different ways to define a closure, each with subtly different effects.[1] Overall, however, it is quite a nice language to work with.
[1] http://innig.net/software/ruby/closures-in-rubyhttp://innig....
Thank you very much for that. It is somewhat of a jarring change from what I'm use to but I at least understand it now.