Lambda the Ultimate

I thought that denizens would be interested in this post by John Gruber about the problems caused by the notion that making Applescript syntax work like English would lead to a friendlier language: http://daringfireball.net/2005/09/englishlikeness_monster

Besides Cobol and Perl are there any other languages where the designers felt that making the syntax resemble English (an evolved rather than designed language with legacy syntactic structures stretching back thousands of years and a history of ambiguous usage) was a good idea? Surely someone must have done some research showing why this usually leads to languages that are harder to work?

This raises some interesting questions about the ways in which language design happens. Should we be paying more attention to the choice of syntax (even though semantics matters I'd claim that in most of the languages used by the vast majority of people the scoping rules and type systems don't wander out of a narrow range of options) and using syntax lists such as this one: http://merd.sourceforge.net/pixel/language-study/syntax-across-languages/ compiled as part of the Merd language project?

After reading a previous thread on debugging I got to thinking about an experience of mine involving debugging a hardware device called a digital filter. This was a big deal involving many people.
We knew for sure that this thing wasn’t going to work from the start and had a step by step plan to debug it at the beginning of the project. Even though this was a hardware project the similarities to what is going on now are too obvious to point out. Digital filters are easily modeled using state and are easily implemented using ordinary OOP software.

Now the key idea is that state systems are really feedback systems. This is very obvious from a hardware point of view because that is the way they are built. I can’t draw a block diagram here so I will try to describe it: Digital filters consist of many patterns of the following type. An input is fed into a subtractor(S) then into a register(R), The output of the register is fed to a multiplier(M) and then fed back to the subtractor(S). The loop R,M,S is the feedback loop. The output is usually the contents of R.

Now from this perspective it was obvious to all of us that in order to debug this thing we had to open up the feedback loops at S and simply go around the circuit and compare the actual values with what should be there for a given input based of a simulation. This is a full proof method and produced a working system after many weeks of tedious work and rewiring.

Here is the problem as I see it. State systems and the state abstraction always involve feedback and the feedback loops may not be obvious. The only full proof and deliberate way to debug such as system is to open up the loops and trace results compared to an open loop simulation. Open loop tests were once common and were often built in.

I am not sure what this means but here is one debugging idea. Suppose we design a system or language to carry a list of its states. And suppose also that we can temporally make those states a constant type (ie not updateable). Now theoretically at least we are in a position to trace through various values based on that state. Another idea might be to log or break whenever a state is updated. I wonder what other readers think about this. This is all fairly obvious but I haven’t seen it myself.