4 ms·

I'm very excited for Jank, I wish the creator well. If I could make one tiny plea, it would be to focus on tooling too, and ensuring the experience for someone

by troad 2y ago

I'm very excited for Jank, I wish the creator well. If I could make one tiny plea, it would be to focus on tooling too, and ensuring the experience for someone trying Jank out is as smooth as possible. Don't assume everyone is already set up with paredit and can fire off emacs chords without a thought. I suspect that Jank will be of particular interest to C++ programmers, many of whom are used to a very different dev paradigm. The Clojure community has done a great job at trying to smooth out the rough edges of Lisp tooling, and ensure there are on-ramps for newcomers (e.g. things like Calva for VS Code). I hope Jank keeps this up, because those first impressions really do matter. I'd hate to watch people bounce off Jank because they get stuck on trying to figure emacs out, or because they get frustrated trying to keep parentheses matched in Notepad.

roenxi 2y ago
This seems like an opportunity to plug the good work https://www.clojuriststogether.org/ https://www.clojuriststogether.org/ do. They do good work. Plug concludes. Clojure - like many languages - seems to be benefiting a lot from the work the IDE people have been putting in to good infrastructure. A lot of the magic is being moved out of Emacs towards tools like Treesitter and the LSP server which are more platform independent. Not a huge amount to do with Clojure per say, but the Clojure ecosystem is benefiting a lot from it. The Emacs specific stuff is becoming very Emacs-specific (like paraedit, bless its socks).
- diggan 2y ago
  I think Clojure has benefit way more from nRepl and everything in that ecosystem, than LSP and that newfangled stuff, at least my personal setup relies on nRepl and doesn't even use LSP afaik.
- waffletower 2y ago
  I am wary of LSP. I should try LSP again using eastwood, which probably has its trade-offs. While I absolutely admire Borkdude's many gifts to the Clojure community, the lack of static analysis in clj-kondo is a non-starter for me -- macro support is painfully manual. Because of its speed, clj-kondo likely is more performant in an editor LSP context, but too opinionated for me.
  - iLemming 2y ago
    I don't know what you're talking about; it feels to me like you're complaining that your camel isn't a Ferrari. Clojure is inherently very dynamic - fully automatic static analysis of Clojure code is extremely difficult. Not just Clojure - any other Lisp too. Do you think that for almost four decades of Emacs Lisp existence, nobody built a deep static analysis tool only because people were just stupid, lazy, or had no incentives? Kondo is actually considered the best-in-class tool for Clojure linting/analysis, and its manual macro configuration is a practical compromise given the language's design. > macro support is painfully manual. If programming was effortless, I would have no job, I bet you wouldn't have either.
Jeaye 2y ago
You're absolutely right. To start with, I'm focusing on capturing and converting existing Clojure devs. However, there's a very large pool of C++ devs who could benefit from jank. As you said, jank not only needs to be ready for them, they need to be educated on lisps, functional programming, data-oriented programming, REPL-based interactive development, etc. It's not an easy learning curve right now, into Clojure. I aim to focus a good deal of time, post jank's launch, to create materials which enable this. Materials specifically targeted at OOP devs coming from the native space.
- lincpa 2y ago
  [dead]
- butterisgood 2y ago
  I can imagine Jank being incredible “glue” to start until it takes over by osmosis. (For c++ of course) Maybe I should play some advent of code games with it to get comfy!
- vlovich123 2y ago
  As someone who might be in your target demographic in theory but not familiar with Clojure, what capabilities does Clojure itself offer as a language that a different mainstream scripting language doesn’t? For example, I’ve always thought that the interesting part of Erlang is Beam & the uninteresting part was a niche language. Beam with JS as the language is much more approachable & leverages a rich existing ecosystem of tooling & libraries. Indeed, if you look at it the right way Cloudflare Workers is exactly that; isolated virtual processes within a single OS process that communicate with each other using a message based IPC & if they crash just the microservice is taken down & transparently relaunched. So from that perspective, why Clojure instead of the same features on a different more popular language?
  - ndr 2y ago
    It's hard to describe what immutable/persistent data structures do to your thinking. A lot of responsibilities move to the edges and you're left being able to think and tests pieces of code in isolation. The repl becomes usable, and you code from inside your running program. It's a steep step to get started but it's going to transform how you think about some problems.
