[rednum]

Yeah, good luck when someone with experimental temperament decides to implement some of your crucial functionality with semialgebras. (that's what happened in my previous job where we run Scala). I'm happy I didn't have to debug any customer issues around that module. Also, I didn't enjoy constant bickering with my reviewers what makes a beautiful code or not. Apparently there are five ways to do everything in Scala and I always ended up picking not the one my teammates would like the most.

[mumblemumble]

Yes. That's pretty much how the Scala project I was working on ran itself aground. Everyone got so caught up in flexing at each other that solving actual business problems became a secondary priority.

[randmeerkat]

This is why I think the community is way more important than the language. In Python people are like, hmm, this is a hack, but it works for now, in Scala it’s, what have you done you savage?!?

[mumblemumble]

It's also just really weird, when you step back and take a good long look at it, to see people getting worked up about hacky ways of doing things within the context of a language that implemented sum types the way Scala implemented sum types, and that implemented typeclasses the way that Scala implemented typeclasses.

Which, I don't want to be too down on Scala. Overall, I like the language. Scala's real weak point is its culture. There's a decent risk of cognitive dissonance when you try to wrap an ethos of design purity around a language that's always been a bit of a communal experimentation project.

[nowherebeen]

This points to a culture problem more than the language itself though.

[mumblemumble]

Interestingly, when we were working on the Java code, we didn't have this problem. Same people, same time, same git repository, different modules.

[milesvp]

This doesn’t terribly surprise me. Community isn’t just the people but also the customs and idioms within the community. It’s probably similar to ‘code switching’ in verbal languages. People talk (and act) differently depending on who thay’re talking to.

[nine_k]

Were semialgebras a right abstraction, or over-engineering?

What is helpful in situations like this is the motto "as simple as possible, but not simpler". During a code review, if you see something you think is too complex, ask the author: "How could it be made even simpler? If not, how exactly a simpler approach did not work?" It sometimes helps find an overlooked simplification.

[hota_mazi]

> Were semialgebras a right abstraction, or over-engineering?

I think that's missing the point.

The criterion should be: is the code clear enough to be easily testable, easy to debug, and easy to evolve?

I will take a wrong abstraction with the qualities listed above any day of the week.

[nine_k]

This is a good call.

The problem with wrong abstractions, though, is that they do not work, especially when you make the next step on the roadmap.

I would say that clear, testable, evolvable code with little abstraction may be fine. OTOH boilerplate and copy-paste prevents easy or well-controlled evolution. The abstractions end up inlined and fused in the code, instead of being made visible, and become easy to miss a case when a concerted change is needed.