Slashdot Mirror
A Better Way To Program
mikejuk writes "This video will change the way you think about programming. The argument is clear and impressive — it suggest that we really are building programs with one hand tied behind our backs. Programmers can only understand their code by pretending to be computers and running it in their heads. As this video shows, this is increadibly inefficient and, as we generally have a computer in front of us, why not use it to help us understand the code? The key is probably interactivity. Don't wait for a compile to complete to see what effect your code has on things — if you can see it in real time then programming becomes much easier."
Yeeehaaa! ;)
The tough problems aren't about running the code and seeing what happens, they're about setting up very specific situations and testing them easily.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Until someone actually creates this new mythical language that is proposed by Bret, than this is all conjecture that a hyper-efficient, overly intuitive programming language that can provide immediate feedback would be hyper-efficient, overly intuitive, and provide immediate feedback.
Basically, the video referenced by the article is no different than "wouldn't it be nice if we were no longer dependent on foreign oil... that would make so many things so much easier!"
Thirty four characters live here.
Someone re-invented scripting languages ?
Religion is what happens when nature strikes and groupthink goes wrong.
If you need to "run" code, either in your head or on a computer, in order to see what it's going to do, you're probably not really programming and you're definitely not an engineer.
No sig. Move along - nothing to see here.
Unless somebody wants to give a better executive summary, there's no way I'm weeding through an hour of video. Do they have any idea how many hours there are of "the one video you must see this year" on YouTube?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
"I remember how, with the advent of terminals, interactive debugging was supposed to solve all our programming problems, and how, with the advent of colour screens, "algorithm animation" was supposed to do the same. And what did we get? Commercial software with a disclaimer that explicitly states that you are a fool if you rely on what you just bought."
From http://www.cs.utexas.edu/~vl/notes/dijkstra.html.
That sounds simple but it isn't. While you could theoretically do this from a virtual machine, the difference between visualising” it and testing it on real hardware is significant especially when it comes to device drivers, which are known to be the most common source of bugs in kernels.
Plus verifying a kernel or a compiler is a pretty hard problem, it's a miracle if you manage to do it in decent time, let alone manage to visualise it in any way.
In the video he covers that as well. Well, at least he conceptually says its covered, I disagree...
Lets start with his abstract example. His binary search on the surface looks straightforward and he wanted to portray it as magically finding bugs as he got a float in one instance and an infinite loop in another. However the infinite loop example was found because he *knew* what he was doing as he intentionally miswrote it to start with and intentionally changed the inputs in accordance with this knowledge. There are a few more possibilities that you have to *know* to try out. For example, he didn't try a value that was lower than the lowest (would have panned out), he didn't try a value omitted from the list but still higher than the lowest and lower than the highest (which also would have been fine) and he didn't try an unordered list (which is incorrect usage, but accounting for incorrect usage is a fact of life). He didn't try varying dataset sizes (in this algorithm doesn't matter, but he has to *know* that) and different types of data. You still have the fact that 'B' is smaller than 'a' and all sorts of 'non-intuitive' things inherent in the situation.
Now consider that binary search is a freshman level programming problem and therefore is pretty low in terms of the complexity a developer is going to deal with. Much of software development will deal with far more complicated scenarios than this, and the facility doesn't *really* cover even the binary search complexity.
I know I may sound more negative than is appropriate, but his enthusiasm and some people's buy-in can be risky. I've seen poor developers suckered in by various 'silver bullets' and produce lower quality code because they think that unit test or other mechanisms passed and they can reast easy. Using these tools is good, but always should be accompanied with some wariness to avoid overconfidence.
XML is like violence. If it doesn't solve the problem, use more.
So your point, basically, is that programming is all about knowing what could go wrong with your code?
Not a bad definition actually...it would certainly explain why coding productivity increases in step with experience; you've made those mistakes already and now know to avoid them.
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
It was in the firehose a few days ago and I down-modded it because (1) the idea was stupid, (2) the article did not give anything but the vaguest hand-waving of explanations, and (3) there is no way someone is going to sit through an hour video if the blogger can't even bother to provide a half-decent summary - which is why I labeled it as binspam ... it's just link bait.
Let's call it what it is, Anti-Social Media.
Most programmers think, that coding takes the most part of the development. In some cases they would admit that testing is also very time consuming. But the real issue is the understanding of the problem. A lot of programmers design while their code. This results in strange development cycles which also includes trying to understand what the program does. As this can be done with a debugger, an interpreter or a trace analysis tool. The real issue is the problem description. First, understand the problem and its borderline cases. Second, come up with a solution for that problem. And third, try to implement it.
BTW: Most programs of today do not contain that many surprising new algorithms. They collect data, the validate data to some constraints, they store data, they provide an interface to query the data. In desktop applications like Inkscape or Word the data is stored in in memory models. And there exist serializers and renderers for the content. So the code as such is not hard to understand, as we all know such structures.
That tends to be the problem with a lot of these 'rethink programming' ideas. They tend to come from people who are thinking in very specific domains and believe that their domain is the only one that matters or that its lessons apply everywhere. It gets very frustrating, esp if your domain is one that is not one of the 'hot' fields that everyone is paying attention to.
Congratulations, you are an idiot.
"Tests", no matter how numerous, cover an infinitely small fraction of possible instances of your code being used (that would be an infinite number of, unless you take into account the maximum lifetime of the Universe). They are supposed to assist a developer finding some faults in his reasoning, nothing more than that.
Contrary to the popular belief, there indeed is no God.
Agreed. I am getting a bit tired of things moving to video only. Videos are hard to skim or speed-read, you have to absorb things at the pace the speaker feels like moving at, which is usually pretty slow/inefficient.
However the infinite loop example was found because he *knew* what he was doing as he intentionally miswrote it to start with and intentionally changed the inputs in accordance with this knowledge.
It's was a demo. Demos by their nature tend to be both simplistic contrived.
He was putting across a principle in the first half of his talk and a way of life in the second. Both very valid.
From your comments it's clear that you're more of a craftsman than a visionary. There's room in the world for both.
You need to watch the video. The horizons of his thinking couldn't be wider.
TBH - at an hour of talking, no. A summary or argument with diagrams would be worth looking at, but a video? I am actually getting tired of this fad of posting videos to make a case. Very inefficient and can usually be summed up in something that only takes 10 minutes to read. I get the feeling the people who do things pieces just like hearing their own voice....
It's worth a hour. But if you don't want to watch it fine. Just don't expect your comments to be worth anything if you haven't done your homework.
And for those decrying the use of video, you'll definitely want to check out Up and Down the Ladder of Abstraction by the same author: http://worrydream.com/LadderOfAbstraction/
It's a big wall of text with interactive javascript examples and no video.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
It's worth a hour. But if you don't want to watch it fine. Just don't expect your comments to be worth anything if you haven't done your homework.
He has a point. You don't need a 1hr long video as the sole measure with which to convey a technical point. Summaries, diagrams, and/or a 8-10 page paper are also necessary. Asking people to devote one hour just to know that something is worth it, that is not how you present technical ideas or issues.
I personally am a fan of "debugging by printf." Kernighan and Pike make a good argument for it in The Practice of Programming. But, that's not limited to debugging, really. It's a great tool for understanding one's own code. Basically, whenever I want to get a greater intuition about how something works, I load it up with print statements at strategic points. I guess you might call it "understanding through printf."
I'll be honest: I didn't invest an hour of my time watching this video. How really does his technique compare to "understanding through printf"?
Program Intellivision!