Martin Rodgers wrote:
> Perhaps with Lisp you have to be more patient, until you reach a point
> where it all clicks and makes sense.
Huh? Both in my own experience, and from what I've been told by some
teachers, the fundamental principles of Lisp can be learned very quickly,
and for adequate problem areas applied more easily than lots of other
programming languages. The problems arise when someone supposedly wants
to learn Lisp, but in fact tries to express idioms from a very different
programming language in Lisp. The point isn't that one couldn't express
many different approaches in Lisp (there's probably not much to which an
expert can't adapt Lisp), but that people tend to confuse particular ways
of coding with more general problem solving.
One teacher who worked with linguists who had not even used a computer
before their course (this was quite a few years before the PC era),
reported that he was deeply impressed how soon these people were able
to write Lisp programs for their professional work, using Lisp to solve
their actual problems - not some toy stuff like what's common in courses.
Good teachers and good tutorials are certainly welcome, but the mental
approach to learning and programming is much more relevant than all the
technical problems together, as far as I can tell.
> Too many programmers just don't have the time to _learn_.
> Instead, they can find loads of people telling them how wonderful
> C/C++ is, so it must be true.
[...]
Too many people in this profession are simply coders, usually not very
interested in the first place to think much beyond the horizon of turning
a pretty much worked out solution into executable code in one and only one
programming language, of which they've seen some examples.
Frankly, I'm not sure why I should want such people to touch Lisp - all
its flexibility won't help a closed mind. Don't misunderstand that - I'm
all for providing as much and as high quality an education to people being
interested in learning - i.e. enjoying to go beyond what they know, even
partially invalidating what they once "knew" - and removing barriers that
people can really invest energy and time in such things, not only for a
job, but in many different areas of life. However, the latter are really
philosophical/social/political problems (aka "economy has quite destructive
effects for humanity"), and the human condition won't be helped very much
by introducing just another few people to Lisp programming.
If you want more dull coders programming horrible applications in Lisp,
something like "Web Applications in Common Lisp" might help. If you want
more people to act intelligently and use the available tools skillfully,
I fear you're looking in the wrong corner for a solution. Bad programmers
using Lisp do still write bad programs - probably even more so than with
tools where the amount of damage they can do is limited by (in your or my
view perhaps irritating) technical constraints.
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
Marc Wachowitz wheezed these wise words:
> Martin Rodgers wrote:
> > Perhaps with Lisp you have to be more patient, until you reach a point
> > where it all clicks and makes sense.
>
> Huh? Both in my own experience, and from what I've been told by some
> teachers, the fundamental principles of Lisp can be learned very quickly,
> and for adequate problem areas applied more easily than lots of other
> programming languages. The problems arise when someone supposedly wants
> to learn Lisp, but in fact tries to express idioms from a very different
> programming language in Lisp. The point isn't that one couldn't express
> many different approaches in Lisp (there's probably not much to which an
> expert can't adapt Lisp), but that people tend to confuse particular ways
> of coding with more general problem solving.
Yes, the problem is when a programmer learns Lisp, as that implies
that they already "know" how programming is done. If the style of
programming that they learned is significantly different to Lisp's
style, then there could be problems. As you said, idioms.
One of the possible distinctions between different kind of languages
is that some languages are extensible. I get the strong impression
that this is a tough idea for many programmers. If their concept of
what a compiler can do comes from somewhere like the Dragon book, they
might not think of languages as possibly being interactive, with
incremental compilers, capable of compiling code into the compiler's
own environment.
Maybe there's a good reason for this omission, but it was only earlier
this year that I discovered that the comp.compilers FAQ didn't include
PJ Brown's book, Writing Interactive Compilers and Interpreters. It
could be that this book is too simple (too "basic" would be a bad pun)
for the comp.compilers folk, but it does at least do an excellent job
of explaining some compiler concepts that go beyond the traditional
batch compiler.
> One teacher who worked with linguists who had not even used a computer
> before their course (this was quite a few years before the PC era),
> reported that he was deeply impressed how soon these people were able
> to write Lisp programs for their professional work, using Lisp to solve
> their actual problems - not some toy stuff like what's common in courses.
Excellent. Now all we have to do is reach all the programmers whose
minds have already been currupted with batch oriented languages.
> Good teachers and good tutorials are certainly welcome, but the mental
> approach to learning and programming is much more relevant than all the
> technical problems together, as far as I can tell.
I agree. I'm just saying that this mental approach is either a rarity,
or that it gets very little press. There are certainly non-technical
reasons why a good tool might be neglected.
> Too many people in this profession are simply coders, usually not very
> interested in the first place to think much beyond the horizon of turning
> a pretty much worked out solution into executable code in one and only one
> programming language, of which they've seen some examples.
Yep, too many "9 to 5" programmers.
> Frankly, I'm not sure why I should want such people to touch Lisp - all
> its flexibility won't help a closed mind. Don't misunderstand that - I'm
> all for providing as much and as high quality an education to people being
> interested in learning - i.e. enjoying to go beyond what they know, even
> partially invalidating what they once "knew" - and removing barriers that
> people can really invest energy and time in such things, not only for a
> job, but in many different areas of life. However, the latter are really
> philosophical/social/political problems (aka "economy has quite destructive
> effects for humanity"), and the human condition won't be helped very much
> by introducing just another few people to Lisp programming.
Alas, improving the human condition isn't necessarily how the market
operates. What does the market reward?
> If you want more dull coders programming horrible applications in Lisp,
> something like "Web Applications in Common Lisp" might help. If you want
> more people to act intelligently and use the available tools skillfully,
> I fear you're looking in the wrong corner for a solution. Bad programmers
> using Lisp do still write bad programs - probably even more so than with
> tools where the amount of damage they can do is limited by (in your or my
> view perhaps irritating) technical constraints.
I'm assuming that there are some good programmers out there who don't
yet know of Lisp, or that they've only heard of Lisp from people who
don't know what they're talking about. We know that such people exist,
as we've seen both kind here in comp.lang.lisp. I don't expect "dull
coders" to want to read "Web Applications in Common Lisp". I'd expect
to find anyone reading such a book to be unusually curious! My point
is that such a book would quickly reward such a reader with the
message, "Lisp can do things that you already do, and it may even help
you do them better, faster, etc."
Alternately, you could just assume that anyone who doesn't already
know Lisp never will, and wouldn't want to. I'm trying to be a little
more positive than that. What can we offer the curious programmer,
whop is currently browsing bookshelves full of books about web
development, visual programming, Java, Perl, etc? It's possible to
find a Lisp book in there, but it's also easy, from a quick flick thru
the pages, to get the wrong impression. Not everyone realises how much
of today's coding is approaching the complexity of AI, or how much
of it becoming AI itself. _We_ may know that, but how do we
communicate it? To many, AI is still a dirty word (well, two words).
And what do we find in so many Lisp books?
It's possible to attract readers looking for one thing, like web apps,
and to give them a whole lot more. PJ Brown did that. His book wasn't
just about compilers, it's also about good programming style. That 2nd
message has a lower profile, but he uses the compiler angle to talk
about something that any programmer should be able to understand. The
level at which he wrote about compiler theory should be intimidating
to anyone who is comfortable with strings.
Nearly 20 years later, what angle would be appropriate today?
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Martin" == Martin Rodgers <···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk> writes:
Martin> Yes, the problem is when a programmer learns Lisp, as that
Martin> implies that they already "know" how programming is done. If
Martin> the style of programming that they learned is significantly
Martin> different to Lisp's style, then there could be problems. As
Martin> you said, idioms.
This can be a difficult nut to crack. I've gotten better at it over
the years (I've worked with at least one language from each major
``family'' -- pure OO, functional, logic, procedural, etc.), and the
only way I've been able to do it at all reliably is this: don't learn
a language from a tutorial, or a reference manual. Pick up a bit of
code and stare at it until it starts to make sense. *Then* go back to
the tutorial and reference manual.
Basically, this has you absorbing the idioms of the language by
osmosis. It's how I learned Scheme, Prolog, and PostScript. I
learned Mercury (a statically typed, very heavily compiled version of
Prolog) with minimal Prolog experience by taking the nontrivial
examples and looking at them until they started to make sense. The
alternative is horrible: when I was young, I worked with AutoLISP and
became disgusted with the language when I couldn't figure out how to
loop. (Recursion hadn't occurred to me yet...)
OTOH, I have the time to do this.
- --
Graham Hughes <·············@resnet.ucsb.edu> / Never attribute to malice that
MIME OK, PGP preferred / which can adequately be
http://A31147.resnet.ucsb.edu/~graham/ / explained by stupidity.
/ -- Hanlon's Razor
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNGwcpSqNPSINiVE5AQFIKgQAq9tvDPN7GDY2zo40QYkKZeuOy+SR2VU/
cPmWp7dlPGcalcl8WJEAvkRS2IVFscBVUFjO+7tjirp0gQZOwyVslftZ6tXdy1cg
jYuscvwwPUu6qIEk5jkQFyQDykU10eTQXI1wzBV1JNLAoG5w+44o3PElpqlOiHrb
5Bi//ns46H4=
=3yi5
-----END PGP SIGNATURE-----
Graham Hughes wheezed these wise words:
> This can be a difficult nut to crack. I've gotten better at it over
> the years (I've worked with at least one language from each major
> ``family'' -- pure OO, functional, logic, procedural, etc.), and the
> only way I've been able to do it at all reliably is this: don't learn
> a language from a tutorial, or a reference manual. Pick up a bit of
> code and stare at it until it starts to make sense. *Then* go back to
> the tutorial and reference manual.
This is why I prefer tutorials that spend half the book on the
language, and the rest on _using_ the language. I learned Pascal from
a book that wasn't intended to teach Pascal, but was instead about
tool building _in any language_. It just happened to use Pascal.
I learned Lisp from the 1st edition of W&H, followed by the 2nd and
3rd editions and other Lisp books. It was interesting to see how the
code changed between each edition of W&H.
> Basically, this has you absorbing the idioms of the language by
> osmosis. It's how I learned Scheme, Prolog, and PostScript. I
> learned Mercury (a statically typed, very heavily compiled version of
> Prolog) with minimal Prolog experience by taking the nontrivial
> examples and looking at them until they started to make sense. The
> alternative is horrible: when I was young, I worked with AutoLISP and
> became disgusted with the language when I couldn't figure out how to
> loop. (Recursion hadn't occurred to me yet...)
Yeah, I learned Basic from a referene manual. The result was some
pretty ghastly code. Then I started reading books like Elements of
Programming Style and Software Tools. My Basic and assembly code
improved after that. I experiemented by applying ideas to see if they
helped, and they did.
I was playing with what I now thinking of prefix notation (I was so
close; all I needed was expression nesting) when I discovered Forth.
A few years later, I began exploring Lisp. One lead to the other.
> OTOH, I have the time to do this.
Same here. I spent two weeks of evenings to write my first Forth. One
week to get the system to the point where it could compile the rest of
the system, one week to recover from the shock of succeeding, and
another week to write the rest of the code. My 3rd Forth was written
in 3 weeks, as I wrote a simple Forth meta compiler and used it to
build the new system. I'm still using that compiler today, altho I
don't do much in Forth anymore. Lisp has taken over.
If I were more like most programmers that I know, I'd only be coding 9
to 5, or I'd focus solely on _one_ language in order to maximise my
investment (time and money). I don't look at it like that. New ideas,
new experiences, new tools...How do we put a price on such things?
My time has been repaid in many ways that I can't quantify. Since I
can't quantify them, I can't easily share them with other people, by
pointing at a schedule and saying, "This time was cut by doing
_this_!" Worse, my skills can applied in any language, even C++. It
matters to me that these skills and experiences came from using Forth,
Lisp, and other equally non-mainstream languages, but since nobody
else needs see this (you might see it in my code, I certainly see it,
but most people probably won't), the "only code in C++" bigots can't
use it against me. I love it.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Reginald S. Perry
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <sxlwwi6mzae.fsf@yakko.zso.dec.com>
········@visi.com (David Thornley) writes:
> Face it, guys, the capitalist system is very inefficient about rewarding
> excellence; it's usually better at rewarding mediocrity. For most
> companies, the computer systems are not the heart of the business, and
> making them superbly efficient is unlikely to help the business nearly
> as much as making the wrong choice is likely to hurt it. It's
> expensive to make changes, and the upside is likely to be streamlining
> a medium-sized chunk of their staff work. It's a matter of optimization.
> It may not be worth it.
>
I am not sure about the validity of what you imply above. I look at
this problem as being largely customer driven. If cars or bridges were
as poorly designed as some commercial software that I have on this PC
next to me, lawyers would be in lawsuit heaven. As it is, as long as
the customers accept crap, and spend their good money on crap, they
will be sold that crap at the highest price they are willing to pay,
delivered to them via the six-pack of crappy programmers that the
manager picked up at the local programmers store.
I think this is starting to change as consumer software becomes more
demanding and the price point for decent hardware remains the
same. People start to notice that they are spending hard earned money
on crap.
> >Too many people in this profession are simply coders, usually not very
> >interested in the first place to think much beyond the horizon of turning
> >a pretty much worked out solution into executable code in one and only one
> >programming language, of which they've seen some examples.
> >
> That's a demographic issue. There aren't enough first-rate programmers
> (like us :-) to go around. It's generally easier to hire a bunch of
> coders than a smaller number of really good people, and generally
> also more comfortable. Managing coders is like herding sheep, while
> managing top programmers is like herding cats.
>
This is always going to be true. I think that the problem is that
management needs to understand the issues a bit better. That wont
happen until people start losing serious money for being stupid.
>
> Right now, I have no faith that my favorite Lisp vendor, Digitool, is
> going to survive this century. I have no doubt that I will continue
> to have first-rate C++ development environments for years to come.
>
Well I am not sure about Digitool. That depends a bit too much on the
fortunes of Apple, but if Apple survives, I dont see Digitool going
anywhere soon.
> Yes, this would make comp.lang.lisp a much less fun place. We'd get
> five people a week asking why (delete 1 foo) doesn't always work,
> inflammatory style wars on car/first and setf/setq, that sort of thing.
> We'd constantly see Lisp abused in horrible ways, and people complaining
> loudly that a Lisp implementation doesn't work the way they want it
> to, regardless of standards.
> >
> >If you want more dull coders programming horrible applications in Lisp,
> >something like "Web Applications in Common Lisp" might help.
> >
> Exactly what I want! Let them pay for Franz and Harlequin and Digitool
> employees designing and building the Lisps of tomorrow, so that we
> can buy those Lisps tomorrow!
>
>
I dont think that Lisp will ever have the industry of "Lisp for
Dummies". This is a good thing. It seems that out of the Lisp vendors,
that Harlequin sells a Lisp system but its not their reason for being
and in spite of that, or maybe because of that, its a pretty darn nice
environment. So I dont think they are going anywhere anytime soon. It
also looks like Franz has a cottage industry of specialized
applications for which people need Lisp. So I have confidence that
they will be around for a while also. Harlequin has brought the price
of Lisp systems into the realm of us little guys so I am actually a
happy camper.
>
> --
> David H. Thornley | These opinions are mine. I
> ·····@thornley.net | do give them freely to those
> http://www.thornley.net/~thornley/david/ | who run too slowly.
-------------------
Reginald S. Perry e-mail: ·····@zso.dec.com
Digital Equipment Corporation
Performance Manager Group
http://www.UNIX.digital.com/unix/sysman/perf_mgr/
The train to Success makes many stops in the state of Failure.
Reginald S. Perry wheezed these wise words:
> I dont think that Lisp will ever have the industry of "Lisp for
> Dummies". This is a good thing.
This is not what I'd want, either. However, I don't believe that
everyone who writes software but who doesn't use Lisp as a "dummy".
The point that I've been trying to make is that Lisp isn't just for
the gurus writing large and spectacularly complex software. This may
well be the kind of software that CL was designed for, but today's
business apps are approaching the size and complexity where Lisp can
help. Even relatively mundane apps like web servers have been written
in Lisp! The business world is currently wetting itself over these
things, but where are the Lisp systems that bundle a web server?
There _are_ people interested in using Lisp to write business
software. This is a time of great opportunities, when whole new
app domains are emerging. (Groupware _finally_ hits the bigtime.)
In spite of the all the advantages that Lisp has over other languages,
the deluge of tools to exploit these networking opportunities are not
targetting Lisp, but languages like C++ and VB.
Maybe it's different for Unix (I recall reading something about www Tk
widgets), but this is certainly the case for Windows. (Let's please
leave the advocacy issues out of this. It won't change the zeitgeist.)
It's tempting to think that just because, let's say, CL-HTTP is
written in Lisp that it can beat the crap out of anything else. Alas,
this is not always the case. We may need more than just a sense of
superiority in order to compete in a tough market. It could be that
Lisp has a safe niche (or several), and that competition isn't as
tough. It could be that I'm just unfamiliar with such a niche, and so
I'm a little sceptical. YMMV.
Right now, I'm more familiar with a niche or two currently dominated
by non-Lisp tools. That doesn't make me wrong, necessarily. It just
gives me a different point of view. If I were the only one with this
POV, then I wouldn't bother to mention it here. I'm only mentioning it
now because it looks like David Thornley and I might be agreeing on a
few things. I certainly have some sympathy with what he's saying here.
> Harlequin has brought the price of Lisp systems into the realm of
> us little guys so I am actually a happy camper.
I'm also happy. If someone would pay me to write code in Lisp, I'd be
even happier, but I guess that's a different matter. I'd be happy
coding in Lisp even if nobody paid me to do _anything_ (Been There,
Done That). In fact, I'd have even more time for using Lisp.
Now even an unemployed Lisp programmer can afford a commercial CL. ;)
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> help. Even relatively mundane apps like web servers have been written
> in Lisp! The business world is currently wetting itself over these
> things, but where are the Lisp systems that bundle a web server?
MCL comes with CL-HTTP on the CD ROM. Some
applications you can buy are written with MCL using CL-HTTP.
There are even demo applications available.
Btw., *one* reason for the ongoing development of Symbolics
Genera is surely the White House web application of
CL-HTTP for document distribution. I would consider this
to be a very successful web application of Lisp.
> targetting Lisp, but languages like C++ and VB.
CL-HTTP has been ported by Harlequin to LispWorks. The current
devo of CL-HTTP should basically work with LWW 4.0.1 (you may need
some patches from Harlequin, too) You can start hack Web applications
with LWW (which, hint, hint, has an ODBC interface). Well,
atleast my copy of LispWorks can run CL-HTTP.
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> MCL comes with CL-HTTP on the CD ROM. Some
> applications you can buy are written with MCL using CL-HTTP.
> There are even demo applications available.
Excellent. Well done Digitool!
> Btw., *one* reason for the ongoing development of Symbolics
> Genera is surely the White House web application of
> CL-HTTP for document distribution. I would consider this
> to be a very successful web application of Lisp.
Just not very competitive with rival web technology. CL-HTTP alone is
lagging behind the top commercial web servers, while Genera is a lot
more expensive, unless you already have an Alpha machine running
OSF/1. It's successful in the sense that it works, and if that's all
you care about, then it's fine.
However, in the web hosting market, you'll find that many others are
rather more demanding. FoxNet also works, but I doubt that you'll find
it running on many corporate webservers. Of course, you can ignore the
corporate market if you wish.
> > targetting Lisp, but languages like C++ and VB.
>
> CL-HTTP has been ported by Harlequin to LispWorks. The current
> devo of CL-HTTP should basically work with LWW 4.0.1 (you may need
> some patches from Harlequin, too) You can start hack Web applications
> with LWW (which, hint, hint, has an ODBC interface). Well,
> atleast my copy of LispWorks can run CL-HTTP.
Patches? I've got LWW 4.0.1 but I didn't know there were any patches
for it yet.
Ok, so there's at least one web tool for Lisp that runs under Windows.
That's a start, but we're hardly deluged in Lisp tools. (See below).
Meanwhile, web tools for C++, VB, etc have been available for well
over a year, and more keep appearing. It's hard to keep track of them.
Perhaps Lisp programmers only need one web server, if it's good
enough? I would think that this is the case. Using LispWorks and CL-
HTTP, it shouldn't be necessary to use a template language for feeding
database results into an HTML page. Lisp itself will do.
My hope is that Lisp-based web development is one of those activities
that is mainly done in-house, and is therefore "invisible". You're not
likely to read about it in mainstream development magazines or the
specialised web development rags. Right now, Java seems to bet getting
most of the software development attention for the web.
Nor do I expect to see mainstream Windows development mags publishing
features on how to use CL-HTTP for your web server. This could be
done, of course, but it's more likely that most of the editorial staff
have been bought off by MS. See the September 1994 issue of Windows
Tech Journal, in which the editor reported the MS practice of inviting
magazine editors to "serve as a member of Microsoft's Visual C++
development team." This coz the mag all their MS advertising, but the
price was worth it, IMHO. It's important to know how much (or how
little) you can trust what you read in the press.
Or maybe I'm being just a little too cynical? I dunno, but I hope so.
Not that I'd wish my cynicism to stop anyone from using Lisp! One of
my rules is: Do it _because you can_. I use Lisp _because I can_.
The only real problem with CL-HTTP is that not enough people know
about it. If Harlequin bundle it with LWW and place adverts for it in
mainstream development mags, the message should get to a few people.
Match non-Lisp based web servers feature for feature, make sure it's
as easy to administrate as the rivals, add remote admin, and then sell
it as rocket powered web technology, and you could compare all the
other web servers to steam power. The "rocket powered" label would be
more convincing if it wasn't based on an assumption that Lisp alone is
enough to make an app superior. Most people don't know this.
Oh, and make sure that the Harlequin website uses it. ;) That's the
real testimony. Point visitors to the Whitehouse site and any others
that use CL-HTTP. In other words, give it some marketing. Sell it.
ATM, Harlequin's website doesn't seem to mention CL-HTTP.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Rainer Joswig
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <34720E03.1F57932B@lavielle.com>
Martin Rodgers wrote:
> Just not very competitive with rival web technology. CL-HTTP alone is
> lagging behind the top commercial web servers,
CL-HTTP was the *first* serverto do HTTP 1.1. The guys at W3C sometimes
did debug their HTTP 1.1
code connecting to CL-HTTP.
It comes with proxy and web walker functionality.
It does support virtual hosts and you can run multiple
HTTP protocols inside the image. You can develop your own
protocol or protocol extensions just by writing CLOS code
and extending the server's object-oriented architecture..
The White House installation has demonstrated joint
development for mail and web based applications from
one code base, integration into an object-oriented database,
URNs, ... Only two web servers are somewhat comparable
(for example Jigsaw), but with a more primitive architecture.
Additionaly the CL-HTTP code is ultra portable (Windows, Windows NT,
Mac OS, Lispm, Unix) using many different
Common Lisp systems (CMU CL, ACL NT, ACL PC, ACL Unix, LW, LWW,
LCL, MCL, SCL). Not bad for a niche language.
> It's successful in the sense that it works,
Successful means, it runs applications people care about, like theWhite
House document distribution, Medical Expert systems
with web interface, tutoring systems, city information systems,
chat systems, ...
> Perhaps Lisp programmers only need one web server, if it's good
> enough?
There are atleast three different web servers for Common Lisp alone.
> ATM, Harlequin's website doesn't seem to mention CL-HTTP.
Go to the links page.
I think it is a good move for Harlequin (especially Martin Simmons) to
support
CL-HTTP. It is currently a standard for web development in Common Lisp
and everyone is invited to use CL-HTTP (according to the license) and
to improve the tool for the benefit of all users. Thank god it's freely
available.
How about getting the latest CL-HTTP devo, get the patches from
Harlequin,
and help improving the LWW port?
* Martin Rodgers wrote:
> Just not very competitive with rival web technology. CL-HTTP alone is
> lagging behind the top commercial web servers,
CL-HTTP is miles ahead of any of the competition that I know of, for
any lisp-based application. It's almost trivial to write things that
export & import information directly from & to the structures in the
program. CL-HTTP was also the first fully http-1.1 server (is it
still?).
(of course the `for any lisp-based application' qualifier above may be
seen as significant).
> while Genera is a lot
> more expensive, unless you already have an Alpha machine running
> OSF/1. It's successful in the sense that it works, and if that's all
> you care about, then it's fine.
You don't need genera for cl-http.
--tim
Tim Bradshaw wheezed these wise words:
> CL-HTTP is miles ahead of any of the competition that I know of, for
> any lisp-based application. It's almost trivial to write things that
> export & import information directly from & to the structures in the
> program. CL-HTTP was also the first fully http-1.1 server (is it
> still?).
Yet it still lacks some critical features, like SSL.
> (of course the `for any lisp-based application' qualifier above may be
> seen as significant).
If you're only comparing it with other Lisp apps, then CL-HTTP appears
to have has no compeition. However, compare it with the servers listed
in the web server FAQs (comp.infosystems.www.*), and it looks rather
different. Of course, if CL-HTTP were a commercial app, then the admin
and security, features found in commercial web servers might be added
to CL-HTTP. Maybe even the commerce features, too.
> You don't need genera for cl-http.
Exactly. And it's just as well! The cost of a server can include the
whole machine, hardware, OS, and web server.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Yet it still lacks some critical features, like SSL.
Critical for whom?
How about implementing SSL in Lisp? Definitely more needed
than just another Lisp compiler.
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> > Yet it still lacks some critical features, like SSL.
>
> Critical for whom?
Anyone who wants security. For example, anyone wishing to trade via
their website. As I said yesterday, not everyone will want to do such
things. I don't expect researchers to do this, but they might have
other uses for SSL.
Note every server can offer every feature, and every server has a few
weaknesses. It would unreasonable to expect a free server to compete
with the most popular commercial web servers. In spite of this, I
think that CL-HTTP is a very capable server. I'm happy to see that I'm
not the only one:
<URL:http://webcompare.internet.com/compare/clhttp.html>
This won't impress everyone, nor should we expect it to. However, a
side by side comparison with commercial servers can still show that
CL-HTTP can give some healthy competition. Whether or not it meets
your needs will vary, depending on the nature of your needs.
This is why I pointed out the lack of SSL. I'm not condemning CL-HTTP
by saying that some people will consider this to be critical. YMMV.
We choose CL-HTTP. Many others don't. Is that heresy or observation?
Is it wrong to offer reasons why people may overlook this fine server?
Is that the same as endorsing such a choice? I hope not.
> How about implementing SSL in Lisp? Definitely more needed
> than just another Lisp compiler.
That's debatable. If someone writes a tool, like a compiler, that does
something not currently done by an existing tool, that could be worth
doing. You may have no use for that tool, but others might. The
programmer who writes it could do it because _they_ have a use for it.
It's hard for anyone else to deny that.
If you wish to tell me what my priorities are, then pay for my time.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Espen Vestre
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <w6ra8d133h.fsf@gromit.nextel.no>
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Just not very competitive with rival web technology. CL-HTTP alone is
> lagging behind the top commercial web servers, while Genera is a lot
do you have any examples of actual "top commercial web servers"?
My experience is that they're all overhyped. Speaking e.g. of Netscape,
their software (client or server) may be feature-rich, but it's
usually very slow and extremely bloated (gee, I think my netscape client
just passed 40MB of RAM usage).
> My hope is that Lisp-based web development is one of those activities
> that is mainly done in-house
you might be right! I'm developing our second lisp-based webserver now,
but it will only be used for internal purposes.
> The only real problem with CL-HTTP is that not enough people know
> about it. If Harlequin bundle it with LWW and place adverts for it in
> mainstream development mags, the message should get to a few people.
Hmm, I actually think that more and more people are getting to know it.
And the Franz web site had a cover story on it.
> Match non-Lisp based web servers feature for feature, make sure it's
> as easy to administrate as the rivals, add remote admin, and then sell
> it as rocket powered web technology, and you could compare all the
> other web servers to steam power. The "rocket powered" label would be
> more convincing if it wasn't based on an assumption that Lisp alone is
> enough to make an app superior. Most people don't know this.
Hmm, it _would_ perhaps be an idea to make a "thing-that-goes-bing"
commercially packaged version of CL-HTTP in order to assist eager
programmers to convince their bosses ;-) What do the CL-HTTP community
think of this?
--
regards,
Espen Vestre
Telenor Nextel AS
Norway
Espen Vestre wheezed these wise words:
> do you have any examples of actual "top commercial web servers"?
I regularly use WebSite, and I've (briefly) used IIS. I'm familiar
with the experiences of people using other servers.
> My experience is that they're all overhyped.
YMMV. What is that seems overhyped? Is there something that they don't
do that you need, or that they do that you don't need?
> Speaking e.g. of Netscape,
Ah, well. I can't comment on their servers. Note the plural - not
everyone needs every feature, so pick the server that matches your
needs.
> their software (client or server) may be feature-rich, but it's
> usually very slow and extremely bloated (gee, I think my netscape client
> just passed 40MB of RAM usage).
I certainly can't comment on performance. I've only been able to
measure performance under "lab conditions", which means stressing the
server to simulate real loads. The online server that I use is either
very lightly loaded, or copes very well with its daily loading.
The Netscape client? The browser? That's a different issue. Out of
curiousity, how does it compare with GNUScape? While Emacs still has a
rep for large memory demands, I've not noticed this with the Windows
version. (OTOH, I've not used GNUScape.) Emacs here uses about 3 MB
working set, 257 MB for the peak virtual size, while the Netscape�
Communicator 4.03 working set is 7 MB, peak virtual size 40 MB (approx
sizes). This current Netscape process has a fault count of 3K, FWIW.
YMMV, esp if you use a different OS. (I currently use NT 4.0.)
> you might be right! I'm developing our second lisp-based webserver now,
> but it will only be used for internal purposes.
Private internal servers can be the most fun, IMHO. You have the most
freedom to try new ideas, and do whatever you like. That's perfect for
development work. Next, you can have internal servers that are shared
with other network users. They can also be fun. And then there're the
online servers that anyone can see - but not everyone can access, or
not access every part of the server, or every site on the server.
> Hmm, I actually think that more and more people are getting to know it.
More Lisp people, certainly. ;) And people who read web server FAQs.
> And the Franz web site had a cover story on it.
Yep. More preaching to the converted, but at least they mention it.
Anyway, how many people are using CL-HTTP but not Lisp? Lisp would
seem to be a prerequisite.
> Hmm, it _would_ perhaps be an idea to make a "thing-that-goes-bing"
> commercially packaged version of CL-HTTP in order to assist eager
> programmers to convince their bosses ;-) What do the CL-HTTP community
> think of this?
This is exactly what I'm hoping will happen. With so many web servers
that work "out of the box", CL-HTTP is at a severe disadvantage. Now,
bundle it with a commercial Lisp system that installs CL-HTTP at the
same time, with a menu item that runs the server, another menu item or
script that creates a stand alone binary, plus some simple admin user
interface for quick results, and maybe CL-HTTP could geta foot in the
door. Then the sales pitch can begin!
It may sound like the smart people who will use a server like CL-HTTP
don't need such hand-holding, but as you pointed out, it may be their
bosses that need convincing, not the programmers. An app like a web
server also suffers from the image of being simple enough to manage
without a programmer. Well, if all you want to do is deliver simple
objects, like pages, images, sounds etc, then that's fine. The more
interesting work requires some programming, even if it's only writing
database templates. The best results demand a lot more than this.
CL-HTTP might be used more if it were targetted at the people who want
to go way beyond the traditional (yep, we can now use that word to
describe the web apps built using familiar and well-worn database
tech) apps. Alas, at least one web server FAQ that mentions CL-HTTP
misses the "power web server" potential. It more or less dismisses it
as a curiousity, an afterthought at the end of the server list. This
isn't a good way to tell people about a power tool.
In contrast, the CL-HTTP web pages are very well written, IMHO. Anyone
who gets as far as the first page will see that this is a serious
server, with good support for the HTTP 1.1 features.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
* Martin Rodgers wrote:
> This is exactly what I'm hoping will happen. With so many web servers
> that work "out of the box", CL-HTTP is at a severe disadvantage. Now,
> bundle it with a commercial Lisp system that installs CL-HTTP at the
> same time, with a menu item that runs the server, another menu item or
> script that creates a stand alone binary, plus some simple admin user
> interface for quick results, and maybe CL-HTTP could geta foot in the
> door. Then the sales pitch can begin!
But `working out of the box' pretty much means `serving a bunch of
html files', or perhaps serving data from some relational database.
Well, CL-HTTP can do that, sure, but it's hardly an interesting
application, is it?
What you want is a web server that lets you do things that are
interesting with the web: dynamically created web pages, web
interfaces to large SW systems, &c &c. A system like that will not
run out of the box, because you're going to have to bite the bullet
and write programs. Writing such programs using CL-HTTP is a delight,
especially after fighting with perl CGI scripts.
In fact, to go off at yet another tangent, this `run out of the box'
idea is one of the most pervasive & dangerous misconceptions currently
around. Non-trivial applications do not run out of the box. I hear
so many people say `just get NT and office 97 and blah and we can just
run our MIS system on the web and it will have no maintenance and it
will just work and all the problems are solved', and this is just
obvious crap: how do we do access control? who is going to run the NT
box? who does the backups? Sure, these tools may make things somewhat
easier, but they do not solve the interesting problems, because the
greater part of these problems is hard, idiosyncratic, and require
thought and time -- that's why they're interesting. There is no
silver bullet.
--tim
Tim Bradshaw wheezed these wise words:
> But `working out of the box' pretty much means `serving a bunch of
> html files', or perhaps serving data from some relational database.
And a _lot_ more. CL-HTTP already has some of these things, like web
based admin, authentication and access control.
> Well, CL-HTTP can do that, sure, but it's hardly an interesting
> application, is it?
Maybe not to research people. Perhaps I'm playing Devil's Advocacte,
by looking at Cl-HTTP from the world of commerce.
> What you want is a web server that lets you do things that are
> interesting with the web: dynamically created web pages, web
> interfaces to large SW systems, &c &c. A system like that will not
> run out of the box, because you're going to have to bite the bullet
> and write programs. Writing such programs using CL-HTTP is a delight,
> especially after fighting with perl CGI scripts.
It depends on what you mean by "dynamic". You can generate pages
dynamically from databases. I've seen entire websites that work this
way. You do indeed need to write the templates for the dynamic pages,
but it doesn't need to be done in _perl_ (yuk). It's not only Lisp
programmers who're repulsed by perl. That's why there are alternatives
to perl, like template languages with embedded SQL.
> In fact, to go off at yet another tangent, this `run out of the box'
> idea is one of the most pervasive & dangerous misconceptions currently
> around. Non-trivial applications do not run out of the box. I hear
> so many people say `just get NT and office 97 and blah and we can just
> run our MIS system on the web and it will have no maintenance and it
> will just work and all the problems are solved', and this is just
> obvious crap: how do we do access control? who is going to run the NT
> box? who does the backups? Sure, these tools may make things somewhat
> easier, but they do not solve the interesting problems, because the
> greater part of these problems is hard, idiosyncratic, and require
> thought and time -- that's why they're interesting. There is no
> silver bullet.
Doing anything dynamic with a web server requires some work. The
phrase "out of the box" refers to the amount of time requires to get
something working, however basic. Today's commercial web servers can
be installed in minutes, and it only takes a little longer to connect
them to a databae and start delivering pages. That's a big selling
feature - you can impress the hell out of people with very little time
and effort.
This won't matter to everyone, but I'm giving one reason why CL-HTTP
won't impress everyone. Whether those people matter or not is
debatable. After all, CL-HTTP isn't really competing with the
commercial web servers.
The OS overheads don't matter - there'll be overheads like backups for
_any_ kind of server. Some people choose NT, some choose Unix, and
others may choose something else. IME they do this because of past
experience with than OS. Pick something you know and can quickly get
results with, because time costs money. And life is short.
Lisp can't work miracles. The question here is: Can CL-HTTP make
creating dynamic web apps easier than commercial web servers? This
will depend on the domain; research, commerce, whatever. If you wish
to ignore commerce, then I'm sure that CL-HTTP will do very nicely.
I'd certainly use CL-HTTP, if I were choosing a web server.
As the subject of this thread is "Limitations of Lisp", I'd suggest
that Lisp's limitations are also it's strengths. And vica versa.
Of course, this is true of everything, so it probably isn't much help.
It's hard to please everyone. Maybe no software can do that...
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> won't impress everyone. Whether those people matter or not is
> debatable. After all, CL-HTTP isn't really competing with the
> commercial web servers.
Why don't you get it? People are already *selling* web servers
based on CL-HTTP. Those may not need be using Lisp at all.
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> Why don't you get it? People are already *selling* web servers
> based on CL-HTTP. Those may not need be using Lisp at all.
Do you mean that they may be stand-alone apps, not requiring a full
Lisp system in order to run CL-HTTP? That's great, because it reduces
the cost per machine when a commercial CL is used.
I _do_ get it, Rainer. I just have the ability to see things from the
point of view of the people who _don't_. Please don't confuse me with
those other people.
If CL-HTTP is competing with commercial web servers as a package
(complete machine setup or prebuilt server binary), by Lisp
developers, then this is no different to how any other web server is
being used commercially.
There are two distinctions that I'm making here. One is between
servers that are themselves commercial, i.e. you have to pay in order
to use them (apart from free evaluation, if that option is available)
and there are restrictions on the number of machines on which they can
be installed. The other distinction is between servers used for
commercial and non-commercial applications. The latter is a tricky
one, as it may depend on who hosts the site and what they consider to
be commercial.
Perhaps it's possible to make it clearer how other people (non-Lisp?)
see CL-HTTP? The web FAQ leads us to the webcompare site, which has
the following page for CL-HTTP:
<URL:http://webcompare.internet.com/compare/clhttp.html>
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Do you mean that they may be stand-alone apps, not requiring a full
> Lisp system in order to run CL-HTTP?
Sure. We are talking about applications here. Not about development
systems.
> If CL-HTTP is competing with commercial web servers as a package
> (complete machine setup or prebuilt server binary), by Lisp
> developers, then this is no different to how any other web server is
> being used commercially.
That's what I'm saying.
> Perhaps it's possible to make it clearer how other people (non-Lisp?)
> see CL-HTTP? The web FAQ leads us to the webcompare site, which has
> the following page for CL-HTTP:
> <URL:http://webcompare.internet.com/compare/clhttp.html>
I'm not sure if this is really helpful, if the information comes
from people who may never have used CL-HTTP.
--
http://www.lavielle.com/~joswig/
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> This is exactly what I'm hoping will happen. With so many web servers
> that work "out of the box", CL-HTTP is at a severe disadvantage. Now,
> bundle it with a commercial Lisp system that installs CL-HTTP at the
> same time, with a menu item that runs the server, another menu item or
> script that creates a stand alone binary, plus some simple admin user
> interface for quick results, and maybe CL-HTTP could geta foot in the
> door. Then the sales pitch can begin!
Guess what, load CL-HTTP into MCL and you get a basic menu for the
server (you can start, stop, inspect, change debug settings, edit code,
load code, get pages, open urls in a local browser,
find documentation, load demos, ...
...
(defun development-items ()
(list (make-about-menu-item)
(make-release-notes-menu-item)
(make-license-menu-item)
(make-mac-readme-menu-item)
(when (fboundp 'ccl::open-url)
(make-open-url-item))
(divider-item)
(make-preferences-menu-item)
(make-load-configuration-menu-item)
(make-save-configuration-menu-item)
(divider-item)
(make-startup-menu-item)
(make-start-server-menu-item)
(make-stop-server-menu-item)
#+open-transport(make-reset-network-menu-item)
(divider-item)
(make-menu-from-inspect-menu-description)
(make-find-documentation-menu-item)
; (make-show-documentation-menu-item)
(make-menu-from-tool-menu-description)
(divider-item)
(make-toggle-var-item 'http:*debug-server*
"Debug Server"
"On error the server enters a break loop.
Not for production use.")
(make-toggle-var-item 'ccl::*use-resolver*
"Use DNS Resolver"
"Controls the MCL DNS resolver code.")
(make-toggle-var-item 'http:*log-resolve-ip-addresses*
"Resolve IP Adresses for Logging"
"All IP Addresses will be resolved for the
log. For production servers you may want to turn it off.")
(when (or (fboundp 'http::show-url)
(fboundp 'http::show-url-headers)
(boundp 'http::*debug-client*))
(divider-item))
(when (boundp 'http::*debug-client*)
(make-toggle-var-item 'http::*debug-client*
"Debug Client"
"On error the client enters a break loop.
Not for production use."))
(when (fboundp 'http::show-url)
(make-show-url-item))
(when (fboundp 'http::show-url-headers)
(make-show-url-headers-item))
(when (fboundp 'http::show-raw-url)
(make-show-raw-url-item))
(when (fboundp 'http::show-url-options)
(make-show-url-options-item))
(when (fboundp 'http::show-url-trace)
(make-show-url-trace-item))
(when (fboundp 'http::enable-proxy-service ) (divider-item))
(when (fboundp 'http::enable-proxy-service)
(make-toggle-menu-item 'http::proxy-service-enabled-p
'http::enable-proxy-service
'http::disable-proxy-service
"Enable Proxy"
"CL-HTTP provides a proxy
service."))
(when (boundp 'http::*debug-proxy*)
(make-toggle-var-item 'http::*debug-proxy*
"Debug Proxy"
"On error the proxy enters
a break loop.
Not for production use."))
(when (boundp 'http::*proxy-caching-p*)
(make-toggle-var-item 'http::*proxy-caching-p*
"Use Caching for Proxy"
"The Proxy caches requests."))
(divider-item)
(make-edit-system-menu)
(make-action-system-menu :load
"Load CL-HTTP System")
(make-action-system-menu :compile
"Compile CL-HTTP System")
(make-action-system-menu :compile-load-always
"Compile and Load (Always) CL-HTTP System")
(make-action-system-menu :compile-load
"Compile and Load CL-HTTP System")
(make-load-extensions-menu)))
You just need to start your save Lisp image
and choose "Start Server with Demos with DNS" from
the CL-HTTP menu. Off you go.
Once I have a usable CLIM for MCL and/or LWW, I'll start writing a CLIM based
user environment for CL-HTTP.
How about stop whining and writing some code?
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> Guess what, load CL-HTTP into MCL and you get a basic menu for the
> server (you can start, stop, inspect, change debug settings, edit code,
> load code, get pages, open urls in a local browser,
> find documentation, load demos, ...
Excellent. That's exactly what CL-HTTP needs, IMHO.
> Once I have a usable CLIM for MCL and/or LWW, I'll start writing a CLIM based
> user environment for CL-HTTP.
Even better!
> How about stop whining and writing some code?
How about paying attention? How about not assuming that because I have
something to say that you don't like, that I don't write code or don't
have a right to an opinion. How about accepting that someone you don't
agree with may still express an opinion? How about not assuming that
Lisp will just win _because it's Lisp_?
You can go into hyper-critical mode if you like, which is why I
refered to "Devil's Advocate" in an earlier post. You're not the only
one who can be hyper-critical - this what I've been doing, in order to
make a point. Not everyone automatically sees Lisp and says, "This
will beat everything else. It's just what I need." Quite the opposite,
in fact.
I'm _not_ knocking CL-HTTP. I'm putting it into context. If this was
the only web server available, there'd be nothing to compare it to. As
this is not the case, I'm comparing to the alternatives.
How about accepting that here are alternatives for CL-HTTP to compete
with? Maybe you won't choose anything but a Lisp-based solution, and
perhaps nobody demands that you justify your choice, but this is not
the case for everyone. In many cases, when this is the case, the
choice won't be Lisp, it'll be C++. (Note the number of servers with
C++/CGI support.) These people will automatically choose C++, just as
_we_ (yep, me too) automatically choose Lisp.
Writing code isn't always the answer, esp if your time is payed for by
people who choose C++. Sometimes the developers themselves choose it!
This is why I'm interested in comparing CL-HTTP with the alternatives,
and trying to be just a little objective. If CL-HTTP can survive such
a comparison, doesn't it look good? If you're going to choose CL-HTTP
anyway, this is not an issue, but...
How about checking the subject of this thread? Automatically choosing
Lisp and Lisp-based solutions doesbn't always the question that
started this thread. How about that?
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Reginald S. Perry
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <sxlvhxqlydt.fsf@yakko.zso.dec.com>
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Reginald S. Perry wheezed these wise words:
>
> > I dont think that Lisp will ever have the industry of "Lisp for
> > Dummies". This is a good thing.
>
> This is not what I'd want, either. However, I don't believe that
> everyone who writes software but who doesn't use Lisp as a "dummy".
> The point that I've been trying to make is that Lisp isn't just for
> the gurus writing large and spectacularly complex software. This may
> well be the kind of software that CL was designed for, but today's
> business apps are approaching the size and complexity where Lisp can
> help. Even relatively mundane apps like web servers have been written
> in Lisp! The business world is currently wetting itself over these
> things, but where are the Lisp systems that bundle a web server?
>
While I agree that Lisp isn't for gurus only (I am nowhere near being a
guru), there is a large amount of tunnel vision in our industry. I
don't think that its worth my effort to attempt to adjust the
limitations of other programmers. I'm too busy trying to correct my
own limitations. :-)
What we can do is slowly try to infiltrate Lisp into our jobs by
slowly convincing our managers to allow us to use Lisp on certain side
projects and slowly move it up the chain. This is a tough route. I
chose this route and got project approval, but resource shortages made
it so that I have to hack more "popular" languages to keep the project
on track. But I did get management to purchase everything I need to
keep the side project alive until we get more resources.
Lisp has been around for a very long time, through several phases
where one would have thought that the language would have died
out. But its still here. The software industry is coming to the point
where time-to-market, quality, and timely response to users' requests
for features are becoming more mutually exclusive or very expensive
to accomplish. The Lisp vendors are starting to respond vigorously to
requests for certain features to the product, like the possibility of
generating DLLs and such so I think that we will come to a point where
I can release a DLL and normal users wont know and wont care what
language was used.
> There _are_ people interested in using Lisp to write business
> software. This is a time of great opportunities, when whole new
> app domains are emerging. (Groupware _finally_ hits the bigtime.)
> In spite of the all the advantages that Lisp has over other languages,
> the deluge of tools to exploit these networking opportunities are not
> targetting Lisp, but languages like C++ and VB.
>
Well it sort of depends on the type of tool that you are looking
for. Some of this stuff would be fitting square pegs into round
holes. Could you give me some examples?
-------------------
Reginald S. Perry e-mail: ·····@zso.dec.com
Digital Equipment Corporation
Performance Manager Group
http://www.UNIX.digital.com/unix/sysman/perf_mgr/
The train to Success makes many stops in the state of Failure.
Reginald S. Perry wheezed these wise words:
> While I agree that Lisp isn't for gurus only (I am nowhere near being a
> guru), there is a large amount of tunnel vision in our industry. I
> don't think that its worth my effort to attempt to adjust the
> limitations of other programmers. I'm too busy trying to correct my
> own limitations. :-)
I feel the same way.
> Well it sort of depends on the type of tool that you are looking
> for. Some of this stuff would be fitting square pegs into round
> holes. Could you give me some examples?
Examples? See the various Windows development magazines, as you'll
find adverts and reviews for many of them. Some mags list new tools,
and it's not unusual to see web-related tools appearing in these
pages. It might not be so easy to find such tools on the web unless
you look for them.
At least I've not yet seen a FAQ for server addons, like the kind of
list you can find in the web server FAQs. The Windows web server FAQ
<URL:http://info.ox.ac.uk/help/wwwfaq/swinnt95.htm> lists CL-HTTP and
describes it like this:
> It is available on many platforms, and can be programmed at a
> remarkably high level, using Lisp code to generate much of the
> output of the server. An interesting option when development
> time is limited.
That last line doesn't sound encouraging, like the author has some
doubts. So comments like this made for any of the other servers, altho
the choice of listed features is curious. Why mention that some
servers are multi-threaded and not others? Availability of space?
Many web tools are just things like database interfaces. However, as
that's a very useful tool in a corporate world, this is far from
insignificant. Some other tools may be little more than TCP/IP
components, altho they do tend to come with source code examples for
many Internet apps, like SMTP, FTP, etc.
These tools tend to build on what Windows developers will already
know, exploiting tools they're already familiar with. Even if the
languages are inferior to Lisp, that leverage helps a lot. Throw a
familiar SQL query into an HTML template, and bam! You've got a web
app. There's a big demand for that. CL-HTTP probably isn't going to
compete well at that level, but as the server tasks get more complex,
Cl-HTTP will gain a killer edge over the more primitive tools.
The really interesting tools are being built on top of the basic
networking tools. Much of that kind of work is done in-house, but you
can read about some examples in magazines like Byte. There's probably
little of it that can't easily be done in Lisp, but I've yet to read
_any_ "how to" style articles using Lisp. This may be because Lisp
programmers find it so much easier that we don't need a "how to"! Such
an article be useful for explaining to others less Lisp-literate than
ourselves why we use Lisp, and that this is not just "An interesting
option when development time is limited."
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Reginald S. Perry
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <sxlu3d8mean.fsf@yakko.zso.dec.com>
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Reginald S. Perry wheezed these wise words:
>
> > Well it sort of depends on the type of tool that you are looking
> > for. Some of this stuff would be fitting square pegs into round
> > holes. Could you give me some examples?
>
> Examples? See the various Windows development magazines, as you'll
> find adverts and reviews for many of them. Some mags list new tools,
> and it's not unusual to see web-related tools appearing in these
> pages. It might not be so easy to find such tools on the web unless
> you look for them.
>
You seem to want a Lisp counterpart for every C/C++/Java component out
there. This is not something that is going to happen anytime soon. And
maybe it shouldn't. I see a lot of developers using tools that they
are forced either to warp their spec or warp the intended usage of the
tool to solve their problem instead of just building the tool
in-house. The illusion is that the former takes less time than the
latter, but I am not so sure. You have to measure the final design in
contrast to what would have happened had you not warped the spec. In
addition some things do look more straightforward than the C
counterpart. For example Harlequin's CAPI looks easier to use than Motif.
>
> Many web tools are just things like database interfaces. However, as
> that's a very useful tool in a corporate world, this is far from
> insignificant. Some other tools may be little more than TCP/IP
> components, altho they do tend to come with source code examples for
> many Internet apps, like SMTP, FTP, etc.
>
> These tools tend to build on what Windows developers will already
> know, exploiting tools they're already familiar with. Even if the
> languages are inferior to Lisp, that leverage helps a lot. Throw a
> familiar SQL query into an HTML template, and bam! You've got a web
> app. There's a big demand for that. CL-HTTP probably isn't going to
> compete well at that level, but as the server tasks get more complex,
> Cl-HTTP will gain a killer edge over the more primitive tools.
>
I think that you are trying to move CL-HTTP out of its intended
realm. If I just want to serve web pages and run a CGI script here and
there, just use Apache and perl. Its free and runs just about
everywhere. If you feel insecure with that, use IIS. It comes with NT
Server. But if you are tired of having to invent wierd ways to
maintain state between transactions, and/or have novel ideas on how
you want to deliver information to the web, then the other tools are
quite inadequate for the job and CL-HTTP is the way to go.
Now I would say that there may be areas in which CL-HTTP could
improve, but I would say that as more people start to use it, you will
have people interested in performance. The thing is that there are so
many cool things that you can do with a server as dynamic as CL-HTTP,
that people are playing with their cool ideas, as they should. I would
say that people like me who are comming in on the ground floor and
slowly learning things should probably contribute the more mundane
things like SMTP, FTP, maybe get more ambitious at some point and do
IMAP, and other network tools of that ilk, and work on documenting the
server and such. This will let the gurus push the envelope while still
getting the server into good enough shape to allow people who just
want to serve web pages with a lisp web server be able to get started
quickly. So I dont think I can complain about what a free product
lacks unless I am willing to put that feature in, if no one else is
interested at the time. This is what the free software movement is
about right? Especially for something like CL-HTTP where most people
are very interested in novel ways of doing dynamic content creation
and presentation.
> The really interesting tools are being built on top of the basic
> networking tools. Much of that kind of work is done in-house, but you
> can read about some examples in magazines like Byte. There's probably
> little of it that can't easily be done in Lisp, but I've yet to read
> _any_ "how to" style articles using Lisp. This may be because Lisp
> programmers find it so much easier that we don't need a "how to"! Such
> an article be useful for explaining to others less Lisp-literate than
> ourselves why we use Lisp, and that this is not just "An interesting
> option when development time is limited."
> --
Like I said before, I dont know how to lead someone to a particular
programming language or convince someone that Lisp is nicer than
something else. When I mention Lisp to some co-workers I just get the
look of the crazy one touched by the Gods whom they should just smile
at but not touch. :-)
I say lets stop wasting valuable time trying to do that and spend more
time writing the mundane apps on the way to attempting to become gurus
ourselves.
-Reggie
-------------------
Reginald S. Perry e-mail: ·····@zso.dec.com
Digital Equipment Corporation
Performance Manager Group
http://www.UNIX.digital.com/unix/sysman/perf_mgr/
The train to Success makes many stops in the state of Failure.
Reginald S. Perry wheezed these wise words:
> You seem to want a Lisp counterpart for every C/C++/Java component out
> there.
No, that's not what I want. My point is that's what most people
looking for web solutions will want, because that's what they've been
lead to believe is the way it's done. For us to show that there are
other ways, we have to offer a very good counter argument to the
"orthodox" solutions.
> This is not something that is going to happen anytime soon.
I agree. Perhaps this is because of a lack of communication. If we
simply state that "Lisp is best", then we're doing no more than the
people who say, "C++ is best", or "Java is best", and the many other
variations of that argument.
I'm not necessarily interested in doing the same things as C++ folk.
If I was, then I'd just use C++. OTOH, we don't have to reject
everything (throwing out the baby with the bathwater), and I don't
that will help whoever started this thread asking for "Help required
on Limitations of Lisp".
> I think that you are trying to move CL-HTTP out of its intended
> realm. If I just want to serve web pages and run a CGI script here and
> there, just use Apache and perl. Its free and runs just about
> everywhere. If you feel insecure with that, use IIS. It comes with NT
> Server. But if you are tired of having to invent wierd ways to
> maintain state between transactions, and/or have novel ideas on how
> you want to deliver information to the web, then the other tools are
> quite inadequate for the job and CL-HTTP is the way to go.
Strangely, most people see _Lisp_ as the weird ways of doing things.
Hence the "Help required on Limitations of Lisp" question.
I'm not arguing in favour of C++. If I'm playing Devil's Advocate,
it's only to explain why anyone would wish to ask about "Limitations
of Lisp", instead of just using it.
> I say lets stop wasting valuable time trying to do that and spend more
> time writing the mundane apps on the way to attempting to become gurus
> ourselves.
Is it a waste of time to help answer a question? Or does the subject
of this thread, "Help required on Limitations of Lisp" (I'm ignoring
the "Lisp OS" for the sake of a quiet life), not tell you something?
Do you have a better argument than "Lisp is best"? Unless I'm
mistaken, just saying that "Lisp is best" doesn't explain what the
limitations of Lisp may or _may not_ be. It doesn't address the issue.
So what should a programmer do, if their boss doesn't understand Lisp,
and don't wish to? Just use Lisp anyway, and see what happens? How
about offering something more constructive? Maybe "Quit your job and
look for some place where they appreciate Lisp"? Yeah, right.
At least I'm trying to answer the question, instead of denying that it
was asked. Let's see that question again:
> I am a student who has been asked to prepare a report on limitations of
> Lisp. However, I have never used Lisp before and cannot get reference
> material on it here in Kenya. I would be grateful if someone could try and
> explain to me about Lisp and its limitations as a programming language.
IMHO the biggest limitation of Lisp is the "C++ is best" crowd and
their complete hostility to the "Lisp is best" crowd. Maybe the lack
of communication is the results of absolutist "X is best" attitudes?
A little perspective can do wonders for seeing the other side's point
of view, and that's the first step toward communication.
In other words, people are the problem. ;)
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Reginald S. Perry
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <sxlsosrm9o7.fsf@yakko.zso.dec.com>
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Reginald S. Perry wheezed these wise words:
>
> > You seem to want a Lisp counterpart for every C/C++/Java component out
> > there.
>
> No, that's not what I want. My point is that's what most people
> looking for web solutions will want, because that's what they've been
> lead to believe is the way it's done. For us to show that there are
> other ways, we have to offer a very good counter argument to the
> "orthodox" solutions.
>
Well its a little tough to use CL-HTTP in this context because its
initial goal was different then say the Apache team's goal. Now if you
say you would like to see CL-HTTP be feature compatible with the other
web servers then I bet the gurus would say "*yawn* thats nice" because
their interests are a lot different. I think that it will eventually
get to this point but that what may happen is that the people who are
first learning the system will probably contribute the things that
flesh out the features that they feel they need as a first project to
cut their teeth on. This is because the focus for CL-HTTP (I think) was
not to make a server that does everything the commercial servers do,
but to do the sort of cool things that can only be done in a dynamic
environment while still being able to do web server stuff. If it was a
commercial product, it would have been clear from the outset that in
order to sell product it would have to do *all* of the things
commercial web servers do *at least as well* and also do its special
cool stuff. Since its a volunteer project, all of the little bells and
whistles may not be there, but I assert that this is only until
someone puts them in.
> > This is not something that is going to happen anytime soon.
>
> I agree. Perhaps this is because of a lack of communication. If we
> simply state that "Lisp is best", then we're doing no more than the
> people who say, "C++ is best", or "Java is best", and the many other
> variations of that argument.
>
> I'm not necessarily interested in doing the same things as C++ folk.
> If I was, then I'd just use C++. OTOH, we don't have to reject
> everything (throwing out the baby with the bathwater), and I don't
> that will help whoever started this thread asking for "Help required
> on Limitations of Lisp".
>
> > I think that you are trying to move CL-HTTP out of its intended
> > realm. If I just want to serve web pages and run a CGI script here and
> > there, just use Apache and perl. Its free and runs just about
> > everywhere. If you feel insecure with that, use IIS. It comes with NT
> > Server. But if you are tired of having to invent wierd ways to
> > maintain state between transactions, and/or have novel ideas on how
> > you want to deliver information to the web, then the other tools are
> > quite inadequate for the job and CL-HTTP is the way to go.
>
> Strangely, most people see _Lisp_ as the weird ways of doing things.
> Hence the "Help required on Limitations of Lisp" question.
>
> I'm not arguing in favour of C++. If I'm playing Devil's Advocate,
> it's only to explain why anyone would wish to ask about "Limitations
> of Lisp", instead of just using it.
>
Its always hard to say what the limitations of a certain language
is. Especially when the people you are talking about are thinking more
about the particular implementations out there than the language
itself. If I look only at MSVC++ I would say that C++ is hard to
optimize but the Watcom C++ compiler and the DEC C++ complier show this
to be untrue.
This started out as a discussion on the limitations of Lisp but then
you wanted to explore how to get more people using Lisp. When I think
only about the question about the limitations of Lisp, I look at CLOS
the condition system, and how extensible the language is and I see
that the only limitations are in our heads. It just depends on what
one wants out of a language. The languages that are interesting to me
at this point in my life are Lisp, SML, and Modula-3. Meanwhile I earn
a living programming in C++ and Java. Go Figure.
>
> At least I'm trying to answer the question, instead of denying that it
> was asked. Let's see that question again:
>
> > I am a student who has been asked to prepare a report on limitations of
> > Lisp. However, I have never used Lisp before and cannot get reference
> > material on it here in Kenya. I would be grateful if someone could try and
> > explain to me about Lisp and its limitations as a programming language.
>
> IMHO the biggest limitation of Lisp is the "C++ is best" crowd and
> their complete hostility to the "Lisp is best" crowd. Maybe the lack
> of communication is the results of absolutist "X is best" attitudes?
> A little perspective can do wonders for seeing the other side's point
> of view, and that's the first step toward communication.
>
> In other words, people are the problem. ;)
Actually this is not a very precise question. It all depends on what
one wants to do, which is why the discussion fell off of the beaten
path. At zeroth level there is nothing that you can do in other
languages that you cannot do in Lisp. Lisp has ran on huge machines,
tiny embedded controllers and everything in between. So the question
that this person could be asking is why should they use Lisp instead
of some other language. I cannot answer this for them, I can only say
why I like Lisp. And since Lisp is a family of languages you should
probably say which Lisp you have in mind when you are talking about
things. The one I like the most is ANSI Common Lisp. So when I say
Lisp, this is the Lisp I mean.
Software Engineering, while trying to be as precise a discipline as say
Civil Engineering, is currently more art than engineering. So I use
the programming language as a form of expression, trying to map the
abstract ideas in my head into instructions for the machine. Lisp
seems to provide me with the greatest range of expression, allowing
one to try out things and have the correct solution evolve instead of
having to work out lots of details up front. I like tools that let me
work the way I want and does not force me into their way of
working. Lisp seems to be that tool. The languages that we now use
like C, C++, and Java, force me to do a lot of up-front thinking about
low level details of the problem which I wont really understand until
I have worked out possible solutions, when I have possible solutions
*then* I will know which data structures and such I can use. Its
easier to work out generalized frameworks to sit your solution on in
Lisp. I think this is because generic functions which have multiple
dispatch allow more expression than the other single dispatch OO
languages.In C++ the STL allows a bit of this kind of power, but look
at the infrastructure they had to construct to do it. *Sheesh*
Now I feel that I haven't even scratched the surface of what I can do
with the environment. It takes some time to actually get comfortable
with being able to do pretty much what I want instead of changing what
I want so that it will compile in the language of the day. So having
while Lisp on your resume is not a sure-fire way to get a job, I would
say that the way that I now think about attacking problems is a result
of exposure to Lisp and I believe that as I gain mastery of Lisp and
being able to take advantage of its idioms, I will become a better
programmer.
Now does this answer the question? I would bet not.
-Reggie
-------------------
Reginald S. Perry e-mail: ·····@zso.dec.com
Digital Equipment Corporation
Performance Manager Group
http://www.UNIX.digital.com/unix/sysman/perf_mgr/
The train to Success makes many stops in the state of Failure.
Reginald S. Perry wheezed these wise words:
> Well its a little tough to use CL-HTTP in this context because its
> initial goal was different then say the Apache team's goal. Now if you
> say you would like to see CL-HTTP be feature compatible with the other
> web servers then I bet the gurus would say "*yawn* thats nice" because
> their interests are a lot different.
Agreed.
> I think that it will eventually
> get to this point but that what may happen is that the people who are
> first learning the system will probably contribute the things that
> flesh out the features that they feel they need as a first project to
> cut their teeth on. This is because the focus for CL-HTTP (I think) was
> not to make a server that does everything the commercial servers do,
> but to do the sort of cool things that can only be done in a dynamic
> environment while still being able to do web server stuff.
There are certainly things being done in CL-HTTP that exploit Lisp
well. Interfacing a web server to Lisp code is a good example. If you
don't already use or know Lisp, this probably won't mean much, so it
might not help answer the question that started this thread, but it's
a point worth making.
> If it was a
> commercial product, it would have been clear from the outset that in
> order to sell product it would have to do *all* of the things
> commercial web servers do *at least as well* and also do its special
> cool stuff. Since its a volunteer project, all of the little bells and
> whistles may not be there, but I assert that this is only until
> someone puts them in.
Exactly. This may well be the kind of "limitation" that the subject of
this thread is asking about. In this case, it's a specific app, but if
that app is used to show how well Lisp can do things, then it may well
be relevant here. It's really a strength, but if it appears to be a
limitation to some people, then that's what'll be - for them.
We can just shrug our shoulders and ignore this, and that's the
easiest way to deal with it. I'm not sure it's a constructive answer,
but in the context of this thread, only Hasita Shah can know that.
> Its always hard to say what the limitations of a certain language
> is. Especially when the people you are talking about are thinking more
> about the particular implementations out there than the language
> itself. If I look only at MSVC++ I would say that C++ is hard to
> optimize but the Watcom C++ compiler and the DEC C++ complier show this
> to be untrue.
Object code quality is only one way of measure a compiler's value.
Just like with Lisp, really. One of Lisp's great strength's is the
quality of Lisp environments. However, in CL a significant part of the
environment is defined by the language, while this is not always the
case in other languages.
The tools that come with a language implementation add value to it.
> This started out as a discussion on the limitations of Lisp but then
> you wanted to explore how to get more people using Lisp.
No. I'm thinking specifically of Hasita Shah, who started this thread.
With so little information about an individual's requirements, it's
hard to say how well Lisp can help them. We can give some examples of
how Lisp can do useful things, and CL-HTTP can do this nicely. It has
the advantage of having a familiar and easily appreciated purpose.
It also makes it easily to compare with non-Lisp solutions, to see how
a Lisp solution can do things differently.
> When I think
> only about the question about the limitations of Lisp, I look at CLOS
> the condition system, and how extensible the language is and I see
> that the only limitations are in our heads. It just depends on what
> one wants out of a language. The languages that are interesting to me
> at this point in my life are Lisp, SML, and Modula-3. Meanwhile I earn
> a living programming in C++ and Java. Go Figure.
I'm in a similar position, except that my prefered languages would be
Lisp, O'Caml, and Haskell. At least, these are the languages I use for
my own projects. Like you, I get paid to use C++ and Java.
Will this be of some help to a student? I expect so. There are many
students who learn Lisp, even if they later get a job using something
else. This is not uncommon. Plus, you can learn programming in Lisp
that can help you when using other languages. My style of C coding
uses small functions, which I'm sure comes from using Forth and Lisp.
> > In other words, people are the problem. ;)
>
> Actually this is not a very precise question. It all depends on what
> one wants to do, which is why the discussion fell off of the beaten
> path. At zeroth level there is nothing that you can do in other
> languages that you cannot do in Lisp. Lisp has ran on huge machines,
> tiny embedded controllers and everything in between. So the question
> that this person could be asking is why should they use Lisp instead
> of some other language. I cannot answer this for them, I can only say
> why I like Lisp. And since Lisp is a family of languages you should
> probably say which Lisp you have in mind when you are talking about
> things. The one I like the most is ANSI Common Lisp. So when I say
> Lisp, this is the Lisp I mean.
Agreed. This is why I like the phrase, "Your Mileage May Vary" so
much. I frequently see that it does. We need more details about a
person's requirements if we wish to discuss a specific option. I find
that my own requirements can vary. Some things I find easier to do in
CL, others in Scheme, and so on. A lot of this depends on the tools
available how well their features match my requirements for that
project.
> Software Engineering, while trying to be as precise a discipline as say
> Civil Engineering, is currently more art than engineering. So I use
> the programming language as a form of expression, trying to map the
> abstract ideas in my head into instructions for the machine. Lisp
> seems to provide me with the greatest range of expression, allowing
> one to try out things and have the correct solution evolve instead of
> having to work out lots of details up front. I like tools that let me
> work the way I want and does not force me into their way of
> working. Lisp seems to be that tool. The languages that we now use
> like C, C++, and Java, force me to do a lot of up-front thinking about
> low level details of the problem which I wont really understand until
> I have worked out possible solutions, when I have possible solutions
> *then* I will know which data structures and such I can use. Its
> easier to work out generalized frameworks to sit your solution on in
> Lisp. I think this is because generic functions which have multiple
> dispatch allow more expression than the other single dispatch OO
> languages.In C++ the STL allows a bit of this kind of power, but look
> at the infrastructure they had to construct to do it. *Sheesh*
I'm very cautious about using any C++ features. I feel like I'm
building a house on loose sand. Lisp is much more stable, but the slow
rate of change can also be a kind of disadvantage. This is why some
people use the latest C++ tools. The language may such farts from dead
cats, but when you can guantee support for the latest OS features,
and time is painfully short, the options available might not be ideal.
Lisp is a better long term bet. Java is a good midrange bet. C++? Hmm.
Short term and highly over-rated IMHO. Alas, short term is what many
people are satisfied with. Fortunately, this may be irrelevant to a
student wishing to learn a good programming language. You can choose
Lisp and have a powerful too for life.
The software you write in Lisp should still have a life many (10? 20?
30?) years from now. I wouldn't say the same thing for C++ code. Some
C++ code may survive 20 years, but by then it'll be a very "dusty
deck". C++ code will be more dusty than any Common Lisp code, I bet. I
have C++ code from just few years ago that is already dusty, because
the language has changed dramatically! This has been a problem with C
compilers since I first started using the language, back in the early
80s. Each time I change to a different compiler, the language changed.
Then ANSI C appeared, and things might have improved, and if you can
code in pure ANSI C, maybe they have. Choose C++ and history repeats
itself, only with more pain. Consider:
"C makes it easy to shoot yourself in the foot. C++ makes it
harder, but when you do, it blows away your whole leg."
-- Bjarne Stroustrup on C++
I don't doubt it. By contrast, I feel that using Lisp is like falling
on a floor of big cushions. It's very soft, I can roll around and have
fun, and do useful things without getting hurt.
> Now I feel that I haven't even scratched the surface of what I can do
> with the environment. It takes some time to actually get comfortable
> with being able to do pretty much what I want instead of changing what
> I want so that it will compile in the language of the day. So having
> while Lisp on your resume is not a sure-fire way to get a job, I would
> say that the way that I now think about attacking problems is a result
> of exposure to Lisp and I believe that as I gain mastery of Lisp and
> being able to take advantage of its idioms, I will become a better
> programmer.
This is my experience, too. There's a slow learning curve, but it's
comfortable, and once you get going there's a stream of pleasant
suprises. Unlike some other languages, which will initially look very
attractive (partly coz so many other people are using them), and then
one day you begin to experience a series of painful suprises.
No wonder there C++ folk who compare their chosen language to using a
sharp knife. We, however, might compare Lisp to a sharp knife with a
_handle_ which will help us avoid a lot unnecessary cuts.
> Now does this answer the question? I would bet not.
Perhaps Hasita Shah could answer that one? I don't know.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Francois-Rene Rideau
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <xgm90ukhilt.fsf@chaland.ens.fr>
In article <···············@yakko.zso.dec.com> ·····@yakko.zso.dec.com (Reginald S. Perry) writes:
········@visi.com (David Thornley) writes:
> Face it, guys, the capitalist system is very inefficient about rewarding
> excellence; it's usually better at rewarding mediocrity. For most
> companies, the computer systems are not the heart of the business, and
> making them superbly efficient is unlikely to help the business nearly
> as much as making the wrong choice is likely to hurt it. It's
> expensive to make changes, and the upside is likely to be streamlining
> a medium-sized chunk of their staff work. It's a matter of optimization.
> It may not be worth it.
I am not sure about the validity of what you imply above. I look at
this problem as being largely customer driven. If cars or bridges were
as poorly designed as some commercial software that I have on this PC
next to me, lawyers would be in lawsuit heaven. As it is, as long as
the customers accept crap, and spend their good money on crap, they
will be sold that crap at the highest price they are willing to pay,
delivered to them via the six-pack of crappy programmers that the
manager picked up at the local programmers store.
I think this is starting to change as consumer software becomes more
demanding and the price point for decent hardware remains the
same. People start to notice that they are spending hard earned money
on crap.
Well, the problem is that mass-communication, advertisement, etc,
are currently producer-driven, not consumer-driven at all. Hence,
we do NOT have a fair market that'd allow liberalistic economy to
work well. Consequently, what consumers purchase is crap and will
stay so according to all non-obvious criteria. If you want things
to improve, you should help appear consumer-driven communication,
and its consequence, consumer-controlled market. [This reminds me
of articles by Bastiat, written in 1850, about the egoistic inte-
rest of producers leading to ruin, while those of consumers leads
to prosperity]. I don't see a consumer-driven economy appearing
any time soon, but still I hope it's possible, and will try to
make it happen sooner by convincing people of its necessity.
Regards,
== Far� -=- (FR) Fran�ois-Ren� Rideau -=- (VN) Уng-V� B�n -=- ······@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System. | 75019 PARIS FRANCE
http://www.eleves.ens.fr:8080/home/rideau/Tunes/ -=- Reflection&Cybernethics ==
[crossposted to comp.lang.ml: we need a good flamewar]
In article <············@darla.visi.com>,
········@visi.com (David Thornley) paraphrased Him:
DT> Dijkstra claimed that languages like Basic warp programmers, but
DT> it seems to me that the whole Fortran/Basic/Pascal/Modula/C/C++/Java
DT> family (apologies to languages left out) warps programmers. They
DT> start to see everything in terms of a procedural language with
DT> static typing.
Symmetrically, we Lisp programmers get our vision of things warped by
using a dynamically typed language.
Some time ago, I was speaking with a die-hard ML programmer (this is
Edinburgh, after all). After a while, he asked me:
`Do you really feel your programming style is cramped by ML's strong
typing? I mean, do you often write a function that couldn't be
typed in ML?'
I started to give an example about a searching function which returns
a string on success and NIL on failure.
`I'd just raise an exception on failure!' (that's ML-speak for
throwing out of a scope)
I then realised that because ML is strongly typed, ML programmers are
likely to use techniques that we don't need in Lisp. And, sure
enough, looking back at the code I wrote back in my ML days, it is
full of exception catching. While my last 3000 lines of Lisp have
three catch forms (plus a few error handlers, but I think that's a
different issue).
I don't know which way is right. C's way of always returning a value,
even on error, is definitely wrong. But what should be done in an
exceptional situation which is not an error? Lisp often chooses to
return NIL (or some other distinguished value), while ML raises an
exception. But the point is that I would not have become aware of
this choice had I not learnt a modern strongly typed language (ML).
(Similarly, one might argue that the purely functional nature of
Haskell led Wadler to use Moggi's ideas about monads, which would
never have been used in programming otherwise.)
DT> Face it, guys, the capitalist system is very inefficient about
DT> rewarding excellence; it's usually better at rewarding mediocrity.
Right. And C and C++ programmers will be the first against the wall
when the Revolution comes. (A ghost is haunting Europe, the ghost of
Dynamic Typing.)
Sincerely yours,
J. Chroboczek
Juliusz Chroboczek <···@dcs.ed.ac.uk> writes:
>
> [crossposted to comp.lang.ml: we need a good flamewar]
>
> In article <············@darla.visi.com>,
> ········@visi.com (David Thornley) paraphrased Him:
>
> DT> Face it, guys, the capitalist system is very inefficient about
> DT> rewarding excellence; it's usually better at rewarding mediocrity.
>
> Right. And C and C++ programmers will be the first against the wall
> when the Revolution comes. (A ghost is haunting Europe, the ghost of
> Dynamic Typing.)
>
Hey! We even have the right name for our language "Common Lisp"
(commonlisp, communlisp ...) and a "Stalin" compiler for Scheme :)
--
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
* Juliusz Chroboczek wrote:
> I don't know which way is right. C's way of always returning a value,
> even on error, is definitely wrong. But what should be done in an
> exceptional situation which is not an error? Lisp often chooses to
> return NIL (or some other distinguished value), while ML raises an
> exception. But the point is that I would not have become aware of
> this choice had I not learnt a modern strongly typed language (ML).
> (Similarly, one might argue that the purely functional nature of
> Haskell led Wadler to use Moggi's ideas about monads, which would
> never have been used in programming otherwise.)
I'd add to that the technique of returning multiple values --
typically one being the answer, and another being a success flag.
That way you can remain strongly-typed but still indicate failure
succinctly. I do this a lot, though I'm not sure where I get it from
other than finding CL's condition system a bit hairy.
--tim
Juliusz Chroboczek wrote in message
<············@goldenapple.srv.cs.cmu.edu>...
>I started to give an example about a searching function which returns
>a string on success and NIL on failure.
>
> `I'd just raise an exception on failure!' (that's ML-speak for
> throwing out of a scope)
Funny, I'd just return a 'string option'. That way, it's either
NONE or SOME x. Simple, no exceptions required. :-)
I tend to agree that exceptions can be overused, fwiw.
>Right. And C and C++ programmers will be the first against the wall
>when the Revolution comes. (A ghost is haunting Europe, the ghost of
>Dynamic Typing.)
Hey! I program in ML too! :-)
Dan Higdon (····@charybdis.com)
In article <············@goldenapple.srv.cs.cmu.edu> Juliusz Chroboczek <···@dcs.ed.ac.uk> writes:
[ a moderately lengthy discussion of how different programming styles
handle cases where a function cannot return a "normal" result;
claiming that ML programmers would usually use exceptions for this
purpose ]
There are (at least) two ways of doing this in ML. If the condition
is more like an "error" (and probably rare) then I would prefer
exceptions. A typical example would be division, where division by 0
is the exceptional case. I personally use exceptions very little.
In situations where the "out of band" value is more frequent I would
have the function return an "option" type. The nice thing about this
is that the ML type checker will force the user of the function to
handle the special case. As a programmer, one cannot easily forget
about it. A typical example where options are useful would be a table
lookup (e.g., a compiler's symbol table).
The drawback of C's (and Lisp's) habit of returning an "impossible"
value is that it is not always obvious what the impossible value
should be. In the typed world of C, the return type of getchar was
artificially widened to include *many* impossible values just so we
can have it return -1 as well as all possible unsigned character
values. In the untyped world of Lisp, it is often the case that there
is no "impossible" return value, in which case the technique of
returning one breaks down. (ML's type system can always make up a
bigger type that can encode every "possible" value plus any number of
additional "impossible" ones.)
The only good way of doing things right in Lisp would be to resort to
passing multiple continuations explicitly. Of course, this avenue is
also open in ML (but less so in C because of its lack of higher-order
functions).
--
-Matthias
Matthias Blume wrote:
>
> In article <············@goldenapple.srv.cs.cmu.edu> Juliusz Chroboczek <···@dcs.ed.ac.uk> writes:
>
> [ a moderately lengthy discussion of how different programming styles
> handle cases where a function cannot return a "normal" result;
> claiming that ML programmers would usually use exceptions for this
> purpose ]
>
[snip]
>
> In situations where the "out of band" value is more frequent I would
> have the function return an "option" type.
As several mail respondents noted, I wa sunaware of the 'option' option.
:)
Still sounds like unnecessary work just to say "nothing found"; now I am
unwrapping an option instead of trapping an exception. Strong-typing
(with all its advantages) is still contorting my code.
>
> The drawback of C's (and Lisp's) habit of returning an "impossible"
> value is that it is not always obvious what the impossible value
> should be.
True, but in the case of "search", I do not see "nothing" as an
impossible result.
> In the untyped world of Lisp, it is often the case that there
> is no "impossible" return value, in which case the technique of
> returning one breaks down.
True. Then Lispers have to return multiple values.
-- Ken
Ken Tilton <····@bway.net> writes:
> As several mail respondents noted, I wa sunaware of the 'option' option.
> :)
>
> Still sounds like unnecessary work just to say "nothing found"; now I am
> unwrapping an option instead of trapping an exception. Strong-typing
> (with all its advantages) is still contorting my code.
No, strong typing is just forcing you to do what you should always do-- namely
check to see whether the operation succeeded.
How many times in C do you forget to check the result of your mallc
if (p = malloc(...)) { ....} ?
<pardon my poor C>
The type system merely checks that you've done this before using the result.
If you don't want to check it immediately, you can pass the result around and
check it when needed.
--Mitch
Mitchell Wand Internet: ····@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
From: John Penix <······@mingus.ececs.uc.edu>
Newsgroups: comp.lang.ml
Subject: measuring execution time
Organization: University of Cincinnati, ECE/CS News Server
Distribution: world
Path: not-for-mail
Reply-To: John Penix <······@mingus.ececs.uc.edu>
Approved: ············@cs.cmu.edu
hi, sorry to post this, but all of our ml books (except the crappy one
I have) are checked out of the library..
is there support for measuring execution time of ML programs?
thanks much,
John
--
John Penix University of Cincinnati ECECS
······@ececs.uc.edu Knowledge-Based Software Engineering Lab
<a http://www.ececs.uc.edu/~jpenix/>I</a>
"I am, I exist, that is certain. But how often?" - Descartes
From: Xavier Leroy <············@see.my.sig.for.address>
Newsgroups: comp.lang.ml
Subject: Re: static typing considered harmful
Organization: INRIA Rocquencourt, projet Cristal
Distribution: world
Path: usenet
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
Sender: ······@cadet.inria.fr
Reply-To: Xavier Leroy <············@see.my.sig.for.address>
Approved: ············@cs.cmu.edu
"Bruce J. McAdam" <···@dcs.ed.ac.uk> writes:
> This morning, Stefan Kahrs gave a talk, `When Types Get in the Way', to
> the ML-Club here in Edinburgh. This was largely a collection of
> examples showing situations when the type system becomes a nuisance in
> some way or another.
I had a look at the slides, and the examples show situations where the
*ML* type system goes in the way, but richer type systems
(e.g. with some amount of polymorphic recursion) would work fine.
So, it seems to me that the conclusions of this talk are more along
the lines of "we need better type systems" rather than "let's get rid
of static typing altogether".
- Xavier Leroy
--
Valid e-mail address (without the underscores): ············@i_n_r_i_a.f_r
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Marco Antoniotti <·······@infiniti.path.berkeley.edu> writes:
>David Hanley <·····@netright.com.delete.me.silly> writes:
>
>> ML has multiple return value as well:
>>
>> (value,flag)=search(table,key);
>>
>> Will initlaize both values in ML.
>
>Technically (and AFAIK) ML does not have multiple values in the sense
>of Common Lisp.
In which technical sense do you mean?
>The CL MVs are crafted in such a way to enable compilers and
>interpreters to allocate the values on the stack. I don't think (if
>memory does not fail me) that ML has constructs for doing exactly the
>same.
It is certainly possible for ML compilers to allocate multiple return
values on the stack, or even better to return them in registers.
(Whether or not existing ML implementations do so is a different question.
But if you're worried about efficiency, I suspect that if you look at the
big picture, then a statically typed language like ML is likely to be more
efficient than a dynamically typed language like Lisp.)
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Ken Tilton <····@bway.net> writes:
>As several mail respondents noted, I wa sunaware of the 'option' option.
>:)
>
>Still sounds like unnecessary work just to say "nothing found"; now I am
>unwrapping an option instead of trapping an exception. Strong-typing
>(with all its advantages) is still contorting my code.
In lisp, you would still need to check that the result was not null.
Why is unwrapping an option any worse? As I see it,
the only significant difference is that if you forget this step,
then in ML you get a type error at compile time, whereas in Lisp if you
forget to check that the result wasn't null then you will get a runtime error.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: Erik Naggum <······@naggum.no>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: Erik Naggum <······@naggum.no>
Approved: ············@cs.cmu.edu
* David Hanley
| I don't see how this is due to static typing. How exactly are you going
| to do this in lisp without exceptions, multiple return values, or
| multiple return types?
multiple return types? there's never more than one type (of each returned
value, that is). remember that Lisp has a type hierarchy, quite unlike
most statically typed languages. every type is a subtype of type t.
if all types and values are conceptually possible success values from a
function, any freshly consed object passed by the caller to the function
can be returned on failure, and is guaranteed not to be confused with a
success value. e.g., `read' can return _anything_, yet there is a need for
a guaranteed unique value to mean "end of file":
(let* ((eof (cons nil nil))
(object (read stream nil eof)))
(if (eq object eof)
(iff-eof)
(iff-real-object)))
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
* David Hanley
| I don't see how this is due to static typing. How exactly are you going
| to do this in lisp without exceptions, multiple return values, or
| multiple return types?
multiple return types? there's never more than one type (of each returned
value, that is). remember that Lisp has a type hierarchy, quite unlike
most statically typed languages. every type is a subtype of type t.
if all types and values are conceptually possible success values from a
function, any freshly consed object passed by the caller to the function
can be returned on failure, and is guaranteed not to be confused with a
success value. e.g., `read' can return _anything_, yet there is a need for
a guaranteed unique value to mean "end of file":
(let* ((eof (cons nil nil))
(object (read stream nil eof)))
(if (eq object eof)
(iff-eof)
(iff-real-object)))
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
[snipping stuff we all know]
(let* ((eof (cons nil nil))
> (object (read stream nil eof)))
> (if (eq object eof)
> (iff-eof)
> (iff-real-object)))
That's true, and one of the things wrong with ML, IMHO--
that equality of objects by default does and element by element
comparinon, traversing pointers, etc. Of course, you can do that
in lisp, but you don't always want to.
dave
David Hanley <·····@netright.com.delete.me.silly> writes:
> [snipping stuff we all know]
>
> That's true, and one of the things wrong with ML, IMHO--
> that equality of objects by default does and element by element
> comparinon, traversing pointers, etc. Of course, you can do that
> in lisp, but you don't always want to.
>
Of course there are ways that you can get the ML type system to complain if
you don't use the right user defined equality function. So you can fix this
in ML. I don't know if you can in LISP or not.
Marco Antoniotti wrote:
> David Hanley <·····@netright.com.delete.me.silly> writes:
>
> >
> >
> >
> > Ken Tilton wrote:
> >
> ...
> >
> > I don't see how this is due to static typing. How exactly are you
> > going to do this in lisp without exceptions, multiple return values,
> > or multiple return types? ML has multiple return value as well:
> >
> > (value,flag)=search(table,key);
> >
> > Will initlaize both values in ML.
>
> Technically (and AFAIK) ML does not have multiple values in the sense
> of Common Lisp.
In the purest sense, yes, it return a single value, which is a tuple.As a
practical programming issue, it doesn't make much difference.
> The CL MVs are crafted in such a way to enable compilers and
> interpreters to allocate the values on the stack. I don't think (if
> memory does not fail me) that ML has constructs for doing exactly the
> same. (Even if the idiom you posted achieves pretty much the same
> effect).
I beleive this is unspecified. I could certianly concieve of an MLcompiler
using the stack for multiple return values. In fact, because
the types are typically known, the calling function could allocate
the tuple on the stack and pass it to the multiple-return-function,
which would then fill in the tuple.
dave
From: Mitchell Wand <····@ccs.neu.edu>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Northeastern University, College of Computer Science
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
Reply-To: Mitchell Wand <····@ccs.neu.edu>
Approved: ············@cs.cmu.edu
Ken Tilton <····@bway.net> writes:
> As several mail respondents noted, I wa sunaware of the 'option' option.
> :)
>
> Still sounds like unnecessary work just to say "nothing found"; now I am
> unwrapping an option instead of trapping an exception. Strong-typing
> (with all its advantages) is still contorting my code.
No, strong typing is just forcing you to do what you should always do-- namely
check to see whether the operation succeeded.
How many times in C do you forget to check the result of your mallc
if (p = malloc(...)) { ....} ?
<pardon my poor C>
The type system merely checks that you've done this before using the result.
If you don't want to check it immediately, you can pass the result around and
check it when needed.
--Mitch
Mitchell Wand Internet: ····@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
From: John Penix <······@mingus.ececs.uc.edu>
Newsgroups: comp.lang.ml
Subject: measuring execution time
Organization: University of Cincinnati, ECE/CS News Server
Distribution: world
Path: not-for-mail
Reply-To: John Penix <······@mingus.ececs.uc.edu>
Approved: ············@cs.cmu.edu
hi, sorry to post this, but all of our ml books (except the crappy one
I have) are checked out of the library..
is there support for measuring execution time of ML programs?
thanks much,
John
--
John Penix University of Cincinnati ECECS
······@ececs.uc.edu Knowledge-Based Software Engineering Lab
<a http://www.ececs.uc.edu/~jpenix/>I</a>
"I am, I exist, that is certain. But how often?" - Descartes
From: Xavier Leroy <············@see.my.sig.for.address>
Newsgroups: comp.lang.ml
Subject: Re: static typing considered harmful
Organization: INRIA Rocquencourt, projet Cristal
Distribution: world
Path: usenet
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
Sender: ······@cadet.inria.fr
Reply-To: Xavier Leroy <············@see.my.sig.for.address>
Approved: ············@cs.cmu.edu
"Bruce J. McAdam" <···@dcs.ed.ac.uk> writes:
> This morning, Stefan Kahrs gave a talk, `When Types Get in the Way', to
> the ML-Club here in Edinburgh. This was largely a collection of
> examples showing situations when the type system becomes a nuisance in
> some way or another.
I had a look at the slides, and the examples show situations where the
*ML* type system goes in the way, but richer type systems
(e.g. with some amount of polymorphic recursion) would work fine.
So, it seems to me that the conclusions of this talk are more along
the lines of "we need better type systems" rather than "let's get rid
of static typing altogether".
- Xavier Leroy
--
Valid e-mail address (without the underscores): ············@i_n_r_i_a.f_r
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Marco Antoniotti <·······@infiniti.path.berkeley.edu> writes:
>David Hanley <·····@netright.com.delete.me.silly> writes:
>
>> ML has multiple return value as well:
>>
>> (value,flag)=search(table,key);
>>
>> Will initlaize both values in ML.
>
>Technically (and AFAIK) ML does not have multiple values in the sense
>of Common Lisp.
In which technical sense do you mean?
>The CL MVs are crafted in such a way to enable compilers and
>interpreters to allocate the values on the stack. I don't think (if
>memory does not fail me) that ML has constructs for doing exactly the
>same.
It is certainly possible for ML compilers to allocate multiple return
values on the stack, or even better to return them in registers.
(Whether or not existing ML implementations do so is a different question.
But if you're worried about efficiency, I suspect that if you look at the
big picture, then a statically typed language like ML is likely to be more
efficient than a dynamically typed language like Lisp.)
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Ken Tilton <····@bway.net> writes:
>As several mail respondents noted, I wa sunaware of the 'option' option.
>:)
>
>Still sounds like unnecessary work just to say "nothing found"; now I am
>unwrapping an option instead of trapping an exception. Strong-typing
>(with all its advantages) is still contorting my code.
In lisp, you would still need to check that the result was not null.
Why is unwrapping an option any worse? As I see it,
the only significant difference is that if you forget this step,
then in ML you get a type error at compile time, whereas in Lisp if you
forget to check that the result wasn't null then you will get a runtime error.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: Erik Naggum <······@naggum.no>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: Erik Naggum <······@naggum.no>
Approved: ············@cs.cmu.edu
* David Hanley
| I don't see how this is due to static typing. How exactly are you going
| to do this in lisp without exceptions, multiple return values, or
| multiple return types?
multiple return types? there's never more than one type (of each returned
value, that is). remember that Lisp has a type hierarchy, quite unlike
most statically typed languages. every type is a subtype of type t.
if all types and values are conceptually possible success values from a
function, any freshly consed object passed by the caller to the function
can be returned on failure, and is guaranteed not to be confused with a
success value. e.g., `read' can return _anything_, yet there is a need for
a guaranteed unique value to mean "end of file":
(let* ((eof (cons nil nil))
(object (read stream nil eof)))
(if (eq object eof)
(iff-eof)
(iff-real-object)))
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
Marco Antoniotti <·······@infiniti.path.berkeley.edu> writes:
>David Hanley <·····@netright.com.delete.me.silly> writes:
>
>> ML has multiple return value as well:
>>
>> (value,flag)=search(table,key);
>>
>> Will initlaize both values in ML.
>
>Technically (and AFAIK) ML does not have multiple values in the sense
>of Common Lisp.
In which technical sense do you mean?
>The CL MVs are crafted in such a way to enable compilers and
>interpreters to allocate the values on the stack. I don't think (if
>memory does not fail me) that ML has constructs for doing exactly the
>same.
It is certainly possible for ML compilers to allocate multiple return
values on the stack, or even better to return them in registers.
(Whether or not existing ML implementations do so is a different question.
But if you're worried about efficiency, I suspect that if you look at the
big picture, then a statically typed language like ML is likely to be more
efficient than a dynamically typed language like Lisp.)
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Ken Tilton <····@bway.net> writes:
>As several mail respondents noted, I wa sunaware of the 'option' option.
>:)
>
>Still sounds like unnecessary work just to say "nothing found"; now I am
>unwrapping an option instead of trapping an exception. Strong-typing
>(with all its advantages) is still contorting my code.
In lisp, you would still need to check that the result was not null.
Why is unwrapping an option any worse? As I see it,
the only significant difference is that if you forget this step,
then in ML you get a type error at compile time, whereas in Lisp if you
forget to check that the result wasn't null then you will get a runtime error.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: Erik Naggum <······@naggum.no>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: Erik Naggum <······@naggum.no>
Approved: ············@cs.cmu.edu
* David Hanley
| I don't see how this is due to static typing. How exactly are you going
| to do this in lisp without exceptions, multiple return values, or
| multiple return types?
multiple return types? there's never more than one type (of each returned
value, that is). remember that Lisp has a type hierarchy, quite unlike
most statically typed languages. every type is a subtype of type t.
if all types and values are conceptually possible success values from a
function, any freshly consed object passed by the caller to the function
can be returned on failure, and is guaranteed not to be confused with a
success value. e.g., `read' can return _anything_, yet there is a need for
a guaranteed unique value to mean "end of file":
(let* ((eof (cons nil nil))
(object (read stream nil eof)))
(if (eq object eof)
(iff-eof)
(iff-real-object)))
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
Ken Tilton <····@bway.net> writes:
>As several mail respondents noted, I wa sunaware of the 'option' option.
>:)
>
>Still sounds like unnecessary work just to say "nothing found"; now I am
>unwrapping an option instead of trapping an exception. Strong-typing
>(with all its advantages) is still contorting my code.
In lisp, you would still need to check that the result was not null.
Why is unwrapping an option any worse? As I see it,
the only significant difference is that if you forget this step,
then in ML you get a type error at compile time, whereas in Lisp if you
forget to check that the result wasn't null then you will get a runtime error.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: Erik Naggum <······@naggum.no>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: Erik Naggum <······@naggum.no>
Approved: ············@cs.cmu.edu
* David Hanley
| I don't see how this is due to static typing. How exactly are you going
| to do this in lisp without exceptions, multiple return values, or
| multiple return types?
multiple return types? there's never more than one type (of each returned
value, that is). remember that Lisp has a type hierarchy, quite unlike
most statically typed languages. every type is a subtype of type t.
if all types and values are conceptually possible success values from a
function, any freshly consed object passed by the caller to the function
can be returned on failure, and is guaranteed not to be confused with a
success value. e.g., `read' can return _anything_, yet there is a need for
a guaranteed unique value to mean "end of file":
(let* ((eof (cons nil nil))
(object (read stream nil eof)))
(if (eq object eof)
(iff-eof)
(iff-real-object)))
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
> [ a moderately lengthy discussion of how different programming styles
> handle cases where a function cannot return a "normal" result;
> claiming that ML programmers would usually use exceptions for this
> purpose ]
No one seems to have mentioned continuation passing style.
From: David Hanley <·····@netright.com.delete.me.silly>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: netright Technologies
Distribution: world
Path: usenet
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ·····@netright.com.delete.me.silly
Approved: ············@cs.cmu.edu
Marco Antoniotti wrote:
> David Hanley <·····@netright.com.delete.me.silly> writes:
>
> >
> >
> >
> > Ken Tilton wrote:
> >
> ...
> >
> > I don't see how this is due to static typing. How exactly are you
> > going to do this in lisp without exceptions, multiple return values,
> > or multiple return types? ML has multiple return value as well:
> >
> > (value,flag)=search(table,key);
> >
> > Will initlaize both values in ML.
>
> Technically (and AFAIK) ML does not have multiple values in the sense
> of Common Lisp.
In the purest sense, yes, it return a single value, which is a tuple.As a
practical programming issue, it doesn't make much difference.
> The CL MVs are crafted in such a way to enable compilers and
> interpreters to allocate the values on the stack. I don't think (if
> memory does not fail me) that ML has constructs for doing exactly the
> same. (Even if the idiom you posted achieves pretty much the same
> effect).
I beleive this is unspecified. I could certianly concieve of an MLcompiler
using the stack for multiple return values. In fact, because
the types are typically known, the calling function could allocate
the tuple on the stack and pass it to the multiple-return-function,
which would then fill in the tuple.
dave
From: Mitchell Wand <····@ccs.neu.edu>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Northeastern University, College of Computer Science
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
Reply-To: Mitchell Wand <····@ccs.neu.edu>
Approved: ············@cs.cmu.edu
Ken Tilton <····@bway.net> writes:
> As several mail respondents noted, I wa sunaware of the 'option' option.
> :)
>
> Still sounds like unnecessary work just to say "nothing found"; now I am
> unwrapping an option instead of trapping an exception. Strong-typing
> (with all its advantages) is still contorting my code.
No, strong typing is just forcing you to do what you should always do-- namely
check to see whether the operation succeeded.
How many times in C do you forget to check the result of your mallc
if (p = malloc(...)) { ....} ?
<pardon my poor C>
The type system merely checks that you've done this before using the result.
If you don't want to check it immediately, you can pass the result around and
check it when needed.
--Mitch
Mitchell Wand Internet: ····@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
From: John Penix <······@mingus.ececs.uc.edu>
Newsgroups: comp.lang.ml
Subject: measuring execution time
Organization: University of Cincinnati, ECE/CS News Server
Distribution: world
Path: not-for-mail
Reply-To: John Penix <······@mingus.ececs.uc.edu>
Approved: ············@cs.cmu.edu
hi, sorry to post this, but all of our ml books (except the crappy one
I have) are checked out of the library..
is there support for measuring execution time of ML programs?
thanks much,
John
--
John Penix University of Cincinnati ECECS
······@ececs.uc.edu Knowledge-Based Software Engineering Lab
<a http://www.ececs.uc.edu/~jpenix/>I</a>
"I am, I exist, that is certain. But how often?" - Descartes
From: Xavier Leroy <············@see.my.sig.for.address>
Newsgroups: comp.lang.ml
Subject: Re: static typing considered harmful
Organization: INRIA Rocquencourt, projet Cristal
Distribution: world
Path: usenet
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
Sender: ······@cadet.inria.fr
Reply-To: Xavier Leroy <············@see.my.sig.for.address>
Approved: ············@cs.cmu.edu
"Bruce J. McAdam" <···@dcs.ed.ac.uk> writes:
> This morning, Stefan Kahrs gave a talk, `When Types Get in the Way', to
> the ML-Club here in Edinburgh. This was largely a collection of
> examples showing situations when the type system becomes a nuisance in
> some way or another.
I had a look at the slides, and the examples show situations where the
*ML* type system goes in the way, but richer type systems
(e.g. with some amount of polymorphic recursion) would work fine.
So, it seems to me that the conclusions of this talk are more along
the lines of "we need better type systems" rather than "let's get rid
of static typing altogether".
- Xavier Leroy
--
Valid e-mail address (without the underscores): ············@i_n_r_i_a.f_r
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Marco Antoniotti <·······@infiniti.path.berkeley.edu> writes:
>David Hanley <·····@netright.com.delete.me.silly> writes:
>
>> ML has multiple return value as well:
>>
>> (value,flag)=search(table,key);
>>
>> Will initlaize both values in ML.
>
>Technically (and AFAIK) ML does not have multiple values in the sense
>of Common Lisp.
In which technical sense do you mean?
>The CL MVs are crafted in such a way to enable compilers and
>interpreters to allocate the values on the stack. I don't think (if
>memory does not fail me) that ML has constructs for doing exactly the
>same.
It is certainly possible for ML compilers to allocate multiple return
values on the stack, or even better to return them in registers.
(Whether or not existing ML implementations do so is a different question.
But if you're worried about efficiency, I suspect that if you look at the
big picture, then a statically typed language like ML is likely to be more
efficient than a dynamically typed language like Lisp.)
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Ken Tilton <····@bway.net> writes:
>As several mail respondents noted, I wa sunaware of the 'option' option.
>:)
>
>Still sounds like unnecessary work just to say "nothing found"; now I am
>unwrapping an option instead of trapping an exception. Strong-typing
>(with all its advantages) is still contorting my code.
In lisp, you would still need to check that the result was not null.
Why is unwrapping an option any worse? As I see it,
the only significant difference is that if you forget this step,
then in ML you get a type error at compile time, whereas in Lisp if you
forget to check that the result wasn't null then you will get a runtime error.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: Erik Naggum <······@naggum.no>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: Erik Naggum <······@naggum.no>
Approved: ············@cs.cmu.edu
* David Hanley
| I don't see how this is due to static typing. How exactly are you going
| to do this in lisp without exceptions, multiple return values, or
| multiple return types?
multiple return types? there's never more than one type (of each returned
value, that is). remember that Lisp has a type hierarchy, quite unlike
most statically typed languages. every type is a subtype of type t.
if all types and values are conceptually possible success values from a
function, any freshly consed object passed by the caller to the function
can be returned on failure, and is guaranteed not to be confused with a
success value. e.g., `read' can return _anything_, yet there is a need for
a guaranteed unique value to mean "end of file":
(let* ((eof (cons nil nil))
(object (read stream nil eof)))
(if (eq object eof)
(iff-eof)
(iff-real-object)))
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
On 21 Nov 1997, Emergent Technologies wrote:
>
> > [ a moderately lengthy discussion of how different programming styles
> > handle cases where a function cannot return a "normal" result;
> > claiming that ML programmers would usually use exceptions for this
> > purpose ]
>
> No one seems to have mentioned continuation passing style.
Also, Icon's failure semantics and goal directed evaluation deserve
mention here, as this kind of code seems to be exactly the motivation for
that langauge's peculiar control flow constructs.
-- Brian
From: ········@wiener.cs.uga.edu (Graham Matthews)
Newsgroups: comp.lang.ml
Subject: Re: static typing considered harmful
Organization: The University of Georgia
Distribution: world
Path: wiener!matthews
References: <············@trumpet.uni-mannheim.de> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ········@wiener.cs.uga.edu (Graham Matthews)
Approved: ············@cs.cmu.edu
"Bruce J. McAdam" <···@dcs.ed.ac.uk> writes:
: > This morning, Stefan Kahrs gave a talk, `When Types Get in the Way', to
: > the ML-Club here in Edinburgh. This was largely a collection of
: > examples showing situations when the type system becomes a nuisance in
: > some way or another.
Xavier Leroy (············@see.my.sig.for.address) wrote:
: I had a look at the slides, and the examples show situations where the
: *ML* type system goes in the way, but richer type systems
: (e.g. with some amount of polymorphic recursion) would work fine.
: So, it seems to me that the conclusions of this talk are more along
: the lines of "we need better type systems" rather than "let's get rid
: of static typing altogether".
On this topic: I was wondering if any of the major FP groups (NJ-SML,
Caml, the Haskell groups, the Clean group, etc) have any kind of
documentation describing where the type system of their language is
going, and when it is planned to get there? For example I hear rumours
of adding existential types to Caml, but is that going to happen, and
if so when? Likewise the Glasgow Haskell people appear to have got a
decent grant to extend Haskell's type system, but I don't know details
or deadlines. Why I am asking this question? Well apart from intellectual
curiosity, I am also wanting to review some functional languages as
implementation languages for a soon to start project -- hence I want
to know where these languages are going.
graham
From: Victor Winter <·······@sandia.gov>
Newsgroups: comp.lang.ml
Subject: fonts
Organization: Sandia National Laboratories
Distribution: world
Path: not-for-mail
Reply-To: Victor Winter <·······@sandia.gov>
Approved: ············@cs.cmu.edu
I want to print "hello world" to the screen and have the
text appear in blue (instead of black). How can I do this?
cheers,
Victor
--
---------------------------------------------------------------------
Victor L. Winter, Ph.D. Voice: (505) 284-2696
FAX: (505) 844-9478
High Integrity Software Systems Engineering
PO Box 5800, Department 2615,
Sandia National Laboratories,
Albuquerque, NM 87185-0535
---------------------------------------------------------------------
From: Emergent Technologies <········@cape.com>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: A poorly-installed InterNetNews site
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
Reply-To: Emergent Technologies <········@cape.com>
Approved: ············@cs.cmu.edu
> [ a moderately lengthy discussion of how different programming styles
> handle cases where a function cannot return a "normal" result;
> claiming that ML programmers would usually use exceptions for this
> purpose ]
No one seems to have mentioned continuation passing style.
From: David Hanley <·····@netright.com.delete.me.silly>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: netright Technologies
Distribution: world
Path: usenet
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ·····@netright.com.delete.me.silly
Approved: ············@cs.cmu.edu
Marco Antoniotti wrote:
> David Hanley <·····@netright.com.delete.me.silly> writes:
>
> >
> >
> >
> > Ken Tilton wrote:
> >
> ...
> >
> > I don't see how this is due to static typing. How exactly are you
> > going to do this in lisp without exceptions, multiple return values,
> > or multiple return types? ML has multiple return value as well:
> >
> > (value,flag)=search(table,key);
> >
> > Will initlaize both values in ML.
>
> Technically (and AFAIK) ML does not have multiple values in the sense
> of Common Lisp.
In the purest sense, yes, it return a single value, which is a tuple.As a
practical programming issue, it doesn't make much difference.
> The CL MVs are crafted in such a way to enable compilers and
> interpreters to allocate the values on the stack. I don't think (if
> memory does not fail me) that ML has constructs for doing exactly the
> same. (Even if the idiom you posted achieves pretty much the same
> effect).
I beleive this is unspecified. I could certianly concieve of an MLcompiler
using the stack for multiple return values. In fact, because
the types are typically known, the calling function could allocate
the tuple on the stack and pass it to the multiple-return-function,
which would then fill in the tuple.
dave
From: Mitchell Wand <····@ccs.neu.edu>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Northeastern University, College of Computer Science
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
Reply-To: Mitchell Wand <····@ccs.neu.edu>
Approved: ············@cs.cmu.edu
Ken Tilton <····@bway.net> writes:
> As several mail respondents noted, I wa sunaware of the 'option' option.
> :)
>
> Still sounds like unnecessary work just to say "nothing found"; now I am
> unwrapping an option instead of trapping an exception. Strong-typing
> (with all its advantages) is still contorting my code.
No, strong typing is just forcing you to do what you should always do-- namely
check to see whether the operation succeeded.
How many times in C do you forget to check the result of your mallc
if (p = malloc(...)) { ....} ?
<pardon my poor C>
The type system merely checks that you've done this before using the result.
If you don't want to check it immediately, you can pass the result around and
check it when needed.
--Mitch
Mitchell Wand Internet: ····@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
From: John Penix <······@mingus.ececs.uc.edu>
Newsgroups: comp.lang.ml
Subject: measuring execution time
Organization: University of Cincinnati, ECE/CS News Server
Distribution: world
Path: not-for-mail
Reply-To: John Penix <······@mingus.ececs.uc.edu>
Approved: ············@cs.cmu.edu
hi, sorry to post this, but all of our ml books (except the crappy one
I have) are checked out of the library..
is there support for measuring execution time of ML programs?
thanks much,
John
--
John Penix University of Cincinnati ECECS
······@ececs.uc.edu Knowledge-Based Software Engineering Lab
<a http://www.ececs.uc.edu/~jpenix/>I</a>
"I am, I exist, that is certain. But how often?" - Descartes
From: Xavier Leroy <············@see.my.sig.for.address>
Newsgroups: comp.lang.ml
Subject: Re: static typing considered harmful
Organization: INRIA Rocquencourt, projet Cristal
Distribution: world
Path: usenet
References: <············@trumpet.uni-mannheim.de>
<············@darla.visi.com>
<············@goldenapple.srv.cs.cmu.edu>
<············@goldenapple.srv.cs.cmu.edu>
Sender: ······@cadet.inria.fr
Reply-To: Xavier Leroy <············@see.my.sig.for.address>
Approved: ············@cs.cmu.edu
"Bruce J. McAdam" <···@dcs.ed.ac.uk> writes:
> This morning, Stefan Kahrs gave a talk, `When Types Get in the Way', to
> the ML-Club here in Edinburgh. This was largely a collection of
> examples showing situations when the type system becomes a nuisance in
> some way or another.
I had a look at the slides, and the examples show situations where the
*ML* type system goes in the way, but richer type systems
(e.g. with some amount of polymorphic recursion) would work fine.
So, it seems to me that the conclusions of this talk are more along
the lines of "we need better type systems" rather than "let's get rid
of static typing altogether".
- Xavier Leroy
--
Valid e-mail address (without the underscores): ············@i_n_r_i_a.f_r
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Marco Antoniotti <·······@infiniti.path.berkeley.edu> writes:
>David Hanley <·····@netright.com.delete.me.silly> writes:
>
>> ML has multiple return value as well:
>>
>> (value,flag)=search(table,key);
>>
>> Will initlaize both values in ML.
>
>Technically (and AFAIK) ML does not have multiple values in the sense
>of Common Lisp.
In which technical sense do you mean?
>The CL MVs are crafted in such a way to enable compilers and
>interpreters to allocate the values on the stack. I don't think (if
>memory does not fail me) that ML has constructs for doing exactly the
>same.
It is certainly possible for ML compilers to allocate multiple return
values on the stack, or even better to return them in registers.
(Whether or not existing ML implementations do so is a different question.
But if you're worried about efficiency, I suspect that if you look at the
big picture, then a statically typed language like ML is likely to be more
efficient than a dynamically typed language like Lisp.)
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: ············@cs.cmu.edu
Ken Tilton <····@bway.net> writes:
>As several mail respondents noted, I wa sunaware of the 'option' option.
>:)
>
>Still sounds like unnecessary work just to say "nothing found"; now I am
>unwrapping an option instead of trapping an exception. Strong-typing
>(with all its advantages) is still contorting my code.
In lisp, you would still need to check that the result was not null.
Why is unwrapping an option any worse? As I see it,
the only significant difference is that if you forget this step,
then in ML you get a type error at compile time, whereas in Lisp if you
forget to check that the result wasn't null then you will get a runtime error.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: Erik Naggum <······@naggum.no>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Distribution: world
Path: not-for-mail
References: <············@trumpet.uni-mannheim.de> <············@darla.visi.com> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu> <············@goldenapple.srv.cs.cmu.edu>
Reply-To: Erik Naggum <······@naggum.no>
Approved: ············@cs.cmu.edu
* David Hanley
| I don't see how this is due to static typing. How exactly are you going
| to do this in lisp without exceptions, multiple return values, or
| multiple return types?
multiple return types? there's never more than one type (of each returned
value, that is). remember that Lisp has a type hierarchy, quite unlike
most statically typed languages. every type is a subtype of type t.
if all types and values are conceptually possible success values from a
function, any freshly consed object passed by the caller to the function
can be returned on failure, and is guaranteed not to be confused with a
success value. e.g., `read' can return _anything_, yet there is a need for
a guaranteed unique value to mean "end of file":
(let* ((eof (cons nil nil))
(object (read stream nil eof)))
(if (eq object eof)
(iff-eof)
(iff-real-object)))
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
Brian Rogoff <···@shell5.ba.best.com> writes:
>On 21 Nov 1997, Emergent Technologies wrote:
>>
>> > [ a moderately lengthy discussion of how different programming styles
>> > handle cases where a function cannot return a "normal" result;
>> > claiming that ML programmers would usually use exceptions for this
>> > purpose ]
>>
>> No one seems to have mentioned continuation passing style.
>
>Also, Icon's failure semantics and goal directed evaluation deserve
>mention here, as this kind of code seems to be exactly the motivation for
>that langauge's peculiar control flow constructs.
Sorry, can't resist the opportunity for a plug ---
if you're looking for a modern, statically typed functional programming
language with support for Icon-style "failure semantics and goal
directed evaluation", try Mercury. See <http://www.cs.mu.oz.au/mercury>.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
In article <············@goldenapple.srv.cs.cmu.edu>, Juliusz Chroboczek
<···@dcs.ed.ac.uk> wrote:
> ...
>
> I started to give an example about a searching function which returns
> a string on success and NIL on failure.
>
> `I'd just raise an exception on failure!' (that's ML-speak for
> throwing out of a scope)
>
> ...
>
> I don't know which way is right. C's way of always returning a value,
> even on error, is definitely wrong. But what should be done in an
> exceptional situation which is not an error? Lisp often chooses to
> return NIL (or some other distinguished value), while ML raises an
> exception.
I think the usual way to do it in ML is to use the option type:
datatype 'a option = NONE | SOME of 'a
If your function should succesfully return a value x, then you
return SOME x instead, otherwise you return NONE. Of course, you
have to inspect the return value on the client side to get the
actual value x, eg, by pattern matching. Some might say this leads
to more complex programs. At least the programs get a bit longer
(though in some cases you can use short cuts); the good thing is
that the program text tells you rather clearly what is really
going on.
Martin
--
·····@fernuni-hagen.de
http://www.fernuni-hagen.de/inf/pi4/erwig/
Juliusz Chroboczek wrote:
>
> I started to give an example about a searching function which returns
> a string on success and NIL on failure.
>
> `I'd just raise an exception on failure!' (that's ML-speak for
> throwing out of a scope)
>
> I then realised that because ML is strongly typed, ML programmers are
> likely to use techniques that we don't need in Lisp. And, sure
> enough, looking back at the code I wrote back in my ML days, it is
> full of exception catching.
[...]
>
> I don't know which way is right. C's way of always returning a value,
> even on error, is definitely wrong. But what should be done in an
> exceptional situation which is not an error?
I vote for the Lisp way.
First, it /sounds/ perfectly reasonable that a function asked to search
for something in a collection matching some criteria should be able to
say "Nothing". That is not an exception, that is a reasonable and normal
result.
An exception would be something like searching for a customer with an
invalid customer number (it flunks some check-digit test). You /could/
just say "Nothing", but that is not completely forthcoming; better to
say "Invalid query" and then you /do/ want to raise an exception, not
attempt to convey the exception in the return value.
Can one /conceive/ of failed search as an exception, justifying ML's
approach? Sure. I once had to live with a library routine that treated
/successful/ search as an exception! The programmer's reasoning: if you
are adding something to a collection, and checking first to see if it
already exists, then successful search is bad. <sigh>
So ML can conceive of failed search as an exception, but it's wrong. <g>
It is what they are forced into by strong-typing.
The second thing telling me the Lisp way is right is--I have a theory:
When two approaches can both be made to work, you can still tell which
one is right. The wrong approach requires more contortions ("looking
back at the code I wrote back in my ML days, it is full of exception
catching"). The right approach (when blended in during on-going
development) usually lets me /take out/ contortions, simplifying my code
in ways unanticipated when I conceived the change. OK, OK, Occam got
there first. :)
-- Ken
Ken Tilton <····@bway.net> writes:
>
> Juliusz Chroboczek wrote:
> >
> > I started to give an example about a searching function which returns
> > a string on success and NIL on failure.
> >
> > `I'd just raise an exception on failure!' (that's ML-speak for
> > throwing out of a scope)
> >
> > I then realised that because ML is strongly typed, ML programmers are
> > likely to use techniques that we don't need in Lisp. And, sure
> > enough, looking back at the code I wrote back in my ML days, it is
> > full of exception catching.
There is no particular reason for this to be the case. My personal
belief is that exceptions are for exceptional circumstances.
> [...]
>
> >
> > I don't know which way is right. C's way of always returning a value,
> > even on error, is definitely wrong. But what should be done in an
> > exceptional situation which is not an error?
>
> I vote for the Lisp way.
>
> First, it /sounds/ perfectly reasonable that a function asked to search
> for something in a collection matching some criteria should be able to
> say "Nothing". That is not an exception, that is a reasonable and normal
> result.
And ML can do this. Instead of using a function
search : key * table -> value
use
search : key * table -> value option
> An exception would be something like searching for a customer with an
> invalid customer number (it flunks some check-digit test). You /could/
> just say "Nothing", but that is not completely forthcoming; better to
> say "Invalid query" and then you /do/ want to raise an exception, not
> attempt to convey the exception in the return value.
And ML can do this as well.
> Can one /conceive/ of failed search as an exception, justifying ML's
> approach? Sure. I once had to live with a library routine that treated
> /successful/ search as an exception! The programmer's reasoning: if you
> are adding something to a collection, and checking first to see if it
> already exists, then successful search is bad. <sigh>
This is not ML's approach, it is simply the approach of one particular
ML programmer. There is nothing to stop you providing several search
routines, each for a particular purpose, one of which might be the
above example.
> So ML can conceive of failed search as an exception, but it's wrong. <g>
Actually, it is you that is wrong here.
> It is what they are forced into by strong-typing.
And that is also incorrect.
> The second thing telling me the Lisp way is right is--I have a theory:
> When two approaches can both be made to work, you can still tell which
> one is right. The wrong approach requires more contortions ("looking
> back at the code I wrote back in my ML days, it is full of exception
> catching"). The right approach (when blended in during on-going
> development) usually lets me /take out/ contortions, simplifying my code
> in ways unanticipated when I conceived the change. OK, OK, Occam got
> there first. :)
I think you'll find ML is as capable of right ways and wrong ways as
Lisp.
--
Dr. Jon Thackray ····@harlequin.co.uk 44 1223 872522 (voice)
Harlequin Ltd. 44 1223 873873 (fax)
Barrington Hall
Barrington
Cambridge CB2 5RG
England
Juliusz Chroboczek <···@dcs.ed.ac.uk> writes:
> [crossposted to comp.lang.ml: we need a good flamewar]
>
I started to give an example about a searching function which returns
> a string on success and NIL on failure.
>
> `I'd just raise an exception on failure!' (that's ML-speak for
> throwing out of a scope)
>
> I then realised that because ML is strongly typed, ML programmers are
> likely to use techniques that we don't need in Lisp. And, sure
> enough, looking back at the code I wrote back in my ML days, it is
> full of exception catching. While my last 3000 lines of Lisp have
> three catch forms (plus a few error handlers, but I think that's a
> different issue).
>
As an ML hacker you really have two choices raise an execption or use the
option type. i.e.
- fun silly fail s =
if fail then NONE
else (SOME s)
val silly = fn : bool -> 'a -> 'a option
- silly true "string";
val it = NONE : string option
- silly false "string";
val it = SOME "string" : string option
- silly true 0;
val it = NONE : int option
- silly false 0;
val it = SOME 0 : int option
The type system will then force you to check and deal with all the
exceptional cases. You need not resort to handlers.