Notes on two presentations by Gordon Bell ca. 1998
|
From: "Andy "Krazy" Glew" on 21 Feb 2010 02:42 Chris Gray wrote: > "Andy \"Krazy\" Glew" <ag-news(a)patten-glew.net> writes: > At the level of a compiler, there are some problems. One has to do with the > basic parsing of such code. A mini-language will typically introduce new > keywords to the language. What if there are conflicts between a pair of > mini-languages created by different people? How does the compiler parse > something that contains syntactic extensions from multiple sources? There are > solutions to problems like this, but they require care to define. My initial > thought is that a "package" containing a bunch of type definitions, > declarations code, etc. should indicate what mini-languages it uses. That > should let the compiler handled it properly. Trying to do this kind of thing > at a finer level could easily produce an unmaintainable mess. I am a big proponent of languages that use XML syntactically. XML capable editors are now widely available. Even for conventional languages like C and C++ this would have advantages. Think of how many programs are broken when new keywords are added to the language - e.g. think of how many C programs broke, when they could have compiled in C++, except that they used C++ keywords like "class" and "private". E.g. while the user might type "if(cond) { then_code(); }" the editing system might produce, internally <keyword>if</keyword>{then_code;} etc. And colorize semantically to boot. With this mindset, conflicting keywords in different mini-languages are just an issue of namespace: if modules A and B both introduce keywords "scan", it might look like <A::keyword>scan</A::keyword>dA_atastructure(<B::keyword>scan</B::keyword>scan(B_datastructure)); (Although this example has little advantage over function calls.)
From: Kai Harrekilde-Petersen on 21 Feb 2010 03:09 Del Cecchi <delcecchinospamofthenorth(a)gmail.com> writes: > Andy "Krazy" Glew wrote: >> I have a dream: >> * New languages, yes >> * But no more gratuitous invention of new languages >> * New languages for the new stuff only > > Are things like SPICE, Verilog, VHDL, considered programming languages > or something else? I definitely consider Verilog and VHDL to be programming languages, although with limited applicability. Kai -- Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
From: Morten Reistad on 21 Feb 2010 04:41 In article <utytbj9h0.fsf(a)harrekilde.dk>, Kai Harrekilde-Petersen <khp(a)harrekilde.dk> wrote: >Del Cecchi <delcecchinospamofthenorth(a)gmail.com> writes: > >> Andy "Krazy" Glew wrote: >>> I have a dream: >>> * New languages, yes >>> * But no more gratuitous invention of new languages >>> * New languages for the new stuff only >> >> Are things like SPICE, Verilog, VHDL, considered programming languages >> or something else? > >I definitely consider Verilog and VHDL to be programming languages, >although with limited applicability. The only one of these I have read enough about to have an opinion is VHDL; but from what I have seen VHDL is definatly one of these languages I am discussing. -- mrr
From: nmm1 on 21 Feb 2010 07:08 In article <gis557-585.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <4B8021BB.4070401(a)patten-glew.net>, >Andy \"Krazy\" Glew <ag-news(a)patten-glew.net> wrote: > >>> But it is the only path I see to contain complexity. >> >>I mainly agree with Morton on this. Invent a new notation that >>simplifies thinking about the problem, and use that >>notation directly to express the solution as a program. >> >>Even better if somebody else can make the implementation of the idioms >>of the new notation faster, better. >> >>My only difference is that I hope that it may be possible to define a >>meta-language, in which many of the new notations >>can be expressed. > >I am not certain that this is a solvable problem. I would be happy >if we could make significant parts of the language toolchain common. > >I have arrived here after making a few of these languages in the >completely wrong manner, as "config files" that have outgrown all >sense. Mostly it has been by adding macro processors, lexical sugar, >simple program constructs etc. > >The most difficult part is not the language syntax. We have lots of >tools for that. The real challenge is the declarative powers of >such languages. The imperative programming model that sits so powerfully >with programmers (i think that is one of the lures about programming) >is under challenge here. Er, no. That was true in the 1960s, but isn't today. I agree that the syntax isn't the issue - and it wasn't then. Back then, a large proportion of the complexity was introduced because the languages were not expressive enough. That led to the specialist, higher-level languages, initially in engineering and statistics. Today, most languages are more expressive than almost anything that existed then. The problem, today, is that much of the complexity is introduced by the language itself, usually in the form of subtle interactions and "gotchas". Parallelism is particularly susceptible to this, of course. The functional programming brigade claim that is the solution, but all experience is that it is at most a slight help. There are other such approaches. What we need is more disciplined languages and, in particular, ones where the programmer can build components that are as safe and checkable as the basic primitives of the language. I.e. the key is control of complexity and not its reduction. Regards, Nick Maclaren.
From: Morten Reistad on 21 Feb 2010 08:56
In article <hlr7nr$qug$1(a)smaug.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >In article <gis557-585.ln1(a)laptop.reistad.name>, >Morten Reistad <first(a)last.name> wrote: >>In article <4B8021BB.4070401(a)patten-glew.net>, >>Andy \"Krazy\" Glew <ag-news(a)patten-glew.net> wrote: >> >>>> But it is the only path I see to contain complexity. >>> >>>I mainly agree with Morton on this. Invent a new notation that >>>simplifies thinking about the problem, and use that >>>notation directly to express the solution as a program. >>> >>>Even better if somebody else can make the implementation of the idioms >>>of the new notation faster, better. >>> >>>My only difference is that I hope that it may be possible to define a >>>meta-language, in which many of the new notations >>>can be expressed. >> >>I am not certain that this is a solvable problem. I would be happy >>if we could make significant parts of the language toolchain common. To elaborate on this, I have seen some examples of such languages grow; and some have grown organically to be monsters. The success criteria are sometimes weird. One example is that the PABX control language that succeeded best was the one where they did away with the program counter completely. The sequence is instead the logical progress through switch steps. You can have exceptions all over the place, but they are logically defined from a standpoint of a PABX installer. Sendmail.cf, that parses around 90% of the worlds's email, has a similar progress through rule sets. >>I have arrived here after making a few of these languages in the >>completely wrong manner, as "config files" that have outgrown all >>sense. Mostly it has been by adding macro processors, lexical sugar, >>simple program constructs etc. >> >>The most difficult part is not the language syntax. We have lots of >>tools for that. The real challenge is the declarative powers of >>such languages. The imperative programming model that sits so powerfully >>with programmers (i think that is one of the lures about programming) >>is under challenge here. > >Er, no. That was true in the 1960s, but isn't today. I agree >that the syntax isn't the issue - and it wasn't then. > >Back then, a large proportion of the complexity was introduced >because the languages were not expressive enough. That led to >the specialist, higher-level languages, initially in engineering >and statistics. Today, most languages are more expressive than >almost anything that existed then. There seems to be a best current practice about simple languages for people that aren't primarily programmers, but want to write programs to assist in their profession. This consensus seems to land on a language that has the simplicity, learning curve and "playfulness" of logo, pascal-like structure and enforcement, and that integrates primitives from the profession in question. But there are surprises. This seems more of an ideological tilt than firm data. Firm data on these things is very scarce; perhaps we need to publish some case studies. But the implementation of the basics of such a "sandbox language" shouldn't be more complex than a normal week-assignment in a CS207 course. This is not the issue. The issue is to isolate the sources of complexity from each other. Then there is the ideology from academia that leads firmly to using a framework like haskell or scheme to define "mini-haskells", or another specialised scheme. My experience is that that is royal overkill, and that the people we want to use these applications will not handle that. I have tried to gently introduce these concepts to the application people at several occasions, but I see instant detatchment. At a PPOE I even build a simple application-specific lisp that was immensly powerful for the little field it covered, and could do some 10-minute prototyping of some important ideas, but I ended up as the only user. >The problem, today, is that much of the complexity is introduced >by the language itself, usually in the form of subtle interactions >and "gotchas". Parallelism is particularly susceptible to this, >of course. The functional programming brigade claim that is the >solution, but all experience is that it is at most a slight help. >There are other such approaches. If we think we need parallellism we need to have that integrated into the core language, and not be something the application programmer has to worry about. A language that is powerful on the declarative side, and uses messages and on-units can be parallellized pretty well. But this is for the "computer-science" side of the big divide. If the application is a success we can get down to optimizing the execution, completely separate from the applications. >What we need is more disciplined languages and, in particular, >ones where the programmer can build components that are as safe >and checkable as the basic primitives of the language. I.e. the >key is control of complexity and not its reduction. We have several source of complexity. We have complexity from the platform and toolchain; we have complexity from rules, regulations and policy, and we have complexity from human interaction. Just breaking these up to be handled separatly is a huge win. I have seen way too many projects where there is a tremendous conceptual stretch between the implementation framework and the application. Examples are where core database sementics has to be included into every single application, or where you have to watch locks and semaphores all the time when you touch data structures. This gives an n-squared complexity, where you have to handle all the "platform complexity" in all the applications. You can get a bit away from this with good libraries, but you still have the issues there, all the time. I want to take this a lot further. I want to have the language itself reflect the field in question. If we are doing finance, I want the definition of an options straggle to be a 10-line declaration, in syntax that is straightforward for a financial analyst to understand. If we are controlling phone switches and ac queue should be just as simple to define. And if you goof in the definition, you have a fault in the option definition; or a nonfunctional acd queue, not a systems problem. I am not particularly interested in the language used for the core functions, either. We will hopefully have generated a lot of the code for it, anyway, using the lexers and tokenisers in favour; and it will use libraries intensively. This tends to push us towards c, because it seems to be the natural target for code generation. And since we have no intention of letting application programmers loose we control many of the huge shortcomings of that language. I have no ambition whatsoever of combining the two program sets. If we want to communicate outside our sandbox a set of catch/throw verbs that can move xml'ised variables around should do the trick, -- mrr |