I think the equivalent to this in Python is "How many list comprehensions can I nest!?"

Solving things with list comprehensions is very idiomatic python, so the thought process goes "the more of these I can stuff inside each other, the more idiomatic my code is."

Solving things with list comprehensions is very idiomatic in Python.

Also, not nesting things is very idiomatic Python ("Flat is better than nested" is part of the Zen).

So, people generally don't think of nested list comprehensions as idiomatic.

And `explicit is better than implicit` is idiomatic python, but the language uses the most implicit characters available on the average keyboard (` ` and ` `) to denote control flow.

The language uses indentation levels to denote control flow, and those are very explicit - much more so than braces in fact.

They're not though. They only exist as the relation between the edge and the start of content.

How many levels of indentation are there on each line?

https://i.imgur.com/s1WBHxU.png

Spoiler: Line 3 has no indentation while Line 6 has one level. Line 4 has a mix of tabs and spaces that would confuse Python.

The fact of the matter is that indentation is white space, and white space is implicit by definition. It only exists as the gap between other things.

Stop using a legacy version of Python.

You will get a "TabError: inconsistent use of tabs and spaces in indentation" exception if you use Python 3.

I haven't used python with inconsistent indentation recently, that's true.

In that sense control flow only exists as the relation between other things, so it makes sense for it to be denoted that way. If a line with no code on it is indented in the forest and nobody hears it, does the line execute?

I write my python interactively in a repl, and often end up with deeply nested list comprehensions as a result. I always need to break them up to have any chance of understanding it even a day later.

I weep anytime I need to decode a one-liner list comprehension/map/filter/reduce/lambda abomination. Like... would it have killed you to break it into multiple lines and sprinkled in some comments?

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.

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).

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

>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)"

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.

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.

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

The problem is mostly a documentation problem and education problem.

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.

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.

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

That's the goal.

I agree with you 100% plus, I'd like to take it up a notch by saying that Pure FP evangelists are the sole reason why Scala is not widely used.

Also, it is not seldom that you hear them say "It took me n years to fully grok the _whatever FP concept_". Or Martin Odersky doesn't get the _whatever FP concept_.

So how do they expect the majority of sw engineers will use/adopt those principles if the guy who invented Scala "does not get it" and even themselves took so much time to "get it"...???

I'm not sure that the right thing is that they relish in complexity:

They tend to use it as something to show off their ego. It's a bit too academic and it often fails to understand the user's need.

It's often ignored about how the tool/library integrates with their user's code. For example, Http4s wants you to form your application around it, rather than just being a single component of your application.

You're right, they're really doing it for job security...