4 ms·

I don't see how this brings anything new to the ecosystem. Clojure is a LISP and we already have lfe (http://lfe.io/ http://lfe.io/) - LISP floured Erlang for q

I don't see how this brings anything new to the ecosystem. Clojure is a LISP and we already have lfe (http://lfe.io/ http://lfe.io/) - LISP floured Erlang for quiet a while now, hence it will definitely be more mature than a new implementation altogether. Moreover I feel, seeing the the currently more effort should be made in maturing the classic clojure implementation and the tooling around it itself, rather than diverting the community into fancy new (not so useful) ports of the same syntax for other runtimes. Seriously, just go improve clojure itself. And if you want to be able to write lisp for BEAM, just use lfe.

polityagent 7y ago
I don't think this implementation harms either Erlang or JVM clojure ecosystems. I also doubt the creator of this has as much interest in maturing JVM tooling as you so demand of them, if they did, they wouldn't have made this port. If this is inferior in every way to lfe then it will remain a niche project. If not, perhaps it will encourage some improvements either in lfe or Erlang itself (though I think the latter is unlikely).
keymone 7y ago
one does not simply say one lisp dialect is better than the other.
- ishankhare07 7y ago
  I never said one is better than the other. All I said is, if you want lisp on BEAM, you already have lfe.
  - keymone 7y ago
    > if you want lisp on BEAM, you already have lfe if you want lisp <insert condition>, you already have <insert lisp satisfying condition>. your assumed condition is wrong, a person may not just want lisp on beam, they may want clojure on beam.
    - ishankhare07 7y ago
      the only major difference I see between what you're calling 'clojure' and a lisp is that clojure compiles to JVM. That alone goes for a toss when you say you're porting it to BEAM. There is no more java in the equation. Its interop with erlang/elixir ecosystem. Which is exactly what lfe is (apart from some minute differences in syntax which may or may not be there).
      - keymone 7y ago
        > the only major difference I see between what you're calling 'clojure' and a lisp is that clojure compiles to JVM it's always better to ask than to make incorrect assumptions
clwk 7y ago
A quick plug for LFE and its very simple premise: in mortal fear of Rails, I embraced the potential of Elixir (with 100% more Phoenix); I had a wonderful test case for macros (can't even remember what it was anymore); I spent hours trying to craft it and fought, fought, fought the AST/syntax/complexity; finally, in anger remembered the mere existence of LFE and its promise of DEFMACRO. I wrote my first vaguely non-trivial LFE program as a macro in the REPL as a guess, and it worked on the first try. If I need a lisp in BEAM, I would run with LFE on that alone.
bitwize 7y ago
More to the point, Clojure is in 2020 the only Lisp that matters. If ypu want to develop a Lisp that attracts the attention of people who work on things that make actual money, your best bet is to port Clojure.

polityagent 7y ago

I don't think this implementation harms either Erlang or JVM clojure ecosystems. I also doubt the creator of this has as much interest in maturing JVM tooling as you so demand of them, if they did, they wouldn't have made this port. If this is inferior in every way to lfe then it will remain a niche project. If not, perhaps it will encourage some improvements either in lfe or Erlang itself (though I think the latter is unlikely).

keymone 7y ago

one does not simply say one lisp dialect is better than the other.

ishankhare07 7y ago
I never said one is better than the other. All I said is, if you want lisp on BEAM, you already have lfe.
- keymone 7y ago
  > if you want lisp on BEAM, you already have lfe if you want lisp <insert condition>, you already have <insert lisp satisfying condition>. your assumed condition is wrong, a person may not just want lisp on beam, they may want clojure on beam.
  - ishankhare07 7y ago
    the only major difference I see between what you're calling 'clojure' and a lisp is that clojure compiles to JVM. That alone goes for a toss when you say you're porting it to BEAM. There is no more java in the equation. Its interop with erlang/elixir ecosystem. Which is exactly what lfe is (apart from some minute differences in syntax which may or may not be there).
    - keymone 7y ago
      > the only major difference I see between what you're calling 'clojure' and a lisp is that clojure compiles to JVM it's always better to ask than to make incorrect assumptions

clwk 7y ago

A quick plug for LFE and its very simple premise: in mortal fear of Rails, I embraced the potential of Elixir (with 100% more Phoenix); I had a wonderful test case for macros (can't even remember what it was anymore); I spent hours trying to craft it and fought, fought, fought the AST/syntax/complexity; finally, in anger remembered the mere existence of LFE and its promise of DEFMACRO. I wrote my first vaguely non-trivial LFE program as a macro in the REPL as a guess, and it worked on the first try. If I need a lisp in BEAM, I would run with LFE on that alone.

bitwize 7y ago

More to the point, Clojure is in 2020 the only Lisp that matters. If ypu want to develop a Lisp that attracts the attention of people who work on things that make actual money, your best bet is to port Clojure.