Let’s Get Excited About Maintenance • Hacker News Board

Re: Let’s Get Excited About Maintenance

#111

Post by marcosdumay » Mon, Jul 24, 2017, 5:18 PM UTC

Mathnerd314 wrote: post #105

kerkeslager wrote: post #86

Earlier quoted context omitted.

This is a product short tenures: software developers switch jobs every 18 months on average, so they don't get to see the long-term effects of their decisions. This leads to decisions with big payoffs in the short term that come back to bite you in the long term. Some examples: 1. Pervasive, maximal frameworks that favor terse magic over clear explicitness. At first this allows you to spin up a website in a few lines…

Global state is actually a good model, see https://awelonblue.wordpress.com/2012/10/21/local-state-is-p... . The issue is more one of fragmentation; figuring out which file(s) / method(s) are responsible for some item of state can get to be impossible without a powerful debugger, and constantly changing frameworks / libraries don't help.

Whatever this article is talking about, it is not what most developers mean when they say "local state".

For a start, one does not persist "local state", and this is a clear give-away:

> state cannot be cheaply recomputed or regenerated like other live values

The author seems to be arguing against a global state encapsulated into a tree of disjoint accessors. And his solution:

> our programs become stateless logics manipulating a stateful substrate

Is verbatim the FP-way of avoiding working on global state.

Re: Let’s Get Excited About Maintenance

#112

Post by tbrownaw » Mon, Jul 24, 2017, 9:00 PM UTC

s_kilk wrote: post #93

saltyworker wrote: post #85

Earlier quoted context omitted.

The fact that you need a sexy word is indicative of _human nature_

If it were something utterly intrinsic to Human Nature, there would be no opposition to it.

Reproduction is intrinsic to all life -- yes, including us humans -- and yet there are people who oppose it.

Re: Let’s Get Excited About Maintenance

#113

Post by akkartik » Tue, Jul 25, 2017, 8:01 AM UTC

lmm wrote: post #106

akkartik wrote: post #102

Earlier quoted context omitted.

Getting more users for x certainly helps mature it. However, making it a library also tends to freeze it. So ideally we'd have ways to encourage people to use something without guaranteeing its interface. I think this is a social problem; we need more libraries that have signs on them saying, "alpha software, compatibility not guaranteed," and we need greater awareness among developers that this is a good thing, that…

Agreed. But I think the idea of listing and cutting down your dependencies (which is what I understood your post to be suggesting) is contrary to that; rather depending on a huge number of tiny libraries makes it easier for libraries to evolve more flexibly.

In general I don't see the connection between the size or number of dependencies and how easy they are to evolve. Truly tiny libraries like left-pad have trivial implementations. Why not just inline them into your project? Then they're no longer libraries, just functions. You get the abstraction benefits, but you don't need to enter into a counter-party relationship with the author.

At scales above the absolutely trivial I think libraries evolve more flexibly based on social rather than technical considerations. It's about not pissing people off when you change the interface. Even something as complex as Go was able to make incompatible changes pre-1.0.

Re: Let’s Get Excited About Maintenance

#114

Post by lmm » Tue, Jul 25, 2017, 9:37 AM UTC

akkartik wrote: post #113

lmm wrote: post #106

Earlier quoted context omitted.

Agreed. But I think the idea of listing and cutting down your dependencies (which is what I understood your post to be suggesting) is contrary to that; rather depending on a huge number of tiny libraries makes it easier for libraries to evolve more flexibly.

In general I don't see the connection between the size or number of dependencies and how easy they are to evolve. Truly tiny libraries like left-pad have trivial implementations. Why not just inline them into your project? Then they're no longer libraries, just functions. You get the abstraction benefits, but you don't need to enter into a counter-party relationship with the author. At scales above the absolutely tri…

My sense is that smaller libraries are more able to evolve at their own place - e.g. the separation of django-rest from django core, or languages moving more things out of their standard library. Pre-1.0 is the easy part, we'll see how Go does is 5 or 10 years once it has a base of programs to maintain compatibility with - I predict it will find it harder to evolve and its library will fall behind.

Re: Let’s Get Excited About Maintenance

#115

Post by fa » Tue, Jul 25, 2017, 2:24 PM UTC

xamuel wrote: post #37

liveoneggs wrote: post #3

(tangentially related to this article) I have recently come to realize that, at least in my world, source code older than five years is basically doomed. Developers simply refuse to work on it. The code that makes it to five years is extraordinary as most of it "dies" before reaching the eighteen month mark. As a result I have recently been shifting my view to support replace-ability vs maintainability whenever possi…

>not totally sure how to achieve it [replaceability] One of the most crucial keys is: make your code greppable . For example, don't treat OOP classes as a license to use generic method names ("add", "set", "close", etc.), or it'll be difficult to weed those classes out.

Xamuel, where did your old blog go? The one where you talked about Esperanto as a gateway language to get people over their fear of learning a new language? I try to cite it regularly but it’s offline and Wayback Machine is giving me lip. (Sorry to barge in on this thread, I hope it’s the most reliable way to get to you.)

Re: Let’s Get Excited About Maintenance

#116

Post by [deleted] » Thu, Jul 27, 2017, 1:33 PM UTC

jtraffic wrote: post #33

I agree with others on the thread that "maintenance or innovation" is a false dichotomy. In particular, I think we need innovative maintenance. For e.g., this article about new ways to fix potholes: https://www.economist.com/news/science-and-technology/217003...

[deleted]