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

31–40 of 47 posts

Re: The Complexity Trap: Think Before You Leap

#31

Post by umvi »

wlesieutre wrote: post #10
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 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."

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?

Re: The Complexity Trap: Think Before You Leap

#32

Post by monksy »

I was pleasantly surprised to read an article like this. Less surprised that it came from Daniel Westheide. He know's his stuff.

What I was expecting: I was expecting the fad pushing an article about how too many people push components together and then they're trying to sell some kind of microservices nonsense.

Re: The Complexity Trap: Think Before You Leap

#33

Post by monksy »

nomel wrote: post #30
monksy wrote: post #22

Earlier quoted context omitted.

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

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.

Re: The Complexity Trap: Think Before You Leap

#34

Post by monksy »

0xdeadbeefbabe wrote: post #26
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.

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

That's the goal.

Re: The Complexity Trap: Think Before You Leap

#35

Post by xamuel »

reificator wrote: post #23
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.

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

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

Re: The Complexity Trap: Think Before You Leap

#36

Post by iak8god »

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.

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.

Re: The Complexity Trap: Think Before You Leap

#37

Post by emilypi »

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.

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

Re: The Complexity Trap: Think Before You Leap

#38

Post by divan »

It's a refreshing read even for non FP/Scala development world.

It's not hard to see that modern software engineering is cherishing accidental complexity, and as it comes from the "tools we use", the fair share of problem is in the languages, frameworks and tools we use. Unfortunately, there are very little of them that really take a tough stance on fighting complexity, instead of adding more features. Actually I can think only of one such language – Go, and, unsurprisingly, it's critizised heavily in many circles exactly for the lack of accidental complexity.

Tony Hoare wrote this in 1974: “But the pursuit of simplicity is one of the most difficult and challenging activities of the human mind. Progress is likely to be extremely slow, where each complexity eliminated must be hailed as a breakthrough. We need not only brilliance of intellect but breadth of experience, nicety of judgement, excellence of taste, and even more than our fair share of good luck.“

I was quite impressed after reading this essay (it's from "The software design: a parable" [1]) – written almost half a century ago, and there seem to be a little progress, if not negative. So books and talks are unlikely to change anything – we, people will still use the path of least resistance and always will be subjected to congitive biases – so probably only tooling can make a change. Go, for example, simply doesn't allow you to do many overly complex things (on purpose) and it results in extremely readable codebase – chances that you open random piece of Go code on internet and will not be able to understand it are almost zero.

I find it a terrific achievement, and wish other (future) languages could embrace the importance of it.

[1] https://people.dsv.su.se/~jpalme/s1/hoare.pdf

Re: The Complexity Trap: Think Before You Leap

#40

Post by Franciscouzo »

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…

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.

Post reply on HN