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

131–140 of 162 posts

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

#131

Post by js8 »

munchbunny wrote: post #122
userbinator wrote: post #93

Earlier quoted context omitted.

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…

To be fair, a lot of OO code tends toward overengineering and premature abstraction. And a lot of functional code tends towards unnecessary levels of indirection through higher order functions as a way of deferring responsibility for actual logic, or on the flipside insufficient abstraction leading to difficulty extending functionality. I've gone back and forth multiple times between functional practices and OO pract…

"I've gone back and forth multiple times between functional practices and OO practices, and I definitely empathize with the confusion going in both directions. You trade one problem for another, and in the end there really is no free lunch."

I think there is a strange kind of duality between OOP and FP. I think OOP passes structures of objects hidden behind interfaces, while the FP passes composed functions in other direction. So you can convert your OOP code to FP code almost mindlessly by total "inversion of control" - wherever you pass an object somewhere (making a call), in FP you pass the operation from the callee to the caller instead.

And I think it's this duality that you observe in practice.

However, I believe there is a practical difference between the two, which makes FP superior despite being harder to understand initially.

It's much easier to spot that you're doing "no-ops" in FP than in OOP. In OOP, often you pass the objects unchanged across layers, while in FP, this manifests as identity functions being used. And it's easier for both human and compiler to remove these redundant identity functions (through function specialization and things like fusion etc.).

Also, I believe functional approach allows you to better realize that there are some algebraic laws governing your problem domain.

It's really kind of like in mathematics, when you come from point-wise understanding of functions to functional understanding of functions, more insight is gained.

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

#132

Post by rabidrat »

candiodari wrote: post #83
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…

I've seen this very often. People are absolutely consumed by avoiding their previous mistakes. Sometimes those are even searched-for almost-made-up mistakes rather than real ones, like in postmortems for successful projects. And then BIG changes are implemented in the process. Usually in the worst possible place: in the planning of the process in the first place. If a project succeeded, and finished, your adjustments…

You have good points but ML needs thousands of generations; at most we'll have done dozens of multi-person projects under our belts. 2% doesn't even beat inflation.

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

#134

Post by coldtea »

>Having business requirements that interleave pure operations with effectful ones - "if the request exceeds one of our free account limits then check the user's subscription is still active in this external service" - is normal, like it or not.

Isn't that what the "imperative shell" is about?

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

#135

Post by lmm »

goflyapig wrote: post #115
lmm wrote: post #31

Earlier quoted context omitted.

> So, we should just "agree to disagree" and stop trying to demonstrate how one approach might be much better over another? How can anything ever get better? No, we should try to make things better. But framing these choices as "complexity" doesn't seem to be helpful. The choices are tradeoffs but they're not a deliberate choice of complexity for the sake of some other value; at most they're choices between different…

> deliberate choice of complexity I also don't see anything in The Complexity Trap that accuses anyone of that. I think that's a misreading. Rather, I think The Complexity Trap argues that many developers have a poor understanding of what "complexity" means, so they end up increasing it even when they think they are decreasing it. Specifically, I think the point it tries to make is that complexity doesn't equate to v…

> Your article seems to agree that DTOs are more decoupled because you refer to it as "cargo cult decoupling", yet you still argue it's more complex. So you aren't using the same definition.

Well I'm using the same definition as the second section of The Complexity Trap, where it considers introducing an effect algebra to be increasing complexity.

Whatever tradeoff is made by introducing DTOs is in some sense the same as the one that's being made by introducing a free monad or tagless final - more verbosity and less coupling. But The Complexity Trap seems to think that verbosity is more complex than coupling half the time, and coupling is more complex than verbosity the other half of the time. So framing either as "trading complexity for ..." is unhelpful.

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

#136

Post by jondubois »

No programming approach is perfect but some programming approaches are better than others. I started programming with a statically typed language for many years and then I went back and forth between dynamically and statically typed several times in my professional career. Once you've developed good programming habbits (which statically typed languages can help you to learn), ultimately, dynamically typed is better. Dynamically typed languages are simpler, faster to write, easier to change, easier and faster to test and debug, focus on raw logic instead of semantics, interact with external services more easily (JSON is the most popular data interchange format and it doesn't carry type information), integrate better with unrelated systems (no type conflicts when integrating different projects).

Functional programming is really nice for some things but ultimately, you need to store state somewhere and often you don't want to store all the data in your entire system inside a single monolothic store or database - Often, you want data to be close to the logic which operates on it; having a global data store is often just as bad as using global variable names in your application; it can lead to conflicts (forces you to think about data in a system-wide way; not accounting for data from external systems) and makes it hard to track where the data is used within the system.

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

#137

Post by lmm »

alexandercrohde wrote: post #38

I have to pretty much reject this post wholesale. True the post it's disagreeing with picked weak examples. But other than that pretty much all of its overall points were actually very accurate. The original article was not about json/scala/etc. It was about this: To summarize, we have to deal with a lot of accidental complexity these days, for multiple reasons. First of all, we adopt techniques and abstractions with…

> True the post it's disagreeing with picked weak examples. But other than that pretty much all of its overall points were actually very accurate.

That's what I initially thought. But how can the overall points possibly be right if they lead to exactly the wrong conclusions in most or all of the specific examples? At best the part you quote is vacuous and unhelpful for actually making technical decisions.

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

#138

Post by jondubois »

LolNoGenerics wrote: post #95
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…

True, definitely Amazon is heavy on the Serverless marketing/filter bubble.

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

#139

Post by akvadrako »

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…

Coincidently, people (and other beings) also have different worldviews in every context and not acknowledging this leads to endless pointless arguments.

It would be cool if the participants of every discussion (programming or otherwise) labeled their worldviews explicitly, so we could at least know what we're dealing with. For example on here with a tag by our usernames.

Old religions used to serve that purpose at least to a first approximation - we really could use some words to describe the new ones.

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

#140

Post by LandR »

Sometimes complexity is needed.

I've worked on too many projects where it's just do whatever is easiest at the time to get it working ASAP. This works, for a while, but eventually that code base that no one really put any thinking into around design turns into a tyre fire.

Maintenance becomes hellish, extending it becomes hellish and error prone. Finding and resolving bugs become excrutiating.

So when people go for a more complex solution up front, it might not be complexity for complexities sake, they might actually be able to forsee issues in the future and want to avoid them.

I wish more software development projects employed front loading the effort, either in terms of design / architecture / employing some sort of code analysis / quality control etc or even just thinking. Especially thinking.

If the result of that thinking is more complexity, then it's fine. You're introducing complexity early, everyone can get used to it because it's going to make your lives in the future easier.

Post reply on HN