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

201–210 of 342 posts

Re: From First Principles: Why Scala?

#201

Post by randmeerkat »

thinkharderdev wrote: post #188
randmeerkat wrote: post #157

Earlier quoted context omitted.

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

> Or maybe they take longer and deliver a higher quality product.

Without going into how do you define a higher quality product, does quality really matter that much..? Most code is going to be re-written every few years anyway. Software engineers aren’t building architectural wonders that will last hundreds or maybe thousands of years. So is the complexity of a language like Scala really worth it, just to deliver a product that will be obsolete in a few years anyway?

Re: From First Principles: Why Scala?

#202

Post by hderms »

spion wrote: post #168
jinfiesto wrote: post #121

Earlier quoted context omitted.

You shouldn't swallow errors like that in FP either. You can trap the error in an effect type and throw it at the top level of your app when your effect type gets run after all of the code that processes that error value has a chance to recover. See something like Zio for an example, though you can do similar things without Zio.

And will you get a call trace when you do that?

we use error types that extend Exception specifically for the purpose of getting a call trace. A lot of people hate doing this but it's been extremely helpful on our project

Re: From First Principles: Why Scala?

#203

Post by dkarl »

joshlemer wrote: post #142
yw3410 wrote: post #105

Earlier quoted context omitted.

Yes, it is a side-effect - and does make the code impure; but it's an /exceptional/ flow like OOM, infinite looping, stack overflows which also break equational reasoning. My argument is that as a programmer you /choose/ the base lemmas which you're comfortable with - with an exception you're saying for a large swathe of your code, it will assume a lemma. When is /does/ break you get to point the finger at it with a…

This is spot on! Way too often in Scala codebases, which tend to wrap IO calls in Future or similar is that you'll have chains of side effecting futures like readFromDb() .flatMap(x => doSomethingElse(x)) .flatMap(x => doSomethingElseAgain(x)) .flatMap(x => onceAgain(x)) And this all gets passed up the call stack to one generic thing that basically does nothing in the case of error, maybe logging it and that's it. It…

Amen. I saw exactly the same problem with over-reliance on flatMap, either explicitly or in for expressions, in future-heavy Akka code that I do in cats and cats-effect code.

People love the unifying abstractions underneath these types, and they love developing instincts about how to write code based on them, but from an application programming point of view, their instincts are often counterproductive. I don't think people take a mathematical enough viewpoint. The abstractions can't tell you what is important and unimportant. They can't tell you how your code should be shaped. They can't tell you which values should be transformed further and which should be short-circuited. They can't tell you which values deserve to be given a name for readability and which values should be anonymous.

"All these values are monads, so I can combine them with a for expression" is a meaningless statement of a trivial mathematical fact, not a clue about how you should write your code.

I think error handling code can be written in a straightforward style, but it isn't as pretty as people would like. I think the trap they fall into is holding onto elegance while they reach for correctness, instead of holding fast to correctness while they reach for elegance.

Re: From First Principles: Why Scala?

#204

Post by yw3410 »

rovolo wrote: post #169
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 often handle Either (and Option) using pattern matching when I feel it's important to give both code paths equal importance and equal visibility in the code, but people change it because flatMap is supposedly more idiomatic, and they believe that eliminating pattern matching from their code is a sign of sophistication. Isn't this the same as letting exceptions bubble up in a non-FP language?

Yes - but you /also/ lose the stack trace and it's /far/ too easy to do; hence my OP.

It is /infuriating/ to be knee-deep trying to work out which of your 30 Eithers failed with a non-descript error.

Re: From First Principles: Why Scala?

#205

Post by oldgradstudent »

MrPowers wrote: post #36

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

> The overuse of DSLs in Scala is really annoying.

Unless, of course, that specific DSL is the sole reason for choosing Scala, like with Chisel[1].

[1] https://www.chisel-lang.org/

Re: From First Principles: Why Scala?

#206

Post by esarbe »

