From: ····@festival.ed.ac.uk (J W Dalton)
Nonetheless, languages are not ordinarily trademarked. The
use of trademark indicates a desire for a kind of control that
is at least unusual.
Yes, *quality* control. If it works as planned, this will lead to a
standardized Dylan definition without going through the infinite quagmire
of a formal standardization process. To me, that's a very attractive
prospect. After spending many years exploring the other alternative
(language design through anarchy), I'm glad that *someone* is in control of
Dylan.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Senior Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:33 N
5000 Forbes Avenue Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================
···@sef-pmax.slisp.cs.cmu.edu writes:
> From: ····@festival.ed.ac.uk (J W Dalton)
>
> Nonetheless, languages are not ordinarily trademarked. The
> use of trademark indicates a desire for a kind of control that
> is at least unusual.
>
>Yes, *quality* control. If it works as planned, this will lead to a
>standardized Dylan definition without going through the infinite quagmire
>of a formal standardization process. To me, that's a very attractive
>prospect. After spending many years exploring the other alternative
>(language design through anarchy), I'm glad that *someone* is in control of
>Dylan.
I don't mind quality control, so long as the requirements are fair,
but this form of control doesn't seem to be needed for other
languages. For instance, market mechanisms are often fairly good
at distinguishing good implementations from bad ones and they allow
customers to use their own notion of "good".
Of course, you may think that other languages need more quality
control, but in any case this is a separate question from that of
formal standardization.
Formal standards may be slow and a big pain in the neck; but
it isn't necessary to tie developments to a formal standard,
as the Revised^n Scheme Reports show, nor do formal standards
provide explicit quality control.
Now, if Apple confines itself to quality control, that may be ok,
as I said; but that's not all they can do with a trademark; and if
you need a license from Apple to use the name, what's to stop Apple
from charging for the license after Dylan becomes a success?
I prefer for languages not to be controlled in this way.
-- jd
In article <············@cs.cmu.edu>, ···@sef-pmax.slisp.cs.cmu.edu writes:
|> From: ····@festival.ed.ac.uk (J W Dalton)
|>
|> Nonetheless, languages are not ordinarily trademarked. The
|> use of trademark indicates a desire for a kind of control that
|> is at least unusual.
|>
|> Yes, *quality* control. If it works as planned, this will lead to a
|> standardized Dylan definition without going through the infinite quagmire
|> of a formal standardization process. To me, that's a very attractive
|> prospect. After spending many years exploring the other alternative
|> (language design through anarchy), I'm glad that *someone* is in control of
|> Dylan.
|>
|> -- Scott
I can greatly appreciate your desire to avoid the anarchy of formal
standardization. I am a bit nervious about Dylan though. It seems a bit too
closed for my tastes, not that my tastes matter much. It seems that only Apple
and your group at CMU has any idea of what's going on with the language. From my
experience, I don't think it's going to matter anyway. The use of any dynamic
language won't be accepted by the programming communitee as a whole. They'll
claim that a dynamic language is just too inefficient to be used for real
problems. It won't matter how much evidence you can produce to disprove their
claim, they just won't believe you. After all, people still make the claim that
you can't write efficient numerical code in lisp. That was shown to be false 30
years ago but "everyone" still believes it.
Mike McDonald Advanced Technology Dept.
Harris Corp.
Email: ···@trantor.harris-atd.com M.S. 16-1912
Voice: (407) 727-5060 P.O. Box 37
Fax: (407) 729-3363 Melbourne, Florida 32902
From: Mark Kantrowitz
Subject: Re: Efficient Numerical Code in CommonLisp -- Re: Dylan/Eulisp
Date:
Message-ID: <CC0uB7.GJ7.1@cs.cmu.edu>
In article <············@life.ai.mit.edu> ···@idiap.ch writes:
>For several implementations, there are tricks you can play to get good
>numerical performance out of them. But those tricks differ from
>implementation to implementation. Furthermore, in order to find out
>where the performance problems are coming from, you often have to look
>at the assembly language output of the compiler.
The tricks don't vary all that much. And if you write the right kind
of declarations, you don't have to specialize them to the
implementation. The only trick I've encountered is having to know that
Allegro doesn't trust declarations about globals, ignores inline
declarations, and doesn't (yet) do block compilation.
In any event, I have a speech synthesis application that runs faster
in optimized CMU CL and Lucid than in optimized C. (I wrote the Lisp
version based on the C version, and didn't make many significant
changes aside from declarations.) One of these days I'll post the numbers.
--mark
From: Thomas M. Breuel
Subject: Re: Efficient Numerical Code in CommonLisp -- Re: Dylan/Eulisp
Date:
Message-ID: <TMB.93Aug20012633@arolla.idiap.ch>
In article <············@cs.cmu.edu> ······@cs.cmu.edu (Mark Kantrowitz) writes:
|In article <············@life.ai.mit.edu> ···@idiap.ch writes:
|>For several implementations, there are tricks you can play to get good
|>numerical performance out of them. But those tricks differ from
|>implementation to implementation. Furthermore, in order to find out
|>where the performance problems are coming from, you often have to look
|>at the assembly language output of the compiler.
|
|The tricks don't vary all that much. And if you write the right kind
|of declarations, you don't have to specialize them to the
|implementation. The only trick I've encountered is having to know that
|Allegro doesn't trust declarations about globals, ignores inline
|declarations, and doesn't (yet) do block compilation.
No, the tricks don't vary all that much--for most of the code. But
those "little" things like "Allegro doesn't do inline" or "CMU CL
doesn't do FLOOR without consing", or "AKCL doesn't like
SIMPLE-ARRAY", or "FOOCL has problems figuring out
(MULTIPLE-VALUE-BIND (X Y) (VALUES 3 4) ...)" can be irritating.
They are responsible for the occasional recalcitrant piece of code
that just refuses to stop consing or boxing for no good reason. In an
older version of Lucid, it took me a while to figure out that two
THE's are slower than one THE (they have now fixed it...). In CMU CL,
I had some pretty straightforward code for the Euclidean distance
transform that just would not optimize; eventually, I rewrote it
completely from scratch and it worked like a charm.
|In any event, I have a speech synthesis application that runs faster
|in optimized CMU CL and Lucid than in optimized C. (I wrote the Lisp
|version based on the C version, and didn't make many significant
|changes aside from declarations.) One of these days I'll post the numbers.
I have lots of image processing code in CL that runs at around C
speed--sometimes a little slower, sometimes a little faster. But
getting to that point is not always straightforward, and moving that
code to new implementations is likely going to be a little bit of
an adventure.
Maybe you and I are willing to put up with such hiccups, but I can
well understand why many people are sufficiently put off by them to
say "CL is not suitable for numerical applications" and go back
to FORTRAN or C++.
Thomas.
From: Mike McDonald
Subject: Re: Efficient Numerical Code in CommonLisp -- Re: Dylan/Eulisp
Date:
Message-ID: <CC2IoL.1x6@jabba.ess.harris.com>
In article <·················@arolla.idiap.ch>, ···@arolla.idiap.ch (Thomas M. Breuel) writes:
|> Maybe you and I are willing to put up with such hiccups, but I can
|> well understand why many people are sufficiently put off by them to
|> say "CL is not suitable for numerical applications" and go back
|> to FORTRAN or C++.
|>
|> Thomas.
Yep and 99.99% of those Fortran and C people are just assuming that their
compilers are producing effecient numerical code.
Mike McDonald Advanced Technology Dept.
Harris Corp.
Email: ···@trantor.harris-atd.com M.S. 16-1912
Voice: (407) 727-5060 P.O. Box 37
Fax: (407) 729-3363 Melbourne, Florida 32902
In article <··········@jabba.ess.harris.com>, ···@mercury.Harris-ATD.com (Mike McDonald) writes:
|> After all, people still make the claim that
|> you can't write efficient numerical code in lisp. That was shown to be false 30
|> years ago but "everyone" still believes it.
For several implementations, there are tricks you can play to get good
numerical performance out of them. But those tricks differ from
implementation to implementation. Furthermore, in order to find out
where the performance problems are coming from, you often have to look
at the assembly language output of the compiler.
The reasons for this are many, including that there aren't enough
users demanding efficient numerical performance from their Lisp
environments, that not enough vendors bother implementing the
necessary features, that some useful declarations have not been
standardized, and, also, that the semantics (and size) of the
CommonLisp language make it quite difficult for implementors to do a
good job at providing high performance numerical implementations.
So, you can write "efficient numerical code in lisp" (I do it all the
time), but it can be a a bit of effort and guesswork.
Now, I believe that these problems are fixable, and that Lisp
implementations that generate efficient numerical code from a minimum
of declarations (the same across platforms!) are possible and could,
in principle, become widespread. However, vendors will only invest
lots of effort into doing a good job on numerical type inference and
generating efficient numerical code if they see more user demand, and
user demand will only pick up if there is a general belief that
numerical programming in Lisp is possible without a lot of effort.
My hope is that sooner or later, one of the Lisp standards (Eulisp?
Dylan? CommonLisp the next generation?) will break this vicious cycle
by standardizing some simple, down to earth features that may not be
pretty, but that give users a clear direction for how to write code
that is efficient across platforms, and that gives implementors clear
and simple directions of how to provide efficient numerical
facilities.
Thomas.
In article <··········@jabba.ess.harris.com>, ···@mercury.Harris-ATD.com
(Mike McDonald) wrote:
>
> I can greatly appreciate your desire to avoid the anarchy of formal
> standardization. I am a bit nervious about Dylan though. It seems a bit too
> closed for my tastes, not that my tastes matter much. It seems that only Apple
> and your group at CMU has any idea of what's going on with the language.
We are working relative
In article <············@cs.cmu.edu> ···@sef-pmax.slisp.cs.cmu.edu writes:
> Newsgroups: comp.lang.lisp
> Path: ads.com!decwrl!decwrl!uunet!magnesium.club.cc.cmu.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!crabapple.srv.cs.cmu.edu!news
> From: ···@sef-pmax.slisp.cs.cmu.edu
> Sender: ····@cs.cmu.edu (Usenet News System)
> Nntp-Posting-Host: sef-pmax.slisp.cs.cmu.edu
> Organization: School of Computer Science, Carnegie Mellon
> Date: Tue, 17 Aug 1993 23:34:35 GMT
> Lines: 24
>
> From: ····@festival.ed.ac.uk (J W Dalton)
>
> Nonetheless, languages are not ordinarily trademarked. The
> use of trademark indicates a desire for a kind of control that
> is at least unusual.
>
> Yes, *quality* control. If it works as planned, this will lead to a
> standardized Dylan definition without going through the infinite quagmire
> of a formal standardization process. To me, that's a very attractive
> prospect. After spending many years exploring the other alternative
> (language design through anarchy), I'm glad that *someone* is in control of
> Dylan.
Talking about trademarks and control what is the official pronunciation of
"Dylan"? Is it as in "DYnamic LANguage" or as in "Bob".
--
Bill Vrotney
BAH/Advanced Decision Systems