Scala – The Simple Parts

http://www.slideshare.net/Odersky/flatmap-oslo-presentation-slides?1m0rTry

40 51 12 years ago

ryanobjc9• 12 years ago

From most of the people I talk to, they rarely complain that scala sold out to industry, but instead talk about how complex the language is.

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.

ch4s32• 12 years ago

I think achieving PHP or Java levels of adoption is as much about timing and serendipity as it does language features.

ryanobjc9• 12 years ago

One is a prerequisite of the other though. That much is undeniable.

wmhtet• 12 years ago

Java(blue collar language http://dfjug.org/thefeelofjava.pdf) is easy. Scala is not(http://blog.goodstuff.im/yes-virginia-scala-is-hard). (I am a Scala fan.)

camus2• 12 years ago

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.

programminggeek3• 12 years ago

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.

ryanobjc9• 12 years ago

I'm gonna sound like a weirdo, but I still like Java, especially Java 8, and IntelliJ.

lmm4• 12 years ago

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).

dkhenry• 12 years ago

The presentation is much better in person.

cfeduke• 12 years ago

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.

pjmlp3• 12 years ago

I agree, if one can afford to be in a company that gives some freedom about which tools to use.

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.

eranation• 12 years ago

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/)

ryanobjc9• 12 years ago

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.

virmundi2• 12 years ago

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.

jiaweihli3• 12 years ago

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 }

lmm4• 12 years ago

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.

runT1ME• 12 years ago

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?

Dewie• 12 years ago

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.

jeffmax• 12 years ago

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.

programminggeek3• 12 years ago

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.

SkyMarshal• 12 years ago

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.

platz3• 12 years ago

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)
	}

pjmlp3• 12 years ago

My only issue with Scala is that I prefer the ML syntax more, given that my first FP language was Caml Light.

tonetheman• 12 years ago

Pretty much if there is a slide with a title "Why not use a Monad?" then this is not the simple parts.

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.

virtualwhys• 12 years ago

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...

Scala – The Simple Parts

Related Stories