Show HN: Nightlight, an editor that runs inside Clojure projects | Hacker News Reader

Show HN: Nightlight, an editor that runs inside Clojure projects

github.com

195 pointsgw63 comments

I don't really see how the integration would be any better than what I'm getting already from Emacs: I can already patch the code live, etc, through a REPL, and run the code as I develop it.

Nightlight is asking me to give up the comfort of Emacs: so what does it get me?

I am ignorant of SLIME/CIDER (though I think I've used the latter with Clojure). Do they have access to the same memory space as the running application and the ability to interact with live application state? It seem that Nightlight has that as a goal. My (limited) understanding is that SLIME/CIDER run in a separate process from the application, thus requiring IPC back and forth between Emacs and the application runtime.

That's true, but the practical effect (having access to application internals, interacting with live program state, the ability to connect to a live program and hotpatch it, even if it's running on a remote server (but you'll really want the source files if you're doing that, and you should be sure to upload the new sources/binary to the server you just hotpatched, or you'll be in for a shock when it reboots), and so on) is exactly the same, and they mostly share the same capabilities (AFAICT, Nightlight might have better autocomplete than SLIME/Geiser, but other than that, I can't think of anything).

> Nightlight is asking me to give up the comfort of Emacs: so what does it get me?

Perhaps nothing. But for me it would give me the fact that it's not Emacs.

I know that Emacs is considered the one and true way to do lisp, specially common lisp, but, for me, it's the reason I haven't started to do anything in that language.

Different people, different needs. It might cater someone else's needs.

You do raise a good point, but I suspect that other users would ask the same question, s/emacs/$EDITOR/gi, and a few other substitutions for the specific commands and plugins (I'm not familiar enough with other ecosystems to say which ones).

And Emacs isn't the only way to do CL, it's just got really good support for all lisps: Paredit and SLIME are still some of the extensions against which all others are judged, with most lisps having a SLIME equivalent mode, give or take.

But what's so bad about Emacs?

> But what's so bad about Emacs?

The time you have to devote to learn it.

I get that when you are used to it and use it you get that time back, but I haven't had a job where I could use that, and when I had time I was more of a vi person.

On can go up so many learning cliffs until he gets tired of that and just yearns for interfaces that are similar to the ones already known or so easy that no learning is necessary to start using them.

VIM has at least decent Lisp support, with a version of Paredit, and SLIMV. I don't know if there's any CIDER equivalent for Clojure development, though.

Wish it credited Light Table as inspiration (http://lighttable.com/) :/ Even the term "instarepl" is taken from LT's creator, Chris Granger. Of course LT's inspiration is Smalltalk's IDE.

"Of course ..." is that really true though? From the very beginning, the very first demo, Chris Granger mentions that he got inspired by Bret Victor's Inventing on Principle demo. He mentions it in the first blog post as well :p No mentions of smalltalk

Chris Granger's first video on LightTable: https://www.youtube.com/watch?v=7XUWpze_A_s Chris Granger's first blog post on LightTable: http://www.chris-granger.com/2012/04/12/light-table-a-new-id...

Hm... I seem to remember him saying something about it, but (of course!) i might be wrong.

Ah, but Bet Victor draws inspiration from Smalltalk, Logo and Hypercard :

http://worrydream.com/LearnableProgramming/

Everything is a remix ;) Light table certainly was my inspiration for the instaREPL. DrRacket inspired the notion of running code in the same process as the editor. The code completion system comes straight from CIDER. I could go on and on. Please don't interpret the lack of a mention as a slight. We're all remixing each others' work.

I like the idea of a browser based IDE. I like the idea of an IDE for a lisp-like language that actually offers first-class auto-completion.

I don't like the idea of embedding it into a project. That doesn't make sense from a dependency tree way of looking at it.

I could see embedding as a huge win as everything moves into the cloud. Just bake this into your project and push it to the test servers. Then log in and code. Imagine not having to connect your laptop to seventeen other "microservices" to be able to develop on something similar to the production environment. No more developing blind in your IDE and then falling back onto vim or nano when trying to play with a remote server.

Of course make sure it is turned off for production, but the same applies to ssh and vim.

Agreed on the dependency weirdness though. It does feel a bit like when that one guy keeps checking his Eclipse or Intellij config files into source controll. I hate that guy.

Is removing vi and SSH from production servers a common thing? How do you configure and operate them?

These days a lot of companies will have production systems launch from a configuration that is known to work as expected already, via QA processes. It'll be launched and configured with tools like chef, puppet, docker, and other buzzwordy technologies. When something needs to be changed, you edit the static configs, stored in a source control system, and let chef and company do the heavy lifting.

...But can't you do the same thing with any REPL? Run NREPL (Or your local equivalent in your Lisp dialect) on a port for internal use, and then just connect to your server with SLIME/CIDER/Geiser or whatever you non-emacs-using folk use (although why you would use another text editor for Lisp code is beyond me).

Maybe a Clojure equivalent to NPM's "devDependencies" can manage something like this, so that it gets excluded from the final deployment JAR. It's been a while since I'd done Java/JVM development, but the dev-time vs. deploy-time dependencies configuration should be possible, I would think.

The pom dependencies allow for `:scope "test"` if that's your bag. You could also wrap the :dependencies inside a special development build task (in Boot) if you choose.

Using leiningen you can add environmental build deps. I forget the specifics but it's definitely available.

I wouldn't want to risk something this critical being in my project. I'm stupid so I try and limit my own attack surface against myself.

A very humble approach, and one that I try to subscribe to, as well. :)

I think the embedding part is certainly a tradeoff. Once the development community settles on a best-practice for things like this, it becomes less of a danger of forgetting. For example, once this sort of config shows up by default in archetypes and boilerplate projects, I feel that the danger is reduced to the level of being manageable. And hopefully the port that the editor uses is blocked by default in the production environment. :)

