Back To 'The Future of Programming'

theodp writes "Bret Victor's The Future of Programming (YouTube video; Vimeo version) should probably be required viewing this fall for all CS majors — and their professors. For his recent DBX Conference talk, Victor took attendees back to the year 1973, donning the uniform of an IBM systems engineer of the times, delivering his presentation on an overhead projector. The '60s and early '70s were a fertile time for CS ideas, reminds Victor, but even more importantly, it was a time of unfettered thinking, unconstrained by programming dogma, authority, and tradition. 'The most dangerous thought that you can have as a creative person is to think that you know what you're doing,' explains Victor. 'Because once you think you know what you're doing you stop looking around for other ways of doing things and you stop being able to see other ways of doing things. You become blind.' He concludes, 'I think you have to say: "We don't know what programming is. We don't know what computing is. We don't even know what a computer is." And once you truly understand that, and once you truly believe that, then you're free, and you can think anything.'"

Comments

I knew it

[ArcadeMan]

Every time some stupid colleagues of mine told me I was doing it wrong, I kept thinking they were close-minded idiots.

Turns out, I was right all along!

Re:Short version?

[oodaloop]

What, TFS wasn't short enough for you?

Hmm

[abroadwin]

Yes and no, I think.

On the one hand, it is a good thing to prevent yourself from constrained thinking. I work with someone who thinks exclusively in design patterns; it leads to some solid code, in many cases, but it's also sometimes a detriment to his work (overcomplicated designs, patterns used for the sake of patterns).

Unlearning all we have figured out in computer science is silly, though. Use the patterns and knowledge we've spend years honing, but use them as tools and not as crutches. I think as long as you look at something and accurately determine that a known pattern/language/approach is a near-optimal way to solve it, that's a good application of that pattern/language/approach. If you're cramming a solution into a pattern, though, or only using a language because it's your hammer and everything looks like a nail to you, that's bad.

Re:Hmm

[orthancstone]

Use the patterns and knowledge we've spend years honing, but use them as tools and not as crutches.

Having just watched this video a few hours ago (sat in my queue for a few days, providence seemingly was on my side to watch it right before this story popped), I can say he argues against this very idea.

He mentions late in the talk about how a generation of programmers learned very specific methods for programming, and in turn taught the next generation of programmers those methods. Because the teaching only involved known working methods and disregarded any outlying ideas, the next generation believes that all programming problems have been solved and therefore they never challenge the status quo.

Much of his talk references the fact that many of the "new" ideas in computing were actually discussed and implemented in the early days of programming. Multiple core processing, visual tools and interactions, and higher level languages are not novel in any way; he's trying to point out that the earliest programmers had these ideas too, but we ignored or forgot them due to circumstances. For example, it is difficult to break out of the single processing pipeline mold when one company is dominating the CPU market by pushing out faster and faster units that excel at exactly that kind of processing.

