5 ms·

I do recall Norvig saying that they use C++ for a lot of core code because even though Lisp would be cheaper to develop, they run so many servers that any decre

I do recall Norvig saying that they use C++ for a lot of core code because even though Lisp would be cheaper to develop, they run so many servers that any decrease in efficiency would cost millions (can't find the quote though)

jrockway 18y ago
If making lisp run faster would save someone millions of dollars, lisp would run faster. Sure, it's practical for Google to use C++ in this case [1], but I am imagining a fantasy world. [1] Unless of course bugs that C++ ignores would be caught by Lisp. Perhaps there is a minor type error in Google's code that makes the search results not quite as good. If CL's type checker caught that, they would have gotten super-rich sooner and would own Microsoft right now. But like I said, this is all fantasy. My real argument is "You are not Google."
- silentbicycle 18y ago
  Making Lisp run faster would almost certainly involve making it closer to SML / OCaml. Beyond algorithmic changes, speed optimization in Lisp usually involves type declarations, or sometimes inference, as in ML. (See: http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf) Give Lisp a really powerful, inferred static type system and you're most of the way there. (Give it a better module system, while you're at it.) And if you want to talk about a type checker catching bugs... I wish OCaml had kept the s-expression syntax, but it's a very interesting (and powerful) take on improving Lisp. (I think it also helps that they don't call it Lisp. It flies under the radar as far as Lisp's reputation.)
  - jrockway 18y ago
    Making Lisp run faster would almost certainly involve making it closer to SML / OCaml. Indeed. I like Haskell as a compromise between OCaml and Lisp. OCaml's syntax is a bit too weird for me, and its type system is needlessly irritating (a different operator for integer and floating point addition?). You have given me a good idea, though -- compiling a Lisp into Haskell or OCaml. All the syntactic goodness of Lisp, all the strictness of the "host" language.
    - silentbicycle 18y ago
      Using different operators for ints and floats in OCaml is like making people use prefix notation for arithmetic in Lisp - you get used to it, but it can really annoy people new to the language, and some people never get over it (or forgive the language designer). (Messing with the syntax for basic arithmetic is all but trying to give a bad first impression, even though it may fit the overall language better. Smalltalk seems to have found a good middle path here.) I'm in the early stages of working on a synthesis between them, as well. Among many other things. I understand the appreciation for Haskell, but it's just not my thing. I really strongly prefer multi-paradigm languages. Instead of forcing me to do everything in pure functional code, I'd rather it just be able to tell if it's pure, and if so, optimize accordingly. Sometimes bending the language's rules a bit is a better idea than the language realizes, and what constitutes "good" code can change over time. No one programming paradigm or technique is the best match for every problem domain. OCaml is far from ideal, but it suits that style of coding pretty well. (Also, I prefer OCaml's syntax to Haskell's, though I might be the only one.) A language with OCaml's type and module sytems, Haskell's typeclasses (which could be built with macros on the existing type system, I think), Lisp's s-exps and clear specification of whether code at executed at read, compile, or run time, and Scheme's first-class continuations could be a great thing. (While we're dreaming, let's give it a standard library like Python's, a conceptual core as clean as Scheme, Smalltalk, Forth, or Lua's, and a runtime as small as Brainfuck's.)
      - lisper 18y ago
        > Using different operators for ints and floats in OCaml is like making people use prefix notation for arithmetic in Lisp - you get used to it Until the day when you have a large code base and you decide that something that you originally decided to make an an int really ought to be a float instead. Then you'll get unused to it again.
        silentbicycle 18y ago
        If you think your numeric type everywhere may change down the road, you could split out the operation and e.g. define let add = (+) and sub = (-) ... etc. and use those in your code, so you will only need to change them in one place, should you change your numeric type. Abstract out the operation. (Then you're back to using prefix notation.) Or, change it once, and let the compiler show you everywhere else it needs to be fixed. Haskell's type classes are a better overall solution for numeric types, of course. Not having a parallel to Haskell's deriving show in the OCaml standard is also annoying, but it's available elsewhere. (See: http://alan.petitepomme.net/cwn/2008.07.08.html#4 http://alan.petitepomme.net/cwn/2008.07.08.html#4) Still, most (though not all) numeric operations fit under either exact (int, bignum, ratio) or inexact (floats) without much ambiguity.

jrockway 18y ago

If making lisp run faster would save someone millions of dollars, lisp would run faster. Sure, it's practical for Google to use C++ in this case [1], but I am imagining a fantasy world. [1] Unless of course bugs that C++ ignores would be caught by Lisp. Perhaps there is a minor type error in Google's code that makes the search results not quite as good. If CL's type checker caught that, they would have gotten super-rich sooner and would own Microsoft right now. But like I said, this is all fantasy. My real argument is "You are not Google."

silentbicycle 18y ago
Making Lisp run faster would almost certainly involve making it closer to SML / OCaml. Beyond algorithmic changes, speed optimization in Lisp usually involves type declarations, or sometimes inference, as in ML. (See: http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf) Give Lisp a really powerful, inferred static type system and you're most of the way there. (Give it a better module system, while you're at it.) And if you want to talk about a type checker catching bugs... I wish OCaml had kept the s-expression syntax, but it's a very interesting (and powerful) take on improving Lisp. (I think it also helps that they don't call it Lisp. It flies under the radar as far as Lisp's reputation.)
- jrockway 18y ago
  Making Lisp run faster would almost certainly involve making it closer to SML / OCaml. Indeed. I like Haskell as a compromise between OCaml and Lisp. OCaml's syntax is a bit too weird for me, and its type system is needlessly irritating (a different operator for integer and floating point addition?). You have given me a good idea, though -- compiling a Lisp into Haskell or OCaml. All the syntactic goodness of Lisp, all the strictness of the "host" language.
  - silentbicycle 18y ago
    Using different operators for ints and floats in OCaml is like making people use prefix notation for arithmetic in Lisp - you get used to it, but it can really annoy people new to the language, and some people never get over it (or forgive the language designer). (Messing with the syntax for basic arithmetic is all but trying to give a bad first impression, even though it may fit the overall language better. Smalltalk seems to have found a good middle path here.) I'm in the early stages of working on a synthesis between them, as well. Among many other things. I understand the appreciation for Haskell, but it's just not my thing. I really strongly prefer multi-paradigm languages. Instead of forcing me to do everything in pure functional code, I'd rather it just be able to tell if it's pure, and if so, optimize accordingly. Sometimes bending the language's rules a bit is a better idea than the language realizes, and what constitutes "good" code can change over time. No one programming paradigm or technique is the best match for every problem domain. OCaml is far from ideal, but it suits that style of coding pretty well. (Also, I prefer OCaml's syntax to Haskell's, though I might be the only one.) A language with OCaml's type and module sytems, Haskell's typeclasses (which could be built with macros on the existing type system, I think), Lisp's s-exps and clear specification of whether code at executed at read, compile, or run time, and Scheme's first-class continuations could be a great thing. (While we're dreaming, let's give it a standard library like Python's, a conceptual core as clean as Scheme, Smalltalk, Forth, or Lua's, and a runtime as small as Brainfuck's.)
    - lisper 18y ago
      > Using different operators for ints and floats in OCaml is like making people use prefix notation for arithmetic in Lisp - you get used to it Until the day when you have a large code base and you decide that something that you originally decided to make an an int really ought to be a float instead. Then you'll get unused to it again.
      - silentbicycle 18y ago
        If you think your numeric type everywhere may change down the road, you could split out the operation and e.g. define let add = (+) and sub = (-) ... etc. and use those in your code, so you will only need to change them in one place, should you change your numeric type. Abstract out the operation. (Then you're back to using prefix notation.) Or, change it once, and let the compiler show you everywhere else it needs to be fixed. Haskell's type classes are a better overall solution for numeric types, of course. Not having a parallel to Haskell's deriving show in the OCaml standard is also annoying, but it's available elsewhere. (See: http://alan.petitepomme.net/cwn/2008.07.08.html#4 http://alan.petitepomme.net/cwn/2008.07.08.html#4) Still, most (though not all) numeric operations fit under either exact (int, bignum, ratio) or inexact (floats) without much ambiguity.