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

61–70 of 99 posts

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

#61

Post by sam0x17 »

deltasixeight wrote: post #58
lostcolony wrote: post #40

Earlier quoted context omitted.

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…

> If you can move your code and spread it around it is Modular by definition.

For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do this merely to get the linter to pass, instead of for the actual purpose of modularization.

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

#62

Post by Jtsummers »

sam0x17 wrote: post #61
deltasixeight wrote: post #58

Earlier quoted context omitted.

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…

> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do…

Right.

If A and B are coupled so tightly that one cannot exist without the other, you don't really have two modules. You have one, AB. This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). The latter is particularly pernicious in languages which don't have a clear separation between classes and modules (Java, for instance, or historically I think this has changed).

The reality is that there are two (at least) kinds of modularity. "Syntactic" (I need a better name for this) modularity like Java classes, or C's translation units (why I need a better name). These act as modules, but don't necessarily define a real, proper module. And then there are your real modules which are comprised of the things that must exist together (like in the earlier example), regardless of the project structure or language's notion of a module.

I had a team try to convince me their code was "modular" but their GUI portion was directly tied to the DB portion and other logic. Nothing could be instantiated separately, so it wasn't really modular, it was just using the language and build system's notions of modules to create the illusion of modularity (C++ and VS in their case). In contrast, another team had developed a collection of libraries (C# and VS again) that were used in multiple applications. That was real modularity.

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

#63

Post by pjmlp »

josephg wrote: post #57
NovaX wrote: post #56

Earlier quoted context omitted.

> 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…

The "enterprise" programming culture did not emerge around Java.

It was already been there regardless of the language.

I am old enough to have done Enterprise C, Enterprise C++, Enterprise VB, Enterprise Delphi, Enterprise xBase, ...

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

#64

Post by tonyedgecombe »

josephg wrote: post #57
NovaX wrote: post #56

Earlier quoted context omitted.

> 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…

>Javascript values programming velocity, accessibility to new programmers and simplicity.

You are joking aren't you?

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

#65

Post by deltasixeight »

sam0x17 wrote: post #61
deltasixeight wrote: post #58

Earlier quoted context omitted.

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…

> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do…

Read the 2nd paragraph of my post you replied to. You talk about true modularity and it is addressed in my second paragraph. If you find these problems with your code then the code was Never modular in the first place.

Modular code involves writing code independent of context. One way of doing this is to wrap every expression in a pure functional context. Another way is to make every variable immutable.

> I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario.

Doing this doesn't hurt. There's nothing stupid about it unless you coded everything in a way where it's NOT modular. Procedural programming is usually not modular because the results of a computation depend on the Order of the procedures. Immutable state is isomorphic to an expression so procedural code with immutable state solves the issue.

Let's say I need a function to add 3 numbers. I impliment it like this:

  addThree = func(x, y, z){ return addTwo(x, y) + z}
  addTwo = func(x, y) {return x + y}
You're saying addTwo is unecessary and pointless if it's not reused. I'm saying you can't predict the future, there may be a time where you need addTwo, but if you never need it, it doesn't really matter, you don't lose anything here. Modularity doesn't hurt the structure and organization of the code. It only effects qualitative aspects like how easy is it to interpret understand or read.

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

#66

Post by deltasixeight »

Jtsummers wrote: post #62
sam0x17 wrote: post #61

Earlier quoted context omitted.

> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do…

Right. If A and B are coupled so tightly that one cannot exist without the other, you don't really have two modules. You have one, AB. This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). The latter is particularly pernicious in languages which don't have a clear separation between classes an…

> This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module).

Exactly! The class is not the smallest unit of modularity. You unionize several pieces of mutable state with several functions (aka methods) in class based programming and if your unionization was a design flaw you're pretty much screwed. To make your code truly modular you need to break it down further. Separate state and function. To go even deeper make the function pure and make state immutable. Abstract mutability to a small unsafe portion of your code.

>The reality is that there are two (at least) kinds of modularity. "Syntactic" (I need a better name for this) modularity like Java classes, or C's translation units (why I need a better name). These act as modules, but don't necessarily define a real, proper module. And then there are your real modules which are comprised of the things that must exist together (like in the earlier example), regardless of the project structure or language's notion of a module.

The only true logic module is a stateless function that is independent of all context. Think on that, that is literally the smallest unit of logic that can be moved around anywhere.

The problem here is how do you program in a way such that even for these functions are easily de-composable and rearranged without necessitating a rewrite in the case where you find the logic needs massive changes?

Use point free programming with pure non-procedural functions solves this. The problem is mutability must happen somewhere and usually this is abstracted to a very small section of your code.

>I had a team try to convince me their code was "modular" but their GUI portion was directly tied to the DB portion and other logic. Nothing could be instantiated separately, so it wasn't really modular, it was just using the language and build system's notions of modules to create the illusion of modularity (C++ and VS in their case). In contrast, another team had developed a collection of libraries (C# and VS again) that were used in multiple applications. That was real modularity.

GUI programming is inherently hard as the state of the GUI is by nature muteable and it's hard to write modular code as a result. However modern programming frameworks generally get around this using the technique I outlined above, see React redux and MVU. https://guide.elm-lang.org/architecture/

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

#67

Post by deltasixeight »

josephg wrote: post #53
lostcolony wrote: post #40

Earlier quoted context omitted.

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 pl…

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

I don't see this as bad. Modularization protects against an uncertain future. Most code that's modularized is only used once and this Looks bad only because you haven't seen the alternative of what could have happened if code wasn't modularized.

Non modularized code is often designed wrong because of an uncertain future. Once the project is too far down the line, people just keep piling technical debt on top of the design flaw. Code is rarely rewritten until it's at a point where it's horrible than it takes a massive engineering effort to rewrite and even this rewrite could be wrong.

The alternative is code littered with modules that are used once. Which is better? Obviously the more modular code.

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

#68

Post by ratww »

neutronicus wrote: post #24
ratww wrote: post #11

> Immediately I remind myself that the implementation from the book ignores the problem of persistence completely. If you close that application it loses all the state. I think this is not an accident. This is where things go wrong for OOP really fast. This point hits hard. Managing "live" scattered state that is gonna go away when the program dies is hard in itself. But as soon as you have to persist it or do anythi…

Ha I do like how ECS and Redux have that common thread of rediscovering global state

True. There's lots of parallels between those two things and relational databases, too.

In the end it seems that the "web app with a database" is becoming the template for other types of apps.

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

#69

Post by josephg »

tonyedgecombe wrote: post #64
josephg wrote: post #57

Earlier quoted context omitted.

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…

>Javascript values programming velocity, accessibility to new programmers and simplicity. You are joking aren't you?

No, I'm not. Or at least, not as I see it.

How would you describe javascript's values, compared to other languages? This is a great chart / explanation of this kind of thinking from Bryan Cantrill:

https://www.youtube.com/watch?v=2wZ1pCpJUIM

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

#70

Post by dgb23 »

Zababa wrote: post #39
ratww wrote: post #31

Earlier quoted context omitted.

Refactoring to use them is not really hard, as they are easily interchangeable with regular classes. They are pretty much syntax sugar for this class pattern here: https://stackoverflow.com/a/63615514

That's true, but that's still a large refactoring to do, especially with going from mutability to immutability. The community might also just not like them.

On the other hand in some cases this type of refactoring might actually reveal design issues with the code, maybe even bugs.
Post reply on HN