Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming News

A Better Way To Program 467

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."
This discussion has been archived. No new comments can be posted.

A Better Way To Program

Comments Filter:
  • Great but... (Score:5, Interesting)

    by Anonymous Coward on Sunday March 11, 2012 @03:54PM (#39319409)

    Seems like it mostly only applies to GUI programming or programming with results expressed through a GUI. What about, say, kernel programming?

  • by slasho81 ( 455509 ) on Sunday March 11, 2012 @03:54PM (#39319411)
    Here's an implementation [chris-granger.com] of Bret's ideas in Clojure.
  • by Anonymous Coward on Sunday March 11, 2012 @04:32PM (#39319645)

    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.

  • by ktappe ( 747125 ) on Sunday March 11, 2012 @04:47PM (#39319707)

    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.

  • Re:An observation... (Score:5, Interesting)

    by TuringTest ( 533084 ) on Sunday March 11, 2012 @05:51PM (#39320177) Journal

    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.

  • by MindPrison ( 864299 ) on Sunday March 11, 2012 @06:05PM (#39320277) Journal

    A few moments in my life can be considered life changing, very rare, very seldom... ...but this video was one of them. He is totally SPOT ON! Instant and LIVE feedback on programming, changes EVERYTHING.
    Let me explain where I come from, so you understand why I react the way I do to this if it sounds weird or foreign to you, but I was the kid in class who asked too many "dumb" questions, the teachers couldn't answer, I wanted to know WHY X and Y was what they where, and not just accept that they where there. The teacher wasn't creative enough to explain why, and told me to just accept that it was there....

    that made me feel dumb for 15+ years, until I actually discovered that I was smarter than any of those teachers, and had an IQ way WAY above average (yep..that explains why I didn't need manuals...duh!)

    The point of the case is, not how intelligent I am, but the way I LEARN THINGS! Such as the video demonstrates very elegantly.

    I'm a tech nerd, I have a room filled with Test-Instruments, you know...oscilloscopes, multimeters, rf-generators, spectrum analyzers etc....I don't have a heavy theoretical science background, but yet I'm very capable of building and constructing robots and advanced circuitry (much to the confusion of my educated friends), but the truth of the matter is - these instruments.. ...yes...here comes the point of the video as well... ...provided me with a VISUAL FEEDBACK ON WHATS GOING ON!

    Did you get that, slashdot audience? Visual feedback is what it's all about (to certain visual persons like me), we're no dummies because we can't just accept or visualize data inside our mind based on eg. traditional math such as you know it, but have a different...visual mind)

    Benoit Mandelbrot comes to mind....if I'm not mistaken...

    Get it?

"The one charm of marriage is that it makes a life of deception a neccessity." - Oscar Wilde

Working...