Live data from Hacker News

Why Isn’t Programming Futuristic?

ianbicking.org

41–50 of 85 posts

Re: Why Isn’t Programming Futuristic?

#41
post #5

I'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…

I hate to say it, but that looks like my Smalltalk browser. Smalltalk has various built in code browsers that allow you different views of the code, your plugin behaves like one of them, the chasing browser.

Re: Why Isn’t Programming Futuristic?

#42
post #7
post #5

I'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…

I loved the CodeBubbles demo. Not for every task, maybe, but I wish I had this tool in my life. Why don't I?

Re: Why Isn’t Programming Futuristic?

#43
post #36

I dunno, I think programming is pretty futuristic. We've got live coding, futuristic platforms, fast dynamic languages, etc... Of course, the most futuristic platform is right under people's noses, the browser. It does things that old Lisp programmers imagined, like live coding, even 3D games, with sound, and even Kinect-like motion control. Live coding: http://www.mrdoob.com/projects/htmleditor/ WebRTC: http://cbate…

[deleted]

Re: Why Isn’t Programming Futuristic?

#44

Earlier quoted context omitted.

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

The iPad is the pinnacle of the marketing job of making people forget everything that came before :) But, seriously, Haskell, for example, is quite practical (better than the imperative languages) for a big set of applications. One problem is that people want a language to rule them all - and that language can only be imperative; the other problem is that people don't want to learn different things, and a new paradig…

Haskell has very good support for imperative programming.

Re: Why Isn’t Programming Futuristic?

#45
post #12
post #2

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

February 1959 for the Astounding Magazine cover: http://www.sfcovers.net/Magazines/ASF/ASF_0339.jpg

And the great story to go with the cover, delightfully relevant to many of the topics we rant about on Hacker News:

http://www.gutenberg.org/files/24035/24035-h/24035-h.htm

Re: Why Isn’t Programming Futuristic?

#46

I think the explanation for this is relatively simple: The obvious is that the low hanging fruit has been picked, so of course the rate of change is going to decrease as the problems get larger and harder to solve. The less obvious is the massive influx of users for these languages/tools. There is an unavoidable regression to the mean related to ability/willingness to expend effort that comes from that influx. In the…

Node.js is just full of Worse Is Better. I think there's a danger for more pure/forward-looking environments to look down on that, because there really is some Better in it – I think the work done to get us forward is going to have to meld Worse Is Better with Actually Better.

Re: Why Isn’t Programming Futuristic?

#47
Anyone who thinks we're using programming technology of the 70's probably wasn't programming in the 70's. Today it's routine to create systems in a handful of days that would have taken a larger team a much greater amount of time to create in the 70's, 80's, 90's, or even 00's. In fact, for years now, power users do certain kinds of applications with spreadsheets and similar tools-- without programmer intervention-- jobs that were previously handled by systems analysts and development teams.

Interfacing different kinds of computer systems together today is orders of magnitude simpler than it was even in the 90's, much less the 70's.

Sure, we're not all talking to our computers while they program themselves and driving around in flying cars. But software development technology has come a long, long way. Users are tons more empowered to do their own work now than they used to be. And the amount of knowledge and training needed to make a developer effective today is nothing like it used to be.

Re: Why Isn’t Programming Futuristic?

#48
post #7

Earlier quoted context omitted.

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…

I remember seeing code bubbles when you released it and thinking it looked much more promising than the flow-based approaches to abstracting away code files that we usually see. NoFlow and the like tend to ignore the fact that: 1) The approach has been tried countless times before and failed. 2) Programmers don't need code abstracted away. Text is great for telling a machine what to do. The real pain point is in link…

Regarding (3), I think if you need 25 feet of screen real estate in a graphical environment, then your code is probably not organized well, regardless of whether it's textual or graphical.

Regarding (1), I think we need to understand why it's been tried and why it's failed. Knowing that it's been tried before and failed should be enough to make you skeptical, but it shouldn't be enough to outright reject something unless it's a copying an old idea wholesale. That said, I think NoFlo specifically has very few new or interesting ideas.

Re: Why Isn’t Programming Futuristic?

#49
post #32
post #5

I'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…

ianap but loved the visualisation space imagined / implemented for excel calculation paths in this recent submission.. i wonder whether a similar idea (ie. for viz.. not replacing an editor) would have mileage here, or would it just be so complex as to be indecipherable? https://news.ycombinator.com/item?id=6585889

That's very similar to the effect we're trying to achieve. I was happy to see it was received well by the HN community. I think the same approach would work well in an IDE.

Re: Why Isn’t Programming Futuristic?

#50
post #17

The author never explains why all these features are desirable. Safe object traversal? Sure, reflection is a pain, but how would an improvement in this area bring us into the "future"? Also, I may have misunderstood, but isn't Lisp's object traversal about as safe as you can get? More/better ASTs? I think he was trying to say "compilers should have APIs for third-party tools". Otherwise I don't see why it matters whe…

Safe object traversal: if you can traverse objects you can start to create search algorithms (which is what Prolog's solver really is) that work across different domains and objects. I think this is a path towards goal-oriented programming.

ASTs: by representing the program in a more abstracted way, we can start to build tools that manipulate them in ways other than ASCII editors.

Direct manipulation of data: well, Bret brought this one up, not me. I thought it was a little odd. While spatial representation of code was about stretching our ASCII into something else, I chose to interpret this as stretching our concrete editing tools towards code. In other words, how do you add abstractions to concrete editing tools. I think the simplest task would be the one to start with: how do you parametrize something in a concrete data editor?

Post reply on HN