Scala – The Simple Parts
slideshare.net
slideshare.net
For 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:
quicksort=: (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)
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.
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...
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.
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)
}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.