randmeerkat wrote: post #201
thinkharderdev wrote: post #188

Earlier quoted context omitted.

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

> Or maybe they take longer and deliver a higher quality product. Without going into how do you define a higher quality product, does quality really matter that much..? Most code is going to be re-written every few years anyway. Software engineers aren’t building architectural wonders that will last hundreds or maybe thousands of years. So is the complexity of a language like Scala really worth it, just to deliver a…

Well, I've been working in financial and data services for many, many years now and I can tell you as much: many of the code bases I've been dealing with (and am dealing with) written in less strictly typed languages (much Python, lots and lots a lot Java) are riddled with hidden runtime errors that you'll just never see in Scala.

If there's a bug, it's usually some modelling problem or some conceptual issues, not the implementation of the code. I've much more confidence in the code I've written in Scala than the code I've written in Python or Java and I never ever had to get up and pick up the phone in the middle of the night because some production issues with code written Scala.

Re: From First Principles: Why Scala?

#207

Post by facorreia »

watwut wrote: post #196
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.

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.

True, and with people switching jobs every 12 to 24 months (at least in the Bay Area) many of them never get to see the outcome of their choices, and don't learn from experience.

Re: From First Principles: Why Scala?

#208

Post by dkarl »

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…

I agree 100%, and I always bring it back to one simple observation that has been true of almost all the projects I've worked on: the limiting resource that programmers work with is their own time and brainpower. To my mind, much of the discipline of programming is centered around making frugal use of that scarce resource.

I still think programmers should work with powerful tools, because "dumb" tools often force you to express things in convoluted ways, and you don't need a powerful language to make a huge mess. (Java proves that you only need single inheritance to produce virtually unlimited amounts of spaghettiness in real-world projects. The difference between Java and Scala is not that Scala enables teams to produce epic piles of FP crap, it's that we long ago stopped being shocked when teams produce epic piles of OO crap.)

I think the programmers doing terrible things with Scala would be doing terrible things in any language, given the chance. What they need is hands-on technical management. When they have a wild idea, they need to be walked through an appropriate engineering decision-making process. They need somebody with the authority to tell them, "Ha ha, yeah, that design with etcd and Kafka and the robot space lasers would friggin' rock, how cool would that be, but on the other hand, we could just stick a REST API in front of a database and you'd be done in two weeks, so let's compare pros and cons."

Re: From First Principles: Why Scala?

#209

Post by desbo »

yw3410 wrote: post #204
rovolo wrote: post #169

Earlier quoted context omitted.

> I often handle Either (and Option) using pattern matching when I feel it's important to give both code paths equal importance and equal visibility in the code, but people change it because flatMap is supposedly more idiomatic, and they believe that eliminating pattern matching from their code is a sign of sophistication. Isn't this the same as letting exceptions bubble up in a non-FP language?

Yes - but you /also/ lose the stack trace and it's /far/ too easy to do; hence my OP. It is /infuriating/ to be knee-deep trying to work out which of your 30 Eithers failed with a non-descript error.

You don't necessarily lose the stack trace. Typically the left side of an either is an Exception (or an error ADT that wraps one). When you want to handle the left case, you can log out the full trace as you would without Either.

The Monad instance for Either means that chaining them together with flatMap has a short-circuiting effect and the first failure will stop the rest of the chain from being evaluated. I find this actually makes it easier to know where your errors are happening, and also allows you to centralise your error handling logic.

Re: From First Principles: Why Scala?

#210

Post by prionassembly »

I want to switch away from Python, at least for personal projects. I want to broaden my range, experiment with weird paradigms (Raku) or get code that’s a little faster (eg Rust).

The problem is that I use Python as a “glue language” and heavily rely on excellent third party libraries. I don’t want to learn how to write a minimum spanning theorem algorithm; I’m used to have it next to several other convenient graph utilities in networkx. There’s so much stuff for Python — where else will you find something like giotto-tda?

I’m not gloating about Python, I feel stuck.

Post reply on HN