Re: Seeking computer-programming job (Sunnyvale, CA)

[Lew]

Just because something isn't in the ANSI CL standard doesn't mean it's
in use by the CL community. Some of the commercial implementations
have their own graphics libraries, and there are several cross-
platform graphics libraries as well. Just google common lisp graphics
to see a sample of these.

"Seamus"'s point is especially weak considering he's been a proponent of Java
in this thread, a language which in and of itself doesn't "assume" any
graphics at all, but depends entirely on an API library to provide graphics
features. Sure, that library is included with the developer's kit for the
language, but it's not part of the Java language standard itself.

Seems like "Seamus" is the one being "cute, all things considered".

 

[Lew]

"Seamus" has his facts wrong.

It didn't drive Georg Cantor mad, and there is no such repute. He was
depressed by the hostility of certain critics and likely suffered from bipolar
disorder; it was the seemingly paradoxical nature of his own theories that
engendered the harsh criticisms from some of his contemporaries.

<http://en.wikipedia.org/wiki/Georg_cantor>

Cantor himself knew that the paradoxes of set theory, including the one for
which he is the eponym, are "not actually contradictory but merely indicative
of a mistaken intuition".

<http://en.wikipedia.org/wiki/Cantor's_paradox>

The "reformation" of mathematics didn't in any way avoid "inconsistencies like
that"; it formalized the statements and the conditions under which they could
or could not be (dis)proven. That reformation was itself in large part
furthered by Cantor's own work.

Nahhh , certainly not half of mathematics , just some techical
details in set theory.

"Seamus" needs to research his facts.

 

[Lew]

Well, "Seamus" invoked Godwin's Law here. This post got through before my
plonk, but it sure makes me glad I've started "mass kill-filing" him already.

And now "Seamus" goes all potty-mouth on us. He must really have some logic
behind his points for him to do that, eh?

 

[Lew]

Well, let's see...

