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

[Alessio Stalla]

Pollyanna much?





Yes, and meanwhile at Mission Control, you just trigger the final
pre-orbital burn of the hypergolic propellants at max-Q and that's that.

Remind me NOT to ever trust you with a multi-million-dollar satellite
payload.



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.

Hmm, not really. The Java equivalent of that defpackage form would be:

package my.package;
import cl.*;
import foo.*;

repeated in every file that is in package "my.package" and uses
packages "cl" and "foo", while in Lisp you define the package once and
then you use it with

(in-package :my-package)

and that gives you all the external symbols in my-package, cl and foo
accessible without qualifiers.

A.

 

[Kenneth Tilton]

Kenneth Tilton wrote (no he didn't):

That was not me, that was Gosling and Steele who designed Java around
that assumption.

Java myth #6! "Java programmers are incompetent".


Oh wait, it looks like Java myth #6 is starting to be questioned by the
lispers. Perhaps a harbinger of bigger changes to come?

You missed my point that Lispers know all these other languages, meaning
we are you only we have been saved by finding Lisp. COBOL, FORTRAN,
BASIC, C, C++, Java, Python, Ruby, Perl -- you name it, we know them and
have succeeded wildly with them in big serious projects. If the ALU had
not managed to erase The Road to Lisp from written history I could point
you to the stories of how Lispers found Lisp. A few were born into
Righteousness because they attended MIT or CMU in the sixties, the rest
found it because they were great programmers but knew the languages
above were holding them back, that there had to be a better way.

The compiler spends all its time complaining about our code. Turnabout
is fair play.

More seriously, the language can use improvement, and maintenance, and
that requires criticism and a realistic outlook.


What, she spent a lot of time complaining about Java?

No, she could have used improvement and maintenance but I put up with
her for ten years before switching to a Cherry 2000.

How rude!

I can imagine you complaining to the fireman carrying you out of the
burning building that he did not knock before coming in.

hth, kzo

 

[Pascal J. Bourguignon]

I hate machine-generated code.

And rigtly you should! Machine-generated code is what will put you jobless.

I hatehateHATE having to *maintain*
machine-generated code.

Well, be happy, you won't have to maintain machine-generated code, the
machine will do it itself.

 

[Pascal J. Bourguignon]

Such a pain, when Java lets you just go

public class MyWhatsit {
@Override
public String toString () {
return "I'm a MyWhatsit!";
}
}

sticking this in your own namespace and not monkeying with any other
code anywhere (either manually, or by running some sort of
code-generator), yet if a MyWhatsit is subsequently passed to
e.g. String.valueOf(Object), out pops "I'm a MyWhatsit!".

It ain't real polymorphism until you can do that, *without* scribbling
outside the lines around the box your code is in.


Duck-typing? Well, it beats no typing at all I suppose.

Eh, wait a minute, you'd write the four method definitions and then
run that code-generator thingy to generate the new versions of the
dispatch tables.

Er, how does that code-generator resolve conflicts again? If someone
else makes a class, also calls it Complex, implements it differently
(r-theta instead of x-y say), and writes methods with the same four
names? Does it use the package the Complex class is in to keep the two
versions of each separate?

You're ridiculous! Go learn some lisp before puting yourself to such a shame.

 

[Pascal J. Bourguignon]

MY point, which remains unaddressed, is that there are three ways to
deal with a commonly-desired support method:

1. The vendor puts it in the system class. No problemo.
2. Everyone rolls their own. Ugh.
3. A third party library puts it in the system class.
Whereas the vendor would create an automatic standard,
absent this, most likely multiple third party libraries
would develop to do the job, and would each do it a bit
differently. Code using one and code using another one
could not typically be combined without problems.

It has already been addressed. There are other ways. We pointed out
that CLOS doesn't work like that.

- in CLOS, methods are not put in a class.

- in CLOS, you can add methods dispatching on your own classes to any
generic function.

- in CLOS, you can redefine methods at will, but you're a big boy and
expected to know what you're doing. So if you want to replace a
method defined in a library, you always can do so, for the better
good of your program.

Beyond that, I won't give you a CLOS lecture here, just go learn
Common Lisp, if you want to stop behaving like a fool.

 

[Stefan Ram]

- in CLOS, you can redefine methods at will, but you're a big boy and
expected to know what you're doing. So if you want to replace a
method defined in a library, you always can do so, for the better
good of your program.

In production environments, this might have security implications.

For example, it allows to inject one's code into clients of those
libraries.

 

[Pascal J. Bourguignon]

You're now claiming it has supra-Turing capabilities? What's the
bonus? Halting oracle? True-analog operations? The downside being:
what's the hardware requirements? I don't have a quantum computer over
here, after all, just a few ordinary Pentium workstations.

No, I mean simple things, such as doing additions or multiplications.


[pjb@galatea :0.0 tmp]$ cat add.java
class Add
extends Object
{

static public void main(String[] args)
{
int tt=2100000000;
System.out.println("2,100,000,000+2,100,000,000 = "+(tt+tt));
}
}

[pjb@galatea :0.0 tmp]$ javac add.java && java Add
2,100,000,000+2,100,000,000 = -94967296

[pjb@galatea :0.0 tmp]$ clisp -norc -q -x '(let ((tt 2100000000)) (format t "~A + ~A = ~A~%" tt tt (+ tt tt)))'
2100000000 + 2100000000 = 4200000000
NIL

 

[Pascal J. Bourguignon]

*breaks down and cries*

The horror, the horror...

You can't win. It's put up with short names, or put up with the
equivalent of the C code some dweebs write that starts with #define
BEGIN {.

Of course I won! You complained about a feature of CL, and I showed
you how you can correct that feature yourself, without patching the
compiler, without having to convince all the other users of that
language that your feature was worthwhile, without having to lobby Sun
Microssystem to change the language and without waiting for them to
issue a new JDK, which would render all the programs developed so far
obsolete.

And I did that easily and quickly in the course of a usenet discussion.




By the way, a few years ago I wrote a few java programs. I tried to
run them again now, and they couldn't run. Different JDK I suppose.
On the other hand, the programs I wrote twenty years ago in Common
Lisp still run nowadays with the new implementations of Common Lisp.


If as a free lance I find it economically wise to invest in CL,
perhaps corportations could do some accounting and realize that it
might be worthwhile to avoid having to rewrite all their software all
the time, just because a new feature has been added or another removed
from Java (or Ruby or Python or Perl, etc).

 

[Pascal J. Bourguignon]

That's a joke, right? One's a full-blown IDE, the other just a text editor.

By the way, I'm using emacs to post these newsgroups articles, to read
my email, to browse the web, to chat with irc and jabber, to do my
accounting, to compute my spreadsheets, to manage my address book, and
of course to develop all my programs, including coding, compiling,
debugging.

Can you do only half of that with your "IDE"?

Copying something from emacs is a good way to give your user base a
headache. Especially if it involves "meta" or (n)curses.

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.

 

[Stefan Ram]

tt+tt (...) (+ tt tt)

Now, imagine both within an inner loop of an image processing
program.

The chance that »tt+tt« can be compiled into a simple machine
instruction seems to be greater than the same chance for
»(+ tt tt)«.

In Java, you pay the performance penalty for
java.math.BigInteger, if you need it. It is harder for the
programmer to write as it is harder for the engine to process.

 

[Pascal J. Bourguignon]

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. It
has
all the functionality that you've described an IDE should have. The
ONE thing it doesn't have is popping out stuff into neat little help
bubbles, but that's cosmetic, not a functionality.

Being able to see a nicely organized workspace with visible context
for displayed informaton, instead of just one page of text at a time
in one window, is "cosmetic, not functionality"? Pardon me if I
disagree.

No pardon for the ignorant!

Here is a typical emacs screenshot: http://collison.ie/code/slime-repl-pics.png
It's as graphic an application as any other.

This is software you expect me to take seriously? And here I'd thought
putting that damn paperclip in office productivity software was asking
for it. (And was proved right.)

What difference between a paperclip and a bubble?

 

[Pascal J. Bourguignon]

What unifying theory would also explain that the majority of practical
desktop and server applications are not written in Lisp? Desktop apps
are mainly written in C, C++, Delphi, and Pascal, with a smattering of
Java; server applications tend to have a C++ core and quite a lot of
Java, along with glue scripts in shell, perl, python, and ruby, with a
smattering of Lisp. Lisp (and Fortran) only become reasonably common
when you look at scientific, engineering, and comp.sci research apps.

The Law of the mean.

It's explained in Jean-François Geneste's "Ainsi marchait l'humanité"
(ed. Bénévent, ISBN 978-2-7563-1103-6).

 

[Pillsy]

Pillsy wrote:

Pillsy wrote: [...]
This, at least, is a potential problem, but in practice it's never
caused me any difficulty.
*deep sigh*

What?

Every time a serious problem is mentioned, you tend to dismiss it with
little more than a hand-wave.

One thing I've discovered is that the things I think are going to be
problems when I start learning a language (or don't know it at all
yet) end up being pretty different from the things that I actually
learn are problems after working with it for a while.
[...]

I'm sure it does, by 1983 standards.

No, I mean, by 2009 standards. It just looks a little crufty.
[...]

Yet earlier someone was saying you'd omit to specify that Complex
inherited from Number.

I might, but if I wanted it to inherit from Number, I could certainly
choose to have it inherit from Number. I'm just not sure that's the
way to go from a design standpoint, though admittedly I haven't
thought about the question a whole lot..

In truth of fact, in Common Lisp, the built-in COMPLEX class actually
does inherit from the built-in NUMBER class.
[...]

Oh, lovely. Machine-generated code you can't even find and read?

Well, I guess that's one way of describing compilation...? Still, it
strikes me as kind of a perverse one.

It's annoying enough to get bison-generated code to play nice
with version control.

Do you version-control object files and executables? That seems like
strange behavior to me.
[...]

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..

The tool I was describing in that paragraph is called... Emacs.
[...]

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

Oh, no, most of the time, you can just use both packages (i.e.,
namespaces) in the package you're working in without having to fully
qualify anything. If there are clashes, you can specify which package
you want to use for a given unqualified name, and qualify the other
one.
[...]

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

Well, like I said, in Lisp we have this thing called a compiler.
Perhaps you've heard of them...?

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.

And I could just slap

(defpackage #:foo use #:cl))

at the top of mine.

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.

I know what potential risks. The potential risks are that something
could go wrong when you try to print an instance of MY-WHATSIT.
[...]

That was you! It's your own previous post you contradicted up there by
putting explicit subtyping declarations into some of your example code.

Yes, it was. Whether you decide to inherit or not is a matter of
choice.
[...]

Like a C++ vtable, then, except that you (or a bug in your code) can
screw with the vtables for objects from the standard library, the
vtables for MY objects, ...

Well, no. I could muck with the dispatch tables for the generic
functions in the standard library, but unless we're using a bizarrely
crappy and bug-ridded implementation, that won't hurt you any. The
methods you've defined on YOUR-WHATSIT will be invoked on YOUR-
WHATSIT, the methods I've defined on MY-WHATSIT will be invoked on MY-
WHATSIT, and there won't be any interference between the too.

Cheers,
Pillsy

 

[Pascal J. Bourguignon]

In production environments, this might have security implications.

For example, it allows to inject one's code into clients of those
libraries.

In production environments, with any language, you can modify the
source recompile and have security implications.

Why are you objecting things that are irrelevant to the language?


But if you're particularly concerned with security problems at the
source level, you may be happy to learn that being a meta programming
language, lisp and its macros allow you to define your own domain
specific language with security in mind, and therefore easily have all
your programmers follow automatically the security rules, by using that
DSL instead of bare Lisp by writing:

(defpackage "MY-PROGRAM" use "SECURE-LISP"))

instead of:

(defpackage "MY-PROGRAM" use "CL"))

 

[Pascal J. Bourguignon]

Now, imagine both within an inner loop of an image processing
program.

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

You cannot win.

 

[Pillsy]

Pillsy wrote:

Pollyanna much?

Why do you keep insisting that I believe you instead of my own lying
eyes?
[...]

Yes, and meanwhile at Mission Control, you just trigger the final
pre-orbital burn of the hypergolic propellants at max-Q and that's that.

Well, OK, let's talk about the not-so-general case, where you try to
use two packages that both export the same name.

You'll get an error telling you that you're trying to use two packages
with the same name, and what that name is. Now that the implementation
has stopped you from defining the new package and told you about the
conflict, you can change the definition of the package so the conflict
doesn't exist anymore.

Remind me NOT to ever trust you with a multi-million-dollar satellite
payload.

Why not? You keep insisting I'm a rocket scientist.
[...]

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.

Yeah, except what I've done is equivalent to Java's

package myPackage;
import foo;

If you want to obsess about a few extra characters, have fun.

Cheers,
Pillsy

 

[Stefan Ram]

In production environments, with any language, you can modify the
source recompile and have security implications.

Java allows »Applets« to be executed within a Web Browser.
These programs have limited rights.

Java has a framework to execute Java-WebStart-Applications
or other applications with controlled rights.

The library with the standard classes is called »rt.jar«.

Substitution a custom copy of »rt.jar« has been made hard
by the use of a a digital signature, IIRC.

Therefore, I believe, one /cannot/ modify the sources of the
standard classes, build one's own »rt.jar« and submit this
to a Java installation.

All those security efforts could be circumvented, if an
application could modify standard classes of its environment.

I am not an expert regarding Java security, but this was as
best as I remember it. Maybe people can correct me if I erred
here.

 

[Pillsy]

Yeah, except what I've done is equivalent to Java's

package myPackage;
import foo;

I mean, "import foo.*;" of course, like Mr Stalla said.

I don't know Java all that well. However, if you really like, I can
invent a bunch of terrible problems with the language that you've just
been ignoring all this time due to your exuberant optimism.

Cheers, Pillsy

 

[Lew]

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.

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. 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>

 

[Lew]

YES, this is Emacs, the same old text editor from the GNU that has
gone through 22.1.1 versions to this current incarnation that I use
right now. I can use the mouse to select text, navigate menus, choose
options, etc -- just like Microsoft Word & co. Heck, search and
replace is child's play for this Emacs -- it can do all the same
search and replace stuff with RegExps too. Put that in NetBeans's pipe
and smoke it!

Well, emacs can't debug Java code, but it's still a fine editor. As for
Paul's, er, rather, Seamus's refusal to awaken from his coma, we've seen this
kind of trollishness before. Don't pay it no never mind.

Look, all we're saying is, Emacs today isn't what Emacs was 30 (?)
years ago. It's the same as with IBM. If somebody who had been in a
coma for 30 years heard that I was using an IBM Thinkpad, he'd
probably envision some sort of "padded" mainframe, not a laptop.

Seamus is apparently one of those who refuses to recognize that a program has
changed and modernized over the years. I predict that you will never get him
to argue about emacs in terms of its modern feature set; instead he'll grip
with white knuckles preconceptions about a version not seen since the
Pleistocene. I do hope I'm wrong, however, and that he will have the decency
at least to discuss the same software that you are. It could happen; I've
been wrong before.