5 ms·

"The reason Cell was designed to be a domain-specific language, and its compiler to be a code generator, should be obvious. Choosing the main language for your

"The reason Cell was designed to be a domain-specific language, and its compiler to be a code generator, should be obvious. Choosing the main language for your application has usually more to do with the tools, libraries and support that are available for it than it has with the language itself, and one generally has to be, by necessity, very conservative there. But a domain-specific language that integrates with your primary language, instead of replacing it, stands a much better chance of actually being useful, as it can be adopted gradually, and only when, and to the extent that, it provides a clear advantage. It's just another tool in your toolbox. " That's a really interesting way of thinking about it.

kelnos 9y ago
This is definitely a plus, but it still doesn't get you all the way: if my IDE/editor of choice doesn't support syntax highlighting, autocompletion, error highlighting, jump-to-definition, etc. for Cell itself, then it's still difficult to integrate into my workflow.
chubot 9y ago
It's also the philosophy behind Clojure and why it's tied to the JVM: https://clojure.org/about/jvm_hosted https://clojure.org/about/jvm_hosted Rich Hickey had said this is a purposeful decision and not a matter of expediency.
- thomastjeffery 9y ago
  Unfortunately also why I haven't bothered to learn Clojure yet. I would really like to see a Clojure that targets LLVM.
  - dkersten 9y ago
    In my opinion that's not a great reason for not trying clojure (although it may be a great reason for not using clojure). Then again, if all you do is native work, then clojure is likely a bad fit in its current form.
    - thomastjeffery 9y ago
      I suppose a better phrase is, "I haven't had an interest in Clojure apart from the language itself, and dealing with the JVM and toolchain is something I find frustrating enough that I have chosen not to dive into Clojure yet." My limited experience with the Java toolchain is that it's unnecessarily difficult to use outside of an IDE (classpaths, etc.), and using Clojure on top of it is even more difficult. My experience is that most people who create tools for the Java ecosystem are quite content with having a bulky mess of tools, and consider IDEs (and nothing else) to be the gold-standard. It's just something that I'd rather not contend with, even though Clojure (and Clojurescript, which suffers from the same problems) as a language sounds quite nice.
      - dkersten 9y ago
        Outside of the initial installation (brew install or apt-get install or whatever you use), you really don't have to deal with the JVM ecosystem or classpaths unless you interop with Java stuff (in which case, you'd be using JVM anyway). Leiningen (and boot) isolate you from all of that. I've been using Clojure since 09 and I don't remember the last time I even had to think about a classpath. I also use vim (and more recently, spacemacs) and not an IDE. Its not an issue in Clojure. Although, I agree with you on the JVM in general and can see how its a reasonably assumption, even if not actually true.
  - baldfat 9y ago
    Well you could look at Rhine which is Clojure inspired on LLVM. https://github.com/artagnon/rhine-ml https://github.com/artagnon/rhine-ml Personally I still love Racket and think that is the LISP of the future. Racket's number one enemy is it is fun and so everyone likes come up with their own solution. Here is one binding to LLVM from 6 years ago. https://github.com/endobson/racket-llvm https://github.com/endobson/racket-llvm
    - thomastjeffery 9y ago
      > Personally I still love Racket and think that is the LISP of the future. I agree. It seems quite likely that the next "hundred-year language" will either be racket itself, or live in racket's ecosystem. That, or something like red[0] [0](http://www.red-lang.org/ http://www.red-lang.org/)

kelnos 9y ago

This is definitely a plus, but it still doesn't get you all the way: if my IDE/editor of choice doesn't support syntax highlighting, autocompletion, error highlighting, jump-to-definition, etc. for Cell itself, then it's still difficult to integrate into my workflow.

chubot 9y ago

It's also the philosophy behind Clojure and why it's tied to the JVM: https://clojure.org/about/jvm_hosted https://clojure.org/about/jvm_hosted Rich Hickey had said this is a purposeful decision and not a matter of expediency.

thomastjeffery 9y ago
Unfortunately also why I haven't bothered to learn Clojure yet. I would really like to see a Clojure that targets LLVM.
- dkersten 9y ago
  In my opinion that's not a great reason for not trying clojure (although it may be a great reason for not using clojure). Then again, if all you do is native work, then clojure is likely a bad fit in its current form.
  - thomastjeffery 9y ago
    I suppose a better phrase is, "I haven't had an interest in Clojure apart from the language itself, and dealing with the JVM and toolchain is something I find frustrating enough that I have chosen not to dive into Clojure yet." My limited experience with the Java toolchain is that it's unnecessarily difficult to use outside of an IDE (classpaths, etc.), and using Clojure on top of it is even more difficult. My experience is that most people who create tools for the Java ecosystem are quite content with having a bulky mess of tools, and consider IDEs (and nothing else) to be the gold-standard. It's just something that I'd rather not contend with, even though Clojure (and Clojurescript, which suffers from the same problems) as a language sounds quite nice.
    - dkersten 9y ago
      Outside of the initial installation (brew install or apt-get install or whatever you use), you really don't have to deal with the JVM ecosystem or classpaths unless you interop with Java stuff (in which case, you'd be using JVM anyway). Leiningen (and boot) isolate you from all of that. I've been using Clojure since 09 and I don't remember the last time I even had to think about a classpath. I also use vim (and more recently, spacemacs) and not an IDE. Its not an issue in Clojure. Although, I agree with you on the JVM in general and can see how its a reasonably assumption, even if not actually true.
- baldfat 9y ago
  Well you could look at Rhine which is Clojure inspired on LLVM. https://github.com/artagnon/rhine-ml https://github.com/artagnon/rhine-ml Personally I still love Racket and think that is the LISP of the future. Racket's number one enemy is it is fun and so everyone likes come up with their own solution. Here is one binding to LLVM from 6 years ago. https://github.com/endobson/racket-llvm https://github.com/endobson/racket-llvm
  - thomastjeffery 9y ago
    > Personally I still love Racket and think that is the LISP of the future. I agree. It seems quite likely that the next "hundred-year language" will either be racket itself, or live in racket's ecosystem. That, or something like red[0] [0](http://www.red-lang.org/ http://www.red-lang.org/)