Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala School

twitter.github.io

Post reply on HN
Print view View original

161–170 of 178 posts

Re: Scala School

#161

Post by airless_bar »

lmm wrote: post #151
eeperson wrote: post #134

Earlier quoted context omitted.

I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE. Also, if you use SBT through Activator[1] you get project templates and an automati…

> I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. Sounds horribly magic/incomprehensible. > This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE. I don't think the work of doing it in M…

Man, you really need to get over your SBT hate.

Maven and Ant are barely maintained anymore despite so many broken things. Just compare artifact resolution/download speed between Maven/Ivy and sbt with coursier.

There is no way in hell I'll ever touch Maven again. SBT works without a single line of configuration, and that IDEs are not able to touch config files is a big fat benefit.

Eclipse developers can't even turn it into a working editor. I certainly don't want Eclipse to deal with my project configuration.

Re: Scala School

#162

Post by airless_bar »

sulam wrote: post #104
airless_bar wrote: post #83

Earlier quoted context omitted.

> the main proponent for one JVM language Hey, I'm interested in that! What proponent? What language? If it was Raffi Krikorian would you mind having a look at https://en.wikipedia.org/wiki/Scala_%28programming_language%... and perhaps update it?

I was not a first party to the discussion, but what I heard is that Alex Roetter had asked the most senior engineers to consider strongly whether or not it would be better to have one JVM language. Twitter pays a polyglot tax and Scala's tool chain is clearly not as mature as Java's. In the resulting discussion, though, even engineers that primarily wrote systems in Java wanted to keep Scala as an option. I had one c…

Thanks!

Re: Scala School

#163

Post by lmm »

airless_bar wrote: post #161
lmm wrote: post #151

Earlier quoted context omitted.

> I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. Sounds horribly magic/incomprehensible. > This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE. I don't think the work of doing it in M…

Man, you really need to get over your SBT hate. Maven and Ant are barely maintained anymore despite so many broken things. Just compare artifact resolution/download speed between Maven/Ivy and sbt with coursier. There is no way in hell I'll ever touch Maven again. SBT works without a single line of configuration, and that IDEs are not able to touch config files is a big fat benefit. Eclipse developers can't even turn…

I'll get over my hate when every setting is documented, every operator is documented in a searchable way (which probably means replacing most of them or writing their own search engine), and build definitions are no longer turing-complete. Until then, Maven's a much better option.

Re: Scala School

#164

Post by lmm »

the_af wrote: post #160
lmm wrote: post #157

Earlier quoted context omitted.

Everything is optional, which is a nightmare for consistency. Using JUnit there's only one style of testing and every test follows it.

You can do what we did in my team: decide on a style of testing and stick to it (in our case, I liked WordSpec). With JUnit you can't do this, because there is only one style. I particularly liked the "should", "must", "where", etc. DSL. If I remember correctly, this style of testing comes from the Rails community. I guess it's a matter of taste, but I would definitely recommend it to newbies.

I wouldn't recommend it to newbies at all, because it's using relatively advanced Scala features - implicit conversions to make the operators available, "word word word" style desugaring into method calls. Of course these are things that you have to learn eventually and that have value, but making a newbie learn how they work before they can test anything is throwing them in at the deep end, and having to use a test framework that you can't understand isn't good.

Re: Scala School

#165

Post by mafribe »

argonaut wrote: post #144
mafribe wrote: post #101

Earlier quoted context omitted.

I have to agree with "lmm" and "the_af" here. You can use Scala as a "Java without semicolons", and indeed that's what I recommend to those who want to learn Scala coming form an OO background. There is absolutely no need to use fancy Scala features like higher-kinds or monadic effects. Indeed, there is no need even to use functional features. Scala is a perfectly fine OO language. The one thing I recommend to learn…

You are advocating that beginners start using Scala without really understanding what they're doing, and being mostly unable to read other code or read the source, while writing what is considered to be bad Scala from the get go. Contrast this to languages like Python or Ruby, where it is totally possible to immediately start writing code you understand that follows the general gist of good Python/Ruby style. You are…

   advocating that beginners start using Scala