Yea it seems like a great project but I don't really like to think of my IDE as a dependency of my code but rather my code as a dependency of my IDE.

Leiningen makes this easy. During development, the :dev profile is run (joined with the project definition), but it's excluded from builds (JAR, WAR, etc.).

Lein and Boot both support tooling plug-ins, ie. libraries that are only loaded as part of the dev environment, so it's certainly possible.

Both the major Clojure / ClojureScript build tools - boot and leiningen - support dev only dependencies.

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

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.

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.

...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.

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.

Yeah. Well, I was thinking CIDER/SLIME/Geiser (they all provide similar services for their environments), but same idea.

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.

Very cool. Looks like a spiritual successor to Catnip[0], which I made heavy use of when I was newer to Clojure.

Bodil's moved on to other things, I'm glad someone is moving forward with this kind of environment.

[0]: https://github.com/bodil/catnip

Something more advanced yet similar to Nightcode is something I am definitely excited to try as an alternative to Emacs and Cursive. Also gotta try this with play-clj to see how the workflow plays out.

Edit: Tried the REPL but it felt quite buggy: http://recordit.co/ziDH1PrJvm.

It's the same author, so I'm assuming that this is his spiritual continuation of Nightcode with a huge update.

EDIT: They are going to remain separate, here's what he wrote on the project site:

> Nightcode remains easier for beginners, because it's a standalone application with Leiningen and Boot built in, so they don't need to use the command line. Nightlight must be added to your project, but provides more power, so it may be more suitable for intermediate and advanced users.

This is actually really creative and clever! In fact it's the first project of it's kind that I've ever heard of!

Basically it's a library that runs a web server that serves a page which displays the contents of your source files in an editable text field, and saves/loads them by reading/writing directly to disk. This also means it should be much easier to implement the advanced IDE features of CIDER, since you don't need a plugin system and have full access both to the raw source code files and the project's very own JVM (which the IDE shares). Neat!

Although, I once again have to completely disagree with Oakes' choice of buttons in the toolbar (just like in Nightcode): I don't know any programmers who don't know the shortcuts for Save, Undo, and Redo by heart.

You might want to have a look at LivelyKernel too:

https://www.lively-kernel.org/

> "More powerful editors like Cider and Cursive manage to do this with some very complex machinery that I could never duplicate. Instead, I decided to rethink the problem. Since Nightlight runs inside the same process as your project, code completion and other advanced features are trivial to implement."

How? What makes it easier to implement code completion when the IDE is running inside your project's JVM? Clojure is still a dynamic language, which means you'll never fully know what vars make actual sense in a given context. For example what vars in the current context make sense as arguments to the function you're about to call, when you have no idea what the type signature of that function is (which may even be a variable). Unless, do you mean very simple context-less code completion? That's what CIDER does, and presumably Cursive too, but they just do it by asking the process on the other end of the nREPL server for more details, and the plugins for these have access to the same JVM.

The reason code completion is easier with this design is that I don't need to deal with any nREPL server; Nightlight can just go to the relevant namespace and ask for the available symbols.

You are wrong that it is context-less code completion. In fact, I use the same library that CIDER does: https://github.com/alexander-yakushev/compliment I pass the entire top-level form to the library so it can make intelligent choices about what to complete. Here's how it works: https://github.com/alexander-yakushev/compliment/wiki/Exampl...

Neat! Better than nothing! Still not as context-aware as IntelliJ does (sometimes), but it's hard to beat Jetbrains, especially as a sole developer. Plus Clojure doesn't exactly make this easy by being dynamic from the bottom up. Assuming you're Oakes, nice job, and I'm looking forward to trying out Nightlight and will probably enjoy it as much as Nightcode :) that said, why the choice of those buttons in the toolbars? Ctrl-S and Ctrl-Z and Ctrl-Y are pretty commonly known.

Just wanted to repeat my sentiment in another thread, that I love this approach to problem solving. The outcome appears to be a tradeoff, but one that simplifies the hard part beautifully, leaving a simple(r) solution. I look forward to how this goes!

It is easier to perform "X" inside the JVM instead of doing "X" in the JVM and providing a client/server protocol to do it from anywhere. The drawback is that you can't plug another client.

Which I guess means Nightlight should expect to see a lot of PRs and/or active forks.

Actually, Cursive doesn't do this, it analyses source for its completions.

Hmm, I knew it did that when the REPL wasn't on, because it gives very limited completion options compared to CIDER. Does Cursive even do this when you have access to a REPL, or when nREPL is running? That's the main reason I still prefer CIDER + Emacs, because it has much more useful completions, though still not as good as IntelliJ's completions for static Java code (only possible because Java is static).

Generally Cursive's completion should be (at least) as good as CIDER's, and if it isn't that's a bug I'd like an issue for. No-one has complained about it so far.

"The ambition is to create something that follows the Lisp and Smalltalk tradition, blurring the line between your tools and your code to provide unprecedented interactivity."

(emphasis mine)

I don't come from a Lisp background, but I don't see why that would be something desirable at all. Does anyone know more about this?

Reflection, for example, was heavily used by Smalltalk tools to build and debug objects alive.

Growing programs without the need to stop them is also very much in the Lisp tradition. See, e.g. the JPL remote bug in spaceship story [1].

[1] https://ti.arc.nasa.gov/m/pub-archive/176h/0176%20(Havelund)...