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

[Pillsy]

That's interesting. It HAS been the experience of C programmers. And
they haven't abandoned macros; they're still alive and well, if used
sparingly.

Lisp macros are much less dangerous than C macros, they're much more
powerful, and they're much easier to write. For one thing, Lisp macros
are defined within a specific namespace, just like Lisp classes,
functions, variables and all the rest. For another, they work on the
syntax tree, instead of just doing text substitution.

There's no equivalent of your

#define malloc(x) 1

example, because there's no support for changing the definitions of
standard functions or macros.

Cheers,
Pillsy
[...]

 

[Series Expansion]

Well, it seems that Common Lisp has already solved that problem.

How? Conforming implementations come with a free crate of aspirin?

They have namespaces (called "packages" in Lisp terminology) that take
care of this problem for you.

So this is absolutely not a headache.

Nothing is if you're on the right drugs when it happens.

Hmmm.  Classpath.  Lisp doesn't have classpaths.  Of course, you do have
the headache of making sure that even code containing such a call, even
if it never executes, won't compile.  So you can't do early testing of
partial implementations.

You can if you comment out the not-yet-reachable bits that refer to
the not-yet-written bits.

And if you want to defend Java, I wouldn't get started on library
dependencies.  I've experienced software combinations where one had to
have multiple versions of a particular library available, and in exactly
the right order in the classpath so that the code would run.

Sounds like what you'll even more easily get with Lisp. Order
dependency among various (deffoo bar baz quux) lines and therefore
files full of such lines. Name clashes. Multiple implementations or
versions of something. Probably, no language can completely avoid such
issues though.

But again, this isn't really a problem in Lisp.  I don't know why you
think it would be.

Maybe because it is inevitable?

 The language just works differently.

Yeah. Keep on saying that. Maybe wishes DO come true.

It's one thing if you have
instanceOfSomeUnfamiliarClass.foo() and obviously need a library
installed, but when code calls non-existent methods on standard
library classes like String, who you gonna call? A google search for
"SomeUnfamiliarClass" might turn up the needed library; a google
search for "String" isn't likely to help much.

[raw flamage]

Ah, and now we get to the crux of the matter: not static vs. dynamic
typing or Lisp vs. Java, but man against man, keyboard clashing
against keyboard. En garde!

In CLOS, objects just encapsulate data.  Period.

Let's set the wayback machine to 1967 shall we, when the shortcomings
of keeping all the data in structs or similar entities, and all the
behavior elsewhere, were becoming painfully apparent as ever-larger
systems were developed, with attendant scaling problems and growing
pains. Then, Ole-Johan Dahl and Kristen Nygaard said "Let there by
classes!" and there was Simula 67...

Lispers are a very interesting clan, it seems. Their main development
tool is a thirty-year-old terminal-mode text editor. Their notion of
an object system appears of an era with peaceniks and Woodstock and "I
Have A Dream". I have to wonder what's in their medicine cabinets, and
whether much of it is legal.

Now for the wakeup call.

The year is now 2009. The seeds planted by Martin Luther's speech took
root decades ago, and we now have an honest-to-god black President
sitting in the Oval Office. Marijuana is still illegal. There's still
a war going badly of dubious morality and motive, but it's not in
Vietnam, it's in Iraq. We have these nifty things called graphics
cards and IDEs now, and the economy is imploding, with climatological
catastrophe looming on the horizon.

I bet to those of you still living in the sixties and seventies, the
above sounds like an opening narration at the start of a bad science-
fiction movie or something, but it's actually real, believe it or
not...

Methods DO NOT BELONG TO CLASSES.  Instead they are organized base on
the function they perform.  Each such "generic function" is a particular
operation.  Methods are added to the generic function to handle
particular argument types (via dynamic multiple dispatch).  So the
methods really belong to the generic function.

Adding methods might be a problem then, if the generic function you
need to edit is in library code you don't control.

