Toward Better Programming

An anonymous reader writes "Chris Granger, creator of the flexible, open source LightTable IDE, has written a thoughtful article about the nature of programming. For years, he's been trying to answer the question: What's wrong with programming? After working on his own IDE and discussing it with hundreds of other developers, here are his thoughts: 'If you look at much of the advances that have made it to the mainstream over the past 50 years, it turns out they largely increased our efficiency without really changing the act of programming. I think the reason why is something I hinted at in the very beginning of this post: it's all been reactionary and as a result we tend to only apply tactical fixes. As a matter of fact, almost every step we've taken fits cleanly into one of these buckets. We've made things better but we keep reaching local maxima because we assume that these things can somehow be addressed independently. ... The other day, I came to the conclusion that the act of writing software is actually antagonistic all on its own. Arcane languages, cryptic errors, mostly missing (or at best, scattered) documentation — it's like someone is deliberately trying to screw with you, sitting in some Truman Show-like control room pointing and laughing behind the scenes. At some level, it's masochistic, but we do it because it gives us an incredible opportunity to shape our world.'"

Comments

You think programming's bad?

[Anonymous Coward]

You think programming's bad? Think about electronics, especially analogue electronics.

Incomplete, inaccurate data sheets. Unlabeled diagrams (where's the electronics equivalent of the humble slashed single line comment?), with unknown parts given, and parts replaced with similarly numbered replacements with subtly different qualities. And then you've got manufacturing variances on top of that. Puzzling, disturbing, irreproducible, invisible failure modes of discrete components.

Programming is hard...

[hsthompson69]

...wear a fucking helmet.

The post essentially points in the direction of the various failed 4GL attempts of yore. Programming in complex symbolism to make things "easy" is essentially giving visual basic to someone without the knowledge enough to avoid O(n^2) algorithms.

Programming isn't hard because we made it so, it's hard because it is *intrinsically* hard. No amount of training wheels is going to make complex programming significantly easier.

Re:Programming is hard...

[Darinbob]

There's the other meme that crops up now and then, that programming as an engineering skill should be similar to other engineering practices. That is you pick out pre-built components that have been thoroughly tested and optimally designed and screw them together. Except that this utterly fails, because that's now how engineering works at all really. Generally the pre-built components are relatively simple but the thing being built is the complex stuff and requires very detailed and specialized knowledge. The advent of integrated circuits did not mean that the circuit designer now doesn't have to think very much, or that a bridge builder only ties together pre-built components with nuts and bolts. So maybe they pick an op-amp out of a catalog, but they know exactly how these things work, understand the difference between the varieties of op-amps, and how to do the math to decide which one is best to use.

However the programming models that claim to be following this model want to take extremely complex modules (a database engine or GUI framework) and then just tie them together with a little syntactic glue. Plus they strongly discourage any programmer from creating their own modules or blocks (that's only for experts), and insist on forcing the wrong module to fit with extra duct tape rather than create a new module that is a better fit (there's a pathological fear of reinventing the wheel, even though when you go to the auto store you can see many varieties of wheels). And these are treated like black boxes; the programmers don't know how they work inside or why one is better than another for different uses.

Where I think this attitude is coming from is from an effort to treat programmers like factory workers. The goal is to hire people that don't have to think, thus they don't have to be paid as much, they don't have to have as much schooling, they can be replaced at a moment's notice by someone cheaper. So the requirement of low thinking is satisfied if all they need to do is simplistic snapping together of legos. That's part of the whole 4G language thing, they're not about making a smart programmer more productive by eliminating some tedium but instead they want to remove the need for a smart programmer altogether.

(I certainly have never met any circuit designer or bridge architect bragging at parties that they skipped school because it was stupid and focused too much on math and theory, but that seems to be on the rise with younger programmers... Also have never seen any circuit designer say "I never optimize, that's a waste of my time.")

pft.

[HeckRuler]

What is programming?

The answers I got to this were truly disheartening. Not once did I hear that programming is “solving problems."

I'd like to think that's because the majority of programmers (not once? Does that mean all of us?) aren't the sort to bullshit you with CEO-level bullshit about vision and buzzwords that fit into powerpoint slides.
It's probably not true, but it's a nice dream.

The problem with defining programming as "solving problems" is that it's too vague. Too high level. You can't even see the code when you're that high up. Hitting nails with hammers could be problem solving. Shooting people could be problem solving. Thinking about existential crisis could be problem solving.

The three buckets:
Programming is unobservable - you don't know what something is really going to do.
Programming is indirect - code deals with abstractions.
Programming is incidentally complex - the tools are a bitch

Something something, he doesn't like piecemeal libraries abstracting things. "Excel is programming". Culture something.

The best path forward for empowering people is to get computation to the point where it is ready for the masses.

We're there dude. We've got more computational power than we know what to do with.
Cue "that's not what I meant by 'power'".

What would it be like if the only prerequisite for getting a computer to do stuff was figuring out a rough solution to your problem?

Yep, he's drifting away into a zen-like state where the metaphor is taking over. Huston to Chris, please attempt a re-entry.

AAAAAAAAnd, it's a salespitch:

Great, now what?

We find a foundation that addresses these issues! No problem, right? In my talk at Strange Loop I showed a very early prototype of Aurora, the solution we've been working on to what I've brought up here.

Re:Separation of Concerns

[Anonymous Coward]

No matter how flexible an architecture you try to design, after the software is mostly built, customers will correspondingly come up with even more incredibly bizarre, complex and unrelated functionality that just HAS to be integrated at the oddest points, with semi-related information thrown here and there, requiring data gathering (or - god forbid, (partial) saving) that slows everything down to a halt. And they rarely give much time to do redesign or refactoring. What was once a nice design, with clean, readable code is now full of gotchas, barely commented kludges, extra optional parameters that might swim around multiple layers, often depending on who called what, when, and from where, and also on various settings, which obviously are NEVER included in bug reports. Of course, there are multiple installations running multiple versions...

Moving the Goalposts

[Anonymous Coward]

Programming is hard because we only call it programming when it's hard enough that only programmers can do it. Scientists do stuff in Mathematica, MBAs in Excel, or designers in Flash/HTML, that would have been considered serious programming work 30 years ago. The tools advanced so that stuff is easy, and nobody calls it programming now.

Lots of stuff that takes real programmers now will, in 20 years, likely be done by equivalents of Watson. And the real programmers will still be wondering why is so hard.

We Choose Framentation Over Consolidation.

[scorp1us]

Let's look at the major programming environments of today:
1. Web
2a. Native Apps (machine languages (C/C++ etc))
2b. Native Apps (interpreted/JIT languages (intermediary byte code))
3, Mobile Apps

1. is made by 5 main technologies: XML, JavaScript, MIME, HTTP, CSS. To make it do anything you need another component, of no standard choice:your language of the server (PHP, Rails, .Net, Java, etc)
2. Was POSIX or Win32, then we got Java and .Net.
3. Is Java or Objective C.

We don't do things smart. There is no reason why web development needs to be 5 technologies all thrown together. We could reduce it all to Javascipt: JSON documents instead of XML/HTML, JSON instead of MIME, NodeJS servers, and even encode the transport in JSON as well.

Then look at native development. Java and .Net basically do the same thing. Which do what POSIX whas heading towards. Java was invented so Sun could keep selling SPARC chips, .Net came about because MS tried to extend Java and lost.

Then, we have the worst offenders. Mobile development. Not only did Apple impose a Objective-C requirement, but the frameworks aren't public. Android, the worst offender is a platform that can't even be used to develop native apps. At least Objective-C can. Why did Android go with Java if it's not portable? Because of some good requirement that they don't want to support a specific CPU, but then they go and break it so that you have to run Linux, but your GUI has to be Android's graphical stack. Not to mention that Android's constructs - Activities, Intents, etc are all Android specific. They don't solve new problems, they solve problems that Android made for themselves. We've had full-screen applications for years the same goes for theading, services, IO, etc.

I'm tired of reinventing the wheel. I've been programming professionally for 13 years now and Java was neat, .Net was the logical conclusion of it. I was hoping .Net would be the final implementation so that we could harness the collective programming power into one environment of best practices... a decade later we were still re-inventing the the wheel.

The answer I see Coming up is LLVM for languages. And Qt, a C++ toolkit. Qt runs everywhere worth running, and its one code base. Sure, I wish there was a java or .net implementation. But I'll deal with unmanaged memory if I can run one code base everywhere. That's all I want. Why does putting a text field on a screen via a web form have to be so different from putting a text box on the screen from a native app? It's the same text box!

Witty, a C++ webtoolkit (webtoolkit.eu) is mirrored after Qt and is for the web. You don't write HTML or JS, you write C++. Clearly the C++ toolkits are onto something. If they were to merge and have a common API (they practically do now) in an environment with modern conveniences (lambas (yes, C++11) managed memory) we'd have one killer kit. Based on 30 year old technology. And it would be a step in the right direction.

Re:Proverb

[lgw]

A good craftsman can get by with suboptimal tools.

A good craftsman is not content to "get by", almost by definition. If some part of your workflow sucks, you make it better, whether that's a better tool or more skill/training. If you're good, you never stop improving (until management forces BS on you, of course).