No, I was talking about strong Java (or C# or C++) programmers learning Scala, starting with the OO part of Scala. Clearly this is not a large jump, as Scala has class-based OO that is really similar to Java, C# and C++. It is perfectly possible to be productive in this fragment.

Re: Scala School

#166

Post by jinst8gmi »

incepted wrote: post #121
jinst8gmi wrote: post #59

Earlier quoted context omitted.

As someone who's seeing plenty of Scala uptake around me that's a rather surprising claim with no supporting evidence. These days I'm writing 90+% of my code at work in Scala. Indeed.com job data suggests that the answer to your suggestion is an obvious "No": http://www.indeed.com/jobtrends/scala.html

This graph shows that Scala grew from 0.02% market share to 0.08% in the last four years. The fact that it's at 0.08% after more than ten years in existence should be a concern for anyone interested in learning it.

For comparison Ruby is just over 0.3% and has been flat for four years. It's the overall job market, not just programming jobs so all percentages will be low.

Re: Scala School

#167

Post by arkadiytehgraet »

lmm wrote: post #87
arkadiytehgraet wrote: post #69

Earlier quoted context omitted.

What about Kotlin? Its 1.0.0 has been recently released and comes as "pragmatic" Java, bringing a lot of useful features and having more concise yet readable syntax. Also, the Java interop is really good (better than that of Scala, for instance).

The Java interop is worse than that of Scala - Kotlin can't represent Java's variance (i.e. existential types) so it has hacks to avoid it. It doesn't have the maturity or ecosystem of Scala. The "pragmatic" design feels like they took a grab-bag of features from Scala and implemented all the simpler use cases individually, with no appreciation for the underlying coherence; IMO the language will not be able to evolve…

What do you mean by inability to represent existential types? Kotlin has in/out/star projections, which are be used for corresponding Java variance. A note about Scala interop: forget the existential types, in Scala I cannot simply use interfaces with bounded type parameters without some dirty hacks, just because compiler will generate weird errors and/or incorrect bytecode. I am sorry, but this makes it just impossible to work with Java in Scala.

The whole point of Kotlin is that it does not need its own ecosystem - it is intended to be used seamlessly (unlike Scala or Ceylon) and, like, today with all existing Java libraries and frameworks. Sure, more idiomatic solutions would always be nicer to work with (and they would probably appear at some time), but you do not need to wait for them - just go with your existing codebase. As for the tooling, Kotlin IDE support way better than Scala's. It is not surprising, however, due to the fact that main language kontributors are JetBrains.

Re: Scala School

#168

Post by eeperson »

lmm wrote: post #151
eeperson wrote: post #134

Earlier quoted context omitted.

I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE. Also, if you use SBT through Activator[1] you get project templates and an automati…

> I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. Sounds horribly magic/incomprehensible. > This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE. I don't think the work of doing it in M…

> Sounds horribly magic/incomprehensible

How is compiling everything in a given directory any more magic/incomprehensible than any other build tool?

> I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done

What IDE comes with a 'scala template' out of the box? What if you are not already in the JVM ecosystem? With SBT, the set up is:

- Install SBT/Activator

With your suggested equivalent, the steps are:

- Install Maven

- Install IDE

- Install Scala IDE plugin

I think the SBT option sounds like they would be much less imposing for a beginner.

Re: Scala School

#169

Post by incepted »

jinst8gmi wrote: post #166
incepted wrote: post #121

Earlier quoted context omitted.

This graph shows that Scala grew from 0.02% market share to 0.08% in the last four years. The fact that it's at 0.08% after more than ten years in existence should be a concern for anyone interested in learning it.

For comparison Ruby is just over 0.3% and has been flat for four years. It's the overall job market, not just programming jobs so all percentages will be low.

Sure, so this tells us there are about 20 times as many Ruby jobs than Scala ones.

Re: Scala School

#170

Post by lmm »

arkadiytehgraet wrote: post #167
lmm wrote: post #87

Earlier quoted context omitted.

The Java interop is worse than that of Scala - Kotlin can't represent Java's variance (i.e. existential types) so it has hacks to avoid it. It doesn't have the maturity or ecosystem of Scala. The "pragmatic" design feels like they took a grab-bag of features from Scala and implemented all the simpler use cases individually, with no appreciation for the underlying coherence; IMO the language will not be able to evolve…

What do you mean by inability to represent existential types? Kotlin has in/out/star projections, which are be used for corresponding Java variance. A note about Scala interop: forget the existential types, in Scala I cannot simply use interfaces with bounded type parameters without some dirty hacks, just because compiler will generate weird errors and/or incorrect bytecode. I am sorry, but this makes it just impossi…

> What do you mean by inability to represent existential types? Kotlin has in/out/star projections, which are be used for corresponding Java variance

Hmm ok, that does seem to provide equivalent functionality. Is it implemented?

> in Scala I cannot simply use interfaces with bounded type parameters without some dirty hacks, just because compiler will generate weird errors and/or incorrect bytecode

Example? I've never seen that happen and I've done a fair bit of mixed Java/Scala.

> The whole point of Kotlin is that it does not need its own ecosystem - it is intended to be used seamlessly (unlike Scala or Ceylon) and, like, today with all existing Java libraries and frameworks.

Scala was intended for that at first. It turned out to be a bad approach. Interfaces are important, library APIs have a surprisingly far-reaching impact on the code that calls them.

> As for the tooling, Kotlin IDE support way better than Scala's. It is not surprising, however, due to the fact that main language kontributors are JetBrains.

That one specific tool perhaps. In terms of the much larger ecosystem of third-party JVM tools, Scala support is naturally more mature.

Post reply on HN