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

An Experiment on Code Structure

pboyd.io

Post reply on HN
Print view View original

31–40 of 62 posts

Re: An Experiment on Code Structure

#31

Post by harimau777 »

I have a pet theory that there are two different ways that people think about and approach programs.

Group 1 likes highly decomposed programs which they feel results have clearer code since hiding the details makes it easier to focus on the behavior.

Group 2 likes to keep code together which they feel results in clearer code since the details of the implementation are readily apparent.

I suspect that these groups may correspond to the Artist versus Hacker groups in this article https://josephg.com/blog/3-tribes/. I.e. do you view writing code as primarily about expressing intent or primarily about controlling technology?

The conclusion that I draw from all of this is that these are likely fundamental differences that may even result from how different people are genetically wired to think. Therefore, I think that any solution should find a way to satisfy both groups. On the other hand, problems arise when, for example, people in group 2 dismiss the needs of people in group 1 by declaring that organizing the code is premature optimization and YAGNI.

Re: An Experiment on Code Structure

#32

Post by harimau777 »

marcus_holmes wrote: post #29

I've become a big fan of not worrying about architecture until the rewrite. The first version is always an exploration of the problem domain, and treating it as that has always made my projects go quicker. This is going to trigger some people, so here's some caveats: - there's always a rewrite. Even with perfect architecture. Usually because nobody understands the problem domain until there's been an exploration of i…

The issue that I see with this is that, even if they say otherwise during the first version, when it comes time for the rewrite the powers that be often (usually?) aren't willing to support it.

Re: An Experiment on Code Structure

#33

Post by twic »

matheusmoreira wrote: post #22
skohan wrote: post #10

Earlier quoted context omitted.

That seems like a problem for compiler optimizers to solve, not programmers.

It's actually the domain of build systems. Splitting code into as many independent files as possible gives the build system more data to work with, allowing it to compile more parts of the program in parallel only when necessary. If a file contains two functions and the developer changes one of them, both functions will be recompiled. If two files contain one function each, only the file with the changed function wil…

In C++, the experience is the opposite - a "unity build", where everything is #included into a single translation unit, tends to be faster:

https://mesonbuild.com/Unity-builds.html

http://onqtam.com/programming/2018-07-07-unity-builds/

https://buffered.io/posts/the-magic-of-unity-builds/

Re: An Experiment on Code Structure

#34

Post by cjfd »

harimau777 wrote: post #31

I have a pet theory that there are two different ways that people think about and approach programs. Group 1 likes highly decomposed programs which they feel results have clearer code since hiding the details makes it easier to focus on the behavior. Group 2 likes to keep code together which they feel results in clearer code since the details of the implementation are readily apparent. I suspect that these groups may…

I am not so sure that pitting to tendencies against each other is such a good idea. The thing is that the good programming is somewhere in the middle of all of these things because if any of these tendencies goes too far we run into problems. I think we should all be able to belong to each of these three tribes depending on the circumstances.

Re: An Experiment on Code Structure

#35

Post by MeteorMarc »

Chris_Newton wrote: post #16
userbinator wrote: post #5

According to GitHub, the totals are: backendA: 11 files, 1 directory, 799 lines (676 sloc), 23.56KB backendB: 23 files, 5 directories, 1578 lines (1306 sloc), 42.26KB It's approximately twice as big for the same functionality, and I had to spend a lot more time "digging" through the second one to get an overall idea of how everything works. Jumping around between lots of tiny files is a big waste of time and overhead…

I really don't get this fetish for lots of tiny files and nested directories, which seems to be a recent trend; I suspect it is the same kind of thinking that says all functions should be very small (without reference to whether each function provides a single meaningful behaviour). Locally, this keeps things relatively simple, but it ignores the global issue that now there are potentially many more connections to fo…

The book "A Philosophy of Software Design" should interest you then: https://www.amazon.com/t/dp/1732102201 It argues, among other things, that deep interfaces matter more than code complexity inside a module.

Re: An Experiment on Code Structure

#36

Post by Chris_Newton »

MeteorMarc wrote: post #35
Chris_Newton wrote: post #16

Earlier quoted context omitted.

I really don't get this fetish for lots of tiny files and nested directories, which seems to be a recent trend; I suspect it is the same kind of thinking that says all functions should be very small (without reference to whether each function provides a single meaningful behaviour). Locally, this keeps things relatively simple, but it ignores the global issue that now there are potentially many more connections to fo…

The book "A Philosophy of Software Design" should interest you then: https://www.amazon.com/t/dp/1732102201 It argues, among other things, that deep interfaces matter more than code complexity inside a module.

That one was the first software book I read in a while where I got to the end and felt like if I wrote a book myself then that is very close to what I would want it to say. I highly recommend it to anyone who has built up a bit of practical programming experience and wants to improve further.

Re: An Experiment on Code Structure

#37

Post by lazulicurio »

kyberias wrote: post #11
skohan wrote: post #10

Earlier quoted context omitted.

That seems like a problem for compiler optimizers to solve, not programmers.

Multiple files also seems like a problem for IDEs to solve, not programmers.

That brings to mind an interesting idea for an IDE: having one big virtual file that you edit, which gets split into multiple physical files on disk (based on module/class/whatever). Although, thinking about it, there are some languages that would make such automatic restructuring rather difficult.

Re: An Experiment on Code Structure

#38

Post by joatmon-snoo »

One thing that I've noticed in my time working in large Java server codebases is that there seem to be a number of broad categories of code (not mutually exclusive, just one breakdown, and not exhaustive):

* framework - dictating how people should do things like request handlers, how work is scheduled * feature - making something new work * wiring - the binary had this information in it in this codepath, but we also need it in this other place...

And I have found that DI tends to be the magical "will write code for you" thing that mostly replaces the third one.

Re: An Experiment on Code Structure

#39

Post by satyrnein »

clarry wrote: post #21

I wish for a future where we can have more than one concurrent view of the same code. Structure need not be derived from from mere files and newlines and a handful of semantic organizational elements (function, class, module). The current way of doing things forces us to make a compromise between prioritizing the forest over the trees, or vice versa. Programming languages are largely concerned with the trees' bark. B…

https://darklang.com/ appears to share some of those goals.

Re: An Experiment on Code Structure

#40

Post by dancek »

hinkley wrote: post #6
nemo1618 wrote: post #2

Even though the results weren't terribly illuminating, I have to give the author a lot of credit for even attempting to do a proper experiment like this. So much of our programming dogma is based on gut feelings ("it looks cleaner") rather than empirical data and peer-reviewed studies. We have very vague notions of what works, and even vaguer notions of why those things work.

I’ve come to the conclusion that half or more of the rules we have about “clean” are about avoiding merge conflicts. Few things have been consistently disappointing to me as the inability of coworkers and myself to reason about merges correctly. There are three hard things in software and merges are #3. If anyone ever figures out how to make merges Just Work, then I expect a lot of pressure toward decomposition over…

An interesting point.

I think it would be better to merge ASTs rather than text files that represent code. The annoying issues with merges are all about the text representation. When there's actually different logic changes in two different directions the merges cease to be annoying and start to require domain knowledge.

Of course getting from this hand-wavey thought to working software is difficult. Perhaps we first need to start focusing more on the tree nature of code even in the editing tools?

Post reply on HN