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

Growing object-oriented software vs. what I would do

dpc.pw

Post reply on HN
Print view View original

51–60 of 99 posts

Re: Growing object-oriented software vs. what I would do

#51

Post by mbrodersen »

PaulDavisThe1st wrote: post #19

Things I've learned from 25+ years of programming in C++ (and 5+ years of C before that): 1. not all software is about pushing and pulling to/from a database; if yours isn't, be sure you understand why that's the case. 2. "backends" (not "web backends", but the more general "where the mechanisms are") should know nothing about "frontends" (again, not web, but the more general "user interface of some kind"). This is r…

40+ years of programming experience here. The next step is to realise that MVC is just an example of events driven programming. An application is a state that “instantly” changes to the next state when an event happens. Multiple separate states (logging/UI/DB/remote/…) coordinate by reacting to events. The business logic is generating “this is now true” events. That’s it. There is nothing else to it.

Re: Growing object-oriented software vs. what I would do

#52

Post by theteapot »

Zababa wrote: post #38
theteapot wrote: post #37

Earlier quoted context omitted.

I don't think you can separate the two. To understand whether OOP is a good idea you need to understand how it's used to solve software problems.

I don't think those are the same "problems". "Design patterns" is about code, not solving business problems. To stay in the well known books in OOP, DDD would be about solving business problems.

"business problems"? I feel like the goal posts are moving here. EOD all I'm saying is I didn't really understand or appreciate OO until I'd read and digested DP. Until you've at least covered those basics it's hard to have an opinion on whether OOP is crap or not in my view. But maybe I've just been indoctrinated by it.

Re: Growing object-oriented software vs. what I would do

#53

Post by josephg »

lostcolony wrote: post #40
sam0x17 wrote: post #32

Earlier quoted context omitted.

There are also a lot of cases where people "modularize" code without actually modularizing it --- they extract certain functions into separate modules or files just to break up the current file, but that new module they've created can't function or do anything on its own outside of the context it was extracted from. So in these cases they've really obfuscated the code in the name of "modularization", but the code is…

Right; breaking it up doesn't necessarily make it more modular, it just necessarily spreads it around. This is -a bad thing-, with no other context. The hope is that it modularizes the code enough to enable better understanding/reuse/extension (thus being a necessary evil).

Right. The problem I've seen way too much is modularizing code too early in its lifecycle. This mistake seems to happen a lot by smart programmers who are inexperienced.

The instinct seems to be that they want hinges in their code, so their code can adapt and be reusable between projects. But they don't actually know where the hinges should go, because they don't need them yet. So they just put hinges all over the place - even where hinges aren't useful. If the metaphor is confusing, I'm talking about things like making an interface around a class, when there's only one implementor of that interface anyway. Or breaking a complex function into small, "reusable" pieces spread over multiple files - except where those small pieces are only ever used by that one call stack anyway. (And where they aren't that semantically self contained.) The result is harder to follow code with no actual benefit. And the resulting code is almost always bigger and more complex, and thus harder to work with.

Usually code thats the easiest to refactor is code thats the easiest to understand. That means, small, dense, correct code, with a simple test suite. If you write code knowing that you can (and will refactor) later anyway, the result is almost always better software. You will come up with a better design after you know more about your problem domain. Plan for that, and set yourself up to take advantage of that knowledge later.

Re: Growing object-oriented software vs. what I would do

#54

Post by PaulDavisThe1st »

mbrodersen wrote: post #51
PaulDavisThe1st wrote: post #19

Things I've learned from 25+ years of programming in C++ (and 5+ years of C before that): 1. not all software is about pushing and pulling to/from a database; if yours isn't, be sure you understand why that's the case. 2. "backends" (not "web backends", but the more general "where the mechanisms are") should know nothing about "frontends" (again, not web, but the more general "user interface of some kind"). This is r…

40+ years of programming experience here. The next step is to realise that MVC is just an example of events driven programming. An application is a state that “instantly” changes to the next state when an event happens. Multiple separate states (logging/UI/DB/remote/…) coordinate by reacting to events. The business logic is generating “this is now true” events. That’s it. There is nothing else to it.

