Re: Is anything easier to do in java than in lisp?
From: Pete Kirkham (pete-kirkham-2004_at_cafemosaic.co.uk)
Date: 05/09/04
- Next message: harry: "Passing by reference, more confusion..."
- Previous message: iamfractal_at_hotmail.com: "Re: abstract naming conventions"
- In reply to: RobertMaas_at_YahooGroups.Com: "Re: Is anything easier to do in java than in lisp?"
- Next in thread: Kristian Elof Sørensen: "Re: Is anything easier to do in java than in lisp?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 09 May 2004 12:35:38 +0100
RobertMaas@YahooGroups.Com wrote:
> If somebody already is content with C, can tolerate the need to write a
> whole program just to test one new line of code, can tolerate the need
> to write your own conversion from input to output format (using the
> built-in printf to print the pieces presumably) to see whether a
> structure was built correctly [snip]
How would you see that in lisp without using the introspector running in
an interactive environment? Is there any real difference between lisp
debugging environments that allow introspection and Java debugging
environments that allow introspection in this regard? Other than there
are very few lisp compilers put out without interactive introspection,
but the standard Java compiler has its debugger as a separate
application, this isn't an issue. Similarly you're out on compile speed
by between one and two orders of magnitude (.5 to 5 seconds, not half a
minute). Loading and compiling a lisp code into ACL on my machine takes
about as long as the same size of Java, the gain is many free lisp
environments allow incremental compile during debug and introspection,
whereas the free Java compiler doesn't. Commercial Java environments do.
There is a distinction between language, environment, implementation and
libraries. Lisp has always shipped with an interactive introspective
environment, it took to the mid-to-late '90s for the compiled languages
to catch up, but they pretty well have. Some Java environments have gone
further, for example supporting backwards stepping debugging so you can
try your code, find it has a bug, step backwards to before the buggy
line, edit & recompile, the continue stepping forwards.
> For example, I have no access to any java GUI here on VT100 dialup into
> Unix shell account.
Nor could you send SMS on a 'wind up' telephone. If your clients want
GUIs, then GUI they must have. If they want to use VT100, use something
suitable for that. But I don't think the ideas in lisp should be
restricted to yesteryears' technology.
> And if you use
> CGI to make your application available to the whole net, your nice GUI
> can't be used, you have to use HTML FORMs, which are just as easy to
> generate and process in LISP as in java.
Or easier. But then there are mutant forms of Java such as JSP that are
intended to make web programming easier by giving the equivalent of
quote and qquote in XML. (though the syntax is so ugly and they mix
abstraction layers so badly I've never used JSP)
There isn't anything like the support for web applications in Lisp than
there is in Java. I haven't used CGI itself for nearly a decade; once
you have anything more than a simple form and want a DB backend, you end
up using a framework. There is some interesting work done is lisp with
continuations for web programming, but continuations aren't part of
Common Lisp, and that's seems more equivalent to the XML based
frameworks that writing pure Java servelets.
> So one way your program can't
> be used on the kind of account I have, and the other way LISP is just
> as good as java, so where's the advantage to java if you want to allow
> everyone to use your program?
Most of the world's populace don't have access to any computer, so you
won't be programming at all by the argument of lowest common technology.
People expect more than can be delivered through an HTML form, let alone
VT100.
> You mean like FIRST (formerly called CAR) and REST (formerly called CDR)?
> You mean like MAP and APPLY and FUNCALL (FUNction CALL)?
Or lambda, which is so old it's ancient Greek. The problem's more one
that there is another abstraction- programmers are taught that a program
is 'like a recipe', so how can a recipe take part of the cookbook as an
ingredient? You have to think different to use lisp, and too many people
are taught to program rather than taught to think.
>From: "Ryan J. Bovorasmy" <zodiac@sdf-eu.org>
>>when I first began learning lisp, it seemed almost backward to me:
>>the way the syntax is set up, you have to write the first thing you
This is similar to a very old argument: programming by query or navigation.
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'
Lisp syntax structures its calls starting with the result (though the
effect is still procedural), Java syntax structures its calls starting
with your arguments.
The best response to this is 'programmers enjoy a challenge'.
On the other hand, the Java syntax fits in with the model of
program-as-recipe, and how real world navigation (which is something
human brains are good at) works. People like working that way, as it
fits in with their congnative model of how the software executes.
> 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.
IDEs also help in the other aspect that keywords do, by showing the
programmer what the names of the arguments are. Not much use on a VT100,
but on any current machine it's adequate.
> In Java if you want to do this same thing with vectors or linked-lists,
> you probably need to write the function yourself, because as far as I
> can tell java.lang doesn't have a class for vectors nor for linked
> lists, and I don't know where else to find something like
> Vector.indexOf or LinkedList.indexOf etc.
Collections are in the utility package, java.util. All the features you
say you need to write yourself are provided. Now-a-days, Java's biggest
advantage is the size of its libraries.
> Suppose you want to find the first or last occurrance of some name,
> ignoring case. In CL it's trivial:
> (search "robert" "Hi, this is Robert Maas here" :test #'char-equal)
> how would you do that in java except by writing your own nested loop
> from scratch?? How come the java API doesn't already include this??
Probably because no one needs to do it that often. You can convert both
to lower-case, but if you wanted fast you'd have to do it as you said.
How come the lisp standard doesn't include {threads, UI, reg ex, ...}?
Nothing is complete, and the standard libraries support the things
people seem to need at the time. As CL isn't case sensitive by default,
is supports case insensitive searches, as Java supports the version of
Unicode that was current at its inception, it has other character string
facilities that CL lacks.
>>2. It makes working with lists easy.
> 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 more
typing, less elegant syntax, but no more cognitive effort.
> And I just noticed: The arguent to indexOf isn't a character at all,
> it's an integer!! At least in CL you can directly pass a character
> object as argument to function that searches for that character within
> a string, instead of coercing it to an integer first!!
The coercion from char to int is automatic; this is a convenience to
counter the effect of having only one set of primitive arithmatic
operations- as all arithmetic is performed as int, you'd have to coerce
back to char if you passed the result of a bit mask etc.. As to whether
exposing such low level details is a good design policy, that's a
different matter, but it simplifies the compiler design, and the
interface to the API is the way it is to make it easier to use. In CL
you'd have to explicitly perform the conversions.
> 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, each with a unique character point value in some encoding,
just like in Java.
If you are comparing function rather than syntax (which is horribly
verbose for this and many other cases), then the equivalent of your Lisp
'find the position of the first occurrence of the integer 65 in the list
...' is:
java.util.Arrays.asList(new Object[]{
new Character('A'),
new Character('B'),
new Integer(65),
new Integer(66),
}).indexOf(new Integer(65))
That will return 2 instead of 0, just like in Lisp.
(normally I'd use a script to generate such lists in Java, with lisp
being the scripting language of choice)
If you want to compare two things, your arguments carry more weight if
you actually compare like with like. Saying things like 'Java is bad
because you'd have to implement lists yourself because I don't know
where the library is in Java' or 'Java development environments don't
support object introspection' isn't going to help your point, only show
you haven't done your research.
Most languages, Java included, are destined to evolve into lisp or
remain niche languages. After 50 odd years, the rate of evolution seems
faster than ever.
Pete
- Next message: harry: "Passing by reference, more confusion..."
- Previous message: iamfractal_at_hotmail.com: "Re: abstract naming conventions"
- In reply to: RobertMaas_at_YahooGroups.Com: "Re: Is anything easier to do in java than in lisp?"
- Next in thread: Kristian Elof Sørensen: "Re: Is anything easier to do in java than in lisp?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