And if no such generic function is defined, your lisp compiler will
complain about it.

What? Surely not -- surely it blithely compiles your code, then your
program chokes on some sort of "message not understood" run-time
exception.

Being able to create generic functions that work with objects created by
others (say in some library code you are using) is a nice way to add
functionality that the library authors didn't anticipate.

I'm more concerned with being able to create objects that work with
generic functions created by others. The English language has seven
times as many nouns as it does verbs, and my own experience suggests
that it's much more common to want to add new objects than to add new
methods to a software system, likewise.

Suppose one manufactured hammers in the manner of an object model where
methods belonged directly to classes.  In that case, there would be a
set of operations anticipated by the library designer for these new
hammer objects.  Typical operations would involve things like driving
nails and pulling them out.  Very functional.

Now, suppose we are laying out a picnic blanket on a windy day.  We
might decide that we would like to use a hammer to help hold it down.
But we can't do that with an ordinary hammer, because it doesn't have a
method for anchoring a blanket.  We could only do that if we created our
own specialized hammer-that-can-anchor-blankets subclass, or else if we
put the hammer inside a special anchoring-objects bag first.  The plain,
ordinary hammer can't fulfill this new purpose, because it wasn't
anticipated.

Software systems are very different. You would not try to make a
construction tool function as a weight or similarly; indeed it's hard
to even make the analogy. The need for a hammer above stems from
lacking a dedicated purpose weight optimized for that task, and a
desire not to drive all the way to the hardware store, or home, or
whatever, and back to get one. In a software system, no such
considerations apply: if you need some simple thing like that you can
typically build it or download it without driving anywhere.

And without access to the source code, you can't change this.

You've just made an argument in favor of open source, not one in favor
of Lisp over Java.

Now the real irony in this discussion is that often the most outrageous
claims are made about Lisp, based on ignorance of the basics of the
language design and philosophy.

That's funny, because it seems the most outrageous claims are being
made about Java, based on ignorance. Not only was mention made of
Java's supposed lack of any dynamic features (and of course
reflection, classloaders, the compiler API, and generic containers
were promptly pointed out by Java partisans) but even of its supposed
slowness. Java hasn't been slow for donkey's years, and people like
you are part of why it is having such a hard time living down its no-
longer-deserved bad reputation in that area.

 On the other hand, almost all of the Lisp programmers are a lot more
familiar and often do program in other languages like Java.

You wouldn't think so, to hear the howlers some of them have written
about Java here lately. I think one even insinuated that it wasn't
even Turing-complete?

I suppose one could adopt the view that the Common Lisp advocates have
somehow had their brains warped by the experience, and inexplicably
cling to the view that Common Lisp is nicer to use for many things.  But
perhaps a more rational view is that those people most familiar with
both languages prefer Lisp.  Those people who don't really know anything
about Lisp are the ones that don't like it.  So what unifying theory
could explain such facts.  I wonder.

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.

In any case, there are lots of objections that just display a
fundamental ignorance of the Lisp language.

In any case, there are lots of objections that just display a
fundamental ignorance of the Java language.

 It makes it hard to take the critics seriously when they complain
about perceived problems that JUST DO NOT EXIST in Common Lisp
programming practice.

It makes it hard to take the critics seriously when they complain
about perceived slowness that JUST DOES NOT EXIST in Java programming
practice.

And we'll ignore the delusion that strongly typed languages which
compile are therefore bug-free.

I don't think anybody but you ever employed that particular straw-man.

But nobody can deny that there's a big difference between catching 100
bugs after hours of bug-hunting, dozens of debugging prints, and lots
of poring over stack traces and watched-variable logs, and catching 50
bugs that way and 50 instantly when you click "build" (or even when
you write the separate buggy lines of code!).

 

[Series Expansion]

Good sir I take offense!
My code base is immaculate!

Sure, sure, that's what they all say.

Compiler actually can see it, if I declare my types, and it happens to
be a type error.

