Why Isn’t Programming Futuristic? • Hacker News Board

Re: Why Isn’t Programming Futuristic?

#31

Post by nly » Thu, Oct 24, 2013, 1:39 AM UTC

hackula1 wrote: post #16

beat wrote: 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…

I recently had a need for an algorithm that did some pretty complex geographical data interpolation that was faster than the existing implementations. The modern vendor library I was using took about a minute to compute. I searched through some old archives and found a scanned in PDF of the algorithm I wanted to implement from a late 60s fortran implementation. I converted it to node.js and Presto! The thing takes th…

Don't be shy. Give us the names of the slow and fast algorithms

Re: Why Isn’t Programming Futuristic?

#32

Post by cam_l » Thu, Oct 24, 2013, 1:39 AM UTC

Permit wrote: 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

Re: Why Isn’t Programming Futuristic?

#33

Post by JackMorgan » Thu, Oct 24, 2013, 1:59 AM UTC

krosaen wrote: post #3

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

Right, any lisp is basically a readable (and with macros dynamically editable) AST. The author even suggests XML as a possible format, which is significantly more difficult to read and edit than simple s-expressions.

Checkout this article for more about lisp s-expressions vs XML. http://www.defmacro.org/ramblings/lisp.html

Re: Why Isn’t Programming Futuristic?

#34

Post by ChuckMcM » Thu, Oct 24, 2013, 2:28 AM UTC

krosaen wrote: post #3

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

Or Forth. One to the powerful abstractions there is that you can only write a program using the vocabulary offered by its semantics. So a simple core allowing more complex constructions allowing for expressing solutions to a problem that is expressed in the same syntax.

For me though this really comes together as a knotty problem in hardware description languages. They are also a great place to start on the problem because hardware is pretty easily specified as a 'problem'.

Re: Why Isn’t Programming Futuristic?

#35

Post by einhverfr » Thu, Oct 24, 2013, 2:35 AM UTC

beat wrote: 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…

I think one of the easy mistakes is to think of the future as a mere progression of the past. This question of futuristic programming inevitably comes back to transcending current limitations of computers. But those limitations haven't really changed in the last thirty years (or perhaps longer). The same fundamental problems exist in all times and eras.

Perhaps these are the wrong limitations. Perhaps the limitations that really matter is how we think about programming. The discussion of sequential vs parallel programming comes to mind.

But it is one thing to think about programming as single threads which follow nice, clean flowcharts, and seeing the program as multiple threads woven or knitted together in complex ways. This isn't necessarily parallel programming, but it can range from things like Aspect-Oriented Programming to moving to asynchronous parallel programming and distributed systems.

But if we recognize this then maybe the solutions in the past, as inadequate as they were, were striking out in useful directions. Thus I am a fan of a sort of back to the future approach where we look sympathetically on discarded solutions for inspiration to future problems.

Re: Why Isn’t Programming Futuristic?

#36

Post by Mikeb85 » Thu, Oct 24, 2013, 2:38 AM UTC

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://cbateman.com/demos/head-coupled/ (needs well-lit room to track your eye position) 3D: http://patapom.com/topics/WebGL/cathedral/index.html

And of course there's plenty more that can be done. People tout an IDE like Lighttable, which of course uses web technology to accomplish everything special it does.

Edit - and as ugly as Javascript is, it's pretty powerful. Has all the power of Lisp/Scheme, beat with a C-flavoured ugly stick for awhile, enhanced with advanced runtimes (V8), and transformed by transpilers/compilers, is even used to represent bytecode (asm.js) and emulate other platforms (http://fir.sh/projects/jsnes/ and http://copy.sh/v24/)

Edit2 - and of course, Smalltalk in the browser: http://amber-lang.net/ and a Lisp machine-type thing in the browser: http://alex.nisnevich.com/ecmachine/

Edit3 - WTF how did I not see this... http://idflood.github.io/ThreeNodes.js/public/index.html

Re: Why Isn’t Programming Futuristic?

#37

