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

From First Principles: Why Scala?

lihaoyi.com

Post reply on HN
Print view View original

191–200 of 342 posts

Re: From First Principles: Why Scala?

#191

Post by jgwil2 »

jmfldn wrote: post #187
jgwil2 wrote: post #184

Earlier quoted context omitted.

I think people can be good programmers and poor software architects at the same time. Sounds like that's what has happened in this case: brilliant abstractions that are misused and result in a buggy product and less productive team.

"I think people can be good programmers and poor software architects at the same time. Sounds like that's what has happened in this case: brilliant abstractions that are misused and result in a buggy product and less productive team." That's fair. I guess if by good programmer we mean, fluency with the language and algorithms / abstractions /types etc then perhaps they qualify. I really meant something more like "sof…

I would guess that it's mainly a question of experience. When you have smart kids fresh out of school, they are going to be eager to use every tool in their toolbox. Eventually (hopefully) they will develop the wisdom to know when to deploy what.

Re: From First Principles: Why Scala?

#192

Post by [deleted] »

bcrosby95 wrote: post #89
MrPowers wrote: post #50

Earlier quoted context omitted.

In the Spark world, you can use a tiny subset of the Scala features and enjoy huge productivity gains over the other language APIs (Java & Python). Those productivity gains are wiped out as more crazy language features get used. I don't think the super complex language features should be removed. Li's libs do some crazy stuff under the hood, but provide a clean, Python-like public interface. Most devs aren't that goo…

> Lots of folks would love Scala codebases that only use 10% of the available language features and none of the complex frameworks. But, like you mentioned, it's a hard language to use responsibly. Does this have the same problem in large languages such as C++ though? Where everyone thinks there's an optimal subset of the language, but no one agrees on what that optimal subset is?

[deleted]

Re: From First Principles: Why Scala?

#193

Post by zmmmmm »

dbsmith83 wrote: post #2

Scala is nice for doing things with Spark compared to say, Java, but I really think that Kotlin can do just as well. The only advantage Scala has with Spark is the syntactic sugar. Once there is an API for Kotlin (beyond the preview version), I will be dropping Scala like a bad habit. Kotlin is also concise, has better IntelliJ support, less "implicit magic", and better Java interop. https://github.com/JetBrains/kotl…

If only Kotlin would introduce a non-ridiculous way to declare map and list literals it would be a great data science language. As it is, it falls over at the first hurdle where you want to specify some data inline. One reason I've really stuck with Groovy for JVM-based data sciency stuff.

Re: From First Principles: Why Scala?

#194

Post by jgwil2 »

keybored wrote: post #183
brabel wrote: post #140

Earlier quoted context omitted.

I am fairly certain the jury is out on this question: It's always better to write simple, almost dumb code that anyone can understand than to use advanced abstractions from category theory or whatever. Why? Because every single study or anedocte I've ever heard is like yours: adding complex abstractions to code do NOT make it more reliable. But they do make it much harder to modify, understand, and fix. FP tought us…

“Complex abstraction” is a contradiction in terms since an abstraction is a relation A -> B where B needs to be simpler than A.

From the client's point of view that may be true; abstraction should be the process of pushing complexity down. But in this case I think we're talking about code that has inadvertently introduced unnecessary complexity in an attempt to be hyper-generic.

Re: From First Principles: Why Scala?

#195

Post by hocuspocus »

marcinzm wrote: post #185
MrPowers wrote: post #80

Earlier quoted context omitted.

Yep, the Spark codebase is a great example of what a big Scala codebase should look like. Nothing crazy, not too many traits, mainly just "regular functions". Imagine another codebase uses a feature like self-types extensively: https://docs.scala-lang.org/tour/self-types.html A small team has no good way to resolve the argument if self types should be used all over the place or avoided entirely.

> Yep, the Spark codebase is a great example of what a big Scala codebase should look like. A lot of the hardcore Scala community hates Spark which sort of summarizes the situation.

This is a false dichotomy. You'll run into all sorts of pain and frustration as soon as Spark touches your codebase, no matter what kind of Scala you're writing.

Re: From First Principles: Why Scala?

#196

Post by watwut »

jgwil2 wrote: post #184
jmfldn wrote: post #176

Earlier quoted context omitted.

"I'm on exactly that kind of team now. They've been working on a very simple problem for several years now and have an enormous, sophisticated, but still buggy and unstable solution. They're really smart people, and they had to be extremely capable programmers to get this far, but the embarrassing question is, how would a team of mediocre developers have tackled this problem? They would have picked a mediocre languag…

