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."
Smalltalk live images (Score:4, Interesting)
I simply don't get why not all programming languages/development environments support live images like Smalltalk..
For those who don't know what that is: in Smalltalk the IDE and the running program are 'the same'. Your 'program' (what you code) never stops and/or is restarted. It just 'freezes' like a laptop and is 'restarted' or awaken at it previous state.
That means if you send me your 'source code' you are actually sending me a sleeping, but running! program.
Re:Smalltalk live images (Score:3, Interesting)
No program is an island. You can stop programs as an OS function in many operating systems, but resuming is a bit harder, as everything they presumed about the system at runtime may have changed, including displays, disk status, sockets, time zones, connected devices, or anything else.
It's a bit like freezing you when you dash down a hill to reach the bus, and then unfreeze you in a glass store.
The only somewhat safe way of saving and resuming a state is if you save and resume an entire OS - like most VMs allow you to do. And even that isn't safe - what if you froze in the middle of writing to an external drive, and another system modified the directory structure while offline?
What Smalltalk and similar environments do is giving you a safe playground that can be frozen, but also cannot access anything outside the playground directly, and requests to the playground manager to interface with the outside world are atomic and cannot be frozen.
It's fairly safe, but also far too limited for most programming jobs. You cannot use an etch-a-sketch to paint a house.
The Golden Age of Programming (Score:5, Interesting)
I don't use mythology in a perjorative sense that this is all pretend or wishful nonsense. I use it in the best Joseph Campbell-Hero-With-Many-Faces sense, of a dim recollection of The Way Stuff Used to Be. This is a way of communicating an Underlying Truth about the Human Condition.
Apparently there was this era of things such as this Smalltalk that you allude to. Another version of this I hear from tales is Common Lisp. And Lisp Machines, specialized hardware and expensive workstations on which these "live images" would reside. So maybe these tales of direct, personal communication with the gods taking place with the Bronze Age Greek heros was not made up?
I guess there was this Barbarian Invasion of Bearded Men from the land called "New Jersey", especially a high place among the rolling plains they called "Murray Hill"? There is this piece of non-canonical scripture that our elders have been trying to supress known as the Unix Hater's Handbook explaining how we came to our present age and how this Golden Age entered into myth. Our elders warn against reading this heretical tract as dangerous to our souls.
As Jerry Pournelle describes the intervening Dark Age between now and that heroic or Golden Age, it isn't so much that people forgot how to develop and maintain a live image programming system such as Smalltalk or Common Lisp, it was that people forgot that such a thing could exist, and we attribute such things to gods or space aliens.
But then again, just as there is talk of ancient creatures in deep lakes in Scotland or in the remote sections of Zaire or Southeast Asia, there are accounts that Smalltalk or Common Lisp are still in use . . .
Often we do this to ourselves. (Score:5, Interesting)
More than once I've seen the existing functionality of an IDE's automatic (or semi-automatic) compile, run and debug loop sabotaged by some (sometimes mandated) third party plugin which is supposed to make things "easier." I've watched as people poorly integrate Java Spring into a project and render it impossible to use Eclipse's debug button because of badly constructed project dependencies. ("Oh, if you want to run the project, just drop into the command-line terminal and type 'ant someobscurebuildproduct run'; it's pretty easy, why are you complaining?") I've seen people integrate Maven into a build process in ways which guarantee the project will stop compiling at some unspecified time in the future by improperly scoping the range of libraries that will be accepted. (And I'm not a fan of Maven or CocoaPods or other external dependency resolution tools anyway, as in part it presumes the external libraries we link against that are hosted outside of our source kits will honor their public interface contracts as minor revisions roll out, something which isn't always true.)
I've seen refactoring which adds code bloat (rather than simplifies the code). I've seen home-rolled configuration files which make code discovery functions break code discovery functions in Eclipse useless (do you really need to home-roll you own class loader, and specify Java classes in JSON?). I've seen plenty of 'voodoo stick waving' standing in for good coding practices. I've seen the lava flow anti-pattern obscure a simple Java RTL call in 20 discrete layers of classes, each added on by another refactoring that did nothing but make things more obscure.
I've seen weird blends of ant and makefile build processes which took a product that should have taken perhaps 5 minutes to build take over an hour, and build processes so broken that it was impossible to shoe-horn into an IDE without rewriting the entire project. ("Real programmers use 'vi.'" *shakes head*)
In fact, I have a working theory about programmers--and that is this: Most programmers think something should be a certain level of difficulty. And when a project turns out to be easier than they think it should be, they add artificial complexity until it reaches the expected level of difficulty. At some point, the project then needs to grow, making things organically more difficult--but the artificial difficulty added by the programmer who thought things were too easy before then simply sabotage the project. This is why quite a few projects I've worked on over the past 25 years have failed.
This is why I have no hope for any project that attempts to fix the problem. That's because the problem is cultural, not technological. We've had IDEs which had integrated debugging and one-button build + run processes going back to the 1980's--yet somehow we always glom to the next big thing, oh, and sorry about breaking your IDE--but this next big thing is SO important it'll totally compensate for the fact that we broke your edit/run/debug cycle.
Meaning I guarantee you the moment someone builds a fool-proof IDE which makes it brain-dead simple to edit, compile, run and debug an application, some damned brain-dead fool will come along, worried that things shouldn't be harder, and break the system.
Re:this is why my kids won't be coders (Score:3, Interesting)
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.
It's interesting you brought that up, because I think a similar analogy is necessary.
While most people do not (and should not) ever try to do advanced mechanic tasks like change out a transmission on their car, it is useful for people to understand basics like rotating tires and changing oil. Similarly with programming, I would not expect most people to pick up programming to the point where they can code up an OS, compiler, or even a typical SOA system. However, giving someone the tools to fiddle around with basic programming like static web pages with a little javascript or simple command-line applications to handle input from a user or a data file and spit out usable information can enhance their hobbies or even non-IT work.
Many people who became programmers after starting in some other field (either in school or the workplace) can recall situations where they used programming to aid in some aspect of their pre-IT life. There's no reason to shut the door for anyone else to do so.
Re:Debuggers (Score:2, Interesting)
For an experienced programmer in a statically typed language (like C++), there are three things that catch bugs before you even get to a debugger: the static type checker, runtime assertions, and unit tests. If any one of them triggers, it is usually obvious how to fix stuff even without a debugger.
Debuggers should be simple, minimal, and reliable, so that the 1-2 times a year that you need them, they get the job done correctly and without having to remember a lot of complicated stuff.
Re:Debuggers (Score:5, Interesting)
I do a lot of embedded programming, and doing the "standard" stuff like unit testing really is a pain. The bugs don't show up most of the time until they're on a real system or linked with everything else, and the bugs that do appear are the sort that are unlikely to be found in unit tests. Even without embedded programming there is almost always a hard and fast deadline with loud and angry people making sure you get it all done in time, so the unit testing is sometimes the first thing that gets cut. And let's be fair here, very often it is just as hard to write a good unit test as it is to write the code itself, and the programmer who is unlikely to find the bug in the code is also unlikely to write a unit test that would find that bug.
So ya, you need a good debugger. And if you're good at using a debugger then your value goes up, especially if you can manage dealing with core files and deciphering what occurred in that optimized assembler.
That said, this is the easy stuff in programing. The "pain of programming" has nothing to do with computers or languages or tools, the pain comes from management. This is why you have people who love to program but hate to come to work.