A question for the group: will the rise of Java mean the demise of
Lisp (which I here take to mean all flavors of Lisp, including Scheme)?
As far as I can tell there are only a very few features of Lisp that
don't exist in Java. There are no continuations, but Common Lisp
doesn't have them either, and most of the things people do with
continuations are present (threads, catch/throw). (In fact, Java is
way ahead of any other language in its support of threads.) There are
no good native code compilers, but I think that's only a matter of
time. There are no macros, which may or may not be a fixable problem.
The syntax is annoying ( ;-) to any Java fans who may be listening),
but that's hardly a show-stopper. So is Lisp dead? Are there any
compelling arguments for using Lisp over Java?
E.
--
Erann Gat ···@jpl.nasa.gov
In article <················@milo.jpl.nasa.gov>,
Erann Gat <···@hpl.nasa.gov> wrote:
(snip)
>continuations are present (threads, catch/throw). (In fact, Java is
>way ahead of any other language in its support of threads.) There are
(snip)
Hmmm... for those of us who don't know, could you briefly summarise
how Java deals with threads?
Personally, I doubt that there'll be much of a decline in Lisp
programming because of Java. Sure, it's a nice language, but it is
getting a bit bloated and overhyped - too many big firms have vested
interests in it. When the language definition settles down and decent
native code compilers are available, it'll be a force to be reckoned
with, but it's still procedural - and once people have had a taste of
how nice it can be to program in a more declarative language like
Lisp, they'll rarely want to give it up completely in favour of a
procedural language except for certain applications. Also, I worry
about big firms adding proprietary extensions to it - look what
happened to HTML, which at its conception was a wonderful idea.
Actually, I think syntax is more of an issue than you suggest. IMHO
one of the reasons Java is popular is that its syntax is close to one
of the industry standards - C/C++. Whereas, you look at languages like
Modula-3 that are technically quite excellent - a concise language
definition, strong typing with OO and opaque typing, multithreading,
network objects, and GUI libraries so portable the same code will
compile under Win95, Unix, etc., and you can program low-level stuff
easily in it if you want to (unlike Java) - free compilers have been
around for some time that produce fast native code for many platforms,
so why doesn't the language do well? In my opinion, one of the big
reasons is simply that the syntax is Pascal-like, so many are
immediately prejudiced against it - certainly I've heard many C
programmers complain about the verboseness!
Ah well.
-- Mark
m> Hmmm... for those of us who don't know, could you briefly summarise
m> how Java deals with threads?
It includes a small amount of language-level support for
synchronisation. You can declare certain methods and blocks as
needing to acquire a monitor on an object before they can proceed.
There's also a Thread class, a ThreadGroup class, and a Runnable
interface; these handle the usual thread-related things you might
expect.
I wouldn't characterise Java's support for multithreaded programming
as innovative or particularly rich; this is not to say the support it
provides is bad. It just sounds like Erann Gat hasn't seen many
(any?) other languages that support concurrent programming.
m> Personally, I doubt that there'll be much of a decline in Lisp
m> programming because of Java.
It has already had some impact and will have some more; there are many
people out there who used to be in the Lisp community and now work
only in Java (I know a fair number myself). This notwithstanding,
Lisp is perfectly capable of withering away by itself without any
external influences, and has already long since done so to all intents
and purposes commercial.
m> Whereas, you look at languages like Modula-3 that are technically
m> quite excellent [...] so why doesn't the language do well?
At least partly because Digital would not be capable of marketing
water to fish, and never tried to commercialise Modula-3 at all.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
f> [...] there are many things you *can't* do in Java, for example,
f> writing the JavaVM itself!
I fail to see how the last part of this statement can be true.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
Bryan O'Sullivan wrote:
>
> f> [...] there are many things you *can't* do in Java, for example,
> f> writing the JavaVM itself!
>
> I fail to see how the last part of this statement can be true.
I am sorry--I should have said you cannot do a *realistic*
JavaVM implementation in Java that performs well, including
the garbage collector, thread support, etc. Besides,
I am not sure if the idea of a safe class loader
makes any sense, either.
In contrast, it is entirely possible to write
an entire Modula-3 runtime in Modula-3, or the
C runtime in C. (Most people opt to write
a tiny 0.5% of the runtime in assembly.)
I think, this may be one definition of
a 'systems programming language'.
Of course, I can see you counting on the garbage
collection, thread support, and exceptions of
the bootstrapping JavaVM, but then you are
cheating because the runtime of the bootstrapping
VM was written in C, and you _are_ runing
some C code. That is, your final Java runtime
has some code linked in which was written in
C/assembly, etc.
--
Farshad Nayeri ·······@cmass.com
Critical Mass, Inc. http://www.cmass.com
Cambridge, USA +1 617 354 6277
···@flownet.com (Erann Gat) writes:
> I put this question because
> I am a Lisp fan who needs to make a case to his management and I could
> use some help.
Your best technical argument may be along these two lines:
- Java encourages a poor programming style which, in the end, will
swallow up some of the benefit Java purportedly gives you over
languages like C++. The typical Java program is not
mostly-functional, which makes it harder to maintain, document and
verify. The Java libraries encourage this. So do, as best as I can
tell from brief scans in bookstores, most of the plethora of Java
books on the market.
- Java has firmly committed itself to a partitioned-type view of the
world. If it wants to do this, it should at least provide better
typing facilities. (Pizza does, to be sure; it works well for many
programs.) But there is also great power (for those who know how to
wield it) in the predicate-typed paradigm. Raw Java is currently in
the worst possible spot: it has neither predicate typing nor a good
partitioned type system.
Of course, these are both _technical_ issues. Management may or may
not give a hoot.
'shriram
mark carroll wrote:
>
> In article <················@milo.jpl.nasa.gov>,
> Erann Gat <···@hpl.nasa.gov> wrote:
> (snip)
> >continuations are present (threads, catch/throw). (In fact, Java is
> >way ahead of any other language in its support of threads.) There are
> (snip)
>
> Hmmm... for those of us who don't know, could you briefly summarise
> how Java deals with threads?
>
> Personally, I doubt that there'll be much of a decline in Lisp
> programming because of Java. Sure, it's a nice language, but it is
> getting a bit bloated and overhyped - too many big firms have vested
> interests in it. When the language definition settles down and decent
> native code compilers are available, it'll be a force to be reckoned
> with, but it's still procedural - and once people have had a taste of
> how nice it can be to program in a more declarative language like
> Lisp, they'll rarely want to give it up completely in favour of a
> procedural language except for certain applications. Also, I worry
> about big firms adding proprietary extensions to it - look what
> happened to HTML, which at its conception was a wonderful idea.
>
> Actually, I think syntax is more of an issue than you suggest.
In many cases, syntax is an excuse. I am not trying
to discount the syntax issue, but consider the following:
- either people want to use a language, and they live
with the syntax. Come on: how about Perl, HTML, C++?!
- or people don't want to use a language, and use the "S
word" as an excuse.
Most good programmers I know can pick up new syntax in
a matter of days (of course, I mean new syntax for a reasonable
language like Scheme or Modula-3.) For most programming, I'd
personally think twice before hiring someone who wouldn't be able to
adjust to a new syntax.
-- Farshad
Farshad Nayeri <·······@cmass.com> writes:
>In many cases, syntax is an excuse. I am not trying
>to discount the syntax issue, but consider the following:
> - either people want to use a language, and they live
> with the syntax. Come on: how about Perl, HTML, C++?!
> - or people don't want to use a language, and use the "S
> word" as an excuse.
>Most good programmers I know can pick up new syntax in
>a matter of days (of course, I mean new syntax for a reasonable
>language like Scheme or Modula-3.) For most programming, I'd
>personally think twice before hiring someone who wouldn't be able to
>adjust to a new syntax.
I would think that today syntax is mush less the problem of adoption
of any language. As suggested, a person could bang on the "Bad Syntax"
if they can't think up any other reasons to not use a language. But
the traps today also the libraries and environment of the language.
The other hangup is getting the idioms of the language down. Learning
idiomatic expressions let the programmer think on a little bit higher
level above the syntax. They also help the programmer learn the syntax
because it shows it off to good use. The Smalltalk folks seem to
really like the "Patterns" stuff.
And of course, the most critical factor in language selection, is how
Cool it is. If it isn't Cool, you're fighting an uphill battle.
C++ has its own problems, but tacking learning of C++ on top of
something like MFC, and I get visions of photos of those ice climbing
guys. But, hey, it's Cool.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
* Farshad Nayeri
| In many cases, syntax is an excuse. I am not trying to discount the
| syntax issue, but consider the following:
|
| - either people want to use a language, and they live
| with the syntax. Come on: how about Perl, HTML, C++?!
|
| - or people don't want to use a language, and use the "S
| word" as an excuse.
I have wondered why the arcane syntaxes are more likely to survive than
simple syntaxes. I believe it is because people struggle with them and
discuss them more with others when they master them. I mean, you get a
certain aura of "guru" if you can answer a question on Perl syntax
immediately, or you can spot an operator precedence problem i C++, or
notice pointers being one level too shallow or deep and such irrelevancies.
you don't get much credit for remembering the syntax of `do' or `let' or
figuring out that lots of output get squeezed into the right margin because
of the value of *print-right-margin* -- it's more like you feel stupid if
you don't. you _can_ get the same kind of awe from other programmers for
writing working `format' control strings right off the bat, but then this
is even frowned upon in Lisp circles. when readability is highly valued,
the readership falls. if it looks complex, it must be hard, right? so
people get a sense of personal satisfaction from mastering the apparently
complex, even though it is semantically quite trivial.
| Most good programmers I know can pick up new syntax in a matter of days
| ... For most programming, I'd personally think twice before hiring
| someone who wouldn't be able to adjust to a new syntax.
it's not the syntaxes that people can't read that bothers me. it's the
syntaxes they invent when they need a new mini-language that makes me cry.
#\Erik
--
man who cooks while hacking eats food that has died twice.
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> After all, while Lisp is
> simpler for _us_ to use, overall it's a more demanding language. It
> demands a greater knowledge of CS in order to understand the basic
> mechanics of the language
Rubbish. You can teach functional programming (be it in Lisp, Scheme,
Haskell or ML, though in the latter two you would want a better
interface because of the sometimes-indecipherable type errors) to a
high school student with nothing more than a knowledge of algebra.
Making them equally sophisticated C++ programmers is well nigh
impossible. (It's hard enough with college graduates, it seems, but
that we might attribute to four years of mind-numbing "CS".)
Functional languages are _not_ more demanding. To the contrary, they
provide simple ways in which to be understood when all else fails.
Maybe what you mean is they also don't give you the same wide berth in
which to tinker yourself out of existence; I hardly call that
demanding a "greater knowledge of CS".
> never mind the compiler theory required to
> implement it.
Who cares? That's the "CS" part. The vast majority of them will
never write a compiler for either language. In fact, better to teach
them Lisp or Scheme, so as to reduce their likelihood of inventing yet
another little language.
'shriram
Shriram Krishnamurthi wheezed these wise words:
> > After all, while Lisp is
> > simpler for _us_ to use, overall it's a more demanding language. It
> > demands a greater knowledge of CS in order to understand the basic
> > mechanics of the language
>
> Rubbish. You can teach functional programming (be it in Lisp, Scheme,
> Haskell or ML, though in the latter two you would want a better
> interface because of the sometimes-indecipherable type errors) to a
> high school student with nothing more than a knowledge of algebra.
Where did I deny this? The C++ programmers who go around bashing other
languages are another matter.
The C++ programmers who write for the mags that I read may be a little
better, but I can't say for sure. Some of them could be just a bigoted
about programming languages, but I know that at least a few of them
have decades of experience. Some of them even have open minds, willing
to learn new tricks.
I can still sense those blank looks that I get when I mention Lisp
to such people. Even online. That may well be ignorance, rather than
stupidity, and ignorance can be fixed. Stupidity cannot.
> Making them equally sophisticated C++ programmers is well nigh
> impossible. (It's hard enough with college graduates, it seems, but
> that we might attribute to four years of mind-numbing "CS".)
Again, I agree with you. I started programming by teaching myself, and
this eventually included CS. I'm sure that it's far less mind-numbing
when you teach yourself. You can set your own pace, and apply what you
learn to problems as you learn it. (I'm assuming that this is harder
for a college graduates, not being in the "real world" at the time.)
> Functional languages are _not_ more demanding. To the contrary, they
> provide simple ways in which to be understood when all else fails.
> Maybe what you mean is they also don't give you the same wide berth in
> which to tinker yourself out of existence; I hardly call that
> demanding a "greater knowledge of CS".
Sure, if you learn them _first_. Few of us have that advantage. I
found it easy, but that could be because I learned a fair amount of
compiler theory before discovering FP. Or perhaps I just have an
aptitude for it, I dunno.
I also have an insatiable curiousity. That helps a lot. It was like I
was driven to explore this territory. Even before I knew what
compilers and interpreters were, I was thinking about this stuff. I
had no idea at the time that I was using an interpreter.
Most programmers I know are pretty clueless about this subject. OTOH,
I''m pretty clueless when it comes to graphics and almost anything to
do with numbers.
> > never mind the compiler theory required to
> > implement it.
>
> Who cares? That's the "CS" part. The vast majority of them will
> never write a compiler for either language. In fact, better to teach
> them Lisp or Scheme, so as to reduce their likelihood of inventing yet
> another little language.
My point was that when we create a DSL (Domain Specific Language) in
Lisp, we're writing a compiler. I began by doing this in Forth, and
Forth programmers take this as much for granted as Lisp programmers
do. Perhaps more so, judging by the content of newsletters like
Forthwrite (the Fig UK newsletter). Compiler theory is pretty heavy,
by most people's standards, but it's all really easy to understand
IMHO - unless you get into the meta compiler stuff.
Consider the various extensions to Lisp that use compilers, like the
Series functions, Screamer, the LOOP macro. Most of this is heavier
compiler material than the Ratfor preprocessor, the C macro processor,
or tools like lex and yacc. Well, lex and yacc...Hmm. ;)
Our familiarity with Lisp can blind us to how others see Lisp. Why is
it possible for C programmers to accept tools like lex and yacc, but
have trouble with semantics found in Lisp (and other languages), like
functional closures and continuations. As we've seen, altho tail
recursion is available in some C compilers, not all C programmers
accept that it works. I learned about such things while studying
assembly language.
Perhaps some C programmers learn a machine model that is too "high
level", not believing that anything lower level than C could exist?
The insistance of C programmers that their language is low level seems
to support this. I find it easier to map Lisp semantics into C
sematics when TRO is supported, but that's only because I'm lazy and
prefer to write simple compilers. The transformations required for CPS
aren't a big deal, but as I said, I'm lazy.
Most C programmers give me the impression that I'm only "lazy" in
contrast to those who write state of the art Lisp compilers. Compared
to the C programmers I see on UseNet, Cix, CSi, and writing in mags,
I'm far from lazy. Instead, I'm writing code beyond their (present)
understanding. They, meanwhile, may be writing code beyond _my_
(present) understanding. That could be because they're using tools or
APIs that I'm not (yet) familiar with.
So, I tend to see these things as a matter of education. The trouble
starts when people confuse the limits of their education with the
limits of the world in general, a la Peaceman.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
"As you read this: Am I dead yet?" - Rudy Rucker
Please note: my email address is gubbish
Martin Rodgers writes:
> > > After all, while Lisp is
> > > simpler for _us_ to use, overall it's a more demanding language. It
> > > demands a greater knowledge of CS in order to understand the basic
> > > mechanics of the language
> >
> > Rubbish. You can teach functional programming (be it in Lisp, Scheme,
> > Haskell or ML, though in the latter two you would want a better
> > interface because of the sometimes-indecipherable type errors) to a
> > high school student with nothing more than a knowledge of algebra.
>
> Where did I deny this? The C++ programmers who go around bashing other
> languages are another matter.
You wrote about 80 lines of text in response to me, and still didn't
address anything related to what I wrote. Your retort to this has
mentioned the mindsets of C++ programmers, stupidity, your own
personal history, more of your personal history, your insatiable
curiosity, your ignorance, compilation, compiler theory, extensions to
Lisp, lex and yacc, retinal distortion, assembly language,
understanding tail recursion via assembly language, CPS, magazines,
laziness, APIs, and concludes with:
> So, I tend to see these things as a matter of education. The trouble
> starts when people confuse the limits of their education with the
> limits of the world in general, a la Peaceman.
Label me dumb, but what are you saying? Maybe the problem is that
_you_ are unable to distinguish between CS, various miscellaneous
issues that are commonly thought to belong in CS, and pedagogy.
(Call this an ad hominem, compare me to Hitler, and we can all go
home.)
'shriram
Shriram Krishnamurthi wheezed these wise words:
> Label me dumb, but what are you saying? Maybe the problem is that
> _you_ are unable to distinguish between CS, various miscellaneous
> issues that are commonly thought to belong in CS, and pedagogy.
In my earlier post, I said:
> After all, while Lisp is
> simpler for _us_ to use, overall it's a more demanding language. It
> demands a greater knowledge of CS in order to understand the basic
> mechanics of the language
I was commenting on the way that non-Lisp programmers will see Lisp. I
was not commenting on your education, but the education of those like
Peaceman, and even those C++ programmers with a more successful
education.
In my previous posting, I said:
> Where did I deny this? The C++ programmers who go around bashing other
> languages are another matter.
I stand by this statement. You may indeed teach FP to a high school
student with nothing more than a knowledge of algebra, but a C++
programmer has already been "educated", ie. their heads will be filled
with C++ memes, the C++ model of the "machine". The FP model is a more
elegant one. Lisp OTOH is rather more than just FP. There's the
syntax, macros, and a very different view of what a program is. For
example, a program need not necessarily be a stand along entity,
distinct from the development environment that created it.
This is why I suggest that to teach a C++ programmer Lisp, you should
first pursuade them to forget everything they've learned about C++
programming, and then open their minds to Lisp programming. If there
were no differences between these two languages, then this would not
be necessary, and we'd have no C++ programmers trying to convince us
that we can't be using Lisp, because in their opinions C++ is the only
language, blah blah blah.
A few of us can learn C before we learn Lisp, and still appreciate the
virtues of Lisp. This is why I described some of my own programming
experiences. I wasn't trying to impress anyone. I was explaining how
it is that I can see a bigger picture than someone like Peaceman.
It was not my intention to flame you, BTW. I do, however, disagree
with you about the demands of Lisp on a programmer, esp a C++
programmer. Perhaps my own experiences with compilers helps me
appreciate Lisp, and so I assume that this is also true to some extent
for other Lisp programmers. I may be wrong about that.
However, it is still my experience that Lisp programmers have far more
contact with compiler theory than C++ programmers. This may say more
about the ignorance of C++ programmers than Lisp programmers, but I
don't know. Perhaps Lisp programmers just have a higher than average
level of intelligence, and take all this compiler stuff for granted.
My experience with Forth and of Forth programmers is that they too
have a greater than average contact with compiler theory, and take for
granted the ability to extend the language by adding to the compiler,
in a "bottom up" fashion.
Yep, Forth lead me directly to Lisp. Not all Lisp programmers will
have discovered the language via this route, so I don't expect
everyone to see Lisp the same way that I do. I hope that this helps
explain my position a little clearer. It could be that _my_ contact
with compiler theory gives me a different point of view, perhaps
blinding me to the obvious.
Alternately, maybe it gives me a few insights. Who knows? Only a C++
programmer who has just discovered Lisp might tell us. _We_ know Lisp
far too well to be objective about what a hypothetical C++ programmer
may see, and the fact that we've embraced Lisp makes it harder for us
to appreciate those who _cannot_.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
"As you read this: Am I dead yet?" - Rudy Rucker
Please note: my email address is gubbish
Martin Rodgers says
> After all, while Lisp is simpler for _us_ to use, overall it's a
> more demanding language. It demands a greater knowledge of CS in
> order to understand the basic mechanics of the language,
Au contraire, since it handles many things for you, I think Lisp
programming is *less* demanding. malloc/free is a CS concept you can
ignore. checking error codes is a CS concept you can ignore. No
doubt you are going to haul out "higher order functions" as a
difficult CS concept required of Lisp programmers. This is a canard,
because Lisp programming no more requires them than does C
programming. I'm not making a theoretical argument, I'm saying that
Motif uses function pointers all over the place, just like Tk and just
like Garnet. Further, I reverse your statement: because user
interface programming are commonly implemented with higher-order
values, having a language with good support for them simplifies the
"basic mechanics" of GUIs (specifically, you don't have to pass around
untyped "data" arguments to be passed to callbacks).
Scott Draves wheezed these wise words:
> Au contraire, since it handles many things for you, I think Lisp
> programming is *less* demanding. malloc/free is a CS concept you can
> ignore. checking error codes is a CS concept you can ignore. No
Oh, I agree about the freedom from the hassles of malloc/free, but
_trusting_ that a GC can work is something appears to either require a
little faith, or a deeper understanding. I guess I didn't make myself
clear enough, for which I apologise.
> doubt you are going to haul out "higher order functions" as a
> difficult CS concept required of Lisp programmers. This is a canard,
> because Lisp programming no more requires them than does C
> programming. I'm not making a theoretical argument, I'm saying that
No, I wasn't thinking specifically of higher order functions. In fact,
I don't recall anyone attacking Lisp by claiming that HOFs don't work,
or arn't "efficient" enough. I may have just forgotten such claims,
but I certainly wasn't recalling/thinking of any recently. I can think
of a number of examples of uses of HOFs in C, just in the standard C
library. There are some more in the Windows API (even Win16 has
them!), so that myth can easily be countered.
On the other hand, there's the "interator vs HOF" argument. I've never
understood the appeal of iterators, but that may be because I was
instroduced to HOFs at a early point in learning about programming.
Other programmers who encounter this idea at a "late" stage in their
programming career may have stopped learning...
Could this explain the lack of support for HOFs in Java? Even if it
does, that's Java in the past and (possibly) the present. How about
the future? I hope that Java programmers can learn a few things from
Lisp, if only so that they might write better code.
> Motif uses function pointers all over the place, just like Tk and just
> like Garnet. Further, I reverse your statement: because user
> interface programming are commonly implemented with higher-order
> values, having a language with good support for them simplifies the
> "basic mechanics" of GUIs (specifically, you don't have to pass around
> untyped "data" arguments to be passed to callbacks).
Commonly, yes. On the Windows side of the world, it's a little
different. Yes, there functions that enumerate over windows, fonts,
etc, by calling a function with a point to what we might call a
closure, making it a functional closure, most of the Windows API is
nwhere near as beautiful as Motif, Garnet, or Tk. Fortunately, we can
add frameworks to hide the unpleasant details, and many such
frameworks now exist for Windows.
The only bad news is that MFC is the dominant framework for Windows,
and people who use it appear unable to appreciate the simplicity of
even Java AWT. Instead, they criticise it for being "primitive". What
I think they mean is that it gives them less control over the details
of the user interface. One of the very features of AWT is surely that
it relieves the programmer of many tedious details, like the layout of
the bottons, labels and other interface components.
I hear a Vorlon-like voice saying, "MFC is irrelevant, Windows is
irrelevant, MFC is irrelevant." Meanwhile, somebody on TV asking
everyone, "What do you want?" Worst of all, he gives it to them!
I recall something about there being three sides, "your side, their
side, and the truth", implying that being objective is vary hard.
The average punter buying software has no interest in any of this
stuff, and why should they? Perhaps they too are irrelevant...
Should we care who uses Lisp, and who uses Java? The subject for this
thread asks, "Will Java kill Lisp?" Well, if numbers are irrelevant,
then the answer will be, "No, not until the last Lisper dies." In
which case, we have nothing to fear. It's the fact that Lispers keep
asking questions like this that makes me wonder. Maybe the numbers
_are_ important, at least to some of us here.
I never even considered the question until I began reading
comp.lang.lisp, 5 years ago. The very first thread I read here was
asking it, and it looks like no definitive answer has yet been given.
If it has, then I suggest that we put it in the Lisp FAQ. If it gets
asked so frequently because there are either unresolved issues, or the
answers are different each time, then it's worth asking again.
Here's my question: Is Java a new "threat", or just a very old one in
new clothes? What exactly _is_ the threat, anyway? The subject uses
the word "kill", but what does that mean in this context? Perhaps the
subject is just a wee bit melodramatic.
Do I detect a paradox here? ;-) A simple answer is that we're not
dicussing the reality of Lisp being threatened by Java, but the far
less serious "threat" of people believing that "Lisp is irrelevant".
Java programmers, for example, might fail to appreciate Lisp. Is that
important? Is that what we're discussing? Or is this thread just an
reminder of how superior Lisp is to Java? "Java is irrelevant"?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
ignorance is better than stupidity
you can cure ignorance
Erann Gat <···@hpl.nasa.gov> wrote in article
<················@milo.jpl.nasa.gov>...
>
>[snip]
>
> So is Lisp dead? Are there any
> compelling arguments for using Lisp over Java?
>
> E.
>
Well, how about dynamic typing? I know that I wouldn't want to use Java
instead of Lisp for the things I use Lisp for, but a combination of SmartLisp
agents getting called by Java GUI applets might be a cool environment. <g>
Bill House
http://www.housewebs.com
> --
> Erann Gat ···@jpl.nasa.gov
>
i'm using this mail software against my will, so please excuse any problems
i may cause... (such as lousy non-text formatting, etc...) thx...
Erann Gat wrote in article ...
>A question for the group: will the rise of Java mean the demise of
>Lisp (which I here take to mean all flavors of Lisp, including Scheme)?
>As far as I can tell there are only a very few features of Lisp that
>don't exist in Java. There are no continuations, but Common Lisp
>doesn't have them either, and most of the things people do with
>continuations are present (threads, catch/throw). (In fact, Java is
>way ahead of any other language in its support of threads.) There are
>no good native code compilers, but I think that's only a matter of
>time. There are no macros, which may or may not be a fixable problem.
>The syntax is annoying ( ;-) to any Java fans who may be listening),
>but that's hardly a show-stopper. So is Lisp dead? Are there any
>compelling arguments for using Lisp over Java?
:: x-platform
i was comissioned to write a large application in java, and did so --
because i was paid to do so, and -- well -- because i recommended java in
the first place. (yes, i fell for the hype... this dates back to the days
when java was alpha/beta, and we were all expecting native compilers within
a year...)
the application, which shall remain sans name, took several time longer to
complete than expected because of java's immaturity... and, though it now
runs under several platforms beyond that which was contracted for, it still
doesn't run properly under macOs (one of the two /required/ OSs.)
so: cross-platform java is NOT. each platform (win32/solaris/sgi) required
'ports'... not to mention that with each new release of java, and with each
new browser, code "breaks"... instead of having N platforms to port to and
test (linux, win, mac, whatever), we have N*NumBrowsers*NumVersions
(assuming applets, of course...)
:: dynamic software
java lacks many things that you neglect to mention; the foremost of these is
the ability to dynamically create executable code... in the product above,
and others, i used an embedded LISP interpreter to add dynamic behaviour. it
works, of course, but "good bye" performance. (assuming, of course, that you
consider java's performance acceptable in the first place.)
:: conclusion
after paying -- severly -- for my java optimism, i've returned to 'things
that work'. C, for example. i can write code that will, without question,
work on all targeted platforms... and, using C, i've taken a PD scheme
implementation, and tcl/tk, and opengl, and created a x-platform system that
actually IS x-platform... that does what i expect *every* time...
and, well, if it doesn't, i can always change the C code, can't i? :)
jdm
In article <··········@dfw-ixnews6.ix.netcom.com>, "jd marrow"
<········@ix.netcom.com> wrote:
> after paying -- severly -- for my java optimism, i've returned to 'things
> that work'. C, for example. i can write code that will, without question,
> work on all targeted platforms... and, using C, i've taken a PD scheme
> implementation, and tcl/tk, and opengl, and created a x-platform system that
> actually IS x-platform... that does what i expect *every* time...
Corel just stopped developing an
office suite for Java platforms. Instead they will
develop for Windows NT.
--
http://www.lavielle.com/~joswig/
r> Corel just stopped developing an office suite for Java platforms.
No they didn't. The newswire agencies that picked up this report got
it hopelessly screwed up. What Corel is actually doing is increasing
the amount of budget they spend on Java development from 30% to 50%.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
In article <··············@serpentine.com>, Bryan O'Sullivan
<···@serpentine.com> wrote:
> r> Corel just stopped developing an office suite for Java platforms.
>
> No they didn't. The newswire agencies that picked up this report got
> it hopelessly screwed up. What Corel is actually doing is increasing
> the amount of budget they spend on Java development from 30% to 50%.
For a discussion of this see:
http://www.zdnet.com/zdnn/content/0820/zdnn0007.html
--
http://www.lavielle.com/~joswig/
In article <·································@news.lavielle.com>,
······@lavielle.com (Rainer Joswig) wrote:
> In article <··············@serpentine.com>, Bryan O'Sullivan
> <···@serpentine.com> wrote:
>
> > r> Corel just stopped developing an office suite for Java platforms.
> >
> > No they didn't. The newswire agencies that picked up this report got
> > it hopelessly screwed up. What Corel is actually doing is increasing
> > the amount of budget they spend on Java development from 30% to 50%.
>
> For a discussion of this see:
>
> http://www.zdnet.com/zdnn/content/0820/zdnn0007.html
Sorry, wrong link. This will work:
http://www.zdnet.com/zdnn/content/zdnn/0820/zdnn0007.html
--
http://www.lavielle.com/~joswig/
jd marrow <········@ix.netcom.com> wrote:
> java lacks many things that you neglect to mention; the foremost of these
is
> the ability to dynamically create executable code... in the product
above,
Umm. Actually you shouldn't regard Java in a discussion with Lisp, but
should use Pizza instead. They added several features from the
functional languages into Java (closures for example, anonymous
functions, functions as first level objects, polymorphic functions and
classes, algebraic datatypes). Great stuff, makes Java into a really
useable language :-)
bye, Georg
> :: dynamic software
>
> java lacks many things that you neglect to mention; the foremost of these is
> the ability to dynamically create executable code... in the product above,
> and others, i used an embedded LISP interpreter to add dynamic behaviour. it
> works, of course, but "good bye" performance. (assuming, of course, that you
> consider java's performance acceptable in the first place.)
the java.lang.ClassLoader supports dynamic software. from the doc:
"The method defineClass converts an array of bytes into an instance of
class Class."
>> :: dynamic software
>>
>> java lacks many things that you neglect to mention; the foremost of these
is
>> the ability to dynamically create executable code... in the product
above,
>> and others, i used an embedded LISP interpreter to add dynamic behaviour.
it
>> works, of course, but "good bye" performance. (assuming, of course, that
you
>> consider java's performance acceptable in the first place.)
>
>the java.lang.ClassLoader supports dynamic software. from the doc:
>"The method defineClass converts an array of bytes into an instance of
>class Class."
aye, you're right of course... but you've got to have something handy to
create [eg compile to] these bytes, eh? :)
java's support for dynamically created code is equivalent to that of c...
jdm
In article <················@milo.jpl.nasa.gov>,
Erann Gat <···@hpl.nasa.gov> wrote:
>A question for the group: will the rise of Java mean the demise of
>Lisp (which I here take to mean all flavors of Lisp, including Scheme)?
>As far as I can tell there are only a very few features of Lisp that
>don't exist in Java. There are no continuations, but Common Lisp
>doesn't have them either, and most of the things people do with
>continuations are present (threads, catch/throw). (In fact, Java is
>way ahead of any other language in its support of threads.)
IMHO, Java is not way ahead of any other language in anything.
Granted that Sun wrote basic thread-handling ability into the
standard language, they provided only the basics, and neglected to
specify whether threads are cooperative (which I think is the right
answer) or preemptive. Consequently, you've got to write Java apps
to run either way.
>There are
>no good native code compilers, but I think that's only a matter of
>time.
Yup. I agree. Mind you, I don't know how good the native code
compilers are going to be, and by using such you lose one of the
more hyped benefits of Java.
>There are no macros, which may or may not be a fixable problem.
What do you mean "fixable problem"? If you mean that you can solve
any problem in Java that you could in Lisp, that's sort of trivial,
and is equally applicable to COBOL and Intercal. If you mean that
there might be something for Java comparable to Lisp macros, you need
to read _On_Lisp_ by Paul Graham. Lisp macros are wonderful.
This gets to one of my pet annoyances about Java: it's a very
limiting language. You are restricted to writing programs like
Gosling does. Common Lisp is wonderfully flexible, and C++ is
also comparatively flexible (for all its faults). Java is a 90s
version of Pascal, although done somewhat better.
Graham suggests that the best way to write something complex is to,
in effect, write a language that handles that sort of thing. Most
of his book is devoted to showing how to do that in Common Lisp.
In C++, you can treat your own classes as if they were built-in
types. In Java, there's the built-ins and then there's your classes.
>The syntax is annoying ( ;-) to any Java fans who may be listening),
>but that's hardly a show-stopper.
So what's the smiley for? Java syntax is annoying. It's annoying
in C, but most of us are willing to forgive K&R for making some bad
decisions. It's annoying in C++, but Stroustrup wanted to preserve
compatibility with C as much as possible (the C programs in K&R,
2nd edition, will in general compile and execute properly in C++).
Java is supposedly a modern language, and not intended to be line-
for-line compatible with C, so why the stupid switch statement and
operator precedence? I'd be a lot happier with Java if the folks at
Sun had set out to make new mistakes, rather than old ones. I'd also
be happier if it didn't look so much like "C++ without the possibly
confusing bits". (So why no multiple inheritance? The only people
who seem to find it confusing are C++ programmers.)
>So is Lisp dead? Are there any
>compelling arguments for using Lisp over Java?
>
Lisp doesn't look any deader than usual to me. As far as compelling
arguments:
1. Lisp macros make it possible to tailor the language to a much
greater degree than in Java (or any other language I'm familiar
with).
2. The Common Lisp Object System is much more powerful than Java's,
and certainly no harder to use.
3. Lisp handles extended-precision integers much better. Consider
multiplying two very large integers. In C or C++, you simply get
the wrong answer. In Java, it throws an exception. In Lisp, you
simply get the right answer; the penalty for overflowing the size
of a fixnum is only reduced performance.
4. Conversely, if you want the raw speed of C, you can turn off
the safety checks in Lisp. I don't think you can do that in Java.
I could go on for a while, but I don't see why. Java isn't a bad
language, but I see no reason to give up Common Lisp.
David Thornley
Thanks to all those who responded to my question. I have a few
comments on the responses:
>Well, how about dynamic typing?
Java has dynamic typing.
>Java sucks.
This isn't very helpful.
>Java has the execution speed of an interpreted
>language and the development speed of a compiled language--
>the worst of both worlds.
This is an implementation issue, not a language issue. It's ironic
to hear Lisp advocates make the same invalid arguments against Java
that C programmer often make against Lisp.
>>The syntax is annoying ( ;-) to any Java fans who may be listening),
>>but that's hardly a show-stopper.
>
>So what's the smiley for?
Because the world at large considers Lisp's syntax to be more annoying
that C/Java syntax. Just because we Lisp programmers are better than
everyone else is no excuse for us to be arrogant. ;-)
>Lisp macros are wonderful.
I agree. Macros are the only major Lisp feature that I can think of
that Java doesn't have, and probably never will. But I'd like to have
a stronger argument than that.
E.
--
Erann Gat ···@jpl.nasa.gov
Erann Gat wheezed these wise words:
> This is an implementation issue, not a language issue. It's ironic
> to hear Lisp advocates make the same invalid arguments against Java
> that C programmer often make against Lisp.
Not just Java, either. Earlier this year, a Lisp programmer was
dumping on Haskell in the same way that C/C++ programmers tend to dump
on Lisp. It's basic primate behaviour. One ape dumps on another,
smaller, ape. This ape then find yet another ape, even smaller, and
dumps on _them_. And so on. I've also seen a Lisp programmer dump on
Basic...It's a lot like watching certain sports events. Part of the
game is the taunting of fans for the opposing team. Until a few years
ago, I hadn't realised that computing was a competitive sport.
There are enough _valid_ reasons for not using Java instead of Lisp.
Just as there are plenty of valid reasons for using Java instead of
Lisp. Yep. There are _no_ heirarchies of languages! Somebody wise once
said that there are only two things wrong with human beings: their
intelligence and their need to organise themselves into heirarchies.
There are a lot of very smart programmers. Hence the problem.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
"As you read this: Am I dead yet?" - Rudy Rucker
Please note: my email address is gubbish
········@visi.com (David Thornley) writes:
> Lisp doesn't look any deader than usual to me. As far as compelling
> arguments:
> 2. The Common Lisp Object System is much more powerful than Java's,
> and certainly no harder to use.
But slower, relatively speaking. All method invocations under single
inheritance can be done in a few machine cycles (a single pointer
indirection). This doesn't happen with the MOP.
> 3. Lisp handles extended-precision integers much better. Consider
> multiplying two very large integers. In C or C++, you simply get
> the wrong answer. In Java, it throws an exception. In Lisp, you
> simply get the right answer; the penalty for overflowing the size
> of a fixnum is only reduced performance.
I'd be interested to know how often extended integers, etc are used by
LISP programmers doing "real" (i.e., not academic mind exercises)
work. If you look at many scheme implementations a big chunk of the
object accounts for implementation of the numeric tower. just curious
Also, this Java vs. LISP discussion might be more interesting if you
brought Dylan into the picture.
Matt
--
···············@jpl.nasa.gov -- I speak for myself, not for JPL.
From: David Thornley
Subject: Re: lisp integers (was Re: Will Java kill Lisp?)
Date:
Message-ID: <5tqjef$bc1$1@darla.visi.com>
In article <·················@nospam.jpl.nasa.gov>,
Matt Wette <···············@nospam.jpl.nasa.gov> wrote:
>········@visi.com (David Thornley) writes:
>> Lisp doesn't look any deader than usual to me. As far as compelling
>> arguments:
>
>> 2. The Common Lisp Object System is much more powerful than Java's,
>> and certainly no harder to use.
>
>But slower, relatively speaking. All method invocations under single
>inheritance can be done in a few machine cycles (a single pointer
>indirection). This doesn't happen with the MOP.
>
Well, yes, but speed seems to be an odd reason to use Java. If I
have to write something that will run really fast, I'm probably best
off using C or C++ or possibly Common Lisp without CLOS. If it
doesn't have to scream, CLOS is probably good enough. Java was
explicitly designed not to maximize execution speed (the designers
deliberately set other priorities higher), and therefore will
probably never run as fast as other languages.
>
>> 3. Lisp handles extended-precision integers much better. Consider
>> multiplying two very large integers. In C or C++, you simply get
>> the wrong answer. In Java, it throws an exception. In Lisp, you
>> simply get the right answer; the penalty for overflowing the size
>> of a fixnum is only reduced performance.
>
>I'd be interested to know how often extended integers, etc are used by
>LISP programmers doing "real" (i.e., not academic mind exercises)
>work. If you look at many scheme implementations a big chunk of the
>object accounts for implementation of the numeric tower. just curious
>
I'd be interested in knowing how many "real" programs just quietly
overflow and print wrong answers which are never caught. Having
worked a while in what is facetiously called the real world, I assure
you that most "real" programs are buggy and give the users wrong
information from time to time, and that that wrong information is
usually not caught. In my not so humble opinion, anything that helps
get all this stuff right is a Good Thing.
>
>Also, this Java vs. LISP discussion might be more interesting if you
>brought Dylan into the picture.
>
I think Dylan is as dead as Modula-3. With Apple dropping it, it has
no corporate sponsor willing to dump large amounts of money into selling
it. To make it, a language needs one or more of several things. One is
sponsorship. One is compatibility with previous popular languages. One
is a niche market to develop in. One, and the least of these four, is
quality. C++ made it on C compatibility and quality. Java made it
on marketing and niche placement.
The corollary is that Lisp needs a nudge, somehow, to become popular.
It has quality; all of us on comp.lang.lisp should agree on that.
It isn't particularly compatible with anything. It lacks sponsorship
and a niche market. (Possibly a niche is all we need. Any suggestions?)
David Thornley
········@visi.com (David Thornley) wrote:
> Well, yes, but speed seems to be an odd reason to use Java. If I
> have to write something that will run really fast, I'm probably best
> off using C or C++ or possibly Common Lisp without CLOS. If it
> doesn't have to scream, CLOS is probably good enough. Java was
> explicitly designed not to maximize execution speed (the designers
> deliberately set other priorities higher), and therefore will
> probably never run as fast as other languages.
That is a bit controversial.
Firstly, Java avoids some of the speed problems of C. For example, it
disallows aliasing for primitive types in many situations.
Secondly, as a cleaner language with garbage collection, it's easier to
write good code in Java than in C/C++. People are already claiming their
Java applications are faster than the C/C++ equivalent, because they were
able to design them differently and because they had more developer time
available for selecting algorithms.
Finally, Java focuses resources on JIT compiler technology. Doing
compilation at load time on the target machine provides a number of
opportunities:
o You can tune for different CPU types. Eg the 80386, 80486, and
Pentium have slightly different optimal ways of doing the same
thing.
o You can collect runtime profiling information and used it to
guide the optimiser. Eg for per-site call dispatch prediction. Or
to decide whether the speed gains of unrolling a loop or inlining
a routine will be worth the space costs. Concentrate on the 10%
of the code that consumes 90% of the time.
o You can do global optimisations because the whole application code
is available. Even in the presence of dynamic linking. If loading
a new class invalidates a decision, you can regenerate the
affected code.
Similar tricks could be used to compile C, but in practise they usually
aren't. The Java hype means the technology _will_ be developed for the JVM.
Obviously any language that compiles to the JVM will benefit.
The upshot is that to say Java "will probably never run as fast as other
languages" is probably not true. Java could well end up running as fast or
faster than C++ or C.
I don't want to compare Java speed with CLOS or Dylan. You can do that
yourself. I note that for Scheme at least, compilers to the JVM already
exist. I figure this is a good way to go for other languages, too.
One response to Java would be to identify what changes the JVM needs in
order to run Lisp well, come up with a minimal set of extensions that have
a chance of being accepted by the Java community, and make a proposal to
Sun for Java 2.0. I know there has been some talk of a "LispOS" and a
"Universal Virtual Machine". I _think_ I'm still on the mailing lists, but
I've had no traffic lately. My impression, from the discussions that I saw,
is that those attempts were over-generalising in a way the Java community
would be unlikely to accept.
Dave Harris, Swansea, UK | "Weave a circle round him thrice,
········@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
David Harris wrote:
> I know there has been some talk of a "LispOS" and a "Universal Virtual
> Machine".
I thought the latter was an IBM project (Smalltalk + Java + VB). Are there
any similar projects underway in academia or at other companies?
Regards,
-- O.L.
From: David Chase
Subject: Re: lisp integers (was Re: Will Java kill Lisp?)
Date:
Message-ID: <3402065E.45AD@world.std.com>
David Thornley wrote:
> Well, yes, but speed seems to be an odd reason to use Java. If I
> have to write something that will run really fast, I'm probably best
> off using C or C++ or possibly Common Lisp without CLOS. If it
> doesn't have to scream, CLOS is probably good enough. Java was
> explicitly designed not to maximize execution speed (the designers
> deliberately set other priorities higher), and therefore will
> probably never run as fast as other languages.
I think this is incorrect. You seem to be confusing specification
with design. The Java byte codes are relatively compilable, and I
expect that you'll be able to get interesting performance for Java
programs before the end of the year. There are a few obstacles, but
there are also places where it is possible to do better than in C
or C++, given typical uses of those languages.
> I think Dylan is as dead as Modula-3.
I think Modula-3 is less dead than Dylan.
> With Apple dropping it, it has no corporate sponsor willing to dump
> large amounts of money into selling it.
The fact that it needs large amounts of money to survive is
part of the problem. Scheme, at least, is small.
> The corollary is that Lisp needs a nudge, somehow, to become popular.
> It has quality; all of us on comp.lang.lisp should agree on that.
> It isn't particularly compatible with anything. It lacks sponsorship
> and a niche market. (Possibly a niche is all we need. Any suggestions?)
Figure out a feasible way to map Lisp onto Java bytecodes and objects.
Write a translator. Note that complaining about the obtuseness and
poor design of the JVM will help you get your work done about as much
as complaining about the x86 architecture helps me get my work done.
If the Java execution stack does not work for Scheme continuations
(it doesn't), then think of a way to map them onto threads, or onto
objects, or something, and do it. Figure out a way to demonstrate
the benefits of this (Lisp) style of writing applets to people with
money. Maybe working in Lisp would let programmers use a better
suite of tools.
--
David Chase, ·····@world.std.com
From: David Chase
Subject: Re: lisp integers (was Re: Will Java kill Lisp?)
Date:
Message-ID: <340225C6.2AC6@world.std.com>
> David Thornley wrote:
> > ... Java was
> > explicitly designed not to maximize execution speed (the designers
> > deliberately set other priorities higher), and therefore will
> > probably never run as fast as other languages.
David Chase wrote:
> > I think this is incorrect. You seem to be confusing specification
> with design.
I seem to be confused myself. I meant "confusing specification
with implementation". Obviously, the first implementation was
interpreted for purposes of portability and time-to-market, not
because the language was designed to be slow. And yes, I think
it was intended to be compiled and run pretty fast, though that
was definitely not (as you note) the highest priority.
David
(I realize this is not related to Java vs. Lisp,
or lisp integers, but I'd like to inject
a bit of factual information. I've forwarded
follow-ups to comp.lang.modula3)
> > I think Dylan is as dead as Modula-3.
>
> I think Modula-3 is less dead than Dylan.
I must admit that, for a "dead language", Modula-3
is doing quite well! For example, many successful
projects that have used it and are using it. See
http://www.cmass.com/cm3/projects.html for a partial list.
Last I checked (say, today) there were both free compilers
that are being improved actively, as well as commercial
development environments which are in use for serious
applications (http://www.cmass.com/reactor)...
Note that I am somewhat biased, but not so much in
this context. Our company builds *both* Modula-3 and
Java tools, but if I had to pick the language to
use for development of real apps, I'd pick Modula-3
over Java any day.
See http://www.m3.org/ for starting points to Modula-3 info.
-- Farshad
--
Farshad Nayeri ·······@cmass.com
Critical Mass, Inc. http://www.cmass.com
Cambridge, USA +1 617 354 6277
Matt Wette <···············@nospam.jpl.nasa.gov> writes:
>> 3. Lisp handles extended-precision integers much better. Consider
>> multiplying two very large integers. In C or C++, you simply get
>> the wrong answer. In Java, it throws an exception. In Lisp, you
>> simply get the right answer; the penalty for overflowing the size
>> of a fixnum is only reduced performance.
>I'd be interested to know how often extended integers, etc are used by
>LISP programmers doing "real" (i.e., not academic mind exercises)
>work. If you look at many scheme implementations a big chunk of the
>object accounts for implementation of the numeric tower. just curious
I think the point here is "what's the language default"? In Lisp, I
can write my program without thinking about maximum values. Later, if
it's too slow, I can look at one variable at a time and if I think it
will not overflow, declare it to be of unsave integers.
When I write in C or Java using ints, I have to think about maximum
values even in code fragments that are not time-critical. And I think
most people don't, they just write and fix the application if negative
value are printed. Just look how many static's coulnters in Unix and
NT can get negative if you have a heavily loaded machine.
To achive my goal, it would be sufficient to have an exception thrown
if a value overflows instead of automatically using unlimited
integers. In Lisp, I can get these by declaring the as integer and
compile with saveness = 3.
In Java and C, your only choice is to use objects that use unlimited
numbers by default, then tell them to throw an exception at some value
(i.e. 2^32). Since this isn't supported by the compiler, you get worse
performance and you have to implement these classes yourself. If you
find your number will alway fit into 32 bits, you declare the type to
be native integer.
But, in C and Java, you can't even do this without *major* code
changes in operations on these variables. On one hand, you don't have
operator overloading to use '+' and such on real objects, on the other
hand, you can't map native type's operators to function call syntax
without heavy macro use. . Changing a variable to int requires
replacing all function calls on this object by operators. Since C and
Java mix prefix and infix syntax, this is much more than a name
change.
C++ got this right, you can switch between native integers and object
just by changing the class name. As you can in Common Lisp.
I didn't test, by I'm sure that a descent Lisp system works with
unlimited integer values (these are not CLOS objects and they have
explicit support from the compiler) much faster than Java would on
Java objects implementing the same semantics. Not to speak of
overflow-triggered automatically conversion of numbers (this is what
Lisp does when the type is not declared). While not neccessarily a
speed advantage, it certainly saves space.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%% ···············@wavehh.hanse.de http://cracauer.cons.org %%%%%%%%%%%
%%
%% "Perhaps it IS a good day to Die! I say we ship it!"
%%
%% If you want me to read your usenet messages, don't crosspost to more
%% than 2 groups (automatic filtering). And no signatures > 4 lines :-)
%%
%% Unwanted commercial email will be billed at $250. You agree by sending.
t> Java has the execution speed of an interpreted language and the
t> development speed of a compiled language-- the worst of both
t> worlds.
I can get non-trivial Java code to run within 50% of the speed of C
code today.
t> Java has garbage collection, but no closures!
This is not true. Java 1.1 supports class features which look and
behave very much like closures. Even if it were true, so what?
t> And you still have to litter your code with checks for null
t> pointers.
And this differs from checking for nil in Lisp in what way?
There are several weaknesses in the Java language as it currently
stands (most notably the absence of parameterised classes), but basing
your complaints on inaccuracies and irrelevancies doesn't do a whole
lot for your case.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
I wrote:
> Java has the execution speed of an interpreted language
> and the development speed of a compiled language--the
> worst of both worlds.
Bryan O'Sullivan wrote:
> I can get non-trivial Java code to run within 50% of the
> speed of C code today.
You mean with a native compiler. I'm sure Java's performance
will improve with time and experience. But Java will always
be slow for a "strongly-typed" language (not because of GC,
but because of all the runtime checks and dispatching it
has to do).
My point was that Java managed to "catch on" without the
promise of execution speed, or the promise of ease of
development. Other languages are better at both. Java
caught on solely because the "net" is the next big thing,
and Java managed to associate itself with the next big
thing, and because it was careful not to alienate all
the C and C++ programmers out there.
I wrote:
> Java has garbage collection, but no closures!
Bryan:
> This is not true. Java 1.1 supports class features
> which look and behave very much like closures. Even if
> it were true, so what?
I'm not familair with 1.1 yet. What are you talking about?
Closures are extremely powerful--much more powerful than
classes. In fact, from one point of view, classes themselves
are nothing but a clumsy form of closure (that is, a function
packaged along with an environment of bound variables).
Closures don't make sense in a non-GCd language. But Java is GCd.
Not bothering to support closures in a "modern" GCd language just
seemed like an incredibly bone-headed thing to do. I can only
assume that there is something about analyzing the byte code for
safety that made them decide not to support closures. (But
somehow I suspect that it was merely a case where behaving like
C++ was more important than good design.)
> t> And you still have to litter your code with checks for null
> t> pointers.
>
> And this differs from checking for nil in Lisp in what way?
I'll try to illustrate with an example. A value of type list
can hold either a unique value representing the empty list,
or it can contain a cons cell containing an item and a value of
type list. (This definition is recursive.)
In a language like SML with a decent type system, the compiler
knows that a value of type list HAS to be one of those two
things, and it will complain loudly if you write code assuming
that the value is always only of one type or only of the other.
You have to use a type case statement and explicitly handle all
possible value types. This applies to every type built from a
union of more than one other type (from binary trees to functions
that read input and may or may not return a string depending on
whether there was input to be read).
On the other hand, a braindead language like C++ that doesn't
support discriminated unions overloads the meaning of pointers
to accomplish the above tasks by making the policy that a
pointer of value 0 is a value of an entirely different type
than a pointer of any other value.
The problem is that *any* pointer can be made 0 whether it makes
sense to allow it or not. And Java, building upon C++'s mistakes
separates the creation of the object from the creation of the
pointer that points at the object. And within that space the
pointer can be 0, which means that you, the programmer, can never
safely assume that a pointer is valid. And more than that,
Java the compiler can (almost) never safely assume that a
pointer is valid, and so must put in time-wasting checks
everywhere a new pointer is dereferenced.
And Java's inheritance model supports covariance. Another
place the programmer HAS to check for a valid pointer every
time or the code is wrong. Really dumb.
***
C++ caught on because the programming masses didn't know how
truly bad it is. Exactly the same thing seems to be happening
with Java.
-thant
--
thant at acm dot org
Erann Gat <···@hpl.nasa.gov> wrote:
>
>...So is Lisp dead? Are there any compelling arguments for
>using Lisp over Java?
Questions of the form "will the appearance of bar be the death
of foo?" are always best met with the answer "Mu". Competition
between systems is rarely a war, though the industry would like
us to think so because it gets our attention and distracts us
from choosing the competitor's products.
The success of one system almost never implies the death of
another -- though the trade press would like us to think so
because it sells magazines. (look at NeXT, for example. One
might have thought that Java would be the death of OpenStep,
but Objective-C doesn't suffer from the performance problems
Java does -- and the cross-platform promises tend to bear fruit.)
Nature abhors homogeneity. (And, frankly, I can't blame her.)
Any system as elegant as lisp (scheme, et. al) will thrive in
some way for decades upon decades.
Erann Gat wrote:
>
> (In fact, Java is way ahead of any other language
> in its support of threads.)
Erann,
I think you ought to double-check your facts on this.
For example, threads have been a standard part of
Modula-3 language since 1988. Java's integration
of threads, exceptions, and garbage collection
has pretty much been a copy of Modula-3's. (I think
even Gosling has mentioned something like this in
the past.) Of course, the public release of M3
was ahead of Java's by 5 years!! (Modula-3 got
it from Modula-2+ and Cedar/Mesa but none of
these were publicly released.)
There is also a lot more interesting multi-threaded
code written in Modula-3 over the past 10 or so years.
For example, Trestle, a fully-concurrent, multi-threaded
windowing system which was released in early 90s, etc.,
Network Objects, what Java RMI was based on, etc.
See the motivation about the design of the threads interface
as part of the Modula-3 definition:
http://www.research.digital.com/SRC/m3defn/html/intro.html#idx.14
(Actually, I recommed reading the entire introduction,
keeping in mind that it was written about 1988!)
For general information on Modula-3, see:
http://www.m3.org/
--
Farshad Nayeri ·······@cmass.com
Critical Mass, Inc. http://www.cmass.com
Cambridge, USA +1 617 354 6277
Greg Sowder (········@one.net) wrote:
: This thread has turned in to a defense of Lisp against Jave.
: Java technology is not a better programming language.
: The goal of Jave is universally portable code.
: Code that, the host computer will be able to restrict the resources which,
: the Jave programs can use.
: This < resource restriction > is to protect the host computer from Trojan
: programs.
:
: Could a similar technology be built with Lisp?
IMHO, resource restriction is better accomplished in the OS or at the OS
level. For instance in a OS where all the sensitive resource accesses
from a process can be checked by another process, basic security can be
guaranted for any language of the galaxy.
I think that Plan 9 or Hurd (GNU OS) are/can be used in that way,
because accesses to files/directories go through other processes,
and there is a possibility to define which access will go to which
process.
Anyway there are other ways/tricks/hacks to restrict access to resources:
- I've seen once that on some *BSD, there is a bitmap telling which syscalls
are allowed. If possible, remove everything but read/write (plus other
harmless but necessary syscalls) and you have security.
- Using ptrace(2) on an unstrusted process (at least with Linux), you
can get all the system calls of the process.
If the OS cannot help you, when you are running an interpreted language
where you cannot "peek"/"poke" randomly in the memory, resource access
can still be controled (for instance with Python), so similar technology
could be built with interpreted Lisp.
Probably that the issue is speed: Java used bytecodes which are
relatively low-level (and thus allow JIT) but I suppose that then they
must be checked for correctness. This is a Java design choice, no one
is obligated to act the same way. [BTW, does actually the Java bytecode
checker verify resource accesses, or just that the bytecode won't
reference data in hyperspace ?]
The real question is: can a interpreted Lisp be fast enough, or
allow absolutly safe compilation ? IMHO, there seems to be no technical
limitation.
((I know at least one other interpreted langage which was fast enough to run
a stripped-down 3D Doom-like engine, and which can be used for applets:
Caml.))
Note that all this resource restriction isn't always perfect, there is
always a possibility that _data files_ used by more than two programs,
can be written by a program to exploit bugs of the other.
-- Cedric Adjih
········@cadvision.com wrote:
>
> I would certainly like to have the ability to write WWW Applets in
> Common Lisp.
Shouldn't be that hard. Figure out how to shoehorn Common Lisp into
the Java Virtual Machine bytecodes (i.e., write a compiler/translator)
and from then you can write WWW applets in Common Lisp.
I'm not claiming this will be easy, or that anyone will want to download
the JVM translation of the Common Lisp runtime libraries, but I think
this
is technically possible, not just theoretically possible. Whether there
is a sufficient market to justify this exercise, I do not know. Scheme
minus continuations might be a much better bet. Awk would also be
entertaining.
And no, I do not think that Lisp will fit directly onto the JVM, I think
it will be a pain in places. That's pretty much the way compilation
goes,
sometimes.
--
David Chase, ·····@world.std.com
David Chase wrote:
> ········@cadvision.com wrote:
> >
> > I would certainly like to have the ability to write WWW Applets in
> > Common Lisp.
>
> Shouldn't be that hard. Figure out how to shoehorn Common Lisp into
> the Java Virtual Machine bytecodes (i.e., write a compiler/translator)
>
> and from then you can write WWW applets in Common Lisp.
There's that option, and then there's LOTS of Lisp interpreters
written in Java, and almost all of them have source code available. All
one would have to do (and I may try in the future) is snarf the code and
create a class that interprets Lisp passed as an argument. It would
probably be slow like crazy (and not half as cool!), but easier than a
Lisp to bytecode compiler.
Matt Wolak (a java programmer who also likes Lisp)
P.S.
I Love to dabble with AI and have noticed that it is much (almost
infinatly) easier in Lisp than in Java
Matt Wolak wheezed these wise words:
> There's that option, and then there's LOTS of Lisp interpreters
> written in Java, and almost all of them have source code available. All
> one would have to do (and I may try in the future) is snarf the code and
> create a class that interprets Lisp passed as an argument. It would
> probably be slow like crazy (and not half as cool!), but easier than a
> Lisp to bytecode compiler.
It should be easy to do, but could it give more ammunition to those
who claim that Lisp is slow? Calling an interpreter slow is a low
shot, but you can bet that some people will suggest that this is a
typical Lisp. Dirty tricks like that are not unusual.
Still, I don't think that's a reason for not doing it. I'd simply
prefer to add a disclaimer. ;)
My homepage has a disclaimer, BTW. As does my email address...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
"As you read this: Am I dead yet?" - Rudy Rucker
Please note: my email address is gubbish
In article <··········@pasilla.bbnplanet.com>, Barry Margolin
<······@bbnplanet.com> wrote:
> In article <··········@news-rocq.inria.fr>,
> Cedric Adjih <·····@inria.fr> wrote:
> > IMHO, resource restriction is better accomplished in the OS or at the OS
> >level. For instance in a OS where all the sensitive resource accesses
> >from a process can be checked by another process, basic security can be
> >guaranted for any language of the galaxy.
>
...deleted
>
> To do this in the OS, you need an OS that implements a very fine-grained
> capabilities-based architecture, and allows access domains to be
> constructed and defined on the fly (so you can create a domain that can
> open network connections to a specific host).
>
AFAIK Inferno (http://www.lucent.com/inferno) does this easily.
--
Best Wishes, Bengt
Email: ······@damek.kth.se
> > If any CL vendors are listening, are there any plans to produce a
> > CL Plug-In?
> Could it be that hard? It ought to be pretty easy to write a
> plug-inin lisp that would 'eat up' lisp source and run it. After all,
It isn't that hard. The hard part isn't being able to
run Lisp code, the hard part is supporting all the things that Lisp
code must do to be truly useful. Things that Java and Javascript already do
already very well, such as security issues, graphic libraries and user input,
integration with HTML forms, etc, etc.
Not to mention the memory/disk footprint that the Lisp will require.
This puts lisp back in the losing position of having to justifying its
size.
My strategy is to use Lisp on the server-side, where its power can
be used more effectively, and current practice is sorely lacking (e.g. Perl
CGI scripts). Furthermore, from the server-side, dynamically
generated javascript and java classes are possible.
-Kelly Murray ···@franz.com http://www.franz.com
···@math.ufl.edu (Kelly Murray) writes:
>Not to mention the memory/disk footprint that the Lisp will require.
>This puts lisp back in the losing position of having to justifying its
>size.
What size? If you ignore the syntax, Javascript _is_ a Lisp dialect.
I'm reading this in comp.lang.scheme, and Scheme is one of the smallest
languages, with the smallest footprints, around. (The _entire_ Scheme
system I use on this machine is smaller than two out of the three C
compilers we have for it, and isn't much bigger than the smallest, which
can't optimise.)
--
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989. Maximum penalty: 10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Pierpaolo Bernardi wrote:
> Kelly Murray (···@math.ufl.edu) wrote:
>
> [...]
>
> : Not to mention the memory/disk footprint that the Lisp will require.
>
> : This puts lisp back in the losing position of having to justifying
> its
> : size.
>
> But all the Java systems that I've looked at so far, do require a lot
> more resources than all the Common Lisps that I've looked at so far,
> both in RAM and disk space. So, whatever the reason for Lisp not
> succeding cannot be this one.
You mean the development system, or the delivered application?You
can, in fact, hand out compact java executables from several
systems: Symantec, Asymetrix, and Microsoft SDK(eech). A chess
program I wrote was an ~85K executable, which included a decent GUI.
dave
David Hanley (·····@nospan.netright.com) wrote:
: Pierpaolo Bernardi wrote:
: > Kelly Murray (···@math.ufl.edu) wrote:
: >
: > [...]
: >
: > : Not to mention the memory/disk footprint that the Lisp will require.
: >
: > : This puts lisp back in the losing position of having to justifying
: > its
: > : size.
: >
: > But all the Java systems that I've looked at so far, do require a lot
: > more resources than all the Common Lisps that I've looked at so far,
: > both in RAM and disk space. So, whatever the reason for Lisp not
: > succeding cannot be this one.
: You mean the development system, or the delivered application?
Both.
: You can, in fact, hand out compact java executables from several
: systems: Symantec, Asymetrix, and Microsoft SDK(eech). A chess
: program I wrote was an ~85K executable, which included a decent GUI.
Unfortunately, none of the systems you cite is available for my
computer. And also, you may deliver the 85K executable because you
presuppone that the people that will run your program will have
several megabytes of libraries installed in their machines. (I'm not
saying that this is bad, of course).
As for the resources use: On my 32 Mb machine running Linux, the most
trivial Java program brings the machine to an unusable state, while
the same machine runs happily all the Common Lisp code I could throw
at it.
Pierpaolo.
: dave
Pierpaolo Bernardi wrote:
> David Hanley (·····@nospan.netright.com) wrote:
>
> : Pierpaolo Bernardi wrote:
>
> : > But all the Java systems that I've looked at so far, do require a
> lot
> : > more resources than all the Common Lisps that I've looked at so
> far,
> : > both in RAM and disk space. So, whatever the reason for Lisp not
> : > succeding cannot be this one.
>
> : You mean the development system, or the delivered application?
>
> Both.
I'll have to state that this is flatly untrue, and is a direct
consquenceof the typing systems of the respective languages.
>
>
> : You can, in fact, hand out compact java executables from several
> : systems: Symantec, Asymetrix, and Microsoft SDK(eech). A chess
> : program I wrote was an ~85K executable, which included a decent GUI.
>
> Unfortunately, none of the systems you cite is available for my
> computer.
A problem, to be sure. I'm not sure if there's a good
javadevelopment package for linux. I know that with my red hat install
there was a package that would compile java to C++--but
I didn't try it.
> And also, you may deliver the 85K executable because you
> presuppone that the people that will run your program will have
> several megabytes of libraries installed in their machines. (I'm not
> saying that this is bad, of course).
Actually, it requires about 350K of libraries in three dll's.I know
this because I tried it to see what kind of install
it would take. An important thing to remember is that once
you install two applications, you win big, because the
second one is using libraries from the first.
> As for the resources use: On my 32 Mb machine running Linux, the most
> trivial Java program brings the machine to an unusable state, while
> the same machine runs happily all the Common Lisp code I could throw
> at it.
Very strange. My home machine had 32MB of ram. I was able torun a
browser, my mail program, the java development envornment,
and the developed java execuatable quite briskly under
windows '95.
Sounds to me like the java implementation under linux is very poor.
This is of course bad, but I don't think you'd think it was correct to
disregard lisp because a particular compiler was bad(slow).
In fact, the java chess program I mentioned was first written in
lisp.
It started out in allegro common lisp lite for windows. That was
no good because it couldn't make an execuatable and it limited me
to <1MB of heap. The regular version was $3000.
I tried harlequin CL but that crashed on me, and the
GUI builder was unusable. I installed LINUX to try the
LINUX lisp enviornments. Allegro LISP for linux was nice,
but doesn't include CLIM, and an text interface was unacceptable.
To be fair, I didn't try gcl, but by that time, the trial version I had
done
in java in a few hours had much faster move generation, a cute little
GUI, and I could make an compact executable. The java code
also ran quite a bit faster as well.
I really wanted to write the program in lisp, for several reasons.
I could have used the flexibility, the dymanism, and interactive
development would have been really great with this kind of
program. But I just ended up being frustrated. :( If I had
a LISP development enviornemnt as good as the ones that are
available for Java( A much younger language! ) I'd be using it.
But--alas...
dave
········@cli.di.unipi.it (Pierpaolo Bernardi) writes:
> David Hanley (·····@nospan.netright.com) wrote:
...
> As for the resources use: On my 32 Mb machine running Linux, the most
> trivial Java program brings the machine to an unusable state, while
> the same machine runs happily all the Common Lisp code I could throw
> at it.
This last is just plain untrue. I've been running Linux on a machine
with 20 megs for the last several years, and running java certainly
doesn't bring the machine to a halt. In fact, for some actual
numbers, if I start xemacs, and run a small java applet with
appletviewer on Linux here at work, "ps u" shows xemacs using 9.4% of
system memory, and the java interpreter using 2.5%. I wouldn't say
JDK on linux is fast enough to start large-scale practical java
development on Linux, but the above claim is an exaggeration.
In addition, this is another case of blaming the language for an
implemtation's problems. Kind of like using CLISP as evidence that
lisp is slow; most people on this group are aware that the ACL or CMU
lisp implementations are much faster. Likewise, the fact that there's
no good Java development environment yet for Linux (In fact there's
only Sun's JDK AFAIK) has nothing to do with Java-the-language.
--
Adam P. Jenkins Office Phone: (413) 545-3059
···············@cs.umass.edu
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQBNAzBt18UAAAECALmLVRW6EP59OrypUB4uT6ADRYGB3FfyW1wACf40cvdTfOUy
QHhM8Oy4aMWZ5RNYeY5qTkCRnvtsfGSsLRxEmN0ABRG0KUFkYW0gUC4gSmVua2lu
cyA8YXBqQHR3YWluLm9pdC51bWFzcy5lZHU+
=yzSE
-----END PGP PUBLIC KEY BLOCK-----
In article <··························@none-o--yo-biz>,
Greg Sowder <········@one.net> wrote:
>This thread has turned in to a defense of Lisp against Jave.
What's Jave? You used the term several times, so it doesn't seem like a
typo. On the other hand, I just made the same typo; I think the problem is
that "jave" is very close on the keyboard to "have", a very common word
that's probably automatic to touch typists.
>Java technology is not a better programming language.
>The goal of Jave is universally portable code.
Funny, that's been a goal of most high level languages.
>Code that, the host computer will be able to restrict the resources which,
>the Jave programs can use.
>This < resource restriction > is to protect the host computer from Trojan
>programs.
The restrictions are only applied to applets, not standalone applications.
>Could a similar technology be built with Lisp?
Probably. Lisp doesn't have low-level pointers, and can detect array
bounds and type errors; as long as you run with error checking enabled,
it's not normally possible to violate the constraints of the Lisp virtual
machine. As for the resource restrictions, those can be built into a Lisp
implementation in basically the same way they're built into a Java
implementation.
--
Barry Margolin, ······@bbnplanet.com
BBN Corporation, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
In article <················@milo.jpl.nasa.gov>, ···@hpl.nasa.gov (Erann
Gat) wrote:
[...]
>Are there any compelling arguments for using Lisp over Java?
Well, there is one thing. As there are fanatics like peaceman who hate
Lisp no matter what and will NEVER listen to any rational arguments about
its merits, there is myself. I will never listen to anything good about
Java, I simply hate it with a passion. There are some other people like me
who also have Java. Given this, there will always be a place for Lisp.
Oh sure, there are technical reasons, but thats what all the _other_
people always talk about. (:
>E.
>
>--
>Erann Gat ···@jpl.nasa.gov
B.B.
In article <············@rtl.cygnus.com> ·······@cygnus.com (Per Bothner) writes:
In article <·················@alexandria.organon.com>,
Jon S Anthony <···@alexandria.organon.com> wrote:
>This is like saying Ada generics are the "equivalent of closures".
>Sure, they can be used to do many of the things you might do with
>closures, but they are strictly a proper subset. And a proper subset
>which leaves out the most important bits. Java does not have closures.
Assuming you know what you're talking about, I would sincerely like
to know what are these "most important bits" that are left out.
Java has the equivalent of closures, but in an object-oriented form.
They seems to be as powerful as closures, though one could argue the
pragmatics (syntax etc) are more cumbersome.
Well, there we are once again at the old "all languages are equally
powerful" dilemma of holy language wars. Of course, modulo
"pragmatics" pretty much _every_ language out there has a combination
of features in the "equivalent of closures".
Programming language design is all about pragmatics.
--
-Matthias
Per Bothner <·······@cygnus.com> wrote in article
<············@rtl.cygnus.com>...
>
>[snip]
>
> Well, Java is a statically-typed language, and it does not have
> procedure types, so the type of (the instances of) the inner class
> needs to be something useful. Using an interface is one way; using
> inheritance is another.
>
You know, I earlier made the converse claim (i.e., that Lisp had dynamic
typing) in reply to the message that originally started this incarnation of the
"Will Java Kill Lisp?" thread. I cited said dynamism as a good reason to use
Lisp over Java. Yet, I noticed that in a later message, a reply to my
assertion was lumped into a group retort by our friend from NASA, to whit:
"Java has dynamic typing"
I realize that Java has an object reference type that can refer to an object of
any type, but I didn't think that this exactly qualified it as
dynamically-typed language. Is this some mixup on our friend's part between the
meanings of strongly-typed vs statically-typed, or am I just losing whatever
clarity I may have once possessed?
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
In article <··························@micron.dazsi.com>,
Bill House <······@nospam.housewebs.com> wrote:
>I realize that Java has an object reference type that can refer to an object of
>any type, but I didn't think that this exactly qualified it as
>dynamically-typed language. Is this some mixup on our friend's part between the
>meanings of strongly-typed vs statically-typed, or am I just losing whatever
>clarity I may have once possessed?
These days, there are really *three* categories of languages: statically
typed (C, Pascal), dynamically typed (Lisp, Smalltalk), and statically
typed with dynamic references/pointers (C++, Java).
The last category requires you to specify a static class for the objects
that a pointer or reference can refer to, but the actual referents may be
any subclass of it. You can only invoke operations declared in the
declaration of the static class, but when the operation is invoked, the
version appropriate for the dynamic class is run (in C++, this only occurs
for member functions marked "virtual" in the static class declaration).
--
Barry Margolin, ······@bbnplanet.com
BBN Corporation, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
In article <··························@micron.dazsi.com>, "Bill House"
<······@nospam.housewebs.com> wrote:
> I realize that Java has an object reference type that can refer to an
> object of any type, but I didn't think that this exactly qualified it as
> dynamically-typed language.
Why not? What does it take to be a dynamically typed language? Here's
a method that takes an object of any type and prints its type:
static void ptype (Object o) {
stdout.println(o + " is a " + o.getClass());
}
The result of calling:
ptype("1");
is:
1 is a class java.lang.String
Classes are themselves Objects, so you can do:
ptype("1".getClass());
and get:
class java.lang.String is a class java.lang.Class
The only way this is different from Lisp is that the primitive types
(integers, floats) do not fall in the class hierarchy, so you can't
ptype(1). However, Java provides wrapper classes for the primitives
so you can ptype an instance of java.lang.Integer.
If this isn't dynamic I don't know what is.
E.
--
Erann Gat ···@jpl.nasa.gov
In article <················@milo.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) wrote:
>
> In article <··························@micron.dazsi.com>, "Bill House"
> <······@nospam.housewebs.com> wrote:
>
> > I realize that Java has an object reference type that can refer to an
> > object of any type, but I didn't think that this exactly qualified it as
> > dynamically-typed language.
>
> Why not? What does it take to be a dynamically typed language? Here's
> a method that takes an object of any type and prints its type:
> [...]
> If this isn't dynamic I don't know what is.
In practical terms, if Java were a dynamic language you would be able to
successully compile a program containing an expression like
o.foo ();
regardless of whether the class or the interface of variable `o' declare
method `foo'. (In fact, `o' would not have to have a type declaration at
all). Only at runtime, when the expression is actually evaluated, it
would be actually checked whether the object referred to by `o' can
understand a message `foo' -- in Smalltalk, or whether the symbol `foo'
has a functional definition (and, if the definition is that of a generic
function, whether the function has any methods applicable to the object
currently bound to, or assigned to, `o') -- in Lisp.
--Vassili
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
"Bill House" <······@nospam.housewebs.com> writes:
> Per Bothner <·······@cygnus.com> wrote in article
> <············@rtl.cygnus.com>...
> >
> >[snip]
> >
> > Well, Java is a statically-typed language, and it does not have
> > procedure types, so the type of (the instances of) the inner class
> > needs to be something useful. Using an interface is one way; using
> > inheritance is another.
> >
> You know, I earlier made the converse claim (i.e., that Lisp had dynamic
> typing) in reply to the message that originally started this incarnation of the
> "Will Java Kill Lisp?" thread. I cited said dynamism as a good reason to use
> Lisp over Java. Yet, I noticed that in a later message, a reply to my
> assertion was lumped into a group retort by our friend from NASA, to whit:
>
> "Java has dynamic typing"
>
> I realize that Java has an object reference type that can refer to an object of
> any type, but I didn't think that this exactly qualified it as
> dynamically-typed language. Is this some mixup on our friend's part between the
> meanings of strongly-typed vs statically-typed, or am I just losing whatever
> clarity I may have once possessed?
I think Java if pretty flexible about typing: it doesn't really fall
neatly into the usual pigeon holes:
- it allows completely statically typed programs
- it allows "mostly" statically typed programs that occassionally
cast objects to subtypes
- it allows "mostly" dynamically typed programs, where most data
structures contain Object and are dynamically cast into useful
types
- it allows "wildly dynamic" typing, where introspection is used to
figure out at run time which methods an object provides and call
them.
About the only pigeon hole it really fits in is "strongly typed".
-mike
Mike Coffin <···@Eng.Sun.COM> wrote in article <···············@Eng.Sun.COM>...
>
>[snip an interesting observation re: Java not fitting pidgeon holes]
>
> - it allows completely statically typed programs
> - it allows "mostly" statically typed programs that occassionally
> cast objects to subtypes
> - it allows "mostly" dynamically typed programs, where most data
> structures contain Object and are dynamically cast into useful
> types
> - it allows "wildly dynamic" typing, where introspection is used to
> figure out at run time which methods an object provides and call
> them.
>
But does Java allow actual objects to change type, or allow new types to be
invented at runtime?
On the dynamic typing scale, perhaps these items are good indicators of a
language with full-blown dynamic typing, as opposed to those with some type
flexibility features.
-- Bill
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
Mike Coffin <···@Eng.Sun.COM> wrote in article <···············@Eng.Sun.COM>...
> "Bill House" <······@nospam.housewebs.com> writes:
>
> > Per Bothner <·······@cygnus.com> wrote in article
> > <············@rtl.cygnus.com>...
> > >
> > >[snip]
> > >
> > > Well, Java is a statically-typed language, and it does not have
> > > procedure types, so the type of (the instances of) the inner class
> > > needs to be something useful. Using an interface is one way; using
> > > inheritance is another.
> > >
> > You know, I earlier made the converse claim (i.e., that Lisp had dynamic
> > typing) in reply to the message that originally started this incarnation of
the
> > "Will Java Kill Lisp?" thread. I cited said dynamism as a good reason to
use
> > Lisp over Java. Yet, I noticed that in a later message, a reply to my
> > assertion was lumped into a group retort by our friend from NASA, to whit:
> >
> > "Java has dynamic typing"
> >
> > I realize that Java has an object reference type that can refer to an
object of
> > any type, but I didn't think that this exactly qualified it as
> > dynamically-typed language. Is this some mixup on our friend's part between
the
> > meanings of strongly-typed vs statically-typed, or am I just losing
whatever
> > clarity I may have once possessed?
>
> I think Java if pretty flexible about typing: it doesn't really fall
> neatly into the usual pigeon holes:
>
> - it allows completely statically typed programs
> - it allows "mostly" statically typed programs that occassionally
> cast objects to subtypes
> - it allows "mostly" dynamically typed programs, where most data
> structures contain Object and are dynamically cast into useful
> types
> - it allows "wildly dynamic" typing, where introspection is used to
> figure out at run time which methods an object provides and call
> them.
>
> About the only pigeon hole it really fits in is "strongly typed".
>
> -mike
>
>
>
>
>
> But does Java allow actual objects to change type,
No.
> or allow new types to be invented at runtime?
Yes, but they don't make it easy.
See java.lang.ClassLoader#defineClass(java.lang.String, byte[], int, int).
> On the dynamic typing scale, perhaps these items are good indicators of a
> language with full-blown dynamic typing, as opposed to those with some type
> flexibility features.
-Chris
Thant Tessman <·······@signature.below> writes:
> One disadvantage over real closures is that in order for the
> inner class to be used by another part of the program, it must
> implement an interface, and that interface must be seen in
> advance by both the user of the inner class and the producer
> of the inner class. Kind of a pain from the point of view
> of modularity.
>
Question: is this really such a problem? Isn't it implicitly the case
that both the producer and the user of a closure must be aware of it's
"interface"? Seems to me that it might be more clear to explicitly
specify the interface, the way Java does it.
> And the point still stands that Java as a language isn't
> in any way a step forward, and in many ways is a step
> backwards.
>
Can't argue with this.
joe
Thant Tessman wheezed these wise words:
> And the point still stands that Java as a language isn't
> in any way a step forward, and in many ways is a step
> backwards.
If you compare Java with Lisp, then yes it is. If you're a C++
programmer, then you may see things differently. It could be that more
programmers see Java as an alternative to C++ than as an alternative
to anything else.
This thread is considering Java as a threat to Lisp, by being an
alternative, but how realistic is that? If you're using Lisp, why
change to Java? I suspect that more C++ programmers will have reasons
to move to Java than Lisp programmers. In that sense, Java is a step
_forward_, not backward. (Memetic lanscape, etc.)
There are some C++ programmers who won't use anything but C++. They
appear to be looking at Java - and everything else - as a "poor
person's C++". It looks to me like this is not that different to how
some Lisp people look at other languages, as a "poor person's Lisp".
Was Java designed to replace Lisp? I don't think so. So why should we
care about Java? Take care to avoid falling into the Peaceman trap. If
you're doing something very different in Lisp to what most people are
doing in Java, then where is the competition? Well, there's the
competition of memes, but as I've said, I don't think that Java memes
will hurt Lisp memes as much as they'll hurt C++ memes, or as much as
C++ memes have (and may continue to) hurt Lisp.
Java is alreadty reshaping the memetic landscape, which could be why
some C++ are trying so hard to trash Java. Curiously, they're using
exactly the same arguments that they've used against Lisp, and those
arguments failed to kill Lisp. We're _winning_!
So, I don't think that this is the time to behave like religious
zealots and slag off Java just for not being Lisp. We can afford to be
a little more pragmatic than that. 10 years from now, this may change,
but by then there should be less BS spouted by C++ programmers. If we
instead find that there's BS posted by _Java_ programmers, then we may
have still moved forward. They'll have to use rather different tactics
to their C++ cousins, to avoid shooting themselves.
Or perhaps I'm completely wrong, _everybody_ is a religious zealot,
and the only rule is to fight, fight, fight?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
"As you read this: Am I dead yet?" - Rudy Rucker
Please note: my email address is gubbish
* Mike Coffin
| Now, Scheme is one of my favorite languages. And I don't claim any
| universal significance to any of the reasons stated above: it's just one
| project. But the practical arguments for Java in this project are pretty
| overwhelming.
how tolerant would Sun Microsystems, Inc, be of a project that elected
_not_ to use Java at this time? how tolerant would Sun be of excellent
reasons not to use Java presented by its own people?
#\Erik
--
404 You're better off without that file. Trust me.
e> How tolerant would Sun be of excellent reasons not to use Java
e> presented by its own people?
Given that the practical alternatives to Java for real projects are C
and C++, the number of excellent reasons not to use Java is already
small for many purposes, and shrinking fairly rapidly.
People don't have religion about Java at Sun, though; I have seen a
few successful instances where a case was made for Java being an
inappropriate language in which to implement a project.
I used to be the lead on the project Mike Coffin now leads. About 18
months ago, I gave some serious thought to reimplementing the entire
project in either Scheme or Common Lisp and sold the appropriate
managers on this idea. When Java 1.1 came out and it became clear
that it would suffice for our needs, I ditched the Lisp idea pretty
quickly, for all the reasons Mike mentions.
Of those reasons, by far the most significant in my book are that it
is very difficult to find talented Lisp programmers, and it is also
difficult to find good commercial Lisp implementations that look like
they'll still be alive and supported a few years from now.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
In article <··············@serpentine.com> Bryan O'Sullivan <···@serpentine.com> writes:
> Given that the practical alternatives to Java for real projects are C
> and C++,
I don't see this as factual, though it does seem to be the typical
perception. Certainly Ada95 is a completely viable and practical
alternative (even with full support for JVM, RMI, CORBA, etc.) IMO
(and more to the point, IME) it is cleary preferable to the three
listed, though I can see how you might claim that "even so - it is not
'good enough'" (if coming from a Lisp perspective).
> Of those reasons, by far the most significant in my book are that it
> is very difficult to find talented Lisp programmers, and it is also
> difficult to find good commercial Lisp implementations that look like
> they'll still be alive and supported a few years from now.
The problem with this (admittedly very widespread view) is that it is
simply self fulfilling prophesy. Just think if a reasonable
percentage of these people just decided that they _were_ going to use
CL. That very action would begin to eliminate in principle this
perceived problem.
/Jon
--
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
b> Given that the practical alternatives to Java for real projects are
b> C and C++, [...]
j> I don't see this as factual, though it does seem to be the typical
j> perception.
Sure it's factual. If I had my druthers, I'd write my code in
Modula-3, Scheme, or Eiffel as the fit took me, but there are a couple
of considerations I have to deal with that prevent me from doing this:
- I don't want to restrict the set of engineers I can hire who can
start working on my project without having to learn a new language,
along with possibly a new way of thinking. It's already quite hard
enough to hire smart people.
- I don't want to have to worry about whether there's a compiler and
runtime environment available for some random platform I'll need to
worry about two years from now, and I don't want to worry about
whether the compiler vendor is going to disappear because nobody
cares about their products.
If these don't seem like significant problems, that's great. I'm very
happy for you.
j> Certainly Ada95 is a completely viable and practical alternative
The only thing I much care for about Ada is that its metastasis has
now been outpaced by that of C++.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
In article <··············@serpentine.com>, Bryan O'Sullivan
<···@serpentine.com> wrote:
> b> Given that the practical alternatives to Java for real projects are
> b> C and C++, [...]
>
> j> I don't see this as factual, though it does seem to be the typical
> j> perception.
>
> Sure it's factual. If I had my druthers, I'd write my code in
> Modula-3, Scheme, or Eiffel as the fit took me, but there are a couple
> of considerations I have to deal with that prevent me from doing this:
>
> - I don't want to restrict the set of engineers I can hire who can
...deleted
>
> - I don't want to have to worry about whether there's a compiler and
> runtime environment available for some random platform I'll need to
...deleted
Let us not forget what Shaw said about resonable and unresonable people.
By beeing resonable one will never get what one wants.
--
Best Wishes, Bengt
Email: ······@damek.kth.se
In article <··············@serpentine.com>, Bryan O'Sullivan
<···@serpentine.com> wrote:
>- I don't want to restrict the set of engineers I can hire who can
> start working on my project without having to learn a new language,
> along with possibly a new way of thinking. It's already quite hard
> enough to hire smart people.
I agree that it is getting ridiculously hard to hire good software
people. BTW, rest of the world, the US, especially silicon valley,
has a severe shortage of good software people, and it looks to be
getting worse, much worse, over the next decade. (According to a
recent report, the number of cs grads is going down! What are those
students thinking?)
However, if there really is a productivity advantage to Lisp, Modula-3,
ML, etc, why not hire people and train them in the language? Good
people are always willing to learn new skills, especially when they
are getting paid for it. This might not work for a short term project,
where the start up costs would eat up your savings, but in a longer
project...
Sam
--
Necessity is the Mother of Improvisation. | Samuel S. Paik
Laziness and Greed are the Parents of Innovation| ····@webnexus.com
Speak only for self
* Samuel S. Paik
| (According to a recent report, the number of cs grads is going down!
| What are those students thinking?)
they look around and see that any uneducated fool can get hired to write
"cool" software and make a lot of money from age 16 onwards. they look
around and see that if they take a serious CS education, they will have
spent the years they could have made a lot of money _paying_ a lot of
money, instead, and few will pay them more to recover their losses.
instead of assembly languages, we have assembly-line languages, where
programmers are as interchangeable as the PC's. some (managers) actually
think this is a *great* development.
the students aren't the problem -- they think rationally in today's market.
the managers are the problem. not only do they buy Microsoft products
because Microsoft targets their marketing at untechnological managers, they
buy into Microsoft's ideas about programming, as well. nearly everybody
else in the software or hardware industries have talked to technologically
savvy people, selling products, not "feeling good, feeling safe".
unfortunately, it's not exactly considered positive for a manager to be
technologically savvy in today's business climate. my impression is that
computers have become a blue-collar thing, and that all that really counts
is the user interface. these managers will begin to pay attention only
after they have run the whole industry into the ground and they can no
longer solve all their problems with "more cheap manpower", lawsuits begin
to blame bad software, and they actually lose money on their uneducated
staff. for this to set in, another decade at today's speed will suffice,
and I believe we are still accelerating. it would take an extremely
insightful 16-year-old to consider the long view instead of the several
hundred thousand dollars he can reap while the managers destroy everything.
#\Erik
--
404 You're better off without that file. Trust me.
Erik Naggum wheezed these wise words:
> the students aren't the problem -- they think rationally in today's market.
> the managers are the problem. not only do they buy Microsoft products
> because Microsoft targets their marketing at untechnological managers, they
> buy into Microsoft's ideas about programming, as well. nearly everybody
> else in the software or hardware industries have talked to technologically
> savvy people, selling products, not "feeling good, feeling safe".
Absolutely! I've said this myself. These days, it's more business than
engineering. I don't think that this is a purely MS problem, as I bet
that anyone at the top will be doing the same thing, and getting the
same flak. Look at other industries, and see how many of them operate
in the same way. It's disgusting, but it's far from unique.
Not that this is any kind of excuse. I don't expect the record
industry to stop cheating, or cynically selling artists that they
_know_ are crap, and even admit that they're crap to music journos.
Nor do I forgive it. They lie, they cheat, they sell us crap at
extortionate prices, and then they have the gall to cry about what
they call "home taping", when it's reallythe big business bootlegging
that is losing them money.
No, I find these excuses sickening, but I see the same things
happening in the software industry. It's all sold on CD, anyway.
I've just read a comment about managers in another ng. "They don't
even know the marketing information, so why should they learn anything
about the technology?" Good question. What's that saying, about how
managers are eventually promoted one level above their competency?
We only need to read Dilbert to know them for what they are. Sadly,
they too read Dilbert, and think that it's about somebody else!
> unfortunately, it's not exactly considered positive for a manager to be
> technologically savvy in today's business climate. my impression is that
> computers have become a blue-collar thing, and that all that really counts
> is the user interface.
Alas, it's users who like the friendly user interfaces. At least,
that's what the people I know in support jobs tell me. Perhaps they
only say that because it makes their jobs easier, but it could still
be called a "crowd pleaser". If less corporate time is wasted, thanks
to a good quality user interface, then we should not be suprised if an
increasing amount of time is spent on this part of the software.
Years ago, I decided that programmers should not design user
interfaces, as we have a very different point of view from users.
Ideally, we'd have some kind of design tool that let's specialists
design the user interface, while us programmers get on with the more
interesting side of development.
15 years later, I'm still waiting for this idea to take off on a big
scale. Some tools exist, in a crude form, so maybe my dream isn't so
far away now. The part that's missing is the link between the code and
the user interface, i.e. the protocol. That part still has to be
written by hand, in most UI frameworks. Even MS can't get that right.
They assume that the programmer will create _both_ parts, the front
end and the back, together. Where as I want to complete detach them,
so that different people can work them completely independantly.
Ideally, the user interface would be generated automagically, by a
tool that just looks at the code and makes it available via a desktop.
Well, we're getting there. Someday, programmers will be able to forget
the interface, and the user. They'll just write the code that does the
real work. Most of this is already available, but it's not yet
automagical enough to be transparent to the programmer, what _is_
available isn't used by enough programmers yet.
Worst of all, most of it still being done using C++. Yeuch.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
ignorance is better than stupidity
you can cure ignorance
Martin Rodgers wrote in article ...
>Years ago, I decided that programmers should not design user
>interfaces, as we have a very different point of view from users.
>Ideally, we'd have some kind of design tool that let's specialists
>design the user interface, while us programmers get on with the more
>interesting side of development.
Actually, a mediator is still needed. Most users, when they sit down
to "design" a UI come up with a big bag o'undifferentiated and misbe-
gotten functions from hell, tied together via a disorganized menu structure
with lots of special modal behavior that makes learning the system
a nightmare. In addition, the UI is generally only fit for their VERY
specific use. If you need an example, look at most non-professional
web pages (which are, in fact, a UI into an information repository).
And, BTW, most "programmers" and "software engineers" (or whatever
you want to call the techno-grunts who grind code) do just as poor of
a job at UI design as the users they believe they serve (take it from one
who has been there and has learned to acknowledge his limitations).
All-in-all, the need for formal UI designers is still there.
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
Frank A. Adrian wheezed these wise words:
> Actually, a mediator is still needed. Most users, when they sit down
> to "design" a UI come up with a big bag o'undifferentiated and misbe-
> gotten functions from hell, tied together via a disorganized menu structure
> with lots of special modal behavior that makes learning the system
> a nightmare. In addition, the UI is generally only fit for their VERY
> specific use. If you need an example, look at most non-professional
> web pages (which are, in fact, a UI into an information repository).
Yes, this what I was saying about the need for user interface design
specialists. I also agree about most web pages, even some that are
produced "professionally". Perhaps they're the result of designing in-
house, under the assumption that the people responsible for the raw
content will be the best people to write the HTML for it. It may even
be plain old politics, and not wishing to let outsiders "interfere".
What ever the reasons, I like the idea of leaving the design to people
who specliase in design, and letting everyone else get on with what
_they're_ good at.
> And, BTW, most "programmers" and "software engineers" (or whatever
> you want to call the techno-grunts who grind code) do just as poor of
> a job at UI design as the users they believe they serve (take it from one
> who has been there and has learned to acknowledge his limitations).
Generally, they just pick the basic components and stick them into
their app, regardless for well the interface works for the user.
Instead, it looks like the criteria is mainly ease of coding.
> All-in-all, the need for formal UI designers is still there.
Agreed. At least for now, anyway. We should eventually see a way of
letting the OS synthesise the UI, using meta info provided by the
application/document, describing the data operations available, and
how they relate to each other, etc.
Either that's not yet been done, or it's there already, but none of
the big OS vendors has adopted it yet, or it's a well kept secret. ;)
Anyway, we can see an increasing number of UI tools (that's always
been true), and now a few of them are getting a lot of special
attention. There's a lot of hype about "thin clients", but I hope this
will calm down, so we'll then have a more sober atmosphere in which to
evaluate these tools. One positive thing that we can say about them,
even now, is that they're allowing the programmers who create the UI
to be different from the programmers who write the "back end", and
while this is nothing new, there's a lot of attention on it.
(Looking at the subject of this thread...) Who knows? Maybe Lisp and
Java can complement each other. If so, then we could be asking whether
Lisp will kill _Java_. :-)
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
ignorance is better than stupidity
you can cure ignorance
Samuel S. Paik wrote:
>
> (According to a recent report, the number of cs grads is going down!
> What are those students thinking?)
They're thinking, "take the job today, or take the job four years from
now and sixty thousand dollars in debt."
Erik Naggum wrote:
>
> they look around and see that any uneducated fool can get hired to write
> "cool" software and make a lot of money from age 16 onwards. they look
> around and see that if they take a serious CS education, they will have
> spent the years they could have made a lot of money _paying_ a lot of
> money, instead, and few will pay them more to recover their losses.
Hey, I resemble that remark!
I never went to college. The best hackers I've ever met never
graduated. I think that staying in school until the bitter end says
more about your ability to follow orders and your lack of desire to
actually get to the point and produce software that real people use,
than it says about your knowlege, skill, or critical reasoning ability.
Don't equate "formal education" with "education." The two are largely
orthogonal.
I don't think Microsoft has anything to do with this.
--
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
At any time, at any place, our snipers can drop you. Have a nice day.
* Erik Naggum
| they look around and see that any uneducated fool can get hired to write
| "cool" software and make a lot of money from age 16 onwards. they look
| around and see that if they take a serious CS education, they will have
| spent the years they could have made a lot of money _paying_ a lot of
| money, instead, and few will pay them more to recover their losses.
* Jamie Zawinski
| Hey, I resemble that remark!
so do I, except I was 16 before today's 16-year-olds were born. times have
changed. the kids who do this now just want "quick bucks", not education.
back then hackers actively sought education, in any way they could find it,
which was way faster than most universities would pace the material, and
way deeper into it.
#\Erik
--
404 You're better off without that file. Trust me.
Erik Naggum wrote:
>
> so do I, except I was 16 before today's 16-year-olds were born. times have
> changed. the kids who do this now just want "quick bucks", not education.
I don't buy it. Starting any statement with "these kids today" is
grumpy-old-man thinking. Hackers are hackers. I haven't met too
many sixteen year olds recently, but the few who have made their
way into my office or mailbox have lived up to my expectations of
what kind of people they would be.
> back then hackers actively sought education, in any way they could find it,
> which was way faster than most universities would pace the material, and
> way deeper into it.
So hackers today don't do that? If they don't, they're not hackers.
Or are you claiming that universities today are faster paced and go
deeper than they did a decade or two ago?
--
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
At any time, at any place, our snipers can drop you. Have a nice day.
* Jamie Zawinski
| Starting any statement with "these kids today" is grumpy-old-man
| thinking. Hackers are hackers. I haven't met too many sixteen year olds
| recently, but the few who have made their way into my office or mailbox
| have lived up to my expectations of what kind of people they would be.
computers, programming languages, and tools have all become vastly more
complex. the focus on appearance in modern software translates to very
time-consuming, manual work for the programmer. there is growing concern
that good, compact code is so much harder to maintain and company loyalty
is so low that managers prefer to hire less educated programmers. there is
more demand on kids to go through formal education and get good grades.
these are changes in the outside world that intelligent kids respond to in
the best way they can. their response is to go for the quick buck and not
to spend time on learning more than to operate bleeding-edge tools that
will be obsolete in a few months. I don't think I'm a grumpy old man, but
I remember that I had time to spend on stuff that had no immediate value to
me, but which were just fun to discover, but from what I see, there appears
to be very little time left for those who don't want to drop out of the
system completely for this kind of exploratory playing.
#\Erik
--
404 You're better off without that file. Trust me.
Erik Naggum <······@naggum.no> writes:
>* Jamie Zawinski
>| Starting any statement with "these kids today" is grumpy-old-man
>| thinking. Hackers are hackers. I haven't met too many sixteen year olds
>| recently, but the few who have made their way into my office or mailbox
>| have lived up to my expectations of what kind of people they would be.
>computers, programming languages, and tools have all become vastly more
>complex. the focus on appearance in modern software translates to very
>time-consuming, manual work for the programmer. there is growing concern
>that good, compact code is so much harder to maintain and company loyalty
>is so low that managers prefer to hire less educated programmers. there is
>more demand on kids to go through formal education and get good grades.
>these are changes in the outside world that intelligent kids respond to in
>the best way they can. their response is to go for the quick buck and not
>to spend time on learning more than to operate bleeding-edge tools that
>will be obsolete in a few months. I don't think I'm a grumpy old man, but
>I remember that I had time to spend on stuff that had no immediate value to
>me, but which were just fun to discover, but from what I see, there appears
>to be very little time left for those who don't want to drop out of the
>system completely for this kind of exploratory playing.
Yup! Boy, that's my mold. Or at least its close.
One of the reasons that I've taken so long to "get" into, and do
things with Lisp is that I have to keep spending time keeping my head
up out on the bleeding edge of "Time saving, code organizing, screen
painting" silver bullet software. Minimally so I can explain it to the
folks using it at the office.
In one sense, if you take a year sabbatical, fall into your cave, and
focus on What's Right, What's Good, you'll come back into a new world.
All of the headlines will be different, the buzzwords have changed,
and have the stuff that was leading edge and "Cool" is now behind the
pack, buggy, "Crap", and passe'. Look at the backlash at Java
happening right now.
Of course, the thing people do not realize is that the basics, the
tenets, and axioms of computer science DO NOT CHANGE. They evolve, a
bit, they advance, and yeah, maybe become a bit obsolete, but
that old CS stuff they taught you in the dark ages of 10 years ago is
still basically valid. Just spoken differently.
Something that I've learned over my journeys with Lisp and Scheme is
that one of the things that makes it great is that it keeps up. It
doesn't fall behind. "Oh looky! A new wamaflugzit! Use the latest
language 'Garble' you can do ....". You look at this "Great Discovery"
and go "Ya know, with a few macros, we could probably pull that off.".
I feel for the kids today. They have a lot of pressure, from society,
from their peers. It's hard to stay in school where your Hacker Buddy
is driving around in his new car.
If the person is the type that will at least READ the academic CS
texts and think and discuss them, then "formal education" isn't
necesarily the only medium of expression. However, it is the most
supportive.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
>>>>> Erik <······@naggum.no> responds to Jamie Zawinski <···@netscape.com>:
Jamie> Hey, I resemble that remark! I never went to college.
Erik> so do I, except I was 16 before today's 16-year-olds were
Erik> born.
Cool, I flunked out of college three times (once retroactively) and
grad school twice.
But can you dropouts try to rescue this thread? Somebody said,
"Java doesn't have closures,"
and somebody responded,
"But Java has inner classes, and that's just about as good,"
and no Lisp heads have taken up the challenge!
I'm just a beginner, so tell me, what can you do with closures that
would be a pain with inner classes?
I figure that Java's got something going for it, since Guy Steele's
writing Java manuals. He did just post that the syntax was rough...
* Bill Richter
| "But Java has inner classes, and that's just about as good,"
| and no Lisp heads have taken up the challenge!
I forget who wrote it, but the argument for programming languages is always
one of _pragmatics_. you can implement something like closures in C, too,
but it would require a lot of manual labor to use them well. the whole
point with closures in Lisp and Scheme is that it is no different from
other functions.
| I'm just a beginner, so tell me, what can you do with closures that
| would be a pain with inner classes?
less typing, fewer idioms to master, better support from the framework.
| I figure that Java's got something going for it, since Guy Steele's
| writing Java manuals.
this is technically known as an argumentum ad hominem. it isn't any more
valid as an argument than its usual negative application. Guy Steele is to
be admired for his excellent work, but we should admire his works based on
their merit, not admire some works _because_ they are made by Guy Steele.
#\Erik
--
404 You're better off without that file. Trust me.
Erik Naggum <······@naggum.no> writes:
> I forget who wrote it, but the argument for programming languages is always
> one of _pragmatics_. you can implement something like closures in C, too,
> but it would require a lot of manual labor to use them well. the whole
> point with closures in Lisp and Scheme is that it is no different from
> other functions.
But it's pretty hard (one might claim impossible) to classify
pragmatics. On the other hand, there are actual expressiveness
measures in the literature -- such as John Mitchell's and Matthias
Felleisen's -- that provide actual, concrete measures of when
something can be claimed to be "expressive".
It is interesting to evaluate how well they correspond to what you
would personally consider expressive, eg, closures done automatically
being more expressive than those built "by hand".
'shriram
I'm on a slow pipe, so I haven't seen the
``Java has inner classes, and that's juts about as good'' message.
I've looked at the inner classes stuff, but I haven't
experimented with them. It looks as if they may be as powerful
as closures (can someone clarify this?).
If so, then all we need is tail-recursion, then we can all grumble
and moan about the sucky syntax.
Bill Richter wrote in article ...
> Somebody said,
>"Java doesn't have closures,"
>and somebody responded,
>"But Java has inner classes, and that's just about as good,"
>and no Lisp heads have taken up the challenge!
>
>I'm just a beginner, so tell me, what can you do with closures that
>would be a pain with inner classes?
>>>>> "ET" == ET <········@eval-apply.com> writes:
ET> I haven't seen the ``Java has inner classes, and that's just
ET> about as good'' message.
That's all I remember. I haven't seen much on this thread about
actual advantages of Lisp/Scheme. It's been heavy on big words that I
don't understand. I'm gonna use some myself:
I'm starting to think the advantage of Lisp/Scheme is that it's so
close to Mathematical Logic, like the G\"odel incompleteness theorem
and Turing machines. Good theoretical stuff to know about: If
something is hard in Scheme, it's probably hard to formulate
mathematically, so maybe it's hard for a compiler to optimize, since
computers are built on the notion of a Turing machine.
I not an expert here, because Math and Math Logic are perpendicular.
Pure Math (Algebra, Topology...) is pretty much defined to be all the
logical corollaries of the Zermelo-Fraenkel set theory axioms (plus
axiom of choice and maybe a few others). So the widely misunderstood
G\"odel incompleteness theorem says that there are true theorems that
the pure Math bunch will never prove, but only because of their
insistence of sticking with the axioms. Otherwise, incompleteness
only means that you can't write a computer program to print out all
the theorems of Number Theory (e.g. Fermat's last theorem, the twin
prime conjecture either way). The only mathematicians who venture
outside the safe ZFC axiom system are the Logic/Set theory bunch, and
they're thought by to be pretty weird, not working on "real math".
So for instance, there's a lotta traffic on c.l.s. about syntax
vs. semantics, and it always sounds to me like structured programming
vs. OOP, Miller vs. Bud.
But in Math logic syntax and semantics have well defined meanings. A
formula in a 1st order system is semantically true if it's true in
every model of the system, and syntactically true if there's a
derivation from the axioms. And G\"odel's earlier completeness
theorem says these notions are actually equivalent. I wonder if that
might explain some of the blurriness of the c.l.s. discussion?
Back to computers, just because something is good because of its Math
doesn't mean you need to learn the Math. If it's good, it should
stand on it's own feet anyway. (And as Jamie Z said earlier, going to
school can be a bad way to learn. I finally realized (close to 40)
that Set theorists don't believe they can construct a model of ZFC, or
even the real numbers, they need the power set axiom to get it R from
N. I was shocked, but pure Math people mostly respond, "Look, can we
sell this? We've got papers to publish, deadlines to meet...")
Skirting inner classes, lots of OOP in Java or C++ sounds like it
would be difficult to code up in Scheme. You can probably do it all
in CLOS but that's a huge system, maybe slow... You can define objects
easily with SICP Ch 3 closures, but not generic binary operators to
act on 2 objects. In Java you can get generic ops with class methods
rather than instance methods. Maybe the conclusion though is
hard in Scheme => hard Math => do we really wanna do this?
I'd like, as a novice, to see more of what you can do with closures.
Bill Richter wrote:
[...]
> Skirting inner classes, lots of OOP in Java or C++ sounds
> like it would be difficult to code up in Scheme. You can
> probably do it all in CLOS but that's a huge system, maybe
> slow... You can define objects easily with SICP Ch 3 closures,
> but not generic binary operators to act on 2 objects. In Java
> you can get generic ops with class methods rather than instance
> methods. Maybe the conclusion though is hard in Scheme => hard
> Math => do we really wanna do this? I'd like, as a novice, to
> see more of what you can do with closures.
Whether it would be easy to translate Java- or C++-style object-
oriented techniques directly to Scheme would indeed depend on
what kind of object system you had available to you in Scheme.
But that's the big difference. Scheme has enough power and
flexibility to allow the programmer to implement their own
object systems for Scheme in Scheme. And they can be as simple
as what's described in SICP or as overwhelmingly full-featured
as CLOS or anywhere in between. And you don't need anything
nearly as sophisticated as CLOS to do Java- or C++-style OOP.
But here's the thing: Once you get comfortable with Scheme, you
start to find that it's not always (or even usually) appropriate
to express ideas in strict `classical' OO terms. Higher-order
functions have amazing utility. One hint of their power is that
they can be used to implement object systems. But it's only the
tip of the iceberg.
-thant
--
thant at acm dot org
>>>>> "Thant" != <·······@signature.below> writes:
Thant> Scheme has enough power and flexibility to allow the
Thant> programmer to implement their own object systems for Scheme
Thant> in Scheme. And they can be as simple as what's described in
Thant> SICP or as overwhelmingly full-featured as CLOS or anywhere
Thant> in between.
More details? I understand the SICP object/method. How can I extend
this to include methods which take 2 arguments (binary generic ops)?
Thant> And you don't need anything nearly as sophisticated as CLOS
Thant> to do Java- or C++-style OOP.
Wow, I hadn't heard before that CLOS is more sophisticated before.
Does anyone else agree with that? Does CLOS compile as fast?
Thant> But here's the thing: Once you get comfortable with Scheme,
Thant> you start to find that it's not always (or even usually)
Thant> appropriate to express ideas in strict `classical' OO terms.
Thant> Higher-order functions have amazing utility. One hint of
Thant> their power is that they can be used to implement object
Thant> systems. But it's only the tip of the iceberg.
That's extremely interesting! Can you give some details, or some
pointer to where I can go learn this?
Bill Richter <·······@conley.math.nwu.edu> writes:
> >>>>> "Thant" != <·······@signature.below> writes:
>
> Thant> Scheme has enough power and flexibility to allow the
> Thant> programmer to implement their own object systems for Scheme
> Thant> in Scheme. And they can be as simple as what's described in
> Thant> SICP or as overwhelmingly full-featured as CLOS or anywhere
> Thant> in between.
>
> More details? I understand the SICP object/method. How can I extend
> this to include methods which take 2 arguments (binary generic ops)?
You can find Gregor Kiczales' MOP-based object system that implements
generic functions with multiple dispatch in the CMU Artificial
Intelligence Repository at
<http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/oop/tinyclos/0.html>
They have several other object systems there as well. Since most of
these packages are quite small (tiny-clos is only 1200 lines of code
including comments) you should be able to understand what's going on
without too much difficulty. If you want to know more about Meta
Object Protocols there is a book called "The Art of the Metaobject
Protocol" by Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow,
MIT Press, ISBN 0-262-61074-4.
> Thant> And you don't need anything nearly as sophisticated as CLOS
> Thant> to do Java- or C++-style OOP.
>
> Wow, I hadn't heard before that CLOS is more sophisticated before.
> Does anyone else agree with that? Does CLOS compile as fast?
When switching from CLOS to C++ you'll feel rather suffocated, because
there are many things that are straightforward in CLOS that are very
difficult in C++, to say the least. However this does not come
without a price: The performance of the freely available CLOS
implementation PCL is rather poor, commercial CL compilers do have
reasonable execution speed for code that makes heave use of CLOS'
features. I don't suppose there are many useful comparisons between
the execution speed of programs written using CLOS and comparable
programs written in C++ but CLOS is definitely fast enough for my
applications.
> Thant> But here's the thing: Once you get comfortable with Scheme,
> Thant> you start to find that it's not always (or even usually)
> Thant> appropriate to express ideas in strict `classical' OO terms.
> Thant> Higher-order functions have amazing utility. One hint of
> Thant> their power is that they can be used to implement object
> Thant> systems. But it's only the tip of the iceberg.
>
> That's extremely interesting! Can you give some details, or some
> pointer to where I can go learn this?
Read SICP. Reread SICP. Read Paul Graham's "ANSI Common Lisp" (not
about Scheme, but a very good book). Oh, and read SICP.
Matthias
>>>>> "Matthias" == Matthias Hoelzl (tc) <··@gauss.muc.de> writes:
>> More details? I understand the SICP object/method. How can I
>> extend this to include methods which take 2 arguments (binary
>> generic ops)?
Matthias> <http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/oop/tinyclos/0.html>
Matthias> Since most of these packages are quite small (tiny-clos is
Matthias> only 850 lines of code including comments) you should be
Matthias> able to understand what's going on
Thanks, I just downloaded it, and I see:
One stumbling block for people interested in playing with the
metaobject protocol (MOP) ideas has been the relative complexity of
working in Common Lisp. This has been a particular obstacle for
undergraduates and others who normally work in Scheme (or a very
reduced Common Lisp). To try and address this, we have designed
and implemented a Scheme embedding of a core subset of CLOS, with a
corresponding core MOP.
Thant> But here's the thing: Once you get comfortable with Scheme,
Thant> you start to find that it's not always (or even usually)
Thant> appropriate to express ideas in strict `classical' OO terms.
Thant> Higher-order functions have amazing utility. One hint of
Thant> their power is that they can be used to implement object
Thant> systems. But it's only the tip of the iceberg.
>>
>> That's extremely interesting! Can you give some details, or some
>> pointer to where I can go learn this?
Matthias> Read SICP. Reread SICP. Read Paul Graham's "ANSI Common
Matthias> Lisp" (not about Scheme, but a very good book). Oh, and
Matthias> read SICP.
I like SICP, and I'm reading it now, from the beginning, trying to do
an exercise asking for a tail-recursive function to compute (semi-)
partitions of natural numbers. But since any computable function can
be written in the Lambda Calculus, it can't be true that a 1st-yr book
on Scheme tells everything about the magic of closures.
Regarding your comments on syntax vs. semantics, you may be interested
in some of Jean-Yves Girard's writings. Perhaps the most gentle
introduction is Girard, Lafont and Taylor's /Proofs and Types/.
'shriram
Bill Richter <·······@conley.math.nwu.edu> writes:
> I'm starting to think the advantage of Lisp/Scheme is that it's so
> close to Mathematical Logic, like the G\"odel incompleteness theorem
> and Turing machines. Good theoretical stuff to know about: If
> something is hard in Scheme, it's probably hard to formulate
> mathematically, so maybe it's hard for a compiler to optimize, since
> computers are built on the notion of a Turing machine.
Neither are computers built on the notion of a Turing machine, nor is
Scheme's execution model somehow linked to Turing machines. The
mathematical theory that underlies Scheme is the lambda calculus.
> I not an expert here, because Math and Math Logic are perpendicular.
> Pure Math (Algebra, Topology...) is pretty much defined to be all the
> logical corollaries of the Zermelo-Fraenkel set theory axioms (plus
> axiom of choice and maybe a few others).
This is a very limited view of Mathematics, to say the least.
> So the widely misunderstood
> G\"odel incompleteness theorem says that there are true theorems that
> the pure Math bunch will never prove, but only because of their
> insistence of sticking with the axioms. Otherwise, incompleteness
> only means that you can't write a computer program to print out all
> the theorems of Number Theory (e.g. Fermat's last theorem, the twin
> prime conjecture either way).
Wrong. It's fairly trivial to write a Program that enumerates all
theorems of number theory formally provable within, say, ZFC. You
simply enumerate all proofs. The bad thing is that it will never stop
and you will therefore not know whether a theorem that is not in the
list you have obtained so far will show up later or not. What you
probably mean is that it is not possible to algorithmically find a
proof for a given theorem. This question however is not directly
solved by Goedel's theorems, these problems are called decision
problems (and many logicians thought they might be solvable even after
Goedel's theorems were known, the decision problem for full L^1 was
solved negatively by Church and Turing).
> The only mathematicians who venture
> outside the safe ZFC axiom system are the Logic/Set theory bunch, and
> they're thought by to be pretty weird, not working on "real math".
Wrong again. There are, e.g., various theorems in topology that
are applications of Martin's axiom (the statement that every compact
T_2 space with the Souslin property satisfies the strong Baire
property is for example equivalent to MA).
> [...]
> Back to computers, just because something is good because of its Math
> doesn't mean you need to learn the Math. If it's good, it should
> stand on it's own feet anyway. (And as Jamie Z said earlier, going to
> school can be a bad way to learn. I finally realized (close to 40)
> that Set theorists don't believe they can construct a model of ZFC, or
> even the real numbers, they need the power set axiom to get it R from
> N. I was shocked, but pure Math people mostly respond, "Look, can we
> sell this? We've got papers to publish, deadlines to meet...")
I don't know what exactly mean by "construct a model", but I always
thought that Goedel's L was a fine example of a transitive proper
class model of ZFC+GCH. And here I sit with a book about constructive
analysis, but, oh, never mind...
> Skirting inner classes, lots of OOP in Java or C++ sounds like it
> would be difficult to code up in Scheme. You can probably do it all
> in CLOS but that's a huge system, maybe slow... You can define objects
> easily with SICP Ch 3 closures, but not generic binary operators to
> act on 2 objects. In Java you can get generic ops with class methods
> rather than instance methods.
Can somebody tell me whether Java really has generic binary operators
that can dispatch on their two operands? This would indeed be good
news.
> Maybe the conclusion though is
> hard in Scheme => hard Math => do we really wanna do this?
Come on, tiny-clos is an objects system with generic functions and
multiple inheritance (and a MOP) that is in many ways more powerful
than C++ and Java. It's 750 lines of Scheme code, not including
comments and it's there, ready for you to use. To me it seems that
for many problems the implication is rather
hard in Lisp => almost impossible in most other languages.
> I'd like, as a novice, to see more of what you can do with closures.
Since you mention SICP so often: Read it and try to understand it.
And please try to read a book about mathematical logic as well if
you post about it.
Matthias
>>>>> "Matthias" == Matthias Hoelzl (tc) <··@gauss.muc.de> writes:
>> Pure Math (Algebra, Topology...) is pretty much defined to be all
>> the logical corollaries of the Zermelo-Fraenkel set theory axioms
>> (plus axiom of choice and maybe a few others).
Matthias> This is a very limited view of Mathematics, to say the
Matthias> least.
Yes, pure mathematicians (excluding set theorists & logicians) have
pretty much limited themselves to ZFC.
>> So the widely misunderstood G\"odel incompleteness theorem says
>> that there are true theorems that the pure Math bunch will never
>> prove, but only because of their insistence of sticking with the
>> axioms. Otherwise, incompleteness only means that you can't
>> write a computer program to print out all the theorems of Number
>> Theory (e.g. Fermat's last theorem, the twin prime conjecture
>> either way).
Matthias> Wrong. It's fairly trivial to write a Program that
Matthias> enumerates all theorems of number theory formally provable
Matthias> within, say, ZFC. You simply enumerate all proofs.
Right. The point is that by incompleteness, there are true theorems
(in number theory, for instance) that are not provable in ZFC.
Matthias> The bad thing is that it will never stop and you will
Matthias> therefore not know whether a theorem that is not in the
Matthias> list you have obtained so far will show up later or not.
Right, by incompleteness. For a given statement S, we'd like to know
(but we don't) that either S or not-S follows from ZFC. That's false
by incompleteness, but if it were true, and we knew that S was true,
then we could wait by the printer for a ZFC proof of S.
Matthias> What you probably mean is that it is not possible to
Matthias> algorithmically find a proof for a given theorem.
That follows from Incompleteness, but I like to say it this way:
ZFC < Truth.
Matthias> This question however is not directly solved by Goedel's
Matthias> theorems, these problems are called decision problems (and
Matthias> many logicians thought they might be solvable even after
Matthias> Goedel's theorems were known, the decision problem for
Matthias> full L^1 was solved negatively by Church and Turing).
Sounds interesting, I'll have to book up about it.
>> The only mathematicians who venture outside the safe ZFC axiom
>> system are the Logic/Set theory bunch, and they're thought by to
>> be pretty weird, not working on "real math".
Matthias> Wrong again. There are, e.g., various theorems in
Matthias> topology that are applications of Martin's axiom (the
Matthias> statement that every compact T_2 space with the Souslin
Matthias> property satisfies the strong Baire property is for
Matthias> example equivalent to MA).
I'm sure you're right, and I'm sure it's interesting, but I'm a
topologist myself, and I've never heard anybody company topologists
talk about it. Pure mathematicians tend to limit themselves to ZFC.
>> Back to computers, just because something is good because of its
>> Math doesn't mean you need to learn the Math. If it's good, it
>> should stand on it's own feet anyway. (And as Jamie Z said
>> earlier, going to school can be a bad way to learn. I finally
>> realized (close to 40) that Set theorists don't believe they can
>> construct a model of ZFC, or even the real numbers, they need the
>> power set axiom to get it R from N. I was shocked, but pure Math
>> people mostly respond, "Look, can we sell this? We've got papers
>> to publish, deadlines to meet...")
Matthias> I don't know what exactly mean by "construct a model", but
Matthias> I always thought that Goedel's L was a fine example of a
Matthias> transitive proper class model of ZFC+GCH.
It's fine, but Goedel didn't really construct L. He assumed that a
model U of ZF existed, and then he constructed your submodel L < U
satisfying the Continuum Hypothesis. Makes sense, I guess: CH says
that the real line has "few" subsets, so you ought to be able to make
it true by tossing out the subsets that are too big.
And Cohen didn't construct a model of ZFC-GCH. He assumed a model U,
and constructed a model U' > U where the Continuum Hypothesis failed.
So if you ever wonder, what model of the real line are we using, are
we using a Goedel model where every uncountable subset of R has the
same size as R, or do we have a Cohen model? The answer is that we
don't have either, we're merely proceeding axiomatically.
Matthias> Neither are computers built on the notion of a Turing
Matthias> machine, nor is Scheme's execution model somehow linked to
Matthias> Turing machines. The mathematical theory that underlies
Matthias> Scheme is the lambda calculus.
The Lambda Calculus and Turing machines are "equivalent" theories in
some sense. It might be that the Lambda Calculus appears to us as a
more powerful theory, that's why Lisp would be a good idea.
From: William D Clinger
Subject: another application of Martin's axiom to topology
Date:
Message-ID: <341F070E.593F@ccs.neu.edu>
Warning: Until the last paragraph, this has nothing to do with
Lisp or Scheme.
In the 1930's or thereabouts, the well-known point set topologist
R L Moore proposed an alternative axiomatization of metric spaces
in terms of what became known as Moore spaces. He showed that
every metric space is a normal Moore space, and conjectured that
every normal Moore space is a metric space.
This important conjecture remained open until the 1960s, when
someone (Mary Ellen Rudin?) constructed a counterexample based
on Martin's Axiom.
Martin's Axiom implies that the Axiom of Choice (the "C" in ZFC)
is false. I do not know whether ZFC implies the normal Moore
space conjecture, nor do I know whether ZFC decides the normal
Moore space conjecture, nor do I know whether it is known whether
ZFC decides the conjecture.
I am neither a topologist nor a logician. I apologize for not
giving a reference: My copy of Rudin's monograph that describes
the counterexample is packed away in a box of books that I haven't
needed in years.
Bill Richter wrote:
> That follows from Incompleteness, but I like to say it this way:
> ZFC < Truth.
The problem with paraphrasing Goedel's (second) incompleteness
theorem in this way is that there is no particular reason to
believe that ZFC < Truth. ZF < Truth is considerably more
plausible, of course, but Goedel's theorems do not require
that Truth even exists (in the capital-T sense assumed by
Richter and many other mathematicians---including Goedel
himself, by the way).
Furthermore this talk of ZF and ZFC sort of misses the point,
because Goedel's first incompleteness theorem shows that the
particular axiomatization is irrelevant: If Z' is any recursive
axiomatization whatsoever that extends a certain very minimal,
obviously incomplete axiomatization of arithmetic, then Z' is
either inconsistent or incomplete.
> The Lambda Calculus and Turing machines are "equivalent" theories in
> some sense. It might be that the Lambda Calculus appears to us as a
> more powerful theory, that's why Lisp would be a good idea.
They are equivalent in the sense that the same set of number-
theoretic functions is computable in each. The lambda calculus
makes it easier to generalize the notion of computation to deal
with abstract data types (i.e. data for which no numerical
encoding can be assumed), which is part of the reason Lisp
(Scheme, ML, Haskell, etc) is a good idea.
Will
>>>>> "Will" == William D Clinger <····@ccs.neu.edu> writes:
Thanks for the reply, which I have to think about, but 2 quickies:
Will> Martin's Axiom implies that the Axiom of Choice (the "C" in
Will> ZFC) is false.
Wrong C. Martin's Axiom implies that the Continuum Hypothesis is
false, but MA is consistent with ZFC (Jech "Set Theory", Theorem 51.)
Will> Bill Richter wrote:
>> That follows from Incompleteness, but I like to say it this way:
>> ZFC < Truth.
Will> The problem with paraphrasing Goedel's (second) incompleteness
Will> theorem in this way is that there is no particular reason to
Will> believe that ZFC < Truth.
Sorry, I meant Goedel's first incompleteness theorem, which says that
you can't write a computer program to print out out all the true
theorems of Number Theory.
So it can't be true that every theorem of the natural numbers is
provable in ZFC. If it were, you could obtain the above impossible
program by enumerating the corollaries of ZFC and piping the output
through a filter that would toss out the set theorems that weren't
wffs of number theory (such as mathematical induction, which is a 1st
order axiom of ZFC but is a 2nd order axiom for number theory). Thus
ZFC \cap #-theory < Truth of #-theory
I've never seen this consequence of Goedel I pointed out in a Logic
book, but I'm sure it's true, so I'll copy a real logician.
And you can subsitute any other consistent recursive axiom system for
ZFC. And you seem to agreeing with me below
Will> Furthermore this talk of ZF and ZFC sort of misses the point,
Will> because Goedel's first incompleteness theorem shows that the
Will> particular axiomatization is irrelevant: If Z' is any
Will> recursive axiomatization whatsoever that extends a certain
Will> very minimal, obviously incomplete axiomatization of
Will> arithmetic, then Z' is either inconsistent or incomplete.
Sure! On to scheme:
Will> [The Lambda Calculus and Turing machines] are equivalent in
Will> the sense that the same set of number theoretic functions is
Will> computable in each. The lambda calculus makes it easier to
Will> generalize the notion of computation to deal with abstract
Will> data types (i.e. data for which no numerical encoding can be
Will> assumed), which is part of the reason Lisp (Scheme, ML,
Will> Haskell, etc) is a good idea.
Cool! Where's a good place to read more about this?
From: Gareth McCaughan
Subject: Re: another application of Martin's axiom to topology
Date:
Message-ID: <8690ww1cua.fsf@g.pet.cam.ac.uk>
Bill Richter wrote:
> Sorry, I meant Goedel's first incompleteness theorem, which says that
> you can't write a computer program to print out out all the true
> theorems of Number Theory.
You've said this before, but it's false. A theorem is something
that has a proof. You can write a program to generate all possible
proofs and print out their conclusions.
If you mean "you can't write a computer program to print out all
the true statements of number theory" then that's true, but it's
not at all the same statement. And some mathematicians would be
very skeptical about whether it's actually *meaningful*; perhaps,
horrible though it sounds, the existence of undecidable statements
for any axiomatisation of number theory means that some things
can be stated in the language of elementary number theory but
are neither true nor false.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
>>>>> "Gareth" == Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
Gareth> Bill Richter wrote:
>> Sorry, I meant Goedel's first incompleteness theorem, which says
>> that you can't write a computer program to print out out all the
>> true theorems of Number Theory.
Gareth> You've said this before, but it's false. A theorem is
Gareth> something that has a proof. You can write a program to
Gareth> generate all possible proofs and print out their
Gareth> conclusions.
I apologize for being confusing. I used the term "theorem", which my
Math Logic books seldom use, to mean an element of a theory, I guess I
think that's poor usage. Lemme clarify:
From Just & Weese "Discovering Modern Set Theory I", a theory is just
a set of sentences in a first order language such as L_A, the language
of Arithmetic, whose only nonlogical symbols are <, +, *, 0, 1. Let N
be the standard model of the natural numbers. Then by
>> the true theorems of Number Theory.
I meant the complete theory Th(N), meaning the set of all wffs in L_A
that are true (or satisfied) in the model N. And I think you're
right, that I should have written
Gareth> the true statements of number theory.
Thanks.
Gareth> If you mean "you can't write a computer program to print out
Gareth> all the true statements of number theory" then that's true,
Gareth> but it's not at all the same statement.
OK.
Gareth> And some mathematicians would be very skeptical about
Gareth> whether it's actually *meaningful*;
Well, Goedel incompleteness is certainly meaningful on this list,
because it's equivalent to the nonsolvability of the Halting Problem.
Gareth> perhaps, horrible though it sounds, the existence of
Gareth> undecidable statements for any axiomatisation of number
Gareth> theory means that some things can be stated in the language
Gareth> of elementary number theory but are neither true nor false.
People often phrase Goedel incompleteness like this, but I say it's
misleading -- it confuses semantic truth in Th(N) with syntactic
derivation in a particular favorite axiom system.
By "true nor false", you mean you have a consistent, decidable set of
axioms G for L_A, and "true" means syntactically derivable from G.
That's quite different from our semantic truth above: a statement of
number theory is semantically true iff it belongs to Th(N).
Let's call Th(G) the theory of syntactic consequences of your axioms
G. If you used Peano's axioms, then Th(G) = PA. Then Goedel's first
incompleteness says
Th(G) < Th(N)
PA < Th(N)
Sounds meaningful to me, limits of axiomatizations and computation.
If you addict yourself to one particular axiom system (as the field of
Pure Math has done, so it could be replaced by machines) then there
are true statements in number theory that you're never gonna prove.
I'd call it sour grapes to then refer to the true statements in Th(N)
that you'll never be able to prove as "neither true nor false."
>>>>> "Gareth" == Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
Gareth> Bill Richter wrote:
>> Then I meant the complete theory Th(N), meaning the set of all
>> wffs in L_A that are true (or satisfied) in the model N.
Gareth> Ah, but what exactly *is* "the model N"? Just "the real,
Gareth> honest-to-God natural numbers"? Some would say that there is
Gareth> no such entity, and that we're fooling ourselves if we think
Gareth> there is.
Good question! I meant "the model N" only in the standard Pure Math
sense (which might be called formalism), which is:
you can build an unambiguous standard model N of the natural numbers
as a consequence of the ZF axioms, e.g. the ZF axiom of infinity.
Gareth> And some mathematicians would be very skeptical about
Gareth> whether it's actually *meaningful*;
>>
>> Well, Goedel incompleteness is certainly meaningful on this list,
>> because it's equivalent to the nonsolvability of the Halting
>> Problem.
Gareth> What I was saying might not be meaningful is the notion of
Gareth> "the model N", or of "the truths of number theory".
Absolutely! All theorems of Set Theory/Logic, such as Goedel's 2nd
incompleteness theorem, begin with, "Assume a model of ZFC exists".
Goedel II says that ZF cannot prove its own consistency, meaning that
we cannot construct a model of of ZF (i.e. a "universe of sets") only
using the ZF axioms.
But you might say, heck we can construct the model ourselves! Start
with the empty set (we all believe in that) and keep taking power
sets. But the set theorists point out that there are serious
difficulties involved in taking power sets: that's why it's an axiom.
If fact the set theorists say they cannot even construct the real
line. Let's start with N -- that's quite believable, you only need to
start with the empty set and believe in mathematical induction. Then
R is pretty much defined to be the power set 2^N, all the subsets of
N. But what do you mean by "all"? Doesn't in mean "all the subsets
that there are"? Now we've left Math for ontology.
Gareth> Incidentally, I'm inclined to be a Platonist myself
Gareth> (actually, I think all pure mathematicians are *inclined* to
Gareth> be -- it would be hard to motivate doing pure mathematics
Gareth> without the feel that one's working on *something*); I'm
Gareth> just pointing out that there is a contrary view and that
Gareth> it's not as crazy as it can sometimes sound.
I believe it's *something*, but why say that it existed already before
in a some static eternal hard disk in the sky? Maybe there's a
Platonic hard disk, but sometime we write new files to it. I'm
following the biologist Rupert Sheldrake here.
Skipping to the end of your letter,
Gareth> Suppose we steer away from N for a moment. Would you say
Gareth> that every statement about *set theory* is either true or
Gareth> false? That, for instance, things like the continuum
Gareth> hypothesis, Martin's axiom, Souslin's "diamond"
Gareth> principle[1], sundry large cardinal axioms, and so on and
Gareth> on, are all either true or false and that we simply don't
Gareth> yet have the tools to decide which?
No, I wouldn't, I think you'd have to be a Platonist to say definitely
true or false. I think you'd be saying, "there's a model of ZFC up in
the Platonic Hard Disk and we don't know everything about it (for
instance, how big the real line in (CH)), but it's an actual object,
so these questions have definite answers."
Penrose gets himself into this problem in "Shadows of the Mind." He
says sure we know that CH is independent of ZFC, but there are only 10
or so axioms that people are divided on, like MA. So he's happy to
say that there are 2^10 different models of ZFC in the Platonic Hard
Disk, and we can download whatever one we want.
I say that's crazy, it's not just 10 axioms. There would be an
uncountably infinite number of versions of the real line which violate
CH. CH means there's one uncountable subset of R which is smaller
than R. But having one such subset, there could be lots more! Are
there really that many copies of R in the Platonism world of forms?
Saunders MacLane wrote in a popular book on Math that most
mathematicians subscribed to "mythological Platonism" while they were
working, but he thought real Platonism didn't make sense any more. He
said something like, "In Plato's time, the Greeks didn't have many
mathematical objects, circles & lines etc, so it made sense to think
of a Platonism world of forms. But nowadays, with so many different
mathematical objects, it must be pretty busy up there!"
From: Gareth McCaughan
Subject: Re: another application of Martin's axiom to topology
Date:
Message-ID: <8667rxv7tl.fsf@g.pet.cam.ac.uk>
Bill Richter wrote:
> Gareth> Ah, but what exactly *is* "the model N"? Just "the real,
> Gareth> honest-to-God natural numbers"? Some would say that there is
> Gareth> no such entity, and that we're fooling ourselves if we think
> Gareth> there is.
>
> Good question! I meant "the model N" only in the standard Pure Math
> sense (which might be called formalism), which is:
> you can build an unambiguous standard model N of the natural numbers
> as a consequence of the ZF axioms, e.g. the ZF axiom of infinity.
But this doesn't help: it doesn't give you a real standard model of
the naturals unless you already have a standard model of ZF.
> But you might say, heck we can construct the model ourselves! Start
> with the empty set (we all believe in that) and keep taking power
> sets. But the set theorists point out that there are serious
> difficulties involved in taking power sets: that's why it's an axiom.
There are even real difficulties with that phrase "keep taking ...".
There's no very big problem with e.g. taking the power set 10
times. But if you start saying "keep on doing it for ever, and when
you reach a limit ordinal just take the union of all earlier stages
and continue", which is what you need to do to make a model of ZF,
then you find that you need to know what ordinals are, and to be able
to take the union of an infinite collection of sets, and stuff like
that.
> If fact the set theorists say they cannot even construct the real
> line. Let's start with N -- that's quite believable, you only need to
> start with the empty set and believe in mathematical induction. Then
> R is pretty much defined to be the power set 2^N, all the subsets of
> N. But what do you mean by "all"? Doesn't in mean "all the subsets
> that there are"? Now we've left Math for ontology.
Too true.
> Gareth> Suppose we steer away from N for a moment. Would you say
> Gareth> that every statement about *set theory* is either true or
> Gareth> false? That, for instance, things like the continuum
> Gareth> hypothesis, Martin's axiom, Souslin's "diamond"
> Gareth> principle[1], sundry large cardinal axioms, and so on and
> Gareth> on, are all either true or false and that we simply don't
> Gareth> yet have the tools to decide which?
>
> No, I wouldn't, I think you'd have to be a Platonist to say definitely
> true or false.
Indeed. I got the impression that you were a Platonist (because of
your willingness to talk about "the truths of number theory"), which
is why I was asking.
> Penrose gets himself into this problem in "Shadows of the Mind." He
> says sure we know that CH is independent of ZFC, but there are only 10
> or so axioms that people are divided on, like MA. So he's happy to
> say that there are 2^10 different models of ZFC in the Platonic Hard
> Disk, and we can download whatever one we want.
>
> I say that's crazy, it's not just 10 axioms. There would be an
> uncountably infinite number of versions of the real line which violate
> CH.
Absolutely right.
> CH means there's one uncountable subset of R which is smaller
> than R.
Er, you mean not-CH, right?
> But having one such subset, there could be lots more! Are
> there really that many copies of R in the Platonism world of forms?
>
> Saunders MacLane wrote in a popular book on Math that most
> mathematicians subscribed to "mythological Platonism" while they were
> working, but he thought real Platonism didn't make sense any more. He
> said something like, "In Plato's time, the Greeks didn't have many
> mathematical objects, circles & lines etc, so it made sense to think
> of a Platonism world of forms. But nowadays, with so many different
> mathematical objects, it must be pretty busy up there!"
I think what really makes Platonism hard to swallow these days is
precisely the work of Goedel, Cohen et al. Not incompleteness as
such -- that isn't really a problem -- but the empirical fact that
there are lots of mathematical questions that (1) are undecidable
with the axioms we have, and (2) seem as if they could go either
way. That, plus the general anti-metaphysical tendency to object
to statements whose meaning one can't explain. (What does it *mean*
to say "the continuum hypothesis is true"? It's not a tautology;
there don't seem to be any conceivable observations that would
confirm or refute it; what *does* it mean? It's so hard to answer
that that it's tempting to conclude that it doesn't really mean
anything; that the feeling that it ought to mean something is a
misleading one.)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
>>>>> Gareth McCaughan <·····@dpmms.cam.ac.uk> responds to me:
Gareth> perhaps, horrible though it sounds, the existence of
Gareth> undecidable statements for any axiomatisation of number
Gareth> theory means that some things can be stated in the language
Gareth> of elementary number theory but are neither true nor false.
I finally understand what you mean! Not an axiomatization of
arithmetic (like Peano's Axioms) but an axiomatization of set theory!
That's a revelation to me, I'd explain it like this:
(1) Assume we have a model of ZFC (a "universe" of sets). The set
theorists do not believe they can construct one, but if there is one,
they will construct many different ones (where e.g. the Continuum Hyp
or MA is either satisfied or violated).
(2) In this model there is an unambiguous standard model N of the
natural numbers, and Th(N) is now an unambiguously defined set of wffs
in the 1st order language L_A of arithmetic, the statements which are
true in our model N.
(3) some of these statement in Th(N) are not provable in ZFC!!!
And I think that's exactly what you mean by "neither true nor false."
I still don't think that's good usage, but one wants to use strong
language to refer to number theory statements whose truth depends on
strange axioms of set theory.
Maybe everyone on the list knew (3) all along, but I never realized it
was true before this thread, but it's what I posted to Clinger:
>> So it can't be true that every theorem of the natural numbers is
>> provable in ZFC. If it were, you could [violate Goedel
>> incompleteness] by enumerating the corollaries of ZFC and piping
>> the output through a filter that would toss out the set theorems
>> that weren't wffs of number theory.
However, I don't think that's the only meaning of G incompleteness. My
belief (and I'll have to book up) is that for any recursive set of
axioms A for number theory, such as Piano's axioms, there is a Goedel
statement in Th(N) which which is provable in ZF but not in A.
Gareth> What I was saying might not be meaningful is the notion of
Gareth> "the model N", or of "the truths of number theory".
Gareth> Incidentally, I'm inclined to be a Platonist myself
Do you mean that these "truths of number theory" which aren't decided
by ZFC actually have an unambiguous answer, because you want to work
in a preferred Platonic N in a preferred Platonic model of ZFC?
>> If you addict yourself to one particular axiom system (as the
>> field of Pure Math has done, so it could be replaced by machines)
>> then there are true statements in number theory that you're never
>> gonna prove. I'd call it sour grapes to then refer to the true
>> statements in Th(N) that you'll never be able to prove as
>> "neither true nor false."
Gareth> I don't think this is at all a fair analysis of the
Gareth> situation. In particular, the mathematicians of my
Gareth> acquaintance who are most inclined to doubt the
Gareth> meaningfulness of talk about "the natural numbers" as a
Gareth> really existing Platonic entity are the ones who are *most*
Gareth> aware of mathematical logic and of the possibility of other
Gareth> systems of axioms.
That's fine, maybe your mathematicians aren't members of "the field of
Pure Math" which I claimed was perpendicular to Math Logic.
From: Gareth McCaughan
Subject: Re: another application of Martin's axiom to topology
Date:
Message-ID: <864t7hv6yz.fsf@g.pet.cam.ac.uk>
Bill Richter wrote:
> I finally understand what you mean! Not an axiomatization of
> arithmetic (like Peano's Axioms) but an axiomatization of set theory!
> That's a revelation to me, I'd explain it like this:
>
> (1) Assume we have a model of ZFC (a "universe" of sets). The set
> theorists do not believe they can construct one, but if there is one,
> they will construct many different ones (where e.g. the Continuum Hyp
> or MA is either satisfied or violated).
>
> (2) In this model there is an unambiguous standard model N of the
> natural numbers, and Th(N) is now an unambiguously defined set of wffs
> in the 1st order language L_A of arithmetic, the statements which are
> true in our model N.
>
> (3) some of these statement in Th(N) are not provable in ZFC!!!
>
> And I think that's exactly what you mean by "neither true nor false."
I'm not quite saying that if something is undecidable in ZFC then
it's neither true nor false, but yes. (What I'm saying is that if,
as non-Platonists would believe, we don't "have" a model of ZFC
and there isn't any given model of PA, it's not clear what it means
to say "Such-and-such a statement about N is true". True in what
model? It's only a sensible question if there actually *is* some
preferred implementation of N. Platonists will say: of course there
is, it's *the natural numbers*. Non-Platonists will say: there's
no such thing as "the natural numbers" in the sense you're using,
and it's just an illusion to think that there is. I'm not claiming
that the non-Platonists are *right*, merely pointing out that their
position does make sense.)
Incidentally, it may be helpful to have a look at a statement
about the natural numbers that can't be proved from the Peano
axioms alone (but can from ZFC; it's not undecidable in that
sense). It's called Goodstein's theorem, and it goes like this.
Suppose I have a number -- any number. I write it as a sum of
powers of 2, and I write all the exponents as sums of powers of 2,
and I write all the exponents in *those* as <etc>. So, for instance,
588 = 2^9 + 2^6 + 2^3 + 2^2
= 2^(2^3 + 1) + 2^(2^2 + 2^1) + 2^(2^1 + 1) + 2^(2^1)
= 2^(2^(2^1+1) + 1) + 2^(2^(2^1) + 2^1) + 2^(2^1 + 1) + 2^(2^1).
Thus I've written my number out using addition, 1 and "2-to-the".
Now, replace "2-to-the" with "3-to-the" throughout; subtract 1;
and, if necessary, rewrite in terms of +, 1, 3-to-the.
Now replace "3-to-the" with "4-to-the", subtract 1, and rewrite
if necessary. And so on.
Goodstein's theorem says: Whatever number I start with, I eventually
reduce it to 1 by doing this. (Yes, this is somewhat counterintuitive
to most people.)
The proof, given the apparatus of ZFC, is trivial. Consider the
ordinals obtained by replacing each stage's expression in terms
of +,1,"n-to-the" with a structurally identical one which has
omega instead of n. Observe that this ordinal decreases at every
stage. Remember that there is no infinite decreasing sequence of
ordinals. We're done.
> However, I don't think that's the only meaning of G incompleteness. My
> belief (and I'll have to book up) is that for any recursive set of
> axioms A for number theory, such as Piano's axioms, there is a Goedel
> statement in Th(N) which which is provable in ZF but not in A.
Surely ZF is itself a "recursive set of axioms for number theory"?
Or does it not count because it extends the language?
> Gareth> What I was saying might not be meaningful is the notion of
> Gareth> "the model N", or of "the truths of number theory".
>
> Gareth> Incidentally, I'm inclined to be a Platonist myself
>
> Do you mean that these "truths of number theory" which aren't decided
> by ZFC actually have an unambiguous answer, because you want to work
> in a preferred Platonic N in a preferred Platonic model of ZFC?
I think that might be true; I would *like* it to be true, and when
I'm doing mathematics I *feel* that it's true. None of which, of
course, prevents it being false. :-)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
>>>>> "Gareth" == Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
Gareth> Bill Richter wrote:
>> Sorry, I meant Goedel's first incompleteness theorem, which says
>> that you can't write a computer program to print out out all the
>> true theorems of Number Theory.
Gareth> You've said this before, but it's false. A theorem is
Gareth> something that has a proof. You can write a program to
Gareth> generate all possible proofs and print out their
Gareth> conclusions.
I apologize for being confusing. I used the term "theorem", which my
Math Logic books seldom use, to mean an element of a theory, I guess I
think that's poor usage. Lemme clarify:
From Just & Weese "Discovering Modern Set Theory I", a theory is just
a set of sentences in a first order language such as L_A, the language
of Arithmetic, whose only nonlogical symbols are <, +, *, 0, 1. Let N
be the standard model of the natural numbers. Then by
>> the true theorems of Number Theory.
I meant the complete theory Th(N), meaning the set of all wffs in L_A
that are true (or satisfied) in the model N. And I think you're
right, I should have written
Gareth> the true statements of number theory.
Thanks.
Gareth> If you mean "you can't write a computer program to print out
Gareth> all the true statements of number theory" then that's true,
Gareth> but it's not at all the same statement.
OK.
Gareth> And some mathematicians would be very skeptical about
Gareth> whether it's actually *meaningful*;
Well, Goedel incompleteness is certainly meaningful on this list,
because it's equivalent to the nonsolvability of the Halting Problem.
Gareth> perhaps, horrible though it sounds, the existence of
Gareth> undecidable statements for any axiomatisation of number
Gareth> theory means that some things can be stated in the language
Gareth> of elementary number theory but are neither true nor false.
People often phrase Goedel incompleteness like this, but I say it's
misleading -- it confuses semantic truth in Th(N) with syntactic
derivation in a particular favorite axiom system.
By "true nor false", you mean you have a consistent, decidable set of
axioms G for L_A, and "true" means syntactically derivable from G.
That's quite different from our semantic truth above: a statement of
number theory is semantically true iff it belongs to Th(N).
Let's call Th(G) the theory of syntactic consequences of your axioms
G. If you used Peano's axioms, then Th(G) = PA. Then Goedel's first
incompleteness says
Th(G) < Th(N)
PA < Th(N)
Sounds meaningful to me, limits of axiomatizations and computation.
If you addict yourself to one particular axiom system (as the field of
Pure Math has done, so it could be replaced by machines) then there
are true statements in number theory that you're never gonna prove.
I'd call it sour grapes to then refer to the true statements in Th(N)
that you'll never be able to prove as "neither true nor false."
I appreciate Bill Richter's corrections to my statements
about Martin's Axiom and the Axiom of Choice. Since I was
wrong about that, it may be that Martin's Axiom is irrelevant
to the normal Moore space conjecture; obviously my memory is
confused and I'll have to dig out my references.
Richter asked whether his main point, that not every true
statement of number theory is provable in ZFC (or whatever),
appears in standard texts. Here are a couple of citations:
Next, we sketch the proof of Kurt Goedel's celebrated
incompleteness theorem. Informally, this theorem says
that, in any reasonable system of formalizing the notion
of provability in number theory, some true statements are
unprovable.
- Michael Sipser, Introduction to the Theory of
Computation, page 209
It follows from Theorem 6 that any consistent mathematical
theory of which the theorems are just the consequences of
some effectively specified set of axioms, and among which
are the seven axioms of Q, is incomplete; hence for any
interpretation of the language of the theory there will
be truths in that interpretation which are not theorems
of the theory. And perhaps the most significant consequence
of Theorem 6 is what it says about the notions of _truth_
(in the standard interpretation for the language of
arithmetic) and _theoremhood_, or _provability_ (in any
particular formal theory): _that they are in no sense the
same_.
- George S Boolos and Richard C Jeffrey, Computability
and Logic, second edition, pages 179-180
Richter also asked for references about the notion of computation
with abstract data types in an extended lambda calculus, which
provides this posting's tenuous connection to Lisp and Scheme:
L. Cardelli and P. Wegner
On Understanding Types, Data Abstraction and Polymorphism
ACM Computing Surveys, 17(4), pp. 480-521, December 1985.
G. Plotkin
LCF considerd as a programming language
Theoretical Computer Science, Vol. 5, pp. 223-225, 1977.
John C. Mitchell
Representation Independence and Data Abstraction
Conference Record of the Thirteenth Annual ACM Symposium on
Principles of Programming Languages, pp. 263-276, ACM, January 1986.
Val Breazy-Tannen and Ramesh Subrahmanyam
On Extending Computational Adequacy by Data Abstraction
1992 ACM Conferenc on Lisp and Functional Programming, pp. 161-169,
ACM, August 1992.
Val Breazu-Tannen and Ramesh Subrahmanyam
On Adding Algebraic Theories with Induction to Typed Lambda Calculi
Proceedings of the Second International Conference on Algebraic
Methodology and Software Technology, pp. 221-225, May 1991.
Val Breazu-Tannen and Albert R. Meyer
Lambda Calculus with Constrained Types
Logics of Programs, Brooklyn, Lecture Notes in Computer Science,
Vol. 193, pp. 23-40, Springer-Verlag, June 1985.
Will
>>>>> "Will" == William D Clinger <····@ccs.neu.edu> writes:
Will> Goedel's theorems do not require that Truth even exists (in
Will> the capital-T sense assumed by Richter and many other
Will> mathematicians---including Goedel himself, by the way).
I understand Goedel was a Platonist, like Roger Penrose, the physicist
writing books about Goedel incompleteness and AI. If I sounded
Platonic, I didn't mean to, and maybe Gareth and I clarified the
meaning of Truth: not capital-T sense but semantic truth in Th(N).
I'd like to distance myself from Penrose, whose argument for I > AI is
that we have the free access to the Platonic world of forms that no
mere machine would enjoy -- nothing to do with incompleteness. But I
think that A.N. Whitehead's contribution to the solution of Russell's
paradox (a key part of Goedel's proof) was to point out that Platonic
world of forms can't exist, since (following Plato & Hegel) we live in
a dynamic universe. The argument I attribute to Whitehead is:
Let R be the collection of all sets in the Math wing of the Platonic
world of forms that don't contain themselves. R can't be a set
belonging to MWPWF, or we'd get Russell's contradiction. Therefore
MWPWF doesn't exist, or it's rules of inclusion are so weird that we
can't understand them (don't tell me they have "classes" in MWPWF).
On Fri, 05 Sep 1997 20:22:23 -0700, Jamie Zawinski <···@netscape.com> wrote:
>I never went to college. The best hackers I've ever met never
>graduated. I think that staying in school until the bitter end says
>more about your ability to follow orders and your lack of desire to
>actually get to the point and produce software that real people use,
>than it says about your knowlege, skill, or critical reasoning ability.
>
>Don't equate "formal education" with "education." The two are largely
>orthogonal.
I just happened to stumble on this posting. Guess we're completely off the
track of this newsgroup but here goes...
It's hard for me to control my anger when I see someone make a rash
generalization like that. Of course, from the eyes of a person who didn't go to
college, this will be the governing theory. But for someone like me, who just
about has a Masters in computer science, I have to disagree. As in any other
situation, different people require different paths to reach the same point.
Some peolple don't need college and might even be hurt by it. Others take what
they need from it and ignore the rest. Yeah, I played their game but I did it
with flair. My college years were one hell of a party. And I learned a ton
about CS and even more about life. Plus I have these pretty pieces of paper I
can use to fool people who don't know any better into giving me a job.
>I don't think Microsoft has anything to do with this.
Do they ever?
>--
>Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
>At any time, at any place, our snipers can drop you. Have a nice day.
Aren't you the guy who had a part in XEmacs at some point? I remember your old
Netscape page that actually changed the Netscape animation. I checked out your
new page and thoroughly enjoyed it.
Chad
--------------------------------------------------------------
Chad Woodford ········@thewatercooler.com
The faster we go, the rounder we get. -- The Grateful Dead
--------------------------------------------------------------
Hofstadter's Law: It always takes longer than you expect,
even when you take into account Hofstadter's Law.
On Sun, 07 Sep 1997 14:01:09 GMT, Chad Woodford
<········@thewatercooler.com> posted:
>On Fri, 05 Sep 1997 20:22:23 -0700, Jamie Zawinski <···@netscape.com> wrote:
>>I never went to college. The best hackers I've ever met never
>>graduated. I think that staying in school until the bitter end says
>>more about your ability to follow orders and your lack of desire to
>>actually get to the point and produce software that real people use,
>>than it says about your knowlege, skill, or critical reasoning ability.
>>Don't equate "formal education" with "education." The two are largely
>>orthogonal.
>It's hard for me to control my anger when I see someone make a rash
>generalization like that. Of course, from the eyes of a person who didn't go to
>college, this will be the governing theory. But for someone like me, who just
>about has a Masters in computer science, I have to disagree. As in any other
>situation, different people require different paths to reach the same point.
I am similarly somewhat offended. And have my M.Sc., with, of course,
the same sort of bias :-).
I agree that "degree" is not identical to "education."
The recent flames engulfing the lisp-related newsgroups have come
from a person that clearly was not getting much "education" (e.g. -
understanding of knowledge) out of his experiences in college.
There are indeed waves of spam-like C++ aficionados that were not
educated to know that there's anything outside of C++. The same
is true for many of the more popular languages and platforms,
including:
- COBOL, FORTRAN, and the haters of these languages that do not
understand the history of the languages,
- Those that worship the Microsoft hegemony; I've recently been
seeing lots of statements to the effect that "Excel finally
made spreadsheets easy to use," which is utter rubbish...
- Those that believe UNIX is the *only* possible best way of
computing...
The commonality tends to be that the powerful aficionados of these
things have seen *one* idea that they believe to be the "true" way
computing works. The fights between C and FORTRAN fans are probably
the most interesting, as they show that many C fans don't understand
C very well. (And that FORTRAN is harder to understand than it
appears to be...)
It's entirely like the story of the blind men that encounter an elephant,
and each perceives the elephant based on a single observation of a single
part of the elephant.
People with *bad* CS educations are those that get exposed to just
one idea and never see that idea challenged. And from there, they
build up the idea that the world works based on that one idea.
A decent CS school is a place where people will get exposed to a
variety of ideas. Many approaches to computing. And from that
does come a certain degree of wisdom. Not from all students,
but from some.
It's usually been pretty difficult to get that variety outside of
university experiences; until the entrance of the Internet, there
was a need for geographic closeness to have significant interaction
with people *dealing with ideas.* And this was largely restricted
to places that are or look a lot like universities.
And moreover, the language used for the bulk of the "advanced" computer
science ideas tends to be that of mathematics, which virtually requires
"interpreters" from within the CS community.
In theory, the Internet breaks down many of those barriers.
Unfortunately, there's so much "crud" that you need CS background
just to tell apart real information from snake oil. For instance,
the blatherings about the "evilness" or "goodness" of recursion,
just what is tail recursion, whether or not there are useful
LISP compilers, and so forth obscure any real information in
the discussion threads.
--
Christopher B. Browne, ········@hex.net, ············@sdt.com
PGP Fingerprint: 10 5A 20 3C 39 5A D3 12 D9 54 26 22 FF 1F E9 16
URL: <http://www.hex.net/~cbbrowne/>
Bill Gates to his broker: "You idiot, I said $150 million on **SNAPPLE**!!!"
> --
> Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
> At any time, at any place, our snipers can drop you. Have a nice day.
Maybe that is why Netscrape sucks so much ? People dropping out of college
before they learn how to use free() properly, design a piece of
software for a purpose and how not to bloat code.
Jaime, maybe you should go back to school and learn about these things.
Jay
--
Join the FreeBSD Revolution!
Jason Alan Nordwick <········@scheme.xcf.berkeley.edu> writes in
<···············@scheme.XCF.Berkeley.EDU>:
Jaime, maybe you should go back to school and learn about these things.
Or perhaps learn how to pick on people who haven't gone to college, eh?
I've been trying to find a copy of ON LISP by Paul Graham. I've
checked 6 of the local bookstores (Barnes & Noble, Stacy's (2 of
them), the Stanford Bookstore extension in Palo Alto, Kepler's and
one that used to be called Computer Literacy bookstore but is now
called Data Guru or something like that.
What bothered me about this experience wasn't just the fact that they
didn't have the book. But even determining that fact required
struggling past hundreds of copies of POWER VISUAL JAVA FOR DUMMIES IN
20 DAYS and the like. It was like the maze of twisty little passages,
all the same. Yesterday at the Data Guru bookstore, which is
completely devoted to computer books, I found ONE Lisp book.
The hype is depressing. Being in the computer field these days makes
me feel like a used-car salesman.
--
Fred Gilham gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
I wrote:
----------------------------------------
What bothered me about this experience wasn't just the fact that they
didn't have the book. But even determining that fact required
struggling past hundreds of copies of POWER VISUAL JAVA FOR DUMMIES IN
20 DAYS and the like. It was like the maze of twisty little passages,
all the same. Yesterday at the Data Guru bookstore, which is
completely devoted to computer books, I found ONE Lisp book.
The hype is depressing. Being in the computer field these days makes
me feel like a used-car salesman.
----------------------------------------
I guess my rant wasn't very clear (thanks, though, to the people who
told me how to get a copy of ON LISP). Seeing all the books about
C++, Java, C++, Windows 95, C++, Java, Visual Basic, Delphi, Java, C++
etc. makes me wonder about the long-term viability of Lisp. The point
is that if you can't find books about Lisp, how can you learn about
it?
I first got interested in Lisp when I got a Lisp interpreter put out
by the Software Toolworks that ran on my Heathkit H8 microcomputer.
After I got it I wandered down to the bookstore to find a Lisp book
and found Winston & Horn's LISP book (the first edition). I didn't
get very far because at that time I wasn't much of a programmer and
the Lisp interpreter wasn't much of a Lisp interpreter. But, starting
from that, I have collected a small library of Lisp books. I got
these at bookstores like Kepler's or Barnes & Noble. The situation is
nowhere near as good today.
I got a copy of Norvig's PARADIGMS OF AI PROGRAMMING at Barnes & Noble
a couple months ago. They never replaced it.
I wonder what can be done about it. I mean, I can buy the books but I
can't publish them. I don't think I can write them at this stage in
my career....
I borrowed a copy of ON LISP until I can get my own. It's
awe-inspiring!. One point Graham makes is the following:
The lack of a distinct name for the concepts underlying Lisp
may be a serious barrier to the language's acceptance.
Somehow one can say ``We need to use C++ because we want to do
object-oriented programming,'' but it doesn't sound nearly as
convincing to say ``We need to use Lisp because we want to do
Lisp programming.'' To administrative ears, this sounds like
circular reasoning. Such ears would rater hear that Lisp's
value hinged on a single, easily understood concept.
Graham gives a couple candidates that haven't proved convincing
(list-processing, symbolic computing, dynamic language) but doesn't
mention `interactive programming' which I think is where Lisp makes a
very powerful contribution. While it's not specific to Lisp, there
are few other programming environments that retain it while also
achieving high performance..
--
Fred Gilham gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
In article <··············@japonica.csl.sri.com>,
Fred Gilham <······@japonica.csl.sri.com> wrote:
> I've been trying to find a copy of ON LISP by Paul Graham. I've
> checked 6 of the local bookstores (Barnes & Noble, Stacy's (2 of
> them), the Stanford Bookstore extension in Palo Alto, Kepler's and
> one that used to be called Computer Literacy bookstore but is now
> called Data Guru or something like that.
This won't help you, but I managed to get a copy at Heffers in Cambridge,
England. I couldn't get a copy from several large bookshops in London or at
Blackwells in Oxford.
Heffers do keep it as standard stock, but it did take about four weeks for
it to be replaced when they sold the previous copy. They said they had to
wait for copies to come from the USA.
--
__ __ __ __ __ ___ _____________________________________________
|__||__)/ __/ \|\ ||_ | /
| || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines
___________________________/ ······@argonet.co.uk
Uploaded to newnews.dial.pipex.com on Fri,12 Sep 1997.18:56:01
David H Wild wrote:
>
> In article <··············@japonica.csl.sri.com>,
> Fred Gilham <······@japonica.csl.sri.com> wrote:
> > I've been trying to find a copy of ON LISP by Paul Graham. I've
> > checked 6 of the local bookstores (Barnes & Noble, Stacy's (2 of
> .......
Go to http://www.prenhall.com/search.html and do author search. No price
listed, however.
| > In article <··············@japonica.csl.sri.com>,
| > Fred Gilham <······@japonica.csl.sri.com> wrote:
| > > I've been trying to find a copy of ON LISP by Paul Graham. I've
| > > checked 6 of the local bookstores (Barnes & Noble, Stacy's (2 of
www.amazon.com
Fast, easy mail order. Kick-ass searching. No bullshit.
bc
Jason Alan Nordwick <········@scheme.xcf.berkeley.edu> writes:
> > --
> > Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
> > At any time, at any place, our snipers can drop you. Have a nice day.
>
> Maybe that is why Netscrape sucks so much ? People dropping out of college
> before they learn how to use free() properly, design a piece of
> software for a purpose and how not to bloat code.
>
> Jaime, maybe you should go back to school and learn about these things.
>
Do you really think you can put together something like Lucid Emacs
(now XEmacs) from the Emacs 19 prerelease without knowing how to use
free() ?
Do you as a fact that Jamie partecipated in the design of the Netscape
Navigator and didn't, say, moved there when such product was already
there ?
Maybe he just worked on the Unix port and the mailer and then moved to
other projects he didn't want to detail on the Net. Just an hypotesis,
mind you.
Myself, I'm half way through my Ph.D., but I really wish I had a
fifth of the hacking capabilities Jamie showed along the years (and
some of his resistence to sleep deprivation too...)
-mav
Jamie Zawinski wrote:
> I never went to college. The best hackers I've ever met never
> graduated. I think that staying in school until the bitter end says
> more about your ability to follow orders and your lack of desire to
> actually get to the point and produce software that real people use,
> than it says about your knowlege, skill, or critical reasoning ability.
>
> Don't equate "formal education" with "education." The two are largely
> orthogonal.
>
> I don't think Microsoft has anything to do with this.
>
Why not, specifically? Microsoft has done more than any other single
entity to shape the software industry, whether we like it or not.
Between the products they've stomped, legally and otherwise, the
products they've produced, the marketing blitzes targeting those
least qualified to make the decisions, and the design choices they've
made, I don't think there's *anything* about the software industry
that Microsoft has nothing to do with -- even such things as GNU are
shaped largely by the needs and market pressures Microsoft has
created. It was Bill Gates and Microsoft who started in with trying
to enforce archaic copyright laws on software in the first place.
How is it even remotely possible that they have "nothing to do" with
the current sorry and monopolized state of the software business and
the "blue-collarizing" of programming as a job?
Bear
--
A disciple of another sect once came to Drescher as he was
eating his morning meal. "I would like to give you this
personality test," said the outsider, "because I want you to
be happy." Drescher took the paper that was offered him and
put it into the toaster. "I wish the toaster to be happy too."
>However, if there really is a productivity advantage to Lisp, Modula-3,
>ML, etc, why not hire people and train them in the language?
We've done exactly this, with good success retraining skilled C++
programmers. One disadvantage: Once they've become Lisp programmers,
there's no going back...
Dan Corkill
Blackboard Technology
Fred Gilham <······@japonica.csl.sri.com> writes:
> I guess my rant wasn't very clear (thanks, though, to the people who
> told me how to get a copy of ON LISP). Seeing all the books about
> C++, Java, C++, Windows 95, C++, Java, Visual Basic, Delphi, Java, C++
> etc. makes me wonder about the long-term viability of Lisp. The point
> is that if you can't find books about Lisp, how can you learn about
> it?
From my very limited experience: things are not so bad. Internet helps
a lot and an interested person with access to Internet can find a lot
of good code and pedagogical material includeng this newsgroup (this
was my case, although I would never become interested in Lisp at all
if my friend would not explain me what antiLisp memes are all
about). Lisp survived for almost 40 years, it can survive 40 years
more in one form or another (may be Java will become more Lisp like or
whatever)
Bryan O'Sullivan wrote:
>
> b> Given that the practical alternatives to Java for real projects are
> b> C and C++, [...]
>
> j> I don't see this as factual, though it does seem to be the typical
> j> perception.
>
> Sure it's factual. If I had my druthers, I'd write my code in
> Modula-3, Scheme, or Eiffel as the fit took me, but there are a couple
> of considerations I have to deal with that prevent me from doing this:
>
> - I don't want to restrict the set of engineers I can hire who can
> start working on my project without having to learn a new language,
> along with possibly a new way of thinking. It's already quite hard
> enough to hire smart people.
I have heard this circular argument before!
If you hire smart programmers, then they won't have any
problems picking up a new language. Unless, you are the type
that hires people and expects results in the first two weeks.
(I will be happy to quote published experiences of good
C programmers picking up Modula-3 in a week or so.)
> - I don't want to have to worry about whether there's a compiler and
> runtime environment available for some random platform I'll need to
> worry about two years from now, and I don't want to worry about
> whether the compiler vendor is going to disappear because nobody
> cares about their products.
I have heard this statement before, also.
While the C++ or Java "ideals" fit the bill, that is, you'd *think*
you can find implementations for "random" platforms, the reality is far
from the ideal. I have seen far too many projects which took the
bait on this for even popular platforms (e.g., thinking their
complex Java programs will work across Windows/Solaris and/or
multiple browser implementations), and ended up shipping
only on a single platform.
Speaking of which, where can I get a supported Java
implementation for SunOS 4.1 running on SPARC--which
is far from "random"? The only supported
implementation of JavaVM that I know of for that
platform is the Critical Mass JVM, which incidently
was entirely written in Modula-3.
See http://www.cmass.com/jvm/ for more details.
Best Regards, -- Farshad
--
Farshad Nayeri ·······@cmass.com
Critical Mass, Inc. http://www.cmass.com
Cambridge, USA +1 617 354 6277
Disclaimer: I am biased!
[Followups directed to comp.lang.misc. Please don't both mail and
post followups to this article.]
f> If you hire smart programmers, then they won't have any problems
f> picking up a new language.
This is true, but I don't want to lock myself into having to find some
way to hire top-notch engineers in perpetuity.
f> While the C++ or Java "ideals" fit the bill, that is, you'd *think*
f> you can find implementations for "random" platforms, the reality is
f> far from the ideal.
No argument here. Java is the most prominent member of a small set of
languages that have a realistic chance of this ever being true,
though.
I might also note that, for most purposes, the advantages of Modula-3
and Eiffel over Java are incremental. Java gets it mostly right and
has several orders of magnitude more momentum than Modula-3 and Eiffel
combined, and so the 70% solution wins again.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
Bryan O'Sullivan wrote:
> Sure it's factual. If I had my druthers, I'd write my code in
> Modula-3, Scheme, or Eiffel as the fit took me, but there are a couple
> of considerations I have to deal with that prevent me from doing this:
> - I don't want to restrict the set of engineers I can hire who can
> start working on my project without having to learn a new language,
> along with possibly a new way of thinking. It's already quite hard
> enough to hire smart people.
I can offer some suggestions as to how you might go about hiring
smart people. Number one, do a better job of interviewing some
of Matthias's students. Some Silicon Valley companies are really
dumb in their interview policies, in terms of picking just a few
schools to interview at, and no others. Number two, your employer
(who is, to be fair, expanding their Boston-area operations, but
Boston only looks cheap to someone from Silicon Valley) lacks
geographic diversity. That is, it's hard to hire someone who is
CS-smart, yet stupid enough not to wonder about Silicon Valley's
0.5% rental vacancy rate and sky-high property values. Learning
a new language ought not be hard; I've learned many over the
years, and the only ones that I found hard were TeX and C++, and
most of the people I've worked with seemed to have little or no
trouble learning new languages, again with the exception of C++.
> - I don't want to have to worry about whether there's a compiler and
> runtime environment available for some random platform I'll need to
> worry about two years from now, and I don't want to worry about
> whether the compiler vendor is going to disappear because nobody
> cares about their products.
>
> If these don't seem like significant problems, that's great. I'm very
> happy for you.
These are not significant problems for a sufficiently well-designed
language.
Modula-3 has been ported to quite a few platforms on a shoestring --
working
for Olivetti, a team of not more than five (Me, Trevor, Mick, Steve,
Marion)
implemented the whole damn language, quite a few tools, and ported it to
Sun-68k, Sun-Sparc, Mach-386, plus a couple of others that I no longer
recall, and we did it in not more than 3 years, including a substantial
part of the language design and one major language revision. We did not
work weekends, we had lives outside our jobs, and for a decent part of
the
time the team was split geographically (once, from California to
England).
Scheme is similarly simple. Java is also relatively simple, though the
library and its interactions with the compiler (*) are a little
annoying.
(* The compiler from byte codes to native, that is.)
For a company as large as Sun, or IBM, or Apple, or Microsoft, if they
needed a language supported on multiple platforms, they could have it
for less than the yearly cost of a typical corporate vice president.
If Sun, Microsoft, IBM, or Apple decided to use Modula-3 and sent
money to the company supporting it, that company would be there as
long as Sun wanted. Same for Scheme, also same for Java.
Near as I can tell, the failure to use good languages is a management
failure, in that the people in charge of making these choices cannot
tell the difference between appropriate technology and inappropriate
technology, between competent people and charlatans, and instead simply
choose to follow the herd. Sun's major win with Java is not that it is
especially good compared to Scheme or Modula-3, but that it is head and
shoulders above the former choice of the herd, namely C++.
(Moo. :-)
--
David Chase, ·····@world.std.com
In article <··············@serpentine.com> Bryan O'Sullivan <···@serpentine.com> writes:
> b> Given that the practical alternatives to Java for real projects are
> b> C and C++, [...]
>
> j> I don't see this as factual, though it does seem to be the typical
> j> perception.
>
> Sure it's factual. If I had my druthers, I'd write my code in
Well, since we use alternatives here and they work for us, I don't see
this as factual. It is just the typical opinion from those who have
not really tried something else.
> - I don't want to restrict the set of engineers I can hire who can
Well, you get what you pay for. Having a pool of thousands of
C,C++,Java one week wonder hacks (learn C,C++,J in a week!, C,C++,J
for dummies, etc.) doesn't mean you are going to get anything worth
much fishing in that barrel.
> - I don't want to have to worry about whether there's a compiler and
> runtime environment available for some random platform I'll need to
Again - I think this is _way_ overly exaggerated for several viable
alternatives, including Ada95 and Eiffel.
> If these don't seem like significant problems, that's great. I'm very
> happy for you.
Thanks! It _is_ great.
> j> Certainly Ada95 is a completely viable and practical alternative
>
> The only thing I much care for about Ada is that its metastasis has
> now been outpaced by that of C++.
Whatever floats your boat!, ;-)
/Jon
--
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Bryan O'Sullivan wrote in article <··············@serpentine.com>...
>... it
>is very difficult to find talented Lisp programmers, and
Why is this the case? There are a lot of former Lisp programmers out there
that would love to shitcan the C++ work they've been doing.
>it is also
>difficult to find good commercial Lisp implementations that look like
>they'll still be alive and supported a few years from now.
What about Symbolics, er, Lucid, ummm, ....
But seriously, both Harlequin and Franz have been around for ages. I've
heard
that Harlequin doesn't need to make a profit in the Lisp division because of
support from other products, so I'd think that both of these would be
viable.
ET wheezed these wise words:
> Why is this the case? There are a lot of former Lisp programmers out there
> that would love to shitcan the C++ work they've been doing.
Good grief. _Former_ Lisp programmers?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
ignorance is better than stupidity
you can cure ignorance
In article <············@newsie2.cent.net> "ET" <········@eval-apply.com> wrote:
> Bryan O'Sullivan wrote in article <··············@serpentine.com>...
>
> >... it
Bryan O'Sullivan wrote in article <··············@serpentine.com>...
>... it
>is very difficult to find talented Lisp programmers, and
Why is this the case? There are a lot of former Lisp programmers out there
that would love to shitcan the C++ work they've been doing.
>it is also
>difficult to find good commercial Lisp implementations that look like
>they'll still be alive and supported a few years from now.
What about Symbolics, er, Lucid, ummm, ....
But seriously, both Harlequin and Franz have been around for ages. I've
heard
that Harlequin doesn't need to make a profit in the Lisp division because of
support from other products, so I'd think that both of these would be
viable.
>>>>> "Gareth" == Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
Gareth> But this doesn't help: it doesn't give you a real standard
Gareth> model of the naturals unless you already have a standard
Gareth> model of ZF.
Right. And a Platonist would say they had a preferred model, but
that's religion or ontology, not Math. And you're saying below that
we can't (just using ZFC) construct a model of ZFC by hand
Gareth> There's no very big problem with e.g. taking the power set
Gareth> 10 times. But if you start saying "keep on doing it for
Gareth> ever, and when you reach a limit ordinal just take the union
Gareth> of all earlier stages and continue", which is what you need
Gareth> to do to make a model of ZF, then you find that you need to
Gareth> know what ordinals are, and to be able to take the union of
Gareth> an infinite collection of sets, and stuff like that.
which maybe explains Goedel's 2nd incompleteness.
>> If fact the set theorists say they cannot even construct the real
>> line. Let's start with N -- that's quite believable, you only
>> need to start with the empty set and believe in mathematical
>> induction. Then R is pretty much defined to be the power set
>> 2^N, all the subsets of N. But what do you mean by "all"?
>> Doesn't in mean "all the subsets that there are"? Now we've left
>> Math for ontology.
Gareth> Too true.
Great! Yeah, how big is 2^N? How many subsets does N have? That's
the Continuum Hypothesis! From Just & Weese,
The power set axiom is a construction principle that would make an
architect perfectly happy, but would drive an engineer nuts. Such
an axiom is called {\em nonconstructive} by less irreverent authors.
Whatever subsets a given set happens to have, just slap curly braces
around it and that's a set too!
Gareth> Indeed. I got the impression that you were a Platonist
Gareth> (because of your willingness to talk about "the truths of
Gareth> number theory"), which is why I was asking.
Sorry.
>> Penrose gets himself into this problem in "Shadows of the Mind."
>> He says sure we know that CH is independent of ZFC, but there are
>> only 10 or so axioms that people are divided on, like MA. So
>> he's happy to say that there are 2^10 different models of ZFC in
>> the Platonic Hard Disk, and we can download whatever one we want.
>>
>> I say that's crazy, it's not just 10 axioms. There would be an
>> uncountably infinite number of versions of the real line which
>> violate CH.
Gareth> Absolutely right.
Great! I never read any such criticism, though. Hilary Putnam was
tasking Penrose about stuff that seemed a lot less telling to me, but
then I'm not really up on AI.
>> CH means there's one uncountable subset of R which is smaller
>> than R.
Gareth> Er, you mean not-CH, right?
Thanks. Sorry, I meant "no uncountable subset"
Gareth> I think what really makes Platonism hard to swallow these
Gareth> days is precisely the work of Goedel, Cohen et al. Not
Gareth> incompleteness as such -- that isn't really a problem -- but
Gareth> the empirical fact that there are lots of mathematical
Gareth> questions that (1) are undecidable with the axioms we have,
Gareth> and (2) seem as if they could go either way. That, plus the
Gareth> general anti-metaphysical tendency to object to statements
Gareth> whose meaning one can't explain. (What does it *mean* to say
Gareth> "the continuum hypothesis is true"? It's not a tautology;
Gareth> there don't seem to be any conceivable observations that
Gareth> would confirm or refute it; what *does* it mean? It's so
Gareth> hard to answer that that it's tempting to conclude that it
Gareth> doesn't really mean anything; that the feeling that it ought
Gareth> to mean something is a misleading one.)
As to (1), all the hoopla in "the field of Pure Math" (Fermat's Last
Theorem, fake R^4s, Witten superstring theory) is about consequences
of ZFC. I thought Will's Martin axiom stuff was interesting, and I
looked up an article by Mary Ellen Rudin in "Handbook Math Logic", by
Barwise, but that's the first I'd ever heard of it.
This sounds like I'm contradicting you, but I'm not: If all the "hot
action" in pure Math (even PDE & Dynamical Systems!) is in ZFC, then
Pure Math is formalism, we don't need a nice Platonic model of ZFC!
My feeling is that we bought into R = 2^N being unambiguous, or
Platonic, out of Newtonian classical mechanics, which is all about
real lines. But Quantum Mechanics probably needs a different way of
thinking, and the weirdness of Math Logic has gotta be part of it
(like Th(N) depending on our model of ZFC, which I didn't realize
before this thread), and you Lisp heads are a lot more interested in
Math Logic than my Pure Math bunch!
Erik Naggum <······@naggum.no> writes:
> * Mike Coffin
> | Now, Scheme is one of my favorite languages. And I don't claim any
> | universal significance to any of the reasons stated above: it's just one
> | project. But the practical arguments for Java in this project are pretty
> | overwhelming.
>
> how tolerant would Sun Microsystems, Inc, be of a project that elected
> _not_ to use Java at this time? how tolerant would Sun be of excellent
> reasons not to use Java presented by its own people?
I couldn't say; we didn't try. I can't speak for others, but *I* didn't
sense any pressure to use any particular language.
-mike
Mike Coffin wheezed these wise words:
> Now, Scheme is one of my favorite languages. And I don't claim any
> universal significance to any of the reasons stated above: it's just
> one project. But the practical arguments for Java in this project are
> pretty overwhelming.
I regret that this sounds painfully familiar.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
"As you read this: Am I dead yet?" - Rudy Rucker
Please note: my email address is gubbish
Bryan O'Sullivan <···@serpentine.com> writes:
> m> - We'd like to avoiding type errors in the extension code. Scheme
> m> is dynamically typed, so most errors don't show up until run
> m> time.
>
> Unfortunately, the absence of parameterised classes in Java makes this
> non-trivial. I have some enthusiasm for the work Phil Wadler and
> Martin Odersky have done on Pizza, but the syntactic decisions they
> made and the sugar they added are pretty heinous.
I definitely agree that it would be far better if Java had
parameterized classes (assuming they were done right). Still, some
compile-time type checking is far better than none.
-mike
From: Thant Tessman
Subject: Parameterized types in Java (Was: Will Java kill Lisp?)
Date:
Message-ID: <3409893E.41C6@signature.below>
Bryan O'Sullivan wrote:
> Unfortunately, the absence of parameterised classes in Java
> makes this non-trivial. I have some enthusiasm for the work
> Phil Wadler and Martin Odersky have done on Pizza, but the
> syntactic decisions they made and the sugar they added are
> pretty heinous.
Here's another proposal:
ftp://ftp.pmg.lcs.mit.edu/pub/thor/popl97/popl97.html
-thant
[...followup redirected...]
--
thant at acm dot org
w> I think Pizzas syntax is rather canonical.
Far from it; it's a grab bag of weird and inconsistent giblets, ears,
and toes from other languages. Some of the giblets represent
reasonable choices, and work well enough; others are not, and don't
work.
- The syntax Pizza uses for declaring parameterised interfaces and
classes leads to ambiguous parses. Consider:
interface Foo<Bar<T>> {
// is that a right shift above?
public interface Baz<Blat<Bong<Z>>> {
// what about the sign-extended shift here?
}
}
- The use of the word "fun" for anonymous functions comes straight
from ML.
- The use of "->" to denote the return type of a function comes from
any number of functional languages, and doesn't fit with any of
Java's syntax. What's wrong with the usual notation?
Regardless of whether you use the standard Java notation or this
icky special casing, the compiler has to do a lot of lookahead to
figure out what is going on.
It's also worth noting that the current syntax is misleading unless
you are more likely to be coming from an ML or Haskell background
than one of C or C++ (which is entirely unlikely for most of the
world), while at least the rest of Java's syntax is not going to
surprise C or C++ programmers.
- Pizza overloads the "case" keyword so that it no longer indicates
simply a particular choice in a switch statement, but also a
declaration of a symbolic atom. Oh, and you get to stick it in
front of a constructor declaration in one special case, too.
- The language permits casts between primitive types and the classes
that represent them. This is implicit magic that you don't see much
of in the rest of the Java language.
- Special-cased syntactic sugar for algebraic classes with a single
constructor is ugly and inconsistent with the usual Java thinking,
because Java provides very few redundant language-level mechanisms
for getting things done, and those that exist are well-chosen.
From where I'm sitting, it looks like the Pizza authors took the
features they wanted from other languages with the syntax they already
had, and simply grafted them straight onto Java without much thought
as to whether the notation fitted cleanly.
I particularly object to the syntactic choices that will confuse C and
C++ programmers, and also to the one-time special syntactic cases and
the shoehorning of new meanings into old keywords.
I thought C++ and Perl already gave us some pretty clear indications
that throwing random syntactic crud at a language in the hope that
some of it will stick is, shall we say, not quite the best way to
produce something that people will find either particularly easy to
learn in the short term, or memorable over a longer period of time.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
Bryan O'Sullivan <···@serpentine.com> writes:
> w> I think Pizzas syntax is rather canonical.
>
> Far from it; it's a grab bag of weird and inconsistent giblets, ears,
> and toes from other languages. Some of the giblets represent
> reasonable choices, and work well enough; others are not, and don't
> work.
>
> - The syntax Pizza uses for declaring parameterised interfaces and
> classes leads to ambiguous parses. Consider:
>
> interface Foo<Bar<T>> {
> // is that a right shift above?
> public interface Baz<Blat<Bong<Z>>> {
> // what about the sign-extended shift here?
> }
> }
This seems to me an LALR problem. Even Suns own Java parser generator,
JavaCC, provides better techniques which can resolve such
ambiguoities.
> - The use of the word "fun" for anonymous functions comes straight
> from ML.
This is not bad by definition. "method" cannot be used, since this
would surely lead to confusion. "static method" is to long.
> - The use of "->" to denote the return type of a function comes from
> any number of functional languages, and doesn't fit with any of
> Java's syntax. What's wrong with the usual notation?
C's syntax for higher oder types is horrible. Do you believe that
"(int ()(int))foo(int(x)(int))" is a better alternative then "int ->
int foo(int -> int x)"? (Don't take me for sure for the correctness of
the C'ish version ...)
> Regardless of whether you use the standard Java notation or this
> icky special casing, the compiler has to do a lot of lookahead to
> figure out what is going on.
Its the parser, and not the compiler, and this additional work most
probably amounts to 1 promille of the overall compilation task.
> - Pizza overloads the "case" keyword so that it no longer indicates
> simply a particular choice in a switch statement, but also a
> declaration of a symbolic atom. Oh, and you get to stick it in
> front of a constructor declaration in one special case, too.
I found this consistent, since the "case" for the class case is
related to using the "case" for matching a class term in a switch. And
the best of it: it doesn't reserves a further keyword. (Java already
steels far to much lower-case identifiers).
BTW, Java 1.1 does overload keywords as well, namely "class".
> - The language permits casts between primitive types and the classes
> that represent them. This is implicit magic that you don't see much
> of in the rest of the Java language.
Discussable. Though the absence of implicit casts from primtives to
their wrappers can be considered as a to less magic in Java as well.
> - Special-cased syntactic sugar for algebraic classes with a single
> constructor is ugly and inconsistent with the usual Java thinking,
> because Java provides very few redundant language-level mechanisms
> for getting things done, and those that exist are well-chosen.
If you view class cases as a sum of product types, this decision is
consistent; if you view them as syntactic sugar for introducing
subclasses, not. Anyway, it is a convenient feature in practice.
> From where I'm sitting, it looks like the Pizza authors took the
> features they wanted from other languages with the syntax they already
> had, and simply grafted them straight onto Java without much thought
> as to whether the notation fitted cleanly.
The examples you have given for this judgment are not convincing.
Actually, Pizza adds only a few new syntax constructs, and these
are, in my opinion, realtive cleanly designed.
Wolfgang
PS. For those following this discussion, and became interested
in Pizza, here is the URL:
http://www.cis.unisa.edu.au/~pizza/
--
··@cs.tu-berlin.de http://uebb.cs.tu-berlin.de/~wg/
Mike Coffin <···@Eng.Sun.COM> wrote in article <···············@Eng.Sun.COM>...
>
>[snip]
>
> - We'd like to avoiding type errors in the extension code. Scheme is
> dynamically typed, so most errors don't show up until run time.
>
Most _type-related_ errors -- even in Java, many serious errors still wait for
runtime to manifest.
IDK about others, but in my own case, type-related errors seem to be the least
of my worries. It sounds good to be able to detect of a whole class of errors
at compile-time, but one pays a big price for the luxury. Having had it both
ways (and given enough horsepower), I find I care less about type-safety than
the flexibility and expressiveness of a language -- a few naming conventions
seem to take care of virtually all type errors for me. ;-)
YMMV
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
"Bill House" <······@nospam.housewebs.com> writes:
> Mike Coffin <···@Eng.Sun.COM> wrote in article <···············@Eng.Sun.COM>...
> >
> >[snip]
> >
> > - We'd like to avoiding type errors in the extension code. Scheme is
> > dynamically typed, so most errors don't show up until run time.
> >
> Most _type-related_ errors -- even in Java, many serious errors still wait for
> runtime to manifest.
Like I said, with Scheme, most errors don't show up until run time.
With Java, a substantial portion show up at compile time. Not all of
them, that's for sure.
> IDK about others, but in my own case, type-related errors seem to be the least
> of my worries. It sounds good to be able to detect of a whole class of errors
> at compile-time, but one pays a big price for the luxury. Having had it both
> ways (and given enough horsepower), I find I care less about type-safety than
> the flexibility and expressiveness of a language -- a few naming conventions
> seem to take care of virtually all type errors for me. ;-)
>
> YMMV
I've had it both ways, too, and I *slightly* prefer the type checking.
When I compare two good languages, one dynamically typed and one
statically typed---say, Scheme and Modula-3---I find that I develop
code more quickly in Scheme. However, I find maintenance is a lot
easier in Modula-3, and the advantage grows with the age of the code
and the number of people who've worked on it.
-mike
Mike Coffin <···@eng.sun.com> wrote in article <···············@eng.sun.com>...
>
>[snip]
>
> I've had it both ways, too, and I *slightly* prefer the type checking.
> When I compare two good languages, one dynamically typed and one
> statically typed---say, Scheme and Modula-3---I find that I develop
> code more quickly in Scheme. However, I find maintenance is a lot
> easier in Modula-3, and the advantage grows with the age of the code
> and the number of people who've worked on it.
>
Slightly is reasonable. <g>
FWIW, all systems seem to grow chaotic over time. Original implementors create
the new order, maintenance programmers dissipate it until it's time to the next
new order to get created. ;-)
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
Shriram Krishnamurthi <·······@africa.cs.rice.edu> wrote in article
<···············@africa.cs.rice.edu>...
>
> In my experience, almost all my run-time errors in Scheme would have
> been caught by the type system in ML. (Yes, I do actually stop and
> check every time.)
>
Sounds interesting -- I'll have to try ML sometime.
[snip]
>
> I challenge anyone who makes these "flexibility and expressiveness"
> statements to try out a soft typer (the DrScheme Analysis engine, or
> Soft Scheme). You pay zero price for the luxury, and you catch real
> bugs. (Remember: many deep semantic bugs DO end up being reflected in
> little type errors.) You may find you no longer need to resort to
> methods like Hungarian coding, which is surely a product of a
> pre-technological age.
>
I might give it a try, but it may not work with our SmartLisp dialect. I did
have one type error last year that took me a whole 45 minutes to find -- how
long does it take for this thing to load?
BTW, Hungarian coding may seem Neanderthal, but I much prefer knowing the type
of something just by looking at it, rather than inferring its type from usage,
or rummaging about for type declarations. Unfortunately, some coders don't
seem to be able to invent variable names that I find particularly intuitive
(and they even have the nerve to say the same thing about me<g>)!
Bill House
----------------
http://www.housewebs.com
NOTE: My email address has been altered to confuse spambots.
Shriram Krishnamurthi <·······@new-world.cs.rice.edu> wrote in article
<··················@new-world.cs.rice.edu>...
>
> It's amusing that you argue about flexibility and expressiveness
> without even having tried the alternative.
>
I'm happy to provide you with entertainment. After all, I did spend the first
half of my life as a professional musician, so entertaining people is a
long-standing avocation of mine. <g>
Still, I didn't realize that ML was such a required tool as to engender guffaws
upon encountering someone not-yet-ML'ed -- I regularly code in 2-3 languages
for most projects, and have written non-trivial systems in about 7 different
languages (Lisp, VB, SQL, C, C++, Xbase, PowerBuilder and Pascal) , so it's not
like I don't try languages, it's just that I haven't had the chance to try ML
yet. FWIW, the language currently on my next-to-learn list is Python (because
I like the syntax).
>
> I don't understand what you're saying. You had only one type error
> all of last year? The longest time it took to find a type error was
> 45 minutes? The shortest time was 45 minutes?
>
One type-related error in Lisp. Of course, I had the usual spate of logic
errors, poorly-chosen algorithms, and just-plain-typos, but only one bona-fide
type error of the sort that type-checking would have uncovered (and that I had
to go looking for). I was working on a project where much of the code was not
Hungarian, so I got confused about the type of a variable and used it
improperly. Otherwise, type errors are just not that common for me. <shrug>
OTOH, type-checking alone would not be unwelcome, it's just that I'm loath to
give up the productivity advantages I enjoy with soft-typing just to have the
machine look over my shoulder. In that regard, the tools that you mention to
seem quite worthwhile.
All the best,
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
From: Michael Winikoff
Subject: Re: Soft Typing, (was Re: Will Java kill Lisp?)
Date:
Message-ID: <34132A11.284A07F8@cs.mu.oz.au>
Bill House wrote:
>
> Shriram Krishnamurthi <·······@new-world.cs.rice.edu> wrote in article
> <··················@new-world.cs.rice.edu>...
>
> >
> > I don't understand what you're saying. You had only one type error
> > all of last year? The longest time it took to find a type error was
> > 45 minutes? The shortest time was 45 minutes?
> >
> One type-related error in Lisp. Of course, I had the usual spate of logic
> errors, poorly-chosen algorithms, and just-plain-typos, but only one bona-fide
> type error of the sort that type-checking would have uncovered (and that I had
> to go looking for). I was working on a project where much of the code was not
> Hungarian, so I got confused about the type of a variable and used it
> improperly. Otherwise, type errors are just not that common for me. <shrug>
Actually type checking usually picks up other errors -- eg tyops.
I find that type checking is very useful when I'm modifying a program
in that it alerts me to the parts of the program which haven't been
updated to match the changes.
Michael
Michael Winikoff <········@cs.mu.oz.au> wrote in article
<·················@cs.mu.oz.au>...
>
> Actually type checking usually picks up other errors -- eg tyops.
>
Tyops? (suspecting intentional humor) <g>
>
> I find that type checking is very useful when I'm modifying a program
> in that it alerts me to the parts of the program which haven't been
> updated to match the changes.
>
That _can_ be a very good aspect of type-checking, but can also be a curse --
what if you already know about those other modules, but want to compile and
test your just-modified bit now anyway?
Rather than have strict type-checking imposed by the language, I think I'd
prefer a really good type-checking and semantic analysis utility. This might
provide all of the vaunted benefits, yet allow me to use it according to my
needs instead of adapting my methods to the needs of the compiler.
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
"Bill House" <······@nospam.housewebs.com> writes:
> That _can_ be a very good aspect of type-checking, but can also be a curse --
> what if you already know about those other modules, but want to compile and
> test your just-modified bit now anyway?
It seems by "module" you mean something that sputters all its bindings
into the top-level. Personally, I find it hard to call this a
"module" system in any real sense of the word. In anything I would
choose to call a module system, there would be a clear way of
describing what the imported bindings are (and their type signature,
where appropriate). In that case, the "curse" would disappear.
Once again: ML's approach to this problem is a pretty good first
approximation. It actually works for writing many interesting and
large programs. Likewise, the Analysis tool in DrScheme can analyze
programs written using DrScheme's unit system. Here, too, you get the
benefits without the drawbacks.
'shriram
Shriram Krishnamurthi <·······@new-world.cs.rice.edu> wrote in article
<···············@new-world.cs.rice.edu>...
>
> It seems by "module" you mean something that sputters all its bindings
> into the top-level.
>
I just mean some other compilation unit, or possibly another function within
the same compilation unit. That's really a side issue, with the central point
of my comment being that I can run my Lisp program and test some small part of
it before having to search through the entire app to fix all the ripple effects
that may exist. I might even decide _not_ to make the change after this, so
the ability to do "what-if" mods is a win for me in Lisp, regardless of the way
things work in other languages.
BTW, is there an ML for Windows? What persistence options are available for ML?
Can you do full-blown applications in ML, like you can in Python, or is this
more a teaching/research language?
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
Bill House wrote:
>
> BTW, is there an ML for Windows?
Yes; a very nice one, in fact. A trial version is available for
download at
http://www.harlequin.com
> Can you do full-blown applications in ML, like you can in Python, or is this
> more a teaching/research language?
Depends on what you need in the way of libraries for your particular
application; Python is way ahead of ML in this regard (though there is a
reasonable amount of ML stuff available). Harlequin ML is a true
compiler, though, and it blows the doors off any available Python
implementation when it comes to performance.
"Bill House" <······@nospam.housewebs.com> writes:
> Still, I didn't realize that ML was such a required tool as to
> engender guffaws upon encountering someone not-yet-ML'ed
Given your statements about type-checking, it's reasonable to assume
you've used what is perhaps the most paradigmatic modern _usable_
programming language with a sophisticated type system. Parading Lisp,
VB, SQL, etc. is fairly pointless, since all their type systems fall
into one of two categories: latently typed, or statically typed but
with very na"ive partition types. Until you've actually tried an
honest-to-goodness polymorphic type system, it's really pretty hard to
take complaints seriously.
'shriram
Axel Schairer <········@dfki.uni-sb.de> writes:
> What is `Hungarian coding'? -- Thanks, Axel
Az Magyar jel"ol'es van egy rendszer ... I mean, Hungarian coding
refers to a system popularized by Charles Simonyi (a native Hungarian)
of MS whereby variable names indicate the type of the variable. No
doubt everyone does this some of the time (any "meaningfully named
variable" does this anyway; many people use conventions like
pluralizing names that are bound to lists; etc). However, Simonyi
carried it further by defining a whole language of such notation, so
that the first several characters of a name indicated much of its type
information.
Simonyi described this, with examples, in his interview in the book
Programmers at Work (compiled by Susan Lammers, Microsoft Press, circa
1985). The convention produces seemingly garbled names; early users
commented that it looked so strange to them, it could as well have
been in Hungarian. The joke stuck.
An example is at
http://www.browsebooks.com/Gutz/Preface.html
A software engineering FAQ cites
Charles Simonyi and Martin Heller, "The Hungarian Revolution", BYTE,
Aug. 1991 (vol. 16, no. 8)
"Greg" has made public _his_ Hungarian conventions:
http://ivory.lm.com/~gregleg/hungarian.html
The C FAQ states
Hungarian Notation is a naming convention, invented by Charles
Simonyi, which encodes things about a variable's type (and perhaps
its intended use) in its name. It is well-loved in some circles and
roundly castigated in others. Its chief advantage is that it makes a
variable's type or intended use obvious from its name; its chief
disadvantage is that type information is not necessarily a
worthwhile thing to carry around in the name of a variable.
'shriram
Shriram Krishnamurthi wrote:
>
> Axel Schairer <········@dfki.uni-sb.de> writes:
>
> > What is `Hungarian coding'? -- Thanks, Axel
>
> Az Magyar jel"ol'es van egy rendszer ... I mean, Hungarian coding
> refers to a system popularized by Charles Simonyi (a native Hungarian)
What it actually does is make it more difficult for beginners to learn
any given language, while at the same time allowing people who are al-
ready proficient to feel superior to 'common folk.'
Actually, I guess it does have its place, but for someone learning a
language there are other things that are much more important. For ex-
ample, one so-called 'beginers' book on a popular programming language
goes to great lengths to promote Hungarian notation, but neglects to in-
clude information on such useful items as plotting a point on a graphics
screen, or how to open disk file for random access.
Ken
Shriram Krishnamurthi wrote:
> What you seem to not care about is a strong-typing discipline, which
> will reject erroneous programs.
I'm sure you meant to say some erroneous programs. Of course,
correct programs may get rejected (missing cast), or incorrect
programs my get accepted (erroneous cast).
R4RS says "Scheme has latent as opposed to manifest types".
I prefer this nomenclature over strong/weak typing.
(I dont think of Scheme as being a "weak" language,
nor do I think of Java as a "strong" language :-)
One of the ironies I find from the manifest (strong-typing) camp,
is the claim that, because manifest typing allows you to detect
errors at compile time, that you will correct them earlier.
In practice, I've found that good systems with latent typing
allow you to go throught the edit-(maybe compile)-run-debug cycle
so much faster, that type errors are actually corrected earlier.
Of course if all you are concerned with is detecting errors,
and not correcting...
-- Mike Klein
--
·············@alumni.caltech.edu
http://www.alumni.caltech.edu/~mklein
Mike Klein <······@alumni.caltech.edu.nospam> writes:
> I'm sure you meant to say some erroneous programs.
Obviously.
> Of course,
> correct programs may get rejected (missing cast), or incorrect
> programs my get accepted (erroneous cast).
One could argue that the program with the missing cast is not, in
fact, "correct". Reasonable type systems are crucially sound, so
within a certain, well-defined framework, you can tell exactly what
kinds of errors cannot possibly happen. (Arguably, some of those
claims are a touch fatuous, such as type versus variant errors.)
> R4RS says "Scheme has latent as opposed to manifest types".
>
> I prefer this nomenclature over strong/weak typing.
First of all, I think the terminology should be restricted to type
_checkers_, not type systems. Type systems have all sorts of
interesting properties, usually unrelated to what their corresponding
checkers do when they find a type invariant violated. However, the
terminological mix-up is probably here to stay. Given that:
A "strong type system" (checker) is one that actively disallows
programs from being processed further in the presence of type errrors.
(Insert caveats for obligatory pathological systems.)
A "weak type system" (checker) signals warnings, but lets the program
proceed with compilation/execution unmolested.
A "soft type system" (checker) signals warnings, and also inserts
run-time checks into the program at the potentially hazardous points.
You can then run the program and, if you do in fact violate a
condition, the inserted check will inform you of the transgression.
> One of the ironies I find from the manifest (strong-typing) camp,
> is the claim that, because manifest typing allows you to detect
> errors at compile time, that you will correct them earlier.
>
> In practice, I've found that good systems with latent typing
> allow you to go throught the edit-(maybe compile)-run-debug cycle
> so much faster, that type errors are actually corrected earlier.
Ah, but there's the dual problem of coverage. Running your program
only covers the portions that your test cases took into account. The
type system will examine the entire program -- even, of course, parts
that may potentially never be executed. This can be a annoying during
program development, which is why soft typing is such a nice
alternative.
'shriram
FWIW, I like your enumeration of the distinctions between the various flavors
of checking, and I agree that the conflation of terms is both unfortunate and
here to stay.
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
Axel Schairer <········@dfki.uni-sb.de> wrote in article
<·············@dfki.uni-sb.de>...
>
> What is `Hungarian coding'? -- Thanks, Axel
>
In Hungarian coding, you prefix your variable names to indicate their type and
possibly their visibility. For example, global variables would be prefixed
with the letter 'g', while string variables would be prefixed with 's'. Thus,
a global string variable would be:
gsFoo
while a local string variable would be
lsFoo
However, I usually don't use a prefix for local scope, since the lack of a
scope prefix identifies locals just as well, but with less typing. <g>
I can see how this might seem onerous to some, but for me, it's been an
effective way to reduce errors and improve the understandability of code,
particularly other people's code.
YMMV,
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
"Bill House" <······@nospam.housewebs.com> writes:
> For example, global variables would be prefixed
> with the letter 'g', while string variables would be prefixed with 's'. Thus,
> a global string variable would be:
> gsFoo
>
> while a local string variable would be
>
> lsFoo
I have always been curious how Hungarian coding could be effective
with any complicated type system. For example, it is quite common for
my programs to contain, say, lists of cons'es of symbols with numbers.
On purely information-theoretic grounds, this would require a good
many characters to encode, which would of course have to be typed
_every single use_. (Not to mention there's the problem of nesting,
whereas the common nesting characters -- the many flavors of
parentheses -- are already taken.)
How do you do it?
'shriram
Shriram Krishnamurthi <·······@new-world.cs.rice.edu> wrote:
| I have always been curious how Hungarian coding could be effective
| with any complicated type system. For example, it is quite common for
| my programs to contain, say, lists of cons'es of symbols with numbers.
| On purely information-theoretic grounds, this would require a good
| many characters to encode, which would of course have to be typed
| _every single use_. (Not to mention there's the problem of nesting,
| whereas the common nesting characters -- the many flavors of
| parentheses -- are already taken.)
|
| How do you do it?
Once upon a time, I was asked to take some C code from Microsoft's RTF
interpreter for Macintosh and use it somewhere else.
At one point in the program, a variable was mentioned: it was, and I
remember it vividly:
mpirrbisz
I asked everyone I knew what this meant. No one could figure it out.
Eventually we did figure out what the hungarian said, but it was so
complex that we couldn't figure out what it MEANT.
So, in answer to your question: "poorly", or at least in my humble opinion.
bc
waiting for the You're-too-stupid-to-live war of posturing to erupt.
··@wetware.com (Bill Coderre) wrote:
>Shriram Krishnamurthi <·······@new-world.cs.rice.edu> wrote:
>| I have always been curious how Hungarian coding could be effective
>| with any complicated type system. For example, it is quite common for
>| my programs to contain, say, lists of cons'es of symbols with numbers.
>| On purely information-theoretic grounds, this would require a good
>| many characters to encode, which would of course have to be typed
>| _every single use_. (Not to mention there's the problem of nesting,
>| whereas the common nesting characters -- the many flavors of
>| parentheses -- are already taken.)
>|
>| How do you do it?
>
>Once upon a time, I was asked to take some C code from Microsoft's RTF
>interpreter for Macintosh and use it somewhere else.
>
>At one point in the program, a variable was mentioned: it was, and I
>remember it vividly:
>
> mpirrbisz
Offhand, mpirrbisz would be the array that maps property entries to
RTF keywords.
Apparently nobody gave you the Hungarian documentation.
mpirrbisz is a MaPping of an Index to an RRB to an Index to a
zero-terminated string (SZ).
Now, as it turns out, an RRB is a structure internal to Microsoft
Word; it holds property information; but you would have had that
structure definition if you had the source.
Eric (who hasn't worked on that sort of stuff for 5 years now).
While talking of hungarian notation, the following pearl has been
forwarded recently from the 0xdeadbeef mailing list. Enjoy.
================================================================
MICROSOFT'S SIMONYI ON JAVA -- "IT'S THE MONKEES ALL OVER AGAIN"
Microsoft applications creator Charles Simonyi says Sun Microsystems' Java
language falls in the same category as Lisp, Smalltalk, Ada and all the
other "revolutionary" languages that claim to boost programmer productivity:
"It's the Monkees. They had a few hits and then disappeared. Java will be
the same. It will be totally forgotten. Microsoft is the Beatles."
Simonyi says Sun's claims to have solved the problem of programming
component software are suspect: "These problems have not even been solved
at Microsoft, in one company. How could anyone solve it across the Net?"
(Forbes ASAP 25 Aug 97)
> MICROSOFT'S SIMONYI ON JAVA -- "IT'S THE MONKEES ALL OVER AGAIN"
>
> Microsoft applications creator Charles Simonyi says Sun
> Microsystems' Java language falls in the same category as Lisp,
> Smalltalk, Ada and all the other "revolutionary" languages that
> claim to boost programmer productivity: "It's the Monkees. They had
> a few hits and then disappeared. Java will be the same. It will be
> totally forgotten. Microsoft is the Beatles." Simonyi says Sun's
> claims to have solved the problem of programming component software
> are suspect: "These problems have not even been solved at Microsoft,
> in one company. How could anyone solve it across the Net?" (Forbes
> ASAP 25 Aug 97)
I was confused about why Microsoft would be willing to buy a piece of
Apple merely to make Explorer the default web browser on Apple's
machines. Why does Microsoft consider Netscape to be the enemy?
Why does Microsoft consider Java to be the enemy?
This really puzzled me, but I think I've finally figured it out.
Microsoft, Netscape, and the part of Sun pushing Java aren't
interested in computers--they're interested in what they think
computers will become (or, more accurately, what they would LIKE
computers to become), and that is internet information appliances.
An internet information appliance (IIA) isn't a computer, although a
computer can be used as an IIA. From the point of view of people
developing software for the IIA, the BROWSER is the operating system.
This is a dream-come-true for anyone lucky enough to be in control of
this operating system (and, oh yeah, in control of how applications
are developed). For one thing, hardware becomes a genuine fungible
commodity. The developer doesn't have to worry about which platforms
to support. For another, very little software lives on the IIA
itself. This means that applications are no longer products, but
services leased from providers on the net on a per-use basis.
The IIA is a tool whose sole purpose is to make it easy for people to
sell products and services using the internet. This is why there is
so much industry...um...excitement over not the internet in general,
but browser technology specifically.
Now maybe I'm just dense and all this is obvious, but this hit me
like an electric shock. It explains so much of what otherwise
appears to be just so much chaos and stupidity in the computer
industry. And don't get me wrong--I'm a rabid defender of free-
market capitalism. IIAs will be even cheaper than computers, and
more stuff will be available to more people than ever before. This
is a good thing. (Well, at least it's better than television. No
FCC-imposed monopoly on content providers...so far.)
But I for one am not interested in internet information appliances.
I'm still interested in the *computer* as a general-purpose tool for
doing things that have never been done before. I'm interested in the
computer as an enabler, not just as a shopping cart. I'm interested
in interactive real-time 3D graphics, not forms and control panels.
I'm interested in products and services that don't have to have a
market of a million customers to justify the their development. I'm
interested in *programming*. (Remember when programming used to be
fun?)
Microsoft isn't at all interested in making it easy for anyone but
Microsoft to apply computers to new products and markets. Okay, fine,
I can deal with that. But now that that egomaniacal asshole Steve
Jobs is out to sabbotage what's left of the market for the MacOS, what
are we left with? UNIX? An extremely powerful and extremely
user-hostile operating system. Maybe the BeOS? I've had no
experience with it, but at least they aren't trying to use their OS
to sell hardware like Apple is (because they no longer sell hardware),
and they aren't trying to use their weight in the market to sell their
own apps like Microsoft is (because they don't have any weight in the
market).
I don't know. Are there any realistic OS alternatives that don't suck?
Do I have to choose between programming in C++ (for NT/UNIX) and Java
(for Netxplorer/Exscape)? Should I just get out of the business now
and learn to carve popsicle sticks for a living?
My appologies for the rant. I'll try not to let it happen again.
-thant (professional programmer)
--
thant at acm dot org
From: James P. White
Subject: Re: vent (Was: Hungarian coding (was: will Java ...))
Date:
Message-ID: <342336F9.866C10A1@pagesmiths.com>
Thant Tessman wrote:
> ...
> I don't know. Are there any realistic OS alternatives that don't suck?
> Do I have to choose between programming in C++ (for NT/UNIX) and Java
> (for Netxplorer/Exscape)? Should I just get out of the business now
> and learn to carve popsicle sticks for a living?
Your insight is quite correct. The entire Java battle is over "thin
clients", whether you want to call them set-top boxes, IIA, or
whatever. There is going to be many times more of those machines than
anything else (the larger part of 1billion connected computers).
Sun wants those machines to run JavaOS. M$ wants all 1billion to run
Windows, which means WinCE for those "thin clients". The only other OS
even on the field is OS/9 (because it is the most widely currently used
in set-top boxes, but WinCE in WebTV will change that PDQ), but there is
no reason to think it will get appreciable share.
So Mr. Bill really wants you to progam Java/Windows (but not until after
WinCE has a lock on those IIAs...). If you find this dismaying, imagine
how Andy Grove feels!
jim
-----------------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
···@aognet.net Pagesmiths' home is http://www.pagesmiths.com
From: Erik Naggum
Subject: Re: vent (Was: Hungarian coding (was: will Java ...))
Date:
Message-ID: <3083771156039913@naggum.no>
* Thant Tessman
| I was confused about why Microsoft would be willing to buy a piece of
| Apple merely to make Explorer the default web browser on Apple's
| machines. Why does Microsoft consider Netscape to be the enemy? Why
| does Microsoft consider Java to be the enemy?
it appears that Bill Gates spent that money on Apple out of fear of the
Feds and their anti-trust investigations. the guy is a just a criminal
with enough knowledge and understanding of the wording of the law to manage
to escape its intent -- to protect the public from predators like himself.
#\Erik
--
see http://www.naggum.no/emacs/ for Emacs-20-related material.
Erik Naggum <······@naggum.no> writes:
>
> it appears that Bill Gates spent that money on Apple out of fear of the
> Feds and their anti-trust investigations. the guy is a just a criminal
> with enough knowledge and understanding of the wording of the law to manage
> to escape its intent -- to protect the public from predators like himself.
>
I wouldn't be so drastic about Bill Gates. He (and MS) is doing what
comes more natural to every capitalist enterprise: i.e., in spite of
all the lassaiz-faire-ist rhetoric, become a monopolist.
--
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
········@cli.di.unipi.it (Pierpaolo Bernardi) writes:
>MICROSOFT'S SIMONYI ON JAVA -- "IT'S THE MONKEES ALL OVER AGAIN" ...
>It will be totally forgotten. Microsoft is the Beatles."
Hmm. My wife was born in 1966. She has heard _of_ the Beatles,
but doesn't know any of their songs, and when I got her a copy of
the Magic Myster Tour video, she disliked it. As far as she and
her younger sisters are concerned, the only memorable thing about
the Beatles is that an ex-Beatle is narrator on Thomas the Tank Engine.
"They're dead, Jim."
In short, I hope Microsoft _are_ like the Beatles.
>Simonyi says Sun's claims to have solved the problem of programming
>component software are suspect: "These problems have not even been solved
>at Microsoft, in one company. How could anyone solve it across the Net?"
_Somebody_ will have to.
--
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989. Maximum penalty: 10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
"Richard" == Richard A O'Keefe <··@goanna.cs.rmit.edu.au> writes:
Richard> ········@cli.di.unipi.it (Pierpaolo Bernardi) writes:
>> MICROSOFT'S SIMONYI ON JAVA -- "IT'S THE MONKEES ALL OVER
>> AGAIN" ... It will be totally forgotten. Microsoft is the
>> Beatles."
Richard> Hmm. My wife was born in 1966. She has heard _of_ the
Richard> Beatles, but doesn't know any of their songs, and when I
Richard> got her a copy of the Magic Myster Tour video, she
Richard> disliked it. As far as she and her younger sisters are
Richard> concerned, the only memorable thing about the Beatles is
Richard> that an ex-Beatle is narrator on Thomas the Tank Engine.
Richard> "They're dead, Jim."
Richard> In short, I hope Microsoft _are_ like the Beatles.
I was born in 1968, and I've probably heard everything the Beatles
recorded and owned every album they made. Try visiting some other
places - the Beatles still live. In Tokyo I saw the side of a building
with the cover of a Beatles album on it. Almost all my friends in the
USA (mostly born in the seventies) can, at least, sing along with
Beatles songs (even if they don't really like 'em). Most of my friends
back in India actually *like* them somewhat (if not more). (But I
haven't met anyone who likes the Magical Mystery Tour movie....)
In short, I hope Microsoft is _not_ like the Beatles.
I guess I tend to think of Lisp/Scheme/Functional Languages more like
Bob Dylan......really the greatest,and timeless, if you just cared to
listen.
Just a point of view!
Cheers!
Shyamal
--
These opinions are mine, not my employers.
From: David Chase
Subject: Re: vent (Was: Hungarian coding (was: will Java ...))
Date:
Message-ID: <3423D035.75A7@world.std.com>
Thant Tessman wrote:
> I don't know. Are there any realistic OS alternatives that don't suck?
> Do I have to choose between programming in C++ (for NT/UNIX) and Java
> (for Netxplorer/Exscape)? Should I just get out of the business now
> and learn to carve popsicle sticks for a living?
My employer would probably like to offer you the choice of Java on
NT/Unix,
but I'll be that's not going to make you much happier. I think the
future
is not quite that bleak. First of all, if you wanted to target Your
Favorite
Language to the JVM using one of those beauty-is-skin-deep ports (under
the
skin, it is ugly to the bone, of course) then you can play in YFL on all
these platforms.
I also have hopes that gadgets will become cheaper and easier to
program,
and Java or something like it might have something to do with that.
If you are interested in computer-as-enabler, why does all the enabling
have to come and go via a screen, mouse, and keyboard connected to a
gazillion bytes of ram and a gigantic disk and a semiconductor chip
running at microwave frequencies?
What bugs me is this vague worry that all this technology will end
up in the service of a corporate version of Big Brother. I keep
waiting for a really great way for lots of ordinary people to make
use of cheap technology. I see little direct connection there to
Java, or C++, or Lisp (and especially not to Hungarian Coding).
> My apologies for the rant. I'll try not to let it happen again.
No, no, there is nothing that I enjoy more than a good rant, especially
when it is on target. I keep suppressing my rants, because I
work for a little tiny company, and we'd hate to offend any potential
customers (look, see the power of the almighty dollar. God, what an
asshole I'd be if I were only rich).
--
David Chase, ·····@world.std.com
From: Erik Naggum
Subject: Re: Hungarian coding (was: will Java ...)
Date:
Message-ID: <3082832187575191@naggum.no>
* Shriram Krishnamurthi
| How do you do it?
the Hungarian naming convention breaks down phenomenally early in the
abstraction process. I think this is one of its main purposes: keep people
working with code that just about anybody could maintain without having to
look at the least number of lines of surrounding code to understand it.
I don't think Hungarian coders do it.
#\Erik
--
404 You're better off without that file. Trust me.
Shriram Krishnamurthi <·······@new-world.cs.rice.edu> wrote in article
<···············@new-world.cs.rice.edu>...
>
> I have always been curious how Hungarian coding could be effective
> with any complicated type system. For example, it is quite common for
> my programs to contain, say, lists of cons'es of symbols with numbers.
> On purely information-theoretic grounds, this would require a good
> many characters to encode, which would of course have to be typed
> _every single use_. (Not to mention there's the problem of nesting,
> whereas the common nesting characters -- the many flavors of
> parentheses -- are already taken.)
>
As with so many things, it's really a question of balance and moderation. I
don't drive myself crazy trying to create new encodings for the types I create,
I just use then to identify the system's intrinsic types. Also, I never exceed
3 characters in a prefix.
For example, in SmartLisp, we have Dictionary objects, which I encode with a
'dic' prefix:
(setq dicFoo (new Dictionary:))
This allows me to easily tell the dictionaries from the directory objects:
(setq dirFoo (new Directory:))
and the plain old structures:
(setq tFoo (makeStructure a: #void b: #void))
A list would just be 'lst', regardless of what it contained.
As you can see, the encoding can be fairly intuitive and does not need to be
made cryptic or _terribly_ unwieldy. If I was an absolutist about it, then I'd
risk wasting my time serving the technique, rather than the other way around. I
don't do this because I think it's the absolute living end, but because it
saves me time.
Also, I find I'm more productive if I adopt similar coding styles across all
the languages that I use. If I were able to work 100% in Lisp or Scheme, I
would probably alter by approach (especially to indenting) somewhat, but I
don't have that opportunity. While you can code C to look like the conventional
Lisp style, you have a harder time doing that with statement-oriented languages
like VB and SQL. So, for the sake of being able to switch back and forth
between languages more easily, I do some stylistic things in Lisp that most
Lispers (I think) don't do. <shrug>
Bill House
--
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
Somebody wrote:
>
> > > Java has the equivalent of closures, but in an object-oriented
> > > form. They seems to be as powerful as closures, though one
> > > could argue the pragmatics (syntax etc) are more cumbersome.
I always have to laugh when somebody says that putting wrapper classes
around functions is more "object-oriented" than passing the function
itself. In a real OO language, functions are objects, just like
everything else.
In article <·············@infinet.com>,
Bruce Tobin <······@infinet.com> wrote:
>Somebody [i.e. me, Per Bothner] wrote:
> > Java has the equivalent of closures, but in an object-oriented
> > form. They seems to be as powerful as closures, though one
> > could argue the pragmatics (syntax etc) are more cumbersome.
>I always have to laugh
"Laugh while you can, monkey-boy."
>when somebody says that putting wrapper classes
>around functions is more "object-oriented" than passing the function
>itself.
Who says that? I certainly didn't.
> In a real OO language, functions are objects, just like everything else.
Wrong. In *some* real OO languages, functions are objects.
--
--Per Bothner
Cygnus Solutions ·······@cygnus.com http://www.cygnus.com/~bothner