3 ms·

> Edit: I meant to note that the reason the specification hasn't been updated, afaik, is because it doesn't have to be updated. All the tools you need to add th

> Edit: I meant to note that the reason the specification hasn't been updated, afaik, is because it doesn't have to be updated. All the tools you need to add the features you require are there in the spec. You can make it into the language you need. That's a big part of the reason I haven't used CL for anything bigger than some toy projects. It's a crusty, old language, and instead of keeping up with the times, everybody has to build the features they need. I can do that, or I can use language that has the features I need and that I don't have to assemble myself. And to make it worse, it's hard to even use libraries that solve the problem, because nobody in the CL community can agree on anything. There's always a dozen incompatible solutions, and it's never clear which one should be used.

pavelludiq 13y ago
" There's always a dozen incompatible solutions, and it's never clear which one should be used." Welcome to software. While your other sentiment seems logical, if you actually look at it as a lisp practitioner, you'll find the answers to the questions you have relatively easy. You don't have to "update" the language, for many things you can just use it like any other. The problem isn't that lisp isn't updated, but that there aren't enough of us to build the lisp django, or at least there aren't enough of us who want the lisp django for it to happen, so thats why web development in lisp is limited to using raw hunchentoot or microframeworks like Restas and Caveman/Clack(which are both pretty awesome btw). Other than a few minor tweaks, lisp really doesn't need updating. More/better libraries would be sufficient! Can you give a couple of specific examples where you think lisp is behind the times and you are "forced" to implement whatever. I can think of maybe a handful of such instances(there isn't a really great STM, but we do have other awesome concurrency options as just one example), but the list of lisp features I miss in python(my day job) is 1-2 dozens at least(and If I had macros and CLOS I could probably half that list in a week or two :) In other words if you are crazy enough to use lisp for useful projects, the language will help you, maybe you haven't tried? Maybe you have and just had bad luck. Some domains(GUI programming for example) aren't as well supported for example. Others are pretty ok.
agentultra 13y ago
I don't really understand the, "crusty, old language," argument either. C++ became an ISO-certified specification in 1998 which is roughly around the same time that CL became an ANSI standardized language. We still use C in many systems for very valid reasons. However unlike the C++ and ANSI C standards, the CL specification left room for programmers to extend the language as they need it. Instead of waiting for decades of expensive committee debates and meetings as you do with C/C++/ECMAScript/etc the programmers using the language in the field can go ahead and add the features they need and implementors can fill the gaps between new OSs and hardware. How is that bad?
- jlarocco 13y ago
  It's bad because every implementation fills the gaps in their own incompatible way. And then instead of converging on the "best" solution, the community argues endlessly about each unique solution is the best. And it's also bad because CL is ancient and it's filled with things that simply don't make sense any more, or have been replaced by "better" solutions in every other language. Look at filename and filepath handling to see what I mean. 2 or 3 of the fields haven't been used in real systems in 20 or 30 years, yet they're kept around because they're in the unchanging CL standard.

pavelludiq 13y ago

" There's always a dozen incompatible solutions, and it's never clear which one should be used." Welcome to software. While your other sentiment seems logical, if you actually look at it as a lisp practitioner, you'll find the answers to the questions you have relatively easy. You don't have to "update" the language, for many things you can just use it like any other. The problem isn't that lisp isn't updated, but that there aren't enough of us to build the lisp django, or at least there aren't enough of us who want the lisp django for it to happen, so thats why web development in lisp is limited to using raw hunchentoot or microframeworks like Restas and Caveman/Clack(which are both pretty awesome btw). Other than a few minor tweaks, lisp really doesn't need updating. More/better libraries would be sufficient! Can you give a couple of specific examples where you think lisp is behind the times and you are "forced" to implement whatever. I can think of maybe a handful of such instances(there isn't a really great STM, but we do have other awesome concurrency options as just one example), but the list of lisp features I miss in python(my day job) is 1-2 dozens at least(and If I had macros and CLOS I could probably half that list in a week or two :) In other words if you are crazy enough to use lisp for useful projects, the language will help you, maybe you haven't tried? Maybe you have and just had bad luck. Some domains(GUI programming for example) aren't as well supported for example. Others are pretty ok.

agentultra 13y ago

I don't really understand the, "crusty, old language," argument either. C++ became an ISO-certified specification in 1998 which is roughly around the same time that CL became an ANSI standardized language. We still use C in many systems for very valid reasons. However unlike the C++ and ANSI C standards, the CL specification left room for programmers to extend the language as they need it. Instead of waiting for decades of expensive committee debates and meetings as you do with C/C++/ECMAScript/etc the programmers using the language in the field can go ahead and add the features they need and implementors can fill the gaps between new OSs and hardware. How is that bad?

jlarocco 13y ago
It's bad because every implementation fills the gaps in their own incompatible way. And then instead of converging on the "best" solution, the community argues endlessly about each unique solution is the best. And it's also bad because CL is ancient and it's filled with things that simply don't make sense any more, or have been replaced by "better" solutions in every other language. Look at filename and filepath handling to see what I mean. 2 or 3 of the fields haven't been used in real systems in 20 or 30 years, yet they're kept around because they're in the unchanging CL standard.