Hacker News Reader

Comment by saalweachter | Hacker News Reader

> To program any more was pointless. My programs would never live as long as [Kafka’s] The Trial.

As a programmer, I want to believe I'm a writer, a poet, a sculptor.

But the truth is programmers are dancers, mimes, ventriloquists. We're performance artists, and the systems we program really only have meaning as long as we keep programming them (or, if we're really lucky, someone else takes up the dance when we grow tired of it). Once we take our final bows, the programs will fade away and die and all that will be left is a memory of the performance.

View on HN

Programmers are really boring analogy whalers, out at sea forever hunting their perfect, elusive, bloody boring, analogs.

Call me HTML

Burritos!

I don't think this is true. Consider the popularity of emulators for older systems. People still care about and use old programs and games. You can even still buy games released 35+ years ago from online retailers like gog. Think about how old programs like ls, dd, etc are (even older when you consider the design and not just the implementation).

People still care about "Super Mario Bros" (a computer program) today, over 30 years after it's original release. Is it really going to be forgotten in the next 10 years? 20? 30? I think not. Will all emulators be abandoned?

Maybe appreciation for old computer programs is a niche interest, but let's face it, Kafka is not exactly popular among the masses either.

Most software may be forgotten, but most books will be too.

I think this would fall into the category of "picking up the dance". For some software, people don't want the performance to end, so they bring the performances to new stages, but, as soon as they stop actively "performing", the dance will end.

I find it a little sad that most modern computing will be lost to time. Early console games were easily self contained systems, and lent themselves well to emulation. Today's consoles are towers of complexity that will likely never be emulated. At best compatibility layers will be built into future systems to interoperate, the likely result is that the classics of today will continue to hobble along on a dwindling number of devices. At worst, a corporation loses interest and all their consoles immediately turn into expensive paperweights.

I disagree. It's easy today to think of the consoles of yesteryear as simple self contained systems (A 6502-based CPU? How quaint!). However, Consider the unholy trinity that was the Sega Genesis/Master System/CD/32X. Though no longer modern, that absolutely is a tower of complexity, especially when it was brand new.

The emulators of the game consoles of the past exist today because some hacker got curious and interested. Complexity certainly isn't stopping emulator devs. The Wii was more complex than the Gamecube, which was more complex than the N64, which was more complex than the SNES, which was more complex than the NES. And yet there are emulators available for all of those systems.

What is different today that would prevent an enterprising hacker tomorrow from making emulators of today's consoles?

> What is different today that would prevent an enterprising hacker tomorrow from making emulators of today's consoles?

Not a sliver of hope of access to the server-side runtime of cloud-assisted† games?

† not full-scale MMOs but Diablo III, Starcraft II, Destiny, even Guild Wars...

If they follow the example of Ultima Online they certainly will live on forever.

In many some though, they will be replaced with full conversions that gets even more popular than the original.

Emulators for old systems aren't very popular at all, compared to the general population's use of computers and computer systems. An increasingly small set of folks seeks out and builds / runs old NES or Sega emulators for the couple of games they miss from their childhood, but I'd wager a vast majority of computer system users today wouldn't even think of a gaming machine as a computer, let alone be able to be run on their modern machine.

Perhaps the myopia of computer culture is a result of our lack of evangelism for classic systems, but, outside of games, most of software deviates from literature or music in that it's a tool. If I write a better word processor, why would I go back to use a two-decades-old word processor? I wouldn't.

Same for graphics software, or IDEs, or web browsers, accounting tools, what have you. For the most part, these things go to obsolescence and there isn't a use case for dusting them off once that happens. With a book, a story is still a story whether the setting or events are modern or not. A song is still a song, whether played on harpsichord or synth tracks on a macbook.

But a piece of software is a hammer or a handsaw or an impact driver. When you have a better one, you put the crappier one away and it doesn't see the light of day again until your kids are cleaning out your garage when they move you into a retirement home.

Kafka also isn't very popular at all, compared to the general population's choice of reading material.

Old software programs can be useful. For example, consider the diehard following of older programs like Deluxe Paint, Impulse Tracker, etc.

I also don't think it's fair to compare utility the kind of utility programs that you are talking about to the works of Kafka. A novel is something designed to provide entertainment, insight, or some other benefit beyond the basic utility of a tool. I think the game is the best type of computer program to compare to a novel, in that they have the same aims.

A better comparison for the type of program you are talking about would be something like a lost pet flyer, or a personal ad, a "Caution: Wet Paint" sign, the terms and conditions for a website or even a technical manual. These are also works of writing, but probably are not going to provide much value out of their specific situation and context, save for historical interest.

So I guess the take-away is that if you want to create something that will be remembered for a long time, you have to more than just provide utility for your own specific time and situation. I think software programs are more than capable of doing that, the programmer just has to have the right focus in developing (so maybe a game, or a software art program, or a demo like the demoscene), or give the program some personality.

