Why Lisp is not popular. No GUI?
thelifter
Common CL GUI
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3DE2CCDA.6030000%40nyc.rr.com&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26group%3Dcomp.lang.lisp%26start%3D25
People where discussing a GUI for Lisp. The point is that there seems
to be not good solution.
Java my be a shitty language but it has a GUI. So in practical terms
it wins.
I think we could make Lisp much more popular if we started to make a
good GUI for it.
When I say GUI I mean that it should be easy to make a GUI using Lisp,
not that the language needs a GUI itself.
What do you all think?
Lovecraftesque
> What do you all think?
Not much. At least, I don't. Your proposal might make Lisp more
popular among those whose business revolves around coding GUIs. I would
like to believe that most coders do something of more substance than
coding GUIs.
Kenny Tilton
thelifter wrote:
> I think we could make Lisp much more popular if we started to make a
> good GUI for it.
...
>
> What do you all think?
Absolutely, but you knew my position on that. <g> Well, by chance just
when Python happened to be /really/ pissing me off someone from this
project tipped me off to it:
http://sourceforge.net/projects/cl-sdl/
...and sure enough I managed to get it up and running. I have a pretty
full-blown app framework that uses win32 for little more than events and
drawing, so with luck we could have a universal CL app framework in a
month. (It took me that long to move from a Mac version to an ACL
version, so ACL to SDL might be the same.)
Anyway, i'll spend a few days now on this to see if it wants to happen.
The hard part will be mastering OpenGL, a worthy foe.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Espen Vestre
> I think we could make Lisp much more popular if we started to make a
> good GUI for it.
Have you ever tried LispWorks with CAPI?
--
(espen)
Software Scavenger
Give an example of something of more substance.
Paolo Amoroso
> Java my be a shitty language but it has a GUI. So in practical terms
> it wins.
> I think we could make Lisp much more popular if we started to make a
> good GUI for it.
[...]
> What do you all think?
Great. When are _you_ going to start working on it?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Lovecraftesque
> Give an example of something of more substance.
Communication protocols, databases, FFTs, cryptography
and security - just about anything is of more substance than
GUIs. To me, GUIs are like the leather seats, A/C, radio/CD
and other gizmos that cars these days come equipped with -
nice, even slick, but not the essential to the main purpose
of the car.
This is, of course, my personal opinion; nothing
else.
Geoffrey Summerhayes
"thelifter" <thel...@gmx.net> wrote in message news:b295356a.02112...@posting.google.com...
In a not so recent thread:
http://groups.google.ca/groups?q=g:thl3655066113d&dq=&hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.21.0011230838390.496-100000%40ajohnson.21st
century.net
--
Geoff
Kenny Tilton
I know what you are saying, but...
1. have you ever run into a really bad gui that had you pulling your
hair out? at least on the down side, a bad gui can overwhelm an
otherwise good product.
2. i am also reminded of working with perfectly good compilers thru
crummy IDEs. I get to the great functionality /thru/ the surface
presented to me, so the gui seems to matter. look how Emacs-ers rave
over their interace to languages.
3. on the flip side, cells let me easily give users a great experience,
so I give them one. without a killer gui mechanism, i could not afford
the effort to provide such a great experience, and the app in toto would
be worse.
In the end it probably varies from app to app. Deep Blue's GUI has
little opportunity to add value to a great chess engine. But something
like Photoshop, where the internal capabilities are astonishing,
probably depends as much for its success on its interface as its guts.
Gabe Garza
> On Fri, 29 Nov 2002 00:53:13 -0800, Software Scavenger wrote:
>
> > Give an example of something of more substance.
>
> Communication protocols, databases, FFTs, cryptography
> and security - just about anything is of more substance than
> GUIs. To me, GUIs are like the leather seats, A/C, radio/CD
> and other gizmos that cars these days come equipped with -
> nice, even slick, but not the essential to the main purpose
> of the car.
>
Trying telling your manager that the GUI isn't essential, and the
people on the floor--the same ones who sometimes need training on how
to use a mouse--can just use the command line...
Not everybody always gets to write programs of "substance," and even
programs of substance need an interface (sometimes even graphical,
unless your clients still use VT420's).
Gabe Garza
Chris Gehlker
b295356a.02112...@posting.google.com, "thelifter"
<thel...@gmx.net> wrote:
I suspect it's a factor but not the most important one. Here are what I
think are the important points in very rough order.
1) Be an automation language. The biggest "winner" of all time is Visual
Basic. It's the automation language of Windows. Given that, it can be
horrible in every other respect. Lisp is a scripting language of a few apps
and that fact account for some of its popularity. It's good to be a
scripting language. It's better to be an automation language.
2) Have a big company behind the language. Lisp ain't in Visual Studio. Nor
is it being actively promoted by Sun/IBM. Nough said.
3) Have a reputation for being easy. Basic again.
4) Be fast on cheap hardware. This was C++'s claim to fame. Most of the
programs that lots of people use every day are written in C++.
Note that where Java has found its niche is mostly in middleware were the
gui doesn't matter. I can count on the fingers of one hand the number of
significant GUI java apps.
I'm *not* trying to say that a Lisp GUI builder wouldn't be a good thing. I
just think it's not the most important thing.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Tim Bradshaw
> 1. have you ever run into a really bad gui that had you pulling your
> hair out? at least on the down side, a bad gui can overwhelm an
> otherwise good product.
That's what command lines are for!
> 2. i am also reminded of working with perfectly good compilers thru
> crummy IDEs. I get to the great functionality /thru/ the surface
> presented to me, so the gui seems to matter. look how Emacs-ers rave
> over their interace to languages.
And this is also what command lines are for: allowing a simple
interface to emacs. The only purpose of *anything* is to interface to
emacs.
--tim (:-)
thelifter
>
> Great. When are _you_ going to start working on it?
>
This is not relevant at all. The people should be convinced by the
arguments, not by me doing it or not. Wouldn't you stop smoking even
if the doctor who told you so is a smoker?
Think...then talk...
Donald Fisk
I think the problem is that the word GUI is nowadays understood
to be the sort of interface you got on programs written in RPG3
and displayed on IBM 3270s in the dim and distant past -- forms
interfaces in other words.
GUI to me means graphics -- ideally 3D, and imaginative ways
of interacting with the computer -- not clicking on buttons with
your mouse and typing text into dialog boxes. You get GUIs in
computer games, but not in much else.
Perhaps look at what Nichimen Graphics were doing
(http://www.franz.com/success/customer_apps/animation_graphics/nichimen.lhtml).
I wonder what language they were using?
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs, sex, and rock & roll. Late nights at Berkeley, coding in
Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd,
with no life or social skills.
Thomas F. Burdick
> Lovecraftesque <Lovecra...@yahoo.com> writes:
>
> > On Fri, 29 Nov 2002 00:53:13 -0800, Software Scavenger wrote:
> >
> > > Give an example of something of more substance.
> >
> > Communication protocols, databases, FFTs, cryptography
> > and security - just about anything is of more substance than
> > GUIs. To me, GUIs are like the leather seats, A/C, radio/CD
> > and other gizmos that cars these days come equipped with -
> > nice, even slick, but not the essential to the main purpose
> > of the car.
>
> Trying telling your manager that the GUI isn't essential, and the
> people on the floor--the same ones who sometimes need training on how
> to use a mouse--can just use the command line...
They can, and in fact, might have an easier time, using a
character-terminal interface. When you have pretty pictures and
buttons and menus, people get lazy and make far worse UIs than they
did when all they had was a character terminal, so they knew they had
to pay attention to the UI.
So, uh, yeah, I'm only objecting to the "G" in there -- graphical or
no, a good UI is essential to a complete program.
> Not everybody always gets to write programs of "substance," and even
> programs of substance need an interface (sometimes even graphical,
> unless your clients still use VT420's).
(Not that I'm claiming character terminals were better, just that they
forced people to think about UI more often -- lord knows the
attrocities people sometimes commited on them were even worse than the
bad GUIs you often see today)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
cr88192
I agree with this. it is just so far that I have not bothered to write
gui's (as I am sufficiently lazy to not bother, partly because the langs I
use make it *so* annoying...), but for practical applications I can see why
they are needed.
I respect cl and think whatever can be written for it is good, but for me I
enjoy the fun of creating my own system and doing things however I want
(actually now the basic language has mostly stabilized, so now a lot of
effort is going into api type things and generally building a system on top
of my lang).
it doesn't matter so much that it is practical, as enjoyable also works.
some more recent changes (ie: pattern matched functions) did't require much
change to the c side of things (all that was really required was adding
bound?). the rest could be pulled off making use of my object system (this
is one thing I like). I would seriously dislike having to go back to class
based systems, I think working for a while with a "unitype" object system
sort of caused a dislike for the class-based approach (in the object all
objects were essentially the same "class", which had all the possible
fields present). in different code you could add fields if you wanted, and
make use of them for whatever purpose (the weirdness being that the fields
silently appeared in all the objects in the system). however though, the
structure of objects was fixed at compile time. this was not quite the same
as a prototype system, but it was close enough to spoil me...
I hope eventually to put all this back on top of my os kernel, though some
of the cooler stuff now could not exist in the kernel given that I would
have to write drivers for a few things (ie: video card, network card, and
mouse). the gui would need a large scale rewrite to work on anything other
than gl, however eventually I plan to rewrite/clean it up (seperating the
gui stuff from rendering stuff, and writting a software renderer).
a lot of what I have now is intended to be a prototype for a future write
(which could be done better).
slightly ot is that I have 3d crap in my gui. nothing really major, but I
was trying to work out some of the details of tieing together 2d and 3d
stuff (most of this was written yesterday).
if my lang does not work well for something, it seems to be modeling. I had
hand converted some models from an older format of mine to my lang, and can
see that it looks quite ugly.
the reason is that geometries involve a lot of vertices, which take up much
space. in the process of conversion I had to make heavy use of
"mr. linebreak", as representing vertices on their own lines was even
ugglier than using linebreaks.
actually I think a lisp using s-expression syntax could handle this better,
mostly because line breaks are not significant with s-expressions (sadly it
is not like I can fully switch between my syntax and a more fully
s-expression form in the same file).
to make use of s-expressions would require keeping models in different
files from the rest of the code (unless one wants to write s-exprs), but
this kind of seperation is better style anyways...
otherwise it is ok.
this morning I have started implementing networking. I am re-absorbing some
of my older code and rewriting it as my api's have changed since then (and
I am working with a not-fully completed network api, which has merged with
the files api...).
I then started having to implement send and recieve for udp, based mostly
on that read and write do not pass sufficient info, then thinking of using
my ioctl-like interface made me think "ick...".
I will then tie this into my vm, which is planned to think in terms of
messages (the network details will be conviniently wrapped...).
networking is another thing I view as needed, but an actually worthwhile
networking api (both flexible and avoids having to mess with the lower
level network crap...) I imagine as better.
several interfaces will exist:
socket-pid pid address-def
creates a socket which routes it's output to a given pid, and is output to
as a response to those messages.
socket-msg address-def
creates a message driven socket, one has to send messages to and recieve
messages from this one.
socket-raw address-def
creates a socket accessible as a port/stream.
if only I were more imaginative here, and not just ripping crap off...
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Software Scavenger
> On Fri, 29 Nov 2002 00:53:13 -0800, Software Scavenger wrote:
>
> > Give an example of something of more substance.
>
> Communication protocols, databases, FFTs, cryptography
> and security - just about anything is of more substance than
> GUIs. To me, GUIs are like the leather seats, A/C, radio/CD
> and other gizmos that cars these days come equipped with -
> nice, even slick, but not the essential to the main purpose
> of the car.
The GUI is like the steering wheel, the brake pedal, the hood
release, the gas tank cap, the light switch, etc. The A/C can
sometimes be essential to the main purpose of the car, if you want
to drive in a very hot place without risk of heat stroke. The
radio can give you important information about road conditions etc.
The music can help you stay in a good mood in spite of those conditions.
If you just want to travel, regardless of comfort and convenience,
why not take a bus?
The bulk of the work of most software development is to make it fit
in well with its environment. The algorithms you consider to be the
"substance" are a minor part of it. Compatibility with other software
and with the users who will be using it is a much bigger part of the
work, and therefore should be considered to be of more "substance."
The things of "substance" you mention are, like a GUI, for comfort,
convenience, and compatibility. A GUI is for compatibility with the
user. A communication protocol is for compatibility between machines
that need to communicate. A database is for compatibility between
those who store data and those who retrieve it. The interesting
aspect of FFT alogorithms is their speed, which is for convenience.
Cryptography and security are for comfort and safety, just like an
air conditioner is, or the ignition key of the car.
One reason why a lot of programmers hate GUI work is that most GUI's
suck. You put a lot of work into them and you just get a complicated
clumsy constricting awkward GUI mess, where the user actually has to
do more work than necessary just to work around the limitations of the
GUI. But it doesn't have to be that way. GUI work is an art, and we
need more people to practice it more and better, till the quality of
the product improves enough that users will no longer tolerate low
quality GUI's once they are used to higher quality.
thelifter
>
> http://sourceforge.net/projects/cl-sdl/
>
> ...and sure enough I managed to get it up and running. I have a pretty
> full-blown app framework that uses win32 for little more than events and
> drawing, so with luck we could have a universal CL app framework in a
> month. (It took me that long to move from a Mac version to an ACL
> version, so ACL to SDL might be the same.)
But is this really what we want? If I understand it correctly using
SDL we will have:
Lisp -> SDL -> native OS calls.
What we wanted:
Lisp -> native OS calls.
So we have added an additional layer. Doesn't Tcl/Tk offer us the same
as SDL(regarding GUIs)?
Lisp -> Tcl/Tk -> native OS calls.
So what do we gain by using SDL?
Also, if I understood SDL correctly it is for making games(graphics,
sounds) and NOT specifically for GUIs. Of course you can also draw
GUIs with it, but for me it sounds like a bit overkill.
Just some thoughts...
Kenny Tilton
thelifter wrote:
> Kenny Tilton <kti...@nyc.rr.com> wrote in message news:<3DE71E8D...@nyc.rr.com>...
>
>> http://sourceforge.net/projects/cl-sdl/
>>
>>...and sure enough I managed to get it up and running. I have a pretty
>>full-blown app framework that uses win32 for little more than events and
>>drawing, so with luck we could have a universal CL app framework in a
>>month. (It took me that long to move from a Mac version to an ACL
>>version, so ACL to SDL might be the same.)
>
>
> But is this really what we want? If I understand it correctly using
> SDL we will have:
>
> Lisp -> SDL -> native OS calls.
yep. or i might punt on SDL if it gives me fits and then make GLUT
interactive-development-friendly and just use that (with just OpenGL).
But this way I get to leverage the CL-SDL project, who are saving me the
trouble of gluing Lisp to OpenGL. And saving me the lesser trouble of
patching up GLUT.
There is little chance this project of mine will get done anyway, so
anything to improve the odds.
>
> What we wanted:
>
> Lisp -> native OS calls.
Yes, but we also wanted universality and we didn't want least common
denominator, so this is a huge effort. The right way to go once everyone
realizes how brilliant Cells are and agrees to pitch in on a native project.
>
> So we have added an additional layer. Doesn't Tcl/Tk offer us the same
> as SDL(regarding GUIs)?
I just installed it. Looks good. Small, almost irrelevant issue: does it
measure up to SDL on video, audio, etc? More important: is Lisp-TK dead?
The link to it from Cliki is.
>
> Lisp -> Tcl/Tk -> native OS calls.
>
> So what do we gain by using SDL?
SDL is a lot thinner/low-level. My way, the widgets and overall app
framework will all be in Lisp. That gives us control over that. The only
thing not in Lisp, really, will be the OpenGL and event stream. I see
they do file I/O as well.
If I actually do this (ha!) one early enhancement might be to make the
event stream native (CL talking to OSes thru conditionalized code).
>
> Also, if I understood SDL correctly it is for making games(graphics,
> sounds) and NOT specifically for GUIs. Of course you can also draw
> GUIs with it, but for me it sounds like a bit overkill.
You think a "oops, the app crashed" box showing a clip of Leonardo
riding the Titanic's butt into the North Atlantic is too much? :)
OK, yep, but OpenGL is universal, and universal is the Prime Directive.
Close second is Lightweight aka As Much As Reasonable in CL. And for
God's sake, Dont Kill Kenny! (keep it simple)
Bear in mind that I am pulling back the scope of this by punting on
native widgets/look-n-feel. So it maybe actually gets done. And I have a
sneaky suspicion there may be enough compensating advantages to the
resulting project that folks may talk themselves out of the native
worry. But first let's see if I do it. :)
Gabe Garza
> Gabe Garza <g_g...@ix.netcom.com> writes:
> > Trying telling your manager that the GUI isn't essential, and the
> > people on the floor--the same ones who sometimes need training on how
> > to use a mouse--can just use the command line...
> They can, and in fact, might have an easier time, using a
> character-terminal interface. When you have pretty pictures and
> buttons and menus, people get lazy and make far worse UIs than they
> did when all they had was a character terminal, so they knew they had
> to pay attention to the UI.
Personally, I like command lines. Or even better--a GUI that
incorporates a command line, like Genera's listener or a lot of the
things you can do with CLIM. But...
I'm a developer in a "Fortune 15" company, and if I tried to release
an application without a windows-like GUI I'd be laughed at. Maybe a
command line or a character terminal interface would be more
efficient, and intuitive to the user for some of what I've done. But
that doesn't matter.
Megacorp users expect an application to look and feel a certain way.
If it doesn't, they're likely to throw up there hands and not even
give it a chance. For a lot of users, just learning the basics of
using a regular Windows application is a big investment of time and
effort--they'd run screaming from something different. I'm fortunate
in that most of my programs are servers and I only have to deal with
this occaisonally...
> So, uh, yeah, I'm only objecting to the "G" in there -- graphical or
> no, a good UI is essential to a complete program.
Situations vary a lot, but you'd be surprised just how important the
"G" is to the unwashed masses. At least in my professional situation,
it has to be there. The ultimate reason why may be "just because,"
but there's no getting around it...
> (Not that I'm claiming character terminals were better, just that they
> forced people to think about UI more often -- lord knows the
> attrocities people sometimes commited on them were even worse than the
> bad GUIs you often see today)
Amen!
Gabe Garza
Kenny Tilton
Gabe Garza wrote:
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>>Gabe Garza <g_g...@ix.netcom.com> writes:
>>
>>>Trying telling your manager that the GUI isn't essential, and the
>>>people on the floor--the same ones who sometimes need training on how
>>>to use a mouse--can just use the command line...
>>
>
>>They can, and in fact, might have an easier time, using a
>>character-terminal interface. When you have pretty pictures and
>>buttons and menus, people get lazy and make far worse UIs than they
>>did when all they had was a character terminal, so they knew they had
>>to pay attention to the UI.
>
>
> Personally, I like command lines.
Last time I worked in tall buildings it was vax/vms; love them command
lines and keypad editing.
By the same token, I like building gui interfaces from scripts, not in a
graphical interface builder.
kt
cr88192
> By the same token, I like building gui interfaces from scripts, not in a
> graphical interface builder.
>
Matthew Danish
> Kenny Tilton <kti...@nyc.rr.com> wrote in message news:<3DE71E8D...@nyc.rr.com>...
> >
> > http://sourceforge.net/projects/cl-sdl/
> >
> > ...and sure enough I managed to get it up and running. I have a pretty
> > full-blown app framework that uses win32 for little more than events and
> > drawing, so with luck we could have a universal CL app framework in a
> > month. (It took me that long to move from a Mac version to an ACL
> > version, so ACL to SDL might be the same.)
>
> But is this really what we want? If I understand it correctly using
> SDL we will have:
>
> Lisp -> SDL -> native OS calls.
>
> What we wanted:
>
> Lisp -> native OS calls.
Tell me: why might C programmers use libSDL? After all,
C -> SDL -> native OS calls -> graphics hardware
instead of
C -> native OS calls -> graphics hardware
Let's go further; why not
C -> graphics hardware
?
> Also, if I understood SDL correctly it is for making games(graphics,
> sounds) and NOT specifically for GUIs. Of course you can also draw
> GUIs with it, but for me it sounds like a bit overkill.
Yes, this is true. CL-SDL is not a graphical user interface project.
It's a 2D and 3D graphics library project, and the aim is to provide a
consistent interface across all platforms. Much like the SDL project
itself. So why not take advantage of their hard work?
CL-SDL by itself isn't enough to be a GUI, but I understand that Kenny
Tilton is working on such a toolkit using CL-SDL and OpenGL as the
drawing layer. IIRC, Mac OS X 10.2 does something similar; it uses
OpenGL to render its GUI toolkit. Given the wide availability of
accelerated OpenGL video hardware, it seems like a sensible way to go.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Kenny Tilton
Matthew Danish wrote:
>>Also, if I understood SDL correctly it is for making games(graphics,
>>sounds) and NOT specifically for GUIs. Of course you can also draw
>>GUIs with it, but for me it sounds like a bit overkill.
follow-up thought: perhaps games are to graphics strength as AI was to
programming language strength. ie, the tough requirement leads to a
generally better tool, better even for other things than the original
requirement.
Chris Gehlker
<g_g...@ix.netcom.com> wrote:
> Situations vary a lot, but you'd be surprised just how important the
> "G" is to the unwashed masses.
Aren't we, all of us, not just Gabe, being a little condescending here?
> At least in my professional situation,
> it has to be there. The ultimate reason why may be "just because,"
> but there's no getting around it...
With the exception of text editors and some MIDI programming, the GUI is
essential. I've tried to work with non-Gui spreadsheet programs. Not fun and
not productive. And there is a clear reason why GUI programs blew away the
competition in CAD, photo editing, drawing and entertainment. Even
Mathematica would be a pale shadow of itself without GUI layout. GUI doesn't
just mean widgets.
Erik Naggum
| Personally, I like command lines. Or even better--a GUI that
| incorporates a command line, like Genera's listener or a lot of the
| things you can do with CLIM. But...
|
| I'm a developer in a "Fortune 15" company, and if I tried to release an
| application without a windows-like GUI I'd be laughed at. Maybe a
| command line or a character terminal interface would be more efficient,
| and intuitive to the user for some of what I've done. But that doesn't
| matter.
I honestly fail to see the problem. A so-called command-line interface
is indistinguishable from a protocol if it is intelligently designed, like
the Common Lisp read-eval-print-loop. A more MTV generation-friendly user
interface can then be built independently and either talk the protocol or
call the functions directly depending on how tight you want the coupling.
If you design your "graphical" user interface so the coupling is so tight
you cannot de-couple the user interface from the code, you have designed
it very weakly to begin with. However, designing protocols must be rocket
science or something since so few people seem to get them right. In my
view, however, a user interface /is/ a protocol whether it uses a sequence
of characters or a sequence of events. The so-called event loop in these
newfangled user interfaces is no harder to program and design for than
intelligently designed command loops. Of course, Windows victims never
quite grasp what a command-line user interface /could be/ because of the
braindamaged command-line they are used to from MS-DOS.
Users want menus of options, some say. Well, that is not as incompatible
with command-line interfaces as some believe. Interactive help functions
and even predictive help functions have been implemented successfully, but
as the mouse crowd has taken over completely, many command-line interfaces
do little more than allow the barest input line editing because designers
think in terms of window-system events and not in terms of user actions.
And, of course, there is the throwback to mainframe-style forms input that
is not even as powerful as the forms processing languages of the past, on
the so-called "web", where even the state information of the past is not
actually available to the programmers although it may be faked. All in
all, the main reason so many users want only one particular user interface
style is that the one they had to learn is so goddamn braindamaged and
hard to learn that they fear every user interface must be equally rotten
and random and so prefer a consistently rotten user interface to a smart
user interface that is not rotten. It is one of those ways that Microsoft
/really/ locks their users into their system: Give them something they
market as "user-friendly" which it most certainly is not, and pretend that
everything else even worse. By usurping the term "user-friendly" to mean
their particular way of doing things, they effectively destroy all hope of
creating actually user-friendly user interfaces. Since the Linux crowd
is also lacking in insight and have been overexposed to the Windows ways,
nothing good will come out of that camp this decade, either.
It is hard to be a user these days.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Gabe Garza
> * Gabe Garza
> | Personally, I like command lines. Or even better--a GUI that
> | incorporates a command line, like Genera's listener or a lot of the
> | things you can do with CLIM. But...
> |
> | I'm a developer in a "Fortune 15" company, and if I tried to release an
> | application without a windows-like GUI I'd be laughed at. Maybe a
> | command line or a character terminal interface would be more efficient,
> | and intuitive to the user for some of what I've done. But that doesn't
> | matter.
>
> I honestly fail to see the problem.
The problem is that users demand a certain style of interface and
aren't willing/able to consider something else--which makes a native
"widgety" interface necessary unless you're willing to write the
interface in a second language and interface it to Lisp through the
implicitly constructed protocol you mentioned. You described the
problem well and even managed to give a plausible explanation that
blames Microsoft. Bravo. ;)
> If you design your "graphical" user interface so the coupling is
> so tight you cannot de-couple the user interface from the code,
> you have designed it very weakly to begin with.
Ironically, I think this would less often be a problem in a "Lisp with
native GUI interface" then in other languages because of the way Lisp
systems tend to get built from the bottom up. In contrast, languages
that either force or encourage programs to be built from the interface
back can (but of course don't always...) suffer greatly from this (at
least in my limited experience).
> Since the Linux crowd is also lacking in insight and have been
> overexposed to the Windows ways, nothing good will come out of
> that camp this decade, either.
I don't expect any crowd to come up with (or revive!) a style of user
interface that will pose any kind of challenge to the status quo.
But then, I'm a bitter pessimist over here in my little corner of
corporate bliss.
Gabe Garza
Patrick W
> With the exception of text editors and some MIDI programming, the GUI is
> essential. I've tried to work with non-Gui spreadsheet programs. Not fun and
> not productive. And there is a clear reason why GUI programs blew away the
> competition in CAD, photo editing, drawing and entertainment. Even
> Mathematica would be a pale shadow of itself without GUI layout. GUI doesn't
> just mean widgets.
Sure. There's a big difference between using graphics to *display*
information (of whatever kind), and using graphics to *interact* with
a system. Too many people assume that a software product's "skin"
should be either wholly graphical or wholly text-based, whereas a good
implementation of the middle path (graphical display w/ text-based
interaction) could be a far more powerful and flexible way of
interacting with a computer.
Pratibha
I thought Graham
e.g., http://www.paulgraham.com/road.html
said that the future isn't desktop GUI anymore but web
server-based apps? That although the browser GUI is
not so powerful, it is "good enough"?
Speaking of which, if you have a Lisp app server and you
want to generate a graphic (e.g., a plot) to be seen
on a browser as well be printable by the browser user,
is there an approach that satisfies all of the following:
- "high quality" screen as well as printed version (e.g.,
PostScript or PDF quality and expressive power for the
printed version)
- screen version shown "directly" on web page
like an image*, instead of having to have Acrobat Reader
plugin get loaded and display on a separate, new page
- does not require separate code to generate the screen
and printed versions
* Is it the case that the only way to embed a graphic in a
web page is to make it an image and use <IMG> --- HTML
has no graphic or drawing operators, does it?
Gabe Garza
> > What do you all think?
>
> I thought Graham e.g., http://www.paulgraham.com/road.html said that
> the future isn't desktop GUI anymore but web server-based apps?
> That although the browser GUI is not so powerful, it is "good
> enough"?
That's a very scary vision of the future.
> Speaking of which, if you have a Lisp app server and you
> want to generate a graphic (e.g., a plot) to be seen
> on a browser as well be printable by the browser user,
> is there an approach that satisfies all of the following:
>
> - "high quality" screen as well as printed version (e.g.,
> PostScript or PDF quality and expressive power for the
> printed version)
>
> - screen version shown "directly" on web page
> like an image*, instead of having to have Acrobat Reader
> plugin get loaded and display on a separate, new page
>
> - does not require separate code to generate the screen
> and printed versions
If I had to do all these things, I'd use Lisp to write command and
data files for gnuplot...
> * Is it the case that the only way to embed a graphic in a
> web page is to make it an image and use <IMG> --- HTML
> has no graphic or drawing operators, does it?
HTML doesn't have any, but you can generate and serve dynamic graphics
in a variety of ways (with a cgi script, with a response function or
equivalent in an embedded web server, etc.)
Gabe Garza
Kent M Pitman
> People where discussing a GUI for Lisp. The point is that there seems
> to be not good solution.
There is no single canonical solution, but there are many very adequate
solutions.
CAPI from LispWorks provides an excellent GUI interface that spans
PC Windows and X Windows.
Common Windows on Allegro is also an excellent native GUI.
I've heard that Corman CL has tight integration with native GUI, but I
don't know the details.
Macintosh Common Lisp is well-reknowned for its tight integration with the
Mac toolbuilding set.
CLIM (available for the Mac, for Allegro, and for LispWorks) provides
very innovative approach to windowing.
I've heard that there's a Garnet toolkit that offers a good windowing
interface on one or more Lisp platforms, but I don't know the details.
> Java my be a shitty language but it has a GUI. So in practical terms
> it wins.
Java certainly wins for a great many political reasons not related to the
availability or non-availability of a GUI.
> I think we could make Lisp much more popular if we started to make a
> good GUI for it.
I don't.
First of all, GUIs exist. Maybe you mean you want a common interface that
is community accepted, and that might not be terrible. But even so, it
would take more than that to "make Lisp popular".
I daresay that there are few actual applications that are worth doing
commercially which are being held back for lack of a good GUI
capability. If you want to make Lisp popular, concentrate on coming
up with a practical business need. If you have a proper business story
and a good product, the interface is going to be a mere detail.
> When I say GUI I mean that it should be easy to make a GUI using Lisp,
> not that the language needs a GUI itself.
If you are having trouble doing GUI building, and you need something like
Java or Visual Basic has, you should investigate the extremely high quality
GUI builder available in Franz Allegro. It doesn't get any easier than
that.
> What do you all think?
I think you haven't looked around enough.
I think you aren't focused on the right things.
I'm not denying there is public resistence to Lisp. I'm just saying
that the answers are not so simplistic as "if only there were an xxx"
for various "xxx" tools, because implementations have come up with these
tools and Lisp has not, as a consequence, rocketed to success.
The problem of Lisp's acceptance is a long-standing political one.
People often cite superficial objections in various places where they
want to keep Lisp out, but if you overcome those objections you often
find other objections behind them because the real objections are often
emotional, not technical.
What will get people interested in Lisp is evidence of business success.
There is a lot of good mechanism available for building such successes.
The concentration on "technology" and not on "business" is what is holding
things back, IMO. Crank out those killer apps, and people will come.
Don't, and no one will care.
Just one person's opinion, of course.
cr88192
>> What do you all think?
>
> I thought Graham
> e.g., http://www.paulgraham.com/road.html
> said that the future isn't desktop GUI anymore but web
> server-based apps? That although the browser GUI is
> not so powerful, it is "good enough"?
>
I skimmed through and thought: no, I don't think this is a long term
target. if anything this is a transition target.
I put a little more of my money on decentralized grid computing, to me
anyways this makes more sense.
more scary would be if people were actually able to force everyone to use
such "asps", in which case not only do they control your system software,
but your whole user experience.
what if you want to be a creative user? what if you want to do something
they didn't have planned allready for you? ok then, you're sol.
a grid computer does not have so much of the cost that your experience is
controlled by a single party, but offers many of the advantages talked
about otherwise.
personally I would want to keep some of my data close, in a location
controlled by me, and other data out in the open, and yet other data
available to whoever is interested.
for now I am not developing a fully distributed system, first I aim to
build a concurrent system and build a distributed system on that.
my system will not have servers or controlling parties, only a mass of
nodes which swap data based partly on locatity and partly on the
interconnections of the data.
I had before thought out some of the protocol details, but it seems I never
implement things exactly as planned before. I almost have a concurrent
system, and it is allready persistent, I will use this as a base for
distribution. it will maintain loose synchronization, where synchronization
is kept more tight in some places (between nodes actively working on data),
but becomes looser as less activity is occuring on it.
data has temporary owners, and these owners are used for synchronizing
control. before was the definition of the control facilities, and how to
handle loss of reachability and similar.
it would be up to the creator to offer some info relating to control of the
information, and the plan is that this info will have an effect on the
protocol (some data may become read only once the owner goes down, other
data will just change owners, ...).
conceptually data will be live, rounding up nodes to do its bidding. ways
will be needed of controlling such data (sanity checks as it were, to limit
some data from gaining too many resources which were not offered
originally, or from endlessly replicating itself to gain control).
nevermind, thoughts are not very clear. I just don't like the idea of
web-apps becomming dominant (I use hotmail, and in many ways it pails
compared to a real email client, though the email clients I use can't
really use hotmail...).
anyone watch "max headroom"?...
compare with "serial experiments lain" or "chobits"...
different worlds as it were.
nevermind.
anyways, I am not one for trying to find "the next big thing"...
Thomas F. Burdick
> One reason why a lot of programmers hate GUI work is that most GUI's
> suck. You put a lot of work into them and you just get a complicated
> clumsy constricting awkward GUI mess, where the user actually has to
> do more work than necessary just to work around the limitations of the
> GUI.
And then there's the other result of most GUI's sucking, that Gabe
mentioned: most users won't even experiment with a nonstandard UI. A
few times, I've thought deeply about the best way to interface with a
particular program, and made a highly unorthodox, application-specific
GUI. Users who were willing to poke at things figured them out really
quickly, and said they were intuitive and easy-to-use. I was forced
to rewrite one to use a "standard" UI, and the other only attracted a
small niche of users because most weren't willing to experiment with
the UI at all.
That's another reason to hate GUI work.
Thomas F. Burdick
> I've heard that there's a Garnet toolkit that offers a good windowing
> interface on one or more Lisp platforms, but I don't know the details.
The current version runs on at least CMUCL. Probably also Allegro.
In the past, it has run on Macintosh CL, and if it's bit-rotted, it
shouldn't be hard to get it running there again. Just FYI, it is a
powerful toolkit, but it also comes with good development tools, like
a Garnet-specific inspector, an interface builder, and a
widget-construction tool.
Bruce Hoult
Gabe Garza <g_g...@ix.netcom.com> wrote:
> Erik Naggum <er...@naggum.no> writes:
>
> > * Gabe Garza
> > | Personally, I like command lines. Or even better--a GUI that
> > | incorporates a command line, like Genera's listener or a lot of the
> > | things you can do with CLIM. But...
> > |
> > | I'm a developer in a "Fortune 15" company, and if I tried to release an
> > | application without a windows-like GUI I'd be laughed at. Maybe a
> > | command line or a character terminal interface would be more efficient,
> > | and intuitive to the user for some of what I've done. But that doesn't
> > | matter.
> >
> > I honestly fail to see the problem.
>
> The problem is that users demand a certain style of interface and
> aren't willing/able to consider something else--which makes a native
> "widgety" interface necessary unless you're willing to write the
> interface in a second language and interface it to Lisp through the
> implicitly constructed protocol you mentioned. You described the
> problem well and even managed to give a plausible explanation that
> blames Microsoft. Bravo. ;)
As Erik pointed out, your application logic should *not* be intimately
tied to the user interface. I know that dreck such as MFC on Windows
makes it very very hard to do anything *other* than tie your application
and the interface together, but it's still a very bad thing to do.
I think there is some general concensus that Apple knows a thing or two
about designing and implementing GUIs. They have now for more than a
decade been pushing hard to get programmers to separate the application
from the user interface, using the mechanism of "AppleEvents" to do
this. AppleEvents provides some standard data types and verbs, plus it
is extensible by individual programs. If a program uses AppleEvents to
communicate between the UI and the engine then it is automatically
scriptable (using AppleScript or any other OSA-compatable language, such
as UserTalk (the language in Frontier)) AND recordable, such that user
GUI actions can be recorded at a high level of abstraction (*not* as
move the mouse here, click there etc) in human-readable form into a
script that can be replayed or modified. Support for AppleEvents is
built right into application frameworks such as MacApp (Apple), the
Think Class Library (Symantec), PowerPlant (Metrowerks) and Cocoa
(NeXT/Apple).
-- Bruce
Bruce Hoult
ibpra...@yahoo.com (Pratibha) wrote:
What you may be missing is that PDF has ways to embed URLs and other
objects that can be clicked. You can make your entire web page a PDF.
It's also pretty easy to generate programatically, though of course you
have to do your own layout.
There is also flash. Vector graphics, animation, but also a programming
language, forms, URLs etc etc. There are quite usable web sites done
*entirely* in flash, such as the one belonging to the Hell Pizza stores
here in Wellington <http://www.hell.co.nz>.
A web/browser interface doesn't necessarily mean HTML.
-- Bruce
Chris Gehlker
<kti...@nyc.rr.com> wrote:
> By the same token, I like building gui interfaces from scripts, not in a
> graphical interface builder.
Maybe it's just me, but I really like having both. I like to tweak the
script and see the results in the graphic interface builder.
Chris Gehlker
<patri...@yahoo.com.au> wrote:
This is exactly right. This is an area where purism is almost always a
mistake. I brought up MIDI programming because the input should be simply
playing the music on an instrument. There are a lot of process control apps
where the best UI will mix text with simply selecting a unit from a
representation of the physical plant on a touch screen. There are other apps
where "the right thing " is to have both a widget set and an
automation/scripting language interface.
Robert St. Amant
For flexibility in programming, this is true, but it's important not
to treat application-interface independence as the most important
issue. When programmers think of the interface as separate from the
application, what often happens is that they treat the interface as
frosting on the cake, and user interaction suffers for it. It's easy
to say, "Once I've got the application working, with all the proper
hooks in it, I can just add the interface and everything will work out
fine." In such cases, things usually turn out badly. For interactive
systems, figuring out where to separate interface functionality from
application functionality can be very tricky. It requires a lot of
thinking about both sides to do it right. (For example, in my
application program logic it might result in the cleanest design if I
get values X, Y, and Z from the user in that order, but a strict
ordering may not be ideal in the interface. I should be careful not
to allow unnecessary constraints to propagate from application to
interface, unless I've checked out how it will affect things in the
interface.) Of course, for good programmers who are aware of human-
computer interaction issues, this is not a problem, but not everyone
is a good programmer.
--
Rob St. Amant
http://www4.ncsu.edu/~stamant
Chris Gehlker
"Robert St. Amant" <sta...@haeckel.csc.ncsu.edu> wrote:
>> As Erik pointed out, your application logic should *not* be intimately
>> tied to the user interface. I know that dreck such as MFC on Windows
>> makes it very very hard to do anything *other* than tie your application
>> and the interface together, but it's still a very bad thing to do.
>
> For flexibility in programming, this is true, but it's important not
> to treat application-interface independence as the most important
> issue. When programmers think of the interface as separate from the
> application, what often happens is that they treat the interface as
> frosting on the cake, and user interaction suffers for it. It's easy
> to say, "Once I've got the application working, with all the proper
> hooks in it, I can just add the interface and everything will work out
> fine." In such cases, things usually turn out badly.
I think that they often turn out very well. Look at the ports that they
OniGroup has done. People rave about their interface design. In most cases,
they threw away the old interface and started from scratch, fitting a new
interface, or new interfaces, onto an existing model.
> For interactive
> systems, figuring out where to separate interface functionality from
> application functionality can be very tricky.
Not if you just separate them as far as possible. This is almost always the
right thing,
>It requires a lot of
> thinking about both sides to do it right. (For example, in my
> application program logic it might result in the cleanest design if I
> get values X, Y, and Z from the user in that order, but a strict
> ordering may not be ideal in the interface.
So the model shouldn't know anything about the order in which the user
manipulated the interface. I agree. This is an argument for decoupling.
>I should be careful not
> to allow unnecessary constraints to propagate from application to
> interface, unless I've checked out how it will affect things in the
> interface.)
If you decouple the interface from the model, there is no need to check
anything out. Constraints can't propagate because the guts of the program
are separate from the UI.
> Of course, for good programmers who are aware of human-
> computer interaction issues, this is not a problem, but not everyone
> is a good programmer.
It's true that good programmers design good interfaces and that good
programmers decouple the model from the UI. It doesn't follow that not so
good programmers should void decoupling. I think they should strive to
emulate good programmers.
Erik Naggum
| For flexibility in programming, this is true, but it's important not to
| treat application-interface independence as the most important issue.
| When programmers think of the interface as separate from the application,
| what often happens is that they treat the interface as frosting on the
| cake, and user interaction suffers for it.
I find this line of argument extremely puzzling.
| It's easy to say, "Once I've got the application working, with all the
| proper hooks in it, I can just add the interface and everything will work
| out fine."
Perhaps you are unaware of how "the interface" can be expressed in a
multitude of ways?
A good programmer will naturally design the user interface as part of the
application (how could it be otherwise?), but in such a way that it the
communication between the application and the user interface is through a
well-defined protocol instead of randomized event processing.
| In such cases, things usually turn out badly.
I think you should reveal your inductive basis: What, precisely, have you
observed that led you to this very strange conclusion?
| For interactive systems, figuring out where to separate interface
| functionality from application functionality can be very tricky. It
| requires a lot of thinking about both sides to do it right.
But it becomes a lot easier if you formulate the interface/interaction as
a protocol. Those who think in terms of the graphic interaction when
they should have been thinking about the information flow tend to get
/everything/ wrong.
| (For example, in my application program logic it might result in the
| cleanest design if I get values X, Y, and Z from the user in that order,
| but a strict ordering may not be ideal in the interface. I should be
| careful not to allow unnecessary constraints to propagate from
| application to interface, unless I've checked out how it will affect
| things in the interface.)
But this is so stunningly irrelevant!
| Of course, for good programmers who are aware of human- computer
| interaction issues, this is not a problem, but not everyone is a good
| programmer.
I am puzzled as to what you think this discussion is about.
A simple control question is perhaps in order: Do you think that it is
impossible to find /any/ boundary between code that communicates with the
user and code that communicates with other code? Or, phrased differently,
do you think it is impossible to find /any/ boundary between code whose
main if not only function is to produce information for user consumption
and code whose main if not only function is to produce values for other
code?
Robert St. Amant
I agree with most of the above. I wasn't arguing that decoupling is a
bad idea, rather that it's not sufficient to produce good interface
designs, and that not considering interface issues when building
applications has historically led to bad results. I'll look up some
references when I get the time.
marcel haesok
> Java my be a shitty language but it has a GUI. So in practical terms
> it wins.
As a lisp newbie, I am curious about your denigration of Java language. Is
LISP that great a language?
Gareth McCaughan
[someone else:]
> > Java my be a shitty language but it has a GUI. So in practical terms
> > it wins.
[Marcel:]
> As a lisp newbie, I am curious about your denigration of Java language. Is
> LISP that great a language?
Yes. (Did you really expect any other answer?)
It's not clear that calling Java "shitty" is really fair.
But its strengths are, um, quite different from Lisp's, so
it's not surprising that someone who likes Lisp a lot sees
Java as rather nasty.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Chris Gehlker
It certainly is not sufficient. For some types of applications it may be
necessary. For others, it's merely helpful.
> and that not considering interface issues when building
> applications has historically led to bad results.
No argument there.
Kenny Tilton
Oh, yeah, we all could go on for hours. One would have
more luck defending Java from "shitty" than questioning Lisp's perfection.
but java has static typing, does not have macros or multiple
inheritance, does not have generic functions, and it lacks sexpr
notation. oh yeah, and it is slow, as in not compiled to native code.
btw, most folks here do not think Lisp is perfect, that's just me.
hey, you tell us what you think as you get into it, yer asking the choir
about the sermon.
:)
Matthew Danish
> Marcel Haesok wrote:
>
> [someone else:]
> > > Java my be a shitty language but it has a GUI. So in practical terms
> > > it wins.
>
> [Marcel:]
> > As a lisp newbie, I am curious about your denigration of Java language. Is
> > LISP that great a language?
>
> Yes. (Did you really expect any other answer?)
>
> It's not clear that calling Java "shitty" is really fair.
I think there are some objectively bad things about Java. Consider the
ridiculous:
SomeLongName variable = new SomeLongName (...);
And the:
item = (SomeLongName)vector.get(i);
casting required everywhere. There are probably other examples too, but
the problem with these is that they require the name of the data type to
be hard-coded in many locations, which makes it very hard to change.
Java in general lacks helpful abstraction facilities such as macros and
higher-order functions, and forces you to write everything in terms of
its own peculiar brand of OOP.
Thus it doesn't surprise me that Lispers might denigrate Java ;-)
Gabe Garza
> Java in general lacks helpful abstraction facilities such as macros
> and higher-order functions, and forces you to write everything in
> terms of its own peculiar brand of OOP.
>
> Thus it doesn't surprise me that Lispers might denigrate Java ;-)
Those are all very good reasons to dislike Java, and I agree with
them. Personally, I hate Java for far less technical reasons. I've
become a Bitter Corporate Programmer, and I'm very fortunate in that I
get to use Lisp. But I get some grief for it--Java is nearly always
the language that's put forth as the best solution. Why is it the
best solution? Is it because you can develop quickly in it? Is it
because it has superb technical features? Is it because it's an
expressive language suitable for any kind of development? Is it
because it runs fast?
Nope! The above questions (true or not) don't matter at all, because
they are almost *never* asked--that's why I hate it. Java is pushed
and advocated because Sun throws an enormous amount of money at it.
They hand out leather jackets with the "Java" logo on them. They
bring it up at tasty, expensive, lunches. After hearing a tale of woo
about a project that uses a different language, they say that if it
was Java they would be willing to loan developers for free if such a
bind ever happened again. They organize tasty, expensive lunches
around Java education and bring in whomever they can, even the people
who aren't qualified *at all* to choose a language--just to increase
the internal pressure to use Java. They make it seem like such an
enormously important technology that if we don't use it and acquire
Java skills, our careers will go absolutely nowhere. I could go on and
on...
I hate Java passionately, though not primarily for technical reasons
(though are plenty of technical reasons to dislike it). In a social
sense, Java is a polar opposite of Lisp--it's language that seems to
have been invented as a corporate controlled Sun-benefitting populist
tool that everyone should use (preferably on a box with multiple Sparc
CPU's). Lisp is a language that was evolved by smart programmers into
a powerful tool that smart programmers can exploit to develop powerful
software (and even have fun at the same time).
I'm not trying to flame Java programmers or put Lisp programmers on a
pedestal. Smart programmers have written good software with both
languages. Nor am I saying that the previous paragraph is 100% pure
truth--I'm sure my views on Java are jaundiced by my professional
situation. Just interpret them as the thoughts of an idealist
who's seen Sun marketing at work...
Gabe Garza
Pratibha
> is indistinguishable from a protocol if it is intelligently designed, like
> the Common Lisp read-eval-print-loop.
Are there any examples, that we can look to for ideas or guidance,
of "intelligently designed" command-line interfaces designed for
end-users (as opposed to developers --- I assume that it is not
being suggested that a Lisp real-eval-print loop or Genera-like
command line or an emacs inferior Lisp buffer or a Unix shell be
surfaced to the end-user, but something that is more
application-specific, right.)
Are there any Common Lisp libraries to help construct such
interfaces? Are we talking about things like
command completion/history/editing/help, optional
and keyword arguments? Could or should it be done through
an emacs inferior-something buffer?
> And, of course, there is the throwback to mainframe-style forms input that
> is not even as powerful as the forms processing languages of the past, on
> the so-called "web", where even the state information of the past is not
> actually available to the programmers although it may be faked.
What were these "forms processing languages of the past", and is it
possible or worthwhile to reinvent/simulate them on the web (using
I assume the closures/continuation passing style technique
described by Graham)?
Erik Naggum
| Are there any examples, that we can look to for ideas or guidance, of
| "intelligently designed" command-line interfaces designed for end-users
| (as opposed to developers --- I assume that it is not being suggested
| that a Lisp real-eval-print loop or Genera-like command line or an emacs
| inferior Lisp buffer or a Unix shell be surfaced to the end-user, but
| something that is more application-specific, right.)
Why do you assume all this? And more importantly, /how/ did you arrive
at all these assumptions?
I need some evidence that you understand what a protocol is before I want
to explain the principles here further.
E.g., are you knowledgeable of how the Emacs command loop works?
Chris Gehlker
haesok" <novu...@attbi.com> wrote:
I don't hate Java. I think that Java hates me. I could give you "ten reasons
why Java sucks" but you can easily find them yourself with Google. The truth
is is that, for me at any rate, coding Java is less fun than programming in
many other languages. I'm not completely sure why that is.
Some of the problem is that it requires strong static typing but it doesn't
provide much support for strong typing. There is a good write-up on this
here:
http://perl.plover.com/yak/typing/notes.html
I'm not sure if that's the whole problem, though.
Paolo Amoroso
> The problem is that users demand a certain style of interface and
> aren't willing/able to consider something else--which makes a native
More precisely, they demand Microsoft Windows. At least in Italy, the so
called European Computer Driving License may be safely renamed European
Windows Driving License.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso
wrote:
> CLIM (available for the Mac, for Allegro, and for LispWorks) provides
> very innovative approach to windowing.
It is also being made available for other Lisp systems via McCLIM.
Paolo Amoroso
> Users want menus of options, some say. Well, that is not as incompatible
> with command-line interfaces as some believe. Interactive help functions
> and even predictive help functions have been implemented successfully, but
> as the mouse crowd has taken over completely, many command-line interfaces
> do little more than allow the barest input line editing because designers
> think in terms of window-system events and not in terms of user actions.
And maybe also completion.
Gareth McCaughan
> > It's not clear that calling Java "shitty" is really fair.
>
> I think there are some objectively bad things about Java. Consider the
> ridiculous:
>
> SomeLongName variable = new SomeLongName (...);
>
> And the:
>
> item = (SomeLongName)vector.get(i);
I hope you weren't expecting me to disagree :-).
Robert St. Amant
Comments at the bottom.
Sorry, I was interpreting "decoupling" too narrowly, thinking of it
only at what we might call the widget level. Thus I might build a
command line interface, and decouple it from the application so that
it runs cross-platform, but not realize that a lot more work would
need to be done to turn it into a direct manipulation interface.
I hope that helps make sense of my comments above.
Erik Naggum
| Sorry, I was interpreting "decoupling" too narrowly, thinking of it only
| at what we might call the widget level. Thus I might build a command
| line interface, and decouple it from the application so that it runs
| cross-platform, but not realize that a lot more work would need to be
| done to turn it into a direct manipulation interface.
|
| I hope that helps make sense of my comments above.
Sorry, no, it makes no sense at all. Why did you not try to answer my
control questions? What do you understand by "command line interface"
to begin with? It seems it is possible to think of this in extremely
concrete terms and that the point I am trying to hammer in, viz, the
nature of user interfaces as /protocols/, somehow does not register.
cr88192
> * Robert St. Amant
> | Sorry, I was interpreting "decoupling" too narrowly, thinking of it only
> | at what we might call the widget level. Thus I might build a command
> | line interface, and decouple it from the application so that it runs
> | cross-platform, but not realize that a lot more work would need to be
> | done to turn it into a direct manipulation interface.
> |
> | I hope that helps make sense of my comments above.
>
> Sorry, no, it makes no sense at all. Why did you not try to answer my
> control questions? What do you understand by "command line interface"
> to begin with? It seems it is possible to think of this in extremely
> concrete terms and that the point I am trying to hammer in, viz, the
> nature of user interfaces as /protocols/, somehow does not register.
>
what is being talked about varies depending on context.
a simple example would be a ui as one program talking to the main program
over some means like pipes or sockets, or via message passing of some sort.
my usual approach though is to define each end with a reasonably consistent
interface, thus allowing me to replace parts. a problem is that these
barriers tend to break down eventually, so later I go and seperate the bits
of code which are becomming overly interconnected.
in larger systems I break down connections more by writing point to point
io or messaging type interfaces. if too large I hack the system apart and
have the parts communicate via networking or similar and work as seperate
programs (I have had very few that have gotten to this point, and what ones
I had were split artifically as the split was planned anyways...).
I think the point being made was for the interface to be some degree
seperated from the other parts of the program (I am not sure to what degree
though). depending on context I would use the controlled interface or
message passing styles...
right now message passing is still a new toy for my current project, though
point to point io has been around for a while. networking was made
difficult as the messaging system is still not really finished (still a bit
hackish), and it was a bit of a pain trying to tie my messaging system into
other code (in this case the networking).
my system for extending the type system is not that good, and required
using objects as wrappers for the created types in order to fake the
desired behavior. networking (along with persistence) still needs a lot of
work before it will be useful.
at present I can pull off:
create handler for incomming messages;
create socket for input, directed at handler;
create socket for output;
send message out output socket directed at input socket to message handler.
the message gets to handler and then something screws up in the vm after
the recieved message is printed (not sure what). maybe I will work on it
more later (and in the process try to clean up the messaging/extended type
support).
my extended type support still needs to be cleaned up before I can really
support texture mapped geometries as well, what I had pulled together for
images is not sufficiently powerful to do texture mapping (mass lameness
that).
I lose point. I can't think well, head not working well now.
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Pratibha
> * ibpra...@yahoo.com (Pratibha)
> | Are there any examples, that we can look to for ideas or guidance, of
> | "intelligently designed" command-line interfaces designed for end-users
> | (as opposed to developers --- I assume that it is not being suggested
> | that a Lisp real-eval-print loop or Genera-like command line or an emacs
> | inferior Lisp buffer or a Unix shell be surfaced to the end-user, but
> | something that is more application-specific, right.)
>
> Why do you assume all this? And more importantly, /how/ did you arrive
> at all these assumptions?
> I need some evidence that you understand what a protocol is before I want
> to explain the principles here further.
I assume that we do not want to surface a raw REPL (i.e., a Lisp's
default REPL) [or a raw Unix shell] because that would allow the
end-user to type arbitrary Lisp forms [Unix commands], which would
be giving too much power and potential for damage. I assume that
an app-specific REPL [or shell] would be surfaced under control of
Lisp, just not *the* raw Lisp REPL [Unix shell]. Aside from too
much power, there is the question of whether we would want to
surface Lisp syntax to the end-user.
Actually, I agree in principle - in theory - in the abstract.
I just wanted to know if there are any existing *end-user*
applications that could be pointed to as practical examples
or models...that would qualify in your view as having an
intelligently designed CLI.
In my limited experience as *end-user* the only example I could
think of is the CLI of AutoCAD. Does that qualify?
> E.g., are you knowledgeable of how the Emacs command loop works?
No, I do not know the details. Would an emacs buffer tied to an
inferior Lisp process and surfacing an app-specific REPL
(not the raw Lisp REPL) be a good way to implement an
intelligently designed CLI for an *end-user*?
Could intelligently designed CLI be done through a web browser?
marcel haesok
"Kenny Tilton" <kti...@nyc.rr.com> wrote in message
news:3DE9902F...@nyc.rr.com...
>
> but java has static typing, does not have macros or multiple
> inheritance, does not have generic functions, and it lacks sexpr
> notation. oh yeah, and it is slow, as in not compiled to native code.
>
> btw, most folks here do not think Lisp is perfect, that's just me.
>
> hey, you tell us what you think as you get into it, yer asking the choir
> about the sermon.
I went through half of touretsky's book, and so far the
Brevity, power(functions) and versatility(list datatype)--- these are
very attractive--- I am quite hooked. I wish I had more
time to learn it quicker but I am having to learn C# for my job.
Hoping that we will soon see LISP hooked up with .NET.
I don't know anything about Java. Cheers. Happy to talk.
Erik Naggum
| I assume that we do not want to surface a raw REPL (i.e., a Lisp's
| default REPL) [or a raw Unix shell] because that would allow the end-user
| to type arbitrary Lisp forms [Unix commands], which would be giving too
| much power and potential for damage.
Oh, so you give preference to issues of too much power and potential for
damage. That explains a lot of your stubborn resistance.
| I assume that an app-specific REPL [or shell] would be surfaced under
| control of Lisp, just not *the* raw Lisp REPL [Unix shell].
What the hell is *the* raw Lisp REPL?
| Aside from too much power, there is the question of whether we would want
| to surface Lisp syntax to the end-user.
Oh, Christ. You have made up your mind about so much that communication
with you is a waste of time. Will you /please/ cut down on the assumptions
and your belief that you have already grasped everything there is to grasp
and just /listen/ to other people for a while? I refuse to shoe-horn what
I talk about into the pre-existing concepts of people who have not thought
about what I talk about. /THINK/ about something that is new to you, do
/not/ try to make it the same as you think everything else is, because if
it /were/, the opinions expressed by other people would be /redundant/
and by the law of relevance in communication, we try to communicate what
is the most important at all times, and that means at this time that you
have to stop believing that you have figured this out, already, when you
have not in fact grasped even the core principle.
| Actually, I agree in principle - in theory - in the abstract.
No, you do not yet understand. Cut this agreement crap and /think/.
| I just wanted to know if there are any existing *end-user* applications
| that could be pointed to as practical examples or models...that would
| qualify in your view as having an intelligently designed CLI.
Giving practical examples to people who do not think yields too much
potential for damage, and with can't have that.
| In my limited experience as *end-user* the only example I could think of
| is the CLI of AutoCAD. Does that qualify?
WTF is this nonsense about *end-user*?
Are you unable to grasp what I have said about letting the GUI talk a
/protocol/ to the rest of the application? Is that why you keep harping
on the same tired old strings? Is all that you can imagine a "CLI" that
talks to *end-users*? THEN WAKE UP! This is not what I am talking about.
I talk about something that you have obviously never thought about. If
you want to take part in the communication, then /think/ and /listen/ and
try to grasp things you have not already grasped.
| > E.g., are you knowledgeable of how the Emacs command loop works?
|
| No, I do not know the details.
"E.g." /means/ exampli gratia, and would have been a practical example if
you had been able to /listen/. Go read the documentation that comes for
free with Emacs about how a key is translated to a function call. Read
about the `interactive´ declaration in Emacs Lisp. Understand how this
declaration is related to the function's argument list. Be enlightened.
| Would an emacs buffer tied to an inferior Lisp process and surfacing an
| app-specific REPL (not the raw Lisp REPL) be a good way to implement an
| intelligently designed CLI for an *end-user*?
*NO* Will you cut down on emphasizing *end-user* and /think/?
| Could intelligently designed CLI be done through a web browser?
*NO* But intelligently designed Web interfaces could communicate with
the same protocol that a systems user (since you are so goddamn stubborn
about "end-users") would.
Damnit, will you please try to think about what it means for something to
be a /protocol/? Or do I have to return to the very basics and explain
this to you in novice terms? Please let me know what you already grasp
so I do not waste my time trying to communicate to someone who stubbornly
believes that what he hears is just like something he already believes.
You have consistently refused to answer any question that would shed
light on your present state of understanding. Why do you do this and
keep arguing against something you do not grasp?
And WTF am I wasting time on you? Give me a reason to continue.
Espen Vestre
> As a lisp newbie, I am curious about your denigration of Java language. Is
> LISP that great a language?
I'm sure java is an O.K. language, but every time i tried to learn it,
I felt asleep and dreamt that the world was caught in a time loop and
it was 1967 again.
--
(espen)
Espen Vestre
> As a lisp newbie, I am curious about your denigration of Java language. Is
> LISP that great a language?
I'm sure java is an O.K. language, but every time i tried to learn it,
I fell asleep and dreamt that the world was caught in a time loop and
Martin Thornquist
> Communication protocols, databases, FFTs, cryptography
> and security - just about anything is of more substance than
> GUIs. To me, GUIs are like the leather seats, A/C, radio/CD
> and other gizmos that cars these days come equipped with -
> nice, even slick, but not the essential to the main purpose
> of the car.
Some of us work with end-user applications, where arguably the GUI is
what the application is all about. As an example I'm working with a
stock quote viewer, the purpose of which is to present stock quotes in
the easiest to grasp way to the user -- what our users want is to get
the best possible view of the current stock situation in the shortest
possible time, to buy or sell at just the right time.
We are using LispWorks CAPI for this. I have not done much work with
other GUI libraries, but I find Common Lisp and CAPI eminent tools for
what we do. Not least because of cross-platform portability -- I
started developing the application with Windows LispWorks, and when we
decided we wanted a Linux version too, I just had to fix a few
filenames and some hard-coded window sizes. I think I had the code
running fine well within half an hour after getting LispWorks set up
on the Linux box.
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
Raymond Wiker
> On Sat, 30 Nov 2002 02:39:48 GMT, Gabe Garza <g_g...@ix.netcom.com> wrote:
>
> > The problem is that users demand a certain style of interface and
> > aren't willing/able to consider something else--which makes a native
>
> More precisely, they demand Microsoft Windows. At least in Italy, the so
> called European Computer Driving License may be safely renamed European
> Windows Driving License.
The situation is the same in Norway. In my mind, it's not
really a "Driving License"; more like a license to drive a vehicle of
limited power, like a scooter or one of those three-wheeled thingies.
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Robert St. Amant
> * Robert St. Amant
> | Sorry, I was interpreting "decoupling" too narrowly, thinking of it only
> | at what we might call the widget level. Thus I might build a command
> | line interface, and decouple it from the application so that it runs
> | cross-platform, but not realize that a lot more work would need to be
> | done to turn it into a direct manipulation interface.
> |
> | I hope that helps make sense of my comments above.
>
> Sorry, no, it makes no sense at all. Why did you not try to answer my
> control questions? What do you understand by "command line interface"
> to begin with? It seems it is possible to think of this in extremely
> concrete terms and that the point I am trying to hammer in, viz, the
> nature of user interfaces as /protocols/, somehow does not register.
I'll revisit your earlier post, though as I say, some of what I wrote
was based on a misconception of mine.
Erik Naggum <er...@naggum.no> writes:
> * Robert St. Amant
> | For flexibility in programming, this is true, but it's important not to
> | treat application-interface independence as the most important issue.
> | When programmers think of the interface as separate from the application,
> | what often happens is that they treat the interface as frosting on the
> | cake, and user interaction suffers for it.
>
> I find this line of argument extremely puzzling.
>
> | It's easy to say, "Once I've got the application working, with all the
> | proper hooks in it, I can just add the interface and everything will work
> | out fine."
>
> Perhaps you are unaware of how "the interface" can be expressed in a
> multitude of ways?
Yes, I agree.
> A good programmer will naturally design the user interface as part of the
> application (how could it be otherwise?), but in such a way that it the
> communication between the application and the user interface is through a
> well-defined protocol instead of randomized event processing.
>
> | In such cases, things usually turn out badly.
>
> I think you should reveal your inductive basis: What, precisely, have you
> observed that led you to this very strange conclusion?
My observation above was mainly about a development process in which
thought about interaction with the user takes a backseat to core
application functionality, which historically has been common, from my
reading of the human-computer interaction literature. (For example,
early efforts at changing command line interface applications to use
graphical user interfaces tended to produce pretty clunky interaction,
though it's hard to tell whether decoupling was an issue.) This was
perhaps a bit off-topic, but prompted by some of other posters'
comments about the value of user interface programming compared to
programming the innards of an application.
I think that a protocol governing the communication between the
application and its interface is a good thing. Because programming
takes time and effort, however, the protocols that I develop might not
be as flexible as I would have developed if I'd given forethought to
how the interfaces might change in the future. The example I gave
below would apply to a protocol in which control was not sufficiently
decoupled. If I always expect information to be given in some
specific order, I might build that order into the protocol, making
more work for myself if it changes because of a revision of the user
interface.
I don't think that those things are impossible. Is your question
phrased that way to point out that the user can be considered another
system component with its own very specialized requirements? I agree.
Mario S. Mommer
Kent M Pitman <pit...@world.std.com> writes:
>
> The problem of Lisp's acceptance is a long-standing political one.
> People often cite superficial objections in various places where they
> want to keep Lisp out, but if you overcome those objections you often
> find other objections behind them because the real objections are often
> emotional, not technical.
This is something that puzzles me so much. How can anyone get far by
rejecting technologies on emotional grounds? Isn't this a recipe for
disaster? OTOH, what might those emotional "reasons" be?
> What will get people interested in Lisp is evidence of business success.
> There is a lot of good mechanism available for building such successes.
> The concentration on "technology" and not on "business" is what is holding
> things back, IMO. Crank out those killer apps, and people will come.
> Don't, and no one will care.
Do you have ideas on what these killer apps might be? It seems to me
that nowadays "killer apps" are mostly so on a plane orthogonal to
technological quality. Think of the success of SMSes on mobile phones.
The thing with popularity is that it is always relative to an
audience. The "audience" that freaks out on Java has not much in
common, it seems to me, with those that dwell here in this NG. Their
interests and priorities are different, and thus the relative
"unpopularity" of Lisp might not be a "bad sign" at all. It might in
fact be utterly irrelevant.
This isn't to mean that there shouldn't be kewl ``Common Lisp''
leather jackets, or tasty, expensive lunches in its name :-)
Regards,
Mario.
Wade Humeniuk
"Mario S. Mommer" <m_mo...@yahoo.com> wrote in message
news:fzlm38w...@cupid.igpm.rwth-aachen.de...
>
> Kent M Pitman <pit...@world.std.com> writes:
> >
> > The problem of Lisp's acceptance is a long-standing political one.
> > People often cite superficial objections in various places where they
> > want to keep Lisp out, but if you overcome those objections you often
> > find other objections behind them because the real objections are often
> > emotional, not technical.
>
> This is something that puzzles me so much. How can anyone get far by
> rejecting technologies on emotional grounds? Isn't this a recipe for
> disaster? OTOH, what might those emotional "reasons" be?
>
The emotional reason is the acceptance by a large group.
Fitting in with what is viewed as right. Emotional security that
everyone else will sink or swim with you. Emotional support
in that someone else is doing the work and you can ride along.
Feeling good because your choices and thoughts are not
questioned. Many people's search for the truth invloves
finding someone or somegroup which agrees with them.
The example of say Java vs CL. Java is good enough to get
a job done, so rejecting the superior CL and going with Java
is a trade-off between emotional security and technological
grounds. Decisions like this never quite bring about disaster,
but they sure slow things down.
Wade
JB
> I don't hate Java. I think that Java hates me. I could
I sometime play chess at the Internet Chess Club. For MS
Windows there is a very good native interface but there is
none for Unix. The only candidate is called Jin and is
written in Java. It is unusable. It is extremely slow and
nowadays we have turn-around times between 100 and 200 ms
and it seems that Jin's slowliness matters.
Of course I cannot tell whether it is simply poorly
programmed or whether this is inherent to Java.
--
JB
Chris Gehlker
"JB" <jbl...@hotmail.com> wrote:
That's a perennial question. All the Java advocates I know argue strongly
that Java programs can be made as fast, or almost as fast, as C programs.
Yet the world is full of slow Java programs, some written by Sun and running
on Sun's hardware. I think part of the reason is that Java is much easier to
learn than it is to master. Another part of the equation is that the Java
compiler if free, as in beer, but it doesn't come with a profiler. Some
developers may simply lack the tools to make their Java programs fast. A
third factor is that fast on one platform doesn't mean fast on all
platforms. Maybe Jin performs fine on the platform where it was developed.
I personally have never used Java for anything that had to be fast. I talked
to one of the JBuilder team though, and they optimize it platform by
platform.
Thomas F. Burdick
> but java has static typing, does not have macros or multiple
> inheritance, does not have generic functions, and it lacks sexpr
> notation.
Yeah, this stuff is not fun. And its type support is particularly
crummy: static typing, but thanks to the sometimes necessity of
downcasting you can still get runtime type errors.
> oh yeah, and it is slow, as in not compiled to native code.
Er, no. It can be slow, but it doesn't have to be. And it can be
compiled to native code, it just uses a different compilation model[*]
than most languages. Java's got a similar problem to Lisp: it's easy
to write slow-as-hell code; but that doesn't mean you can't write fast
code. It *is* more difficult to write efficient code in Java though,
because of its impoverished abstraction facilities.
[*] You know, where the efficiency of the native code produced depends
on the *user's* setup, not on the developer's. Bleah.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Pascal Costanza
> On 12/2/02 11:13 AM, in article asg779$pmd1p$1...@ID-167393.news.dfncis.de,
> "JB" <jbl...@hotmail.com> wrote:
>
>
>>Chris Gehlker wrote:
>>
>>>I don't hate Java. I think that Java hates me. I could
>>>give you "ten reasons why Java sucks" [...]
>>
>>I sometime play chess at the Internet Chess Club. For MS
>>Windows there is a very good native interface but there is
>>none for Unix. The only candidate is called Jin and is
>>written in Java. It is unusable. It is extremely slow and
>>nowadays we have turn-around times between 100 and 200 ms
>>and it seems that Jin's slowliness matters.
>>Of course I cannot tell whether it is simply poorly
>>programmed or whether this is inherent to Java.
>
>
> That's a perennial question. All the Java advocates I know argue strongly
> that Java programs can be made as fast, or almost as fast, as C programs.
The element that usually slows down Java is the Swing GUI API (part of
Java's standard API). Switch to something better than Swing and you will
get a performance boost nearly for free. See for example the Eclipse IDE
that is based on SWT (Shared Widget Toolkit, part of Eclipse and can be
used in your own applications) - it feels quite fast, and what's even
more important, it feels like a native application (as in "developed
specifically for your current platform").
Another source of performance problems is the startup time of the JVM.
You shouldn't use Java for small programs, because it doesn't pay off
performance-wise. (However, AFAIK they have solved the latter problem on
Mac OS X, and that solution will be fed back to the Sun JVM. The
solution is roughly to keep the JVM in RAM so that you don't notice the
startup time later on. But I am not sure about this bit...)
Pascal
--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
Bruce Hoult
Pascal Costanza <cost...@web.de> wrote:
> Another source of performance problems is the startup time of the JVM.
> You shouldn't use Java for small programs, because it doesn't pay off
> performance-wise. (However, AFAIK they have solved the latter problem on
> Mac OS X, and that solution will be fed back to the Sun JVM. The
> solution is roughly to keep the JVM in RAM so that you don't notice the
> startup time later on. But I am not sure about this bit...)
Right. It seems that the the OS X JVM is a single shared server.
Also, they have mapped Swing to use the native GUI widgets, which gives
a good speedup as well.
-- Bruce
Chris Gehlker
"Pascal Costanza" <cost...@web.de> wrote:
>> Chris Gehlker wrote:
[snip]
>>
>> That's a perennial question. All the Java advocates I know argue strongly
>> that Java programs can be made as fast, or almost as fast, as C programs.
>
> The element that usually slows down Java is the Swing GUI API (part of
> Java's standard API). Switch to something better than Swing and you will
> get a performance boost nearly for free. See for example the Eclipse IDE
> that is based on SWT (Shared Widget Toolkit, part of Eclipse and can be
> used in your own applications) - it feels quite fast, and what's even
> more important, it feels like a native application (as in "developed
> specifically for your current platform").
>
This is good to know. I'll definitely try that if I ever do more Java
desktop stuff.
It is interesting that this thread started by asking if Java's hypothesized
popularity, despite its hypothesized suckyness, was due to it's integration
of a GUI library and now we find out that Java works better with a bolt-on
GUI kit.
I wonder if Java is really all that much more popular than Lisp. It
certainly gets more press but, as others have remarked, it's in the middle
of a marketing war with the .Net flavors. That makes for exciting ink.
Applets seem to be a fad that is mostly over and Java's middleware niche is
being invaded by Perl, Python, Ruby and arguably PHP. Lisp, OTOH, seems
secure in it's niche and, if you count all the folks messing with emacs and
AutoCAD, fairly widely used.
Kenny Tilton
Mario S. Mommer wrote:
> This is something that puzzles me so much. How can anyone get far by
> rejecting technologies on emotional grounds?
Wherever did you get the idea that humans are creatures of reason? Not
on Usenet, that's for sure. :)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"We're not machines like you, Spock!" -- "Bones" McCoy
Charlton Wilbur
CG> I wonder if Java is really all that much more popular than
CG> Lisp. It certainly gets more press but, as others have
CG> remarked, it's in the middle of a marketing war with the .Net
CG> flavors. That makes for exciting ink.
From what I've seen, Java is *far* more popular than LISP. This
probably doesn't hold true among the intelligentsia of programmers,
but you can take an informal poll by checking out the computer-books
section of your favorite bookstore. How many books are there on Java,
compared to how many books on LISP? (Can you even *find* a book on
LISP?)
CG> Applets seem to be a fad that is mostly over and Java's
CG> middleware niche is being invaded by Perl, Python, Ruby and
CG> arguably PHP. Lisp, OTOH, seems secure in it's niche and, if
CG> you count all the folks messing with emacs and AutoCAD, fairly
CG> widely used.
Java has two advantages over all the other languages you list.
First, it has a single, strong, corporate sponsor. The business
mindset seems to be that products tied to a corporate owner are
preferable to open source products because, should something break,
there is someone to sue.[1] This has other ramifications, such as
large budgets for glossy magazine ads. None of Perl, Python, Ruby, or
PHP can match this; the one that comes closest in visibility is Perl,
and that suffers terribly from its partially-deserved reputation. No
large company, fond of lockstep groupthink and of not doing anything
risky or experimental, is going to adopt Python, Ruby, or LISP over
Java; even Perl, as well-supported and widely-known as it is, causes
tremors of fear.
Second, it supports mediocre programmers well, which means that
management can treat programmers as interchangeable parts. Java's
paucity of higher-level abstractions suits the unwashed masses just
fine, because, frankly, they can't handle higher-level abstract
thought.[2] Java is safe because you know that nobody will be writing
code that confuses the Java-programming mediocrities; Perl is not
safe, because you have the triple demons of cryptic variable names,
implicit variables, and powerful abstraction. LISP is not safe,
because you have an incredible amount of power and abstraction. The
danger is not that you can't write basic, comprehensible code in a
given language, but that you might write something complex that the
plug-in replacement programmer might not understand. With LISP or
Perl, hiring an intelligent programmer[3] means that you can get
expressive, clear, powerful code written quickly. It also means that
when your first programmer leaves, you need to find an intelligent one
to replace him. With Java, you just hire one of the recent
interchangeable college graduates; it's impossible to do complex
abstract things in the language anyway, so you can be fairly certain
that anyone who can write basic Java will understand whatever your
prior programmer wrote.
Charlton
[1] This is essentially meaningless; I'm currently dealing with a
Java group that insists on using an application server that can't stay
running for more than about 12 hours; the application server support
staff say it's a problem in the JVM, and the JVM authors say it's
either a problem in our company's code or in the application server.
End result: the thing crashes twice a day, and the fact that this
comes from a corporate entity rather than from an open-source group is
largely irrelevant to our approach to fixing the problem -- except
that we don't have the source code, and can't fix it ourselves.
[2] Yes, this is elitist.
[3] No 'intelligent programmers don't use Perl' comments, please; Perl
has ugly syntax and a lot of cruft that comes from the past; it's also
one of my favorite languages because of its expressiveness,
flexibility, and capabilities for high-level abstraction -- much the
same things I like in other languages, but (as noted) the chances of
finding a job dealing with Perl are better than the chances of finding
a job dealing with LISP.
Wade Humeniuk
"Charlton Wilbur" <cwi...@mithril.chromatico.net> wrote in message
news:87bs448...@mithril.chromatico.net...
> plug-in replacement programmer might not understand. With LISP or
> Perl, hiring an intelligent programmer[3] means that you can get
> expressive, clear, powerful code written quickly. It also means that
> when your first programmer leaves, you need to find an intelligent one
> to replace him. With Java, you just hire one of the recent
> interchangeable college graduates; it's impossible to do complex
> abstract things in the language anyway, so you can be fairly certain
> that anyone who can write basic Java will understand whatever your
> prior programmer wrote.
An app whether written in Java or Lisp inherently has the same
complexity. They have to do essentially the same things. Thus the
apps are at least of the same complexity. So why do you say in the
Lisp case you have to hire an intelligent programmer and in the
Java case you do not? Comparable apps need comparable intelligence
to understand and modify. Are you saying that with Java software you cannot
have apps of any complexity? I do not think you are saying that.
I would think Java with its OO centric approach is harder for programmers
to exchange ideas and thus they would have to be more intelligent. With
OO it seems you have to understand a whole vocabulary framework before
you know what each class does (and thus can modify it).
Are you saying,...
JavaMan Software Developer Conversation
JavaMan1: Grunt Burp Grunt Phew Grunt
JavaMan2: Ugh, Burp Grunt Phew Phew
And LispMan talk is like a conversation between intellectuals?
Wade
Chris Gehlker
"Charlton Wilbur" <cwi...@mithril.chromatico.net> wrote:
>>>>>> "CG" == Chris Gehlker <geh...@fastq.com> writes:
>
> CG> I wonder if Java is really all that much more popular than
> CG> Lisp. It certainly gets more press but, as others have
> CG> remarked, it's in the middle of a marketing war with the .Net
> CG> flavors. That makes for exciting ink.
>
> From what I've seen, Java is *far* more popular than LISP. This
> probably doesn't hold true among the intelligentsia of programmers,
> but you can take an informal poll by checking out the computer-books
> section of your favorite bookstore. How many books are there on Java,
> compared to how many books on LISP? (Can you even *find* a book on
> LISP?)
It's hard. One could infer that the Lisp books are flying off the shelves,
while nobody wants the Java books. ;-) Seriously though, a lot of the Java
books are of the "Java 2 for Dummies" or "Learn Java in 21 Days" variety. I
think these are more indicative of a soft interest in Java rather than that
there are people who have actually mastered the language. Java has a
reputation for being easy.
>
> Java has two advantages over all the other languages you list.
>
> First, it has a single, strong, corporate sponsor.
I agree completely with this.
> Second, it supports mediocre programmers well.
Here I don't completely agree. Java may not be the most expressive language
but most Java programs don't come close to pushing its limits. In fact the
worst code I see tends to be in Java. Bad Java is no more
maintainable/extensible than bad Cobol.
Gabe Garza
> An app whether written in Java or Lisp inherently has the same
> complexity.
I think it's useful to differentiate between the complexity of the
task a program does and the complexity of the program itself. I've
seen some very complex programs that did very simple things. :)
> They have to do essentially the same things. Thus the apps are at
> least of the same complexity.
The tasks are of the same complexity, the applications need not be.
Consider a simple MegaCorp app that gives workers information on what
shifts they are to work in the following week.
Programmer A might make a simple application that allows a manager to
fill out a simple form, generates an email from that form, and sends
it off to all of the workers.
Programmer B might make three Java programs, one called
EmployeeTimeManagerInputManager and one called
EmployeeTimeDisplayManager and one called
EmployeeTimeManagerOfManagers. EmployeeTimeManagerofManagers will run
on an J2EE app server, store all of its state in an Oracle database,
and serve information to instances of EmployeeTimeDisplayManager using
SOAP, after the employee who is running that instance of
EmployeeTimeDisplayManager has authenticated himself with information
in the database (shift information being very confidential, because it
is). It will receive information from
EmployeeTimeManagerInputManager, which those who have pointed hair
will use to input information that it transmits to
EmployeeTimeManagerOfManagers via SOAP over SSL. It will also serve a
web page giving the current status of the system so the NOC can make
sure the system is functioning at all times. There's also a fail-over
app server for EmployeeTimeManagerInputManager, which must be sigma 6,
because Programmer B's manager heard the phrase during a conference
call once.
They do the same task, but given the choice I'd prefer to maintain
Programmer A's work.
> So why do you say in the Lisp case you have to hire an intelligent
> programmer and in the Java case you do not?
I don't think you *have* to hire an intelligent programmer unless it's
a very complex task that's being performed. But even on a simpler
problem, the intelligent programmer is going to take (a lot!) less
time to write a much better program.
> I would think Java with its OO centric approach is harder for programmers
> to exchange ideas and thus they would have to be more intelligent. With
> OO it seems you have to understand a whole vocabulary framework before
> you know what each class does (and thus can modify it).
I think that framework of vocabulary is important to Java's success
because that framework of vocabulary gets translated into the
framework of a program--and relative to other language it's not a very
complex vocabulary.
> Are you saying,...
>
> JavaMan Software Developer Conversation
>
> JavaMan1: Grunt Burp Grunt Phew Grunt
> JavaMan2: Ugh, Burp Grunt Phew Phew
>
> And LispMan talk is like a conversation between intellectuals?
For the *average* JavaMan, and the *average* LispMan, I wouldn't say
that's not too far off, if for no other reason then inexperienced
programmers are (*in general*) more likely to know Java "well" then to
know Lisp at all....
Gabe Garza
Matthew Danish
> Are you saying,...
>
> JavaMan Software Developer Conversation
>
> JavaMan1: Grunt Burp Grunt Phew Grunt
> JavaMan2: Ugh, Burp Grunt Phew Phew
More likely:
JavaMan1: XML DOM JSP SOAP EJB HTML JAXP
JavaMan2: J2EE SQL .NET B2B J2SE JVM JIT
Which is pretty much the same thing, I suppose.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
John Klein
> People where discussing a GUI for Lisp. The point is that there seems
> to be not good solution.
>
> When I say GUI I mean that it should be easy to make a GUI using Lisp,
> not that the language needs a GUI itself.
>
> What do you all think?
I think this is a good idea.
I would suggest the following: clone capi, the basic lispworks GUI.
I suggest this approach because
a) Harlequin has already done the design work - minimise trial and error.
b) CAPI seems pretty simple - this seems a finite 'good enough' project,
not an attempt to recreate the glorous byzantine complexity of (say)
CLIM. I tried CLIM, but it doesn't seem quite ready for users yet.
c) CAPI sits atop the native GUI - hence you get native
widgets, and the project does not have to worry about drawing
buttons, borders, etc. eg, the GTK interface to CMUCL would be a fine
starting point for one implementation; Corman Lisp would use
Windows widgets...
d) A single template file defining the CLOS object hierarchy and methods
could serve as a starting point for all implementations - porting
it would ideally consist of filling in the blanks with native widget
calls.
e) The docs have been written. The niftiest GUI in the world is
near worthless without docs, and hackers don't like to write docs.
Of course, there are copyright issue that would have to be
resolved as they were for the hyperspec.
I began doing something similar for CMUCL's CLM Motif interface,
but I started designing the hierarchy from scratch rather than using
CAPI as a template, and got bogged down in too much
thinking/designing (see a). Also, Motif is rather antiquated and CLM is
frozen and unused, and things just didn't seem to work quite right.
But it was enough to convince me that you can do a lot in a couple of
thousand lines of code if all you are doing is wrapping CLOS
around native widgets.
Marco Antoniotti
jk27...@yahoo.com (John Klein) writes:
> thel...@gmx.net (thelifter) wrote in message news:<b295356a.02112...@posting.google.com>...
> > People where discussing a GUI for Lisp. The point is that there seems
> > to be not good solution.
> >
> > When I say GUI I mean that it should be easy to make a GUI using Lisp,
> > not that the language needs a GUI itself.
> >
> > What do you all think?
>
> I think this is a good idea.
>
> I would suggest the following: clone capi, the basic lispworks
> GUI.
CAPI is nice. But would Xanalys allow a clone of it? And why not
Franz's Common Windows?
> I suggest this approach because
>
> a) Harlequin has already done the design work - minimise trial and error.
>
> b) CAPI seems pretty simple - this seems a finite 'good enough' project,
> not an attempt to recreate the glorous byzantine complexity of (say)
> CLIM. I tried CLIM, but it doesn't seem quite ready for users yet.
>
> c) CAPI sits atop the native GUI - hence you get native
> widgets, and the project does not have to worry about drawing
> buttons, borders, etc. eg, the GTK interface to CMUCL would be a fine
> starting point for one implementation; Corman Lisp would use
> Windows widgets...
>
> d) A single template file defining the CLOS object hierarchy and methods
> could serve as a starting point for all implementations - porting
> it would ideally consist of filling in the blanks with native widget
> calls.
Not so fast. :) First of all the "peer" layer in CLIM and Java is a good
idea. Secondly, you have the usual problem of tying in a
"C-style-lets-call-the-main-loop-function" into the Lispy way of doing
things.
> e) The docs have been written. The niftiest GUI in the world is
> near worthless without docs, and hackers don't like to write docs.
> Of course, there are copyright issue that would have to be
> resolved as they were for the hyperspec.
The docs of CAPI are not quite up to speed with the implementation.
This is something the Xanalys folks are aware of.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Gabe Garza
> CAPI is nice. But would Xanalys allow a clone of it? And why not
> Franz's Common Windows?
When it comes down to it, I don't think Xanalys has a choice. I'm not
a lawyer, and my memory may be misfiring (please correct me if it
is...), but software interfaces are not covered by copyright
laws--only the literal implementation and to a limited extent its
design is.
Unless you were talking about being civil and asking or something. ;)
Gabe Garza
Friedrich Dominicus
> >
> > I would suggest the following: clone capi, the basic lispworks
> > GUI.
>
> CAPI is nice. But would Xanalys allow a clone of it?
I don't think they were against it. Just a simular exampls is
UncommonSQL which has used the CommonSQL API too.
>And why not
> Franz's Common Windows?
Well I do not see a difference. I would think the mentioned points
hold for both.
> > e) The docs have been written. The niftiest GUI in the world is
> > near worthless without docs, and hackers don't like to write docs.
> > Of course, there are copyright issue that would have to be
> > resolved as they were for the hyperspec.
>
> The docs of CAPI are not quite up to speed with the implementation.
> This is something the Xanalys folks are aware of.
Well as I understand the CLIM stuff more behind... But I would agree,
CAPI could be better documented.
Regards
Friedrich
Paolo Amoroso
wrote:
> learn than it is to master. Another part of the equation is that the Java
> compiler if free, as in beer, but it doesn't come with a profiler. Some
I seem to remember that early JDKs included some sort of profiling tool.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Pascal Costanza
> On Mon, 02 Dec 2002 11:44:59 -0700, Chris Gehlker <geh...@fastq.com>
> wrote:
>
>
>>learn than it is to master. Another part of the equation is that the Java
>>compiler if free, as in beer, but it doesn't come with a profiler. Some
>
>
> I seem to remember that early JDKs included some sort of profiling tool.
Recent JDKs also offer profiling. See the documentation on "java -Xprof"
and "java - Xrunhprof..."
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Carl Shapiro
> Not so fast. :) First of all the "peer" layer in CLIM and Java is a good
> idea. Secondly, you have the usual problem of tying in a
> "C-style-lets-call-the-main-loop-function" into the Lispy way of doing
> things.
I can see how this can be construed as a problem. CAPI, CLIM and CG
all make calls to foreign code for low level event processing. All of
these UIMS work just fine on Windows.
Chris Gehlker
<cost...@web.de> wrote:
> Paolo Amoroso wrote:
>> On Mon, 02 Dec 2002 11:44:59 -0700, Chris Gehlker <geh...@fastq.com>
>> wrote:
>>
>>
>>> learn than it is to master. Another part of the equation is that the Java
>>> compiler if free, as in beer, but it doesn't come with a profiler. Some
>>
>>
>> I seem to remember that early JDKs included some sort of profiling tool.
>
> Recent JDKs also offer profiling. See the documentation on "java -Xprof"
> and "java - Xrunhprof..."
>
I stand corrected.
Kenny Tilton
John Klein wrote:
> thel...@gmx.net (thelifter) wrote in message news:<b295356a.02112...@posting.google.com>...
>
>>People where discussing a GUI for Lisp. The point is that there seems
>>to be not good solution.
>>
>>When I say GUI I mean that it should be easy to make a GUI using Lisp,
>>not that the language needs a GUI itself.
>>
>>What do you all think?
>
>
> I think this is a good idea.
>
> I would suggest the following: clone capi, the basic lispworks GUI.
Excuse me? How am I any different than Microsoft? I have already
pre-announced Cello, the universal CL gui. That should be enough for
everyone to re-engineer for Cello.
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Carl Shapiro
Carl Shapiro <cshapi...@panix.com> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Not so fast. :) First of all the "peer" layer in CLIM and Java is a good
> > idea. Secondly, you have the usual problem of tying in a
> > "C-style-lets-call-the-main-loop-function" into the Lispy way of doing
> > things.
>
> I can see how this can be construed as a problem. CAPI, CLIM and CG
I *cannot* see how this...
Jock Cooper
> An app whether written in Java or Lisp inherently has the same
> complexity. They have to do essentially the same things. Thus the
> apps are at least of the same complexity. So why do you say in the
> Lisp case you have to hire an intelligent programmer and in the
> Java case you do not? Comparable apps need comparable intelligence
> to understand and modify. Are you saying that with Java software you cannot
> have apps of any complexity? I do not think you are saying that.
>
Here's a simple example. Let's say you have some kind of program that
just generates report output. Say there are 10 different output
sections and they are all similar but have differences in formatting,
data, breakdown or whatever.
One way to write such a program would be to write the code for the
first section, then copy it for each other section and make changes to
it for that section. This would be easy to understand code; it's
obvious what each little section is doing. Unfortunately you have
to maintain all those sections.
A second way to write the program would be to write a generic 'section
generator', which you pass some data structure into to control its
behavior. You could include a parser to get the data structures for
each section from some config file. Adding these abstractions
increases the program's complexity. It produces the same output as the
first one, yet is more complex to understand. But the benefits can
compensate for this: You can change the outputs without recompiling.
And you can make broad changes to all the output sections (eg adding
alternative output formats, or adding an extra digit or precision to
percentages) by changing the generic generator. You can add new
sections quickly just by inserting text into the config file.
The abstraction ability of the language used determines whether it
makes sense to write the program the second way. As the language
power decreases you will face diminishing returns by trying to
abstract so much.
For example, I was writing a generic database editor in CL; I wanted
to get the config (database, tables, how to display rows in each
table, which columns are protected etc) from a file. I also wanted to
express SQL in the source code as an easily readable string, that I
could quickly add columns, tables or other clauses to. CL made it
easy for me to write a generic parser (based on ideas in META) in
about 200 lines; about 100 lines for a config file grammar, about 170
lines for a grammar for the subset of SQL I needed to parse. In a
weaker language I would probably have had to take a more brute force
approach.
Jock Cooper
------
http://www.fractal-recursions.com
Marco Antoniotti
Carl Shapiro <cshapi...@panix.com> writes:
> Rats!
>
> Carl Shapiro <cshapi...@panix.com> writes:
>
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > > Not so fast. :) First of all the "peer" layer in CLIM and Java is a good
> > > idea. Secondly, you have the usual problem of tying in a
> > > "C-style-lets-call-the-main-loop-function" into the Lispy way of doing
> > > things.
> >
> > I can see how this can be construed as a problem. CAPI, CLIM and CG
>
> I *cannot* see how this...
It is not a problem per se, and I know it is doable. I just wanted to
point out that you require something more sophisticated than just
going out an write a FFI for - say - Gtk. You need to understand more
about what is going on in each GUI library (built usually in C) and in
each CL implementation.
Charlton Wilbur
CG> On 12/2/02 3:00 PM, in article
CG> 87bs448...@mithril.chromatico.net, "Charlton Wilbur"
CG> <cwi...@mithril.chromatico.net> wrote:
>> Second, [Java] supports mediocre programmers well.
CG> Here I don't completely agree. Java may not be the most
CG> expressive language but most Java programs don't come close to
CG> pushing its limits. In fact the worst code I see tends to be
CG> in Java. Bad Java is no more maintainable/extensible than bad
CG> Cobol.
No, but my point was about the other end of the spectrum. No language
will support bad programmers well; Java does a very good job of
supporting mediocre ones.
Let me give a practical example. (I use Perl as an example because I
work in Perl most of the time.) In a recent program, I wrote
something along the lines of --
# we expect timestamps are in the format 20 November 2002 15:47:03
# pick out the ones for the current month, and sort them by date
@this_month_timestamps = sort { ($a =~ /(\d+)/)[0] <=> ($b = /(\d+)/)[0] }
grep { (/\w+/)[0] eq $month and (/\d+/)[1] eq $year } @timestamps;
There are a number of Evil Perl Features here: treating things
differently in scalar or list context, implicit variables, and a
functional approach to sorting an array. This expressiveness, and
these features, mean that I can find an elegant solution to problems
and that I can express complex things very tersely; a solution to the
same problem in Java would not fit in one line of code.
At the same time, this expressiveness and level of abstraction is
dangerous. If I leave this company, they'll have a great deal of
well-written but terse Perl code, and they'll need to rewrite it
extensively in another language or they'll need to hire a good Perl
programmer. Because of the expressiveness of the language and the
skill required to use it well, you cannot simply swap Perl programmers
like interchangeable parts. I am allowed to work in Perl because my
code doesn't break, because I get things done more quickly and more
efficiently than a Java team would, and because I put enough comments
into my code for less experienced Perl programmers to figure out
what's going on.
I have not invested the same level of effort into learning LISP as I
have learning Perl, but I know enough LISP to be aware that it has
much the same issues with power and expressiveness, and much the same
danger in the hands of mediocre or incompetent programmers. Java is
much safer for management; they don't have to worry about hiring
artisan programmers, because interchangeable programmers are freely
available. They don't have to worry about keeping artisan programmers
happy, because colleges and universities keep on grinding out
barely-Java-fluent coders at an alarming rate, and Java programmers
are largely interchangeable.
Charlton
sv0f
<amo...@mclink.it> wrote:
>I seem to remember that early JDKs included some sort of profiling tool.
Sundial, hourglass, or pocketwatch?
Carl Shapiro
> It is not a problem per se, and I know it is doable. I just wanted to
> point out that you require something more sophisticated than just
> going out an write a FFI for - say - Gtk. You need to understand more
> about what is going on in each GUI library (built usually in C) and in
> each CL implementation.
Before writing any sort of abstraction, you must first understand what
you are abstracting away from.
Writing primitive GUI bindings in Lisp is easy. More often than not,
all you need is a Lisp which supports foreign calls and callbacks.
When using such systems on Windows, I have been able to hand translate
to Lisp interesting GUI examples from Petzold's "Programming Windows"
and Newcomer's "Win32 Programming". Give it a try, it's a no-brainer.
Chris Gehlker
"Charlton Wilbur" <cwi...@mithril.chromatico.net> wrote:
>>>>>> "CG" == Chris Gehlker <geh...@fastq.com> writes:
>
> CG> On 12/2/02 3:00 PM, in article
> CG> 87bs448...@mithril.chromatico.net, "Charlton Wilbur"
> CG> <cwi...@mithril.chromatico.net> wrote:
>
>>> Second, [Java] supports mediocre programmers well.
>
> CG> Here I don't completely agree. Java may not be the most
> CG> expressive language but most Java programs don't come close to
> CG> pushing its limits. In fact the worst code I see tends to be
> CG> in Java. Bad Java is no more maintainable/extensible than bad
> CG> Cobol.
>
> No, but my point was about the other end of the spectrum. No language
> will support bad programmers well; Java does a very good job of
> supporting mediocre ones.
[snip evil perl example]
> At the same time, this expressiveness and level of abstraction is
> dangerous. If I leave this company, they'll have a great deal of
> well-written but terse Perl code, and they'll need to rewrite it
> extensively in another language or they'll need to hire a good Perl
> programmer. Because of the expressiveness of the language and the
> skill required to use it well, you cannot simply swap Perl programmers
> like interchangeable parts. I am allowed to work in Perl because my
> code doesn't break, because I get things done more quickly and more
> efficiently than a Java team would, and because I put enough comments
> into my code for less experienced Perl programmers to figure out
> what's going on.
But if they hire a "team" of Java geeks then they need a PHB and a
secretary. A lot of the team's time will be spent on communication rather
than real work. And they still have to worry about turn-over because now if
any member of the team leaves, the whole team will be disrupted. Meanwhile,
the code base will bit-rot and while individual elements may be easier to
read, there will be more code to maintain.
> I have not invested the same level of effort into learning LISP as I
> have learning Perl, but I know enough LISP to be aware that it has
> much the same issues with power and expressiveness, and much the same
> danger in the hands of mediocre or incompetent programmers. Java is
> much safer for management; they don't have to worry about hiring
> artisan programmers, because interchangeable programmers are freely
> available. They don't have to worry about keeping artisan programmers
> happy, because colleges and universities keep on grinding out
> barely-Java-fluent coders at an alarming rate, and Java programmers
> are largely interchangeable.
I have a hard time believing that mediocre programmers are all that useful.
I'm starting to believe Kay more each day about the "crystallization of
style" versus "agglutination of features" distinction. If new programmers
learn C, Smalltalk and Lisp, they can pick up anything else pretty easily
and make it work.
Espen Vestre
> danger in the hands of mediocre or incompetent programmers. Java is
> much safer for management; they don't have to worry about hiring
> artisan programmers, because interchangeable programmers are freely
> available. They don't have to worry about keeping artisan programmers
> happy, because colleges and universities keep on grinding out
> barely-Java-fluent coders at an alarming rate, and Java programmers
> are largely interchangeable.
This is a common management theory. In practice, I've seen the
absolute opposite happen, especially close before the dotcom meltdown,
when java programmers switched jobs like ordinary people change their
underpants: I saw java-based systems popping up all the time, some
quite o.k, most of them pretty awful, and several of them were close
to unmaintainable because the programmers had left long ago and the
newbie java programmers that you _might_ be able to hire wouldn't have
any chance starting to work with such complex systems.
Hiring competent Common Lisp programmers was actually much easier, and
even the perl programmers were easier to get.
--
(espen)
ozan s yigit
> Do you have ideas on what these killer apps might be?
apache ant?
[ok, i admit, this is intended to either make people laugh sadly
or hurl across the room, whichever comes first. :]
oz
---
there is a fault in reality. do not adjust your minds. -- salman rushdie
Mario S. Mommer
Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
> Let me give a practical example. (I use Perl as an example because I
> work in Perl most of the time.) In a recent program, I wrote
> something along the lines of --
>
> # we expect timestamps are in the format 20 November 2002 15:47:03
> # pick out the ones for the current month, and sort them by date
>
> @this_month_timestamps = sort { ($a =~ /(\d+)/)[0] <=> ($b = /(\d+)/)[0] }
> grep { (/\w+/)[0] eq $month and (/\d+/)[1] eq $year } @timestamps;
>
> There are a number of Evil Perl Features here: treating things
> differently in scalar or list context, implicit variables, and a
> functional approach to sorting an array.
EEeew! :-P
> At the same time, this expressiveness and level of abstraction is
> dangerous. If I leave this company, they'll have a great deal of
> well-written but terse Perl code, and they'll need to rewrite it
> extensively in another language or they'll need to hire a good Perl
> programmer.
I've not seen much pearl, so I don't know. But, if something goes
wrong in the above example, how do you find out? Is it so clear for
you on a glance what's going on?
> I have not invested the same level of effort into learning LISP as I
> have learning Perl, but I know enough LISP to be aware that it has
> much the same issues with power and expressiveness, and much the same
> danger in the hands of mediocre or incompetent programmers. Java is
> much safer for management; they don't have to worry about hiring
> artisan programmers, because interchangeable programmers are freely
> available. They don't have to worry about keeping artisan programmers
> happy, because colleges and universities keep on grinding out
> barely-Java-fluent coders at an alarming rate, and Java programmers
> are largely interchangeable.
Flat tires are also interchangeable >:)
What are these problems with power and expressiveness? My impression
is that the number of subtleties, barbed wire fences and landmines is
much much smaller than in C++, for instance.
And what if I sneak into such acompany and write a java programm with
some deeply evil logic (this is what inexperienced programmers often
do). How are they going to exchange me without dumping my code too?
Regards,
Mario.
Mario S. Mommer
Gabe Garza <g_g...@ix.netcom.com> writes:
> The tasks are of the same complexity, the applications need not be.
> Consider a simple MegaCorp app that gives workers information on what
> shifts they are to work in the following week.
>
> Programmer A might make a simple application that allows a manager to
> fill out a simple form, generates an email from that form, and sends
> it off to all of the workers.
...and with this has solved the problem thoroughly...
>
> Programmer B might make three Java programs, one called
> EmployeeTimeManagerInputManager and one called
> EmployeeTimeDisplayManager and one called
> EmployeeTimeManagerOfManagers. EmployeeTimeManagerofManagers will run
> on an J2EE app server, store all of its state in an Oracle database,
> and serve information to instances of EmployeeTimeDisplayManager using
> SOAP, after the employee who is running that instance of
> EmployeeTimeDisplayManager has authenticated himself with information
> in the database (shift information being very confidential, because it
> is). It will receive information from
> EmployeeTimeManagerInputManager, which those who have pointed hair
> will use to input information that it transmits to
> EmployeeTimeManagerOfManagers via SOAP over SSL. It will also serve a
> web page giving the current status of the system so the NOC can make
> sure the system is functioning at all times. There's also a fail-over
> app server for EmployeeTimeManagerInputManager, which must be sigma 6,
> because Programmer B's manager heard the phrase during a conference
> call once.
...while this might not even do what it is supposed to do.
I've seen this pattern before. The problem here need not be
intelligence, I think. Programmer B might have seized the opportunity
to build himself a monument. He does not necessarily try to solve the
problem, but tries to throw in as many buzzwords as he can to get
everyone to believe he's a wizard. Which, given that his boss probably
has no clue, might work out better in career terms than programmer As
tactic!
> They do the same task, but given the choice I'd prefer to maintain
> Programmer A's work.
Programmer B might become the founder of a startup and get insanely
rich. "Time Management Systems (.com)", or whatever.
Some would say that programmer A has no visions...
> > So why do you say in the Lisp case you have to hire an intelligent
> > programmer and in the Java case you do not?
>
> I don't think you *have* to hire an intelligent programmer unless it's
> a very complex task that's being performed. But even on a simpler
> problem, the intelligent programmer is going to take (a lot!) less
> time to write a much better program.
It takes more to understand how programmer Bs solution works, in my
view. Maybe you need *wiser* programmers :-)
Mario.