11 ms·

5 posts about various lisps have reached the top today. If lisp is so awesome and people end up building lisps on top of Rust and everything else, why do we nee

5 posts about various lisps have reached the top today. If lisp is so awesome and people end up building lisps on top of Rust and everything else, why do we need non-lisp languages like Rust itself anyway?

oblio 6y ago
> If lisp is so awesome and people end up building lisps on top of Rust and everything else, why do we need non-lisp languages like Rust itself anyway? Building Lisps on top of anything is extremely rare, especially in commercial environments.
- giancarlostoro 6y ago
  Emacs and every Emacs developers custom elisp setups would like to have a word with you. Of course, I'm not entirely sure of another example of mass adoption of Lisp in a commercial setting outside of Hacker News if you consider this setup commercial. I would argue HN definitely provides value back to YC by bringing plenty of exposure to their startups, but in all honesty I don't think a single soul on HN would complain against it, considering the alternative is much worse.
  - oblio 6y ago
    How is your comment contradicting mine? Emacs is 1 out of hundreds if not thousands of editors out there.
    - giancarlostoro 6y ago
      Why does mine have to contradict yours? I'm just saying, there's people who've used Emacs for 30 plus years to be productive.
- omnicognate 6y ago
  It's common, including in "commercial environments" - eg. I've seen multiple things that would qualify as "lisps" built in banks. Why? Probably because they are easy to make and extremely expressive given that limited effort. Is making an expressive custom language with no tooling to solve a single problem a good idea? Nope. Do people do it anyway? Yes. Edit: And never forget Greenspun's 10th rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
  - oblio 6y ago
    > Edit: And never forget Greenspun's 10th rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Maybe it's time to put this to rest? The rule is 27 years old and I'd be shocked if something like the .Net BCL (for example) is not bigger than Common Lisp, these days. And I'm not sure we can get a consensus that the .Net BCL can be considered "ad hoc, informally-specified, bug-ridden, slow implementation". That rule comes from a time when half the software written was still writing its own string and linked list data structures/classes. Now people just use standard libraries.
MisterTea 6y ago
This is a good point. The intro to gamelisp reads like so: > Rust is my favourite programming language. It has impeccable performance, an expressive and powerful type system, and a great community. > However, when it comes to game development, Rust has a few well-known problems. Compile times are painfully slow, and the type system can sometimes feel rigid or bureaucratic. When adding a new feature to a game, you'll often need to write code in a messy, fast, exploratory fashion - and in those cases, Rust can be a hindrance rather than a help. Having to bolt a programming language from 1958 to your hip new language du jore to make it easier to use doesn't exactly make a good case for using it.
- nimih 6y ago
  It's almost as though programming language design is full of trade-offs, and that building a game engine and building a game within that same engine are different enough tasks that they have radically different requirements w/r/t those trade-offs.

oblio 6y ago

> If lisp is so awesome and people end up building lisps on top of Rust and everything else, why do we need non-lisp languages like Rust itself anyway? Building Lisps on top of anything is extremely rare, especially in commercial environments.

giancarlostoro 6y ago
Emacs and every Emacs developers custom elisp setups would like to have a word with you. Of course, I'm not entirely sure of another example of mass adoption of Lisp in a commercial setting outside of Hacker News if you consider this setup commercial. I would argue HN definitely provides value back to YC by bringing plenty of exposure to their startups, but in all honesty I don't think a single soul on HN would complain against it, considering the alternative is much worse.
- oblio 6y ago
  How is your comment contradicting mine? Emacs is 1 out of hundreds if not thousands of editors out there.
  - giancarlostoro 6y ago
    Why does mine have to contradict yours? I'm just saying, there's people who've used Emacs for 30 plus years to be productive.
omnicognate 6y ago
It's common, including in "commercial environments" - eg. I've seen multiple things that would qualify as "lisps" built in banks. Why? Probably because they are easy to make and extremely expressive given that limited effort. Is making an expressive custom language with no tooling to solve a single problem a good idea? Nope. Do people do it anyway? Yes. Edit: And never forget Greenspun's 10th rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
- oblio 6y ago
  > Edit: And never forget Greenspun's 10th rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Maybe it's time to put this to rest? The rule is 27 years old and I'd be shocked if something like the .Net BCL (for example) is not bigger than Common Lisp, these days. And I'm not sure we can get a consensus that the .Net BCL can be considered "ad hoc, informally-specified, bug-ridden, slow implementation". That rule comes from a time when half the software written was still writing its own string and linked list data structures/classes. Now people just use standard libraries.

MisterTea 6y ago

This is a good point. The intro to gamelisp reads like so: > Rust is my favourite programming language. It has impeccable performance, an expressive and powerful type system, and a great community. > However, when it comes to game development, Rust has a few well-known problems. Compile times are painfully slow, and the type system can sometimes feel rigid or bureaucratic. When adding a new feature to a game, you'll often need to write code in a messy, fast, exploratory fashion - and in those cases, Rust can be a hindrance rather than a help. Having to bolt a programming language from 1958 to your hip new language du jore to make it easier to use doesn't exactly make a good case for using it.

nimih 6y ago
It's almost as though programming language design is full of trade-offs, and that building a game engine and building a game within that same engine are different enough tasks that they have radically different requirements w/r/t those trade-offs.