What are you coding in? Java? Or maybe something like OCaml, given
your probable predilection for more functional-style languages.

Obviously not Lisp; how can the compiler catch a type error in code
that has no types, just list atoms?

However, if I am writing a function that at runtime writes and
compiles another function;
I won't know that the secondary function has an error in it until I
generate and compile it.
But this really demonstrates to me the importance of testing your code
*before* you ship it, rather than the evils of meta-programming.

Think of static typing and the compiler's type checking as a kind of
automatic testing of one aspect of the design that inevitably has full
code coverage.

It's no substitute for doing further, less-automatic testing, but it's
part of the same basic philosophy.

But that has nothing to do with dynamic typing...(Aside from the fact
that it is very hard (most likely impossible) to do this sort of stuff
in a statically typed language).

Do what sort of stuff? Accidentally wind up with a Float in a pack of
Strings? Why would you want to?

All of this is actually orthogonal to compiler checks.

No, of course not; without static typing, the compiler has no type
information to use when checking anything, since as far as it knows,
any variable might hold any value of any type whatsoever.

(Aside: I don't understand everyone's obsession with type errors! I
rarely make them!)

Or, perhaps, you have made few of them *that you know about*. Of
course, you might know of a lot more if your compiler detected them
all.

No, *YOUR* code base has 50 bugs.

Don't try to foist your buggy, machine-generated code on me. I want no
part of it. Here -- you keep it.

This is a good example of what would happen if I were using Java (or
any statically typed language; I believe) to do meta-programming.

It's a good example of what would happen if you were to do meta-
programming, period.

At least Java meta-programming doesn't have the bane of macro-based
meta-programming: variable capture.

I fix the one bug and go on my merry way,
living my life of decadence and excess,
lucky should I live to see the year 2040!

If you live to see 2040, you'll probably have been reimplemented on an
artificial, nanotechnological hardware platform. And ported to Java.

 

[Series Expansion]

My Lisp IDE can do all this.

It sure beats the text editors most of the other lispies here are
apparently using, then.

In combination with my Lisp implementation of choice, it also shows
undefined functions, undefined variables, and even type errors

What? No! That simply isn't possible. How can it show type errors?
Function parameters and suchlike have no types in Lisp. I suppose it
could try some sort of type inference, but then we'd have a statically-
typed funcional language a bit like OCaml, not Lisp anymore.

Yes, it's Emacs.

You just described a bunch of features that require a GUI to present
usably. I hope you realize that.

 

[Adlai]

What are you coding in? Java? Or maybe something like OCaml, given
your probable predilection for more functional-style languages.

Obviously not Lisp; how can the compiler catch a type error in code
that has no types, just list atoms?

Go back and read what the guy said: "... if I declare my types,"

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

Once you have them, a good compiler (i.e. any of the commonly used
implementations, including many open-source ones) will start to give
warnings when you start to write type-buggy code.

Do what sort of stuff? Accidentally wind up with a Float in a pack of
Strings? Why would you want to?

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

No, of course not; without static typing, the compiler has no type
information to use when checking anything, since as far as it knows,
any variable might hold any value of any type whatsoever.

See the above re: declarations.

It's a good example of what would happen if you were to do meta-
programming, period.

At least Java meta-programming doesn't have the bane of macro-based
meta-programming: variable capture.

Variable capture is a useful tool sometimes, for example in anaphoric
macros. Like normal if, when, etc, except that they bind the result of
the test to the variable IT.

Java is meta-programming for JVM bytecode. Lisp is meta-programming
for Lisp. By being a meta-language for itself, Lisp allows you to
express a huge variety of concepts. Your imagination is really the
only significant limit, second maybe to carpal tunnel -- and you
barely get any of that because macros shrink source code.


- Adlai

 

[Adlai]

It sure beats the text editors most of the other lispies here are
apparently using, then.