ab5tract 2y ago
The “use emacs” prerequisite that shows up frequently when exploring Lisps has been such a dealbreaker for me in the past. I have no patience for learning “chords” or even using a non-modal-but-still-not-just-normal-input editor simply to explore a language. My impression being that these chords morph depending on “modes” doesn’t help at all. At least with vim you can learn a piece at a time (sorry, not trying to revive last century’s favorite flame war, but it’s true). Also: no one has managed to explain to me what makes emacs so uniquely capable of interacting with a running interpreter, despite this usually being the USP I hear for “needing” emacs when attempting to Lisp.
- pritambaral 2y ago
  > Also: no one has managed to explain to me what makes emacs so uniquely capable of interacting with a running interpreter, despite this usually being the USP I hear for “needing” emacs when attempting to Lisp. As an Emacs user that has to work in teams of non-Emacs users, the answer to this boils down to culture and ecosystem maturity. Purely technically, there's nothing that Emacs allows me to do with REPL Driven Development that _couldn't _ be done in another editor. Practically? I still haven't been able to even get (sufficiently) started with any editor. I often have to work on a Rails codebase that takes tens of seconds just to start. Dev cycles in the traditional Edit-Restart flow were so painful that I wished badly to burn this codebase down and rewrite it all in a language and style that supports a Lisp-style REPL. Then I discovered inf-ruby.el in Emacs. It allows me to just edit the code and reload only what's changed. It automatically inserts the correct `module Xyz; ...; end` etc. No more restarts. I showed it to my coworkers. They shared the pain with restarts. And yet, to this day, none of them have an equivalent to inf-ruby in their editors. inf-ruby.el is less than 1400 lines of code. It's easy enough to implement in Vim, IntelliJ, VS Code, anything really. But it exists only in Emacs, so far. Why? I'm sure because some Emacs user, once upon a time, wished similarly to have a more Lispy REPL for their Ruby dev work, and just built it. Because they were used to it, from having used Emacs or other Lisps with Emacs. Compare that to when I first tried to support Common Lisp development on VS Code. A language that already has full support for REPL Driven Development with an interactive debugger built-in. Nope, we aren't gonna use any of that, because in VS Code land, we use LSP. A model that really only works for languages that can be statically analyzed. You want Go To Definition on a method that's included from a module and called on a receiver that's a dynamic variable? Well, sucks to be you, I guess. So, while people make do with the severe limitations of Solargraph or Ruby-LSP, I use robe.el — which adds lisp style code intelligence by running inside your Ruby process — and get code intelligence that actually works with a language as dynamic as Ruby. Again, robe.el was just there for me to use. Again, there's nothing about Emacs that makes robe.el possible in Emacs but not in other editors. Again, there's no equivalent to it (that I've found) in the ecosystems of other editors.

by troad 2y ago

roenxi 2y ago

This seems like an opportunity to plug the good work https://www.clojuriststogether.org/ https://www.clojuriststogether.org/ do. They do good work. Plug concludes. Clojure - like many languages - seems to be benefiting a lot from the work the IDE people have been putting in to good infrastructure. A lot of the magic is being moved out of Emacs towards tools like Treesitter and the LSP server which are more platform independent. Not a huge amount to do with Clojure per say, but the Clojure ecosystem is benefiting a lot from it. The Emacs specific stuff is becoming very Emacs-specific (like paraedit, bless its socks).

diggan 2y ago
I think Clojure has benefit way more from nRepl and everything in that ecosystem, than LSP and that newfangled stuff, at least my personal setup relies on nRepl and doesn't even use LSP afaik.
waffletower 2y ago
I am wary of LSP. I should try LSP again using eastwood, which probably has its trade-offs. While I absolutely admire Borkdude's many gifts to the Clojure community, the lack of static analysis in clj-kondo is a non-starter for me -- macro support is painfully manual. Because of its speed, clj-kondo likely is more performant in an editor LSP context, but too opinionated for me.
- iLemming 2y ago
  I don't know what you're talking about; it feels to me like you're complaining that your camel isn't a Ferrari. Clojure is inherently very dynamic - fully automatic static analysis of Clojure code is extremely difficult. Not just Clojure - any other Lisp too. Do you think that for almost four decades of Emacs Lisp existence, nobody built a deep static analysis tool only because people were just stupid, lazy, or had no incentives? Kondo is actually considered the best-in-class tool for Clojure linting/analysis, and its manual macro configuration is a practical compromise given the language's design. > macro support is painfully manual. If programming was effortless, I would have no job, I bet you wouldn't have either.

