Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Complexity Trap: Think Before You Leap

danielwestheide.com

Post reply on HN
Print view View original

21–30 of 47 posts

Re: The Complexity Trap: Think Before You Leap

#21

Post by monksy »

afpx wrote: post #6

As one who frequently deals with Scala code, I have to say that this guy is right: the Scala community in particular seems to relish in complexity. Scala is a wonderful language and well-designed, especially in contrast to Java. The learning curve requires a good deal of effort, but with experience, it becomes incredibly fun to write Scala code. Once I got past the learning curve, Scala became my go-to language. That…

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.

Re: The Complexity Trap: Think Before You Leap

#22

Post by monksy »

zie1ony wrote: post #7
afpx wrote: post #6

As one who frequently deals with Scala code, I have to say that this guy is right: the Scala community in particular seems to relish in complexity. Scala is a wonderful language and well-designed, especially in contrast to Java. The learning curve requires a good deal of effort, but with experience, it becomes incredibly fun to write Scala code. Once I got past the learning curve, Scala became my go-to language. That…

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.

The problem is mostly a documentation problem and education problem.

Re: The Complexity Trap: Think Before You Leap

#23

Post by reificator »

zie1ony wrote: post #7
afpx wrote: post #6

As one who frequently deals with Scala code, I have to say that this guy is right: the Scala community in particular seems to relish in complexity. Scala is a wonderful language and well-designed, especially in contrast to Java. The learning curve requires a good deal of effort, but with experience, it becomes incredibly fun to write Scala code. Once I got past the learning curve, Scala became my go-to language. That…

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.

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

Re: The Complexity Trap: Think Before You Leap

#24

Post by reificator »

malkarouri wrote: post #13
wlesieutre wrote: post #10

Earlier quoted context omitted.

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.

Re: The Complexity Trap: Think Before You Leap

#25

Post by lmm »

reificator wrote: post #24
malkarouri wrote: post #13

Earlier quoted context omitted.

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.

Re: The Complexity Trap: Think Before You Leap

#26

Post by 0xdeadbeefbabe »

zie1ony wrote: post #7
afpx wrote: post #6

As one who frequently deals with Scala code, I have to say that this guy is right: the Scala community in particular seems to relish in complexity. Scala is a wonderful language and well-designed, especially in contrast to Java. The learning curve requires a good deal of effort, but with experience, it becomes incredibly fun to write Scala code. Once I got past the learning curve, Scala became my go-to language. That…

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.

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

Re: The Complexity Trap: Think Before You Leap

#27

Post by reificator »

lmm wrote: post #25
reificator wrote: post #24

Earlier quoted context omitted.

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.

Re: The Complexity Trap: Think Before You Leap

#28

Post by tunesmith »

zie1ony wrote: post #7
afpx wrote: post #6

As one who frequently deals with Scala code, I have to say that this guy is right: the Scala community in particular seems to relish in complexity. Scala is a wonderful language and well-designed, especially in contrast to Java. The learning curve requires a good deal of effort, but with experience, it becomes incredibly fun to write Scala code. Once I got past the learning curve, Scala became my go-to language. That…

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.

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.

Re: The Complexity Trap: Think Before You Leap

#29

Post by lmm »

reificator wrote: post #27
lmm wrote: post #25

Earlier quoted context omitted.

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 ex…

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?

Re: The Complexity Trap: Think Before You Leap

#30

Post by nomel »

monksy wrote: post #22
zie1ony wrote: post #7

Earlier quoted context omitted.

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.

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.

Post reply on HN