After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways. Each has a decent size library of useful utilities as a standard
portable part of the core language, the LISP package, and the java.lang
package, respectively. Both have big integers, although only LISP has
rationals as far as I can tell. Because CL supports keyword arguments,
it has a wider range of string search utilities etc. where :key and
:test and :start :end etc. are parametric instead of fixed or
special-cased here but not there. The only major differences I see are
speed and interactivity:
Speed comparisons on FreeBSD Unix:
javac or java takes appx. 24 seconds to start up the first time, then
is virtually instant subsequent times within a short time span.
However even on immediate re-runs, javac takes between 2 and 7 seconds
to compile a very small file (23 lines total, only 10 lines of actual
code).
CMUCL takes appx. 2 seconds to start up the first time, then is
virtually instant subsequent times within a short time span.
Recompiling a 33-line file runs so blindly fast that even with
*error-output* diverted to bit sink so as to suppress listing of each
function compiled, its limited only by 19200 bps printout of the return
value.
(let ((*error-output* (make-broadcast-stream))) (compile-file "tabsp.lisp"))
#p"/home/users/rem/JavaWork/tabsp.x86f"
You need to re-start java every time you want to compile and every time
you want to run what you compiled, you can't just leave the jvm running
and load tasks into it. Consequently, if you go away from java for a
minute to edit the source to recompile it, etc., then you're back to 24
seconds start-up again when you want to compile what you edited, a
royal pain! By comparison, you can stay in CMUCL and do almost
everything there, so you don't have to suffer even the two-second
first-time-start ever again during a session.
Interactivity: In CL (and virtually any LISP since the original), you
can sit in a read-eval-print loop composing and trying one line of code
at a time, storing the results of correct computation in global
variables to feed into the next step of composing&trying. By
comparison, in java you have to switch back and forth between editing
the source of not just what you want to test but a whole test rig
around it to make a "complete program", compiling that "complete
program" to bytecode, and running that "complete code" just to see if
you got one line of new code correct. Comparing the instant feedback
when typing one new LISP form into the R-E-P, against the 24+ second
turnaround to try one new line of java code, LISP is a *big* winner!
So I ask, is there any particular kind of task where java has an
advantage over LISP? The only thing I can think of is networking. I've
heard that java has networking built into the language, things like
sockets, TCP/IP, HTTP, etc., whereas they aren't part of CL per se and
need to be supplied by various vendors on the side. So is this true,
that java is better than CL for networking stuff? Also, is there any
other area where java beats CL?
Well, there's Unicode, which is built into java but not CL, but I have
no use for it at present so that doesn't count. But I'd like to write
some Web-networking code to replace the hack I currently use where lynx
is run as a sub-process under CL and lynx does all the work of handling
cookies etc. If java can do all that directly more easily than CL, I
might give it a try.
Jul 17 '05
73  7883 
Oliver Plohmann wrote: Since several Lisp gurus have replied to this thread maybe one can
tell me why recursiveness and non-destructiveness in Lisp is such a
holy thing (this is a "real" question - not a rhetoric one).
How long ago was your Lisp class?
The funny thing is that anyone posting on c.l.lisp a recursive solution
where any of the many Lisp iteration mechanisms (various do's, various
map's, loop) would suffice can reliably count on being flamed as a
closet schemer.
Me, I got a huge kick out of recursion when I started my Lisp family
programming in Logo. It took a little mind-bending, but I grokked the
power straight away. So I for one do not pounce on those who recur for
recursion's sake, but then neither do I eschew iteration where it will,
um, do.
btw, sounds like you gave up on recursion and Lisp too fast, before you
had mastered recursion. Recursion is worth understanding for those times
when iteration is the wrong hammer.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Oliver Plohmann wrote: Since several Lisp gurus have replied to this thread maybe one can
tell me why recursiveness and non-destructiveness in Lisp is such a
holy thing (this is a "real" question - not a rhetoric one).
It's not. It's a quasi-religious thing with some *Scheme*
advocates, but (most?) Common Lisp programmers view the
recursion fetish with something between dismay and disdain.
Paul
Oliver Plohmann schrieb: The major advantage of Java, C, C++, Pascal, etc. over Lisp is that
solving anything that can be solved with an iterative solution easily
is easy. To me that's the real advantage ...
I once took a Lisp class when I was studying. I was quite curious
about Lisp. Then a programming task was given that would have been a
peace of cake when solving it with an iterative approach. Looking for
a recursive stack-based solution for Lisp caused big headaches. Since
that day I was not that interested in Lisp any more. Okay, with a
recursive solution things are non-desctructive which is convenient
when debugging. Things in Smalltalk are also non-desctructive (okay,
not 100% as in Lisp - but in general it is true) since the respective
methods in the Collection hierarchy only iterate over the receiver
collection but work on copies. It makes probably more sense to compare
Lisp and Smalltalk - they are more alike and both almost dead.
As others already pointed out: Lisp /does support/ iteration.
Hmm, what do you do when you can apply iteration on a problem but your
language doesn't support it? While Lisp can be extended to support your
kind of iteration as if it always had been in the language before in
many other languages you often run into the problem to describe a good
iteration with basic mechanisms - all the time.
In Java for example you could not easily loop over collections until Sun
came up with 1.5. When a new paradigm of iterating is needed you would
have to ask again Sun to implement it and wait perhaps one or two years.
In that time tens of thousands of lines of code would have been written
with a not so powerfull iteration method.
In these situations it would have been nice to have macros like Lisp does.
No Oliver, I think when we look at language constructs we won't find big
advantages of Java over Lisp. We need to look at libraries. There we can
find many things which Java has and Lisp doesn't.
You want to integrate SAP? No problem with Java with original drivers
from SAP. In Lisp.. you would have to write them yourself.
André
-- ol****@plohmann.com (Oliver Plohmann) writes: Since several Lisp gurus have replied to this thread maybe one can
tell me why recursiveness and non-destructiveness in Lisp is such a
holy thing (this is a "real" question - not a rhetoric one).
It isn't holy. There are some advantages to non-destructive
solutions. As you pointed out, it is easier to debug if your input
isn't getting smashed. Non-destructive solutions compose easier and
can maximize sharing. The results of pure functions can be cached.
The compiler can easily re-order computations if they do not
side-effect.
In article <ll**********@ccs.neu.edu>, Joe Marshall <jr*@ccs.neu.edu>
wrote: ol****@plohmann.com (Oliver Plohmann) writes:
Since several Lisp gurus have replied to this thread maybe one can
tell me why recursiveness and non-destructiveness in Lisp is such a
holy thing (this is a "real" question - not a rhetoric one).
It isn't holy. There are some advantages to non-destructive
solutions. As you pointed out, it is easier to debug if your input
isn't getting smashed. Non-destructive solutions compose easier and
can maximize sharing. The results of pure functions can be cached.
The compiler can easily re-order computations if they do not
side-effect.
GC is also potentially a lot faster for side-effect-free code.
E.
Erann Gat <gN*******@flownet.com> writes: In article <ll**********@ccs.neu.edu>, Joe Marshall <jr*@ccs.neu.edu>
wrote:
ol****@plohmann.com (Oliver Plohmann) writes:
> Since several Lisp gurus have replied to this thread maybe one can
> tell me why recursiveness and non-destructiveness in Lisp is such a
> holy thing (this is a "real" question - not a rhetoric one).
It isn't holy. There are some advantages to non-destructive
solutions. As you pointed out, it is easier to debug if your input
isn't getting smashed. Non-destructive solutions compose easier and
can maximize sharing. The results of pure functions can be cached.
The compiler can easily re-order computations if they do not
side-effect.
GC is also potentially a lot faster for side-effect-free code.
Yes! Thanks for mentioning that. The `write-barrier' for
generational GC does not need to apply to newly allocated storage, and
ephemeral garbage costs practically nothing.
--
~jrm
André Thieme <ad****************************@justmail.de> writes: You want to integrate SAP? No problem with Java with original drivers
from SAP. In Lisp.. you would have to write them yourself.
I think there's a bootstrapping problem here: Such interfaces
(don't know about SAP, but we're interfacing to a number of weird
protocols where I work) are easy to write in lisp, so every active
lisper who needs it writes his own and doesn't think of sharing
his little hack, so the next lisper writes it himself too... and
so on.
--
(espen)
Hello!
Joe Marshall <pr***********@comcast.net> wrote: [...]
GC is also potentially a lot faster for side-effect-free code.
Yes! Thanks for mentioning that. The `write-barrier' for
generational GC does not need to apply to newly allocated storage, and
ephemeral garbage costs practically nothing.
Of course, if you add non-strictness into the mix, you get hidden
side effects again (updating a deferred calculation with its result),
so you need write-barriers or so again.
You still gain the greater ease to reason about some aspects of the
code though.
Kind regards,
Hannah.
Mario S. Mommer <m_******@yahoo.com> wrote in message news:<fz************@germany.igpm.rwth-aachen.de>... ol****@plohmann.com (Oliver Plohmann) writes: I once took a Lisp class when I was studying. I was quite curious
about Lisp. Then a programming task was given that would have been a
peace of cake when solving it with an iterative approach. Looking for
a recursive stack-based solution for Lisp caused big headaches. Since
that day I was not that interested in Lisp any more.
You probably mean Scheme here, or at least not Common Lisp. If
something is a peace of cake iteratively, then in Common Lisp you will
solve that iteratively (and it will be a peace of cake too).
You were right. We were using Scheme back then ;-). Thanks for the
answers. Usually ppl just start to flame you and your question remain
unanswered. Okay then, maybe I have a look at Lisp again.
Regards, Oliver
OTOH, if it is a peace of cake recursively/functionally, then again,
you'll probably solve it recursively in Common Lisp.
Modern Common Lisp is a multiparadigm language.
>>>>> On Wed, 16 Jun 2004 09:56:02 +0200, Espen Vestre ("Espen") writes:
Espen> André Thieme <ad****************************@justmail.de> writes: You want to integrate SAP? No problem with Java with original drivers
from SAP. In Lisp.. you would have to write them yourself.
Espen> I think there's a bootstrapping problem here: Such interfaces
Espen> (don't know about SAP, but we're interfacing to a number of weird
Espen> protocols where I work) are easy to write in lisp, so every active
Espen> lisper who needs it writes his own and doesn't think of sharing
Espen> his little hack, so the next lisper writes it himself too... and
Espen> so on.
If he writes a good implementation, why not sell it?
Kenny Tilton <kt*****@nyc.rr.com> wrote in message news:<l%*********************@twister.nyc.rr.com>. .. Oliver Plohmann wrote:
You were right. We were using Scheme back then ;-). Thanks for the
answers. Usually ppl just start to flame you and your question remain
unanswered. Okay then, maybe I have a look at Lisp again.
Hang on, what happened to?:
It makes probably more sense to compare
Lisp and Smalltalk - they are more alike and both almost dead.
Why look at a near-dead language?
Well, I'm not really sure which of those two languages is the more
dead one ... ;-). But I would say they are both quite dead, which is a
pity for both of them. The only thing Lisp has that Smalltalk hasn't
is macros. I'm not really sure I fully comprehend the power of macros.
So I won't make a statement whether you can live without them or not.
But I think Smalltalk is more organized than Lisp and in case of
Squeak you can change the compiler/VM to add those macros to Squeak.
confusedly, kenny
Oliver Plohmann schrieb: Well, I'm not really sure which of those two languages is the more
dead one ... ;-). But I would say they are both quite dead, which is a
pity for both of them. The only thing Lisp has that Smalltalk hasn't
is macros. I'm not really sure I fully comprehend the power of macros.
So I won't make a statement whether you can live without them or not.
But I think Smalltalk is more organized than Lisp and in case of
Squeak you can change the compiler/VM to add those macros to Squeak.
Did you know that Dr. Alan Kay, the inventor of Smalltalk said some few
years ago, that Lisp is "the greatest single programming language ever
designed"?
( http://www.paulgraham.com/quotes.html)
André
--
André Thieme <ad****************************@justmail.de> wrote in message news:<ca**********@ulric.tng.de>... Did you know that Dr. Alan Kay, the inventor of Smalltalk said some few
years ago, that Lisp is "the greatest single programming language ever
designed"?
(http://www.paulgraham.com/quotes.html)
André
Hi André!
I didn't know, but I'm not all that surprised. Smalltalk has many
similarities with Lisp (e.g., Smalltalk blocks and Lisp lambda
expressions, non-destructive programming, and other things).
Cheers, Oliver
> From: Pete Kirkham <pe***************@cafemosaic.co.uk> How would you see that in lisp without using the introspector running
in an interactive environment?
If you use ordinary nested-list structures when first developing your
new program, the ordinary read-eval-print loop is all you need to see
the result of every step you key in manually. Only a poor teacher would
insist on brand new students, never programmed before, using other
kinds of structures from the very start. And any experienced lisp
programmer would know to use ordinary nested-list structures when
developing something that is really difficult to do, then switch to
other kinds of structures later if there's a really good reason to do
so. By comparison, in java generally you hardly ever use
nested-linklist structures, you use instances of classes, for which
there isn't a standard useful way to print them. So even with BeanShell
you won't have the ease of lisp. (If BeanShell provides a useful
printed representation of every class instance, somebody please correct
what I said there. By the way, does anybody have a CGI interface to
BeanShell so that I could play with it to get a feel for how nice it
is?)
People expect more than can be delivered through an HTML form, let
alone VT100.
Google does just fine with HTML forms, and it's pretty popular, both
regular Web search, and Google Groups.
Yahoo Groups does fine with HTML forms too, except for their live chat
service which requires something more.
Or lambda, which is so old it's ancient Greek.
Without changing the syntax, what word would you like in place of
lambda? Maybe anonymous-function, or just anonfunc to keep it short?
programmers are taught that a program is 'like a recipe', so how can
a recipe take part of the cookbook as an ingredient?
Actually I like that metaphor! Lisp allows you to write programs that
not just follow recipies a human wrote, but write their own recipes and
then follow them just the same! Macros are a crude beginning to that
idea: You write a template that converts one kind of form into another
kind of form, with the latter being a recipe that the computer can
follow. So for example you could have the macro form:
Fried eggs and toast <n>
expand into:
Put oil and <n> eggs into frypan and turn on burner.
Put <n> pieces of bread into toaster-oven, set to high, and press on.
When eggs are almost done, turn over.
After toaster oven turns off, wait a few seconds then remove toast.
When eggs are all done, remove from pan, place on top of toast, and
turn off burner.
So depending on the number you put for <n>, you get a different recipe.
(With cakemixes etc. where you have to measure strange amounts of
different ingredients proportionally, the parameterized recipe is much
more useful than my trivial example above. Most such recipes give the
amounts for a standard size such as to serve four, and tell you to us
proportionally larger or smaller amounts to serve other numbers of
people, which is a royal pain to do manually. So having the ability to
have the computer generate the desired recipe could be seen as an
advantage to anyone who ever cooks such recipes.) Then once the student
understands that metaphor, and has written simple programs manually,
combining the two ideas to write a macro that writes a program would be
understandable.
too many people are taught to program rather than taught to think.
Why do you assume it's an either-or situation, not both??
lisp/Prolog/SQL you say 'I want the first part of the rest of the list'.
C/C++/Java/CODASYL 'I have a list, I will navigate through it until I
have the second element, then return that element'
I disagree. In either lisp or C you can do it either way.
Lisp syntax structures its calls starting with the result (though the
effect is still procedural), Java syntax structures its calls starting
with your arguments.
For static methods, that's not true at all. Package and class and
function name is first, arguments come later, making them the same as
ordinary lisp function calls where package:functionname precede
arguments.
For instance methods it's only partly true. The object reference comes
first, then the dot, then the method name interpreted within the class
that the object has at runtime, then the other arguments which are
interpreted per their compiletime declared class not their actual
runtime class in deciding which overloaded method to call.
But there seems to be a fundamental difference in the *semantics*:
http://cl-cookbook.sourceforge.net/clos-tutorial/
... OO systems which only allow you to
specialize on the first argument. This argument is then given
linguistic prominence, and the function call is given a new syntax to
reflect that:
Hmm, sounds like java is an example of such an OO language, am I correct?
CLOS supports multi-methods - methods that can specialize on more than
one argument.
So that's why the same kind of syntax, one argument up front the rest
later, isn't used in lisp (specifically CLOS).
the Java syntax fits in with the model of program-as-recipe
Ignoring the point about how Java doesn't make it easy for programs to
compose programs, whereas lisp does: I disagree. Either language can be
programmed the same way: Define a function (method) which takes
arguments, do some calculation based on them, do some more calculation
based on those calculations, etc., until it has the finished result,
then return that result. (Either can return multiple values: CL
explicitly via an efficient mechanism, Java via allocatinging a vector
and returning that, which is the old way lisp did it before
multiple-value returns were implemented. That's just an efficiency
issue.) You get some ingredients, do various mixing and cooking of
them, and at the end you have something to eat. Function/method calling
within a function/method is like a sub-recipe for making some difficult
ingredient, such as won tons which are an ingredient in won ton soup.
Again, I see no essential difference between Java and Lisp in having
recipe as a metaphor.
Anyway, back to lack of keywords, so every combination of what would be
keywords in CL becomes a totally separate functionName and/or
argumentList in java.
This is more a lack of optional arguments, rather than keyword arguments.
Incorrect. Just yesterday I was working on a GUI program (AWT Applet)
in Java, and needed to find the appropriate version of a particular
method. I wanted to specify the message text, title, type of message,
and nothing else. But that particular combination wasn't available, so
I had to use a method that required additional arguments, and supply
dummy values for each of them. Optional arguments wouldn't have helped,
because the *first* argument of the method I used was one of the
arguments I didn't want to have to specify myself. Optional arguments
only let you stop supplying arguments from some point onward, they
don't let you skip early arguments and include later ones. Keyword
arguments would have allowed me to specify exactly the arguments I
wanted, and let the rest default to reasonable values. Look at this
mess:
static String showInputDialog(Component parentComponent,
Object message)
Doesn't let me specify title, hence useless for my need.
static String showInputDialog(Component parentComponent,
Object message, Object initialSelectionValue)
Doesn't let me specify title, hence useless for my need.
static String showInputDialog(Component parentComponent,
Object message, String title, int messageType)
What I want, except I have to supply the first argument somehow even
though it's a pain, but null seems to work (put dialog in middle of
whole screen instead of centered within current Applet if I specify
that as the parentComponent).
static Object showInputDialog(Component parentComponent,
Object message, String title, int messageType, Icon icon,
Object[] selectionValues, Object initialSelectionValue)
Requires several arguments I can't supply, hence useless for my need.
static String showInputDialog(Object message,
Object initialSelectionValue)
Doesn't let me specify title, hence useless for my need.
Oh if you're curious why I'm using a swing JOptionPane method within an
AWT Applet: Because AWT doesn't have anything like that yet, a
deficiency of Java'a GUI API.
IDEs also help in the other aspect that keywords do, by showing the
programmer what the names of the arguments are.
But there are five different overloaded versions of the same-name
method, so it's impossible for the IDE to know which of the five should
have its argument names shown to programmer. By comparison with CL with
keyword arguments an IDE could do the "right thing" of clearly
indicating which arguments if any are required then what keyword
arguments may be used, perhaps by a pull-down menu hanging from the
cursor the way Visual Basic's IDE deals with a list of all the GUI
controls that might be specified for an event handler.
Indeed, in java working with linked lists must be an awful pain.
Either your list can contain only one kind of element, so you declair
your own class to include link-cells whose data pointer is of that
type, or you use the generic Object type and deal with having to write
code that explicitly checks the case of every element at runtime.
You tend to use the singly polymorphic dispatch mechanism. It's not as
elegant as generic functions, but it's not something you notice- the
main difference is that the generic function definition has to be placed
into an 'interface' and (if using Java version<1.5) you have to 'cast'
(coerce) the elements in the list to the interface type.
It's a big loser: Suppose you want to have a list that can contain any
mixture of twenty different types, mostly built-in types. You *cannot*
create an interface for these twenty types, then make each of the
twenty types implement your new interface, because you are not allowed
to re-define system-supplied API classes to make them implement a new
interface they didn't before. So you'd have to extend each of the
system-supplied classes to be a version that was just like the system
version but which implemented your new interface. Then you'd have to
keep track of whether you were using your extension or the original
type throughout your program, doing downcasting explicitly as needed.
It's a waste of effort, probably easier to just use Object type which
needs explicit typecase dispatch in your code, but Java doesn't have
typecase, so daisy chain of:
else if (obj instanceof type<n>) { ... }
no big deal. Or better, have a single static method that maps from the
twenty object types to an integer which is used as an index in your
emulated typecases, so you can just use a switch select statement.
Then when you start to use a 21th type of object in your list, you just
modify the static method to include that new type, and you search for
all calls to that static method to make sure all your code can handle
the new object type. As for the actual code you run after you've found
which type the object is: You can then cast to the actual type it is,
and use method overloading to make the syntax parallel so it looks nice
and can be eyeballed to see if it's all correct:
else if (obj instanceof BigInteger) { return processObj((BigInteger) obj); }
else if (obj instanceof Double) { return processObj((Double) obj); }
else if (obj instanceof Character) { return processObj((Character) obj); }
or equivalent with static function returning index which is named constant.
switch (MyTypes.objToTypeCode(obj)) {
case MyTypes.TYPE_BIGINTEGER: return processObj((BigInteger) obj); break;
case MyTypes.TYPE_DOUBLE: return processObj((Double) obj); break;
case MyTypes.TYPE_CHARACTER: return processObj((Character) obj); break;
default: throw new MyTypes.unknowntype... }
Referring to the generic sequence functions in CL, specifically in this
example used with a linked-list (although a general vector would work
just the same, with different syntax in the example): In CL, if you pass an integer instead of a character, it looks for that
integer, not the character with that ASCII code, for example:
(position 65 '(#\A #\B 65 66))
will find the 65 instead of the #\A, returning 2 instead of 0 as the
index where it found that number.
Strings are objects that wrap arrays of UTF-16 encoded characters, not
ASCII, nor are they lists of typed objects as in your example. You can't
create a string in Lisp with numbers in it, a string is a vector of
characters, ...
That's irrelevant to my point, which was about generic sequences (lists
or vectors of generic element type), not specialized sequences of
characters-only. Suppose in java you make a linked list, or array, as
the representation of a sequence of Objects of various types. Does the
Java API provide any method(s) equivalent to this?
position item sequence &key :from-end :test :test-not :start :end :key
java.util.Arrays.asList(new Object[]{
new Character('A'),
new Character('B'),
new Integer(65),
new Integer(66),
}).indexOf(new Integer(65))
The ugly part there is the creation of the list itself, in the absense
of any parser such as READ in lisp. But I thought Java had software to
handle serialization and deserialization of data for purpose of
communicating across the network? How hard is it to set up a a Java
equivalent to CL's READ-FROM-STRING function that created all the
necessary stringinput/bufferedreader daisy chain and fed it through a
deserialization method to allow something like:
MyParser.deserializeLispSyntax("(#\A #\B 65 66)").indexOf(new Integer(65))
Too bad there's no way to add new methods to a system-supplied API
class, in this case String, or else you could maybe do this:
"(#\A #\B 65 66)".deserializeLispSyntax().indexOf(new Integer(65))
(normally I'd use a script to generate such lists in Java, with lisp
being the scripting language of choice)
I don't quite understand what you mean there. Do you mean you actually
run CL as a sub-process under Java and pass it the s-expression as a
string and somehow get back a linked list or array in the jvm, such as
by CL doing callbacks to Java API methods to build up the Java object
piece by piece? Or do you mean you'd run a CL program to convert the
s-expresssion syntax to XML or other serial representation known by
Java, and then use Java's built-in XML-or-whatever deserializer to load
the object into the jvm?
Most languages, Java included, are destined to evolve into lisp or
remain niche languages.
Hmm, that's the opposite of what a certain very opinionated DeAnza
instructor said (LISP is an A.I. langauge, not useful for anything
except that niche -- paraphrased to fit the current context).
I agree with you, not him, of course, on this point. CL is the general
purpose language, all other languages are niche languages, but some are
evolving to escape their niche to become as general as CL.
(I have to count Scheme as a niche language, sigh.)
Still I would like CL to become even more general, such as including
what PSL (Portable Standard LISP) called "SysLisp", which is a way to
cross-compile s-expressions via LAP into low-level assembly code that
can be included in ordinary assembly-language programs that can be
assembled to run stand-alone as an application or as a module in some
non-LISP environment, thereby allowing using SysLisp to write the main
part of compilers and even operating systems, even the kernel,
replacing C as the standard language for writing such. Maybe this has
already been done but isn't and won't be in the ANSI standard because
it's not of enough general use?
> From: Antonio Menezes Leitao <An************@evaluator.pt> Are you referring to the Java API which is all nicely documented
(module a few obvious mis-statements such as the one I found whereby it
claims the arcsin etc. functions take an angle as an argument) on the
WebSite? Or third-party libraries which can be difficult to find and
even more difficult to get a license to use? Both, actually. BTW, which third-party libraries are you talking about?
Any that I am unable to find out about. In my search for Java libraries
for a browser/spider to handle cookies for HTTP sessions, all I could
find was Jakarta, a third-party library, nothing in standard libraries,
and the documentation for Jakarta indicated there are three ways
cookies are done and you have to just try different ways to see which
way a particular server is using, so it's a pain even with Jakarta to
write any software to handle cookies the server throws at you.
I looked for interval arithmetic, but can't find what I want.
Java has been changing from the beginning. I know that the changes are
mostly backward compatible but I would hardly considered the language as
"stable" (and much less as "nice").
Hmm. Does the jvm suddenly change out from under the user, causing old
already-compiled code to suddenly stop working? Or is the jvm fine but
the system library no longer supports the method you have been using,
or the method no longer does exactly what it used to do? Or is it just
that if you try to re-compile the old code that compiled fine before,
it might no longer compile because some basic syntax it used has been
depricated and expunged from the compiler? Or just that there's new
stuff you haven't been using and you feel bad that your old program
still does things the old way instead of taking advantage of new
features?
Have you tried to run Java 1.2 on older browsers?
I don't know what that question means. I run java on a computer, not on
a browser. Please clarify the question.
By the way, is there any way to ask javac or java what version it is,
or to otherwise learn that information on a given system? On Unix, I
can use the whereis command, which on this FreeBSD Unix shell account
I'm using gives the directory as /usr/local/jdk1.2.2/bin/ so does that
mean we have version 1.2.2 installed here? But there's no way to run a
java-applet-enabled browser here (via VT100 dialup) as far as I know,
so that info probably isn't usefully related to your question. But on
campus where I'm taking a java class, they have jcreator on MicroSoft
Windows 2000 Professional, or somesuch. Is there a way on that system
to learn what version of java is installed?
Linj isn't available for FreeBSD yet.
Sigh. (Both java and CL are platform independent, so I wonder why Linj
can't be ported easily here?)
> From: "Alex Kay" <me*@spam.not> Cookie is in javax.servlet.http
I'm looking at: http://java.sun.com/j2se/1.4.2/docs/...w-summary.html
but I don't see any mention of ...servlet..., guessing: http://java.sun.com/j2se/1.4.2/docs/...e-summary.html
no mention there either, also none here either: http://java.sun.com/j2se/1.4.2/docs/...e-summary.html
Ah, I looked in Enterprise Edition, and found it: http://java.sun.com/j2ee/1.4/docs/ap...w-summary.html http://java.sun.com/j2ee/1.4/docs/ap...e-summary.html
Unfortunately that's not free, and it deals only with the server end
which is the other end from what I'm wishing to program.
On the off chance my ISP has j2ee, I tried to import it, no it fails:
Package javax.servlet.http not found in import.
As I understand it, what I need is a static variable that holds a jar
full of cookies (or a local variable I keep passing around everywhere),
whatever the server has sent me so-far, a method that puts new cookies
into the jar when parsing the header from the server, and a method that
compares my next request URL with the cookies in the jar and transmits
all appropriate cookies with my request, right? If I ever get the
energy, I'll just have to write it from scratch using CL...
> From: ol****@plohmann.com (Oliver Plohmann) The major advantage of Java, C, C++, Pascal, etc. over Lisp is that
solving anything that can be solved with an iterative solution easily
is easy. To me that's the real advantage ...
That's the advantage of LISP! In those other languages, if you have a
linked-list, or vector (one-dimensional array), or other sequence of
data, origSeq, and you want to process each element in sequence, and
build up the list of results, resSeq, you need to do something like
this (this is Java, the easiest of those non-LISP languages to use):
Enumeration e = origSeq.toEnumeration();
Queue q = new Queue();
while (e.hasMoreElements())
q.push(processData((sometype)(e.nextElement())));
New restype resSeq = QueueToResSeqType(q);
(For some appropriate toEnumeration method, some appropriate type of
data you are handling, some processData routine you want to use, and
some appropriate QueueToResSeqType method for converting to the kind of
sequence you want at the end.)
In CL it's this easy:
(setq resSeq (map 'resSeqType #'processData origSeq))
And who says LISP has too many parens!! Java has more!!
I once took a Lisp class when I was studying. I was quite curious
about Lisp. Then a programming task was given that would have been a
peace of cake when solving it with an iterative approach. Looking for
a recursive stack-based solution for Lisp caused big headaches. Since
that day I was not that interested in Lisp any more.
I feel sorry for you having suffer such a droid of a teacher. But he's
not alone. Most books give really stupid examples of recursion, such as
factorial and fibonacci. Factorial isn't too bad, because if you don't
use the regular definition but instead carefully code it to be tail
recursive, then on some compilers the generated code is essentially a
tight iterative loop. But recursive factorial without a cache is
totally stupid because it's exponentially slower than iterating to
build a list of previous results, or even rotating three local
variables. Your instructor should have come up with some example where
recursion is *much* easier than doing it using an iteration loop and a
state machine with an explicit stack. For example, given a multi-level
list, full of strings, replace all occurances of the 'f' word with
"(expletive deleted)". OK to copy all structure so nothing except the
strings are shared between original and result.
(defun replace-naughty-words (naughtyWord listStructure)
(cond ((consp listStructure)
(cons (replace-naughty-words naughtyWord (car listStructure))
(replace-naughty-words naughtyWord (cdr listStructure))))
((null listStructure) nil)
((not (stringp listStructure)) (error "Not valid structure"))
((string-equal listStructure naughtyWord) "(expletive deleted)")
(t listStructure)))
Nah, that's too hard for a beginner. I'll have to think of something
easier. OK, how about this: Given a positive integer, if it's larger
than 9 then break it into two approximate halves and then if either of
those numbers is larger than 9 break again etc. until all the pieces
are less than or equal to 9, and express these partial sums as lists.
For example:
27 -> (13 14) -> ((6 7) (7 7))
(defun split-past-9 (n)
(if (> n 9) (list (split-past-9 (floor n 2))
(split-past-9 (ceiling n 2)))
n))
tell me why recursiveness and non-destructiveness in Lisp is such a
holy thing
Your question is based on a false assumption. Recursiveness isn't holy,
it's just a useful way to decompose many kinds of problems that branch
in an unlimited number of directions. Non-destructiveness is useful
too, but again not holy. If you want more than one process, or more
than one time in a single process, to look at the same data, it helps
if one process or one time doesn't modify the data causing the later
process or time to see the modified data instead of the original when
it was supposed to see the original. You can get around this by making
a deep copy of the data structure, and handing a different copy to each
process, but if only a few changes are going to made, and most of the
structure is the same before and after, this wastes a lot of space
compared to sharing everything that didn't change. But it's a design
decision which way to go for any given application.
How would you write a deep-copy/clone function/method without recursion
anyway? If there are only a fixed number of levels of structure, you
can write a separate function for each level. But if the number of
levels deep is unlimited, that doesn't work, and you need the hassle of
using a stack to emulate recursion yourself, or just write the
function/method recursively in the first place.
By the way, the right way to demonstrate a recursive definition of
factorial is by splitting the product into two sub-products of nearly
the same length, not by splitting a single term off one end or the
other and recursing on all the rest.
By the way, Tower of Hanoi is nicely solved by a recursive algorithm,
but if you can figure out how to do it yourself then there's a nice
iterative demo of it where you cycle around mod 3 manipulating three
explicit stacks representing the three towers.
> From: cs****@news.dtpq.com (Christopher C. Stacy) If he writes a good implementation, why not sell it?
Because there's virtually no market for lisp software. I've never seen
anyone express an interest in purchasing lisp software from random
programmers such as myself. I've written lots of software, much in
lisp, that I'd like to sell, but there's no point in even inquring
about somebody to buy some particular piece of my software with the
whole market virtually non-existant in the first place.
>>>>> On Fri, 25 Jun 2004 17:09:36 -0700, RobertMaas ("RobertMaas") writes: From: cs****@news.dtpq.com (Christopher C. Stacy)
If he writes a good implementation, why not sell it?
RobertMaas> I've written lots of software, much in lisp, that I'd
RobertMaas> like to sell, but there's no point in even inquring about
RobertMaas> somebody to buy some particular piece of my software with
RobertMaas> the whole market virtually non-existant in the first place.
Simply writing your software in Lisp will not make it marketable.
What marketable software products have you produced that happen to
be written in Lisp, and what happened when you tried to market them?
> From: Antonio Menezes Leitao <An************@evaluator.pt> I looked for interval arithmetic, but can't find what I want. My experience is that there are many more alternatives in the Java
camp than in the Lisp camp. Some of the alternatives are crap, of
course, but the probability of finding something that suits your needs
is, IMHO, higher in the Java camp.
So how should I go about searching for something, for example interval
arithmetic, with high probability of actually finding something
suitable?
The syntax is changing and new language constructs are still being
added.
So new source code might not compile under old compiler because it
happens to use some new syntax? Would any old syntax cease to work
under new compiler?
Have you tried to run Java 1.2 on older browsers?
I don't know what that question means. I run java on a computer, not on
a browser. Please clarify the question.
Applets are Java programs intended to run on the browser. Obviously,
the browser must contain a JVM. The problem is that you cannot use
certain language features because older implementations of the JVM
do not implement those features.
So what you really mean to ask was:
Have you tried to run Applets that use new language features, in
browsers that have old versions of the jvm?
No. The only Java-capable browser I've ever used for running an Applet
is Internet Explorer at DeAnza College, and that seems to be a recent
version of IE that had no trouble running my Applet.
On Unix, I
can use the whereis command, which on this FreeBSD Unix shell account
I'm using gives the directory as /usr/local/jdk1.2.2/bin/ so does that
mean we have version 1.2.2 installed here?
java -version
java version "1.2.2"
Classic VM (build jdk1.2.2-FreeBSD:root:2000/11/25-02:08, green threads, nojit)
Thanks. Indeed what we have here is pretty old! But for my class work,
it seemed to work, except when I tried to run a GUI application here,
whereupon compilation ran just fine but a runtime exception occurred
because it was trying to find an X11 server, which of course doesn't
exist here. Too bad java doesn't support VT100 term the way lynx does
for HTML forms.
public class guiH {
public static void main(String[] args) {
JOptionPane.showMessageDialog(null, "Welcome", "Title",
JOptionPane.INFORMATION_MESSAGE);
System.exit(0);
}
}
Exception in thread "main" java.lang.InternalError: Can't connect to X11 window
server using ':0.0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.<clinit>(X11Graphic sEnvironment.java:58)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:124)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvir onment(GraphicsEnvironment.java:63)
at java.awt.Font.initializeFont(Font.java:262)
at java.awt.Font.<init>(Font.java:292)
at javax.swing.plaf.metal.DefaultMetalTheme.<init>(De faultMetalTheme.java:59)
at javax.swing.plaf.metal.MetalLookAndFeel.createDefa ultTheme(MetalLookAndFeel.java:709)
at javax.swing.plaf.metal.MetalLookAndFeel.getDefault s(MetalLookAndFeel.java:713)
at javax.swing.UIManager.setLookAndFeel(UIManager.jav a:363)
at javax.swing.UIManager.setLookAndFeel(UIManager.jav a:390)
at javax.swing.UIManager.initializeDefaultLAF(UIManag er.java:850)
at javax.swing.UIManager.initialize(UIManager.java:92 6)
at javax.swing.UIManager.maybeInitialize(UIManager.ja va:948)
at javax.swing.UIManager.getUI(UIManager.java:559)
at javax.swing.JOptionPane.updateUI(JOptionPane.java: 1318)
at javax.swing.JOptionPane.<init>(JOptionPane.java:12 81)
at javax.swing.JOptionPane.showOptionDialog(JOptionPa ne.java:630)
at javax.swing.JOptionPane.showMessageDialog(JOptionP ane.java:498)
at javax.swing.JOptionPane.showMessageDialog(JOptionP ane.java:478)
at guiH.main(guiH.java:4)
Apparently swing doesn't support VT100 term. I'm not trying to do any
actual graphics, just put up some text in a box. Why can't it put up
something like:
/===== Title =======\
| |
| Welcome |
| OK |
\===================/
with OK currently selected just like in lynx?
All these claims about java being platform independent are hooey!
Because I didn't found the time yet to install a FreeBSD system.
But if java were platform independent, as claimed, you could just
publish the compiled (.class) files and anybody could download them to
FreeBSD Unix and they'd just *work* from the start, right? Ro********@YahooGroups.Com wrote:
Thanks. Indeed what we have here is pretty old! But for my class work,
it seemed to work, except when I tried to run a GUI application here,
whereupon compilation ran just fine but a runtime exception occurred
because it was trying to find an X11 server, which of course doesn't
exist here. Too bad java doesn't support VT100 term the way lynx does
for HTML forms.
public class guiH {
public static void main(String[] args) {
JOptionPane.showMessageDialog(null, "Welcome", "Title",
JOptionPane.INFORMATION_MESSAGE);
System.exit(0);
}
}
Exception in thread "main" java.lang.InternalError: Can't connect to X11 window
server using ':0.0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.<clinit>(X11Graphic sEnvironment.java:58)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:124)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvir onment(GraphicsEnvironment.java:63)
at java.awt.Font.initializeFont(Font.java:262)
at java.awt.Font.<init>(Font.java:292)
at javax.swing.plaf.metal.DefaultMetalTheme.<init>(De faultMetalTheme.java:59)
at javax.swing.plaf.metal.MetalLookAndFeel.createDefa ultTheme(MetalLookAndFeel.java:709)
at javax.swing.plaf.metal.MetalLookAndFeel.getDefault s(MetalLookAndFeel.java:713)
at javax.swing.UIManager.setLookAndFeel(UIManager.jav a:363)
at javax.swing.UIManager.setLookAndFeel(UIManager.jav a:390)
at javax.swing.UIManager.initializeDefaultLAF(UIManag er.java:850)
at javax.swing.UIManager.initialize(UIManager.java:92 6)
at javax.swing.UIManager.maybeInitialize(UIManager.ja va:948)
at javax.swing.UIManager.getUI(UIManager.java:559)
at javax.swing.JOptionPane.updateUI(JOptionPane.java: 1318)
at javax.swing.JOptionPane.<init>(JOptionPane.java:12 81)
at javax.swing.JOptionPane.showOptionDialog(JOptionPa ne.java:630)
at javax.swing.JOptionPane.showMessageDialog(JOptionP ane.java:498)
at javax.swing.JOptionPane.showMessageDialog(JOptionP ane.java:478)
at guiH.main(guiH.java:4)
Apparently swing doesn't support VT100 term. I'm not trying to do any
actual graphics, just put up some text in a box. Why can't it put up
something like:
/===== Title =======\
| |
| Welcome |
| OK |
\===================/
with OK currently selected just like in lynx?
All these claims about java being platform independent are hooey!
I think you are expecting too much there. Java does thrive to be
platform independent. However, Swing is a GUI library, intended to run
in a graphical environment. A VT100 does not qualify. That does not
mean that Java is not platform independent. You should have no problem
running console applications in this environment.
Ray
--
XML is the programmer's duct tape.
> From: Antonio Menezes Leitao <An************@evaluator.pt> You google for it. Type "interval arithmetic java" on google
I already did that several weeks ago.
and you will get several promising links (they look promising to me,
at least)
They looked promising to me too, until I actually clicked on the links
and started reading the details.
- the Brandeis Interval Arithmetic Constraint Solver (with Java
source code)
You need a java-enabled web brower to run the applet.
I don't have any such browser here on VT100 dialup into Unix shell. By
the way, Java Applets don't usually work. I wrote one for a class
assignment and put it up here: http://www.rawbw.com/~rem/Lab7.htm and
it works fine from InterNet Explorer in the computer lab at De Anza
College, but it doesn't work in InterNet Explorer in the instructor's
office, and it doesn't work in the classroom adjoining the computer
lab. (In the latter two places, the main dialog comes up, but none of
the buttons do anything.)
the current version is NOT sound since it relies on Java's underlying
math library which is not proven to be accurate to the last bit.
I.e. they don't really implement interval arithmetic, instead they use
ordinary sloppy floating-point arithmetic for the guts of it, then
pretend it's accurate when running interval constraints on top of that,
so it's not at all what I'm looking for which is interval arithmetic
where it counts to guarantee bounds on results of arithmetic
operations.
- interval.sourceforge.net/interval (a 100% Java, verifiable
implementation of interval arithmetic operations and constraint
contractors for the arithmetic operations and elementary functions
(exp,log,sin,cos,tan,asin,acos,atan,sin2pi,...)
Platforms supported
* RedHat Linux 6.1 on the PC and Macintosh OS X
Note: Porting to other architectures should not be hard. The only
non-portable code is that which deals with setting the rounding
modes!
The only java system I have access to from home is FreeBSD Unix, which
is neither of the above two systems. I have no idea what would have to
be done inside the jvm to set rounding modes on FreeBSD Unix.
Is adding annonymous inner classes a minor change?
No, that's a major sort of thing. If I try to port somebody else's
software that depends on that in a key place, I'd probably have to
rewrite the whole module to get it to work under an old version of
java.
Is adding automatic boxing and unboxing a minor change?
Yeah, it'd be a pain to explicitly box/unbox everywhere the compiler
gives an error message, if there are lots of places, but it's a simple
fix linear in number of such places, so I'd consider it a minor change.
Is adding generic types a minor change?
I don't know what that phrase means in java jargon. I know what
abstract classes and interfaces are, and how you can declare a variable
of the generic class and make it dispatch at runtime. Also I know about
the Object class and how LISP-like no-declared-type programming can be
done by passing everything as Object variables to static methods and
then having the static method do a typecase of the argument to dispatch
to all the specific methods. But I don't know whether the phrase you
used is anything like either of those.
I'm curious: what is your definition for "platform independent"?
If the desired task makes sense on a set of platforms, then the program
or whatever does that task on them all. For example, text-mode Web
browsing makes sense on both GUI systems and VT100 dialups, and indeed
some browsers work on GUI systems and some work on VT100 dialups so a
truly platform independent web browser would make sense, but in any
case using the appropriate web browser for each platform the text-mode
Web pages do indeed work on all such platforms. So text-mode Web pages
are in that sense platform independent. (They even work with
Web-by-email services!) There's no reason applets shouldn't work
everywhere HTML FORMs work, except the people in charge of java haven't
bothered to do that.
The Linj compiler that translates from Linj to Java is written in
Common Lisp and it needs a Common Lisp environment to run. It is the
Linj compiler that is not platform independent because binary Common
Lisp code is not platform independent.
Oops, sorry, in all this discussion of java classes that people say I
can download and run anywhere, I forgot Linj isn't java code. But if
you generate fasl files and then load them into a CL environment,
although the contents of the fasl files themselves are dependent on the
CPU, the process of making them is system independent (compile-file
...) so if you avoid calling anything from the SYSTEM package, if you
stick to making ANSI CL calls, it should be easy to make Linj run on
any ANSI-compliant CL system. I guess I'm overlooking something. This thread has been closed and replies have been disabled. Please start a new discussion. |
