The Future of Programming (2013) | Hacker News Reader

The Future of Programming (2013)

worrydream.com

225 pointsillo66 comments

Why does everyone seem to believe this talk is about the fact that these problems were "solved" decades ago? My takeaway is that, no, these things weren't solved, they were abandoned. We got tunnel vision and decided that a handful of ideas were what programming is, rather than just a tiny subset. This talk isn't about how the early programmers were better at everything, if anything it's the opposite, that we should question their decisions and not take anything for granted.

"Do you know why these ideas, and so many other good ideas came about in this particular time period, the 60's-early 70's? Why did it all happen then? It's because it was late enough that technology kinda got to the point where you could actually kinda do things with computers, but it was still early enough that nobody knew what programming was. Nobody knew what programming was supposed to be. And they knew they didn't know, so they tried everything."

This talk is not saying that these problems were "solved" decades ago but rather, decades ago we had much better instincts and in many ways we were on the right track, and now we're not.

Except that the track we're on now was started then. Unix was created during the time period he's talking about. We've just stopped looking at the other stuff. They weren't "on the right track", they didn't have a track. That's the point: they were doing everything

One of my all-time favorite talks. The IT industry is pretty bad in general at knowing what problems have previously been solved.

Yeah. Almost every time I watch a Marvin Minsky or Alan Kay video of any kind I'm surprised with info on some awesome technology or research from the 60s or 70s.

You should also check the systems programming research that was happening on those days, NEWP already had UNSAFE blocks that required "root" blessing to be executed.

Or the IBM RISC research using PL/8.

And many other examples, lost in research papers from all those companies.

I think you'll like the discussion he had at CMU a few years back, which focused a lot on the technology side of things https://www.youtube.com/watch?v=PFc379hu--8

Also for me.

When I delve into the digitized copies of these researches, I am always fascinated by the little treasures I find out.

And by being old enough to have experimented with some of them it saddens me the amount of left turns we have taken, for some to still be happy with a plain phosphor terminal experience.

In many cases, we have to first acknowledge that the problem exists before we attempt to apply some of these solutions. I've noticed myself seeing solutions to problems that I didn't know I had, only to brush off the solution as though it were only an interesting curiosity with no real practical use. It was years later when I went back to that and realized how useful it could have been.

This was one of my professors favorite gripes. He loved to tell stories about how companies would reinvent algorithms (usually multiple times) that had been published in the 70's and 80's

The problem here is search. The problem may have been solved, but finding the relevant paper is like looking for a needle in the haystack. It doesn't help that terminology has changed during the years...

> It doesn't help that terminology has changed during the years...

As has hardware. Trivial example, but linked lists made a lot more sense in the 1970s than they do today.

The problem with the solution to the problem of search is searching for the solution to the problem of search?

> The problem here is search.

And training.

I've had to reinvent algorithms I know already exist for my hobby work because they were invented to solve another unrelated problem I'm not familiar with and phrased using domain language I don't know.

Apart from making information easily retrievable, which ironically academia at least used to be notoriously bad at, inventing an algorithm and using it effectively in an application in many cases are two very different matters.

These arguments often get handwavy rather quickly. Real-life applications have to accommodate edge cases and non-functional requirements, something a scientific paper doesn't need to account for.

That's perfectly fine. It isn't a scientist's job to worry about implementation details but those shouldn't be brushed off lightly either.

> what problems have previously been solved

And we're worse at identifying what the problems actually are.

Treasures from Alan Kay and friends can be found here: http://www.vpri.org

Do check the STEPS project: a complete system in 10_000 readable LOC.

Really exceptional.

Bret Victor can be found here: http://worrydream.com

Friends can be found here: https://harc.ycr.org/member/

Make sure to check Alan Kay's answers on Quora: https://www.quora.com/profile/Alan-Kay-11

