3 ms·

Agree. Either choose to use lisp syntax and lisp macros or add all the language "features" ad-hoc one by one over the years.

• yoz-y 6y ago
  That is stretching the quote fairly thin. Programming in Swift is nothing like programming in Lisp on many levels.
  • raspasov 6y ago
    >> Programming in Swift is nothing like programming in Lisp on many levels. Precisely. "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
  • blacktriangle 6y ago
    Eh its kind of an interesting question. Where is the line between what should be a language feature and what should be a macro. At the extreme arguing a feature should not be part of the language and be a library does translate to advocating lisp for everything. But concurrency is a really interesting case. Concurrency solutions are highly specific. I think we'd all agree there is no "answer" for concurrency, which puts it square in the library category. And there are consequences to getting your language's concurrency solution wrong. For example, I'd point to Clojure's built-in STM as a huge swing-and-a-miss. Otoh Erlang is the poster child for why doing concurrency right really does require language-level support. What's the way out? Imo either build your language around concurrency from day 1, ie Erlang, Go, Pony, or accept that concurrency will always be a best effort good-enough solution in your language.