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

Scala projects are difficult to maintain

mungingdata.com

Post reply on HN
Print view View original

231–235 of 235 posts

Re: Scala projects are difficult to maintain

#231

Post by hderms »

closeparen wrote: post #156
tootie wrote: post #34

Earlier quoted context omitted.

I only witnessed from the outside, but saw a similar story play out. A client had bet on Scala for a new platform and made it about 6 months in before throwing in the towel and rewriting the whole thing in in Java. It's too hard to recruit and the tooling isn't mature enough.

I thought it was understood that choosing a less popular language meant hiring people for fundamentals and then letting them ramp on on your language. Did the client choose Scala thinking they would just hire "Scala people"?

If you stick to a reasonable middle-ground of scala it really shouldn't be hard to teach. I do like the FP community but that style has gone a long way towards mythologizing scala as an impossible language to teach.

In my experience it's clearly considerably simpler than Rust or C++ to become productive in.

Re: Scala projects are difficult to maintain

#232

Post by hderms »

weatherlight wrote: post #89
dwhitney wrote: post #59

Earlier quoted context omitted.

I think mixing the OO and FP is the crux of the problem. Type inference and subtyping (class based inheritance) don't mix well, and often require type annotations to help the compiler when types get somewhat complex. Eventually you develop an instinct for it, and it's not a problem, but the road to developing that instinct is littered with torn out hair. (edit: spelling)

I have found that languages that support both FP and OO paradigms its best to do things like data manipulation in FP, and use OO to encapsulate those processes and be limited to just passing messages to other objects. Avoid inheritance. Once an object is instantiated, don't change its internal state. etc.

Yes this is the conclusion I've drawn. Often called "FP in the small, OOP in the large".

Higher-level organizational patterns in pure FP style aren't familiar enough to replace the ergonomics of just using a few classes and DI to make things modular. Maybe tagless final or something similar will eclipse it eventually, but for now it seems like using "anemic style" OOP, with functional in the small is still the best we have for mainstream development.

Re: Scala projects are difficult to maintain

#233

Post by hderms »

jdmichal wrote: post #105
weatherlight wrote: post #89

Earlier quoted context omitted.

I have found that languages that support both FP and OO paradigms its best to do things like data manipulation in FP, and use OO to encapsulate those processes and be limited to just passing messages to other objects. Avoid inheritance. Once an object is instantiated, don't change its internal state. etc.

This is my philosophy: Data types are object-oriented. They are responsible for ensuring that their internal state is consistent, and nothing more. They may inherit if it makes sense, but it usually doesn't and most of the time aggregation is more appropriate. Business rules are functional. There's just a bag of composable, pure functions that take the various data types and perform validations, transformations, etc.…

Great breakdown. Seriously, I've had very similar ideas but never tried to build a coherent mapping like this. Thanks for writing it out!

Re: Scala projects are difficult to maintain

#234

Post by hderms »

PopsiclePete wrote: post #114
anthonyskipper wrote: post #20

I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really mi…

> but simplicity trumps doing either of those things well. That's the genius (?) of Go. They gave us what we didn't know we needed. Software people love the "manliness" that comes with "serious", "real" programming languages. Maybe it's the desire to impress our peers with our intelligence? But in the end the only thing that matters is whether you can get your shit done and on time in at least a semi-working state.

I appreciate what you're getting at, but is Go really the epitome of a "get things done" language? It seems to suffer from some serious boilerplate issues even compared to something like Java.

As far as it being driven my machismo, I think that's part of it, but I'd be more inclined to blame it on the following:

* complex languages/mental frameworks function as an "intellectual trap" where people more inclined to be interested in intellectual things for their own sake start to lose site of the forest for the trees.

* FOMO that one must keep up to speed with all the coolest new developments in programming or face mounting irrelevance

* Elitism/self promotion where specializing in something difficult (and potentially keeping newcomers out) either provides internal or external motivation

I think some of these traits seem somewhat correlated with the "nerd machismo" archetype but I think the actual causes are multifaceted. .

Re: Scala projects are difficult to maintain

#235

Post by eternalban »

hderms wrote: post #230
eternalban wrote: post #170

Earlier quoted context omitted.

It is not undefined behavior. Bytecodes are modified via custom CL and superclass was swapped from e.g. Object to something else. As for errors, honestly its been 23+ years so don’t really remember. Naturally you can’t just swap any random class - it has to be correct e.g. can’t have an override method in the child that has no corresponding method in the super. And if memory serves, you can also play this trick using…

I've definitely experienced some scary bugs caused by runtime bytecode injection (from a tracing library). I didn't bother tracking it down further than identifying it was at the intersection of some slightly strange type and the tracing. Caused VM errors when this method was called but only when the tracing was configured. Not saying it's not interesting to experiment with things like that, but there are non-trivial…

I'm pretty sure (but am hedging here :) that you would get any errors in the verification phase of loading a class. What you saw may have been due to bugs in that library you were using.

Anyway, this was before ASM and other bytecode engineering libraries. Today I would not directly hack the class def myself.

Post reply on HN