There are so many problems with Scala, that the question of static vs. dynamic typing becomes secondary. Static typing could well be downright awesome, but Scala is still a mess.
I'm repeating the same line for the third time today, but I find that Scala is for people who find Haskell too simple, and want to add mutability, inheritance and macros on top of it, while dropping safety, purity, and much of the type inference (and I'm certainly not a Haskell fan, but Scala makes Haskell seem like Logo).
For the life of me I can't understand what the language designers want, or how they think software should be written. It seems like they're finding it a fun challenge to see how many features from different languages can fit in a single compiler, and they justify each feature as necessary to solve some arcane problem.
I think it's the complete opposite of languages like Clojure and Erlang (or Java, even), whose designers started by pondering the major issues of software development, and tried to come up with a coherent solution, rather than pile on features, each plugs a specific hole, without any fundamental organizing principle.
> There are so many problems with Scala, that the question of static vs. dynamic typing becomes secondary. Static typing could well be downright awesome, but Scala is still a mess.
Well, gosh, it must be terrible, avoid it all costs!
> I'm repeating the same line for the third time today.
You're obviously not a fan of the language if you find yourself bashing it 3 times in a day, fair enough.
> I find that Scala is for people who find Haskell too simple
Scala is for those that want to get shit done without dealing with Java's endless boilerplate, while still running on the performance beast that is the JVM and benefiting from Java's massive ecosystem. As a bonus you get FP out of the box, so you find yourself, without consciously being aware of it, favoring immutable constructs (map,flatMap,fold, etc.) over imperative mutable boilerplate ridden hacks to achieve the same, thereby, in complete disagreement with the article at hand, becoming a better programmer.
With Haskell you get purity, unhindered FP elegance, and minuscule ecosystem, a language interoperable with...itself it seems.
While it's true that Scala is perhaps overly feature rich, with the to be released 2.11 the focus has been on aggressively stripping out unused features from the language and improving compiler performance.
Following that, perhaps for 2.12, Odersky recently proposed on Twitter a revision of the type system that had FP devotees up in arms since the proposed change removes some of the complexity that makes libraries like Scalaz possible.
At any rate, with Java8 there will be a squeeze in the JVM landscape, alternative languages will be fighting for users as lousy legacy Java is soon going out the window.
All the features you've mentioned (which are the only features 99% of Scala's developers want or use anyway) are found in Kotlin, without the crazy complexity. So occasionally you'll need to cast a reference; so what? Scala doesn't enforce safety anyhow, so why spend so much effort on removing each and every cast?
What you've described is what Scala programmers want Scala to be, or what they use; not what it really is. It seems to me that you've actually described Kotlin.
BTW, I agree that the JVM is a tremendous asset. I develop for the JVM every day and I love it.
Yes, yes, Kotlin, we know, it's wonderful, such an amazing language...that does not yet exist.
The reality is that Kotlin ships a milestone about every 4 months; they're still on 0.6 and the 1.0 release will be a beta release, so we can expect to see Kotlin stable in what, maybe 18 months? That's a long way away when you consider that...
Java8 (arguably the bigger threat to Kotlin than Scala is) will already have launched (looks like Q2 2014 last I checked) and grabbed frustrated Java teams everywhere.
So, Scala trimming down and Java fattening up. Kotlin? A bit late to the party. Java8 will keep existing Java shops intact, and Scala already having made significant inroads into the enterprise, will continue to thrive as _the_ statically typed Java alternative.
My take at any rate, will be fun to find out how it all shakes out in the coming years.
> Scala doesn't enforce safety anyhow, so why spend so much effort on removing each and every cast?
Because then the computer knows what I'm doing, and not just me. Whenever I write a cast, I am assuming I'm smarter than my computer--so smart I never, ever need the computer to check it. This is pretty stupid, because I'm not that smart. (Neither are you.)
> What you've described is what Scala programmers want Scala to be, or what they use
This is a pretty silly line of demarcation. Scala is what people use. So is JavaScript. There's no prescriptive use case for it.
I'd like to like Kotlin, but it wasn't done enough soon enough and I now know Scala intuitively enough that there's no real reason for me to use it. It's just-different-enough from Scala to throw me, while being a step back down the continuum of expressivity. If Kotlin had come out three years ago, it might have grabbed me, but at this point it holds no value to me.
> Scala is for those that want to get shit done without dealing with Java's endless boilerplate
I've always wondered about this argument. Haven't modern Java IDEs more or less automated away the boilerplate?
Using a tool like IntelliJ IDEA or even Eclipse for that matter, I'm really hard pressed to find something that could be autocompleted or generated that hasn't been. They even have views that collapse or otherwise hide away unnecessary verbosity.
Sure, you have a little more code to look at. But frankly, sometimes this can improve readability vis-a-vis excessively concise and overloaded syntax. It can make it easier to grok someone else's code.
I'm not saying there's no difference, just that it's a little odd that this is the NUMBER ONE advantage always cited for Scala vs. Java. Am I crazy?
> I've always wondered about this argument. Haven't modern Java IDEs more or less automated away the boilerplate?
They may automate some of the typing of boilerplate, but that just means the language you are entering isn't the same language you are reading, which is another problem.
The boilerplate is still there, and its still in the way.
> Sure, you have a little more code to look at. But frankly, sometimes this can improve readability vis-a-vis excessively concise and overloaded syntax.
IME, its more often the case that the boilerplate that Java requires makes code hard to read than that the conciseness that Scala permits (but generally does not require) makes it hard to read. And, since the concise options in Scala are generally options, a programmer who is aware of a case where being maximally concise impedes clarity can opt for a more explicit expression, whereas the Java-required boilerplate isn't optional, so even if the programmer is aware of it getting in the way of readability, they can't eliminate it.
> that just means the language you are entering isn't the same language you are reading
I don't think that's true. Your phone has an autocomplete function for text input. You're still typing and reading the same language.
> a programmer who is aware of a case where being maximally concise impedes clarity can opt for a more explicit expression
By the same token, readers are held hostage by the poor decisions of overly concise Scala programmers. This is not theory, it really happens a nontrivial amount of time. You can blame the programmer if you want, but it's a point for Java readability.
> a language that makes clear, concise code impossible
Now you're simply overstating the case. Why?
This is a perfect example of my claim. There is this emotional component to the "Java boilerplate" argument that belies rationality. There is some other unstated reason advocates want Scala and are fitting the argument to that conclusion. Because it's cool? Big fish small pond syndrome?
I think the conciseness can improve readability. Consider these examples:
List<String> list = getListofStrings();
List<String> capitalized = new ArrayList<String>();
for(String st : list)
if(Character.isUpperCase(st.charAt(0)))
capitalized.add(st);
Or...
val list = getListOfStrings
val capitalized = list.filter(_.head.isUpper)
Grokking two lines will take less time than grokking six lines.
Ok, first of all your Java example is five lines not six.
Second, a lot of the concision comes from omitting type declarations. I will argue this decreases the readability of the Scala example.
What kind of data structure does getListOfStrings return? With Java you know with complete certainty that it returns a List of String (and only String). With Scala you have to infer it from the method name and hope it's honest. Likewise with the filter function. Whatever your opinion is of explicit type declarations, they are not mere "boilerplate".
There are certainly other savings in your Scala example apart from types, like the filter lambda function. I'm just a bit incredulous that Scala advocates genuinely think this saves them large quantities of time over the course of a project vs. an IDE-assisted Java version. I mean, how much longer would it take you to write or grok that Java for loop? Seconds? How much longer to do it 100X in a project? Minutes?
There has got to be a deeper underlying emotional reason why people advocate Scala -- which is not to invalidate that reason at all. It's important to feel love for your tools. But be honest about it. It's not about saving hundreds of hours of time writing boilerplate.
Is not about writing the boilerplate, is about having to think at that level. In Java, you think "I loop through the Strings and if it starts with uppercase, I'll add it to a new collection (which I need to remember to intialize)", in Scala is more "filter the strings that starts with uppercase".
And even if the IDE can generate most of it, it still shows it to you to modify the template, and even if later hides it, it still in your code, in your diffs.
Besides, higher order functions are not the only thing, traits are an awesome tool for structuring separation of concerns, and java doesn't come closer.
Sure, if you are excessively habituated to reading Language X and have some kind of barrier to learning new things, Language X will be better for you for most uses. That's not really a feature of Language X, though.
An IDE that could take the first example, then hide it, and then infer what that would look like with more higher order functions (the latter example), and then display that, that would be a truly magical IDE...
Boilerplate code isn't just a problem for the person creating it. It's for the 20 people afterward who are going to be browsing, maintaining and adding new features on top of it. It is also lines of code that serve no purpose.
And even the best IDEs can't help with much of what I've seen in large Java apps.
You are not, but subjectively I move more of my code to Scala, maybe java8 will change it, probably not. It's very much a personal choice. The easiest way is simply to write some code in Scala and get a feel for it.
I prefer Scala because it's working for me, but everyone has different criteria and personal preferences. Go, clojure, Haskell might have more hype, but I tried them in the ultimate test of my productivity, and stayed with Scala. Because of my experience, not because someone convinced me in a comment or post. It's too subjective.
You are either crazy or maybe just not a very good programmer, if you think that tons of boilerplate is no problem because sometimes your IDE can generate / hide some of it for / from you.
Unless an IDE can hide 5 consecutive for-loops and then translate it into the equivalent composition of higher-order functions (with intermediate assignments for readability... but how will a code generator know what's readable) and then display that instead, I don't think that more functionally leaning programmers will think that IDE-generated code and code-hiding accomplishes the same thing, vis-a-vis what they might mean by "boilerplate".
>Following that, perhaps for 2.12, Odersky recently proposed on Twitter a revision of the type system that had FP devotees up in arms since the proposed change removes some of the complexity that makes libraries like Scalaz possible.
What is the proposed change, exactly? Do you have more information?
>With Haskell you get purity, unhindered FP elegance, and minuscule ecosystem, a language interoperable with...itself it seems.
As someone who switched from scala to haskell, I find your mis-characterization rather amusing. The haskell ecosystem is far better than the scala ecosystem. The ecosystem is more than just libraries, and using java libraries in scala is giving up much of the benefits of scala. And scala interoperability has been one of the biggest things everyone complained about, probably not a good choice to criticize other languages for.
>Following that, perhaps for 2.12, Odersky recently proposed on Twitter a revision of the type system that had FP devotees up in arms since the proposed change removes some of the complexity that makes libraries like Scalaz possible.
"Don't worry, they are going to make it 1% simpler by giving up 25% of its expressiveness!" is a pretty terrible sales pitch.
> The ecosystem is more than just libraries, and using java libraries in scala is giving up much of the benefits of scala.
What does that even mean? There's full Java interop, so I just add a dependency on JodaTime and voila, a kick ass library at my finger tips. That is by and large the ecosystem, a massive wealth of functionality, followed by community and tooling (which in Scala is admittedly a weak point).
With Haskell you have Haskell's ecosystem, nothing less, nothing more. So if a Haskeller hasn't developed, for example, a PDF generator to produce client invoices, you're SOL short of writing it yourself.
Scala has a strong, somewhat modernish type system. That protects against many bugs. Java does not. Java libraries can contain code that breaks assertions the scala language makes.
>With Haskell you have Haskell's ecosystem, nothing less, nothing more
Sure. But haskell's ecosystem is miles ahead of scala's. So it is less common to need to resort to using a C lib than it is to have to resort to using a java lib from scala. Yes, tooling and documentation are a huge part of the ecosystem, and scala is pretty awful in that regard.
Haskell's ecosystem is far from all "wine and roses": my few experiences with cabal were not what I hoped to put it mildly, since 2010 I have a yearly yak shaving ritual called "try to install leksah" that only this year was successful, and last time I've tried to install the latest version of the Haskell platform on my Ubuntu box, had to build it form the source manually installing the profiling packages on one by one.
In no way it qualifies as "miles ahead of Scala"
Mutability and inheritance are good solutions to certain classes of problems, and it's valuable to have them in your toolbelt.
What's scala designed for? Programming - not just highly concurrent programming, not just quick scripts to do some text manipulation, not just web services for millions of requests, but all these things and more. It's the most generally applicable language I've ever seen, and there's real value in being able to write your whole platform in a single language which is nevertheless a good fit for a very wide range of problems.
I don't think it's fair to say each feature is piled on to plug a specific hole; rather, a lot of the power of scala comes from the interaction of several features that are individually quite simple. E.g. unlike Haskell's typeclasses which have to be built into the language, in scala that's simply a pattern that you write in regular code. Unlike Erlang's built-in notion of actors, in scala Akka is "just" a library.
> Unlike Erlang's built-in notion of actors, in scala Akka is "just" a library.
So what? In Erlang it's part of the language because Joe Armstrong et al. thought that this is how modern software should be written. They figured they'd need immutability, process isolation, and message passing. In Scala you can do that in a library minus (guaranteed) immutability and isolation, which were the whole point to begin with.
Same for Haskell. They've figured that an unbreakable type-system with functional purity will make it easier to write bug free code. So Scala takes the rich type system (that has its own mental cost), but removes the purity and the safety which are the the whole purpose of the exercise (or much of it, at least).
I could go on and on (with macros, implicits and more), but Scala never fails to miss the mark. It adopts a feature without adopting the philosophy that makes the feature powerful.
> Mutability and inheritance are good solutions to certain classes of problems, and it's valuable to have them in your toolbelt.
Sure, but not if I have to pay the price of such a complex type system, that was designed for languages without mutability and inheritance! Each of these features is good in isolation, but combine them, and you get a mess. Scala is a the pizza-ice-cream-soup-steak-salad. Each has its place, but not as part of the same fucking dish! What is wrong with using one coherent language for one problem, and another for a different one? That's what Scala's designers don't seem to get. They simply have no taste. They're gluttons.
I certainly wouldn't mind the generality if only the mental price I had to pay for it wasn't so high. A lack of guidance is not bad in and of itself - C offers no guidance and no guarantees, and is fit for many tasks - but combined with so many haphazard features and mind-boggling complexity, it becomes a liability rather than an asset. You end up paying the price for each of the features, but reaping few of the rewards. I think programmers are the last people this language is for. In fact, I think Scala is mostly made to amuse its compiler writers.
Scala reminds me of nothing so much as C++. Yeah, you may not want to use what is to you some obscure corner-case feature, but it's 100% certain that you will encounter some code written by someone with a different view of what is and isn't critical. So you need to keep this enormous pile of abstractions and their interactions in your working set, or you're off to the documentation.
I don't entirely see the value in having these "big-tent" languages, where everyone writes their own dialect but imposes that mental cost on all of the other readers. Odersky is clearly a very smart guy, but I'm not persuaded around his way of thinking.
Scala is more expressive than Java-the-language (it'd be difficult to be less so), but that's not the only metric one should use [1].
[1] PLEASE DO NOT READ THIS AS AN ENDORSEMENT OF JAVA-THE-LANGUAGE.
> Odersky is clearly a very smart guy, but I'm not persuaded around his way of thinking.
He is, and his way of thinking, if you watch some of his talks seems to be: sometimes you have this problem, and sometimes that problem. How can we write a compiler that tackles both?
If you listen to Rich Hickey or Joe Armstrong you see something completely different. They ask what the biggest problems facing software developers are, and what philosophy should modern software development adopt in order to face these problems. The features of the languages they've designed directly follow from their philosophy.
I think it is no coincidence that Martin Odersky is a PL researcher (and hence is interested more in sophisticated compilers), while Hickey and Armstrong come "from the field".
It feels off to me because it feels like applying a technological fix (more complicated compilers!) to what is in essence a social problem. Of course tooling has an enormous weight in how people go about solving their programming problems; but the idea that we can fix the effects of e.g. underpricing technical debt or downward wage pressure on programmers simply by creating better tools (and better by which metric?) is -- in my experience -- a fool's errand.
The value for big-tent languages like C++ and Scala comes pretty much from the following factors:
1) There is an existing language that has become widely used in a domain (or a variety of domains) with a well-developed ecosystem, and
2) There are well-known limitations of that existing language for the domains in which it has become widely used, and
3) The existing alternative languages that take conceptually pure approaches to addressing the problems with the existing dominant language have problems making use of the ecosystem that has evolved around that dominant language and/or pose a difficult transition for programmers versed in the dominant language, and
4) The "big-tent" language provides an easier transition for people versed in the language than purer alternatives (by way of more directly supporting the idioms of the dominant language) and has better support for leveraging the existing ecosystem that has grown up around the dominant language.
Ah, but one of the great points of the JVM is that it provides easy interoperability.
So much of being versed in a language is knowing its libraries, but on the JVM, many of the libraries are shared among languages. I use a lot of my Java and JDK knowledge when I write Clojure, and I'm using Clojure when it makes sense and Java when it makes sense.
There doesn't even need to be a "transition" on the JVM, but a gradual, selective use of languages in certain circumstances.
I don't really see Clojure as a particularly "conceptually pure" alternative, but more as another big-tent language like Scala, but one with a syntax less similar Java's (which has plusses and minuses.)
> There doesn't even need to be a "transition" on the JVM, but a gradual, selective use of languages in certain circumstances.
To an extent, that's true on any machine so long as none of the languages interposes its own runtime on top of the machine and the languages use common calling conventions.
But the conceptually pure alternatives to Java pointed out in this thread (like Erlang and Haskell) generally don't run on the JVM. And even when they maybe do (e.g., Erjang exists) they don't provide easy access to the ecosystem.
I don't value purity; I value coherence, and a good sense of direction. I would take JVM interoperability over purity any day, because the value of whatever compromise this entails far exceeds its cost.
In fact, I don't even consider it a compromise because for all their strengths, neither Haskell nor Erlang solve all problems. In that respect Scala is right. Scala is wrong, however, to think that each concept's deficiencies need to be addressed in the same language. It could have worked in theory, maybe, but the result in practice turned out an ugly mess.
I believe in combining forces through a few languages that interoperable over one platform, and the JVM achieves this quite well.
> And even when they maybe do (e.g., Erjang exists) they don't provide easy access to the ecosystem.
Sure they do. Erjang (and Frege, for that matter) support straightforward integration with Java.
In the sense in which conceptually pure was being used upthread for langauges which have a very strong opinion on the constructs appropriate for software development (Haskell with pure functional programming, Erlang with actor-model concurrency), I don't see Lisps in general, including Clojure, as being conceputally pure (there is a kind of conceptual purity there, but its at a lower level and in a sense opposed to the kind of purity at issue here, as I see it.)
Clojure is a lisp, but that's not why it's coherent. It's coherent because it has a clear model of data, state, abstraction and computation. It's not only clear, but (like Erlang) resembles the way people think about the world and about computation.
I'd argue the proliferation of languages for the JVM is the biggest endorsement of Java the language. It is the under-appreciated bedrock of modern JVM programming.
I think this is right. I detest Java-the-language, but it is inextricable from the JVM. Being able to drop down to a simple (less charitably, lowest-common-denominator) language when necessary seems to help with the implementation of more interesting languages.
I'd say just the opposite; there have been more languages for the JVM than for the CLR because Java-the-language is a worse language than C#, so people are more motivated to create replacements.
Oh come on.
I have great respect for Mr.Odersky.
C++ was the language that taught us OOP and helped us make so many abstractions that were otherwise not possible.
Also, C++ is not something that people write not critical software with. The browser that I write this reply is written in C++, or the server that processes this may be written in C++.
Scala is also not something that people write "less serious" code. e.g., Twitter frontend services are written in scala.
Every language has solved some or other problem. It is nothing like someone does less serious stuff with it.
> What is wrong with using one coherent language for one problem, and another for a different one?
Some shops really hate doing work in multiple languages. If designing a language for general industrial use, I'd think long and hard before writing a language that was not at least somewhat sort of decent at everything.
It's not a mess. It's a language in which you can do what you did in Erlang, or what you did in Haskell, or what you did in Java, not because it's taken all their features but because the core language is expressive enough that you can write a library rather than making a separate language. You can shape the language to the problem, not because it's complex but because it's simple. It reminds me of go (the game, not the language) - yes, you can build up these very high level patterns, consisting of dozens of pieces, and sometimes you look at a master's beautiful play and wonder how he ever found it. But the underlying rules are very simple, and it's always possible to take a pattern apart and see why it works.
So you get the expressiveness of a language like perl, or yes, C++; you can write in a huge variety of styles. But you don't get the problem where no-one can read anyone else's code, because underneath it all those styles are using the same language primitives. So even if you haven't seen a typeclass before, you can understand scala code that uses them, because it's just passing an implicit parameter of a certain type. Even if you haven't seen an actor before, you can understand code that uses them, because it's just a library of funny-named methods with particular semantics, and using pattern-matching in a particular way.
Yes, you could write two actors that access mutable fields in another object. Yes, you could write a method in the I/O monad that also calls println. But you wouldn't do these things by accident. In 3+ years of professional scala development (with several quite inexperienced team members) I've never seen a bug caused by inappropriate mutability or inheritance. Yes, it would be nice if the compiler could draw a distinction between pure functions, those that performed I/O, those that modified state, and those that had other kind of effects. But it doesn't seem to be necessary in practice.
Being able to use a single language means being able to use one set of tools, one set of infrastructure (the maintaining of which is often one of the more tedious parts of the job). It means not having to context switch, and not making mistakes because a similar-looking operation means something different in another language. It makes code reuse much easier (yes, even on the JVM - while it's possible to call from one language to another, an API designed for a different language will be cumbersome because it uses different conventions). Ultimately it's just a lot less mental overhead.
The scala scripting is an oft-overlooked feature, and I think it's pretty great. You can compile your codebase into a jar, upload it to a server and link to it from a script in Scala you're editing there in a console text editor. Advantages:
- no compilation required, while still maintaing static typing checks
- since the script is the same Scala language as your main codebase, you can copy/paste code snippets into script for increased productivity
From my experience, it's been great for one-off data processing jobs done on the server.
I think you've hit the nail on the head with Scala. It feels every conceivable concept in language research has been thrown in. The lack of coherency is sometimes quite jarring.
Coherency/conceptual integrity are things I look for in computing environments they make reasoning things much simpler as logical deductions can be made, I don't find myself doing that with Scala.
Your mileage may certainly vary, but having used Scala pretty steadily for the last year, I find the strong majority of Scala code I see in practice generally very easy to intuit. You can do stupid things with it--see Scalaz, which is bad ideas[1] given form--but for the most part, people don't.
I used to have the same concern you're expressing, and a few others besides--I've written comments on HN along the lines of "I'm writing Scala that I can't read the next day"--but I got past that stage not too long afterwards, and I find it remarkably predictable and consistent in everyday use.
[1] - this isn't a fair characterization, see deeper in the tree
Sorry, that was a little more flip than it should have been. Scalaz attempts to wedge into Scala a set of idioms that don't really work well in Scala; as an OO language that's still largely imperative at its core, it's swimming upstream and the code--and the use of that code--is pretty clumsy.
Scala isn't a pure-FP language, and trying to treat it as one doesn't really...work. Square peg, round hole. For me it falls in the "neat hack, but" bucket. That it can be done as Scalaz does is cool, but the practical value of it seems vastly oversold and I'm uncomfortable with the functional-everywhere political viewpoint pushed by some of its leaders (and fortunately Odersky seems opposed to a lot of it, which IMO bodes well for Scala's future).
I think one of the points you're getting at here is that there's many different ways to solve a problem in Scala, versus something like Python. It's definitely true, as can be seen when comparing a codebase like Lift (https://github.com/lift/lift) with Play (https://github.com/playframework/playframework). Both are two MVC frameworks written in Scala but have vastly different coding styles.
The company I work for is a Scala shop, and we've found success in codifying our coding style using the Scalastyle linter. The combination of a linter and peer code reviews has been very helpful for us in figuring out which language constructs and libraries we use and which we shy away from.
You've done a very sensible thing. Yet, I'm pretty sure that most if not all the features you've decided to use are found in Kotlin. I'm not saying you should use Kotlin, as it's not ready. I'm bringing it up to demonstrate that what people want from Scala and what its designers had in mind are two completely different things. What people want from Scala is Kotlin, but what its designers built is a Java-Haskell hybrid with macros.
And there's a bigger problem. Do you shy away from Scala collections? Because I have no idea how the types works there, I didn't want to spend who knows how many hours just to understand how a simple list is coded, and I certainly wasn't going to use something I couldn't understand. So while you may easily understand your own code, I don't know if your team understands this simplest, most basic of libraries.
> For the life of me I can't understand what the language designers want, or how they think software should be written.
From what I've read, that's exactly the design philosophy: we don't know what people will (eventually) want from our language, so we'll be sure to make it very extensible. And so the Scalable Language was made.
Type annotations let you get the shape of the data structure out of your head and into code. The compiler can then ensure that you're using the data structure properly.
Whereas if you're using a dynamic language without type annotations, you need to keep the shape of the data in mind; after that array index, hash lookup, function call, you need to know what kind of thing it is you've got in hand, and what you can do with it. Sure, you write tests to exercise the code and flush out the mistakes, but that isn't as tight an iteration cycle as a compiler - if living in an IDE, the cycle may be as low as a few milliseconds.
And this is the point of the "not a great programmer" comment. Making progress even though you don't have the entire map of the whole program's data structures in your mind all at once.
Having said that, I think this ability to deal with a lot of complexity in working memory can be detrimental to good code, even in typed languages. I've worked with some talented programmers that had an enormous capacity for complexity, but that very complexity made them less inclined to abstract their code. In fact, because they had less need for abstraction, their abstraction skills overall were poorer.
> Type annotations let you get the shape of the data structure out of your head and into code.
This is by far the best argument for static typing I've ever heard. I'm not a big fan of static typing (mostly due to Java). I like Scala, but I think its type system is way over the top.
For the most part, I care about rapid development, and you'll always need unit tests anyway, so they can also test your types for you. And Scala type matching in its builtin switch statements can always get my type back when I get handed an Object. With tools like that, I don't really need absolute type safety.
But getting the shape of your data structures out of your head, that's definitely an advantage.
I agree strongly with the statement the author calls out. Stop believing in yourself and your amazing abilities, and embrace your incompetence. Stop talking about what a great marksman you are, look down at your bullet-ridden feet at long last, and embrace tools that make it harder to shoot yourself in the foot.
This weekend I found a collection of Javascript tests meant to evaluate one's abilities. I spent an hour trying to get the project to run, so I could take the tests, but it was all built on piles of Jello. A bunch of slightly-incompatible versions of libraries and frameworks and shit, so that 3 months after its release I couldn't use it. Stop the madness. Build shit to last and stop using things that make your next 5 seconds in emacs slightly easier at the expense of everyone else.
Maybe it would be better to say, "I'm a pretty good programmer. However, I'm not perfect, and I make mistakes. Static typing helps minimize the mistakes."
The one thing I don't like about Scala is type inference. We spend all that time specifying the exact type of parameters and return values, but then we can just lazily declare an immutable value val, set it equal to a return value of a function, whose signature is in different file, and from a quick glance at the code we can not tell what 'val' is. it might be convenient in the short run, and splits the difference between convenience of dynamic typing and the precision of static typing, but it does so at the cost of readability.
If you feel a particular value needs an explicit type you can always include the type in the declaration. Or your development environment should be able to tell you what type it is.
I do think scala needs an IDE to be used effectively, at least if you're making heavy use of implicits and inferred types (and, as a sibling mentions, indirect imports). But I think that's ultimately a good thing: it uses the power available to us nowadays to allow a more compact representation of code than would be acceptable in a plain text file (which is good for readability - AIUI evidence is that code readability takes a big hit as soon as a function spans more than one screen). Rather than throwing away the convenience of text like the '80s "visual programming" efforts, it's more of a "progressive enhancement".
The type of that value is the type returned by that function. If you want to see what that type is, look at the function. That's not as weird as it sounds. Consider:
int x = foo(2);
What is x? OK, you know it is an "int", due to the redsundant declaration. But that's not useful to you the programmer.
int foo(int n) { return n+1 }
Ok, foo is successor. But you have to look at the definition to remind yourself that. Why not put that in the declaration of x as well?
That's exactly one of my many complains about Scala (and about type inference in general). Type annotations are not there just for the compiler, they also help readability / documentation.
There are numerous places I find Scala has preferred brevity over readability and it does not take long for that choice to take it's toll when you have many people working on a project. Yours is a perfect example. Another is allowing multiple ways of importing such as allowing relative imports. When I've tried to use Scala it's much more of a pain to figure out where some classes are coming from whereas in Java it's immediately obvious from the import at the top of the file.
Scala is the best language out there today for general purpose programming, FULLSTOP.
Many people complain about the complexity of Scala, or how many features it has, etc. Yes, there are some odd features (I am looking at you, native XML support), but these are features I NEVER use. Just learn the fucking type system (it's not that hard, all you need to understand for most of your coding is [A], [+A] and [A <: B] and you are set) and stick to the features you like / understand.
To those who praise the purity of Clojure: That is nice, but comes with a high prize. For example that you have to wait for something like Clojure.Typed, which is already a non-issue with Scala, because Scala comes with BATTERIES INCLUDED. Complaining that Scala has too many features is like complaining that Clojure has too many libraries.
> Scala is the best language out there today for general purpose programming, FULLSTOP.
You have a very narrow view of what makes a good general purpose programming, it's not just about its syntax and its type system.
Scala suffers from a lot of hurdles that make it awkward to use in production and which lessen its productivity:
- IDE support, still very shaky, each new version of the plugin adding new features and breaking old ones, and the plugins randomly refusing to work now and then
- Tool support in general (it's sad that the best build tool is sbt, I was hoping we had learned from ant and maven that we can build better build tools)
- Slow compilation and getting slower at every release (memories of C++ and template linking)
- Backward compatibility still a problem. The compiler is a bit better now but the library story is simply a non starter for most production work
- And overall, the overwhelming impression that Scala is to Java what C++ is to C. It's a very big language that keeps getting bigger at each release, despite Typesafe promising they are working to fix that. They also promised that Scala development would no longer be driven by papers published at conferences, but that's a lie as well.
Also, some influential Scala people have been leaving Typesafe recently, and not in very good terms (e.g. Paul Philips, who was the guy keeping the releases together).
I just have a bad feeling overall about the future of such a language.
IDE support indeed has a ways to go, has improved a ton over the past 2 years, but still far from the rock solid Java IDE experience.
SBT is not simple, particularly for complex edge cases, but once you get your feet wet SBT is really quite awesome.
The notion that Scala compilation gets slower with every release is complete nonsense and is a clear indication of one who is not using the language. Scala 2.10 + SBT 0.13 combined with sub projects (modules) completely obviates the notion that Scala is "slow" since incremental builds are near Java speed (full builds, yes, much slower than Java, but for development, where you spend most of your day, working in Scala is relatively snappy).
Scala is Java++, fair enough, no complaints there.
> some influential Scala people have been leaving Typesafe recently
some is plural, other than Paul P what significant core Scala member has left Typesafe recently? Paul is a compiler addict, he may have "left" Typesafe, but look at his commits, he's still going strong, I don't think the guy can stop, he's obsessed.
> I just have a bad feeling overall about the future of such a language.
OK, leave it to those that use the language: wanting a language to fail is different than watching it succeed.
The IDE support is pretty good, I don't have problems with it. Ask the Clojure people how THEIR IDE support is ... sbt is a great build tool, better than ant or maven, pretty much the best I am aware of for any relevant language. The compilation speed is good enough for me, maybe you should upgrade your hardware. If you have compatibiliy problems, don't move to the new version. Wait until you have your issues fixed. You don't need to upgrade your Scala version immediately just because there is a new one.
As to Paul Philips leaving, what was he responsible for, and what were the "bad terms"?
I have a really great feeling overall about the future of Scala. This feeling is based on my 20 years programming experience with all sorts of languages, and Scala is the best one out there right now. The IDE support and tooling is far greater than for any other language that comes close to Scala. (When you code in Java, even the greatest tooling in the world will not help your productivity).
I've done my share of Clojure programming, and none of the tools you mention are usable in a serious setting. The only stuff I could use (and that was damn hard to set up in the first place, and is "deprecated" for a year now) was an Emacs based solution.
I think sbt is the worst of all the jvm build tools I've used. I'm still learning the scala community but it puzzles me how such a strong community with great leadership and pretty nice tooling (scala-ide) can produce such an underwhelming tool.
I guess "general purpose" doesn't include embedded (robotics, medical devices, etc.), games, systems programming, telecoms, scientific computing and various other disciplines, FULLSTOP.
C++ is a dangerous and unsafe language, so you need to be aware of every little detail. That's why many features in C++ are a problem. Scala runs on the JVM. That and the saner design of Scala makes it much safer to code in Scala than in C++, and what you don't know in Scala, usually doesn't hurt you.
Doesn't that only work if you're coding in isolation from bottom up? As soon as you include some library or start collaborating with someone who likes a different subset, you can't simply stick to what you know.
That might be a good point. You should come to an understanding with your collaborators on the subset you code in. That may be more difficult in an open-source setting.
BUT: This is even exaggerated in Clojure, where you are forced to learn all the little libraries your collaborators use...
I think that typing is useful, but I say that as someone who wrote a bunch of type checking code on top of Ruby to make my boundaries cleaner and more sane. It made my code a lot nicer to work with, but I quickly realized that what I really would prefer is strong interfaces and typing at the boundaries.
Thus, scala, go, java, c++, etc. make a lot of sense to me because you gain performance and stronger boundaries are baked into the language.
I want strong typing because it makes my code better. I want it built into the language because it makes my code cleaner.
I also found his talk fascinating, but the paper he referred to was a bit unapproachable for me. Any suggestions for resources that could help get me more comfortable with reading and understanding type calculi?
Absolutely static typing helps you be a better programmer. No programmer is infallible, and static typing helps you catch a large class of your mistakes sooner -- at the moment you write or compile them, rather than at runtime or never.
The author's reasoning is quite poor. They don't even concretely define what it means to be a "sharp" programming tool.
There is a lot of focus on haskell vs scala and deep intricate discussions about type systems, but here's a question - how is scala as a better java ?
For my purpose (working with hadoop), it has proved to be more than adequate - I get a repl to work with java classes (serious productivity jump over those who have to work with vanilla java), I dont have to muck about with classnames <> filename mapping.
I come from the JRuby world and I have a secret fetish for Clojure - but the near-Java performance of Scala is impossible to argue against.
My biggest, biggest problem is sbt - it is fairly sucky, since it inherits Maven's Madness. Pet peeve - not sure why "sbt console" insists on compiling class files before launching a repl. I mean, I'm launching a repl since something did screw up, right ?
I think Scala can be much, much simpler and better - especially in compiler error messages and tooling. But it is absolutely amazing as a Java replacement.
> Pet peeve - not sure why "sbt console" insists on compiling class files before launching a repl. I mean, I'm launching a repl since something did screw up, right ?
Presumably, your launching a REPL because something screwed up at runtime, not because something screwed up in compilation. You can't kick the tires of how code runs without compiling it, so...
'sbt console' compiles before it launches a repl because it includes your project's classpath. If you want a Scala repl that doesn't have your project's classpath (and hence doesn't need to compile things) start a repl separately from sbt.
Alternately, use "console-quick", which brings up a console with your dependencies on the classpath, but not your actual code.
As a (lengthy) side-note, that name really bugs me. In sbt, we have console-quick and console-project (brings up a console with your build on the classpath). Argh! These are kinds of consoles. They should be quick-console and project-console! Alas, those are the names that Mark Harrah gave us, so they're the ones we have to live with, I guess.
"I am a great programmer and I choose static type systems because I demand sharp tools."
I strive to build correct software, and I leverage a static type system to enforce the absence of incorrect program behavior. Any other benefits are just niceties.
> I am a great programmer and I choose static type systems because I demand sharp tools.
> Of course by taking this position you run the risk of pushing a fallacious, authority-based angle. However, in the weak or strong case you’re already pushing anecdotes around, so you may at least choose the one that is open for objective measurement.
Which part is open to "objective measurement"?
I don't know if I'm a good programmer, whatever that is, but I use static type systems when I want a system to work both today and tomorrow after I refactor it.
These are all very subjective statements, things like "I choose ... because". If you asked 20 programmers why they like statically typed languages, I am willing to bet you will get quite the variety of answers. Personally, I think statically typed languages scratch an itch that is different from programmer to programmer.
Scala transcends the static vs dynamic typing debate via it's duck typing. Because of it's implementation of implicits, you get static type checking along with the flexibility of a language like JavaScript or Python. IMO This puts Scala head and shoulders above the rest of the programming world in terms of language design.
Scala lets you spend lots of time typing incomprehensible type signatures and gives you less type safety than ML-family languages in exchange. Truly it is the pinnacle of PL design!
I certainly hope you don't give me an Object. That would mean I still haven't escaped the JVM! Just give me HM and I can write type safe code without typing types.
> Scala transcends the static vs dynamic typing debate via it's duck typing.
Hardly anyone uses duck typing in Scala (you probably mean structural typing, by the way). There are plenty of articles explaining why structural typing is a bad idea, here is one:
That article explains duck typing badly. In duck typing, you actually test if it quacks like a duck. His example doesn't, and just blindly assumes it can quack.
Is this really a worthwhile distinction? Using the first example from the Wikipedia article on duck typing, I have a choice between exploding when given invalid values:
def calculate(a,b,c):
return (a+b)*c
or failing silently when given invalid values, which will often cause some other piece of code to explode, or at the worst cause some misbehavior that is difficult to detect:
The article is weird. Martin Odersky is an incredibly good programmer, just dive into the source code of scalac, he was probably just being modest to make a point.
I think it is a better way to phrase it anyway. If you say you are an awesome programmer and since you are awesome your decision to use static typing to get you better compile errors and help your development is right, then people can just argue that you suck. But if you say you suck and static typing allows you to suck less, what are they going to say?
It's pretty widely admitted that languages need to help developers suck less to succeed, see Java removing multiple inheritance, operator overloading, etc. and becoming the premier business language. These were power features that made it easy to shoot yourself (and team members) in the foot.
>but I suspect it’s an attempt to counter the idea that strong static type systems like Scala’s are complicated.
Nope. It is simply stating the reason we use typed languages. Because we are human beings, and make mistakes. Having a compiler automatically tell us when we make those mistakes is very helpful. That's it. It has nothing to do with "sharp tools", which untyped advocates also claim their tools to be. It is simply that type systems can find a large number of bugs, at compile time, with 100% certainty.
I'm repeating the same line for the third time today, but I find that Scala is for people who find Haskell too simple, and want to add mutability, inheritance and macros on top of it, while dropping safety, purity, and much of the type inference (and I'm certainly not a Haskell fan, but Scala makes Haskell seem like Logo).
For the life of me I can't understand what the language designers want, or how they think software should be written. It seems like they're finding it a fun challenge to see how many features from different languages can fit in a single compiler, and they justify each feature as necessary to solve some arcane problem.
I think it's the complete opposite of languages like Clojure and Erlang (or Java, even), whose designers started by pondering the major issues of software development, and tried to come up with a coherent solution, rather than pile on features, each plugs a specific hole, without any fundamental organizing principle.