Jeaye 2y ago

You're absolutely right. To start with, I'm focusing on capturing and converting existing Clojure devs. However, there's a very large pool of C++ devs who could benefit from jank. As you said, jank not only needs to be ready for them, they need to be educated on lisps, functional programming, data-oriented programming, REPL-based interactive development, etc. It's not an easy learning curve right now, into Clojure. I aim to focus a good deal of time, post jank's launch, to create materials which enable this. Materials specifically targeted at OOP devs coming from the native space.

lincpa 2y ago
[dead]
butterisgood 2y ago
I can imagine Jank being incredible “glue” to start until it takes over by osmosis. (For c++ of course) Maybe I should play some advent of code games with it to get comfy!
vlovich123 2y ago
As someone who might be in your target demographic in theory but not familiar with Clojure, what capabilities does Clojure itself offer as a language that a different mainstream scripting language doesn’t? For example, I’ve always thought that the interesting part of Erlang is Beam & the uninteresting part was a niche language. Beam with JS as the language is much more approachable & leverages a rich existing ecosystem of tooling & libraries. Indeed, if you look at it the right way Cloudflare Workers is exactly that; isolated virtual processes within a single OS process that communicate with each other using a message based IPC & if they crash just the microservice is taken down & transparently relaunched. So from that perspective, why Clojure instead of the same features on a different more popular language?
- ndr 2y ago
  It's hard to describe what immutable/persistent data structures do to your thinking. A lot of responsibilities move to the edges and you're left being able to think and tests pieces of code in isolation. The repl becomes usable, and you code from inside your running program. It's a steep step to get started but it's going to transform how you think about some problems.

ab5tract 2y ago

The “use emacs” prerequisite that shows up frequently when exploring Lisps has been such a dealbreaker for me in the past. I have no patience for learning “chords” or even using a non-modal-but-still-not-just-normal-input editor simply to explore a language. My impression being that these chords morph depending on “modes” doesn’t help at all. At least with vim you can learn a piece at a time (sorry, not trying to revive last century’s favorite flame war, but it’s true). Also: no one has managed to explain to me what makes emacs so uniquely capable of interacting with a running interpreter, despite this usually being the USP I hear for “needing” emacs when attempting to Lisp.

pritambaral 2y ago
> Also: no one has managed to explain to me what makes emacs so uniquely capable of interacting with a running interpreter, despite this usually being the USP I hear for “needing” emacs when attempting to Lisp. As an Emacs user that has to work in teams of non-Emacs users, the answer to this boils down to culture and ecosystem maturity. Purely technically, there's nothing that Emacs allows me to do with REPL Driven Development that _couldn't _ be done in another editor. Practically? I still haven't been able to even get (sufficiently) started with any editor. I often have to work on a Rails codebase that takes tens of seconds just to start. Dev cycles in the traditional Edit-Restart flow were so painful that I wished badly to burn this codebase down and rewrite it all in a language and style that supports a Lisp-style REPL. Then I discovered inf-ruby.el in Emacs. It allows me to just edit the code and reload only what's changed. It automatically inserts the correct `module Xyz; ...; end` etc. No more restarts. I showed it to my coworkers. They shared the pain with restarts. And yet, to this day, none of them have an equivalent to inf-ruby in their editors. inf-ruby.el is less than 1400 lines of code. It's easy enough to implement in Vim, IntelliJ, VS Code, anything really. But it exists only in Emacs, so far. Why? I'm sure because some Emacs user, once upon a time, wished similarly to have a more Lispy REPL for their Ruby dev work, and just built it. Because they were used to it, from having used Emacs or other Lisps with Emacs. Compare that to when I first tried to support Common Lisp development on VS Code. A language that already has full support for REPL Driven Development with an interactive debugger built-in. Nope, we aren't gonna use any of that, because in VS Code land, we use LSP. A model that really only works for languages that can be statically analyzed. You want Go To Definition on a method that's included from a module and called on a receiver that's a dynamic variable? Well, sucks to be you, I guess. So, while people make do with the severe limitations of Solargraph or Ruby-LSP, I use robe.el — which adds lisp style code intelligence by running inside your Ruby process — and get code intelligence that actually works with a language as dynamic as Ruby. Again, robe.el was just there for me to use. Again, there's nothing about Emacs that makes robe.el possible in Emacs but not in other editors. Again, there's no equivalent to it (that I've found) in the ecosystems of other editors.