Erlang appears on the list. 
8 Likes
TL;DR:
â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â
C, C++, C#, Java, Python, Ruby, JavaScript, Perl, PHP, Objective-C, Swift, Go, Erlang, Haskell (spelled Haskel 
)
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.
1 Like
Very true
1 Like
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.
Perl, JavaScript, PHP, Obj-C (and mispelling Haskell)⊠nope, 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).
2 Likes
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.
2 Likes
Iâll wait for StackOverflow summary of the year, I think itâs a best option.
1 Like
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 nil.
But the :error atom, again, in my mind, is exactly what Iâm talking about when saying no nil.
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 Nothing.
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.
1 Like
For what itâs worth:
TIOBE Index for November 2016. Interesting move: Elixir (from #86 to #64).
http://www.tiobe.com/tiobe-index/
4 Likes
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.
2 Likes
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. 
This list is so meaningless, just wanted to say that.
1 Like
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.
1 Like
