3 ms·

So, it would take W hours to get Lisp working well. He will spend X hours writing and maintaining his python over the next Y years. And if he used Lisp instead,

by xlnt 18y ago

So, it would take W hours to get Lisp working well. He will spend X hours writing and maintaining his python over the next Y years. And if he used Lisp instead, after the initial W hour investment, he would save Z hours on less maintenance and coding time thanks to Lisp's power. Is Z greater than W, or less than W? That's the critical question for him. How can he decide which approach is best without estimating the hour values of each variable? Edit: of course there's some other issues. maybe he'd spend 80 hours on python maintenance vs 100 writing lisp unicode support. the numbers are made up, but the point is that maintenance probably isn't much fun, so one might choose the lisp path even if it takes a bit more time. besides fun, one might learn more that way.

cstejerean 18y ago
Why are you automatically assuming that the maintenance costs of a Lisp app are lower than of a Python app? Lisp as a concept is very powerful. The current dialects, their implementations, respective libraries and package management systems on the other hand have often gotten in my way. For example take a look at http://article.gmane.org/gmane.lisp.cclan.general/807 http://article.gmane.org/gmane.lisp.cclan.general/807
- xlnt 18y ago
  More powerful language -> shorter, DRYer code -> less maintenance. (Plus a few other reasons. See PG's essays, PG's Lisp books, and SICP if you don't know the other reasons.) If you don't believe this, don't use Lisp. The guy writing the article does seem to believe it. He likes and respects Lisp. So he ought to analyze in the way I said.
  - sunkencity 18y ago
    So it's lack of faith that is his problem? But yeah I agree with you, the more powerful the language, the shorter code you can write. Though python is a pretty powerful language in it's own right, it's got a repl console and sweet little list comprehensions and more, so is the difference really that great between python and lisp? Python is not assembler after all. To know that I suppose I should have to learn lisp myself, which I haven't had the time to do yet. Surrounded by java zealots at work as I am though, and that clojure seems to be the best working non-statically typed language on the JVM I just might. The issue with utf-8 seems to be solved by now from reading the comments around here. But there are always problems working with utf-8 with libraries written by people that have never needed to work on non-ascii text, the code has simply not been tested thoroughly on the problem of working with utf-8 text so while it might be production quality regarding to ASCII there are weird bugs that pop out of the woodwork when working with musical notes. On a related note: I've written a few programs in ruby where I've really run into trouble not having decent unicode support in the language. With iconv you can easily make it work if you are working with characters that map to an 8-bit character set. But if you are working with characters that map to several european languages at once, and need the euro symbol, you're in the cold. You can have utf-8 strings in ruby yes, but if you pry them apart, or make changes to them, they loose their utf-8:ness and look like shit. This is an issue that should really be solved at language level, if you don't want to have roughly similar the same abstraction level dealing with strings as you have in C. I love ruby, but I hate working with utf-8 strings in it just now.
    - xlnt 18y ago
      > unicode is an issue that should really be solved at language level with lisp, you don't need anything to be built in "at the language level" because you can modify the language much better than with python or ruby. many "built-in" lisp features, that would be language-level in other languages, are just built-in macros, and you could have written them yourself exactly the same. for example, loops are done this way.
      - gaius 18y ago
        What you say is true, of course, but at the same time it's true of any Turing-complete languages, and therefore, meaningless. I'm not a bad engineer because I don't have time to start every project from the bare metal. Runtime and libraries make a huge difference in the real world. Sure I'd love to spend the time really diving deep and making LISP into the perfect DSL for me, but the truth is, I can just use Python and go.
        xlnt 18y ago
        it's not the same in any turing-complete language. lisp makes adding new "language level features" easy, and python makes it hard. i'm not saying you should always use lisp for everything. but for this particular issue lisp has a major advantage.

by xlnt 18y ago

cstejerean 18y ago

Why are you automatically assuming that the maintenance costs of a Lisp app are lower than of a Python app? Lisp as a concept is very powerful. The current dialects, their implementations, respective libraries and package management systems on the other hand have often gotten in my way. For example take a look at http://article.gmane.org/gmane.lisp.cclan.general/807 http://article.gmane.org/gmane.lisp.cclan.general/807

xlnt 18y ago
More powerful language -> shorter, DRYer code -> less maintenance. (Plus a few other reasons. See PG's essays, PG's Lisp books, and SICP if you don't know the other reasons.) If you don't believe this, don't use Lisp. The guy writing the article does seem to believe it. He likes and respects Lisp. So he ought to analyze in the way I said.
- sunkencity 18y ago
  So it's lack of faith that is his problem? But yeah I agree with you, the more powerful the language, the shorter code you can write. Though python is a pretty powerful language in it's own right, it's got a repl console and sweet little list comprehensions and more, so is the difference really that great between python and lisp? Python is not assembler after all. To know that I suppose I should have to learn lisp myself, which I haven't had the time to do yet. Surrounded by java zealots at work as I am though, and that clojure seems to be the best working non-statically typed language on the JVM I just might. The issue with utf-8 seems to be solved by now from reading the comments around here. But there are always problems working with utf-8 with libraries written by people that have never needed to work on non-ascii text, the code has simply not been tested thoroughly on the problem of working with utf-8 text so while it might be production quality regarding to ASCII there are weird bugs that pop out of the woodwork when working with musical notes. On a related note: I've written a few programs in ruby where I've really run into trouble not having decent unicode support in the language. With iconv you can easily make it work if you are working with characters that map to an 8-bit character set. But if you are working with characters that map to several european languages at once, and need the euro symbol, you're in the cold. You can have utf-8 strings in ruby yes, but if you pry them apart, or make changes to them, they loose their utf-8:ness and look like shit. This is an issue that should really be solved at language level, if you don't want to have roughly similar the same abstraction level dealing with strings as you have in C. I love ruby, but I hate working with utf-8 strings in it just now.
  - xlnt 18y ago
    > unicode is an issue that should really be solved at language level with lisp, you don't need anything to be built in "at the language level" because you can modify the language much better than with python or ruby. many "built-in" lisp features, that would be language-level in other languages, are just built-in macros, and you could have written them yourself exactly the same. for example, loops are done this way.
    - gaius 18y ago
      What you say is true, of course, but at the same time it's true of any Turing-complete languages, and therefore, meaningless. I'm not a bad engineer because I don't have time to start every project from the bare metal. Runtime and libraries make a huge difference in the real world. Sure I'd love to spend the time really diving deep and making LISP into the perfect DSL for me, but the truth is, I can just use Python and go.
      - xlnt 18y ago
        it's not the same in any turing-complete language. lisp makes adding new "language level features" easy, and python makes it hard. i'm not saying you should always use lisp for everything. but for this particular issue lisp has a major advantage.