What obstacles do Common Lisp programmers face?
Software Scavenger
poor implementations of those languages. We spent vast portions of
our time fighting bugs and limitations in our programming languages
and development environments. It seemed like those obstacles were the
main reasons why we didn't get our work done almost as soon as it was
assigned to us. Even those who used Common Lisp in the past faced
obstacles of imperfect implementations and weak hardware. But now
those obstacles are gone, and we can all proceed full speed with
Common Lisp on modern hardware. Programming is theoretically easy.
Once you know what the program should do, and how it should do it, you
simply communicate that information to the computer, and the job is
done.
Thus it seems that we should now get our work done the same hour we
decide to do it. If not, why not? What obstacles do Common Lisp
programmers still face, which make the work continue to take longer
than that?
Espen Vestre
> Thus it seems that we should now get our work done the same hour we
> decide to do it. If not, why not? What obstacles do Common Lisp
> programmers still face, which make the work continue to take longer
> than that?
Four examples at the top of my head:
- non-technical: having to defend the choice of programming language
so often can be tiresome.
- GC: GCs are good, but if you work on really big heavy applications
you can encounter their limits in unpleasant ways.
- libraries: The availability of libraries and library
interfaces. I.e. I still don't know of any available interfaces to
standard DBM libraries (NDBM, GDBM, Berkeley DB). The transparent
interface to all these is one of the gems of Perl, I think.
- non-technical: once you start to do magic with CL, people expect
you to do even more magic, all the time ;-)
--
(espen)
Rudi Schlatte
> - libraries: The availability of libraries and library
> interfaces. I.e. I still don't know of any available interfaces to
> standard DBM libraries (NDBM, GDBM, Berkeley DB). The transparent
> interface to all these is one of the gems of Perl, I think.
Just a quick referral to
<URL:http://ww.telent.net/cliki/berkeley-db>
Regards,
Rudi
Thaddeus L Olczyk
<rsch...@ist.tu-graz.ac.at> wrote:
Only if you use CMUCL.
Christophe Rhodes
Is this not another language/implementation confusion? If you require
an interface to Berkeley DB in Common Lisp, you can have it if you use
the CMUCL implementation?
Perl has only been implemented once; it should be compared with an
implementation, not the intersection of all implementations, or
(worse) the Common Lisp standard.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Tim Bradshaw
>>
> Only if you use CMUCL.
True. None of the perl libraries work in Tim's own Perl either, they
only work in the Larry implementation.
--tim
Thaddeus L Olczyk
>* Thaddeus L Olczyk wrote:
>>>
>> Only if you use CMUCL.
>
>True. None of the perl libraries work in Tim's own Perl either,
Well. Maybe that's because *Tim* is a bed programmer.
>they
>only work in the Larry implementation.
>
Not. True. Where alternatives exist the perl libraries will work
with those alternatives such as ActiveState Perl. One of the
prime advantages of the language created by Larry "should be lined up
against a " Wall is that there is a very large library, no implementor
would want to mess with that.
A second point. Where implementation differ from Wall's implemantation
they are wrong, because Wall's implementation is the definition of the
langauge. CMUCL does not share that priveledge. No Lisp implementation
does.
In closing, it does not do to reply to someone complaining that Lisp
does not support X by report that the Y implemenation of Lisp supports
X. If CMUCL has BerkleyDB interfaces, SBCL has thread support, CLISP
has support for BSD type sockets and GCL has support for CGI ( as an
example ), it does me no good if I need all four in one application.
This is one place where lisp has to clean up it's act.
Christophe Rhodes
> In closing, it does not do to reply to someone complaining that Lisp
> does not support X by report that the Y implemenation of Lisp
> supports X.
This seems a little bit bizarre, really. I can see where you're
coming from, but to berate people for responding directly and
precisely to your complaint appears to be thoughtless.
> If CMUCL has BerkleyDB interfaces, SBCL has thread support, CLISP
> has support for BSD type sockets and GCL has support for CGI ( as an
> example ), it does me no good if I need all four in one application.
> This is one place where lisp has to clean up it's act.
This is, of course, a completely different complaint; if you'd said
"No 'free' implementation of Common Lisp on Unix supports all four of
threads, BerkeleyDB interfaces, BSD sockets and a CGI library" (again,
hypothetically) then we the readers would have been forced to agree.
And it is probably true that Common Lisp implementations don't have as
wide a library as, say, Perl (though the quality of some of the things
in CPAN is slightly suspect). However, if one implementation did have
all four extensions, would you still be complaining? What if a
'non-free' implementation supports all of these (as I suspect ACL
and/or LispWorks might well do) -- does that satisfy your requirement?
Kenny Tilton
Software Scavenger wrote:
> Programming is theoretically easy.
But actually hard.
> Once you know what the program should do, and how it should do it,
Ahem. I believe "how it should do it" is the sticky wicket.
> you
> simply communicate that information to the computer, and the job is
> done.
Where can I buy such a wonderful computer? Mine can only perform logic
operations on bits and branch execution.
:)
kenny
clinisys
Frode Vatvedt Fjeld
> In closing, it does not do to reply to someone complaining that Lisp
> does not support X by report that the Y implemenation of Lisp
> supports X.
Of course it does, in particular when that response also states whether
X is included in the scope of ANSI CL.
> If CMUCL has BerkleyDB interfaces, SBCL has thread support, CLISP
> has support for BSD type sockets and GCL has support for CGI ( as an
> example ), it does me no good if I need all four in one application.
You are looking at this the wrong way. If you ask the question "does
(any) lisp have these four features", _then_ you should expect a
yes/no/which answer, and any "implementation Z has one of those
features"-response whould be insufficient.
> This is one place where lisp has to clean up it's act.
Only in the sense that it would (always) be nice to have more
feature-rich implementations, more complete libraries, at lower
costs. But who will provide?
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld
> Programming is theoretically easy. Once you know what the program
> should do, and how it should do it, you simply communicate that
> information to the computer, and the job is done.
_Anything_ is theoretically easy according to some equally meaningless
theory.
> Thus it seems that we should now get our work done the same hour we
> decide to do it. If not, why not?
Because that work might happen to be some intrinsically difficult
problem that no-one has solved before. I like to think that most of my
work fall into this category.
--
Frode Vatvedt Fjeld
Eric Moss
>
> What obstacles do Common Lisp programmers still face, which make the work
> continue to take longer than that?
In my case:
[1] paucity of [perl|python]-ish lisp calls.
Much of my work is translating existing non-lisp code to lisp--just to
get existing functionality into the lisp world. Often the codebase is
too big to write from scratch in a lispy way, so I start with naive
translations just a reference system going which I can then hone.
Python-like APIs of say, regex calls would help immensely. I know lisp
has more powerful constructs than does Python, but it would be nice to
just turn:
matches = re.findall(<some-pattern>, <somestring>)
for match in matches:
...
into:
(dolist (match (re:findall <some-pattern> <some-string>))
...
I am writing get-by versions of these kinds of things as I go, but a
canned set would help a lot.
[2] No free CLIM.
I want to use CLIM on an involved GUI that was originally Openstep, but
don't have $900 for LW or MCL. That's not a moral accusation against
commercial software, just a sad fact about my finances.
[3] lack of standardized extended APIs. (related to point #1)
I know... they're "extended" because the standard is for universal
concepts. But every OS for which someone would pay me to write lisp has
a tree file structure, and concepts of file permissions and onwership
and create/write date.
I also know that vendors want to differentiate themselves based on their
extended libraries, so standardizing would be a messy fight. I would be
happy with a library that hid all the #+ use behind a uniform interface.
[4] others' prejudice
My friends constantly tease me about lisp, without ever even trying it.
Clients are willing to use lisp IF I can show them a finished product,
but they aren't willing to finance exploration, even when outside help
is offered. All of the above problems would fix themselves quickly if
lisp development were treated like any other development cost, rather
than as an not-real-world approach.
[5] my own inexperience.
well... I'm working on it. :)
Eric
Tim Bradshaw
> Not. True. Where alternatives exist the perl libraries will work
> with those alternatives such as ActiveState Perl.
Sigh. We've been through this before, haven't we? I can only assume
that this failure to understand a class/instance distinction is caused
by the low standard of education in CS or something - you'd have
thought that after 30 years of `OO' people would understand it by now.
Firstly, activestate perl is a *port* from the same code base, it's
not a new implementation.
Secondly, new implementatons of perl (if there were to be any, and why
would there) would almost certainly be constrained to follow slavishly
whatever the Wall perl did, bugs and all. They'd probably be
compatible, but I wouldn't want to lay money on it - imagine how
vulnerable to gratuitous changes they'd be, and the extreme
competitive advantage of the single defining implementation (think
about Windows for a moment). Even with the current
single-implementation *users* are incredibly vulnerable to the kinds
of random incompatible changes that have *frequently* happened with
perl and other such systems.
This is a completely different animal than a language which is defined
by a standard - formal or not. Given a standard you can have
competition. But standards are *very* expensive. If you think they
aren't try and work out how much money has been spent on posix, or C++
standardisation. A 9-11 digit (base 10) dollar sum I should think.
> In closing, it does not do to reply to someone complaining that Lisp
> does not support X by report that the Y implemenation of Lisp supports
> X. If CMUCL has BerkleyDB interfaces, SBCL has thread support, CLISP
> has support for BSD type sockets and GCL has support for CGI ( as an
> example ), it does me no good if I need all four in one application.
> This is one place where lisp has to clean up it's act.
Quite, but before you whine, try and think. It is *really* expensive
to develop standardised interfaces without simply specifying an
implementation. That might be what is holding us back. Give me a
billion dollars and I'll produce a standard for all of these things
for CL, without it it isn't so easy.
If you don't want to spend that kind of money then an alternative is
to pick an implementation and contribute to it to make sure it has
what you need. In either case, don't just sit there and whine for
Christ's sake. I know it's easy and it makes you feel better, but it
just makes people want to staple your head to the floor.
--tim
Christopher Stacy
Tim> If you don't want to spend that kind of money then an
Tim> alternative is to pick an implementation and contribute to it to
Tim> make sure it has what you need.
I didn't see an original point that explained why a given set of
compatible implemenations and libraries was insufficient to address
the requirements.
If you need a specific feature that is not available in your chosen
implementation, just pay the vendor to put it in.
If the problem is that everything is not free, too bad, I guess.
Thomas F. Burdick
> On 11 Jan 2002 15:33:20 +0000, Tim Bradshaw <t...@cley.com> wrote:
>
> >True. None of the perl libraries work in Tim's own Perl either,
>
> Well. Maybe that's because *Tim* is a bed programmer.
(sigh) I want a laptop so I can be a bed programmer, too.
> >they
> >only work in the Larry implementation.
> >
> Not. True. Where alternatives exist the perl libraries will work
> with those alternatives such as ActiveState Perl. One of the
> prime advantages of the language created by Larry "should be lined up
> against a " Wall is that there is a very large library, no implementor
> would want to mess with that.
>
> A second point. Where implementation differ from Wall's implemantation
> they are wrong, because Wall's implementation is the definition of the
> langauge.
Even Perl isn't as confused as you are here. The behavior of the Perl
language implemented by Wall et al., mod bugs, is the definition of
the Perl language. If someone were crazy enough to reimplement Perl,
they could mimic the cannonical implementation's behavior, and still
be incompatible with the most useful libraries, which depend on
details of the internals of the implementation.
> In closing, it does not do to reply to someone complaining that Lisp
> does not support X by report that the Y implemenation of Lisp supports
> X. If CMUCL has BerkleyDB interfaces, SBCL has thread support, CLISP
> has support for BSD type sockets and GCL has support for CGI ( as an
> example ), it does me no good if I need all four in one application.
> This is one place where lisp has to clean up it's act.
You just took a hypothetical example where you got the details wrong
(forgivable if you'd stayed hypothetical), and drew conclusions from
it. CMUCL has support for all those things. And more importantly,
the commercial Lisps do, too. If you want a whole ton of features
outside of the scope of the standard, together in one implementation,
you probably want one of the commercial ones. If, on the other hand,
you're just talking about glue to a C library, which is what's usually
done in most languages, complete with the limitations of following the
C semantics, why a little bit of work writing alien definitions (in
cmucl) goes a *long* way. Most Lispers expect extensions to fit well
into the language, but if you lower your integration standards down to
the Perl level, you can have most everything Perlers get, with less
work for each piece.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick
Bah, you just need to speak through a translator. See, I've got this
great translator: I write down how I want the computer to do things,
file it away in "files", which my translator then "compiles" into new
"files". When I "load" these into the translator "application", it
tells the computer what I told it, only in terms the computer can
understand. It's usually at this point that I realize I knew what I
wanted done, but I had explained in detail how to do something similar
but not quite what I wanted.
Martin Cracauer
>Thus it seems that we should now get our work done the same hour we
>decide to do it. If not, why not? What obstacles do Common Lisp
>programmers still face, which make the work continue to take longer
>than that?
Insufficient, inefficient, unportable, and/or plain stupid interfaces
to C, raw data and raw files.
The unix interface for files, networking and time has won thoroughly
enough that it should be part of every Lisp implementation. Which of
course require transpartend access to C data.
Bad thread support.
Constant stepbacks in development environment. For all the excellent
work the ilisp people do, is an external dynamic-scope non-common-lisp
editor in a nonthreaded environment with no graphical support
whatsoever and few if any capturing of alife objects all we can show
after decades of Symbolics, Lispworks, the Smalltalk environment?
Debuggers. While still better in some respects than C debuggers,
lacking in others, especially coupling to source location and editor
support to move around source locations, at least in Franz and CMUCL.
The strenth comes from the integration with REPL, but the debuggers
and the mechanism of communication via the fasl files is a joke.
GC.
Random compiler messages without close enough hints about source
location, not to speak of Control-c `, non-supressablity of warning
you chose to ignore, few if any support to break on some kinds of
warnings.
Lisp syntax sometimes gets on my nerves, especially when it comes to
declarations. See Paul Graham's ARC proposal. Sacrifice some chars
for syntactic shugar, with a straight translation to S-expression
syntax. Loop isn't a pretty shot either.
CLOS. I want sealed classes with possible inlining like in Dylan.
I want arrays of (self-defined) structs with immedeate values on the
stack, all represented without a single pointer indirection. And I
don't want obligatory initializing, much less to anything else than
binary zero (which isn't quite possible given a practical CL
implementation). So don't initialize unless asked for and given that,
the compiler can finally warn about reading them before writing (like
gcc does or most other compilers for that matter). While at it,
integrate with low-overhead, sealable OO system.
The real shame is that a language with these flaws is still by far the
best one I used. So what I really want is a society where...
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Erik Naggum
| In the past most of us used other programming languages, and usually poor
| implementations of those languages. We spent vast portions of our time
| fighting bugs and limitations in our programming languages and
| development environments. It seemed like those obstacles were the main
| reasons why we didn't get our work done almost as soon as it was assigned
| to us. Even those who used Common Lisp in the past faced obstacles of
| imperfect implementations and weak hardware. But now those obstacles are
| gone, and we can all proceed full speed with Common Lisp on modern
| hardware.
Really? Which is the fully conforming, bug-free implementation of ANSI
X3.226-1994 Common Lisp? I keep finding annoying discrepncies all the
time, leading me to believe it is safe to depend only on a small subset
of Common Lisp unless you install a direct line to your vendor's support
department _and_ you get their attention when you say "conformance", the
one word which leads some of them to ignore your bug report completely if
they can think up a work-around or another way to accomplish your goal,
but that is precisely what I do _not_ want, as it means different ways of
doing the same thing in different implementations when we have a single
specification that the vendors purport to implement.
If car manufacturers made cars according to spec the same way software
vendors make software according to spec, all five wheels would be of
widely differing sizes, it would take one person to steer and another to
work the pedals and yet another to operate the user-friendly menu-driven
dashboard, and if it would not drive straight ahead without a lot of
effort, civil engineers would respond by building spiraling roads around
each city.
I know I am in the small minority that reads documentation and standards
and the like, but the operational definition of "conformance" can be
stated very simply: If you read about something in the standard or in an
accurate textbook and you can trust that it is always your own fault if
it does not work as expected, the system is fully conforming. But this
is predicated on people reading the standard or that someone has written
similarly accurate textbooks and that readers of either pay attention to
the details, are willing to _listen_ and _understand_
| Thus it seems that we should now get our work done the same hour we
| decide to do it. If not, why not? What obstacles do Common Lisp
| programmers still face, which make the work continue to take longer than
| that?
The fact that writing robust Common Lisp code in the Common Lisp spirit
still takes considerable effort. Let me give an example. Suppose you
develop a socket interface and think it is of sufficiently high quality
that you want to share it. You could develop a class, service, that
contained a host (with name, address family, address) and a port and a
protocol (tcp or udp at this point), decide on a syntax and write
functions to read and write objects of this class, and then include some
easy-to-use designators like strings in this syntax, but internally, you
always use your class. You would therefore develop a solid framework to
refer to network services instead of, say, just using integers for IP
addresses and ports, and these more complex things would be the end
points of your socket interface, rather than more or less magic integers.
This would offer something substantial above the "everything is really a
machine integer" view that C and Unix has foisted upon the world and
would afford an abstraction that allows people to refer to these services
uniformly regardless of changes in the underlying implementation, such as
we face when transitioning from IPv4 to IPv6, which some socket code has
made more than painful. This would require some thought and more code,
but it would produce a fully reusable piece of code, with a specification
that would be worthy of standardization.
But suppose instead you are the kind of engineer who really do not really
believe in the value of Common Lisp, but just like its syntax while you
still think in basic C terms and prefer meaningless integers instead of
typed objects. Then you would force the user to engage in a tremendous
amount of silly work, just like you would in C, but maybe half as much
just to be nice, to refer to and use, not to mention set up, a network
service. It would appear "nice" to those used to the bare-bones C stuff,
but it would still suck relative to other Common Lisp functionality.
This would take _much_ less time to write than Common Lisp standard-like
functionality, and it may be "documented" enough to be useful for others,
but it is not the kind of code you write specifications for.
That is, you would be inclined to _re-implement_ something that was not
written to specification quality rather than read the specification and
use it as specified. Lots of code is written like this in languages that
have fairly bad specifications in themselves, communities that do not
care much about their specifications in the first place, and whose code
sharing traditions usually are at the "it works for me" level, but Common
Lisp has a specification that sets a standard for what new contributions
should look like, as well. Good library design in C++ is said to be 25
times more expensive and complex than a simple user-level implementation
that should be thrown away and re-implemented the next time it is needed.
I would estimate that good library design in Common Lisp is about 10
times more expensive and complex than throw-away implementations, but
that it is possible to make throw-away implementations "reusable" in
Common Lisp with considerable effort, while it is not possible not in
C++, so those who have not _designed_ for standard-library quality will
think that additional libraries for Common Lisp need not be different
from user code with documentation. This, again, unfortunately means that
the ability to use other people's code in Common Lisp is much lower than
that in other languages -- ironically because the effort to create good
code is so much lower than in other languages that the extra effort to
design top-notch quality does not seem worth it to many.
///
--
Jean-François Brouillet
<er...@naggum.net> wrote:
[an interesting, if somewhat lengthy, piece about how designing good,
reusable code takes time, care and dedication, no matter what the
language you are using].
Too bad that the writings of Mr Naggum are so rarely in this category.
Not Earth shattering, for sure, but informative enough to warrant the
status of signal.
If everything else he writes were like this, I wouldn't mutter (even
to say that the constant bashing of "other languages" is an already
lost, useless game).
[And Oh, yes, while I'm there: your sentences are too long. They require
the reader to memorize to much context before the end is reached.
When the cognitive load becomes too great, many readers will just
skip the sentence, then paragraph, then message, then thread, etc...
And it is not worth writing if is to not be read.]
--
Jean-François Brouillet
Tim Bradshaw
> I didn't see an original point that explained why a given set of
> compatible implemenations and libraries was insufficient to address
> the requirements.
Such a set is sufficient. Such a set *is* an informal standard, or
could become one. What I'm trying to explain is that a system
*defined* by a *single* implementation - like perl - is a very
different animal than a system defined by a standard. A standard is a
class, an implementation is an instance.
--tim
Tim Bradshaw
> Constant stepbacks in development environment. For all the excellent
> work the ilisp people do, is an external dynamic-scope non-common-lisp
> editor in a nonthreaded environment with no graphical support
> whatsoever and few if any capturing of alife objects all we can show
> after decades of Symbolics, Lispworks, the Smalltalk environment?
> Debuggers. While still better in some respects than C debuggers,
> lacking in others, especially coupling to source location and editor
> support to move around source locations, at least in Franz and CMUCL.
> The strenth comes from the integration with REPL, but the debuggers
> and the mechanism of communication via the fasl files is a joke.
I think this is another case where one should be careful about
class/instance confusion, and also consider things like relative
resource levels.
If you want to compare `Common Lisp' environments with something then
you should probably compare them with `C' environments, as a class.
An awful lot of C/C++ environments look like emacs, gcc and gdb, and
that's not such a bad setup compared with, say, Emacs and CMUCL.
People develop real code in these systems (both of them). Neither are
really great environments. God knows, some C environments are still
ed and a terminal, with adb, really.
There are two possibly-more-interesting comparisons.
1. Best-of-breed free C/C++ vs best-of-breed free CL. I don't know
what this would pick from either class. I've recently been
involved in trying to find a decent, free, GUI debugger for C++ on
Linux, and there don't seem to be any - there are some that look
nice but they all have an awful habit of falling on their faces too
often to be usable. However if you really poke around, C/C++ may
be winning here. If you want a cross-platform environment though
you're likely to end up with emacs/gcc/gdb and emacs/ilisp/some-cl,
so maybe CL is not doing so badly.
2. Best-of-breed commercial. Again, I don't know what the answer is
here. I like the Lispworks environment a lot, it feels as
productive to me as anything as I've used and with 4.2 the debugger
is really good enough for the way I use debuggers. And most of it
works on windows, linux and several unices just the same. I'm not
sure about Franz's - I think the fancy one only runs on Windows,
but emacs/eli is OK, and portable. MCL probably beats both, or
someone will claim so. Perhaps for C/C++ visual studio should win,
but it's seriously windows-only. I think if you pick a single
platform - windows - then C/C++ is winning, cross-platform
LispWorks might be in there.
So maybe C++ environments are winning, at least if you don't worry
about cross-platform issues. But now stop and think. How much money
have Microsoft thrown at visual studio, or Sun at their environment?
I have no idea, but my guess is several orders of magnitude more than
all the lisp vendors put together, and worse, they don't even need to
make a profit on the systems, since they're all support for other,
profitable, activities. Is it actually surprising that their
environments are better? I think it's actually, on the contrary,
amazing that the lisp environments can even be considered in the same
breath.
--tim
Greg Menke
> 2. Best-of-breed commercial. Again, I don't know what the answer is
> here. I like the Lispworks environment a lot, it feels as
> productive to me as anything as I've used and with 4.2 the debugger
> is really good enough for the way I use debuggers. And most of it
> works on windows, linux and several unices just the same. I'm not
> sure about Franz's - I think the fancy one only runs on Windows,
> but emacs/eli is OK, and portable. MCL probably beats both, or
> someone will claim so. Perhaps for C/C++ visual studio should win,
> but it's seriously windows-only. I think if you pick a single
> platform - windows - then C/C++ is winning, cross-platform
> LispWorks might be in there.
Visual Studio is ok, but Borland's Cbuilder/Delphi thing is pretty
good, but more importantly, the class heirarchy and "plugin" model is
a good bit cleaner and it has a much better form layout/manipulation
interface. Having written a few small and a few large projects in
Visual Studio, I found it just OK. Not especially reliable, its able
to confuse itself to the point where you have to kill it from the OS
and its not particularly configurable either. Newer V.S versions have
improved to the point that when they crash, they don't take out the OS
also.
I think the class heirarchy that a development platform offers is most
important, if so, Borland's environment is much nicer than Visual
Studio's. MFC is about as half-assed and inconsistent as one might
expect. CBuilder/Delphi have a well organized class system. On the
other hand, CBuilder having Pascal lurking just below the surface
sometimes leads to a rather strange experience using the product.
Though I've not seen it yet, Borland's environment is asserted to be
useful on Linux in addition to Windows.
Gregm
Janosch Zwerensky
>Thus it seems that we should now get our work done the same hour we
>decide to do it. If not, why not?
I think the short answer is that programming isn't going to be easy in any
language. Even if we had reasonably efficient compilers for (mathematical)
*natural* language, writing complex programs would be exactly as hard as
teaching a human to perform a complex task...
Janosch Zwerensky
>I think the short answer is that programming isn't going to be easy in any
>language. Even if we had reasonably efficient compilers for (mathematical)
>*natural* language, writing complex programs would be exactly as hard as
>teaching a human to perform a complex task...
I just thought about it again and have to admit it isn't true, strictly
speaking. After all, unlike a human, the NL compiler might be willing to
follow instructions given to it even if it doesn't see what purpose this will
serve, and it might well not be affected by problems that are a consequence of
the fact that the human brain is terribly bad at doing big, error-free,
sequential computations. Still, the general point that even with
something as expressive and intuitive-to-use as mathematical natural language
one could possibly have problems expressing complex things without danger of
being misunderstood in any way is, I believe, valid.
William Newman
> cubic...@mailandnews.com (Software Scavenger) writes:
>
> >Thus it seems that we should now get our work done the same hour we
> >decide to do it. If not, why not? What obstacles do Common Lisp
> >programmers still face, which make the work continue to take longer
> >than that?
I agree with a lot of Martin's priorities here. (I'm replying to him,
instead of the original poster, to get in that remark.)
I'll also add some remarks of my own.
Sometimes Common Lisp's design choices just don't fit. For lots of
problems they're great, or good enough. But they can't be
ideal for everything. CL is dynamic. That fights with
powerful program-analyzing programs, or even
wimpy ones like "make" and "make depend". CL encourages lots of
program-writing programs written as part of the application. That
fights with debuggers and other introspection: not fundamentally,
maybe, but as a practical matter it can make human inspection of
a running Lispy program more confusing than a program which
wasn't generated by Turing-complete macrology. CL has a lot
of indirection, GC, and typing built into its specification.
That fights with efficiency, both a fundamental unavoidable cost (e.g.
extra machine-level indirection on every function call or nested object
reference, extra overhead setting type bits) and a larger cost
in practice (like for efficient portable reasonable Lispy floating point
code, not AFAIK a solved problem).
I think the free implementations of CL aren't
all that impressive. Not pathetic, but not in the
same class as the best-of-breed free software.
Linux, and more especially emacs, perl, tcl/Tk, and (but see
below for more remarks on this) gcc are programs
with no shortage of architectural warts or deep problems, but they
succeed in large part because (judging both from their reputation
and from my experience) their implementations are really,
really good.
As a free CL maintainer, I feel a little defensive about the
quality of free CL implementations. So I'll point
out that CL is a big, hard-to-implement language.
I think to some extent the implementation problems reflect this.
As alluded to above, consider gcc. The C implementation
(modulo various pain in the library, anyway) is very very good.
The C++ implementation, well. Templates and stuff. You be the
judge. I didn't consider it ready for prime time last time I looked. So,
with this in mind, I don't think the Lisp implementors are
necessarily worse programmers
than the implementors of other systems (though some of us probably
are:-). When you hand the gcc project a big hard language,
it does some stumbling around too. Big systems are hard.
Also, CL has its own design flaws. For example, reloading
code is sort of, but not quite idempotent.
If your DEFGENERIC is in a.lisp, and some DEFMETHODs
are in b.lisp, then if you load a.lisp, then b.lisp, then a.lisp again,
you end up with your generic function's behavior in a weird sliced state.
Given that dynamically reloading code into the system is so important
(that you make CL implementors put up with major pain to support it!)
it would be nice if the standard also provided some guarantees
about reasonable useful baseline behavior if you do something like
(progn (load "a.lisp") (load "b.lisp") (load "a.lisp")). Of
course, if you write your own macros you could mess this up. But
it'd be nice if the system's own macros were written in such a way
that if you only used them, then this reloading would automatically give
you a coherent result. Instead, in CL the predefined system macros are
pre-messed-up for you, alas.
> The real shame is that a language with these flaws is still by far the
> best one I used. So what I really want is a society where...
Both in Chess and in Go I know of top players, perhaps running out
of people to measure themselves against, speculating about how close
to perfect they are. ("I could win against God, every time, with a
bishop handicap," that kind of thing.) I wonder how far Common Lisp is
from some ideal language. (Presumably you'd have to limit it to the space
of various design choices: parentheses, dynamic typing, supporting
incrementally growing and modifying your program in place instead of
killing the process and starting over, compilable without
solving the halting problem or even any NP problems, etc.)
CL is a very good language. I agree with Martin
that it's the best I've run into so far.
Ocaml or SML would be strong runners up if they weren't so hostile
to, or at least horribly unsupportive of, important kinds of
mutual recursion (especially in complex nested
data structures), which seems like
a bizarre design flaw to me (but probably follows somehow from the
'compilable without solving the XXX problem' issue above, mixed with
static typing: I'm under no illusions that the ML people are missing
an obvious solution). Most other close-to-general-purpose
languages seem to have priorities
that don't make sense in most problems today (especially microefficiency over
programmer efficiency). Many of the interesting exceptions seem to be:
* systems languages. C and C++ (well, OK, reasonable people can
disagree about ANSI C++, but I think most people can see at least
see a pretty good language struggling to get out in C++), where
microefficiency and other lowlevelness matter. But they shouldn't
be used nearly so widely as they are, as has been hashed out
many times here and elsewhere.
* scripting languages. It's been noted before how they tend to drift
toward Lisp as people apply them to more serious, sizeable problems.
* B&D languages for really big projects. My experience with the
moderate-sized CMUCL/SBCL codebase (on the order of 100KLOC) is
that Common Lisp works fine. But I can see people wanting static
typing, obviously-correct incremental rebuilding, global guarantees
of safety and incorruptibility (not just C-level stray pointers,
but guarantees that you can't do things like
(SETF (AREF (SYMBOL-NAME 'PRINT) 4) #\X) to
leave the system mysteriously brain-damaged) and other
things. At some size, you probably need them.
Will Deakin
> Perhaps for C/C++ visual studio should win,
> but it's seriously windows-only. I think if you pick a single
> platform - windows - then C/C++ is winning,
sized projects using c and c++ with Visual C/C++ and/or xemacs and Forte
C/gcc/Sunworks with adb/gdb and the motif sun debugger I would prefer to hammer
red hot needles through my eye lids rather than to go back to Visual C/C++.
Maybe things have really changed since version 5 and 6. And maybe part of the
problem is that I have fallen out of love with c++ and grew to hate MS windows
programming -- but having played with the Lispworks GUI and with more experience
of the xemacs stuff I *still* think in a lot of ways lisp environments win.
[...elided stuff about Sun and Microsoft development environments...]
>Is it actually surprising that their environments are better? I think it's
>actually, on the contrary, amazing that the lisp environments can even
>be considered in the same breath.
Sure. I would go further: given how much money is spent -- and how restrictive
the licensing and how *much* these environments cost[1] I am suprise at how
bloody awful these IDE's are and how remarkably good (particular in my
experience of commerical) lisp IDE's.
Then again what do I know? I don't do this stuff for money any more.
:)w
[1] In particular microsoft.
Pierre R. Mai
> Also, CL has its own design flaws. For example, reloading
> code is sort of, but not quite idempotent.
> If your DEFGENERIC is in a.lisp, and some DEFMETHODs
> are in b.lisp, then if you load a.lisp, then b.lisp, then a.lisp again,
> you end up with your generic function's behavior in a weird sliced state.
Could you give some more details of what you are thinking of here?
I can't seem to come up with a scenario that would leave the GFs
behaviour in a "weird sliced state", but I might just be missing
something here...
> * B&D languages for really big projects. My experience with the
> moderate-sized CMUCL/SBCL codebase (on the order of 100KLOC) is
FWIW, a couple of months ago I happened to need some silly KLOC counts
on the CMU CL codebase, and the "exact" figures that came up where:
Core Stuff:
- C runtime code (lisp directory): ~ 15 KLoC
- Assembler runtime code (assembly directory) ~ 5 KLoC
- Lisp runtime code (code directory): ~ 70 KLoC
- PCL CLOS code (pcl directory): ~ 20 KLoC
- Python Compiler code (compiler directory): ~ 110 KLoC
(includes native code generators)
Total: ~ 220 KLoC
Extension stuff:
- CLX (clx directory): ~ 20 KLoC
- CMUCL/Motif (motif + interface directories): ~ 5 KLoC
- Hemlock (hemlock directory): ~ 36 KLoC
- tools, tests and contrib directories: ~ 10 KLoC
Total: ~ 71 KLoC
Empty and comment-only lines are not included in those counts, but all
platforms (including legacy platforms like IBM RT-PC) are included.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Christopher Stacy
Tim> * Christopher Stacy wrote:
>> I didn't see an original point that explained why a given set of
>> compatible implemenations and libraries was insufficient to address
>> the requirements.
Tim> Such a set is sufficient. Such a set *is* an informal standard, or
Tim> could become one. What I'm trying to explain is that a system
Tim> *defined* by a *single* implementation - like perl - is a very
Tim> different animal than a system defined by a standard. A standard is a
Tim> class, an implementation is an instance.
Yes of course I understand that, but I don't see how it's relevent,
because I don't understand why the original poster was dissatisfied.
Erik Naggum
| Too bad that the writings of Mr Naggum are so rarely in this category.
| Not Earth shattering, for sure, but informative enough to warrant the
| status of signal.
Jean-François Brouillet, go fuck yourself with a telephone pole wrapped
in barbed wire, will you?
///
--
William Newman
> william...@airmail.net (William Newman) writes:
>
> > Also, CL has its own design flaws. For example, reloading
> > code is sort of, but not quite idempotent.
> > If your DEFGENERIC is in a.lisp, and some DEFMETHODs
> > are in b.lisp, then if you load a.lisp, then b.lisp, then a.lisp again,
> > you end up with your generic function's behavior in a weird sliced state.
>
> Could you give some more details of what you are thinking of here?
> I can't seem to come up with a scenario that would leave the GFs
> behaviour in a "weird sliced state", but I might just be missing
> something here...
I'm sorry, I seem to've been confused. The spec says that when DEFGENERIC
executes "first, methods defined by previous defgeneric forms are removed".
I misunderstood that at least a year ago, thinking it meant "methods
defined by previous CLOS forms [either DEFGENERIC or DEFMETHOD] are
removed". IIRC I also interpreted it
as the explanation for some bug I had when trying to incrementally
modify a system which had a lot of DEFGENERICs and DEFMETHODs, and
gritted my teeth and made a point to stop doing that. Oops. The ANSI
specifiers wrought better than I thought, and I can go back to
incrementally reloading code containing CLOS definitions. (Cool!
Except it's a little unsettling that defined-by-DEFMETHOD methods
have different properties than defined-by-DEFGENERIC methods.
But basically cool, overall, I think.)
I do have some other gripes, though. E.g. I don't think
global variables are a very good way to control reader and printer
properties. Using per-stream values, or some other more-local values,
would get rid of a lot of not-quite-right stuff that SBCL and CMU CL
have in common (and may share with many other CL implementations
that I know less about): *DEBUG-PRINT-LENGTH*, *TRACE-PRINT-LEVEL*,
never quite getting it right whether to use ~A or ~D or what when
printing numbers in CONDITIONs which you expect to be printed
interactively at the debugger REPL, and probably some other
annoyances that don't immediately spring to mind. Global variables
just don't work all that well for some (many...) things.
> > * B&D languages for really big projects. My experience with the
> > moderate-sized CMUCL/SBCL codebase (on the order of 100KLOC) is
>
> FWIW, a couple of months ago I happened to need some silly KLOC counts
> on the CMU CL codebase, and the "exact" figures that came up where:
>
> Core Stuff:
>
> - C runtime code (lisp directory): ~ 15 KLoC
> - Assembler runtime code (assembly directory) ~ 5 KLoC
> - Lisp runtime code (code directory): ~ 70 KLoC
> - PCL CLOS code (pcl directory): ~ 20 KLoC
> - Python Compiler code (compiler directory): ~ 110 KLoC
> (includes native code generators)
>
> Total: ~ 220 KLoC
>
> Extension stuff:
>
> - CLX (clx directory): ~ 20 KLoC
> - CMUCL/Motif (motif + interface directories): ~ 5 KLoC
> - Hemlock (hemlock directory): ~ 36 KLoC
> - tools, tests and contrib directories: ~ 10 KLoC
>
> Total: ~ 71 KLoC
SBCL really is closer to 100KLoC.
Since it doesn't support as many CPUs or extensions as CMU CL
does, there was a lot of now-dead code in the
inherited-from-CMU-CL codebase. Beyond that, the SBCL codebase
has been relatively aggressively pruned of dead or
at least killable code (like the way Nathan Froyd blew
away the old pre-CL:LOOP ITERATE macrology
in src/pcl/ last month). So even where there's
no loss of functionality relative to CMU CL (as in PCL, AFAIK,
though I might be confused about what CMU CL considers to be
supported functionality) things have shrunk noticeably:
16420 lines of code in SBCL's current src/pcl/
20063 in cmucl-18c (i.e. reasonably current CMU CL)
27602 in cmucl-2.4.8 (i.e. around the time of the original SBCL fork)
In fact, maybe one good statistic deserves another.:-) Using the
script llinec-all
f .lisp | xargs llinec-some
implemented in terms of llinec
# lisp line count (ignores ';' comments and blank lines but is tricked
# by #||# comments)
grep '^[ ]*[^ ;]' $* | wc --lines
and llinec-some
for f in $*; do
echo -n `llinec $f`;
echo " $f";
done
echo -n `llinec $*`;
echo " (total)"
and f
#!/usr/bin/perl -w
# a specialized version of find, searching for partial matches
# starting in current directory
my @SEARCH;
if (@ARGV) {
# ordinary case: Search for partial matches to all command line args.
@SEARCH = @ARGV;
} else {
# When no command line args supplied, search for everything.
@SEARCH = ("");
}
# We prefer -iname, but classic find only has -name.
my ($looks_like_gnu_find) = ($ENV{"OSTYPE"} =~ /linux/);
my ($inameoid) = $looks_like_gnu_find ? "-iname" : "-name";
foreach (@SEARCH) {
system
"find", ".", "(", $inameoid, "*$_*", "-or", $inameoid, ".*$_*", ")", "
-print";
}
I get 130464 lines total in a clean version of my current working copy of
the SBCL directory tree.
Of course, there are various peculiarities lurking in there
besides the #||# issue in the script comments: files called .lisp-expr
which are Lispy data meant to be read by READ but not executed,
more than 3K lines of Lisp in post-build test scripts, etc.
Also, there's comfortably more than 10K lines, maybe 20K lines,
of CPU-architecture-specific stuff for each
CPU architecture. So if you just sliced out
basic SBCL for a single CPU architecture, it's probably about 100K
lines of Lisp code. But then the code in other languages (mostly C for
runtime support and system header grovelling, and shell scripts and
Makefiles to control the build) would bulk it up a little bit again.
Henry Lebowzki
"Christophe Rhodes" <cs...@cam.ac.uk> escreveu na mensagem
news:sq8zb42...@cam.ac.uk...
> olc...@interaccess.com (Thaddeus L Olczyk) writes:
>
> > In closing, it does not do to reply to someone complaining that Lisp
> > does not support X by report that the Y implemenation of Lisp
> > supports X.
>
> This seems a little bit bizarre, really. I can see where you're
> coming from, but to berate people for responding directly and
> precisely to your complaint appears to be thoughtless.
>
> > If CMUCL has BerkleyDB interfaces, SBCL has thread support, CLISP
> > has support for BSD type sockets and GCL has support for CGI ( as an
> > example ), it does me no good if I need all four in one application.
> > This is one place where lisp has to clean up it's act.
>
> This is, of course, a completely different complaint; if you'd said
> "No 'free' implementation of Common Lisp on Unix supports all four of
> threads, BerkeleyDB interfaces, BSD sockets and a CGI library" (again,
> hypothetically) then we the readers would have been forced to agree.
> And it is probably true that Common Lisp implementations don't have as
> wide a library as, say, Perl (though the quality of some of the things
> in CPAN is slightly suspect). However, if one implementation did have
> all four extensions, would you still be complaining? What if a
> 'non-free' implementation supports all of these (as I suspect ACL
> and/or LispWorks might well do) -- does that satisfy your requirement?
>
> Christophe
Funny thing I noticed with Common Lisp is that the free implementations lag
behind proprietary software (LispWorks, etc.) at least interface-wise.
I think this is a sad fact. One of the nicest things about Perl is tha Larry
Wall
really wanted to keep it free software and, as he writes in the book Voices
from
The Open Source Revolution, what he did can actually be compared with the
"center of an onion". Layer after layer has developed around Perl the
language, that
were developed by a very active community.
Is the gap between paid Lisp and free Lisp due to the fact that Lispers
always
work on companies with big budgets, so they don't feel the __need__ to
better
the user interface in the free stuff?
Regs
HL
Henry Lebowzki
"Christopher Stacy" <cst...@spacy.Boston.MA.US> escreveu na mensagem
news:ulmf4y...@spacy.Boston.MA.US...
Too bad for the Lisp community, I guess.
If the Perl Mongers or other active groups were to think like you do,
Perl wouldn't be "the glue of the internet."
And there wouldn't be Emacs, GNU/Linux, etc, etc.
Regs
HL
Christopher Stacy
>> If the problem is that everything is not free, too bad, I guess.
Henry> Too bad for the Lisp community, I guess. If the Perl Mongers
Henry> or other active groups were to think like you do, Henry> Perl
Henry> wouldn't be "the glue of the internet." And there wouldn't be
Henry> Emacs, GNU/Linux, etc, etc.
I would disagree that "Perl is the glue of the Internet", and I
would also disagree with the idea that Emacs was written "for free".
Could you back up those base claims, and then explain what it is that
you believe I think, and what that has to do with your dissatisfaction
at being asked to pay for high-quality software?
More the point: if the problem is that high-quality software is not
available for free, why don't you stop whatever it is you're currently
doing and please provide yourself and the rest of us with the free
compilers and development environments that ought to exist?
Actually, I think you're just trolling around to see if you can
cause people to waste their precious time arguing about "free"
software. It isn't even the "free" in the sense defined by the
GNU people, by the way ("free beer vs. free speech").
I'll read exactly one more message from you, and if you say something
that makes extraordinary compelling sense to me, I'll read more.
But I'm not about to get sucked in - I've got a life to live.
Daniel Barlow
> Is the gap between paid Lisp and free Lisp due to the fact that
> Lispers always work on companies with big budgets, so they don't
> feel the __need__ to better the user interface in the free stuff?
No.
HTH
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow
> Too bad for the Lisp community, I guess.
> If the Perl Mongers or other active groups were to think like you do,
> Perl wouldn't be "the glue of the internet."
> And there wouldn't be Emacs, GNU/Linux, etc, etc.
I'm not entirely sure what effect you're hoping to achieve with these
postings, but I for one am not finding myself inspired by them to go
away and hack great things.
If you'd like to do something _good_ for the Lisp community, you could
start by writing some code - or some docs, or a useful web site, or
answers to questions on Usenet, or whatever. Something of value.
What you've given us here is the kind of pointless negative
destructive criticism that the Lisp community can do without. It
annoys me to read it.
Tim Bradshaw
> Funny thing I noticed with Common Lisp is that the free
> implementations lag behind proprietary software (LispWorks, etc.) at
> least interface-wise. I think this is a sad fact. One of the nicest
> things about Perl is tha Larry Wall really wanted to keep it free
> software and, as he writes in the book Voices from The Open Source
> Revolution, what he did can actually be compared with the "center of
> an onion". Layer after layer has developed around Perl the language,
> that were developed by a very active community. Is the gap between
> paid Lisp and free Lisp due to the fact that Lispers always work on
> companies with big budgets, so they don't feel the __need__ to
> better the user interface in the free stuff?
Funny thing I noticed with C++ is that the free implementations lag
behind proprietary software (Visual C++, etc.) at least
interface-wise. I think this is a sad fact.
Get the point now?
--tim
Tim Bradshaw
> I do have some other gripes, though. E.g. I don't think
> global variables are a very good way to control reader and printer
> properties. Using per-stream values, or some other more-local values,
> would get rid of a lot of not-quite-right stuff that SBCL and CMU CL
> have in common (and may share with many other CL implementations
> that I know less about): *DEBUG-PRINT-LENGTH*, *TRACE-PRINT-LEVEL*,
> never quite getting it right whether to use ~A or ~D or what when
> printing numbers in CONDITIONs which you expect to be printed
> interactively at the debugger REPL, and probably some other
> annoyances that don't immediately spring to mind. Global variables
> just don't work all that well for some (many...) things.
Actually, I think that special variables (not just `global variables')
are a fantastic win for this kind of thing, for reasons which are
often missed. If you have per-stream flags to control things like
reader and printer properties then the interaction with multithreading
becomes problematic at best: if some stream has the `print-readably'
flag set in one thread then you end up with it set in *all* threads.
Really the only way of having this work correctly is to have some
approach where you say something like:
(with-stream-parameters ((s stream)
:print-readably t ...)
...
(print ... s))
where this form creates a *new* stream S which is a wrapper around
STREAM but sets these parameters. The other possible approach would
be to have a binding form for stream parameters which sets them and
then secretly used something like DYNAMIC-WIND to unset them on thread
switches, but for reasons we've discussed in cll before DYNAMIC-WIND
is a hideous thing to assume as part of a threading system.
Instead, special variables, which interact with the threading system
properly in any sensible implementation, provide a simple & general
solution to the problem.
--tim
Ian Wild
>
[flame-bait]
Were you the guy teaching good manners earlier?
Eugene Zaikonnikov
Henry> Too bad for the Lisp community, I guess.
Henry> If the Perl Mongers or other active groups were to think like
Henry> you do, Perl wouldn't be "the glue of the internet."
I don't want Lisp to be a glue.
Henry> And there wouldn't be Emacs, GNU/Linux, etc, etc.
What is your point? Free (for any meaning of free) Common Lisp
implementations do exist (and there's more than one - hint hint).
--
Eugene
Rob Warnock
+---------------
| Python-like APIs of say, regex calls would help immensely...
...
| (dolist (match (re:findall <some-pattern> <some-string>))
+---------------
See <URL:http://www.ccs.neu.edu/~dorai/pregexp/pregexp.html>
[but the CL version mentioned there, though, not the Scheme one].
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]