Live data from Hacker News

Scala projects are difficult to maintain

mungingdata.com

61–70 of 235 posts

Re: Scala projects are difficult to maintain

#61

I am really a beginner of both Scala and functional programming. I took the first Coursera course on Scala, and I got really frightened when I noticed that you can express many things in either the functional or in the object-oriented paradigm. One example is pattern matching vs. polymorphism. When you mix up those ideas throughout your code base, it might become really hard to understand. This is just a thought that…

FYI this is known as the "expression problem" https://wiki.c2.com/?ExpressionProblem

Re: Scala projects are difficult to maintain

#62
I've been on C# for over a decade and I'm still very happy with it. I think it's highly underrated in the startup space.

When helping start my current startup, one of the founders asked why I chose C# as he was asked by others why we'd pick that language/stack as it's not common for SF startups. I told him that it's less about the language and I could do just about anything with it. It's turned out great and of all the things to worry about, the language hasn't ever come up again.

Re: Scala projects are difficult to maintain

#63

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.

There are certainly folks that argue the language it too big. Here's a great talk arguing that a lot of language features should be eliminated and Scala should be made a functional programming language: https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=...

I'm personally in the camp of "keep Scala huge and weird and multi-paradigm, but just make less breaking changes and focus all efforts on making the ecosystem more stable".

Re: Scala projects are difficult to maintain

#64

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)

Maybe the best approach is using a language with dynamic types ? (e.g: cloujure)

Re: Scala projects are difficult to maintain

#65
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.

fentanyl is 50-100x more potent than morphine. Its still the user's fault for overdosing, but overdosing is easier to do with fent.

Pepsi is more potent (sugar) than an apple, easier to get fat. Still the consumer's fault.

My point is the choice of language may require more energy to enforce better code practices. Scala is so feature packed that it makes it easy for a developer to... overdose.

Re: Scala projects are difficult to maintain

#66

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.

I've been at a Scala shop for just over a year, and it's certainly the case that there's a lot of overlap between language features. Personally I prefer having to make judgement calls as needed, rather than being shoehorned into a one-size-fits-all approach (e.g. like Java's class-based, single-inheritance OOP).

One thing I find encouraging is that Scala features may become deprecated (either explicitly or de facto) if an overlapping feature is added that works 'better'. Examples I've come across are Manifest getting replaced by TypeTag and implicit coercions getting replaced by implicit classes.

Re: Scala projects are difficult to maintain

#67
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.

It may be reasonable to think however that some technologies are more conducive to dumpster fires than others.

Re: Scala projects are difficult to maintain

#69
post #34

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 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 about how to write code that yields the best work in the long run.

Re: Scala projects are difficult to maintain

#70
post #5

I have only marginal experience with both but.. isn't this the case also with java nowadays?

Not quite, java binaries are backward compatible (but they are not forward compatible). This means that as long as your runtime and build binaries stay relatively recent (by that I mean java 8 and up at this present date), you won't get any compatibility problem.
Post reply on HN