4 ms·

> I can do easy prototyping in python; safe, functional code in haskell; serious multiprocessing in erlang; fast tight-loops in c; nice oo in either python, c#

by geocar 17y ago

> I can do easy prototyping in python; safe, functional code in haskell; serious multiprocessing in erlang; fast tight-loops in c; nice oo in either python, c# or java, etc. etc. Why exactly should I spend more time with lisp? Because I can do easy prototyping in lisp; safe, functional code in lisp; serious multiprocessing in lisp; fast tight-loops in c; nice oo in either lisp, lisp or lisp. If you find a problem that needs a new paradigm, you either need a new language, or you need lisp. > Python right now is basically lisp + community from what I can see. Python is a great language. It supports a lot of the most useful and powerful paradigms that lispers use, so many lispers like it and use it. But python is not "basically lisp", simply because it lacks the property I mentioned earlier.

viraptor 17y ago
By "safe" I meant "static type-safe" - sorry for the confusion. And no - can't do that in lisp. What do you mean by serious multiprocessing in lisp? Does it have a distributed database included? Or a node registration and message passing framework? Or a process control framework? Can it run my 10000 processes? Does it have portable networking and thread implementation where nothing ever blocks... Or did you mean that I can have for example the sbcl threading http://www.sbcl.org/manual/Threading.html http://www.sbcl.org/manual/Threading.html and can build all of that on my own? I could do the same in c... but I won't - erlang is better for that. I'd also argue with "nice oo in lisp"... for some values of "nice" :) For big projects I want a code browser / ide. I want types in my OO. I want the code to be structured in a way that makes the methods belong to classes. I don't want old-style message passing OO (not saying that it's bad... it's just not what is used these days in big projects). I want new-style enterprise-level OO with interfaces and self-commenting code where you write what you want to do, because every single person in your 100-person team has to understand it without any comments when you're not around. So everything that's left imho is easy prototyping. We can shoehorn every paradigm into any language - sure. But then you get something that can do everything and isn't good for anything in particular. If I learned lisp before python, I'd probably say the same thing about python... it's just not worth the additional attention, because they're both easy-prototyping languages, where you can promote the code into production when your first design is "good enough".
- PieSquared 17y ago
  Someone correct me if I'm wrong, but I think Common Lisp provides the ability to declare types of variables, and do type-checking on it. This allows you to make CL type-safe if you want to. It also allows a major speed up. The real problem I see with Lisp is that it lacks a vibrant community like Ruby and Python has, and is in some cases quite ugly. (Why, why use names like 'progn'? Why not the shorter, clearer 'do'? etc.) Clojure addresses that, but I get the feeling that Clojure is just an addon to Java and that you must use the Java lib in order to use Clojure; the integration between them seems to be to be a bit ugly, if easy to use. However, due to the size of the JVM base, Clojure is very good for production code - but strikes me as lacking the hack-hack quality you can get with CL. And only has one implementation. Aurgh! If only they didn't standardize CL. (Except, then it wouldn't exist at all right now, I bet.)
- geocar 17y ago
  > We can shoehorn every paradigm into any language - sure. But then you get something that can do everything and isn't good for anything in particular That doesn't necessarily follow, but it might very well be true. In addition to features, languages need speakers. Java is rarely regarded for its feature set, but it is certainly a "good" language in that it is good at something. The rest of your comment is largely drivel, compounded by the fact you simply don't know lisp well enough to think in lisp, and consequently have a meaningful conversation about what that means. Nevertheless, you somehow got the impression that I thought you should switch to lisp, and I sincerely apologize for that; I never meant that at all- only to express how knowing lisp is valuable. However, there was one thing in particular: > I don't want old-style message passing OO Most lisp programmers prefer CLOS-style OO which uses generic functions, and not message passing.
  - viraptor 17y ago
    Feel free to correct me - I hope to learn something new if you say exactly why you think my points are incorrect. Especially - why would you choose lisp over a specialised solution - static type safety, multiprocessing, oo being the main areas discussed. I don't claim to be an expert in lisp, as I mentioned before. What I wrote is based more on what I see, rather than what I work with every day and I appreciate other views even if don't agree :)