(defpackage #:my-package
use #:cl #:foo))

Two lines. 42 characters (not including internal linefeed and
indentation). Nesting depth of brackets: 2.

import foo;

One line. 11 characters. Nesting depth of brackets: zero.

That is such an irrelevant comparison.

 

[Lew]

I don't know why you keep mentionning ncurses. emacs is a GUI
application like any other, it has menus, toolbar, scrollbars, pop-up
dialogs, and runs with any window manager the host system provides,
such as X, Aqua or whatever they have on MS-Windows.

"Seamus" is fond of the intellectually dishonest technique of arguing about a
25-year-old version of the product as if it disproved anything about your
claims regarding the modern world. I don't think you'll be able to get him to
admit publicly that emacs is a GUI product or that it's as flexible as it is.

 

[Frank GOENNINGER]

http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf

You cannot win.

Oh, I bet they don't bother reading it. It may be too much to take for
them. I really *pray* for making them read this paper ...

 

[gugamilare]

On May 15, 6:25 pm, (e-mail address removed) (Pascal J. Bourguignon)

Apparently, gugamilare would.

Stop saying that already! I wouldn't! What I wrote was just
misinterpreted, what I really meant is what folks already said: I hit
three keys n my keyboard and a new buffer is open with the
macroexpansion! I just had to leave so I couldn't say it, but you
should take the other Lisp folks' word when they said what I really
meant.

Sorry to make this personal, but you really look like a stubborn 6
years old kid on your argumentation because you don't have a CLUE
about how Lisp works. It is impossible to have a normal discussion
with you folks. You REALLY should EITHER learn Common Lisp or scheme
RIGHT NOW so that you KNOW what you are talking about or STOP POSTING
HERE!

 

[Pascal J. Bourguignon]

just trying to point out the strength, flexibility, and, despite your
preconceptions about a language second only to FORTRAN in its age,
modernity of Common Lisp.

LISP was "originally specified in 1958". [1] ALGOL 58 was specified in
1958. [2] It may be that LISP is third, not second, in age among
third-generation languages.

Common Lisp didn't appear until 1984. [3] Claiming that it's "second
only to FORTRAN in its age" is disingenuous.

Not if it has been designed with ascendent compatibility and it's
still able to run programs that ran on LISP.

http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html


Works on LISP started in 1958, but the first paper "specifying" it was
AFAIK AIM-8, dated March 1959.

Lisp today resembles LISP of 1958 about as the C-ish languages and
Java of today resemble ALGOL of 1958 and as Fortran today resembles
the FORTRAN of 1957.

No. You can basically run the programs written in AIM-8 LISP in
Common Lisp. You need very little "glue".

The semantics are different in details, but a "normal" lisp program,
ie. a program that doesn't mess with implementation details will
mostly run the same in Common Lisp as in the first LISPs.


After all, you cannot have it both way, complain about CAR, CDR, CONS,
COND and LAMBDA, and imagine that programs using these old operators
don't work anymore.

The modernity to which you refer is the result
of evolution and significant changes to the language.

[1] <http://en.wikipedia.org/wiki/Lisp_programming_language>
[2] <http://en.wikipedia.org/wiki/ALGOL_58>
[3] <http://en.wikipedia.org/wiki/Lisp_programming_language#History>

There are indeed some significant changes in the internal semantics,
eg. the introduction of lexical closures.

But otherwise Lisp grew mostly by adding layers and staying compatible
with the previous iterations. Common Lisp in particular was designed
to be compatible as much as possible with all the lisps that existed
at that time.

For example, one significant late addition, the CLOS, was implemented
at first as a library implemented in CL, and strongly inspired from
the various older object systems.

This is an important characteristic of Lisp, because it means that
Lisp programmers (not Lisp designers) may augment and morph the
language themselves. If a new programming paradigm appears it can be
implemented as a library by anybody and once a concensus appears, it
may be standardized (but we don't lose much time in standarizing
anyways, because it's enough to have this Common Lisp core
standardized, all the rest being add-ons).

Which doesn't prevent implementers to modify their implementations to
take into account these new features that are implemented as libraries
at first, if they can justify the cost by increased performance.
Nowadays, CLOS taken into account by the compiler and produce efficient
code.

 

[gugamilare]

On May 16, 7:46 am, Series Expansion <[email protected]> wrote:

[Some attributions are missing. Sorry.]

Do things like have a pack of THINGS, rather than a pack of strings.

Paul Graham repeats often, for good reason, that one of Lisp's great
strengths is its flexibility. You can have a heterogenous list and
Lisp won't blink.

Series mentioned some Java myths being perpetuated in this thread: Java
is slow, Java lacks reflection, Java isn't Turing complete. Well, this
seems to be another one: Java doesn't have heterogeneous lists.

Heck, prior to version 5 it didn't have NONheterogeneous lists.

Sheesh!

Are you stupid or what? He didn't even mention the word Java. He is
saying what neat features Lisp has. This discussion is about LISP.
This discussion is NOT about Java's lack of something.

 

[Series Expansion]

Lisp macros are much less dangerous than C macros, they're much more
powerful, and they're much easier to write.

Wow, This is like hearing some air force dude say "Nukes are much less
dangerous than C-4, they're much more powerful, and they're much
easier to use".

Be afraid. Be very afraid.

For another, they work on the syntax tree, instead of just doing
text substitution.

Sounds like they're less powerful and slightly less dangerous then,
rather than more powerful and a lot less dangerous.

 

[gugamilare]

You assume people are using some particular tool, with a fairly decent
interface, that I ain't never heard of. From all indications, a straw
poll here would show most of the other lispers to be using emacs or
something else equally primitive, though, and there might also be issues
with getting such a tool to work with different dialects of Lisp reliably..

Guess what? This IS a feature of Emacs + Slime - and I have used this
feature many, many times. You can assume EVERYONE here uses Emacs +
Slime, because the people who don't will say otherwise - since Emacs +
Slime IS the "standard" way to program in CL - not the only one, but
the most used one.

Limp. Very limp.

Such a shame what a strange reaction people who never learned CL have
when they hear about what it is possible to do with it.

Fully-qualifying the fuckin' names! What the hell else could I be
referring to?

You really NEVER have to do that, and, even when you do have to, it is
using much letters than you might be thinking about now.

Let me guess: no MANUAL code generation. Something in the toolchain does
it for you.

That's not quite the same thing. And there's no namespace-related stuff
in your code. OK, there was none in mine, either, but you can just slap
a "package foo;" at the top of it. Whereas yours requires you to
defmethod the pre-existing, in some widely used namespace, print-object
method, with who knows what potential risks if you screw it up.

Oh yeah, I forgot: you're perfect and simply will not ever screw it up.
Ever.

You bet. Just like you won't screw anything up with pointers (which,
believe me, are much more dangerous than this). You insist in this
thing of screwing everything up. With manual pointer manipulation
(and, not the case of Java, but handling allocation and dis-allocation
of memory) is MUCH more dangerous than ANYTHING in Lisp. Believe it or
not.

 

