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

[gugamilare]

Ah!!! I didn't know that! Now I know why C macros fail. And why this
is so difficult for you to understand

C lets you #define all kinds of code fragments. Lisp macros apparently
have to appear to be function calls, and be called in the same places
where one could make function calls.

Now you get it. The only difference between macros and functions is
when it is called, and the type of arguments it receives. Believe me,
all the power we are talking about come from such a simple feature.
Whether you believe it or not, this simple feature is already enough
to make all the things we said. Period.

But Lisp (and C's preprocessor) allow a typo to catastrophically
affect far-away code that isn't even supposed to be interacting
directly with the part of the codebase containing the typo, and in
ways other than by causing an obvious name collision or other compile-
time error.

The Lisp compiler always complains about name collisions, whether it
is a macro-macro, function-function or macro-function call. Any other
cases can't be misinterpreted.

Another hand-wave. Macros are macros are macros.

No. Every language implements everything in a different way.

Macros are a symbol, possibly with formal parameters, that is expanded
where it is called in the code, with the formal parameters in turn
expanded into copies of the actual parameters.

It immediately follows that an actual parameter with side effects may
end up having those side effects multiple times, and that certain
other problems can arise.

This is easily handled in lisp using local variables and gensyms (auto-
generated collision-free symbols). You just bound the arguments you
want to evaluate into variables whenever you want to evaluate anything
(this is mostly, but not always, the case), and then use the
variables. Side-effects and variable-collision safe. Just simple as
that.

Furthermore, the variable capture problems follow automatically as
well.

Gensyms again.

If the macro assigns to a variable in the outermost scope in its
body, it will clobber the value of any variable of the same name
existing at the call site, since when the macro is expanded in place
at that site, the variable name in the macro becomes a reference to
that other variable. Likewise, if the macro contains a structure in
its body that creates a smaller local scope and defines a variable in
that, when expanded at the call site that becomes a nested local scope
at the call site, and the variable will hide any variable of the same
name existing in the scope enclosing the call. If the macro uses a
formal parameter inside that nested scope, and the call site uses that
variable in the corresponding actual parameter, the expansion will use
the macro's local variable instead of the one the coder intended it to
use, because the latter is hidden by the former.

This again causes an encapsulation failure: merely changing the names
of variables internally used in the macro, without altering anything
else, may cause it to behave very differently at some call sites.

And all of the above is extrapolated from the definition of "macro"
without reference to any particular language, implementation, or
anything. The only way for the above not to happen is for the "macro"
involved to violate in some manner the generic, language-independent
definition of a macro, i.e. for it not to be a macro at all but rather
something else, such as a plain-Jane function call.

Do you really think that 50 years of coding and Lisp programmers are
amateurs enough to make such bad mistakes? Again you fail to
understand this.

Nintendo 64 was implemented using Lisp. So was Mario 64. And also
another game made to Playstation 2 that I don't remember the name. ITA
Software is a well known company that uses Common Lisp. There are at
least 2 commercial Lisp implementations that sell CL environments with
many features and charge over a thousand dollars on a single license.
Many really experienced programmers like Paul Graham use Lisp (and not
only Lisp). And you are the first one to ever see these problems. You
must be a genius.

 

[gugamilare]

Just because somebody has a tiny grammar mistake in their English,
doesn't mean that the rest of what they say doesn't have some valuable
information.

Oh, he was talking about my English. Ok, I might have made English
mistakes throughout the thread, I am not a native English speaker so
understand that writing things in English is not as intuitive and as
easy as it is to you, even though I am not bad in English. If you
think I am stupid just because my English is not as good as yours, you
don't have a point.

 

[Series Expansion]

Notice that in 1985, GUI existed and were commercialized already for a
few years.

They weren't commonplace, aside from the clunky old black-and-white
Macs.

However, your comment seem to show that you think that GUI are better
than CLI.

Doesn't that kind of go without saying? The progression has been:
toggle switches, punched cards, teletype-and-keyboard, line-oriented
monitor-and-keyboard, curses-based interfaces and their equivalents,
GUIs.

Or just look at the interfaces of personal computers:
1980 - BASIC interpreter acting as command prompt and as line editor
for BASIC code.
1990 - MS-DOS command prompt, but with Edit providing a full-screen
text-mode editor.
2000 - Windows ME with a GUI file manager and graphical Notepad text
editor.

This is called "progress".

It is notable that the older interfaces tend to remain available in
some form. In 1990, MS-DOS also had EDLIN, an "ed"-style line editor,
as well as the command prompt itself being line-oriented and in 2000,
Windows ME had the ability to spawn MS-DOS prompts and applications in
terminal emulator windows.

Unix systems have followed a similar progression, from command prompt
and ed to command prompt and emacs, vi, and ed to X Window System
workstations with graphical editors, other tools, and xterm, within
which you can run bash and ed and vi.

This is called "progress, combined with backwards compatibility".

I agree that GUI are generaly nice.  Unfortunately they're also less
productive than CLI.

You mean, more productive. GUIs provide a lot of productivity
benefits:

* Increased screen real-estate for text. Instead of a smallish rigid
rectangular grid of ASCII characters you can have quite a large
grid, and you can use a proportional font and ditch the grid
constraint.
* Ability to display much larger character sets, foreign characters
for instance. The best pre-graphics systems could display sometimes
several of the European languages, though only one at a time, by
supporting a choice of code pages. GUIs can display the whole of
Unicode, including the very large character sets used in
far-Eastern languages, and mix them all seamlessly (modulo
reading-order differences).
* A picture is worth a thousand words. GUIs can display symbols like
a dangling plug instead of taking up much more space with the
slower-to-comprehend word "disconnected", allowing more compact and
informative status areas.
* The same thing lets GUIs put a dangling plug symbol onto a
push-button to clearly and concisely do all of these at once:
- tell you you can disconnect
- tell you one way of doing so
- provide that way of doing so
In a terminal you're stuck putting the first item in a status line
at the bottom (say, the word "connected"), the second buried in a
long help file somewhere out of immediate view, and the third bound
to some probably unguessable hotkey without browsing the help
(screen-oriented) or by typing "disconnect" and enter at some
prompt (line-oriented). The latter can still be subject to
usability problems:
- guess-the-verb, if there are several synonyms; a common culprit
is when exactly one of "quit" and "exit" works, or worse,
neither, and different ones don't work in different apps, with
none working in all
- it takes eleven input actions to type "disconnect" and hit enter
versus two, a flick of the mouse and a click, to hit a button.
For frequently-used commands the difference adds up rapidly.
- fixing the second problem worsens the first drastically. If you
make the disconnect command "dis", you solve the second problem,
but make guess-the-verb a hell of a lot worse. If you allow both
synonyms, hardly anybody is going to discover that the
abbreviation "dis" works so you fail to solve the second problem
in practice, though you do solve it in principle.
* Flexibility of workflow. The user can open and arrange various
windows to suit, move data around via copy and paste, and the like.
A terminal constrains the user to using a linear sequence of
applications, and of screens within an application, and working out
some cumbersome system of scratch files to move data around.
Copy/paste doesn't work across applications and only one screen of
one application can be used at a time.
* Web access. The web is largely unusable with lynx nowadays. With a
window system and a reasonably modern browser, you can make full
use of the world's largest free library, and you can easily
alternate between doing so and using your other software. For
instance, if you hit a snag with something and get an unusual and
cryptic diagnostic from your compiler, you can select it in the
IDE's compiler-output window or pane, alt-tab to a pre-existing
Firefox, click in the google box at top right, paste in the error
message, hit enter, click a link, and probably be reading some
useful information about the error in a matter of mere *seconds*,
if you're proficient with modern user interfaces, modern web
browsers, and your IDE. It takes significantly more time to
memorize a part of an error message on your screen, type lynx and
enter, tab a bit, type http://www.google.com, type what you can
remember of the error message, hit enter, arrow down, etc., and
eventually exit Lynx and fire up your editor to go back to your
makefile or source code. Moreover, this presupposes that the
helpful site with information on the error message is readable or
navigable at all in Lynx. (And you can thank your lucky stars that
Google itself is, or you'd really be stuck.)
* A GUI can place your current actions and work in context in various
ways. For example, a file list can be accompanied by a directory
tree, and the image files in formats your file manager recognizes
can be displayed as thumbnails, so you can find images by what you
remember them looking like and not just by what you remember their
filenames to be. Every additional way to view or find things helps,
and a lot of ways are inherently incompatible with displaying in an
ASCII terminal.
* Similarly, it can provide cues for navigating the space of
available next steps in your work, for example in the form of
buttons and menus. These can appear and disappear as they become
available or not depending on your actions, so edit/cut appears in
editable text and not in read-only text or browsing a class
hierarchy or the source code directory's file listing. This beats
the heck out of having an assortment of control-this keys or a
prompt to type verbal commands into, and, somewhere else, a long
help file listing all the commands that are ever available
anywhere, anytime. Users want to write code, fix the red-eye in
their photos, or whatever, not play guess-the-verb like it was an
Infocom text adventure game ("Oops! All of your data has just been
erased. Play again? Y/N") or play the 101-key piano (which
invariably not only results in recurrent trips to the online help,
if there even is any, but leads to other problems too, such as
typing something and suddenly the application does something wacky
with no obvious way to undo it, because you typo'd in something it
apparently finds meaningful).
* A window system also supports *user* multitasking. For example, if
you get email, it can chime or show a tray notification or both,
and if you decide to check it, you can tab to it right away
instead of having to drop everything, fire up an email client, and
poke around in a cryptic interface to make it connect, download
the new message, and display it. Indeed, it can be downloading
your mail as it arrives, quietly, and even classifying and
discarding much of the spam for you, only alerting you when
something it thinks is legitimate shows up, and having that
already displayed by the time you alt-tab to its window from your
work. All of this is doubly useful if you're waiting for a
task-related email, such as a reply to a post on a project
mailing list that you expect to carry information you can use.
Often the balloon help in the tray will show the subject of the
incoming email, too -- if it's "[foo-dev-l] Re: file status API"
you're golden, and if it's "EN1ARG3 YU0R P3N15 T0DAY!!!" you
can safely ignore it.

If point-by-point arguments bore you, here's the nutshell,
metaphorical version too: after using a GUI, using anything more
primitive feels like flying a plane with no instruments, a keyhole-
sized cockpit window to peer out of, and a control stick you have to
talk to rather than simply pull, push, and turn with your hands.

At night.

In fog.

The main point here is that the theory behind GUI is that it's the
user who is working, the GUI presents to the user objects that he can
manipulate with the mouse and menus.  

On the contrary, CLI are means to give orders to the computer, to let
the computer do the work.  

Yes. This means:

The GUI is most useful when the user is doing creative tasks, such as
writing novel code, or doing image, 3D, or similar tasks that
absolutely require graphics to show the user their work and that
benefit extremely from having a pointing device as one input tool.

The CLI is most useful for firing off commands that do something
noninteractive, such as building the source tree and generating the
distribution zipfile, or bundling up the source tarball, or things
like that, or doing batch file renames or other such filesystem
administrivia.

Even then a GUI can be useful. For example, a GUI editor to edit the
makefile before the build, or an IDE with a built-in debugger with a
debugging prompt in its debugger window (a CLI inside a GUI!), or a
file manager that lets you grab files and mass-manipulate them by
mouse for when you just want to "take all these and move them here"
rather than do anything sophisticated like "move all the files dated
before July whose names contain foo to the directory whose name is
their modification date", which requires some kind of wildcard
trickery.

Oh, wait -- even then a GUI can sometimes be better! If it has a good
multi-criteria search tool, your graphical filemanager can be made to
display just the files with the appropriate criteria, and you can grab
them and drag them about. The added advantage is that while it's
displaying the results and before you do anything to them, you can
glance at them and see if there's anything that shouldn't be there, or
anything missing that should be there. So another GUI point:

* More visual feedback on the work being performed and its
progress can help reduce errors as well as provide richer
feedback as to whether, and how quickly, a task is
proceeding.

It can be quite disconcerting to tell a CLI to move some files and
just have the prompt reappear: did it even do anything? Even more so
to tell it to move some files and have it appear to hang.

Versus seeing the files appear one by one in the destination folder,
and if it's taking long enough, a clock counting down the estimated
time remaining until the job's done. And being easily able to do
something else (except if it involves those files) in the meantime.

and the point is not to let the user manipulate himself the texts, but
as much as possible to direct emacs to do the editing instead of the
user.

This is problematical. Writing program code is a largely un-
automatable task, aside from generating parser skeletons from grammars
and GUI code from forms. We have bison for the former, and if you're
generating GUI code you're generally doing it from an actual GUI!

So your dream of being able to just type "write the implementation of
the Foo.bar() method for me" and enter at a prompt and get useful code
out if it is not likely to be fulfilled anytime soon.

So much for directing the editor to do the editing; you'll just have
to type "public void bar () {" and figure out and type in the logic
all on your own. A smart IDE will generate the declaration and the
line with the close brace for you and position the cursor in the
middle with one mouse click -- no need for typing in keyboard commands
-- but that's as far as it will go. And that only if the class
implements an interface or it can otherwise infer the need for this
method.

There's one major exception: NetBeans can generate getters and setters
for a private field, with the appropriate names derived from the name
of the field. Some other predictable boilerplate sorts of code it can
likewise generate for you. You lispers claim to do the equivalent in
Lisp code using Lisp macros, so all of the Lisp code you actually
edit, in theory, is non-automatically-generatable, and thus no code
generation features in your editor or IDE seem useful or necessary.
Whereas the NetBeans ones that are useful for Java development clearly
are not incompatible with the editor being a GUI one instead of a
command line one.

So instead of clicking on buttons on menues, we can give commands, and
add and improve the commands we may give to your lisp systems.

Many major GUI applications provide equivalent capabilities. In Word
for example you can write VBScript to do something novel to a document
and then give it an icon and add it to your toolbar, or bind it to a
control-shift-foo type hotkey, or both. NetBeans has a templating
language for customizing its code generation, and is open source, so
you can hack NetBeans itself if hacking in the templating language
won't suffice. New templates appear in appropriate places in the
menus. Eclipse is even more modular and reprogrammable, using Java and
SWT. It can even be turned into a non-IDE tool such as a word
processor.

 This way, instead of doing the work yourself, you can just
give commands to the computer and it will work for you.

If the Lisp code you're editing can be generated automatically,
shouldn't you be using a Lisp macro instead of having your editor
churn it out? Then you can just change the macro later instead of
every spot where the editor did whatever it did.

Your arguments in favor of a command-driven editor instead of a normal
one appear to contradict your arguments in favor of Lisp macros. I'm
afraid you'll have to pick exactly one of those to continue to
support, or else lose credibility in both debates.

 

[Series Expansion]

You are being hypocrite.

You are being rude.

You have just ignored everything he explained

I don't consider "No, no, no, no" to be an explanation. Sorry.

Yes.

As evidenced by the flame I'm now replying to.

you don't have idea of what you are talking about

That's a good example of such flamage, yes.

convincing you is just hopeless because you ignore or misinterpret
every damn good point we make.

And look! Here's some more anger. Let me check that guide to see what
the next stage is. Ah, here it is -- withdrawal. I guess you'll be
shutting up soon, then.

(*What* good points you make? I've yet to see any.)

Wow, I am impressed.

Why, thank you.

You know what? I will not waste one more precious minute of my time
trying to explain everything to you.

And there it is, right on cue -- withdrawal. And the stage after
*that* is ...

Hoo boy. Apparently it's acceptance! I guess the argument is finally
almost over then.

If you want to continue this debate, read the ENTIRE book

If you'll pay for it (shipping and tax included), I'll be happy to.
Otherwise, not interested.

 

[Series Expansion]

This is false.

I have just spent quite a while demonstrated otherwise.

And this is something that you may try to do in Lisp, but which will
pose absoltely no problem because  it has a very well defined and sane
semantic:

(defun malloc (size) ...

That's a function, not a macro. Now watch what happens when someone
makes a macro with the same name and hides it away somewhere.

Why do you insist talking about things you don't know?

But I know a great deal about macros, and the pitfalls thereof.

No it is not.

Sure it is. In

int x;

x has to be an integer, at least unless you use wacky casts, which
will earn you a compiler warning. In

(defun foo (x) (do something with x))

x can be absolutely anything whatsoever -- integer, rational, decimal,
list, and so forth. If it's the wrong thing, the best you can probably
hope for is that the "do something with x" part will throw some kind
of run-time exception. Silent data corruption is more likely. It's
like if you had some C code with only one pointer type used anywhere,
void *, except it probably can't outright crash the runtime by goofing
up, just dump you into the REPL with a cryptic error message.

"one"+2=8175
status = 0

*** - +: "one" is not a number

So you found one instance where C quietly generates a logic error but
Lisp's REPL produces a run-time exception.

And it looks like you may have done something to suppress the warnings
from the C compiler.

The problem with macros that I've been getting it is their inherent
ability to alter the behavior of far-away code from pretty much
anywhere. A function has to be intentionally invoked by some code to
have effect there; a macro has to be coded to operate ON some other
code to have effect there.

[calls me a liar]

If you're going to do that, then we're done here.

Of course a macro can be programmed to expand to code that modify the
global state, for example, it could define a new global variable, or
it could define (or redefine) a function or a macro.

Well, there you go, then.

But if you don't want your macro to define a function, then you don't
program it to do so, and it won't have that global effect.

Unless a mistake is made.

Then the effects of a macro invocation will be strictly localized.

Unless a mistake is made.

Notice that defining global variables or (re)definining functions or
macros can also be done by functions in Lisp.

Maybe Lisp macros aren't more dangerous than Lisp functions after all,
then -- but because Lisp makes functions MORE dangerous instead of
macros LESS!

Forget all you know about C macros

Why should I? It's a useful job skill.

 

[gugamilare]

They weren't commonplace, aside from the clunky old black-and-white
Macs.


Doesn't that kind of go without saying? The progression has been:
toggle switches, punched cards, teletype-and-keyboard, line-oriented
monitor-and-keyboard, curses-based interfaces and their equivalents,
GUIs.

Or just look at the interfaces of personal computers:
1980 - BASIC interpreter acting as command prompt and as line editor
for BASIC code.
1990 - MS-DOS command prompt, but with Edit providing a full-screen
text-mode editor.
2000 - Windows ME with a GUI file manager and graphical Notepad text
editor.

This is called "progress".

It is notable that the older interfaces tend to remain available in
some form. In 1990, MS-DOS also had EDLIN, an "ed"-style line editor,
as well as the command prompt itself being line-oriented and in 2000,
Windows ME had the ability to spawn MS-DOS prompts and applications in
terminal emulator windows.

Unix systems have followed a similar progression, from command prompt
and ed to command prompt and emacs, vi, and ed to X Window System
workstations with graphical editors, other tools, and xterm, within
which you can run bash and ed and vi.

This is called "progress, combined with backwards compatibility".


You mean, more productive. GUIs provide a lot of productivity
benefits:

* Increased screen real-estate for text. Instead of a smallish rigid
  rectangular grid of ASCII characters you can have quite a large
  grid, and you can use a proportional font and ditch the grid
  constraint.

Emacs can also have a large grid. It has windows.

* Ability to display much larger character sets, foreign characters
  for instance. The best pre-graphics systems could display sometimes
  several of the European languages, though only one at a time, by
  supporting a choice of code pages. GUIs can display the whole of
  Unicode, including the very large character sets used in
  far-Eastern languages, and mix them all seamlessly (modulo
  reading-order differences).

Don't you think Emacs has Unicode support? Emacs is not a frozen
ancient application, it has evolved, and that is why it still exists.

* A picture is worth a thousand words. GUIs can display symbols like
  a dangling plug instead of taking up much more space with the
  slower-to-comprehend word "disconnected", allowing more compact and
  informative status areas.

Emacs is not different.

* The same thing lets GUIs put a dangling plug symbol onto a
  push-button to clearly and concisely do all of these at once:
  - tell you you can disconnect
  - tell you one way of doing so
  - provide that way of doing so
  In a terminal you're stuck putting the first item in a status line
  at the bottom (say, the word "connected"), the second buried in a
  long help file somewhere out of immediate view, and the third bound
  to some probably unguessable hotkey without browsing the help
  (screen-oriented) or by typing "disconnect" and enter at some
  prompt (line-oriented). The latter can still be subject to
  usability problems:
  - guess-the-verb, if there are several synonyms; a common culprit
    is when exactly one of "quit" and "exit" works, or worse,
    neither, and different ones don't work in different apps, with
    none working in all
  - it takes eleven input actions to type "disconnect" and hit enter
    versus two, a flick of the mouse and a click, to hit a button.
    For frequently-used commands the difference adds up rapidly.
  - fixing the second problem worsens the first drastically. If you
    make the disconnect command "dis", you solve the second problem,
    but make guess-the-verb a hell of a lot worse. If you allow both
    synonyms, hardly anybody is going to discover that the
    abbreviation "dis" works so you fail to solve the second problem
    in practice, though you do solve it in principle.
* Flexibility of workflow. The user can open and arrange various
  windows to suit, move data around via copy and paste, and the like.

Wow! Emacs does that. You don't need multiple windows to copy and
paste code, but Emacs provide them if you ask.

  A terminal constrains the user to using a linear sequence of
  applications, and of screens within an application, and working out
  some cumbersome system of scratch files to move data around.
  Copy/paste doesn't work across applications and only one screen of
  one application can be used at a time.

You clearly didn't ever use Emacs. This can be done without multiple
windows. But, still, Emacs can have multiple windows.

* Web access. The web is largely unusable with lynx nowadays. With a
  window system and a reasonably modern browser, you can make full
  use of the world's largest free library, and you can easily
  alternate between doing so and using your other software. For
  instance, if you hit a snag with something and get an unusual and
  cryptic diagnostic from your compiler, you can select it in the
  IDE's compiler-output window or pane, alt-tab to a pre-existing
  Firefox, click in the google box at top right, paste in the error
  message, hit enter, click a link, and probably be reading some
  useful information about the error in a matter of mere *seconds*,
  if you're proficient with modern user interfaces, modern web
  browsers, and your IDE. It takes significantly more time to
  memorize a part of an error message on your screen, type lynx and
  enter, tab a bit, typehttp://www.google.com, type what you can
  remember of the error message, hit enter, arrow down, etc., and
  eventually exit Lynx and fire up your editor to go back to your
  makefile or source code. Moreover, this presupposes that the
  helpful site with information on the error message is readable or
  navigable at all in Lynx. (And you can thank your lucky stars that
  Google itself is, or you'd really be stuck.)

Emacs have even an extension that is a browser inside Emacs. And, yes,
Emacs can display pictures that the webpages have. (Someone already
said that he uses Emacs to surf on the web, but, conveniently, you
just ignored him).

* A GUI can place your current actions and work in context in various
  ways. For example, a file list can be accompanied by a directory
  tree, and the image files in formats your file manager recognizes
  can be displayed as thumbnails, so you can find images by what you
  remember them looking like and not just by what you remember their
  filenames to be. Every additional way to view or find things helps,
  and a lot of ways are inherently incompatible with displaying in an
  ASCII terminal.
* Similarly, it can provide cues for navigating the space of
  available next steps in your work, for example in the form of
  buttons and menus. These can appear and disappear as they become
  available or not depending on your actions, so edit/cut appears in
  editable text and not in read-only text or browsing a class
  hierarchy or the source code directory's file listing. This beats
  the heck out of having an assortment of control-this keys or a
  prompt to type verbal commands into, and, somewhere else, a long
  help file listing all the commands that are ever available
  anywhere, anytime. Users want to write code, fix the red-eye in
  their photos, or whatever, not play guess-the-verb like it was an
  Infocom text adventure game ("Oops! All of your data has just been
  erased. Play again? Y/N") or play the 101-key piano (which
  invariably not only results in recurrent trips to the online help,
  if there even is any, but leads to other problems too, such as
  typing something and suddenly the application does something wacky
  with no obvious way to undo it, because you typo'd in something it
  apparently finds meaningful).
* A window system also supports *user* multitasking.

For the thousandth time, Emacs have a window system.

For example, if
  you get email, it can chime or show a tray notification or both,
  and if you decide to check it, you can tab to it right away
  instead of having to drop everything, fire up an email client, and
  poke around in a cryptic interface to make it connect, download
  the new message, and display it. Indeed, it can be downloading
  your mail as it arrives, quietly, and even classifying and
  discarding much of the spam for you, only alerting you when
  something it thinks is legitimate shows up, and having that
  already displayed by the time you alt-tab to its window from your
  work. All of this is doubly useful if you're waiting for a
  task-related email, such as a reply to a post on a project
  mailing list that you expect to carry information you can use.
  Often the balloon help in the tray will show the subject of the
  incoming email, too -- if it's "[foo-dev-l] Re: file status API"
  you're golden, and if it's "EN1ARG3 YU0R P3N15 T0DAY!!!" you
  can safely ignore it.

If point-by-point arguments bore you, here's the nutshell,
metaphorical version too: after using a GUI, using anything more
primitive feels like flying a plane with no instruments, a keyhole-
sized cockpit window to peer out of, and a control stick you have to
talk to rather than simply pull, push, and turn with your hands.

At night.

In fog.

The main point here is that the theory behind GUI is that it's the
user who is working, the GUI presents to the user objects that he can
manipulate with the mouse and menus.  

On the contrary, CLI are means to give orders to the computer, to let
the computer do the work.  

Yes. This means:

The GUI is most useful when the user is doing creative tasks, such as
writing novel code, or doing image, 3D, or similar tasks that
absolutely require graphics to show the user their work and that
benefit extremely from having a pointing device as one input tool.

The CLI is most useful for firing off commands that do something
noninteractive, such as building the source tree and generating the
distribution zipfile, or bundling up the source tarball, or things
like that, or doing batch file renames or other such filesystem
administrivia.

Even then a GUI can be useful. For example, a GUI editor to edit the
makefile before the build, or an IDE with a built-in debugger with a
debugging prompt in its debugger window (a CLI inside a GUI!), or a
file manager that lets you grab files and mass-manipulate them by
mouse for when you just want to...

mais »

 

[gugamilare]

I have just spent quite a while demonstrated otherwise.

But used only invalid arguments, at least in the contest of Lisp.

 

[Adlai]

You are being rude.


I don't consider "No, no, no, no" to be an explanation. Sorry.



As evidenced by the flame I'm now replying to.


That's a good example of such flamage, yes.


And look! Here's some more anger. Let me check that guide to see what
the next stage is. Ah, here it is -- withdrawal. I guess you'll be
shutting up soon, then.

(*What* good points you make? I've yet to see any.)

I think there have been some good explanations in some of my threads
explaining how Emacs IS A GRAPHICAL SYSTEM, and is much much much much
much much more than just a text editor. I also had a very detailed
post about an hour ago about the Lisp macro system. Please spend your
time on explanatory posts, not flammatory ones.

Why, thank you.


And there it is, right on cue -- withdrawal. And the stage after
*that* is ...

Hoo boy. Apparently it's acceptance! I guess the argument is finally
almost over then.


If you'll pay for it (shipping and tax included), I'll be happy to.
Otherwise, not interested.

Dude, it's been said 5 or 6 times already --

a) it's free

b) we've pointed you to a specific chapter to look at

c) it's right here -- the ENTIRE BOOK FOR FREE. http://www.gigamonkeys.com/book/

If you just don't want to learn about Lisp, just say so. However, at
that point, we'll probably start ignoring you, rather than trying to
show you where you can fill in gaps in your knowledge.


- Adlai

 

[gugamilare]

(*What* good points you make? I've yet to see any.)

You already saw them. The only thing is that you don't understand them
because you don't understand Lisp.

 

[gugamilare]

But used only invalid arguments, at least in the contest of Lisp.

ConteXt, before you flame me again for writing wrong English.

 

[gugamilare]

Why should I? It's a useful job skill.

He meant that a C macro is so much different from a Lisp macro that,
to understand a Lisp macro, you need not to take any knowledge you
already have using C macros.

 

[Marco Antoniotti]

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

I don't understand this.... Would you care to explain? Debugging
macros implies debugging an AST rewriting process (something you do
not have at hand with the C preprocessor). In what way you are
"breaking the 'natural encapsulation' barrier"?

Cheers

 

[Marco Antoniotti]

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.

Welll... In Java (but not in C++) the 'import' at the beginning also
instruct javac where to look, via the classpath, for the other
packages/classes.

It is a very nice thing of Java. BTW. If you scrape enough of all
the layers of Eclipse, Netbeans and MSVS, you always get down to the
equivalent of 'javac' or 'cl' (meaming MS C/C++ compiler/linker).

Cheers

 

[Paul Donnelly]

But they're just as obsolete. If nothing else, their user interfaces
will be woefully subpar by modern standards.

Has Pascal gotten that much better at UI design since then (assuming the
had UIs)?

 

[Alessio Stalla]

And free implementations?

I've already answered you. There's lots of free (as in freedom and as
in beer) CL libraries, but sometimes they require to - gasp! - spend a
little time reading their documentation and installing them, instead
of clicking "add library X" in some IDE. But this has nothing to do
with languages and much to do with community size and amount of
invested money. (Just to clarify, I do find it easier to install
libraries in Java, but I've never had any serious problems installing
a CL library, either. Many of them are actually packaged in Linux
distros, for example, and you can install them just as you install any
other library).

Oh. How disappointing.



Getting rid of types to solve this is throwing out the baby with the
bathwater.

Yet this is precisely what happens when you use any kind of XML-based
configuration in Java and other languages. Need I mention some
examples? Spring's application context, web.xml webapp descriptor,
faces-config.xml, tld files, Facelet taglibs, and the list goes on and
on. Any decently-sized enterprise application will use at least some
of them, and probably others. All of these files refer (using
strings!) to names of classes, or even properties and methods of those
classes, and combine them *without* any kind of static type checking,
since XML is not considered to be source code and thus not compiled.
If you say that programmers should get rid of these non-statically-
typed tools and always use statically-typed Java for everything,
that's fine - but I doubt you'll convince any Java programmer of this.

So I'm just saying that what in Spring you write as

<bean id="someObject" class="com.mypackage.MyClass">
<property name="someProperty" ref="someOtherObject" />
</bean>

in Lisp - without using any library - you'll simply write as

(defvar *some-object*
(make-instance 'my-package:my-class
:some-property *some-other-object*))

and *compile* and load the file with this code *at runtime*, getting
warnings or errors if you have made mistakes. This covers the most
common and simple use of Spring, I repeat using only standard CL -
that is defining a bunch of "singleton" (in Spring parlance) objects
and combining them, and being able to change their classes without
recompiling the whole application. If you want something more
sophisticated, you'll need a library, which hasn't been written yet
(probably because there's not much need of it in Lisp). You could try
and write such a library, it could be a great way to learn some
Lisp

Says someone who evidently has never heard of junit.

I know JUnit and regularly use it - for testing Java code. I'm not
aware of how JUnit could test fragments of XML.

Alessio

PS: Spring is only an example. You can easily replace other kinds of
XML-based configurations using bare Lisp or a little DSL on top of it.
For example, take a loot at how Hunchentoot - a Lisp web server -
registers functions to be executed when a request matches a certain
pattern, just like web.xml does with servlets:
http://www.weitz.de/hunchentoot/#request-dispatch

 

[Nicolas Neuss]

"Series Expansion" is a worthless troll. Ignore him. He's not in any
way representative of the universe of Java programmers. He's just a
nasty little man.

Yes, don't judge a language by its trolls - we have some of them in
comp.lang.lisp, too. At the moment, we are in the lucky situation that Xah
Lee and Jon Harrop are taking a rest, but the Maas troll who started this
thread is still active.

Nicolas

P.S.: I think we can also be quite sure that there are no Lisp or Java
"gods" present in this thread. At least, one "god" (or better wise man)
who posts to comp.lang.lisp more or less regularly, namely Kent Pitman, has
stated explicitly that he does not participate in crossposted threads.

 

[Paul Donnelly]

Just as I feared.


Except the lack of encapsulation barrier, and the ability of macros to
replace or modify existing functions of the same name.

You're complaining that macros can do something that functions can do
too?

You might want to explain this "lack of encapsulation barrier" stuff so
we can tell you specifically how wrong you are this time.

 

[Paul Donnelly]

Nintendo 64 was implemented using Lisp. So was Mario 64.

Was it? Where did you learn that?

And also another game made to Playstation 2 that I don't remember the
name.

Jak and Daxter, although some of their other games might have been done
the same way. I don't recall.

 

[Pascal J. Bourguignon]

In what quantum universe? Is the grass greener there than it is here,
too?


Replace "class" with "generic function" then:

1. The vendor puts it in the system generic function. No
problemo.
2. Everyone rolls their own. Ugh.
3. A third party library puts it in the system generic
function. 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.

The language forbids to define methods of standard generic functions
on standard classes. In the same way that Java forbids you to add or
modify anything in java.lang.*

However this is not a big problem.

First there's only 40 standard generic functions, most of them are
hooks for other CL functionarity, that shouldn't be called by the
user, but designed so the user may put methods on for its own classes:
there would be no point to add a method for a standard class, because
the implementation may even not call the generic function with a
standard class instance in the first place, only for user classes.

Next if it's the name of the generic-function you're interested in,
you can always shadow it it and use your own symbol of same name in
your own package:

(defpackage "MY-PROGRAM"
use "CL")
shadow "PRINT-OBJECT"))
(in-package "MY-PROGRAM")
(defgeneric print-object (obj str))
(defmethod print-object ((a integer) (b stream))
(print `(this is an integer of value ,a) b))

so now when you write:

(print-object 42 *standard-output*)

you will get:

(THIS IS AN INTEGER OF VALUE 42)

printed.

Worse, sometimes you have to, even with generic functions from someone
else's namespace, even ones in the system package(s).

CLOS, and Lisp itself, seem designed for the "lone hacker in his
garage" model of software development. Very little modern software is
actually developed that way.

But at least, with Lisp you can indeed develop big software with less
developers, smaller teams than with other programming languages.

And then watch your coworkers tearing out tufts of hair, screaming,
sobbing, throwing office furniture around, and going prematurely gray.

Therefore you don't.

If I were of a sadistic bent, I might like that idea.

As things stand ...

Well, I think my opinion has become quite clear.

Lisp language designers don't think lisp programmers are dumb.

 

[Pascal J. Bourguignon]

You did? What was it, the bozo of the week award? Can I see it? Pretty
please?


No, now it will just make all your coworkers break out in hives when
your code is checked into the source code repository and a big
whirling red light and wailing Klaxon promptly pop out of panels on
the git server box to warn of an impending meltdown.

Not at all. This is done every days by lisp programmers and no such
thing occurs.

But they're just as obsolete. If nothing else, their user interfaces
will be woefully subpar by modern standards.

You are not the one to say whether they'd be obsolete or not, only
their users.

And corporations may have something else to do, and something else to
finance, than to pay java programmers to follow the fashion of the day
in GUI for their mission critical software.