From: Robert Myers on
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
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
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
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
> 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