I'm not normally one to complain about headlines, but I think the editorializing here does a huge dis-service to the blog post. It implies there is such a thing as one true best language, which is pretty obviously false. I almost didn't even bother reading the post because of it.
EDIT: If it gets changed, the submitted title is "Why Scala is the best language available today"
The original headline doesn't tell you anything about what the post is about; when I've submitted posts under similar headlines they've sunk without trace.
"This is the problem with dynamic syntax in, well, dynamic languages. As Philips puts it, ignorance is strength, and freedom is slavery..."
Hey man, that's like... your opinion
In my opinion types are a poor man's schema, my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo". I use schema libraries and asserts to both document the code and make sure you can't feed it wrong data. I even generate automatic html documentation out of my schema so my clients know what to send me, and this only in the places I need, no need to a schematize or assert every simple function with obvious parameters.
Maybe type annotation is more useful in OO languages, but as a clojure programmer, for me, data is just data, there's no behavior associated. If I really want type safety at compile time I can use core.typed only in the places I need it.
As a former long time java programmer (who tried scala for months) I welcome my new found freedom from type slavery, but that's just... my opinion.
> my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo"
I fully agree. Those sound like exactly the kind of thing I would enforce using types.
> and this only in the places I need, no need to a schematize or assert every simple function with obvious parameters.
How do you enforce that all code paths go via your schema? Just visual inspection?
Unfortunately dependent types are incredibly difficult to get working (Scala's type system is already turing complete (and can handle path-dependent types) and true dependent types would make reasoning about nigh-on impossible).
I would argue that you're dealing with a sub-typing problem here, Email <: String, LongLat <: (Int, Int)*
Have you ever worked in enterprise projects with distributed teams, around > 30+ developers per site, grokking hundreds of code lines in a dynamic language without unit tests, because they are a waste of employee salary time?
I really value strong typed languages in such projects.
>In my opinion types are a poor man's schema, my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo".
Err, you know that a type system could take care of all of those contraints, right?
Because you come across as types for you are restricted to be just the known scalar or barebones object types.
Having an email just as a string if far from the exhausting the specialization you can do using an "email" type.
Types are generally a hindrance for a small scale app. They pay off when your working on an app that has 30-40 developers and millions of lines of code.
Use the right tool for the job, and there are jobs where Types are the right tool.
Hm, I have an issue with the absolute qualifier "best". Best in what respect?
I'd personally say Python is best.. for general data manipulation. But it's slow.
Go is best.. for network and concurrent programming, but it's rough around the edges and comparably low level.
C is best.. for precise control of the hardware. No hand-holding here. But that's also it's weakness.
C++ is best.. has all the bells and whistles you can think of, and more. More of the later probably.
PHP is best for.. masochists and people used to it. It's also one of the quickest ways to create a web application by completely abstracting the low level stuff away.
C# is best.. for religious people and people who buy into the Microsoft ecosystem. Strong library selection.
Java is best.. for people who are looking for a job. As boring as enterprise is, they have money and look for Java devs.
VBA is best.. if you are on a locked down corporate environment, just because it's almost the only option.
<insert language> is best.. <advantages>, but <constraint>.
So, you want to tell me that Scala has all advantages and none of the disadvantages? I don't buy it..
Legally, best is a vacuous term, meaning "as good as anything else." So if you say "this is the best tire ever" you can't be sued, at least in an English speaking country (unless they spell it tyre).
Critically, never take a "best" statement at face value since these things can't be measured anyways.
you might try julia. it's a bit like python with optional types and (the promise of) speed. i am hoping it works out (and agree in general with your viewpoint otherwise, except i haven't tried rust or kotlin).
> To my eyes this is half the genius of Scala: things that would have to be config files in another language are instead just Scala code that uses particular functions and classes[2].
That's cute; he seems to think the reason for managing configuration information in separate files is due to the inflexibility of Java. Let's hope that one day he has to deal with a non-trivial project and is enlightened.
> a language core should be small but flexible; despite the power and complexity of Scala libraries, Scala's language specification is much shorter than Java's
Looks like GrǬǬvy, also begun in 2003, went the other way, making its language grammar larger but its core methods small.
I will not rehash my strong objections to Scala, but I think that this kind of discussion about programming language starts off on the wrong foot – the same wrong foot that led to what I perceive is everything that's wrong with Scala.
A new programming language that hopes to achieve wide adoption is a big deal. A very big deal. C has been in widespread use for 40 years now, and Java for almost 20. You could switch a language every five years or so, but that means that you're not in "mainstream software development" but in some kind of Silicon Valley startup (a tiny minority among software developers). Mainstream software developers don't switch languages every five years, and in most case, not even every decade, so they'd better get the language right.
But what makes a programming language right? That is a big question. Obviously, adoption, which is also a result of marketing, is a major factor regardless of the language's intrinsic merits. Also, you must consider your domain. Ruby is great for short-lived projects; Java is great for big, complex projects with dozens or hundreds of developers.
But assuming you've taken all that into account, making a switch better be really justified. The problem with the article, I think, is it focuses on specific language features (effects, delegation, etc.), which is what got Scala into trouble (IMO) in the first place.
When thinking about a new programming language, especially one not intended for research but for widespread adoption, this is not the way to go. I believe we should start by thinking what are the big problems with software developments, and how we can address them with a new language – one that does not simply offer this or that convenient feature, but gives a really big advantage, one that merits a switch. Java has done it with a GC for a C++-like language, and to a lesser degree, with threads. Clojure and Erlang address the issue of state - Erlang because of fault-tolerance, and Clojure (mostly) because of concurrency.
On the other hand, some languages, like Ruby, focus on "developer productivity", which often means getting to working, useful code quickly, while maintaining good readability. This is, no doubt, important (for some domains much more so than others), but is this a major problem of software development today?
Also, the article talks a lot about type safety. But type safety is language feature which is a means to an end. That end can be project maintenance/manageability, and arguably more correct code. But are there other ways of achieving this goal? I'm not saying there are, I'm just saying we should start by studying the problem, not examining particular solutions. Every language feature must be a part of solving a big problem; big enough to justify switching languages. After all, that's is a big deal so we better get it right. So, what big problem are you trying to solve?
As some people already mentioned, you should really stop treating your personal opinions (which quite often lack both substance and any evidence) as the one true thing.
I also find it a bit irritating that you love the vague claims like in the last article, but don't like articles with a precise and to-the-point description of issues. It's almost like you want to love all negative articles on Scala, but have to hate even neutral or remotely positive ones, completely irregardless of the quality of the article and the issues raised in them.
It leads to this whole train-wreck of reasoning here which you seem to be forced to post in pretty much every post with the word “Scala” in it.
Nobody can prevent you from spending your time with things you hate, but from my experience, live is happier if you spend it on things you love.
I have problems a few random floating statements:
"decorators have well-defined semantics in Python"
Python lacks well-defined semantics for just about anything.
even simple expressions like 1.0 + 1/2 will evaluate to different things depending on which python version you're using.
I want a strongly and statically typed, preferably compiled, multicore PHP, basically. With good tooling, if the world was perfect. Scala seems to fit that in my limited playing, and seems to be the closest in terms of what I want out of a language in general. I'm still keeping an eye out though, as Scala does have some rough edges.
[+] [-] steveklabnik|12 years ago|reply
EDIT: If it gets changed, the submitted title is "Why Scala is the best language available today"
[+] [-] lmm|12 years ago|reply
[+] [-] islon|12 years ago|reply
Hey man, that's like... your opinion
In my opinion types are a poor man's schema, my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo". I use schema libraries and asserts to both document the code and make sure you can't feed it wrong data. I even generate automatic html documentation out of my schema so my clients know what to send me, and this only in the places I need, no need to a schematize or assert every simple function with obvious parameters.
Maybe type annotation is more useful in OO languages, but as a clojure programmer, for me, data is just data, there's no behavior associated. If I really want type safety at compile time I can use core.typed only in the places I need it.
As a former long time java programmer (who tried scala for months) I welcome my new found freedom from type slavery, but that's just... my opinion.
[+] [-] lmm|12 years ago|reply
What's the distinction you're drawing here?
> my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo"
I fully agree. Those sound like exactly the kind of thing I would enforce using types.
> and this only in the places I need, no need to a schematize or assert every simple function with obvious parameters.
How do you enforce that all code paths go via your schema? Just visual inspection?
[+] [-] octo_t|12 years ago|reply
Unfortunately dependent types are incredibly difficult to get working (Scala's type system is already turing complete (and can handle path-dependent types) and true dependent types would make reasoning about nigh-on impossible).
I would argue that you're dealing with a sub-typing problem here, Email <: String, LongLat <: (Int, Int)*
* I would say in Scala:
[+] [-] pjmlp|12 years ago|reply
I really value strong typed languages in such projects.
[+] [-] hrvbr|12 years ago|reply
Here's the documentation for custom types in F#:
http://fsharpforfunandprofit.com/posts/conciseness-type-defi...
http://fsharpforfunandprofit.com/series/understanding-fsharp...
http://fsharpforfunandprofit.com/series/designing-with-types...
Types are a very good way to model your data strictly.
[+] [-] coldtea|12 years ago|reply
Err, you know that a type system could take care of all of those contraints, right?
Because you come across as types for you are restricted to be just the known scalar or barebones object types.
Having an email just as a string if far from the exhausting the specialization you can do using an "email" type.
[+] [-] ShardPhoenix|12 years ago|reply
[+] [-] adamnemecek|12 years ago|reply
Dependent types to the rescue!
[+] [-] stormcrowsx|12 years ago|reply
Use the right tool for the job, and there are jobs where Types are the right tool.
[+] [-] skriticos2|12 years ago|reply
I'd personally say Python is best.. for general data manipulation. But it's slow.
Go is best.. for network and concurrent programming, but it's rough around the edges and comparably low level.
C is best.. for precise control of the hardware. No hand-holding here. But that's also it's weakness.
C++ is best.. has all the bells and whistles you can think of, and more. More of the later probably.
PHP is best for.. masochists and people used to it. It's also one of the quickest ways to create a web application by completely abstracting the low level stuff away.
C# is best.. for religious people and people who buy into the Microsoft ecosystem. Strong library selection.
Java is best.. for people who are looking for a job. As boring as enterprise is, they have money and look for Java devs.
VBA is best.. if you are on a locked down corporate environment, just because it's almost the only option.
<insert language> is best.. <advantages>, but <constraint>.
So, you want to tell me that Scala has all advantages and none of the disadvantages? I don't buy it..
[+] [-] seanmcdirmid|12 years ago|reply
Critically, never take a "best" statement at face value since these things can't be measured anyways.
[+] [-] octo_t|12 years ago|reply
[+] [-] lucian1900|12 years ago|reply
I'm productive with Python, but it lacks many useful things and I'm no longer comfortable with the rampant mutation.
I like Haskell and the type system is extremely useful (typeclasses ftw), but I haven't managed to become productive using it.
Scala scares me like C++ does, through sheer size.
Rust is very interesting, but not yet mature enough. I'm not even certain that level of abstraction would generally be the one I want.
Clojure is perhaps the closest (especially with core.typed and ClojureScript), but the dependency on the JVM is unpleasant for me to say the least.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] andrewcooke|12 years ago|reply
[+] [-] coolsunglasses|12 years ago|reply
[+] [-] _pmf_|12 years ago|reply
That's cute; he seems to think the reason for managing configuration information in separate files is due to the inflexibility of Java. Let's hope that one day he has to deal with a non-trivial project and is enlightened.
[+] [-] vorg|12 years ago|reply
Looks like GrǬǬvy, also begun in 2003, went the other way, making its language grammar larger but its core methods small.
Beginning with a clone of Java's grammar, they expanded it with lots of extras, see http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/...
And for the core methods http://groovy.codehaus.org/api/org/codehaus/groovy/runtime/D... (note the methods marked "deprecated" still actually exist but were repackaged into other classes for Groovy 2.x).
[+] [-] CmonDev|12 years ago|reply
[+] [-] pron|12 years ago|reply
A new programming language that hopes to achieve wide adoption is a big deal. A very big deal. C has been in widespread use for 40 years now, and Java for almost 20. You could switch a language every five years or so, but that means that you're not in "mainstream software development" but in some kind of Silicon Valley startup (a tiny minority among software developers). Mainstream software developers don't switch languages every five years, and in most case, not even every decade, so they'd better get the language right.
But what makes a programming language right? That is a big question. Obviously, adoption, which is also a result of marketing, is a major factor regardless of the language's intrinsic merits. Also, you must consider your domain. Ruby is great for short-lived projects; Java is great for big, complex projects with dozens or hundreds of developers.
But assuming you've taken all that into account, making a switch better be really justified. The problem with the article, I think, is it focuses on specific language features (effects, delegation, etc.), which is what got Scala into trouble (IMO) in the first place.
When thinking about a new programming language, especially one not intended for research but for widespread adoption, this is not the way to go. I believe we should start by thinking what are the big problems with software developments, and how we can address them with a new language – one that does not simply offer this or that convenient feature, but gives a really big advantage, one that merits a switch. Java has done it with a GC for a C++-like language, and to a lesser degree, with threads. Clojure and Erlang address the issue of state - Erlang because of fault-tolerance, and Clojure (mostly) because of concurrency.
On the other hand, some languages, like Ruby, focus on "developer productivity", which often means getting to working, useful code quickly, while maintaining good readability. This is, no doubt, important (for some domains much more so than others), but is this a major problem of software development today?
Also, the article talks a lot about type safety. But type safety is language feature which is a means to an end. That end can be project maintenance/manageability, and arguably more correct code. But are there other ways of achieving this goal? I'm not saying there are, I'm just saying we should start by studying the problem, not examining particular solutions. Every language feature must be a part of solving a big problem; big enough to justify switching languages. After all, that's is a big deal so we better get it right. So, what big problem are you trying to solve?
[+] [-] frowaway001|12 years ago|reply
I also find it a bit irritating that you love the vague claims like in the last article, but don't like articles with a precise and to-the-point description of issues. It's almost like you want to love all negative articles on Scala, but have to hate even neutral or remotely positive ones, completely irregardless of the quality of the article and the issues raised in them.
It leads to this whole train-wreck of reasoning here which you seem to be forced to post in pretty much every post with the word “Scala” in it.
Nobody can prevent you from spending your time with things you hate, but from my experience, live is happier if you spend it on things you love.
I can't say it any better than dancapo said it here: https://news.ycombinator.com/item?id=6844600 Maybe you should really at least try to consider the points he raises.
[+] [-] kitd|12 years ago|reply
https://code.google.com/p/frege/
[+] [-] toolslive|12 years ago|reply
"Even F# simply isn't powerful enough (never mind OCaml)" evidence, please?
[+] [-] frowaway001|12 years ago|reply
[+] [-] edem|12 years ago|reply
[+] [-] babawere|12 years ago|reply
[+] [-] girvo|12 years ago|reply
[+] [-] CmonDev|12 years ago|reply
[+] [-] octo_t|12 years ago|reply
There's plenty in Scala that other languages do better, the author's claim is that no languages puts all of its features together better than Scala.
[+] [-] Grue3|12 years ago|reply
[+] [-] Horusiath|12 years ago|reply
[+] [-] banachtarski|12 years ago|reply
[+] [-] cosmicvisitor|12 years ago|reply
[+] [-] zs0H|12 years ago|reply
[+] [-] dallagi|12 years ago|reply
[+] [-] adamnemecek|12 years ago|reply
https://news.ycombinator.com/item?id=6829725
[+] [-] StavrosK|12 years ago|reply