A Better Way To Program

← Back to Stories (view on slashdot.org)

Posted by Soulskill on Sunday March 11, 2012 @07:50AM from the creativity-by-slider-bars dept.

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."

10 of 467 comments (clear)

Min score:

Reason:

Sort:

Great but... by Anonymous Coward · 2012-03-11 07:54 · Score: 5, Interesting

Seems like it mostly only applies to GUI programming or programming with results expressed through a GUI. What about, say, kernel programming?
1. Re:Great but... by viperidaenz · 2012-03-11 08:09 · Score: 5, Funny
  
  Visualise them kernel then. They didn't have any problems in The Matrix.
2. Re:Great but... by spyked · 2012-03-11 08:37 · Score: 5, Insightful
  
  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.
3. Re:Great but... by Junta · 2012-03-11 09:07 · Score: 5, Insightful
  
  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.
4. Re:Great but... by sjames · 2012-03-11 09:20 · Score: 5, Funny
  
  What about, say, kernel programming?
  If you enter a syntax error, you get a video of Orville Redenbacher ripping you a new one.
Re:Connecting to your creation in Clojure by justforgetme · 2012-03-11 08:35 · Score: 5, Informative

And here is the vimeo video for those who want to tear their eyes out when
visiting i-programmer and their 180px content column.

--
-- no sig today
Re:They invented the debugger! by ktappe · 2012-03-11 08:47 · Score: 5, Interesting

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
Re:Conjecture. by SJS · 2012-03-11 08:49 · Score: 5, Insightful

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!)
Re:An observation... by Anonymous Coward · 2012-03-11 09:00 · Score: 5, Funny

I'd guess it slips a $1 and $2 bill into a stripper's titties by the looks of it.
Re:understanding by doing... faster by Alex+Belits · 2012-03-11 09:56 · Score: 5, Insightful

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.