That might be true for something where the phrase "business logic" is applicable.

But in my niche (realtime audio software), there is underlying data in the system that changes over time independently of events. So there is "something else to it".

Re: Growing object-oriented software vs. what I would do

#55

Post by PaulDavisThe1st »

mistrial9 wrote: post #48
PaulDavisThe1st wrote: post #19

Things I've learned from 25+ years of programming in C++ (and 5+ years of C before that): 1. not all software is about pushing and pulling to/from a database; if yours isn't, be sure you understand why that's the case. 2. "backends" (not "web backends", but the more general "where the mechanisms are") should know nothing about "frontends" (again, not web, but the more general "user interface of some kind"). This is r…

number three comes from Javascript specifically?

Not at all. I've likely written no more than 100 lines of JS in my entire life. This is an observation based on C++ development, exclusively, but I believe likely relevant to any language that can implement something semantically equivalent to a closure.

Re: Growing object-oriented software vs. what I would do

#56

Post by NovaX »

josephg wrote: post #5

This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program. In com…

> In Java it would be a nest of SortComparator interfaces and SortAlgorithm implementors, which would act to hide the algorithm itself.

That is odd because when I look at the Java style, DualPivotQuicksort [1], it seems that the language authors did not do that. This is so very strange! Their methods are long, complex, and highly documented. Maybe they must be really incompetent Java programmers? I mean, they did put this obtuse abstraction by hiding it in Arrays. That's super crazy, just look at this monstrosity!!!

    public static void sort(int[] a) {
      DualPivotQuicksort.sort(a, 0, 0, a.length);
    }
Maybe you need to have an intervention with them? Somehow, in some crazy world, even Java programmers are capable of writing good and efficient code. Its like bad developers might do an awful in job in whatever language they used? Can't be true...

[1] https://github.com/openjdk/jdk/blob/master/src/java.base/sha...

Re: Growing object-oriented software vs. what I would do

#57

Post by josephg »

NovaX wrote: post #56
josephg wrote: post #5

This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program. In com…

> In Java it would be a nest of SortComparator interfaces and SortAlgorithm implementors, which would act to hide the algorithm itself. That is odd because when I look at the Java style, DualPivotQuicksort [1], it seems that the language authors did not do that. This is so very strange! Their methods are long, complex, and highly documented. Maybe they must be really incompetent Java programmers? I mean, they did put…

The "enterprise" programming culture which has emerged around Java doesn't impinge on all java code. But it is still a real thing. The fact that openjdk authors can rise above it and write clean, reusable Java code is obviously good. The fact that there is something that needs to be risen above is unfortunate.

I think the same about Javascript, though the specifics are different. I've been writing JS for years, but I've been moving away from it lately because increasingly I feel like an odd duck in the JS world. Most javascript programmers have much less experience (in any language) than I do. When I mention I write a lot of javascript professionally, people assume I'm an fresh faced bootcamp grad. Its sometimes hard to find high quality libraries on npm because the average quality there is reasonably low. Eg good luck finding a password generator which doesn't use Math.random(). Or finding an email parsing library which preserves the order of email headers. (This has semantic content!)

Does there exist high quality java + javascript code? Sure. But even macdonalds makes good food sometimes. That isn't enough to make me a regular customer.

Sometimes the right call is to fight for the ecosystem you're a part of and help it improve. I've done a lot of that. But you don't have to fight for high quality software if you just go where the high quality software is being made. Its easier to switch languages than change a culture.

... I'm being a bit sloppy and judgemental here. Maybe it would be better to say, each ecosystem has a set of values. Javascript values programming velocity, accessibility to new programmers and simplicity. Java has a different list. Insomuch as you're living inside an ecosystem, you don't get to simply ignore and dismiss those influences when you don't like them. It sucks writing Go if you hate gofmt. It sucks writing rust if you don't even want the borrow checker. And it sucks writing Java if you hate dealing with AbstractIteratorFactoryImpl. Even if there's some redeeming code in openjdk.

