4 ms·

An analytic database like Vertica? A computer game with cutting-edge graphics? Etc.

• betterunix 14y ago
  Be careful about statements of the form, "That language is great, but it could not possibly be used for performance-critical code." There is nothing inherent to any of the languages I mentioned that makes them slow, and modern Lisp compilers can compete with C compilers on emitting fast code (and that is despite the fact that those compilers often lack some of the optimizations of C compilers; SBCL, for instance, has no peephole optimizer and it shows in the disassembly of compiled code). There is no reason why a Lisp program cannot access special hardware, use special CPU features via inline assembly, etc.
  • elliptic 14y ago
    < here is nothing inherent to any of the languages I mentioned that makes them slow. I don't agree. The inability to explicitly allocate on the stack in Java and OCaml? The lack of threads in OCaml? Java GC pauses (by the time you're storing things off-heap you might as well be writing C++)? I don't know as much about Lisp, but when looking at a task X, I tend to give the benefit of the doubt to languages (or frameworks, or hardware, or people, for that matter) that have actually achieved a measure of success at X.
    • gsg 14y ago
      Yep, that's the price of simplicity and safety. People talk a lot about stack allocation, but the same issue of pointerful vs flat representation arises in arrays and records, where it presents even more of a performance issue. Some GCed languages allow a measure of control there: however, Java and OCaml are not among them. People have tried to marry flat representation and safety while allowing things like passing pointers to stack-allocated objects. The results are distinctly baroque (complex notions of region, etc).