What? No! That simply isn't possible. How can it show type errors?
Function parameters and suchlike have no types in Lisp. I suppose it
could try some sort of type inference, but then we'd have a statically-
typed funcional language a bit like OCaml, not Lisp anymore.


You just described a bunch of features that require a GUI to present
usably. I hope you realize that.

Series, PLEASE read my first post in this thread, in reply to Seamus
MacRae. I describe the difference between the Emacs you're thinking of
and the Emacs that we use today.

 

[Spiros Bousbouras]

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.

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

None acknowledging the difference between merely defining named
functions and actually *altering how the compiler interprets the
language* (or, and this came up elsethread, altering a system class to
add idiosyncratic new methods).

My knowledge of CLOS is rudimentary so I've stayed out of that
part of the discussion and I have only skimmed through posts
commenting on it. I can assure you 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.

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: you write your functions using macros or whatever
else you find increases your productivity and you only expose an
interface to other people. I'm not saying that macros should
only be used by one person and not a team, I'm just pointing out
that even in such a scenario they will have a positive impact
while at the same time minimising the dangers you seem to think
are present.

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

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/co...1a8856b074/4ef5dfa2fc6d906f?#4ef5dfa2fc6d906f

[1] <
http://groups.google.co.uk/group/co...1a8856b074/7385151a2ea1e6a9?#7385151a2ea1e6a9

 

[Series Expansion]

Apart for emacs, I know of no editor able to do the syntactic analysis

Text editors don't do syntactic analysis. They deal strictly in ASCII
strings.

that is needed to match the boilerplates you have to have in non-lisp
programming language, and do the needed substitutions.

But in practice it's too hard to do, so you end doing the updates
manually or mostly manually anyways.

Well, that's emacs for you. Those of us using a real IDE don't have
these problems.

You are so confused!  The macros are not expanded by the editor!  They
are compiler hooks

Yes, normally, but the debugging procedure just described involved
changing some particular bit of macro-using code, in the text editor,
to what it becomes after the macro transforms it, in order to get a
clue as to why the macro wasn't doing the right thing there. If that
change isn't undone afterward, it will no longer reflect subsequent
changes made to the macro (including the bug fix!) and that's going to
cause problems.

The only thing you have to do when you change a macro, is to recompile
the functions that use it.  This is easily done automatically by
putting macros in a separate source file and defining correctly the
dependencies of the other files.

Manually defining dependencies? How 1980s. I haven't done that since
God finally invented automake. And these days I use ant. What a world
of difference that makes!

