That's an interesting way to put it (and pretty neat), but I guess I'm not totally convinced it is that useful in practice. I saw the linked example about the parser using implicit objects but I think that could be rewritten in a number of different ways without relying on that feature.
From First Principles: Why Scala?
51–60 of 342 posts
Re: From First Principles: Why Scala?
#52I am a Scala programmer & think it's a great language. Here are some arguments for why not Scala: * Li's libs (os-lib, upickle, utest) have clean public interfaces, but most Scala ecosystem libs are hard to use, see the JSON alternatives for examples: https://www.lihaoyi.com/post/uJsonfastflexibleandintuitiveJS... * The Mill build tool looks a lot better than SBT, but seems like everyone is still using SBT * Scala mi…
> * Scala minor version are binary incompatible, so maintaining Scala projects is a big pain. Upgrading Spark from Scala 2.11 to Scala 2.12 was a massive undertaking for example.
Scala just chose a strange naming scheme. Other languages would have just increased their major version instead. The scala minor version is increased every few years and not every month or so.
> * Scala has tons of language features and lets people do crazy things in the code.
Actually, that's not true. Or rather: compared to what language?
Scala has surprisingly few language features, but the ones it has are very flexible and powerful. Take Kotlin for example. It has method extensions as a dedicated feature. Scala just has implicits which can be used for method extension.
> * Scalatest is stil used by most projects and is annoying to use, as described here: https://github.com/lihaoyi/utest#why-utest. The overuse of DSLs in Scala is really annoying.
I agree with the overuse of DSLs. Luckily that got much better, but older libraries like scalatest still suffer from that.
> * Li's libs (os-lib, upickle, utest) have clean public interfaces, but most Scala ecosystem libs are hard to use, see the JSON alternatives for examples
I think that just comes from using the library in a non-idiomatic way. In most applications, you will need to use the whole json anyways, and then you use (or can use) circe like that:
{
"id": "c730433b-082c-4984-9d66-855c243266f0",
"name": "Foo",
"counts": [1, 2, 3],
"values": {
"bar": true,
"baz": 100.001,
"qux": ["a", "b"]
}
}
case class Data(
id: String,
name: String,
count: List[Int],
values: List[DataValue]
)
case class DataValue(
bar: Boolean,
baz: Float,
qux: List[String]
)
import circe.generic.auto._
import io.circe.parser._
val data = decode[Data]("...").get
data.copy(name = data.name.reverse).asJson
Yeah, that is more code, but as I said, in the vast majority for projects, you need all or most of the fields anyways, so all the structure definition is a one-time thing.The advantage is that the last line is plain Scala code. You don't even need to understand the json-library to do transformations and re-encode into json.
Re: From First Principles: Why Scala?
#53> While most programming languages allow you to take an expression (1213, "moo") and infer the type (Int, String), Scala allows you to go the other direction: take the type (Int, String) and infer a value (1213, "moo")! This is tremendously useful in a whole range of different scenarios That's an interesting way to put it (and pretty neat), but I guess I'm not totally convinced it is that useful in practice. I saw th…
Re: From First Principles: Why Scala?
#54Earlier quoted context omitted.
> Hard to win technical arguments with Scala geniuses that like using complicated language features. I was on a team building good old crud apps using monads, monoids, categories, combinators, effects cats, seamless and bunch of other nonsense that i've now purged from my brain. You could've easily mistaken our team for a programming language research group at a university. This is literally the number one reason i w…
This is my biggest gripe with Scala as well. I'm sure it's a great language, but I've often seen it used to add complexity where none is necessary. It's abused to give developers a sense of accomplishment and intellectual superiority. In fact, in one project my former employer was involved in, one main reason they picked Scala was to, on the one hand, weed out the chaff from their existing team of .net developers (in…
This is scala equivalent of HN/pg lisp folklore.
Re: From First Principles: Why Scala?
#55Scala is just an amazing language. I'm very happy that the worst of the 'Scala as a worse Haskell' days is over and that the Scala community is finding it's own programming style. I remember years ago when I had a heated discussion about local mutable state. An that time it felt like heresy to even suggest it. I just recently had another discussion with the same programmer and he was like: "Yeah, that works". Good ti…
There are beautiful, simple, elegant ways to write Scala, but I'm afraid that the community isn't converging on a single concrete style, and a consensus around an abstract set of ideas about style isn't useful. Everybody agrees on words like "simple" and "elegant" and "readable," but I've seen some real abominations in Scala that people are tragically proud of. I'm afraid that Scala has attracted too many of the wrong kind of programmer, the kind that identifies their professional value with their ability to implement complex solutions that are intractable to their peers. The problem is not that you can't write simple code in Scala, but that people choose not to.
I don't want to blame the pure FP style of Scala itself, because I've seen the same problems in the "better Java" style as well, and because I'm still thinking that I might be able to write good code in this style and might even come to prefer it. But oh man, the Scala programmers I've personally worked with who embrace pure FP have really screwed up priorities.
Re: From First Principles: Why Scala?
#56Scala is just an amazing language. I'm very happy that the worst of the 'Scala as a worse Haskell' days is over and that the Scala community is finding it's own programming style. I remember years ago when I had a heated discussion about local mutable state. An that time it felt like heresy to even suggest it. I just recently had another discussion with the same programmer and he was like: "Yeah, that works". Good ti…
Re: From First Principles: Why Scala?
#57If I've said it once I've said it a thousand times: the day Scala kills sbt officially will be the day thousands of devs consider a return to it. Until then, I couldn't dare.
Perhaps the better way to phrase this is "the day Lightbend deprecates SBT and tells the community to use Mill", but I agree with the sentiment. Scala needs a new "official stack", hopefully Mill + utest/Munit + scalafmt (with opinionated settings). Scala 3 + SBT + Scalatest + whatever formatting isn't going to grab folk's attention.
Re: From First Principles: Why Scala?
#58Great Analysis! I agree that languages are becoming more like Scala. I'm not sure about the JIT part though. Aren't many of the recent language success stories now about AOT compiled languages like Go, Rust and Swift?
A strongly typed language like Scala has the potential for massive optimizations under the whole program optimization umbrella...and no JIT would ever dare to try those types of optimizations, because they are extremely memory and compute intensive. They'd have to pause execution for minutes at a time just to figure out what to do.
I think it is unfortunate that Scala was designed for the JVM first. It brought a lot of syntactic baggage for interop purposes, and it saddled it with weird things like reflection and dynamic class loading, making it hard to statically compile. The ideas behind scala's type system are extremely powerful and could have fundamentally changed programming for the better, but all we got was a JVM me-too that was quickly usurped by Kotlin. I don't think it is dead or a lost cause...but the legacy that the JVM has on Scala is one that slowed it down, not sped it up (like what was claimed would happen with JVM languages).
Re: From First Principles: Why Scala?
#59I am a Scala programmer & think it's a great language. Here are some arguments for why not Scala: * Li's libs (os-lib, upickle, utest) have clean public interfaces, but most Scala ecosystem libs are hard to use, see the JSON alternatives for examples: https://www.lihaoyi.com/post/uJsonfastflexibleandintuitiveJS... * The Mill build tool looks a lot better than SBT, but seems like everyone is still using SBT * Scala mi…
Let's clarify some points for folks not so familiar with Scala. > * Scala minor version are binary incompatible, so maintaining Scala projects is a big pain. Upgrading Spark from Scala 2.11 to Scala 2.12 was a massive undertaking for example. Scala just chose a strange naming scheme. Other languages would have just increased their major version instead. The scala minor version is increased every few years and not eve…
I don't think it's fair to say it like this. Scala's implicits can mean different things, depending on where they're used. Scala 3 even divides 'implicit' to multiple keywords.
(kind of 'static' in C++ I guess, only more complicated)
Re: From First Principles: Why Scala?
#60I definitely agree that many newer languages are strongly inspired by Scala, but I don't see a strong argument for why to choose Scala over one of a newer hybrid language. My own intuition is that these newer languages have had the benefit of being able to learn from Scala's mistakes. A lot of them have intentionally sacrificed some of the Scala's flexibility to be easier to learn and use. I found Scala to be an extr…
That principle is actually directly from the CTM book, which seems to have been a great inspiration for Martin Odersky in the language design.