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."
Debuggers (Score:5, Insightful)
I suppose this is addressed by the old quote "What is the best language for x?"
"I don't know. Which has the best debugger?"
The pain is good (Score:2, Insightful)
When you spend 8 hours troubleshooting an open-source project to compile with a third party proprietary library it feels damn good to make it work. Coding is good because it's hard. The higher the stakes the more the accomplishment of that task will make me proud/happy.
Sure... there are some places where things should be simple. When I install an IDE I expect it to compile a hello world just after typing the proper code.
Difficulty Spectrum (Score:5, Insightful)
Programming has a spectrum of difficulty. The tools can always be improved to make the easier parts easier and the harder parts more manageable, but in the end the hard parts are hard because of the nature of the work; not due to lack of tools.
In more mature fields the spectrum of difficulty is well understood and no one expects the hard parts to be easy. If a person can write a "hello world" program then it should not be expected they will have the wherewithal to roll out healthcare.gov. If a person can apply a bandage to a skinned knee then it should not be expected they will have the wherewithal to do brain surgery; regardless of how good the tools are.
Re:this is why my kids won't be coders (Score:4, Insightful)
Historically, so far, the easier you make it, the harder the problems become.
One of the most visible examples of this is in frontend web development. Now that we have jquery and a billion javascript librairies, we don't do the same simple web pages we used to in a fraction of the time (something that would have taken a month back then takes literally seconds today). Instead, we do crazy shit that were never meant to be done in a browser.
If we make that crazy shit easier, people will just go and do crazier shit.
Re:this is why my kids won't be coders (Score:5, Insightful)
Yeah, but this perception of programming is the real problem.
Programming is not a "pain" if you do it right. Most of the times programming is a "pain" because you are working with code or frameworks written by mediocre programmers who probably shouldn't be programmers. The more accessible you try to make programming, the more mediocre programmers will be encouraged to write code and software that will be a pain to work with.
Re:this is why my kids won't be coders (Score:2, Insightful)
the more accessible you make it the more people get into it and the more of a commodity it will become
even now developing and coding is a commodity in a lot of fields or a secondary skill to being a math whiz and working with algorithms on data sets
So true. I studied computer science at university, never graduated because I began consulting. Years later I am finishing a mathematics degree and regret ever pursuing computer science much less the IT career into which it led me. I came across the textbook for an introductory computer science course at a leading university in Canada; it was so dumbed down I almost cried. The notion everyone should learn to programme computers is ridiculous in the same sense everyone should should learn to wire their own home or repair their own automobile.
What nonsense (Score:2, Insightful)
Yes, I usually get by with print statements as well, because I do not need anything else! Learning to debug is a critical part of learning how to program. Taking that away is plain harmful. Advanced debuggers give you more, but anybody that cannot debug simpler print-statements does not have the level of understanding of the code that is absolutely required to make it any good.
Re:Eclipse? (Score:2, Insightful)
You are certainly right about eclipse being an elephant.
Re:Debuggers (Score:1, Insightful)
> the ability to track down a bug with nothing more than a set of print/alert statements saying "I got here, X=47" means the difference between "programmer" and "wizard's apprentice"
Really? Because in my experience it's the "apprentices" that tend to lean far too heavily on printf, which is always taught before debuggers and is much easier to use. They spend hours instrumenting everything only to find a bug that could have been located in a few minutes with breakpoints, watchpoints, and stepping. Then they leave behind them a trail of commented-out printf garbage that pollutes the codebase.
> if the IDE's wizard fails you, you end up almost drowning until a real programmer saves you
Because Real Programmers build houses using only hammers. Nailguns, screwdrivers, shovels, and power tools are for pussies.
Re:The pain is good (Score:5, Insightful)
Sorry, but no. If I have a known-working source tree that I want to work with just to tweak one tiny nuisance, I want to download it, open the project, make the change, then build/test/deploy.
In gaming, you have the concept of artificial vs natural hardness. When the game makes you do things just right with cheap tricks like an almost unavoidable trap right before boss / end of the level, when it requires pixel-perfect jumps, when it has insanely complex or tedious puzzles to solve, when it has time limits that require you to essentially memorize which buttons to mash and when, when it doesn't allow saves except at completely useless spots, the devs have made it artificially hard because they failed to make it challenging through more natural means.
In coding, we have the same problem, except we don't (usually) do it to ourselves intentionally - And you describe the most egregious example of it, configuring dependencies. I love a good challenge in writing actual code. Optimizing a tight loop cycle by cycle, importing useful numbers from a BOL file that everyone else has given up on, implementing a new (to me) algorithm in language X (I had a great time learning SQL for that reason, because most of my stock tricks from the C world don't translate well). Those all leave me feeling deeply satisfied at the end of the day. When, however, I can't even get the damned thing to build because I have to tweak 17 obscure dependencies:
"Oh yeah, it doesn't work with the newest 2.17.99 release of WidgetBlaster, you need to hunt down 2.17.94"
"Oh, you used the default build parameters for WidgetBlaster? Heh, you have to pass it the undocumented NoFleem flag at compile time"
"Yeah, NoFleem doesn't actually have any effect unless you install the not-obviously-required WidgetFleem library first"
"Well, you can't actually do it in one pass, since WidgetFleem has a circular dependency on WidgetBlaster - So build WidgetBlaster without NoFleem, then build WidgetFleem, then rebuild WidgetBlaster with the NoFleem option".
"Oh yeah, it only works in GCC 4.4.x, they changed the optimizer after that one and it breaks WidgetFleem."
"Did I mention you need to cross-compile it from an OS X machine because a critical buildtool doesn't exist on Windows?"
Shit like that drives me up the wall, I have zero patience for - or enjoyment of - trying to work around someone else's quirky build environment. If your code depends on obscure external packages, include them in your source tree, and include building them in your default project/makefile, period. I don't care if it makes your source tree 2.5GB, because I'll need to download them all anyway, and at least you know the right versions to include.
Re:Debuggers (Score:5, Insightful)
People that need debuggers will never be any good.
People who work with trivially-simple applications and never have to deal with someone else's legacy mess will never be any good either.
Re:Debuggers (Score:5, Insightful)
Our experiences differ somewhat drastically, then - Perhaps this involves a difference between the Windows world and the Linux world. In Linux, yes, knowing how to attach and use the standard debuggers counts as something of a fine skill set (though I don't think that still holds true like it used to - We have a hell of a lot more choices today than just GDB/DDD). In the Windows world, when the code breaks, the IDE throws you into a debugger and all but tells you what happened and what to do about it.
Because Real Programmers build houses using only hammers. Nailguns, screwdrivers, shovels, and power tools are for pussies.
Nice strawman, but no. Real programmers use power tools when appropriate. But when the sawzall won't fit in a tight space, the real programmer knows how to use a keyhole saw.
Re:Debuggers (Score:5, Insightful)
Hint: outside of Hello World, bugs will happen. Debuggers are a great way of determining what the bug is so you can get on with fixing it, instead of acting like the hot programmer who doesn't need them but instead wastes an entire day combing through his code looking for that one error. Deciding that you're "above" some subset of tools available to you is childish at best.
Re:Debuggers (Score:3, Insightful)
Game development is different. For example, you cannot easily unit-test things like what is displayed on the screen or whether something runs smooth or not. There are other differences. Anyhow, the discussion is not about being able to use a debugger or even having one. It is about people that need one even for simple things and these people have no business writing code in the first place.