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

People who disagree aren't trying to make things complex

m50d.github.io

Post reply on HN
Print view View original

91–100 of 162 posts

Re: People who disagree aren't trying to make things complex

#91

Post by kazinator »

0xdeadbeefbabe wrote: post #4
ilaksh wrote: post #3

A big part of this is that programmers have different programming worldviews. Many people seem to be unaware that worldviews are not perfect rational easily modifiable constructions but are instead foundational structures that thinking builds upon automatically. Programmers are about as unlikely to easily change their programming worldviews as they are to change their political beliefs. Which is not to say that progr…

Have you seen the mkdir world view? It's the one where all the code is spread out over as many directories as possible, and leaf directories typically have no siblings just yet and one child.

   cons()
   {
     local newdir=cons_$((counter++))
     local car=$1
     local cdr=$2
     mkdir $newdir
     ln -s $car $newdir/car
     ln -s $cdr $newdir/cdr  
   }

Re: People who disagree aren't trying to make things complex

#92

Post by dahart »

Raidion wrote: post #63
dahart wrote: post #8

> What if there is no "complexity trap", just disagreements about how best to design programs? While I think this post asks reasonable questions, and has some healthy skepticism, the complexity trap is very real, in my experience. After 20 years of professional software development, I can safely say I've watched literally tens of millions of dollars wasted over-engineering solutions to problems that were anywhere fro…

Well, I feel like the environment of the job coupled with the developer causes over-engineering, rather than true technical concerns. I'm fairly young for my new role and architecting (from the ground up) some fairly big systems. I'm really struggling not to over complicate problems and I think it's really easy to do for a couple reasons. The selfish architect I'm working very hard not to be would rather have his wor…

I agree with all of that. My first reaction is that you’re probably in startup land where you’re mainly building new things. People do bat an eye at estimates to update old and large existing systems. It’s the new and small ones that are easy to update. If you’re even talking about MVPs, you’re probably not seeing much over-engineering yet. Or, you might have some and not know it yet, it might take a couple of years before you realize you paid large opportunity costs solving issues that seemed important. Having to decide whether to solve an issue before vs after MVP can be hard, but if you know you need to solve it either way, you’re way ahead of solving something that you aren’t absolutely sure you’ll need.

A common but not-common-enough (IMO) programming philosophy is to only write the minimum code necessary to solve problems you actually tangibly have, not for any problems you think you’ll have, only for problems that absolutely require solving now and people are screaming for them. Extreme programming and Agile and lots of other software development frameworks all have variations on this tenet.

The biggest over-engineering mistakes I’ve seen are when teams decide to rewrite from scratch a code base that they deem too crufty and too difficult to maintain and update anymore. Devs make this call far too easily, and fail to take into account how many things still work and how much effort it took to get there. I’ve been witness to two very large such rewrites that, many years later, both companies admitted were colossal mistakes.

Re: People who disagree aren't trying to make things complex

#93

Post by userbinator »

btilly wrote: post #57

Since this seems to be the place for personal views, my views, after 20 years of experience, is that people do not notice the complexity of anything that they have digested as normal. As a result doing anything other than what they are used to seems very complex to them. Whether that other thing is actually complex to a neutral third party is situation and observer dependent. I have seen this with procedural programm…

people do not notice the complexity of anything that they have digested as normal

...which is why examples of "minimal complexity" code often provoke feelings of extreme unease and horror; one nice example is https://news.ycombinator.com/item?id=8558822 where the functionality:code ratio almost seems impossible at first glance.

I have seen this with procedural programmers struggling with OO code.

To be fair, a lot of OO code tends toward overengineering and premature abstraction.

Re: People who disagree aren't trying to make things complex

#94

Post by userbinator »

taneq wrote: post #34
0xdeadbeefbabe wrote: post #4

Earlier quoted context omitted.

Have you seen the mkdir world view? It's the one where all the code is spread out over as many directories as possible, and leaf directories typically have no siblings just yet and one child.

I think this is a special case of the 'simpler is better as absurdum' approach, where you only ever write 1-3 line functions, each in their own file, because they're 'simple'. Of course, this really just moves the complexity to the composition of these functions and destroys locality of reference for anyone trying to read it.

I've found that this is true particularly when working in OO styled languages --- there seems to be an innate desire to minimise microcomplexity at the expense of greatly increasing macrocomplexity. It's like writing a book where each page contains one word. Each individual piece is "simple", but taken as a whole it's much more difficult to understand.

Re: People who disagree aren't trying to make things complex

#95

Post by LolNoGenerics »

btilly wrote: post #57

Since this seems to be the place for personal views, my views, after 20 years of experience, is that people do not notice the complexity of anything that they have digested as normal. As a result doing anything other than what they are used to seems very complex to them. Whether that other thing is actually complex to a neutral third party is situation and observer dependent. I have seen this with procedural programm…

To mock about the doings of others is easy. Plead me guilty. But there are rights and wrongs on both sides. Usually.

My theory is that engineers are often stuck in a filter bubble. Especially newer engineers. If you read all day about microservices and SPAs, there is at some point no place for something else. But classic web app achitectures are still doing very well. At a common scale they do things better with less complexity. The point is that they aren't very heavily discussed anymore. Most problems have been discussed and there are solutions for it. For me it is hard to argue about the problems of modern approaches. Not because I don't have any arguments, but because mostly the response is that we have to throw more code, hardware and architecture at it. It works for FAANG, why argue?

All sides need to pay more respect to things that work. And we have to set context when/where/why it works.

Re: People who disagree aren't trying to make things complex

#96

Post by btilly »

ilaksh wrote: post #89
shuntress wrote: post #48

Earlier quoted context omitted.

