Some quotes from “Lucid” book: Haskell, beware!

“Lucid, the Dataflow Programming Language” by William W.Wadge and Edward A. Ashcroft (chapter 3, page 75) :

The problems with imperative languages mentioned in the introduction (enormous complexity, lack of formal specifications, difficulties in expressing parallelism and so on) are products of the imperative philosophy itself, and are caused by the clash of imperative features (like assignment) with declarative features (like recursion). If the designers of non-procedural languages try to borrow imperative features, they will end up borrowing the problems as well. Nonprocedural languages will succeed by developing the strength of the nonprocedural approach, not by imitating the weakness of the imperative. When first designing Lucid, for example, we worried for some time because the usual one-update-at-a-time array algorithms (e.g., for sorting) appeared somewhat inelegant in Lucid. Finally it occurred to us that perhaps this sort of strict sequentiality is not such a good idea in the first place.

And also (chapter 5, page 119):

Of course, we could adopt a sort of nonprocedural Cowboy attitude. We could claim that Lucid is such a good language, that its tools are so powerful, that you do not need strategy. This attitude is not completely unfounded. Programs in Lucid (and in nonprecedural languages in general) tend to (be) noticeably simpler, more elegant, and above all shorter than corresponding programs in the competing imperative languages.

We cannot stop programmers from using the language in any away they want, but as for ourselves we think that programming strategy is all-important – no amount of cleverness or powerful tools can compensate for bad strategy. It is true, though, that the Cowboys can take on bigger tasks that ever before, while relying only on their wits. Nevertheless, even the toughest Cowboy will eventually be ‘Dry Gulched’ by a really nasty problem, and having powerful tools only postpones the day of reckoning.

Overall, I think that this book is grossly underestimated…

Scheme & Pattern matching

To continue this fine set of rules, here is another one:

Any sufficiently complicated Scheme program contains an ad hoc, informally specified, bug-ridden, slow implementation of pattern-matching primitives

Pattern-matching is a notable omission from Scheme standards, which partly can be blamed on the statically typed offspring that do have pattern-matching. I argue that:

1. Pattern-matching has value for dynamically typed languages too: the use of patterns in type inference is important but it’s not the only reason for pattern-matching. It’s probably even more important for dynamically typed languages like Scheme, since they have no way of dispatching on types at compile-time, while this feature can be provided by pattern matching.
2. Pattern-matching simplifies life of great many applications: pretty much every complex Scheme application is full of stuff like this:
   
(let ([datum some complex stuff])
(let ([field (cdadr datum)])
(case (car datum)
([foo bar] (process field)))))

   Which can be expressed like this with pattern-matching cases', which implicitly auto-quotes the pattern (requiring you to unquote the pattern variables):
   
(cases' some complex stuff
| ([foo || bar] ,(_ . field)) => (process field))

   or, with cases, which doesn’t do auto-quoting (requiring you to quote literals):
   
(cases some complex stuff
| (['foo || 'bar] (_ . field)) => (process field))
   
   Note how the “parentheses problem” becomes much less pronounced with pattern-matching in-place (mainly due to removal of a few superfluous lambda abstraction levels)!
3. Although pattern-matching in Scheme can be easily implemented with
syntax-rules, making it interoperate with the type-system and the need for speed does require native implementation.

The terseness of Knuth

Its never too late to discover the terseness of Knuth on a number of very relevant issues (still, even after so many years!)

Its amazing how one can make a political statement by just asking the right questions and never answering them …

Hello world!

Welcome to WordPress.com. This is your first post.
(display "hello world")(newline)