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

Why Programming is Difficult (2014)

joearms.github.io

Post reply on HN
Print view View original

111–117 of 117 posts

Re: Why Programming is Difficult (2014)

#111

Post by derefr »

greenyoda wrote: post #91
derefr wrote: post #60

Earlier quoted context omitted.

> Projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. Personally, I think this isn't inherent, but is just an effect of how all the current programming paradigms (procedural, functional, even logic) tend to compose features together by simply sticking more code into each node of the function graph. So code that was originally a single stream of s…

"that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order." That might be a good way of understanding the evolution of the system if you're already familiar with what the system does. But if you were a newly hired de…

I'm picturing each individual "feature patch" being defined as a file containing a set of independent per-subsystem code-migrations, the way that database-migrations are files containing sets of independent per-table/view migrations. In order to learn about one subsystem, you could probably get an IDE (I'm picturing something LightTable-like here) to "pull out" all the relevant migrations that went into that particular subsystem, and just read them in order†. Each one would be presented with a bit of surrounding context for the feature-patch that introduced it, the way regular commits are presented with surrounding context from the file they affect.

So, rather than staring at a function's git-blame trace together with commit history to try to deduce a reason for each of the (likely uncommented) lines in it to exist, you would instead just see that the function started simple, and then there was a feature-patch for feature Foo that added lines 1, 5, and 7 to the function, which all reference a global variable $Foo that was also defined elsewhere in the same feature-patch. Etc.

One of the big problems with "only having the diffs" is being unable to know what they add up to: usually, the only way to tell what "flat schema" a set of DB migrations add up to is to run them against a real RDBMS and then dump the resultant schema. But again, with a LightTable-like editor, I could easily imagine each feature-patch being presented together with the "generated context" of what the resultant function looks like at that point in the code's history—or what it looks like now—with that feature-patch in play. You could tweak the feature-patch, save, and the code in the other pane would auto-update.

---

† One interesting thing is that there would definitely be times where a particular subsystem got a feature added, and then removed when it became unnecessary or was obviated by another feature. The feature might persist in other places (so you wouldn't git-rm the entire feature-patch that introduced the feature) but rather than seeing a complete feature history for some subsystem Foo (+A, +B, -A), it would be useful to be able to get an "abridged" summary of Foo that just introduces feature B and pretends feature A never happened.

Both views would have their purpose; the abridged view would be more useful for first learning the subsystem, while the unabridged view would be more useful for understanding the codebase as a whole, since you could see why, for example, there are two logging systems in play—it would be clear in unabridged view that one is in the process of replacing the other, but there are some subsystems where the newer one hasn't yet been introduced.

Re: Why Programming is Difficult (2014)

#112

Post by TheOtherHobbes »

derefr wrote: post #111
greenyoda wrote: post #91

Earlier quoted context omitted.

"that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order." That might be a good way of understanding the evolution of the system if you're already familiar with what the system does. But if you were a newly hired de…

I'm picturing each individual "feature patch" being defined as a file containing a set of independent per-subsystem code-migrations, the way that database-migrations are files containing sets of independent per-table/view migrations. In order to learn about one subsystem, you could probably get an IDE (I'm picturing something LightTable-like here) to "pull out" all the relevant migrations that went into that particul…

That's a very interesting idea. It's related to something I've been thinking for a while, which is that one of the deep problems with code is that it uses the same symbolic languages to define a set of domain-specific abstractions and to create logical processes that manipulate those abstractions.

This sounds like it shouldn't be an issue, but in fact it's a terrible state of affairs, because abstraction design - i.e. domain modelling - is in no way the same as process design.

It's why you get feature patches for Foo that add a couple of lines to handle some tiny little edge case. The patch works procedurally - as a little blob of disconnected logic for one specific case - but it isn't really part of the main abstraction model.

Repeat that a few times and you don't have an abstraction model any more - you have a library of epicycles and special cases, and the conceptual equivalent of what used to be called spaghetti code. Or a machine with a lot of spare cogs all over the floor: they're all needed, but they're not connected how they should be.

A system like the one you're suggesting specifically highlights intent and context, which can bring you back to the abstraction level and help minimise diff confusion.

