C# : The new language from M$
Marc Battyani
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
The Glauber
<57D01C66CBEFE28E.0140FBE2...@lp.airnews.net>,
"Marc Battyani" <Marc_B...@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...
This is incredible! They've just reinvented Javascript! (What's next,
the wheel, perhaps?)
--
Glauber Ribeiro
thegl...@my-deja.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Before you buy.
Eugene Zaikonnikov
"Marc Battyani" <Marc_B...@csi.com> wrote in message
news:57D01C66CBEFE28E.0140FBE2...@lp.airnews.net...
[snip]
> Now we will see Java/C#/lisp threads instead of Java/lisp ones... sigh.
>
--
Eugene.
Marco Antoniotti
The Glauber <thegl...@my-deja.com> writes:
> In article
> <57D01C66CBEFE28E.0140FBE2...@lp.airnews.net>,
> "Marc Battyani" <Marc_B...@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 ===========================================
Jason Trenouth
wrote:
That was a bit flat. :-j
Surely Microsoft have just made a hash of something again? :-j
__Jason
Joe Marshall
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.
Paolo Amoroso
<vik...@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/
Philip Lijnzaad
> 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, lijn...@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
Jochen Schmidt
>
> On Tue, 27 Jun 2000 15:15:00 +0300, "Eugene Zaikonnikov"
> <vik...@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
j...@dataheaven.de
http://www.dataheaven.de
David Bakhash
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
Russell Senior
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.
sen...@aracnet.com Bellison uncorked a flood of horrible
profanity, which, translated meant, `This is
extremely unusual.' ''
David Bakhash
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
The Glauber
David Bakhash <ca...@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!)
Robert Monfera
> 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
Marc Battyani
David Bakhash <ca...@alum.mit.edu> wrote in message
news:m3wvjbv...@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
David Bakhash
> 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
David Bakhash
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
Jason Trenouth
> 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
Hannu Koivisto
| 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
Eugene Zaikonnikov
news:861z1ij...@coulee.tdb.com...
> >>>>> "Eugene" == Eugene Zaikonnikov <vik...@cit.org.by> writes:
>
> Eugene> Guess that # is an abbrevation for ++++ :)
>
> No, they are just trying to get used to looking through prison bars.
>
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.
Erik Naggum
| 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.
The Glauber
> 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" ":-)"))
Erik Naggum
| 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.
David Bakhash
> 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
Barry Margolin
>* "Eugene Zaikonnikov" <vik...@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, bar...@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.
Johan Kullstam
> * "Eugene Zaikonnikov" <vik...@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
vsync
> 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.
Christopher Browne
>* "Eugene Zaikonnikov" <vik...@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...
--
aa...@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
John Markus Bjorndalen
> 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
Bruce Hoult
cbbr...@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
Marc Battyani
"John Markus Bjorndalen" <jo...@cs.uit.no> wrote in message
news:hvhfadz...@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
Eugene Zaikonnikov
news:uitutn...@res.raytheon.com...
> Erik Naggum <er...@naggum.no> writes:
>
> > * "Eugene Zaikonnikov" <vik...@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.
>
> not sure if there is a proper swedish word for the "#" per se.
> russian could have a similar scheme.
>
probably must be spelled diez. Yuck!
Anyway I bet that C# will get some other name here.
--
Eugene.
Simon Brooke
>
> > 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.
--
si...@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.
Jason Trenouth
> Jason Trenouth <ja...@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
Reini Urban
>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
Rob Myers
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 <kpamlscdjl89ihfhs...@4ax.com>, Jason Trenouth
> <ja...@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 - ro...@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/
The Glauber
<57D01C66CBEFE28E.0140FBE2...@lp.airnews.net>,
"Marc Battyani" <Marc_B...@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
s...@usa.net
"Eugene Zaikonnikov" <vik...@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.
Michael Livshin
> In article <9622072...@cpl2500.cit.org.by>,
> "Eugene Zaikonnikov" <vik...@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.
Joe Marshall
> > 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.
Lyman Taylor
...
> 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
Lyman Taylor
...
> .... 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
oo...@my-deja.com
>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.
oo...@my-deja.com
David Bakhash <ca...@alum.mit.edu> wrote:
> Jason Trenouth <ja...@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.
Marc Battyani
<oo...@my-deja.com> wrote in message news:8jg8qk$q6h$1...@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
Kent M Pitman
> In article <9622072...@cpl2500.cit.org.by>,
> "Eugene Zaikonnikov" <vik...@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. ;-)
Christopher Browne
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...
--
cbbr...@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
Bruce Hoult
> 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
Christopher Browne
>In article <hvhfadz...@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.
>
>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...
--
cbbr...@ntlug.org - <http://www.ntlug.org/~cbbrowne/lsf.html>
?OM ERROR
Paul Foley
> s...@usa.net writes:
>> In article <9622072...@cpl2500.cit.org.by>,
>> "Eugene Zaikonnikov" <vik...@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>"))
Simon Brooke
> In article <kpamlscdjl89ihfhs...@4ax.com>, Jason Trenouth
> <ja...@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).
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
' ' <------- this blank intentionally spaced left
Jason Trenouth
> 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
Bruce Hoult
Brooke <si...@jasmine.org.uk> wrote:
> Bruce Hoult <br...@hoult.org> writes:
>
> > In article <kpamlscdjl89ihfhs...@4ax.com>, Jason Trenouth
> > <ja...@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
Erik Naggum
| 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.
Scott McKay
Erik Naggum wrote in message <31713540...@naggum.no>...
>* Jason Trenouth <ja...@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.
Jason Trenouth
> * Jason Trenouth <ja...@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
Erik Naggum
| 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".
David Bakhash
> 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
> In article <c29g0px...@nerd-xing.mit.edu>,
> David Bakhash <ca...@alum.mit.edu> wrote:
> > Jason Trenouth <ja...@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
Carl L. Gay
>
> * "Scott McKay" <s...@mediaone.net>
> | If infix syntax was not what you expected, please alter your expectations.
>
> Oh, please.
>
> | I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
> | what? I like Dylan better, syntax and all.
>
>
> 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.
Erik Naggum
| 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.
Tim Bradshaw
> 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
Phil Stubblefield
> | 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 ph...@rpal.rockwell.com
Erik Naggum
| And the alternative is... impersonal ad brochures?
Someone just getting the point would be a worthwhile alternative.
vsync
> [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)))
Bruce Hoult
McKay" <s...@mediaone.net> wrote:
> Erik Naggum wrote in message <31713540...@naggum.no>...
> >* Jason Trenouth <ja...@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
Christopher Browne
>>
>>
>> | 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.
>>
>>
>> pretty darn stupid considering it was a selling point towards a
>> community that was told "you fine people don't matter, anymore".
>
>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_.
--
cbbr...@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
>Erik Naggum <er...@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...
--
cbbr...@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
Erik Naggum
| 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.
Scott McKay
>
>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.
Scott McKay
Phil Stubblefield wrote in message <395D0225...@rpal.rockwell.com>...
>> | 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.
>
>
>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.
Scott McKay
David Bakhash wrote in message ...
>"Scott McKay" <s...@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.
Carl L. Gay
>
> * Carl L Gay wrote:
>
> > Reality sucks.
>
> 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.
Johan Kullstam
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
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Michael T. Richter
news:m2og4ha...@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".
Erik Naggum
| 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
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.
Neel Krishnaswami
>
> 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
Erik Naggum
| 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.
Paul F. Dietz
> 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
Neel Krishnaswami
> > 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
Scott McKay
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.
Scott McKay
Erik Naggum wrote in message <31714603...@naggum.net>...
>* "Scott McKay" <s...@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.
Paul F. Dietz
> 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
Eric Gouriou
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 egou...@cup.hp.com
Neel Krishnaswami
Paul F. Dietz <di...@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
Scott McKay
Paul F. Dietz wrote in message <395E8386...@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.
>
>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.
Erik Naggum
| 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_.
Simon Brooke
> "Johan Kullstam" <kull...@ne.mediaone.net> wrote in message
> news:m2og4ha...@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.
--
si...@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.
Erik Naggum
| [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.
António Nunes
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!
----------------------------------------
Janos Blazi
> 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.
Erik Naggum
| 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.
Scott McKay
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.
Erik Naggum
| 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 s...@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_.
Christian Lynbech
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: c...@ericssontelebit.com
Phone: +45 8675 6828 | web: www.ericssontelebit.com
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Tim Bradshaw
> 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
Jens Kilian
> 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 ;-)
--
mailto:j...@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]
Jon S Anthony
>
> - 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
Johan Kullstam
> "Johan Kullstam" <kull...@ne.mediaone.net> wrote in message
> news:m2og4ha...@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.
vsync
> 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)))