By now you’ve seen my preference for programming languages like Lisp and Python: interactive and not so strongly typed.
K&R C is like this also, but is not interactive (leaving aside C interpreters like CINT and Ch). Originally everything was an int.
So what does ceremony have to do with programming? A high ceremony language like C++ or Java (or ADA) involves lots of boiler-plate code, such as type definitions and wrappers that are required before the meat of the program can be written. COBOL seemed to start all this.
It seems to me that a lot of the Microsoft language environments have reams of boilerplate code to negotiate. Yes, there are large Integrated Development Environments (IDE) that will generate the boilerplate for you — but you have to master those.
There’s a place for high ceremony to be sure, especially when the tasks are well-defined, but if you wish to solve a problem and can’t afford the overhead then a low ceremony language can be a godsend.
Perl is a well-known “swiss army knife” that can be low ceremony (Careful! It can quickly become high ceremony when you start using the object system). Also Perl is not really interpreted (there is a debugger that can be invoked — but that’s nothing like an immediate mode) — Python and Lisp have a true Read-Eval-Print Loop (REPL).
BTW: Clojure has better concurrency support than Python just now, Python has great mechanisms but has a single interpreter lock which negates much of its concurrency support. I’m not sure why this hasn’t been fixed, Python has a wonderful community.
This allows for a much quicker development cycle on the front end as you learn what you’re up against. Functions and data can evolve on the fly until the tests pass.
(You ARE using test driven development including boundary/corner cases, right?)
My feeling on the matter is that solving new problems is hard enough and I prefer the language to get out of the way.
Easy to tell I started with ZetaLisp on a Symbolics Lisp machine, eh?
Finally, a little fun.
The Unix Haters Handbook was published in 1994 and is available online here. Here’s a bit from the preface: an email from John Rose in 1987. (How far we have come, how much things remain the same 🙂 )
Pros and Cons of Suns
Well, I’ve got a spare minute here, because my Sun’s editor window evaporated in front of my eyes, taking with it a day’s worth of Emacs state.
So, the question naturally arises, what’s good and bad about Suns?
This is the fifth day I’ve used a Sun. Coincidentally, it’s also the fifth time my Emacs has given up the ghost. So I think I’m getting a feel for what’s good about Suns.
One neat thing about Suns is that they really boot fast. You ought to see one boot, if you haven’t already. It’s inspiring to those of us whose LispMs take all morning to boot.
Another nice thing about Suns is their simplicity. You know how a LispM is always jumping into that awful, hairy debugger with the confusing backtrace display, and expecting you to tell it how to proceed? Well, Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. What could be easier? If there’s a window involved, it closes right up. (Did I feel a draft?) This simplicity greatly decreases debugging time because you immediately give up all hope of finding the problem, and just restart from the beginning whatever complex task you were up to. In fact, at this point, you can just boot. Go ahead, it’s fast!