Micro$oft has found that C++ is too hard for their average customers and VB
is for dummies so they made a simplified C++ (� la Java, but without Sun...)
with a GC, direct mapping between objects and XML etc...
I quote : "More than anything else, C# is designed to bring rapid
development to the C++ programmer"
Now we will see Java/C#/lisp threads instead of Java/lisp ones... sigh.
you can see the Intro here:
http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
Marc Battyani
In article
<··················································@lp.airnews.net>,
"Marc Battyani" <·············@csi.com> wrote:
> Micro$oft has found that C++ is too hard for their average customers
and VB
> is for dummies so they made a simplified C++ (� la Java, but without
Sun...)
> with a GC, direct mapping between objects and XML etc...
[...]
> you can see the Intro here:
> http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
This is incredible! They've just reinvented Javascript! (What's next,
the wheel, perhaps?)
--
Glauber Ribeiro
··········@my-deja.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
The Glauber <··········@my-deja.com> writes:
> In article
> <··················································@lp.airnews.net>,
> "Marc Battyani" <·············@csi.com> wrote:
> > Micro$oft has found that C++ is too hard for their average customers
> and VB
> > is for dummies so they made a simplified C++ (� la Java, but without
> Sun...)
> > with a GC, direct mapping between objects and XML etc...
> [...]
> > you can see the Intro here:
> > http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
>
>
> This is incredible! They've just reinvented Javascript! (What's next,
> the wheel, perhaps?)
>
You are sooo wrong. They have "embraced and extended" Java, C++,
JavaScript and Intercal.
Cheers
--
Marco Antoniotti ===========================================
Marco Antoniotti <·······@parades.rm.cnr.it> writes:
> The Glauber <··········@my-deja.com> writes:
>
> > In article
> > <··················································@lp.airnews.net>,
> > "Marc Battyani" <·············@csi.com> wrote:
> > > Micro$oft has found that C++ is too hard for their average customers
> > and VB
> > > is for dummies so they made a simplified C++ (� la Java, but without
> > Sun...)
> > > with a GC, direct mapping between objects and XML etc...
> > [...]
> > > you can see the Intro here:
> > > http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
> >
> >
> > This is incredible! They've just reinvented Javascript! (What's next,
> > the wheel, perhaps?)
> >
>
> You are sooo wrong. They have "embraced and extended" Java, C++,
> JavaScript and Intercal.
while it may be true that this language is more than Javascript, it's
certainly is _not_ about "embracing" anything (though "choking" or
"suffocating" do kinda come to mind). As I said in my other post,
this language is a step forward, but I was really talking about GC;
otherwise, it's incredibly stupid for _anyone_ to use it in the long
term. I certainly hope not to see people using this language. If I
have to go to a site and work with this garbage, or turn down an
opportunity because I don't understand C#, and don't want to, then
(yet again) Microsoft will have landed another one on me. I hope this
thing flops just like Visual J++ flopped. If you think about it, what
they're doing is a very similar ploy: they're likening this language
to (V)C++, trying to cajole programmers into thinking that it's just
some kind of extended, modified, and better-in-some-way langauge than
C++. While I've had some satisfaction with several MS products
(e.g. NT, SQL Server, Word), I believe that they often do act with a
degree of dimentia. I wonder how unlimited their developer pool is
sometimes. I mean, between their office suite, Exchange Server, a
bunch of OSs (including this .NET thing), when does it end? And, as
the language of .NET, C# (to me) just means that the .NET thing is
likely to be a huge failure. I read the PR hype from
http://www.microsoft.com/presspass/topics/f2k/whitepaper/default.asp
and I'm having trouble buying it. C# doesn't help me think that this
.NET thing will be the "revolution" in computing that they're
claiming.
Marco. Embraced? What are you talking about?
dave
In article <··············@cadet.dsl.speakeasy.net>,
David Bakhash <·····@alum.mit.edu> wrote:
[...]
> bunch of OSs (including this .NET thing), when does it end? And, as
> the language of .NET, C# (to me) just means that the .NET thing is
> likely to be a huge failure. I read the PR hype from
[...]
Yes, having invented Javascript, it's just natural that they now
invented the Internet, to go with it. I think Al Gore should sue these
people!
(This has nothing to do with Lisp, whatsoever!)
--
Glauber Ribeiro
··········@my-deja.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
David Bakhash <·····@alum.mit.edu> wrote in message
···················@cadet.dsl.speakeasy.net...
> I certainly hope not to see people using this language.
You don't know the "convicing" power of M$. They will start to put
functionnalities only usable by C# and VB in their OS. They have done the
same thing for COM. All the Shell functionnalities have COM interfaces only.
So even if you don't like COM (a poor design at least...) you have to use
it. They are currently doing the same thing with COM+.
I hope the OS will be separated from M$ soon!
This has an impact on the other languages like Lisp. When the OS API were C
functions a simple FFI was enough. As C was a low level language is was
rather easy. But now you can't even use those functionnalities in C. So it
will be harder in Lisp too.
Marc Battyani
"Marc Battyani" <·············@fractalconcept.com> writes:
> This has an impact on the other languages like Lisp. When the OS API were C
> functions a simple FFI was enough. As C was a low level language is was
> rather easy. But now you can't even use those functionnalities in C. So it
> will be harder in Lisp too.
I think it'll be harder for the implementors, but for application
developers, it'll probably still be just as easy. I believe that the
FFI will hold under such circumstances. Just consider that foreign
functions even now work similarly for foreign Fortran, C, C++, etc. But
the real moral of the story (for me) will be to simply abandon Microsoft
as a platform for developing applications. I guess over these past few
years I got wedded to Windows and developing on it. Between Cygwin,
Xwin32, WinCVS, ntemacs, SecureCRT, MS Word, Dragon, and other stuff, I
just started to prefer it as my _personal_ OS in many ways. But on
Linux, I can pay the same for Common Lisp, and life is much easier:
there's no VC++, no COM, no very stupid stuff. And for GUI stuff, I've
heard that there are now Lisp bindings for GTK, and maybe even KDE,
though I don't know what kinds of licenses these have, and how they
would affect writing commercial applications. But what I do know is
that Windows, more and more, is started to get out of control. While I
may not like the MFC, it seemed to do wonders for the commercial
software market, and many applications were very usable. Who hasn't
noticed the uniformity among windows apps that Unix lacked for a long
time? (KDE mostly does the right thing, of course). Apparently, not
everything that MS created was bad. VC++ developers seemed to get
things done. And, many applications under windows that require getting
into the guts of the OS were made to work (namely, vmware, Xwin32,
Exceed, and a bunch of others that don't come to mind right now).
And so one of these MS buzzwords (COM, DNA, DCOM, OLE,...) makes it
possible, and maybe even feasible to do stuff such as copy a table from
a spreadsheet application and just past it into Word, or link it in, or
whatever, and in a way that makes subsequent applications able to do so
with the same objects. So, they get a pat on the back, at least from
me. But it only goes so far. I will avoid C# and it's .NET mother as
best I can, just as I will avoid using particular commercial Common Lisp
implementations as long as unfair licensing practices prevail.
Basically, these software guys are like little children, abusing the
system, suing each other like little tattle-tales, hoarding their
technology, trying so hard to be unfair monopolies, and not to mention
their ridiculous licensing agreements. and so whenever Bill starts
crying just because the gov't notices that his corporation has not been
acting in accordance with the rules that monopolies must abide by, I
think, get this tyrannous child out of here. You take the real big
boys, like GM, or GE. They understand where they are, and how to play
fairly for the most part. You take MS, and what I consider to be
companies that behave similarly in the space that affects me more
directly, and you just wonder. They just don't get it.
dave
From: Reini Urban
Subject: Re: C# : The new language from M$
Date:
Message-ID: <395b4f8c.271060664@news>
Marc Battyani wrote:
>This has an impact on the other languages like Lisp. When the OS API were C
>functions a simple FFI was enough. As C was a low level language is was
>rather easy. But now you can't even use those functionnalities in C. So it
>will be harder in Lisp too.
Well, you are able to use COM interfaces without any COM via a plain
FFI. But admitted, it is a mess and next to impossible to use with
callbacks. See for example the Corman Lisp sources or the Inside OLE
book for the C way.
With simple call outs it's a double indirection, but I shrudded when
thinking of implementing COM call-ins (aka "Events") via a plain FFI.
Hope that I don't have to do that somewhen.
Thanksfully there are only a few MS COM-only API's, most provide a
double-interface (early and late binding) where you can call-out to the
C/C++ functions directly without the double-indirection, or safearray
and BSTR conversion. With C++ you only have to find the demangled names.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
The Glauber wrote:
> This is incredible! They've just reinvented Javascript! (What's next,
> the wheel, perhaps?)
You mean, the Innovation does not require static type declarations? Do
you have a URL that says this?
Robert
Robert Monfera <·······@fisec.com> writes:
> The Glauber wrote:
>
> > This is incredible! They've just reinvented Javascript! (What's next,
> > the wheel, perhaps?)
>
> You mean, the Innovation does not require static type declarations? Do
> you have a URL that says this?
you can read it yourself at:
http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
they use the term "type-safe". I don't know for sure what they're
talking about. If you want to find out more about the language, there's
a download, but for god's sake it's an .EXE file! Should one have to
run an executable to learn more about a language? Also, when I read
about it, I was on a Linux box, and _couldn't_ run that EXE if I'd
wanted to. So, if it's the same for you, you'll have to go based on
what's in that URL, and on other press releases.
dave
David Bakhash <·····@alum.mit.edu> writes:
| Also, when I read about it, I was on a Linux box, and _couldn't_
| run that EXE if I'd wanted to. So, if it's the same for you,
You don't need to run it. Just install unzip and then extract the
.doc with `unzip clanref.exe' (it's a self-extracting zip
archive).
--
Hannu
* David Bakhash <·····@alum.mit.edu>
| If you want to find out more about the language, there's a
| download, but for god's sake it's an .EXE file!
It's one of those nifty self-extracting archive things for Windows
victims deprived of understanding this "high" techology.
Fortunately, you can apply unzip to it and not have to execute the
file. Doing so yields a .DOC file which is a lot more useful than
an .EXE file, fer sure! You now need _more_ Microsoft shitware to
read the goddamn _text_. I used the demented StarOffice suite, and
tried to print this "document" to paper, the only medium it should
have been in in the first place, which failed miserably, of course.
The PostScript file looks reasonable, and ghostview can display it,
but no PostScript printer _anywhere_ will print it for me. Sigh.
But C# looks like what comes out of a brilliant mind at gun-point.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.no> writes:
> Fortunately, you can apply unzip to it and not have to execute the
> file. Doing so yields a .DOC file which is a lot more useful than
> an .EXE file, fer sure! You now need _more_ Microsoft shitware to
> read the goddamn _text_. I used the demented StarOffice suite, and
I used "strings", and although I missed some diagrams and punctuation,
it was enough to get the general idea of the language. It's got a few
things Java doesn't have, and it's missing a few things Java does
have, but on the whole, it's just a Java knockoff. Nothing special
here, folks; move along...
--
vsync
http://quadium.net/ - last updated Fri Jun 23 23:28:05 MDT 2000
Orjner.
Centuries ago, Nostradamus foresaw a time when vsync would say:
>Erik Naggum <····@naggum.no> writes:
>
>> Fortunately, you can apply unzip to it and not have to execute the
>> file. Doing so yields a .DOC file which is a lot more useful than
>> an .EXE file, fer sure! You now need _more_ Microsoft shitware to
>> read the goddamn _text_. I used the demented StarOffice suite, and
>
>I used "strings", and although I missed some diagrams and punctuation,
>it was enough to get the general idea of the language. It's got a few
>things Java doesn't have, and it's missing a few things Java does
>have, but on the whole, it's just a Java knockoff. Nothing special
>here, folks; move along...
[Aside...] Microsoft DOC files commonly include all the revisions, as
opposed to merely containing the most recent set of contents.
As a result, if you use "strings" to extract the "stuff that looks
like text," you can often find more material in the document than the
writer may have intended that you be able to see.
It is apparently (emphasis "most") entertaining if you receive an
offer letter from a would-be employer in Word DOC form. If they
issued more than one offer, you might be able to extract information
about (emphasis "other") offers from the document, which will
doubtless prove valuable in the "negotiations" phase...
--
········@acm.org - <http://www.ntlug.org/~cbbrowne/linux.html>
A year spent in artificial intelligence is enough to make one believe
in God. -- Alan Perlis
········@news.hex.net (Christopher Browne) writes:
> [Aside...] Microsoft DOC files commonly include all the revisions, as
> opposed to merely containing the most recent set of contents.
>
> As a result, if you use "strings" to extract the "stuff that looks
> like text," you can often find more material in the document than the
> writer may have intended that you be able to see.
In this case, though, they didn't seem to have done a "fast save".
Either that, or they typed it all in one pass.
--
vsync
http://quadium.net/ - last updated Thu Jun 29 13:01:57 MDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
Erik Naggum <····@naggum.no> writes:
> Fortunately, you can apply unzip to it and not have to execute the
> file. Doing so yields a .DOC file which is a lot more useful than
> an .EXE file, fer sure! You now need _more_ Microsoft shitware to
> read the goddamn _text_. I used the demented StarOffice suite, and
> tried to print this "document" to paper, the only medium it should
> have been in in the first place, which failed miserably, of course.
> The PostScript file looks reasonable, and ghostview can display it,
> but no PostScript printer _anywhere_ will print it for me. Sigh.
I don't have any printers where I am now, but ps2pdf on the PostScript
file that StarOffice (5.1 with the "SGENPRT PostScript" printer
driver) generated something that xpdf and Acroread ate. Maybe those
would generate printable PostScript for you.
I know, I could have fired up VMware, but I haven't picked up
PDFWriter yet.
> But C# looks like what comes out of a brilliant mind at gun-point.
Have you seen this quote?
And an even more cunning route was at hand, as the redoubtable
maintainer of the Java site Cafe Au Lait, Rusty Harold Elliot points
out. Elliot, a long time critic of Sun's licensing tactics, notes: "If
Microsoft wanted to really challenge Java, they should have gone with
Python. I just don't believe it's possible for any major advances in
language design to be made while restricting oneself to the mistakes
Kernighan and Ritchie made 30 years ago."
It's at http://www.theregister.co.uk/content/1/11606.html. The author
even found a reference to Cool in the language reference.
In case you want to look at what Elliot wrote:
http://metalab.unc.edu/javafaq/ (search for June 23).
--
// John Markus Bj�rndalen
In article <··············@johnmnb.cs.uit.no>,
>Elliot, a long time critic of Sun's licensing tactics, notes:
"If
> Microsoft wanted to really challenge Java, they should have gone
with
> Python.
If Microsoft had wanted to kill Java, they should have acquired
Harlequin Dylan. Dylan is leaps-and-bounds better than Java, and
Harlequin had a good compiler already. Harlequin Dylan (now Functional
Developer) even supports COM/OLE and makes it easy to use.
Sent via Deja.com http://www.deja.com/
Before you buy.
<····@my-deja.com> wrote in message ·················@nnrp1.deja.com...
> If Microsoft had wanted to kill Java, they should have acquired
> Harlequin Dylan. Dylan is leaps-and-bounds better than Java, and
> Harlequin had a good compiler already. Harlequin Dylan (now Functional
> Developer) even supports COM/OLE and makes it easy to use.
I agree that Dylan is better than Java, but he didn't said that MS wanted to
have a better language than Java (there are already quite a lot of them). He
said "if MS wanted to really chanllenge Java...". Almost nobody believes
that Java succeeded on its technical merits.
Marc Battyani
Centuries ago, Nostradamus foresaw a time when ····@my-deja.com would say:
>In article <··············@johnmnb.cs.uit.no>,
>>Elliot, a long time critic of Sun's licensing tactics, notes:
>"If
>> Microsoft wanted to really challenge Java, they should have gone
>with
>> Python.
>
>If Microsoft had wanted to kill Java, they should have acquired
>Harlequin Dylan. Dylan is leaps-and-bounds better than Java, and
>Harlequin had a good compiler already. Harlequin Dylan (now Functional
>Developer) even supports COM/OLE and makes it easy to use.
Now _THERE_ is a frightening idea.
Mind you, if Microsoft had "bought" Dylan, this would give the Lisp
family a Rather Large shot in the arm, in terms of "credibility
amongst rather credulous people." Whether _that_ is a good thing
or not is anybody's guess...
--
········@ntlug.org - <http://www.ntlug.org/~cbbrowne/lsf.html>
?OM ERROR
"John Markus Bjorndalen" <·····@cs.uit.no> wrote in message
···················@johnmnb.cs.uit.no...
> And an even more cunning route was at hand, as the redoubtable
> maintainer of the Java site Cafe Au Lait, Rusty Harold Elliot points
> out. Elliot, a long time critic of Sun's licensing tactics, notes: "If
> Microsoft wanted to really challenge Java, they should have gone with
> Python. I just don't believe it's possible for any major advances in
> language design to be made while restricting oneself to the mistakes
> Kernighan and Ritchie made 30 years ago."
I think that they consider that Python is a scripting language and they have
already 2 such ones with VBScript and JavaScript. They have a marketing hole
for a Java class language and they try to fill it with C#. They try to do
the same recipe that Sun used with Java.
Marc Battyani
> Erik Naggum <····@naggum.no> writes:
>
> > Fortunately, you can apply unzip to it and not have to execute the
> > file. Doing so yields a .DOC file which is a lot more useful than
> > an .EXE file, fer sure! You now need _more_ Microsoft shitware to
> > read the goddamn _text_. I used the demented StarOffice suite, and
> > tried to print this "document" to paper, the only medium it should
> > have been in in the first place, which failed miserably, of course.
> > The PostScript file looks reasonable, and ghostview can display it,
> > but no PostScript printer _anywhere_ will print it for me. Sigh.
You may find that wvware <URL:http://www.wvware.com/> - which is GPL
- will make a more-or-less reasonable job of rendering it into
HTML. Not brilliant HTML, you understand, but something you can at
least read.
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
Morning had broken, and there was nothing left for us to do
but pick up the pieces.
In article <···············@nerd-xing.mit.edu>,
David Bakhash <·····@alum.mit.edu> wrote:
[...]
> If you want to find out more about the language, there's
> a download, but for god's sake it's an .EXE file! Should one have to
> run an executable to learn more about a language? Also, when I read
> about it, I was on a Linux box, and _couldn't_ run that EXE if I'd
> wanted to.
[...]
You could run a Windows emulator in Linux?
(loop (format t "~A" ":-)"))
--
Glauber Ribeiro
··········@my-deja.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
"Marc Battyani" <·············@csi.com> wrote in message
·······················································@lp.airnews.net...
[snip]
> Now we will see Java/C#/lisp threads instead of Java/lisp ones... sigh.
>
Guess that # is an abbrevation for ++++ :)
--
Eugene.
On Tue, 27 Jun 2000 15:15:00 +0300, "Eugene Zaikonnikov" <······@cit.org.by>
wrote:
>
> "Marc Battyani" <·············@csi.com> wrote in message
> ·······················································@lp.airnews.net...
> [snip]
> > Now we will see Java/C#/lisp threads instead of Java/lisp ones... sigh.
> >
> Guess that # is an abbrevation for ++++ :)
That was a bit flat. :-j
Surely Microsoft have just made a hash of something again? :-j
__Jason
Jason Trenouth <·····@harlequin.com> writes:
> On Tue, 27 Jun 2000 15:15:00 +0300, "Eugene Zaikonnikov" <······@cit.org.by>
> wrote:
>
> >
> > "Marc Battyani" <·············@csi.com> wrote in message
> > ·······················································@lp.airnews.net...
> > [snip]
> > > Now we will see Java/C#/lisp threads instead of Java/lisp ones... sigh.
> > >
> > Guess that # is an abbrevation for ++++ :)
>
> That was a bit flat. :-j
> Surely Microsoft have just made a hash of something again? :-j
Well, I wouldn't want to *pound* this into the ground, but there are a
*number* of other difficulties with the language.
`C-octothorpe' sounds more like an obscure mollusc than a computer
language.
> That was a bit flat. :-j
D-flat, perhaps? Or should that be abbreved to Db :-P
Philip
--
Ban GM foods! Long live the Mesolithicum, pesticides and starvation
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk \ European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
On Tue, 27 Jun 2000 15:15:00 +0300, "Eugene Zaikonnikov"
<······@cit.org.by> wrote:
> Guess that # is an abbrevation for ++++ :)
What about this?
C# --> C sharp --> See Sharp
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso wrote:
>
> On Tue, 27 Jun 2000 15:15:00 +0300, "Eugene Zaikonnikov"
> <······@cit.org.by> wrote:
>
> > Guess that # is an abbrevation for ++++ :)
>
> What about this?
>
> C# --> C sharp --> See Sharp
Or simply C-Hash (pronounced like "cash") ;-)
--
cya,
Jochen Schmidt
···@dataheaven.de
http://www.dataheaven.de
>>>>> "Eugene" == Eugene Zaikonnikov <······@cit.org.by> writes:
Eugene> Guess that # is an abbrevation for ++++ :)
No, they are just trying to get used to looking through prison bars.
--
Russell Senior ``The two chiefs turned to each other.
·······@aracnet.com Bellison uncorked a flood of horrible
profanity, which, translated meant, `This is
extremely unusual.' ''
"Russell Senior" <·······@aracnet.com> wrote in message
···················@coulee.tdb.com...
> >>>>> "Eugene" == Eugene Zaikonnikov <······@cit.org.by> writes:
>
> Eugene> Guess that # is an abbrevation for ++++ :)
>
> No, they are just trying to get used to looking through prison bars.
>
:) This gesture (forefingers and middle fingers of both hands crossed) in
Russian means exactly the prison bars. Another issue is that the 'sharp' has
no verbal equivalent in Russian. I wonder which nickname C# will receive
here :)
And I just noticed that MS Outlook Express strips out C# from header for
some reason when replying (see the subject).
--
Eugene.
* "Eugene Zaikonnikov" <······@cit.org.by>
| Another issue is that the 'sharp' has no verbal equivalent in
| Russian.
Huh? It's from the musical note system: flats and sharps.
| And I just noticed that MS Outlook Express strips out C# from header
| for some reason when replying (see the subject).
Amusing.
#:Erik
--
If this is not what you expected, please alter your expectations.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* "Eugene Zaikonnikov" <······@cit.org.by>
>| And I just noticed that MS Outlook Express strips out C# from header
>| for some reason when replying (see the subject).
>
> Amusing.
I think OE strips out everything up to the first ":" in headers. I believe
this is part of their internationalization support: when replying, it
inserts whatever the local equivalent of "Re:" is, and it removes anything
up to the first ":" on the assumption that it may be a foreign equivalent
of "Re:".
This is actually somewhat relevant to this thread, since they're both
examples of how Microsoft feels the need to set their own standards.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Erik Naggum <····@naggum.no> writes:
> * "Eugene Zaikonnikov" <······@cit.org.by>
> | Another issue is that the 'sharp' has no verbal equivalent in
> | Russian.
>
> Huh? It's from the musical note system: flats and sharps.
yes. in swedish C# is "ciss". the -iss suffix means sharp but i am
not sure if there is a proper swedish word for the "#" per se.
russian could have a similar scheme.
> | And I just noticed that MS Outlook Express strips out C# from header
> | for some reason when replying (see the subject).
lol
--
johan kullstam l72t00052
"Johan Kullstam" <········@ne.mediaone.net> wrote in message
··················@res.raytheon.com...
> Erik Naggum <····@naggum.no> writes:
>
> > * "Eugene Zaikonnikov" <······@cit.org.by>
> > | Another issue is that the 'sharp' has no verbal equivalent in
> > | Russian.
> >
> > Huh? It's from the musical note system: flats and sharps.
>
> yes. in swedish C# is "ciss". the -iss suffix means sharp but i am
> not sure if there is a proper swedish word for the "#" per se.
> russian could have a similar scheme.
>
Right. In Russian it would sound like 'see diez', so the sharp sign alone
probably must be spelled diez. Yuck!
Anyway I bet that C# will get some other name here.
--
Eugene.
Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:
>* "Eugene Zaikonnikov" <······@cit.org.by>
>| Another issue is that the 'sharp' has no verbal equivalent in
>| Russian.
>
> Huh? It's from the musical note system: flats and sharps.
There already was a "D-Flat;" Al Stevens presented several variations
of this in Dr Dobbs Journal a couple of years ago; it involved a
combination of:
a) Interpreted C++-like language and
b) Text mode CUA tools for OS/2 and Windows.
It's possible that the point of "C#" is purely subversive, of MSFT
tying (uncorrected typo; it just seems right...) to have their own
Java "successor."
But I suspect it may not be solely "political;" it may be reflective
of people starting to see that Java is not entirely adequate, and
starting to look for the "next thing" to migrate to.
If that be the case, it's somewhat sooner than I expected; I thought
Java would zenith a bit later. If this in fact be the case, I find it
_appalling_ that a hacked-up version of the Java design is being
suggested as the Next Step.
Alternatively, it may be a Very Good Thing, supposing it causes big
enough disasters as to make people actually step back and think before
simply rehashing BCPL and Simula again...
>| And I just noticed that MS Outlook Express strips out C# from header
>| for some reason when replying (see the subject).
>
> Amusing.
>
>#:Erik
Which would make your ":Erik" into an "optional argument," rather than
a symbol... There's something strangely amusing about that.
Someone at Microsoft probably figured that stripping out some
characters from headers would somehow "improve security," which is
about par for the course...
--
·····@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/lisp.html>
When replying, it is often possible to cleverly edit the original
message in such a way as to subtly alter its meaning or tone to your
advantage while appearing that you are taking pains to preserve the
author's intent. As a bonus, it will seem that your superior
intellect is cutting through all the excess verbiage to the very heart
of the matter.
-- from the Symbolics Guidelines for Sending Mail
········@news.hex.net (Christopher Browne) writes:
> > Amusing.
> >
> >#:Erik
>
> Which would make your ":Erik" into an "optional argument," rather than
> a symbol... There's something strangely amusing about that.
I thought #:Erik nearly always denoted a required argument. I should
have read the documentation.
In article <·······················@news5.giganews.com>,
········@hex.net wrote:
> But I suspect it may not be solely "political;" it may be reflective
> of people starting to see that Java is not entirely adequate, and
> starting to look for the "next thing" to migrate to.
>
> If that be the case, it's somewhat sooner than I expected; I thought
> Java would zenith a bit later. If this in fact be the case, I find it
> _appalling_ that a hacked-up version of the Java design is being
> suggested as the Next Step.
>
> Alternatively, it may be a Very Good Thing, supposing it causes big
> enough disasters as to make people actually step back and think before
> simply rehashing BCPL and Simula again...
I sure hope so.
And Dylan is finally ready, just in the nick of time. I hope :-)
-- Bruce
In article <···············@cpl2500.cit.org.by>,
"Eugene Zaikonnikov" <······@cit.org.by> wrote:
> Another issue is that the 'sharp' has
> no verbal equivalent in Russian.
this is from the musics lingo.
[si diez] is the translation.
Sent via Deja.com http://www.deja.com/
Before you buy.
···@usa.net writes:
> In article <···············@cpl2500.cit.org.by>,
> "Eugene Zaikonnikov" <······@cit.org.by> wrote:
> > Another issue is that the 'sharp' has
> > no verbal equivalent in Russian.
>
> this is from the musics lingo.
> [si diez] is the translation.
Oh, it's that kind of '#'... I had just assumed C# was the British
English name and that it would be called C$ in American English...
emphasizing the use of C technology at the cost of $ or #, whichever
M$ thinks they could extort from us at the time. ;-)
Centuries ago, Nostradamus foresaw a time when Kent M Pitman would say:
>···@usa.net writes:
>
>> In article <···············@cpl2500.cit.org.by>,
>> "Eugene Zaikonnikov" <······@cit.org.by> wrote:
>> > Another issue is that the 'sharp' has
>> > no verbal equivalent in Russian.
>>
>> this is from the musics lingo.
>> [si diez] is the translation.
>
>Oh, it's that kind of '#'... I had just assumed C# was the British
>English name and that it would be called C$ in American English...
>emphasizing the use of C technology at the cost of $ or #, whichever
>M$ thinks they could extort from us at the time. ;-)
How about a third option?
Pronounce it "C-Hash."
Which would mean that Microsoft is telling us that they are "making a
hash" of C...
--
········@ntlug.org - <http://www.ntlug.org/~cbbrowne/languages.html>
"The problem with the current Lisp Machine system is that nothing ever calls
anything anymore." -- KMP
On Thu, 29 Jun 2000 21:48:59 GMT, Kent M Pitman wrote:
> ···@usa.net writes:
>> In article <···············@cpl2500.cit.org.by>,
>> "Eugene Zaikonnikov" <······@cit.org.by> wrote:
>> > Another issue is that the 'sharp' has
>> > no verbal equivalent in Russian.
>>
>> this is from the musics lingo.
>> [si diez] is the translation.
> Oh, it's that kind of '#'... I had just assumed C# was the British
> English name and that it would be called C$ in American English...
> emphasizing the use of C technology at the cost of $ or #, whichever
> M$ thinks they could extort from us at the time. ;-)
Heh. Unlikely -- as far as I know, pronouncing "#" as "pound" is a
purely American thing (I've never heard anyone else use that...
everyone else uses "lb" for pounds (avoirdupois; if they use pounds at
all). I have used British computers that had the pound (sterling)
sign on the shifted "3" key, where American keyboards have the hash,
and used the same code point in the character set, but that can't be
related (surely!?))
--
Nomina stultorum in parietibus et portis semper videmus. -- Cicero
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley <·······@actrix.gen.nz> writes:
> all). I have used British computers that had the pound (sterling)
> sign on the shifted "3" key, where American keyboards have the hash,
> and used the same code point in the character set, but that can't be
> related (surely!?))
A UK keyboard typically has the pound sterling symbol on shifted 3.
It doesn't usually share a code point in the character set (I haven't
seen anything that did since some time in the early 80s, at least) but
note that in ISO Latin 1, hash has the number 35, and sterling has 163
-- the difference is 128. So sending a pound sterling symbol through
a link that strips the high bit will often get you a #. This tends to
complicate things when the discussion comes round again on usenet.
-dan
--
http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm
···@usa.net writes:
> In article <···············@cpl2500.cit.org.by>,
> "Eugene Zaikonnikov" <······@cit.org.by> wrote:
> > Another issue is that the 'sharp' has
> > no verbal equivalent in Russian.
>
> this is from the musics lingo.
> [si diez] is the translation.
[do diez] is the translation, actually.
--
only legal replies to this address are accepted.
Make sure your code does nothing gracefully.
well, it's a step in the right direction. maybe in some ways it's
what Dylan was (though, I don't know enough about Dylan to know for
sure). I guess that Java didn't cut it, likely because Java _is_ a
LCD language in many ways (in the MS writeup about C#, they say:
``...there are languages today that raise productivity by sacrificing the
flexibility that C and C++ programmers often require. Such
solutions constrain the developer too much (for example, by
omitting a mechanism for low-level code control) and provide
least-common-denominator capabilities. They don't easily
interoperate with preexisting systems, and they don't always mesh
well with current Web programming practices.''
So, what they're referring to is that there are new technologies
(e.g. XML) and they want their new programming language to have
features which facilitate interoperability. But that's the big
problem! they keep (re)inventing languages with new features that are
specific to what they're doing right then and there. So today the
thousand-dollar buzzword is XML. Surely tomorrow it will be something
else. Will they create yet another language every 5 or 10 years? And
will that window start becoming narrower and narrower? Or will they
actually just create a language that can be adapted over time? My
opinion is that they're going to get screwed just *because* they're so
insistent upon holding onto C stuff. Am I the only person here who
cringes at the thought of C embedded inside C#, in which assembly code
may be doubly embedded? Will my brain realistically have an easier
time reading C# when I know that at any time it can turn into C, and
then back?
I think this new thing may be great for Windows programmers. Good for
them. But for me it's just more noise -- another language to talk
about, and think about, and hear about. And worst yet, people who
program in it will likely _never_ have the luxury of being able to
detatch themselves easily from what will become MS legacy. I bet that
even if C# makes it 10X easier to get some XML application off the
ground using MS Windows, it'll be 100X harder to port to Unix than if
the original implementor used straight C, and that's exactly what MS
probably wants (and all the power to them -- they're not stupid).
As usual, those who don't look at the big picture will eventually be
doomed. Of course, when doom happens, many of them will be retired,
and so it won't be their problem.
dave
On 27 Jun 2000 10:25:21 -0400, David Bakhash <·····@alum.mit.edu> wrote:
> well, it's a step in the right direction. maybe in some ways it's
> what Dylan was (though, I don't know enough about Dylan to know for
> sure).
No. C# is nothing like Dylan _is_ (present tense). :-j
In Hollywood mogel vernacular "Dylan is Scheme meets Common Lisp meets
Smalltalk meets Pascal":
Scheme's basic Lisp-1 semantics.
Common Lisp's object system and condition system.
Smalltalk's objects-all-the-way-down philosophy.
Algol/Pascal ish syntax.
Basically, Dylan is very Lispy and easy for Schemers and Lispers to understand.
However, Dylan aims for more straightforward application delivery so it
separates the application from the environment and provides less in the way of
reflection, introspection, and application-controlled compilation.
You can still interactively compile and redefine individual methods etc, and
then experimentally invoke them inside your running application, but this all
happens under the control of the IDE via a tether to the separate application.
The separation of application and means that when development has finished it
is already in a standalone redistributable form (EXE, DLL, OCX, etc) with only
the libraries it needs.
From a Common Lisper's point of view Dylan may seem to pander too much to the
masses and have too many useful/interesting bits cut out, but conversely
Lispers may also find it has less historical baggage and is more easily able to
produce standalone applications and components that interact with the 'modern'
world.
__Jason
From: David Bakhash
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <c29g0pxbubg.fsf@nerd-xing.mit.edu>
Jason Trenouth <·····@harlequin.com> writes:
> Basically, Dylan is very Lispy and easy for Schemers and Lispers to understand.
I personally don't agree. That's only my opinion.
> However, Dylan aims for more straightforward application delivery so it
> separates the application from the environment and provides less in the way of
> reflection, introspection, and application-controlled compilation.
application delivery in ANSI CL is kinda non-existent, but not so with
what's out there. It is true, of course, that you don't have too many
options with CL as far as delivery goes.
> From a Common Lisper's point of view Dylan may seem to pander too much to the
> masses and have too many useful/interesting bits cut out, but conversely
> Lispers may also find it has less historical baggage and is more easily able to
> produce standalone applications and components that interact with the 'modern'
> world.
I looked into it. I found Perl syntax easier to grasp. Maybe Dylan is
just too modern (for me). Anyway, when I look at other languages, I
don't do so looking to replace the Old one; I just like to see Lispish
stuff implemented in different ways, and with different syntaxes and
such.
Anyway, getting back to C#. I compared it to Dylan because:
1) native code compilation
2) GC
3) C-ish syntax with some Java-like stuff thrown in there
that's all. I should have enunciated that more clearly. sorry about
that.
dave
From: ····@my-deja.com
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <8jg99e$qk2$1@nnrp1.deja.com>
In article <···············@nerd-xing.mit.edu>,
David Bakhash <·····@alum.mit.edu> wrote:
> Jason Trenouth <·····@harlequin.com> writes:
>
> > Basically, Dylan is very Lispy and easy for Schemers and Lispers to
understand.
>
> I personally don't agree. That's only my opinion.
>
I regard Dylan as a descendant of Lisp... basically a
fully-object-oriented and cleaned-up Lisp. I think that any Lisp
programmer should pick up Dylan very, very easily.
Sent via Deja.com http://www.deja.com/
Before you buy.
From: David Bakhash
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <c29hfabb0ix.fsf@nerd-xing.mit.edu>
····@my-deja.com writes:
> In article <···············@nerd-xing.mit.edu>,
> David Bakhash <·····@alum.mit.edu> wrote:
> > Jason Trenouth <·····@harlequin.com> writes:
> >
> > > Basically, Dylan is very Lispy and easy for Schemers and Lispers to
> understand.
> >
> > I personally don't agree. That's only my opinion.
> >
>
> I regard Dylan as a descendant of Lisp... basically a
> fully-object-oriented and cleaned-up Lisp. I think that any Lisp
> programmer should pick up Dylan very, very easily.
don't get me wrong. I see the similarities, and an kinda map Dylan back
into Lisp. It's going the other way that's the problem, and since I'm
kinda stuck thinking in Common Lisp, this is just too hard. In fact,
maybe it's the fact that they share enough in common that hurts me.
It's almost interference. I program quite fluently in Perl, and that's
not too similar to CL at all, except no pointers and GC.
Dylan did clean up some things, but they were mostly minor to me.
"very, very easily" makes me feel a bit slow.
dave
On 28 Jun 2000 13:15:47 -0400, David Bakhash <·····@alum.mit.edu> wrote:
> Jason Trenouth <·····@harlequin.com> writes:
>
> > Basically, Dylan is very Lispy and easy for Schemers and Lispers to understand.
>
> I personally don't agree. That's only my opinion.
Hmmm. Maybe you just found the transition from Common Lisp to Scheme confusing
if you haven't used Scheme before? A single namespace and using bindings
instead of symbols can seem strange at first I think.
e.g.
;; Lisp
(defun test ()
(process-args 'foo 'bar '(baz quux)))
(defun process-args (func context args)
(loop for arg in args
do (funcall func context arg)))
// Dylan
define function test ()
process-args( foo, #"bar", #( baz, quux ) );
end;
define function process-args ( func, context, args )
for ( arg in args )
func( context, arg );
end;
end;
..
> Anyway, getting back to C#. I compared it to Dylan because:
>
> 1) native code compilation
> 2) GC
> 3) C-ish syntax with some Java-like stuff thrown in there
Well, Dylan really isn't C-ish syntax. No braces (except in macro definitions),
no casting, postfix type declarations, and very different (Lisp/Scheme-like)
identifier conventions. Unfortunately, from the point of view of promulgating
the language, Dylan's syntax looks very alien to many C programmers.
__Jason
In article <··································@4ax.com>, Jason Trenouth
<·····@harlequin.com> wrote:
> Well, Dylan really isn't C-ish syntax. No braces (except in macro
> definitions), no casting, postfix type declarations, and very
> different (Lisp/Scheme-like) identifier conventions. Unfortunately,
> from the point of view of promulgating the language, Dylan's syntax
> looks very alien to many C programmers.
I suspect that the guys tasked with coming up with the infix syntax were
concerned that if it looked *too* C-like then people would expect it to
have C semantics.
This was, of course, in the days before Java, Perl, and C#.
-- Bruce
From: Lyman Taylor
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395B7ECC.E558CDD5@mindspring.com>
Bruce Hoult wrote:
...
> This was, of course, in the days before Java, Perl, and C#.
Err... C# certainly. :-)
Work on Dylan probably predates Java (the language formerly know as Oak)
only by short amount of time, if at all. I seem to recall hearing about
Oak and Dylan around the same time. However, the current infix
syntax does not. (Dylan had Lisp/Scheme like syntax at first).
Perl (1987)... I don't think so. At least "Perl" the replacement for "awk".
(as opposed to Perl that caught the internet wave).
I think it would more accurate that the Dylan syntax was likely more a
direct "anti" reaction to the baroque language C++. That language was
in the "cures all ills" phase that Java is in now about that time. I
don't think the designers wanted to take the herculean leap from
"scheme like" to "c++ like". Languages like Ada and Modula-3 had
more compatible syntatical goals than C/C++.
The commonality that C/Dylan share is along the respective
Algol ancestory lines. Which for both is kind of far back. ;-)
However, it is enough, with modest effort, for folks predisposed
to C syntax to latch onto.
Lyman
From: Rob Myers
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395B53FD.2F3EE4CE@h2g2.com>
The syntax looks alien relative to curly-bracket languages, but the
semantics are pretty similar. I find that as long as you admit that it
looks different, then explain how it's similar, you can get people to map
their C syntax to Dylan syntax pretty easily.
I got used to Dylan's syntax from a C background, I still haven't got used
to Lisp's.
int CPlusPlus()
{
return 1;
}
(defun lisp (x)
1
)
define method dylan() => ( result )
1;
end method dylan;
- Rob.
Bruce Hoult wrote:
> In article <··································@4ax.com>, Jason Trenouth
> <·····@harlequin.com> wrote:
>
> >Unfortunately,
> > from the point of view of promulgating the language, Dylan's syntax
> > looks very alien to many C programmers.
--
Rob Myers - ····@h2g2.com H2G2 - http://www.h2g2.com/
"Don't talk to sociologists. Social practice has no sociological
content."A&L
http://www.robmyers.org/ http://www.gwydiondylan.org/
From: Lyman Taylor
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395B857C.B5FEA267@mindspring.com>
Rob Myers wrote:
...
> .... but the
> semantics are pretty similar.
Huh???
Dylan C
reference based semantics value based semantics
(never make a copy unless ( always make copies)
explicity asked for)
operators are function calls operators tend to map to opocodes
most "statements" are expressions statements don't return values.
(e.g.
1 == if test then a else b end; )
There are not totally unsimilar, but there are some definately some stuff
that can throw a C programmer into confusion.
The presented code fragments were almost entirely "syntax", IMHO.
The "last expression, function's value" sematics are matched in
dylan and lisp whereas the C requires explicit control change.
I will grant that people present their most negative visceral reactions
to "alien" syntax. Second only to "alien" editors. :-) They seem to
much more forgiving of difference as long as it malleable enough to
tweaked to what they want. (if necessary, a big enough hammer to
fit round peg into square hole.
if test then temp := a else temp := b end;
1 == temp;
Or the classic "FORTRAN written in C". )
Lyman
Bruce Hoult <·····@hoult.org> writes:
> In article <··································@4ax.com>, Jason Trenouth
> <·····@harlequin.com> wrote:
>
> > Well, Dylan really isn't C-ish syntax. No braces (except in macro
> > definitions), no casting, postfix type declarations, and very
> > different (Lisp/Scheme-like) identifier conventions. Unfortunately,
> > from the point of view of promulgating the language, Dylan's syntax
> > looks very alien to many C programmers.
>
> I suspect that the guys tasked with coming up with the infix syntax were
> concerned that if it looked *too* C-like then people would expect it to
> have C semantics.
Isn't there also an (alternative) prefix syntax for Dylan? That must
be even more lisp-like (says Simon, never having tried it).
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
' ' <------- this blank intentionally spaced left
On Fri, 30 Jun 2000 09:33:34 GMT, Simon Brooke <·····@jasmine.org.uk> wrote:
> Isn't there also an (alternative) prefix syntax for Dylan? That must
> be even more lisp-like (says Simon, never having tried it).
No. That was ditched a long time ago.
__Jason
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171354053463029@naggum.no>
* Jason Trenouth <·····@harlequin.com>
| No. That was ditched a long time ago.
Yet, curiously, that was about the same time I decided Dylan was a
waste of time.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum wrote in message <················@naggum.no>...
>* Jason Trenouth <·····@harlequin.com>
>| No. That was ditched a long time ago.
>
> Yet, curiously, that was about the same time I decided Dylan was a
> waste of time.
>
If infix syntax was not what you expected, please alter your expectations.
Translation: I implemented Lisp and Lisp environments for 12 years.
I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
what? I like Dylan better, syntax and all.
>#:Erik
>--
> If this is not what you expected, please alter your expectations.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171366678290484@naggum.no>
* "Scott McKay" <···@mediaone.net>
| If infix syntax was not what you expected, please alter your expectations.
Oh, please.
| Translation: I implemented Lisp and Lisp environments for 12 years.
| I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
| what? I like Dylan better, syntax and all.
Yeah, we need more personal testimonials.
My point was that the decision to drop the Lisp-like syntax was
pretty darn stupid considering it was a selling point towards a
community that was told "you fine people don't matter, anymore".
#:Erik
--
If this is not what you expected, please alter your expectations.
From: Carl L. Gay
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395C9ACA.5272174C@thecia.net>
Erik Naggum wrote:
>
> * "Scott McKay" <···@mediaone.net>
> | If infix syntax was not what you expected, please alter your expectations.
>
> Oh, please.
>
> | Translation: I implemented Lisp and Lisp environments for 12 years.
> | I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
> | what? I like Dylan better, syntax and all.
>
> Yeah, we need more personal testimonials.
>
> My point was that the decision to drop the Lisp-like syntax was
> pretty darn stupid considering it was a selling point towards a
> community that was told "you fine people don't matter, anymore".
It's pointless to spend any effort selling to 1% of the market.
Reality sucks.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171376801691704@naggum.no>
* "Carl L. Gay" <·····@thecia.net>
| It's pointless to spend any effort selling to 1% of the market.
Then it's clearly even more pointless to spend any effort "selling"
anything to you, only one in 6 _billion_ people, such as a much
better attitude towards "reality" than you currently have, both in
terms of suckiness and in terms of this mythological _one_ market.
#:Erik
--
If this is not what you expected, please alter your expectations.
From: Tim Bradshaw
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <ey38zvnyrjo.fsf@cley.com>
* Carl L Gay wrote:
> It's pointless to spend any effort selling to 1% of the market.
> Reality sucks.
I wonder how big Dylan's market is compared to Lisp's (not a
rhetorical question, I'd like to know).
--tim
From: Carl L. Gay
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395DE0EA.EB084693@thecia.net>
Tim Bradshaw wrote:
>
> * Carl L Gay wrote:
>
> > It's pointless to spend any effort selling to 1% of the market.
> > Reality sucks.
>
> I wonder how big Dylan's market is compared to Lisp's (not a
> rhetorical question, I'd like to know).
I guess it's a good sign that you don't think it's obvious. :-)
It's a small percentage of the size of the Lisp community, I'm sure.
Centuries ago, Nostradamus foresaw a time when Carl L. Gay would say:
>Erik Naggum wrote:
>>
>> * "Scott McKay" <···@mediaone.net>
>> | If infix syntax was not what you expected, please alter your expectations.
>>
>> Oh, please.
>>
>> | Translation: I implemented Lisp and Lisp environments for 12 years.
>> | I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
>> | what? I like Dylan better, syntax and all.
>>
>> Yeah, we need more personal testimonials.
>>
>> My point was that the decision to drop the Lisp-like syntax was
>> pretty darn stupid considering it was a selling point towards a
>> community that was told "you fine people don't matter, anymore".
>
>It's pointless to spend any effort selling to 1% of the market.
>Reality sucks.
Ah, but when you're trying to sell _Dylan_, when it has _no_ market,
having a community of Lisp adopters might have been a Good Thing, and
might well have represented a lot more than 1% of the market _for
Dylan_.
--
········@hex.net - <http://www.ntlug.org/~cbbrowne/lisp.html>
I'M SORRY, LUSER, I CAN'T LET YOU DO THAT. WHY DON'T YOU LIE DOWN AND TAKE
A STRESS PILL? MY NAME IS LM1. I WAS MADE AT THE LISP MACHINE FACTORY IN
MASSACHUSETTS ON DECEMBER 12, 1992. MY TEACHER WAS MR. WINSTON. HE
TAUGHT ME A PROGRAM. WOULD YOU LIKE TO SEE IT? HERE IT IS:
Christopher Browne wrote in message ...
>
>Ah, but when you're trying to sell _Dylan_, when it has _no_ market,
>having a community of Lisp adopters might have been a Good Thing, and
>might well have represented a lot more than 1% of the market _for
>Dylan_.
Hey, look, if the only thing that Lispers care about is having
Lisp syntax, then they are as closed-minded as the C and Java
communities. Syntax is trivial. Get over it.
From: Johan Kullstam
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <m2og4hajrm.fsf@euler.axel.nom>
"Scott McKay" <···@mediaone.net> writes:
> Christopher Browne wrote in message ...
>
> >
> >Ah, but when you're trying to sell _Dylan_, when it has _no_ market,
> >having a community of Lisp adopters might have been a Good Thing, and
> >might well have represented a lot more than 1% of the market _for
> >Dylan_.
>
>
> Hey, look, if the only thing that Lispers care about is having
> Lisp syntax, then they are as closed-minded as the C and Java
> communities. Syntax is trivial. Get over it.
it's not. i like the lisp syntax because of its clean look. more
importantly, the syntax is what lets lisp have such powerful and
useful macros. with a less regular or less simple syntax you could
never do it as easily nor to such great effect. it has nothing to do
with being closed minded. sometimes certain things really are better;
this is such a case.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
"Johan Kullstam" <········@ne.mediaone.net> wrote in message
···················@euler.axel.nom...
>> Syntax is trivial. Get over it.
> it's not. i like the lisp syntax because of its clean look.
That's the first time I've seen someone describe a profusion of parentheses
as "clean".
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171472167433957@naggum.net>
* "Michael T. Richter" <···@ottawa.com>
| That's the first time I've seen someone describe a profusion of
| parentheses as "clean".
Congratulations! That's means you have finally opened your eyes to
the _existence_ of people who don't share your closed-minded view on
syntax. That's no small feat for a man in this day and age! I hear
tolerance is such a virtue over in the Dylan camp, so you must feel
almost like a white supremacist who saw the first black in his life,
or the uptight puritan who first discovered gays and lesbians on his
own -- such wild and unbridled expansion of your consciousness is so
seldom achieved without drugs these days. Man, you are _so_ lucky.
No wonder Dylan dropped its clean, attractive syntax -- had it
retained it, the Dylan community would have had to deal with so much
hostility in their own ranks -- as always, it's _so_ much better to
find an external "enemy" to ridicule and denigrate, especially when
it's someone you think you're competing with because you might have
been friends if you were any smart, but if you choose infix, being
smart is just _not_ an option.
#:Erik
--
If this is not what you expected, please alter your expectations.
Wow! One post and you've already triggered Godwin's Law.
Goodbye.
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * "Michael T. Richter" <···@ottawa.com>
> | That's the first time I've seen someone describe a profusion of
> | parentheses as "clean".
>
> Congratulations! That's means you have finally opened your eyes to
> the _existence_ of people who don't share your closed-minded view on
> syntax. That's no small feat for a man in this day and age! I hear
> tolerance is such a virtue over in the Dylan camp, so you must feel
> almost like a white supremacist who saw the first black in his life,
> or the uptight puritan who first discovered gays and lesbians on his
> own -- such wild and unbridled expansion of your consciousness is so
> seldom achieved without drugs these days. Man, you are _so_ lucky.
>
> No wonder Dylan dropped its clean, attractive syntax -- had it
> retained it, the Dylan community would have had to deal with so much
> hostility in their own ranks -- as always, it's _so_ much better to
> find an external "enemy" to ridicule and denigrate, especially when
> it's someone you think you're competing with because you might have
> been friends if you were any smart, but if you choose infix, being
> smart is just _not_ an option.
>
> #:Erik
> --
> If this is not what you expected, please alter your expectations.
From: Seth Gordon
Subject: Godwin's Law (every day in every way I'm getting meta and meta)
Date:
Message-ID: <3969EE47.F2B79ACD@kenan.com>
"Michael T. Richter" wrote:
> Wow! One post and you've already triggered Godwin's Law.
>
> Goodbye.
>
> "Erik Naggum" <····@naggum.net> wrote in message
> ·····················@naggum.net...
> > ...I hear
> > tolerance is such a virtue over in the Dylan camp, so you must feel
> > almost like a white supremacist who saw the first black in his life...
(with-pedantry
I don't think a reference to "a white supremacist" is enough to trigger
Godwin's Law -- you need to specifically mention, umm, you know, him, or,
umm, you know, them.
)
--
--Why is it that most kids are attracted to computers while
most adults are quite wary of computers?
--Most adults are smarter than most kids. ["Ask Uncle Louie"]
== seth gordon == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
From: Tim Bradshaw
Subject: Re: Godwin's Law (every day in every way I'm getting meta and meta)
Date:
Message-ID: <ey3wvit29fo.fsf@cley.com>
* Seth Gordon wrote:
> (with-pedantry
> I don't think a reference to "a white supremacist" is enough to trigger
> Godwin's Law -- you need to specifically mention, umm, you know, him, or,
> umm, you know, them.
> )
It's also OK to call them by name when discussing Godwin's law. This
is a fairly trivial consequence of Quirk's exception I think, although
I don't have my copy of `mathematical methods for usenet' to hand.
--tim
"Michael T. Richter" <···@ottawa.com> writes:
> "Johan Kullstam" <········@ne.mediaone.net> wrote in message
> ···················@euler.axel.nom...
> >> Syntax is trivial. Get over it.
>
> > it's not. i like the lisp syntax because of its clean look.
>
> That's the first time I've seen someone describe a profusion of parentheses
> as "clean".
Well, then, look again. LISP syntax results from the fact that LISP as
printed is a very nearly direct representation of the structures that
are created in the machine as it is read.
The representation of LISP structures which you conventionally edit in
a file has a uniquely direct and simple mapping onto the
representation which is held in core - a representation much more
direct, much more consistent and much more perspicuous than in any
other high-level language in common use. Furthermore, these structures
which you edit can be interpreted directly, and one of the great
benefits of Common LISP over earlier LISPs is it strives very hard to
ensure that the semantics of code when it is compiled are identical to
the semantics of the same code when interpreted.
It's this cleanness which makes it so much easier to 'think yourself
into the machine' in LISP than in other high-level languages.
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; If God does not write LISP, God writes some code so similar to
;; LISP as to make no difference.
"Simon Brooke" <·····@jasmine.org.uk> wrote in message
···················@gododdin.internal.jasmine.org.uk...
>> That's the first time I've seen someone describe a profusion of
>> parentheses as "clean".
> Well, then, look again. LISP syntax results from the fact that LISP as
> printed is a very nearly direct representation of the structures that
> are created in the machine as it is read.
But, silly me, I've always thought the point of automation was to make *MY*
life easier, not the machine's.
"Michael T. Richter" <···@ottawa.com> writes:
> But, silly me, I've always thought the point of automation was to make
> *MY* life easier, not the machine's.
your life is easier when there are less barriers between expression and
action to worry about.
thi
"thi" <···@netcom.com> wrote in message
····················@netcom3.netcom.com...
>> But, silly me, I've always thought the point of automation was to
>> make *MY* life easier, not the machine's.
> your life is easier when there are less barriers between expression and
> action to worry about.
<tone mode="irony">
Yes. That's why I always resort to assembler when I write complex programs.
</tone>
From: David Hanley
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <396675F0.647A358D@ncgr.org>
"Michael T. Richter" wrote:
> "thi" <···@netcom.com> wrote in message
> ····················@netcom3.netcom.com...
> >> But, silly me, I've always thought the point of automation was to
> >> make *MY* life easier, not the machine's.
>
> > your life is easier when there are less barriers between expression and
> > action to worry about.
>
> <tone mode="irony">
> Yes. That's why I always resort to assembler when I write complex programs.
> </tone>
I suspect someone who knows assembler would realize that the
need to juggle registers, worry about timing, track the types of
thing in registers, etc, are, in fact, barriers to expression. It makes
expression harder, right?
dave
David Hanley <···@ncgr.org> writes:
> "Michael T. Richter" wrote:
>
> > "thi" <···@netcom.com> wrote in message
> >
> > > your life is easier when there are less barriers between
> > > expression and action to worry about.
> >
> > <tone mode="irony">
> > Yes. That's why I always resort to assembler when I write
> > complex programs.
> > </tone>
>
> I suspect someone who knows assembler would realize that the need to
> juggle registers, worry about timing, track the types of thing in
> registers, etc, are, in fact, barriers to expression. It makes
> expression harder, right?
i see i was unclear in defining my context. for me, expression is best
when done at its most high-level ("leveraged" for the buzzword bingo
crowd). to get back to the point, reading LISP forms allows me to
connect to the original author's brain quite easily because the
abstraction level chosen by that author tells me a lot about the
author's overall approach (or context).
to go meta (why not?), all this verbiage could've been replaced w/:
(with-context 'guru-wannabe
(reading LISP))
=>
the-good-life
btw, i know assembly and agree w/ your assessment, but only because i've
been ruined by all these parentheses... :->
thi
From: David Hanley
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39667028.2A126AF8@ncgr.org>
"Michael T. Richter" wrote:
> "Simon Brooke" <·····@jasmine.org.uk> wrote in message
> ···················@gododdin.internal.jasmine.org.uk...
> >> That's the first time I've seen someone describe a profusion of
> >> parentheses as "clean".
>
> > Well, then, look again. LISP syntax results from the fact that LISP as
> > printed is a very nearly direct representation of the structures that
> > are created in the machine as it is read.
>
> But, silly me, I've always thought the point of automation was to make *MY*
> life easier, not the machine's.
It does make the programmer's job easier when he has to think about
transforming source code, or think about exactly how the machine
is interpreting this code. Because there's major transformation
going on ( lisp code is almost an abstract syntax tree itself ) it can
be very obvious what is happening.
dave
From: Reini Urban
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3964d24b.369090373@news>
Compliments only to features which deserve them. Here I found a couple
of misinterpretations, so I list some "problems" which might be anchors
for people from outside:
Simon Brooke wrote:
>Well, then, look again. LISP syntax results from the fact that LISP as
>printed is a very nearly direct representation of the structures that
>are created in the machine as it is read.
are you mixing assembler with lisp here?
a lisp (READ) is a much more complicated then a C read().
a lisp (PRINT) is much more complicated then a C write().
the point is the difference, not the sameness.
not having pointers is a great burden to represent data, and internally
you have only pointers which is a great burden to deal with also.
>The representation of LISP structures which you conventionally edit in
>a file has a uniquely direct and simple mapping onto the
>representation which is held in core - a representation much more
>direct, much more consistent and much more perspicuous than in any
>other high-level language in common use.
doubt the first. exactly the opposite, thanksfully so.
C or pascal pointer orgies would resemble high-level internal
representation of lists in contrast to the list abstraction.
compare a => b => c => nil to (a b c).
simple? hmm. powerful, yes. consistent and perspicuous?
well... that's getting esoteric. every language has its own consistent
and perspicuous representation.
structures are just "vector" areas in memory, that's why we have
high-level languages and don't have to deal with internal
representations. pointers and offsets. *(s+i) and such.
named and typed slots, in lisp even typed data, not just slots.
and with tagged data it is completely the opposite of direct
representations. ever wrote lisp<-><other memory> converters?
only typed structures and typed vector would deserve that name.
>It's this cleanness which makes it so much easier to 'think yourself
>into the machine' in LISP than in other high-level languages.
I prefer the opposite thinking. into the problem not into the machine.
that's why I prefer lisp and not assembler or C.
The points with lisp are other's, that you can easily abstract lists,
nested lists and more. And having a language which is defined in exactly
the same simple way. blabla...
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
From: Daniel Barlow
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <87hfa2z215.fsf@tninkpad.telent.net>
······@sbox.tu-graz.ac.at (Reini Urban) writes:
> Simon Brooke wrote:
> >Well, then, look again. LISP syntax results from the fact that LISP as
> >printed is a very nearly direct representation of the structures that
> >are created in the machine as it is read.
>
> are you mixing assembler with lisp here?
> a lisp (READ) is a much more complicated then a C read().
> a lisp (PRINT) is much more complicated then a C write().
You're both right. He said "read", not "compiled".
I definitely think it's a win that we have a standard list-based form
(pun, uh, intended) on which the macro system operates.
-dan
--
http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm
······@sbox.tu-graz.ac.at (Reini Urban) writes:
> Compliments only to features which deserve them. Here I found a couple
> of misinterpretations, so I list some "problems" which might be anchors
> for people from outside:
>
> Simon Brooke wrote:
> >Well, then, look again. LISP syntax results from the fact that LISP as
> >printed is a very nearly direct representation of the structures that
> >are created in the machine as it is read.
>
> are you mixing assembler with lisp here?
Yes and no. LISP *is*, after all, at bottom, an assembler - for an
abstract machine with a small number of instructions, and the ability
to compose new instructions from existing ones in a seamless manner.
After all, all of
CAR
CDR
EQ
SET
(and others, but exactly which others we could argue about) are
effectively primitive instructions for the LISP virtual machine (and,
indeed, are generally compiled to single instructions for the machine
machine LISP runs on); but it's worth bearing in mind that in LISP
machines (in the broader sense) the distinction between a function and
a primitive instruction can get blurred in the strangest places. For
example, in the mid-eighties, Xerox had an experimental processor
which did selector-method resolution for LOOPS (Xerox' object-oriented
extension for InterLISP, and one of the precursors for CLOS) as a
*single* machine instruction. Given that LOOPS was multiple
inheritance, that is an exceedingly non-trivial function (and yes, it
was implemented in microcode, and I'm sure it didn't execute in one
clock tick).
Furthermore, assembler, in its commonly accepted sense, is a very poor
representation of what actually happens in the machine. It can
represent clearly only continuous vectors of instructions. Very little
of what happens in a machine is continuous vectors of instructions.
> a lisp (READ) is a much more complicated then a C read().
> a lisp (PRINT) is much more complicated then a C write().
Did I say they weren't? Wherein is the contradiction?
> >The representation of LISP structures which you conventionally edit in
> >a file has a uniquely direct and simple mapping onto the
> >representation which is held in core - a representation much more
> >direct, much more consistent and much more perspicuous than in any
> >other high-level language in common use.
>
> doubt the first. exactly the opposite,
If you believe this, you have never written a structure editor. Write
one; you will find it very instructive.
> thanksfully so.
> C or pascal pointer orgies would resemble high-level internal
> representation of lists in contrast to the list abstraction.
> compare a => b => c => nil to (a b c).
> simple? hmm. powerful, yes. consistent and perspicuous?
So you would be happy to write your C programs by stitching together
strings representing code vectors with pointers? I could not do that,
although I've written a lot of C.
> well... that's getting esoteric. every language has its own consistent
> and perspicuous representation.
not so. The representation
int plus( int a, int b)
{
return a + b;
}
looks superficially very like the representation
typedef struct treeVal
{
struct treeVal * next;
struct dTNode * node;
int depth;
}treeVal;
but the structures they build in C are entirely different. The
representation is inconsistent, because it re-uses syntactic forms in
different contexts to mean things
> and with tagged data it is completely the opposite of direct
> representations. ever wrote lisp<-><other memory> converters?
> only typed structures and typed vector would deserve that name.
Indeed I have, for Portable Standard LISP with mark-and-sweep garbage
collection, in multi-tasking environments where GC could happen during
the copy. Yes, it can get interesting - but that's because the way
LISP and C organise structures in memory are very different.
> The points with lisp are other's, that you can easily abstract lists,
> nested lists and more. And having a language which is defined in exactly
> the same simple way. blabla...
Isn't that *exactly* what I said?
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
; ... of course nothing said here will be taken notice of by
; the W3C. The official place to be ignored is on www-style or
; www-html. -- George Lund
From: Reini Urban
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39663498.459791415@news>
Simon,
This gets into hair-splitting, because both of use understand the
strengths and weaknesses of both worlds.
I just wanted to clear out some common misinterpretations, esp. with
GOOD and BAD representations in the "machine" and on the contrary in the
"program". Your term "memory" was meant by you as "program memory" and
by me as "machine memory". Same with "core" below.
To make my point:
lisp as well as a program needs "bounding" markers and "linking"
delimiters.
(a b c)
raw machine memory needs just pointers and offsets. with lists that is
a starting pointer, linking pointers and an ending sentinel.
a => b => c
with programs the same, only linking can be omitted, only when needed
explicitly by jump instructions. in core you won't need boundaries and
delimiters as in lisp. their point.
In some possible interpretation you could argue that the latter syntax
is easier, in another the former. easier is the latter ("you need no
markers around"), but better the former, because it allows nesting
without structs.
Simon Brooke wrote:
>······@sbox.tu-graz.ac.at (Reini Urban) writes:
>
>> Compliments only to features which deserve them. Here I found a couple
>> of misinterpretations, so I list some "problems" which might be anchors
>> for people from outside:
>>
>> Simon Brooke wrote:
>> >Well, then, look again. LISP syntax results from the fact that LISP as
>> >printed is a very nearly direct representation of the structures that
>> >are created in the machine as it is read.
s/machine/program
then it would be okay for me.
>> a lisp (READ) is a much more complicated then a C read().
>> a lisp (PRINT) is much more complicated then a C write().
>
>Did I say they weren't? Wherein is the contradiction?
misinterpretation. when I associate machine with raw memory it's a
contradiction but when associated with "program" I accept your words.
daniel got it also. you may mean also compiled/interpreted code with the
"structures" as in the next chapter, so it's perfectly okay then.
I only want to fall back into the C/C++ minds from time to time, our
terms used here mean almost nothing to them.
>> >The representation of LISP structures which you conventionally edit in
>> >a file has a uniquely direct and simple mapping onto the
>> >representation which is held in core - a representation much more
>> >direct, much more consistent and much more perspicuous than in any
>> >other high-level language in common use.
>>
>> doubt the first. exactly the opposite,
>
>If you believe this, you have never written a structure editor. Write
>one; you will find it very instructive.
done. and I do it even with dynamic foreign data. horrible to do it in C
or C++, but wonderful in python, perl or lisp.
just the same misinterpretation and again hair-splitting because we are
talking about two different things.
I wouldn't use "core" as the internal program representation. With core
I think of hex dumps in a debugger which has no direct and easy mapping
in lisp, in contrast to unaligned C (just as example).
#pragma pack(1) /* MSVC syntax for byte alignment */
would fit fine to the term "direct" then.
for lisp I would need something like (ffi:malloc ...) for a "direct"
representation. :)
>> thanksfully so.
>> C or pascal pointer orgies would resemble high-level internal
>> representation of lists in contrast to the list abstraction.
>> compare a => b => c => nil to (a b c).
>> simple? hmm. powerful, yes. consistent and perspicuous?
>
>So you would be happy to write your C programs by stitching together
>strings representing code vectors with pointers? I could not do that,
>although I've written a lot of C.
both of us admire lisp's abstraction. we wouldn't do that.
but other folks are also proud of their language abstraction
possibilities (C++ folks excluded probably).
The point is that the "simple" and "fast" argument for mere pointer
traversal (same as CDR, I know) will not die. also the simple and fast
(to write) syntax arguments.
we cannot simply say that our language is "better", "consistent", "more
consistent" and "perspecious" in this regard, because it is relative.
>> well... that's getting esoteric. every language has its own consistent
>> and perspicuous representation.
>
>not so. The representation
>
> int plus( int a, int b)
> {
> return a + b;
> }
>
>looks superficially very like the representation
>
> typedef struct treeVal
> {
> struct treeVal * next;
> struct dTNode * node;
> int depth;
> }treeVal;
>
>but the structures they build in C are entirely different. The
>representation is inconsistent, because it re-uses syntactic forms in
>different contexts to mean things.
worse with parens only. that's a contra lisp argument here.
you have to remember function names and their actions, with C you only
have to remember that "struct" is a struct, () is for arguments, {} is
for blocks. more precise. and more consistent.
different context, different meaning.
>> The points with lisp are other's, that you can easily abstract lists,
>> nested lists and more. And having a language which is defined in exactly
>> the same simple way. blabla...
>
>Isn't that *exactly* what I said?
yes, but non-lispers wouldn't understand it the way you said it.
--
Reini
······@sbox.tu-graz.ac.at (Reini Urban) writes:
> Simon,
>
> This gets into hair-splitting, because both of use understand the
> strengths and weaknesses of both worlds.
Actually, having read your post, I don't think we disagree at all.
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
'graveyards are full of indispensable people'
"Michael T. Richter" <···@ottawa.com> writes:
> That's the first time I've seen someone describe a profusion of parentheses
> as "clean".
Hint: Write down a grammar for Lisp. Write down a grammar for Dylan (or C,
or C++, etc.). Compare their sizes.
HAND,
Jens.
(Oh, and good luck with the C++ grammar ;-)
--
··········@acm.org phone:+49-7031-464-7698 (HP TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
From: Neel Krishnaswami
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <slrn8m2hft.eq8.neelk@brick.cswv.com>
Jens Kilian <···········@agilent.com> wrote:
> "Michael T. Richter" <···@ottawa.com> writes:
> > That's the first time I've seen someone describe a profusion of parentheses
> > as "clean".
>
> Hint: Write down a grammar for Lisp. Write down a grammar for Dylan (or C,
> or C++, etc.). Compare their sizes.
FTR, I disagree with Michael, but your response doesn't have the
answer you apparently think it does: Dylan is the smallest of all of
these -- Dylan plus its special forms is substantially less complex
than Common Lisp and its special forms.
Now to profit maximally from this observation, I recommend comparing
the two with a critical eye, keeping in mind that both languages were
designed by smart and knowledgeable people. I learned a lot from this
very exercise; the two languages are close enough in design space that
their differences reveal a lot about the fine structure of language
design. (Haskell vs. ML is another good pairing. I haven't found
anything to compare Smalltalk to yet, though.)
Neel
Centuries ago, Nostradamus foresaw a time when Neel Krishnaswami would say:
>Jens Kilian <···········@agilent.com> wrote:
>> "Michael T. Richter" <···@ottawa.com> writes:
>> > That's the first time I've seen someone describe a profusion of parentheses
>> > as "clean".
>>
>> Hint: Write down a grammar for Lisp. Write down a grammar for Dylan (or C,
>> or C++, etc.). Compare their sizes.
>
>FTR, I disagree with Michael, but your response doesn't have the
>answer you apparently think it does: Dylan is the smallest of all of
>these -- Dylan plus its special forms is substantially less complex
>than Common Lisp and its special forms.
That's an interesting claim; I suspect that down that road lies some
unfortunately impressive flame wars, to go alongside whatever insights
come up.
>Now to profit maximally from this observation, I recommend comparing
>the two with a critical eye, keeping in mind that both languages were
>designed by smart and knowledgeable people. I learned a lot from this
>very exercise; the two languages are close enough in design space that
>their differences reveal a lot about the fine structure of language
>design. (Haskell vs. ML is another good pairing. I haven't found
>anything to compare Smalltalk to yet, though.)
Unfortunately, "comparative programming languages" tends towards
threads that resemble "capitalism versus communism." While there
are probably some useful insights in such discussions, it is unlikely
that the discussion will remain grounded in any common understandings,
as there are _dramatically_ different attitudes towards them. There
are enough "bigots" out there, whether relating to political systems
or to programming languages, that the discussion is likely to go down
in flames...
--
·····@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/linux.html>
Flashlights are cases for holding dead batteries.
·····@brick.cswv.com (Neel Krishnaswami) writes:
> Jens Kilian <···········@agilent.com> wrote:
> > "Michael T. Richter" <···@ottawa.com> writes:
> > > That's the first time I've seen someone describe a profusion of parentheses
> > > as "clean".
> >
> > Hint: Write down a grammar for Lisp. Write down a grammar for Dylan (or C,
> > or C++, etc.). Compare their sizes.
>
> FTR, I disagree with Michael, but your response doesn't have the
> answer you apparently think it does: Dylan is the smallest of all of
> these -- Dylan plus its special forms is substantially less complex
> than Common Lisp and its special forms.
While that may be, the original poster didn't mention special forms (or macros,
or whatever). His complaint was specifically about parentheses.
Bye,
Jens.
PS: comp.lang.dylan removed from Newsgroups: line.
--
··········@acm.org phone:+49-7031-464-7698 (HP TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
From: David Hanley
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39666FB1.CAAAE5DD@ncgr.org>
Neel Krishnaswami wrote:
> Jens Kilian <···········@agilent.com> wrote:
> > "Michael T. Richter" <···@ottawa.com> writes:
> > > That's the first time I've seen someone describe a profusion of parentheses
> > > as "clean".
> >
> > Hint: Write down a grammar for Lisp. Write down a grammar for Dylan (or C,
> > or C++, etc.). Compare their sizes.
>
> FTR, I disagree with Michael, but your response doesn't have the
> answer you apparently think it does: Dylan is the smallest of all of
> these -- Dylan plus its special forms is substantially less complex
> than Common Lisp and its special forms.
I would disagree that special forms which are amenable to macros
are part of a language's syntax. But that's not a factual thing, but an
opinion.
dave
From: Johan Kullstam
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <m2g0pqal5d.fsf@euler.axel.nom>
"Michael T. Richter" <···@ottawa.com> writes:
> "Johan Kullstam" <········@ne.mediaone.net> wrote in message
> ···················@euler.axel.nom...
> >> Syntax is trivial. Get over it.
>
> > it's not. i like the lisp syntax because of its clean look.
>
> That's the first time I've seen someone describe a profusion of parentheses
> as "clean".
lisp only looks longwinded and confusing on the surface.
gareth mccaughan had an excellent post about this
http://x71.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=578557750&CONTEXT=962663586.1539506178&hitnum=0
the parens take up very little room and don't get in your way. notice
how much more descriptive words lisp allows compared to the required
boilerplate of C/C++. with-open-file only looks long compared to
fopen, but the former does *so much more*.
in general, i find that lisp programs are *much* shorter and more
concise than in other languages. this is least apparent with short
program stumps like in the above post. the gap is very wide once you
program anything of even modest size.
i admit that the boilerplate mishmash of parens, braces and semicolons
can help a human find their way, e.g., i think C's for (;;){} is
easier than lisp's (do ()()()). however, C's semi-random assortment
of statement seperators comes at a very high cost. look how feeble
C's macros are compared to lisp. do not be penny wise and pound
foolish.
imho the simple syntax of lisp is a *huge* advantage for lisp.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: vsync
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <87g0pqvmxe.fsf@piro.quadium.net>
Johan Kullstam <········@ne.mediaone.net> writes:
> http://x71.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=578557750&CONTEXT=962663586.1539506178&hitnum=0
Just FYI, this can be shortened to:
http://www.deja.com/=dnc/getdoc.xp?AN=578557750
--
vsync
http://quadium.net/ - last updated Fri Jun 30 22:55:16 MDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
From: Reini Urban
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <396156a6.140829051@news>
vsync wrote:
>Johan Kullstam <········@ne.mediaone.net> writes:
>> http://x71.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=578557750&CONTEXT=962663586.1539506178&hitnum=0
>
>Just FYI, this can be shortened to:
> http://www.deja.com/=dnc/getdoc.xp?AN=578557750
I'd prefer: http://www.deja.com/=sr/getdoc.xp?AN=578557750&fmt=text
=sr has the threaded format template, =dnc the search stuff below.
(as text format both do the same of course)
--
Reini
In article <··············@piro.quadium.net>, vsync <·····@quadium.net>
wrote:
> Johan Kullstam <········@ne.mediaone.net> writes:
>
> > http://x71.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=578557750&CONTEXT=96266
> > 3586.1539506178&hitnum=0
>
> Just FYI, this can be shortened to:
>
> http://www.deja.com/=dnc/getdoc.xp?AN=578557750
Or, indeed, to:
http://deja.com/=dnc/article/578557750
-- Bruce
From: vsync
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <87bt0evmnj.fsf@piro.quadium.net>
Johan Kullstam <········@ne.mediaone.net> writes:
> the parens take up very little room and don't get in your way. notice
> how much more descriptive words lisp allows compared to the required
> boilerplate of C/C++. with-open-file only looks long compared to
> fopen, but the former does *so much more*.
>
> in general, i find that lisp programs are *much* shorter and more
> concise than in other languages. this is least apparent with short
> program stumps like in the above post. the gap is very wide once you
> program anything of even modest size.
This example is especially good. My main programming language for
some time was (and still is, but not by choice) Java, and although its
exception handling does help localize errors and error checking, I
always hated its verbosity and seeming kludginess. Often, it seemed
like every tenth line was either a try or a catch.
Things such as with-open-file almost frightened me at first; they
seemed too good to be true. And then I needed to use unwind-protect
in some of my own code. Wow. I suspect I haven't even scratched the
surface yet, but Lisp's way of doing things is so much nicer to work
with.
--
vsync
http://quadium.net/ - last updated Fri Jun 30 22:55:16 MDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
Johan Kullstam <········@ne.mediaone.net> schrieb in im Newsbeitrag:
> [...]
> lisp only looks longwinded and confusing on the surface.
>
Well, wjen I started learning Lisp last year I thought than the parentheses
will become a nightmare but now I see that this is not the case. But there
is one example when I still think that infix syntax would be preferable: In
long mathematical formulae:
(/ (+ (- b) (sqrt ( - (* b b) (* 4 (* a c))))) (* 2 a))
ot something like that (I have not checked if the formula is correct) still
looks messy and I wonder if practicing would help. I can see immediately if
the infix form is correct, though.
J.B.
Janos Blazi wrote:
> (/ (+ (- b) (sqrt ( - (* b b) (* 4 (* a c))))) (* 2 a))
>
> ot something like that (I have not checked if the formula is correct) still
> looks messy and I wonder if practicing would help.
(/ (+ (- b)
(sqrt (- (* b b)
(* 4 a c))))
(* 2 a))
What you need is not a pratice, just a decent editor.
abe
--
keke at mac com
From: Raymond Wiker
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <k7mk8f2ti6x.fsf@eto.ericsson.se>
"Janos Blazi" <······@vipsurf.de> writes:
> Johan Kullstam <········@ne.mediaone.net> schrieb in im Newsbeitrag:
>
> > [...]
> > lisp only looks longwinded and confusing on the surface.
> >
>
> Well, wjen I started learning Lisp last year I thought than the parentheses
> will become a nightmare but now I see that this is not the case. But there
> is one example when I still think that infix syntax would be preferable: In
> long mathematical formulae:
>
> (/ (+ (- b) (sqrt ( - (* b b) (* 4 (* a c))))) (* 2 a))
>
> ot something like that (I have not checked if the formula is correct) still
> looks messy and I wonder if practicing would help. I can see immediately if
> the infix form is correct, though.
It helps if you break this up over several lines and indent it
properly:
(/ (+ (- b)
(sqrt ( - (* b b)
(* 4 (* a c)))))
(* 2 a))
--
Raymond Wiker
From: Tim Bradshaw
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <ey3bt0exmag.fsf@cley.com>
* Janos Blazi wrote:
> (/ (+ (- b) (sqrt ( - (* b b) (* 4 (* a c))))) (* 2 a))
> ot something like that (I have not checked if the formula is
> correct) still looks messy and I wonder if practicing would help. I
> can see immediately if the infix form is correct, though.
Mathematical expressions are the only place where I find infix better,
certainly.
--tim
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171713054143887@naggum.net>
* "Janos Blazi" <······@vipsurf.de>
| Well, wjen I started learning Lisp last year I thought than the parentheses
| will become a nightmare but now I see that this is not the case. But there
| is one example when I still think that infix syntax would be preferable: In
| long mathematical formulae:
|
| (/ (+ (- b) (sqrt (- (* b b) (* 4 (* a c))))) (* 2 a))
|
| ot something like that (I have not checked if the formula is correct) still
| looks messy and I wonder if practicing would help. I can see immediately if
| the infix form is correct, though.
Hardcore Lispers know that the syntax of Common Lisp is programmable
and act accordingly. Infix has its merit for very simple arithmetic
and if that is done often enough to be usefully modified, one simply
adds a little convenience to the language. I prefer to use { and }
to bracket infix expressions:
{ (sqrt(b * b - 4 * a * c) - b) / (2 * a)) }
However, note that (* 4 (* a c)) is better written (* 4 a c). Few
infix-oriented people get beyond two-argument arithmetic functions,
but all arithmetic functions take many arguments, and redundancy in
form is A better approach
to the above would thus be
(/ (- (sqrt (- (* b b) (* 4 a c))) b) 2 a)
But note how little infix syntax buys you in this case.
[ The sore freaks in comp.lang.dylan don't need to be reminded that
their language doesn't have a programmable syntax, so followups are
redirected away from the pathetic loser camp. ]
#:Erik
--
If this is not what you expected, please alter your expectations.
From: Immanuel Litzroth
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <8jv0pf$638$1@news.planetinternet.be>
····@naggum.net (Erik Naggum) wrote in <················@naggum.net>:
>* "Janos Blazi" <······@vipsurf.de>
>| Well, wjen I started learning Lisp last year I thought than the
>| parentheses will become a nightmare but now I see that this is not the
>| case. But there is one example when I still think that infix syntax
>| would be preferable: In long mathematical formulae:
>|
>| (/ (+ (- b) (sqrt (- (* b b) (* 4 (* a c))))) (* 2 a))
>|
>| ot something like that (I have not checked if the formula is correct)
>| still looks messy and I wonder if practicing would help. I can see
>| immediately if the infix form is correct, though.
>
> Hardcore Lispers know that the syntax of Common Lisp is programmable
> and act accordingly. Infix has its merit for very simple arithmetic
> and if that is done often enough to be usefully modified, one simply
> adds a little convenience to the language. I prefer to use { and }
> to bracket infix expressions:
>
>{ (sqrt(b * b - 4 * a * c) - b) / (2 * a)) }
>
> However, note that (* 4 (* a c)) is better written (* 4 a c). Few
> infix-oriented people get beyond two-argument arithmetic functions,
> but all arithmetic functions take many arguments, and redundancy in
> form is A better approach
> to the above would thus be
>
>(/ (- (sqrt (- (* b b) (* 4 a c))) b) 2 a)
>
> But note how little infix syntax buys you in this case.
>
>[ The sore freaks in comp.lang.dylan don't need to be reminded that
> their language doesn't have a programmable syntax, so followups are
> redirected away from the pathetic loser camp. ]
>
>#:Erik
I agree and would like to add that the argument only holds for "long
mathematical formulae having only two argument operators that are
predefined in the language". Otherwise you have to write your operators as
prefix function application or start messing about with infix declarations
which may have unknown interactions with other code you are using.
The simple, uniform way in which these mathematical expressions are written
makes them easy to generate or analyze for various mathematical purposes
such as reduction, simplification, optimization etc. Not having to bother
with writing a parser is a timesaver and a parser/pretty-printer can always
be added after the interesting part is finished.
Immanuel
From: Steven M. Haflich
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3964179B.6B05B1C7@pacbell.net>
Immanuel Litzroth wrote:
>
> I agree and would like to add that the argument only holds for "long
> mathematical formulae having only two argument operators that are
> predefined in the language". Otherwise you have to write your operators as
> prefix function application or start messing about with infix declarations
> which may have unknown interactions with other code you are using.
>
> The simple, uniform way in which these mathematical expressions are written
> makes them easy to generate or analyze for various mathematical purposes
> such as reduction, simplification, optimization etc. Not having to bother
> with writing a parser is a timesaver and a parser/pretty-printer can always
> be added after the interesting part is finished.
As I age I find less and less use for mathematical formulae. But I also
find less and less use for basic arithmetic, so perhaps my needs aren't
particularly important. Nonetheless. I do have a slightly-modified version
of the infix package taken from the CMU Lisp repository. It is modified in minor top-level ways necessary to preserve portablility in face of certain
clarifications in the ANS; the interesting parts of the code remain
unmodified. I've checked that it works in Allegro (although it could
still benefit from integration with the excl:named-readtable facility)
and _ought_ to work in other implementations.
Please observe the original copyright notices, but otherwise take it with my
blessings. You can download this version of the file from
<http://www.franz.com/~smh/infix.cl>
;;; Written by Mark Kantrowitz, CMU School of Computer Science.
;;; Copyright (c) 1993-95. All rights reserved.
;;; May be freely redistributed, provided this notice is left intact.
;;; This software is made available AS IS, without any warranty.
Here are some examples of what it does:
USER(7): '#i" sin (2*pi*cosh(atan foo^^3)) "
(SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
USER(8): '#i" sin(2*pi*cosh(atan foo^^3)) "
(SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
USER(9): '#i" 1 + x * y ^^ 3 "
(+ 1 (* X (EXPT Y 3)))
USER(10): '#i"x+y+1"
(+ X Y 1)
USER(11): '#i"x=y+1"
(SETQ X (+ Y 1))
Enjoy!
From: Steven M. Haflich
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3964AF1C.84F9E36@pacbell.net>
"Steven M. Haflich" wrote:
> ... (although it could
> still benefit from integration with the excl:named-readtable facility)
I just added this, and also added a Change Log entry to the source.
Feel free ...
From: Rob Warnock
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <8k3686$2gsgr$1@fido.engr.sgi.com>
Steven M. Haflich <···@alum.mit.edu> wrote:
+---------------
| <http://www.franz.com/~smh/infix.cl>
...
| Here are some examples of what it does:
|
| USER(7): '#i" sin (2*pi*cosh(atan foo^^3)) "
| (SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
| USER(8): '#i" sin(2*pi*cosh(atan foo^^3)) "
| (SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
+---------------
Uh... Isn't there a bug here? Shouldn't both of those results have
been this instead?!? +-----------------+
| |
(SIN (* 2 PI (COSH (ATAN (EXPT FOO 3)))))
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171918535420486@naggum.net>
* Rob Warnock
| Uh... Isn't there a bug here?
From infix to prefix, with a fix! It doesn't get better than this.
#:Erik
--
If this is not what you expected, please alter your expectations.
On 6 Jul 2000 23:54:46 GMT, Rob Warnock <····@rigden.engr.sgi.com> wrote:
> Steven M. Haflich <···@alum.mit.edu> wrote:
> +---------------
> | <http://www.franz.com/~smh/infix.cl>
> ...
> | Here are some examples of what it does:
> |
> | USER(7): '#i" sin (2*pi*cosh(atan foo^^3)) "
> | (SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
> | USER(8): '#i" sin(2*pi*cosh(atan foo^^3)) "
> | (SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
> +---------------
>
> Uh... Isn't there a bug here? Shouldn't both of those results have
> been this instead?!? +-----------------+
> | |
> (SIN (* 2 PI (COSH (ATAN (EXPT FOO 3)))))
The bug appears to be in the infix input. Look at the use of `atan' in the
input.
--
Take a look in Hagbard's World: | boxquote.el - "Boxed" text quoting.
http://www.hagbard.demon.co.uk/ | sawfish.el - Sawfish mode.
http://www.acemake.com/hagbard/ | uptimes.el - Record emacs uptimes.
emacs software, including.......| quickurl.el - Recall lists of URLs.
From: Rob Warnock
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <8k49il$2kefk$1@fido.engr.sgi.com>
Dave Pearson <·····@davep.org> wrote:
+---------------
| Rob Warnock <····@rigden.engr.sgi.com> wrote:
| > Steven M. Haflich <···@alum.mit.edu> wrote:
| > +---------------
| > | USER(7): '#i" sin (2*pi*cosh(atan foo^^3)) "
| > | (SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
| > +---------------
| >
| > Uh... Isn't there a bug here? Shouldn't both of those results have
| > been this instead?!? +-----------------+
| > | |
| > (SIN (* 2 PI (COSH (ATAN (EXPT FOO 3)))))
|
| The bug appears to be in the infix input. Look at the use of `atan' in the
| input.
+---------------
Aha! My apologies! Indeed, thou art correct! My eyes are so used to
reading Lisp prefix forms that I skipped right over the input bug!
Should be this, yes? +------+
| |
'#i" sin(2*pi*cosh(atan(foo^^3))) "
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
From: Reini Urban
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39663ea7.462366918@news>
Dave Pearson wrote:
>On 6 Jul 2000 23:54:46 GMT, Rob Warnock <····@rigden.engr.sgi.com> wrote:
>> Steven M. Haflich <···@alum.mit.edu> wrote:
>> +---------------
>> | <http://www.franz.com/~smh/infix.cl>
>> ...
>> | Here are some examples of what it does:
>> |
>> | USER(7): '#i" sin (2*pi*cosh(atan foo^^3)) "
>> | (SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
>> | USER(8): '#i" sin(2*pi*cosh(atan foo^^3)) "
>> | (SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
>> +---------------
>>
>> Uh... Isn't there a bug here? Shouldn't both of those results have
>> been this instead?!? +-----------------+
>> | |
>> (SIN (* 2 PI (COSH (ATAN (EXPT FOO 3)))))
>
>The bug appears to be in the infix input. Look at the use of `atan' in the
>input.
no. ^^ binds before atan. hairy precedence rules, badly implemented.
that's why prefix or better "explicit precedence" is better than
implicit precedence. otherwise we can use a parenless lisp (like ROBOL),
omit all parens and force indentation on ambiguities.
sin * 2 pi cosh atan exp foo 3 ; is ambiguous
=> sin * 2 pi cosh
atan exp foo 3 ; when exp is unary
but then you can also use your HP calculator or do forth instead, being
forced to use your brain to set the syntactic delimiters correctly.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
On Fri, 07 Jul 2000 20:40:49 GMT, Reini Urban <······@sbox.tu-graz.ac.at> wrote:
> Dave Pearson wrote:
>
> >On 6 Jul 2000 23:54:46 GMT, Rob Warnock <····@rigden.engr.sgi.com> wrote:
>
> >> | USER(7): '#i" sin (2*pi*cosh(atan foo^^3)) "
> >> | (SIN (* 2 PI (COSH ATAN (EXPT FOO 3))))
> >>
> >> Uh... Isn't there a bug here? Shouldn't both of those results have
> >> been this instead?!? +-----------------+
> >> | |
> >> (SIN (* 2 PI (COSH (ATAN (EXPT FOO 3)))))
> >
> >The bug appears to be in the infix input. Look at the use of `atan' in the
> >input.
>
> no. ^^ binds before atan. hairy precedence rules, badly implemented.
Perhaps, but there was a bug in the infix input regarding atan. It was:
,----
| atan foo^^3
`----
when it should have been:
,----
| atan(foo^^3)
`----
--
Take a look in Hagbard's World: | boxquote.el - "Boxed" text quoting.
http://www.hagbard.demon.co.uk/ | sawfish.el - Sawfish mode.
http://www.acemake.com/hagbard/ | uptimes.el - Record emacs uptimes.
emacs software, including.......| quickurl.el - Recall lists of URLs.
From: Janos Blazi
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <396321a8_2@goliath.newsfeeds.com>
Immanuel Litzroth <·················@hotmail.com> schrieb in im Newsbeitrag:
············@news.planetinternet.be...
> ····@naggum.net (Erik Naggum) wrote in <················@naggum.net>:
>
> >* "Janos Blazi" <······@vipsurf.de>
> >| Well, wjen I started learning Lisp last year I thought than the
> >| parentheses will become a nightmare but now I see that this is not the
> >| case. But there is one example when I still think that infix syntax
> >| would be preferable: In long mathematical formulae:
> >|
> >| (/ (+ (- b) (sqrt (- (* b b) (* 4 (* a c))))) (* 2 a))
> >|
> >| ot something like that (I have not checked if the formula is correct)
> >| still looks messy and I wonder if practicing would help. I can see
> >| immediately if the infix form is correct, though.
> >
> > Hardcore Lispers know that the syntax of Common Lisp is programmable
> > and act accordingly. Infix has its merit for very simple arithmetic
> > and if that is done often enough to be usefully modified, one simply
> > adds a little convenience to the language. I prefer to use { and }
> > to bracket infix expressions:
> >
> >{ (sqrt(b * b - 4 * a * c) - b) / (2 * a)) }
> >
> > However, note that (* 4 (* a c)) is better written (* 4 a c). Few
> > infix-oriented people get beyond two-argument arithmetic functions,
> > but all arithmetic functions take many arguments, and redundancy in
> > form is A better approach
> > to the above would thus be
> >
> >(/ (- (sqrt (- (* b b) (* 4 a c))) b) 2 a)
> >
> > But note how little infix syntax buys you in this case.
> >
> >[ The sore freaks in comp.lang.dylan don't need to be reminded that
> > their language doesn't have a programmable syntax, so followups are
> > redirected away from the pathetic loser camp. ]
> >
> >#:Erik
>
> I agree and would like to add that the argument only holds for "long
> mathematical formulae having only two argument operators that are
> predefined in the language". Otherwise you have to write your operators as
> prefix function application or start messing about with infix declarations
> which may have unknown interactions with other code you are using.
>
> The simple, uniform way in which these mathematical expressions are
written
> makes them easy to generate or analyze for various mathematical purposes
> such as reduction, simplification, optimization etc. Not having to bother
> with writing a parser is a timesaver and a parser/pretty-printer can
always
> be added after the interesting part is finished.
> Immanuel
> .
To Erik and Immanual:
You are of course (again) right. (This is not surprising as this is a purely
technical matter.)
I simply did not think of writing (* 4 a c). It seems that learning
'thinking the prefix way' takes time.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Hartmann Schaffer
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3963e446@news.sentex.net>
In article <··········@goliath.newsfeeds.com>,
"Janos Blazi" <······@netsurf.de> writes:
>
> ...
>> >| (/ (+ (- b) (sqrt (- (* b b) (* 4 (* a c))))) (* 2 a))
> ...
>> >
>> >(/ (- (sqrt (- (* b b) (* 4 a c))) b) 2 a)
>> >
> ...
> I simply did not think of writing (* 4 a c). It seems that learning
> 'thinking the prefix way' takes time.
sorry, this has nothing to do with prefix notation: the reason why
you can do it is that in lisp all expressions are delimited by being
surrounded by parantheses. without that you still would need fixadic
operators to parse expressions.
--
Hartmann Schaffer
From: Hannah Schroeter
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <8jt7ta$52c$1@c3po.schlund.de>
Hello!
In article <············@spamkiller.newsfeeds.com>,
Janos Blazi <······@vipsurf.de> wrote:
>(/ (+ (- b) (sqrt ( - (* b b) (* 4 (* a c))))) (* 2 a))
Besides from changing reader syntax:
(let*
((discriminant (- (* b b) (* 4 a c)))
(numerator (- (sqrt discriminant) b))
(denominator (* 2 a)))
(/ numerator denominator))
>[...]
Regards, Hannah.
>> That's the first time I've seen someone describe a profusion of
>> parentheses as "clean".
> lisp only looks longwinded and confusing on the surface.
If something looks confusing, it likely is.
> i admit that the boilerplate mishmash of parens, braces and semicolons
> can help a human find their way, e.g., i think C's for (;;){} is
> easier than lisp's (do ()()()).
Yes. Finally I've met someone in the Lisp camp who recognizes this feature.
> however, C's semi-random assortment
> of statement seperators comes at a very high cost. look how feeble
> C's macros are compared to lisp. do not be penny wise and pound
> foolish.
Why is it that when I criticise Lisp's profusion of parentheses, the Lispers
always assume that this is a defense of C/C++?
Look at the newsgroups above. Point me to where it says "comp.lang.c" or
"comp.lang.c++".
> imho the simple syntax of lisp is a *huge* advantage for lisp.
If unreadability is supposed to be an advantage, I guess I'm all for it.
From: Hartmann Schaffer
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39628640@news.sentex.net>
In article <······················@news1.rdc1.on.wave.home.com>,
"Michael T. Richter" <···@ottawa.com> writes:
>>> That's the first time I've seen someone describe a profusion of
>>> parentheses as "clean".
>
>> lisp only looks longwinded and confusing on the surface.
>
> If something looks confusing, it likely is.
everything looks confusing to the uninitiated. mathematical notation
is an excellent example, but after having learned a little bit about
it, most people prefer it over the alternatives. imo the same applies
to lisp
> ...
>> imho the simple syntax of lisp is a *huge* advantage for lisp.
>
> If unreadability is supposed to be an advantage, I guess I'm all for it.
see above
--
Hartmann Schaffer
"Hartmann Schaffer" <··@inferno.nirvananet> wrote in message
·············@news.sentex.net...
>>> lisp only looks longwinded and confusing on the surface.
>> If something looks confusing, it likely is.
> everything looks confusing to the uninitiated. mathematical notation
> is an excellent example, but after having learned a little bit about
> it, most people prefer it over the alternatives. imo the same applies
> to lisp
But you're *DEALING* with someone who learned a bit about it. Indeed you're
dealing with someone who learned a bit about Lisp (and work-alikes) before
he learned about C. And rejected Lisp. Several times. I've attempted to
add Lisp and its work-alikes to my tool belt several times. Each time I
wind up with a nearly perl-like tendency toward having code I've written
become unreadable six weeks later.
>> If unreadability is supposed to be an advantage, I guess I'm all for it.
> see above
See above.
I think one of the most annoying traits of Lispers is that you all seem to
think that people who don't like Lisp are merely ignorant of all of its
advantages. I'm not. I know what kinds of powerful things Lisp provides.
I know how useful those things are. But all this utility comes at a cost:
the language is horrid to read and tends to turn into write-only code with
little effort -- for me, at any rate. No amount of your wildly flapping
your arms and telling me that I'll "get it" with only a bit of effort will
change the fact that after SEVERAL YEARS of on-again-off-again attempts to
learn the language, I *STILL* despise it as an unreadable mess.
Is that clear?
In comp.lang.lisp Michael T. Richter <···@ottawa.com> wrote:
> I think one of the most annoying traits of Lispers is that you all seem to
> think that people who don't like Lisp are merely ignorant of all of its
> advantages. I'm not. I know what kinds of powerful things Lisp provides.
> I know how useful those things are. But all this utility comes at a cost:
> the language is horrid to read and tends to turn into write-only code with
> little effort -- for me, at any rate. No amount of your wildly flapping
> your arms and telling me that I'll "get it" with only a bit of effort will
> change the fact that after SEVERAL YEARS of on-again-off-again attempts to
> learn the language, I *STILL* despise it as an unreadable mess.
>
> Is that clear?
Sure. In other words you insist on blaiming *Lisp* for *your*
inability to use it. You don't like the language - fine. I don't
think anyone will blaim *you* for that, but than make us a favor and
don't come here spreading FUD about Lisp. Ok?
SY, Uwe
--
···@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
On 5 Jul 2000 14:12:11 GMT, Valeriy E. Ushakov <···@ptc.spbu.ru> wrote:
>In comp.lang.lisp Michael T. Richter <···@ottawa.com> wrote:
>
>> I think one of the most annoying traits of Lispers is that you all seem to
>> think that people who don't like Lisp are merely ignorant of all of its
>> advantages. I'm not. I know what kinds of powerful things Lisp provides.
>> I know how useful those things are. But all this utility comes at a cost:
>> the language is horrid to read and tends to turn into write-only code with
>> little effort -- for me, at any rate. No amount of your wildly flapping
>> your arms and telling me that I'll "get it" with only a bit of effort will
>> change the fact that after SEVERAL YEARS of on-again-off-again attempts to
>> learn the language, I *STILL* despise it as an unreadable mess.
>>
>> Is that clear?
>
>Sure. In other words you insist on blaiming *Lisp* for *your*
>inability to use it. You don't like the language - fine. I don't
>think anyone will blaim *you* for that, but than make us a favor and
>don't come here spreading FUD about Lisp. Ok?
Everybody has their own preferences and there isn't anything wrong with
discussing them. I haven't worked on a project in Lisp of the size
necessary to make this kind of assessment and I appreciate Michael
Richter sharing his assessment with the group. This *isn't* an advocacy
group although it sounds like one on occasion. I feel the same way
about PERL that this poster feels about Lisp and there certainly isn't
anything wrong with my stating this.
Thank you for your assessment, Michael.
Rather that berating him for what he has posted why don't those of you
with contradictory experiences discuss how this can be prevented...
coding practices that are used by you or the people aroud you to keep
code maintainable?
--
Kenneth P. Turvey <······@SprocketShop.com>
http://www.tranquility.net/~kturvey/resume/resume.html
--------------------------------------------------------
If you pick up a starving dog and make him prosperous, he will not
bite you. This is the principal difference between a man and a dog.
-- Mark Twain
Kenneth P. Turvey <······@sprocketshop.com> wrote:
> > Sure. In other words you insist on blaiming *Lisp* for *your*
> > inability to use it. You don't like the language - fine. I don't
> > think anyone will blaim *you* for that, but than make us a favor and
> > don't come here spreading FUD about Lisp. Ok?
>
> Everybody has their own preferences and there isn't anything wrong
> with discussing them.
The key word being "discussing". Making generalized statements that
Lisp is unreadable and the like is not a good way to start a
constructive discussion, is it?
> Rather that berating him for what he has posted why don't those of
> you with contradictory experiences discuss how this can be
> prevented... coding practices that are used by you or the people
> aroud you to keep code maintainable?
In Russian there's an idiomatic expression "proving that you are not a
camel". I don't appreciate it when people make bold claims without a
slightest indication that they would like to discuss things and that
they would care to learn something from the discussion. Responding to
such bold generalized claims is like proving that you're not a camel,
as the saying goes.
I maintain (shameless plug) a mailing list for the Lout batch document
formatter and I handle almost all requests for help on the list (since
the user base is extremely small and I'd rather let the Lout author do
the further development). I appreciate it very much when people that
ask questions follow this pattern:
. I want to accomplish this and this
. I'm doing this and this
. I have the following problems with my approach
. How should I proceed?
It's a pleasure to answer this sort of requests as I know that the
person does care and that he will learn from the advice.
While some of the burned readers of this newsgroup picture Erik as a
napalm-death flamer, look how he responds to constructive questions
like that, no matter how seemingly trivial. You might be surprised
how attitude matters.
SY, Uwe
--
···@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
On 5 Jul 2000 23:24:35 GMT, Valeriy E. Ushakov <···@ptc.spbu.ru> wrote:
>
>In Russian there's an idiomatic expression "proving that you are not a
>camel". I don't appreciate it when people make bold claims without a
>slightest indication that they would like to discuss things and that
>they would care to learn something from the discussion. Responding to
>such bold generalized claims is like proving that you're not a camel,
>as the saying goes.
[snip]
I understand what you are saying, but I didn't take the original posters
statements this way.
--
Kenneth P. Turvey <······@SprocketShop.com>
http://www.tranquility.net/~kturvey/resume/resume.html
--------------------------------------------------------
Careful attention to small detail, often proves superior to genius.
-- Cicero
In article <·····················@pug1.sprocketshop.com>,
······@SprocketShop.com (Kenneth P. Turvey) writes:
> ...O
>>Sure. In other words you insist on blaiming *Lisp* for *your*
>>inability to use it. You don't like the language - fine. I don't
>>think anyone will blaim *you* for that, but than make us a favor and
>>don't come here spreading FUD about Lisp. Ok?
>
> Everybody has their own preferences and there isn't anything wrong with
> discussing them. I haven't worked on a project in Lisp of the size
> necessary to make this kind of assessment and I appreciate Michael
> Richter sharing his assessment with the group. This *isn't* an advocacy
> group although it sounds like one on occasion. I feel the same way
> about PERL that this poster feels about Lisp and there certainly isn't
> anything wrong with my stating this.
but would you go into comp.lang.perl (or a subgroup thereof) with the
single statement "Perl is crap"?
> Thank you for your assessment, Michael.
>
> Rather that berating him for what he has posted why don't those of you
would you kindly point out what part of my post was "berating him"?
> with contradictory experiences discuss how this can be prevented...
> coding practices that are used by you or the people aroud you to keep
> code maintainable?
>
--
Hartmann Schaffer
Hartmann Schaffer wrote:
>but would you go into comp.lang.perl (or a subgroup thereof) with the
>single statement "Perl is crap"?
sure! polemics are always enlightning.
especially if you can give some good arguments lateron. (which is easy
with perl)
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
On 5 Jul 2000 21:36:18 -0400, Hartmann Schaffer <··@inferno.nirvananet> wrote:
>In article <·····················@pug1.sprocketshop.com>,
> ······@SprocketShop.com (Kenneth P. Turvey) writes:
>> Everybody has their own preferences and there isn't anything wrong with
>> discussing them. I haven't worked on a project in Lisp of the size
>> necessary to make this kind of assessment and I appreciate Michael
>> Richter sharing his assessment with the group. This *isn't* an advocacy
>> group although it sounds like one on occasion. I feel the same way
>> about PERL that this poster feels about Lisp and there certainly isn't
>> anything wrong with my stating this.
>
>but would you go into comp.lang.perl (or a subgroup thereof) with the
>single statement "Perl is crap"?
He said much more than "Lisp is crap". He indicated why he felt this
way about Lisp. It sounded like a plea for advice although it wasn't
worded that way. He had tried unsuccessfully to apply lisp to the
problems he had and was airing his frustrations. If all you heard was,
"Lisp is crap", you weren't listening.
>> Thank you for your assessment, Michael.
>>
>> Rather that berating him for what he has posted why don't those of you
>
>would you kindly point out what part of my post was "berating him"?
I'm not going to get into this argument.
--
Kenneth P. Turvey <······@SprocketShop.com>
http://www.tranquility.net/~kturvey/resume/resume.html
--------------------------------------------------------
Careful attention to small detail, often proves superior to genius.
-- Cicero
* Kenneth P Turvey wrote:
> I feel the same way
> about PERL that this poster feels about Lisp and there certainly isn't
> anything wrong with my stating this.
It depends on how you state it. If you started the conversation with
a followup to another post praising perl's syntax, in a perl newsgroup
with:
That's the first time I've seen someone describe a profusion
of non-alphabetic characters as "clean".
You might expect a bad reaction. You'd probably get one.
Stating an opinion is one thing, polemic is another.
--tim
From: Joe Marshall
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <lmzglkqf.fsf@alum.mit.edu>
"Michael T. Richter" <···@ottawa.com> writes:
> I think one of the most annoying traits of Lispers is that you all seem to
> think that people who don't like Lisp are merely ignorant of all of its
> advantages. I'm not.
You're not *merely* ignorant? Ok.
> No amount of your wildly flapping your arms and telling me that I'll
> "get it" with only a bit of effort will change the fact that after
> SEVERAL YEARS of on-again-off-again attempts to learn the language,
> I *STILL* despise it as an unreadable mess.
I suppose some people still won't `get it', even after `several years'
of attempting to. Good thing there is a such a high demand for Java
programmers.
From: Duane Rettig
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <4lmzgr48f.fsf@beta.franz.com>
"Michael T. Richter" <···@ottawa.com> writes:
> I think one of the most annoying traits of Lispers is that you all seem to
> think that people who don't like Lisp are merely ignorant of all of its
> advantages. I'm not. I know what kinds of powerful things Lisp provides.
> I know how useful those things are. But all this utility comes at a cost:
> the language is horrid to read and tends to turn into write-only code with
> little effort -- for me, at any rate. No amount of your wildly flapping
> your arms and telling me that I'll "get it" with only a bit of effort will
> change the fact that after SEVERAL YEARS of on-again-off-again attempts to
> learn the language, I *STILL* despise it as an unreadable mess.
> Is that clear?
No. You seem to be saying that you dislike Lisp, but I'm hearing in much
louder tones that you are complaining about not being able to write good
lisp code.
Compare writing and reading Lisp code to playing and enjoying a musical
instrument. There is a difference between playing the instrument
(producing possibly different styles of music) and listening to someone
play that instrument. You may or may not like the sound of the instrument,
and you may or may not like the style of music being played. But consider
for example that if you pick up a trumpet for the first time, I guarantee that
you will sound horrible; the tone is raspy, the intonation is sharp or
flat, and the attack is non-existent. I also guarantee that you (and others)
will not like the sound that comes out. And you may even improve yourself
somewhat by practicing playing for years, but if you have learned any bad
habits in forming the sounds, it is very hard to unlearn those habits and
your trumpet playing will still sound bad to you and others. However,
it would be wrong to say that the trumpet is a raspy, out-of-tune
instrument that you could never like. It is not the trumpet's fault.
The trumpet can sound sweet and clear, and masters can melt people's
hearts with their playing. Still, not every one like the sound of the
trumpet, but usually the issue is not with the trumpet itself, but with
the player.
What does one do in such a situation? One seeks the tutelage of a master,
who can point out your bad habits and help you to progress. How bad must
you be before seeking tutelage? Not bad at all; even master musicians ask
other masters to give them a lesson or two.
If you can make the connection to Lisp in the above paragraphs, and agree
with it, then you are ready for the next step. Post some of your code.
Make it your most unreadable code. Then ask us what makes the code
unreadable, and you will get some answers. And if you don't like the
idea of posting publically, then choose someone you believe can help you
and ask that person, if he is willing (this falls in line more closely
to the musical example, because most of the more successful lessons
tend to be private).
Good luck in your efforts to add Lisp to your tool-belt.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
"Michael T. Richter" <···@ottawa.com> writes:
> "Hartmann Schaffer" <··@inferno.nirvananet> wrote in message
> ·············@news.sentex.net...
> >>> lisp only looks longwinded and confusing on the surface.
>
> >> If something looks confusing, it likely is.
>
> > everything looks confusing to the uninitiated. mathematical notation
> > is an excellent example, but after having learned a little bit about
> > it, most people prefer it over the alternatives. imo the same applies
> > to lisp
>
> But you're *DEALING* with someone who learned a bit about it. Indeed you're
> dealing with someone who learned a bit about Lisp (and work-alikes) before
> he learned about C. And rejected Lisp. Several times. I've attempted to
> add Lisp and its work-alikes to my tool belt several times. Each time I
> wind up with a nearly perl-like tendency toward having code I've written
> become unreadable six weeks later.
If it isn't for you, it isn't for you. Just because it isn't for you
doesn't mean it isn't for everyone. Different people think in
different ways, and use different mental models and tools to help
their understanding. There's no shame in finding one toolkit better
*for* *you* than another, and equally just because a particular
toolkit doesn't suit your way of thinking doesn't mean it isn't any
good.
But if LISP isn't for you, don't keep banging your head on a brick
wall. It's only one of a large number of turing-equivalent
languages. What can be expressed in one can be expressed in the
others. Choose one whose expression works for you.
> I *STILL* despise it as an unreadable mess.
Despising things[1] is rarely wise.
Simon
[1] Except PERL, of course.
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
; ... of course nothing said here will be taken notice of by
; the W3C. The official place to be ignored is on www-style or
; www-html. -- George Lund
Simon Brooke <·····@jasmine.org.uk> writes:
> Despising things[1] is rarely wise.
>
> Simon
>
> [1] Except PERL, of course.
I keep hearing this on comp.lang.lisp. Basically, many of you guys
despise Perl. I have a strong feeling it is its ambiguous syntax that
makes it hard for some to grasp, and probably discourages people from
pursuing it as a viable option for many problems. I'd like to encourage
people who have not (yet) made this assessment that Perl is not too bad,
and can be pretty easy and fun, and powerful too.
First off, Perl, like Lisp, is GC'd, has no pointers, has an object
system (much simpler than CLOS, of course), and some other features that
are Lispy in some way.
I don't enjoy coding in Perl like I do CL, but it's still kinda fun. I
have trouble expressing myself in the language. But what makes it
really nice is that the modules are so numerous, and I've seldom had a
problem for which there wasn't a module on CPAN (www.cpan.org) that
didn't make the problem easy. Many low-level things are easy to do with
Perl. It's a hacking language, and so I don't think that one should be
using it for the same types of problems that they use CL for, for the
most part. But for what I use it for, it's a life-saver, and I'd really
like to see how CL programmers could manage some of the things I've done
and seen done in Perl.
Also, there are ways to write Perl so that it's very readable. the $_
stuff is not necessary. One can eliminate the bulk of different ways to
code the same thing and pick the one which is most readable. Also,
writing OO modules is easy too.
If you can use CL, then definitely do so. But consider that Perl really
is free, has a lot of support, a great selection of modules, works
across Unix and Win32 platforms, and has tons of written code, samples,
scripts, libraries, and modules. It's not the bad thing people seem to
think it is. True that reading crappy code is excessively hard, but
what *isn't* hard to read if not well-written?
If Perl rubbed you wrong the first time, then I'd say it's worth trying
it again. At least for scripting.
dave
David Bakhash <·····@alum.mit.edu> writes:
> Simon Brooke <·····@jasmine.org.uk> writes:
>
> > Despising things[1] is rarely wise.
> >
> > Simon
> >
> > [1] Except PERL, of course.
>
> I keep hearing this on comp.lang.lisp. Basically, many of you guys
> despise Perl.
Look
(i) it was a joke.
(ii) people who like languages with rigorous formalism aren't going to
like bags of cool hacks and vice versa.
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
; ... of course nothing said here will be taken notice of by
; the W3C. The official place to be ignored is on www-style or
; www-html. -- George Lund
In article <··············@gododdin.internal.jasmine.org.uk>, Simon
Brooke <·····@jasmine.org.uk> wrote:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > Simon Brooke <·····@jasmine.org.uk> writes:
> >
> > > Despising things[1] is rarely wise.
> > >
> > > Simon
> > >
> > > [1] Except PERL, of course.
> >
> > I keep hearing this on comp.lang.lisp. Basically, many of you guys
> > despise Perl.
>
> Look
>
> (i) it was a joke.
Fair enough.
> (ii) people who like languages with rigorous formalism aren't going to
> like bags of cool hacks and vice versa.
Um. Why?
I like Scheme and I like Perl as well. Scheme has far too little syntax
while Perl has far too much and too wierd (at the lexical level, at any
rate), but both let you get your work done and they are surprisingly
similar at the inner language level. Dylan with a resource like CPAN
would be better than either and it has (for me, maybe not for you) about
the right amount of syntax.
-- Bruce
From: David Bakhash
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <c294s5tn0dl.fsf@nerd-xing.mit.edu>
Simon Brooke <·····@jasmine.org.uk> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > Simon Brooke <·····@jasmine.org.uk> writes:
> >
> > > Despising things[1] is rarely wise.
> > >
> > > Simon
> > >
> > > [1] Except PERL, of course.
> >
> > I keep hearing this on comp.lang.lisp. Basically, many of you guys
> > despise Perl.
>
> Look
>
> (i) it was a joke.
well, jokes don't really make much sense here. First off, it's hard to
tell that you were kidding. Try to realize that it's straight text
we're reading. There's no change in tone, or facial expression, or
inflection to determine what's a joke and what's not -- especially with
no help from you (e.g. a smiley-face, "jk", etc.). If it's your true
opinion, then fine.
again, it's just flame bait crap, throwing around random opinions
without justification. I don't care too much for Perl, but what you
are essentially doing is slandering a programming language that has its
pros and cons, just like anything else, but really without
justification. And since you and several others do it, it amounts to
people prematurely deciding that Perl (or whatever else) is no good, and
when they need to solve a problem that Perl might be the right thing
for, they'll overlook or avoid it, based on posts like these.
> (ii) people who like languages with rigorous formalism aren't going to
> like bags of cool hacks and vice versa.
Perl was originally intended as a scripting language. CL really isn't
the ideal scripting language. For about 90% of what mosts "scripts" are
written for, I perform better in Perl than in CL, even though I spend
on the order of 20 times more time in CL than Perl. It's a different
tool that many people have coerced into a general-purpose programming
language. I don't think it's anyone's fault, but there is serious value
in using Perl. I only want to make this clear for those people who
don't know anything about it except what they hear. If you can use CL,
then of course, go for it. But if it's too cumbersome and you suspect
that there's another tool for your task that may help you become more
productive, then Perl may be a viable option.
dave
From: Joe Marshall
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <g0pc1zvj.fsf@alum.mit.edu>
David Bakhash <·····@alum.mit.edu> writes:
> well, jokes don't really make much sense here.
There's a lot that doesn't make much sense here, jokes aren't
special.
> First off, it's hard to tell that you were kidding. Try to realize
> that it's straight text we're reading. There's no change in tone,
> or facial expression, or inflection to determine what's a joke and
> what's not -- especially with no help from you (e.g. a smiley-face,
> "jk", etc.). If it's your true opinion, then fine.
The landscape of the world of literature before smiley faces were
invented must have been truly bleak. Did authors simply eschew irony,
sarcasm, hyperbole, etc, or were there a brave few that would throw
caution to the wind and take the risk that the more gullible of the
population would react with indignation?
> again, it's just flame bait crap, throwing around random opinions
> without justification.
And we can't have *that* on the Usenet!
> I don't care too much for Perl, but what you are essentially doing
> is slandering a programming language that has its pros and cons,
> just like anything else, but really without justification.
I think it would be `libel' actually. And regardless of
justification, it is libel (in the US, at least) only if it actually
damages a reputation and it is false.
> And since you and several others do it, it amounts to people
> prematurely deciding that Perl (or whatever else) is no good, and
> when they need to solve a problem that Perl might be the right thing
> for, they'll overlook or avoid it, based on posts like these.
So make sure, if you read this group, to only pay attention to those
people who denigrate Perl *after* they have examined it. To aid new
users in determining this, I suggest we all note how much Perl
experience we have had in either our signature or as an
`X-Perl-Experience:' header.
Joe Marshall <·········@alum.mit.edu> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > again, it's just flame bait crap, throwing around random opinions
> > without justification.
>
> And we can't have *that* on the Usenet!
Of course we can. the more I think about it, maybe I just don't
tolerate the anti-perl stuff well is that Perl and CL really have
different purposes. It's not like C and C++, where the applications
written there are so often things where CL would be appropriate. Most
developers simply don't write large-scale programs in Perl. Of course,
the same programs written in C (and even CL) _might_ actually be pretty
large.
> > I don't care too much for Perl, but what you are essentially doing
> > is slandering a programming language that has its pros and cons,
> > just like anything else, but really without justification.
>
> I think it would be `libel' actually. And regardless of
> justification, it is libel (in the US, at least) only if it actually
> damages a reputation and it is false.
yes. that's the word I was looking for. I'm not saying that Perl
doesn't suck. I just wish there was some a supporting argument more
than half the time people say things. Of course, if it makes people
feel better about their views to just state their opinions, and through
footnote metahumor, the way Simon Brooke did, then so be it.
> > And since you and several others do it, it amounts to people
> > prematurely deciding that Perl (or whatever else) is no good, and
> > when they need to solve a problem that Perl might be the right thing
> > for, they'll overlook or avoid it, based on posts like these.
>
> So make sure, if you read this group, to only pay attention to those
> people who denigrate Perl *after* they have examined it. To aid new
> users in determining this, I suggest we all note how much Perl
> experience we have had in either our signature or as an
> `X-Perl-Experience:' header.
If you ask me, I think what might actually happen is that:
1) people hear something sucks (e.g. Perl)
2) people check it out, predisposed to believe that it truly does suck
3) people don't give it a fair chance after little inspection
4) more people denigrate it.
that's what's happening here. Just because you probably feel the same
about Perl that Simon feels, and probably many others, you are opposing
my argument. Again, so be it. I'm not asking you to like Perl; I'm
just asking you and others to write thoughtfully. I always thought
writing was something that should be _more_ thoughtful than what we say
out loud. We can't convey expressions easily; we can't determine the
exact extent of our audience, who they are, what they currently know,
etc. I guess, in a nutshell, I'm advocating more thoughtful posts.
dave
David Bakhash <·····@alum.mit.edu> wrote in message
····················@mint-square.mit.edu...
> If you ask me, I think what might actually happen is that:
>
> 1) people hear something sucks (e.g. Perl)
> 2) people check it out, predisposed to believe that it truly does suck
> 3) people don't give it a fair chance after little inspection
> 4) more people denigrate it.
>
hmm...I wonder if that could happen to lisp.....
cb ; )
"Coby Beck" <·····@mercury.bc.ca> writes:
> David Bakhash <·····@alum.mit.edu> wrote in message
> ····················@mint-square.mit.edu...
> > If you ask me, I think what might actually happen is that:
> >
> > 1) people hear something sucks (e.g. Perl)
> > 2) people check it out, predisposed to believe that it truly does suck
> > 3) people don't give it a fair chance after little inspection
> > 4) more people denigrate it.
> >
>
> hmm...I wonder if that could happen to lisp.....
what do you mean, wonder? It happens to Lisp continuously. And since
people group the different Lisp languages, it's even worse for CL. I
know people who think they know CL because they know Scheme (like
undergrads from MIT). They are underestimating the differences.
I have also mentioned the utter stupidity I've seen with people thinking
that CL is not a compiled language, including PhD students in Computer
Science at MIT, who got their BS/MS in Computer Science at CMU. These
same people go around saying that CL sucks every chance they get. And
worst of all, many of these people even skipped step (2).
Does this torque you? It should. If you don't believe it, consider
that one day you might be a contractor, and a potential client will say
"This is what we need you to do for $XXX/hr" and you say "okay. I'll do
it in CL" and then they refuse, and say "Common Lisp won't cut it. It
has to be done in C++. We can't have slow, ugly, unmaintainable code
here." Then how will you feel? Well, I've been there, and so yeah,
this certainly does bother me.
dave
David Bakhash <·····@alum.mit.edu> wrote in message
····················@mint-square.mit.edu...
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > David Bakhash <·····@alum.mit.edu> wrote in message
> > ····················@mint-square.mit.edu...
> > > If you ask me, I think what might actually happen is that:
> > >
> > > 1) people hear something sucks (e.g. Perl)
> > > 2) people check it out, predisposed to believe that it truly does suck
> > > 3) people don't give it a fair chance after little inspection
> > > 4) more people denigrate it.
> > >
> >
> > hmm...I wonder if that could happen to lisp.....
>
> what do you mean, wonder? It happens to Lisp continuously.
Oh, yes, i do know that!! I was being ironic, i assure you :-) When i read
the lines about Perl it just struck me as soOOoo applicable to lisp (and
just about any other out-of-fashion technology or idea or movie or piece of
music or.......)
>
> I have also mentioned the utter stupidity I've seen with people thinking
> that CL is not a compiled language, including PhD students in Computer
> Science at MIT, who got their BS/MS in Computer Science at CMU. These
> same people go around saying that CL sucks every chance they get.
Add to this list people i know who have actually used the language
professionally!!
In my job i work on the lisp portion of a sophisticated, multi-language
system, maintaining c1100 files of CLOS code and leading new development. I
have seen such CRAP in there it makes my head spin!! (to be fair there is a
great deal of excellent work in there to, i suppose this is normal in a
project after four years and various developers coming and going.) Many of
these people came straight from C/C++ and could not grasp the functional
approach AT ALL (for some of the code there is no reasonable excuse). For
example...
(method names have been changed to protect the innocent)
(defmethod my-method ((arg my-class))
(let* ((part-answer (foo arg))
(real-answer nil))
(setf real-answer (fum part-answer))
(return-from my-method real-answer)))
Did the author of this code understand the language? (hint: this is a
rhetoorical question)
There are additionally so many violations of such basic programming
principles, like a 500 line (no joke) long method!!! and one that is 300
and countless 80+ line methods full of cut and paste code (can you say
supporting function? I knew that you could...) And it is code full of side
effects and global variables.
Now lo and behold, the system is buggy and very hard to maintain and i
guarantee many people will now pass on the impression that "lisp is slow and
unreadable"
> Does this torque you? It should.
it does.
But (perhaps out of naive optimism) i think things are getting better.
Coby
From: Link Davis
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <397E6DCF.7CBA299@mindspring.com>
Compared to you guys I'm lower than the lowest newbie.
Part of it's not my fault... I had base case of the big-C,
and I don't mean the language. Most of it is my fault.
Try as I may to "understand what Lisp is all about",
I inevitably fail. It reminds me of trying to learn Russian.
Without someone to converse with it was a lost ambition.
So, too, it seemed, with my desire to learn CLOS...
Until I found a buddy who, after about a year of listening
to the "Lisp is dead" crowd, came to the realization that
he loves CLOS and doesn't care what anyone else says.
He is in a position to not care. Myself, I am faced with
the advent of Visual Studio 7 and the constant pressure
of the big, ignorant, argument: "We don't want to develop
anything we can't reuse." ... ... ...
It seems to me that the only defense for CLOS is a good
offense. It is often said that CLOS vs C++ is much faster,
but where's the proof. In the case of a chain trenching
machine manufacturer the efficiency of his product can be
clearly contrasted with the use of track hoes and blasting.
I'm not sure that can be done with programming simply
because there is such a vast gap between the slightly-
skilled and highly-skilled programmer.
So it all comes down to results. The clients I have had
who knew anything at all about software development
didn't care what language I used because the tools on
disk are less important than the tools in the mind.
I want very much to "know what Lisp is all about", but I
probably never will. That won't stop me from trying.
And the men who tell me Lisp is dead, well, when they
say that it tells me that they have not done their homework.
Nonetheless, VS7's Common Language Runtime, free-
threads and objects in VB, are going to make it harder
to convince people that I'm not a fool for using Lisp.
That's okay. So far it hasn't been that tough.
> David Bakhash <·····@alum.mit.edu> wrote in message
> ····················@mint-square.mit.edu...
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> > > David Bakhash <·····@alum.mit.edu> wrote in message
> > > ····················@mint-square.mit.edu...
> > > > If you ask me, I think what might actually happen is that:
> > > >
> > > > 1) people hear something sucks (e.g. Perl)
> > > > 2) people check it out, predisposed to believe that it truly does suck
> > > > 3) people don't give it a fair chance after little inspection
> > > > 4) more people denigrate it.
> > > >
> > >
> > > hmm...I wonder if that could happen to lisp.....
> >
> > what do you mean, wonder? It happens to Lisp continuously.
>
> Oh, yes, i do know that!! I was being ironic, i assure you :-) When i read
> the lines about Perl it just struck me as soOOoo applicable to lisp (and
> just about any other out-of-fashion technology or idea or movie or piece of
> music or.......)
>
> >
> > I have also mentioned the utter stupidity I've seen with people thinking
> > that CL is not a compiled language, including PhD students in Computer
> > Science at MIT, who got their BS/MS in Computer Science at CMU. These
> > same people go around saying that CL sucks every chance they get.
>
> Add to this list people i know who have actually used the language
> professionally!!
>
> In my job i work on the lisp portion of a sophisticated, multi-language
> system, maintaining c1100 files of CLOS code and leading new development. I
> have seen such CRAP in there it makes my head spin!! (to be fair there is a
> great deal of excellent work in there to, i suppose this is normal in a
> project after four years and various developers coming and going.) Many of
> these people came straight from C/C++ and could not grasp the functional
> approach AT ALL (for some of the code there is no reasonable excuse). For
> example...
>
> (method names have been changed to protect the innocent)
>
> (defmethod my-method ((arg my-class))
> (let* ((part-answer (foo arg))
> (real-answer nil))
> (setf real-answer (fum part-answer))
> (return-from my-method real-answer)))
>
> Did the author of this code understand the language? (hint: this is a
> rhetoorical question)
>
> There are additionally so many violations of such basic programming
> principles, like a 500 line (no joke) long method!!! and one that is 300
> and countless 80+ line methods full of cut and paste code (can you say
> supporting function? I knew that you could...) And it is code full of side
> effects and global variables.
>
> Now lo and behold, the system is buggy and very hard to maintain and i
> guarantee many people will now pass on the impression that "lisp is slow and
> unreadable"
>
> > Does this torque you? It should.
>
> it does.
> But (perhaps out of naive optimism) i think things are getting better.
>
> Coby
"Link Davis" <·········@mindspring.com> escribi� en el mensaje
·····················@mindspring.com...
> Nonetheless, VS7's Common Language Runtime, free-
> threads and objects in VB, are going to make it harder
> to convince people that I'm not a fool for using Lisp.
> That's okay. So far it hasn't been that tough.
You may build the core of your system with CL and do the GUI in VB, VC++
(VC#?) or whatever makes your customer happy. This way CL is sort of
hidden: your brainless customer is happy and your braincells stay healthy.
;-)
Anyway, I don't think that VS and CL compete: they are in different
leagues.
Centuries ago, Nostradamus foresaw a time when David Bakhash would say:
>Simon Brooke <·····@jasmine.org.uk> writes:
>Perl was originally intended as a scripting language. CL really isn't
>the ideal scripting language. For about 90% of what mosts "scripts" are
>written for, I perform better in Perl than in CL, even though I spend
>on the order of 20 times more time in CL than Perl. It's a different
>tool that many people have coerced into a general-purpose programming
>language. I don't think it's anyone's fault, but there is serious value
>in using Perl. I only want to make this clear for those people who
>don't know anything about it except what they hear. If you can use CL,
>then of course, go for it. But if it's too cumbersome and you suspect
>that there's another tool for your task that may help you become more
>productive, then Perl may be a viable option.
If there was an easy way of doing Quick 'n Dirty regular expression
parsing "in the style popularized by Perl" (and now also offered, in
what seems to me to be a cleaner form, in Python), then it would be
even easier to "coerce" CL to do many of those scripting tasks, likely
providing greater robustness.
--
·····@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/linux.html>
"That's convenience, not cracker-proofing. Security is an emergent
property, not a feature." -- void <·····@interport.net>
From: Rudolf Schlatte
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <lxsntboc1w.fsf@ist.tu-graz.ac.at>
········@news.hex.net (Christopher Browne) writes:
> If there was an easy way of doing Quick 'n Dirty regular expression
> parsing "in the style popularized by Perl" (and now also offered, in
> what seems to me to be a cleaner form, in Python), then it would be
> even easier to "coerce" CL to do many of those scripting tasks, likely
> providing greater robustness.
Zebu contains an implementation of Emacs-style regular expressions
within its lexer. I have not looked at it in detail, but it's there
and working. URLs at http://ww.telent.net/cliki/Zebu
On 07 Jul 2000 03:38:54 -0400, David Bakhash <·····@alum.mit.edu> wrote:
>
>I keep hearing this on comp.lang.lisp. Basically, many of you guys
>despise Perl. I have a strong feeling it is its ambiguous syntax that
>makes it hard for some to grasp, and probably discourages people from
>pursuing it as a viable option for many problems. I'd like to encourage
>people who have not (yet) made this assessment that Perl is not too bad,
>and can be pretty easy and fun, and powerful too.
[Snip]
I've used Perl. It has been a few years, but I wrote a shopping cart
system in it a while back. I found it to be a powerful scripting
language but by necessity only suitable for disposable code.
Maintaining Perl code is a nightmare I wouldn't wish on anyone. It is
powerful and fun to write in, but absolutely without longevity.
--
Kenneth P. Turvey <······@SprocketShop.com>
http://www.tranquility.net/~kturvey/resume/resume.html
--------------------------------------------------------
I find it rather easy to portray a businessman. Being bland, rather
cruel and incompetent comes naturally to me.
-- John Cleese
From: Hartmann Schaffer
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3963e1ac@news.sentex.net>
In article <·······················@news1.rdc1.on.wave.home.com>,
"Michael T. Richter" <···@ottawa.com> writes:
> "Hartmann Schaffer" <··@inferno.nirvananet> wrote in message
> ·············@news.sentex.net...
>>>> lisp only looks longwinded and confusing on the surface.
>
>>> If something looks confusing, it likely is.
>
>> everything looks confusing to the uninitiated. mathematical notation
>> is an excellent example, but after having learned a little bit about
>> it, most people prefer it over the alternatives. imo the same applies
>> to lisp
>
> But you're *DEALING* with someone who learned a bit about it. Indeed you're
> dealing with someone who learned a bit about Lisp (and work-alikes) before
> he learned about C. And rejected Lisp. Several times. I've attempted to
> add Lisp and its work-alikes to my tool belt several times. Each time I
> wind up with a nearly perl-like tendency toward having code I've written
> become unreadable six weeks later.
so YOU have some problems with lisp. this definitely was not clear
from your earlier posts, where you stated that lisp IS unreadable.
nobody wants to force you to use lisp.
>>> If unreadability is supposed to be an advantage, I guess I'm all for it.
>
>> see above
>
> See above.
>
> I think one of the most annoying traits of Lispers is that you all seem to
> think that people who don't like Lisp are merely ignorant of all of its
> advantages. I'm not. I know what kinds of powerful things Lisp provides.
in more cases than not this probably is true.
> I know how useful those things are. But all this utility comes at a cost:
> the language is horrid to read and tends to turn into write-only code with
> little effort -- for me, at any rate. No amount of your wildly flapping
my guess is that "for me, at least" is the important part. For most
people who are familiar with lisp you statement without that phrase is
simply in contradiction to their own experience
> your arms and telling me that I'll "get it" with only a bit of effort will
> change the fact that after SEVERAL YEARS of on-again-off-again attempts to
> learn the language, I *STILL* despise it as an unreadable mess.
i wasn't wildly flapping my arms, but i was telling you what (in my
experience) is the most likely cause for your problem (or frustration
or whatever). you, otoh, should realise that making generalised
statements about the unusability of lisp in an environment where
practically everybody has the opposite experience will trigger the
type of responses you get, without at least mentioning that this is your
personal experience despite several attempts, is bound to trigger
responses that you seem to object to
> Is that clear?
yes, and i hope that my response is equally clear
--
Hartmann Schaffer
From: Reini Urban
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39648741.349880121@news>
Michael T. Richter wrote:
>I think one of the most annoying traits of Lispers is that you all seem to
>think that people who don't like Lisp are merely ignorant of all of its
>advantages. I'm not. I know what kinds of powerful things Lisp provides.
>I know how useful those things are. But all this utility comes at a cost:
>the language is horrid to read and tends to turn into write-only code with
>little effort -- for me, at any rate. No amount of your wildly flapping
>your arms and telling me that I'll "get it" with only a bit of effort will
>change the fact that after SEVERAL YEARS of on-again-off-again attempts to
>learn the language, I *STILL* despise it as an unreadable mess.
>
>Is that clear?
So you are saying that LISP is a write friendly language, which is
incredibly hard to read-only, reader/lurker-friendly who have no time to
write also.
That might be true. A lot of people think this way.
But I don't think so, because in my case I hardly write any common lisp
code. Try to read any good lisp book first. maybe this helps.
I do mainly reading, and to my eyes it is VERY reader friendly if
properly indented and without the former upcase habits. (in ancient
times).
This is true for:
* simple stuff
typical lisp-like long names, consistent style habits, shorter code
* recursive ones like the mentioned REMOVE
but only if you once wrote something like this by yourself of course. a
typical "written-once => understand it" pattern.
Introductory CS courses are here for exactly that purpose.
* OO
I never wrote any single CLOS line (well, let's say 20 lines), but is
still much easier to read for me than any C++, perl or Java in this
regard.
* harder stuff (search, parsers, compilers, optimizers, ai-like
problems, ...).
I simply cannot read this in - just let's abuse for this example the
JEmacs reader - java. There you can easily compare kawa (scheme) and
java.
try kawa-1.6.66/gnu/jemacs/lang/
there are java and scm sources for similar hard tasks, where it is next
to impossible to read the hard java stuff, but very easy in the scheme
syntax. unfortunately per has to do this in java. on the contrary the
simple buffer and window handling code is much easier to read in java.
(but there's no attempt in scheme.)
BTW: kawa is even easier to read than CL because the strict typing helps
a lot, compared to CL-alike declare statements. looks like Dylan.
Dylan is VERY easy to read in my eyes. Maybe the easiest to read
language for me at all. I can say that without ever having written any
single dylan line. But I cannot deal with ML and friends, though I
started with basic, pascal, C and prolog. Strange.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
From: David Hanley
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <396671FD.199E9635@ncgr.org>
"Michael T. Richter" wrote:
> "Hartmann Schaffer" <··@inferno.nirvananet> wrote in message
> ·············@news.sentex.net...
> >>> lisp only looks longwinded and confusing on the surface.
>
> >> If something looks confusing, it likely is.
>
> > everything looks confusing to the uninitiated. mathematical notation
> > is an excellent example, but after having learned a little bit about
> > it, most people prefer it over the alternatives. imo the same applies
> > to lisp
>
> But you're *DEALING* with someone who learned a bit about it. Indeed you're
> dealing with someone who learned a bit about Lisp (and work-alikes) before
> he learned about C. And rejected Lisp. Several times. I've attempted to
> add Lisp and its work-alikes to my tool belt several times. Each time I
> wind up with a nearly perl-like tendency toward having code I've written
> become unreadable six weeks later.
I would submit that since I, and other people can read our old lisp
code, that the failure would be with you, and not the tool. Is this
line of reasoning clear, or not?
dave
From: Colin Walters
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <85wvj2ymf4.fsf@meta.verbum.org>
"Michael T. Richter" <···@ottawa.com> writes:
> > i admit that the boilerplate mishmash of parens, braces and
> > semicolons can help a human find their way, e.g., i think C's for
> > (;;){} is easier than lisp's (do ()()()).
>
> Yes. Finally I've met someone in the Lisp camp who recognizes this
> feature.
Speaking of loops, I have started using Common Lisp for some of my
programs instead of Scheme because of its standardization of important
things like packages, but one thing I really miss from Scheme is the
"named let" syntax for function calls. I think this syntax beats both
Common Lisp's `do' and `labels', as well as C's `for (;;) {}'
construction, in terms of terseness and clarity. I suppose it
wouldn't be hard to write a `letf' macro or something, though.
If you haven't seen the Scheme "named let" before, it looks like:
(define (remove p l)
(let remove ((l l)
(result '()))
(cond ((null? l) result)
((eqv? p (car l)) (remove (cdr l) result))
(else (remove (cdr l) (cons (car l) result))))))
which is equivalent to
(define (remove p l)
(letrec ((remove
(lambda (l result)
(cond ((null? l) result)
((eqv? p (car l)) (remove (cdr l) result))
(else (remove (cdr l) (cons (car l) result)))))))
(remove l '())))
and the Common Lisp construction:
(defun remove (p l)
(labels ((remove (l result)
(cond ((null l) result)
((eql p (car l)) (remove (cdr l) result))
(t
(remove (cdr l) (cons (car l) result))))))
(remove l '())))
Colin Walters <·······@cis.ohio-state.edu> wrote in message
···················@meta.verbum.org...
>>> i admit that the boilerplate mishmash of parens, braces
>>> and semicolons can help a human find their way, e.g., i
>>> think C's for (;;){} is easier than lisp's (do ()()()).
>> Yes. Finally I've met someone in the Lisp camp who
>> recognizes this feature.
> Speaking of loops, I have started using Common Lisp for some
> of my programs instead of Scheme because of its standardization
> of important things like packages, but one thing I really miss
> from Scheme is the "named let" syntax for function calls. I
> think this syntax beats both Common Lisp's `do' and `labels', as
> well as C's `for (;;) {}' construction, in terms of terseness
> and clarity. I suppose it wouldn't be hard to write a `letf'
> macro or something, though.
> If you haven't seen the Scheme "named let" before, it looks like:
[snip definition]
Unfortunately I find Scheme easily as unreadable as Lisp. As a result, I
have no tool available to evaluate the elegance of the construct you posted.
Can you do a line-by-line commentary (if you have the time) to explain: a)
how it works and b) what you find powerful in it?
From: Tim Bradshaw
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <ey3sntpc416.fsf@cley.com>
* Colin Walters wrote:
> Speaking of loops, I have started using Common Lisp for some of my
> programs instead of Scheme because of its standardization of important
> things like packages, but one thing I really miss from Scheme is the
> "named let" syntax for function calls. I think this syntax beats both
> Common Lisp's `do' and `labels', as well as C's `for (;;) {}'
> construction, in terms of terseness and clarity. I suppose it
> wouldn't be hard to write a `letf' macro or something, though.
named let is almost trivial to write in a CL, and if you have TRO it's
efficient. Like this in fact:
(defmacro iterate (name bindings &body body)
"Scheme style named LET for common lisp: (ITERATE name bindings . body)
bindings is a CL-style LET-bindings spec (ie you can have isolated
symbols which are bound to NIL. This will be horrible if your CL doesn't
optimise local functions properly."
;; note that this is like LET* not LET
(let ((argnames ())
(argvals ()))
(labels ((grind-bindings (tail)
(if (not (null tail))
(etypecase (car tail)
(symbol
(grind-bindings (cdr tail))
(push (car tail) argnames)
(push nil argvals))
(list
(grind-bindings (cdr tail))
(push (car (car tail)) argnames)
(push (cadr (car tail)) argvals))))))
(grind-bindings bindings)
`(labels ((,name ,argnames
,@body))
(,name ,@argvals)))))
It's possible to write seriously obscure code with named let I found,
because it's basically GOTO in slight disguise. So I tend to use
explicit loops now as I have a tendancy to write maximally obscure
code if the language lets me.
LETF is traditionally used to mean something else -- a LET which can
bind places in the SETF sense.
--tim
From: David Bakhash
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <c29vgylykwt.fsf@nerd-xing.mit.edu>
"Michael T. Richter" <···@ottawa.com> writes:
> > i admit that the boilerplate mishmash of parens, braces and semicolons
> > can help a human find their way, e.g., i think C's for (;;){} is
> > easier than lisp's (do ()()()).
>
> Yes. Finally I've met someone in the Lisp camp who recognizes this feature.
bogus.
But, if you really love C's `for' then just implement it in Common
Lisp. It shouldn't be too hard to have something that looks almost
exactly like `for' (maybe a bit lispy, but hey, it's lisp).
(for ((i 0.0) (< i 1.0) (+ i 0.1))
(print i))
==>
0.0
0.1
.
.
.
0.9
just a thought.
dave
David Bakhash <·····@alum.mit.edu> wrote in message
····················@nerd-xing.mit.edu...
>>> i admit that the boilerplate mishmash of parens, braces and
>>> semicolons can help a human find their way, e.g., i think C's
>>> for (;;){} is easier than lisp's (do ()()()).
>> Yes. Finally I've met someone in the Lisp camp who recognizes
>> this feature.
> bogus.
<tone style="sarcasm">
A very cogent rebuttal. I have now seen the error of my ways. You are a
truly fiendish disputante for you have undone an opinion based upon years of
effort with a simple, two-syllable word.
</tone>
> But, if you really love C's `for' then just implement it in
> Common Lisp. It shouldn't be too hard to have something that
> looks almost exactly like `for' (maybe a bit lispy, but hey,
> it's lisp).
> (for ((i 0.0) (< i 1.0) (+ i 0.1))
> (print i))
> just a thought.
But a thought based upon missing the point entirely. The point is that
cramming a half-dozen completely different sets of semantics into one syntax
makes the resulting code hard for human readers. Having the code illustrate
through visual cues that you're dealing with something which is semantically
different aids human readers.
Using the equivalent C "for" construct...
for (i = 0.0; i < 1.0; i++)
{
print(i);
}
...(and remembering that I'm trying to escape the C-influenced world, so
don't make the usual error of assuming I'm a C apologist) I have the
following information provided for free without any need for picking apart
the code:
- I'm entering an enumerated, top-test loop. ("for")
- There is assignment to a variable. ("=")
- There is an in-place increment of a variable. ("++")
- There is a code block. ("{}")
- There is a function invocation. ("()")
Your code tells me that I'm entering an enumerated, top-test loop for free.
After that I have to parse what's there to get the semantics.
Yes, Lisp has its advantages. Readability isn't one of them.
In article <····················@news22.bellglobal.com>,
"Michael T. Richter" <···@igs.net> writes:
> David Bakhash <·····@alum.mit.edu> wrote in message
> ····················@nerd-xing.mit.edu...
> > (for ((i 0.0) (< i 1.0) (+ i 0.1))
> > (print i))
>
> The point is that cramming a half-dozen completely different sets of
> semantics into one syntax makes the resulting code hard for human readers.
> Having the code illustrate through visual cues that you're dealing with
> something which is semantically different aids human readers.
I'd disagree that you get a half-dozen sets of semantics. At a stretch, I'd
identify two -- function call, and macro invocation. But that's a minor
detail.
> Using the equivalent C "for" construct...
>
> for (i = 0.0; i < 1.0; i++)
> {
> print(i);
> }
>
> ...(and remembering that I'm trying to escape the C-influenced world, so
> don't make the usual error of assuming I'm a C apologist) I have the
> following information provided for free without any need for picking apart
> the code:
> - I'm entering an enumerated, top-test loop. ("for")
Sure. The first word tells you what's going on.
> - There is assignment to a variable. ("=")
Just like this almost identical one for C9x or C++, I take it?
for (double i = 0.0; i < 1.0; i += 0.1) {
print(i);
}
Except that in this case, the "=" means `initialize', not `assign', and it
turns out that they're different. If you're trying to argue that it's
better to have visually distinctive syntax for operations with different
semantics, then C is certainly not the right language to hold up as an
example -- even if you're not trying to be an apologist for C.
> - There is an in-place increment of a variable. ("++")
(You actually wanted "i += 0.1" to get the same meaning as David's loop, but
I'll assume that's an oversight.)
Are you really concerned that there's an in-place increment of a variable,
or merely that the value of the variable increases over time? If the
latter, then I would claim that having to specify "in-place increment"
merely clutters the code without adding anything of interest.
> - There is a code block. ("{}")
Of course there's a code block -- it's a loop. This seems a somewhat
specious means of increasing your count of differing semantics. I'd also be
inclined to suggest that the visual cue for "code block" is not the brace
pair, but the additional indentation. Lisp does the same thing: you read
not the parentheses, but the indentation. (And in my opinion, Lisp has two
significant advantages here. Firstly, the conventions that have arisen for
indenting Lisp are much closer to universal than any of the competing
conventions for languages like C. Secondly, the highly regular nature of
Lisp syntax makes it pretty trivial to perform this sort of indentation
automatically.)
> - There is a function invocation. ("()")
It's unclear to me why you think that visually marking function invocation
is a particularly good idea. Surely the majority of all code is function
invocations? This certainly applies to Lisp. For C, the argument against
this idea is that the infix operators aren't functions; but C++ abandons the
distinction.
> Your code tells me that I'm entering an enumerated, top-test loop for free.
> After that I have to parse what's there to get the semantics.
So write your FOR macro differently. When I was young(er) and (more)
foolish, I wrote a FOR macro that allowed syntax like this (among a too-wide
variety of other styles):
(for (0 <= i < 1 :step 1/10)
(print i))
(All sensible combinations of <, <=, >, >= are permitted, and the :step part
is optional.) I actually really like this syntax; I find that it describes
what is going on far more clearly than any other syntax I've seen.
Alternatively, you could use the standard LOOP macro:
(loop for i from 0 to 9/10 by 1/10 do
(print (float i)))
Seems entirely readable to me. (As an aside, note that this version does
actually give you the desired answer; using floating-point arithmetic is
probably a pretty bad idea here.)
To return to your initial point that visual cues are useful, and that Lisp
syntax provides fewer such cues than many other languages: I don't deny
either the utility of visual cues, or the fact that some Lisp forms may
overuse nested parentheses (DO being an example). But Lisp's approach to
syntax, in which you can use macros and reader macros to alter what the
programmer sees, enables you to construct syntax that is convenient for what
you're doing. Regarding DO in particular, my experience is that many if not
most uses of this form are actually hidden away in macros that relate to
some abstraction. Though they needn't be implemented in terms of DO, the CL
macros DOLIST, DOTIMES, DO-SYMBOLS are good examples of what I mean.
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
From: Tim Bradshaw
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <ey3bt0dbsfw.fsf@cley.com>
* Aaron Crane wrote:
> I'd disagree that you get a half-dozen sets of semantics. At a stretch, I'd
> identify two -- function call, and macro invocation. But that's a minor
> detail.
special forms are a third.
--tim
From: Gareth McCaughan
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <slrn8m4ibs.lf.gjm11@g.local>
Michael T. Richter wrote:
[David Bakhash:]
> > But, if you really love C's `for' then just implement it in
> > Common Lisp. It shouldn't be too hard to have something that
> > looks almost exactly like `for' (maybe a bit lispy, but hey,
> > it's lisp).
>
> > (for ((i 0.0) (< i 1.0) (+ i 0.1))
> > (print i))
..
> But a thought based upon missing the point entirely. The point is that
> cramming a half-dozen completely different sets of semantics into one syntax
> makes the resulting code hard for human readers. Having the code illustrate
> through visual cues that you're dealing with something which is semantically
> different aids human readers.
>
> Using the equivalent C "for" construct...
>
> for (i = 0.0; i < 1.0; i++)
> {
> print(i);
> }
[SNIP: Michael explains why he prefers "for"]
For readability by inexperienced humans, I don't think either
of these approaches comes close to
(loop for i from 0 by 0.1 below 1.0 do
(print i))
Some Lispers detest LOOP. I'm glad it's there, because it's
a great tool for expressing simple iterations simply. (Most
iterations are simple. Hairy ones are tricky to understand
whatever language you express them in.)
For slightly more complicated iterations, compare C's
for (p=items; p; p=p->next) {
do_something(p);
}
with Lisp's
(loop for item in items do
(do-something p))
No comparison, I reckon.
Note that the Lisp versions also isolate the binding of the
loop variable to within the loop, which is usually what you
want. Doing that in C requires more braces and an extra
declaration.
Now, I know you're not primarily defending C. But if the issue
is the readability of C's iteration constructs versus that of
Lisp's, I think it's a one-way contest, and not in the direction
you're suggesting.
Some bits of C's syntax *are* much easier for the non-immersed
to grasp. For instance, I think assignments and arithmetic are
clearer in C than in Lisp, unless you have a little reader
macro that lets you write
{ x = (5 * y + 7) / (y + 3) }
(which isn't hard; there are such things out there and in the
public domain). On the other hand, I find that I never use them;
one gets used to the syntax of Lisp.
--
Gareth McCaughan ················@pobox.com
sig under construction
From: vsync
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <87sntpjyvm.fsf@piro.quadium.net>
·····@g.local (Gareth McCaughan) writes:
> Some Lispers detest LOOP. I'm glad it's there, because it's
> a great tool for expressing simple iterations simply. (Most
> iterations are simple. Hairy ones are tricky to understand
> whatever language you express them in.)
I detest LOOP. The whole point of Lisp IMO is the parens and the
prefix notation. Why screw that up with some weird English-like
thingie that just looks _wrong_? As to simple and complex iterations,
I don't find using MAPCAR or DOLIST or just plain DO to be hard to
understand. I just spend 5 minutes reading the manual _before_ I try
something for the first time.
> Note that the Lisp versions also isolate the binding of the
> loop variable to within the loop, which is usually what you
> want. Doing that in C requires more braces and an extra
> declaration.
Java (and C++ IIRC) let you do this:
for (int i = 0; i < MAX_SIZE; i++)
do_something_with(i);
i is only within the scope of that loop.
--
vsync
http://quadium.net/ - last updated Fri Jun 30 22:55:16 MDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
From: Paul F. Dietz
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39626DBF.64B75E0A@interaccess.com>
vsync wrote:
> I detest LOOP. The whole point of Lisp IMO is the parens and the
> prefix notation. Why screw that up with some weird English-like
> thingie that just looks _wrong_?
Because the result is often easier to understand
that the equivalent code without LOOP.
But then I grew up on Interlisp, so maybe it's
a cultural thing.
Paul
From: vsync
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <87g0ppjxkl.fsf@piro.quadium.net>
"Paul F. Dietz" <·····@interaccess.com> writes:
> vsync wrote:
>
> > I detest LOOP. The whole point of Lisp IMO is the parens and the
> > prefix notation. Why screw that up with some weird English-like
> > thingie that just looks _wrong_?
>
> Because the result is often easier to understand
> that the equivalent code without LOOP.
>
> But then I grew up on Interlisp, so maybe it's
> a cultural thing.
I think that's true. I learned Lisp from Paul Graham's _ANSI Common
Lisp_, and he smacks LOOP down pretty hard. I think I would have
disliked it anyway, though, as my preference is to do things in the
way most fitting to the language. LOOP just doesn't seem very "Lispy"
to me.
But it's great that the different facilities are there. It's not just
in Perl that "there's more than one way to do things". =)
--
vsync
http://quadium.net/ - last updated Fri Jun 30 22:55:16 MDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
On 04 Jul 2000 17:16:26 -0600, vsync <·····@quadium.net> wrote:
> "Paul F. Dietz" <·····@interaccess.com> writes:
>
> > Because the result is often easier to understand that the equivalent
> > code without LOOP.
> >
> > But then I grew up on Interlisp, so maybe it's a cultural thing.
>
> I think that's true. I learned Lisp from Paul Graham's _ANSI Common Lisp_,
> and he smacks LOOP down pretty hard. I think I would have disliked it
> anyway, though, as my preference is to do things in the way most fitting
> to the language. LOOP just doesn't seem very "Lispy" to me.
I become familiar with CL via the same book. IIRC Graham makes the point
that writing "languages" within CL is a common thing to do, perhaps even a
"Lispy" thing to do. Given that I've always thought that LOOP was *very*
"Lispy".
--
Take a look in Hagbard's World: | boxquote.el - "Boxed" text quoting.
http://www.hagbard.demon.co.uk/ | sawfish.el - Sawfish mode.
http://www.acemake.com/hagbard/ | uptimes.el - Record emacs uptimes.
emacs software, including.......| quickurl.el - Recall lists of URLs.
"Paul F. Dietz" <·····@interaccess.com> writes:
> vsync wrote:
>
> > I detest LOOP. The whole point of Lisp IMO is the parens and the
> > prefix notation. Why screw that up with some weird English-like
> > thingie that just looks _wrong_?
>
> Because the result is often easier to understand
> that the equivalent code without LOOP.
>
> But then I grew up on Interlisp, so maybe it's
> a cultural thing.
I grew up with InterLISP (and Portable Standard LISP, to be fair) too,
and I *hated* that awful 'english like' loop stuff. MAPCAR and friends
have always seemed more elegant and more perspicuous to me.
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
; ... of course nothing said here will be taken notice of by
; the W3C. The official place to be ignored is on www-style or
; www-html. -- George Lund
"Simon Brooke" <·····@jasmine.org.uk> wrote in message
···················@gododdin.internal.jasmine.org.uk...
> I grew up with InterLISP (and Portable Standard LISP, to be fair) too,
> and I *hated* that awful 'english like' loop stuff. MAPCAR and friends
> have always seemed more elegant and more perspicuous to me.
You should have a look at the Series package for CL maintained by Fernando
D. Mato Mira at http://series.sourceforge.net
To be (very...) short, it's mapcar like functions on steroids.
Marc Battyani
From: Reini Urban
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3964869c.349715043@news>
Marc Battyani wrote:
> Series ...
>To be (very...) short, it's mapcar like functions on steroids.
steroids?
--
Reini
From: Colin Walters
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <858zvfl698.fsf@meta.verbum.org>
······@sbox.tu-graz.ac.at (Reini Urban) writes:
> Marc Battyani wrote:
> > Series ...
> >To be (very...) short, it's mapcar like functions on steroids.
>
> steroids?
A drug for abnormally enhancing muscle growth.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171881715434356@naggum.net>
* Reini Urban
| steroids?
He means "anabolic steroids", specifically hormones resembling
testosterone, which stimulate anabolism (the constructive phase of
metabolism) in the body. These hormones are widely used to enhance
the effect of muscle building. A sports star discovered to be on
steroids is demoted to _asteroid_. (Just kidding.)
I think catabolic steroids give a better picture of the development
of some languages where this expression is used. Such steroids act
as immunosuppressives in everything from asthma via transplant
rejection to cancer and aids, and cause the body to accumulate water
and build fatty tissue while breaking down muscle tissue.
#:Erik
--
If this is not what you expected, please alter your expectations.
vsync <·····@quadium.net> wrote in message
···················@piro.quadium.net...
> ·····@g.local (Gareth McCaughan) writes:
>
> > Some Lispers detest LOOP. I'm glad it's there, because it's
> > a great tool for expressing simple iterations simply. (Most
> > iterations are simple. Hairy ones are tricky to understand
> > whatever language you express them in.)
>
> I detest LOOP. The whole point of Lisp IMO is the parens and the
> prefix notation. Why screw that up with some weird English-like
> thingie that just looks _wrong_? As to simple and complex iterations,
> I don't find using MAPCAR or DOLIST or just plain DO to be hard to
> understand. I just spend 5 minutes reading the manual _before_ I try
> something for the first time.
No, the whole point of Lisp is that things such as LOOP can be created at
all, within the language itself. Otherwise we wouldn't be having this
discussion.
Will Hartung
(······@home.com)
From: David Bakhash
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <c29sntpyzd8.fsf@nerd-xing.mit.edu>
·····@g.local (Gareth McCaughan) writes:
> Michael T. Richter wrote:
>
> [David Bakhash:]
> > > But, if you really love C's `for' then just implement it in
> > > Common Lisp. It shouldn't be too hard to have something that
> > > looks almost exactly like `for' (maybe a bit lispy, but hey,
> > > it's lisp).
> >
> > > (for ((i 0.0) (< i 1.0) (+ i 0.1))
> > > (print i))
> ..
> > But a thought based upon missing the point entirely. The point is that
> > cramming a half-dozen completely different sets of semantics into one syntax
> > makes the resulting code hard for human readers. Having the code illustrate
> > through visual cues that you're dealing with something which is semantically
> > different aids human readers.
> >
> > Using the equivalent C "for" construct...
> >
> > for (i = 0.0; i < 1.0; i++)
> > {
> > print(i);
> > }
> [SNIP: Michael explains why he prefers "for"]
>
> For readability by inexperienced humans, I don't think either
> of these approaches comes close to
>
> (loop for i from 0 by 0.1 below 1.0 do
> (print i))
this goes without say, and LOOP is _exactly_ how most people would do
this example.
> Some Lispers detest LOOP.
This will likely change over time.
One thing I must say about the readability, or unreadability of Lisp
code is that when you're diving into other people's heavy macrologies,
things can often get very difficult to read, and know what's going on.
If it all works, then it's usually okay. But when you're debugging
other people's code, one often depends on macroexpansion to see what's
going on. If macros are written correctly, well documented, and maybe
even show an example or two of usage, then what is to some a burden can
easily become a friendly tool.
dave
Centuries ago, Nostradamus foresaw a time when David Bakhash would say:
>·····@g.local (Gareth McCaughan) writes:
>
>> Michael T. Richter wrote:
>>
>> [David Bakhash:]
>> > > But, if you really love C's `for' then just implement it in
>> > > Common Lisp. It shouldn't be too hard to have something that
>> > > looks almost exactly like `for' (maybe a bit lispy, but hey,
>> > > it's lisp).
>> >
>> > > (for ((i 0.0) (< i 1.0) (+ i 0.1))
>> > > (print i))
>> ..
>> > But a thought based upon missing the point entirely. The point is that
>> > cramming a half-dozen completely different sets of semantics into one syntax
>> > makes the resulting code hard for human readers. Having the code illustrate
>> > through visual cues that you're dealing with something which is semantically
>> > different aids human readers.
>> >
>> > Using the equivalent C "for" construct...
>> >
>> > for (i = 0.0; i < 1.0; i++)
>> > {
>> > print(i);
>> > }
>> [SNIP: Michael explains why he prefers "for"]
>>
>> For readability by inexperienced humans, I don't think either
>> of these approaches comes close to
>>
>> (loop for i from 0 by 0.1 below 1.0 do
>> (print i))
>
>this goes without say, and LOOP is _exactly_ how most people would do
>this example.
The only thing worse than LOOP is the set of alternatives to LOOP.
The C "for" construct is _used as_ a looping construct; it is rather
better compared to DO, whether we're talking the Common Lisp DO, or
the Scheme DO.
In either case, DO, just like C's "for," represents a primitive control
structure that doesn't really structure things very strongly. You can
do virtually anything in the clauses, as opposed to the way that LOOP
supplies both name bindings _as well as control over what they do_.
C provides neither bindings nor control; you need to pre-declare your
variables, and manually set up the clauses to do "the right things."
DO provides bindings, but no control. You have to manually set up the
clauses to do "the right things," namely initializing, incrementing, and
comparing.
In contrast,
(loop for i from 0 by 0.1 below 1.0 do
(print i))
shows that LOOP is supporting all three of these things:
-> It creates a binding for "i"
-> It supplies the code to increment and test i, based on a _description_
of what is to be done to i.
>> Some Lispers detest LOOP.
>
>This will likely change over time.
I don't much like LOOP, but find that the alternatives are largely
_worse_.
There are two _major_ cases:
a) If you're doing a relatively simple loop, LOOP is pretty nice.
b) If you're doing a _really complex_ loop, LOOP is pretty nasty, but
so are the alternatives.
It might be a Nice Thing to revisit LOOP, and make up a "cleaner"
design. An ambitious person might want to show us what a "better
LOOP" might look like with a sample implementation.
>One thing I must say about the readability, or unreadability of Lisp
>code is that when you're diving into other people's heavy macrologies,
>things can often get very difficult to read, and know what's going on.
>If it all works, then it's usually okay. But when you're debugging
>other people's code, one often depends on macroexpansion to see what's
>going on. If macros are written correctly, well documented, and maybe
>even show an example or two of usage, then what is to some a burden can
>easily become a friendly tool.
Herein lies the _other_ merit of LOOP that exists whether you use it or
not; it provides an example of a sophisticated language embedded in
Common Lisp using macros.
Other languages have nothing of comparable nature, AT ALL.
--
·····@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/lisp.html>
"[In 'Doctor' mode], I spent a good ten minutes telling Emacs what I
thought of it. (The response was, 'Perhaps you could try to be less
abusive.')" -- Matt Welsh
From: Rob Myers
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <B588B187.3F6F%robmyers@cwcom.net>
> From: Erik Naggum <····@naggum.net>
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
> Please leave me out of your insanity, Rob.
It's insane to deny the existence of space aliens? You're further gone than
I thought! Come on, say it: "The people around Erik have not been replaced
by alien pods. Erik does not have to kill them Come The Day." .
> Please ask your doctor
> to reconsider the suggestion to use USENET for therapeutic purposes.
> You just be calm, now. You _don't_ need to hurt yourself, OK? You
> can get through this stressful period safely. Just take your anti-
> psychotic medication and try to stay away from challenges to your
> beliefs, and this will all be over in a couple days, OK? If you try
> and avoid responding to me, you'll soon feel much better, too.
Well, with that stunning, if unintentional, piece of self-description on
your part, my work here is done.
All that's left is for you to prove me right about you having to have the
last word again, and you can go back to being the list Village Idiot.
- Rob.
In article <·······················@knuth.brownes.org>,
········@hex.net wrote:
> Herein lies the _other_ merit of LOOP that exists whether you use it or
> not; it provides an example of a sophisticated language embedded in
> Common Lisp using macros.
>
> Other languages have nothing of comparable nature, AT ALL.
Not true.
Your loop in Dylan:
for (i from 0.0 below 1.0 by 0.1)
print(i)
end
This, as you would expect, does the same thing as the CL version and,
also as in CL, is implemented as a macro in the Dylan standard library.
The Dylan "for" macro supports numeric sequences (as above), iterating
through any kind of collection ("e in coll"), and explicit steps ("p =
myList then p.next"). Naturally it also supports multiple, parallel,
iteration variables and explicit exit conditions.
And it's all implemented as an (admitedly hairy) macro that expands to a
tail-recursive local function.
-- Bruce
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171718243085769@naggum.net>
* "Michael T. Richter" <···@igs.net>
| <tone style="sarcasm">
| A very cogent rebuttal. I have now seen the error of my ways. You
| are a truly fiendish disputante for you have undone an opinion based
| upon years of effort with a simple, two-syllable word.
| </tone>
Let's _quote_ from some of Michael T. Richter's eloquence on display
for all the world to see (well, that part of the world which thinks
Dylan is all the world, anyway):
In <······················@news1.rdc1.on.wave.home.com>, Michael
T. Richter <···@ottawa.com>, presumably the same _gentleman_, writes:
"Hey fuckhead"
Granted, it's two words and three syllables, which could imply that
Michael T. Richter is anywhere between 50% and 100% more cogent than
Dave Bakhash's "bogus", but since the first word is but a noise word
to get attention, it isn't worth anything at all, which means we're
dealing with a neanderthal who is very envious of humans. Worse,
yet, "bogus" is _way_ more cogent than "fuckhead", but then again,
Dave is a Lisp user and Michael is a Dylan user, and we know what
kind of people _they_ are: ...
| Yes, Lisp has its advantages. Readability isn't one of them.
... hostile, illiterate bums who hate their parens, as this new
evidence of eloquence and cogency shows so clearly.
#:Erik
--
If this is not what you expected, please alter your expectations.
From: Rob Myers
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3962196B.44DF1727@h2g2.com>
Erik Naggum whined:
> "Hey fuckhead"
I thought you appreciated economy of expression and its accompanying accuracy?
> and we know what kind of people _they_ are: ...
And I repeat: didn't you have something to say about people who make
sweeping generalizations?
- Rob.
--
"Don't talk to sociologists. Social practice has no sociological
content." - Art & Language.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171726661211649@naggum.net>
* Rob Myers <····@h2g2.com>
| And I repeat: didn't you have something to say about people who make
| sweeping generalizations?
I'm so glad you asked. Yes, of course, but I'm trying to learn
about the Dylan ways by studying such fine gentlemen as yourself.
Remember, languages shape the way we think, so in order to think
like a Dylanite or whatever your neanderthal race is called, I must
study how you perform in the big challenge that is life. For Dylan
users, specifically, random, unchecked assumption are perfectly OK,
sweeping generalizations even better, and so naturally one has to
deal with neanderthals such as your community on your own premises.
You _surely_ can't mean that when a number of Dylanites prove to the
world that when they make sweeping generalizations about others, and
the _others_ object, they have _not_ communicated clearly that it is
OK to apply sweeping generalizations to _themselves_? I don't think
very highly of the Dylan community, but the sheer inability to grasp
that when you do something to others out of moral righteousness, it
most certainly must be OK to apply it back to yourself is too much
-- even I don't think _that_ badly of neanderthals morons. And lest
you object -- _you_ have most certainly proven beyond _any_ doubt
that there's one law for you (Dylanites) and one law for everyone
else, so I'm just trying to do the smallest things to accomodate you
Dylanites. Out of courtesy, you know -- _your_ kind of courtesy.
#:Erik
--
If this is not what you expected, please alter your expectations.
From: ······@my-deja.com
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <8jtbd7$plk$1@nnrp1.deja.com>
In article <····················@news22.bellglobal.com>,
"Michael T. Richter" <···@ottawa.com> wrote:
> for (i = 0.0; i < 1.0; i++)
> {
> print(i);
> }
That syntax is actually not as good as you think. You of course
carefully removed any bugs from it to show it in a positive light,
but in spite of your best efforts, it doesn't increment the iterator
correctly, and is therefore not equivalent to the code you were
trying to compare it with.
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Joe Marshall
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <puot4tx6.fsf@alum.mit.edu>
"Michael T. Richter" <···@igs.net> writes:
>
> Using the equivalent C "for" construct...
>
> for (i = 0.0; i < 1.0; i++)
> {
> print(i);
> }
>
> ...(and remembering that I'm trying to escape the C-influenced world, so
> don't make the usual error of assuming I'm a C apologist) I have the
> following information provided for free without any need for picking apart
> the code:
> - I'm entering an enumerated, top-test loop. ("for")
> - There is assignment to a variable. ("=")
> - There is an in-place increment of a variable. ("++")
> - There is a code block. ("{}")
> - There is a function invocation. ("()")
I forget. What do the `;' mean? Do they always mean the same thing
everywhere, or do they mean different things in different places? I
also don't understand the function invocation: is FOR being invoked
on 7 arguments (i, =, 0.0;, i, <, 1.0;, i++)? Or do parenthesis mean
different things in different places, too?
Or perhaps it is the case that the keyword FOR has its own syntax that
is similar to the syntax of the rest of the code. In which case an
experienced user knows what to expect in a FOR statement. How does
this differ from the lisp version of FOR?
Joe Marshall <·········@alum.mit.edu> writes:
> "Michael T. Richter" <···@igs.net> writes:
>
> >
> > Using the equivalent C "for" construct...
> >
> > for (i = 0.0; i < 1.0; i++)
> > {
> > print(i);
> > }
> >
> > ...(and remembering that I'm trying to escape the C-influenced world, so
> > don't make the usual error of assuming I'm a C apologist) I have the
> > following information provided for free without any need for picking apart
> > the code:
> > - I'm entering an enumerated, top-test loop. ("for")
> > - There is assignment to a variable. ("=")
> > - There is an in-place increment of a variable. ("++")
> > - There is a code block. ("{}")
> > - There is a function invocation. ("()")
>
> I forget. What do the `;' mean? Do they always mean the same thing
> everywhere, or do they mean different things in different places? I
> also don't understand the function invocation: is FOR being invoked
> on 7 arguments (i, =, 0.0;, i, <, 1.0;, i++)? Or do parenthesis mean
> different things in different places, too?
>
> Or perhaps it is the case that the keyword FOR has its own syntax that
> is similar to the syntax of the rest of the code. In which case an
> experienced user knows what to expect in a FOR statement. How does
> this differ from the lisp version of FOR?
thanks, joe. I could never have said it better. As I recall, {}'s can
mean enums, code blocks, etc. etc. There's definately lots of that in C
and its friends.
Also, a word on "bogus". I use that word as a rather light-hearted
word. I didn't mean to offend or denigrate anyone's opinions or
justifications; I mearly was expressing a *difference* of opinion, where
something that was an opinion seemed to be stated as if it were fact.
It seemed to me as if the poster was implying that it's a bad thing that
in CL you could define macros, and that they generally obfuscate the
language. Well, no one says you have to write macros, unless you're
working alone, working on a Lisp project won't be too fun for you.
dave
From: David Bakhash
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <c29vgylz2v9.fsf@nerd-xing.mit.edu>
David Bakhash <·····@alum.mit.edu> writes:
> ...Well, no one says you have to write macros, unless you're working
> alone, working on a Lisp project won't be too fun for you.
I was in a rush. What I meant by that was that as a CL programmer, you
don't _have_ to use macros, but that if you're working in a group of
more more than one person, then you're gonna have a hard time, since so
many people _do_ use macros in Lisp.
The real point, though, was that macros, properly used, are supposed to
clarify code on the whole, make it more readable, and easier to write.
The WITH-OPEN-FILE example from another thread illustrates this nicely.
dave
David Bakhash <·····@alum.mit.edu> writes:
> The real point, though, was that macros, properly used, are supposed to
> clarify code on the whole, make it more readable, and easier to write.
> The WITH-OPEN-FILE example from another thread illustrates this nicely.
There's kind of a trade off though, isn't there? The top-level code
gets more readable, surely, but when you have to debug something deep
in a pile of macros, it can get really nasty and brain-twisting.
Macros need to be *very* carefully tested and debugged before you build
anything on top of them, in my opinion.
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
'You cannot put "The Internet" into the Recycle Bin.'
Simon Brooke <·····@jasmine.org.uk> wrote in message
···················@gododdin.internal.jasmine.org.uk...
> David Bakhash <·····@alum.mit.edu> writes:
>
> > The real point, though, was that macros, properly used, are supposed to
> > clarify code on the whole, make it more readable, and easier to write.
> > The WITH-OPEN-FILE example from another thread illustrates this nicely.
>
> There's kind of a trade off though, isn't there? The top-level code
> gets more readable, surely, but when you have to debug something deep
> in a pile of macros, it can get really nasty and brain-twisting.
Really, it's the same as any usage of abstraction. A variety of "function"
definitions with side-effects can be just as hazardous.
> Macros need to be *very* carefully tested and debugged before you build
> anything on top of them, in my opinion.
Well, so does everything. If you don't test, you don't know it's correct.
It's the same with functions. And, I would expect, the same in all
languages. Macros are no different.
faa
David Bakhash wrote:
> thanks, joe. I could never have said it better. As I recall, {}'s can
> mean enums, code blocks, etc. etc. There's definately lots of that in C
> and its friends.
When I was taking a C++ class this spring, I lost count of the number of times I
wrote
class Foo {
// definition of the class
} // whoops, forgot to put a semicolon here
because, of course, when you define a *function* in C or C++, the {} *doesn't* end
with a semicolon.
Furthermore, if the missing semicolon comes at the end of a file that's #include-d
somewhere else, then Microsoft's compiler doesn't complain about the file with the
missing semicolon, but the file that #include-d it ... or the file #include-d
immediately *after* it ... and of course the error message it produces seems to
have nothing to do with the original problem. Evil! Evil! Evil!
When the time came to pick a final project for the class, I volunteered to write a
Scheme interpreter, as a way to remove the blemish from my soul. (I wrote enough
of the interpreter to ace the project, but not enough to implement some of the
more esoteric primitives, like ... ahem ... LAMBDA....)
--
--Why is it that most kids are attracted to computers while
most adults are quite wary of computers?
--Most adults are smarter than most kids. ["Ask Uncle Louie"]
== seth gordon == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
From: David Hanley
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39667153.63777D14@ncgr.org>
"Michael T. Richter" wrote:
> David Bakhash <·····@alum.mit.edu> wrote in message
> ····················@nerd-xing.mit.edu...
> >>> i admit that the boilerplate mishmash of parens, braces and
> >>> semicolons can help a human find their way, e.g., i think C's
> >>> for (;;){} is easier than lisp's (do ()()()).
>
> >> Yes. Finally I've met someone in the Lisp camp who recognizes
> >> this feature.
>
> > bogus.
>
> <tone style="sarcasm">
> A very cogent rebuttal. I have now seen the error of my ways. You are a
> truly fiendish disputante for you have undone an opinion based upon years of
> effort with a simple, two-syllable word.
> </tone>
>
> > But, if you really love C's `for' then just implement it in
> > Common Lisp. It shouldn't be too hard to have something that
> > looks almost exactly like `for' (maybe a bit lispy, but hey,
> > it's lisp).
>
> > (for ((i 0.0) (< i 1.0) (+ i 0.1))
> > (print i))
>
> > just a thought.
>
> But a thought based upon missing the point entirely. The point is that
> cramming a half-dozen completely different sets of semantics into one syntax
> makes the resulting code hard for human readers. Having the code illustrate
> through visual cues that you're dealing with something which is semantically
> different aids human readers.
>
> Using the equivalent C "for" construct...
>
> for (i = 0.0; i < 1.0; i++)
> {
> print(i);
> }
>
> ...(and remembering that I'm trying to escape the C-influenced world, so
> don't make the usual error of assuming I'm a C apologist) I have the
> following information provided for free without any need for picking apart
> the code:
> - I'm entering an enumerated, top-test loop. ("for")
> - There is assignment to a variable. ("=")
> - There is an in-place increment of a variable. ("++")
> - There is a code block. ("{}")
> - There is a function invocation. ("()")
>
> Your code tells me that I'm entering an enumerated, top-test loop for free.
> After that I have to parse what's there to get the semantics.
If you think that there's no parsing going on to determine what's
going on in the C for loop, you're from a different planet than I
am. From my experience, many, many professional C programmers
write their for loops by rote, and don't really understand what's
going on. And I remember in my college C class the for loop
was a big stumbling block. Why? Because there's all this
special syntax going on. It's sort of case unto itself. It looks
like a function, but it's not. How do those semicolons work
in a function? And how often do people do this:
for(int a=0;a<10;++a);
> Yes, Lisp has its advantages. Readability isn't one of them.
It really depends. To me, the degree of regularity in the
language can and does assist readability.
dave
From: Paul F. Dietz
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3966938C.BF3B68BB@interaccess.com>
> Yes, Lisp has its advantages. Readability isn't one of them.
Your next assignment is to explain why C's type syntax is more
readable than Lisp's. :)
Paul
From: Johan Kullstam
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <m2r999opf9.fsf@euler.axel.nom>
David Bakhash <·····@alum.mit.edu> writes:
> "Michael T. Richter" <···@ottawa.com> writes:
>
> > > i admit that the boilerplate mishmash of parens, braces and semicolons
> > > can help a human find their way, e.g., i think C's for (;;){} is
> > > easier than lisp's (do ()()()).
> >
> > Yes. Finally I've met someone in the Lisp camp who recognizes this feature.
>
> bogus.
>
> But, if you really love C's `for' then just implement it in Common
> Lisp. It shouldn't be too hard to have something that looks almost
> exactly like `for' (maybe a bit lispy, but hey, it's lisp).
>
> (for ((i 0.0) (< i 1.0) (+ i 0.1))
> (print i))
however, this misses my point. well, actually i have two points
*) your lisp for still requires some parentheses counting. lisp
indents some things better than others. some expressions really are a
sea of lists.
*) C's for has many delimiters. this makes counting go away. however,
you are punished by having a crufty syntax.
on the whole, i prefer lisp syntax because it is straightforward and
doesn't get in your way when things get complex. it's really a
question of scalability.
in standard math notation, infix really isn't infix because there are
a myriad of exceptions. functions are prefix. sometimes a postfix
notation is used (permutation groups). the mix of stuff with many
rules and exceptions make things harder once the problem grows. it is
also very bad for automatic code generation.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
Johan Kullstam wrote in message ...
>it's not. i like the lisp syntax because of its clean look. more
>importantly, the syntax is what lets lisp have such powerful and
>useful macros
This is simply wrong. What makes DRM Dylan macros less
powerful than Lisp macros is that they can call general procedures
at compile-time. The syntax has nothing to do with it, except that
Lisp macros at their worst are even more unreadable than Dylan
ones. As I have already said in this so-called conversation, the
adoption of Keith Playford's procedural macros for Dylan would
make them equally as powerful as Lisp's macros.
The confusion of macro power with infix is just that -- confusion.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171460328438767@naggum.net>
* "Scott McKay" <···@mediaone.net>
| Hey, look, if the only thing that Lispers care about is having
| Lisp syntax, then they are as closed-minded as the C and Java
| communities. Syntax is trivial. Get over it.
Wow, so much _passion_ against somebody caring about something! But
why reduce somebody else's concerns to "only thing that they care
about"? How rewarding can it be to beat those strawman arguments?
You may dislike that some people care about syntax and even think
they are idiots for it, but at least have the honesty and decency to
judge them for what they think, not for some moronic attitude _you_
attribute to them out of malice, OK?
Syntax _is_ important to some people. So, too, is spelling and
grammar in natural languages. Some _always_ "disagree" with this,
however and it is usually coupled with a hostile "get over it" to
whoever points out a mistake. One could psychologize endlessly over
the causes of such intolerant hostility.
Syntax evidently forms the ways our languages develop and evolve, if
the history of programming languages is at all useful to consider,
which would imply that syntax itself in no small part shapes the way
we _think_ in our languages, especially when so much of programming
is all about making our own thoughts expressible _in_ a language, by
extending it in various ways. I therefore find it a sign of general
lack of insight into languages and human use of them to make such an
unfounded and overly broad claim as "syntax is trivial", especially
after having complained about Lisp's syntax. What was that "get
over it"? It surely does not apply _only_ to others, does it?
On the other hand, my chief gripe with fixed-grammer syntaxes is
that they enforce this artificial separation between the language
and any expression in the language, but some people never get past
the level where they only "use" a language. as opposed to be able to
_live_ with the language. [A weak reference to Richard Gabriel's
"Patterns of Software" and _inhabitable_ software.]
Finally, a twist on the old "beware of programmers with screwdrivers":
Beware of programming language designers who show disdain for syntax.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum wrote in message <················@naggum.net>...
>* "Scott McKay" <···@mediaone.net>
>| Hey, look, if the only thing that Lispers care about is having
>| Lisp syntax, then they are as closed-minded as the C and Java
>| communities. Syntax is trivial. Get over it.
>
> Wow, so much _passion_ against somebody caring about something! But
> why reduce somebody else's concerns to "only thing that they care
> about"? How rewarding can it be to beat those strawman arguments?
Perhaps you missed the "if" in that sentence?
> You may dislike that some people care about syntax and even think
> they are idiots for it, but at least have the honesty and decency to
> judge them for what they think, not for some moronic attitude _you_
> attribute to them out of malice, OK?
>
> Syntax _is_ important to some people. So, too, is spelling and
> grammar in natural languages. Some _always_ "disagree" with this,
> however and it is usually coupled with a hostile "get over it" to
> whoever points out a mistake. One could psychologize endlessly over
> the causes of such intolerant hostility.
>
> Syntax evidently forms the ways our languages develop and evolve, if
> the history of programming languages is at all useful to consider,
> which would imply that syntax itself in no small part shapes the way
> we _think_ in our languages, especially when so much of programming
> is all about making our own thoughts expressible _in_ a language, by
> extending it in various ways. I therefore find it a sign of general
> lack of insight into languages and human use of them to make such an
> unfounded and overly broad claim as "syntax is trivial", especially
> after having complained about Lisp's syntax. What was that "get
> over it"? It surely does not apply _only_ to others, does it?
If you took the time to actually learn something about modern
linguistic theory, you would see that people like Chomsky have
tried to show that surface syntax is a property derived from
much deeper underlying rules. Pinker's books are an excellent
introduction to this. I find it a sign of general lack of insight that
people think that syntax in most languages is the tough thing,
because it isn't.
> On the other hand, my chief gripe with fixed-grammer syntaxes is
> that they enforce this artificial separation between the language
> and any expression in the language, but some people never get past
> the level where they only "use" a language. as opposed to be able to
> _live_ with the language. [A weak reference to Richard Gabriel's
> "Patterns of Software" and _inhabitable_ software.]
>
> Finally, a twist on the old "beware of programmers with screwdrivers":
> Beware of programming language designers who show disdain for syntax.
I have seen evidence of "disdain for syntax". Well, except from
you, who evidently could not care less for the genuine effort
spent making Dylan's infix syntax reasonable.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171498017446243@naggum.net>
* "Scott McKay" <···@mediaone.net>
| Perhaps you missed the "if" in that sentence?
:
| If you took the time to actually learn something about ...
I don't really think I "miss" what you communicate with your "if"s.
I perceive your intentions _very_ well, actually: You're here to
show off your _personal_ superiority to anyone who dares criticize
Dylan, and especially its syntax. By the insulted tone of your
messages and your constant insults hurled towards me, it is clear
that you have failed to deal with public comments in a public way,
but instead prefer to make this a personal issue. Coupled with your
lack of observation skills is your inability to deal with what
people are actually saying in preference to arguing against
incredibly cheap strawman arguments. This imparts an impression of
a _stale_ intellect in need of self-defense at the slightest hint of
serious criticism. I don't understand what you think you could
possibly _gain_ by this, however, but I'm sure _you_ think Dylan
will go out of this stupid activity of yours as a clear-cut winner.
Maybe it's time to re-evaluate your strategy? Maybe you just ought
to deal with the fact that not everybody shares your pathetically
unenlightened (why else resort to the stupidity I have spared you
from quoting in its entirety above) view on syntax?
| I find it a sign of general lack of insight that people think that
| syntax in most languages is the tough thing, because it isn't.
I quite agree -- it isn't, but nobody ever said anything about it
being "the tough thing", dude, so where _did_ you get that cheap
straman argument? (Does it feel good to knock down strawman
arguments, or does it leave you with an empty feeling inside which
fits the sheer lack of intellectual accomplishment? Feel free to
elaborate on your arrogance and inability to read what people
actually write to defend yourself.) If you aren't bright enough to
understand that objection to or love of syntax is not even related
to the effort required to learn or use the language, I have no
resepct for the rest of your similarly shallow opinions.
_If_ you took the time to read what people say instead of believing
they said what you can most easily argue (such as it is) against,
you might actually learn something, including differences in what
people prioritize and value, but I get the impression that it's been
a while since you learned anything from anyone other than yourself,
and I certainly won't waste any more of my time on you when you are
so demonstrably devoid of ability to deal with criticism.
| > Finally, a twist on the old "beware of programmers with screwdrivers":
| > Beware of programming language designers who show disdain for syntax.
|
| I have seen evidence of "disdain for syntax".
Precisely. If you "missed" a "no" in there, perhaps you are going
to deny that you wrote "syntax is trivial, get over it", too?
| Well, except from you, who evidently could not care less for the
| genuine effort spent making Dylan's infix syntax reasonable.
So you really are _personally_ offended, now, huh? Geez, get over
yourself. If you can't deal with negative comments on your work in
public, it would be a good thing for you to try to avoid defending
_yourself_. But why spend so much _genuine effort_ at something
that you claim is _trivial_ towards those who _don't_ like it? Just
how do you propose that I reconcile your clear disdain for syntaxes
(other than your own) with that whining about respecting your work?
I don't judge your efforts, dude, I judge the results, from a number
of aspects and values and premises of my own. You do not seem to
have any respect for any such other than precisely _your_ own, which
means that communication with you is a waste of time, just like
Dylan is a waste of time, from my point of view. At this point, I
think I have to tell you that you are free to be personally insulted
by my opinion, as well as free to act _professionally_ about a
difference in opinion that does not concern you personally at all.
Good luck with you language and your syntax and your efforts. Let's
just hope you do a better job communicating with someone who cares
what you think, _professionally_.
#:Erik
--
If this is not what you expected, please alter your expectations.
From: Eric Gouriou
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395EC8C0.BF0F9D8C@cup.hp.com>
Erik Naggum wrote:
[Some character attack on Scott McKay]
Erik,
Please keep your comments to yourself if you cannot manage
a minimal level of civility. These are not advocacy newsgroups
and your flames are uncalled for.
I tried to make this point privately and politely a few hours ago,
but my mail bounced. Either there was a technical problem or the
mail address you provide when posting is invalid.
For the record, I do not remember any post from Scott McKay where
he failed to be professional and helpful. I was expecting at least
as much from a Lisp advocate - due to the respect I have for Lisp
and its users.
Regards - Eric
--
Eric Gouriou ········@cup.hp.com
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171546824561484@naggum.net>
* Eric Gouriou <········@cup.hp.com>
| [Some character attack on Scott McKay]
Really? Well, this just goes to show some people can't read
anything eyond what they already believe in.
| Please keep your comments to yourself if you cannot manage a minimal
| level of civility.
Sure, I'll make sure to ask you every time I conclude that I do, and
you probably don't.
| These are not advocacy newsgroups and your flames are uncalled for.
And here I was thinking that what I replied to was a nasty attack,
but, hey, this just goes to show that some people will excuse juat
about anything if it comes from one of their own.
| I tried to make this point privately and politely a few hours ago,
| but my mail bounced. Either there was a technical problem or the
| mail address you provide when posting is invalid.
And this shows me that you aren't interested in being helpful or
constructive. _Any_ programmer knows that having some user draw
his own conclusions about what might be the problem is useless; the
_only_ useful thing to do is to report the problem _accurately_, and
since you don't do that with something so simple as an error message
from SMTP (I got a useful message from somebody else who experienced
the same problem), there's now _some_ reason not to trust whatever
else you conclude, too.
| For the record, I do not remember any post from Scott McKay where
| he failed to be professional and helpful.
Probably true, but I didn't respond to your memory. I responded to
an actual message from Scott McKay where he acts incredibly insulted
and retorts in worse kind. Most people are nice when they are safe
and not challenged in any way. What's important is what it takes to
make them feel unsafe or challenged and what they do then. Many
people are nice only because they suppress feelings of being unsafe
or challenged, and then they turn into veritable psychopaths when
they feel they have a "right" to cease being nice, such as when they
feel that empathy can be withheld. Don't be misled by someone's
history as being nice once they are being pushed -- Scott McKay has
obviously never had to defend Dylan and its syntax before, and he
turned into a nutcase as soon as he had to. _That's_ important.
| I was expecting at least as much from a Lisp advocate - due to the
| respect I have for Lisp and its users.
I'm not responsible for your desire to think in group terms.
#:Erik
--
If this is not what you expected, please alter your expectations.
From: Ant=?ISO-8859-1?B?8w==?=nio Nunes
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <B584DAEC.219C%tonio@euronet.nl>
in article ················@naggum.net, Erik Naggum at ····@naggum.net wrote
on 7/2/00 10:13 AM:
> Most people are nice when they are safe
> and not challenged in any way. What's important is what it takes to
> make them feel unsafe or challenged and what they do then. Many
> people are nice only because they suppress feelings of being unsafe
> or challenged, and then they turn into veritable psychopaths when
> they feel they have a "right" to cease being nice, such as when they
> feel that empathy can be withheld.
So from the tone of your writings I guess you're describing yourself here
then :-)
I'm sorry to read you have such a negative view of human nature. People can
be so nice when treated with respect. This effect tends to be amplified when
they realise you continue to be respectful even when they know they are
being disrespectful to you. That's when they will often start to respect you
at a deeper level. (That's my reality anyway, hope it will be yours too one
day!).
Live well,
Ant�nio
----------------------------------------
Disapprove of sin but not of the sinner!
----------------------------------------
> So from the tone of your writings I guess you're describing yourself here
> then :-)
>
> I'm sorry to read you have such a negative view of human nature. People
can
> be so nice when treated with respect. This effect tends to be amplified
when
> they realise you continue to be respectful even when they know they are
> being disrespectful to you. That's when they will often start to respect
you
> at a deeper level. (That's my reality anyway, hope it will be yours too
one
> day!).
>
> Live well,
> Ant�nio
Isn't it wonderful how we all teach each other how to behave? Maybe we
should consider changing the name of the NG (I hope the second 'we' is not
an insult to anybody).
J.B.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171564945173966@naggum.net>
* Ant�nio Nunes <·····@euronet.nl>
| So from the tone of your writings I guess you're describing yourself
| here then :-)
You need to guess less and think omre.
| I'm sorry to read you have such a negative view of human nature.
You need to guess less and think more.
| People can be so nice when treated with respect.
Now, how does that _really_ differ from what I said?
| This effect tends to be amplified when they realise you continue to
| be respectful even when they know they are being disrespectful to
| you.
Well, I think this is an excellent idea. However, in keeping with
the very simple concept of "puting your money where you mouth is", I
wait for those who proclaim a principle to apply it to themselves.
Anybody can expound on some principle he wants _others_ to apply,
but if you refrain from applying it to yourself, you communicate a
quality of the advice given that is extremely unflattering: If it
isn't good enough for yourself, why should anyone take your advice?
| That's when they will often start to respect you at a deeper level.
| (That's my reality anyway, hope it will be yours too one day!).
It amazes me that you start off your "respectful" message with a
disrespectful grin, instead of just _doing_ what you recommend.
Such hypocrisy is utterly _disgusting_ to watch. Just quit it.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum wrote in message <················@naggum.net>...
I've trimmed all of Erik's lame attempts to hurl insults at to spare
everyone the trouble of re-reading them. Since Erik's return mail
address appears not to work, it's not actually possible to address
any of this in private.
>| Well, except from you, who evidently could not care less for the
>| genuine effort spent making Dylan's infix syntax reasonable.
>
> So you really are _personally_ offended, now, huh? Geez, get over
> yourself. If you can't deal with negative comments on your work in
> public, it would be a good thing for you to try to avoid defending
> _yourself_. But why spend so much _genuine effort_ at something
> that you claim is _trivial_ towards those who _don't_ like it? Just
> how do you propose that I reconcile your clear disdain for syntaxes
> (other than your own) with that whining about respecting your work?
For the record, I had no part in designing Dylan's infix syntax. It was
a fait accompli by the time I started doing any work on Dylan. I should
have thought that my comment earlier in this discussion about how I
was surprised to discover that I liked the infix syntax would have clued
people in to that fact. So I don't take any personal offense at all.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171575302832937@naggum.net>
* "Scott McKay" <···@mediaone.net>
| Since Erik's return mail address appears not to work, it's not
| actually possible to address any of this in private.
This is really interesting. I have logged an attempt to send mail
from ···@mediaone.net via chmls06.mediaone.net [24.147.1.144] port
42508 at 2000-07-01 23:40:41.218 UTC, and your posted this silliness
2000-07-03 00:08:47 UTC, more than 24 hours later. This is quite
telling, actually, since you blithely assume that a problem properly
reported (which a Lisp user did to another address (which anyone who
knows about WHOIS would have found in no time), but another Dylan
user whined about it in a very useless way in public) would not get
fixed for 24 hours, even when it concerns such a terribly important
basic network service as e-mail.
With such an attitude towards software problems, nobody should care
what that person might have to say about programming _languages_.
#:Erik
--
If this is not what you expected, please alter your expectations.
"Scott McKay" <···@mediaone.net> writes:
> Erik Naggum wrote in message <················@naggum.net>...
>
> I've trimmed all of Erik's lame attempts to hurl insults at to spare
> everyone the trouble of re-reading them. Since Erik's return mail
> address appears not to work, it's not actually possible to address
> any of this in private.
Actually, that's unfair. I mailed Erik in response to one of his posts
some ten days ago, and his email address worked fine.
--
·····@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
'You cannot put "The Internet" into the Recycle Bin.'
From: Rob Myers
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3961EF01.99E4229E@h2g2.com>
At the time Scott wrote this (more recently than 10 days ago), it was
correct. Erik's email was broken when I and at least two other people
tried to contact him.
He's since fixed it and shouted at us for not WHOIS-ing him to find a
backup address. :-)
- Rob.
Simon Brooke wrote:
>
> "Scott McKay" <···@mediaone.net> writes:
>
> > Erik Naggum wrote in message <················@naggum.net>...
> >
> > I've trimmed all of Erik's lame attempts to hurl insults at to spare
> > everyone the trouble of re-reading them. Since Erik's return mail
> > address appears not to work, it's not actually possible to address
> > any of this in private.
>
> Actually, that's unfair. I mailed Erik in response to one of his posts
> some ten days ago, and his email address worked fine.
--
Rob Myers - Mac Game Wonderfulness. Join us at http://www.h2g2.com/
"Don't talk to sociologists. Social practice has no sociological content."
- Art & Language.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171712702882456@naggum.net>
* Rob Myers <····@h2g2.com>
| At the time Scott wrote this (more recently than 10 days ago), it was
| correct. Erik's email was broken when I and at least two other people
| tried to contact him.
Well, it _was_ broken for -- all of 362 minutes, and fixed thanks to
a good Lisp user who informed me about the problem in a way that
made the error clear. Dylan users whined uselessly. However, Dylan
users don't believe that bugs can be fixed, so they think anything
that was broken once will remain broken. This attitude is _very_
foreign to Lisp users. Another good reason to leave the Dylan world.
Languages shape the way we think. Or not, as the case may be.
| He's since fixed it and shouted at us for not WHOIS-ing him to find a
| backup address. :-)
Dylan brilliance at it best. Again. And assuming it's a _backup_
address is one of those lovely Dylanisms. We've been getting used
to the random assumption-generator over there in comp.lang.dylan.
#:Erik
--
If this is not what you expected, please alter your expectations.
From: Rob Myers
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39620E4E.C9093FFC@h2g2.com>
Erik Naggum ranted:
>
> Well, it _was_ broken for -- all of 362 minutes, and fixed thanks to
> a good Lisp user who informed me about the problem in a way that
Are the Evil Lisp users the ones who have been replaced by space aliens?
The ones you will have to kill Come The Day? They're here, Erik, it's starting!
> Languages shape the way we think.
I didn't realise you were a Klingon speaker.
> And assuming it's a _backup_ address...
Erik, I'm sorry. Please tell me how to describe that address. I promise
I won't use the word "backup" about your email again ouside of
description of its content.
- Rob.
--
····@h2g2.com - Rob Myers - http://www.robmyers.org/
"Don't talk to sociologists. Social practice has no sociological
content."
- Art & Language.
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171719617770638@naggum.net>
* Rob Myers <····@h2g2.com>
| Are the Evil Lisp users the ones who have been replaced by space
| aliens? The ones you will have to kill Come The Day? They're here,
| Erik, it's starting!
Please leave me out of your insanity, Rob. Please ask your doctor
to reconsider the suggestion to use USENET for therapeutic purposes.
You just be calm, now. You _don't_ need to hurt yourself, OK? You
can get through this stressful period safely. Just take your anti-
psychotic medication and try to stay away from challenges to your
beliefs, and this will all be over in a couple days, OK? If you try
and avoid responding to me, you'll soon feel much better, too.
#:Erik
--
If this is not what you expected, please alter your expectations.
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> By the insulted tone of your messages and your constant insults
> hurled towards me, it is clear that you have failed to deal with
> public comments in a public way, but instead prefer to make this
> a personal issue.
Hey fuckhead: the person who invokes white supremacists in a trivial
disagreement over syntax really has nothing to complain about insults-wise.
> Maybe it's time to re-evaluate your strategy?
Maybe it is time for you hypocrites to read your own messages and follow
your own advice?
From: David Hanley
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39610F82.E7043767@ncgr.org>
Scott McKay wrote:
> Christopher Browne wrote in message ...
>
> >
> >Ah, but when you're trying to sell _Dylan_, when it has _no_ market,
> >having a community of Lisp adopters might have been a Good Thing, and
> >might well have represented a lot more than 1% of the market _for
> >Dylan_.
>
> Hey, look, if the only thing that Lispers care about is having
> Lisp syntax, then they are as closed-minded as the C and Java
> communities. Syntax is trivial. Get over it.
Actually, I thought that the simple, regular syntax greatly assists in
creation
of source-code transforming macros, which is one of the big plusses
of LISP.
dave
From: Tim Bradshaw
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <ey3vgyny1un.fsf@cley.com>
* Scott McKay wrote:
> Hey, look, if the only thing that Lispers care about is having
> Lisp syntax, then they are as closed-minded as the C and Java
> communities. Syntax is trivial. Get over it.
I kind of agree, but the world doesn't seem to: look at XML. One of
the great advantages of Lisp syntax, I think, is that it gives you
everything useful that XML does, without the nauseating complexity.
Of course Lisp somehow managed to fail to take advantage of this, so
people are now busy implementing XML interfaces to Lisp, but that's
just the usual Lisp `x, 4 years too late' syndrome.
--tim
From: Phil Stubblefield
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395D0225.4FFEE339@rpal.rockwell.com>
Erik Naggum <····@naggum.no> wrote:
>
> * "Scott McKay" <···@mediaone.net>
> |
> | Translation: I implemented Lisp and Lisp environments for 12 years.
> | I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
> | what? I like Dylan better, syntax and all.
>
> Yeah, we need more personal testimonials.
And the alternative is... impersonal ad brochures?
Seriously, I'd love to hear Lisp vs. Dylan comparisons from someone
with Scott's amount of Lisp experience. I just browsed the subject
tree at Amazon.com, and of the three books listed within "Dylan
Programming," one was a tutorial, one a reference manual, and the
third had the comment, "Incomplete and riddled with errors." I'd
rather trust the judgement of someone like Scott, who I know *gets*
Lisp.
Scott, I second David Bakhash's interest in more details from you.
Phil Stubblefield
Rockwell Palo Alto Laboratory 206/655-3204
http://www.rpal.rockwell.com/~phil ····@rpal.rockwell.com
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171389765956073@naggum.no>
* Phil Stubblefield <····@rpal.rockwell.com>
| And the alternative is... impersonal ad brochures?
Someone just getting the point would be a worthwhile alternative.
#:Erik
--
If this is not what you expected, please alter your expectations.
Phil Stubblefield wrote in message <·················@rpal.rockwell.com>...
>Erik Naggum <····@naggum.no> wrote:
>>
>> * "Scott McKay" <···@mediaone.net>
>> |
>> | Translation: I implemented Lisp and Lisp environments for 12 years.
>> | I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
>> | what? I like Dylan better, syntax and all.
>>
>> Yeah, we need more personal testimonials.
>
>And the alternative is... impersonal ad brochures?
>
>Seriously, I'd love to hear Lisp vs. Dylan comparisons from someone
>with Scott's amount of Lisp experience. I just browsed the subject
>tree at Amazon.com, and of the three books listed within "Dylan
>Programming," one was a tutorial, one a reference manual, and the
>third had the comment, "Incomplete and riddled with errors." I'd
>rather trust the judgement of someone like Scott, who I know *gets*
>Lisp.
>
>Scott, I second David Bakhash's interest in more details from you.
OK, I'll tell you some of the things I like about Dylan, and some
of the things I like better in Lisp. First the likes:
- I like Dylan's type system. I like that the "built-in" types fix into
the type system in a clean and consistent way. I like that you
can use it "typeless" but can then clamp down the types to get
better code, and more importantly, better compile-time error
detection. Going back to Lisp makes me fell butt-naked on the
type safety front; as the static-type people have been saying
for years, a lot of errors really are type errors, and Dylan does
a good job catching these.
- I am surprised to say that I have come to like the infix syntax.
For one, using type decls in Dylan is a lot easier than in Lisp,
and a lot more readable, too. Don't delude yourself into thinking
Lisp has "no syntax" (as many people claim); it does, but it's
just harder to see.
- I like Dylan's hygienic macro system. If we adopted Keith
Playford's work on procedural macros, Dylan's macros would
be very nearly as powerful as Lisp's, and many of Lisp's
pitfalls would fall away.
- I like that Dylan has a library compilation model. I like being
able to ship reusable components. I like Dylan's library and
module system.
- I like that Dylan is smaller than Common Lisp. I don't miss most
of the fat.
- Believe it or not, I now prefer the simpler method combination
in Dylan. It forces you to get your class hierarchy correct, and
not to patch it up with kludgy method combination. If you think
you haven't used kludgy method combination, I bet you're wrong.
I prided myself on how little I resorted to such kludges, but my
Dylan experiences truly showed that my pride wenteth before
a fall. (I confess that I miss the "namespace" provided by
daemon method combination, but you get used to it.)
- I like that all primitive operations are defined as generic functions,
too, unlike in Lisp.
- It's partly parental pride, but I like using HD/FD better than almost
any other programming environment I've used. Yeah, it's not as
mature or solid, but it's really good.
Now some dislikes:
- I don't like that Dylan doesn't have first-class interfaces like Java.
- I wish Dylan hadn't thrown out so much of the CLOS MOP. I would
like some of the introspection reinstated (slot descriptors, e.g.),
but could live with only compile-time MOP for doing extensions.
Obviously, I like that Dylan is truly a dialect of Lisp (closest to Eulisp,
I think) with all that Lisp gives you: dynamic types, keyword args,
higher order functions, etc.
From: Jon S Anthony
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <39610545.22C9@synquiry.com>
Scott McKay wrote:
>
> - I like Dylan's type system. I like that the "built-in" types fix into
> the type system in a clean and consistent way. I like that you
> can use it "typeless" but can then clamp down the types to get
> better code,
Up to here, I don't believe there is any real difference to CL. Not
that you are comparing...
> and more importantly, better compile-time error
> detection. Going back to Lisp makes me fell butt-naked on the
> type safety front; as the static-type people have been saying
> for years, a lot of errors really are type errors, and Dylan does
> a good job catching these.
This I simply no longer agree with. Well, for all I know _you_ do
feel "butt-naked" w/o static typing, but I don't believe there is any
significant objective reality to the proposition that it really helps
find errors or helps clear up design issues, or whatever.
I used to believe that it _did_ help a lot with errors (well, more or
less), and it is certainly true that you can give some pretty good
arguments that static typing _should_ make a difference here, but in
practice it turns out to mean more or less nothing. At least in our
experience. Having built some large (and more importantly, _complex_)
stuff in statically typed languages (Ada95, Java) as well as Common
Lisp, Common Lisp turns out to be significantly better wrt catching
and eliminating errors. This is even more true wrt "real" bugs -
logic errors. I actually kept a log on the number of errors that a
statically typed language would have saved me from at runtime (note:
this is the only real difference - it is important to realize that the
error _will_ be caught with dynamic typing just as well as with static
typing).. This currently amounts to 3 simple typos in 2MB of source.
If you are working on true safety critical and/or mission critical
control software, then the very small potential advantage of static
typing preventing a runtime error is clearly still worth it. However,
in anything else it is more than made up for by the true dynamicism,
flexibility, and inherently easier to test (and thus more likely to be
fully tested) approach provided by environments like Common Lisp.
> - I am surprised to say that I have come to like the infix syntax.
> For one, using type decls in Dylan is a lot easier than in Lisp,
I don't think this has anything to do with "infix syntax".
> - I like Dylan's hygienic macro system. If we adopted Keith
> Playford's work on procedural macros, Dylan's macros would
> be very nearly as powerful as Lisp's,
Presumably this means these would allow complete use of the entire
language and any user defined functions and macros for processing at
compile time. However, that didn't happen and (even though you try to
claim otherwise) it is likely that the effort to make this all work
smoothly with the significantly more difficult syntax had a lot to do
with this.
> not to patch it up with kludgy method combination. If you think
> you haven't used kludgy method combination, I bet you're wrong.
I haven't, and you'd be wrong. If there is any inherent problem here
it is that people use OO for things for which it shouldn't be.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
In article <·············@synquiry.com>, Jon S Anthony
<···@synquiry.com> wrote:
> This I simply no longer agree with. Well, for all I know _you_ do
> feel "butt-naked" w/o static typing, but I don't believe there is any
> significant objective reality to the proposition that it really helps
> find errors or helps clear up design issues, or whatever.
It might be interesting to compare this with "Extreme Programming"
(XP), which originated in the Smalltalk camp and describes
how you achieve high productivity and quality using a dynamic
development "environment".
--
Rainer Joswig, BU Partner,
ISION Internet AG, Steinh�ft 9, 20459 Hamburg, Germany
Tel: +49 40 3070 2950, Fax: +49 40 3070 2999
Email: ····················@ision.net WWW: http://www.ision.net/
From: David Bakhash
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <c29k8f7b0ya.fsf@nerd-xing.mit.edu>
"Scott McKay" <···@mediaone.net> writes:
> I implemented Lisp and Lisp environments for 12 years. I worked on
> Dylan for 5 years. I'm back to using Lisp again. Guess what? I like
> Dylan better, syntax and all.
if it's okay, and you feel you can expound on this (i.e. if you can
point out things in the syntactic differences), plesae do. I know that I
was averse to Dylan's syntax. But I also know the following:
when people know and love and understand something -- whatever that
something may be -- and then make a serious change (like Lisp->Dylan),
it's always hard to go back. I think I wrote a post about his
phenomenon not too long ago. Basically, it's always hard to go back to
something that breaking away from was work. It's the same thing that
makes it hard for me to live in Long Island after growing up very
sheltered and struggling to live in my own in Boston.
Of course, for me it was Pascal -> Common Lisp, and so going back to
that is hard for me. It's really all about what you see and when you
see it. I try to look at these things with as open a mind as I can, and
I simply cannot for the life of me see how the Dylan syntax is more
sensible. I'm not counter-arguing; I just want to know details -- that
is, if you feel you can do it justice. Admittedly, I have only a
cursory understanding of Dylan syntax, and so the best I can do is say
"I just don't like it as much" or something useless like that. I do
think that Dylan syntax bites, at least for me. Syntax is _extremely_
important to many programmers because there are many times when several
languages are "equivalent" in many respects, and so in the end it comes
down to which one's syntax one is most comfortable with.
Since you have lots of experience with both languages, would you agree
that the CL syntax is more expressive? more malleable? More uniform?
I would, but if you feel otherwise, I'd like to know why.
dave
David Bakhash wrote in message ...
>"Scott McKay" <···@mediaone.net> writes:
>Since you have lots of experience with both languages, would you agree
>that the CL syntax is more expressive? more malleable? More uniform?
>I would, but if you feel otherwise, I'd like to know why.
I don't actually think CL syntax is more expressive or more uniform.
The *basic* syntax of lists certainly is, but once you start adding in
all the macros and special forms, the nice uniformity goes right
down the tubes. Think of if, cond, do, defclass, ...
It's certainly more malleable, and it's certainly easier to write read
and print. There are some things for which that is a real benefit.
In fact, the slightly less malleable syntax actually makes most Dylan
macros easier to read, in my opinion, because there isn't so much
flexibility that you can do any awful thing.
From: Neel Krishnaswami
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <slrn8lsn6a.972.neelk@brick.cswv.com>
David Bakhash <·····@alum.mit.edu> wrote:
>
> Syntax is _extremely_ important to many programmers because there
> are many times when several languages are "equivalent" in many
> respects, and so in the end it comes down to which one's syntax one
> is most comfortable with.
I don't want to disparage your (or anyone else's) taste, but
for me, syntax rarely matters except when it is designed to maximize
confusion. (Eg: Perl and Python -- the two languages have nearly
identical semantics, but Perl is awk on PCP and Python isn't, so
I use Python for sysadminy things.)
But Dylan and Lisp are both clean enough; I can judge between the two
based on their feature sets. I chose Dylan, but there are features
that you might need (such as the MOP) that Dylan (deliberately)
doesn't have.
> Since you have lots of experience with both languages, would you
> agree that the CL syntax is more expressive? more malleable? More
> uniform? I would, but if you feel otherwise, I'd like to know why.
Actually, I'd say that Dylan is simpler and more uniform than Common
Lisp. There are single features of CL (such as LOOP and the FORMAT
sublanguage) that are nearly as complex as all of Dylan.
But Common Lisp has a set of powerful features Dylan doesn't. Reader
macros, compiler macros, and the ability to do computation at macro
expansion time. Dylan's macros are very close to Scheme's; they are a
hygienic pattern-expansion mechanism (plus a feature to deliberately
break hygiene).
Since I do need a comprehensive object system but don't usually need
the MOP, make frequent use of higher-order functions, and naturally
tend to write only the sorts of macros easily written with a hygienic
system, I prefer Dylan.
Neel
From: Paul F. Dietz
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395E5A82.8C429DD7@interaccess.com>
Neel Krishnaswami wrote:
> But Common Lisp has a set of powerful features Dylan doesn't. Reader
> macros, compiler macros, and the ability to do computation at macro
> expansion time. Dylan's macros are very close to Scheme's; they are a
> hygienic pattern-expansion mechanism (plus a feature to deliberately
> break hygiene).
I was interested in Dylan, but this makes me much less interested.
I use the power of CL's macros all the time.
Paul
From: Neel Krishnaswami
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <slrn8lsqtf.9bo.neelk@brick.cswv.com>
Paul F. Dietz <·····@interaccess.com> wrote:
> Neel Krishnaswami wrote:
> >
> > But Common Lisp has a set of features Dylan doesn't. Reader macros,
> > compiler macros, and the ability to do computation at macro
> > expansion time. Dylan's macros are very close to Scheme's; they are
> > a hygienic pattern-expansion mechanism (plus a feature to
> > deliberately break hygiene).
>
> I was interested in Dylan, but this makes me much less interested.
> I use the power of CL's macros all the time.
There's no shame in not liking Dylan, of course, but I still think
it's very much worth trying out.
Personally, I think much of the use of macros in Lisp is to avoid
using higher-order functions, or to work around non-generic functions
in the CL spec. These are both more natural in Dylan. I don't want to
over-sell, though: if you are writing something like Screamer, then CL
is the only thing that can do it.
Neel
From: Paul F. Dietz
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <395E8386.E8B9934D@interaccess.com>
Neel Krishnaswami wrote:
> Personally, I think much of the use of macros in Lisp is to avoid
> using higher-order functions, or to work around non-generic functions
> in the CL spec. These are both more natural in Dylan. I don't want to
> over-sell, though: if you are writing something like Screamer, then CL
> is the only thing that can do it.
My major use is in compiling sets of patterns. This involves
nontrivial computation at compile time.
Paul
[Newsgroups trimmed, since this no longer has Dylan relevance.]
Paul F. Dietz <·····@interaccess.com> wrote:
>
> My major use is in compiling sets of patterns. This involves
> nontrivial computation at compile time.
Incidentally, do you know if anyone has written a regexp or parsing
package in Common Lisp that uses this strategy to produce really fast
matchers?
It seems a natural niche for Lisp, which has a long NLP tradition, and
it could plausibly yield results that run faster than C regexp engines,
since you wouldn't need the *engine* at all -- you could just compile
to efficient custom Lisp for each pattern.
Neel
Paul F. Dietz wrote in message <·················@interaccess.com>...
>Neel Krishnaswami wrote:
>
>> Personally, I think much of the use of macros in Lisp is to avoid
>> using higher-order functions, or to work around non-generic functions
>> in the CL spec. These are both more natural in Dylan. I don't want to
>> over-sell, though: if you are writing something like Screamer, then CL
>> is the only thing that can do it.
>
>My major use is in compiling sets of patterns. This involves
>nontrivial computation at compile time.
FWIW, this is the kind of thing I probably would do in Lisp
because (1) you get to use a very simple representation
for patterns (lists that you call 'read' on), and (2) you really
do get all of Lisp's run-time at compile-time. For me, this
sort of thing happens 1% of the time; I'm sure there are
people for whom the occurrence is much higher, and they
should keep using Lisp.
Just my opinion.
In article <·····················@typhoon.ne.mediaone.net>, "Scott
McKay" <···@mediaone.net> wrote:
> Erik Naggum wrote in message <················@naggum.no>...
> >* Jason Trenouth <·····@harlequin.com>
> >| No. That was ditched a long time ago.
> >
> > Yet, curiously, that was about the same time I decided Dylan was a
> > waste of time.
> >
>
> If infix syntax was not what you expected, please alter your expectations.
>
> Translation: I implemented Lisp and Lisp environments for 12 years.
> I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
> what? I like Dylan better, syntax and all.
Hark! The voice of experience!
But could you clarify that?
1) you hate Dylan syntax, but still prefer Dylan over CL for other
reasons
2) you prefer Dylan syntax
-- Bruce
From: Steven M. Haflich
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3963FDCF.171D159E@pacbell.net>
Scott McKay wrote:
>
> Translation: I implemented Lisp and Lisp environments for 12 years.
> I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
> what? I like Dylan better, syntax and all.
Nonetheless, Scott, it's good to have you back from the dead
and participating in comp.lang.lisp again.
On 30 Jun 2000 11:40:53 +0000, Erik Naggum <····@naggum.no> wrote:
> * Jason Trenouth <·····@harlequin.com>
> | No. That was ditched a long time ago.
>
> Yet, curiously, that was about the same time I decided Dylan was a
> waste of time.
I appreciate that Lispers may dislike Dylan's compromises and miss some of the
omitted features. Apart from the syntax, want do you think of the semantics and
the feature set?
__Jason
From: Erik Naggum
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Date:
Message-ID: <3171446179158559@naggum.net>
* Jason Trenouth <·····@harlequin.com>
| Apart from the syntax, want do you think of the semantics and
| the feature set?
I thought I said that: I concluded that Dylan was a waste of time.
What kept me interested in it for a while was the Lisp-like syntax.
I didn't find the semantics and the "feature set" sufficiently
attractive on their own, and knowing how fixed-grammer languages
evolve (rampant keyworditis and logorrhea), didn't appear to be
something worth investing in at the time. However, it has been six
years, so I ordered a couple books on Dylan from Functional Objects
to see if there are any good ideas I am more likely to pick up now.
(Incidentally, I didn't see any non-Windows offerings, which means
I'm not inclinced to investigate further, as I simply don't deal
with criminals, such as Microsoft.)
#:Erik
--
If this is not what you expected, please alter your expectations.
In article <··············@gododdin.internal.jasmine.org.uk>, Simon
Brooke <·····@jasmine.org.uk> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <··································@4ax.com>, Jason Trenouth
> > <·····@harlequin.com> wrote:
> >
> > > Well, Dylan really isn't C-ish syntax. No braces (except in macro
> > > definitions), no casting, postfix type declarations, and very
> > > different (Lisp/Scheme-like) identifier conventions. Unfortunately,
> > > from the point of view of promulgating the language, Dylan's syntax
> > > looks very alien to many C programmers.
> >
> > I suspect that the guys tasked with coming up with the infix syntax
> > were
> > concerned that if it looked *too* C-like then people would expect it to
> > have C semantics.
>
> Isn't there also an (alternative) prefix syntax for Dylan? That must
> be even more lisp-like (says Simon, never having tried it).
Oh, absolutely. A lot of simple Scheme textbook programs can be
converted into prefix Dylan simply by doing a global s/lambda/method/
e.g.
(define fact (lambda (n) (if (< n 1) 1 (* n (fact (- n 1)))))) // Scheme
(define fact (method (n) (if (< n 1) 1 (* n (fact (- n 1)))))) // Dylan
Then the differences start. Scheme has a shortcut "(define (fact n) ...
)" whereas Dylan has "(define-method fact (n) ... )". Dylan lets you
replace args in the argument list with (n <integer>) as a type
declaration. Dylan has a built-in object system (and everything is an
object). But they are very, very similar.
But neither current implementation of Dylan supports the prefix syntax.
At all. It's pining for the Fjords. It's an ex-syntax. It's bleedin'
snuffed it.
-- Bruce
In article
<··················································@lp.airnews.net>,
"Marc Battyani" <·············@csi.com> wrote:
> Micro$oft has found that C++ is too hard for their average customers
and VB
> is for dummies so they made a simplified C++ (� la Java, but without
Sun...)
> with a GC, direct mapping between objects and XML etc...
[...]
Predictably, there's a lot of discussion about this in the Java group.
It does look like the "writing on the wall" for Java, and it would
certainly be, if it wasn't for IBM having rescued the language from
being just a Sun plaything. Now, looking at IBM's track record against
MS, things still look bad for Java. Too bad, Java is a step in the
right direction (or towards Pascal? :-)).
I wonder how many people out there have programmed Java only through a
MS IDE (Visual J-something)? You hire some of these programmers, put
them in front of a Unix terminal, and they are useless.
It's bothersome to have to learn the new language-du-jour, but in the
end it's all the same, right? If you are able to become a good
programmer, this skill should be on a higher level than the language
used to express it. (But don't program in VB if you can avoid it!)
glauber
--
Glauber Ribeiro
··········@my-deja.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Christian Lynbech
Subject: Re: C# : The new language from M$
Date:
Message-ID: <of3dlrtzfi.fsf@chl.tbit.dk>
>>>>> "The" == The Glauber <··········@my-deja.com> writes:
The> It's bothersome to have to learn the new language-du-jour...
Reiterates my own decision not to trust a language whose age in
decades may be counted with a single finger. :-)
---------------------------+--------------------------------------------------
Christian Lynbech | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J
Fax: +45 8675 6881 | email: ···@ericssontelebit.com
Phone: +45 8675 6828 | web: www.ericssontelebit.com
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)