I think people can be good programmers and poor software architects at the same time. Sounds like that's what has happened in this case: brilliant abstractions that are misused and result in a buggy product and less productive team.

Frankly, they are bad programmers. They are smart highly intelligent people who don't have either knowledge or aptitude or willingness to be good programmers.

My pet peeve in this business are supposedly good programmers who get praised despite never having actual results. And it is not like they would be rare.

Re: From First Principles: Why Scala?

#197

Post by zmmmmm »

ebruchez wrote: post #127
mwcampbell wrote: post #20

I dabbled with Scala several years ago, but I've been using Kotlin for a JVM-based project and am happy with it. My main reason for choosing Kotlin is smoother interop with the JVM world. For example: - Scala adds an Option type, whereas Kotlin adds nullability checking for existing object types. - Scala has its own convention for getters and setters, whereas Kotlin automatically turns JVM getters and setters into pr…

> Scala defines its own set of collection classes [...] And that is a huge benefit. Scala collections are really great. In addition , Scala also has wrappers around Java collections for interop, or you can just use plain Java collections directly.

> Scala collections are really great.

It doesn't really matter how great they are, it kills JVM interop right there ... and its even worse if it doesn't and you get implicit conversions killing your performance.

This is where there is a bit of bait and switch with the JVM story (applies to a lot of JVM languages) - "language has great feature X" and "use any library from the JVM ecosystem" - often turn out to be mutually exclusive in a practical sense. Groovy is the only JVM language I've found that seems to deliver a real JVM interop story, but that's explicitly because it is designed from the ground up for that.

Re: From First Principles: Why Scala?

#198

Post by yw3410 »

Fellshard wrote: post #163
dkarl wrote: post #133

Earlier quoted context omitted.

As I am slowly acquiring the habits of thought that make it possible to read and write FP code at a reasonable speed, I'm horrified by how much idiomatic Scala FP code relies on projecting certain assumptions onto types and operations that seem, at first glance, to be neutral mathematical abstractions. For example, I find myself hating the Either type, because I feel like there is a socially established convention th…

I've been working through 'Haskell From First Principles', and it turned on a lightbulb: the 'right' half of Either is the 'important' one because its type variable is free to change. instance Functor (Either a) where -- a is fixed here! fmap :: (b -> c) -> Either a b -> Either a c fmap _ (Left l) = Left l fmap f (Right r) = Right (f r) As a general rule, the last type parameter of a type carries special significance…

This is also the reason we have the convention in Scala as well - the inference to partially apply the type works in a certain way. But I agree with the parent post, a more descriptive name would be better.

Re: From First Principles: Why Scala?

#199

Post by zmmmmm »

merb wrote: post #181
thelittlenag wrote: post #102

Earlier quoted context omitted.

Lightbend is planning to end support and development of Slick? This is the first I've heard of this. Can you point me towards what they've said?

they never said that, but it's basically abadonware. look at the commit history: https://github.com/slick/slick/commits/master you can also look at the contributors page: https://github.com/slick/slick/graphs/contributors the guys who primarly contributed to it basically left lightbend, and in 2019 he shifted his priorities. it only had 28 commits since 2020 (including merge commits and changes to the build process)…

> 28 commits since 2020

wow, the bar for "not dead" is really high these days :-)

Re: From First Principles: Why Scala?

#200

Post by jmfldn »

jgwil2 wrote: post #191
jmfldn wrote: post #187

Earlier quoted context omitted.

"I think people can be good programmers and poor software architects at the same time. Sounds like that's what has happened in this case: brilliant abstractions that are misused and result in a buggy product and less productive team." That's fair. I guess if by good programmer we mean, fluency with the language and algorithms / abstractions /types etc then perhaps they qualify. I really meant something more like "sof…

I would guess that it's mainly a question of experience. When you have smart kids fresh out of school, they are going to be eager to use every tool in their toolbox. Eventually (hopefully) they will develop the wisdom to know when to deploy what.

Maybe the issue is that Scala requires a bit more wisdom that some languages. The problem is that the profession is filled with inexperienced people because of the rate at which new programmers are appearing. In that world you either want safe and, dare I say it, lowest common denominator languages, or you need more hierarchy where senior people take a stronger lead and set the rules. In other words, if you're going to use Rust, Scala, Haskell etc acknowledge the tradeoffs and potential footguns and insist that someone who knows what they're doing, leads the project in a very hands on way. Properly mentored juniors or mid level devs will have that moment of enlightenment where they see the point of these languages and don't just succumb to the blub paradox https://en.wiktionary.org/wiki/Blub_paradox.
Post reply on HN