11–20 of 85 posts
When I first encountered computer programming, we were still using line numbers. Now, about 20 years later, we've got Python and Ruby and Haskell and ubiquitous GC and… so many frameworks.
Programming is more futuristic than ever, and the tools available are continuing to evolve.
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'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…
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 linking pieces of relevant text, something that OOP does pretty successfully, but still leaves some room for improvement.
3) Nobody has 25 feet of screen space to see an entire program on, and scrolling around over giant flows is a huge PITA.
4) Attempts to solve the screen real estate issues through collapsable nesting of flow paths usually lead the same incomprehensible rat's nests of logic that regular old code does.
5) Business people don't want to code, despite their fantasies of kicking all the expensive programmers to the curb. Computers usually do exactly what you tell them to, and talented programmers are different than your typical business people in that they have a knack for taking high level requirements and turning them into highly complex, low level implementations. Someone who has no interest in this sort of work will ever be any good at it IMHO.
6) Building flows requires 99% of the implementation to already be complete. Stringing together prebuilt modules with if/thens is not that difficult or unreadable in textual code anyway.
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…
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 more than heavily marketed dribble; it was actually usable when compared to the TC1100, and basically "realized the dream" of tablet computing when predecessors couldn't: specifications are shit, usability is king. Engineers often don't get that.
> 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...
CUDA dominates the HPC world right now; MapReduce dominates big data processing. Vector machines and data-parallel pipelines have won big in their own domains. And I'm not even going to talk about relational database, all of which are very non Von Neumann computing models and have been very successful.
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).
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 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 the exact same inputs, gives the exact same outputs, and does it all in... 35 milliseconds.
With the complexity of the algorithm and size of the dataset I am pretty sure it would have taken a mainframe the size of a warehouse and weeks to compute back then, but it showed me that the underlying data structures and mathematics have not changed in the least.
I have always tried to take it to heart that "we stand on the shoulders of giants" and all that, but this was really a turning point for me over the last few weeks, that many of the greats from the past would make us all look like morons if they were around today.
There are implementations of this algorithm in C, C++, Java, Python, Javascript, and probably others, but they are all at least an order of magnitude slower than the one that came out back then, given the same modern hardware, even in a language that is not exactly known for its computational prowess.
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 whether the compiler builds an AST or not.
"Direct manipulation of data" as coding? First of all, what does this even mean, and how is it better than the current standard of ASCII files? The author dismisses graphical programming languages as being too heavily focused on "symbolic manipulation". I'm guessing he's talking about LabVIEW, which is admittedly horrendous. But there are others. Blender's node-based shader system[1] fulfills many of these seemingly arbitrary wish-list items. It's easily accessible via Blender's Python API, it has a clearly visible AST, it's deterministic and massively parallel...
In short, I'm confused and unconvinced that the future envisioned in this article is better than what we have now.
[1] http://www.blender.org/development/release-logs/blender-242/...
"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 developed programming environment."
The MOP?
Are we doomed to keep on asking these questions again and again? An IT curriculum should include at least one unit where students are required to study the history of these things and write an essay.
A lot of these points look like they're solved by Clojure, but Clojure is my hammer, so perhaps it's cognitive bias that these look like Clojure-shaped nails.
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…
