June 23, 2006
Jonathan Edwards' Manifesto of the Programmer Liberation Front is an inspiring call to arms for programmers who are fed up with the status quo of Java and C#. Maybe it is time to open your window, stick your head out and yell, "I'm as mad as hell and I'm not going to take this anymore!"
Or you could just read his blog post. Here are a few highlights:
Compared to every other field of design and engineering, programming is an embarrassment and a failure. The "software crisis" has dogged us from almost the beginning. We who have made programming our life will no longer tolerate this.
Programming languages are the fundamental technology of programming. To make fundamental improvements in programming you need a fundamentally better programming language.
There is a widespread belief in both industry and academia that working on new programming languages is pointless. This is short-sighted. Historically, all sciences and technologies undergo revolutionary change. The lack of meaningful progress in the last 20 years means that there is an enormous pent-up potential for change, and the lack of interest in it means there is an enormous opportunity for the intrepid. It is a good time for a revolution.
To fully embrace adaptation as the essence of programming will require a change of attitude that is quite difficult: discarding elegant yet fragile constructions in favor of messy but flexible ones. One case in point is copy-and-paste programming. This violates all the accepted rules of modularity and hygiene, yet everyone still does it routinely. Either most programmers are stupid and evil, or the accepted rules are idealistic and impractical. The latter is the case. It is necessary to embrace copy-and-paste as a first-class "semi-modularity" mechanism in the language Ã¢â‚¬â€œ to track it, manage it, and eventually refactor it into "proper" modularity. This may be heretical, yet an honest appraisal of how programmers really work requires something like it. Usability is a subversive idea.
In Science and Math, formulas are typically one-liners. Even small programs are far larger than any mathematical statement. Expression-based languages attempt to scale up formulas to hundreds or thousands of lines. One reason this does not work is that people can not easily handle more than about 2 levels of nesting. We are not stack machines! Natural languages rely on linear narrative flow and avoid deep nesting. This may be the real problem with LISP: people complain about parentheses, but they are really complaining about deep nesting.
Commercial considerations often dictate that compatibility and performance have the highest priority, with disastrous consequences (witness C++). As the Open Source movement has demonstrated, progress requires overthrowing the economics of software. We will need to go even further, freeing our minds of traditions established with the very first programming languages. Usability is the guiding light to rationally reinvent programming from scratch.
Programming is at a dead-end. The only way things will get better is with a complete revolution. More conservative attempts over the years have repeatedly failed to make a difference, leading to the widespread abandonment of hope. We have nothing to lose.
You might say it's a street corner preacher rant. But that's what makes it so good.
Posted by Jeff Atwood
Sohow do we distinguish whether we demand more from the language or demand more from the IDE.
For example, I could envision a copy/past IDE improvement in which copying a chunk of code and pasting it would bring up a little smart tag the developer could click which would allow the developer to automatically refactor the chunk into a method.
This is exactly why we need excellent RAD tools that work directly with the design of the GUI to generate a database automatically from the form generated.
Excellent form inheritence (unlike the mess that MS has created) that will allow you to create a template and inherit from it. Change the base, change every form. Most of the copy and paste that happens is specifically because of GUI issues, and rarely to do with other things.
Fix these two things, and you're well on your way to creating a very effective and quick to design, build and test application. Our software is living proof of this motto. All database are created AFTER the GUI is created and the functionality is fully determined. The GUI is NOT determined by some database written first. Nor is it determined by the code complexity of the form. We design the form based on the user's optimal experience and then live with the crappy performance of 2000+ line forms under VS.net and every other tool, simply because it's the user that determines the interface. It is the person doing WORK with the software that will ultimately determine the success and failure of the software.
And to that end, we have a rich interface. We build it using .NET Form Inheritience, got around all of the bugs and other pains in the ass with it, and now we can fix a bug once instead of 50 windows, and we can change the look once and it's done for all of the windows.
The reality is that the vast majority of programs are front ends to databases. That is, the store information and retrieve it intelligently based on need. But the database is determined by the need, which can only be determined by the end user. By flipping it, and having the GUI build the database instead of the other way around, you eliminate 99% of the problems.
"Natural languages rely on linear narrative flow and avoid deep nesting."
i think this is an oversimplification of the languages commonly in use today. Every word spoken is backed by layers upon layers of context and emotional nuance that constitute deep nesting taken to an absurd level. it's just that the speakers are so i tune with the background context, it literally is a part of their being, that they don't even notice the nesting.
Lets take the blog entry you link to as an example. At the top, the date reads "12/6/2004", but at the bottom it is signed "june 16 2004" Now if a computer needed to order this with regards to other blog entries, which date should it use? Given our experience with languages, concepts, and how we deal with information given our culture, background, education, and experience will dictate how we handle the data we are given. Some will choose to assume that the essay was written in June and published in December. Some folks in Europe will think he went backwards 4 days in time to june 12th to publish it. Most of us will realize that the date isn't as important as the concepts put forth. Try modeling that decision using binary logic gates. It gets complicated very quickly.
The reason we program the way we program and the reason that programming languages ar ethe way they are is primarily due to the environment in use. Writing another abstraction layer on top of a binary system just presents more failure points. We've discussed this before Jeff, garbage collection is great until it isn't, then you have to understand how memory management works if you have a problem in order to diagnose it. Example centric programming languages are great, until you run into a more complicated example or you are missing a key building block. Then it's back into logic gate manipulation. All programming is still just flipping switches because that's all computers right now are. Languages like Java, C#, and (especially) Ruby make it a little less painful to flip those switches. But that's about it.
What a stupid rant. Let's see, how about I change a few words in this paragraph?
"Electrical engineering is so hard that only highly talented, trained, and dedicated individuals can do it passably well. The inescapable conclusion is that electrical engineering as we know it is just unnatural for humans. The solution is to reinvent electrical engineering to suit human cognitive skills – to make electrical circuits the way we think."
Why is it that every couple of month some idiot pops out of the woodwork who thinks that programming, UNLIKE ANY OTHER TRAINED PROFESSION, should not require any effort or education?
programming, UNLIKE ANY OTHER TRAINED PROFESSION, should not require any effort or education?
While I agree that's a weak part of the rant, programming *is* unlike most other trained professions. Imagine trying to be an electrical engineer if the laws of physics were rewritten every 10 years:
having been hit by the thrown down the gauntlet:
there are code centric folks and data centric folks. if you're the latter, then things like Firestorm/[DAO|SDO] are nirvana. the reason is simple: intelligent lifeforms seek to put the data and its control as close to each other as possible. that's the DataBase. for those still trying to relive COBOL/VSAM (the code centric folks), then keep them as far apart as possible. you'll lose.
now, the "bound data control" of VB fame is NOT the same thing. let's be clear about that. what we're seeking is one fact, one place, one time. and generate the UI from the catalog. it's not that tough. if you can do it from some convoluted XML stuff (which i see every day here in CubeLand), then you can from the catalog. it is, after all, just text.
and be clear about where we're trying to get: since the "view" (in MVC speak), is *supposed* to be fungible, then it is irrelevant to the data model. the DataBase rules. of course, one has to really be a DataBase developer to get that part. coder, these days, tend to treat the DataBase as if it is just a surrogate for the (flat) file system. which is very 1960's. and not progress. they just change to vocabulary from "record" to "object". same same.
the systems which will work well in the Web sense will be just CRUD; there will never be enough bandwidth to ship 10's of thousands of rows over the wire. decompose the data into BCNF, and send only what's needed.
have a look at Rails. even he's starting to get it.
The laws of programming are NOT rewritten every 10 years. That's 90% of the problem; people show up and start programming out of their butt's, and then 10 years down the road they learn about something called "efficiency" and "n lg n" and think they have invented something new.
Wow. That's 10 minutes of my life I'm not going to get back. What an unproductive load of flawed crap.
This is just a loosely connected bunch of complaints, and a set of positive-sounding but hopelessly vague and completely unactionable ideas. I don't see that he's actually proposing anything meaningful here.
I'm struggling to understand what you thought was good about this.
sounds an awful lot like the high level declarative vs. low level imperative debate, yet again.
having used a Prolog variant, i'll stick with imperative languages. and until there's a processor based on something other than the Von Neumann architecture...
Getting mad as hell, sticking your head out the window (one might even consider stepping outside) and yelling: "I'm not going to take it anymore!" is all fine and very wholesome, as long as you're mad as hell about, say, armies invading defenseless countries, and not the imperfections of programming languages.
Quoth Buggy Fun Bunny:
"what we're seeking is one fact, one place, one time. and generate the UI from the catalog. it's not that tough. if you can do it from some convoluted XML stuff (which i see every day here in CubeLand), then you can from the catalog. it is, after all, just text."
Thank you. Are there more people like us? Is someone actually writing code to do this besides me?
"Introspecting" the database catalog tables, reading some addt'l metadata out of some UI definition tables, and generating a UI on-the-fly at runtime is a hell of a lot easier, to me, than hand writing or generating XML descriptions of an RDBMS schema that get parsed to generate Java / PHP / et. al. code that's actually executed on the web server. What passes for database schema-driven user interface code today sucks, from where I look at it, because hardly anybody gets it.
I want to add columns to the database and have the UI "just change".
I think the problem with the article is that it misses the point. Programming is hard, not because of the tools (albeit they often do not help), but because the underlying problem is hard. While a new paradigm for languages might help, history shows us that most of the claims for such new ways do not stand the test of time, or are so narrowly focused as to be useless.
Programming is hard because computers do not think for themselves, will not automatically allow for variations in context. And we expected them to be right 100% of the time, no more no less. A checkout at a store needs to neither double scan or miss a scan, all the time. Whatever the angle of the barcode etc..
It is this handling of all the edge cases, one in a million conditions that we, developers, spend our time on. Until someone makes that part easy (because the usual case is rarely the challenging piece) programming will continue to be hard.
By flipping it, and having the GUI build the database instead of the other way around, you eliminate 99% of the problems.
James Hancock on June 25, 2006 08:06 PM
And by doing that YOU limit the data to that GUI. All the security, contraints, information about the database will be handled by the GUI? So when someone wants to access the data from another tool - how will that work?
Interesting article. I would like to clear up two misconceptions for your readers:
1. When writing lisp, programmers adhere to a coding standard. Editors are responsible for indentation and matching parenthesis. After 4 hours of lisp programming, you forget about the presence of parenthesis.
2. The uniformity of syntax and dynamic typing make it natural to write programs that write programs.
Well. I guess I have reached the limit of your attention span.
Good luck with that software crises of yours!
"This is exactly why we need excellent RAD tools that work directly with the design of the GUI to generate a database automatically from the form generated."
You have got to be joking me. The last thing we need are GUI which simply spray the underlying database schema into a form or a webpage. That type of behavior, which passes for "architecture" these days, creates a hideously coupled UI with the database.
Coupling == bad.