3 ms·

The possibilities of this thing blow my mind. Very cool idea.

by swalsh 10y ago

S4M 10y ago
Can you give some examples of what you have in mind? I find this very intriguing but I can't think of anything it could do that would be impossible with hot reloading code.
- JamesLeonis 10y ago
  1. Cloud based development/debugging. One of the harder issues when I'm building microservices is stringing each service and dependency together and debugging. With this I could put together a full staging environment and log into each service to monitor and tweak problems I've found. 2. Limited hardware or access. This is important because it's talking with Java Clojure not Clojurescript. Because it's entirely browser based, I could spin up an EC2 instance and load the editor on my phone. I can't do that with a regular Clojure environment in my phone.
  - qwertyuiop924 10y ago
    ...But can't you do that already with CIDR? (or SLIME/Geiser, for some of the other lisps). IIRC, it does support connecting to a remote REPL like this.
- BWStearns 10y ago
  I don't think it gives you a whole lot over emacs with figwheel set up but it does seem to minimize the barrier to entry (ie emacs no longer soft mandatory). I think if it grows a sublimetext style command pallet and shortcut arsenal it could very well be the default new-to-clojure experience. It could fill the role in the clojure ecosystem that Haskell for Mac does in haskell's ecosystem.
  - qwertyuiop924 10y ago
    Yeah. Well, I was thinking CIDER/SLIME/Geiser (they all provide similar services for their environments), but same idea.
tunaoftheland 10y ago
Agreed! The author mentioned Smalltalk and it instantly clicked for me. Having a live programming environment sounds awesome, it sounds like it will fit my thinking pattern better. Then, for production deploy, you drop the editor library from the JAR. It's kinda like stripping the IDE part of a Smalltalk/Pharo image before production deployment. As much as I want to like Pharo and am amazed by its fast progress, its integration story (to external data source like PostgreSQL) is pretty weak, currently. I'll be tracking the progress of this project to see how it goes, though I've yet to love Clojure. I want to add that I think it's a beautiful approach to solving the problem; rather than implementing a complicated mechanism for interrogating the application state from a tool running in another process, the author is flipping that around and putting the editor inside application so that it has a very simple access to the application state. Love it.

The possibilities of this thing blow my mind. Very cool idea.

by swalsh 10y ago

The possibilities of this thing blow my mind. Very cool idea.

S4M 10y ago

Can you give some examples of what you have in mind? I find this very intriguing but I can't think of anything it could do that would be impossible with hot reloading code.

JamesLeonis 10y ago
1. Cloud based development/debugging. One of the harder issues when I'm building microservices is stringing each service and dependency together and debugging. With this I could put together a full staging environment and log into each service to monitor and tweak problems I've found. 2. Limited hardware or access. This is important because it's talking with Java Clojure not Clojurescript. Because it's entirely browser based, I could spin up an EC2 instance and load the editor on my phone. I can't do that with a regular Clojure environment in my phone.
- qwertyuiop924 10y ago
  ...But can't you do that already with CIDR? (or SLIME/Geiser, for some of the other lisps). IIRC, it does support connecting to a remote REPL like this.
BWStearns 10y ago
I don't think it gives you a whole lot over emacs with figwheel set up but it does seem to minimize the barrier to entry (ie emacs no longer soft mandatory). I think if it grows a sublimetext style command pallet and shortcut arsenal it could very well be the default new-to-clojure experience. It could fill the role in the clojure ecosystem that Haskell for Mac does in haskell's ecosystem.
- qwertyuiop924 10y ago
  Yeah. Well, I was thinking CIDER/SLIME/Geiser (they all provide similar services for their environments), but same idea.

tunaoftheland 10y ago

Agreed! The author mentioned Smalltalk and it instantly clicked for me. Having a live programming environment sounds awesome, it sounds like it will fit my thinking pattern better. Then, for production deploy, you drop the editor library from the JAR. It's kinda like stripping the IDE part of a Smalltalk/Pharo image before production deployment. As much as I want to like Pharo and am amazed by its fast progress, its integration story (to external data source like PostgreSQL) is pretty weak, currently. I'll be tracking the progress of this project to see how it goes, though I've yet to love Clojure. I want to add that I think it's a beautiful approach to solving the problem; rather than implementing a complicated mechanism for interrogating the application state from a tool running in another process, the author is flipping that around and putting the editor inside application so that it has a very simple access to the application state. Love it.