A
Alex Martelli
Pascal Costanza wrote:
...
Ah, what a wonderfully meaningful view that is.
I didn't say SMALL. Small or large, it's about alteration to the
syntax. Other lispers have posted (on several of this unending
multitude of threads, many but not all of which I've killfiled)
stating outright that there is no semantic you can only implement
with macros: that macros are ONLY to "make things pretty" for
given semantics. If you disagree with them, I suggest pistols at
ten paces, but it's up to you lispers of course -- as long as
you guys with your huge collective experience of macros stop saying
a million completely contradictory things about them and chastising
me because (due, you all keep claiming, to my lack of experience)
I don't agree with all of them, I'll be glad to debate this again.
Till then, this is yet another thread that get killfiled.
Right: exactly what I _DON'T_ want to happen to my favourite language.
What's "considerably more complicated" in, say,
my_frobazzer = frobaz_compiler('''
oh my pretty, my beauteous,
my own all my own special unique frambunctious *LANGUAGE*!!!
''')
and later on call my_frobazzed(bim. bum, bam) at need? The complexity
of the frobaz_compiler factory callable depends exclusively on the
complexity of the language you want it to parse and compile, and you
of course have total choice ("Python doesn't give you a choice" MY
LEFT FOOT) on how to apportion the work between the factory and the
__call__ method of the resulting my_frobazzer.
You just have to respect Python's syntax and fundamental semantics
(e.g., strict order when your Python code calls a Python callable --
you can ALWAYS, TOTALLY count on this, NO surprises possible EVER),
and you still have a BAZILLION of choices, even AFTER making the
decision, which SHOULD be momentous rather than "a breeze" (!!!),
to CHOOSE to structure your whole application around your own unique
language or sub-language.
If Python makes it just as appealing to structure applications in
other ways, reserving "language design" for those occasions which
really call for it, so much the better. As I've repeatedly posted,
I've SUFFERED the consequences of computer scientists "breezily"
designing embedded Lisp subdialects for "domain-specific languages"
for domains they DIDN'T know 1/10th as well as the poor non-CS'ers
forced to suffer under that mishmash (hardware design the domain,
hardware design engineers the poor non-CS'ers) -- while at other
competing firms language design was treated with the respect it
deserves, producing not-embedded-in-anything, not-necessarily-
distorted-extended-subsets-of-anything hardware design languages
that let people actually DESIGN HARDWARE when that was their job.
The vast majority of applications has absolutely no need to tinker
with the language's syntax and fundamental semantics. When you need
a language with different syntax, this is best treated as a serious
task and devoted all the respect it deserves, NOT treated as "a
breeze". PARTICULARLY for domain-specific languages, the language's
designers NEED access to domain-specific competence, which typically
they won't have enough of for any domain that doesn't happen to be
what they've spent many years of their life actually DOING (just
STUDYING doesn't cut it); the people WITH the domain-specific
competence will in turn not typically be experienced programmers --
they've spent their lives getting experience in the specific domain
instead. Making things harder for "beginners" (which may well be
the domain-specific experts) is then the wrong choice: those
non-programmers fully deserve, if a domain-specific language is
indeed warranted by the task's complexity, a language that does NOT
just happens to embed bits and pieces of another, harder-for-
beginners language, just because it was "a breeze" to design it thus.
I'm talking about substantial applications meant to get into heavy
production use. For experimentation, play, research in computing
itself, whatever, go ahead, not my own interest. For application
programming, IF a domain-specific language is needed, I want it to
be designed FOR THE USERS' NEEDS AND CONVENIENCE (==productivity!),
NOT because it's easy to hack together with macros. And that IF is
a big one; more often than not, no weird new syntax and semantics
are warranted. If it's too easy to tweak syntax and semantics, they
will be tweaked whether that's warranted or not; such frequent and
lightly undertaken SYNTAX CHANGES are NOT what I want in the language
I will use, in collaboration with many others, to build applications.
Some resistance to change is useful. Without attrition, walking
would be VERY hard. Without a constitution that's FAR harder to
change than ordinary laws, and "balance of powers" so that the
legislature, the executive and the courts hamper each other, a
democracy might be dangerously unstable (the "Federalist Papers"
make that case particularly well). Without an unchanging core,
such as syntax and fundamental semantics, a language may be less
useful for application development by middling-large groups (the
language might be wonderful for play and free-spirited experiments
AND at the same time less wonderful for such usage).
So, you KNOW "doesn't give you a choice" is ridiculous.
You are (by far) exaggerating the effort. Check out such tools as
spark or SimpleParse and you'll see that parsing a custom language,
e.g. into an AST, is reasonably trivial. Once you have your AST,
you're basically in the same position as you start out with
S-exprs, so compiling and/or interpreting them is the same work.
What you don't do this way is MERGING LANGUAGE AND META-LANGUAGE --
sprinkling bits and pieces of your own custom language in the middle
of your implementation language and vice versa -- not "casually": if
and when you decide to embed languages into each other you must
deliberately take all decisions about arranging that.
As a consequence, the language you design is NOT influenced by the
language you choose to use for the implementation thereof -- no
special push to make the supposedly application-domain-specific
language conform to uses and conventions typical of the implementation
language, no fragments of the implementation language suddenly perking
up in the middle of the application-domain-specific language.
So, for example, the BLM Language being developed at AB Strakt
(www.strakt.com) is INDEPENDENT from Python (though the designers
have of course been influenced by the parts of Python's syntax
they most liked, e.g., significant indentation); in the first
implementation, the embedded language for expressions and actions
is also Python, but the syntax already provides for embedding
multiple procedural/imperative languages even inside a single
BLM module. The interface between the declarative parts and the
embedded imperative ones is defined in terms of functions and
objects, so that, if and when the application-domain-specific
experts demand it (and pay for it
other languages may just as
well be adapter (sufficiently non-dynamic ones will necessarily
end up with lots of boilerplate code such as
attrib := blm.services->get_attribute(current_name);
and the like, but then, users of non-dynamic languages do appear
to like such boilerplate.
Sure, it could perfectly have been done in lisp (or any other
sufficiently high-level language just as well), but one would
have had to resist the temptation to orient the language being
designed towards "ease of implementation with lisp macros and
ease of integration with snippets of lisp", making it a
totally separate language -- and I've seen, and suffered on
my own skin, what typical CS'ers do about resisting such
temptation, particularly when convinced (as most, though not
all, of you guys seem to be) that lisp is obviously the best
language for ANY task, so why EVER could one POSSIBLY want a
totally different one for [insert any application domain]...?!
[Well, I've seen what they did about it 20+ years ago -- no
doubt human nature HAS changed drastically since, I'm sure].
But will the simple way be the RIGHT one? Or will you end up
designing application-domain-specific languages needlessly, in
applications that would be much better structured in other ways,
AND when an application-domain-specific language IS called for,
end up "along the continuum" designing it ``by inertia'' as just
some "extended subset" of lisp, instead...?
I have HAD to use (several mutually incompatible varieties of)
"application-domain-specific languages" built by lispers with
their beloved macros (in the early '80s, so it wasn't common
lisp yet, but rather a congeries of different lisp dialects,
including scheme). I know how macros work: they get hacked by
computer scientists that don't really grok the application domain,
then the resulting "extended subset of lisp" du jour is foisted
on people who DO know the application domain, CLAIMING falsely
to be appropriate for the specific application domain -- why,
they're (some kind of) lisp, OF COURSE they're automatically ideal
for ANY application right? And I'm not sure what the "unrelated"
syntax or portions of sources were, if any -- we had to describe
system-level, interface-level, circuit-level &c views of a chip
being developed in one or more of those (expl.del) "application
awful languages" and NO of _course_ you can't use COND here
because [gibbledygook] -- that's in AAL 1 as designed in Lab 1,
while in AAL 2 designed in Lab 2 OBVIOUSLY you must use COND here,
I thought you were HIRED because you had used lisp (I had, scheme
actually, but that was the favoured lisp of lab _3_ so mentioning
it in labs 1 or 2 made you an instant leper obviously).
No doubt "the solution" you proposed would have been to learn a
few of those GD macro systems and write the N-plus-1-th divergent
incompatible subdialect. Yeah right. I found a better one --
jump ship to IBM Research, get a raise, get to use a GOOD (for
the times, mind you -- still over 20 years ago) hardware design
language, have the fun of my life designing HW for a while until
I had to go back to SW -- and reconciling myself to the latter when
I found out it didn't HAVE to mean endlessly designing languages
for domains you didn't truly grasp with congeries of pieces of an
existing language and half-baked concoctions of your own -- you
COULD actually design good systems and algorithms, just like you
could with hardware, using SOLID, UNCHANGING (inside a project's
timeframe, _almost_-decently-designed-for-the-general-domain
languages [PLURAL!!!! *YES*!!!]. Admittedly, "almost". I tried
my hand at designing specialized languages (one of those sins
that just about everybody practices in youth, I guess) and found
out that, even when I grasped the application domain perfectly
well, that still didn't make my languages usable by other experts
of the domain (maybe because I kept falling onto prefix s-exproid
syntax in those years -- and just about everybody else hated it).
Been there, done that, *NEVER, NEVER AGAIN*. Don't keep repeating
this claim, analogous to one that somebody who's lived and suffered
under a dictatorship shouldn't be spreading misconceptions but try
being a dictator to "know the things better that you criticize". I
don't want to foist my half-baked macro-based lisp dialects on
others any more than I'm going to suffer others foisting their own
on me, thankyouverymuch. If and when I should find myself working
on a solo project for which the need to tweak syntax within an
s-expr world appears, I may try some kind of lisp (hopefully, by
then, Graham's new baby -- if he's as good as the reverence every
lisper devotes him seems to indicate, then his claim that he can
make a lisp that's better than both scheme and CL while having the
strenths of both -- and then some -- should be credible).
But, until then -- bye. And now, to killfile this thread too....
Alex
...
Ah, what a wonderfully meaningful view that is.
I didn't say SMALL. Small or large, it's about alteration to the
syntax. Other lispers have posted (on several of this unending
multitude of threads, many but not all of which I've killfiled)
stating outright that there is no semantic you can only implement
with macros: that macros are ONLY to "make things pretty" for
given semantics. If you disagree with them, I suggest pistols at
ten paces, but it's up to you lispers of course -- as long as
you guys with your huge collective experience of macros stop saying
a million completely contradictory things about them and chastising
me because (due, you all keep claiming, to my lack of experience)
I don't agree with all of them, I'll be glad to debate this again.
Till then, this is yet another thread that get killfiled.
Right: exactly what I _DON'T_ want to happen to my favourite language.
What's "considerably more complicated" in, say,
my_frobazzer = frobaz_compiler('''
oh my pretty, my beauteous,
my own all my own special unique frambunctious *LANGUAGE*!!!
''')
and later on call my_frobazzed(bim. bum, bam) at need? The complexity
of the frobaz_compiler factory callable depends exclusively on the
complexity of the language you want it to parse and compile, and you
of course have total choice ("Python doesn't give you a choice" MY
LEFT FOOT) on how to apportion the work between the factory and the
__call__ method of the resulting my_frobazzer.
You just have to respect Python's syntax and fundamental semantics
(e.g., strict order when your Python code calls a Python callable --
you can ALWAYS, TOTALLY count on this, NO surprises possible EVER),
and you still have a BAZILLION of choices, even AFTER making the
decision, which SHOULD be momentous rather than "a breeze" (!!!),
to CHOOSE to structure your whole application around your own unique
language or sub-language.
If Python makes it just as appealing to structure applications in
other ways, reserving "language design" for those occasions which
really call for it, so much the better. As I've repeatedly posted,
I've SUFFERED the consequences of computer scientists "breezily"
designing embedded Lisp subdialects for "domain-specific languages"
for domains they DIDN'T know 1/10th as well as the poor non-CS'ers
forced to suffer under that mishmash (hardware design the domain,
hardware design engineers the poor non-CS'ers) -- while at other
competing firms language design was treated with the respect it
deserves, producing not-embedded-in-anything, not-necessarily-
distorted-extended-subsets-of-anything hardware design languages
that let people actually DESIGN HARDWARE when that was their job.
The vast majority of applications has absolutely no need to tinker
with the language's syntax and fundamental semantics. When you need
a language with different syntax, this is best treated as a serious
task and devoted all the respect it deserves, NOT treated as "a
breeze". PARTICULARLY for domain-specific languages, the language's
designers NEED access to domain-specific competence, which typically
they won't have enough of for any domain that doesn't happen to be
what they've spent many years of their life actually DOING (just
STUDYING doesn't cut it); the people WITH the domain-specific
competence will in turn not typically be experienced programmers --
they've spent their lives getting experience in the specific domain
instead. Making things harder for "beginners" (which may well be
the domain-specific experts) is then the wrong choice: those
non-programmers fully deserve, if a domain-specific language is
indeed warranted by the task's complexity, a language that does NOT
just happens to embed bits and pieces of another, harder-for-
beginners language, just because it was "a breeze" to design it thus.
I'm talking about substantial applications meant to get into heavy
production use. For experimentation, play, research in computing
itself, whatever, go ahead, not my own interest. For application
programming, IF a domain-specific language is needed, I want it to
be designed FOR THE USERS' NEEDS AND CONVENIENCE (==productivity!),
NOT because it's easy to hack together with macros. And that IF is
a big one; more often than not, no weird new syntax and semantics
are warranted. If it's too easy to tweak syntax and semantics, they
will be tweaked whether that's warranted or not; such frequent and
lightly undertaken SYNTAX CHANGES are NOT what I want in the language
I will use, in collaboration with many others, to build applications.
Some resistance to change is useful. Without attrition, walking
would be VERY hard. Without a constitution that's FAR harder to
change than ordinary laws, and "balance of powers" so that the
legislature, the executive and the courts hamper each other, a
democracy might be dangerously unstable (the "Federalist Papers"
make that case particularly well). Without an unchanging core,
such as syntax and fundamental semantics, a language may be less
useful for application development by middling-large groups (the
language might be wonderful for play and free-spirited experiments
AND at the same time less wonderful for such usage).
So, you KNOW "doesn't give you a choice" is ridiculous.
You are (by far) exaggerating the effort. Check out such tools as
spark or SimpleParse and you'll see that parsing a custom language,
e.g. into an AST, is reasonably trivial. Once you have your AST,
you're basically in the same position as you start out with
S-exprs, so compiling and/or interpreting them is the same work.
What you don't do this way is MERGING LANGUAGE AND META-LANGUAGE --
sprinkling bits and pieces of your own custom language in the middle
of your implementation language and vice versa -- not "casually": if
and when you decide to embed languages into each other you must
deliberately take all decisions about arranging that.
As a consequence, the language you design is NOT influenced by the
language
special push to make the supposedly application-domain-specific
language conform to uses and conventions typical of the implementation
language, no fragments of the implementation language suddenly perking
up in the middle of the application-domain-specific language.
So, for example, the BLM Language being developed at AB Strakt
(www.strakt.com) is INDEPENDENT from Python (though the designers
have of course been influenced by the parts of Python's syntax
they most liked, e.g., significant indentation); in the first
implementation, the embedded language for expressions and actions
is also Python, but the syntax already provides for embedding
multiple procedural/imperative languages even inside a single
BLM module. The interface between the declarative parts and the
embedded imperative ones is defined in terms of functions and
objects, so that, if and when the application-domain-specific
experts demand it (and pay for it
other languages may just aswell be adapter (sufficiently non-dynamic ones will necessarily
end up with lots of boilerplate code such as
attrib := blm.services->get_attribute(current_name);
and the like, but then, users of non-dynamic languages do appear
to like such boilerplate
.Sure, it could perfectly have been done in lisp (or any other
sufficiently high-level language just as well), but one would
have had to resist the temptation to orient the language being
designed towards "ease of implementation with lisp macros and
ease of integration with snippets of lisp", making it a
totally separate language -- and I've seen, and suffered on
my own skin, what typical CS'ers do about resisting such
temptation, particularly when convinced (as most, though not
all, of you guys seem to be) that lisp is obviously the best
language for ANY task, so why EVER could one POSSIBLY want a
totally different one for [insert any application domain]...?!
[Well, I've seen what they did about it 20+ years ago -- no
doubt human nature HAS changed drastically since, I'm sure].
But will the simple way be the RIGHT one? Or will you end up
designing application-domain-specific languages needlessly, in
applications that would be much better structured in other ways,
AND when an application-domain-specific language IS called for,
end up "along the continuum" designing it ``by inertia'' as just
some "extended subset" of lisp, instead...?
I have HAD to use (several mutually incompatible varieties of)
"application-domain-specific languages" built by lispers with
their beloved macros (in the early '80s, so it wasn't common
lisp yet, but rather a congeries of different lisp dialects,
including scheme). I know how macros work: they get hacked by
computer scientists that don't really grok the application domain,
then the resulting "extended subset of lisp" du jour is foisted
on people who DO know the application domain, CLAIMING falsely
to be appropriate for the specific application domain -- why,
they're (some kind of) lisp, OF COURSE they're automatically ideal
for ANY application right? And I'm not sure what the "unrelated"
syntax or portions of sources were, if any -- we had to describe
system-level, interface-level, circuit-level &c views of a chip
being developed in one or more of those (expl.del) "application
awful languages" and NO of _course_ you can't use COND here
because [gibbledygook] -- that's in AAL 1 as designed in Lab 1,
while in AAL 2 designed in Lab 2 OBVIOUSLY you must use COND here,
I thought you were HIRED because you had used lisp (I had, scheme
actually, but that was the favoured lisp of lab _3_ so mentioning
it in labs 1 or 2 made you an instant leper obviously).
No doubt "the solution" you proposed would have been to learn a
few of those GD macro systems and write the N-plus-1-th divergent
incompatible subdialect. Yeah right. I found a better one --
jump ship to IBM Research, get a raise, get to use a GOOD (for
the times, mind you -- still over 20 years ago) hardware design
language, have the fun of my life designing HW for a while until
I had to go back to SW -- and reconciling myself to the latter when
I found out it didn't HAVE to mean endlessly designing languages
for domains you didn't truly grasp with congeries of pieces of an
existing language and half-baked concoctions of your own -- you
COULD actually design good systems and algorithms, just like you
could with hardware, using SOLID, UNCHANGING (inside a project's
timeframe
, _almost_-decently-designed-for-the-general-domainlanguages [PLURAL!!!! *YES*!!!]. Admittedly, "almost". I tried
my hand at designing specialized languages (one of those sins
that just about everybody practices in youth, I guess) and found
out that, even when I grasped the application domain perfectly
well, that still didn't make my languages usable by other experts
of the domain (maybe because I kept falling onto prefix s-exproid
syntax in those years -- and just about everybody else hated it).
Been there, done that, *NEVER, NEVER AGAIN*. Don't keep repeating
this claim, analogous to one that somebody who's lived and suffered
under a dictatorship shouldn't be spreading misconceptions but try
being a dictator to "know the things better that you criticize". I
don't want to foist my half-baked macro-based lisp dialects on
others any more than I'm going to suffer others foisting their own
on me, thankyouverymuch. If and when I should find myself working
on a solo project for which the need to tweak syntax within an
s-expr world appears, I may try some kind of lisp (hopefully, by
then, Graham's new baby -- if he's as good as the reverence every
lisper devotes him seems to indicate, then his claim that he can
make a lisp that's better than both scheme and CL while having the
strenths of both -- and then some -- should be credible).
But, until then -- bye. And now, to killfile this thread too....
Alex