Fixing the Pain of Programming 294
An anonymous reader writes "Light Table is a Kickstarted, open source IDE that's been trying to integrate real-time feedback into code creation. Part of their process has been figuring out how to improve the practice of programming, from top to bottom. They've put up a post about the troublesome aspects of programming that we've learned to deal with and take for granted, but which need solving if programming is to be made accessible for more people. 'Surprisingly, one of the most common difficulties we have heard from beginners is just running code. Even if we were to hand [a new programmer the whole source code] they would likely still struggle to actually use it. They have to install dependencies, compile code, start servers and open ports. At each step the errors are difficult to diagnose and time-consuming to fix.' But these problems extend to experienced coders, too: 'The simplest question we could ask about our application is "what is the current state." Bizarrely, very few programming environments give you any help on this front. Many programmers get by with nothing but print statements.' It's interesting to see somebody working on these issues, instead of accepting that they're the status quo and just part of the experience of programming."
Re:Debuggers (Score:4, Funny)
People who work with trivially-simple applications and never have to deal with someone else's legacy mess will never be any good either.
People that never write embedded code, and never have to trigger the debugger when a particular voltage occurs on a particular pin in order to to track down a race condition caused by clock skew and/or misaligned asynchronous inputs to the FPGA, will never be any good either.
Re:Debuggers (Score:5, Funny)
> there are three things that catch bugs before you even get to a debugger:
Yes, but the "hard" bugs are the ones that happen at run-time. Those depends on the context such as Networking, Rendering, and AI bugs that can be a real PITA to track down.
Race Conditions, and Deadlock are hairiest ones.
There has to be a comprehensive list someplace aside from the usual
* syntax (compile time)
-- variable mis-spelt
* logic
-- classic "fencepost" bug
* run-time
-- race conditions
-- deadlock
On a half serious note:
* Bohrbugs: Most of the bugs that we come across are reproducible, and are known as Bohrbugs.
* Heisenbugs: All experienced programmers have faced situations where the bug that crashed the software just disappears when the software is restarted
* Mandelbugs: When the cause of the bug is too complex to understand, and the resulting bug appears chaotic,
* Schroedinbug: Sometimes, you look into the code, and find that it has a bug or a problem that should never have allowed it to work in the first place
http://www.opensourceforu.com/... [opensourceforu.com]