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

[Arne Vajhøj]

Software development does not necessarily require much computer power.
An old 486 with DOS 6.22 and DJGPP for C programming does not seem slow.
The editor may seem a bit primitive, but then more thinking and less
typing is usually a good thing.

Appropriate software can help too - an 866 MHz P3 with 256 MB RAM
wouldn't have a hope in hell of running Windows XP or later, but is OK
running most current Linuxes including the graphical desk top. Admittedly
having 512 Mb RAM is better but isn't necessary for a Linux development
box.

FWIW I have just such a machine that's currently running Fedora 8 at a
perfectly acceptable speed. Its my main development box for C and Java,
which is done alongside a variety of servers (Postfix [mail], Apache [web
server], Postgres [RDBMS] and with Seti@Home in the background to soak up
unused cycles).

According to MS it will !

http://www.microsoft.com/windowsxp/sysreqs/pro.mspx

But yes - Linux offer you better trimming capabilities.

Arne

 

[Arne Vajhøj]

http://www.inspiration.com/videos/InspireData

Or if we can agree on considering Clojure to be
a LISP, then Clojure can use Swing. There is
an example on one of the main pages
(http://clojure.org/jvm_hosted).

Arne

 

[Series Expansion]

Because we're talking about lisp macros and they have nothing in common with C macros.

That is incorrect. They have in common the basic properties all macros
have, and all logical consequences deriving therefrom. Particularly, a
macro is a piece of code that, where invoked, replaces its invocation
with its own output, embedded in which are copies of the arguments it
was called with.

 

[Arne Vajhøj]

Well, the above paragraph is prima facie evidence that you have a
profound ignorance of how the Lisp package system works. You also have
a profound ignorance of how the Lisp object system works. And taken
together, those sources of ignorance lead you to raise objections that
are absolutely incorrect.

First of all, methods don't belong to classes. Period.
Second of all, classes don't establish any sort of namepsace. Period.

I will take your word for it.

The only way in Lisp for you to have "classes of the same name" is for
them to be exactly the same class, as in EQ classes. To put this into
Java terms for you, the confusion you are imagining would be akin to
saying that one could have two classses java.lang.String and
java.lang.String which are different, and thus confusable. You can't,
since they are the same classes.

Technically two classes with same name including package are
considered different in Java if they are loaded by different
classloaders.

Not that it really matters for your argumentation - it is still
perfectly valid.

Arne

 

[Arne Vajhøj]

Um, how does this work if you want the Java method to return a literal
such as int or double? I guess you are then forced to wrap the return
type in the corresponding Integer or Double, so that you have a safe
null value you can return?

Yep.

Arne

 

[gugamilare]

As opposed to Lisp, where one is force to use

 (import 'foo)

instead.  That seems to be a mere syntax change....

Save your breath. Seamus seems to have completely abandoned the thread
a long time ago and Series Expansion is still responding posts from
yesterday, if he really is going to post here since it's been a long
time from his last post. He probably have given up, he was writing too
long posts. Besides, all these things that you are saying all have
already been said more than once, so writing it all over again will
not make him change his mind, and no one else in this thread is
agreeing with him.

Instead of wasting more of your time here, post other interesting
threads in c.l.l. or write one more nice library for CL using macros,
generic function and all this good stuff that they flamed here

 

[Arne Vajhøj]

Seamus MacRae and Series Expansion are proving themselves to be
grandmasters of trolling. The Troll-o-Matic will have to be updated to
reflect their expert techniques.

And has anyone else noticed that they are never both present at the
same time? Just a thought.

Based on his IP address then Series Expansion is twisted alias
Paul Derbyshire.

You can do the googling.

Arne

 

[Series Expansion]

I'll try a last time.

This is a non-sequitur.

You've been explained that the macro can and will generate unique
name, that in no way may be collided.

That would require the macro to be able to examine the contents of the
scope containing the call site. Which means moving more things into
the macro's arguments from outside, so that they're available to the
macro's code to examine. The macro eventually grows to absorb the
entire calling function; every macro then has additional part-of-
function-before-macro's-job and part-of-function-after-macro's-job
arguments.

When you want to have *multiple* macro calls inside a single function,
then the fun really begins, as the macros have to avoid tripping over
*each other*. A combinatorial explosion ensues.

 This is absolutely impossible.

I'm gratified that you apparently realize this.

And now for the "personal insult":

None are desired or necessary.

   Go learn Common Lisp!  Or even Scheme with its hygienic macros, you
   might like them better than Common Lisp macros.

It sounds like Scheme's do something like auto-create a nested scope,
as if #define wrapped things in an implicit brace pair. This solves
variable capture but not variable hiding or multiple evaluation. To be
more "hygienic" (= encapsulated like regular functions) one supposes
it would also need to evaluate its actual arguments once, in left to
right order, assigning to local variables named the formal parameter
names. At this point, it's only half a macro; indeed, it's really just
an always-inlined function.

My guess is that Scheme macros are not any more encapsulated than Lisp
macros with respect to multiple evaluation issues, so implementation
changes to a Scheme macro can still screw up some call sites. The
variable hiding issue would also remain.

Tell me again what macros get you that closures don't?

 

[Arne Vajhøj]

I am not familiar with Jon Harrop. He does not seem to post to
comp.lang.java.programmer.

He does occasionally.

Mostly stating that ML-derivative languages are faster than
Java and similar.

Arne

 

[Series Expansion]

[...]
It's strange to be told, repeatedly, that things I do routinely,
without a great deal of difficulty or aggravation, are in fact
ridiculously hard and painful.
Real debugging or some sort of cargo-cult debugging, going through the
motions and having faith that it will have the intended effect?
Real debugging. Lisp macros are a good deal less arcane than you seem
to think; the ones you write 95% of the time are really just
straightforward Lisp functions that act on a tree made up of conses.

Except that macros lack the natural encapsulation barrier that
surrounds functions, as explained elsethread. With all the
consequences for debugging straightforwardness that that implies.

You're talking nonsense.

Actually, you are; personal attacks like this do not constitute
logical arguments in support of your position.

 Lisp macros /are/ functions!

They're sort of both. The function you refer to evaluates some code
into other code, which is then substituted at the call site.

The substitution at the call site, and substitution of the arguments
for the formal parameters, are the defining features of a macro, and
simultaneously are the cause of the variable-hiding, variable-capture,
and multiple-evaluation issues. All of those issues arise
automatically with macros and none of them arise with normal
functions.

So what I said about a kind of encapsulation barrier present with
normal functions and lacking with macros remains unassailed. Changes
to the innards of functions, such as renaming a local variable or
rearranging the exact way it computes something, can be made that
don't affect its computational semantics, and such changes can be made
safely without breaking things at the function's call sites. Similarly
semantically-null changes to macros can, however, break things at call
sites.

This is explained in more detail in some of my earlier posts. You have
not refuted it either by calling me names or by saying that Lisp
macros are functions.

The only difference between a "macro" and an ordinary
"function" is that macro-functions get executed at compile time.

And the results lexically substituted for the call. This last, which
you left out, is the most crucial point of difference.

 

[Arne Vajhøj]

Regardless, Lisp appears to have been designed for a simple line-
oriented-terminal model of interaction, much like bare-bones ANSI C,
actually, which requires third-party libraries to even do curses-type
stuff, let alone graphics and mouse support. Unlike C, it seems
difficult for such libraries to exist when Lisp, unlike C, compiles to
bytecode. Certainly third-party Java libraries cannot, unless they use
JNI, directly access hardware and thereby attain capabilities
involving interfacing with the hardware or the host OS that weren't
built into the JVM or the standard libraries. And I have not heard of
any Lisp facility analogous to JNI. So unless the LVM (or whatever you
want to call it) provides a particular form of host-system interface,
it is apparently unavailable to programs.

In my browsings around the net, the free Lisp implementations I've
come across seem to all be line-oriented. While it's possible that
I've missed something, it looks like the facilities required to create
a more capable UI are unavailable outside of expensive commercial
implementations.

If you pick Clojure then you can use the entire Java library
including JNI calls, Swing etc.etc..

Arne

 

[Series Expansion]

LOL

Non-sequitur. Your response is irrational and does not constitute an
argument in favor of Lisp or against Java.

 

[Series Expansion]

But emacs can also show "balloons": (tooltip-show "Hello world").

How, like this?
___________________
| balloon text here |
~~~~~~~~~~~~~~~~~~~

The problem with that sort of thing is that it cannot, at a glance, be
identified; the same pattern of characters on the display could result
if the above box-and-text were literally present in the text being
edited.

A GUI text editor lacks this difficulty, as it can display a proper
balloon with graphical borders and a yellow background, and this can
readily be distinguished from anything that could ever be present in
text.

(The problem rearises with image-editing software, when users edit
screenshots of GUIs: the GUI features shown in the screen shot may
look the same as actual GUI features of the system on which the
editing is being done. The usual effect is to slow the user down
somewhat and have little effect otherwise, though, so it doesn't seem
to be severe.)

 I prefer it to use the mini-buffer or split a new window.

How cumbersome.

 

[Series Expansion]

I agree, the mini-buffer is the best. It does not take your attention
from what you are doing like "balloons", but it still provides the
information anyway.

Tray notifications or a status bar can be used in GUIs to achieve the
same effect. GUIs present the application designer with an additional
option, though, which is to pop up urgent information, or almost-
certainly-desired information, right near where the user's eyes are
probably looking. It won't sometimes accidentally go unnoticed for
hours.

As with any feature, overuse or misuse of it can irritate and detract
from usability.

A further thing that software designed to run (only) on modern
hardware can use is sound, for example a gentle and nonobtrusive chime
to announce possibly-useful but non-urgent events (e.g. you have mail,
or a download has finished, or there's a tip displayed in the status
area), versus a loud buzz to warn of imminent danger (e.g. a delete is
too large to undo, are you sure?).

 

[Arne Vajhøj]

It is limited by the text modes the hardware can support. A graphics
display, especially using a proportional font, can easily have three
times the number of columns and double the number of rows; six times
the total effective display area.


Faking windows with ASCII has been done before, and always fails to
impress, or to achieve as high a level of usability as an actual GUI.

Emacs has been running on X for 20 years (give or take a few).

Of course not. An ASCII editor lacks Unicode support by definition.

Wrong on two counts:
* Emacs is not (entirely) an a text mode editor
* A text mode editor can support Unicode fine vi UTF-8

[and the rest is just as wrong]

Arne

 

[Arne Vajhøj]

Meanwhile I theorize that some of the Lisp vs. Java animosity might be
explained as a kind of sublimated emacs vs. vi hostility. Whereas
there seems to be a close association between Lisp and emacs, and the
latter uses a dialect of the former as its scripting language, one of
the creators of Java was also the principal developer of vi some
decades ago.

Bill Joy was part of early vi.

But James Gosling was part of early emacs.

No reason to think Java people should particular prefer
vi over emacs.

Arne

 

[Arne Vajhøj]

That isn't so true when you're learning Java EE. For that you really
need a Pentium-class computer and at least a gig of RAM, if you intend
to run a modern IDE and an app server and a database and your app.

Some types of development does require more hardware.

(you can run Tomcat in 512 MB though)

But the point is that it does not cost a small fortune in
hardware to be able to some open source development.

Arne

 

[Arne Vajhøj]

Surprisingly (to me, anyway), the compiler doesn't object, or even warn,
if one then assigns this (possibly null) Integer to a (certainly not
null) int, leading to the not-entirely-obvious possibility of a
NullPointerException at runtime.

I've only recently started using Java again after quite a while, and so
this autoboxing mularky is new to me. Autounboxing looks to me like a
mistake; an operation that could fail at runtime ought to require an
explicit cast or method call.

The "we want to type less" mob won that fight.

Arne

 

[Lew]

(F/U set to clj.programmer)

The "we want to type less" mob won that fight.

Fortunately, the "we want code that's reliable" elite still have the option to
write explicit unboxing or to use the wrapper class utterly.

It is foolishness in Java to mix primitives and objects, such as int and
Integer, without care for the side effects of the mixture. Generally, it is
foolishness to use object references at all in Java without being aware that
dereferencing a 'null' value is not wise. It's not like anyone forces you to
use auto(un)boxing, or that the semantics of 'null' are poorly documented.

 

[Lew]

Instead of wasting more of your time here, post other interesting
threads in c.l.l. or write one more nice library for CL using macros,
generic function and all this good stuff that they flamed here

And cease posting in clj.programmer.