Right, I think people forget that Java essentially aimed to be a vastly simplified version of C++ with garbage collection and memory safety. This was something a lot of people were crying out for at the time. There were some bad decisions in early Java (making data structures synchronized by default, lack of generics), but it's got to the point now where it's pretty good at what it's intended to be.
Yeah I think Java was the right(enough) solution at exactly the right time. I write some Java, but can't say I've ever really enjoyed it. Scala feels, well just more interesting to me. But it isn't easy.
I started out with ASP2 BTW so I managed to skip cgi.
I wouldn't argue that Scala is going to be The Next Big Thing. I think the industry is large enough that there isn't going to be one. At least not for web development. Everyone prioritizes something different.
I find Scala a really consistent language though. Which fits my own personal definition of "simple" well enough. Much more so than say, Ruby. Where even "truthiness" is somehow a vague concept.
The underscore in Scala for example is, when you grok it, actually a really simple concept. So is map/flatMap/filter. So for-comprehensions. And Extractors/Pattern-Matching. It's all a bunch of orthogonal, simple features that together are greater than the sum of their parts.
IMO.
Depending on if you've run into the issues Paul Phillips highlights in scala.collections you might find some fault there. I haven't personally beyond the fact that for me, CBF might as well imply a sealed class and custom collections are something I tend to avoid (that wasn't true of c#).
That's a tangent though I suppose. Just the same, the argument was features as a prerequisite for timing. And while there's some obvious truth in that, considering previous examples, just about any modern language would meet that challenge.
I write Scala production code on a daily basis and I've never had to even look at CanBuildFrom. I know it's there (I remember the API docs before they started hiding things), I just never have to deal with it.
I know it's a common complaint, it's just one that's never impacted me in the real world. Never comes up.
A majority of PHP users are not devs and just know enough to upload files on a server or tweak Wordpress.There is not that much serious PHP "engineers".
Anyway,it's great Scala choosed the JVM because it can be part of the stack of any business that already relies on it.That's what matters IHMO.If it is not fit,one can still switch back to java and still use the jar developped in scala or exploit java libs.
Mass market programming languages are built on the back of "non serious engineers" as you call it. PHP is big because it is legible and works for literally 10 million "not serious PHP engineers".
Ridiculing the funnel of people into engineering is insane. This comment alone is the reason why 50 women didn't go into CS this week.
It has been proven that anxiety about not "knowing enough" or being "good enough" at programming is keeping women out of CS. By segregating students into ability levels, one college was able to get enrollment up to 42% in CS:
Considering how important programming is becoming, how many aspects of our lives are ALREADY controlled by code, your "suited for another field of endeavor" comment just makes no sense.
There is a lot to love about Scala, but one of the hurdles is/was the compile time. I used Scala and I didn't love the tooling around it. Even installing and running scalatra, I felt like it was maven installing THE WORLD, just to build a very small thing. Then, once I got it going to have a very simple change, save, refresh to see changes loop in my web workflow was like 3-10 sec. Not huge, but I'm used to PHP or Ruby dev with instant refresh cycles. Then on the TDD side, it would take upwards of 10 seconds to noticed that files had changed to run my test suite in SBT. Again, I'm used to < 1 second to notice a change and run my entire test suite in ruby.
I'm not sure if that's Scala's fault or Scalatra or SBT, but no matter how I sliced it, as of 9 months ago or so, Scala didn't feel amazing to develop code in. Everything felt a bit clunky. The code itself I loved, but the way I got there felt worse.
Surprisingly when I tried Go, it was a much better developer experience in terms of the near instant compile, refresh, see change loop and also running tests was nearly instant. The "instant" feeling I get in PHP and Ruby was there, but in a compiled language. However, in Go, I don't have some of the functional and immutable concepts that I have in Scala, which sort of sucks.
At the end of the day I'm making tradeoffs somewhere and it doesn't feel awesome anywhere. I might check out Facebook's Hack simply because it offers type checking, performance, and fast refresh. Also maybe the latest .NET stuff announced with continuous compile might bridge the gap for C#. I really don't know.
I have yet to find the language that really feels amazing as a developer in sort of all areas. Every language seems to have baked in tradeoffs.
On the JVM I like Scala and Clojure more than Java, but I am realistic and know that those languages are only available to me for hobby projects, given how the enterprise works.
It's remarkably uncool to like Java, but I know what you mean. I did a web app using Play! version 1 and it was a really enjoyable experience, even though it was in Java. Also, Android development is not brilliant, but most of that is the emulator's slowness, not the Java language itself.
Also I love IntelliJ or Netbeans both a lot more than Eclipse.
I'm sure there is a Java dev experience that is pretty great, especially if you can pull in some of the functional things from Java 8 and maybe immutable things from guava. I haven't tried that.
I have tried Kotlin and I enjoyed playing with it in IntelliJ, though I haven't done anything beyond project euler problems and some JUnit testing.
I'm using it in industry right now, and my biggest complaint would be along the lines of "it's sold out". I'm very worried that Odersky's talk of "simplifying" the type system will mean removing features that I use and depend on (in my real, revenue-generating applications).
A word of advice: if you move from the .NET platform - C# - to the JVM, then Scala is your language. Java was your language for a very long time, and Java 8 is pretty close, but I still believe Scala is the right choice.
There is a ton of complexity in the type system but you don't need to learn it all at once. If you approach Scala development like you approach C# development you'll go far.
Scala is great no matter what is the "true" answer to the question "is Scala too complex?".
If it's indeed too complex for the mass average developers, then I can use it to filter them out. I got a free way to hire better developers (I don't have to use Scala in production in order to use it in interviews...)
Also if you do find a top developer who managed to master Scala's complexity, then the complexity is no longer a problem, it becomes a benefit, and they use it to create better libraries and APIs for the "regular" developers to use with more ease and type safety.
If it's not complex then I can easily hire any decent Java developer and provide Scala training (I think there is no argument that it's more productive / expressive than Java*, and remember in this "scenario" Scala is not more complex to learn than Java)
Win win
Now the real issue is compile times. If anything itches me toward trying Kotlin is having way too many coffee breaks (http://xkcd.com/303/)
Productivity of a programming language is a tricky bit.
Definitely you can achieve more with less characters in Scala than Java. Are you paying by the character?
For me, legibility and long term readability is the most dominating factor out of any. This is really subjective, but saving on characters you have to type, only to make the code a lot harder to read seems like penny wise pound foolish to me.
And to pull out an expert who agrees with me, Linus slaps C++ around for many of the same reasons. He noted that it's a lot easier to review patches in C because there is no hidden features (eg: operator overloading) that prevent comprehension.
I'm curious to see how Scala matures. Right now the community is really into the FP side. So much so that they want to make everything look like Haskell. So we've got operators and types and nomenclature that doesn't make sense to the average developer. So the developers could mature/advance/become-academic or they could take the good parts of Scala and treat it as Java++. I, frankly, think the second is better.
I'm not sure if it's accurate to say that the community is on the FP side, or if there's just an extremely vocal FP community within scala drowning out all the other scala community members.
This is one of my major grips about Scala, but sometimes I'm also guilty of overusing this feature how you do Google <:< or ~?> or λ. Its even worse when the api you are working against doesn't have a "normal" function for what you are trying to do. It does take a while to remember them but even worst it makes it hard for new users to follow your code. Reminds me of some for a lack of a better work "voodoo" Perl code way back.
A few years ago, this was very much true. The Dispatch lib for doing HTTP requests was particularly guilty of this - you had to learn a whole new mapping of symbols to methods!
I feel Scala is beginning to stabilize now. The recent release of 2.11 fixed several annoying issues, notably thread-safe reflection. The community is beginning to build some substantial and usable libraries. There's a still a long road ahead, though.
That being said, I doubt (and fervently hope against!) Scala will ever become Java++. Scala seems to constantly push the boundaries of language design. This is great, as it results in exposure for some lesser-known concepts into the mainstream developer community (e.g. Scala implicits ~= Ruby refinements).
With regards to language stability - the docs will specifically warn you against highly experimental features (e.g. macros), and for many you even need to explicitly import something to enable them.
The type system is very much rock-solid. Scala doesn't force you to use co/contra-variance or higher-kinded types, but they're there should you need to write very theoretically sound or extensible code.
Yes, you're always paying the character: each character increases mental load on the developer - either through code complexity (https://github.com/scalaz/scalaz) or just the sheer amount of code (would you want to code everything in assembly?).
Leaky abstractions, as you mentioned, result in unclear code.
On the other hand, well-designed and easily understood abstractions reduce complexity.
Take for example, the atrocious lambda 'hacks' needed before Java 8 - create an anonymous class, then override a method. Compare that with something like words.map { _.size }
People think in terms of hierarchy and concepts, not individual components. For example, cars with more internal components are not actually more difficult to DRIVE than simpler cars (eg: carburetor vs fuel injection).
Likewise, people don't pay by the character. They pay by the word. They also pay by the concept, so having N different ways to do something simple can be a higher cognitive burden than just 1 way. (hence python vs perl).
Now, I believe that clear code, "well designed" code (despite the fact that its patently obvious that no one agrees on what well designed actually MEANS) are better. Good abstractions.
But these are a function of the programmer from which they come from. The programming language makes a difference but I'm starting to suspect beyond a certain point of feature completeness, you are hitting diminishing returns then negative returns. Yes Java8 has Lambdas, that helps a lot. But would Java9 benefit from implicit parameters? Or from nearly any punctuation being an operator that can be overridden? I argue these 2 features of scala, which people love for their ability to build concise, hard to read, harder to write, DSLs are part of the problem.
Ok enough ranting. My parting shot is I write a 25,000 lines of scala into a production system. We had to rewrite ALL the for loops into while loops. In the end, I'd say Scala was generally helpful but not so much that I'd do it again.
It's unarguably shorter than anything you could write in most other languages, but is it more readable?
My point is that, while too many characters are bad, too few are bad as well. And that possibly the "just right" verbosity varies from person to person. And also that readability is completely unresearched topic without any established facts we could argue about... Anyway, the key takeaway: we're all wrong on the issue of readability and we don't even know how much wrong.
I don't pay by the character but I do read by the character. I think there's a huge readability gain in having classes that fit on a single screen, which just isn't practical in Java (if nothing else, because of all the getters and setters that scala's uniform access principle lets you avoid).
I think the focus on operator overloading is misplaced; in C you might not be able to write "a + b" and have it launch some missiles, but you can write "add(a, b)" and have it launch some missiles, which is just as bad. If anything Scala is more predictable and uniform here - "a + b" is just sugar for "a.+(b)", methods and operators work the same way, and the operator precedence list you have to memorize is much shorter than C's.
When dealing with arithmetic equations the cognitive burden of add vs + can be quite high. Not allowing the overriding of arithmetic operators means that all new mathematical code you right will be second class vs primitives, encouraging people to not use special types in math operations. This leads to unit mismatches and other sorts of bugs.
The ~ operator in scala is the same as in java (if it isn't overloaded)
In a well-designed library, it does what it looks like - whatever "~" means in the language of that domain. In a badly-designed library it could do anything. Just like .add().
(It's normal for the same symbol to mean different things in different domains, even in Java. If a and b are BigIntegers, a.add(b) means one thing; if a and b are Wicket components, a.add(b) means something quite different. Wicket remains a respected, well-designed library even though it "overloads" the word "add" in this way)
(Another reply points out that it has the same meaning on numeric types - bitwise negation - as in Java, but I doubt that's what you're asking about)
Ah, but you are comparing line by line or function by function. Is a 3 line scala for comprehension doing simple mapping more 'readable' than a 10 line java loop? Well, depending on who you ask the answer is either "about the same" or "less readable" if they aren't familiar with the idiom.
However, it's pointless to compare methods when we need to be comparing applications. In my experience, I'd say I get about... 100 times reduction in LOC compared to a java application. Not hyperbole, two orders of magnitude LOC reduction compared to java applications.
Now, given that information, does it matter if each particular line takes you three times as long to read? With more type safety to boot?
I don't think anyone is criticizing for comprehensions as unreadable. Implicits in particular introduce non-local effects that may not visible from reading a particular piece of code, and in my experience should be used sparingly.
This is such a strawman. I really doubt that there are a lot of people who favour terse programming languages (or programming practices) only because of how little they have to write - if that was the only concern, they would be happy with a verbose language as long as it had good support for autocomplete and boilerplate generators.
Some people think that terse code is more readable, not just more writeable.
I don't think that a language that is too complex for "mass developers" is necessarily a good test for finding better developers. That assumes that better developers flock to more complex languages.
The slow compile times made me look at Kotlin and so far I like what I see. The web projects in kotlin aren't very mature, but maybe you can use plain old servlets or or some other JVM web framework. I haven't gone down that path with Kotlin yet.
Scala was the first ML family language I learned. I tried to love it, but found I needed help learning it, so I turned to Haskell hoping for a better understanding of some of Scala's type system and other ML concepts. Then I fell in love with Haskell.
Equally complex, if not moreso, and not any easier, but it felt simpler since it focused on a single paradigm instead of attempting to mix two big ones, and the whitespace-enforced readability and uniformity helped reduce cognitive load while learning and working with it. Great performance too, C-like in some cases with expert optimizations, and a range of concurrency and parallelization options.
yep. When I first tasted Scala it seemed great, but the having abstractions that leak less (haskell) is something I really appreciate.
And there's something about Scala using traits for everything that rubs me the wrong way.
Stuff like this I still find odd, mixing abstract classes with functions and inheritance.
abstract class IntSeqBuffer extends SeqBuffer {
type U = Int
}
object AbstractTypeTest1 extends App {
def newIntSeqBuf(elem1: Int, elem2: Int): IntSeqBuffer =
new IntSeqBuffer {
type T = List[U]
val element = List(elem1, elem2)
}
val buf = newIntSeqBuf(7, 8)
}
This is all a preamble to Dotty, the new experimental compiler ("dotc" in the slides), making its way into Scala proper.
When it was first announced some Scalaz core members freaked out on Twitter (due to proposed simplification of the type system), but that died down, apparently the changes won't completely neuter the type system down to that of other JVM languages.
Presumably tooling and build times will improve, along with fewer ways to do the same thing, when Dotty comes on the scene (guessing a couple of years away).
For now, if one makes use of SBT sub projects along with incremental builds in SBT 0.13 (and turns off automatic builds in Eclipse/IntelliJ), one _can_ have a snappy development experience and decent compile times.
Have to learn the ropes though, as with any powerful language, out of the box there are hard yards to get through...
51 comments
[ 0.21 ms ] story [ 80.5 ms ] threadFor truly widespread adoption, I'm talking PHP or Java levels, you need to have a totally different mindset. I don't think Scala is that language.
- how easy is it to understand this language
- how quickly can i do something useful in it?
PHP -> It made it trivial to make active webpages, something that was a disaster in other languages until recently. Do you even remember perl cgi-bin?
Java -> provided a realistic replacement for C++.
BASIC -> People go could from 0 to program nearly instantly.
The "good vs bad" you hint at just doesn't really register on this scale.
I started out with ASP2 BTW so I managed to skip cgi.
I wouldn't argue that Scala is going to be The Next Big Thing. I think the industry is large enough that there isn't going to be one. At least not for web development. Everyone prioritizes something different.
I find Scala a really consistent language though. Which fits my own personal definition of "simple" well enough. Much more so than say, Ruby. Where even "truthiness" is somehow a vague concept.
The underscore in Scala for example is, when you grok it, actually a really simple concept. So is map/flatMap/filter. So for-comprehensions. And Extractors/Pattern-Matching. It's all a bunch of orthogonal, simple features that together are greater than the sum of their parts.
IMO.
Depending on if you've run into the issues Paul Phillips highlights in scala.collections you might find some fault there. I haven't personally beyond the fact that for me, CBF might as well imply a sealed class and custom collections are something I tend to avoid (that wasn't true of c#).
That's a tangent though I suppose. Just the same, the argument was features as a prerequisite for timing. And while there's some obvious truth in that, considering previous examples, just about any modern language would meet that challenge.
I know it's a common complaint, it's just one that's never impacted me in the real world. Never comes up.
Anyway,it's great Scala choosed the JVM because it can be part of the stack of any business that already relies on it.That's what matters IHMO.If it is not fit,one can still switch back to java and still use the jar developped in scala or exploit java libs.
Mass market programming languages are built on the back of "non serious engineers" as you call it. PHP is big because it is legible and works for literally 10 million "not serious PHP engineers".
Ridiculing the funnel of people into engineering is insane. This comment alone is the reason why 50 women didn't go into CS this week.
It has been proven that anxiety about not "knowing enough" or being "good enough" at programming is keeping women out of CS. By segregating students into ability levels, one college was able to get enrollment up to 42% in CS:
http://www.bloomberg.com/video/76028566-harvey-mudd-presiden...
Considering how important programming is becoming, how many aspects of our lives are ALREADY controlled by code, your "suited for another field of endeavor" comment just makes no sense.
I'm not sure if that's Scala's fault or Scalatra or SBT, but no matter how I sliced it, as of 9 months ago or so, Scala didn't feel amazing to develop code in. Everything felt a bit clunky. The code itself I loved, but the way I got there felt worse.
Surprisingly when I tried Go, it was a much better developer experience in terms of the near instant compile, refresh, see change loop and also running tests was nearly instant. The "instant" feeling I get in PHP and Ruby was there, but in a compiled language. However, in Go, I don't have some of the functional and immutable concepts that I have in Scala, which sort of sucks.
At the end of the day I'm making tradeoffs somewhere and it doesn't feel awesome anywhere. I might check out Facebook's Hack simply because it offers type checking, performance, and fast refresh. Also maybe the latest .NET stuff announced with continuous compile might bridge the gap for C#. I really don't know.
I have yet to find the language that really feels amazing as a developer in sort of all areas. Every language seems to have baked in tradeoffs.
Also I love IntelliJ or Netbeans both a lot more than Eclipse.
I'm sure there is a Java dev experience that is pretty great, especially if you can pull in some of the functional things from Java 8 and maybe immutable things from guava. I haven't tried that.
I have tried Kotlin and I enjoyed playing with it in IntelliJ, though I haven't done anything beyond project euler problems and some JUnit testing.
There is a ton of complexity in the type system but you don't need to learn it all at once. If you approach Scala development like you approach C# development you'll go far.
If we are talking about the typical enterprise, with mega projects, having out-sourcing and off-shoring components, then Java is still the king.
Since a few years I am mostly involved in such type of projects and I see how many of such developers struggle with modern programming concepts.
If it's indeed too complex for the mass average developers, then I can use it to filter them out. I got a free way to hire better developers (I don't have to use Scala in production in order to use it in interviews...) Also if you do find a top developer who managed to master Scala's complexity, then the complexity is no longer a problem, it becomes a benefit, and they use it to create better libraries and APIs for the "regular" developers to use with more ease and type safety.
If it's not complex then I can easily hire any decent Java developer and provide Scala training (I think there is no argument that it's more productive / expressive than Java*, and remember in this "scenario" Scala is not more complex to learn than Java)
Win win
Now the real issue is compile times. If anything itches me toward trying Kotlin is having way too many coffee breaks (http://xkcd.com/303/)
Definitely you can achieve more with less characters in Scala than Java. Are you paying by the character?
For me, legibility and long term readability is the most dominating factor out of any. This is really subjective, but saving on characters you have to type, only to make the code a lot harder to read seems like penny wise pound foolish to me.
And to pull out an expert who agrees with me, Linus slaps C++ around for many of the same reasons. He noted that it's a lot easier to review patches in C because there is no hidden features (eg: operator overloading) that prevent comprehension.
I feel Scala is beginning to stabilize now. The recent release of 2.11 fixed several annoying issues, notably thread-safe reflection. The community is beginning to build some substantial and usable libraries. There's a still a long road ahead, though.
That being said, I doubt (and fervently hope against!) Scala will ever become Java++. Scala seems to constantly push the boundaries of language design. This is great, as it results in exposure for some lesser-known concepts into the mainstream developer community (e.g. Scala implicits ~= Ruby refinements).
With regards to language stability - the docs will specifically warn you against highly experimental features (e.g. macros), and for many you even need to explicitly import something to enable them.
The type system is very much rock-solid. Scala doesn't force you to use co/contra-variance or higher-kinded types, but they're there should you need to write very theoretically sound or extensible code.
Leaky abstractions, as you mentioned, result in unclear code. On the other hand, well-designed and easily understood abstractions reduce complexity.
Take for example, the atrocious lambda 'hacks' needed before Java 8 - create an anonymous class, then override a method. Compare that with something like words.map { _.size }
Likewise, people don't pay by the character. They pay by the word. They also pay by the concept, so having N different ways to do something simple can be a higher cognitive burden than just 1 way. (hence python vs perl).
Now, I believe that clear code, "well designed" code (despite the fact that its patently obvious that no one agrees on what well designed actually MEANS) are better. Good abstractions.
But these are a function of the programmer from which they come from. The programming language makes a difference but I'm starting to suspect beyond a certain point of feature completeness, you are hitting diminishing returns then negative returns. Yes Java8 has Lambdas, that helps a lot. But would Java9 benefit from implicit parameters? Or from nearly any punctuation being an operator that can be overridden? I argue these 2 features of scala, which people love for their ability to build concise, hard to read, harder to write, DSLs are part of the problem.
Ok enough ranting. My parting shot is I write a 25,000 lines of scala into a production system. We had to rewrite ALL the for loops into while loops. In the end, I'd say Scala was generally helpful but not so much that I'd do it again.
Not so. A quicksort in J is one absolutely lovely counter-example:
It's unarguably shorter than anything you could write in most other languages, but is it more readable?My point is that, while too many characters are bad, too few are bad as well. And that possibly the "just right" verbosity varies from person to person. And also that readability is completely unresearched topic without any established facts we could argue about... Anyway, the key takeaway: we're all wrong on the issue of readability and we don't even know how much wrong.
I think the focus on operator overloading is misplaced; in C you might not be able to write "a + b" and have it launch some missiles, but you can write "add(a, b)" and have it launch some missiles, which is just as bad. If anything Scala is more predictable and uniform here - "a + b" is just sugar for "a.+(b)", methods and operators work the same way, and the operator precedence list you have to memorize is much shorter than C's.
Btw what does the operator ~ do in scala?
Compare: (a + (b + c)) + d vs. add(add(a, add(b, c)), d)
One is arithmetic, the other is polish notation.
+ + a + b c d
We can also (with mainstream OO syntax) make add infix and it's still ugly:
a.add(b.add(c)).add(d)
Yuck, really? I find that much less readable than "add(add(a, add(b, c)), d)"
I do have to read it backward and build the stack, but that's basically intuitive at this point.
The ~ operator in scala is the same as in java (if it isn't overloaded)
(It's normal for the same symbol to mean different things in different domains, even in Java. If a and b are BigIntegers, a.add(b) means one thing; if a and b are Wicket components, a.add(b) means something quite different. Wicket remains a respected, well-designed library even though it "overloads" the word "add" in this way)
(Another reply points out that it has the same meaning on numeric types - bitwise negation - as in Java, but I doubt that's what you're asking about)
However, it's pointless to compare methods when we need to be comparing applications. In my experience, I'd say I get about... 100 times reduction in LOC compared to a java application. Not hyperbole, two orders of magnitude LOC reduction compared to java applications.
Now, given that information, does it matter if each particular line takes you three times as long to read? With more type safety to boot?
Some people think that terse code is more readable, not just more writeable.
Equally complex, if not moreso, and not any easier, but it felt simpler since it focused on a single paradigm instead of attempting to mix two big ones, and the whitespace-enforced readability and uniformity helped reduce cognitive load while learning and working with it. Great performance too, C-like in some cases with expert optimizations, and a range of concurrency and parallelization options.
And there's something about Scala using traits for everything that rubs me the wrong way.
Stuff like this I still find odd, mixing abstract classes with functions and inheritance.
I tend to wonder why more people do not talk about Eckels book on Scala if they want a more basic intro to the language.
When it was first announced some Scalaz core members freaked out on Twitter (due to proposed simplification of the type system), but that died down, apparently the changes won't completely neuter the type system down to that of other JVM languages.
Presumably tooling and build times will improve, along with fewer ways to do the same thing, when Dotty comes on the scene (guessing a couple of years away).
For now, if one makes use of SBT sub projects along with incremental builds in SBT 0.13 (and turns off automatic builds in Eclipse/IntelliJ), one _can_ have a snappy development experience and decent compile times.
Have to learn the ropes though, as with any powerful language, out of the box there are hard yards to get through...