Live data from Hacker News

What's Next for Scala

lihaoyi.com

151–160 of 203 posts

Re: What's Next for Scala

#151

Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted. First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists. Second, the entrance level remains…

I was asked to join a team of scala developers. Most except one had started learning about 6 months earlier. I was asked to learn it while making small contributions to the project. I quickly found out that there were statements that could be interpreted in multiple ways, can't remember now what it was. Then I got stuck on something and even our seasoned very enthusiastic Scala developer could not solve it. I then and there decided not to pursue learning the language and quickly have myself transferred to another team. It's a difficult language, one should not spend thinking on the language but spend time thinking about the problem itself. Probably what I say is not doing justice to Scala as I was just a newbie but I did not have those problems with Clojure which is another not that mainstream language.

Re: What's Next for Scala

#152
post #104

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…

Interesting you refer to C++. Both languages, IMHO, became too big to be practical. You need to, as a team, choose a subset of C++ (or Scala) and a style for it to become manageable. I dont think this looks good on a language, I prefer a language that comes with a small, concise set of features that are broadly understood and applied. But different folks different strokes.

To me, the question is who is allowed to make the choice?

Is it the language designer's place to say what can or cannot be done with it or the person/team who chooses what they do with it?

Personally, I would rather work with programming languages which allow me/the team to choose. YMMV.

Re: What's Next for Scala

#153

Earlier quoted context omitted.

I would disagree here. Scala's language spec is smaller than javas, it's problems are akin to Lisps. Too many dsls, extensions and so on. It really opened the doors for FP concepts to go mainstream. Unfortunately, some people went way too far with it.

Brainfuck's spec fits in one page. As does Whitespace's spec. These two languages are impossible to write code in because of their complexity. It's completely mystifying to me that even today, Martin still uses the "spec size" argument in his keynotes to attempt to demonstrate that Scala is a simple language, and it demonstrates a complete ignorance of what language design actually is, or a troubling disingenuity mea…

The intention should matter. Brainfuck's is self descripted. I can come up with a few things that are genually confusing about scala, like implicits resolution rules and quirks of the type system, but I cannot claim they are intentional, and they are getting fixed. On the other hand, having things like functional collections futures years before Java made life easier for the whole lot of us

Re: What's Next for Scala

#154

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…

> Martin Odersky is for me in the top three language designers of our time I don't know about that. To me, the criteria he uses to allow incorporation of features in both Scala 2 and Scala 3 is "Will this feature allow me and my students to apply papers for conferences and fund my PhD students?". Language design seems to have very little to do with that. As long as you can derive multiple papers to multiple conferenc…

That sounds like an accusation. Could you back it up by something, perhaps examples?

Re: What's Next for Scala

#155

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…

I always thought scala native to be a bit of distraction after graalvm went mainstream. Don't know why people do not like working with language that can combine better parts of Java Haskell Ruby and Erlang. Having said that, Scala is Scala, and people who are writing Haskell or Java code in Scala certainly not writing Scala

> people who are writing Haskell or Java code in Scala certainly not writing Scala

For me, one of the joys of Scala is that you can use different paradigms and mix them up as convenient. Haskell Scala is still Scala and so is Java Scala!

Re: What's Next for Scala

#156

I very recently (about a year ago) joined a shop that is primarily into functional programming (FP) and I got my first exposure to Scala as well as F# through work projects. As a long time user of Java/OOP here are my thoughts on Scala and why it has so many things things going against it. Consider the following: 1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis pu…

Agreed. I switched from scala to python and oh man what a relief. Scala is a heavy weight languange. By heavyweight I mean, 1. Even intellij struggles to figure out the meaning of implicits in the given context. And then there are macros. 2. Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid. There is always a nagging feeling that you don't 'get it' when you program in sca…

> I switched from scala to python and oh man what a relief.

I did a bit of Python, then did a bit of Scala, and now do both at work. Oh what a pain Python is! And what a joy Scala is!

> Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid.

Concepts are theoretical in their nature, aren't they? Perhaps these concepts are useful and you just haven't yet found out why?

Wrt feeling stupid, there are two possible reactions: "gee, I'm not so smart" and "whee a learning opportunity" - I'll prefer the latter anytime.

> There is always a nagging feeling that you don't 'get it' when you program in scala

Yes I have that too - so much more to learn!

Re: What's Next for Scala

#157
post #81

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…

Unfortunately, I slowly got frustrated reading the what's coming for Scala 3. * True intersections and union types -- use them sometimes, not something you can't live without though. * Trait parameters -- slightly easier life for OOP, ok I guess. * Function types and implicit function types -- right, will make your code even harder to read (subjective). * Generic tuples -- again, I can't remember we ever had problems…

Yup. I jumped ship for Swift a while ago.

Re: What's Next for Scala

#158
post #127

Earlier quoted context omitted.

I've done the same by being lazy, mainly treating it as a better Java and only learning new stuff when necessary or obviously beneficial. I want to write good programs, not fancy code. My advice: - Options, immutability, pattern matching, and list comprehensions are all awesome and better than the default Javaesque way - Scala concurrency abstractions all better than Java, but concurrency is still hard. Proceed with…

OK, here's my question then. You're embracing Option type and yet presumably avoiding monads, applicatives, and functors (avoiding "FP-crusader stuff"), right? So what happens when you are dealing with multiple option types, like you two optional ints you need to add together? Or you have an optional field in an optional object? This happens all the time in code that heavily uses Option types. So do you match on ever…

For comprehensions should alleviate the examples you have given with regards to readability.

Although yes there are other more complex instances in which nested matches might come up. Generally I would think to handle them by creating a function that contains the next layer of matching instead of trying to come up with an uber function. Adds a bit more verbosity perhaps but I find it is fairly easy to follow and show intent.

Re: What's Next for Scala

#159

> It's not Clojure-dead It never ceases to amaze me. Almost every single time, whenever there's a post or a comment on HN that mentions Clojure or Clojurescript, there's always someone from outside of the Clojure community attacking the language, saying things that are simply untrue. Like people are afraid of it becoming too successful. It's not some zero-sum game - the success of one language ecosystem doesn't mean…

Hmm, I don't like the concept of talking about a programming community as e.g. "python people" in combination with stating something on their behalf.

Re: What's Next for Scala

#160
post #81

Earlier quoted context omitted.

Unfortunately, I slowly got frustrated reading the what's coming for Scala 3. * True intersections and union types -- use them sometimes, not something you can't live without though. * Trait parameters -- slightly easier life for OOP, ok I guess. * Function types and implicit function types -- right, will make your code even harder to read (subjective). * Generic tuples -- again, I can't remember we ever had problems…

Scala 3 could improve on 2.x struggles with supporting JDK 9 and up: Support features of JDK 11+ https://github.com/scala/scala-dev/issues/139 Support Java Module System https://github.com/scala/scala-dev/issues/529 In comparison language features seem to attract much more attention: Removing existential types https://contributors.scala-lang.org/t/proposal-to-remove-exi... Significant indentation syntax https://githu…

That is a good example why betting on the platform languages is always a long term safer bet than betting the house on guest languages,

Eventually they won't keep up with the underlying platform.

Post reply on HN