Live data from Hacker News

Scala – The Simple Parts

slideshare.net

41–50 of 52 posts

Re: Scala – The Simple Parts

#41

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 longe…

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…

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.

Re: Scala – The Simple Parts

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

Re: Scala – The Simple Parts

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

Re: Scala – The Simple Parts

#44

Earlier quoted context omitted.

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 Ru…

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

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.

Re: Scala – The Simple Parts

#45

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 longe…

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.

Re: Scala – The Simple Parts

#46
post #5

Earlier quoted context omitted.

I don't think that's true at all. There are plenty of "bad" languages that have become popular.

The language features for making it big are realistically: - 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 "go…

That's a really loose/convenient definition.

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.

Re: Scala – The Simple Parts

#47
post #24
post #8

Earlier quoted context omitted.

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

I wish they would get rid of CanBuildFrom

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.

Re: Scala – The Simple Parts

#48
post #40

Earlier quoted context omitted.

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…

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

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.

Re: Scala – The Simple Parts

#49
post #28

Earlier quoted context omitted.

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 m…

Humans read by the word, not by the individual letters. + vs add() is not a real cognitive burden. Btw what does the operator ~ do in scala?

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)

Re: Scala – The Simple Parts

#50

Earlier quoted context omitted.

Humans read by the word, not by the individual letters. + vs add() is not a real cognitive burden. Btw what does the operator ~ do in scala?

I'm not sure what you mean by word, but + vs. add() definitely have different levels of cognitive burden: Compare: (a + (b + c)) + d vs. add(add(a, add(b, c)), d) One is arithmetic, the other is polish notation.

Even polish notation benefits from +, IMO.

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

Post reply on HN