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

Composition shouldn't be this hard

cambra.dev

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Composition shouldn't be this hard

#61

Post by yxhuvud »

TeMPOraL wrote: post #43
DanielHB wrote: post #28

> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained. I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely neces…

Right. One thing I learned over the years is that you can support arbitrarily high level of tech debt and still be able to effectively maintain and enrich a successful software system, as long as you throw enough warm bodies at it . The overhead will get absurd, you'll end up with 10x or more increase in engineers working on the system, all of them making slow progress while spending 90% time debugging, researching,…

The classical case of this are banks that tend to keep ancient systems alive for a very, very long time.

Re: Composition shouldn't be this hard

#62

Post by gessha »

DanielHB wrote: post #28

> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained. I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely neces…

A decision can be right even if the outcome doesn’t work out and a decision can be wrong even if the outcome works out.

Example: Gambling is wrong but you can win big money.

Re: Composition shouldn't be this hard

#63

Post by satvikpendem »

DanielHB wrote: post #28

> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained. I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely neces…

Well yeah, I'm not sure why that's sad. One can't find all edge cases at the beginning but only through usage of the app, and fix them over time. Be glad at least someone is using the app as that means the role of software is being fulfilled, as a tool to help people accomplish some goal, because much software written isn't even used by a single person.

Re: Composition shouldn't be this hard

#64

Post by andrewflnr »

thenoblesunfish wrote: post #19

Maybe this unfairly off topic, but in reading the intro, my thought was not that things become brittle and hard to change because of the inelegance of the abstractions, but because of the banal dynamics of work. Mostly, people act quickly towards short term goals, without full understanding. They accept technical debt, they pass things between people, and the numbers to avoid making things kinda gross just never work…

I think they would say that their goal is to make the less-gross approach the path of least resistance (or at least closer to it, no tool can force you to solve the right problem). Or rather, that even when someone takes a short term approach, it's not that hard to fix because the system is more flexible overall. That would be my goal, certainly, if I were founding this company.

Re: Composition shouldn't be this hard

#65

Post by rho4 »

buggymcbugfix wrote: post #49
rho4 wrote: post #11

Not sure if tools and technologies can solve accidental complexity. In my opinion, a system that has been stable for years isn't 'mature' in a good sense. An exceptional system is one that can still change after many years in production. I believe this is almost impossible to achieve for enterprise software, because nobody has incentive to make the (huge) investment into longterm maintainability and changeability. Fo…

You can't say... > Not sure if tools and technologies can solve accidental complexity. ... and then say > For me, consistent systematic naming and prefixes/suffixes to make names unique are a hint that a person is thinking about this or has experience with maintaining old systems. This has a huge effect on how well you can search, analyze, find usages, understand, replace, change. I have battle scars from refactoring…

I guess I wanted to say that no tool/technology can prevent people from creating chaos (or make up for bad/non-existant processes). People need to do that. Of course, systematic people use tools as well. But you can't expect to buy or mandate a tool/technology and expect your system to then automatically have these qualities.

Re: Composition shouldn't be this hard

#66

Post by buggymcbugfix »

rho4 wrote: post #65
buggymcbugfix wrote: post #49

Earlier quoted context omitted.

You can't say... > Not sure if tools and technologies can solve accidental complexity. ... and then say > For me, consistent systematic naming and prefixes/suffixes to make names unique are a hint that a person is thinking about this or has experience with maintaining old systems. This has a huge effect on how well you can search, analyze, find usages, understand, replace, change. I have battle scars from refactoring…

I guess I wanted to say that no tool/technology can prevent people from creating chaos (or make up for bad/non-existant processes). People need to do that. Of course, systematic people use tools as well. But you can't expect to buy or mandate a tool/technology and expect your system to then automatically have these qualities.

That is true! The system I mentioned above, which I had to refactor, was written in the worst Haskell that I've ever seen and nobody at the company dared touch it with a 10-foot pole.

Re: Composition shouldn't be this hard

#68

Post by dr2df »

TeMPOraL wrote: post #43
DanielHB wrote: post #28

> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained. I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely neces…

Right. One thing I learned over the years is that you can support arbitrarily high level of tech debt and still be able to effectively maintain and enrich a successful software system, as long as you throw enough warm bodies at it . The overhead will get absurd, you'll end up with 10x or more increase in engineers working on the system, all of them making slow progress while spending 90% time debugging, researching,…

What a 'fancy' way of distinguishing between capital expenses vs operating expenses....

Why do people on here do this? Just keep it simple. lmao.

"the economic math actually adds up"

just lol.

Re: Composition shouldn't be this hard

#69

Post by dr2df »

yxhuvud wrote: post #61
TeMPOraL wrote: post #43

Earlier quoted context omitted.

Right. One thing I learned over the years is that you can support arbitrarily high level of tech debt and still be able to effectively maintain and enrich a successful software system, as long as you throw enough warm bodies at it . The overhead will get absurd, you'll end up with 10x or more increase in engineers working on the system, all of them making slow progress while spending 90% time debugging, researching,…

The classical case of this are banks that tend to keep ancient systems alive for a very, very long time.

The implicit cost of systems associated with banks failing is why they continue going on as is.
Post reply on HN