Re: Growing object-oriented software vs. what I would do

#58

Post by deltasixeight »

lostcolony wrote: post #40
sam0x17 wrote: post #32

Earlier quoted context omitted.

There are also a lot of cases where people "modularize" code without actually modularizing it --- they extract certain functions into separate modules or files just to break up the current file, but that new module they've created can't function or do anything on its own outside of the context it was extracted from. So in these cases they've really obfuscated the code in the name of "modularization", but the code is…

Right; breaking it up doesn't necessarily make it more modular, it just necessarily spreads it around. This is -a bad thing-, with no other context. The hope is that it modularizes the code enough to enable better understanding/reuse/extension (thus being a necessary evil).

If you can move your code and spread it around it is Modular by definition. This is never a bad thing from a design perspective. It is only a bad thing from a complexity and readability perspective.

More likely you think it's a bad thing because your code isn't actually modular. Likely you need one piece of logic but that logic isn't modular so to move it to another location you need to drag a bunch of extra baggage around with it. You wanted a banana but instead you got the gorilla holding the banana and the entire jungle. Sound familiar?

The smallest primitive that is modular is a pure immutable function. If the modules you are moving around are not pure functions then likely your code isn't actually modular.

Re: Growing object-oriented software vs. what I would do

#59

Post by smashed »

PaulDavisThe1st wrote: post #54
mbrodersen wrote: post #51

Earlier quoted context omitted.

40+ years of programming experience here. The next step is to realise that MVC is just an example of events driven programming. An application is a state that “instantly” changes to the next state when an event happens. Multiple separate states (logging/UI/DB/remote/…) coordinate by reacting to events. The business logic is generating “this is now true” events. That’s it. There is nothing else to it.

That might be true for something where the phrase "business logic" is applicable. But in my niche (realtime audio software), there is underlying data in the system that changes over time independently of events. So there is "something else to it".

Not meant to be pedantic, just playing devil's advocate, but isn't the real time audio bitstream just a continuous source of events that gets blended with the rest of the application state like active filters and what not?

Re: Growing object-oriented software vs. what I would do

#60

Post by deltasixeight »

sam0x17 wrote: post #32
deltasixeight wrote: post #30

Earlier quoted context omitted.

No hacking code to pieces makes it more complex. The trade off here is that the code becomes more modular. Whether you want your code to be more modular is an opinionated decision but most people don't realize the benefits of high modularity. Almost all major design mistakes that necessitate code rewrites come from lack of modularity.

There are also a lot of cases where people "modularize" code without actually modularizing it --- they extract certain functions into separate modules or files just to break up the current file, but that new module they've created can't function or do anything on its own outside of the context it was extracted from. So in these cases they've really obfuscated the code in the name of "modularization", but the code is…

I would say the file thing is unnecessary. That's just an OCD thing. You can break stuff up and keep it within the same file, it literally has the same effect.

I understand why you think that type of modularity is bad, but it is actually good. It only appears bad because most of the "modularized" code is only used once.

No one can predict the future so the way to minimize rewrites is to make composable units of code that are small and highly modular. It's not about breaking up your code. It's about writing small logical component then building up the larger component by composing the smaller components.

This results in a large number of modules that are only used one time, but it prepares your code for the inevitable point of the future where you find out the design was wrong and you have to rearrange the logic.

When such a time comes you most likely just trivially rearrange some of your logic and add additional pure functions into your pipe line for any actual new logic. The majority of your modules remain untouched and this only seems bad, but it prevented a rewrite of the entire framework.

The timeline where the definitively worse outcome occured didn't happen because your code was too modular. So you have no point of comparison and you assume the modular code that is hard to read is bad only because it's hard to read. You failed to see how it prevented a massive refactor.

Usually if code is so unmodular, people just live with it and keep accumulating massive tech debt on top of everything. If all your seeing is tiny functions everywhere then this is definitively better than the alternative.

From a design perspective highly modular code is always better. From readability perspective though, you are right, modular code is harder to read. But there are ways to mitigate this.

Post reply on HN