Slashdot Mirror
Fixing the Pain of Programming
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."
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?"
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
> The higher the stakes the more the accomplishment of that task will make me proud/happy.
While true, this has little to do with the time wasted learning the basic layout of the build tools and auto-configuration tools. The time wasted constantly retweaking and hand-compiling individual components as source code is updated is just that for most programmers: time wasted.
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.
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 . . .
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.
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.
I would like to spend more of my time creating new things rather than fighting to make existing things work together.
I mean, thats the elephant in the room, isnt it. I found that everything thich can be automated easily is automated in eclipse.
Whenever I see one of these headlines about how there is a supposed shortage of programmers and we should make it easier so "stupid people" will come to save the day, it just makes me think "what the what?" I have an awesome sister. She can't sing. She makes people cover their ears and the dog runs out of the room. Are we going to solve today's broken music scene by making singing easier and coaxing my sister to become a singer? I don't think so. Singing is easy. Doing it well enough that people want to listen is not hard...for people who are good at it. People who suck at singing should just do the world a favor and not try it in public. The fact that the world has a limited number of programmers, and an even smaller number of good programmers and an even smaller number of really-really good programmers is simply that people are all different. Some of them can sing. Some of them can do technology. Some of them are jocks. Some of them just take up space. (Hey, it may be harsh, but it is accurate.) On the other end of the millions of different bell curves that could be used to describe humanity, there are some people who excel at bad things, like the Hitlers and the Lawyers of the world. Sadly though, this sort of "how can we make programming accessible to the masses" nonsense will never go away. That is simply because there are people on this planet who are six sigma at asking stupid questions.
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.
Yes. Turns out people unable to program lack talent, insight, dedication, but not an IDE.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
So it seems to me that most of the pain of programming is bad programmers who can't be bothered to learn about the tools they're working with or even the hammer that they're using to solve every problem. So why do you think your hammer's going to be better, again?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Mod parent up. Not sure if this New Yorker cartoon from the most recent issue will stay around long, but I saw it this morning and it sums up how I feel about much of computer software development the last thirty years since Smalltalk:
http://www.newyorker.com/image...
A character says "The new house is almost ready!" and it looks exactly the same as the rundown house in almost exactly the same location.
Software could be better, like the character could in theory have built a better house. But in practice, watching this play out of 30 years myself, much of what we get is just re-re-re-inventing the wheel. And there is a terrible waste in having to re-learning it slightly differently with slightly different bugs and limits, and little true progress. Often there is regress, since Smalltalk's keyword syntax is still more readable and expandable than C-like syntax.
Where would we be now if a truly free Smalltalk had had all the billions poured into it that Java had due to IBM and Sun's marketing clout and all the effort that has gone into JavaScript dues to Netscape/Mozilla/Google/etc.? Including the best of any LightTable ideas (a view with source when you hover over a name in code is indeed cool) and any other GUI improvements? As well as better libraries and better cross-platform support and better browser integration and so on?
Still, maybe JavaScript is the best we could hope for at this point, and better than we deserve, as someone else said and I echo in this submission from yesterday about James Mickens' last "USENIX "login" column explaining all that is wrong with the Web pages technically:
http://slashdot.org/submission...
Citing: https://www.usenix.org/system/...
But we got that mess for social reasons (competition, centralization, monetarization), not technical one, like I mention here:
http://slashdot.org/comments.p...
Social stuff like ParcPlace not being willing to license ObjectWorks/VisualWorks cheaply to Sun when they wanted to do a set top project (which ultimately lead to sun making Java).
Could Smalltalk be improved? Yes. Even the syntax could, like by using more C-like strings and comments while keeping the keywords. Could it benefit from type annotations for optimization? Probably yes too. And could it benefit from being built from textual sources instead of an image (like GNU smalltalk). Again yes. But investments in that direction would have produced so much more benefits than something like Java or JavaScript.
That said, after all the pain and suffering and waste, Java and JavaScript/HTML5/CSS3 have finally become half-way decent platforms. I'm moving more in a JavaScript direction myself for mostly social and practical reasons, despite knowing how great Smalltalk was and seeing how much it could have become. I talk about that on Slashdot here:
http://slashdot.org/comments.p...
http://developers.slashdot.org...
Smalltalk might still get there building on Java and JavaScript as with these projects:
http://amber-lang.net/
http://www.redline.st/
Mickens' comments are mostly true, but end up being tradeoffs for ubiquity and easy installs in the case of JavaScript -- even Alan Kay and Dan Ingalls agreed on that with their efforts toward the Lively Kernel driven by the fact they could not get many people to install Squeak or Squeak-based apps).
http://www.lively-k
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
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.
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.
First, why does programming need to be accessible to more people? That's exactly the opposite direction a mature technology goes. It use to be easy to fix your own car, but now with the modern engine and manufacturing techniques it's damn near impossible for most people to do more than add consumables. It used to be easy to fix electronics, but now it's impossible to take things apart and if you do you find everything is done in literally a black box of a chip and there's nothing you can do to it. These things have good points and bad points and I'm not here to argue for or against them, just to say that mature technology tends towards "no user-serviceable parts inside". Why would you expect programming to be any different?
Second, the pain in programming doesn't come from the tools. Yeah, it's a pain to learn the tools, but that's a pain that's short-lived. The real pain comes from the nature of programming. It's caused by having to tell the computer in excruciating detail exactly what you want it to do. In order to tell the computer you have to figure it out for yourself, without glossing over any "you know what I mean" steps, because the computer certainly doesn't know what you mean. And not only do you have to tell it how to do the job when everything is working as it should, you have to anticipate all the ways in which things could fail and tell the computer what to do in those cases, too. THAT'S the painful part of programming -- the programming. No tool is going to fix that.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
The only "pain of programming" I have experienced was always the result of my own poor design choices. Is there an IDE for that?
They looked at this problem before, and came up with Netbeans. They looked at it again and the result was Eclipse. I don't hold out much hope.
Disclaimer: currently trying to [re]learn java (did a bit when it was 1.1) and I'm wondering if it'd just be better to use gedit or even vi...
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
At least they haven't automated being simultaneously pretentious and mathematically illiterate.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."