As you probably know, recently Java has incorpored annotations and
templates into its syntax, and the combinations of both make Java more
dinamic and in some way closer to the compiler behavor as Lisp macros
do.
Now, they are pretending to add closures. You can find the paper
explaining their intentions here:
http://blogs.sun.com/roller/resources/ahe/closures.pdf
Now I'm thinking: it is really true that the programming world is
tending towards Lisp. If we continue in this line, we're going to have
Java and other languages evolutionating until they are very close to
Lisp.
But the most interesting thing is that they are implementing these
things now, but most of them just ignore that Lisp was able to do so
from 30 years ago to now!
I'd like to read some comments from all you experts.
Javier wrote:
> Now I'm thinking: it is really true that the programming world is
> tending towards Lisp...but most of them just ignore that Lisp was able to do so
> from 30 years ago to now!
(a) Too embarrassing
(b) They want people to say "gee whiz!" over "new" features, not roll
their eyes.
(c) You are wrong. They usually mention somewhere in half a
parenthetical clause that there used to be a language called Lisp that
did something similar.
>
> I'd like to read some comments from all you experts.
>
Finally I am getting some recognition around here!
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
For some reason my mind jumped straight to: "Pigs are going to have
wings."
(Kenny must be rubbing off!)
Javier wrote:
> As you probably know, recently Java has incorpored annotations and
> templates into its syntax, and the combinations of both make Java more
> dinamic and in some way closer to the compiler behavor as Lisp macros
> do.
> Now, they are pretending to add closures. You can find the paper
> explaining their intentions here:
>
> http://blogs.sun.com/roller/resources/ahe/closures.pdf
>
> Now I'm thinking: it is really true that the programming world is
> tending towards Lisp. If we continue in this line, we're going to have
> Java and other languages evolutionating until they are very close to
> Lisp.
> But the most interesting thing is that they are implementing these
> things now, but most of them just ignore that Lisp was able to do so
> from 30 years ago to now!
>
> I'd like to read some comments from all you experts.
Javier wrote:
...
> Now I'm thinking: it is really true that the programming world is
> tending towards Lisp. If we continue in this line, we're going to have
> Java and other languages evolutionating until they are very close to
> Lisp.
I haven't yet seen anyone comment on the extraordinarily awkward way
that Java is now dodging its own type system. Starting with Struts and
enshrined in the JSP expression language, a lot of Java programming now
uses String references like "foo.bar", which eventually get processed
through the reflection APIs to try to call a method "getBar()" on the
object named "foo."
All of this drives me nuts. I feel like "you're telling me you put me
through the hell of coding in a 'type safe' language but once I get up
to the presentation layer I'm just going to completely lose the
supposed benefits of type safety?" And the behavior when the types
mismatch is erratic. If I try to test (foo.bar == 3) and the object foo
has no member bar, I would really prefer an exception be raised, rather
than the expression evaluate to false.
Regarding Java closures, as a working Java programmer, I can tell you
that if they include this in the language I will use function types
every single day. I am constantly writing inner classes whose only
member is a function -- this syntax will cut out two thirds of the code
for doing that and really improve the clarity. I don't bump into the
need to close over a variable that often, but it does happen.
On 2006-08-24 01:43:27 +0100, "Javier" <·······@gmail.com> said:
> But the most interesting thing is that they are implementing these
> things now, but most of them just ignore that Lisp was able to do so
> from 30 years ago to now!
The people who designed Java were very well aware of Lisp: look at the
authors of the JLS.
I wasn't there, but I imagine that what they wanted to do was design a
language which was widely taken up, but achieved several crucial
benefits over the then state of the art. And to do this before
Microsoft ate their lunch.
`Widely taken up' is important: if you think you have a way of
improving the safety (say) of programs, then unless a language which
incorporates that mechanism is widely used, you have achieved nothing.
One way of improving a language's chances of being widely taken up is
to be culturally compatible with an existing, widely used, language.
So Java is culturally compatible with C (and not with Lisp). (Perl is
another example: culturally compatible with sh, awk, sed etc.)
The big win Java achieved was to get automatic memory management
accepted. It's hard to stress how important this is: in 1994 almost
everyone thought that GCd languages were unusable because they were
`too big and slow'. Now almost no-one thinks that, and that's because
of Java. Now one of the most commonly used vendor-neutral languages is
one in which it is not possible to trample on arbitrary memory. It is
hard to stress enough how enormous that achievement is.
(It's significant that Java does this whole memory-safety thing better
than CL: it mandates things that CL makes only optional at high
optimization settings.)
Another thing Java has is a huge standard library, most of which is
usable, and which is cross-platform. That's another very significant
win: you can write programs in Java which generate handcrafted UDP
packets and have them just work on all the major platforms, for
instance. CL missed this trick (though it looks to be catching up).
Java missed out on at least two things.
An extensible syntax (some kind of prefix syntax) with macros etc.
Could it have done this while being culturally compatible with C? I
suspect it couldn't, but it's still a shame.
A coherent object-based semantics, with everything being an object,
closures, and preferably multiple inheritance. I hate that they
didn't do this but instead botched things with non-object types like
int, and a rudimentary object system. Whether they could have done
this while maintaining cultural compatibility with C I'm not sure.
More to the point could they have implemented a compiler & runtime that
worked reasonably well in the time available (before MS ate them in
other words)?
--tim
Tim Bradshaw wrote:
> On 2006-08-24 01:43:27 +0100, "Javier" <·······@gmail.com> said:
>
> > But the most interesting thing is that they are implementing these
> > things now, but most of them just ignore that Lisp was able to do so
> > from 30 years ago to now!
>
> The people who designed Java were very well aware of Lisp: look at the
> authors of the JLS.
> [...]
I'm feeling that these wonderful workers are loosing their times
designing and improving something that was invented much time before.
But, what can we do? People tends to move in the same direction as
everyone does.
Just imagine how wonderful the programming world would be if everyone
adopted Lisp several years ago in the same way they have done with
Java. But it's only a dream.
On 2006-08-25 02:24:52 +0100, "Javier" <·······@gmail.com> said:
> Just imagine how wonderful the programming world would be if everyone
> adopted Lisp several years ago in the same way they have done with
> Java. But it's only a dream.
Precisely my point. Dreaming is not useful, you need to actually *get
GC accepted* by average Joe Programmer. Java did that.
--tim
Tim Bradshaw wrote:
> Precisely my point. Dreaming is not useful, you need to actually *get
> GC accepted* by average Joe Programmer. Java did that.
I'm surprised to hear so many people saying that when Java is notoriously
slow.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
On 2006-08-25 08:23:01 +0100, Jon Harrop <···@ffconsultancy.com> said:
> I'm surprised to hear so many people saying that when Java is notoriously
> slow.
It's notoriously slow in the sense that Lisp is notoriously slow, which
is that (a) startup time could be better on some platforms, (b) some
*amazingly* badly written programs have been written, which are very
slow and (c) some very old implementations were slow.
--tim
Tim Bradshaw wrote:
> On 2006-08-25 08:23:01 +0100, Jon Harrop <···@ffconsultancy.com> said:
>> I'm surprised to hear so many people saying that when Java is notoriously
>> slow.
>
> It's notoriously slow in the sense that Lisp is notoriously slow,
Yes.
> which is that (a) startup time could be better on some platforms,
Indeed, startup time is orders of magnitude slower for Java than most other
languages.
> (b) some *amazingly* badly written programs have been written, which are
> very slow and
Do you think that Java makes it easy to write slow code? I find it
impossible to write efficient code in Java.
> (c) some very old implementations were slow.
I'm using Sun's JDK 1.5 and I'm still finding Java to be very slow compared
to other languages. Even after hand-coding string buffers/builders and so
forth, when none of the other languages require it.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
On 2006-08-28 02:42:13 +0100, Jon Harrop <···@ffconsultancy.com> said:
>
> Do you think that Java makes it easy to write slow code? I find it
> impossible to write efficient code in Java.
It has the same characteristics as Lisp: it's easy to make complicated
data structures (in the same way as C and Lisp, but not, say, Perl),
*and* it has GC and other memory safety features, which means that it's
possible to get away with code which is so bad it would be humanly
impossible to write in C, say.
> I'm using Sun's JDK 1.5 and I'm still finding Java to be very slow compared
> to other languages. Even after hand-coding string buffers/builders and so
> forth, when none of the other languages require it.
I've never had this experience for code I've written in Java. I
specifically tested things I was worried about and found it to be close
enough to C as made no odds. As far as I can tell everything spends
all its time waiting for memory and I/O now - processor time is
essentially free.
--tim
Tim Bradshaw wrote:
> On 2006-08-28 02:42:13 +0100, Jon Harrop <···@ffconsultancy.com> said:
>> Do you think that Java makes it easy to write slow code? I find it
>> impossible to write efficient code in Java.
>
> It has the same characteristics as Lisp: it's easy to make complicated
> data structures (in the same way as C and Lisp, but not, say, Perl),
> *and* it has GC and other memory safety features, which means that it's
> possible to get away with code which is so bad it would be humanly
> impossible to write in C, say.
Is that not equally true of many other languages that do not share Java's
reputation for being slow?
>> I'm using Sun's JDK 1.5 and I'm still finding Java to be very slow
>> compared to other languages. Even after hand-coding string
>> buffers/builders and so forth, when none of the other languages require
>> it.
>
> I've never had this experience for code I've written in Java. I
> specifically tested things I was worried about and found it to be close
> enough to C as made no odds. As far as I can tell everything spends
> all its time waiting for memory and I/O now - processor time is
> essentially free.
I recently wrote s-expr lexers and parsers in OCaml, C++ and Java. The OCaml
and C++ were both several times faster than the Java. I find this
particularly surprising because I expected parsing to be IO bound and not
CPU bound.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Jon Harrop <···@ffconsultancy.com> writes:
[...]
> I recently wrote s-expr lexers and parsers in OCaml, C++ and
> Java. The OCaml and C++ were both several times faster than the
> Java. I find this particularly surprising because I expected parsing
> to be IO bound and not CPU bound.
I expect there are character set issues there. Java uses UCS-2, IIRC,
whereas OCaml's 8-bit characters (I think?), and probably your C++ is,
too.
Probably other things are in play, too, but my guess is that some
random benchmark doing text manipulation would tend to end up slower
in languages which used several bytes per character than those that
didn't.
Bruce Stephens wrote:
>> I recently wrote s-expr lexers and parsers in OCaml, C++ and
>> Java. The OCaml and C++ were both several times faster than the
>> Java. I find this particularly surprising because I expected parsing
>> to be IO bound and not CPU bound.
>
> I expect there are character set issues there. Java uses UCS-2, IIRC,
> whereas OCaml's 8-bit characters (I think?), and probably your C++ is,
> too.
That is almost certainly the case. However, I wouldn't expect more than a
factor of 2 due to Unicode. I'll look up the timings I got...
> Probably other things are in play, too, but my guess is that some
> random benchmark doing text manipulation would tend to end up slower
> in languages which used several bytes per character than those that
> didn't.
Well, Java is also 2.5x slower than C++ on my ray tracer benchmark.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Jon Harrop <···@ffconsultancy.com> writes:
> Bruce Stephens wrote:
[...]
>> I expect there are character set issues there. Java uses UCS-2, IIRC,
>> whereas OCaml's 8-bit characters (I think?), and probably your C++ is,
>> too.
>
> That is almost certainly the case. However, I wouldn't expect more than a
> factor of 2 due to Unicode. I'll look up the timings I got...
I wouldn't be surprised. You might get wacky caching effects, for
example. Also, I imagine there might be optimization tricks that make
sense if you're dealing with only 256 chars (or 8 bits) which are less
attractive with 65536 (16 bits).
>> Probably other things are in play, too, but my guess is that some
>> random benchmark doing text manipulation would tend to end up slower
>> in languages which used several bytes per character than those that
>> didn't.
>
> Well, Java is also 2.5x slower than C++ on my ray tracer benchmark.
Yeah, that feels less defensible. That's the kind of thing that JIT
compilers ought to be good for, I'd have thought.
On 2006-08-28 23:44:50 +0100, Jon Harrop <···@ffconsultancy.com> said:
>
> Is that not equally true of many other languages that do not share Java's
> reputation for being slow?
Which languages? And why are they not perceived as being slow? I
suspect the answer is `because there are no examples of millions of
lines of marginal code, written using marginal frameworks by marginal
programmers, which have appalling performance'. That, combined with
the normal `there were once some rather badly performing
implementations, so we all know the language is slow' is why people
said Lisp was slow, and it's why people say Java is slow too.
>
> I recently wrote s-expr lexers and parsers in OCaml, C++ and Java. The OCaml
> and C++ were both several times faster than the Java. I find this
> particularly surprising because I expected parsing to be IO bound and not
> CPU bound.
Well, where did the time go? Did you profile it all? Did they do the
same thing (for instance were they all Unicode-based?). Was the
parsing performance likely to be on the critical path for any actual
application? Finally, are you claiming that this slowness is inherent
in the language (including in the use of the JVM) or is it just a poor
implementation?
Incidentally, don't get me wrong when I say Java isn't slow: I'm sure
there are cases where a straight-to-native-code system can beat a Java
-> JVM -> native system quite handsomely. What I'm saying is that the
reasons people perceive Java as slow are those I gave above, and not
related to actual performance of implementations.
--tim
Tim Bradshaw wrote:
> On 2006-08-28 23:44:50 +0100, Jon Harrop <···@ffconsultancy.com> said:
>> Is that not equally true of many other languages that do not share Java's
>> reputation for being slow?
>
> Which languages?
OCaml and SML, for example. I'm sure there are others (Clean?).
> And why are they not perceived as being slow?
Because they execute people's programs quickly.
> I
> suspect the answer is `because there are no examples of millions of
> lines of marginal code, written using marginal frameworks by marginal
> programmers, which have appalling performance'. That, combined with
> the normal `there were once some rather badly performing
> implementations, so we all know the language is slow' is why people
> said Lisp was slow, and it's why people say Java is slow too.
I see what you're saying but my belief that Java is slow stems more from my
own, almost-verbatim translations, running much more slowly in Java than in
most other languages.
>> I recently wrote s-expr lexers and parsers in OCaml, C++ and Java. The
>> OCaml and C++ were both several times faster than the Java. I find this
>> particularly surprising because I expected parsing to be IO bound and not
>> CPU bound.
>
> Well, where did the time go? Did you profile it all?
I never bothered profiling it but, as Bruce has pointed out, part of the
problem will be Java using Unicode by default.
> Did they do the
> same thing (for instance were they all Unicode-based?). Was the
> parsing performance likely to be on the critical path for any actual
> application?
Yes, this is for a GUI client. Startup time was sometimes minutes so we were
asked to optimise the Java. The first thing we did was get rid of the XPath
stuff because it was giving asymptotically poor performance. I wrote the
s-expr lexer and parser. Startup time is now almost 3 orders of magnitude
faster and the rest of the GUI is much more responsive too (all
communication with the server was over s-exprs).
> Finally, are you claiming that this slowness is inherent
> in the language (including in the use of the JVM) or is it just a poor
> implementation?
Both. Java's stdlib is appallingly bloated and slow, IMHO, but the language
itself doesn't seem to be able to give good performance on anything
non-trivial (e.g. nbody).
> Incidentally, don't get me wrong when I say Java isn't slow: I'm sure
> there are cases where a straight-to-native-code system can beat a Java
> -> JVM -> native system quite handsomely. What I'm saying is that the
> reasons people perceive Java as slow are those I gave above, and not
> related to actual performance of implementations.
Well, I won't expect Java to get within 2x the performance of C++ or OCaml
on any of my real applications.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Jon Harrop wrote:
> I never bothered profiling it but, as Bruce has pointed out, part of the
> problem will be Java using Unicode by default.
You do performance measurements but you don't profile? Oh dear.
--tim
Tim Bradshaw wrote:
> Jon Harrop wrote:
>> I never bothered profiling it but, as Bruce has pointed out, part of the
>> problem will be Java using Unicode by default.
>
> You do performance measurements but you don't profile?
Yes, I just wrote straightforward code in all of the languages and only Java
was several times slower. Not profiling doesn't invalidate the
performance...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
On 2006-08-29 20:19:30 +0100, Jon Harrop <···@ffconsultancy.com> said:
> Yes, I just wrote straightforward code in all of the languages and only Java
> was several times slower. Not profiling doesn't invalidate the
> performance...
It does, however, invalidate almost any useful conclusion you might
draw, and in particular the ones you want to draw (`the language itself
doesn't seem to be able to give good performance on anything
non-trivial (e.g. nbody)' for instance). It's probably the case that a
human being could have a reasonably accurate mental performance model
of (small) C programs on something like a PDP11, but I'm reasonably
sure that no one has a model that is even faintly for programs written
in a language with a huge complex runtime library and a sophisticated
GCd implementation, on modern hardware: predicting performance of the
hardware alone is an enormous challenge. (Unfortunately, of course,
most people's mental model is `a giant PDP11'.) You need to profile to
understand performance, and with a good profiler to boot.
What's particularly bizarre about this whole thread is that I've made
*exactly* these arguments about Lisp rather than Java.
--tim
Tim Bradshaw wrote:
> On 2006-08-29 20:19:30 +0100, Jon Harrop <···@ffconsultancy.com> said:
>> Yes, I just wrote straightforward code in all of the languages and only
>> Java was several times slower. Not profiling doesn't invalidate the
>> performance...
>
> It does, however, invalidate almost any useful conclusion you might
> draw, and in particular the ones you want to draw (`the language itself
> doesn't seem to be able to give good performance on anything
> non-trivial (e.g. nbody)' for instance).
My conclusion was not based upon one program.
> It's probably the case that a
> human being could have a reasonably accurate mental performance model
> of (small) C programs on something like a PDP11, but I'm reasonably
> sure that no one has a model that is even faintly for programs written
> in a language with a huge complex runtime library and a sophisticated
> GCd implementation, on modern hardware: predicting performance of the
> hardware alone is an enormous challenge. (Unfortunately, of course,
> most people's mental model is `a giant PDP11'.)
Agreed.
> You need to profile to
> understand performance, and with a good profiler to boot.
Profiling simply gives you a breakdown of where the time was spent, it
doesn't let you "understand performance".
More importantly, I'm not interested in highly-optimised and tuned Java vs
ordinary C++, OCaml etc.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Tim Bradshaw wrote:
> On 2006-08-29 20:19:30 +0100, Jon Harrop <···@ffconsultancy.com> said:
>> Yes, I just wrote straightforward code in all of the languages and only
>> Java was several times slower. Not profiling doesn't invalidate the
>> performance...
>
> It does, however, invalidate almost any useful conclusion you might
> draw, and in particular the ones you want to draw (`the language itself
> doesn't seem to be able to give good performance on anything
> non-trivial (e.g. nbody)' for instance).
My conclusion was not based upon one program.
> It's probably the case that a
> human being could have a reasonably accurate mental performance model
> of (small) C programs on something like a PDP11, but I'm reasonably
> sure that no one has a model that is even faintly for programs written
> in a language with a huge complex runtime library and a sophisticated
> GCd implementation, on modern hardware: predicting performance of the
> hardware alone is an enormous challenge. (Unfortunately, of course,
> most people's mental model is `a giant PDP11'.)
Agreed.
> You need to profile to
> understand performance, and with a good profiler to boot.
Profiling simply gives you a breakdown of where the time was spent, it
doesn't let you "understand performance".
More importantly, I'm not interested in highly-optimised and tuned Java vs
ordinary C++, OCaml etc.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
On 2006-08-30 20:45:24 +0100, Jon Harrop <···@ffconsultancy.com> said:
> Profiling simply gives you a breakdown of where the time was spent, it
> doesn't let you "understand performance".
Um, if you don't know where the time is going, you definitely do not
understand the performance of your programs. In particular you're
unable to report just what it is about the language which makes it
slow, as you claim it is. Oh well, never mind.
--tim
Tim Bradshaw wrote:
> On 2006-08-30 20:45:24 +0100, Jon Harrop <···@ffconsultancy.com> said:
>> Profiling simply gives you a breakdown of where the time was spent, it
>> doesn't let you "understand performance".
>
> Um, if you don't know where the time is going, you definitely do not
> understand the performance of your programs.
Yes.
> In particular you're
> unable to report just what it is about the language which makes it
> slow, as you claim it is.
Yes. But I can still claim that it is slow.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
On 2006-09-01 20:33:34 +0100, Jon Harrop <···@ffconsultancy.com> said:
> Yes. But I can still claim that it is slow.
I can write slow programs in any language you like, on any machine you
like, however fast and well endowed with memory and I/O it may be.
I've seen back end database systems on machines with tens of processors
and the best part of 100G of memory which sustained 10 disk operations
per http transaction on the front end, when 99% of those transactions
were served directly from cache and never got anywhere near the back
end. That's *easy* to do.
--tim
Tim Bradshaw wrote:
> On 2006-09-01 20:33:34 +0100, Jon Harrop <···@ffconsultancy.com> said:
>> Yes. But I can still claim that it is slow.
>
> I can write slow programs in any language you like, on any machine you
> like, however fast and well endowed with memory and I/O it may be.
Yes. The critical point here is that the programs appear to be equivalently
written in different languages and yet Java is much slower. This is
subjective but still important.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
On Wed, 30 Aug 2006 20:45:24 +0100, Jon Harrop
<···@ffconsultancy.com>:
>Profiling simply gives you a breakdown of where the time was spent, it
>doesn't let you "understand performance".
At least, it tells you what few lines of code you must study.
When one of my programs started to slow down, I ran a profiler, and
was very surprised at the results -- I'd never imagined that that
particular function was the culprit.
Fabien LE LEZ wrote:
> On Wed, 30 Aug 2006 20:45:24 +0100, Jon Harrop
> <···@ffconsultancy.com>:
>>Profiling simply gives you a breakdown of where the time was spent, it
>>doesn't let you "understand performance".
>
> At least, it tells you what few lines of code you must study.
It doesn't even do that in the presence of garbage collection. Several of my
programs spend 30-50% of their time doing GC. When they go wrong, they can
spend 90+% doing GC. Profiling doesn't even give me a clue what is
generating all of that garbage.
> When one of my programs started to slow down, I ran a profiler, and
> was very surprised at the results -- I'd never imagined that that
> particular function was the culprit.
Yes, it can certainly be a big help.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
On 2006-08-31 23:23:57 +0100, Jon Harrop <···@ffconsultancy.com> said:
> It doesn't even do that in the presence of garbage collection. Several of my
> programs spend 30-50% of their time doing GC. When they go wrong, they can
> spend 90+% doing GC. Profiling doesn't even give me a clue what is
> generating all of that garbage.
Then you're not using a very good profiler!
Jon Harrop wrote:
> Yes, I just wrote straightforward code in all of the languages and only Java
> was several times slower.
Then probably Lisp is not your solution. Look here:
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=java&lang2=sbcl
It seems that the JIT on Java is as good if not better than SBCL, even
if you use declarations in Lisp.
And it doesn't appear in that web, but GCJ is even faster than Sun JVM,
so expect that GCJ can beat SBCL very easily.
I don't know how Lisp commercial implementations are going here.
Tim Bradshaw wrote:
> On 2006-08-24 01:43:27 +0100, "Javier" <·······@gmail.com> said:
>
>> But the most interesting thing is that they are implementing these
>> things now, but most of them just ignore that Lisp was able to do so
>> from 30 years ago to now!
>
>
> The people who designed Java were very well aware of Lisp: look at the
> authors of the JLS.
>
> I wasn't there, but I imagine that what they wanted to do was design a
> language which was widely taken up, but achieved several crucial
> benefits over the then state of the art. And to do this before
> Microsoft ate their lunch.
>
> `Widely taken up' is important: if you think you have a way of improving
> the safety (say) of programs, then unless a language which incorporates
> that mechanism is widely used, you have achieved nothing. One way of
> improving a language's chances of being widely taken up is to be
> culturally compatible with an existing, widely used, language. So Java
> is culturally compatible with C (and not with Lisp).
Thought experiment: what if Sun had simply embraced Lisp, with an LVM
instead of a JVM, and then poured the same resources into promoting it
and delivering libraries and doc for it?
ie, Given the above equivalent effort, do you think it really matters
that some surface syntax was preserved from C?
Food for thought: a lot of corporate folks I saw get excited about Java
did not even know C. More food for thought: Dylan. C. Culturally
compatible. If you have not heard of Dylan.... :)
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Thu, 24 Aug 2006 21:27:36 -0400, Ken Tilton <·········@gmail.com>:
> what if Sun had simply embraced Lisp
Could Sun have *controlled* Lisp? If not, why bother?
Sun, like Microsoft, needs its own pet language in order to have as
much control as possible on as many programmers as possible.
You can't do that with a language that already exists.
Fabien LE LEZ wrote:
> On Thu, 24 Aug 2006 21:27:36 -0400, Ken Tilton <·········@gmail.com>:
>
>
>>what if Sun had simply embraced Lisp
>
>
> Could Sun have *controlled* Lisp? If not, why bother?
OK. But the only control was over the spec. I had a Java compiler and
JVM from Metrowerks perty fast after Java came out. Again, if the same
effort goes into an LVM to get binary compatibility, then throw in some
real-world libs (jeez, the best Lisp can do in 2006 is LTk and Cells-Gtk
for a GUI), hey, they /do/ have their own pet platform just as much as
they did with Java. No?
kt
>
> Sun, like Microsoft, needs its own pet language in order to have as
> much control as possible on as many programmers as possible.
> You can't do that with a language that already exists.
>
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Fabien LE LEZ wrote:
> > On Thu, 24 Aug 2006 21:27:36 -0400, Ken Tilton <·········@gmail.com>:
> >
> >
> >>what if Sun had simply embraced Lisp
> >
> >
> > Could Sun have *controlled* Lisp? If not, why bother?
>
> OK. But the only control was over the spec. I had a Java compiler and
> JVM from Metrowerks perty fast after Java came out. Again, if the same
> effort goes into an LVM to get binary compatibility, then throw in some
> real-world libs (jeez, the best Lisp can do in 2006 is LTk and Cells-Gtk
> for a GUI), hey, they /do/ have their own pet platform just as much as
> they did with Java. No?
>
> kt
>
> >
> > Sun, like Microsoft, needs its own pet language in order to have as
> > much control as possible on as many programmers as possible.
> > You can't do that with a language that already exists.
> >
>
> --
> Cells: http://common-lisp.net/project/cells/
>
> "I'll say I'm losing my grip, and it feels terrific."
> -- Smiling husband to scowling wife, New Yorker cartoon
If anything, there will (hopefully) be a nice well-distributed
Free(dom) JVM out there for people to build on. There are already a
lot of Lispy things that run on the Sun Java VM ->
http://www.robert-tolksdorf.de/vmlanguages.html
On Thu, 24 Aug 2006 22:38:29 -0400, Ken Tilton <·········@gmail.com>:
>(jeez, the best Lisp can do in 2006 is LTk and Cells-Gtk for a GUI)
And how good (or bad) are those?
Fabien LE LEZ wrote:
> On Thu, 24 Aug 2006 22:38:29 -0400, Ken Tilton <·········@gmail.com>:
>
>
>>(jeez, the best Lisp can do in 2006 is LTk and Cells-Gtk for a GUI)
>
>
> And how good (or bad) are those?
>
I couldn't be happier with Celtk (my Tk-based option I did not mention
because the Open Source Fairy has left the building). These are
certainly better than java's original GUI, which led others to roll a
new GUI based on native underpinnings.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Thu, 24 Aug 2006 22:38:29 -0400, Ken Tilton <·········@gmail.com>:
>(jeez, the best Lisp can do in 2006 is LTk and Cells-Gtk
>for a GUI)
It seems that it's possible to access Qt in Lisp, which is a Good
Thing, since Qt seems a well-respected, powerful, but unfortunately
non-LGPL, GUI library.
http://sourceforge.net/forum/forum.php?forum_id=516261
And maybe it also works with wxWidgets, which is another good GUI
library, and LGPL.
Fabien LE LEZ <········@gramster.com> writes:
> On Thu, 24 Aug 2006 21:27:36 -0400, Ken Tilton <·········@gmail.com>:
>
>> what if Sun had simply embraced Lisp
>
> Could Sun have *controlled* Lisp? If not, why bother?
>
> Sun, like Microsoft, needs its own pet language in order to have as
> much control as possible on as many programmers as possible.
> You can't do that with a language that already exists.
Well, in the case if Lisp it wouldn't matter, since the number of non
Sun lisp programmers is insignificant.
--
__Pascal Bourguignon__
On 2006-08-25 02:34:51 +0100, Fabien LE LEZ <········@gramster.com> said:
>
> Could Sun have *controlled* Lisp? If not, why bother?
Yes, of course it could. They had a lot of free money then and in
subsequent years: it would have been easy for them to fund the
standardisation process sufficiently heavily that they had effective
control. It still would be easy.
(But, surprisingly enough, they don't want control, because they're not
a monopolist, although I'm sure they would like to be.)
--tim
On 2006-08-25 02:27:36 +0100, Ken Tilton <·········@gmail.com> said:
> Thought experiment: what if Sun had simply embraced Lisp, with an LVM
> instead of a JVM, and then poured the same resources into promoting it
> and delivering libraries and doc for it?
Sun are not and were not a big enough player to push something like
this through. At the time of Java they'd already failed at this
several times: NeWS and OpenLook are two good examples: both expensive
failures.
>
> ie, Given the above equivalent effort, do you think it really matters
> that some surface syntax was preserved from C?
Syntax and semantics. Yes, I do.
>
> Food for thought: a lot of corporate folks I saw get excited about Java
> did not even know C. More food for thought: Dylan. C. Culturally
> compatible. If you have not heard of Dylan.... :)
But they knew what C *was*. And no, Dylan is *not* culturally
compatible with C the way Java is (and Dylan made almost every decision
wrong that Java made right, notably picking a fight with Lisp, not C,
ensuring that even if it drove out Lisp it would get, perhaps, 1%
market share).
--tim
Ken Tilton wrote:
>
> Thought experiment: what if Sun had simply embraced Lisp, with an LVM
> instead of a JVM, and then poured the same resources into promoting it
> and delivering libraries and doc for it?
Wouldn't have worked.
> ie, Given the above equivalent effort, do you think it really matters
> that some surface syntax was preserved from C?
Yes. Richard Gabriel describes a recipe for making a language successful
in http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf - Section "The
End of History and the Last Programming Language". One element is that a
language "must be similar to existing popular languages."
Sun basically followed the recipe described in that book. (I don't know
if they really consciously did so, but it seems obvious when you read
it. And Richard Gabriel works for Sun...)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Hi,
this is my first post to this community so let me briefly introduce
myself. I'm a Computer Science student from Germany and I'm reading
this list since several months. Somehow I got to Paul Graham's homepage
last november and got addicted instantly. Many of you will know what I
mean ;) I'm part-time working in a software company on a project
written in Java. (Perhaps I can give you some information why we choose
Java when we started)
So I used Java quite much when I finally learned LISP. The product is
amphipoLISP, a Lisp interpreter written in Java.
http://virtual-void.net/projects/javalisp/
I'm thinking much about programming language in the last time. I'm
constantly argueing with my fellow programmers why Java is *not* my
language of choice and then I found this topic.
> The people who designed Java were very well aware of Lisp: look at the
> authors of the JLS.
>
> I wasn't there, but I imagine that what they wanted to do was design a
> language which was widely taken up, but achieved several crucial
> benefits over the then state of the art. And to do this before
> Microsoft ate their lunch.
Today I read about the history of Java.
http://today.java.net/jag/old/green/
Astonishing, I think. And did you know: James Gosling who designed
Java, wrote Emacs. Richard Stallman's code was initially based on
Gosling's. So blasphemy is probably not in order. He did know what he
was doing when he designed Java ('Oak', formerly).
Let's talk about Java. It has a plain design. Plain, simple, yes, in
some way beautiful. It's the c++ object orientation but simpler, less
susceptible to faults. (i.e. C++ minus C)
I don't want to talk about the shortcomings you discussed them already
and I'm annoyed every day at work.
When it was released it worked. And you could use it in a browser. And
they promised mobile devices working with Java. And Java became famous.
Do you think that's enough to become famous?
> Richard Gabriel describes a recipe for making a language successful
> in http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf - Section "The
> End of History and the Last Programming Language". One element is that a
> language "must be similar to existing popular languages."
>
> Sun basically followed the recipe described in that book. (I don't know
> if they really consciously did so, but it seems obvious when you read
> it. And Richard Gabriel works for Sun...)
I think you make a strong point here. Why do you think is Ruby such
famous recently?
1. You can write programs, everyone could read and understand
2. It has rails which is Internet programming
3. It has 'modern' object orientation
4. It has first-order functions (and they are looking beautiful ;) )
and other powerful constructs
5. It has a great set of libraries
But: Ruby is older than Java (1993 vs. 1995), why this hype now
(actually two years ago but I missed it a little bit)?
I think it's about culture. Culture? I would like to call culture the
expectation value of a society. So it would be the sum/average of the
traditions, technology, religion, art aso of a society. (You could say
as well:It is the things one could commonly expect from others).
Culture is never stable. It depends on time. But changing an average
needs changing everyone a bit and that takes time.
Back in 1995 the programming community was about the internet and C++
was famous. There was a 'shared notion' what object orientation is
about. But: C++ was not easy to use. The wannebe programmers couldn't
start programming or were distracted because there was no instant
just-pour-water-over-it object-oriented language. (I'm guessing and
probably simplyfying, I didn't have a PC that time (yet).)
Java filled that gap. And they made the right marketing decisions. (And
it was a refuge for all those grateful students and teachers who had to
learn Pascal in school before...)
Lisp is not famous. Lisp is geeky. But everytime some 'new' programming
features are announced a lisper says: 'New? Lisp had that feature in
the sixties more easily to use'. But that doesn't help. There is no
shared notion what a first-class function is. Or 'prototype-based
object orientation' (promoting Slate or Ruby). Or a 'static type
inferring compiler' (promoting ML dialects). If you want to hype a
programming language you need good features, good marketing, good
promoters (you remember the topic about 'the famous promoter'). But: it
has to be the right time. It has to be the time, when the right guys
have a notion of the language features you try to promote. Java did
that, by chance or by purpose.
It can be the other way round: For example: There is a notion about
code writing code (lisp macros): it's called black magic. It reminds
one of a computer virus, there is no association to one of the most
powerful features in computer languages.
So if you want to change the programmer's (the world's) language choice
you have to change their knowledge of language features available. Show
them something, they can do with your language, only with this
language, which is easy to accomplish, looks nice (code + result) and
has to do with the internet ;)
At some point your language will have the critical mass. Then the
recursion will start. Managers perceive a language as mainstream
language. All the competitors will use it, cheap or free libraries will
become available and every programmer(employee) becomes replaceable...
Just this.getCents(2).
Johannes
Johannes Rudolph wrote:
[...]
> Just this.getCents(2).
I completely agree with your opinión.
And just to add something... there is the easy of use. Althought
anybody can understand Lisp syntax and some of them functional
programming, not everybody is able to understand macros.
There are people who still are programming in Basic, and even in Cobol
and deny to write in anythign which is not similar to plain PHP,
because they don't fully understand OOP, or if they do, they have
difficulties to write in that paradigma. This kind of people do only
worry about being able to resolve a problem and no more. Try to explain
to them that macros are better and more elegant... they are simply not
going to learn them unless they are forced to, and even in that case it
will happen the same as with OOP: they will learn that only for being
able to understand other's program, and will have difficulties to apply
them to real life programming for several years. And I believe that the
vast majority of programmers in this world have a similar actitude.
On 26 Aug 2006 07:12:21 -0700, "Javier" <·······@gmail.com>:
>will happen the same as with OOP: they will learn that only for being
>able to understand other's program
Yeah, people tend to have a bad kind of laziness: they don't accept to
learn new techniques, even though those techniques would allow them to
get the same result with less efforts.
And when I say "they", I should actually say "we". I'm in the lot.
I've programmed in PHP for years, believing that OOP wasn't really
useful in PHP, since associative arrays were enough -- even though I
use OOP in C++ everyday.
Then, one day, I decided to learn OOP in PHP. It took me about one
hour -- and now I use it quite extensively.
From: Duane Rettig
Subject: Re: Java is going to have closures.
Date:
Message-ID: <o0mz9rpkko.fsf@franz.com>
"Johannes Rudolph" <················@googlemail.com> writes:
> Lisp is not famous. Lisp is geeky.
Yes. But don't worry, Geeks will have their day. It's already
started, at least 11 years ago:
http://www.digg.com/tech_news/Men_Who_Use_Computers_Are_The_New_Sex_Symbols_of_the_90s
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Sat, 26 Aug 2006 08:45:27 -0700, Duane Rettig <·····@franz.com>:
>http://www.digg.com/tech_news/Men_Who_Use_Computers_Are_The_New_Sex_Symbols_of_the_90s
Too bad the 90s finished 6 years ago...
Johannes Rudolph wrote:
> So I used Java quite much when I finally learned LISP. The product is
> amphipoLISP, a Lisp interpreter written in Java.
> http://virtual-void.net/projects/javalisp/
Johannes, amphipoLisp looks like an interesting project.
Congratulations for making it this far.
I would like to suggest that you make CL conformance your highest
priority.
The problem is that people with CL programs (e.g. me) would be
happy to recompile with amphipoLisp, but it is much less likely
that they will invest the time needed to port to a different Lisp
dialect.
(The program of interest to me is Maxima, a computer algebra system.
See http://maxima.sourceforge.net .)
Armed Bear CL is another Lisp implemented in Java. ABCL is too
far from CL to run Maxima successfully (it compiles but there are
run time bugs). Maybe you would consider joining forces with ABCL.
It's just a thought.
All the best,
Robert Dodier
On 26 Aug 2006 06:17:21 -0700, "Johannes Rudolph"
<················@googlemail.com>:
>Somehow I got to Paul Graham's homepage
>last november and got addicted instantly.
That was the start for me too (except that happened last Sunday).
But <http://www.paulgraham.com/avg.html> is really interesting in this
discussion. Viaweb was successful because:
- it was programmed in Lisp;
- other companies didn't use Lisp.
All the present discussion is about why Lisp is so unpopular.
Another interesting question is: is that a Good Thing or a Bad Thing?
I'd say it's a Bad Thing from the open-source point of vue: less
programmers means less resources, difficulties of deployment[*], etc.
But it may be a Good Thing from a "competitive business"[**] point of
vue: if you program in Lisp and your competitor program in another
language, you may have an advantage.
What do you think?
[*] Just compare PHP and Lisp on a shared web server...
[**] Count the number of times Paul Graham says "competitors" or
"competitive" in <http://www.paulgraham.com/avg.html>...
In article <················@newsfe08.lga>,
Ken Tilton <·········@gmail.com> wrote:
> Thought experiment: what if Sun had simply embraced Lisp, with an LVM
> instead of a JVM, and then poured the same resources into promoting it
> and delivering libraries and doc for it?
Thought experiment: what if someone produced a LispScript (like
Javascript except using S-expressions) plugin that worked in every major
web browser? Or embedded a LispScript interpreter in Firefox? Or wrote
a new web browser entirely in Lisp?
> ie, Given the above equivalent effort, do you think it really matters
> that some surface syntax was preserved from C?
There is no question about it. All else being equal, professionals
generally do not want their work made simpler. They have invested a lot
of time learning the arcana of their craft and the more complicated it
is the higher the barrier to entry, the more secure their jobs, and the
more they get paid. Java succeeded not because it was simple but
despite the fact it was simple. It succeeded because the productivity
gains were so overwhelming (relative to C) that they dominated the
resistance it received because of its "missing" features (which have
been creeping back in ever since).
This is true for all professions (medicine, law), not just programming.
This is the reason that Java's feature creep has met with so little
resistance over the years. This is the reason that C++ thrives despite
the fact that it is the most godawful mess ever produced by man. You
can even see the same dynamic at work in the CL community, where
attempts to simplify (indeed to make any changes to) the language are
met with extreme resistance.
> Food for thought: a lot of corporate folks I saw get excited about Java
> did not even know C.
But they "knew" that Java was "like" C, only better.
> More food for thought: Dylan. C. Culturally
> compatible. If you have not heard of Dylan.... :)
Apple abandoned Dylan long before it reached the level of maturity that
Java had when it was launched.
rg
Ron Garret wrote:
> Thought experiment: what if someone produced a LispScript (like
> Javascript except using S-expressions) plugin that worked in every major
> web browser? Or embedded a LispScript interpreter in Firefox? Or wrote
> a new web browser entirely in Lisp?
Well, I haven't used it, but Curl ( http://www.curl.com ) is supposedly
Lispish (though they replaced the parens with curly braces, which
strikes me as being about the worst idea in the history of ... um ...
ideas).
Le Fri, 25 Aug 2006 09:33:45 -0700, Ron Garret a écrit :
> Thought experiment: what if someone produced a LispScript (like
> Javascript except using S-expressions) plugin that worked in every
> major web browser? Or embedded a LispScript interpreter in Firefox?
Funny, that idea also occurred to me very recently... I was told on the
ECL mailing-list that it had been suggested for Google Summer of Code.
In the KDE world, Kross could be a easy entry point for Lisp:
http://kross.dipe.org/readme.html
> Or wrote a new web browser entirely in Lisp?
It would at least not have to infamous memory leaks of Firefox...
Quickly,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
> Thought experiment: what if someone produced a LispScript (like
> Javascript except using S-expressions) plugin that worked in every major
> web browser? Or embedded a LispScript interpreter in Firefox? Or wrote
> a new web browser entirely in Lisp?
An annotation to that one. (I know that wasn't the question) Why would
one try to replace JavaScript? Did one of you examine what JavaScript
is able to do? I wrote a JavaScript compiler two years ago and
it(Javascript, the compiler was not finished) is much more dynamic than
Java ever was. It has first-order functions and it has a
prototype-object system which is working quite well.
Now think about what I said before: The hypes... we have a recent Ajax,
Web 2.0 bla hype. And what is it based on (at least the technical
part)? Some programmers became aware of the strength JavaScript has and
they used it. The EcmaScript spec is written in 1999. Seven years ago
and noone noticed. (one should probably consider the dependency on
processor speed as well)
On 26 Aug 2006 07:44:48 -0700, "Johannes Rudolph"
<················@googlemail.com>:
>Did one of you examine what JavaScript
>is able to do?
I did. And I think that Javascript suffers from a reputation gained a
long time ago, when there were two independant Javascripts (Netscape's
and IE's).
Now Javascript is normalized by the W3C, has gained both power and
usability (like you said, processors are far more powerful than they
used to be, so you can run complicated algorithms in an interpreted
language), but the reputation stays.
Also, Javascript has been misused a lot, to show advertisements, or
with features that seemed a good idea to programmers, but are really
annoying for users. That added a lot to its bad reputation.
When I think about it, the strength of Lisp might be that people
usually aren't forced to use it (like what happens with Java, C++ or
even Javascript). Either you like it, and learn to use it properly, or
dislike it, and use another language instead.
Lots of languages are used improperly, because programmers are forced
to use them, and don't bother spending time learning it.
Johannes Rudolph wrote:
> Why would one try to replace JavaScript?
I actually have a twisted fondness for JavaScript, but it's just not a
polished language. Yes, you can accomplish a lot with it, but it takes
a ton of effort, and I always end up with a real messy and hard to
maintain code base, and the same is true of all other people's
JavaScript I've read.
> Now think about what I said before: The hypes... we have a recent Ajax,
> Web 2.0 bla hype. And what is it based on (at least the technical
> part)? Some programmers became aware of the strength JavaScript has and
> they used it. The EcmaScript spec is written in 1999. Seven years ago
> and noone noticed. (one should probably consider the dependency on
> processor speed as well)
It's true that a lot of people are suddenly overcoming a longstanding
aversion to JavaScript, but I really think that has mostly to do with
companies like Yahoo and Google pouring tons of money into developing
good JavaScript strategies, and then sharing them (and a lot of code)
with the community. Most web developers are never going to hand-develop
dynamic Ajax components, any more than they write their own GUI
toolkits.
Hell, with Google's GWT, you don't even write in JavaScript -- you
write in Java and they translate it to JavaScript.
On Fri, 25 Aug 2006 09:33:45 -0700, Ron Garret wrote:
>Thought experiment: what if someone produced a LispScript (like
>Javascript except using S-expressions) plugin that worked in every major
>web browser?
As a web user, if a new plugin was needed to access a website,
I'd usually try another website. If I really needed to access that
"Lisp-website", only then I'd attempt to install the plugin.
As a webmaster, I'd know that fact, so I'd really hesitate to
use such an unknown plugin.
That's the good old hen-egg problem: users will install the
plugin if lots of websites need it; but lots of websites will use the
plugin only if lots of users already have the plugin installed.
It worked for one plugin: Flash. And that's probably because you
don't even have to be a programmer to make a Flash applet; only the
worst computer-illiterate are unable to use Flash. That means there
are an awful lot more potential users that Java, C++, C, PHP and Lisp
could ever imagine.
Some older websites use something complicated and limited for
the video (Quicktime, Real, WMV), but newer websites tend to use
Flash, because it's simpler, and the plugin is virtually installed on
every single machine.
It didn't work for Java. Except in very small areas (e.g. some
websites made by and for physics teachers), you don't see many Java
applets on the web.
[Actually, I'm really wondering what all those Java programmers
are doing exactly. I know exactly one Java application -- Azureus, one
application that seems to optionally use Java for something --
OpenOffice (but that's just because Sun is implied on the funding of
that software), and I see nearly no Java applets on the web.]
Fabien LE LEZ wrote:
> It worked for one plugin: Flash. And that's probably because you
> don't even have to be a programmer to make a Flash applet; only the
> worst computer-illiterate are unable to use Flash.
That depends on what you're doing with it. A good artist with a few
computer skills can make something look nice in Flash, but it won't do
much. To do a web application in Flash is as hard or harder than doing
it in other languages. You have to build a lot of your own widgets, and
do a lot of wiring. Flash didn't win because it's easy; it won because
Flash files download fast and look awesome -- at least, if you have a
corporate budget for graphic artists.
I've always avoided Flash because I would never pay for the development
environment, but free ActionScript compilers are becoming available.
Someday I'll sit down with one and see what I can crank out.
> [Actually, I'm really wondering what all those Java programmers
> are doing exactly. I know exactly one Java application -- Azureus, one
> application that seems to optionally use Java for something --
> OpenOffice (but that's just because Sun is implied on the funding of
> that software), and I see nearly no Java applets on the web.]
That's because they're not writing Applets. Nobody's paid any attention
to applets in this century. But Java is immensely popular for building
back-end systems and corporate web sties (oops -typo, but let it
stand). Many of the major online stores are written in JSP, backed by
Java application servers. That's largely because Java Enterprise
Edition caught on as a concrete model for multitier business
applications. It's hard to get a bunch of college grads and 2-3 year
programmers to really understand why they should be writing layered
software, but it's pretty easy to get them to figure out which of Java
EE's "roles" they fit into and then follow the steps in the tutorial
for building the type of object they're responsible for. And that's
probably a good thing -- it's a hell of a lot easier to jump in and
work on someone's JSP/Servlet/EJB code than it is to try and
disentangle someone else's Perl.
On 27 Aug 2006 18:57:11 -0700, "joh" <·····@wenet.net>:
>> only the
>> worst computer-illiterate are unable to use Flash.
>
>That depends on what you're doing with it. A good artist with a few
>computer skills can make something look nice in Flash, but it won't do
>much.
It's not about doing it well, it's about doing it.
Flash is mostly mis-used (like Javascript, actually), to do things
that would work better with plain HTML, or show ugly animations, or
show ads.
In fact, I've installed Flashblock on Firefox, to activate only Flash
applets I need.
But my point is that anyone can do something in Flash -- regardless of
quality.
>To do a web application in Flash is as hard or harder than doing
>it in other languages.
Yep. Flash definitely isn't meant for programmers. I tried to do a
rather simple thing (just an edit box where words are colored
on-the-fly, the color depending of the number of letters of the word),
and it was rather hellish.
>but free ActionScript compilers are becoming available.
Interesting... Would you happen to have a name or a URL?
> it's a hell of a lot easier to jump in and
>work on someone's JSP/Servlet/EJB code than it is to try and
>disentangle someone else's Perl.
How about someone else's Lisp?
(Let's try to be on-topic from time to time ;-p )
Pascal Bourguignon wrote:
> Real functions are not named foo an do-something.
>
> Real functions take their name from the functional abstractions they
> embody. You don't need a specific type for the arguments or variable,
> because it's an abstract type anyway, and an implementation detail of
> the function abstraction. Not mentionning that most algorithms work
> mostly on whatever type of data.
What you are describing are ideal functions, not real ones. I have
spent the last couple of weeks reading a lot of Lisp code in a lot of
libraries that seem to get real use, and I can tell you that I have
often had trouble figuring out exactly what type of structure these
functions expect to have passed to them. It seems quite common for
people to write functions that will only work if they are passed an
alist or some ad-hoc cons-based tree structure. I'm sure some of the
programmers whose work I'm reading had some vague intention of going
back and cleaning up, but that doesn't happen much in the real world.
Sorry to reply to my own post, but I thought I should give some real-
world examples.
This method is from a very popular piece of Lisp software. I've
changed the identifiers slightly, but this is very true to the
original. In the context, you would have a pretty good idea of what an
action is and what a processor is supposed to do, but that's not quite
enough.
(defmethod process-action ((processor t) action)
(etypecase processor
(cons (apply (car processor) action (cdr processor)))
(function (funcall processor action))
(symbol (funcall processor action))))
You can see that this method can take a cons as the first argument.
But not just any cons. You have to work out that the car of the cons
must be a function, and the cdr must be a list of arguments
for that function.
Another example from the same code base:
(loop for (name val . rest) on value-defs by #'cddr do ...
Nothing in the surrounding definition tells me what value-defs is.
Maybe for an experienced Lisper this is idiomatic, but I have to take
a moment to parse this and figure out that value-defs must be a list
of the form (name1 value1 name2 value2 ...). The functions that use
this code will do wrong if handed anything else.
I'm not saying that this is bad code, my original point was just that
this step of "figure out what the expected argument values look like"
is for me the hardest part of reading someone else's Lisp, and it's a
step you usually don't need to perform in a statically typed language.
Again, I am NOT arguing for static typing, just observing one
difference.
Fabien LE LEZ wrote:
> On 28 Aug 2006 10:07:44 -0700, "joh" <·····@wenet.net>:
>
> >Take two well-designed, attractive interfaces for the same application,
> >one written in Flash,
>
> We're still talking about websites, right?
> Could you give me an example of a usable website written in Flash?
http://www.nike.com
On Mon, 28 Aug 2006 22:54:52 +0200, Pascal Bourguignon
<···@informatimago.com>:
>Real functions are not named foo an do-something.
And real functions' arguments are not named x or l.
Or, if an argument is named x, it's usually the abscissa of a point,
and there's a y not far away.
I wrote:
>> In fact, I've installed Flashblock on Firefox, to activate only Flash
>> applets I need.
Just go to <http://www.clubic.com/comparateur-de-prix.html>, with a
"standard" browser (i.e. Flash installed, and no ad-removers), and I
think you'll understand why I filter Flash animations.
I wrote:
>> Flash is mostly mis-used (like Javascript, actually), to do things
>> that would work better with plain HTML, or show ugly animations, or
>> show ads.
"joh" <·····@wenet.net> answered:
>Take two well-designed, attractive interfaces for the same application,
>one written in Flash, one in HTML (let's be generous and say DHTML with
>AJAX).
>[...]
>http://www.nike.com
OK, I went to that site, and didn't find many bugs.
As a matter of fact, they certainly spent a lot of money to make that
website.
And that's my point: with so much money, Nike could have done the same
with other technologies (e.g. Java).
But even the guy who isn't a programmer (or the company that doesn't
want to pay a programmer), can do something with Flash. It will not be
well-designed, but at least there will be Flash's bells and whistles
on his website. That's where Flash is better than Java.
>Some people, mostly programmers or people with old machines,
>will say the Flash one is bloated with unnecessary bells and whistles.
I'd say the contrary: the problem with Flash-driven websites is that
they lack features, like tabbed browsing and, in general, normal HTML
navigation.
But then again, for an advertisement website (like nike.com), you
don't really need "normal" web features.
OTOH, for an informational website (like CLHS, or even Google), you
couldn't do much without the ability to go back and forth, and the
ability to say "Hey, this link could be interesting, I'll load it in a
new tab while I finish reading this page."
On 2006-08-26 15:19:20 +0100, Fabien LE LEZ <········@gramster.com> said:
> It didn't work for Java. Except in very small areas (e.g. some
> websites made by and for physics teachers), you don't see many Java
> applets on the web. [Actually, I'm really wondering what all those
> Java programmers
> are doing exactly. I know exactly one Java application -- Azureus, one
> application that seems to optionally use Java for something --
> OpenOffice (but that's just because Sun is implied on the funding of
> that software), and I see nearly no Java applets on the web.]
There's an enormous amount of server-side Java running web sites etc.
Most of it using J2EE (which is a horror).
--tim
Ken Tilton <·········@gmail.com> writes:
> Thought experiment: what if Sun had simply embraced Lisp, with an LVM
> instead of a JVM, and then poured the same resources into promoting it
> and delivering libraries and doc for it?
It would have been a monumental flop. Lisp just doesn't grab the
average programmer and probably never will.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
Le Thu, 24 Aug 2006 07:54:21 +0100, Tim Bradshaw a écrit :
> (It's significant that Java does this whole memory-safety thing better
> than CL: it mandates things that CL makes only optional at high
> optimization settings.)
Coul you elaborate this point?
Curiously,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On 2006-08-24 20:36:51 +0100, Pierre THIERRY
<···········@levallois.eu.org> said:
> Le Thu, 24 Aug 2006 07:54:21 +0100, Tim Bradshaw a �crit�:
>> (It's significant that Java does this whole memory-safety thing better
>> than CL: it mandates things that CL makes only optional at high
>> optimization settings.)
>
> Coul you elaborate this point?
Well, no, not really: what more is there to say. Java says `must'
where CL says `may' basically.
--tim
Tim Bradshaw wrote:
> (It's significant that Java does this whole memory-safety thing better
> than CL: it mandates things that CL makes only optional at high
> optimization settings.)
...but this also means that you cannot program close to the hardware in
Java.
> Java missed out on at least two things.
>
> An extensible syntax (some kind of prefix syntax) with macros etc.
> Could it have done this while being culturally compatible with C? I
> suspect it couldn't, but it's still a shame.
Annotations are apparently supposed to fill this gap.
> A coherent object-based semantics, with everything being an object,
> closures, and preferably multiple inheritance. I hate that they didn't
> do this but instead botched things with non-object types like int, and a
> rudimentary object system. Whether they could have done this while
> maintaining cultural compatibility with C I'm not sure.
I think the simplicity of Java's (original) object system attracted lots
of people who tend to fall into the trap to think that a simple language
correlates with simpler programs. This was, I think, one factor that
made Java popular. You can see the same pattern over and over again, for
example with so-called scripting languages like Python and Ruby.
> More to the
> point could they have implemented a compiler & runtime that worked
> reasonably well in the time available (before MS ate them in other words)?
They were already not able to do this with Java's rudimentary objects.
The first just-in-time compiler was not implemented by Sun, and the
HotSpot VM was derived from products of two different companies that
they bought. (Ironically based on research done at their research labs
which was canceled beforehand.)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Javier wrote:
> As you probably know, recently Java has incorpored annotations and
> templates into its syntax, and the combinations of both make Java more
> dinamic and in some way closer to the compiler behavor as Lisp macros
> do.
> Now, they are pretending to add closures. You can find the paper
> explaining their intentions here:
>
> http://blogs.sun.com/roller/resources/ahe/closures.pdf
>
> Now I'm thinking: it is really true that the programming world is
> tending towards Lisp. If we continue in this line, we're going to have
> Java and other languages evolutionating until they are very close to
> Lisp.
> But the most interesting thing is that they are implementing these
> things now, but most of them just ignore that Lisp was able to do so
> from 30 years ago to now!
>
> I'd like to read some comments from all you experts.
It's not a given that this will be added to Java in the end, although it
has become more likely due to the competition with C#. Note that Java
already had full closures in an internal prototype implementation, but
this was dropped due to user feedback. See
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04030.html
- so whether closures will be added or not depends on what users are
going to say.
It's hard to predict what effect this will have. On the upside, Java may
be slightly easier to use, so if you have to use it in your day jobs,
your life will become somewhat easier. If they have to tweak the JVM to
make closures perform well, this will also benefit other languages
implemented for the JVM, like for example Armed Bear Common Lisp or the
various Scheme implementations for the JVM.
On the downside, for those who choose languages based on checklists of
supported features, there is one excuse less to drop Java, which may
slow down its death. [1]
Pascal
[1] It's not only important what features a language supports, but also
how well they are integrated. The proposals to add closures to Java is
an interesting case in this regard: why don't they just "complete"
anonymous inner classes and let them close over non-final variables?
That would fit the existing design of Java much better. With the
addition of closures, they just add another inconsistency.
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> On the downside, for those who choose languages based on checklists of
> supported features, there is one excuse less to drop Java, which may
> slow down its death. [1]
I must agree with all your comments, except that I don't believe that
Java is going to death in the next years. It is going very strong in
the market right now, and any important Open Source project made in
Java is growing more and more. Take for example Netbeans: there are
more than 300.000 people recieving its mailing list, and more than
100.000 new downloads each month
(http://www.netbeans.org/about/stats/). This program by itself has
probably more popularity and acceptance than the entire Lisp comunity
with all their libraries, programs and IDEs all together. Just sum the
entire Java community and compare it with the Lisp one: it will be like
comparing a castell with the dog house.
Sun is also to make the JDK open source. This means that in some months
Linux distributions are going to become the 'defacto' system for
developing Java applications, and more hackers and middle to small
companies are going to switch to it.
Just think about C. It is in the market for 30 years and much of the
software produced today still are written in that language. Java was
born 10 years ago and has totally success, even at the point that today
anybody who don't know how to program in Java, will have dificulties to
find a job as a programmer.
Elsewhere, I like Lisp very much, much more than Java. And I think it
is the same case as everyone here. But we must admit the facts.
Javier wrote:
> Pascal Costanza wrote:
>> On the downside, for those who choose languages based on checklists of
>> supported features, there is one excuse less to drop Java, which may
>> slow down its death. [1]
>
> I must agree with all your comments, except that I don't believe that
> Java is going to death in the next years. It is going very strong in
> the market right now, and any important Open Source project made in
> Java is growing more and more. Take for example Netbeans: there are
> more than 300.000 people recieving its mailing list, and more than
> 100.000 new downloads each month
> (http://www.netbeans.org/about/stats/). This program by itself has
> probably more popularity and acceptance than the entire Lisp comunity
> with all their libraries, programs and IDEs all together. Just sum the
> entire Java community and compare it with the Lisp one: it will be like
> comparing a castell with the dog house.
>
> Sun is also to make the JDK open source. This means that in some months
> Linux distributions are going to become the 'defacto' system for
> developing Java applications, and more hackers and middle to small
> companies are going to switch to it.
>
> Just think about C. It is in the market for 30 years and much of the
> software produced today still are written in that language. Java was
> born 10 years ago and has totally success, even at the point that today
> anybody who don't know how to program in Java, will have dificulties to
> find a job as a programmer.
>
> Elsewhere, I like Lisp very much, much more than Java. And I think it
> is the same case as everyone here. But we must admit the facts.
Java is currently in the same stage that C++ about somewhat more than 10
years ago: a once simple (simplistic) straightforward design has grown
far too complicated for average users. In the case of Java it's even
worse, because "above-average" programmers don't get a lot of bang from
Java.
You can sense at conferences that people are waiting for something new.
I am talking about academic conferences here, and Java had a very strong
backing from academia. If someone plays his/her cards right, a new
language could now "take over", at least in those circles.
Notice how Python and Ruby have created some considerable buzz already.
If one of those languages would be backed by a major player, things
could quickly change. I am not very optimistic about the possible
quality of such a language, though. A new language would still have to
be culturally compatible with the mainstream to a certain degree.
Java will, of course, remain a pretty important legacy language for some
time to come.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2006-08-25 08:17:30 +0100, Pascal Costanza <··@p-cos.net> said:
> Java is currently in the same stage that C++ about somewhat more than
> 10 years ago: a once simple (simplistic) straightforward design has
> grown far too complicated for average users. In the case of Java it's
> even worse, because "above-average" programmers don't get a lot of bang
> from Java.
I disagree. C++ was always a horrible misdesigned botch, and it got
rapidly worse, while failing to actually be standard for a very long
time. Java is nowhere near that bad.
--tim
"Javier" <·······@gmail.com> writes:
> As you probably know, recently Java has incorpored annotations and
> templates into its syntax
Unfortunately, Java's generics don't provide anything close to
the power of C++ templates. They're little more than a very complex
means to avoid a few casts.
No doubt any closure implementation will be similarly
emasculated.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
Patrick May wrote:
> "Javier" <·······@gmail.com> writes:
> > As you probably know, recently Java has incorpored annotations and
> > templates into its syntax
>
> Unfortunately, Java's generics don't provide anything close to
> the power of C++ templates. They're little more than a very complex
> means to avoid a few casts.
>
> No doubt any closure implementation will be similarly
> emasculated.
It seems to be logical. They are pretending to have a lot of features
but mantaining the goal of being "simple". Of course, the language has
grown at the point that it is not simple anymore, but because the
"evolution" has been made smoothly in all these years, not eveybody has
realised this fact.
"Javier" <·······@gmail.com> writes:
> I'd like to read some comments from all you experts.
I don't think it matters what language features are adopted. One of
the things that makes Lisp special is the development environment.
You're in a running Lisp session and dynamically adding and changing
definitions. You can even break the execution of a Lisp session and
make changes from in the debugger.
Until you can do that with Java, it won't be the same.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> I don't think it matters what language features are adopted. One of
> the things that makes Lisp special is the development environment.
> You're in a running Lisp session and dynamically adding and changing
> definitions. You can even break the execution of a Lisp session and
> make changes from in the debugger.
>
> Until you can do that with Java, it won't be the same.
You can, if you use Eclipse.
"joh" <·····@wenet.net> writes:
> David Steuber wrote:
> > I don't think it matters what language features are adopted. One of
> > the things that makes Lisp special is the development environment.
> > You're in a running Lisp session and dynamically adding and changing
> > definitions. You can even break the execution of a Lisp session and
> > make changes from in the debugger.
> >
> > Until you can do that with Java, it won't be the same.
>
> You can, if you use Eclipse.
How is the unwinding of the stack during the execution of an exception
handler dealt with in Java/Eclispe? You've lost information in the
unwind. Or does Java now have CL's condition system?
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
On 2006-08-28 06:25:59 +0100, David Steuber <·····@david-steuber.com> said:
> How is the unwinding of the stack during the execution of an exception
> handler dealt with in Java/Eclispe? You've lost information in the
> unwind. Or does Java now have CL's condition system?
I don't think it does. But I used to think that I personally knew all
the people who understood HANDLER-BIND.
--tim
"joh" <·····@wenet.net> writes:
> David Steuber wrote:
> > "joh" <·····@wenet.net> writes:
> >
> > > David Steuber wrote:
> > > > I don't think it matters what language features are adopted. One of
> > > > the things that makes Lisp special is the development environment.
> > > > You're in a running Lisp session and dynamically adding and changing
> > > > definitions. You can even break the execution of a Lisp session and
> > > > make changes from in the debugger.
> > > >
> > > > Until you can do that with Java, it won't be the same.
> > >
> > > You can, if you use Eclipse.
> >
> > How is the unwinding of the stack during the execution of an exception
> > handler dealt with in Java/Eclispe? You've lost information in the
> > unwind. Or does Java now have CL's condition system?
>
> Hey, I never said you can do everything in Java you can do in Lisp. But
> even in Lisp, exactly what changes you can safely make to a running
> system are limited and both application- and implementation-dependent.
> I'm just saying that with Eclipse, you can break on an error, edit the
> code, and let Eclipse cause the running system to reload the class. Or
> change variables and restart. And the debugger's a hell of a lot nicer
> to use than Slime.
>
> To step back a bit, when you argue that Lisp is better because it has a
> better development environment, Java coders say "OK, let's see if I can
> make a development environment that does that." And they often get
> surprisingly far with it.
Fair enough.
Someone might mention ACL's IDE for Windows and what it can do, but I
have no personal experience with that so it won't be me.
I should also give some mention to bean shell since it gives some
dynamic behavior to Java. I haven't really played with that either.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
On 2006-08-27 21:38:27 -0400, "joh" <·····@wenet.net> said:
> David Steuber wrote:
>> I don't think it matters what language features are adopted. One of
>> the things that makes Lisp special is the development environment.
>> You're in a running Lisp session and dynamically adding and changing
>> definitions. You can even break the execution of a Lisp session and
>> make changes from in the debugger.
>>
>> Until you can do that with Java, it won't be the same.
>
> You can, if you use Eclipse.
I hope you weren't trying to imply Eclipse is a nice development environment.
And even if you were you still have to agree that it is a slow, bloated beast.
Novus
Novus wrote:
> I hope you weren't trying to imply Eclipse is a nice development environment.
> And even if you were you still have to agree that it is a slow, bloated beast.
I find it OK, although it's a bit overwhelming if you know what you're
trying to do. If you *don't* know what you're trying to do, the
aggressive help/completion is actually quite useful. I presume it can
be turned off (in fact I'm sure it can). My major gripe is that the
emacs emulation is not nearly complete enough.
Slow and bloated, well, yes. But that's software for you.
--tim
As an Emacs user, I wouldn't be comfortable calling much software a
"slow, bloated beast".
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> As an Emacs user, I wouldn't be comfortable calling much software a
> "slow, bloated beast".
Eclipse is to emacs as emacs is to vi.
--tim (vi? use ed like real men)
"Tim Bradshaw" <··········@tfeb.org> writes:
> David Steuber wrote:
> > As an Emacs user, I wouldn't be comfortable calling much software a
> > "slow, bloated beast".
>
> Eclipse is to emacs as emacs is to vi.
So why aren't you using Eclipse to read USENET?
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
On 2006-08-30 03:43:15 +0100, David Steuber <·····@david-steuber.com> said:
> So why aren't you using Eclipse to read USENET?
I read usenet with telnet.
David Steuber wrote:
> As an Emacs user, I wouldn't be comfortable calling much software a
> "slow, bloated beast".
Compared to modern software Emacs isn't bloated. It starts in
~4seconds on my ancient computers and uses very little memory. The
only real bloat is the disk space it consumes and the size of the
manual.
"Rob Thorpe" <·············@antenova.com> writes:
> David Steuber wrote:
> > As an Emacs user, I wouldn't be comfortable calling much software a
> > "slow, bloated beast".
>
> Compared to modern software Emacs isn't bloated. It starts in
> ~4seconds on my ancient computers and uses very little memory. The
> only real bloat is the disk space it consumes and the size of the
> manual.
But Emacs is a complete hosted OS and development environment. It
takes over an hour to compile Emacs on my 867Mhz G4 PowerBook. Most
of all, Hanoi runs so slowly.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> "Rob Thorpe" <·············@antenova.com> writes:
>
> > David Steuber wrote:
> > > As an Emacs user, I wouldn't be comfortable calling much software a
> > > "slow, bloated beast".
> >
> > Compared to modern software Emacs isn't bloated. It starts in
> > ~4seconds on my ancient computers and uses very little memory. The
> > only real bloat is the disk space it consumes and the size of the
> > manual.
>
> But Emacs is a complete hosted OS and development environment. It
> takes over an hour to compile Emacs on my 867Mhz G4 PowerBook.
I don't really consider how long it takes to compile something as
representative of how bloated it is. It's not really very relevant to
normal use either. (It often isnt's relevant to how long the program
is either, ECL for example takes an age to compile).
Or do you compile it every time you use it? Choosing the compiler
flags for optimum speed for your task :)
> Most
> of all, Hanoi runs so slowly.
It's supposed to, to make you do some work, layabout. Doctor mode is
rude to me - I think it's for the same reason.
Novus wrote:
> On 2006-08-27 21:38:27 -0400, "joh" <·····@wenet.net> said:
>
> > David Steuber wrote:
> >> I don't think it matters what language features are adopted. One of
> >> the things that makes Lisp special is the development environment.
> >> You're in a running Lisp session and dynamically adding and changing
> >> definitions. You can even break the execution of a Lisp session and
> >> make changes from in the debugger.
> >>
> >> Until you can do that with Java, it won't be the same.
> >
> > You can, if you use Eclipse.
>
> I hope you weren't trying to imply Eclipse is a nice development environment.
> And even if you were you still have to agree that it is a slow, bloated beast.
>
> Novus
Eclipse is better than any crap that Lisp has, and is only slow and
bloated if you get your systems out of the dumpster.
On 30 Aug 2006 02:50:14 -0700, ·············@gmail.com"
<············@gmail.com>:
>Eclipse is better than any crap that Lisp has, and is only slow and
>bloated if you get your systems out of the dumpster.
So, what's the minimum configuration to make it work smoothly?
[I mean, any action, including starting the program, is too fast for
the user to notice he's waiting.]
On Wed, 30 Aug 2006 13:50:36 +0200, Fabien LE LEZ <········@gramster.com>
wrote:
> On 30 Aug 2006 02:50:14 -0700, ·············@gmail.com"
> <············@gmail.com>:
>
>> Eclipse is better than any crap that Lisp has, and is only slow and
>> bloated if you get your systems out of the dumpster.
>
> So, what's the minimum configuration to make it work smoothly?
> [I mean, any action, including starting the program, is too fast for
> the user to notice he's waiting.]
>
About 500mb.
But if you are building anything substantial that too will require
a lot of memory so 1 Gb is better.
Java programs using Swing tend to grow enormously when used
for a while. I believe one of the reasons for this is that
memory is allocated in procedures then a subproc is called and the original
memory is never freed. This leads to a memory leak because java
retains memory not really in use. It is less of a problem in
Lisp since the coding style is more functional.
When Swing was created I think it was generally believed that
garbage Collection solved all problems. One the code was written the
problem was realized, but it was too late.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Wed, 30 Aug 2006 14:35:13 +0200, John Thingstad
<··············@chello.no> wrote:
> On Wed, 30 Aug 2006 13:50:36 +0200, Fabien LE LEZ
> <········@gramster.com> wrote:
>
>> On 30 Aug 2006 02:50:14 -0700, ·············@gmail.com"
>> <············@gmail.com>:
>>
>>> Eclipse is better than any crap that Lisp has, and is only slow and
>>> bloated if you get your systems out of the dumpster.
>>
>> So, what's the minimum configuration to make it work smoothly?
>> [I mean, any action, including starting the program, is too fast for
>> the user to notice he's waiting.]
>>
>
> About 500mb.
> But if you are building anything substantial that too will require
> a lot of memory so 1 Gb is better.
> Java programs using Swing tend to grow enormously when used
> for a while. I believe one of the reasons for this is that
> memory is allocated in procedures then a subproc is called and the
> original
> memory is never freed. This leads to a memory leak because java
> retains memory not really in use. It is less of a problem in
> Lisp since the coding style is more functional.
> When Swing was created I think it was generally believed that
> garbage Collection solved all problems. One the code was written the
> problem was realized, but it was too late.
>
I could add that for faster loading SATA drives help a lot.
The can load at 3 Gb/s as opposed to 600 Mb/s for ATA.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On 2006-08-30 13:39:01 +0100, "John Thingstad" <··············@chello.no> said:
> I could add that for faster loading SATA drives help a lot.
> The can load at 3 Gb/s as opposed to 600 Mb/s for ATA.
I seriously doubt any current disk drive can transfer data at 3Gb (or
is that 3GB?) per second sustained. A suitable array can, but that's
probably not what you mean.
--tim
On Wed, 30 Aug 2006 23:38:31 +0200, Tim Bradshaw <···@tfeb.org> wrote:
> On 2006-08-30 13:39:01 +0100, "John Thingstad"
> <··············@chello.no> said:
>
>> I could add that for faster loading SATA drives help a lot.
>> The can load at 3 Gb/s as opposed to 600 Mb/s for ATA.
>
> I seriously doubt any current disk drive can transfer data at 3Gb (or is
> that 3GB?) per second sustained. A suitable array can, but that's
> probably not what you mean.
>
> --tim
>
Nop. That is the SATA driver.
The disc's do however have buffers. Then it depends if you seek time
and whether the data is sequential etc. This varies from manufacturer
to manufacturer. Never the less, SATA drives are significantly faster.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Thu, 31 Aug 2006 00:39:05 +0200, "John Thingstad"
<··············@chello.no>:
>> I seriously doubt any current disk drive can transfer data at 3Gb (or is
>> that 3GB?) per second sustained. A suitable array can, but that's
>> probably not what you mean.
>Nop. That is the SATA driver.
>The disc's do however have buffers.
The OS too. If you want fast access to files, you want them to stay in
RAM (in the cache managed by the OS).
That's why you want lots of RAM.
>Never the less, SATA drives are significantly faster.
I doubt it's due to the sheer speed of the bus. It might come from
NCQ, or from the fact that you don't have two drives on the same cable
like with PATA.
On 2006-08-31 15:20:09 +0100, Fabien LE LEZ <········@gramster.com> said:
> I doubt it's due to the sheer speed of the bus. It might come from
> NCQ, or from the fact that you don't have two drives on the same cable
> like with PATA.
I think (but am not sure) that SATA has been specified slightly better
than PATA was, & in particular I think it has tagged commands, which
you need if you want to be able to use a write cache *and* reliably say
whether your data is on non-volatile store or not. This should only
matter for writes (and even then only for systems which care about
answering this question). On the other hand I also think I read that
they botched the spec so you couldn't actually rely on it.
I suspect the dominant factor is that no one is making high-performance
PATA disks now - they'll all be SATA for domestic use and SAS / FC for
enterprise stuff (FC itself presumably will go away as a disk
interconnect to be replaced, I suppose by SAS, but will live on as a
storage-system <-> computer interconnect for SANs etc because you can
have very long cable runs).
--tim
On Thu, 31 Aug 2006 20:32:23 +0100, Tim Bradshaw <···@tfeb.org>:
>I suspect the dominant factor is that no one is making high-performance
>PATA disks now
AFAIK, the slowest part in a hard drive, i.e. the mechanical part, is
the same for a PATA drive and a SATA drive.
On 2006-08-31 21:36:49 +0100, Fabien LE LEZ <········@gramster.com> said:
> AFAIK, the slowest part in a hard drive, i.e. the mechanical part, is
> the same for a PATA drive and a SATA drive.
Well, that's my point: probably they're not, because new drives may
well not be shipping with PATA.
On Fri, 1 Sep 2006 02:07:32 +0100, Tim Bradshaw <···@tfeb.org>:
>> AFAIK, the slowest part in a hard drive, i.e. the mechanical part, is
>> the same for a PATA drive and a SATA drive.
>
>Well, that's my point: probably they're not, because new drives may
>well not be shipping with PATA.
I believe the controller card is pretty independant.
And it's pretty soon to put PATA drives into their grave -- lots of
PATA disks are still being sold.
But anyway, my point is, there isn't much evolution in hard drives'
mechanical parts: the platters still turn at 7200 rpm, like five years
ago.
On 2006-09-01 17:31:28 +0100, Fabien LE LEZ <········@gramster.com> said:
> But anyway, my point is, there isn't much evolution in hard drives'
> mechanical parts: the platters still turn at 7200 rpm, like five years
> ago.
10k and 15k drives are quite common now for serious applications.
--tim
On Fri, 01 Sep 2006 18:31:28 +0200, Fabien LE LEZ <········@gramster.com>
wrote:
> On Fri, 1 Sep 2006 02:07:32 +0100, Tim Bradshaw <···@tfeb.org>:
>
>>> AFAIK, the slowest part in a hard drive, i.e. the mechanical part, is
>>> the same for a PATA drive and a SATA drive.
>>
>> Well, that's my point: probably they're not, because new drives may
>> well not be shipping with PATA.
>
> I believe the controller card is pretty independant.
> And it's pretty soon to put PATA drives into their grave -- lots of
> PATA disks are still being sold.
>
> But anyway, my point is, there isn't much evolution in hard drives'
> mechanical parts: the platters still turn at 7200 rpm, like five years
> ago.
>
For one thing you can get drives with 10 000 rpm and 15 000 rpm.
They just cost a lot more. Secondly the density has gone up
tremendously. So you pass more sectors pr time. Thus the drives
are actually faster. Third the drives are much smaller
1 inch instead of 3 inch height. Also the drives are
much quieter. Then also we have the addition of micro-drives
and memory cards.
So actually hard drives have evolved significantly.
I payed about 100 $ for 2 160 GB drives.
A 1 Gb memory stick the size of a key chain. 40 $
What would a similar capacity have cost 5 years ago?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Fri, 01 Sep 2006 19:21:47 +0200, "John Thingstad"
<··············@chello.no>:
>For one thing you can get drives with 10 000 rpm and 15 000 rpm.
>They just cost a lot more. Secondly the density has gone up
>tremendously. So you pass more sectors pr time. Thus the drives
>are actually faster.
What I meant, is that I see no reason for a 300-GB, 7200 rpm, 3"1/2
SATA drive, to be significantly faster than a 300-GB, 7200 rpm, 3"1/2
PATA drive.
(Except maybe some tricks like NCQ, that may make operations of small
files a bit more efficient.)
>Third the drives are much smaller
>1 inch instead of 3 inch height.
Did you see any 3-inch-high hard drives in the last 10 to 15 years?
The oldest drive I have is a WD 200-MB IDE, and its size is the same
usual 3"1/2 x 1", like all recent disks.
I think I've seen a 20-MB disk on a very old PC (286), and it was the
same size.
>Also the drives are much quieter.
Yes. Both PATA and SATA.
On Fri, 01 Sep 2006 23:28:17 +0200, Fabien LE LEZ <········@gramster.com>
wrote:
>
>> Third the drives are much smaller
>> 1 inch instead of 3 inch height.
>
> Did you see any 3-inch-high hard drives in the last 10 to 15 years?
> The oldest drive I have is a WD 200-MB IDE, and its size is the same
> usual 3"1/2 x 1", like all recent disks.
>
My bad. Mixing inches and centimeters.
My new drives approx 1/3 inch thick.
So they are much thinner than my old ones.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Sat, 02 Sep 2006 00:08:13 +0200, "John Thingstad"
<··············@chello.no>:
>My new drives approx 1/3 inch thick.
I suppose they are relatively small (around 100 GB), and have roughly
the same density as a 1"-thick 300-GB hard disk?
John Thingstad wrote:
> On Wed, 30 Aug 2006 13:50:36 +0200, Fabien LE LEZ <········@gramster.com>
> wrote:
>
> > On 30 Aug 2006 02:50:14 -0700, ·············@gmail.com"
> > <············@gmail.com>:
> >
> >> Eclipse is better than any crap that Lisp has, and is only slow and
> >> bloated if you get your systems out of the dumpster.
> >
> > So, what's the minimum configuration to make it work smoothly?
> > [I mean, any action, including starting the program, is too fast for
> > the user to notice he's waiting.]
> >
>
> About 500mb.
> But if you are building anything substantial that too will require
> a lot of memory so 1 Gb is better.
> Java programs using Swing tend to grow enormously when used
> for a while. I believe one of the reasons for this is that
> memory is allocated in procedures then a subproc is called and the original
> memory is never freed. This leads to a memory leak because java
> retains memory not really in use. It is less of a problem in
> Lisp since the coding style is more functional.
> When Swing was created I think it was generally believed that
> garbage Collection solved all problems. One the code was written the
> problem was realized, but it was too late.
>
> --
Another clueless one giving advice for something they've obviously
never used. Eclipse doesn't use Swing.
············@gmail.com wrote:
>>About 500mb.
>>But if you are building anything substantial that too will require
>>a lot of memory so 1 Gb is better.
>>Java programs using Swing tend to grow enormously when used
>>for a while. I believe one of the reasons for this is that
>>memory is allocated in procedures then a subproc is called and the original
>>memory is never freed. This leads to a memory leak because java
>>retains memory not really in use. It is less of a problem in
>>Lisp since the coding style is more functional.
>>When Swing was created I think it was generally believed that
>>garbage Collection solved all problems. One the code was written the
>>problem was realized, but it was too late.
>>
>>--
>
>
> Another clueless one giving advice for something they've obviously
> never used. Eclipse doesn't use Swing.
First, how the hell would he know, just by *using* Eclipse,
whether it used Swing or not? (Perhaps he could tell by
its modestly un-Swing-like 500MB memory footprint?)
Second, I got the impression he was talking about the Java
code one would develop using Eclipse. That is, 500MB to run
the IDE, plus another 500MB to accomodate the program under
development, which might very well use Swing.
-- JK
Joe Knapka wrote:
> > Another clueless one giving advice for something they've obviously
> > never used. Eclipse doesn't use Swing.
>
> First, how the hell would he know, just by *using* Eclipse,
> whether it used Swing or not? (Perhaps he could tell by
> its modestly un-Swing-like 500MB memory footprint?)
>
I was assuming he was not a complete idiot and had two eyes and that's
how he would know it didn't use Swing.
> Second, I got the impression he was talking about the Java
> code one would develop using Eclipse. That is, 500MB to run
> the IDE, plus another 500MB to accomodate the program under
> development, which might very well use Swing.
>
> -- JK
It doesn't use 500MB just to run the IDE (not even close), so obviously
he was talking out of his ass about things he has no idea about.
············@gmail.com wrote:
> It doesn't use 500MB just to run the IDE (not even close), so obviously
> he was talking out of his ass about things he has no idea about.
I used to do some Java stuff on a box with 384MB (running windows 2000
and nothing else significant, probably a VNC viewer and a couple of
cygwin shells) and it was very painful indeed.
half a gig is probably a reasonable minimum if you don't want to sit
around a lot. I can't see any reason at all to have less than a gig
myself, & I'd not configure a development machine with less than 2 (by
the time you've god a VMware image for test etc, you need lots). Now
you're going to say `but that's for the IDE *and* the OS etc, not just
the IDE', but that is, in fact, the question that was asked and
originally answered.
--tim
On Thu, 31 Aug 2006 08:08:45 +0200, ············@gmail.com
<············@gmail.com> wrote:
> Joe Knapka wrote:
>> > Another clueless one giving advice for something they've obviously
>> > never used. Eclipse doesn't use Swing.
>>
>> First, how the hell would he know, just by *using* Eclipse,
>> whether it used Swing or not? (Perhaps he could tell by
>> its modestly un-Swing-like 500MB memory footprint?)
>>
>
> I was assuming he was not a complete idiot and had two eyes and that's
> how he would know it didn't use Swing.
>
In truth it has been a while since I used it.
Thinking about it I know it dosn't use Swing.
>
>> Second, I got the impression he was talking about the Java
>> code one would develop using Eclipse. That is, 500MB to run
>> the IDE, plus another 500MB to accomodate the program under
>> development, which might very well use Swing.
>>
>> -- JK
>
> It doesn't use 500MB just to run the IDE (not even close), so obviously
> he was talking out of his ass about things he has no idea about.
>
But the memory requirements grow over time..
I am not talking about the memory when I start it.
My last machine had 256 Mb with windows. To low to run any large Java App
comfortably. I monitored the use of memory over time and stand by the 512
Mb claim.
You can run it with a lot less. But the question was "without seeming
slow".
And yes.. My frustration comes more from large java programs
in general than Eclipse in particular.
Sorry if I insulted you with my ignorance.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> writes:
> On Wed, 30 Aug 2006 13:50:36 +0200, Fabien LE LEZ
> <········@gramster.com> wrote:
>
>> On 30 Aug 2006 02:50:14 -0700, ·············@gmail.com"
>> <············@gmail.com>:
>>
>>> Eclipse is better than any crap that Lisp has, and is only slow and
>>> bloated if you get your systems out of the dumpster.
>>
>> So, what's the minimum configuration to make it work smoothly?
>> [I mean, any action, including starting the program, is too fast for
>> the user to notice he's waiting.]
>>
>
> About 500mb.
I doubt it. With half a bit, you don't go too far in computing...
--
__Pascal Bourguignon__
·············@gmail.com" <············@gmail.com> writes:
> Eclipse is better than any crap that Lisp has, and is only slow and
> bloated if you get your systems out of the dumpster.
God damn it! You broke my troll-o-meter!
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > Eclipse is better than any crap that Lisp has, and is only slow and
> > bloated if you get your systems out of the dumpster.
>
> God damn it! You broke my troll-o-meter!
>
> --
You're so weak that you don't even have anything to counter with.
Maybe Kenny will lend you some of his meds and you'll come up with
something.
············@gmail.com wrote:
> David Steuber wrote:
>> ·············@gmail.com" <············@gmail.com> writes:
>>
>>> Eclipse is better than any crap that Lisp has, and is only slow and
>>> bloated if you get your systems out of the dumpster.
>> God damn it! You broke my troll-o-meter!
>>
>> --
>
> You're so weak that you don't even have anything to counter with.
> Maybe Kenny will lend you some of his meds and you'll come up with
> something.
Here is something at the same level of your posting:
The IDEs for Common Lisp are better than any crap that Java has, and are
never slow and bloated.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> ············@gmail.com wrote:
> > David Steuber wrote:
> >> ·············@gmail.com" <············@gmail.com> writes:
> >>
> >>> Eclipse is better than any crap that Lisp has, and is only slow and
> >>> bloated if you get your systems out of the dumpster.
> >> God damn it! You broke my troll-o-meter!
> >>
> >> --
> >
> > You're so weak that you don't even have anything to counter with.
> > Maybe Kenny will lend you some of his meds and you'll come up with
> > something.
>
> Here is something at the same level of your posting:
>
> The IDEs for Common Lisp are better than any crap that Java has, and are
> never slow and bloated.
>
Or in other words, you have nothing to counter with either.
············@gmail.com wrote:
> Pascal Costanza wrote:
>> ············@gmail.com wrote:
>>> David Steuber wrote:
>>>> ·············@gmail.com" <············@gmail.com> writes:
>>>>
>>>>> Eclipse is better than any crap that Lisp has, and is only slow and
>>>>> bloated if you get your systems out of the dumpster.
>>>> God damn it! You broke my troll-o-meter!
>>>>
>>>> --
>>> You're so weak that you don't even have anything to counter with.
>>> Maybe Kenny will lend you some of his meds and you'll come up with
>>> something.
>> Here is something at the same level of your posting:
>>
>> The IDEs for Common Lisp are better than any crap that Java has, and are
>> never slow and bloated.
>
> Or in other words, you have nothing to counter with either.
Right, because there's nothing to counter.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/