Locke1689 17y ago
Lisp does not, at the moment, have any truly practical implementation of multiprocessing. It also doesn't gather any of the lazy benefits of Haskell. It is worthless for prototyping as its modules haven't been up to date in 20 years. Edit: Gruseom is right, I was very critical without providing any support. Lisp is still very useful in certain cases. The instances which I find trouble with it are detailed in my second response.
- gruseom 17y ago
  Lisp does not, at the moment, have any truly practical implementation of multiprocessing. That would explain why there aren't any Lisp web servers. It is worthless for prototyping as its modules haven't been up to date in 20 years. Tell that to the people who are using it. Oh wait, I'm one of them. What you're saying here is such a crock that I have to wonder what your purpose is.
  - Locke1689 17y ago
    Fair, I was overly critical. For me, I find that it is far easier to find modules for Python than for Lisp. For example, the other day I was looking for a module to read and write ID3 tags. The only thing I could find for lisp was http://www.google.com/search?hl=en&client=safari&rls=en&q=lisp+id3+module&aq=f&oq=&aqi= http://www.google.com/search?hl=en&client=safari&rls..., which is buggy and incomplete. It didn't take very long to find a suitable Python module. As to multithreading, first since when is a web server the be-all-end-all of multiprocessing? Hell, you don't even need multithreading to do a webserver, just use Unix processes. My issue with Lisp is that there is no standard for multi-threaded Lisp; the ANSI spec doesn't consider threading at all. The Lisp community seems to be increasingly fractured over the years, which is too bad because I'm not insulting Lisp because I hate it -- it has just become too difficult to use as my generic do-everything language.
    - gruseom 17y ago
      Sorry for impugning your motivations. I lumped your comment in with the anti-CL canards that people keep repeating. Your ID3 tag library is a good example of the kind of thing one doesn't find much of in the CL world. On multithreading, though, I think you're off base. Modern CLs all support it, it works great, end of story. That it's not in the standard is a red herring; you simply look up what you need in the documentation for your Lisp instead of in the Hyperspec. Big deal. If you want to run on more than one Lisp, it's trivial: (defun spawn (name fn) #+ccl (ccl:process-run-function name fn) #+lispworks (mp:process-run-function name nil fn) #+sbcl (sb-thread:make-thread fn :name name)) I wouldn't use CL as a do-everything language either, but it's typically a superb place to be if you're trying to do anything complex.

by geocar 17y ago

viraptor 17y ago

By "safe" I meant "static type-safe" - sorry for the confusion. And no - can't do that in lisp. What do you mean by serious multiprocessing in lisp? Does it have a distributed database included? Or a node registration and message passing framework? Or a process control framework? Can it run my 10000 processes? Does it have portable networking and thread implementation where nothing ever blocks... Or did you mean that I can have for example the sbcl threading http://www.sbcl.org/manual/Threading.html http://www.sbcl.org/manual/Threading.html and can build all of that on my own? I could do the same in c... but I won't - erlang is better for that. I'd also argue with "nice oo in lisp"... for some values of "nice" :) For big projects I want a code browser / ide. I want types in my OO. I want the code to be structured in a way that makes the methods belong to classes. I don't want old-style message passing OO (not saying that it's bad... it's just not what is used these days in big projects). I want new-style enterprise-level OO with interfaces and self-commenting code where you write what you want to do, because every single person in your 100-person team has to understand it without any comments when you're not around. So everything that's left imho is easy prototyping. We can shoehorn every paradigm into any language - sure. But then you get something that can do everything and isn't good for anything in particular. If I learned lisp before python, I'd probably say the same thing about python... it's just not worth the additional attention, because they're both easy-prototyping languages, where you can promote the code into production when your first design is "good enough".

PieSquared 17y ago
Someone correct me if I'm wrong, but I think Common Lisp provides the ability to declare types of variables, and do type-checking on it. This allows you to make CL type-safe if you want to. It also allows a major speed up. The real problem I see with Lisp is that it lacks a vibrant community like Ruby and Python has, and is in some cases quite ugly. (Why, why use names like 'progn'? Why not the shorter, clearer 'do'? etc.) Clojure addresses that, but I get the feeling that Clojure is just an addon to Java and that you must use the Java lib in order to use Clojure; the integration between them seems to be to be a bit ugly, if easy to use. However, due to the size of the JVM base, Clojure is very good for production code - but strikes me as lacking the hack-hack quality you can get with CL. And only has one implementation. Aurgh! If only they didn't standardize CL. (Except, then it wouldn't exist at all right now, I bet.)
geocar 17y ago
> We can shoehorn every paradigm into any language - sure. But then you get something that can do everything and isn't good for anything in particular That doesn't necessarily follow, but it might very well be true. In addition to features, languages need speakers. Java is rarely regarded for its feature set, but it is certainly a "good" language in that it is good at something. The rest of your comment is largely drivel, compounded by the fact you simply don't know lisp well enough to think in lisp, and consequently have a meaningful conversation about what that means. Nevertheless, you somehow got the impression that I thought you should switch to lisp, and I sincerely apologize for that; I never meant that at all- only to express how knowing lisp is valuable. However, there was one thing in particular: > I don't want old-style message passing OO Most lisp programmers prefer CLOS-style OO which uses generic functions, and not message passing.
- viraptor 17y ago
  Feel free to correct me - I hope to learn something new if you say exactly why you think my points are incorrect. Especially - why would you choose lisp over a specialised solution - static type safety, multiprocessing, oo being the main areas discussed. I don't claim to be an expert in lisp, as I mentioned before. What I wrote is based more on what I see, rather than what I work with every day and I appreciate other views even if don't agree :)

Locke1689 17y ago

Lisp does not, at the moment, have any truly practical implementation of multiprocessing. It also doesn't gather any of the lazy benefits of Haskell. It is worthless for prototyping as its modules haven't been up to date in 20 years. Edit: Gruseom is right, I was very critical without providing any support. Lisp is still very useful in certain cases. The instances which I find trouble with it are detailed in my second response.

gruseom 17y ago
Lisp does not, at the moment, have any truly practical implementation of multiprocessing. That would explain why there aren't any Lisp web servers. It is worthless for prototyping as its modules haven't been up to date in 20 years. Tell that to the people who are using it. Oh wait, I'm one of them. What you're saying here is such a crock that I have to wonder what your purpose is.
- Locke1689 17y ago
  Fair, I was overly critical. For me, I find that it is far easier to find modules for Python than for Lisp. For example, the other day I was looking for a module to read and write ID3 tags. The only thing I could find for lisp was http://www.google.com/search?hl=en&client=safari&rls=en&q=lisp+id3+module&aq=f&oq=&aqi= http://www.google.com/search?hl=en&client=safari&rls..., which is buggy and incomplete. It didn't take very long to find a suitable Python module. As to multithreading, first since when is a web server the be-all-end-all of multiprocessing? Hell, you don't even need multithreading to do a webserver, just use Unix processes. My issue with Lisp is that there is no standard for multi-threaded Lisp; the ANSI spec doesn't consider threading at all. The Lisp community seems to be increasingly fractured over the years, which is too bad because I'm not insulting Lisp because I hate it -- it has just become too difficult to use as my generic do-everything language.
  - gruseom 17y ago
    Sorry for impugning your motivations. I lumped your comment in with the anti-CL canards that people keep repeating. Your ID3 tag library is a good example of the kind of thing one doesn't find much of in the CL world. On multithreading, though, I think you're off base. Modern CLs all support it, it works great, end of story. That it's not in the standard is a red herring; you simply look up what you need in the documentation for your Lisp instead of in the Hyperspec. Big deal. If you want to run on more than one Lisp, it's trivial: (defun spawn (name fn) #+ccl (ccl:process-run-function name fn) #+lispworks (mp:process-run-function name nil fn) #+sbcl (sb-thread:make-thread fn :name name)) I wouldn't use CL as a do-everything language either, but it's typically a superb place to be if you're trying to do anything complex.