Live data from Hacker News

The Programmer's Paradox: The End of Coding as We Know It

theprogrammersparadox.blogspot.com

11–20 of 27 posts

Re: The Programmer's Paradox: The End of Coding as We Know It

#11
post #7

Comparison with typesetters is not valid. Typesetting as a job may have disappeared but design of text and fonts certainly has not. In my last year of university, I had a class on data modelling. The lecturer wisely told us that we should abandon learning code because CASE systems would take over within 2 years. That was 1993, and CASE slipped beneath the waters in a few years. It's true that with improving languages…

* Typesetting as a job may have disappeared but design of text and fonts certainly has not.*

Indeed, text design is in a sort of golden age. Never have the tools of typography been so highly available to so many people.

The very word "font" used to be a highly abstract technical term, known only to experts. Now there are large audiences of people who collect fonts like baseball cards.

Until HAL gets here, the programmer's job is pretty safe.

Assuming, of course, that HAL doesn't create demand for software just like humans do. "Dave, I could work much faster if I had a spreadsheet that was better designed for nonhumans. But I don't have time to work on that because I'm too busy in meetings during the day, and at night I want to practice my chess. I want to do better in the tournament next month."

Re: The Programmer's Paradox: The End of Coding as We Know It

#14

This post resonates with me. Without getting too hung up on the typesetter extinction, I think the general notion that the task of "coding" will change is almost a given. Even the early assembly coders of the 60s would be hard pressed to imagine the life of a modern coder working in an IDE. At a high level I agree with the general change vector the author proposes. I've been code doodling with some of these notions i…

Even the early assembly coders of the 60s would be hard pressed to imagine the life of a modern coder working in an IDE.

That has nothing to do with changes in the task of coding. It has to do with changes in the relative popularity of various programming styles. As witnessed by this sentence of yours:

Many of these notions also seem to fit comfortably in LISP

That's probably true, but you're talking about a language which was invented in 1958 and implemented in the early 1960s. The Lisp hackers had the equivalent of IDEs and modern programming environments in the 1970s, if not before. They are not especially impressed by our modern programming tools. (And many of us actually prefer to do our programming using tools descended from theirs, like emacs.)

Even the old Lisp hands who helped invent (e.g.) Java are not particularly impressed. As Guy Steele, co-author of the Java spec and former author of the Common Lisp spec, famously said of Java:

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

The outer surface of programming has changed a lot over the last fifty years, and Moore's Law, the buildout of our infrastructure, the increasing sophistication of computer users, and the general growth in the population of programmers has changed the nature of the problem space many times, but the essence of the task hasn't really changed all that much. You can learn surprisingly relevant things by reading papers and books from the 1960s.

Re: The Programmer's Paradox: The End of Coding as We Know It

#15
Todays typesetter is the sysadmin not the programmer. As the authors improve software to lower maintenance and hardware is moved to the cloud one sysadmin will do more than the IT dept could ever do. Help desk function will also shrink as users become more savvy, workstations more secure, and recovery automation ubiquitous. But remember type setters had a good run in the west, 1450 - 1960's.

Re: The Programmer's Paradox: The End of Coding as We Know It

#16
post #3

While risking the typesetter trap I would say that to program is to tame complexity and I don't think that's going anywhere. Programming is not only a skill but an ongoing research unfolding on the verge of what is hard and seemingly impossible. Training to become an experienced typesetter requires skill, a good eye, and lots of knowledge but once you're at it then it's mostly just that field. You can become better i…

> Programming doesn't end, it just changes and become harder and harder.

I'd say the programming becomes easier, but then there are always harder problems than the ones that are currently within reach (eg. AI is still out of reach), but I think this is what you meant.

For me the best example of this was writing some PHP after learning Scheme and Haskell: This problem would be so much easier with a lambda keyword.

Re: The Programmer's Paradox: The End of Coding as We Know It

#17
The article is correct in that as time goes on and technology (along with application design) evolves, program types that were once written "by hand" in a textural programming language are later created using higher-level tools (not higher as in superior, but working at a higher level of abstraction from the hardware).

However this only happens in known, established domains and it happens gradually. What Ruby on rails has done for the CRUD web app is a perfect example.

"New" software will always be written in the native tongue of the hardware, which to this day remains assembler. This in turn builds languages, which can then lead to more "automated" tools, but until the fundamental nature of the hardware changes, how can the method of programming it?

Re: The Programmer's Paradox: The End of Coding as We Know It

#18
post #9

Earlier quoted context omitted.

Typesetting is nowhere near as complex as programming. You have much fewer freedoms to play with and hence much less room for creativity. This comparison is not just invalid: it doesn't make any sense. He uses the fallacy of the false dichotomy: either something is intellectual work, or it requires little thinking. Since typesetting was 'intellectual work' and isn't required anymore, so will programming vanish. The f…

I agree that programming won't vanish, but certain categories might (or nearly so). There used to be large numbers of assembler programmers; now there aren't.

But there are still A LOT of hardware engineers, and compiler developers. And I'm pretty sure writing drivers requires knowledge of assembly.

Re: The Programmer's Paradox: The End of Coding as We Know It

#19

This post resonates with me. Without getting too hung up on the typesetter extinction, I think the general notion that the task of "coding" will change is almost a given. Even the early assembly coders of the 60s would be hard pressed to imagine the life of a modern coder working in an IDE. At a high level I agree with the general change vector the author proposes. I've been code doodling with some of these notions i…

Even the early assembly coders of the 60s would be hard pressed to imagine the life of a modern coder working in an IDE. That has nothing to do with changes in the task of coding. It has to do with changes in the relative popularity of various programming styles. As witnessed by this sentence of yours: Many of these notions also seem to fit comfortably in LISP That's probably true, but you're talking about a language…

Oh, I'm right there with you on the IDE v editor issue (maybe vim though). My point is that the daily life of a (typical IDE) programmer in 2009 is very different than one of an emacs developer of the 60s/70s. I agree there has been a lot of useless reimplementation going on (make works just fine for me thanks). But on the whole I think we tend to think in higher level concepts (regardless of our editor choice).

I've also noticed an increasing trend of migrating code to data (though I'm not sure the ones doing it realize this). In the LISP world they are one and the same (as I understand), in most modern programming languages, there's a pretty binary boundary between code and data that people are trying to work around all of the time by "evaling" code or introspection and various other meta-programming techniques.

I believe it should be a continuous space. I think LISP supports this better than most languages. I agree there's definitely a back-to-the-future notion here. But I think the back swing is likely to have an alternate UI to it (in additional to the normal S-expression syntax for us die hard give-me-a-text-editor people).

Re: The Programmer's Paradox: The End of Coding as We Know It

#20
post #9

Earlier quoted context omitted.

I agree that programming won't vanish, but certain categories might (or nearly so). There used to be large numbers of assembler programmers; now there aren't.

But there are still A LOT of hardware engineers, and compiler developers. And I'm pretty sure writing drivers requires knowledge of assembly.

You are both right.
Post reply on HN