Re: proposal: state machine syntax also usable for continue / nested break

[Everett L Williams II <rett@...>]

steve donovan wrote:

the constructs available in such languages. The problem with great power is
that it normally engenders subtle syntax, making readable by only a very
limited set of readers. That is where lua resides.
    

Most people would be advised to keep their code as straightforward as
possible, and Lua provides the mechanisms so that a simple subset can
be used, with a little library help.  The essayist Paul Graham writes
about 'keeping programs in your head', (explicitly acknowledging that
people have limited cache) and so the strategy for big programs is to
build a dialect that expresses the domain well.  So the actual core
becomes manageable and fits inside the average programmer's head.

  

This is an excellent piece of advice. It has long been one of my rules. I write no code until I can see the entire program in my head. In my case that certainly limits it. It certainly has made sure that I don't write complex garbage that is difficult to follow. As a newbie, I knew every nook and cranny of every language that I used, to include Assembler, and I often used a large part of that knowledge. What I discovered was that I became a slave to those "brilliant" pieces of code, because no one else could maintain them, and that prevented me from easily moving on to other things. Once trapped, twice shy...from that point on I formulated two new rules. First, was your rule, and second, if this piece of code is not going to look understandable at 2:00am six months from now, you probably shouldn't write it that way, and if you do, you had better write a very large chunk of doc to explain just exactly what you had in mind, and how what you did got the job done. Actually there was a third rule that enforced the first two, and that was that someone else had to make the first correction or addition to the program. If they could not, then you probably did not follow rules one and two.

reasonable effort, figure out how to interface with C or Cpp programs that
they did not write is not just logically ridiculous, but palpably
exemplified by the massive systems of code that are out there at the heart
of so much of our current programming world.
    

Most of the world is written in C, so that's what we sit on and have
to build abstractions on top of.

steve d

Steve,

I realize that C and Cpp have become that base, but it is an unwieldy and limiting practice that emphasizes the skills of coders over those of designers. There is a whole area called Agile/XP(extreme programming) that has risen up around this code now, fix and design as you go along mode, and I find it useful for commercial code, and evil for that type of base code that all depend on to make their commercial code. Base code requires a full understanding of how the base structure of systems and programming must work, and slapping it together as you go is an absolute disaster. I have always regarded coding as a trivial and boring task that should occupy no more than 10-20% of the effort in any project. Once I have a program working in my head, I can write literally thousands of lines of code in a day, if the language is straightforward. I also learned that, rather than festoon a core with exception after exception and variation after variation, it is easier, cleaner, and in the long run faster and more maintainable to separate out major and even some minor variations on a theme. There is more code, but it is easily repicated, and as exceptions and variations multiply, there effect on the code is much smaller and more limited in scope. There is this horrid tendency to pack everything to do with one stream of data into one big Christmas tree, and you can almost hear the code screaming in agony. But enough.

I am a mathematician by education, and it did not take me long to realize that math was not a science, but a tool of science, and one could get lost in the crystalline beauty of the math without realizing that math can express any consistent logical stream, having absolutely nothing to do with reality. That is how I see lua. It is a beautiful artifact that allows access to the basic mechanisms of functional and object oriented programming without necessarily doing something useful or even intelligible. On the other hand, solving a difficult equation or building a gem of a program in lua gives a great deal of personal satisfaction, but that is not usually what I have in mind when I sit to program.

Everett L.(Rett) Williams II

Everett L.(Rett) Williams II