[zie1ony]

I worked professionally for a year with Scala. For me the biggest problem were functional fanatics that design solutions only top 20% of devs can understand. The rest comes from the object oriented realm and can't deal with monad transformers etc. That might work in small teams, but when you want to scale a team to 100 people you can't ignore this effect. And functional fanatics are strong in ignorance.

[emilypi]

I'll do you one better.

I worked for years in Scala, and the biggest problem I had was OOP fanatics who clung to stale design patterns and out of date knowledge of general programming principles despite FP being both the simpler, cleaner, more legible, and more maintainable approach. Part of this is the fault of the individual not asking more of themselves, and part of this is the language, encouraging people to feel good about their FP+OOP hybridity, which is entirely incompatible as a concept. I've never had a new grad who could not make the switch to an FP mindset. I have, however, had older or more established devs who don't want to learn and thought they could get away with shit work (which is the main cause of scalability issues, not new concepts).

For the record, I never used more complicated concepts than Monads and MTL in my day to day usage. If you can deal with Monads, you can deal with MTL. If you can't deal with Monads, then you didn't put in the 1 whole day of work it takes to become comfortable with the concept. If you can learn what an AbstractFactoryBean is, you can damn sure learn that a Monad consists of 4 functions across 3 interfaces and that Functor:fmap => Applicative:(pure + ap + fmap) => Monad(>>= + pure + ap + fmap).

[reificator]

> functional fanatics that design solutions only top 20% of devs can understand

Not a part of that group, but I think this is a false narrative. 20% might be accurate, or it might be a bit high even. But it has nothing to do with `top` or `bottom` performers. It's purely to do with exposure to functional styles.

Learning Haskell first doesn't make you a top 20% developer, much as I'm sure HN in particular will want to argue with me on that point.

All I'm trying to say is: there's not an intelligence spectrum of `imperative` to `functional` with `object oriented` in the middle. They're different, and many who learn one first struggle with the others, but that doesn't mean they're lower performers in what they do know than the ones who can talk about currying vs partial application.

[xamuel]

>many who learn one first

Everyone learns imperative first. "Wake up!" or "Eat your vegetables!" are imperative. No-one says to their kids, "map(vegetables, eat)"

[reificator]

I mean, those are much closer to functional than imperative tbh. At best it's simply too abstracted to discuss either way. Recipes would be a better example.

If you want to use that example it'd be more like this snippet that no one on earth would tell their children:

> Starting from n = 0, take the nth vegetable from your plate, insert your fork into that vegetable, raise your fork to your mouth, bite that vegetable, remove your fork from your mouth, masticate, add one to n, and repeat.

[tunesmith]

You can get really far on Scala just by following a couple of principles.

1) Aim towards your functions depending only on the function inputs, to calculate a return value, with no side effects

2) Aim towards your functions having a return type that exactly describes the possible outputs of your inputs.

A lot of the magic after that is clever composition that, while having the benefit of making your code shorter and smaller and more "expressive", is also obfuscating to people that are less experienced.

[bgorman]

If you are trying to write Java in Scala, you probably shouldn't be using Scala.

[monksy]

The problem is mostly a documentation problem and education problem.

[nomel]

This is another way of saying "it's too complicated".

The purpose of the advancement of technology is to make things easier. The practical use of these languages is to create something that makes money, with as little overhead as possible. A language should be selected to make things easier, with little overhead. Not being able to easily scale to 100 people is a very bad business decision, especially when the same functionality could be achieved in languages/methods that require less education (cheaper) and have a larger talent pool (cheaper). I'm talking about the use of tools that are meant for productivity, in general, not Scala.

[monksy]

It's a more precise way of saying it's too complicated. You should be precise if you want to solve issues.

> methods that require less education (cheaper)

This is not a good thing. Trying to devalue a skill is just asking for trouble, especially in engineering.

[0xdeadbeefbabe]

Don't functional fanatics write code that has no side effects?

[monksy]

That's the goal.