Notes on two presentations by Gordon Bell ca. 1998
|
From: Robert Myers on 14 Feb 2010 23:20 On Feb 14, 7:57 pm, Fred the Freshwater Catfish <usenet.f...(a)bdtd.invalid> wrote: > Oops, sorry. Missed alt.test. > > Fred the Freshwater Catfish Is this an attempt at humor? Robert.
From: Tim McCaffrey on 15 Feb 2010 21:20 In article <4vrk47-e5e.ln1(a)laptop.reistad.name>, first(a)last.name says... > >I have long advocated "surface languages" to address such complaxity. >This may mean actually designing new languages for the applications. >There is huge resistance to doing this. But I see daily the productivity >that it generates. > >The asterisk extensions language, sendmail.cf and sed/awk are examples >that even pretty ghastly languages can boost productivity radically >when they address the issue at hand directly, and manage to bury >complexity. > >We need more languages. > >This is where the junior programmers scream foul, of course. When >they have to master language implementation and a new, initially >pretty volatile language definition. > >But it is the only path I see to contain complexity. > Interesting, as this is basically what, at least one, (fairly) modern compiler does when optimizing. The internal representation is translated into something more friendly to whatever optimization pass is being done, then the result is translated back into a more generic representation. Makes my head hurt to look at the code, but it is effective. - Tim
From: Robert Myers on 15 Feb 2010 22:22 On Feb 15, 9:20 pm, timcaff...(a)aol.com (Tim McCaffrey) wrote: > In article <4vrk47-e5e....(a)laptop.reistad.name>, fi...(a)last.name says... > > > > > > > > >I have long advocated "surface languages" to address such complaxity. > >This may mean actually designing new languages for the applications. > >There is huge resistance to doing this. But I see daily the productivity > >that it generates. > > >The asterisk extensions language, sendmail.cf and sed/awk are examples > >that even pretty ghastly languages can boost productivity radically > >when they address the issue at hand directly, and manage to bury > >complexity. > > >We need more languages. > > >This is where the junior programmers scream foul, of course. When > >they have to master language implementation and a new, initially > >pretty volatile language definition. > > >But it is the only path I see to contain complexity. > > Interesting, as this is basically what, at least one, (fairly) modern compiler > does when optimizing. The internal representation is translated into > something more friendly to whatever optimization pass is being done, then the > result is translated back into a more generic representation. > > Makes my head hurt to look at the code, but it is effective. > Maybe I am a junior programmer. New languages, without profound insight, are academic masturbation. Compiler intermediate representations are a different matter, but who talks about them? Robert.
From: Morten Reistad on 16 Feb 2010 03:57 In article <d1171014-351b-4b7f-8cdf-9808c2bb3dd9(a)u9g2000yqb.googlegroups.com>, Robert Myers <rbmyersusa(a)gmail.com> wrote: >On Feb 15, 9:20�pm, timcaff...(a)aol.com (Tim McCaffrey) wrote: >> In article <4vrk47-e5e....(a)laptop.reistad.name>, fi...(a)last.name says... >> >There is huge resistance to doing this. But I see daily the productivity >> >that it generates. >> >> >The asterisk extensions language, sendmail.cf and sed/awk are examples >> >that even pretty ghastly languages can boost productivity radically >> >when they address the issue at hand directly, and manage to bury >> >complexity. >> >> >We need more languages. >> >> >This is where the junior programmers scream foul, of course. When >> >they have to master language implementation and a new, initially >> >pretty volatile language definition. >> >> >But it is the only path I see to contain complexity. >> >> Interesting, as this is basically what, at least one, (fairly) modern compiler >> does when optimizing. �The internal representation is translated into >> something more friendly to whatever optimization pass is being done, then the >> result is translated back into a more generic representation. >> >> Makes my head hurt to look at the code, but it is effective. >> > >Maybe I am a junior programmer. New languages, without profound >insight, are academic masturbation. Compiler intermediate >representations are a different matter, but who talks about them? I am talking about bringing the full set of language features into applications, and letting the application form the language, not the other way around. Today applications are captives of their tools, be it Java, C, haskell, perl or php. I am talking about a class of languages that would be scorned in any cs class. _Very_ application-spesific ones. One theoretical example would be a bookkeeping language. Where t-accounts, batches, transactions (bookkeepin ones, not database ones), audit logs, tax handling hooks (on-units, really), bankers rounding, infinite, but undetermined variable length, access rules, value restrictions etc are all part of the language. And a very strongly typed language. And the language implementation is audited, and accepted as safe from an audit-perspective; so you can write your scripts with wild abandon, trusting the audit and rollback/forwards in the language. Add a message-passing interface, and you could have this system handling your business logic. You could script it with wild abandon, because the language itself provides the audits. Or, for a real-world example, the extensions language in asterisk. Syntactically a nightmare. But it follows the logic that all the PABX phone installers have been familar with since the 1970s, and makes advanced phone logic very easy to do. It is not an imperative language. It follows the state of a phone call. And it is a primitive language, with tons of simple lexical sugar thrown into it. A CS course would give you a D- for the language. We have even invented a word, swedish-english "Busugly" for it. But it give tremendous productivity gains. This language alone represents around 1/3rd of high-end linux server sales, according to IBM sales reps I talk to. The reason for the success is that non-programmers can actually program in a safe sandbox, just like in excel. You won't crash a system, you may just send sit tones to a phone line if you goof and your little program bails out. Which means that even non-programmers can play around. Then the core process control people can make the core pabx features work right, and obey the thousands of ITU, IETF and national standards in the field. Just because there is a language on top there is absolutly no application pressure on the core developers, just mild and polite requests to provide this and that extra core function, or an option to a function. 99.9% of applications are very simple business integration stuff, really. So, learn from excel, and provide the toolbox. We need more of these. Lots and lots more. But could we try to at least design a language qualifying for a B in a CS course, please? Please? -- mrr
From: Stefan Monnier on 16 Feb 2010 09:12
> I am talking about a class of languages that would be scorned in > any cs class. _Very_ application-spesific ones. Yes, these are called "DSL" (for Domain Specific Languages) and they're quite popular in the PL research community (the goal being to try and design languages and techniques that make it easier to define new DSLs). That covers a broad area, starting with Lisp macros on one end, and full specialized compilers at the other. See http://www.haskell.org/haskellwiki/Research_papers/Domain_specific_languages for some examples. Stefan |