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.
Paolo Amoroso
> In article <lqzsPbCVwupP0P...@4ax.com>, Paolo Amoroso
> <amo...@mclink.it> wrote:
>
> >I seem to remember that early JDKs included some sort of profiling tool.
>
> Sundial, hourglass, or pocketwatch?
You got a telescope and a table of eclipses of Jupiter moons. Later
versions came with Harrison clocks.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Wade Humeniuk
"Jock Cooper" <jo...@mail.com> wrote in message news:m3r8cza...@jcooper02.sagepub.com...
> 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
This says nothing about which way is more intelligent. If both meet the
requirements, why it is necessary to write a generic 'section generator'?
There is nothing wrong with code which is inherently throw away and
task specific. The second choice is usually made because a programmer
feels that they doing something more important than it usually is.
>
> 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.
>
Again just because its easier in Lisp to abstract does not mean it should be
done in all cases. Lisp's inherent abstractions with symbols, lists, hash tables,...
already provide many of the patterns needed to get the job done.
An SQL parser might certainly be one case where you found additional
abstraction helps. But it is a far cry from 10 different output sections.
Wade
Chris Gehlker
"Mario S. Mommer" <m_mo...@yahoo.com> wrote:
> 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.
My experience is that when those familiar with the whole C family of
languages, are given a choice between ObjC, C++ and Java, will tend to
prefer them in that order. Delegation is a bitch in Java, it's threading
model is awkward and its type system is broken.
C++ has a few landmines but they are easy to avoid. The biggest one is
probably dealing with diamond inheritance patterns. You only have to do that
in school. They simply don't happen in the real world. The second big
bugaboo in C++ is memory management. Again it's a big problem in school
where they won't let you use leak detectors but in the real world there are
cheap/free tools that read the file your compiler produces for the debugger
and flag every line where something gets allocated that is not subsequently
released.
ObjC is very nice where it's well supported. Unfortunately, that doesn't
include Windows.
Guess I got a bit OT there. Sorry.
-----= 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! =-----
Jock Cooper
> "Jock Cooper" <jo...@mail.com> wrote in message
> news:m3r8cza...@jcooper02.sagepub.com...
> > 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
>
> This says nothing about which way is more intelligent. If both meet the
> requirements, why it is necessary to write a generic 'section generator'?
> There is nothing wrong with code which is inherently throw away and
> task specific. The second choice is usually made because a programmer
> feels that they doing something more important than it usually is.
Throw away or sloppy code is fine for something that runs once, or
runs many times but never changes. But in cases where management is
making changes to the requirements all the time (which has pretty much
been my experience throughout my career) it is better to have
something more flexible/maintainable. Consolidating similar code
accomplishes this. It's why people write libraries. Both versions
can meet the requirements on go live day, but I think that the second
one will be easier to maintain in the long run. It almost sounds like
you are arguing against spending the extra effort to write reusable
code. Of course I'm talking about a broader class of programming
problems than just creating report outputs.
For example, would it make sense when creating a web based product
catalog to write the page for each product by hand in static HTML, or
would you write a page generator that reads a database of products?
Maybe if your product list was small and never changed, static hand
written pages make sense. Otherwise it would be quite foolish to do
it that way.
Back to the report thing, consider another case (besides the ones I
already mentioned in the previous post) where someone now wants to
create a new report with 10 new sections. With version 1, you have to
start from scratch, or else do a lot of copying/modifying old sections
(bug prone IMHO). With version 2 you effectively have already have a
core generator (or call it a library, package, whatever) that you just
have to write a new config file for.
>
> >
> > 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.
> >
>
> Again just because its easier in Lisp to abstract does not mean it should be
> done in all cases. Lisp's inherent abstractions with symbols, lists, hash tables,...
> already provide many of the patterns needed to get the job done.
> An SQL parser might certainly be one case where you found additional
> abstraction helps. But it is a far cry from 10 different output sections.
I'm not even sure why we are discussing all this in the first place.
My original point was how two programs can both produce the same
output, with one being simple and one being complex. You had stated
that two programs which do the same thing are the same complexity.
Now you seem to be arguing that it is unnecessary for a program to be
internally complex or reusable.
I wasn't really addressing which is the right way to do it. It is a
design choice which way to write it. It depends on how much you
expect requirements to change, enhancements to be requested, and/or
future projects which will work similarly.
Jock Cooper
---
http://www.fractal-recursions.com
Charlton Wilbur
CG> But if they hire a "team" of Java geeks then they need a PHB
CG> and a secretary. A lot of the team's time will be spent on
CG> communication rather than real work. And they still have to
CG> worry about turn-over because now if any member of the team
CG> leaves, the whole team will be disrupted. Meanwhile, the code
CG> base will bit-rot and while individual elements may be easier
CG> to read, there will be more code to maintain.
Oh, yes. But they *have* a PHB -- who do you think is choosing Java
over LISP? And a team of 10 that loses a member is much better off
than a team of 2 that loses a member.
I suppose I ought to make it clear that I'm not saying that these
arguments are sufficient reason to use Java over LISP; I'm pointing
out that there are substantial arguments, especially convincing to the
PHB-sorts, involving risk management and cost of resources.
Suppose the PHB hires two brilliant LISP programmers instead of 15
mediocre Java programmers. If one of those LISP programmers is hit by
a bus, he's got to find another brilliant LISP programmer -- *not* an
easy task. (How do you identify a brilliant LISP programmer on the
strength of perhaps three hours' worth of interviews?) The PHB must
also pay them more, because they're more aware of their importance to
the company and the cost to replace them. On the other hand, if he
hires 15 mediocre Java programmers and one gets hit by a bus, another
mediocre Java programmer is not going to be hard to come by, and he
doesn't have to pay all that much for them.
CG> I have a hard time believing that mediocre programmers are all
CG> that useful.
I think if I had a choice between a mediocre programmer and a
good one, I'd pick the good one every time. But I find that mediocre
programmers are numerous and good programmers are rare as hen's teeth,
and so if I were a PHB I'd focus on ways of getting useful work from
mediocre programmers rather than tools to make good programmers more
productive. Thus, Java rather than LISP, because it's easier to
constrain mediocre programmers into producing useful work than it is
to elevate them to the level of good programmers.
I think what we're seeing here is an industrial revolution in
software. Before the Industrial Revolution, things were made by hand,
with hand tools; each chair or each gun was made by a person who
understood how it all worked. After the Industrial Revolution, the
assembly line, and the factory, things were made by machine or by
assembly line, with each person putting a rung in the chair or a gear
in the great clockwork without understanding how it all worked. I
think we're seeing something similar. The vast majority of Java
programmers are in effect assembly line programmers, and we're the
former artisans and craftsmen lamenting the artistry and craftsmanship
that's falling by the wayside.
CG> I'm starting to believe Kay more each day about the
CG> "crystallization of style" versus "agglutination of features"
CG> distinction. If new programmers learn C, Smalltalk and Lisp,
CG> they can pick up anything else pretty easily and make it work.
I agree with this wholeheartedly, perhaps in part because it was the
foundation of my own computer science education and I seem to have
turned out okay.
Charlton
Charlton Wilbur
EV> In practice, I've seen the absolute opposite happen,
EV> especially close before the dotcom meltdown, when java
EV> programmers switched jobs like ordinary people change their
EV> underpants: I saw java-based systems popping up all the time,
EV> some quite o.k, most of them pretty awful, and several of them
EV> were close to unmaintainable because the programmers had left
EV> long ago and the newbie java programmers that you _might_ be
EV> able to hire wouldn't have any chance starting to work with
EV> such complex systems.
EV> Hiring competent Common Lisp programmers was actually much
EV> easier, and even the perl programmers were easier to get.
Well, yes, when the theory is based on the easy availability of
barely-skilled labor, and even barely-skilled labor is hard to find,
then the practice will not match the theory. In that market, an
intelligent manager (if that is not a contradiction in terms) would
probably be best off abandoning Java in favor of Perl or LISP, simply
because of the availability of resources.
But now that the dotcom meltdown has passed, and there are hundreds of
Java programmers out of work, the "easy interchangeability" philosophy
works again.
Charlton
Charlton Wilbur
MM> 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+/)[1] eq $month and (/\d+/)[1] eq $year } @timestamps;
MM> I've not seen much pearl, so I don't know. But, if something
MM> goes wrong in the above example, how do you find out? Is it so
MM> clear for you on a glance what's going on?
This example of Perl is cryptic because it's terse. I could probably
write it in about a dozen lines and make it clear even to novice
programmers.
To translate this into a LISPish syntax, this is roughly a (sort
(lambda ....) (filter (lambda ...) input-list); most of the cryptic
stuff is in the anonymous subroutines. The sort {} grep {} @list
structure is clear; the stuff inside {} is the criteria for sorting or
filtering.
MM> What are these problems with power and expressiveness? My
MM> impression is that the number of subtleties, barbed wire
MM> fences and landmines is much much smaller than in C++, for
MM> instance.
LISP has fewer strange subtleties and misfeatures than C++ or Java,
but it offers a higher level of abstraction. This is dangerous
because most programmers don't learn to think at that level of
abstraction.
MM> And what if I sneak into such acompany and write a java
MM> programm with some deeply evil logic (this is what
MM> inexperienced programmers often do). How are they going to
MM> exchange me without dumping my code too?
Evil as in malicious? In that case, they should be rid of (the
hypothetical) you and your code.
Or evil as in very bad? In that case, they rewrite your code -- but
if you're a novice programmer, finding someone who understands the
problem and who understands your code is fairly simple.
Much of this reminds me of the apocryphal engineer who submitted a
bill -- "$1 to tap the machine, $9999 for knowing where to tap it."
The Java attitude, based on what I've seen, would be to pay 10 people
$800 each to dismantle and fix a part of the machine, with a $100
bonus to the person who could demonstrate having gotten rid of the
problem.
Charlton
Christian Nybų
> 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.
Why should a programmer learn Smalltalk in addition to Common Lisp?
--
chr
Skull
>
> 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?
There is a GUI in LISP, I believe.
Personally I never had a practical reason to use the GUI parts of Java,
other than to rewrite map drawing code(WDBII GeoFlavors) I had
already written/worked-with in Lisp in Java to prove I could
code Java in order to get a job doing god-knows-what with Java--
turned out to be NES HttpApplets.
It was the server-side stuff and the connectivity drivers
to databases and directory servers that made Java. Also
the Java goggles of J2EE to make accessible the whole "enterprise
computing" set of problems. The networking built-in to Java
is what gave it leverage.
But the Java really hit the fan with web page compilation(JHTML). There
you could have easy stateful variables for a page without much pain.
CL-HTTP had all the stuff Java servlets could do in 1996 or thereabouts,
but it didn't have the page compilation. It had something close, some
sort of server-side include that could be a lisp expression. Even
better than compilation. But no "thin drivers" to enterprise resources
that I'm aware.
It's been 5 years at least, why hasn't someone
gone ahead and decompiled Oracle's thin drivers and translated them
to pure LISP? Answer, no common socket implementation. You
can't write to some common socket layer that you can leverage and
have your driver portable from one LISP to another. So there's no
point. So it was the networking that made Java. For LISP it's the same
multiple-implementation problem for LDAP drivers.
No, Java won because at the time you had all this investment by
Netscape in server-side java (remember HttpApplet?), and obviously
Sun. But Enterprise Server had the server-side java very early on.
WebLogic was a very early Java server as well, given away with
Peoplesoft licenses. By 1997, server-side java was on people's
critical paths. At the time Netscape was also pouring money into
*inventing* the directory-server concept and value proposition
and creating the LDAP standard. There is some roots in UMichigan,
but I believe it was Netscape Inc that funded a lot of it. And
it was investors who funded Netscape Inc., most of whom didn't
see a return, or realized a total loss, I imagine.
Java is a freebie that jumped the fence and became a sort of "emergent"
value thing, not at all what you would expect for the "design and
introduction of a computing language".
Currently JSP and XML are divergent technologies (JSP syntax is not
well-formed), so who knows what will happen next.
We keep up with our ACL licenses, but it's not on my critical path.
If it were I know I'd get so much more accomplished.
Regards,
-Rich
sv0f
<cwi...@mithril.chromatico.net> wrote:
>Suppose the PHB hires two brilliant LISP programmers instead of 15
>mediocre Java programmers. If one of those LISP programmers is hit by
>a bus, he's got to find another brilliant LISP programmer -- *not* an
>easy task. (How do you identify a brilliant LISP programmer on the
>strength of perhaps three hours' worth of interviews?) The PHB must
>also pay them more, because they're more aware of their importance to
>the company and the cost to replace them. On the other hand, if he
>hires 15 mediocre Java programmers and one gets hit by a bus, another
>mediocre Java programmer is not going to be hard to come by, and he
>doesn't have to pay all that much for them.
I understand the "hit by a bus" argument is not meant to be taken
literally, but still I wonder: Have people actually been in situations
where one person with
Pascal Costanza
> Suppose the PHB hires two brilliant LISP programmers instead of 15
> mediocre Java programmers. If one of those LISP programmers is hit by
> a bus, he's got to find another brilliant LISP programmer -- *not* an
> easy task. (How do you identify a brilliant LISP programmer on the
> strength of perhaps three hours' worth of interviews?) The PHB must
> also pay them more, because they're more aware of their importance to
> the company and the cost to replace them. On the other hand, if he
> hires 15 mediocre Java programmers and one gets hit by a bus, another
> mediocre Java programmer is not going to be hard to come by, and he
> doesn't have to pay all that much for them.
I disagree. Apart from the 15 mediocre Java programmers you need at
least one or two above-average programmers that do the hard work, like
designing the program, deciding what architecture and frameworks to use,
and so on. I can't imagine that you can run a software project with
mediocre programmers alone. Now, one of the two project leads can be hit
by a bus, can't they? They are also aware of their importance, aren't they?
> I think if I had a choice between a mediocre programmer and a
> good one, I'd pick the good one every time. But I find that mediocre
> programmers are numerous and good programmers are rare as hen's teeth,
> and so if I were a PHB I'd focus on ways of getting useful work from
> mediocre programmers rather than tools to make good programmers more
> productive. Thus, Java rather than LISP, because it's easier to
> constrain mediocre programmers into producing useful work than it is
> to elevate them to the level of good programmers.
Again, I disagree. In the long run, mediocre programmers can learn the
complex stuff. When you take a historic perspective, you will notice
that programmers already learnt quite a bunch of complex concepts in the
last 10 or 20 years, like for example object-oriented programming. One
of the good things of Java is that things like garbage collection and a
focus on solving problems rather than twiddling with the machine level
are taken for granted by now. Languages like Python and Ruby already
have given way to concepts like higher-order functions, etc., to a
larger audience. Microsoft has announced to include higher order
functions into C#; elements for meta-programming are already part of C#
and more of that will be included in future versions. The amazing thing
that will happen is that, due to magazine articles and "C# for dummies"
books and so on, the next generation of programmers will understand at
least a certain amount of these concepts.
> I think what we're seeing here is an industrial revolution in
> software. Before the Industrial Revolution, things were made by hand,
> with hand tools; each chair or each gun was made by a person who
> understood how it all worked. After the Industrial Revolution, the
> assembly line, and the factory, things were made by machine or by
> assembly line, with each person putting a rung in the chair or a gear
> in the great clockwork without understanding how it all worked. I
> think we're seeing something similar. The vast majority of Java
> programmers are in effect assembly line programmers, and we're the
> former artisans and craftsmen lamenting the artistry and craftsmanship
> that's falling by the wayside.
The assembly line notion is the basic mental model pushed forward by
people who are into software engineering and process models. I have
strong doubts that this is the right model. Again, apart from the
workers at an assembly line, someone has to design and build the
assembly line itself! I think the assembly line notion is wrong because
even the so-called mediocre programmer who just implements the
specifications given to him needs some amount of creativity. Otherwise
the job could be done much better by program generators. Workers at an
assembly line don't need any creativity. And it happens more often than
not, that those mediocre programmers notice problems and bugs in
specification that the "master designers" haven't thought of. The
assembly line notion is dangerous in this regard because it basically
prevents (or at least hinders) corrective actions "from below" in these
cases.
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
Daniel Barlow
> # 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
It's also a classic example of the underlying Evil Perl Philosophy:
would it not make more sense to fix whatever braindamaged application
is producing those ridiculously formatted timestamps in the first place?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
sv0f
<cost...@web.de> wrote:
>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
Food for thought:
"A clear statement is a statement to which the opposite is either true
or false. A deep statement is a statement to which the opposite is another
deep statement." Niels Bohr
"If anything is possible, then nothing is interesting." H. G. Wells.
"I argue that all rules have their limits and that there is no comprehensive
Śrationalityą, I do not argue that we should proceed without rules and
standards." Paul Feyerabend
"There is no need to fear that the diminished concern for law and order in
science and society that characterizes an anarchism of this kind will lead
to chaos. The human nervous system is too well organized for that." Paul
Feyerabend
Chris Gehlker
<c...@nybo.no> wrote:
Every time you learn a new language, you gain insights into how to solve
problems with the language that you use most often. Every language
facilitates certain approaches to problem solving and discourages others.
But Kay asserted that some languages "crystallize" a style of problem
solving, making it very explicit while almost forcing the programmer to
adopt it. Others might accommodate the new style but they will also
accommodate programming the familiar way with a new syntax. They teach you
less.
Now the theory is that C "crystallizes" procedural programming, Smalltalk
crystallizes OO and Lisp crystallizes the "bottom up" approach and goes
pretty far along the functional dimension. So learning these languages is
more valuable than learning the fashionable language in terms of adding to
your tool kit.
Here is a concrete example. Your friend calls up and he just can't get
Debian to boot on his old Mac. You realize that it's probably because he
replaced his IDE drive with a couple of SCSIs. You boot into the firmware
and, my god, it's FORTH. If you are the greatest Java programmer in the
world you are SOL. If you know Lisp, however, it looks sort of familiar. You
download a three page tutorial, grok that it's another bottom up language
but postfix, not prefix, discover words dumps the FORTH dictionary to
screen, look at the dual-boot script that you friend got with the new OS and
noodle out that you can change one symbol and adapt it to SCSI.
Frank A. Adrian
> ... even the perl programmers were easier to get.
If you could stand having the fanatics about.
faa
Friedrich Dominicus
>
> Suppose the PHB hires two brilliant LISP programmers instead of 15
> mediocre Java programmers. If one of those LISP programmers is hit by
> a bus, he's got to find another brilliant LISP programmer -- *not* an
> easy task. (How do you identify a brilliant LISP programmer on the
> strength of perhaps three hours' worth of interviews?) The PHB must
> also pay them more, because they're more aware of their importance to
> the company and the cost to replace them. On the other hand, if he
> hires 15 mediocre Java programmers and one gets hit by a bus, another
> mediocre Java programmer is not going to be hard to come by, and he
> doesn't have to pay all that much for them.
This is as arrogant as can be. Excellence is rare and
excellent C hackers will outperform either mediocre Lisp programmers
or such Java programmers. What does it buy you to qualify Java
programmers as mediocre? Do you feel a better man while using Lisp?
> The vast majority of Java
> programmers are in effect assembly line programmers, and we're the
> former artisans and craftsmen lamenting the artistry and craftsmanship
> that's falling by the wayside.
I assume you mean this seriously.
>
> I agree with this wholeheartedly, perhaps in part because it was the
> foundation of my own computer science education and I seem to have
> turned out okay.
I think you feel suprerior well in Germany we have a saying.
"Hochmut kommt vor dem Fall." If all Lispers would think that way,
Lisp is doomed to fail.
Friedrich
Kenny Tilton
Friedrich Dominicus wrote:
> Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
>
>
>>Suppose the PHB hires two brilliant LISP programmers instead of 15
>>mediocre Java programmers. If one of those LISP programmers is hit by
>>a bus, he's got to find another brilliant LISP programmer -- [massive snip] another
>>mediocre Java programmer is not going to be hard to come by, and he
>>doesn't have to pay all that much for them.
>
> This is as arrogant as can be.
Possibly, but you do not know that, so you should hold your tongue.
Possibly the OP was speaking clamly as a matter of fact.
> excellent C hackers will outperform either mediocre Lisp programmers
There /are/ no mediocre Lispers. Mediocrities move on.
> Do you feel a better man while using Lisp?
<resisting temptation to make a lewd joke>
> I think you feel suprerior well in Germany we have a saying.
> "Hochmut kommt vor dem Fall." If all Lispers would think that way,
> Lisp is doomed to fail.
So you think a language which delights its users thoroughly is perforce
doomed? users who know the alternatives probaly as well as their adherents?
What's the German for "get a grip"?
:)
--
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
> > ... even the perl programmers were easier to get.
>
> If you could stand having the fanatics about.
;-)
But actually, I know several perl hackers that also are quite fluent
in, and quite fond of, Common Lisp.
--
(espen)
Jeremy Yallop
> I think you feel suprerior well in Germany we have a saying.
> "Hochmut kommt vor dem Fall."
"[I]n Germany"?
http://www.biblegateway.com/cgi-bin/bible?passage=PROV%2B16%3A18&version=KJV
Jeremy.
Mario S. Mommer
Kenny Tilton <kti...@nyc.rr.com> writes:
> > Do you feel a better man while using Lisp?
>
> <resisting temptation to make a lewd joke>
<laughing just the same>
> What's the German for "get a grip"?
Babelfish embarrasses itself with
"erhalten Sie einen Griff"
Mario
Friedrich Dominicus
> Friedrich Dominicus wrote:
> > Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
> >
>
> >>Suppose the PHB hires two brilliant LISP programmers instead of 15
> >>mediocre Java programmers. If one of those LISP programmers is hit by
> >>a bus, he's got to find another brilliant LISP programmer -- [massive snip] another
> >>mediocre Java programmer is not going to be hard to come by, and he
> >>doesn't have to pay all that much for them.
> > This is as arrogant as can be.
>
>
> Possibly, but you do not know that, so you should hold your
> tongue.
Why? Just because that is how I think about such stuff?
> Possibly the OP was speaking clamly as a matter of fact.
Which is the arogance I meant.
>
>
> > excellent C hackers will outperform either mediocre Lisp programmers
>
> There /are/ no mediocre Lispers. Mediocrities move on.
That is nonsense.
>
> > Do you feel a better man while using Lisp?
>
> <resisting temptation to make a lewd joke>
Well I don't think I misused man here.
>
> > I think you feel suprerior well in Germany we have a saying.
> > "Hochmut kommt vor dem Fall." If all Lispers would think that way,
> > Lisp is doomed to fail.
>
> So you think a language which delights its users thoroughly is
> perforce doomed?
No, there's a difference about "thinking of oneself as beeing
brilliant" and beeing delighted about one's tools.
Friedrich
Friedrich Dominicus
> >
> > <resisting temptation to make a lewd joke>
>
> <laughing just the same>
>
> > What's the German for "get a grip"?
>
> Babelfish embarrasses itself with
>
> "erhalten Sie einen Griff"
I think it suits well whith the mentioned temptation :)
Friedrich
Alexander Maryanovsky
> programmed or whether this is inherent to Java.
Neither. Disclaimer: I'm the author of Jin. You are either running Jin
on a very bad JVM or a very slow machine. I have run Jin on a Pentium
1 133Mhz machine with no noteable slowness.
Alexander Maryanovsky.
JB <jbl...@hotmail.com> wrote in message news:<asg779$pmd1p$1...@ID-167393.news.dfncis.de>...
> 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.
Tim Lavoie
KT> Friedrich Dominicus wrote:
KT> There /are/ no mediocre Lispers. Mediocrities move on.
Heh. I'm *sure* I've written code which dispels the first notion. I
feel better if I chalk it up to "learning experience".
>> Do you feel a better man while using Lisp?
KT> <resisting temptation to make a lewd joke>
SCHWIIIIIIING.. It'd be tough to explain to my wife though. :)
--
I argue very well. Ask any of my remaining friends. I can win an argument on
any topic, against any opponent. People know this, and steer clear of me at
parties. Often, as a sign of their great respect, they don't even invite me.
-- Dave Barry
Kenny Tilton
Friedrich Dominicus wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>Friedrich Dominicus wrote:
>>
>>>Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
>>>
>>
>>>>Suppose the PHB hires two brilliant LISP programmers instead of 15
>>>>mediocre Java programmers. If one of those LISP programmers is hit by
>>>>a bus, he's got to find another brilliant LISP programmer -- [massive snip] another
>>>>mediocre Java programmer is not going to be hard to come by, and he
>>>>doesn't have to pay all that much for them.
>>>
>>>This is as arrogant as can be.
...
>>Possibly the OP was speaking clamly as a matter of fact.
>
> Which is the arogance I meant.
No, I just checked my dictionary: "aggressively assertive or
presumptuous; overbearing". The OP's words simply tell it like it is.
Are you saying he is wrong, or "even if it is true, you should not say
that"? Or something else?
>>There /are/ no mediocre Lispers. Mediocrities move on.
>
> That is nonsense.
why would they stay? for all the job opportunities? for the thrill of
the power they get in hobby programming--then they are not mediocre.
I am reminded, btw, of the politician who defended mediocre G Harold
Carswell's nomination to the Supreme Court: "mediocre people have a
right to be represented on the Court." :)
>>>Do you feel a better man while using Lisp?
>>
>><resisting temptation to make a lewd joke>
>
> Well I don't think I misused man here.
No, you didn't, that was not the joke I had in mind. I was thinking,
Yes, Lisp definitely gives me a woody. :)
> No, there's a difference about "thinking of oneself as beeing
> brilliant" and beeing delighted about one's tools.
I am smart enough always to give the tool the credit.
Charlton Wilbur
FD> This is as arrogant as can be. Excellence is rare and
FD> excellent C hackers will outperform either mediocre Lisp
FD> programmers or such Java programmers. What does it buy you to
FD> qualify Java programmers as mediocre?
Look at the masses of programmers out there. While there's no
certainty that the man who uses LISP on a daily basis is a good
programmer and the man who uses Java on a daily basis is a mediocre
programmer, that's certainly the way to bet.
The core of my argument is that, in the hands of a mediocre
programmer, Java is a safer way to go than LISP, because a mediocre
programmer will have problems using the power and flexibility of LISP
adequately. In the hands of a brilliant programmer, they're both
going to more than get the job done, of course; but there are
remarkably few good programmers and millions of mediocre ones.
I suggest you go back and read my posts; you seem to have completely
missed the points I was making.
Charlton
Charlton Wilbur
EV> "Frank A. Adrian" <fad...@ancar.org> writes:
>> > ... even the perl programmers were easier to get.
>>
>> If you could stand having the fanatics about.
EV> But actually, I know several perl hackers that also are quite
EV> fluent in, and quite fond of, Common Lisp.
I'm not a Perl fanatic, except compared to such things as Visual Basic
and PHP. If I were to try to use LISP in this environment, I'd have
an uphill climb ahead of me; Perl gives me most of the flexibility and
power, while not requiring me to justify myself to upper management
(and thus draw attention to the fact that I'm not using Java).
Charlton
Charlton Wilbur
DB> Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
>> # 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
DB> It's also a classic example of the underlying Evil Perl
DB> Philosophy: would it not make more sense to fix whatever
DB> braindamaged application is producing those ridiculously
DB> formatted timestamps in the first place?
Given that the real problem in this example is not the format of the
timestamp, but filtering them and printing them, I'm not sure why this
is an Evil Perl Philosophy. I could put the timestamps in whatever
format I liked; no format that I'm aware of would make them filter
themselves or sort themselves.
Charlton
Coby Beck
"Kenny Tilton" <kti...@nyc.rr.com> wrote in message
news:3DEF870C...@nyc.rr.com...
> I am reminded, btw, of the politician who defended mediocre G Harold
> Carswell's nomination to the Supreme Court: "mediocre people have a
> right to be represented on the Court." :)
If I'm not mistaken, that was good ol' Ronnie Ray-gun, and a classic quote
it is!
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Espen Vestre
> I'm not a Perl fanatic, except compared to such things as Visual Basic
> and PHP. If I were to try to use LISP in this environment, I'd have
> an uphill climb ahead of me; Perl gives me most of the flexibility and
> power, while not requiring me to justify myself to upper management
> (and thus draw attention to the fact that I'm not using Java).
Do all the interesting work in lisp and add some silly java front end.
Then, if the PHB asks "is it java?" you can sincerly answer "As far
as you know"
;-)
--
(espen)
Christian Nybų
> I think if I had a choice between a mediocre programmer and a
> good one, I'd pick the good one every time. But I find that mediocre
> programmers are numerous and good programmers are rare as hen's teeth,
> and so if I were a PHB I'd focus on ways of getting useful work from
> mediocre programmers rather than tools to make good programmers more
> productive. Thus, Java rather than LISP, because it's easier to
> constrain mediocre programmers into producing useful work than it is
> to elevate them to the level of good programmers.
Is the premise in the last sentence your opinion, or something you
assume you'd think if you were a pointy-haired boss?
--
chr
Kenny Tilton
Coby Beck wrote:
> "Kenny Tilton" <kti...@nyc.rr.com> wrote in message
> news:3DEF870C...@nyc.rr.com...
>
>>I am reminded, btw, of the politician who defended mediocre G Harold
>>Carswell's nomination to the Supreme Court: "mediocre people have a
>>right to be represented on the Court." :)
>
>
> If I'm not mistaken, that was good ol' Ronnie Ray-gun, and a classic quote
> it is!
>
bzzzt, Coby. You are /not/ dating yourself (speaking of getting s grip).
Carswell was a Nixon nominee, and the honors go to Sen. Roman Hruska.
"Even if he were mediocre, there are a lot of mediocre judges and people
and lawyers, and they are entitled to representation, aren’t they?" —
Sen. Roman Hruska, super conservative Republican commenting on Richard
Nixon’s rejected nomination of a truly mediocre judge, Harold Carswell,
to the Supreme Court.
http://www.pressrepublican.com/Archive/2002/10_2002/10312002hb.htm
Thomas F. Burdick
> > Of course I cannot tell whether it is simply poorly
> > programmed or whether this is inherent to Java.
>
> Neither. Disclaimer: I'm the author of Jin. You are either running Jin
> on a very bad JVM or a very slow machine. I have run Jin on a Pentium
> 1 133Mhz machine with no noteable slowness.
For what it's worth, this is a huge problem I have with java: an
application's performance depends on the host JVM. I've got quite a
lovely setup here on Mac OS X, between Project Builder and Emacs/EJDE,
and the good JVM. Unfortunately, not everyone runs the HotSpot JVM on
a RISC machine. In Lisp, Obj-C, C++, Fortran, etc., I--the developer--can
ensure that the end user is running efficient object code code. Not so
for Java :-(
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Bob Bechtel
Roman Hruska. I'd agree that it's a classic.
bob bechtel
sv0f
<kti...@nyc.rr.com> wrote:
>"Even if he were mediocre, there are a lot of mediocre judges and people
>and lawyers, and they are entitled to representation, aren’t they?" —
>Sen. Roman Hruska, super conservative Republican commenting on Richard
>Nixon’s rejected nomination of a truly mediocre judge, Harold Carswell,
>to the Supreme Court.
Thanks for the exact quote, Kenny.
Chris Gehlker
"Thomas F. Burdick" <t...@apocalypse.OCF.Berkeley.EDU> wrote:
>
> For what it's worth, this is a huge problem I have with java: an
> application's performance depends on the host JVM. I've got quite a
> lovely setup here on Mac OS X, between Project Builder and Emacs/EJDE,
> and the good JVM. Unfortunately, not everyone runs the HotSpot JVM on
> a RISC machine. In Lisp, Obj-C, C++, Fortran, etc., I--the developer--can
> ensure that the end user is running efficient object code code. Not so
> for Java :-(
Hmm,
It seems that you are going a little too far, not in criticizing Java but in
praising the alternatives. The OP was clearly mistaken to argue "Hey it runs
fine on my box so it must run fine on yours" but I think that to some extent
that goes for any language. Even the C X-compiler vendors are careful to
limit their claims to "If it compiles and runs on the host and it compiles
for the target it will run on the target." They carefully don't say that any
optimizations that you make on the host will translate into better
performance on the target.
I would say that regardless of language, you can't know how your program
performs on platform X until you test it there. The problem with Java is
that its marketing folks pretended it was different.
Kenny Tilton
sv0f wrote:
>
> Thanks for the exact quote, Kenny.
thx, but full marks to google. i once (pre-web, that is) had the idea
that books should be indexed according to a standard taxonomy of
content. it would be an effort, but hey, indexing is an effort already,
this might just make it easier by giving one a standard taxonomy. and
then all books would get linked in a global index.
but now no matter what comes up, it seems i can find it, in more and
better detail than i ever dreamed possible. not by human-directed
categorization, but by simple text search.
there is nothing interesting about brute force (take that, Deep Blue)
but it sure is handy.
Bruce Hoult
Charlton Wilbur <cwi...@mithril.chromatico.net> wrote:
> CG> I have a hard time believing that mediocre programmers are all
> CG> that useful.
>
> I think if I had a choice between a mediocre programmer and a
> good one, I'd pick the good one every time. But I find that mediocre
> programmers are numerous and good programmers are rare as hen's teeth,
> and so if I were a PHB I'd focus on ways of getting useful work from
> mediocre programmers rather than tools to make good programmers more
> productive. Thus, Java rather than LISP, because it's easier to
> constrain mediocre programmers into producing useful work than it is
> to elevate them to the level of good programmers.
I think you're simply wrong.
Your argument is quite possibly a valid one if you're talking about Java
vs C++. Mediocre programmers can pretty much get by in Java, and get
useful things done, eventually. They slaughter themselves in C++.
But Lisp? Or Smalltalk? Or Dylan? You're wrong. These languages are
both more powerful than Java *AND* equally easy for mediocre programmers
to learn to use at least as well as they can use Java.
If they are *such* poor programmers that they are only ever going to be
able to learn a single syntax, and they happen to be taught Java first,
then that is a problem. But merely mediocre programmers can learn more
than one syntax. And they don't *have* to be taught Java first.
-- Bruce
Patrick W
> Your argument is quite possibly a valid one if you're talking about Java
> vs C++. Mediocre programmers can pretty much get by in Java, and get
> useful things done, eventually. They slaughter themselves in C++.
>
> But Lisp? Or Smalltalk? Or Dylan? You're wrong. These languages are
> both more powerful than Java *AND* equally easy for mediocre programmers
> to learn to use at least as well as they can use Java.
I think so. I also suspect that these more powerful, less restrictive
languages enable people to grow beyond mediocrity faster, provided
they have it in them.
Piers Cawley
>>>>>> "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.
>
> 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.
Without wishing to be overly rude, that's a bloody awful way of
implementing that in Perl which would get torn to shreds in any
sensible code review. Doing a regex match Nlog(N) times is generally not
considered a good idea for instance.
@this_month_timestamps =
map $_->{raw},
sort { $a->{day} <=> $b->{day} }
grep { ($_->{month} eq $month) &&
($_->{year} == $year ) }
map { my %d_struct = (raw => $_);
@d_struct{ qw/day month year/ } = split ' +' }
@timestamps;
It's still not going to win prizes for elegance, but it's a good deal
more efficient, clearer and doesn't play anywhere near as many
pointlessly silly games with context. Oh yes, and there's only one
regex used and that's a trivial one. Result. So what if it takes more
than one line, I'm not playing Perl golf, I'm playing the game of
writing efficient, maintainable code that isn't going to make me think
too much when I have to come back to it.
> 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,
If that's an example of your typical coding style then 'well written'
is not an adjective I'd apply to it in a million years. It's ugly,
fragile code with assumptions about data formats laced through
it. What happens when your timestamp format changes? With the
rewritten code I present, you just pull out the code in the rightmost
map into a 'parse_date' function, modify it for the new date format,
and alter the final map to look like
...
map parse_date($_), @timestamps
> and they'll need to rewrite it extensively in another language or
> they'll need to hire a good Perl programmer.
Well, that goes without saying, hiring mediocrities is a road to ruin,
but they won't necessarily need a 'good Perl programmer' because your
code is good...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Piers Cawley
> Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
>
>> # 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
>
> It's also a classic example of the underlying Evil Perl Philosophy:
> would it not make more sense to fix whatever braindamaged application
> is producing those ridiculously formatted timestamps in the first place?
Oh definitely. Personally I'd be slinging timestamp objects (with
appropriate overloadings) around as soon as possible, then it's just a
matter of
sort {$a <=> $b}
grep {$_->month == $month &&
$_->year == $year}
@timestamps
And then it's just a matter of getting over a lisper's dislike for
perl syntax.
Will Hartung
"Bruce Hoult" <br...@hoult.org> wrote in message
news:bruce-8C3EDB....@copper.ipg.tsnz.net...
> In article <87u1ht7...@mithril.chromatico.net>,
> Charlton Wilbur <cwi...@mithril.chromatico.net> wrote:
>
> > CG> I have a hard time believing that mediocre programmers are all
> > CG> that useful.
> >
> > I think if I had a choice between a mediocre programmer and a
> > good one, I'd pick the good one every time. But I find that mediocre
> > programmers are numerous and good programmers are rare as hen's teeth,
> > and so if I were a PHB I'd focus on ways of getting useful work from
> > mediocre programmers rather than tools to make good programmers more
> > productive. Thus, Java rather than LISP, because it's easier to
> > constrain mediocre programmers into producing useful work than it is
> > to elevate them to the level of good programmers.
>
> I think you're simply wrong.
>
> Your argument is quite possibly a valid one if you're talking about Java
> vs C++. Mediocre programmers can pretty much get by in Java, and get
> useful things done, eventually. They slaughter themselves in C++.
>
> But Lisp? Or Smalltalk? Or Dylan? You're wrong. These languages are
> both more powerful than Java *AND* equally easy for mediocre programmers
> to learn to use at least as well as they can use Java.
Well, I think you're both wrong, so nyah!
The question comes down to two things I think. What is the role this
programmer is going to play, and why is this programmer mediocre.
If the task at hand is really a job of coding up a bunch of screens, then
while a good programmer may be desirable, a mediocre programmer can be just
as effective, happier doing it, and cost less. In modern IT systems, if a
system has 100 screens, I'd wager about 5 of them are Interesting and the
rest pretty rote. Rote enough for mediocre programmers, and perhaps rote
enough to give a terrible programmer some good experience to grow with, but
also so rote that when your Master Programer walks in in the morning and
sees he has 75 to go, he may just put his head on his desk and whimper.
That's just simple job satisfaction.
The next question is why is the progammer mediocre. I've always felt that it
takes a certain kind of internal drive to become a good programmer, and from
what I've seen a lot of programmers don't have that drive. They can ingest
what you tell them, and you can even show them some reasonably advanced
concepts, but they never seem to have the ability to leverage that and
expand beyond them. They never seem to be able to apply the concepts very
well outside of what you showed them. Something silly like "Oh, I can use a
List HERE too?"
These folks will always be mediocre. Programming is Just A Job. Today, I
think this is the vast majority of programmers.
Then, there are the up and coming programmers who just happen to be mediocre
due to lack of experience and exposure. These folks are ideally only going
to be mediocre for a while as they rise on up.
The challenge is how to determine what kind of programmer you have on your
hands.
With beginning programmers, the languages really need to be proactive in
protecting the system from the programmer himself. They tend to thrash at
problems by trying just bizarre things and not thinking through why things
fail and how to solve the problems. A lot of this thrashing tends to remain
in the code, so things like garbage collection and static typing can be a
big win for these folks.
Mediocre programmers tend to work with idioms presented to them, regardless
of the language. They'll just keep doing what was shown to work before over
and over with perhaps a mild understanding if they think about it, but they
simply don't think about it too much relying on the fact that these idioms
"worked before". These folks can work in any language as long as their is
someone to guide them with examples or source code or some shoulder surfing
during early developement. These are the classic "assembly line"
programmers. Happy anywhere. Coders.
The Master programmers may desire a better environment but they know that
they can leverage many lower level systems with higher level concepts. The
classic "lisp reinvented -- badly" trend. There are many Master Programmers
happy in the world of C++, even those conscious of other environments.
They're happy because they've already mastered much of it, and its
Productive Enough for them to do their Interesting Things. Don't judge the
programmer by their tools. Simply because they're writing in VB or DBase or
whatever doesn't mean they're incompetent and can not see the larger issues
of computing in general.
At this point for what I'm doing, I'm happy with Java. Basically, I'd rather
have the availability of all this boiler plate infrastructure that it
provides than the more expressiveness and power of Lisp for what we do and
who we work with on our team. We aren't charting any new ground here with
our application, so its better I think to be able to make sound judgement of
the frameworks and environments being provided than concocting something of
our own.
The Java community has had the distinct ability, I think, of really
hammering on the concept of open interfaces to complex functionality instead
of simply implementations. Things like the XML models, the Servlet and J2EE
models, other components coming out of Sun and others. How many servlet
engines are there now? How many wide spread XML parsers?
No other community has done this to the extent of the Java community. Perl
has CPAN, but that's different. Those are actual implementations, not
specifications. The tools of the Java community are much like the compilers
of the Lisp community. While Sun may hold Java close to home, the folks
working on servlets and J2EE must pay attention to details that are not
portable, simply because of the fact that there are multiple implementations
of all the specifications.
And having to worry about details like that helps everyone because it means
that people need to think about their application, think about the
specification, understand these details, make conscious effort to deviate
from either one, and then if they find the specifcation lacking, go scream
at the committees developing the future version so it is easier to write
portable code in the future. Those that do not do this will find their code
fails should they try and port it.
Anyway, fill the position with the person that best matches the task at
hand. Exposure to things like Lisp et al can really make programmers better
by introducing them to new ways of thinking, but I think that the better
programmers will come to this realm on their own even if they're not working
in it professionally.
Regards,
Will Hartung
(wi...@msoft.com)
Charlton Wilbur
CN> Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
>> I think if I had a choice between a mediocre programmer and a
>> good one, I'd pick the good one every time. But I find that
>> mediocre programmers are numerous and good programmers are rare
>> as hen's teeth, and so if I were a PHB I'd focus on ways of
>> getting useful work from mediocre programmers rather than tools
>> to make good programmers more productive. Thus, Java rather
>> than LISP, because it's easier to constrain mediocre
>> programmers into producing useful work than it is to elevate
>> them to the level of good programmers.
CN> Is the premise in the last sentence your opinion, or something
CN> you assume you'd think if you were a pointy-haired boss?
The last sentence is my opinion, based on having worked as a TA while
in school and on having worked with programmers ranging from mediocre
to brilliant. I think in a perfect world all programmers could be
elevated to the level of brilliance; in this imperfect world, doing so
depends on a variety of factors, such as resource limitations and
motivation on the part of the programmers, that are completely beyond
the PHB's control.
Charlton
Thomas F. Burdick
> On 12/5/02 6:08 PM, in article xcvel8w...@apocalypse.OCF.Berkeley.EDU,
> "Thomas F. Burdick" <t...@apocalypse.OCF.Berkeley.EDU> wrote:
>
> >
> > For what it's worth, this is a huge problem I have with java: an
> > application's performance depends on the host JVM. I've got quite a
> > lovely setup here on Mac OS X, between Project Builder and Emacs/EJDE,
> > and the good JVM. Unfortunately, not everyone runs the HotSpot JVM on
> > a RISC machine. In Lisp, Obj-C, C++, Fortran, etc., I--the developer--can
> > ensure that the end user is running efficient object code code. Not so
> > for Java :-(
>
> Hmm,
>
> It seems that you are going a little too far, not in criticizing Java but in
> praising the alternatives. The OP was clearly mistaken to argue "Hey it runs
> fine on my box so it must run fine on yours" but I think that to some extent
> that goes for any language. Even the C X-compiler vendors are careful to
> limit their claims to "If it compiles and runs on the host and it compiles
> for the target it will run on the target." They carefully don't say that any
> optimizations that you make on the host will translate into better
> performance on the target.
>
> I would say that regardless of language, you can't know how your program
> performs on platform X until you test it there. The problem with Java is
> that its marketing folks pretended it was different.
Right, but that's not what I'm talking about. I can develop and test
my application in Lisp on, say, OpenMCL/OS X and CMUCL/Solaris, then
give users binaries for OS X and Solaris. I know what the object code
they're running is. With Java, the object code, and thus the
performance, depends on the *user's* setup. I'm not saying I can
develop on Solaris and deploy in Windows without a windows box. But
once I've deployed on Windows, I know what object code my users are
running.
Christian Nybų
Earlier in the thread this PHB of yours shoved two lisp hackers under
a passing bus to replace them with fifteen mediocre java coders, now
you state that he has no control over resource limitations nor
motivation? Perhaps it's better to restrict the discussion to just a
few possible worlds?
Let's assume you're right in that Java is better than Common Lisp for
mediocre programmers. Could a dumbed-down Common Lisp make mediocre
programmers as productive as Java does? What would you take away or
disable in the lisp environment?
--
chr
Bob Coyne
> Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
>
> Let's assume you're right in that Java is better than Common Lisp for
> mediocre programmers. Could a dumbed-down Common Lisp make mediocre
> programmers as productive as Java does? What would you take away or
> disable in the lisp environment?
I disagree with the assumption that Java is better than CL for mediocre
programmers. When I was at Symbolics Graphics Division we sold
graphics systems to video editors and animators who were not programmers
at all and quite a few of them learned enough Lisp to do useful stuff and
became fairly proficient programmers as time went on. This was because
of the power of the Lisp language and environment (things like apropos, the
interpreter, dynamic windows, etc). You could just type in a form and see
your 3d object move in the 3D viewer, for example. That's great immediate
feedback and makes it easy to learn.
So I think Lisp can be ideal for novice and mediocre programmers. That assumes
the infrastructure (GUI, application, etc) exists to do something useful and
visible.
Chris Gehlker
"Thomas F. Burdick" <t...@avalanche.OCF.Berkeley.EDU> wrote:
>
> Right, but that's not what I'm talking about. I can develop and test
> my application in Lisp on, say, OpenMCL/OS X and CMUCL/Solaris, then
> give users binaries for OS X and Solaris. I know what the object code
> they're running is. With Java, the object code, and thus the
> performance, depends on the *user's* setup. I'm not saying I can
> develop on Solaris and deploy in Windows without a windows box. But
> once I've deployed on Windows, I know what object code my users are
> running.
I, finally, get it. We agree that, for any language, if you claim to support
targets x, y and z you better have tested on targets x, y and z. You're
making the additional point that for Java, "target" doesn't just mean
"hardware platform", it means every combination of hardware/JVM. So
multi-platform support is actually harder in Java if performance matters
because there are more platforms.
This may be why Apple added Jikes to PB. If a user says "this app sucks in
terms of performance" you can recompile with Jikes and, give him that
version, and say "Try this. *Maybe* it will work better for you."
Michael Sullivan
> I would say that regardless of language, you can't know how your program
> performs on platform X until you test it there. The problem with Java is
> that its marketing folks pretended it was different.
I think it goes further than that. With java, you are dependent on the
JVM, so any target for which there is no good JVM (or none suited to
your program) is SOL, unless you're willing to write your own JVM.
Testing might only demonstrate this, it doesn't necessarily give you any
opportunity to fix it. In a language with a compiler for that target,
you get an opportunity to fix it. Admittedly, a bad compiler selection
for a target can cause the same problem as a bad JVM selection
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT mic...@bcect.com
Chris Gehlker
"Michael Sullivan" <mic...@bcect.com> wrote:
> Chris Gehlker <geh...@fastq.com> wrote:
>
>> I would say that regardless of language, you can't know how your program
>> performs on platform X until you test it there. The problem with Java is
>> that its marketing folks pretended it was different.
>
> I think it goes further than that. With java, you are dependent on the
> JVM, so any target for which there is no good JVM (or none suited to
> your program) is SOL, unless you're willing to write your own JVM.
> Testing might only demonstrate this, it doesn't necessarily give you any
> opportunity to fix it. In a language with a compiler for that target,
> you get an opportunity to fix it. Admittedly, a bad compiler selection
> for a target can cause the same problem as a bad JVM selection
I finally got the point after Thomas said it two different ways, but now you
have me curious. Are there really general purpose computer/OS combos out
there without JVMs of any sort. I remember there was no JVM for BeOS but I
thought that was the only victim. Isn't there supposed to be a JVM for every
cell phone in the world?
Duane Rettig
> "Christian Nybų" wrote:
>
> > Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
> >
> > Let's assume you're right in that Java is better than Common Lisp for
> > mediocre programmers. Could a dumbed-down Common Lisp make mediocre
> > programmers as productive as Java does? What would you take away or
> > disable in the lisp environment?
>
> I disagree with the assumption that Java is better than CL for mediocre
> programmers. When I was at Symbolics Graphics Division we sold
> graphics systems to video editors and animators who were not programmers
> at all and quite a few of them learned enough Lisp to do useful stuff and
> became fairly proficient programmers as time went on. This was because
> of the power of the Lisp language and environment (things like apropos, the
> interpreter, dynamic windows, etc). You could just type in a form and see
> your 3d object move in the 3D viewer, for example. That's great immediate
> feedback and makes it easy to learn.
But this actually lends credence to the assertion that CL is bad for
mediocre programmers, because it tends to draw them toward becoming
exceptional. If a PHB wants to keep his department mediocre (and
thus low-paid, less independent, etc) he would certainly not choose CL ...
I almost put a smiley here, but unfortunately it tends to be true
in situations where turnover is high and where programmer cost is
more of an immediate concern than program quality. Of course, the
forward-thinking manager will realize that increasing program
quality will eventually drive down costs, and those are the managers
to whom we are more successful selling CL.
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
thelifter
> Every time you learn a new language, you gain insights into how to solve
> problems with the language that you use most often. Every language
> facilitates certain approaches to problem solving and discourages others.
> But Kay asserted that some languages "crystallize" a style of problem
> solving, making it very explicit while almost forcing the programmer to
> adopt it. Others might accommodate the new style but they will also
And what is it that SmallTalk crystallizes? Concerning OOP I have
used:
Eiffel, C++ and Java. Is there anything that Smalltalks offers in
addition? Do I still need to learn SmallTalk? Please give me a precise
answer.
Thanks
Chris Gehlker
<du...@franz.com> wrote:
> But this actually lends credence to the assertion that CL is bad for
> mediocre programmers, because it tends to draw them toward becoming
> exceptional. If a PHB wants to keep his department mediocre (and
> thus low-paid, less independent, etc) he would certainly not choose CL ...
Has everybody seen this?:
http://home.earthlink.net/~mrob/pub/lang_srom.html
I don't think it proves anything but it fits pretty well with my intuition.
What's interesting is that are more people who know/care enough about Lisp
to post an opinion about it than there are such people who know/care about
Java. In fact, Lisp beats out everything but the C/C++ aggregate in this
regard. The other interesting thing is that of those who do care enough
about Java to post an opinion, half think it sucks.
It may be reasonable to conclude that whatever is holding Lisp back from
world domination, it's not obscurity and it's not a bad reputation. Lisp
seems to be both well known and highly regarded.
I personally have *never* heard an unqualified bash of Lisp. The strongest I
have heard is things like "Lisp is hard to read but it's very expressive."
Compared to the typical things one hears, that's an endorsement.
Thomas F. Burdick
I don't know Eiffel, but I'd say "yes", since you listed it with the
other two. Java gives you an inkling of what using a 100%-OOP
language is like. C++ doesn't even give you that.
> Please give me a precise answer.
I suspect this translates as "I am a troll", but I'm answering anyway.
(Hmm, Edi Weitz was right to praise the lack of internet access in
cafes. Maybe I should move.)
Chris Gehlker
b295356a.02120...@posting.google.com, "thelifter"
<thel...@gmx.net> wrote:
I'm not familiar enough with Eiffel to really comment there but with regards
to C++ and Java, you have yet to use an OO language. Stroustrup himself says
that C++ is not an OO language. It's a general purpose language that will
let you do OO if you want to and know how. But it also supports procedural
and generic programming by design. So one can write perfectly good
procedural, generic, or procedural/generic programs in C++ and never go near
00, just a one can write perfectly good Lisp programs without going near
CLOS.
Now to say Java is not an OO language is more controversial because Sun
markets it as an OO language. But if you get a chance to talk to someone
from Sun, ask them if Java is OO in the same sense as Smalltalk. They will
readily admit that Smalltalk is "pure OO", (I've even heard "Extreme 00" a
couple of times) and Java isn't. What it is, is a language that's a little
more along the continuum from C or Pascal to Smalltalk than is C++. I use
Java sometimes because of its great built-in or easily incorporated network
support and it so happens that, given what I was trying to do, I wanted to
write straight procedural code. So I used classes as structs and methods as
functions and wrote what amounted to straight C in Java and it worked fine.
Maybe that's not so surprising, since I was consciously doing it, but I've
also seem a few books on Java where the sample code looked just like what I
did.
Now I don't doubt that you *could* write C in Smalltalk if you really wanted
to but it would be hard. Smalltalk is designed to support the OO style
really well and nothing else at all.
So are you an OO programmer? I can't tell without doing a code review. And
maybe you can't tell, how could you?, without getting a code review from an
OO programmer.
Well, there is one other way to find out, and it's fun. Go get Squeak
Smalltalk which is free and multi-platform. Write something simple like a
tic-tac-toe game. If it's easy, you are an OO programmer and Smalltalk has
nothing to teach you. I'll bet you keep Squeak though.
If its hard or feels weird to program that way, then you are not an OO
programmer (yet) and you will have to decide whether to persist or adopt a
different paradigm.
Maybe that wasn't too precise but I hope it helps.
Duane Rettig
> On 12/6/02 2:00 PM, in article 47kemc...@beta.franz.com, "Duane Rettig"
> <du...@franz.com> wrote:
>
> > But this actually lends credence to the assertion that CL is bad for
> > mediocre programmers, because it tends to draw them toward becoming
> > exceptional. If a PHB wants to keep his department mediocre (and
> > thus low-paid, less independent, etc) he would certainly not choose CL ...
>
> Has everybody seen this?:
>
> http://home.earthlink.net/~mrob/pub/lang_srom.html
>
> I don't think it proves anything but it fits pretty well with my intuition.
> What's interesting is that are more people who know/care enough about Lisp
> to post an opinion about it than there are such people who know/care about
> Java. In fact, Lisp beats out everything but the C/C++ aggregate in this
> regard. The other interesting thing is that of those who do care enough
> about Java to post an opinion, half think it sucks.
>
> It may be reasonable to conclude that whatever is holding Lisp back from
> world domination, it's not obscurity and it's not a bad reputation. Lisp
> seems to be both well known and highly regarded.
C++ doesn't dominate me, and Java certainly doesn't dominate me. What
measure do you use to judge what language has achieved world domination?
Is that really a reasonable goal?
Your reference above may only be an indicator of how loud people are,
rather than how sucessful a language is (or how highly people regard a
language). To qualify such an interesting chart in my eyes, I would have
to see the number of originators of such content; one or two sites would
easily skew results in any direction chosen.
Not that I don't like the results that are there; in fact, what makes
you sure Lisp is "held back"?
> I personally have *never* heard an unqualified bash of Lisp. The strongest I
> have heard is things like "Lisp is hard to read but it's very expressive."
> Compared to the typical things one hears, that's an endorsement.
I have seen unqualified Lisp bashings, although they are much fewer in
number nowadays, and they are almost always of the "lisp is big and slow"
variety, or the "lisp is dead" variety, which clearly don't apply to
the current CL situation. And the perennial statement about lisp having
"too many parentheses" is not a bashing at all; that's like telling a
medieval executioner that his mortality rate is too high.
Pascal Bourguignon
thel...@gmx.net (thelifter) writes:
I'd say: Meta-Classes.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. do not adjust your minds. -- Salman Rushdie
Pascal Costanza
> Chris Gehlker <geh...@fastq.com> wrote in message news:<BA13F66A.2407D%geh...@fastq.com>...
>
>>Every time you learn a new language, you gain insights into how to solve
>>problems with the language that you use most often. Every language
>>facilitates certain approaches to problem solving and discourages others.
>>But Kay asserted that some languages "crystallize" a style of problem
>>solving, making it very explicit while almost forcing the programmer to
>>adopt it. Others might accommodate the new style but they will also
>
>
> And what is it that SmallTalk crystallizes? Concerning OOP I have
> used:
> Eiffel, C++ and Java. Is there anything that Smalltalks offers in
> addition?
Here are some points.
* Smalltalk offers a lack of static type checking. Some people
(including me) see this as an advantage. Static type checking is an
advantage only on a very superficial level. (Eiffel's design by contract
makes things even worse IMHO, but I haven't yet found anyone to
sympathize with this assessment.)
Of course, YMMV. But it's definitely a good thing to have experienced
both languages with and without static type checking.
* Smalltalk offers closures (blocks) - C++ doesn't have them, Java only
has a crippled variant. I don't know enough about Eiffel in this regard.
* Some (the correct) implementations of Smalltalk offer continuations,
but I don't think they are used very often.
* Smalltalk is purely object-oriented - that means that, for example,
numbers and classes are also instances of their respective classes.
In practice, I prefer languages that allow combination of different
paradigms - but again, it's a good learning experience to work with
"pure" languages.
* Smalltalk was one of the first languages to include an advanced IDE,
including, for example, a class browser. Java has only recently caught
up with the flexibility and productivity Smalltalk (as a development
environment) has already offered for two decades.
> Do I still need to learn SmallTalk? Please give me a precise
> answer.
I don't see how precision could be of any help in this regard. Of
course, you don't need to learn anything. But consider a mechanic asking
these questions: "I have already used various screwdrivers. Is there
anything other tools offer in addition? Do I still need to learn them?
Please give me a precise answer."
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
Peter Seibel
Chris> On 12/6/02 11:51 AM, in article
Chris> xcvn0nj...@avalanche.OCF.Berkeley.EDU,
Chris> "Thomas F. Burdick" <t...@avalanche.OCF.Berkeley.EDU> wrote:
Chris> This may be why Apple added Jikes to PB. If a user says
Chris> "this app sucks in terms of performance" you can recompile
Chris> with Jikes and, give him that version, and say "Try this.
Chris> *Maybe* it will work better for you."
A bit OT but: you mean the compiler Jikes? From IBM? If so, they
probably added it because it compiles about a billion times faster
than javac. But the performance of the resulting code is unlikely to
be different than code compiled with javac--the .class files are not
noticibly different, AFAIK. (And I have had some occasion to look at
and compare the generated bytecodes, though not with this question in
mind.) In general, the Java world doesn't care much how you *compile*
the code--none of the .java-to-.class compilers seem to bother with
optimizations; they leave that for the JITs (just-in-time compiler) in
the VM to do the magic. In fact, you could imagine that writing a
really tricky compiler that generates super optimized bytecodes might
be counter productive because you'll just fake out the JIT which may
be looking for certain patterns in the bytecode that are common in
normal-compiler output and that it knows how to optimize the heck out
of. (Though that's just a theory I made up.)
-Peter
--
Peter Seibel
pe...@javamonkey.com
Chris Gehlker
"Pascal Costanza" <cost...@web.de> wrote:
> Eiffel's design by contract
> makes things even worse IMHO, but I haven't yet found anyone to
> sympathize with this assessment.
You just aren't hanging out with the right folks. The Unit Testing/Extreme
Programming advocates love to poke holes in DBC and they mostly do it by
posting Eiffel code that breaks.
I don't know much about the issue myself. I confess that I stay away from
Eiffel because my buddies say it sucks and life is to short to try
everything. Not a compelling argument.
Friedrich Dominicus
>
> * Smalltalk offers a lack of static type checking. Some people
> (including me) see this as an advantage. Static type checking is an
> advantage only on a very superficial level. (Eiffel's design by
> contract makes things even worse IMHO, but I haven't yet found anyone
> to sympathize with this assessment.)
>
>
> Of course, YMMV. But it's definitely a good thing to have experienced
> both languages with and without static type checking.
>
>
> * Smalltalk offers closures (blocks) - C++ doesn't have them, Java
> only has a crippled variant. I don't know enough about Eiffel in this
> regard.
called Agents there.
>
>
> * Smalltalk is purely object-oriented - that means that, for example,
> numbers and classes are also instances of their respective classes.
>
>
> In practice, I prefer languages that allow combination of different
> paradigms - but again, it's a good learning experience to work with
> "pure" languages.
choice". I have looked as Haskell while learning Common Lisp too, that
has helped me considerably to understand "functional programming"
Regards
Friedrich
Chris Gehlker
Seibel" <pe...@javamonkey.com> wrote:
>>>>>> "Chris" == Chris Gehlker <geh...@fastq.com> writes:
>
> Chris> This may be why Apple added Jikes to PB. If a user says
> Chris> "this app sucks in terms of performance" you can recompile
> Chris> with Jikes and, give him that version, and say "Try this.
> Chris> *Maybe* it will work better for you."
>
> A bit OT but:
People don't seem to mind if you are somehow comparing Lisp to Java.
> you mean the compiler Jikes? From IBM?
Yes
> If so, they
> probably added it because it compiles about a billion times faster
> than javac. But the performance of the resulting code is unlikely to
> be different than code compiled with javac--the .class files are not
> noticibly different, AFAIK. (And I have had some occasion to look at
> and compare the generated bytecodes, though not with this question in
> mind.) In general, the Java world doesn't care much how you *compile*
> the code--none of the .java-to-.class compilers seem to bother with
> optimizations; they leave that for the JITs (just-in-time compiler) in
> the VM to do the magic. In fact, you could imagine that writing a
> really tricky compiler that generates super optimized bytecodes might
> be counter productive because you'll just fake out the JIT which may
> be looking for certain patterns in the bytecode that are common in
> normal-compiler output and that it knows how to optimize the heck out
> of. (Though that's just a theory I made up.)
It all sounds persuasive. It makes me wonder why they left javac as the the
default.
The implications for Java are pretty bad though. If the code runs fine on
your machine but not on your users, then given what you say above and
assuming there isn't another JVM for that platform lying around, your only
choices are to persuade the user to switch platforms or write a better JVM
yourself. At that point, you will probably wish you had not chosen Java.
Michael Sullivan
> On 12/6/02 12:47 PM, in article 1fmrvfa.16gy4z8twki4fN%mic...@bcect.com,
> "Michael Sullivan" <mic...@bcect.com> wrote:
> > Chris Gehlker <geh...@fastq.com> wrote:
> >> I would say that regardless of language, you can't know how your program
> >> performs on platform X until you test it there. The problem with Java is
> >> that its marketing folks pretended it was different.
> > I think it goes further than that. With java, you are dependent on the
> > JVM, so any target for which there is no good JVM (or none suited to
> > your program) is SOL, unless you're willing to write your own JVM.
> > Testing might only demonstrate this, it doesn't necessarily give you any
> > opportunity to fix it. In a language with a compiler for that target,
> > you get an opportunity to fix it. Admittedly, a bad compiler selection
> > for a target can cause the same problem as a bad JVM selection
> I finally got the point after Thomas said it two different ways, but now you
> have me curious. Are there really general purpose computer/OS combos out
> there without JVMs of any sort. I remember there was no JVM for BeOS but I
> thought that was the only victim. Isn't there supposed to be a JVM for every
> cell phone in the world?
I don't know many platforms that have *no* JVM, but some of them are
pretty lousy. The macOS 8/9 JVM sucks dead bunnies through a straw. I
never ran anything on it that didn't crash every 15 minutes and have all
kinds of strange anomalies. Note, I'm not a java programmer (though
it's similar enough to C et. al. that I can mostly understand it), so
it's possible I was just dealing with poor code, but it was all stuff
that people on windows and certain unices (including early OSX versions)
reported running smoothly.
Michael
Paolo Amoroso
wrote:
> I disagree with the assumption that Java is better than CL for mediocre
> programmers. When I was at Symbolics Graphics Division we sold
> graphics systems to video editors and animators who were not programmers
> at all and quite a few of them learned enough Lisp to do useful stuff and
> became fairly proficient programmers as time went on. This was because
Something similar also happens with Emacs.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Wade Humeniuk
"Jock Cooper" <jo...@mail.com> wrote in message news:m37keps...@jcooper02.sagepub.com...
> I'm not even sure why we are discussing all this in the first place.
> My original point was how two programs can both produce the same
> output, with one being simple and one being complex. You had stated
> that two programs which do the same thing are the same complexity.
> Now you seem to be arguing that it is unnecessary for a program to be
> internally complex or reusable.
>
> I wasn't really addressing which is the right way to do it. It is a
> design choice which way to write it. It depends on how much you
> expect requirements to change, enhancements to be requested, and/or
> future projects which will work similarly.
Yes exactly, it depends and there is not fixed answer. It involves
trade-offs and idealism applied in some kind of balance. That
is one of the reasons I like CL so much, it is not fanatical.
Wade
Kenny Tilton
Chris Gehlker wrote:
> I confess that I stay away from
> Eiffel because my buddies say it sucks and life is to short to try
> everything.
Why didn't you listen to them when they said Lisp was dead?
:)
--
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
JB
>> Of course I cannot tell whether it is simply poorly
>> programmed or whether this is inherent to Java.
>
> Neither. Disclaimer: I'm the author of Jin. You are either
> running Jin on a very bad JVM or a very slow machine. I
> have run Jin on a Pentium 1 133Mhz machine with no
> noteable slowness.
Oh! I have been caught red handed!
I ran Jin on my Suse Linux 8.0 on a 1333MHz Athlon. The JVM
was the one I had downloaded from Sun.
Can you give me some piece of advice as to the JVM I should
use? (By the way: Jin was all right when I wanted to watch
a tournament but compared to BlitzIn it was slow. I have
not tried it on Windows.
--
JB
Chris Gehlker
Sullivan" <m...@panix.com> wrote:
> I don't know many platforms that have *no* JVM, but some of them are
> pretty lousy. The macOS 8/9 JVM sucks dead bunnies through a straw. I
> never ran anything on it that didn't crash every 15 minutes and have all
> kinds of strange anomalies.
You're right. I'd forgotten about that one. Probably because it was too
painful to remember. And my wife's company still runs on OS9 so I guess it
has to be considered a living platform.
Chris Gehlker
<kti...@nyc.rr.com> wrote:
>
>
> Chris Gehlker wrote:
>> I confess that I stay away from
>> Eiffel because my buddies say it sucks and life is to short to try
>> everything.
>
> Why didn't you listen to them when they said Lisp was dead?
>
> :)
The conversation went something like this:
Me: Shall I learn Eiffel to plumb the mysteries of CBD and escape the burden
of testing, that weighteth me down sorley?
Buddies: Nay, for we have studied Eiffel and judged it. It deliverith not on
that which it promiseth. Cleave to the path of testing for it is arduous but
true.
Me: Why do you now?
Buddies: We study Haskell, that we may judge it.
Me: May I join you in this great endeavor?
Buddies: Nay, sorry, only the leet may judge, for the opinions of the vulgar
are as the wind from Redmond. The vulgar should'st limit their utterances to
condemnation of the offshoots of the tree of Wirth, for even a child may
recognize a monster.
Me: What must I do to become leet?
Buddies: Go forth and study Lisp!
When I left they were muttering about great beings who wander the world
disguised as decrepit beggars but I didn't get the allusion.
Rob Warnock
+---------------
| ...if a system has 100 screens, I'd wager about 5 of them are Interesting
| and the rest pretty rote. Rote enough for mediocre programmers, and
| perhaps rote enough to give a terrible programmer some good experience
| to grow with, but also so rote that when your Master Programer walks in
| in the morning and sees he has 75 to go, he may just put his head on his
| desk and whimper. That's just simple job satisfaction.
+---------------
Maybe. Or maybe the *real* Master Programmer is the one who walks in,
stares at the "75 to go", then spends a day or two building a screen-
building meta-coding tool, and polishes all 75 off on the third day
and takes a well-deserved long weekend off... (And maybe the following
week, too.)
-Rob
-----
Rob Warnock, PP-ASEL-IA <rp...@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>* Smalltalk offers a lack of static type checking. Some people
>>(including me) see this as an advantage. Static type checking is an
>>advantage only on a very superficial level. (Eiffel's design by
>>contract makes things even worse IMHO, but I haven't yet found anyone
>>to sympathize with this assessment.)
>
> this is strange opinion. Why do you think so?
Sorry for the time I have taken to answer this question, but it's a
rather complicated issue.
I see several points that are problematic with design by contract. Most
of these points can be solved better with unit testing framework IMHO (a
la JUnit and the like).
* side effects:
The invariants (pre-/post conditions, class invariants) need to be free
of side effects. One reason that's usually quoted for this requirement
is that developers want to switch off checking of invariants for
deployment. However, I think this requirement should even be fulfilled
without that reason because the conditions are supposed to only describe
the functionality provided by a class but don't provide "functionality"
(side effects) of their own.
In complex cases it can be hard to make sure that the code in the
invariants is really free of side effects. This fact fuels some research
on automatically determining this property for a certain class of
functions/methods. It's clear that this is generally not solvable, so
the proposals usually require the programmer to add declarations to
their functions if they are free of side effects or not.
A unit testing framework doesn't have this problem at all because here
the tests are defined externally, and of course they can include side
effects (and usually do so). After all, the methods to be tested should
work in various contexts...
* old values vs. new values:
Usually, the post conditions need to refer to the state of certain
variables before the computation. Here is an example.
(defmethod inc-by-1 (x)
(dbc:require t) ;; no preconditions
(incf x)
(dbc:provide (= (new x) (1+ (old x))))) ;; the postcondition
In order to make this work, the language has to provide a copy of the
previous state to the postcondition. In such a simple example, there are
no real problems. However, if the variables involved hold references to
complex data structures, this results in several issues: 1) Do we need
shallow or deep copy? How much memory do we want to use for these
copies? Intuitively, a deep copy should do the job, however it can be
shown that there are several cases where a deep copy is _not_ correct.
(See "Copying and Comparing: Problems and Solutions" by Peter Grogono
and Markku Sakkinen, ECOOP 2000.) Generally, the appropriate copy
operation depends on the concrete data structure, so we have to use the
copy operation that is provided with the data structure. But then: 2) Is
this copy operation free of side effects? Or rather: Does this copy
operation only carry out the side effects we want?
Again, these questions fuel further (useless) research, and again, unit
testing frameworks don't have these problems. In a unit test, you can
just store the values that are of interest to a particular test before
calling the method to be tested and refer to these afterwards. (In turn,
this approach is not easy with dbc, because you would need to store
values within the precondition - but weren't the preconditions supposed
to be free of side effects?)
* internal / external calls:
If a method m calls another method n internally, but that method n can
also be called from the outside, there are situations where you want the
invariants to be checked only for the external calls, but not for the
internal ones. (The idea is that a method should be able to temporarily
break the invariants, but only needs to ensure them before the return to
the caller.)
There are situations where it's hard for the runtime environment to
determine if a call is an internal or an external one.
* inheritance of conditions:
One of the strongest problems that dbc has IMHO is the inheritance of
invariants (of which Bertrand Meyer even thinks that it is the
cornerstone of OOP). This results in the mathematically inclined
requirement that preconditions can only be generalized in subclasses and
postconditions can only be restricted. However, there are situations
where you want to restrict preconditions and/or generalize
postconditions. This is also known as covariant redefinition. (Covariant
redefinitions are no problem at all in dynamically typed languages, and
can even be allowed in statically typed systems when the compiler has
global knowledge. See "Object-Oriented Type Systems" by Jens Palsberg
and Michael Schwartzbach.)
* symmetry breaking:
The latter point can also be reworded as follows: Design by contract is
an approach to ensure the Liskov Substitution Principle that in turn
ensures a certain kind of symmetry between classes and their subclasses.
However, a useful language needs ways to break symmetry and it's not
clear to me how to achieve that with dbc. (See for example
http://www.rcnchicago.com/~jcoplien/Patterns/Symmetry/Springer/SpringerSymmetry.html)
* class invariants:
As I said before, most of the problems that dbc has are easier to solve,
or simply don't exist, in a unit testing framework. However, dbc offers
class invariants that can be checked for at arbitrary places. I don't
know if this can easily be accomplished with unit testing. I guess that
Common Lisp has an advantage in this regard because of the method
combinations that allow you to insert arbitrary code into existing
methods. However, class invariants might still be easier to use with dbc
support.
I hope this helps.
Kenny Tilton
Rob Warnock wrote:
> Will Hartung <wi...@msoft.com> wrote:
> +---------------
> | ...if a system has 100 screens, I'd wager about 5 of them are Interesting
> | and the rest pretty rote. Rote enough for mediocre programmers, and
> | perhaps rote enough to give a terrible programmer some good experience
> | to grow with, but also so rote that when your Master Programer walks in
> | in the morning and sees he has 75 to go, he may just put his head on his
> | desk and whimper. That's just simple job satisfaction.
> +---------------
>
> Maybe. Or maybe the *real* Master Programmer is the one who walks in,
> stares at the "75 to go", then spends a day or two building a screen-
> building meta-coding tool, and polishes all 75 off on the third day
> and takes a well-deserved long weekend off... (And maybe the following
> week, too.)
exactly. i did that once (but on nineteen screens and it took three
weeks, but then I was using COBOL and all I had going for me was the
template mechanism "COPY <source-file> REPLACING <token> WITH <stuff>....
Even without such a huge productivity win, the Master programmer will at
least develop a framework which will automate coding of modules, with
wins in both development time/cost but /especially/ maintenance. And
flexibility, has when management suddenly decides all the screens have
to work a little different breaking now just one framework instead of 75
hardcoded apps.
Skull
> Chris Gehlker <geh...@fastq.com> writes:
>
> > 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.
>
> Why should a programmer learn Smalltalk in addition to Common Lisp?
I found the syntax irritating and quit after a few minutes...
I barely have a few minutes a day to spend on my favorite
programming langauge, let alone smalltalk.
(this may change, as I've discovered how to place ACL
right down in the middle of my critical path--use it
to replace 5 separate tools I'm using for 5 different
data sources: TOAD, QueryAnalyzer, LDAP browser,
internet search, and Outlook. hurray! ) uh, wouldn't
this just be Emacs?
Alexander Maryanovsky
on a 1333Mhz machine it should run fine under any JVM. You might feel
that the UI isn't as responsive as with native apps, but that is quite
different from "slowness". Also, you might have experienced a very
annoying bug regarding XOR painting in Sun's JDK 1.4 and mistaken that
for performance problems. The URL of the bug report is:
http://developer.java.sun.com/developer/bugParade/bugs/4665237.html
Alexander Maryanovsky.
JB <jbl...@hotmail.com> wrote in message news:<astf9t$unrk8$1...@ID-167393.news.dfncis.de>...
Pekka P. Pirinen
[Much useful exploration of the weaknesses of DBC and Eiffel snipped]
> * old values vs. new values:
>
> Usually, the post conditions need to refer to the state of certain
> variables before the computation. Here is an example.
>
> (defmethod inc-by-1 (x)
> (dbc:require t) ;; no preconditions
> (incf x)
> (dbc:provide (= (new x) (1+ (old x))))) ;; the postcondition
>
> In order to make this work, the language has to provide a copy of the
> previous state to the postcondition. In such a simple example, there are
> no real problems. However, if the variables involved hold references to
> complex data structures, this results in several issues: 1) Do we need
> shallow or deep copy? How much memory do we want to use for these
> copies? Intuitively, a deep copy should do the job, however it can be
> shown that there are several cases where a deep copy is _not_ correct.
> (See "Copying and Comparing: Problems and Solutions" by Peter Grogono
> and Markku Sakkinen, ECOOP 2000.) Generally, the appropriate copy
> operation depends on the concrete data structure, so we have to use the
> copy operation that is provided with the data structure.
That seem the wrong way round: surely the appropriate copy operation
depends on the abstract structure. Consider that many abstract
structures can be implemented as linear lists. Furthermore, the
appropriate copy operation also depends on the equality test, that is,
they have to work together, since what we're really doing is testing
that the side effect made by the method was correct.
This is not unrelated to the point that there are no universal Copy
and Equality operators, see Kent's
<http://world.std.com/~pitman/PS/EQUAL.html>.
However, it seems to me that these pitfalls can be avoided by
delegating the copying to the programmer:
(defmethod inc-by-1 (x)
(let ((old-x x)) ; no special copy required in this example
(dbc:require t) ; no preconditions
(incf x)
(dbc:provide (= x (1+ old-x))))) ; the postcondition
The programmer knows what comparison they are attempting to write. If
the language attempts to manage the conditions, this will become much
harder. And we need one of them sufficiently smart compilers to
eliminate the copy when we build a release version without the tests -
or a LET-FOR-CONDITIONS.
> * inheritance of conditions:
>
> [...] requirement that preconditions can only be generalized in
> subclasses and postconditions can only be restricted. However, there
> are situations where you want to restrict preconditions and/or
> generalize postconditions. [...]
>
> * symmetry breaking:
>
> The latter point can also be reworded as follows: Design by contract is
> an approach to ensure the Liskov Substitution Principle that in turn
> ensures a certain kind of symmetry between classes and their subclasses.
> However, a useful language needs ways to break symmetry and it's not
> clear to me how to achieve that with dbc. (See for example
> http://www.rcnchicago.com/~jcoplien/Patterns/Symmetry/Springer/SpringerSymmetry.html)
I agree with your point here, but don't support it by arguments from
that paper (despite the merit of the authors in other fields)! I took
a look at it, because this sounded exciting, and it severely
overreaches itself and blatantly mangles the terminology.
In particular, the bit in section 4.3 about inheritance as symmetry
defines it as symmetry in a single, linear subtyping path where all
the classes are considered equivalent! Naturally, in such a set, any
transformation is a symmetry, but the triviality of this seems to have
escaped the authors. Not content with this, they go on to prove that
"the set of all invertible inheritance operations" forms a symmetry
group, these operations being - as near as I can make out -
derivations of a subclass from one of its superclasses, i.e., they're
not even binary operations!
I couldn't bear to read all of it, but as far as subclasses go, the
bit in section 6.2 about multimethods breaking LSP is just wrong.
I'm surprised it's been accepted for publication.
--
Pekka P. Pirinen
The gap between theory and practice is bigger in practice than in theory.
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
> [Much useful exploration of the weaknesses of DBC and Eiffel snipped]
>
>
>>* old values vs. new values:
>>
>>Usually, the post conditions need to refer to the state of certain
>>variables before the computation. Here is an example.
>>
>>(defmethod inc-by-1 (x)
>> (dbc:require t) ;; no preconditions
>> (incf x)
>> (dbc:provide (= (new x) (1+ (old x))))) ;; the postcondition
>>
>>In order to make this work, the language has to provide a copy of the
>>previous state to the postcondition.
[...]
> However, it seems to me that these pitfalls can be avoided by
> delegating the copying to the programmer:
>
> (defmethod inc-by-1 (x)
> (let ((old-x x)) ; no special copy required in this example
> (dbc:require t) ; no preconditions
> (incf x)
> (dbc:provide (= x (1+ old-x))))) ; the postcondition
>
> The programmer knows what comparison they are attempting to write.
[...]
Yes, you're right, good point. However, this reintroduces the problem of
side effects in the invariants.
However, it could be the case that dbc as implemented in Eiffel is an
example of LFM - could dbc usefully be reduced in an LFSP style? (In the
sense that, for example, smart programmers know how to avoid side effects?)
>>* inheritance of conditions:
>>
>>[...] requirement that preconditions can only be generalized in
>>subclasses and postconditions can only be restricted. However, there
>>are situations where you want to restrict preconditions and/or
>>generalize postconditions. [...]
>>
>>* symmetry breaking:
>>
>>The latter point can also be reworded as follows: Design by contract is
>>an approach to ensure the Liskov Substitution Principle that in turn
>>ensures a certain kind of symmetry between classes and their subclasses.
>>However, a useful language needs ways to break symmetry and it's not
>>clear to me how to achieve that with dbc. (See for example
>>http://www.rcnchicago.com/~jcoplien/Patterns/Symmetry/Springer/SpringerSymmetry.html)
>
>
> I agree with your point here, but don't support it by arguments from
> that paper (despite the merit of the authors in other fields)! I took
> a look at it, because this sounded exciting, and it severely
> overreaches itself and blatantly mangles the terminology.
I am sorry, I should have noted that this is obviously work in progress.
Jim Coplien told me that they have already found some bugs in the
current papers and are working on improvements.
[...]
> I'm surprised it's been accepted for publication.
One sometimes gets the impression that some papers are accepted because
the reviewers don't want to admit that they don't understand the
contents. :->
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)
Charlton Wilbur
RW> Maybe. Or maybe the *real* Master Programmer is the one who
RW> walks in, stares at the "75 to go", then spends a day or two
RW> building a screen- building meta-coding tool, and polishes all
RW> 75 off on the third day and takes a well-deserved long weekend
RW> off... (And maybe the following week, too.)
I aspired to this level of Master Programmerhood at one point; then I
realized that doing in an hour what would take an average person an
entire week meant that you were expected to do the work of 40, often
for the same pay. And there aren't long weekends off, either.
Charlton
Thomas F. Burdick
Hmmm. My advice would be to either (a) find a job where you get
something like proportional compensation/appreciation; or (b) don't
let anyone know exactly how productive you are, and spend the extra
time playing or doing research.
Brad Miller
"Thomas F. Burdick" <t...@blizzard.OCF.Berkeley.EDU> wrote in message
news:xcvlm2x...@blizzard.OCF.Berkeley.EDU...
> Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
>
> > >>>>> "RW" == Rob Warnock <rp...@rpw3.org> writes:
> >
> > RW> Maybe. Or maybe the *real* Master Programmer is the one who
> > RW> walks in, stares at the "75 to go", then spends a day or two
> > RW> building a screen- building meta-coding tool, and polishes all
> > RW> 75 off on the third day and takes a well-deserved long weekend
> > RW> off... (And maybe the following week, too.)
> >
> > I aspired to this level of Master Programmerhood at one point; then I
> > realized that doing in an hour what would take an average person an
> > entire week meant that you were expected to do the work of 40, often
> > for the same pay. And there aren't long weekends off, either.
>
> Hmmm. My advice would be to either (a) find a job where you get
> something like proportional compensation/appreciation; or (b) don't
> let anyone know exactly how productive you are, and spend the extra
> time playing or doing research.
(A) probably means you have to start your own company as a practical matter.
In most companies, work grows to the point that you can no longer handle it,
without direct compensation. (Over the long term, you might get a promotion,
but generally you are better served by making business cases than by being
productive if you want to climb the ladder far). (B) is surprisingly easy,
and some companies even reward the fruits of the research (e.g., pay patent
and/or paper bounties). Also the line between playing and doing research is
pretty fine (he says as he orders another robot kit ;-).
Pekka P. Pirinen
> However, it could be the case that dbc as implemented in Eiffel is an
> example of LFM - could dbc usefully be reduced in an LFSP style? (In the
> sense that, for example, smart programmers know how to avoid side effects?)
OK, you lost me there: What do LFM and LFSP stand for? "SP" is for
"smart programmer", I can guess. Two acronym dictionaries and a quick
google left me no wiser. (Library File Maintenance? Landing Force
Manual? Large Furry Marsupial?)
Ignoring that, the answer is probably: Yes, a smart programmer could
benefit from verifying contracts even without much help from the
language. Using assertions is a major part of solid programming,
especially in unsafe languages.
--
Pekka P. Pirinen
A programming language is low level when its programs require attention to
the irrelevant. - Alan Perlis
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>However, it could be the case that dbc as implemented in Eiffel is an
>>example of LFM - could dbc usefully be reduced in an LFSP style? (In the
>>sense that, for example, smart programmers know how to avoid side effects?)
>
>
> OK, you lost me there: What do LFM and LFSP stand for? "SP" is for
> "smart programmer", I can guess. Two acronym dictionaries and a quick
> google left me no wiser. (Library File Maintenance? Landing Force
> Manual? Large Furry Marsupial?)
:)
I am terribly sorry - they mean "languages for the masses" and
"languages for smart people". (I am not sure if this is a useful
distinction - see
http://lambda.weblogs.com/discuss/msgReader$4365?mode=day for a discussion.)
> Ignoring that, the answer is probably: Yes, a smart programmer could
> benefit from verifying contracts even without much help from the
> language. Using assertions is a major part of solid programming,
> especially in unsafe languages.
Yes, assertions are extremely useful. I have the feeling that dbc is
very different in spirit - but it might just be that assertions are the
LFSP variant of dbc. Do you agree, or do you think there's something
more going on?
Christian Nybų
> OK, you lost me there: What do LFM and LFSP stand for? "SP" is for
> "smart programmer", I can guess. Two acronym dictionaries and a quick
> google left me no wiser. (Library File Maintenance? Landing Force
> Manual? Large Furry Marsupial?)
Michael Vanier writes at http://www.paulgraham.com/vanlfsp.html:
| Why are "languages designed for smart people" (LFSPs) so much more
| fun to program in than "languages designed for the masses" (LFMs)?
--
chr
Charlton Wilbur
TB> Charlton Wilbur <cwi...@mithril.chromatico.net> writes:
>> I aspired to this level of Master Programmerhood at one point;
>> then I realized that doing in an hour what would take an
>> average person an entire week meant that you were expected to
>> do the work of 40, often for the same pay. And there aren't
>> long weekends off, either.
TB> Hmmm. My advice would be to either (a) find a job where you
TB> get something like proportional compensation/appreciation; or
TB> (b) don't let anyone know exactly how productive you are, and
TB> spend the extra time playing or doing research.
I'm currently doing (b) and considering (a), but thanks for the
advice. (It's always nice to be agreed with.)
Charlton
Pascal Bourguignon
> Friedrich Dominicus wrote:
> > Pascal Costanza <cost...@web.de> writes:
> >
> >>* Smalltalk offers a lack of static type checking. Some people
> >>(including me) see this as an advantage. Static type checking is an
> >>advantage only on a very superficial level. (Eiffel's design by
> >>contract makes things even worse IMHO, but I haven't yet found anyone
> >>to sympathize with this assessment.)
> > this is strange opinion. Why do you think so?
>
> Sorry for the time I have taken to answer this question, but it's a
> rather complicated issue.
>
> I see several points that are problematic with design by
> contract. Most of these points can be solved better with unit testing
> framework IMHO (a la JUnit and the like).
Perhaps we don't mean the same thing by "design by contract", but for
me, pre/post conditions and invariants are not programming stuff like
a function, but mathematical stuff. They are mathematical proposition
saying something about the program. For me, "design by contract" is
using mathematics to specify and to prove a program. Therefore...
> * side effects:
An invariant or a pre/post condition cannot have side effect, because
a mathematical proposition has no effect.
Now, I agree that until we get powerful IA able to do all this
mathematical theorem proving work for us programmer, we can only use
that quick-and-dirty hack of writting functions to evaluate the truth
value of these mathematical proposition, and that of course, these
functions must not have side effects on the state of the program.
> * old values vs. new values:
Actually conditions and invariants can refer to anything they
want. You could introduce a semantic model of the application domain
and refer the boxes of shoes there is in a stock or whatever, that is
not necessarily to the reach of your function, but that is influenced
by a side effect of your function. So that could be much more
complicated than just copying data structures, you may have to
manipulate whole mathematical semantic models that are not even
instanciated in the computer memory. Anyway, the old value and the
current value of a variable is only an element of a mathematical set
and there is no problem to refer them and to prove propositions such
as an invariant or a post-condition about them.
Once again, you're speaking of a q&d hack consisting of copying some
bits to try to compute the truth value of mathematical proposition.
Did you write the pre/post conditions and invariants of this
processing? How will you hack THESE meta pre/post conditions and
invariants? (By the way, here is another hack: just before the
statement for which you want to check the post condition refering to
the old value, fork and run the statement only in the parent and then
use the memory space of child to retrieve the "old" value wherever it
may be stored and the memory space of the parent to retrieve the "new"
value...)
Moreover, notice that these postconditions presupose a mono-thread
programming model. How would you write the postcondition of x++ in
this case:
static volatile int x=0;
void thread1(void) { sleep(random()); x=0; }
void thread2(void) { /* pre: x==alpha */ x++; /* post: ? */ }
void main(void){ start_thread(thread1); start_thread(thread2); }
That's not so difficult, you just use some modal logic to write the
thread proposition. But that's similar to happens when you have
unexpected side effects: you must expect them!
> * internal / external calls:
> * inheritance of conditions:
Here, you're taking the problem feet over head. If you have covariant
subclasses, of if you want to be able to call an "internal" method
without "doing your part of the contract", you must, and you, as the
designer, only have to rewrite the contract. That is, once you write
the covariant overriding method, you change the contract of the
overrided method to state that finally, the precondition is not so
strict. Or said otherwise, if you start with a program with no
invariant and no pre/post condition specified, you can analyse it and
rebuild the the minimum invariants and conditions from the bottom
up. Then you'll have documented the behavior of that implementation,
and if it matches the formal specifications (you have formal
specifications haven't you) you'll have proved that your program
implements the specifications (or not, then you'll have found all the
bugs (granted all your deductions and all the mathematical proofs of
the matching are correct).
> * symmetry breaking:
> http://www.rcnchicago.com/~jcoplien/Patterns/Symmetry/Springer/SpringerSymmetry.html
Interesting, but misleading. First, it says that a list is not a set
and that a set is not a list, then it tries to implement a set as a
subtype of list. That's silly, and of course this leads to all sort
of problems. Perhaps there is a super type for both list and set,
where you can enumerate elements or where you can add, remove or count
elements. (But be careful with these postconditions! When you add an
element to a thingy-possibly-set-possibly-list, you don't always
increment the element count, it would be silly to write this in the
contract of that type!). But that's not the point. If you want to
use a list to implement a set, you just encapsulate the list of
elements in the set and all is well.
+--------+ +----------------------+
| List | | Set |
+--------+ |----------------------|
| | +--------+ |
/_\ WRONG! | elements: | List | | Right.
| | +--------+ |
+--------+ +----------------------+
| Set |
+--------+
The same problem exists with numerical types. Hopefully here,
mathematicians came first and defined correctly the subtype
relationship between Complex, Real, Integers, etc. And now, us
programmers should be surprized to see that Complex needs two Real and
that Integer need less bits to store than Real? And thus that perhaps
the hierarchy should be reversed? (Breaking Class Symmetry!?) Silly!
First note that we don't manipulate Complex or Real. We never do. Our
types are SubSetOfDecimal and (SubSetOfDecimal x SubSetOfDecimal), not
Real and Complex. So it should not be surprizing if we need more bits
to store supertypes than subtypes. More over, this number of storage
bit depends more on the range we choose to represent than anything
else. Imagine if you please: class Complex { bytes* storage }; class
Real:public Complex {/* nothing more! */}; class Integer:public Real
{}; and suddenly the symetry is kept!
Finally, about all this symetry affair, if we need to break some
symetry to create (discriminate) stuff, (afterall, playing with balls
is not funny passed a certain age), that does not mean that the
universal laws still apply and that the overall symetry still exists
in the fundamental equations. That's where Liskov Substitution
Principle stands. It does not prevent you to write the contracts of
any class, subclass or pattern you may introduce to break the symetry.
> * class invariants:
>
> As I said before, most of the problems that dbc has are easier to
> solve, or simply don't exist, in a unit testing framework. However,
> dbc offers class invariants that can be checked for at arbitrary
> places.
Not so arbitrarily. You cannot check it inside the methods of the
class.
> I don't know if this can easily be accomplished with unit
> testing. I guess that Common Lisp has an advantage in this regard
> because of the method combinations that allow you to insert arbitrary
> code into existing methods. However, class invariants might still be
> easier to use with dbc support.
Ok. So you're saying that some ad-hoc quick-and-dirty hack to compute
half-assedly truth values of invariants and pre/post condition is not
a panacea and has a lot of problems. True. So what for the "design
by contract" approach which is mathematical in essence? Implement
theorem provers instead!
> I hope this helps.
>
>
> Pascal
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. do not adjust your minds. -- Salman Rushdie
Pascal Costanza
>>I see several points that are problematic with design by
>>contract. Most of these points can be solved better with unit testing
>>framework IMHO (a la JUnit and the like).
>
>
> Perhaps we don't mean the same thing by "design by contract", but for
> me, pre/post conditions and invariants are not programming stuff like
> a function, but mathematical stuff. They are mathematical proposition
> saying something about the program. For me, "design by contract" is
> using mathematics to specify and to prove a program. Therefore...
>
>
>>* side effects:
>
>
> An invariant or a pre/post condition cannot have side effect, because
> a mathematical proposition has no effect.
Yes, but the problem in defining programming language support for dbc is
how to guarantee that conditions/invariants don't have side-effects (or
even worse: only the auxiliary side-effects that are needed).
>>* class invariants:
>>
>>As I said before, most of the problems that dbc has are easier to
>>solve, or simply don't exist, in a unit testing framework. However,
>>dbc offers class invariants that can be checked for at arbitrary
>>places.
>
>
> Not so arbitrarily. You cannot check it inside the methods of the
> class.
Correct.
>>I don't know if this can easily be accomplished with unit
>>testing. I guess that Common Lisp has an advantage in this regard
>>because of the method combinations that allow you to insert arbitrary
>>code into existing methods. However, class invariants might still be
>>easier to use with dbc support.
>
>
> Ok. So you're saying that some ad-hoc quick-and-dirty hack to compute
> half-assedly truth values of invariants and pre/post condition is not
> a panacea and has a lot of problems. True. So what for the "design
> by contract" approach which is mathematical in essence? Implement
> theorem provers instead!
OK, so perhaps we are really referring to different things. I have
always understood dbc to be the concept as proposed by Bertrand Meyer
and implemented in Eiffel. Apparently, you have a broader notion of what
dbc is about. Is this correct?
Pascal Bourguignon
It seems so.
Bertrand Meyer started from the mathematical theory of program proof too.
Note that the syntax for ensure or require is:
tag: boolean expression
or:
tag: comment
that is, either you have a simple boolean expression (something
without side effect that can be expressed in eiffel), or you just
write the mathematical proposition in the comment, and have a external
tool analyse the code and prove the assertions.
So the methodology is not restricted to what can be done by the
compiler.
For example, you could manipulate parameters for an limit to infinity
of an infinite sum of integral functions, and define pre and post
conditions in term of these limits that a non symbolic system like
eiffel will never be able to check. Or, to make it simplier, you
could just have propositions like (for all x in R, P(n,x)) and since
there is no type like R in any programming language, this kind of
proposition cannot be "run". At most, they could try to check the
proposition for all the decimals representable in their "float" types,
but they could never check P(n,pi) or P(n,sqrt(2)).
thomas
> Yes, assertions are extremely useful. I have the feeling that dbc is
> very different in spirit - but it might just be that assertions are the
> LFSP variant of dbc. Do you agree, or do you think there's something
> more going on?
>
>
> Pascal
An old comp.lang.eiffel thread (my googling fails me) made the
interesting point that people have found dbc to free them from
defensive programming.
IIRC The idea was:
- Defensive Programming
Write code chunks that can cope (more or less gracefully)
with any input they might conceivably receive. (Hard work)
- DBC
Write code chunks that accept only what you naively expect to
give them. (Easy)
Write Boolean assertions that record your assumptions. (Easy)
If you find that your code is not general enough (either you
read the assertions, or get a run-time contract violation),
go back and generalise so that it needs less restrictive
preconditions to protect it.
In contrast, Defensive programming requires you to do a lot of
pre-emptive generalisation.
thomas
Pascal Costanza
> An old comp.lang.eiffel thread (my googling fails me) made the
> interesting point that people have found dbc to free them from
> defensive programming.
That's surely an interesting point - however, we were not talking about
dbc vs. defensive programming. In fact, assertions also can be used in
that way ("to free you from defensive programming").
Thaddeus L Olczyk
(Pekka P. Pirinen) wrote:
>> * symmetry breaking:
>>
>> The latter point can also be reworded as follows: Design by contract is
>> an approach to ensure the Liskov Substitution Principle that in turn
>> ensures a certain kind of symmetry between classes and their subclasses.
I agree the a part of DBC is really LSP in disguise, but the symmetry
part...
>> However, a useful language needs ways to break symmetry and it's not
>> clear to me how to achieve that with dbc. (See for example
>> http://www.rcnchicago.com/~jcoplien/Patterns/Symmetry/Springer/SpringerSymmetry.html)
I'm suprised he is still onto this, I told him to drop it about two
and a half years ago when he asked my opinion.
>
>I agree with your point here, but don't support it by arguments from
>that paper (despite the merit of the authors in other fields)! I took
>a look at it, because this sounded exciting, and it severely
>overreaches itself and blatantly mangles the terminology.
>
On Tue, 10 Dec 2002 17:44:44 +0100, Pascal Costanza <cost...@web.de>
wrote:
:I am sorry, I should have noted that this is obviously work in progress.
:Jim Coplien told me that they have already found some bugs in the
:current papers and are working on improvements.
:
It worse then that he just doesn't understand symmetry. He defines
symmetry as something that changes but sort of doesn't change
( an invariant ). In a symmetry things just stay the same. The
classical example in electrodynamics is the gauge potential of an
electromagnetic field. If you change the gauge of the gauge potential,
the electric field, the magnetic field, the energy, the way that
particles move in the system don't change. This is because the gauge
potential is not itself a physiucal field and cannot be measured.
( Well, it does have an effect, but to see it you need an infinite
system, unsymmetric boundary conditions, and a "quatized" universe. )
He also incorrectly defines invariant. Invariants of a symmetry are
the byproducts of the symmetry not the generators. In the EM example,
an invariant would be the fact that the magnitic flux coming out of
a rgion is independent of the shape of the box ( change it from a
sphere to a box and you get the same flux -- Noether's theorem).
Polymoprhism as a symmetry is just ass backwards.
You take one object and you replace it with another object
and the program changes. You change the guage with a guage equivalent
one and the physics doesn't change.
Part of the problem is that he heavily relies on a popularisation
( Rosen ). Most people know that if you rely on a popularisation
for your information, then you are going to be highly misinformed.
>In particular, the bit in section 4.3 about inheritance as symmetry
>defines it as symmetry in a single, linear subtyping path where all
>the classes are considered equivalent! Naturally, in such a set, any
>transformation is a symmetry, but the triviality of this seems to have
>escaped the authors. Not content with this, they go on to prove that
>"the set of all invertible inheritance operations" forms a symmetry
>group, these operations being - as near as I can make out -
>derivations of a subclass from one of its superclasses, i.e., they're
>not even binary operations!
>
>I couldn't bear to read all of it, but as far as subclasses go, the
>bit in section 6.2 about multimethods breaking LSP is just wrong.
>
I couldn't either I actually only read through half of two and then
skimmed for definitions. It was the same with a previous paper.
That's part of why it's so hard to explain. ( The other half
is because it's hard to put everything I have to explain in an email.
Most of it comprises several text boooks. I have to meet him face to
face. )
>I'm surprised it's been accepted for publication.
>One sometimes gets the impression that some papers are accepted because
>the reviewers don't want to admit that they don't understand the
>contents. :->
And the name.
In the mid 80's the editor of General Relativity and Graviation
apologised for the behaviour of a person. That person was
a rabid "Einstein is wrong" sort of guy, who claimed to have
proof from an experiment. Most others contested his interpretation.
GRG agreed to publish his results ( after a long fight ) as long as it
was just about his experiment and results-- no theory. The guy agreed
but added his theory in "notes added to proof". ( Esentially a sort
of prepublication errata. ) This led the editor to apologise.
Moral: Don't trust everything you read. Even in peer reviewed
publications.