I completely agree with your comment but since we are on the topic of worldviews and assumptions I just want to point out that women program too. My assumption currently is that you do not switch pronouns arbitrarily and as a result were not just as likely to send "social circumstances may necessitate that she adopt a new viewpoint" when writing about an abstract individual programmer. I know it is annoying to have t…

There is a problem with the English language. There is no commonly used neutral pronoun. The closest thing is "they" but I think some people consider that incorrect grammar or something. he/she or switch back and forth is awkward.

See https://stroppyeditor.wordpress.com/2015/04/21/everything-yo... for more than everything that you might want to know about the use of they as a singular pronoun. Even those who think that they object to it, frequently use it without noticing.

The upshot is that whining from self-important grammarians notwithstanding, English has always had a third person singular pronoun in common use. It has been used in every century by established writers. Indeed frequently by the same people who were saying that nobody should use it. That pronoun is "they".

Re: People who disagree aren't trying to make things complex

#97

Post by trainingaccount »

Bjartr wrote: post #70
ionforce wrote: post #27

Earlier quoted context omitted.

I feel like most of the strife caused at work is different value judgements on things. So I've been trying to tease out truths vs value judgements. 1 + 1 will always equal 2, no one debates that. AWS offers both Postgres and MySQL, no one debates that. But which one is better, that will be informed by possibly irrational value judgements ("Postgres bit me once, never again!") I think people are irrational in terms of…

> 1 + 1 will always equal 2, no one debates that. Challenge accepted. * In boolean algebra, 1 + 1 = 1 * Over the field Z2 (the integers modulo 2), 1 + 1 = 0 * In binary, 1 + 1 = 10 * In a language that allows overloading +, 1 + 1 = usually 2, but potentially almost anything else In conclusion, context matters

Wot no vectors?

Re: People who disagree aren't trying to make things complex

#98

Post by crimsonalucard »

austincheney wrote: post #9

I deliberately try to make things complex, but not more complex than they actually are, though apparently this is received as a matter of perception. It commonly boils down to risk or performance versus convenience. As a senior developer I notice that juniors will sometimes do everything in their power to over-simplify a given problem. This is more often due to insecurity than accident or technical ignorance and whil…

You all have it wrong. There is a solution to building better systems.

Complexity nor simplicity are the answer for future proofing work. If a problem is complex then the problem requires a complex solution. Simplification can only be done on problems that are inherently simple.

The key for future proofing work is modularity. You must design a system in small components and each component should be self contained and unaware of the other components. Additionally, the way these components are connected together matters. The goal is to try to build a system that is a linked list rather then a graph of complex nodes. Systems that look like linked lists can have nodes removed and inserted easily in the pipeline while graphs cannot. Composability and unidirectional data flow all lead to modularity. Do not build graph architectures, build pipelines whenever possible.

Additionally the nodes in the system must never shift. If a node is a functional unit then passing closures and first class functions all over the system is equivalent to a graph structure that shifts with time. A shifting graph is not modular at all.

This is key. A simple or complex solution cannot adapt to a changing problem; and if modularity is not introduced into the system then hacks or rewrites need to be made to the entire module to get things to work. Keep in mind modularity does not mean generality. You don't need to create abstract general systems to create modular systems.

Of course this model doesn't work on all problems and there are always compromises. The goal is to minimize the compromises. GUIs are problems that doesn't fit the problem well. You will note that Redux attempts to solve this issue by attempting to transform the GUI problem into something as close to a linked list as possible. However a full transformation isn't possible due to the inherently complex graph nature of the GUIs' itself.

The very model of OOP is the antithesis of modularity. While one can create a lot of abstract objects that can be repurposed for other uses this modularity is an illusion. OOP actually promotes a style of programming where your code becomes a graph of nodes leading to less modularity overall.

Re: People who disagree aren't trying to make things complex

#99

Post by btilly »

userbinator wrote: post #93
btilly wrote: post #57

Since this seems to be the place for personal views, my views, after 20 years of experience, is that people do not notice the complexity of anything that they have digested as normal. As a result doing anything other than what they are used to seems very complex to them. Whether that other thing is actually complex to a neutral third party is situation and observer dependent. I have seen this with procedural programm…

people do not notice the complexity of anything that they have digested as normal ...which is why examples of "minimal complexity" code often provoke feelings of extreme unease and horror; one nice example is https://news.ycombinator.com/item?id=8558822 where the functionality:code ratio almost seems impossible at first glance. I have seen this with procedural programmers struggling with OO code. To be fair, a lot of…

That is an excellent link to read through, and the code is an excellent description.

There is an inherent complexity to a compiler. That example had only that. There are standard names for things in C. That example had only that. In all fields, internalizing compact names improves how much an expert can think and makes it impenetrable to beginners. (Math is particularly good at supplying examples.) That program used compact variable names that are standard enough in C to be instantly recognizable, but come as a shock to someone who hasn't internalized them.

The result is a compressed version of exactly what an experienced compiler programmer has already internalized. And is utterly impenetrable to anyone who hasn't internalized the concepts that they need.

Re: People who disagree aren't trying to make things complex

#100

Post by munchbunny »

undershirt wrote: post #82
otikik wrote: post #81

I can't if it's the typefaces, the interlining, the space between paragraphs or a combination of those, but that page was so unpleasant to read that I had to use Firefox's "reader view" to do it. I have no opinion whatsoever on the the text, but the presentation was so hideous that I thought it was worth mentioning.

It's the negative line height—you can see by selecting multiple lines of text that the rows actually overlap each other.

Spot on. The lines are too long and too scrunched together.

I could feel myself involuntarily squinting to read it.

Post reply on HN