(Guess what -- automake turns 15 this September! I think I'll order a
birthday cake for it, though I won't be able to share it with it.)

"Go to definition" can be implemented using classical tags, like for any
other programming language.

I want to spend my time programming my actual project, not programming
an editor.

a simple editor like emacs

*sputter* What?!

Oh Christ, I've got Coke running down my screen, gimme a minute to
wipe it up.

And don't do that again! Sheesh.

Why would we do that?  That would mean shooting in one's foot.  Nobody
would do that.

Apparently, gugamilare would.

In your dreams only.

I am fairly certain that I was not imagining the post I replied to.

In really, such a mission-critical system was developed by Paul
Graham, and sold to Yahoo for a fortune, which used it without such a
catastrophe.http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt

"This style of development fits well with the rolling releases that
are possible with Web-based software. It's also a faster way to
get software written generally."

Releases. Sounds like they didn't hack the live web-server on the fly,
but kept a separate test-monkey, though with fairly frequent updates
to the live version.

Still not an example of what I was talking about, then.

Another example, is the debugging of the OS code of the Deep Space 1
code when it was millions of kilometers from the Earth.  Again, the
modifications were made on a running program without outage, and even
without physical access to computer.http://www.flownet.com/gat/jpl-lisp.html

Modifications first tested on a copy dirtside, no doubt, running on
some NASA emulator against simulated mission parameters.

And what became of Lisp at JPL? Why, it got shitcanned, and now their
Lisp flavor does the lowly menial work of serving the Google ads that
one of my browser plugins (probably written in Java) blocks.

Well probably lisp programmers are smarter.  For sure you make us
think so.

Is there a point here, or just some lashing out at the messenger?

 Is it so hard a concept to make the modifications both in
the running lisp image and in some persistent storage?

Having to make the same changes in two places is a recipe for trouble.

This is actually the normal work flow of a lisp programmer: he will
edit the source file in emacs, type C-x C-b which will ask slime to
send the file to the running lisp image, which updates it.

I find it hard to take seriously any proposed procedure that has "ask
slime" as a step. Or involves emacs.

 

[Series Expansion]

Well not only I'm serriously suggesting that, I proved it.

OK, technically it can't actually NOT be a plus. But it's gotta be a
very, very SMALL plus. And the cost in not-very-modernness ...

Not a tradeoff I'd likely make.

 

[Series Expansion]

Wound up vaporware.

And my point stands.

 

[Series Expansion]

Never happens in Common Lisp.

A hand-wave like this is not an argument. An idealist supposes people
will always do something more elegant than using two pieces of code
together that use incompatible versions of yet another bit of code. A
pragmatist knows that people will throw any two pieces of code
together eventually and having a way to deal with conflicts is
essential.

Example of a piece of software that assumed collisions would "never
happen": Windows 95. Remember DLL Hell?

Example of a piece of software that took the pragmatic approach, after
learning its lesson: Windows XP. DLL versioning and DLLs often kept
with programs, rather than in the system directory where two different
same-name ones would clobber one other, albeit at the cost of
sometimes having several copies of the same DLL in various Program
Files subdirectories.

Another thing you might fondly remember from Windows 95 is the
infamous BSOD. Much less common with XP. Guess why.

 We didn't mention it because the
discussion so far only involved macros, but Common Lisp is a full
featured programming language, and there are tools to solve all the
problems that occured to lisp programmer in the last fifty years.

I'm more worried about all the problems that didn't occur to Lisp
programmers in their fifty years of tinkering with theorem-provers and
AI research in various ivory towers, but that J2EE server admins and
word-processor developers and social-networking site coders and
Limewire hackers encounter every day and have pragmatic solutions for.

 You see, there's a lot of accumulated experience and knowledge, even if
unfortunately it's not spread over a big number of programmer.

Experience and knowledge doing what? Keeping the ivory from getting
dingy? Meanwhile, hackers all over the world have to maintain
systems that run power grids and dispatch 911 calls, serve millions of
customers a second at the bigger e-commerce sites, optimize inventory
management for high-volume bricks-and-mortar businesses, route network
packets, route trucks and buses and taxis and ambulances, and even run
in thermostats and SUV fuel-injection systems and bomb-sniffing
robots.

So in this case, the notion of PACKAGE, which coarsely  correspond to
that of C++ namespace is put to use, and there's never any collision
problem between two CL library because they live in different
namespaces.  Of course, there may always be some collision on the
usage of some global resource,

such as a pre-existing system class or generic function or whatever
that needs modifying,

but at least names are not such a global resource.
Hmm.


And even in this case, it's rather trivial to load one version of the
library, and to _rename_ (at run-time) the packages of that version,
before loading the other version.

How crufty.

Frankly, I must say that I find your objections rather silly...

Not as silly as that thing on your head. You should wear a baseball
cap or something.

Indeed why?  When you can use a lisp compiler, and just patch it at a
high level with a few macros.

The Java compiler, meanwhile, doesn't need patching. It just works.

Indeed.

Well, there you go, then.

 In lisp, it's  easy to do things hard to do in other
languages

Useful things, though?

and it's possible to do things that are impossible in other
programming language.

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.

 

[Series Expansion]

And you don't HAVE to use implementation-standard names.

(defpackage "MY-LISP-WITHOUT-CAR"
   nickname "MY-LISP")
   use "CL")
   export "CONTENT-OF-ADDRESS-PART-OF-REGISTER"
            "CONTENT-OF-DECREMENT-PART-OF-REGISTER"))
