> Scala feels like the Perl of the modern era: there is more than one way to do it. There is value in that mode of thinking, and Perl is a better language than people give it credit for.
> This actually is one of my frustrations with Scala, too many right ways to do the same thing. Makes it easier to write but harder to read especially when people have drastically differing styles. One of the advantages of Java is how easy it is to read and use someone else's code since the base language is so limited.
---
The question of company dialects for various languages comes up occasionally. You can see it with people talking about having to learn a new LISP (or Scheme) each time they switch to a different company.
I suspect that flexibility is similar to what is seen in perl, ruby, scala, and groovy.
The TMTOWTDI Scala exists... but I want to say that it is more a reflection of the power of the language (drawing from their LISP heritage). It becomes then a question of how much does the company impose a consistent way of doing it within the company (compare the different company dialects).
> people talking about having to learn a new LISP (or Scheme) each time they switch to a different company.
Which people, where? Do you have a URL to a discussion?
I've not seen heard or read such talk almost 25 years of being involved in open source Lisp. Needless to say, I've often seen such narrative repeated by programmers not working in Lisp, who heard it from such others.
Someone talking about any industry work in Lisp whatsoever, even just one job, from any angle, is extremely rare.
And that does get into the "25 years ago" area. Really neat place to browse and see as a historical record of discussion from back then.
The issue is that languages that allow/encourage writing domain specific languages within the environment leads to people doing exactly that - writing a DSL that is then used in that company.
These languages (and Scala too) allow for writing a dialect of the language that differs substantially from the main language.
I've seen it in ruby. I've personally done it in groovy (wrote categories to make certain reports easier to write)... twice (also wrote a DSL in groovy that matches the script used as input for powershell doing ftp so that instead of `ftp.ps1 script` it looked like "add this import to the top of the script and do `groovy script`")... for that matter gradle is a groovy script that has gone well beyond groovy as a DSL.
Just as the problem existed with "having to learn a new LISP dialect" 25 years ago, many times going from languages that allow for such flexibility in how its written from one shop to another have the "having to learn a new {language} dialect" today.
For code that I have to work on with someone else, I believe it is better/easier to work in a language that doesn't allow you to rewrite the language so that when I have to work with yet another person, they don't need to learn a completely different way of doing it from what they knew previously.
> Scala feels like the Perl of the modern era: there is more than one way to do it. There is value in that mode of thinking, and Perl is a better language than people give it credit for.
https://news.ycombinator.com/item?id=2603425
> This actually is one of my frustrations with Scala, too many right ways to do the same thing. Makes it easier to write but harder to read especially when people have drastically differing styles. One of the advantages of Java is how easy it is to read and use someone else's code since the base language is so limited.
---
The question of company dialects for various languages comes up occasionally. You can see it with people talking about having to learn a new LISP (or Scheme) each time they switch to a different company.
I suspect that flexibility is similar to what is seen in perl, ruby, scala, and groovy.
The TMTOWTDI Scala exists... but I want to say that it is more a reflection of the power of the language (drawing from their LISP heritage). It becomes then a question of how much does the company impose a consistent way of doing it within the company (compare the different company dialects).