On the other hand utility programs and utility writing are still useful and necessary in the short term, and there's nothing wrong with that.

> To program any more was pointless. My programs would never live as long as [Kafka’s] The Trial.

I found it a touch ironic considering that Kafka, on his deathbed, asked his friend Max Brod to destroy all of Kafka's unpublished work, including The Trial.

The request was the final grand gesture.

> BORGES: "In the case of Kafka, we know very little. We only know that he was very dissatisfied with his own work. Of course, when he told his friend Max Brod that he wanted his manuscripts to be burned, as Virgil did, I suppose he knew that his friend wouldn't do that. If a man wants to destroy his own work, he throws it into a fire, and there it goes. When he tells a close friend of his, “I want all the manuscripts to be destroyed,” he knows that the friend will never do that, and the friend knows that he knows and that he knows that the other knows that he knows and so on and so forth."

As much as it pains me to disagree with Borges, Kafka had already burnt almost 90% of his unpublished work [1] before his health declined due to starvation from a then untreatable laryngeal tuberculosis.

I think Kafka did truly want to burn his work, but also feel Max Brod was right to save what he could.

[1] http://www.nytimes.com/2010/09/26/magazine/26kafka-t.html?_r...

He had burnt a lot, it's true, but that raises another question: given that he did burn a lot of it regularly throughout his life before his fatal illness, why did he not burn the remainder while healthy and instead later asked Brod (who claims to have immediately told Kafka he would not do that) to do it? Borges's reading here makes more sense; it was simply the final Kafkaesque gesture.

I prefer the term `software gardener' to `software engineer' for this reason: software is slowly created over time and requires constant care, or it will wilt and die.

I never liked this analogy. There is no such thing as software entropy - bits are bits, and the code doesn't decay with time. The only reason we have maintenance problems is because we keep changing components. If you program a box, unplug it from the Internet and leave it running, the code will continue to work until the hardware physically fails.

Programming for the on-line world is more like managing a clothing brand - everything is constantly changing around you, things go out of fashion every other month and you need to keep up or else your brand will die and get quickly forgotten.

>everything is constantly changing around you

Like an ecosystem? ;)

Well, ok. I guess my point is that programming is like gardening only if you deliberately decide to work in an environment that forces you to keep up with changes, like the Internet. Software for infrastructure can easily last unchanged for 20+ years.

I really like the ecosystem analogy.

Ecosystems have a variety of niches which change at varying paces. A shark isn't better than a finch because it is more stable on the evolutionary timescale, it is well-adapted to a stable niche. More stable niches are not better or worse than transient, quickly-changing niches, they're just more stable.

I think it is important to recognize that the stability of a niche is independent of its value or the care that should be taken filling it. A feed processor must be written carefully even though most often they only live a couple of years before the underlying need for it goes away. A compiler is of great value but without constant maintenance it will be worthless within a few years, as compiler techniques evolve, languages are restandardized, and machine architectures shift. Software written as part of scientific inquiry is frequently worthless and uninteresting after the questions being examined have been answered.

So where do security updates factor into your diatribe? You're saying bits don't decay, but to be honest it's not bits you're coding, it's logic.

When underlying shared libraries and OS gets update because of security updates, your code ages a bit. In a while it won't behave as you expect, and after long enough it simply won't work.

And let's face it - I would bet less than 1% of the people in this forum write code they would expect to reside in an unconnected box. As soon as you connect it, security updates are required/happen.

TeMPOraL's post was hardly a diatribe.

> There is no such thing as software entropy - bits are bits, and the code doesn't decay with time.

The article contains some thought that disagrees:

    > To program any more was pointless. My programs would never live as long
    > as [Kafka’s] The Trial. A computer will never live as long as The Trial.
    > … What if Amerika was only written for 32-bit Power PC? Can an unfinished
    > program be reconstructed? Can I write a program and go, “Ah, well, you
    > get the gist of it.” … But no. It wasn’t written for 32-bit Power PC. It
    > was written for eyes.

See, The Trial was written on a platform that's been around quite a while: German. And it was ported to other, fairly stable platforms, like English.

However, if you write some code from the 32-bit PPC architecture, the vast majority of 'readers' possible for your code is very, very small. And dwindling by the day. Nothing you can do! Other than keep working on the code, porting it to the latest version of the OS, architecture, platform, API version, or whatever.

You can write it in C. Bloody thing is like a particularly disgusting cockroach. I bet people can still read it in way too many years, to the extent that C can be read.

Even in C, it's not insta-portable. In the quote author's case, the UI framework was entirely deprecated, basically requiring a large re-write to use the new API, to keep the same functionality.