Bret Victor is now at HARC (https://harc.ycr.org/member/) which has an interesting list of projects.

Some of the "better programming" stuff exists, programmers just don't program them because you don't need them for it.

Parallel programming didn't matter as much as long as clockrates continued to scale with transistor count. The disconnect is a relatively recent phenomena (last 10 years). There's also lots of tools beyond raw threads+locks these days.

Finding new semantics for constructing computational logic is certainly a good middle-of-the-road innovation.

The philisophical underpinnings of my own research and practice over the past decade are in constant existential friction with many of the most basic assumptions that underlie information theory. I've argued about it on here before. Since I'm terrified of general AI developing under the current power-dynamic, I haven't been too enthusiastic about contributing.

That said, a lot needs to be disbelieved-- we need an ideological grass fire on the great plans, of sorts-- before certain types of phenomenon can be reliably conjured through our electrical counting machines.

We've mistaken the representation with the thing itself, especially in the 'information sciences.' The idea of 'information' and 'data' as 'packets' presupposes the existence of a physical world composed of neatly delineated objects. While this has been and continues to be a convenient and even useful approximation of reality, it is still that-- a representation.

I've never seen this assumption questioned Im CS/IS forums. At this point, it's beyond dogma.

The unbelievable volume and density of the knowledge built in the information sciences, all of it sewn into these base assumptions of information theory, generate in the unwitting practitioner a belief considered as a hard-as-bedrock fact, always presumed but never questioned. It's confirmation bias propping up a simulacra of reality.

Like physics did last century, our latest IS works (like general AI) are hitting the hard limit on these assumptions.

What's next? Try deconstructing it yourself. That's part of the fun, and helpful in the creative process.

In the mean time It would be nice to see new ways of visualizing code and code execution, that's probably a good start.

Code in Motion – An Interstellar Inspired Visualization for the JVM - https://vimeo.com/96317948 Code Galaxies Visualization - http://anvaka.github.io/pm/ Binary data visualization - https://news.ycombinator.com/item?id=15164166

We’re still trying to crawl out of the tar pit.

https://github.com/papers-we-love/papers-we-love/blob/master...

Is anyone working on these problems, or did people just give up?

It's crazy to think that the way we create and consume software barely changed since the 60s/70s.

Commercialization and commoditization: "Why make things better when people don't care?"

Oh, people do care. Programmers are expensive, and making them more productive means more money for the bottom line.

It’s just that we don’t know how. Even designing a good text based language is very challenging, and in no way a solved problem. Something graphical and interactive has a much larger design surface, and is thus even harder to get right, especially for general purpose programming.

I don’t know that the people making the decisions care all that much. Even though programmers are expensive, most managers seem to prefer to hire a dozen programmers where far fewer would get the job done if given access to better tools. They look better leading a bigger team regardless of the teams output.

The incentive exists for the shareholders, but they are not the ones making hiring decisions and choosing tools for programmers to use.

We consume software very differently, because the we includes people like us...by which I mean that statistically to many decimal places nobody had access to software in the 1960's and in the 1970's the people who had access to software were all out in the long tail of standard deviations of a Bell Curve.

In terms of creating software, in the 1960's most was being written in Assembly and if it was written in a higher level language that language almost certainly contained a large proportion of vendor specific instructions or was entirely proprietary or machine specific. That didn't change much in the 1970's and it was only at the end of the 1980's that language standards could practically mean portable code across vendors and platforms.

Some of it even got worse.

Outside AT&T walls, strong type systems programming did actually exist.

And here are we now still looking towards to somehow fix it, and it will take several generations.

Yeah it's definitely crazy! A few people are working on this from different angles. There is research https://harc.ycr.org/project/realtalk/, side projects that explore Jupyter notebook like programming environments: https://www.maria.cloud/intro, or https://www.runkit.com; my team and I are working on https://www.clay.run: making it easier to prototype by allowing developers to write code that is instantly running without setup or configuration and 'fork' other people's code to have your own running copy.

Maria, clay and runkit look interesting - I like the quick iterations and incremental programming they allow.

But you're still writing 'text' to manipulate 'data'. An example of something fundamentally different would be if you can make programs without text. I intentionally said make not write to avoid framing the discussion. For instance why write `(circle 10)` when you can instead just draw a circle and then perhaps define processes to manipulate it? I don't mean code generation - why even have text as the canonical form that describes computation processes?

yes absolutely! I think things along the idea of programming by example like Flash Fill https://www.microsoft.com/en-us/research/video/flash-fill-fl... or direct manipulation of graphics or other objects would be very interesting. I think in order to move away from text it would be important to find use-cases where other forms of describing computational processes would give the person an order of magnitude more leverage over doing the same thing in text. The idea of programming by example would make it so that testing skills are more valuable than breaking down a process into logical steps.

Maybe I am old school, but the fact that text is easily version able and comparable means a lot to me. I use to code with two side-by-side windows, comparing the old and the new version of my program.

It's a sort of fluid evolution where I can always be in control.

It would be a hard time doing that via visual programming.

I think you are right. It's much easier to compare old and new versions of a program if they are text. But we also should remember that we developed tools like diff to work with programming in text. If instead we were using a different paradigm we could explore the equivalent of diff in that model. Merge conflicts in text are often not real logic conflicts but just re-ordering things in a text file, or formatting changes. If we used a projectional editor, one that treats code as an AST instead of just flat text like lamdu - https://github.com/lamdu/lamdu we would need to create a new way to look at the evolution of changes in the code but it could be more meaningful than just looking at text.

Also you could have a timeline that shows you what got changed instead of comparing two text files. There can be lots of ways to achieve the same goal, understanding what changed and how, than just diffing two text files.

> text is easily version able and comparable means a lot to me.

Don't you really want to do more meaningful comparisons though? I think text is a poor form for versioning and comparison because you always have to mentally extrapolate the textual diff (lines added/deleted) to the syntactic diff (functions added/deleted/modified) to the diff in effect (which logic in which systems is modified). There is no reason other forms of programs cannot also do diffs, that could be more useful.

Visual does't have to mean flowchart boxes. Even a tree structure might be incrementally better than plain text.

Syntax-aware diff for text isn't hard, but it's just not usually worth the effort because line-oriented text diff is good enough and more generally applicable.

i think that's a little off. there is no reason why visual programming cannot be version-able and comparable, and in some cases it is. labview has some facilities for this, however, i will concede they could be better.

but there is no inherent reason why text is better at this than visual programs. it's just that people haven't done it, which is the issue. everyone just assumes text is the natural way to interact with a computer, but yet most people forget they went through a lot of training, formal or informal, to get to that perspective. and one could argue that comparing text is not as good as comparing the differences between visual programs because the latter actually contains structure and relationships of how things are called more readily.

what you describe with two side-by-side windows of the same VI (i.e., function or code block or whatever) is exactly something that i have done with labview. a better visual comparator is not beyond reach.

It is probably the same reason as why books (text) are still the main medium. Movies may be more popular entertainment, and comics might be preferred by some demographics, but everybody write something, and everybody read something, being it a facebook post, a tweet, a novel or a 10-tome encyclopaedia.

Nobody says that books kinda suck and should be replaced by pictographs on papyri, but somehow many programmers at least have a phase when they think that having to program by drawing shapes could somehow be easier than writing textual code...

> books (text) are still the main medium

Geometry books don't use text as the only form of communication. Neither do books about architecture, mechanical engineering, anatomy, circuit design, etc. Imagine a world where you used only text to convey all these ideas and their relationships. Computer programming today a bit like that. Why should we assume that pure text is the best and only suitable form for representing automatic computation?

> why even have text as the canonical form that describes computation processes?

Because before you get to machine code, you’ll want to transform to an expression tree, and text is an excellent accessible way to represent that. The text form might be an IR with various graphical or other non-text (and possibly some text) source languages, though.

https://vcvrack.com

Here’s an example of visual programming. All you’re really doing there is chaining together functions and tuning parameters, but instead of typing, you’re dragging wires around and twiddling knobs.

I've yet to encounter a more precise and usable input mechanism than the keyboard. I've played a bit with drag-and-drop programming environments, and they've gotten a lot better, but it's hard to be as expressive and it's hard to be as efficient.

That said, the input in The Mother Of All Demos (https://en.wikipedia.org/wiki/The_Mother_of_All_Demos) maybe did improve over the keyboard, what with multi-button mice and single-hand cording keyboards. But it's not a setup people have engaged with much since then.

You can also imagine more effort into displaying code in a less textual manner, even if the keyboard remains the primary input. There are even fonts that do this in a small way (turning >= into ≥, for instance). But plain text has a nice advantage over these: it's always clear how to reproduce what you see. There's no hidden information. There's no display bug that renders structure invisible (except perhaps bad indentation). Text can be trusted. The one visual overlay we use – syntax highlighting – is more like a checksum than an augmentation.

Another possibility is to have a richer set of literals, like you suggest with a drawn circle. The drawn circle is not unlike any other object, it would have parameters, an in-memory and serialized representation. And it would have its own mini-editor of sorts. But how many constants do you need in a program? Not many in my experience. At first this made me think about JSX – which is modestly a more expressive form of JavaScript – but then I realized: what makes JSX special is that the code and HTML are mixed together. JSX and React are a kind of refutation of limited template systems. How do you draw a circle with size S and color C? I can express (circle 10) in concretely, but how can I express (circle (/ height 2))? The second expression is where programming gets interesting.

Sketchpad (https://en.wikipedia.org/wiki/Sketchpad) is kind of interesting here, as my impression was that what made it special wasn't just the interactive graphics but that it was a constraint-based system, where the drawn figures could be interpreted and adapt to other environments, as they had both fixed and flexible sides. In a sense you were creating models, and those models were turned into concrete drawings.

I think there's probably a better expression of programs than text, but it's going to require something more different than what we've thought of so far.

My own inkling is that the Wolfram Language might have something in it. Maybe Symbolic Calculation (https://en.wikipedia.org/wiki/Symbolic_computation) is an aspect of it. Symbolic computation has the possibility of doing something and then telling the programmer why it did what it did. Like, imagine I have some program that makes a picture:

    (repeat (i 50)
      (transpose 
        (color (circle (* i 0.5))
               (- 1 (/ i 50)) 0 i)
        (* i 10) 0)

I.e., it lays out a line of circles that grow in size and change from red to blue. Except I messed it up, I didn't get the blue argument to (color) correct. You can imagine a language where the circles weren't bitmaps, you were really making objects, and those objects know how and when they were made, they are just expansions of expressions. So I could inspect one of those overly-blue circles, and I can see the expression that made it, the value of i at the time it was made, and how each part of the expression evaluated as it formed the circle. That would be pretty nice! A graphical object is one example, but what if we could do that for all kinds of output? Maybe textual output is problem, not textual programs?

Excellent points!

> I've yet to encounter a more precise and usable input mechanism than the keyboard. > You can also imagine more effort into displaying code in a less textual manner, even if the keyboard remains the primary input.

I agree the keyboard is definitely a great 'high bandwidth/fidelity' input mechanism and I don't see it being easily replaced. Can we use it to manipulate something other than 'text files'? As a simple incremental improvement, manipulating a tree like structure directly comes to mind. I'll note that the powerful operations in most text editors already use models that treat the text as something more structured than a 'sequence of lines'.

> how can I express (circle (/ height 2))? The second expression is where programming gets interesting.

I don't imagine text being completely eliminated at all levels, but a hybrid model where you could have many views of the same 'literal'. E.g. something like http://aprt.us where you can draw an object, but then also fiddle with it's parameters in another inspector - including binding those parameters to other inputs. I imagine you'd also also have snippets of text here and there, or occasional text views of objects.

> But plain text has a nice advantage over these: it's always clear how to reproduce what you see.

This actually a valid point and I hadn't thought much about it. Perhaps the trust is just a result of the current situation where text cloning (copy-pasting) is reliable, but object cloning is either impossible or hacky. If I could drag a diagram off a wikipedia page, manipulate its parameters and integrate it with my program - that would be something.

> Sketchpad (https://en.wikipedia.org/wiki/Sketchpad) is kind of interesting here, as my impression was that what made it special wasn't just the interactive graphics but that it was a constraint-based system

Yes! Interestingly that model isn't widely used either. An interesting generalization of this could be an 'interactive' programming experience - where I try to compose two artifacts and the computer offers N options to do that composition, based on what it knows about the artifacts and known constraints. Then I narrow them down by selecting one or adding more constraints, etc. Type checking is very clunky and rigid form of doing composition that IMO forces me to do too put in too much effort of the wrong kind.

> Symbolic computation has the possibility of doing something and then telling the programmer why it did what it did.

This does sound interesting and touches on another issue I have with the systems today, that they require me to simulate the computer in my head too often (while sitting in front of a computer, ironically). I suppose light table like tools are trying to solve the problem, but there is a broader problem in that the surrounding infrastructure is not conducive to such tools - many interesting things I'd want to see are buried in secret file formats and internal in-memory structures of the compilers and runtimes.

> A graphical object is one example, but what if we could do that for all kinds of output?

Yes that would be awesome!

> Maybe textual output is problem, not textual programs?

As are 'hidden' representations that I have to mentally simulate. Ideally I want to see not just the immediate program I'm manipulating (text or otherwise) but also the implications - the affected parts of various other intermediate representations all the way to the running, live system that will be affected.

You're right, it is crazy. A few people, here and there, are trying -- but precious few.

There's a regular meetup group in San Francisco:

https://www.meetup.com/Future-of-Programming

Max/MSP has implemented some of the visual programming ideas he refers to in the talk https://cycling74.com/products/max

It is domain-specific and their current promotional material makes it look like an expanded DAW a la Ableton Live, but you can develop all kinds of software in Max, not that you necessarily should.

Check here;

https://2017.splashcon.org/track/live-2017#Call-for-Papers

Jonathan Edwards submitted something I like and HARC (checking out Sean his submission now), MS Research are doing cool things.

I wanted to go there. Next time perhaps; interesting work anyway.

Slightly off-topic but does anybody know of other great talks with a quirky theme like this, where the talk is "set" in the 70s talking about the "future" (present)?

I'll kick it off by submitting [Growing a Language] (https://youtu.be/_ahvzDzKdB0) by Guy Steele, where he speaks using only monosyllabic words and words he defines in terms of other monosyllabic (or previously defined) words.

There's the Gary Bernhardt classic "The Birth & Death of Javascript"

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

Call me naive, but I listened the entire talk thinking it happened in 1973. Then came back and after seeing the discussion realized its an act.

So definitely my wonderment and awe of it came down by several notches, as I could see how every 1/2 minutes I was exclaiming in wonder of how relevant it was to today's time. But of course when you recreate the past in the future, you can be very selective towards ideas/topics which are relevant in some way.

There is a huge disconnect between these flashy ideas and what you can actually use to create software. Showing cool ideas is great, but there needs to be interfaces that scale to complex software and a realistic way to integrate them with languages that already exist. Brand new languages with no eco system and without mature compilers backing them are not going to allow general software to be written in them.

I've been looking into the linked resources more and more of late and they reveal a perspective of computing research I find I'm really excited about.

I wonder how one can start studying and taking part in this direction of computing research.

Using slide projector in 2013. Daring.

I am pretty sure that was a conscious decision based on the subject matter.

No kidding! My favorite moment is at the beginning when he introduces the talk, then pushes the slide up to reveal the date :-D

I was not trolling rather appreciating that he did not go with the flow.

That was part of his delivery. He presented like in the 70's to make a point. Even his design is retro.

I think this attitude of "we solved these problems decades ago!" is rather naive and sometimes arrogant.

I think it's a fantastic talk, and that Bret Victor and Alan Kay are geniuses. But I feel that they both promote the idea that we definitively solved all these important computing problems years ago, and that people are just too clueless/resistant to catch on. Yes, I agree that many good ideas have been culturally "forgotten". But for the most part, the reason these great past ideas are not in use is because nobody has made them into a compelling product.

Their attitude is comparable to someone saying "oh I invented the WWW in 1985 but nobody would listen to me", or "oh I invented Twitter before Twitter but users weren't enlightened enough to appreciate it". Almost all good ideas were already had before, but they are worth comparatively little, and unlikely to catch on, until they are reified into something that people want to use.

I agree with them that probably more people should be working in certain areas (e.g. new ways of programming). But if they really had it all figured out, then why haven't they themselves made the amazing new programming language that we all use? What if it's the case that some of their ideas are good in theory, but are hard to translate into a usable product? Most people accept that execution>>idea in the world of startups, but don't acknowledge that the same may apply here.

> comparable to someone saying "oh I invented the WWW in 1985 but nobody would listen to me"

I hear there's a guy that invented EMAIL..

> But for the most part, the reason these great past ideas are not in use is because nobody has made them into a compelling product.

I think you're overestimating the market's ability to select good ideas and specifically, promote long term scientific advances. A lot of variables affect what succeeds, e.g. marketing, coincidence, network effects etc.

You cannot leave everything to the market (i.e. what people adopt) and expect great science to come from it. Many times, great science (and maths) comes from the compelling drive of people to discover and create something new. These talks are encouraging that kind of research, and I don't see them saying they 'have it figured out', but rather pointing out ideas they think should be explored more extensively.

I certainly don't think that the market selects good ideas or is sufficient to promote long-term advances. Per the bit of my comment that you quoted, I'm saying that the reason that the ideas are not in use (more) is that they haven't been incorporated into more compelling products. He feels that good ideas are not in wide use because we didn't "get" them or forgot them. I'm saying that sure, that may be part of the reason, but I think most of the reason is that certain ideas that seem good on paper are really hard to put into practice.

Quoting the talk:

> But I do think that it would be kind of a shame if in forty years we’re still coding in procedures and text files in a sequential programing model. I think that would suggest we didn’t learn anything from this really fertile period in computer science. So that would kind of be a tragedy.

Lots of people seem aware of the idea of coding without text files. There are some "visual" programming environments with traction (in the game dev world, Max/MSP). I'm even working on one myself! But there are significant downsides/challenges associated with this approach (more difficult to version control, often tied to one editor, etc.). So to his quote, the fact that we're still coding in text files may not be because we didn't learn anything, but because the idea of non-textual programming is hard to form into a product that more people want to use.

I agree with you that his talk is very valuable in terms of drawing attention to ideas that deserve more exploration, and I love the talk. It's just this one facet that I take issue with, the suggestion that the ideas haven't caught on because nobody appreciates them. His talks are frequently at the top of HN, they are widely appreciated. People have been super excited about related projects, like Light Table and Eve, and yet they haven't gotten much traction. So I think it's worth acknowledging that the problem is less idea-awareness and more compelling-implementation-difficulty.

Agreed. I fall into this trap more often than I'd care to admit. But I've comforted myself into thinking this is not limited to our field. Look at folks convinced that Romans knew how to make better concrete. Or that Damascus steel is somehow beyond current capabilities.

Are there gems that were lost in the past? Almost certainly. Could we have done better by not getting obsessed with constantly rewriting things into new languages? Debatable. My money is on not. And I hate js.

Timing can also play a huge role in the success of an invention or the widespread adoption of an idea.

If you're saying you think the talk was arrogant, I think that's a bit of an exaggeration. I just found it funny. I thought the whole format of posing as a computer engineer in the early seventies seemed clever. Parts of the talk were a bit snarky, but not Linus-Torvalds-snarky.

Was it just me or did the talk not actually cover "The Future of Programming"?

It covered the future of programming from the point of view of the past.

http://tvtropes.org/pmwiki/pmwiki.php/Main/DaysOfFuturePast

https://en.wikipedia.org/wiki/Retrofuturism

woosh

It was about "the future of programming" as it should have (or could have) been, as seen from the 70s.

"These are some good ideas. It would be kind of a shame if in 40 years [ie, today] we're still coding in procedures in text files in a sequential programming model. That would suggest we didn't learn anything from this really fertile period of computer science [...] The real tragedy would be if people forgot you could have new ideas about programming models in the first place."

"Once you grow up with dogma, it's really hard to break out of it".

Reply on news.ycombinator.com