Post by minor_nitwit » Thu, Oct 24, 2013, 2:47 AM UTC

freshhawk wrote: post #24

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…

Here's a good article on disfluency and why it causes resistance to new things. http://www.edge.org/conversation/disfluency

Re: Why Isn’t Programming Futuristic?

#38

Post by Jtsummers » Thu, Oct 24, 2013, 2:59 AM UTC

vithlani wrote: post #18

This is a sad discussion -- both the essay and here. Nobody has bothered to look back in history. "You need to be able to inspect and traverse objects, all objects." Smalltalk? Lisp Machines? "There also must be a culture where proper extensions are regularly provided on objects. Powerful tools are built on powerful paradigms, and enabling a paradigm isn’t the same thing as actually implementing it across a fully dev…

Lisp and Smalltalk are not on the standard curriculum at most US schools. I know that GT used to offer an OO course (speaking of abandoning history, can't view old course webpages past 2008, and new ones are apparently hidden behind a student only portal) which used Squeak, it was a co-requisite of Software Engineering (circa 2003, don't know how it's changed since because I can't get to the pages). I wasn't introduced to lisp until I took a special topics course that used Common Lisp for AI in grad school. Ok, technically I used scheme before then in a survey of programming languages course, but 2 weeks exposure hardly counts. For various reasons I left GT about that time, and finished up elsewhere. I do know that in 2002 (2001?) they introduced scheme for CS 1301 (whatever the number changed to), but dropped it for python later (cheating scandal that year, something like 200 students caught in CS 1 and CS 2).

Speaking of, that PL course was probably the closest to a CS history course that I ever took. The only other courses that came close were ones where I deliberately sought out papers on algorithms (AI, graphics) that had been developed in the 70s/80s relevant to projects I was working on. Other students just brute forced their solutions taking advantage of the much faster hardware available at the time.

Re: Why Isn’t Programming Futuristic?

#39

Post by rsl7 » Thu, Oct 24, 2013, 2:59 AM UTC

I'm doing some serious development right now for the first time in 12 years, and it's way more fun and much easier to work with a geographically dispersed team than it ever was before. It may not be hand-wavy object magic.. but let's be real about this: we're not a future-oriented culture anymore. We're all about the present. Lots has been written about this elsewhere.

The secret to creating advanced tools is to minimize the magic. Crazy powerful tools still require the expert user to have a predictive mental model of what is really going on so that accurate decisions can be made and valuable experiences can be accumulated on the learning curve.

I would say, though, that the programming we do is by its very nature futuristic. So few humans have been able to interact with information the way programmers today do. The tool churn and huge volume of ideas and trials that we're going through will, eventually, become a mainstream way of working with ideas. It may take a long time.

The other thing is.. a hammer may seem like a simple and obvious tool, but there is still a huge gap between an expert and a novice when it comes to pounding nails. You still need a lot of practice.

Re: Why Isn’t Programming Futuristic?

#40

Post by ianbicking » Thu, Oct 24, 2013, 3:02 AM UTC

vithlani wrote: post #18

This is a sad discussion -- both the essay and here. Nobody has bothered to look back in history. "You need to be able to inspect and traverse objects, all objects." Smalltalk? Lisp Machines? "There also must be a culture where proper extensions are regularly provided on objects. Powerful tools are built on powerful paradigms, and enabling a paradigm isn’t the same thing as actually implementing it across a fully dev…

Smalltalk, what of it? I've never used a Lisp Machine, but I did go through a Smalltalk phase. Smalltalk doesn't identify between safe and unsafe method calls, for instance. So sure, you can safely get the underlying instance variables of an object, just like Python's obj.__dict__. But you can't traverse into external structures, you can't use the standard getter methods since you don't know what's a getter and what causes modifications.

And the meta-object protocol is exactly what I'm talking about: extensibility without ubiquitous useful patterns. The MOP might (maybe) be helpful in implementing a prototype, but it wouldn't by itself create a system where goal-oriented traversal and search across an application was possible.