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

181–190 of 342 posts

Re: From First Principles: Why Scala?

#181

Post by merb »

thelittlenag wrote: post #102
joshlemer wrote: post #72

Earlier quoted context omitted.

Nobody should be recommending Slick to anyone for new projects. Slick will not be supported in the future.

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) it's basically dead until somebody steps up.

Re: From First Principles: Why Scala?

#182

Post by davidfstr »

The author argues that dynamic languages like (JavaScript, Python) have Poor IDE and Tooling Support and are Unmanageable in large programs.

I'll counter that if you add a type checker to one of these languages, such as TypeScript (for JavaScript) or mypy (for Python), then all of those problems go away.

I'm personally particularly excited about the possibilities unlocked in the Python community by type checking, which I wrote about recently here: https://dafoster.net/articles/2021/01/26/python%27s-type-che...

Additionally, RE "Poor performance" the author is presumably talking about CPU-bound performance. If you happen to be writing network-based or I/O bound programs, which you always are in JS/TypeScript and sometimes are in Python (for web applications), then the effective performance is more affected by the network/database/disk than the programming language.

Re: From First Principles: Why Scala?

#183

Post by keybored »

brabel wrote: post #140
dkarl wrote: post #74

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

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.

Re: From First Principles: Why Scala?

#184

Post by jgwil2 »

jmfldn wrote: post #176
dkarl wrote: post #74

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

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

Re: From First Principles: Why Scala?

#185

Post by marcinzm »

MrPowers wrote: post #80
lihaoyi wrote: post #73

Earlier quoted context omitted.

> Hard to win technical arguments with Scala geniuses that like using complicated language features. This is an interesting point. Perhaps part of the reason my current employer has been successful with Scala has been that we never were integrated into that part of the community. We hire non-Scala programmers and they write Scala without any training, and it generally turns out OK and ends up converging in a pretty b…

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.

Re: From First Principles: Why Scala?

#186

Post by tikhonj »

dkarl wrote: post #74
dominotw wrote: post #40

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

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

> how would a team of mediocre developers have tackled this problem?

In my experience, mediocre developers would stick to a simple language like Python and only use simple Python features... and write a completely impenetrable, 100% coupled and wholly unreadable mess that would make you wish for over-engineered Scala. Don't even get me started on what happens with "simple" distributed computing tools like Hive...

I see people complain about languages like Scala leading to over-engineering and I just don't get it: have you not worked with sub-par Python or JavaScript code? Sure, poorly designed complex solutions have problems, but so do under-abstracted codebases! Bad code is bad code, and I don't think it's meaningful to say that "over-engineering" is categorically worse than "under-engineering".

I actually worked with somebody who wrote pathologically over-complicated Haskell. Had some friction between us over that. His Python code? Somehow even worse.

No serious language I've seen at either end of the abstraction-friendly spectrum (not Haskell/Scala nor Go/Java/Python/etc) puts a meaningful floor on code quality. An inexpressive language can have a low ceiling for how good code is, but restrict or simplify the language however you like and people will still happily write utterly unworkable code.

I've found that languages—especially less common languages thanks to the "nobody gets fired for IBM" effect—get used as scapegoats for not talking about cultural issues. If people on the team are writing clearly poor, over-complicated and bug-riddled code, it means there is some sort of technical leadership shortcoming, and it would not be any better if they were using Java instead. (I mean, have you seen Enterprise™ Java™ codebases?) And, at the same time, it's clear that a Scala codebase with tasteful technical direction and leadership—conveyed through team culture, code reviews, shared expectations... etc—can be absolutely great to work in.

At this point, I'm leery of blaming languages for programming problems without a clear mechanism. "The language lets people do bad things" isn't a real mechanism because all languages do bad things. "The language attracts people who like complexity" seems specious too. (Again, let's not blame languages for hiring and cultural problems!) "The languages defaults incentivize poor code" is a better argument, although it can be a bit fuzzy. And arguments like "language A doesn't have capability B that we need" or "language C allows classes of bugs other languages don't which empirically cause problems" are the most compelling of all.

Re: From First Principles: Why Scala?

#187

Post by jmfldn »

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.

"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 "software engineer" ie. someone who can architect a simple, sane, working solution adhering to the usual best practices of good software construction. Maybe there's a missing piece between being a good coder vs scaling this knowledge up to the application level. The latter is indeed a much rarer skill and too often, people without it influence major decisions.

Re: From First Principles: Why Scala?

#188

Post by thinkharderdev »

randmeerkat wrote: post #157
thinkharderdev wrote: post #117

Earlier quoted context omitted.

To give them their credit. The argument from the purists is that purity is itself about shipping code. As a long-time scala developer who has started using the pure-FP ecosystem (cats,cats-effect mainly) I am starting to see their point. It takes some time to grok but once you do then it is amazingly productive to work with.

Maybe you’re on an exceptional team, but I’ve never seen a Scala team that could deliver faster than a Python / Ruby / Java team. Scala teams also have a hard time hiring and if they hire a dev that’s new to Scala they then have to deal with a very long ramp up time.

Maybe. I certainly don't have data on it but am also not sure what sort of data would actually prove that point. Teams that choose Scala may just be solving different sorts of problems. Or maybe they take longer and deliver a higher quality product. All I know if that I am personally way more productive in Scala than any other language I've used (and I have used most of them at one point or another).

Re: From First Principles: Why Scala?

#189

Post by jgwil2 »

MikeDelta wrote: post #178
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…

When I was young I though that good writers are the ones who write such complex sentences that nobody can understand. Later I learned that good writers are clear and understandable. I used to write complex code because I found it elegant. Now I write simple code because I enjoy breaking down a complex problem into its simplest form, which for me means I fully understand the problem.

I think the writing metaphor is a good one; we are writing source code for other humans to read after all.
Post reply on HN