Live data from Hacker News

The Future of Programming (2013)

worrydream.com

61–67 of 67 posts

Re: The Future of Programming (2013)

#61

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...

Re: The Future of Programming (2013)

#62

Earlier quoted context omitted.

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 runni…

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 perha…

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?

Re: The Future of Programming (2013)

#63
post #52

Earlier quoted context omitted.

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 perha…

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 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.

Re: The Future of Programming (2013)

#64
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

Re: The Future of Programming (2013)

#65

Earlier quoted context omitted.

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 perha…

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 an…

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.

Re: The Future of Programming (2013)

#66

Earlier quoted context omitted.

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 perha…

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 l…

> 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?

Re: The Future of Programming (2013)

#67
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.

Post reply on HN