TL;DR - learning new programming language's syntax doesn't make you able to properly (& fully) utilize its potential as each language comes with something much harder to learn: its own idiomatic identity - unique expressive power that determines constructs & patterns strongly preferred (optimal by design) in this particular language.
These are great times for being a software engineer. There are so many ways to solve problems, so many platforms, languages & tools to crack the obstacles & make a difference. You can quite likely deliver similarly satisfactory business effects by using Node.js, ASP.NET Web API, Go, Spring.Boot or Rails. As a result, in many companies teams are free to pick the tools of their choice and derive satisfaction from succeeding on their preferred platform.
Going beyond syntax
In some (reported) cases people tend to go a bit too far, rapidly jumping from one tech stack to another, in a neverending quest for perfection, satiating inner geekdom & learning new stuff. It doesn't sound perfectly reasonable :) but it's up to their companies whether they accept this or not. Unfortunately, at least in some cases (I've actually encountered few of them), this "exploration" is completely devoid of any sense, because the only thing that can be explored in such a rush "platform-hopping" is mere syntax.
idiomatic - peculiar to or characteristic of a particular language or dialect.
(according to dictionary.com)
Contrary to the common belief, particular programming language isn't only about syntax, core libraries, community activity, build systems, package repositories & landscape maturity. Syntax itself is never "tight" enough to fully reflect abstract, conceptual model & unique "expressive power" of the language. Additionally, keep in mind that it's hard to teach an old dog new tricks, so people keep following practices & patterns they've grown accustomed to before (using other languages). As a result (i.a.):
- a lot of C to C++ converts have shamelessly (& only half-consciously) continued to write C-style code using C++ syntax
- many former Java developers just writes Java (+ some syntactic sugar) in Scala
- Elixir community puts so much emphasis in fighting the belief that Rubyists can now write Ruby on BEAM (Erlang platform) & automatically (w/o giving it much thought) benefit from actual OTP goodness
In other words: developers transition to the new language, but twist its usage, ignoring (consciously or not) idiomatic patterns & scenarios. This is very, very wrong as some constructs that do great on one platform are definite no-goes on other ones, e.g. if you apply traditional control flow & exception-based error handling in Elixir (w/o utilizing processes & OTP in general) it will prevent 'let-it-crash' paradigm & any scalability advantages, leaving you with averagely efficient Ruby dialect running on exotic VM ...
What are my lessons learned regarding idiomatic programming languages that I'd like to share with you?
- if you're missing the presumed advantages of new platform, without really knowing 'why', hold on your disappointment & avoid fruitless flaming on the web, but try to look "behind the syntax" - even if compiler lets you to do something, it doesn't mean it's proper for this language.
- learning new language or library/framework with a rich (potentially DSL-enhanced) model is a process far longer (& demanding) than getting familiar with bare syntax - that's why doing programming kata is so important.
- this one may be controversial for some, but ... over-expressive programming languages with too much of syntactic sugar & watered-down idiomatic identity are usually wrong tools for any job & should in general be avoided (maybe even buried deep down below the surface of earth ...)
What's the justification for the last remark? IMHO this is a clear indication of bad language design & development process - either language's vision & purpose were not clear (or got muddy throughout the way) or language development is performed wrong - usually in a chaotic, unorganized way. Results are always the same: reduced readability, rotten compromises introduced after learning the unintended side-effects of hastily introduced syntactic sugar, excessive complexity of all compilation phases.
Pic: © TungCheung - Fotolia.com