If you wrote some C code that ran on Mac OS 9, for example, you'd eventually be forced to upgrade, because eventually, there are no computers running OS 9 anymore.

Gary Bernhardt's "The Birth and Death of Javascript"[1] is a rebuttal to this, I think.

Effectively, imagine that a compiler, put in static-compilation mode, would link everything required to run a piece of code (the relevant windowing toolkit, all the system libraries, copies of any OS binaries the code spawns, copies of any OS binaries the code sends messages to over an IPC bus, etc.) into something resembling a Docker container, or a Unikernel VM image. Imagine, additionally, that all this then gets translated into some standard bytecode for a high-level abstract platform target that has things like graphics and networking primitives—say, asm.js. Now everything can live as long as something still executes that bytecode.

[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...

This will be really cool in the future, someday. But it's a sci-fi like talk for a reason.

(and funny enough, when I saw him give this talk, the above quoted situation is exactly what I thought of...)

Maybe it's unrealizable at the moment for x86 code. On the other hand, for random digraphs of arcade-game microcontrollers, JSMESS is doing pretty well at achieving this. :)

Language changes dramatically over time. Read English from 1000 years ago! There is a great example in "The Language Instinct" which shows a writing in English from 4 different periods in time. The oldest will make non sense to modern English speakers.

That's why I said 'fairly' stable. Compared to the length of time it takes software to change, languages are effectively immutable ;)

you have a strange definition of immutable. Language is changing rather constantly. Take an 80 year old and have them listen to a conversation between 16 year olds. I bet there are a bunch of words they don't know the meaning of.

In this analogy, you're talking about PPC specific assembly code, and I'm talking about C.

I mean, yes, this is fuzzy. It's hard to even nail down what "English" _is_, for things like what you're saying.

The broader point is that computer languages have a much smaller period of time where their particular language is spoken than human languages. We'll see if that changes in the future, but I doubt it.

Exactly. When was the last time you had to update the firmware on your microwave?

That's because it doesn't need to integrate with anything yet. Most software written now does need to integrate with many different things, especially obvious on web and mobile.

We live in such a primitive era of programming that you shouldn't compare it to printed books, but to scrubbed reusable parchment. We don't write good enough code to last. We don't have robust enough machines to keep it in service.

It's too soon to adopt a philosophical position on what it means to write code. We don't do it well enough to claim to be experts at it.

One might rebut that with an analogy to the William Gibson quote: quality programming is already here—it's just not very evenly distributed.

We write code that lasts all the time. We call it "embedded code." Satellites, nuclear power plants, microwaves, pacemakers, cars—they all run code that lasts.

Most code doesn't last, because most code doesn't need to last. It's not part of the profit-function of the business producing the code, so something else gets optimized for: ease and speed of production, say.

We can code well when there's any sort of incentive to that outweighs other incentives. It's not even a matter of individual programmer skill, only of systems engineering: having checks and cross-checks, QA reviews and burn-in testing, tolerances, etc.

Those things can happen "in the small" at the level of how individual lines of code get written, too. Maybe "we" don't know how to do that. But that's ignorance, not inability. We've never tried.

That's quality programming by today's standards. And you say it lasts, but there probably isn't a single piece of code that has lasted a full century. That's barely more than a single lifetime.

Comparing microwave code to the code I'm talking about is like comparing medieval accounting records to Hamlet. One is far more impressive than the other.

Would that be an university degree?

On my world software engineer is a synonym for what is known as CS degree.

So I can only expect it to be comparable, if gardening would be one as well.

Construction/architecture-metaphors work a bit too: They can outlive the involvement of the initial designer, many bits can be tacked on or changed, and they have some overriding functional requirements.

They especially work if you've owned and maintained an actual, physical building. You can build for the ages, but if no one patches the holes in the roof every now and again, it will rot from the inside out in a few years.

Unless you build in stone.

Even if you build in stone.

Most long-lasting stone structures are in constant decay. Without being weather sealed and maintained, they will decay and fail. Even if they are in moisture and vegetation free environment like the pyramids, they are still subject to that most basic human trait - theft.

I've seen plenty of roofless stone buildings. They're decorative but not useful.

Architecture metaphor is relevant because architecture is a mix of art and science. The same happens with software.

Very few houses become or have the pretension to be monuments. Most of them only have a mundane function: they are shelters. The same happens with software.

Very few architects are visionary enough to project an house in a different way and point a new direction. Most of them just follow the existent trends. The same happens with software.

Most houses become monuments because of historical reasons, not because they are the best ones. The same happens with software.

I see myself as a bonsai artist. Bonsai trees need to be cared for, trimmed, styled, wired, etc. They grow over time. You can change things, but you can't realistically change everything without starting again. A bonsai tree is not "done" until it is dead.

I think this is the same as software.

I generally agree, but I have been surprised. We had a bug in a program my company released in the late 90's and that bug only became apparent last year. 5-6 people contacted us for a fix (which we provided). The program was more than 15 years old and it was still in production. That surprised me and made me adjust my views of each of my software releases. They might be deployed in the field for far longer than I had assumed.

The irony is that a digital information is theoretically lossless, but in practice software and hardware changes so fast that it is one of the most ephemeral things humanity has ever created.

So if you got into programming because you wanted to create something lasting, I think you are destined to be disappointed. But then again, all human endeavor, and indeed everything in our human experience, even the seas and the mountains and the stars are all ephemeral on some time scale. As the Buddhists say, the temporary nature of things is unavoidable and neutral, it's ones desire for permanence that causes a problem.

I don't like the theory that a piece of software can't be complete. Not all software can be complete, but some simple tools (which most software should be made of) can and should be able to be finished forever, or at least asymptotically approach completeness to a degree that the distance becomes irrelevant.

A perfect, fully complete piece of software will still need adaptations: even if feature requirements never change, the underlying platform surely will.

Even a complete, self-contained system—one which never sees any changes at any level from software to hardware—will still require periodic hardware maintenance.

Even the simplest, most -seemingly- feature-complete software can and will need fixes. The best example comes from the Big Iron world, where a program which does nothing was needed: http://en.wikipedia.org/wiki/IEFBR14

Programmers are indeed like writers, but some of us get to write Beowulf, some others get to write college term papers and the rest of us lie somewhere in between.

As a programmer, I want to believe I'm a writer, a poet, a sculptor.

Nah, it doesn't have to be that way, although it often is.

We're like artists or architects, but most of what we build isn't lasting because there's little demand for that, just as many architects will never get paid to work on anything that might last. The Sistene Chapel lasted; the slums of Rome from almost any era haven't. For every artist whose work makes it into a museum, there are thousands hawking cheap prints on the streets of Paris.

Programmers can build software that will last for a long time. I know people whose programs are still running, untouched, after 30 years. We can solve problems and keep them solved. It doesn't have to be just code; papers and new algorithms can advance the state of the field. Since we're a progressive sort who really believe in the ability of our "magic power" to blow away drudgery, we love when we're able to do that: to solve a problem and keep it solved. If this is applied to code, you can get exponential growth in codebase or library or ecosystem value for a long time.

Here's the problem, though: no one is willing to pay for code that lasts. Just as most architects are building clapboard houses in the suburbs, most of us get stuck writing throwaway code because The Business won't pay for good code by giving us the autonomy and timeframes that'd enable it to exist. Of course, bad code and failed software projeects are far more costly in the long term, but executives are not a tribe known for thinking long term; most corporate climbers have the political skill to get promoted away from their externalized costs before anything can be linked to them.

In your opinion what does an organization which does pay for Sistine Chapels of code look like? It's an interesting thought experiment since presumably we're looking for the Holy Roman Empire of a company (Google? Google in 20 years? Google if they last another 20 years? Or 200?)

In your opinion what does an organization which does pay for Sistine Chapels of code look like?

That's a hard question. Until recently, people relied on institutions to set visions, take on big projects, and think to the future. Whatever you think of governments, churches, and universities, they had long-term plans and that prevented them from being too greedy or focused on the short term.

These days, individuals have more long-term vision than the corporations that they work for. Programmers can expect a fight if they want 30-40 year careers. It can be done, but you have to "steal time" at most companies to keep abreast of changes, contribute to open source, etc.

Companies are now in next-quarter mode, because it's a way to hide the fact that most companies are being looted by their executives. If you create a sense of short-term desperation and mandatory immediate focus, then people are distracted from the hands in the corporate coffers. You basically don't see people thinking further ahead than three months in most companies.

So now we rely on individuals to set the long-term course, but individuals are (coincidence of words not intended) individually effective but rarely as coherent as a well-run institution. We rely on individuals for long-term orientation because organizations no longer make themselves adequate.

> We rely on individuals for long-term orientation because organizations no longer make themselves adequate.

The flip side of that coin is that organizations are only as good as their leadership. Being able to select good leadership generation after generation has been something that has eluded mankind since the inception of civilization. There hasn't been an organization invented that doesn't eventually fall to corruption.

So, how do we create institutions that will last? It's a problem that appeals to the ego. The solution would have a much larger impact than just on tech.

> In your opinion what does an organization which does pay for Sistine Chapels of code look like?

The OpenBSD Foundation: http://www.openbsdfoundation.org/index.html

You're tying quality with being long-lasting, but is that really true? I know code that's running for over 30 years, and it's terrible. It's running because it's terrible, because nobody dare approach it and risk it breaking, because it's a flimsy column supporting the roof, and you fear it might collapse.

Reply on news.ycombinator.com