Recently in Programming Category
Surface tension
For some problems a talented designer is able to create a tiny solution that floats on water. Sometimes a solution like that is exactly what is required at the time. However, the very real limits to the size of a solution that will float in such a way should be observed. If the problem changes it’s usually better to find a new solution instead of struggling to find ways to get the tiny one to float with a donkey on its back.
Higher order programming?
So this year I entered codejam and decided to write all my answers in JavaScript. Usually I would solve any given problem in the language I felt most suitable but, I write much more JavaScript than I do anything else and the familiarity means I can write a bit faster…
It’s not going too well.
I got through the qualification round ok despite “hitting the wall” by the third of the three problems on offer. The reason I say it’s not going too well is the rubbish code I’ve created. My JavaScript looks like bad C.
My code is too crap to post here. Anybody who really wanted to could probably find it on the codejam site with some effort. I suggest nobody bother.
Anyway, hopefully by now there’s not many people around who still need convincing that JavaScript isn’t bad C or indeed, a C derivative at all… despite the semicolons and curly braces.
Still, apart from one decent object mapping section in my solution to the second problem, my solutions so far look and feel like C. Bad C. What happened to all the functional, higher order and prototypical object system code? What happened to using JavaScript the right way?
At first I told myself that the types of problems presented were really geared towards that style of coding and that it wasn’t my fault. Then I went over and had a look at some statistics from the 2008 competition.
The first thing I looked at was the competition stats for Lisp. There weren’t many people in the competition using Lisp but those that did use it were doing fine. Some really elegant solutions among the answers.
It’s interesting to go through the solutions in different languages and see how people are using those languages under the pressure of a limited amount of time for code that they know is immediately throw-away. I’ve been doing a bit of Clojure lately which may influence my opinion but the good Lisp solutions read much better that anything else I found. I know that there are a lot of exceptional C and C++ programmers out there and they were well represented in the best performers in the 2008 codejam but to me, looking at some of the code… if it was me I would probably choose not to solve the problems at all than have to write some of that code… No fun.
Personal preference? I know there’s a million C programmers out there who are much more talented programmers than I am. It’s just that, if I somehow became an awesome C programmer I’d also have an awesome migraine.
I’m a JavaScript guy and I do User Interface. If my code feels ugly and I’m not enjoying writing it that tends to infect the User Interface… and it’s the User Interface that really matters.
Anyway, for me I think it’s going to be back to SICP or The Little Schemer to see if I can rewire my brain to start solving programming problems in more elegant ways. If you’re like me, and wouldn’t want to be an exceptional C programmer even if you magically became talented enough to be one then I might suggest you do the same.
After that? Perhaps The Art of Computer Programming.
On another note, looking through some of the contestants there are a few examples of polyglot programmers who write solutions in a dozen different languages. Impressive stuff.
How far have we come?
Note: this is a sketchy rant and I haven’t backed up my arguments to any great detail. I don’t know why I feel the need to state that on my blog but… there it is.
Anyway…
The recent release of the source code for the Lunar Lander had me thinking about the relative value of code and whether programming has really advanced much in the last fifty years in terms of what people are actually achieving with software. How far have we come?
I’m probably like most “modern” programmers - when I looked at the source code for the Lunar Lander I was simultaneously astonished, horrified and embarrassed. My single adventure into the land of assembly programming left me with painful memories of hours spent writing and testing hundreds of lines of machine code for the Motorola Z80 in order to get a speaker to beep. Writing assembly code is painful. How on earth did programmers manage to write assembly code to send man to the moon?
Reading this interview from Allan Kump managed to shed some light on it for me. The Lunar Lander module code was designed by about 300 people over a 7 year period for 46 million dollars in 1967. This puts the apparent pyramid building feat of the LM into some perspective. They succeeded because they had to. It took a great deal of time, money and people to succeed.
Even then, I might question how they managed to achieve what they did without modern development techniques and engineering practices… or a drawn out beta period. How did they avoid bugs? How did they manage this task without a higher level language.
I don’t know much about their development process. I don’t think I need to and, really, I don’t find it that interesting to ponder. How about the question of bugs and no higher level language? Well….
Firstly, they did write it in a higher level language which they hand-compiled to the machine code and secondly the code was never bug free and at least one of those bugs could have been catastrophic.
However, it still disturbs me that in fifty years, we haven’t really come all that far. 1967, what else happened in 1967?
A fully mechanical ABS was in the Ferguson P99 (Mercedes had the first electronic version in their 1978 S-class).
Not that interesting. What is interesting though is this: Lisp was first specified in 1958.
You know what McCarty said about Lisp?
“Lisp will become obsolete when someone makes a more comprehensive language that dominates Lisp practically and also gives a clear mathematical semantics to a more comprehensive set of features.”
Note that it says obsolete, not untrendy.
I don’t want to get into debates around the why of Lisp not particularly been a popular success but it was first specified before work commenced on the lunar module. Would it have been a good idea to design the lunar module in Lisp?
The answer, I think, is no.
Why? The designers needed to keep touch with the input, output and with the system that they were interfacing. I don’t know how this would be achieved in Lisp at the time. I have no backing evidence for this but (this is the web and I’m writing on a blog so hey, I don’t need any) I’d say Lisp would not have been very close to the problem domain the developers were working in given that they ultimately had to hand compile it down to machine code.
What if it was 2009 instead of 1967 though? What about finding 300 developers in 2009 to write the Lunar Lander control module? What language?
For 300 developers today, chances are that Lisp still wouldn’t be chosen, or any functional language for that matter. Parentheses aside, cultural issues aside, accidents and convenience aside - the thing is that really, most developers simply do not grok the concepts at all…
I’ve been looking at some legacy code recently and the same old pattern has emerged there as I see everywhere else. The list of things that many developers seem to understand sufficiently to be comfortable using is about four things: SQL, procedures, global variables, XML.
For front-end developers just replace SQL with CSS.
Either most developers only know those things or most developers simply feel they can solve any problem with that magical quartet. Well yeah, they probably can solve all their problems with that - in a completely non-flexible, non-extensible and generally kludgy manner. Nobody cares though right? It’s all abandonware anyway, somebody will come back in ten years with an even bigger budget and redo the whole thing again exactly the same in a different system but this time use thirty times the CPU as last time.
Lisp (or another functional language) is simply too hard because it’s almost impossible to write the kind of really ugly, shit code that I know - because I’ve seen it - exists in too many code bases for legacy and modern systems written, in many cases, by decent programmers. Sure, it’s possible to write another sort of rubbish code but in my experience people who are going to write rubbish code aren’t bothered to learn clever ways to do so… The most basic features of the most accessible language will do just fine.
The solution to the nobody gets it problem, according to some pundits, was going to be Object Oriented programming. I’m actually quite confident that to a large extent that was a massive success. Why? Because, despite a bit of initial confusion it seems that a greater percentage of developers than are able to grasp other composing techniques are able to grasp the concept that instead of having lots of procedures they can partition their code into… ummm… things and attach procedures (methods) to those things/objects. Not making great use of OO but it’s a start.
Even given that, too many developers will still code by creating a bunch of procedures, initiate them from a starting point and pass any shared state they need to via whatever global mechanism the language allows. Why? Because it’s easier and they don’t need to know much of the language to do it. This is a curse that has struck many languages. JavaScript, meet the curse. Curse, meet JavaScript.
Going back to the legacy system I mentioned earlier… What is the dirty, horrible barbarian language it was written in? I’d rather not say, but… it has lambda (hand-waving version at least) among some other nice language features that help to compose software. Sure it’s got some oddities but… It has lambdas!
Perhaps this is the same tired old story paraded around but really; this legacy system might as well have been written in any language if… and only if, that language was used for nothing but lots of (basically) global procedures and variables. The developers (or most of them) had a language with some expressive power and they used none of it. Again, reminds me of JavaScript. At least JavaScript stopped short of letting people ram most of their code into SQL or XML… No wait, somebody figured out how to do that in JavaScript too.
So the new, non-legacy, replacement system is written in a modern Object Oriented language. I haven’t looked at the code base but my bet is that really it’s only Object Oriented as far the developers were forced to code in a (kinda) Object Oriented language. The attention in the code to actually doing Object Oriented is probably only as much as the developers are baptised members of the church of Object Orientation and they’re really scared of being excommunicated. Oh sure, there’s probably a bit of a perverse bastardisation of MVC shoved in there somewhere and they might map objects to the db and they probably have lots and lots of middleware and instead of a custom configuration script conjured up by a developer there’s probably nine hundred XML files instead but… you get the idea.
Of course, what the new system has is libraries and API’s ready to go that reduce the amount of actual code that any developer on the current system has to write. Now, instead of learning a language and how to program effectively in that language there’s a tendency for people to learn the language basics and then refer everything to an API that serves as a tourist dictionary. Of course, there’s more than one API and these language tourists are walking around with a bag full of dictionaries trying to communicate. This has nothing to do with the merit of one language versus another or the incredible usefulness of well designed API’s… It has everything to do with tools being applied where they should or being used as a crutch for an unrelated deficiency.
How far have we really come? I wonder.
Ever noticed how C presents with some immediacy those language features that are the first to be learned? Hello World. My Name is… Count to ten.
There are many powerful mechanisms in C and many more powerful language constructs but fundamentally the simplest of programmers really only groks just enough of a programming language to get around as a tourist. Oddly enough, the popularity of most programming languages is independent of their actual merits and most closely tied to how easily a tourist is able to find the nearest public toilet.
Perhaps because of this shortcoming the general approach over time seems to have been removing the language aspect of programming as much as possible. Given that developers are not capable storytellers in the programming language they have to use a whole heap of effort goes into IDE’s and tools by which developers are able to avoid writing programs. So great was the extent of this that the era of GUI programming came about in many arenas from WYSIWYG to a misguided hope that one day developers could create UML diagrams and have a large proportion of their code written for them.
That was the dream. People would go to the nth degree to model everything and design everything up front and the handle got cranked and out popped a UML diagram. The model would be run through a model checker and then the handle would get another crank and out popped all the code nicely done. Application finished.
Then what?
Then it’s discovered that nobody can use it because the “developers” were too busy navel gazing to check at any point if the original specification provided something that anybody could use… assuming anybody even wanted anything like it in the first place.
I think it is a mistake for anybody to think that programming is purely an exercise in symbol manipulation with developers sitting in their Searle Chinese Room translating symbols from one representation to another.
Actually, I don’t think it’s just a mistake. I think it is exactly the wrong idea. The removal of emphasis from language is wrong. Humans are good at language, exceptional at language, but instead of applying that linguistic ability the trend was towards making people push coloured blocks around a page as if the extent of their creative ability was on par with a parrot such as Alex.
Alex can’t tell stories. Programming is about telling a story.
Good programmers have a concept in their head about the software they’ve written, a narrative through a story told by the code they have written. Code smell? It’s a result of a poorly constructed story, a bad plot, wooden dialogue.
Programming should be a linguistic activity, it should be a craft and it should have a design component. A good program should read well and be entertaining all by itself. It makes absolutely no sense to me that anybody would want to remove the language component for programmers unless we really want to start using parrots to do software architecture… pushing those coloured blocks around and churning out software.
As for that Lunar Lander… I bet every single person working on that project was excited to be working on a system that was involved in sending humans to the moon. That’s a pretty good incentive for making sure it works regardless of what it was coded in.
Anyway, apparently they built the pyramids without any computers at all. I sure bet they had language though.
Objects, messages, users, people
One of the highlights for me at JAOO Sydney 2009 was Dave Thomas’ talk on Cloud computing. Among other things, he talked about the vast dinosaur swamp of OO middleware that Java developers will be having fun maintaining for the next thirty years.
As somebody whose programming time is mostly either UI related in JavaScript or hobby coding in whatever takes my fancy in a given week (this week it’s factor) I was in a good position to laugh in a “it’s funny because it’s not happening to me” way at the humorous insights from Dave, the self confessed former Pied Piper of Objects. Actually, I found it especially amusing because my recollection of computer science at university in the late 90’s was that almost every student at the time was begging, demanding, wailing and gnashing their teeth… to be trained as a member of this army of average Java middleware programmers.
Of course, opting to code UI in JavaScript long ago revoked my membership to the fraternity of real programmers so my hyperbole on these things can freely be dismissed as nonsense by that part of the world shepherding business objects for a living.
I was raised on objects. I like objects. I do not like what we did with them.
In particular, I don’t like that I can sit in a meeting of non-programmers who once walked past a Computer Science 101 lecture and hear somebody saying that “we should take an object-oriented approach” to the problem.
I don’t like that anybody doing architecture ever talked in terms of UML class diagrams where all the business objects were drawn and detailed and then all the messages, you know the actual stuff going on was reduced to zero. It’s all interface, all objects and nothing happening. That’s not designing a living system for code, it’s designing a pyramid to bury people in.
All objects with no messages, no configurability, no data. Everything else got moved or obliterated until finally, finally when somebody turned around and realised “Hey, we need ways to do a bunch of this other stuff” the answer that came forth was XML. So now there’s this whole universe of people programming all the important parts of their software in XML. I don’t care to take a guess at how that is going to work out.
Of course, that was all too hard for many people and instead of following the musical pipe they went off to use PHP, broke every single principle of good, bad and ugly software design - including some that weren’t invented yet, and still managed to get things done. That said, I’ve done enough work with things such as the Wordpress template system to be reasonably confident that something has gone horribly awry and that there’s a good chance that a whole community of programmers will also be keeping themselves in jobs maintaining the mess they’ve created in PHP.
Back to JAOO though, it was good to see a strong representation for dynamic languages, DSL’s, functional programming and on top of all that, it was good to hear all types of people with a good sense of history and architects talking about service oriented architectures and composition.
Now, at this point I would assume that any lispers still paying attention to current trends can only be wondering why it took so many dances around the prickly-pear tree before more people started to “get it.” The lispers may have questions such as “Did it really take fifty years for lambda to even start entering mainstream consciousness?” and “Is XML really what you made of s-expressions?” and those would be just warm up questions… what happened?
The shift to DSL’s is encouraging… I can only hope that this time we can actually get them right as almost everything that has come before has been an abomination. That goes double for most of the 4GL’s around, I’m looking at you CSS. The problem with most 4GL’s is that they were designed to suit the problem, not the people who had to solve the problem. I think one of the big challenges going forward will be how to design languages, or design the space around which languages can develop, that work better for users… while still maintaining conceptual purity and elegance.
Programming language design philosophy
Guido van Rossum has started a series of articles on the history of Python with the first post being on the Python design philosophy. Guido’s guiding principles read like design patterns… you know, pattern language style, before it was all implementation patterns and UML diagrams.
Most languages come from one person and their specific design patterns reflect heavily on the language forever. We can look at Larry on Perl as a post-modern language, Matsumoto on Ruby, Paul Graham on Arc, Richard Gabriel on Lisp, C and worse-is-better and of course, the Guy Steele ‘98 OOPSLA classic “Growing a Language (video).
Interestingly, most of the language creators still seem to enjoy their creations. Eich seems to be in a minority. Is JavaScript the only language where the creator openly derides it?
All designers have to be careful not to simply create a monument (statue, pyramid etc) to themselves. Taking a lesson from Dewey’s “Art as Experience” - that the value of art is in the experience for the user - the artistic value of a programming language is the value for the people programming in that language.
There’s (at least) two particular design difficulties with programming language design:
1. The extent to which the language designer influences the entire set of universes created with it
2. A programming language is an expert environment which makes is very difficult to figure out how it will be used…
Design by an amateur would be many times more disastrous in the case of a programming language. For good reason, language designers are typically both expert programmers and experts in compiler implementation. Even then, the whole affair seems to be fairly hit-and-miss even for people who’ve already designed great languages… by pure luck we seem to have gotten some languages created by people who were also talented language designers. Still, I think Alan Kay is right when he says in an interview in Queue that “nobody really knows how to design a good language, including me.”
Going back to JavaScript though, what of its design philosophy? (apart from the ones dictated by timelines) I’m paraphrasing from memory here but Eich essentially said source code sharing and simple powerful primitive mechanisms were ideas for JavaScript. I’m leaving out some really good (lambda and prototypal inheritance) and some bad (which I won’t bother hashing over) ideas because they don’t really feel like ideas behind JavaScript but more just things that happened to be there.
Powerful primitive mechanisms was also design goal for Lua. I don’t know if Lua’s success is due to that or simply, because like JavaScript, it seems quite familiar. Still, can we say for sure that powerful primitives is a worthy design goal for any programming language?
Over on LTU there’s a post asking if there are any resolved debates in programming language design. Nothing much has been resolved enough to be even considered resolved in that thread.
In some sense you could distil most programming languages down to some basic quiddity. Perl - post modern, smalltalk - message passing… Quiddity is probably a fitting word, I like both uses of the word quiddity for this because whilst we can say something about the fundamental nature of a particular programming language with such distillations, what we end up saying can, in effect, often be a trifle. That’s kinda where the LTU thread seemed to go.
Anyway…
I wonder if we could create a language based on some fundamental principles from semantic primitives?
On being prolific
There’s a post over on Coding Horror with the title Quantity Always Trumps Quality that gives an example of a circumstance in which promoting output volume (quantity) resulted in better quality than promoting quality for itself after a set number of days.
That circumstance is an individual (or group) in a learning environment.
This seemed initially like a fairly tame and uncomplicated message for Jeff to put forward. Judging from some of the comments he’s received though, apparently it wasn’t, with a whole host of people taking exception to what he posted.
As I was reading those comments I had a few ideas running through my head ranging from Dewey to Feldenkrais, trying to think of how to word an argument for why it’s good advice. In the end though, I don’t think anything overly complicated is necessary. Only the following:
In order to learn a new skill, practise is essential. There are many ways to practise and often related activities, including thinking about practise, count.
The individual needs to be increasingly reflective as they practise. Not only because it helps improve the skill being practised but also because it helps improve the skill of improving.
It is conducive to improving overall output quality if the teacher encourages volume of practise. A beginner is not really in any position to be theorising about how to produce work of the highest quality when they have no experience of the activity they are theorising about. Firstly, the beginner is typically unaware of how much they don’t know, so their theorising can be misdirected. Secondly, even if the beginner manages to find some really good ideas about how to produce quality work, without sufficient practise they will typically be incapable of actually producing it.
The question is how to achieve quality, not about whether quality is important or whether that is what the student should move towards (surely those are not debated?) The question is simply about how to get the student there. The answer put forward, which I think is the correct one, is to encourage the individual to practise frequently, make mistakes, learn and improve.
As an aside - Steve Yegge has an old post entitled Practicing Programming which is worth a read.
As for calling software development an art, I am perfectly comfortable with that. It was good enough for Donald Knuth and there are many reasons why I think it’s still good enough today. I will, however, take the liberty of being elliptical and not detail any of them.
Thoughts on
tagged with
- event handling
- observations
- language
- opinion
- agile
- baudrillard
- C
- cacheability
- codejam
- correctness
- dependencies
- focus
- forms
- game
- gentoo
- growth
- idiom
- intentionality
- interface
- language design
written in
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- August 2008
- July 2008
- June 2008