[Pillsy]

Wow, This is like hearing some air force dude say "Nukes are much less
dangerous than C-4, they're much more powerful, and they're much
easier to use".

You point out one seriously destructive thing you can do with C
macros, I point out that you can't do that with Lisp macros and
explain why, and this is your response?

They let you do what you want in a much more structured way than their
C equivalents, and allow you to use familiar language constructs to do
it instead of introducing an entirely different (and pitiful)
language. How is it surprising that this is both safer and more
powerful?

Cheers,
Pillsy

 

[gugamilare]

Well, let's see...

(defpackage #:my-package
   use #:cl #:foo))

Two lines. 42 characters (not including internal linefeed and
indentation). Nesting depth of brackets: 2.

import foo;

One line. 11 characters. Nesting depth of brackets: zero.

No, that code you write just once. Then in every file you just put a
(in-package :my-package).
Anyway, you are not seriously trying to argue that, if for one thing
CL use a few more characters, than CL is necessarily bad. You really
don't have good arguments.

 

[Frank GOENNINGER]

Nobody makes an arrogant statement like that on usenet without getting
his nose tweaked.

Nobody.

PUWAHAHAHAHA - Puwaaahahhhahaaahahaaa - Good grief, man, you're talking
to Kenny Tilton.

That much is certain. (I think it might be that rather well-known one
that's paved with good intentions.)

You are so sweet in your childish innocence.

That is arguably correct also, though Perfect Knowledge is ordinarily
considered to be the sole preserve of God. Oh, wait, did you not also
explicitly say you *were* God? I believe you did.

Well, man, I can tell you, he is one of the Lisp Gods, really. Because
he is one of those who are able to help and support others in doing them
good and in doing them bad. (That's a *hint* for you !)

If he says something then you should *listen* - er, read. I have learned
to read twice (at least) when one of the Language Gods (not just the
Lisp Gods, you know) is sending us their wisdom.

Or, do you mean ... are you one of the Java Gods ?

Cheers
Frank

 

[Series Expansion]

Go back and read what the guy said

How rude.

You can make type declarations in Lisp. They look like:
(declare (float x y z)
         (list  a b c))

Let me guess: using macros to try to graft on some sort of poor-man's
type-checking?

That seems to cement the case for static vs. dynamic typing -- users
of dynamic languages end up finding ways to emulate static typing!

Do things like have a pack of THINGS, rather than a pack of strings.

You can have a heterogenous list and
Lisp won't blink. You can have a function that returns some data, or
NIL if the data is unavailable. You can bind the result of that
function to a variable without worrying about types.

Sounds an awful lot like:

import java.util.*;

....

private Map<Object,String> nameMap = new HashMap<Object,String>();

....

public List<String> getNameList (List<?> list) {
List<String> result = new LinkedList<String>();
for (Object o : list) {
String s = nameMap.get(o);
if (s != null) result.add(s);
}
return result;
}

Lists of anything, methods that return some data or null, a variable
that can hold some data or null -- anything missing?

See the above

See above re: faking it.

Variable capture is a useful tool sometimes, for example in anaphoric
macros.

Someone call the doctor -- Adlai has anaphoric macros!

Er -- what are anaphoric macros?

Useful tool? Even if so, variable capture is clearly a dual-edged
sword. Lisp macros? Dual-edged Swiss-army knife, maybe.

Like normal if, when, etc, except that they bind the result of
the test to the variable IT.

Global variables for fun and profit! I bet you guys get ...
*interesting* scaling problems with large projects.

 

[Series Expansion]

Series, PLEASE read my first post in this thread

The first post in this thread was some guy whining that he couldn't
get a job. You'll forgive me if I fail to see how that's relevant to
the Great Lisp vs. Java Debate of 2009.

 

[Lew]

[stuff elided]...

Well, man, I can tell you, he is one of the Lisp Gods, really. Because
he is one of those who are able to help and support others in doing them
good and in doing them bad. (That's a *hint* for you !)

If he says something then you should *listen* - er, read. I have learned
to read twice (at least) when one of the Language Gods (not just the
Lisp Gods, you know) is sending us their wisdom.

Or, do you mean ... are you one of the Java Gods ?

I assure you that "Seamus" is most definitely not one of the Java gods.

 

[gugamilare]

I forgot a few notes:

[1] from page 191 of On Lisp, by Paul Graham
[2]www.gigamonkeys.com
[3]http://www.psg.com/~dlamkins/sl/

By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE.

But can you debug Java code in it?

You bet it can. I don't now how because I don't program in java, but
Emacs has support for many languages, including Java.

 

[Lew]

No, that code you write just once. Then in every file you just put a
(in-package :my-package).
Anyway, you are not seriously trying to argue that, if for one thing
CL use a few more characters, than CL is necessarily bad. You really
don't have good arguments.

He really doesn't. Java is a fine language, really, as is Lisp, clearly,
regardless of what "Seamus" says or does.

He seems to understand the Java language well enough, but he doesn't make a
good apologist for it.

 

[Series Expansion]

Three messages saying this, more or less. Two of them identical and
from you.

Well , I did warn in [1] that the argument and counterargument
have been brought up before , years ago , on comp.lang.python so
you shouldn't be surprised if you encounter here it as well. I
think [1] appeared before you started commenting on macros.

What's this [1] shit? Some creative sort of pseudo-pronoun?

Who gives a crap. I can't figure it out without more information than
you've apparently chosen to provide. Besides, my original point
stands: with functions, you affect whatever calls those functions.
Macros on the other hand can throw a monkey wrench anywhere into the
codebase, if something goes wrong.

Regarding the duplicate post, I thought it looked so nice it just
had to be posted twice  ;-)

Some guy thinks his advertisements for shoes look so nice in cljp that
they just have to posted sixty thousand times.

I have read very carefully
(the parts of) your posts specifically dealing with macros. I'll
comment on some of them right after this but I'm afraid I will
still not acknowledge any difference because you have not
convinced me there is a difference with regards to safety.

Well, I don't know how it can get any plainer than my earlier example
showing that a macro introduced into one bit of a codebase can
potentially quietly redefine system functions used throughout that
codebase. This could happen by accident and cause bugs that were very
hard to track down.

Regarding the coworker issue it is perfectly possible to use
macros to increase your own productivity without your macros
having any impact whatsoever on the code of any of your
coworkers

Macros alter the compiler's behavior; you said it yourself earlier.
That means the potential for them to alter how it treats the
coworker's code. So once your code, including your macro, and your
coworker's code are combined anywhere, boom!

Maybe not a problem if there are separate compilation units that get
linked together later. I could #define something in one of my .c
(not .h) files and it would be local to that file, and not affect how
anyone else's .c files were compiled, and the C linker wouldn't care
when it later linked the .o files. But my understanding of Lisp is
that all of the code is compiled together as a seamless whole, which
means a macro in that code can potentially "contaminate" any
subsequent code, more like a #define in a .h file than one in a .c
file. And I've shown how a buggy one can be dangerous.

Oh and macros do not alter ``how the compiler interprets the
language''.

This is in direct contradiction to your own earlier claim. (And what's
with the funny quotes? Shift key broken?)

By the way, I usually don't make an issue out of people
acknowledging stuff but since you brought it up you have not
acknowledged
<http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/...

I'm not in the UK, so I don't see how anything at groups.google.co.uk
could be relevant here, and I'm not sure I'd even get it. Half the BBC
website doesn't work from where I am, after all.