pls.m...@gmail.com wrote: > On 4 Mag, 05:08, scholz.lot...@gmail.com wrote: >> Without Unicode support, Windows Ports, true Multithreading i think >> definietly not.
> Gimme everything. And free. And now. And without my contribution. > Does this work anywhere in your personal life?
It does seem to work all right if one is using Python.
There is lots of stuff out there for which it does not really matter whether one is using CL, Python, Ruby, or any other half-sane language. In that situation, the language where you can just say "import X" for stuff like regexps, HTTP, HTML etc. is going to win. And for good reason, I might add. -- Pertti
På Mon, 05 May 2008 09:18:11 +0200, skrev Pertti Kellomäki <pertti.kellom...@tut.fi>:
> pls.m...@gmail.com wrote: >> On 4 Mag, 05:08, scholz.lot...@gmail.com wrote: >>> Without Unicode support, Windows Ports, true Multithreading i think >>> definietly not. >> Gimme everything. And free. And now. And without my contribution. >> Does this work anywhere in your personal life?
> It does seem to work all right if one is using Python.
> There is lots of stuff out there for which it does not really > matter whether one is using CL, Python, Ruby, or any other half-sane > language. In that situation, the language where you can just > say "import X" for stuff like regexps, HTTP, HTML etc. is going > to win. And for good reason, I might add.
I see thee approaches here.
Indeed if all you do is call library code, who cares how fast the language is? After all the library is doing all the work anyhow. Of course there are cases where Python, Ruby etc are just to slow like when implementing non trivial algorithms of your own. So you need a library for everything. (Web designers like this way.)
If you don't have a library you you are left with implementing it in C or simular. LUA works on this principle. Do the speed critical stuff in C/C++. Do the glue code in LUA. (Computer games people like this way.)
CL is just another alternative. It allows you to customize the language to fit the problem and COMPILE it. Particularly handy if the problem you want to solve isn't that trivial in the first place. (Expert systems, CAD/CIM, Gene mapping perhaps)
No CL isn't Ruby and might not attract the same people. Personally I am fine with that.
On Sun, 04 May 2008 19:09:58 +0200, John Thingstad <jpth...@online.no> wrote: > På Sun, 04 May 2008 05:08:43 +0200, skrev <scholz.lot...@gmail.com>: [...] >> Without Unicode support, Windows Ports, true Multithreading i think >> definietly not.
> Of course my LispWorks system supports all of the above.. > It does not do 'symmetric' multiprocessing if that is what you mean. > I might add that none of these things are a part of the C standard either. > That hasn't prevented C from being a popular language.
However the libraries to do thouse things have been standardized.
> Common Lisp is just a common denominator for Lisp's. Commercial versions > like LispWorks and ACL come with large libraries in addition to ANSI > Common Lisp.
Thats the problem. I'm no longer writing CL, I'm writing a dialect of CL that is dependent on the success or otherwise of my vender.
On Sun, 04 May 2008 19:09:58 +0200, "John Thingstad" <jpth...@online.no> wrote: > Of course my LispWorks system supports all of the above.. It does > not do 'symmetric' multiprocessing if that is what you mean.
The next version will do. Dave Fox made an announcement at the ECLM asking people interested in beta-testing this to contact LispWorks.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spamt...@agharta.de" 5) "edi")
> If it's true that as we progress in time, successive > fashionable languages resemble Lisp more and > more then Lisp's turn should come at some point.
> Do you agree with this argument ? If yes, would > you say we're close to a Lisp boom ?
> On Sun, 04 May 2008 19:09:58 +0200, John Thingstad <jpth...@online.no> wrote: >>Common Lisp is just a common denominator for Lisp's. Commercial versions >>like LispWorks and ACL come with large libraries in addition to ANSI >>Common Lisp.
> Thats the problem. I'm no longer writing CL, I'm writing a dialect of > CL that is dependent on the success or otherwise of my vender.
Lock-in is a gray-scale, If you cannot switch from ODB to RDB in a heavily-caffeinated long weekend we need you extinct.
"David Formosa (aka ? the Platypus)" <dform...@usyd.edu.au> writes:
> On Sun, 04 May 2008 19:09:58 +0200, John Thingstad <jpth...@online.no> wrote: >> På Sun, 04 May 2008 05:08:43 +0200, skrev <scholz.lot...@gmail.com>: > [...] >>> Without Unicode support, Windows Ports, true Multithreading i think >>> definietly not.
>> Of course my LispWorks system supports all of the above.. >> It does not do 'symmetric' multiprocessing if that is what you mean. >> I might add that none of these things are a part of the C standard either. >> That hasn't prevented C from being a popular language.
> However the libraries to do those things have been standardized.
This is false.
There are some standards, but you have to considerably restrict your targets to be able to use them.
Even on a single platform like Linux, you've got to choose between three different API to do multi-threading, for example. And let's not talk about GUI API!
And while you have some level of POSIX support in linux, unix, macosx (mach kernel), MS-Windows, BeOS, Haiku, QNX, etc, it is the most basic common denominator API you can get.
>> Common Lisp is just a common denominator for Lisp's. Commercial versions >> like LispWorks and ACL come with large libraries in addition to ANSI >> Common Lisp.
> Thats the problem. I'm no longer writing CL, I'm writing a dialect of > CL that is dependent on the success or otherwise of my vender.
Or you can choose to use libraries that offer some platform independence, but life won't be easy sometimes.
EL <eckhardnos...@gmx.de> writes: > Spiros Bousbouras schrieb: >> If it's true that as we progress in time, successive >> fashionable languages resemble Lisp more and >> more then Lisp's turn should come at some point. >> Do you agree with this argument ? If yes, would >> you say we're close to a Lisp boom ?
Notice he had to re-split the Lisp and Scheme categories, in order to make his list believable - would anyone have accepted a list like that where Lisp/Scheme ranked in positions close to Fortran and C?
Duane Rettig <du...@franz.com> writes: > EL <eckhardnos...@gmx.de> writes:
>> Spiros Bousbouras schrieb: >>> If it's true that as we progress in time, successive >>> fashionable languages resemble Lisp more and >>> more then Lisp's turn should come at some point. >>> Do you agree with this argument ? If yes, would >>> you say we're close to a Lisp boom ?
> Notice he had to re-split the Lisp and Scheme categories, in order to > make his list believable - would anyone have accepted a list like that > where Lisp/Scheme ranked in positions close to Fortran and C?
> :-)
And I notice a CL in 27th position too. If we added Lisp+Scheme+CL, the sky's the limit! Actually the first position, but good enough :-)
>> Notice he had to re-split the Lisp and Scheme categories, in order to >> make his list believable - would anyone have accepted a list like that >> where Lisp/Scheme ranked in positions close to Fortran and C?
>> :-)
> And I notice a CL in 27th position too. If we added Lisp+Scheme+CL, > the sky's the limit! Actually the first position, but good enough :-)
Zynically: I thought that Lisp programmers don't need to google that much for their tools, in order to get something done. Contrahery to the Java/Python crowd... So it must really be the interest of newbies that we see here ;-).
>> IMO, not until CL goes through another standardization process, not >> for the language this time, but for a few libraries: comm, stream, >> unicode, thread.
> Yeah, the damn thing is unusable as it is.
It's not that it's unusable (that's clearly false, as every project written in CL clearly demonstrates); it's that it's less usable than would otherwise be the case. It's not an issue of black-and-white: it's an issue of lighter vs. darker grey. There was a time when CLOS was not standardised; as The Art of the Metaobject Protocol demonstrates, it could always be rolled by hand. Surely you agree that a single standardised CLOS is better than a dozen similar-but-incompatible OOP libraries? In the same way, standardising libraries would be useful.
The existing pretty-much-similar sockets libraries should be standardised. Gray Streams should be standard. Unicode should be the new standard, with clearly-defined migration paths for legacy encodings (I'm not up on my Unicode specs--perhaps there are some suggestions already there). Threading and multi-processing should be standardised.
Something interesting would be standard message-passing based on the Erlang model. I don't know if there's any agreement that the Erlisp model is the right way to do this though. It would be nice for CL to be as far ahead of the curve again as it once was. Garbage collection and closures are pretty common now; optional and keyword arguments are not unknown (c.f. Python); macros are at a tipping point (people realise they need them, and are trying to figure out how to get them in irregular languages); CLOS-style generic functions are in a similar position; conditions still haven't caught on; I think that integrating some of Erlang's features might be a way to do for multiprocessing what CLOS did for OOP.
>> Too bad there isn't a benevolent angel that could fund such >> an expenditure <hint>PG</hint>.
> Nah, he went broke trying to do a start-up with CL, a Web store I think.
PG's too busy reinventing the wheel with Arc to do anything for CL.
-- Robert Uhl <http://public.xdi.org/=ruhl> People who do technical support for a living are bitter, twisted and uncharitable. Eight hours a day of telling people what's already in the manual [...] results in a steady and inexorable progression towards a state of depressive sociopathy. --dansdata.com
>> I'm no longer writing CL, I'm writing a dialect of CL that is >> dependent on the success or otherwise of my vender.
> How is that different from C/C++?
With standard C plus standard POSIX, you're pretty much certain that your app will run anywhere important. You're not certain that it'll run fast or particularly well, and of course there are those edge cases that need to be taken care of--but my perception is that C+POSIX is much more reliable a platform than Common Lisp.
It's also much more low-level and much more prone to segfaults and security holes. At the moment I'd rather program in non-portable CL than in portable C, but that's me.
-- Robert Uhl <http://public.xdi.org/=ruhl> Remember, democracy never lasts long. It soon wastes, exhausts, and murders itself. There never was a democracy yet that did not commit suicide. --John Adams, 1814
>>> Spiros Bousbouras schrieb: >>>> If it's true that as we progress in time, successive >>>> fashionable languages resemble Lisp more and >>>> more then Lisp's turn should come at some point. >>>> Do you agree with this argument ? If yes, would >>>> you say we're close to a Lisp boom ?
>> Notice he had to re-split the Lisp and Scheme categories, in order to >> make his list believable - would anyone have accepted a list like that >> where Lisp/Scheme ranked in positions close to Fortran and C?
>> :-)
> And I notice a CL in 27th position too.
Ah, you're talking about the Tiobe site. I was talking about the "cleaned up" list, which currently places Scheme at #12 and Lisp at #13. I was the one that originally suggested to the tiobe people that they combine Lisp and Scheme.
> If we added Lisp+Scheme+CL, > the sky's the limit! Actually the first position, but good enough :-)
As far as I know, CL is actually included in that mix for the Tiobe data. It's hard, though, to infer contextually that a particular instance of "CL" stands for Common Lisp. I read at one point how they get their data, and that's what led me to make the suggestion to combine.
I personally place very little faith in numeric measurements like tiobe's list and LOC measurements, mostly because they can be abused by both sides of an argument. But for what they're worth (i.e. an interesting number) they are numbers, and they make possible a narrow comparison that wouldn't be otherwise available. But take or leave the list; the guy who wrote the "cleaned up" list (which he apparently now retracts becase he's seen the light about taking any list too seriously, including his) was obviously incensed that his own pet language, Haskell, was rated less popular than APL (which nobody has a keyboard for anyway :-). Everyone is going to find reasons to hate the list, and it should be a lesson to those who ask for "proof" that Lisp is better than something else; it's not going to happen, because in deconstructing the meaning of the word proof one finds that there needs to be an observer to the proof/test, and such observation is always going to be subjective.
Pertti Kellomäki <pertti.kellom...@tut.fi> writes:
> There is lots of stuff out there for which it does not really matter > whether one is using CL, Python, Ruby, or any other half-sane > language. In that situation, the language where you can just say > "import X" for stuff like regexps, HTTP, HTML etc. is going to > win. And for good reason, I might add.
Yes. Fortunately, for the important Lisps one just goes to weitz.de and grabs CL-PPCRE (faster Perl-compatible regexps than Perl!) and Hunchentoot. HTML generation is another issue, although I'm partial to CL-WHO (also from Dr. Weitz). For a good portion of the '&c.' weitz.de is your one-stop shop...
-- Robert Uhl <http://public.xdi.org/=ruhl> Customs officers enter into a Faustian bargain whereby they are given absolute power in exchange for their sense of humour. Hitler's dad, you will remember noddingly, was a Customs officer. And _Hitler_ thought he was a nasty piece of work. --Mil Millington
On Tue, 06 May 2008 09:43:16 -0600, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote: > With standard C plus standard POSIX, you're pretty much certain that > your app will run anywhere important.
How many useful and/or successful Windows apps have been written in pure standard C plus standard POSIX?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spamt...@agharta.de" 5) "edi")
On May 3, 8:30 pm, Ken Tilton <kennytil...@optonline.net> wrote:
> What I see happening is India or China discovering CL specifically and > standardizing on it (er, informally) and crushing the West. Man, that > would be funny, but not surprising.
Kenny, if one knows the history, then he knows the future...
Robert Uhl <eadmun...@NOSPAMgmail.com> writes: > Edi Weitz <spamt...@agharta.de> writes:
>>> I'm no longer writing CL, I'm writing a dialect of CL that is >>> dependent on the success or otherwise of my vender.
>> How is that different from C/C++?
> With standard C plus standard POSIX, you're pretty much certain that > your app will run anywhere important. You're not certain that it'll run > fast or particularly well, and of course there are those edge cases that > need to be taken care of--but my perception is that C+POSIX is much more > reliable a platform than Common Lisp.
In a world of closed source, proprietary OS like we had 20 years ago, yes.
In a world of free software, easily downloadable from the Net, and installable on any machine, not anymore, C+POSIX is not more reliable a platform than Common Lisp or anything else. For example, IIRC, MacOSX 10.5 is delivered to the users with ruby, without gcc.
It's not harder to download darwin ports, and type port install sbcl to get a CL platform than it is to type port install gcc to get a C+POSIX one.
I don't have the impression that MS-Windows is delivered to the users with a C compiler either... Download for download, you can as well download sbcl or clisp to make your MS-Windows box a programmable computer.
> It's also much more low-level and much more prone to segfaults and > security holes. At the moment I'd rather program in non-portable CL > than in portable C, but that's me.
On Tue, 06 May 2008 18:13:21 +0200, <plamen.use...@gmail.com> wrote: > On May 3, 8:30 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>> What I see happening is India or China discovering CL specifically and >> standardizing on it (er, informally) and crushing the West. Man, that >> would be funny, but not surprising.
> Kenny, if one knows the history, then he knows the future...