While TFS hits on the point at hand (don't rest on your laurels), it is worth noting that the talk is trying to emphasize open mindedness towards approaches to programming. While that kind of philosophical take is certainly a bit broad (most employers would rather you produce work than redesign every input system in the office), it is important that innovation still be emphasized. I would direct folks to look at the Etsy "Code as Craft" blog as an example of folks that are taking varying approaches to solving problems by being creative and innovating instead of simply applying all the known "best practices" on the market.

I suppose that final comment better elaborates this talk in my mind: Don't rely on "best practices" as if they are the best solution to all programming problems.

Would you happen to be an InfoSys trainer?

[xxxJonBoyxxx]

>> We don't know what programming is. We don't know what computing is. We don't even know what a computer is.

Aha - they found the guy who trains InfoSys employees.

70s yeah right!

[rvw]

The future of programming, from the seventies, it's all hippie talk...

"We don't know what programming is. We don't know what computing is. We don't even know what a computer is." And once you truly understand that, and once you truly believe that, then you're free, and you can think anything.'"

Next thing we can throw our chairs out and sit on the carpet with long hair, smoke weed and drink beer....

Re:70s yeah right!

[Zero__Kelvin]

"Next thing we can throw our chairs out and sit on the carpet with long hair, smoke weed and drink beer...."

If you aren't doing it that way already, then you're doing it wrong.

Re:70s yeah right!

[phantomfive]

The future of programming, from the seventies, it's all hippie talk...

What you don't understand is, in ~1980 with the minicomputer, Computer Engineering got set back decades. Programmers were programming with toggle switches, then stepped up to assembly, then started programming with with higher level languages (like C). By the 90s objects started being used which brought the programming world back to 1967 (Simula). Now mainstream languages are starting to get first-class functions. What a concept, where has that been heard before?

Pretty near every programming idea that you use daily was invented by the 80s. And there are plenty of good ideas that were invented back then that still don't get used much.

My two favorite underused (old) programming ideas:

Design by contract.
Literate programming.

If those two concepts caught on, the programming world would be 10 times better.

Re:70s yeah right!

[DutchUncle]

In college in the 1970s, I had to read the Multics documents and von Neumann's publications. We're still reinventing things that some very clever people spent a lot of time thinking about - and solving - in the 1960s. It's great that we have the computer power and memory and graphics to just throw resources at things and make them work, but imagine how much we could make those resources achieve if we used them with the attitude those people had towards their *limited* resources. And we have exactly the same sets of bottlenecks and tradeoffs; we just move the balance around as the hardware changes. Old ideas often aren't *wrong*, they're just no longer appropriate - until the balance of tradeoffs comes around again, at which point those same ideas are right again, or at least useful as the basis for new improved ideas.

Re:70s yeah right!

[Shados]

I'm a static language guy myself, but its important to keep in mind that different problems have different solutions.

Doing heavy image processing or transnational operations, number crunching, I/O with third party APIs, etc? Yeah, static languages are probably better.

Doing prototyping, or UI intensive work? Most UI frameworks suck, but the ones designed for static languages generally suck more, because some stuff just can't be done (well), so they have to rely on data binding expressions, strings, etc, that are out control of the language. At least dynamic languages deal with those like they deal with everything else and have them as first class concepts.

Case in point: an arbitrary JSON string, in a dynamic language, can be converted to any standard object without needing to know what it will look like ahead of time. In a static language, you either need a predesigned contract, or you need a mess of a data structure full of strings that won't be statically checked, so you're back at square one. These type of use cases are horribly common in UI.

Time for real apprenticeships in tech and not year

[Joe_Dragon]

Time for real apprenticeships in tech and not years of theory?

Patents

[Diss Champ]

One reason I had so many patents relatively early in my career is I wound up doing hardware design in a much different area than I had planned on in school. I did not know the normal way to do things. So I figured out ways to do things.
Sometimes I wound up doing stuff normally but it took longer, this was OK as a bit of a learning curve was expected (they hired me knowing I didn't know the area yet).
Sometimes I did things a bit less efficiently than ideal, though this was usually fixed in design reviews.
But sometimes I came up with something novel, and after checking with more experienced folks to make sure it was novel, patented it.

A decade later, I know how a way to do pretty much everything I need to do, and get a lot less patents. But I finish my designs a lot faster:).

You need people who don't know that something isn't possible to advance the state of the art, but you also need people who know the lessons of the past to get things done quickly.

Wow man

[jackjumper]

I need some more bong hits to fully consider this

Re:Short version?

[Alwin Henseler]

You must be new here. That "pretentious philosophical BS" is like the spark in a fuel-and-oxygen filled chamber. It ignites into a heap of comments, and those comments are the actual story. Who needs an article when you can browse +5 funny / informative / interesting and -1 trolls?

As for the linked articles, that's just a cleverly disguised DDoS botnet setup. Some figured it out, but few seem to care the /. botnet is still operating. Heck, I'm even contributing people-time to it (on top of CPU cycles).

All I know about 1973 ..

[bAdministrator]

.. is that C was seen as a major setback by Frances E. Allen and others.

It [C] was a huge setback for--in my opinion--languages and compilers, and the ability to deliver performance, easily, to the user.

Source:
Frances E. Allen
ACM 2006 Conference
http://www.youtube.com/watch?v=NjoU-MjCws4

The context here surrounds abstractions and not allowing users (programmers) to play with pointers directly (C, and later, C++), which is a setback concerning optimization, because of the assumptions/connections you make about/with the underlying machine.

If you want to learn more about the ideas of the 1960s and 1970s, I highly recommend looking up talks by Alan C. Kay ("machine OOP" which is Smalltalk in a nutshell), Carl Hewitt (actor model), Dan Ingalls, Frances E. Allen (programming language abstractions and optimization), Barbara Liskov ("data OOP" which is C++ in a nutshell), and don't stop there.

Re:All I know about 1973 ..

[bAdministrator]

The thing to get here is that there are basically two kinds of OOP, so to speak.

Here's a short discussion that covers it:
https://news.ycombinator.com/item?id=2336444

In Alan Kay land objects are sub-computers that receive messages from other sub-computers. In Barbara Liskov world objects are abstract data with operators and a hidden representation.

Kay OOP is closely related to the actor model by Carl Hewitt and others.

Liskov had her own idea of OOP, and she was not aware of Smalltalk (Kay, Ingalls) at the time. She started work on her own language, CLU, at the same time as Smalltalk was developed.

The mess at the bottom

[Animats]

A major problem we have in computing is the Mess at the Bottom. Some of the basic components of computing aren't very good, but are too deeply embedded to change.

• C/C++ This is the big one. There are three basic issues in memory safety - "how big is it", "who can delete it", and "who has it locked". C helps with none of these. C++ tries to paper over the problem with templates, but the mold always comes through the wallpaper, in the form of raw pointers. This is why buffer overflow errors, and the security holes that come with them are still a problem.

  The Pascal/Modula/Ada family of languages tried to address this. All the original Macintosh applications were in Pascal. Pascal was difficult to use as a systems programming language, and Modula didn't get it right until Modula 3, by which time it was too late.

• UNIX and Linux. UNIX was designed for little machines. MULTICS was the big-machine OS, with hardware-supported security that actually worked. But it couldn't be crammed into a PDP-11. Worse, UNIX did not originally have much in the way of interprocess communication (pipes were originally files, not in-memory objects). Anything which needed multiple intercommunicating processes worked badly. (Sendmail is a legacy of that era.) The UNIX crowd didn't get locking right, and the Berkeley crowd was worse. (Did you know that lock files are not atomic on an NFS file system?) Threads came later, as an afterthought. Signals never worked very well. As a result, putting together a system of multiple programs still sucks.
• DMA devices Mainframes had "channels". The end at the CPU talked to memory in a standard way, and devices at the other end talked to the channel. In the IBM world, channels worked with hardware memory protection, so devices couldn't blither all over memory. In the minicomputer and microcomputer world, there were "buses", with memory and devices on the same bus. Devices could write anywhere in memory. Devices and their drivers had to be trusted. So device drivers were usually put in the operating system kernel, where they could break the whole OS, blither all over memory, and open security holes. Most OS crashes stem from this problem. Amusingly, it's been a long time since memory and devices were on the same bus on anything bigger than an ARM CPU. But we still have a hardware architecture that allows devices to write anywhere in memory. This is a legacy from the PDP-11 and the original IBM PC.
• Academic microkernel failure Microkernels appeared to be the right approach for security. But the big microkernel project of the 1980s, Mach, at CMU, started with BSD. Their approach was too slow, took too much code, and tried to get cute about avoiding copying by messing with the MMU. This gave microkernels a bad reputation. So now we have kernels with 15,000,000 lines of code. That's never going to stabilize. QNX gets this right, with a modest microkernel that does only message passing, CPU dispatching, and memory management. There's a modest performance penalty for extra copying. You usually get that back because the system overall is simpler. Linux still doesn't have a first-class interprocess communication system. (Attempts include System V IPC, CORBA, and D-bus. Plus various JSON hacks.)
• Too much trusted software Application programs often run with all the privileges of the user running them, and more if they can get it. Most applications need far fewer privileges than they have. (But then they wouldn't be able to phone home to get new ads.) This results in a huge attackable surface. The phone people are trying to deal with this, but it's an uphill battle against "apps" which want too much power.
• Lack of liability Software has become a huge industry without taking on the liability obligations of one. If software companies were held to the standards of auto companies, software would work a lot better. There are a few areas where software companies do take on liability. Avionics, of course. But an

Re:The mess at the bottom

[SuricouRaven]

The whole x86/64 architecture is a mess when you get deep enough. It suffers severely from a commitment to backwards compatibility - your shiny new i7 is still code-compatible with an 80386, you could install DOS on it quite happily. But the only way to fix this by now is a complete start-over redesign that reflects modern hardware abilities rather than trying to pretend you are still in the era of the z80. That just isn't commercially viable: It doesn't matter how super-awesome-fast your new computer is when no-one can run their software on it. Only a few companies have the engineering ability to pull it off, and they aren't going to invest tens of millions of dollars in something doomed to fail. The history of computing is littered with products that were technologically superior but commercially non-viable - just look at how we ended up with Windows 3.11 taking over the world when OS/2 was being promoted as the alternative.

The best bet might be if China decides they need to be fully independant from the 'Capitalist West' and design their own architecture. But more likely they'll just shamelessly rip off on of ARM or AMD's designs (Easy enough to steal the masks for those - half their chips are made in China anyway) and slap a new logo on it.

Re:The mess at the bottom

[SuricouRaven]

Some of the problems were pointed out:
- The device access model is still stuck in the ISA age, when peripherals were just wired up to the address and data buses. That isn't how things are done now - even the PCI-e 'bus' is actually a series of high-speed serial links. This means that all device drivers have to run in kernel memory space. Stability and security problems result.

- The 16-bit 'real' addressing mode. Another relic of the past, but still can't be abandoned without breaking the boot process. Lose that, and you could lose some complexity in silicon.

- Even the 32-bit mode could arguably go. The only upside it has over 64-bit is slightly lower memory usage when there are a lot of pointers being used, and it's a real headache at the OS level maintaining two variations on every library to support both 32-bit and 64-bit programs. Lose 32-bit, and you lose a load more complexity. Also means you could lose PAE as a bonus.

- There are opcodes for handling BCD. These are just completly pointless.

Entertaining, but...

[msobkow]

It's an entertaining presentation, but I don't think it's anything nearly as insightful as the summary made it out to be.

The one thing I take away from his presentation is that old ideas are often more valuable in modern times now that we have the compute power to implement those ideas.

As a for-example, back in my university days (early-mid 1980s), there were some fascinating concepts explored for computer vision and recognition of objects against a static background. Back then it would take over 8 hours on a VAX 7/80 to identify a human by extrapolating a stick figure and paint a cross-hair on the torso. Yet nowadays we have those same concepts implemented in automatic recognition and targetting systems that do the analysis in real time, and with additional capabilities such as friend/foe identification.

No one who read about Alan Kay's work can fail to recognize where the design of the modern tablet computer really came from, despite the bleatings of patent holders that they "invented" anything of note in modern times.

So if there is one thing that I'd say students of programming should learn from this talk, it is this:

Learn from the history of computing

Whatever you think of as a novel or "new" idea has probably been conceptualized in the past, researched, and shelved because it was too expensive/complex to compute back then. Rather than spending your days coding your "new" idea and learning how not to do it through trial and error, spend a few of those days reading old research papers and theories relevant to the topic. Don't assume you're a creative genius; rather assume that some creative genius in the annals of computing history had similar ideas, but could never take them beyond the proof-of-concept phase due to limitations of the era.

In short: learn how to conceptualize and abstract your ideas instead of learning how to code them. "Teach" the machine to do the heavy lifting for you.

I think he got it wrong why we got lost ...

[Qbertino]

I think he got it wrong why we got lost.

It's not because we didn't or don't know. It's because software was free back then. Hardware was so bizarly expensive and rare that no one gave a damn about giving away software and software ideas for free. It's only when software was commercialised that innovation in the field started to slow rapidly. The interweb is where it was 18 years ago because ever since simply because people are busy round the clock 24/7 trying to monetise it rather than ditching bad things and trying new stuff.

Then again, x86 wining as an archtecture and unix as software model probably does have a little to do with it aswell. We're basically stuck with early 80ies technology.

The simple truth is:
CPU and system development need's its iPhone/iPad moment - where a bold move is made to ditch out decade old concepts to make way for entirely new ones!

Look what happed since Steve Jobs and his crew redid commodity computing with their touch-toys. Imagine that happening with system architecture - that would be awesome. The world would be a totally different place in 5 years from now.

Point in case: We're still using SQL (Apollo era software technology for secretaries to manually access data - SQL is a fricking END-USER INTERFACE form the 70ies!!!) as a manually built and rebuilt access layer to persistance from the app level. That's even more braindead than keeping binary in favour of ASM, as given as example in the OPs video-talk.

Even ORM to hide SQL is nothing but a silly crutch from 1985. Java is a crutch to bridge across plattforms because since the mid 70ies people in the industry have been fighting turf wars over the patented plattforms and basically halted innovation (MS anyone?). The sceomorphic desktop metaphor is a joke - and allways has been. Stacked windowing UIs are a joke and allways have been. Our keyboard layout is a provisionary from the steam age, from before the zipper was invented (!!). E-Mail - one of the bizarest things still to be in widespread use - is from a time when computers weren't even connected yet, with different protocolls for every little shit it does, bizar, pointless, braindead and arcane concepts like the seperation of MUA, editor and seperate protocolls for sending and recieving - a human async communication system and protocol so bad it's outclassed by a shoddy commercial social networking site running from webscripts and browser-driven widgets - I mean WTF??? etc... I could go on and on ...

The only thing that isn't a total heap of shit is *nix as a system, and that's only because everything worthwhile being called Unix today is based on FOSS where we can still tinker and move forward with babysteps like fast no-bullshit non-tiling window managers, complete OpenGL accelerated avantgarde UIs (I'm thinking Blender here), workable userland and OS seperation and a matured way to handle text-driven UI, interaction and computer controll (zshell & modern bash).

That said, I do believe if we'd come up with a new, entire FOSS hardware arcitecture "2013" with complete redo and focus on massive parallel concurrency and build a logic-and-constraint driven touch-based direct-maniplation-interface system - think Squeak.org completely redone today for modern retina touch display *without* the crappy desktop - that does away with seperation of filesystem and persistance seperation and other ancient dead-ends, we'd be able to top and drop *nix in no time.

We wouldn't even miss it. ...

But building the bazillionth web framework and next half-assed x.org window manager and/or accompaning windows clone or redoing the same audio-player app / file manager / UI-Desktop toolkit every odd year from bottom to top again appears to be more fun I guess.

My 2 cents.