I notice that the word `lisp' doesn't appear anywhere in the release.
I guess it's a dirty word or something---dang, it has 4 letters.... :-(
If people don't want to sell lisp, why should we buy it from them?
-- Fred Gilham gilham @ csl . sri . com King Christ, this world is all aleak, / And life preservers there are none, And waves that only He may walk / Who dared to call Himself a man. -- e. e. cummings, from Jehovah Buried, Satan Dead
>I notice that the word `lisp' doesn't appear anywhere in the release.
Nor do C, C++, Java, Dylan, or any other language, for that matter. Why should they?
They did, however, mention a couple of applications in the Editors' Notes that run on Lisp.
>If people don't want to sell lisp, why should we buy it from them?
Harlequin is perfectly willing to sell their Lisp. If you don't believe me, call them.
Some might be disgruntled that Harlequin has laid off much of the staff they acquired from Lucid and Symbolics when those companies met financial trouble. But since when is any one company required to support an entire industry's personnel single-handedly?
-- Chuck -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please) chuck...@home.com (MIME enabled) Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
I presume this explains Pitman's layoff a few weeks ago, although it seems strange that there would be so much time between the layoff and the announcement of the reorganization. Were all the other Dylan and Lisp folks laid off as well?
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Don't bother cc'ing followups to me.
On Tue, 24 Nov 1998 08:49:01 GMT, Barry Margolin <bar...@bbnplanet.com> wrote: > In article <joswig-2311981627390...@194.163.195.67>, > Rainer Joswig <jos...@lavielle.com> wrote:
> I presume this explains Pitman's layoff a few weeks ago, although it seems > strange that there would be so much time between the layoff and the > announcement of the reorganization. Were all the other Dylan and Lisp > folks laid off as well?
ja...@harlequin.com (Jason Trenouth) writes: > On Tue, 24 Nov 1998 08:49:01 GMT, Barry Margolin <bar...@bbnplanet.com> wrote: > > Were all the other Dylan and Lisp folks laid off as well? > No. We're still here.
Not ever single person is gone, but I think it's misleading for Harlequin to suggest that there has not been a major "streamlining".
It is common knowledge that a lot of people (especially senior people) from the Lisp and Dylan groups, both development and support, as well as the Memory and Database group, and other areas, were let go.
In fact, my understandng is that the Lisp and Dylan groups no longer exist, and that the remaining people have been folded into a generic "Languages" group.
The press release on their web site seems pretty clear that they are no longer in the business of selling computer languages, but are focusing on their publishing and the law enforcement products. It is not tht they casually neglected to mention Lisp and Dylan as products: they have deliberately excised them.
Presumably this reflects a new business plan in which those languages are considered to be internal technologies, rather than general products in ongoing market areas. I would be surprised if Harlequin wouldn't sell you a copy of Lisp or Dylan, but they have certainly made noticable reductions in their ability to develop and support them.
I don't have any inside information, and who knows what the future will bring. I am just reading Harlequin's press release and making the obvious inferences. People should read it for themselves.
If harlequin were to give up on Lisp, then that would be a major mistake.
It's funny. I'm a grad student at BU. I was sitting beside an undergrad in the cluster yesterday. I am a math person, so I was working on a digital filtering problem. I saw, on the kid's screen, C-mode, with all the font-lock stuff going on, and lots of pointers, and something that looked like:
struct tree_node { left blah...
}
and it just went on and on. I felt like I had to say something. So I bother to ask him what his program was supposed to do. And, at about 2:15 am, as he was struggling just to make it compile, he told me. then, I showed him how I would do all that with defstruct, in Lisp, and I literally did his whole problem set in under 5 minutes. He thought I was a genius. After I made it work, I showed him how I could then add in declarations, etc...
Why do I mention this? It's because people learn a method of doing something and stick with it. You don't know about something that might be better, but you know your way around _something_, and though painful, you're comfortable with it, and since the rest of the world uses it, you think it must be the least painful.
All I know is that I showed that kid something just in time. I think I made a difference to him. I think he saw that he was spending an aweful lot of time doing something that was painful, when he could have been thinking about more interesting things.
anyway, my theory is that software is getting far too complex, and C/C++ will eventually die away because as complexity grows, it becomes too painful to code in anything but Lisp (as far as I've seen, and I've played with many languages). (can't speak for Dylan, though, and I've read interesting things about it). One day, when Lisp is the thing, Harlequin will painfully regret letting go of it, if that's what they're doing.
>I presume this explains Pitman's layoff a few weeks ago, although it seems >strange that there would be so much time between the layoff and the >announcement of the reorganization. Were all the other Dylan and Lisp >folks laid off as well?
At the LUGM in Berkely, I believe I heard that Harlequin let go _all_ of the Lispers in the US. The remaining Lisp developers are all in the UK.
On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote:
>As complexity grows, it becomes too painful to code in anything but Lisp.
Lisp has some real problems. Anything can be in any list, so you can be seriously bit at runtime by typing errors that a language with stronger types would have caught. The module system was pretty poor last time I checked. And having to look at the type bits in a variable to find out its type slows it down even more. These are not just theoretical concerns: my copy of Dylan brings my pentium pro 200 (NT) to its knees, much worse than excel or word or any other language environment I know of, and it's written in a state-of-the-art Lisp, isn't it? I really like algebraic types, so coding in Lisp or Scheme seems like going back a couple of decades in the way-back machine. For a big project ("as complexity grows") I'd go for Objective Caml or maybe even SML/NJ over Lisp. Ocaml is small, very fast, very powerful, with a great type system and full source freely available. So that's a bit of dissention to your comments, Dave, although I agree wholeheartedly with all that you said about C and the student, etc.
dwi...@pentasoft.com (Dwight VandenBerghe) writes: > poor last time I checked. And having to look at the type bits > in a variable to find out its type slows it down even more. These > are not just theoretical concerns: my copy of Dylan brings my > pentium pro 200 (NT) to its knees, much worse than excel or word > or any other language environment I know of, and it's written in > a state-of-the-art Lisp, isn't it? I really like algebraic types,
I'm not going to argue in detail with any of your other concerns, since I'm quite sure that others will disagree wholeheartedly with your statements ;)
But Harlequin Dylan was implemented in Harlequin Dylan, so no Lisp is to blame here (might be that Lispworks was involved in bootstrapping somewhere, but those components have been purged quite some time ago IIRC). OTOH Harlequin's Lispworks PE for NT is a true-blue Lisp implementation from the ground up, and last time I checked, it was much much much faster than Harlequin Dylan (all of this on a lowly AMD5x86-133, which reaches P90 levels at most, and where Java+Swing is much much much much much slower than even Dylan...)
With current, modern compiler-technology, Common Lisp performance is not something I've fretted about for quite some time, and I'm in the simulation business, where performance is not totally unimportant (and yes, the machines that run my simulations are better than my home machine, where I play around with Dylan ;).
> On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote: > >As complexity grows, it becomes too painful to code in anything but Lisp.
> Lisp has some real problems. Anything can be in any list, so you can > be seriously bit at runtime by typing errors that a language with > stronger types would have caught.
The Usenet system has some real problems. Any moron can post to any unmoderated newsgroup, so you can be seriously bit at read time by idiots who obviously have little real-world experience in what they are spouting off about, which a Usenet system with stronger group moderation would have caught. 8>)
In article <365b5a83.45243...@news.accessone.com>, dwi...@pentasoft.com
(Dwight VandenBerghe) wrote: > On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote: > >As complexity grows, it becomes too painful to code in anything but Lisp.
> Lisp has some real problems. Anything can be in any list, so you can > be seriously bit at runtime by typing errors that a language with > stronger types would have caught.
Yes and no.
> The module system was pretty > poor last time I checked.
There is only a package system
> And having to look at the type bits > in a variable to find out its type slows it down even more.
Objects carry types. If variables are typed the compiler will profit from that. Two different things.
> These > are not just theoretical concerns: my copy of Dylan brings my > pentium pro 200 (NT) to its knees, much worse than excel or word > or any other language environment I know of, and it's written in > a state-of-the-art Lisp, isn't it?
It isn't. Harlequin Dylan is not written in CL. Apple Dylan was. Ironically Apple Dylan is acceptably on my PowerBook. ;-)
>I really like algebraic types, > so coding in Lisp or Scheme seems like going back a couple of > decades in the way-back machine.
No - it is a different view of design. Still if your compiler can type check - nobody has anything against that - even if it is a Lisp compiler.
> For a big project ("as complexity > grows") I'd go for Objective Caml or maybe even SML/NJ over Lisp. > Ocaml is small, very fast, very powerful, with a great type system > and full source freely available.
This is the old difference between languages that are more in the SM group ;-) and languages that are more expressive like Lisp. "This has advantages for production code, but has disadvantages for rapid prototyping and evolution of programs." So, for even bigger projects you might come back to Lisp.
Reread the foreword to "On Lisp" for some arguments.
In article <joswig-2511980808300...@194.163.195.67>, jos...@lavielle.com
(Rainer Joswig) wrote: > In article <365b5a83.45243...@news.accessone.com>, dwi...@pentasoft.com > (Dwight VandenBerghe) wrote: > >I really like algebraic types, ... > > For a big project ("as complexity > > grows") I'd go for Objective Caml or maybe even SML/NJ over Lisp. > > Ocaml is small, very fast, very powerful, with a great type system > > and full source freely available.
Second try. I think I need to write something more polemic. ;-) Sorry.
Which type system do you like? The one from ML? Standard ML? Haskell? Which Haskell? Clean? Erlang? Some extended Java? Sather? Miranda? Where are the big differences?
How painful is it to move a 100000 line program from Haskell to Standard ML? And are the *big* differences between the two languages? How painful is it two maintain a 100000 line program that uses pattern matching in function definitions?
In CL a single person can write a 100000 line program in a few months and maintain it. How much people would I need to do it in say Haskell where the code would be three times as big (less abstraction mechanisms available) and three times as complicated (hey, how many programmers can you get that have heard the word "Monad"?). My impression is that there is going an awful amount of research into these areas (FP) and atleast 50% is academic "masturbation" (sorry ;-) ) creating evermore complicated mechanisms to fix the problems of the last language generation.
When will any of these languages be so advanced that they have something like CLOS? A MOP? Conditions? Incremental compilers? Great interactive environments? Just to the contrary working with the languages is like going **way** back in time.
Note, I know there are exceptions and a really appreciate the work people are doing - but so far I'm not that convinced I'll must use it for work right now. If I need functionality of that sort - *I* just do it inside CL with a language built on top of CL.
> Second try. I think I need to write something more polemic. ;-) > Sorry.
> Which type system do you like? The one from ML? Standard ML? > Haskell? Which Haskell? Clean? Erlang? Some extended Java? > Sather? Miranda? Where are the big differences?
Don't get me wrong I like CL there are of couple of things about types/classes that could (IMHO) be improved e.g.
It would be nice if classes and types could be intergrated.
It would be nice if methods could dispatch on higher functional types.
It is also a complication of dubious value that symbols have a number of different pieces of data associated with them.
> times as complicated (hey, how many > programmers can you get that have heard the word "Monad"?).
( I can even give you a accurate definition :-))
> My impression is that there is going an awful amount of research > into these areas (FP) and atleast 50% is academic "masturbation" > (sorry ;-) ) creating evermore complicated mechanisms to > fix the problems of the last language generation.
No doubt lisp was once regard in this light too...
> When will any of these languages be so advanced that they > have something like CLOS? A MOP? Conditions? Incremental > compilers? Great interactive environments? Just > to the contrary working with the languages is like > going **way** back in time.
Some functional laguages have interactive enviroments and incremental compilation. I've yet to find a language that there isn't a half-decent emacs mode for :-). The need for classes as such is much reduced when a type system is well designed and used. Although Functors in ML provide a similar sort of functionality and I understand that Erlang has a class system (although I don't speak Erlang).
Paul Rudin <pa...@shodan.demon.co.uk> writes: > half-decent emacs mode for :-). The need for classes as such is much > reduced when a type system is well designed and used. Although > Functors in ML provide a similar sort of functionality and I > understand that Erlang has a class system (although I don't speak > Erlang).
I don't speak Erlang either, but in general, when "modern" functional languages talk about classes, they generally mean type classes and the like, which are not quite what the OOP crowd calls classes.
In general, modern functional languages use a very different vocabulary from either the OOP (i.e. C++/Java + Smalltalk) crowd or the Lisp/Scheme crowd (there are some overlapping groups of people though ;), a vocabulary that stems mostly from an algebraic, type-theoretic background...
Regs, Pierre (who still thinks that monad-based parsing is way cool, but fears that monadic techniques destroy program modularity in general).
In article <joswig-2511981106000...@pbg3.lavielle.com>, jos...@lavielle.com says...
> How much people would I need to
The rest of your question is deliberately omitted, as I believe this question can applied to _any_ programming language. The answer is that it depends on the programmers you pick. One experienced programmer could be as productive as ten newbies.
> Note, I know there are exceptions and a really appreciate > the work people are doing - but so far I'm not that > convinced I'll must use it for work right now. If I need > functionality of that sort > - *I* just do it inside CL with a language built on top of CL.
Ahh, so your post is really only saying, "This is not for me."
Fair enough. Until a standard appears, I'd warn anyone from using Haskell to build a large app. Even the people creating Standard Haskell will agree - that's why they're creating it. Programmers need is stability for a reasonable length of time, which Haskell is currently lacking.
So ANSI CL wins purely on the grounds that it changes more slowly. ;) There are also be more implementations to choose from. Issues like the ease of learning to use monads depend more on the number and quality of tutorials, and again CL wins.
BTW, while ANSI C seems to have even more tutorials than ANSI CL, I'm not so impressed by the quality of these books. I have a similar opinion of most books about programming. While I'm generally against book burning, there are some examples that I've had the misfortune to find in bookshops which I'd say the world could do without.
And so we return to the programmer question; experience (may vary with language), imagination, and of course creativity. I hope that with this recent change of direction, the quality of Harlequin's programmers doesn't suffer. (Dragging us back on topic?)
FWIW, I write code in languages like Lisp and Haskell for pleasure, and usually get blank looks when I mention them in professional circles... -- Remove insect from address to email me | You can never browse enough will write code that writes code that writes code for food
David Cooper <dcoop...@genworks.com> writes: > The Usenet system has some real problems. Any moron can post to any > unmoderated newsgroup, so you can be seriously bit at read time > by idiots who obviously have little real-world experience in what > they are spouting off about, which a Usenet system with stronger > group moderation would have caught. 8>)
ROFLOL
Sorry for the noise content, but I couldn't let such a brilliantly sarcastic reply go uncongratulated. Wish I had thought of it. -- Michael Tuchman A Great way to avoid flame wars: all.SCORE has ("vs\\.?" -1000 nil r)
Joachim Achtzehnter <joac...@kraut.bc.ca> writes: >If any Lisp vendors are listening: When will we see Lisp environments >that use the available type information and warn at runtime about such >errors?
CMUCL's compiler gives out quite some useful warnings if you try to compile code with declarations, although this doesn't really apply to CLOS related calls.
Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer - for email address see a search engine. There is a business like showbusiness: www.microsoft.com http://www.freebsd.org/ - Where you want to go. Today.
In article <uclnkzlfsn....@ns.mercury.bc.ca>, Joachim Achtzehnter
<joac...@kraut.bc.ca> wrote: > Note, > he was talking about using Lisp in practise, not about what might be > possible in theory.
You are right.
> At least with some major Lisp implementations > compile-time type checking is totally absent. Being involved in a > major Lisp-based project I find it extremely frustrating to encounter > runtime errors which would have been easily caught by any crappy C > compiler. These errors are often encountered long after the relevant > code was written, and worse, sometimes by end users...
How are you dealing with that currently?
> If any Lisp vendors are listening: When will we see Lisp environments > that use the available type information and warn at runtime about such > errors? It is about time that Lisp programming environments grow > up. Look at what C/C++ environments let you do in terms of debugging > support. This should all be much easier in Lisp, yet it isn't.
That's one reason some people are still using the Lisp machine. Debugging is quite good. Some of the commercial systems are usable.
> In article <365b5a83.45243...@news.accessone.com>, dwi...@pentasoft.com > (Dwight VandenBerghe) wrote:
> > Lisp has some real problems. Anything can be in any list, so you can > > be seriously bit at runtime by typing errors that a language with > > stronger types would have caught.
> Yes and no.
His message may have come across as a troll, but as far as his particular gripe about type safety is concerned he has a point. Note, he was talking about using Lisp in practise, not about what might be possible in theory. At least with some major Lisp implementations compile-time type checking is totally absent. Being involved in a major Lisp-based project I find it extremely frustrating to encounter runtime errors which would have been easily caught by any crappy C compiler. These errors are often encountered long after the relevant code was written, and worse, sometimes by end users...
If any Lisp vendors are listening: When will we see Lisp environments that use the available type information and warn at runtime about such errors? It is about time that Lisp programming environments grow up. Look at what C/C++ environments let you do in terms of debugging support. This should all be much easier in Lisp, yet it isn't.
* chu...@best.com (Chuck Fry) | Some might be disgruntled that Harlequin has laid off much of the staff | they acquired from Lucid and Symbolics when those companies met financial | trouble. But since when is any one company required to support an entire | industry's personnel single-handedly?
excuse me, but what _is_ this last sentence _really_ about? it is so far from the actual situation in this market that it stands out as a prime example of "disgruntled", but I can't fathom what the target really is. care to explain?
#:Erik -- The Microsoft Dating Program -- where do you want to crash tonight?
Erik Naggum <e...@naggum.no> writes: > yes, it does. unfortunately, you didn't list any of them. that's also > one of the real problems Lisp has: myths, misconceptions, and prejudice.
It's only a few days ago since I talked to an otherwise well-informed programmer who asked the can't-stand-to-hear-anymore-question: "Isn't lisp an interpreted language?" (and this was even a _java_ programmer...)
> > yes, it does. unfortunately, you didn't list any of them. that's also > > one of the real problems Lisp has: myths, misconceptions, and prejudice.
> It's only a few days ago since I talked to an otherwise well-informed > programmer who asked the can't-stand-to-hear-anymore-question: "Isn't > lisp an interpreted language?" (and this was even a _java_ programmer...)
> Sigh.
In a similar vein, I recently spent some time explaining the virtues of (our implementations of) Common Lisp, Dylan, and ML to a booth visitor at a trade show where we were exhibiting.
The visitor currently programmed in Java and Delphi, so towards the end of the demo and the chat, I was quizzed him about the kind of differences he found between those two. He was a bit stuck, so I prompted that perhaps Delphi not having a GC made a significant difference.
The visitor then said that Delphi didn't have a GC because it was a compiled language! :-j
(And this after explaining and demonstrating the combination of native compilation and GC just beforehand. I know my boothmanship isn't great, but I'm pretty sure I went over that ground...)
