Why Isn’t Programming Futuristic?
ianbicking.org
Why Isn’t Programming Futuristic?
1–10 of 85 posts
Re: Why Isn’t Programming Futuristic?
#2Programming is futuristic in a 1950s sort of way. There's a classic Astounding Magazine cover from the era of a guy aggressively boarding a spaceship or something with a ray gun in his hand and a slide rule in his teeth.
In other words, it's not futuristic because we're not terribly good at imagining the future.
The guts of modern computing is based on the fundamental logical architecture of Von Neumann and others, work of the 1940s and 1950s. We may be building things in software that couldn't have been imagined back then, but we're building it on structures designed back then.
Look at the iPad and modern tablet computers, in many ways the pinnacle of the modern computer movement. Then look up Alan Kay's Dynabook, which he invented (conceptually) in 1968! We're just now catching up with his vision from 45 years ago.
Re: Why Isn’t Programming Futuristic?
#3Love the quote, "Phrasing problems in solvable terms is more effort than solving them." as to why Prolog didn't take off.
I'm surprised, however, given the talk about ASTs, that the article mentions nothing about LISPS and the notion of a language being homoiconic. Lot's of really awesome stuff happening in clojure that really does feel like the future (or the awesome past reloaded).
Re: Why Isn’t Programming Futuristic?
#4I've wondered if it would take a 'non-programmer' to develop a new metaphor/representation of programming that is more futuristic. The OP has some interesting suggestions of characteristics that 'futuristic programming' would have, including safe object traversal, ubiquitous object extensions, and code transport, but these are still conceived within the paradigm that we think of programming today. Maybe programming needs an outsider to help us start over conceptually?
Re: Why Isn’t Programming Futuristic?
#5I'm of the opinion that the way we interact with code is flawed. This author touched on it when discussing text dumps. I agree with the author that little time is spent modifying large modules of code (something NoFlow[1] is trying their hand at).
However, I think these text dumps we work with should be organized differently. As it stands, we interact with code on a file-by-file basis. But any programmer knows that the execution path of a given program is rarely going to be contained within one file, and it's not going to execute from the top of the file to the bottom. Execution jumps from file to file, and programmers spend much of their time maintaining a mental model of these jumps.
I think this is the wrong way to program. I think execution path should be more easily accessible to a programmer, and they shouldn't have to navigate through function calls one "Go To Definition" at a time. This topic has become fourth year design project for myself and a few peers and we're trying to play with different representations of code on a function-by-function basis.
Here's a rough prototype we hacked together a few months ago: http://www.youtube.com/watch?v=Bm38U40HL4E
We've since integrated it into Visual Studio so as to retain Intellisense, syntax highlighting and existing plugin functionality. We're using Roslyn to gain insights into semantic information about the code.
[1] http://www.kickstarter.com/projects/noflo/noflo-development-...
Re: Why Isn’t Programming Futuristic?
#6it's slow, but i think it's happening. co-routines are starting to become popular 35 years after icon had something similar. that could be seen as step on the road to integrated search (which needs some kind of idea of sequences of results).
[incidentally, i wrote a recursive descent combinator lib that worked on generic sequences, in python. afaik no-one ever used it for anything but strings. not even for parsing binary data in comms protocols. i extended it to a regexp engine; it was hopelessly slow. one reason regexps work so well is that they're so efficiently implemented on simple sequences of bytes. the overhead of "irregular" sequences is quite something - perhaps jits will help here (although pypy didn't help me)...]
Re: Why Isn’t Programming Futuristic?
#7I'm of the opinion that the way we interact with code is flawed. This author touched on it when discussing text dumps. I agree with the author that little time is spent modifying large modules of code (something NoFlow[1] is trying their hand at). However, I think these text dumps we work with should be organized differently. As it stands, we interact with code on a file-by-file basis. But any programmer knows that t…
For this specific aspect of the problem, you'll probably find some inspiration in code bubbles, debugger canvas, and Light Table. I implemented a prototype of the former in VS before I left MSFT, it later became the basis for the debugger canvas, and then Light Table happened.
[1]: http://www.andrewbragdon.com/codebubbles_site.asp
[2]: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...
[3]: http://www.chris-granger.com/2012/04/12/light-table---a-new-...
Re: Why Isn’t Programming Futuristic?
#8I'm of the opinion that the way we interact with code is flawed. This author touched on it when discussing text dumps. I agree with the author that little time is spent modifying large modules of code (something NoFlow[1] is trying their hand at). However, I think these text dumps we work with should be organized differently. As it stands, we interact with code on a file-by-file basis. But any programmer knows that t…
For this specific aspect of the problem, you'll probably find some inspiration in code bubbles, debugger canvas, and Light Table. I implemented a prototype of the former in VS before I left MSFT, it later became the basis for the debugger canvas, and then Light Table happened. [1]: http://www.andrewbragdon.com/codebubbles_site.asp [2]: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-... [3]: http://www.ch…
Was that Codeporium? I believe Noah Richards and Chris Granger worked on something similar according this this comment: https://news.ycombinator.com/item?id=3848543
I actually saw the Codeporium .dlls kicking around inside the DebuggerCanvas package. Most of the Visual Studio interfaces lack a lot of formal MSDN documentation, which has forced me to do some novel research haha.
Edit: Oh, you are Chris Granger haha. I'd also like to thank you for the Visual Studio 2010 editor tutorials, while I have the chance.
Light Table looks fantastic, and I hope it inspires a change within other IDEs as well.
Re: Why Isn’t Programming Futuristic?
#9Programming is futuristic in a 1950s sort of way. There's a classic Astounding Magazine cover from the era of a guy aggressively boarding a spaceship or something with a ray gun in his hand and a slide rule in his teeth. In other words, it's not futuristic because we're not terribly good at imagining the future. The guts of modern computing is based on the fundamental logical architecture of Von Neumann and others, w…
Tablet computers the pinnacle? They're fairly generic from a conceptual point of view. Pretty much the straightforward logical evolution of computing, as size gets smaller and computational power gets higher.
Please don't mention the iPad as a pinnacle of anything. It is not. It is merely a rehash of old technologies packed into a slick exterior and heavily marketed. It is more a tool of social status than a utility. Compare this to the HP Compaq TC1100, which was a tablet computer released seven years before the first iPad and the specifications of which trumped those of the iPad by double.
As for being victims of a constrained Von Neumann mindset, perhaps so. On the other hand I haven't really noticed any non-Von Neumann languages that are too practical for human purposes. Languages like APL and FP are quite esoteric, compared to the straightforward, if theoretically lacking, ALGOL model.
Re: Why Isn’t Programming Futuristic?
#10For the specific case of traversing objects (well, let's say data types), I think Haskell's lens library is the ultimate modern example. In fact, I think it basically covers everything he asked for in that section and more. It's quite a large library, for better or worse, so it really is complete.
People have called it a "jQuery for data types", and that isn't such a bad description. It allows you to uniformly interact with nested records (similar to objects), collections and variants (values chosen from a known set of possibilities--sum types).
It's systematic, modular and surprisingly powerful. Of course, like many powerful abstractions--including Haskell itself--it takes a bit of up-front effort to learn, but it's more than worth it.