It has been repeatedly and voluminously proposed that a cadre or cabal be formed to create a neolisp sublanguage -- a sanctioned set of add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe for obvious reasons.) I tend to agree with those who think that this needs to be done in public by a semi-formal elected committee. But I'm not much for talk. Therefore, I propose that we simply form the committee and start putting together the addons. What would have to happen is:
1. Create a sourceforge project. (I already have one that we could co-opt temporarily). 2. Elect the committee who create a charter. 3. Create a web site. (I run a server that we can use for free temporarily.) 4. Create a process, like the Python PEP process for proposal to be considered. 5. Do it.
#2 seems to be the most problematic, so I propose the following process:
2a. We set a target number of members, say 5. (Of course, anyone can help, but there needs to be a reasonable non-even voting block to make decisions.) 2b. Anyone wishing to become a member write a short self-promoting note. 2c. There is a period of voting through email to me. 2d. I'll tally the vote. (Anyone who has stood for election can review the raw vote email trail.) 2e. The top n (default 5) win. 2f. Those 5 worry themselves about the charter, which will presumably include how to change membership, etc.
I'll start setting up the web site, and those wishing to stand for election should register with me (just send me email), including writing your self-promoting bio (1000 word limit, please) by the end of this month.
The vote will take place for one week (7 days) beginning on May 1. We will begin the development effort mid-May.
JShra...@gmail.com wrote: > It has been repeatedly and voluminously proposed that a cadre or cabal > be formed to create a neolisp sublanguage -- a sanctioned set of > add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe > for obvious reasons.) I tend to agree with those who think that this > needs to be done in public by a semi-formal elected committee. But I'm > not much for talk. Therefore, I propose that we simply form the > committee and start putting together the addons.
Just for the enlightenment of the clueless, what happened to this effort? http://clrfi.alu.org/
I'd agree we need something like this (I suppose I'm part of the voluminous proposals you refer to) but it needs to be well structured, well organized, and have the active support of enough of the Lisp community to have moral authority. Probably the best way is to create good proposals. Also, perhaps the commercial Lisp vendors would have some interest in such a process, as well as the resources to do high quality work?
JShra...@gmail.com wrote: > It has been repeatedly and voluminously proposed that a cadre or cabal > be formed to create a neolisp sublanguage -- a sanctioned set of > add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe > for obvious reasons.) I tend to agree with those who think that this > needs to be done in public by a semi-formal elected committee.
Most wildly successful open source projects have a BDFL (benevolent dictator for life) that keeps things focused and moving forward at a good speed. You don't elect a BDFL, he emerges because he is doing something so kick ass that others want to be a part of it.
While popular, the term BFDL is really a misnomer. It would be more accurate to call Linus, Larry, Guido et. al. prophets rather than BFDLs. Any Joe can climb to the top of a hill and preach a sermon. When a true prophet preaches, people gather round. People begin to follow. If the leader loses his chops then folks lose interest and move on.
Of course in the technical realm, "preaching" means creating useful working code.
If you yourself are not a prophet and you can't find a prophet you want to follow then you need to learn to make due with the status quo (e.g. pick a CL implementation) and get on with your own work.
"C Y" <smustude...@yahoo.com> writes: > Just for the enlightenment of the clueless, what happened to this > effort? http://clrfi.alu.org/
Some people took the CLRFI idea and tried to define a process which would give them work, which they didn't do, so the process stopped.
In my opinion, in this time of web and wiki, the CLRFI could just be posted and commented in cliki.net, without a need for a central "authority", at least until some momentum is gained and resources agregated.
For example, useful libraries like CFFI could be posted as a CLRFI.
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any manner whatsoever, will increase the amount of disorder in the universe. Although no liability is implied herein, the consumer is warned that this process will ultimately lead to the heat death of the universe.
Oh. Right. Sorry. I forgot that we'd all agreed to to just sit around in church and pray for the nth coming ... Oh, and to dis any proposal to organize the community into collective action. Forgive me... (What page were we on in the hymnal?)
"Have you ever been in a relationship?" Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems.
JShra...@gmail.com writes: > Oh. Right. Sorry. I forgot that we'd all agreed to to just sit around > in church and pray for the nth coming ... Oh, and to dis any proposal > to organize the community into collective action. Forgive me... (What > page were we on in the hymnal?)
That's an interesting perspective. An individual with no obvious credentials comes along and proposes to do something that's been done in the past to little avail (cf. CLRFI) and which, in the minds of many Lispers, may or may not even be a worthwhile goal. The community largely ignores this individual and somehow this is proof that there is something deeply wrong with the Lisp community. Go away.
Pascal Bourguignon <p...@informatimago.com> writes: > For example, useful libraries like CFFI could be posted as a CLRFI.
They could, but I think that this would be a bad idea: libraries like CFFI are unstable in the sense that their interface is changing as new requirements are being discovered. What might make more sense to submit as a CLRFI is some interface to the low-level operations that CFFI uses to implement itself: operators dealing with things like C pointers, pinning vectors against being moved by garbage collectors, and similar. Bonus points if these operators are required by more than one 'userspace' library, so that one can judge the semantics needed against more than one use case.
>> Oh. Right. Sorry. I forgot that we'd all agreed to to just sit around >> in church and pray for the nth coming ... Oh, and to dis any proposal >> to organize the community into collective action. Forgive me... (What >> page were we on in the hymnal?)
> That's an interesting perspective. An individual with no obvious > credentials comes along and proposes to do something that's been done > in the past to little avail (cf. CLRFI) and which, in the minds of > many Lispers, may or may not even be a worthwhile goal. The community > largely ignores this individual and somehow this is proof that there > is something deeply wrong with the Lisp community. Go away.
On one hand we have a community that agrees about the lack of standard for threads, gui, sockets and whatnot... On the other hand we have people that agree about the standard being pretty good as it is and frankly quite big already.
It seems obvious that a standard library is the solution that will fit both views.
First off, if you think that I don't write code, you clearly have no idea who you are talking to (which I guess is possible, but would be unfortunate). We all write code (most of us, anyway) or we would be reading rec.poker, or some such thing. So let's get it clear from the start: You write code. I write code. Possibly even Bill Atkins writes code (although no one seems to have taught him manners or, like you, to figure out who you are conversing with before telling them in public to go to hell).
Writing code is NOT what is needed now; Code abounds. What is needed is not more code but buy-in from the community to a process for adopting the best code into a new standard package. By "Buy-in" I mean at least the help and blessings of the community -- having the community elect the people to do the organizing is the only way I know to get this. But "buy in" could also mean money to support the process -- possibly paying some of the people who do the work. And by "process" I mean people who will do the work (and possibly get paid for it).
I therefore hereby publicly offer $10,000 (in addition to my volunteer help) to support the process if it involves duly elected (by YOU ALL -- NOT BY ME!) representatives of the community who have a charter and process by which to produce a public open source standard add-on package for Common Lisp. And I hope for my 10 grand to see an elected committee and a package produced within a year from when I write the check. These folks can choose to pay themselves with my money, and hopefully with other community support as well.
[Note that I don't expect to be a paid part of this process -- I don't have high enough profile in the community to expect to be elected to the CADRe I have proposed -- and I probably shouldn't be as there many better Lisp programmers around here than me (and, from the amount of talk on this board, they all have more time than I do -- I'm too busy writing code! :-) I expect only to help as I can and as needed.]
Okay, Ken, and everyone else. Put your money where your mouth is.
JShra...@gmail.com wrote: > This is exactly wrong.
> First off, if you think that I don't write code, you clearly have no > idea who you are talking to (which I guess is possible, but would be > unfortunate).
Nope. Never noticed you until you snapped like a twig when the whole world did throw themselves at your feet. Get used to it because you are so exactly wrong: about two people on c.l.l write code.
> We all write code (most of us, anyway) or we would be > reading rec.poker, or some such thing. So let's get it clear from the > start: You write code. I write code. Possibly even Bill Atkins writes > code (although no one seems to have taught him manners or, like you, to > figure out who you are conversing with before telling them in public to > go to hell).
Aw, jeez, this is Usenet. Get over it.
> Okay, Ken, and everyone else. Put your money where your mouth is.
$10k? Very impressive. Good for you. LispNYC is about to waste $4500 on something related. Ron Garret is looking for a place to spend his fortune. Maybe you all should talk. You and Ron on a committee should do great.
As for my Incredibly Shrinking money is committed to keeping me alive until I can ship a "Win Big With Lisp". That means I am writing code, btw, some of which is a universal CL GUI. Eat your heart out. :)
"Have you ever been in a relationship?" Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems.
JShra...@gmail.com wrote: > This is exactly wrong.
> You write code. I write code.
You miss my meaning. Yes, I write code. I also cook, but no one would confuse the crap that comes out of my kitchen with the works of art that Thomas Keller produces at the French Laundry.
Likewise, while I do write code for a living, my technical chops don't compare to Linus, Guido, Larry or Theo. It is not enough to write code. You must create an awesome product with that code. Not a mediocre product. Not a good product. An awesome product.
CLISP and SBCL are pretty good but apparently not good enough to take over the evolution of the CL world like GCC did for the open source C/C++ space.
> Writing code is NOT what is needed now; Code abounds. What is needed is > not more code but buy-in from the community to a process for adopting > the best code into a new standard package.
I agree that buy in is key. Where we differ is how to get buy in. Forming yet another committee is not an effective way to get buy in (IMESHO).
> I therefore hereby publicly offer $10,000 (in addition to my volunteer > help) to support the process if it involves duly elected (by YOU ALL -- > NOT BY ME!) representatives of the community who have a charter and > process by which to produce a public open source standard add-on > package for Common Lisp.
I commend your fiscal commitment but trying to hire someone else to be inspired is not effective. If you yourself don't have a plan for exactly what you want to do then I doubt you will be effective in hiring others to come up with the plan to improve lisp.
Of course I remember back in 1991 a schoolmate told me about this exciting new operating system linux that was much better than minux and would be as good as SunOS soon. I was skeptical that a bunch of hobbyists could produce a professional grade OS. I could not have been more wrong...
Nothing would make me happier than to see you prove me wrong by jump starting the growth and improvement of the Lisp community.
Christophe Rhodes wrote: > They could, but I think that this would be a bad idea: libraries like > CFFI are unstable in the sense that their interface is changing as new > requirements are being discovered. What might make more sense to > submit as a CLRFI is some interface to the low-level operations that > CFFI uses to implement itself: operators dealing with things like C > pointers, pinning vectors against being moved by garbage collectors, > and similar. Bonus points if these operators are required by more > than one 'userspace' library, so that one can judge the semantics > needed against more than one use case.
I think the problem with that idea is that implementations will already have these sorts of things, and they will all be different, and the implementors will have a significant investment in how they do things now (lots of working code) and won't want to change them, quite reasonably. Specifying some thin standard wrapper around the various extant implementations might be a good approach, but only if they are similar enough that one or more is not unduly penalised. This matters a lot for FFIs in particular of course - no one wants some standard wrapper that causes enormous overhead when calling C code, on *some* implementations.
So I think a higher-level standard interface would be a better idea. But if CFFI is unstable then that's probably a good indication that the time is not yet ripe for one.
Of course, there are things that could be done that aren't this hard. For instance (just from looking at the CFFI-SYS manual and cringing): how hard would some package-related standards be? It is about 10 years past time that people started giving packages sensible names and it's easy to just borrow what Java has done there (ORG.TFEB.UTILS for instance, not UTILS). Then we want things like short names for packages, and there are some fairly obvious things to do with that. And all of this has the nice property that, though implementation changes will be required, they will probably be very small ones, and also not on any kind of critical performance path (really, you just need a few hooks on which to hang the new DEFPACKAGE etc). Finally, getting this done lets you construct variant CLs by package manipulations of various kinds (for instance: one where the symbol you get buy reading CL:DEFPACKAGE is not the common lisp DEFPACKAGE. So something like this is perhaps a good jumping-off place.
(Of course, I happen to have done work implementing things that do all this, which is why I'm mentioning it - there are probably other areas which would pay off at least as well. In any case what I *don't* have is a specification, I just have code. Still less do I have a specification which might be acceptable to implementors.)
I'm not disagreeing with you by the way - at least not intentionally.
On the subject of BDFLs which came up in another branch of this thread. All the mentioned BDFLs are for *implementations* not for standards. Standards are very different things, and I'm not aware of any driven by BDFLs. In many ways standards are *harder* than implementations, because for them to be useful they need to be widely accepted, and that requires social skills. Which is why the coup d'etat approach is not likely to work for them.
Finally, the money issue. Writing code is something that people will do for free (fools that they are), because it has an immediate payoff - you have a problem, so you write something that makes the problem go away. And then you can write a little bit more code and some more problems go away - it's just drugs without the being-illegal bit really. Writing standards, and doing all the political stuff involved with them is a different issue: there is no immediate hit from solving a problem, and you have to deal with a whole lot of social & political stuff that most programmers find very painful, are really bad at and avoid whenever they can. And writing good standards is also just hard work, even without the human interaction aspects, requiring very good command of language and so on. My guess is that very few standards are written by people for free, and those that are will generally be thin skins on an imlementation (like the python standard or something). No one is going to work on POSIX for free for instance! And though the original poster has mentioned money, I don't think he realises how little it is, given that people with the skills to do standardisation work also have the skills to earn a lot of money (all those social skills turn out to matter).
Tim Bradshaw wrote: > ... though the original poster has mentioned money, I don't think > he realises how little it is ...
Of course he relalizes how little it is. He didn't just offer the cash, he challenged others to step up like he did. You don't have to give $10,000 -- how about $1000? How about $500? How about $100?
JShra...@gmail.com wrote: > Of course he relalizes how little it is. He didn't just offer the cash, > he challenged others to step up like he did. You don't have to give > $10,000 -- how about $1000? How about $500? How about $100?
If the goal is newbie adoption, it sounds like there's a much easier solution, based on work that's already been done for us by hard workers. The canonical newbie distro can be LispBox. The nice website can be built around it, with recommended, tested libs. Resources can be applied to port things to Wintel and MacOS X.
If someone else thinks this is a bad approach, they can do something else. A democratic process where people manage themselves.
And really, it seems more important to hear newbies talk, rather than experienced Lisp users debate. Seems the newbies' problems are much more humble than we think. Like being able to reliably install CLSQL under Lispbox. (Which I kinda did yesterday, and had a big hiccup, which would've turned off the casual newbie. I say "kinda" because I didn't use Lispbox but did use asdf-extensions.lisp which I extracted from Lispbox. That interacts badly with makefiles, requiring a workaround; an issue I expect Lispbox users face.)
> If the goal is newbie adoption, it sounds like there's a much easier > solution, based on work that's already been done for us by hard > workers.
The goal isn't newbie adoption, but if it were, you'd be right, Lispbox is good. Regardless, what you are in fact exactly right about is that building and maintaining Lispbox is hard work done by hard workers, and the guy/folks who does/do it need to pay his/their rent and occasionally eat. As has been pointed out, $10,000 isn't much, but it's something. I don't mean this in a nasty way, but I'll bet you and the rest of the community aren't going to offer the Lispbox guy/folks a dime for all his/their hard work, nor will you (that is, the community) offer him/them, nor anyone else anything but a warm handshake for the work involved in doing what it takes to keep Lisp alive. The open source/freeware mentality has broken something deep in the world, and it's killing Lisp, and probably lots of other good things. Companies that build fantastic Lisp platforms can barely stay in business and need to scratch for every dime to pay their hard-working engineers, and the community is full of people who think that just because they write and give away yet another crappy, partly working implementation of variable persistence that they knocked off in their spare time, they deserve to get excellent working software by the hard work of brilliant people for free. Ugh.
(Sorry, TJG, this flame isn't directed at you -- just prompted by your note.)
JShra...@gmail.com wrote: > I don't mean this in a nasty way, but I'll bet you and the > rest of the community aren't going to offer the Lispbox guy/folks a > dime for all his/their hard work, nor will you (that is, the community) > offer him/them, nor anyone else anything but a warm handshake for the > work involved in doing what it takes to keep Lisp alive.
My reply may be besides your point but I'd like to offer, as a data-point, that part of the community collectively gave $1123.09 to common-lisp.net. If you look at the donors list you'll recognize some of them as regular posters to this group. While it may not be much money, the annual budget is only $900.
JShra...@gmail.com wrote: >>If the goal is newbie adoption, it sounds like there's a much easier >>solution, based on work that's already been done for us by hard >>workers.
> The goal isn't newbie adoption, but if it were, you'd be right, Lispbox > is good. Regardless, what you are in fact exactly right about is that > building and maintaining Lispbox is hard work done by hard workers, and > the guy/folks who does/do it need to pay his/their rent and > occasionally eat. As has been pointed out, $10,000 isn't much, but it's > something. I don't mean this in a nasty way, but I'll bet you and the > rest of the community aren't going to offer the Lispbox guy/folks a > dime for all his/their hard work, nor will you (that is, the community) > offer him/them, nor anyone else anything but a warm handshake for the > work involved in doing what it takes to keep Lisp alive. The open > source/freeware mentality has broken something deep in the world, and > it's killing Lisp, and probably lots of other good things.
Well, nothing is going to kill Lisp. What may get killed is people trying to make money off commodity software, because they will be up against free versions and it is hard to be better enough to justify bucks. Especially when some people do not realize how much the rough edges of "free" stuff costs them.
> Companies > that build fantastic Lisp platforms can barely stay in business and > need to scratch for every dime to pay their hard-working engineers,
Agreed. But look at CLisp. That sets the bar $$$ Lisps must clear by a high enough margin to justify the $$$. And Lispworks sets the bar for Franz in re runtime licensing. I mention only win32-portable Lisps because commercial success kinda requires that.
As a Lisp entrepreneur myself I am of course rooting for the commercial Lisp vendors, but am I supposed to treat them as charity cases and give them revenue for no reason when I could be using cheaper alternatives (assuming for the sake of argument that CLisp and LW do not fall into the "expensive free" category).
Note, btw, that your $10k would be financing another knife in the $$$Lisp back, since all they have to point to are add-ons like CAPI (LTk and Cells-Gtk killed that advantage) and AllegroCache. And their proprietary implementations of sockets and FFI (CFFI killed that) do a little to lock in developers (not much, tho).
The answer is simple: vertical apps, not tools. It is time for the IT community to stop creating tools (or trying to make money off them) and start using them to solve problems in the real world. Paul Graham did it. Orbitz did it. That is what I have been trying to do for seven years.
"Have you ever been in a relationship?" Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems.
You're right. It's already dead. (In the sense that it's stopped evolving-- which is what this was all about to begin with.)
> What may get killed is people > trying to make money off commodity software, because they will be up > against free versions and it is hard to be better enough to justify > bucks. Especially when some people do not realize how much the rough > edges of "free" stuff costs them.
Amen to that!
> The answer is simple: vertical apps, not tools. It is time for the IT > community to stop creating tools (or trying to make money off them) and > start using them to solve problems in the real world. Paul Graham did > it. Orbitz did it. That is what I have been trying to do for seven years.
> All aboard?
I would be, if you were right, but unfortunately, you're not. "Vertical apps" is too simplistic a way of thinking about it. I work primarily in biocomputing (which, btw, I do entirely in Lisp!) where freeware vertical apps abound too, and thus the vertical app manufacturers are scratching around just like the platform manufacturers in the IT world are.
It's utterly amazing to me that the folks in the labs that I work with will drop $50,000 without even thinking about it hard for an HPLC machine that they'll use, maybe 10 times a year, but I have to beg them for $1500 to buy the Lisp platform that I use to support every biocomputing activity in the lab (which is a LOT, and a LOT more work than the HPLC machine supports.)
The answer isn't vertical or horizontal or anything so simple, and it's not real or virtual -- what I do for the biologists in my lab is as real as what that HPLC machine does -- do I get paid for it? No. Can I get them to pay for software licenses (vertical or horizontal)? No. It's something like: "Do something that no one can replicate, and that everyone needs, and charge for it." No one can replicate what an HPLC machine does, but the biologists <i>believe</i> that they can replicate what I do for them... with excel or something (which, of course, they think is free because it <i>appears</i> to be free on the Stanford site license). In fact, I (and a team of mostly volunteer, but paid when I get pay them) engineers built them a lovely platform (entirely on Lisp) with which to do their work... will they help pay for it at all? No. Why? Well, because it's on the web, and it's just a web thing, and all web things are just free, aren't they?
The world is all sooooooooooooo f'ed up with respect to software and money that I just can't believe it...
JShra...@gmail.com wrote: > (Sorry, TJG, this flame isn't directed at you -- just prompted by your > note.)
No problem. I personally feel the recent discussions here are almost too objectionable and irrational to participate in, partly because I don't think people are interested in listening to each other (preferring debate rather than building something). While I may not agree with your points, it's not a reason for aiming abuse at you.
> > If the goal is newbie adoption, it sounds like there's a much easier > > solution, based on work that's already been done for us by hard > > workers.
> The goal isn't newbie adoption, but if it were, you'd be right, Lispbox > is good.
Hmm, what's your goal? I (and perhaps others) haven't understood you, in that case.
> Regardless, what you are in fact exactly right about is that > building and maintaining Lispbox is hard work done by hard workers, and > the guy/folks who does/do it need to pay his/their rent and > occasionally eat. As has been pointed out, $10,000 isn't much, but it's > something. I don't mean this in a nasty way, but I'll bet you and the > rest of the community aren't going to offer the Lispbox guy/folks a > dime for all his/their hard work, nor will you (that is, the community) > offer him/them, nor anyone else anything but a warm handshake for the > work involved in doing what it takes to keep Lisp alive.
Yes, there isn't even much funding for the people working hard on vital issues like environmental destruction and need for independent media, is there? Still, we prioritize. Where money is effective, maybe we give money. Where our skills as Lisp programmers are effective, maybe we contribute in that manner.
Or not.
> The open > source/freeware mentality has broken something deep in the world, and > it's killing Lisp, and probably lots of other good things. Companies > that build fantastic Lisp platforms can barely stay in business and > need to scratch for every dime to pay their hard-working engineers, and
Such is our economic system... it does not support infinitely reproduceable goods well.
> the community is full of people who think that just because they write > and give away yet another crappy, partly working implementation of > variable persistence that they knocked off in their spare time, they > deserve to get excellent working software by the hard work of brilliant > people for free. Ugh.
Which persistence libs are you critiquing? A serious critique sounds interesting.
> > > If the goal is newbie adoption, it sounds like there's a much easier > > > solution, based on work that's already been done for us by hard > > > workers. > > The goal isn't newbie adoption, but if it were, you'd be right, Lispbox > > is good. > Hmm, what's your goal? I (and perhaps others) haven't understood you, > in that case.
It's having a systematic process through which the langauge -- by which I mean the core language and the "standard library set" which amounts to a distributed part of the language -- can be extended to encompass modern needs and discoveries in order that professional work can be done in it, and that we (professionals) can expect (and may have to expect to support!) the continued growth of the language as new needs and discoveries are discovered. The goal -- my goal, anyhow -- is to retain professionals, and lead professionals to choose lisp for app development over, say, Python, PERL, or Java or even C/C++ (although I think that the latter serve a useful role in the world at the moment in deep near-hardware development). I'm not just pissing this stuff: I program in Lisp every single day of the week, and have to nearly 30 years. I do absolutely everything in Lisp (except, as above, near-hardware stuff, and in many cases I do that with Lisp-based macros!) I've written god knows how much code, and published over 50 peer-reviewed professional papers most of who's contents is ENTIRELY based on Lisp -- InterLisp, *Lisp, MacLisp, CMUCL (the origianl -- I was at CMU!). But, you know, every time I need to dig around to find something that is essentially standard in Python or Java, and end up just writing it myself and hating it, I have to resist the urge to jump ship myself. And it's not merely that the language doesn't have X or Y, it's that there is no process by which X or Y could EVER become part of the language (or standard libraries), and so I watch Python, Perl, C#, and Java racing by while I'm yet-again writing my own dumb partial implementation of something that should be standard in ANY MODERN LANGUAGE. The language is like Latin. It's perfect for the Roman world. And like Latin it's perfectly dead. So, to answer your quesiton: My goals is not to attract newbies, it's to keep myself from breaking my own heart by leaving the love of my life.
> > ... though the original poster has mentioned money, I don't think > > he realises how little it is ...
> Of course he relalizes how little it is. He didn't just offer the cash, > he challenged others to step up like he did. You don't have to give > $10,000 -- how about $1000? How about $500? How about $100?
I don't think you realise who ill-conceived I think the idea is.
On 20 Apr 2006 09:41:48 -0700, JShra...@gmail.com wrote:
> It's having a systematic process through which the langauge -- by which > I mean the core language and the "standard library set" which amounts > to a distributed part of the language -- can be extended to encompass > modern needs and discoveries in order that professional work can be > done in it, and that we (professionals) can expect (and may have to > expect to support!) the continued growth of the language as new needs > and discoveries are discovered. [snip snip]
In my opinion, Common Lisp is caught in a catch-22. On the one hand, the language and the standard library are not a commodity. Thus in the marketplace for implementations and tools, customer lock-in is still a viable business plan -- given all the parameters that go into a decision of which implementation(s) to use, today the path of least resistance given many permutations of those parameters is to just go with a single vendor, and then it becomes very, very hard to migrate to a different implementation. This situation is facilitated in part by the spec that we have today (which we must recognize is a product of not just a technical process, but also a political process).
The vendors today have enough marketshare and remain healthy enough as businesses that the bar for commoditization to take hold is too high. The FOSS implementations are strong in their own right, but not yet compelling enough to displace the commercial implementations. And the commercial vendors see a relatively low potential ROI in encouraging further standardization. So for all of these reasons, the status quo remains. But I do think there is a change occurring.
I do not in any way blame the commercial vendors for finding strategies to earn revenue. I would be hard-pressed to come up with better strategies, and I deeply respect the ability of these companies to survive conditions that would have put lesser companies out of business long ago. In other words, I don't have an anti-commercial mindset. I'm just explaining my view as to why a sanctioned standards process is a non-starter right now.
So, my thinking is that Common Lisp can only evolve at this point through ad hoc standards, with CFFI being the easiest and most obvious example of an emerging ad hoc standard. It's getting harder and harder to justify staying with vendor-specific FFI. To my way of thinking, emerging ad hoc standards are the most likely disruptive development that could change the status quo.
Obviously I can't say where the tipping point is, but I do believe that there is a tipping point where commoditization can occur. That's where I see a sanctioned process coming into play, and in my opinion a process like that would become essential.
|