It's strange that devs often have to build systems that create and handle metadata, but there's been hardly any research into making code more legible with supporting metadata and context.

Re: Why Programming is Difficult (2014)

#113

Post by js8 »

nickpeterson wrote: post #48
mbrock wrote: post #2

In my experience, the overwhelmingly most difficult thing about programming is writing code that makes sense, even after it has gone through a couple rounds of requirements changes and bug fixes. Any concrete coding task can be dealt with straightforwardly enough, but projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. The idea of composability i…

One thing I really liked about the DDD idea of ubiquitous language was that you reduce the amount of artificial abstractions between domain experts and the code, and it forces developers to be able to converse better with the business. I also think we should be doing a much better job documenting the intent of an entire system. New features get added by working them into the narrative of the 'Document of Intent', rat…

I recently thought that there should be 10-times rule for good documentation. So, every line would be documented (best if self-documented), every 10 lines (which is roughly a function), every 100 lines (a class?), every 1000 lines (a module), and so on until you got to the top of the system. But it's an awful lot of documentation to maintain.

Re: Why Programming is Difficult (2014)

#114

Post by EvanPlaice »

derefr wrote: post #111
greenyoda wrote: post #91

Earlier quoted context omitted.

"that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order." That might be a good way of understanding the evolution of the system if you're already familiar with what the system does. But if you were a newly hired de…

I'm picturing each individual "feature patch" being defined as a file containing a set of independent per-subsystem code-migrations, the way that database-migrations are files containing sets of independent per-table/view migrations. In order to learn about one subsystem, you could probably get an IDE (I'm picturing something LightTable-like here) to "pull out" all the relevant migrations that went into that particul…

This is a topic is rarely talked about because maintaining history and attribution is valuable.

The 'easy' approach is to split the codebase up into modules that can be versioned independently.

A more extreme approach would be to store the previous history away as a separate branch and squash related changes with the log referencing the commits that make up the aggregate.

Feature branches accomplish this to some degree and it's not unusual for OSS maintainers to request that added features get squashed but they also tend to dispose of the branches that contain the more granular history of changes.

Re: Why Programming is Difficult (2014)

#115

Post by rapind »

nly wrote: post #81
mbrock wrote: post #24

Earlier quoted context omitted.

Yeah, practical and cultural shifts determine how the theoretical foundations come into play. Ten years ago, if you said you were into functional programming, most people wondered if you were crazy and why you didn't just program in a real, normal language. Fifteen years ago, garbage collection was considered slow and mostly only suitable for "scripting." Twenty-five years ago, there was Haskell, Erlang, Common Lisp,…

The matters from each era you mention haven't become any more agreed upon... the hype bubbles just evaporated and reformed elsewhere. Nobody became wiser, the landscape just changed. And, you know, it's probably more interesting to look at the landscape than the architecture anyway. The 70s brought us computing, the 80s brought us networking, the 90s brought us eCommerce, the 00s brought us social and mobile. I don't…

If I had to guess I'd say IoT (yeah the hype is real, but there's some good stuff in there).

Re: Why Programming is Difficult (2014)

#116

Post by gozur88 »

soared wrote: post #107
gozur88 wrote: post #62

Earlier quoted context omitted.

Why does something come next? Maybe we're already doing it right.

Step 1 in grinding innovation to a halt: Assume you're right and can't be improved.

Not at all. I just think it's unreasonable to assume just because some arbitrary time period has passed we ought to be doing something different.

Re: Why Programming is Difficult (2014)

#117

Post by hyperpallium »

mbrock wrote: post #2

In my experience, the overwhelmingly most difficult thing about programming is writing code that makes sense, even after it has gone through a couple rounds of requirements changes and bug fixes. Any concrete coding task can be dealt with straightforwardly enough, but projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. The idea of composability i…

Also, just normal efficiency and error handling tend to obscure the basic idea of code. Keeping a commented-out copy of the original can document the basic idea.

Or, it's epicycles within epicycles until a paradigm shift to a simpler theory. Though most real-world programming goals are not intrinsically simple, but a mish-mash of mess.

Post reply on HN