(do-external-symbols (sym "CL")
  (unless (member sym '(car cdr #|...|#))
    (export sym "MY-LISP-WITHOUT-CAR")))
(setf (symbol-function 'my-lisp:content-of-address-part-of-register)   (symbol-function 'car))
(setf (symbol-function 'my-lisp:content-of-decrement-part-of-register) (symbol-function 'cdr))

and now, in your programs instead of writing:

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

you will write:

  (defpackage "MY-PROGRAM" use "MY-LISP"))
  (in-package "MY-PROGRAM")
  (content-of-address-part-of-register   (cons 1 2)) ; --> 1
  (content-of-decrement-part-of-register (cons 1 2)) ; --> 2

What we've done here is to define a new language, one which is almost
like Common Lisp, but where car and cdr are actually named
content-of-address-part-of-register and
content-of-decrement-part-of-register.

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

 

[Series Expansion]

I was referring to development time, not runtime.

So, now the "Java is slow" myth is having new life breathed into it by
claiming it makes *development* slow.

I guess there's no stopping people from believing the worst about
Java, if they're really determined to do so...

 

[Adlai]

Text editors don't do syntactic analysis. They deal strictly in ASCII
strings.

Yeah, and you read the ASCII string and do syntactic analysis on it!

Look, I don't know how Emacs is built, but I do know that when I'm
working on some Lisp code, there's a little info bar that lets me know
the syntax of the form I'm editing at the moment. Yes, that's right,
my TEXT EDITOR is able to sniff out the syntax of what I'm typing in,
figure out which ASCII string is the function, macro, or special form
that I'm making a call to, look up the syntax of that form (including
syntax of user-defined forms), and displays that syntax to me. It even
highlights the part of the syntax that I'm currently editing.

Emacs has this power for two reasons (that I know of off the top of my
head):
1) It's written in a dialect of Lisp, which gives it a lot of symbolic
processing power, and
2) I've got SLIME running as well, which enhances Emacs's knowledge of
Lisp, and its functionality.

READ MY DETAILED POST ABOUT SLIME PLEASE BEFORE SPEWING FORTH MORE
IGNORANCE UNTO THE NETS!

Yes, normally, but the debugging procedure just described involved
changing some particular bit of macro-using code, in the text editor,
to what it becomes after the macro transforms it, in order to get a
clue as to why the macro wasn't doing the right thing there. If that
change isn't undone afterward, it will no longer reflect subsequent
changes made to the macro (including the bug fix!) and that's going to
cause problems.

Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
SOURCE CODE.
You've either misunderstood gugamilare (highly likely), or gugamilare
has made some questionable decisions about how he works on his code.

When you test a macro using the MACROEXPAND form, you evaluate that
separately, in a Lisp prompt, or in a separate prompt opened by slime,
the way a normal IDE does. IT DOES NOT EXPAND INTO YOUR SOURCE CODE.
Your source code stays exactly as you left it.

Manually defining dependencies? How 1980s. I haven't done that since
God finally invented automake. And these days I use ant. What a world
of difference that makes!

(Guess what -- automake turns 15 this September! I think I'll order a
birthday cake for it, though I won't be able to share it with it.)

Defining dependencies is a) a piece of cake, and b) something that
macros do for you.

I want to spend my time programming my actual project, not programming
an editor.

That's why we've got SLIME, a huge package of editor customizations
that sets up Emacs into a powerful Lisp IDE. Read my post here if you
haven't already, so that you understand what you're talking about
before you say Emacs can't do syntactic analysis:
http://groups.google.com/group/comp.lang.lisp/msg/af00fe4c6ff30ae8?hl=en

Apparently, gugamilare would.



I am fairly certain that I was not imagining the post I replied to.

