death wrote:I guess I should have been more specific about what I wanted to know. I wanted to know about the details of your particular case, i.e. what implementation you chose to use, what libraries you had trouble with, what that trouble was, how far did you go before you decided to use Ruby, why didn't you have that trouble using Ruby, etc.
I wanted to know why you think standardization, with all its costs and constraints, is the way to solve the problems you faced. That assuming, of course, that you are aware of these costs and constraints, and I am not just talking about the costs of setting up a committee of interested Lisp users and vendors to propose, argue for and against, and ultimately compromise on a non-innovative set of modifications to the current standard. I am also talking about the costs to the users and implementers, who are supposed to integrate these modifications with their current code and knowledge-base. Do you think standardization is a viable idea at all? Who will pay for this effort? Everyone maintaining Lisp code, given that enough are willing to pay for it - but are they? is it worth paying for? Keep in mind that your answer is only part of the equation.
You see, I very much doubt that standardization is the answer to your problems. If you gave concrete details about your problem situation, maybe we could re-examine it and come up with more realistic and less costly solutions (hopefully not involving switching to a different language - Ruby or NewCL).
findinglisp wrote:So, in summary, I like Lisp. But Lisp, and Lisp advocates, need to stop apologizing for the language and just get on with it. As soon as Lisp becomes easier to use than Ruby and Python, it will rule the world. Of that, I have no doubt. Until then, anybody looking to implement an application will end up taking the path of least resistance, and depending on the application, that might be something other than Lisp.
findinglisp wrote:There are many types of "standardization," some light weight, some heavyweight. I do not think that heavyweight standardization (going back to ISO to update the CL spec, for instance) is the right way to do things. It's far too slow and expensive, as you rightly point out. I'd much rather see a couple of implementations get together and hammer out the issues and get it done. You don't need perfect agreement, only critical mass. Market share can make up that critical mass, too. Essentially, you just need to separate the world of implementations into "those that are leading" and "those that are following." If the "weight" of the leaders is sufficient, then people writing libraries and such will naturally gravitate that direction.
But make no mistake, I have no desire to revisit my decision toward Ruby or work around things on the Lisp side. Instead of diagnosing my individual situation, let's just get on with correcting Lisp deficiencies. Lisp is a great language. It just needs to stop apologizing for its deficiencies and start competing in the market.
So, in summary, I like Lisp. But Lisp, and Lisp advocates, need to stop apologizing for the language and just get on with it. As soon as Lisp becomes easier to use than Ruby and Python, it will rule the world. Of that, I have no doubt. Until then, anybody looking to implement an application will end up taking the path of least resistance, and depending on the application, that might be something other than Lisp.
JamesF wrote:I've been mulling over this batteries-included thing for a few days, and thinking in particular on the comments about standardisation. I see a potential solution, albeit not a trivial or quickly-completed one. You're right in that lightweight standardisation is the way to go: figure out which libraries do play nice together, and hope like hell we have critical mass. Failing that, figure out where we're short of critical mass, and see what needs doing to get us there. I haven't sufficient cluefulness to help out with networking or threading libraries, but now that I've accumulated a few clues, should be able to help around the edges.
A certain degree of fascism may be needed among the leaders, taking the stance of "here's the standard set of implementations and libraries. Use the others as you will, but these are what we're using as common ground." I'm guessing that SBCL, ACL and Lispworks will be the main implementations, plus whatever's working best on Windows (not meaning to be dismissive of the implementations, I just don't use Windows so don't know). I expect it'll be Common Lisp all over again, being politics rather than art, but like CL, might just work well enough to concentrate the efforts. Ideally, we'll wind up with a set of libraries and implementations that can be mixed and matched at will, which is what Perl, Python and Ruby have as a major advantage.
Now I'll throw in my own main grievance: it's wonderful to have all these libraries available for download, it really is. But it'd be so much nicer to know which version we're downloading, especially when you're trying to maintain consistency. I have to maintain my own repositories just to know which versions I'm dealing with. "It's the latest" isn't quite as helpful as it might be, and doesn't tell me whether it's later than the "latest" version I downloaded three months ago. I may be missing something, but I'm pretty sure I also can't define an ASDF config file that tells ASDF-install to pull and load dependencies whose versions either match specific values, or fall within a certain range. That's my next project after lisp-php, right?
dlweinreb wrote:By the way, I'd like to respectfully point out that using a sarcastic tone to answer questions from beginners is not such a good idea. One of the reasons people are repelled from using Lisp is that they get the feeling that the community is hostile and unhelpful.
dlweinreb wrote:Doesn't cater to beginners: In what way is it harder for beginners
than Python or Ruby? It's easier for beginners than C or Java, in my
opinion, because of its interactive nature: you can just start typing
expressions. And these days there are many good textbooks, such as
"Practical Common Lisp". Common Lisp isn't nearly as hard to learn
as most people think.
Balooga wrote:Newbies are able to install the free implementation of Python or Ruby in Windows in a couple of clicks. The same newbies try to install a free CL implementation in Windows and spend the next day trying to get Emacs working with Slime and SBCL/CLISP.
Balooga wrote:And then another day or two trying to get ASDF-INSTALL working because newbies are told that most libraries are packaged for ASDF, not knowing that actually getting ASDF-INSTALL to work in Windows is an exercise in futility. And then finally give up.
Users browsing this forum: No registered users and 1 guest