Will Java kill Lisp?
Erann Gat
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 g...@jpl.nasa.gov
mark carroll
In article <gat-2108...@milo.jpl.nasa.gov>,
Erann Gat <g...@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
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
Bryan O'Sullivan
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. b...@eng.sun.com
Please Do Not Crash. b...@serpentine.com
^G^IP@P6 http://www.serpentine.com/~bos
Bryan O'Sullivan
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.
Bill House
Erann Gat <g...@hpl.nasa.gov> wrote in article
<gat-2108...@milo.jpl.nasa.gov>...
>
>[snip]
>
> So is Lisp dead? Are there any
> compelling arguments for using Lisp over Java?
>
> E.
>
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 g...@jpl.nasa.gov
>
Farshad Nayeri
mark carroll wrote:
>
> In article <gat-2108...@milo.jpl.nasa.gov>,
> Erann Gat <g...@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)
>
>
> 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
jd marrow
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
Rainer Joswig
In article <5tjgre$r...@dfw-ixnews6.ix.netcom.com>, "jd marrow"
<pach...@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.
David Thornley
>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
Will Hartung
Farshad Nayeri <far...@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. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Bryan O'Sullivan
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.
Bryan O'Sullivan
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%.
Erann Gat
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.
Pohl Longsine
Erann Gat <g...@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.
Martin Rodgers
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
Farshad Nayeri
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 far...@cmass.com
Critical Mass, Inc. http://www.cmass.com
Cambridge, USA +1 617 354 6277
Thant Tessman
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
Farshad Nayeri
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:
Matt Wette
thor...@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
--
matthew...@jpl.nasa.gov -- I speak for myself, not for JPL.
Erik Naggum
* 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.
Cedric Adjih
Greg Sowder (greg...@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
Shriram Krishnamurthi
g...@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
Barry Margolin
In article <01bcaf84$c1c3a6a0$4fd270ce@none-o--yo-biz>,
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, bar...@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.
Georg Bauer
jd marrow <pach...@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
Georg Bauer
Thant Tessman <add...@signature.below> wrote:
> Java sucks. Java has the execution speed of an interpreted
> language and the development speed of a compiled language--
> the worst of both worlds.
Use a JIT-compiler, that will do the job. Really.
> Java has garbage collection, but no closures! And you still
> have to litter your code with checks for null pointers.
Use Pizza instead of Java :-)
(BTW: the null in Java is conceptual identical to the nil in Lisp, not
to the NULL in C++).
> It's "strongly" typed, but to build your own generic container
> classes you have to resort to storing "Objects" and dynamically
> typing them anyway! (To be fair, I know of at least one
> excellent proposal to fix this.)
Again, use Pizza. They support generic classes (something like the
templates of C++, but instead of them they work)
> Java's advantage is that it has a superficial resemblance to
> C++ which soothes the neophobes. The idea of writing something
> that runs on *anything* is an attractive one, but I wouldn't
> write in Java for any other reason.
Actually that's the worst you can do - learn C++ before Java totally
misleads you in the use of Java. Java only has the syntax of C++, but
the semantics are quite different. Ok, C semantics apply to a modest
degree, but C++ definetely not. Java is much more like a typed Smalltalk
than it is like C++.
I quite like Java (and Pizza even more). Ok, I don't like the syntax,
but I like the concept of a accepted virtual machine. But then, I
learned programming on UCSD-Pascal ;-)
But although I do program in Java and Pizza, it won't stop me from using
Common Lisp. Common Lisp is just to good - everything you may need is
alread there, and it's even there in several flavors! And you don't need
that brain-damaged type-casts you clutter your Java-code with (actually
_that's_ the biggest minus for me with Java. A static typed language
that needs that much type-casts must have something missing in the
design).
bye, Georg
Rainer Joswig
In article <87yb5ux...@serpentine.com>, Bryan O'Sullivan
<b...@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:
Rainer Joswig
In article <joswig-ya0231800...@news.lavielle.com>,
jos...@lavielle.com (Rainer Joswig) wrote:
Sorry, wrong link. This will work:
David Chase
hume...@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, ch...@world.std.com
Shriram Krishnamurthi
mcr@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
Matt Wolak
David Chase wrote:
> hume...@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
Martin Rodgers
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.
Martin Rodgers
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...
Bengt Kleberg
In article <5tnn80$k...@pasilla.bbnplanet.com>, Barry Margolin
<bar...@bbnplanet.com> wrote:
> In article <5tml8c$k...@news-rocq.inria.fr>,
> Cedric Adjih <ad...@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: ben...@damek.kth.se
Scott Draves
> :: 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."
Bryant Brandon
In article <gat-2108...@milo.jpl.nasa.gov>, g...@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 g...@jpl.nasa.gov
B.B.
David Thornley
In article <7k7mddg4...@nospam.jpl.nasa.gov>,
Matt Wette <Matthew...@nospam.jpl.nasa.gov> wrote:
>thor...@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.
>
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
>
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.
>
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
jd marrow
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
David Harris
thor...@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,
bran...@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 Chase
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, ch...@world.std.com
Martin Cracauer
Matt Wette <Matthew...@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
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%% 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.
David Chase
> 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
Matthias Blume
In article <5tvm90$dma$1...@rtl.cygnus.com> bot...@cygnus.com (Per Bothner) writes:
In article <JSA.97Au...@alexandria.organon.com>,
Jon S Anthony <j...@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
Shriram Krishnamurthi
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
Martin Rodgers
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_.
Bill House
Per Bothner <bot...@cygnus.com> wrote in article
<5u2213$fmv$1...@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
Barry Margolin
In article <01bcb334$0ae9d860$c4a1...@micron.dazsi.com>,
Bill House <bho...@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).
Joseph Allen Dane
Thant Tessman <add...@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
Erann Gat
In article <01bcb334$0ae9d860$c4a1...@micron.dazsi.com>, "Bill House"
<bho...@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.
Mike Coffin
"Bill House" <bho...@nospam.housewebs.com> writes:
> Per Bothner <bot...@cygnus.com> wrote in article
> <5u2213$fmv$1...@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
Vassili Bykov
In article <gat-2808...@milo.jpl.nasa.gov>,
g...@jpl.nasa.gov (Erann Gat) wrote:
>
> In article <01bcb334$0ae9d860$c4a1...@micron.dazsi.com>, "Bill House"
> <bho...@nospam.housewebs.com> wrote:
>
> > object of any type, but I didn't think that this exactly qualified it as
> > dynamically-typed language.
>
> 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
Martin Rodgers
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?
Bill House
Mike Coffin <m...@Eng.Sun.COM> wrote in article <8p6iuwq...@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.
>
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 <m...@Eng.Sun.COM> wrote in article <8p6iuwq...@Eng.Sun.COM>...
> "Bill House" <bho...@nospam.housewebs.com> writes:
>
> > Per Bothner <bot...@cygnus.com> wrote in article
> > <5u2213$fmv$1...@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
Chris Cole
> 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
Bruce Tobin
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.
Olivier Lefevre
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.
Erik Naggum
* 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.
Martin Rodgers
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.
Bryan O'Sullivan
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. b...@eng.sun.com
Please Do Not Crash. b...@serpentine.com
^G^IP@P6 http://www.serpentine.com/~bos
Mike Coffin
Bryan O'Sullivan <b...@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
Mike Coffin
Erik Naggum <cle...@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
Thant Tessman
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
Per Bothner
In article <34077F...@infinet.com>,
Bruce Tobin <bto...@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 bot...@cygnus.com http://www.cygnus.com/~bothner
Jon S Anthony
> 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
Bryan O'Sullivan
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.
Bryan O'Sullivan
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++.
Bengt Kleberg
In article <87d8mtx...@serpentine.com>, Bryan O'Sullivan
<b...@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: ben...@damek.kth.se
Samuel S. Paik
In article <87d8mtx...@serpentine.com>, Bryan O'Sullivan
<b...@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| pa...@webnexus.com
Speak only for self
Wolfgang Grieskamp
Bryan O'Sullivan <b...@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:
Erik Naggum
* 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.
dan corkill
>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
Farshad Nayeri
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 far...@cmass.com
Critical Mass, Inc. http://www.cmass.com
Cambridge, USA +1 617 354 6277
Disclaimer: I am biased!
Bryan O'Sullivan
[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.
David Chase
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, ch...@world.std.com
Frank A. Adrian
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
frank_...@firstdatabank.com (W)
fra...@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.
Jon S Anthony
In article <87d8mtx...@serpentine.com> Bryan O'Sullivan <b...@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!, ;-)
Kelly Murray
> > 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 k...@franz.com http://www.franz.com
Martin Rodgers
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
ET
Bryan O'Sullivan wrote in article <87lo1jy...@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.
Martin Rodgers
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_. :-)
Farshad Nayeri
(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.
Martin Rodgers
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?
Mike Coffin
"Bill House" <bho...@nospam.housewebs.com> writes:
> Mike Coffin <m...@Eng.Sun.COM> wrote in article <8p667so...@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
Bill House
Mike Coffin <m...@Eng.Sun.COM> wrote in article <8p667so...@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
Richard A. O'Keefe
k...@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.
Bill House
Mike Coffin <m...@eng.sun.com> wrote in article <8p6n2lt...@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.
>
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
Shriram Krishnamurthi <shr...@africa.cs.rice.edu> wrote in article
<j7vu3g1...@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.
David Hanley
Pierpaolo Bernardi wrote:
> Kelly Murray (k...@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
Shriram Krishnamurthi
Axel Schairer <scha...@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
Mike Klein
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
--
mailto:mkl...@alumni.caltech.edu
http://www.alumni.caltech.edu/~mklein
Bill House
Shriram Krishnamurthi <shr...@new-world.cs.rice.edu> wrote in article
<j7vzpps6h...@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
Bill House
Axel Schairer <scha...@dfki.uni-sb.de> wrote in article
<340FB8...@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,
Erik Naggum
* 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.
Scott Draves
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).
Erik Naggum
* 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.
Chad Woodford
On Fri, 05 Sep 1997 20:22:23 -0700, Jamie Zawinski <j...@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 wood...@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.
Martin Rodgers
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"?
Will Hartung
Erik Naggum <cle...@naggum.no> writes:
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. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Bill Richter
>>>>> Erik <cle...@naggum.no> responds to Jamie Zawinski <j...@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...