Live data from Hacker News

Scala projects are difficult to maintain

mungingdata.com

81–90 of 235 posts

Re: Scala projects are difficult to maintain

#81

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…

Pretty much a noob at FP in general: Wouldn't f# solve the FP and OO integration?

Re: Scala projects are difficult to maintain

#82
post #14

Scala has a Lisp-like quality in that I feel like I should love it. On a certain, 30,000-ft level, I do, but when I'm actually trying to solve a real problem I usually end up just doing it in Java and then "translating" it back into Scala.

I'm curious, what is the lisp like quality? I like scala. I haven't used it for anything big, though. And hard to argue that it has an interesting approach to discipline. Lisp, though, I like to use. I'm not as impressed with myself for getting something working in it. I am impressed that all of my books have code still work.

I think the more expressive language is that quality. Which I believe is the base of the problem. If you have a really professional team then it will make programming even complex programs a breeze. But this same thing is a catastrophe in the hand of average devs. Go’s design was pretty much this (though I prefer a more expressive lang than that). Java while not necessarily an elegant language, I think strikes a great balance between sufficient expressiveness and not-too-many ways to express things.

Re: Scala projects are difficult to maintain

#83
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 didn't run into problems with recruiting in general being too difficult. Plenty of people are interested in FP and are eager to do it professionally. But recruiting the right mix of people can be a challenge. Scala tends to attract people with an experimental temperament, and scare away more conservative developers. A team needs a healthy mix of both, though. It's the creative tension among different attitudes abou…

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.

Re: Scala projects are difficult to maintain

#84
The problem is that functional programming is a really good idea but nobody has figured out (yet) the specific industry applications where it makes possible new things that weren't possible before. Mapreduce was a big win but you can do it in java. Spark was a big win but you can drive it from python. How do you make a better CRUD app in Scala? Serving http requests but with monads is not the answer.

Re: Scala projects are difficult to maintain

#85
I think about scala a bit because the second biggest chess website (lichess) is open source and written in play framework/scala. Was interested in learning some scala to help contribute since I play on the site so often

Wonder if they've run into these issues with the language though

Re: Scala projects are difficult to maintain

#86

Is the Scala language simply too big? I tried to learn it once (years ago) and quickly found myself overwhelmed by the number of concepts. I remember feeling like 80% of power of the language could have been achieved with 20% of the complexity. The latest Java releases are somewhat proving this with functional interfaces and records.

A lot of the problems with Scala echo many of the problems that people used to write about Perl codebases minus specific language quirks like typing and objects. The problem with complex, rich languages is that it doesn't guarantee anything about the wisdom of programmers to pick, choose, and abuse from the features that wouldn't be easily legible to future maintainers.

Somehow Scala has a lot of the issues that I feared would have impacted Typescript by now (yet hasn't) so I'd be interested in comparing and contrast why Typescript isn't perceived as having the kinds of issues Scala does when on paper they sound similar in features and technical challenges.

Having worked on a lot of legacy codebases both creating and inheriting I'm quite interested in practices that balance rapidly prototyping and deploying systems and gracefully degrading when projects lose people and funding. It seems tragic to see so much of the work of our lives thrown away so fast.

Re: Scala projects are difficult to maintain

#87

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…

>We really loved the integration of OO and FP, really miss the FP awesomeness honestly... but simplicity trumps doing either of those things well.

Agreed. I like the Scala language, but I can't imagine a scenario where I would recommend it for a project over Java.

Re: Scala projects are difficult to maintain

#88
post #79
post #15

> Scala can also bring out the weirdness in programmers and create codebases that are incredibly difficult to follow, independent of the maintenance cost. Some programmers are more interested in functional programming paradigms and category theory than the drudgery of generating business value for paying customers. This is the tragedy of Scala. The maintenance cost is bearable. In return you get a language that dares…

To be honest I'm also seeing this with Typescript for example. I have seen some much energy wasted just for the pleasure of using RambdaJS[1] with TS. It's probably even worse than with Scala, because at least with Scala the language is on your side to do FP. [1] https://ramdajs.com/

I've used typescript with lodash/fp (a similar FP library) and I found it to be an absolute joy. Once the team decided to really use lodash/fp for data manipulation, and the basis for composable logic, we really start to move quick.

We came up with our own linting guide, and guidelines for writing extensible and composable code.

I've never coded in Scala, but I've shipped production code in languages that support multiple paradigms.

Conventions are important. Things need need to be agreed upon and done in a certain way or your code base will become a tangled mess.

Re: Scala projects are difficult to maintain

#89

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…

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.

Re: Scala projects are difficult to maintain

#90
post #33

In my experience, it's easier for many developers to blame the tools and language rather than admit the dumpster fire of a codebase was entirely their doing and their responsibility.

A more complicated language needs more skills and more skills mean you are inexperienced in at least some of those skills and inexperience causes dumpster fire codebases.

When I started software development I had "hammer and nail syndrome" for absolutely everything. I figured out something new and then used it everywhere. Experimenting in this way is necessary but you absolutely want to avoid it in a production codebase. Over time you have run out of hammers and nails to play around with. You've developed the ability to judge where and when a specific hammer is most effective and when it shouldn't be used at all. Scala offers you a wide variety of hammers and nails. You'll have to experiment a lot.

Post reply on HN