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."
Seems like it mostly only applies to GUI programming or programming with results expressed through a GUI. What about, say, kernel programming?
Here's an implementation of Bret's ideas in Clojure.
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
Someone re-invented scripting languages ?
Religion is what happens when nature strikes and groupthink goes wrong.
Yes, if only there were existing systems that worked that way. Such as the Lisp environment from 1958 or the Smalltalk environment from 1976. Such revolutionary new ideas about programming! I wonder if he will invent automatic refactoring tools next...
I am TheRaven on Soylent News
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've been doing this for years with Python's interactive prompt. I write code and test it on a line by line basis as I'm programming when working with unfamiliar libraries. The code that works is then put into a permanent file for reuse as a script or compiled to an executable for distribution to my end users.
"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.
It is the most worthless, dumbass thing I've ever had to sit through.
It's just another "wouldn't it be great if computers programmed themselves" video by someone too stupid to tie their own shoes.
I know what the code I'm writing is going to do *before* I start writing it, as I hope for the love of god most programmers do.
In fact, the biggest plague on programming ever has been this concept that changing what you want fifteen times along the way is perfectly okay and we just need to adapt methods to that idiocy. You don't need any of this crap if you just know what you want ahead of time.
It's called Python. I use the interactive interpreter to test snipets of code al the time. This makes me 4 times more productive than Java, for example.
Smalltalk and Lisp are a good example, and they show (to me) that the problem isn't the language. The hard part about programming isn't the code.
The hard part about programming is understanding and decomposing the problem. If you're not any good at that, then no matter what language you use, you're going to struggle and produce crap.
This isn't to say that languages aren't important -- different languages lend themselves to particular problem-spaces by suggesting particular solutions. Picking the right language for the problem is as important as picking the right wrench for the nut.
But there will never be a DWIM language, because the big problem is getting the programmer's brain wrapped around what needs to be done. Once that's done, what's left is only difficult if the programmer doesn't have the figurative toolset on hand.
Pick One: http://www-rohan.sdsu.edu/~stremler/sigs/sigs.html (Note - disable Javascript first!)
I'd guess it slips a $1 and $2 bill into a stripper's titties by the looks of it.
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.
You approach makes lots of sense for writing mathematical of physical code, where you have a perfect model of the world that is the basis of the problem to solve. Your ancient Slashdot ID seems to indicate that this is the kind of that you have experience with; that, or the essential infrastructure for big businesses, which is similarly model-based.
But when your program is for a specific business flow application, for which there is no model and the logic and corner cases must be elucidated from the client by showing a partially working prototype, the only way to extract all the requisites for the program is to throw in a few lines, show it to the user and ask what it's missing or how the current version is wrong, and then fix it; because the program's behavior has not been fully defined yet when the first version was written, it's d^Hrefined as a reaction of the working code.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
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.
* is a greedy "match as many as you can", and the first
So the result of -- $_ = "foo:bar:baz:qux"; s/(.*):(.*)/$2:$1/; -- would be "qux:foo:bar:baz".
Ah, arrogance and stupidity, all in the same package. How efficient of you. -- Londo Mollari