Hacker News Reader

Comment by gravypod | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com