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.
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.
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.
another way to phrase it is at least one of the specific situations needs to be the input of a random number generator doing crazy stuff.
Your Arabic to Roman numeral converter accepts a INT? Well it better not crash when fed a negative, or zero, 2**63-1 (or whatever max_int is where you live), and any ole random place in between
This is still archaic thinking. A much more efficient way would be for the IDE to, when specifying a variable, ask there & then what the boundaries of the variable should be. Then the compiler could error any time it saw a situation where the variable could be (or was) handed a value outside those boundaries. Programmers should not be having to catch weird situations over and over; that's what computers are for. Allowing a variable to be any possible INT/FLOAT/REAL just doesn't make any sense in many situations so I'm quite curious why we're still having to even talk about random number generators for debugging & testing. It feels like we're still working for the computers instead of the other way around.
"We can categorically state we have not released man-eating badgers into the area." - UK military spokesman, July 2007
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.