Man, give the guy a break. He miscommunicated to you, and now you're
just deliberately sticking to a misinterpretation to wave in our face,
instead of trying to understand our explanations.

"This style of development fits well with the rolling releases that
are possible with Web-based software.  It's also a faster way to
get software written generally."

Releases. Sounds like they didn't hack the live web-server on the fly,
but kept a separate test-monkey, though with fairly frequent updates
to the live version.

Still not an example of what I was talking about, then.

Uh, actually, they did hack the server while it was live. While on the
phone with customers reporting bugs. So yeah, this is EXACTLY what you
were talking about. This is the power of Lisp.

Modifications first tested on a copy dirtside, no doubt, running on
some NASA emulator against simulated mission parameters.

And what became of Lisp at JPL? Why, it got shitcanned, and now their
Lisp flavor does the lowly menial work of serving the Google ads that
one of my browser plugins (probably written in Java) blocks.

Somebody posted this link earlier, maybe you missed it.
http://www.flownet.com/gat/jpl-lisp.html

Here's a quote from that page (under the heading "1994 - 2000": Remote
Agent):

"""Remote Agent controlled DS1 for two days in May of 1999. During
that time we were able to debug and fix a race condition that had not
shown up during ground testing. (Debugging a program running on a
$100M piece of hardware that is 100 million miles away is an
interesting experience. Having a read-eval-print loop running on the
spacecraft proved invaluable in finding and fixing the problem."""

Is it possible to scream "Lisp saved our asses" more loudly than that
does!?

Please read up on SLIME, Emacs, CLOS, and Common Lisp Macros before
you continue posting ignorance!


- Adlai

 

[Series Expansion]

I meant that NetBeans has exactly the same feature as emacs

uh.

Ah.

AAAACHOOOOO!


Oh, I'm sorry. I'm allergic to bullshit.

(I don't think you can find two more different pieces of software than
NetBeans and emacs!)

 

[Spiros Bousbouras]

That's interesting. It HAS been the experience of C programmers. And
they haven't abandoned macros; they're still alive and well, if used
sparingly.

So in other words they have reduced their use and adopted a
collection of guidelines for macro usage which bring the danger
down to an acceptable level. And they tend to consider them a
wart. With Lisp there is also a set of guidelines on how to
construct macros but as long as you follow those (and think
carefully when you decide to violate them) you can use macros to
your heart's content hence Lisp programmers have not reduced
their use of macros. And they consider them one of the parts
of the language to be most proud of.

Core parts of Lisp are well-tested, I assume.

Five-minute quick hacks are another story, and unfortunately, it's in
the nature of macros to potentially interact with practically the
entire code base.

No , macros only interact with the code which uses them in much the
same way that functions only interact with code which uses them.

If you doubt that, think for two seconds about the consequences of
taking any very large C project and sticking this at the top of the
most commonly-included header file:

#define malloc(x) 1

The horror of it is, it will probably actually compile (at least if
the malloc.h header is seen before the one you edited) but it will
bomb with SIGSEGV or otherwise blow up spectacularly when run.

I expect you would get many warnings about assigning integer to
pointer without a cast.

And that's macro mischief in a "safe" (well, type-safe) language.

C is not type safe because it has casts but it's besides the
point. Imagine that C didn't have macros. You go on and change
the definition of malloc() and make it do something it's not
supposed to do. Don't you think that your programme would also
crash or even worse corrupt data? Obviously yes so why is it
that macros specifically cause the problem?

Apart from that you give an example where you use a macro in a
silly manner. You cannot extrapolate from that to when you use
macros in a thoughtful manner.

I can only begin to imagine what might happen (even by accident) with
a macro in a dynamically-typed language.

With a badly-written function, the code that uses that function has
problems. A badly-written macro can throw a spanner into the works
just about *anywhere*. Or, sometimes, just about *everywhere*.

Anywhere the macro is used just like functions. Look, macros are
also functions whose input and output is Lisp code. You seem to
think that if a function's input and output is anything other
than code then it's ok but when the input and output is code
then you reach a whole new level of danger. You don't.

