Erlang appears on the list.
“While I don’t think it’s important to be an expert in every language that exists, I do think it’s very useful to be aware of the major programming languages and their differences”
The list is too long and some of them are just too similar to make this list definitive. And Perl? As a lesson on how to not design a language?
Cannot deny that Perl is not still a major language, but yeah, it is a good example of what not to do in language design. ^.^
By that reasoning COBOL should be on the list.
Thank you for noticing the Haskell (double ‘l’, thank you very much!) typo.
And, yeah, I’m on board with the “Perl?! For realsies?!”.
But, you know, no Perl there would be no PCRE and a programming world with no PCRE would have been a very sad one indeed.
I for one salute Larry Wall.
Can’t and won’t take this list seriously, sorry.
I’m tempted to throw into the “why this list is sooo wrong” Go as well. And Java.
No, seriously, we’re 2016.
Multi-core, concurrency and parallelability are the hot topics and what does this list push? Those languages (as well as C/C++ and C#).
I can see why learning Python/Ruby might be a good intro to this whole thing called computer programming, but those languages?!
The world should be moving into functional, concurrency/parallelability supporting langauges as a built-in ability.
Those that don’t have a NULL operator, by whatever name (Oh, yeah, I’m looking at you Go).
Tight yet expressive syntax where the work is being done by an optimizing compiler, not a dev that pounds 1000 LOCs just to get a “Hello, world!” on the screen.
No state by default and immutability by default as well.
Shared-nothing resources (be it STM, actor model, whatever… threads don’t utilize the same resources at any time. (Pair that with lazy processing and you can “share” terabytes of data… only ever really processing what you really need when you really need it).
And that’s true in the so-called “system’s programming” as well.
You’ve got D, Rust, Nim.
Sorry… this list is a load of, you-know-what.
You want to cite it cause it has Erlang on it, go ahead.
But I think this list is bogus.
And, Erlang/Elixir are great languages on their own. They will blossom cause it’s their time (along with the rest of the awesome langs: Haskell, OCaml, Clojure, Kotlin, Rust, Nim, all the ML-derivatives that compile to good JS code).
True, and you should! Post it up! ^.^
And elixir really, in many cases you have to compare to
nil or handle
:error tuples or so without the compiler catching you if you don’t, just an aspect of dynamic typing sadly…
Does D still have the 2 incompatible standard libraries or have they settled on one over the years? Interesting language it was though, played with it a bit almost a decade ago.
I’ll wait for StackOverflow summary of the year, I think it’s a best option.
I know Elixir has
nil, a sad (in my opinion, of course) inheritance from Ruby, and yes, I hypocritically looked away because Elixir has all the rest of the goodies I listed else that it overcomes its inclusion of
:error atom, again, in my mind, is exactly what I’m talking about when saying no
It is not a non-value, something that might creep on you when you least expect it.
It’s a known error that you must plan for and expect and have a contingency plan to handle.
To me that’s a huge difference.
Same with Haskell’s
Maybe: you get either a
Just a or
Nothing and you damn well be prepared to handle that
It’s a value!
Representing no-value, but, in and of itself, it is.
As for D… only ever tried it for a little spin way back ago so can’t tell what it’s standard library is today, but even then it was considered a better C++, and it was functional-capable (multi-paradigm) even then.
Perl? I cant even read it.
JS? LoL, too crazy.
PHP? I use this at work, even thou I dont like it.
For what it’s worth:
TIOBE Index for November 2016. Interesting move: Elixir (from #86 to #64).
Exactly, you always have ‘some’ form of a ‘null’ in dynamically typed languages, I cannot think of one that does not. Compare that to statically typed languages as you describe:
It may be a value, but it forces you to handle it, which is the better way as then an error cannot just creep in somewhere, you know where they will happen and you have to handle it, you cannot ignore a potential bug.
Haskell/Ocaml/Rust handle these properly, they force you to handle the error case instead of just silently ignoring a potential magic error value (like a null pointer in C or
nil in elixir). In Elixir you just get random faults, it may be based on the state passed in, but you can still get something back that you do not expect.
I think I’m getting the distinction. Didn’t think of it like that.
I’d still keep Elixir/Erlang on the “HOT” list and just about all the langs on the article on the “not” one.
There is also comparison for languages 2016 European Software Development Salary Survey
This list is so meaningless, just wanted to say that.
I agree, the list seems to be the same as most job descriptions: i.e
“We don’t know what we want you to do/what you should learn; so you’ll need everything…”
That said, I’ve recently taken the decision to shelve all of my work with Elixir/Phoenix, in favour of better learning PHP and in particular; Laravel. I know it seems like a bonkers decision, particularly when I was starting to make good progress with Phoenix.
However, I’ve realised that I’ve spent the last 8-9 months learning Elixir and various JS SPAs when really, all the apps/sites that I need to be building at the moment don’t need anything like the power and concurrency offered by Elixir. Instead, the well-trodden path, the infrastructure (Laravel Forge, Laracasts, Cashier, etc) and the knowledge that every problem ever encountered has already been solved for PHP/Laravel will get me to a completed, launched app faster.
At the moment (about to go solo), building a business is my priority, and Laravel & PHP is a better tool than Elixir for that purpose right now. Elixir and Phoenix are far superior technically, academically and conceptually; but it comes down to pragmatism. When I need what they offer, I’ll pick up Elixir and Phoenix again.
Thats the reason I think some of those languages on the list deserve a place there. They are still the moment pragmatic option, despite being less than their contemporaries.
I used PHP alot back in the day. Never used Laravel, but it seems to be constructed via a classic OOP approach. If you’re going down that route, I found this book, “Modernizing Legacy Applications In PHP”, by Paul Jones to be very useful. Lots of detailed, practical discussion on the better practices in that domain and how to avoid technical debt down the line.
Using tools that make you more productive is definitely an important consideration, my Elixir experience is very limited but one of they key attractions for me is actually productivity gains I think the somewhat lacking support infrastructure is more than compensated for by very supportive community. When I am sleepy or distracted I periodically start trying to use Elixir features in other languages (like trying to write a guard clause) which each time reminds me of the power of Elixir. So It is very likely a very personal thing as far as what makes one productive.