My mother, or so I am told, had a device for dealing with that frustrating syndrome where you wake up in the middle of the night and your damn brain decided to tour all the things that are making you anxious. The trick was to try and enumerate something, for example vegetables in alphabetical order.
So I’ve be trying this out but I needed something to enumerate. At first I was enumerating foods, and then I started adding constraints. … gizzards, haggis, intestines, … Then I started enumerating programing languages: APL, Basic, C, Datalog, … But it was became fun to try and include a language only if it has some aspect that makes me smile. For example the function calling weirdness in SL5. Elang is a layer cake of odd smilies, though then I can’t use E. R is a must have for how evaluates function arguments.
You might pick Caja[1,2] for C. And that lead me to recall Dart. I’ve been meaning to go back and see what’s up with Dart. This talk is a fascinating entry point into Dart, at least for me. Google managed to find a good guy, Gilad Bracha, for this design challenge!
For the me the tasty thing in this talk is that they are trying to stand in the middle ground between a dynamically typed language and something, well, something else.
This decades after what Common Lisp did about this problem. In Common Lisp you can declare that something is, for example, a small integer; but the programming environment can ignore that; it’s just advice. In fact even in a single language environment how that statement effects things can vary depending on other stuff like optimization settings. If you implementation ignores the declarations then they practically comments. I think it was an Algol manual that documented comments by saying “the compiler makes no effort to check the correctness of the comments.” This wiggle room makes some people’s skin crawl. And, it’s certainly enticed a lot of engineering effort on the part of Common Lisp implementors.
In fact a Common Lisp programmer can do wonderfully weird things with the type system and declarations. For example we can define a type that asserts our graphs are acyclic and provide a predicate that we only use in desperate situations.
(defun acyclic-graph-p-for-type (g) (if *desperate-debug* (acyclic-graph-p g) t)) (deftype acyclic-graph () (and graph (satisfies #'acyclic-graph-p-for-type))
The reason I found that Dart talk so interesting is the how Gilad deals with the skin crawling issue. He adopts a war weary Eeyore-ish manner. I can totally relate. He makes no real effort to argue why this is a useful such a powerful and useful approach. In fact I’d say he baits his audience into an absence of sympathy.
I’ve done some very fun things with type systems that are analogous to what he is calling optional typing, for example this diagnostic typing I described a while back.
I’ll have to dig some more to see if any of the Caja ideas survived into Dart. But they are similar, in the sense that there turn out to be many type system like blankets one might want to throw over your program to make you feel more cozy. And if you insist that on exactly when in the program life cycle, if ever, they are checked (or worse proven) it’s just not as much fun.
The talks also made me sad. It’s clear there is a lot of language design argot that I haven’t kept up with.
… junket, keratin, …
