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

11–20 of 47 posts

Re: The Complexity Trap: Think Before You Leap

#11

Post by harveywi »

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…

Your argument, distilled:

- You don't like "those people" (the Scala community)

- You explain behaviors of Scala programmers in terms of your beliefs of their internal states ("they relish complexity") rather than external factors.

- "Those people" are arrogant.

- "Those people" are abusive.

- "Those people" show off

- "Those people" exploit users and maintainers

- "Those people" are insecure

- "Those people" aren't doing anything new.

- "Those people" are just following fads.

Re: The Complexity Trap: Think Before You Leap

#12

Post by [deleted] »

titzer wrote: post #9

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” --Brian Kernighan How many times have I bitten myself this way? Dear past me: stop being so smart.

[deleted]

Re: The Complexity Trap: Think Before You Leap

#13

Post by malkarouri »

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

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.

Re: The Complexity Trap: Think Before You Leap

#14

Post by phendrenad2 »

harveywi wrote: post #11
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…

Your argument, distilled: - You don't like "those people" (the Scala community) - You explain behaviors of Scala programmers in terms of your beliefs of their internal states ("they relish complexity") rather than external factors. - "Those people" are arrogant. - "Those people" are abusive. - "Those people" show off - "Those people" exploit users and maintainers - "Those people" are insecure - "Those people" aren't…

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

Re: The Complexity Trap: Think Before You Leap

#15

Post by Verdex_3 »

I really like it when people become concerned about cognitive complexity. I think it's one of the significantly ignored concepts in our industry and if we ever find a way to address the issue (either with some sort of cognitive complexity solution or some sort of big oh like math framework that describes how things are complex) then the future generations of software engineers will look at what we're currently doing now the same way we look at how people used to do alchemy for our lack of being able to handle cognitive complexity.

Personally, I want a mathematical structure of "problems" such that we can track when we're actually making things more complex or less complex. In the article, removing boilerplate was a problem because internal domain models were being exposed publicly. But what I really want to know is "what are we actually gaining by removing the boiler plate and what are we losing by exposing domain models". In like a general mathematical sense such that if everyone about programming changes (maybe suddenly we switch to APL or something), the lessons we learned are still valid.

So far the best I've managed is [1]. I've done a bunch of refinement in the last year and a half, but the general structure is about the same. I'm not suggesting that what I have is complete or even necessarily the right direction to go for this sort of thing. But what I am saying is that in order to make definite statements about how the problem and/or code you're dealing with is complex (that don't rely on appeals to authority) then you probably need to have done at least as much "work" as I have (if that makes any sense).

[1] - https://www.sep.com/sep-blog/2017/04/25/objective-code-quali...

Re: The Complexity Trap: Think Before You Leap

#16

Post by bgorman »

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.

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

Re: The Complexity Trap: Think Before You Leap

#17

Post by skohan »

Verdex_3 wrote: post #15

I really like it when people become concerned about cognitive complexity. I think it's one of the significantly ignored concepts in our industry and if we ever find a way to address the issue (either with some sort of cognitive complexity solution or some sort of big oh like math framework that describes how things are complex) then the future generations of software engineers will look at what we're currently doing…

I like the alchemy analogy. I think a huge trap we tend to fall into as a profession is presuming to know what software engineering practices are good or bad when we actually have next to zero empirical data on the matter. Most of what the accepted dogma is comes from either authority, or from what techniques lend themselves to the strongest arguments.

Re: The Complexity Trap: Think Before You Leap

#18

Post by nuclx »

lmm wrote: post #5

> Doing that certainly means that you scrap quite a bit of boilerplate and reduce the complexity in your code. However, if you look at the bigger picture, this is the opposite of removing complexity. Exposing your domain model like this almost always leads to strongly coupled systems that are very difficult to evolve. If you ask me, this is one of the most promising ways to create a distributed monolith. It really am…

Yeah, I really wanted to agree with the author and I did on some points e.g. avoid to abstract unnecessarily over effects. But advocating for explicitly defined library interfaces is actually dangerous unless there is the specific need for a stable interface, as it adds complexity in the form of technical debt.

Re: The Complexity Trap: Think Before You Leap

#19

Post by marcosdumay »

lmm wrote: post #5

> Doing that certainly means that you scrap quite a bit of boilerplate and reduce the complexity in your code. However, if you look at the bigger picture, this is the opposite of removing complexity. Exposing your domain model like this almost always leads to strongly coupled systems that are very difficult to evolve. If you ask me, this is one of the most promising ways to create a distributed monolith. It really am…

> Very few people will claim that the problem with today's software is that programmers think things through too much and should rush to write code instead (though for the record I think that's actually the case).

People coming from easy to refactor languages have widely different rule books from the ones coming from boileplate-filled ones. It expected that the same person thinks people should rush to write code earlier and gets to understand how a project can fail because of lack of higher-kinded types. The hard part is explaining to people how those weird languages make one more productive, because their thought follows completely opposite rules.

Post reply on HN