Interesting that people mostly prefer C and Java to assembly, but
mostly prefer C and Java to Lisp, then ...

It's interesting but I'm not sure it's relevant. It would be
relevant if we knew that people made their choice on the basis
of macros and their choice was an informed one. I doubt that
either assumption is a true one. Take you for example: you have
strong opinions about macros but I bet you've never written a
single Lisp macro. May I suggest reading chapter 7 of "Practical
Common Lisp"? It can be found at
http://www.gigamonkeys.com/book/macros-defining-your-own.html
I realise that you probably consider it a waste of time to read
about Lisp macros but it's a quick read and if you take the time
you may find that Lisp macros are not as dangerous as you think
they are.

 

[Little Green Man]

You mean, the source code for a dispatch table you posted is
machine-generated, like yacc output? No wonder it looks like ... well,
what a lay person will probably imagine "yacc output" describes.

Oh, shit. I think you guys may actually be dealing with someone with a
9th-dan black belt in usenet-fu here. Do you see how he subtly, but
quite definitely, retaliates for your earlier insulting comparison of
his Java code to vomit by doing the same to your Lisp code here?

No matter. I'm outta here before it all hits the fan.

 

[Series Expansion]

You have to remember though, that there's not really such a thing as
boilerplate Lisp code. If you need to use some code once, you write it
there and that's it. If you need to use it more than once -- or if you
can conceive of situations in other projects, where you'd need to do
the same thing again -- you whip up a macro, and bye bye boilerplate.

Oh, God. Macros that generate imports and affect namespacing. If
*that's* not playing with fire, I don't know what is.

The beautiful thing about macros is that it's not "machine-generated
code".

You mean, the Lisp machine actually contains little elves that write
the expanded code? I thought that was just a myth!

Unless you're writing wizard macro-defining macros[1], debugging macro
code is fairly straightforward

OH RLY?

with the assistance of macroexpansion tools available in modern IDEs
such as Emacs + SLIME, and a working macro that you'll reuse in the
future is a huge asset.

You know, most people find it hard to take anything seriously that has
"modern IDEs such as Emacs" as a dependent clause.

 

[Spiros Bousbouras]

May I suggest reading chapter 7 of "Practical
Common Lisp"? It can be found at
http://www.gigamonkeys.com/book/macros-defining-your-own.html

That would be chapter 8.

 

[Adlai]

You have to remember though, that there's not really such a thing as
boilerplate Lisp code. If you need to use some code once, you write it
there and that's it. If you need to use it more than once -- or if you
can conceive of situations in other projects, where you'd need to do
the same thing again -- you whip up a macro, and bye bye boilerplate.

Oh, God. Macros that generate imports and affect namespacing. If
*that's* not playing with fire, I don't know what is.

The beautiful thing about macros is that it's not "machine-generated
code".

You mean, the Lisp machine actually contains little elves that write
the expanded code? I thought that was just a myth!

Unless you're writing wizard macro-defining macros[1], debugging macro
code is fairly straightforward

OH RLY?

with the assistance of macroexpansion tools available in modern IDEs
such as Emacs + SLIME, and a working macro that you'll reuse in the
future is a huge asset.

You know, most people find it hard to take anything seriously that has
"modern IDEs such as Emacs" as a dependent clause.

I'm sorry, I was assuming that you could read entire sentences. I'll
try and restate my point in sentence fragments:

SLIME adding power!

.... to old (not) useless Emacs!

Read my post describing SLIME please.

Also, understand that macro code is code that you write. You control
every detail of the code in the macroexpansion. Please check out the
link that Spirol Bousbouras posted to Peter Seibel's chapter on
writing macros, and just glance over it.

That way, you'll be able to discuss this issue and have us respect you
as somebody who tries to fix their knowledge gaps, rather than pity
you as a casualty of groupthink.


- Adlai