When Atom was first launched I mentioned that it might make sense to port the interesting parts of LT over to it since the core editor isn't what's important (and it's also a ton of work to get right). LT has found its way into lots of projects, from the Chrome Dev Tools to XCode and IntelliJ, which is a tremendous honor for us - it's great to see it coming to Atom as well.
I've been thinking a lot about what makes for a good development experience, and how to properly "factorize" an IDE to provide a consistent experience across different languages. The monolithic IDE experience can be great (once you get it set up) if all your work is in a single language. But for people like me, having a confusingly different development environment for each project is a nightmare.
This is a tiny step toward the dream of having a consistent core editor but with powerful tools for each language that allow introspection into the state of the running machine.
I'd love to do live variable inspection (like the Chrome Dev Tools) — it's something I'm thinking about for the future.
There's a (nascent) project called `jmp` (for Jupyter Messaging Protocol) that implements kernel communication in JS: https://github.com/n-riesco/jmp. I'll probably contribute to that and factor out my kernel communication.
I'm starting up a way to do this with an Electron app (the base of Atom), called Jupyter side car. It's not ready yet, but will share some of the same components. All this is pretty exciting for the Jupyter project.
There are also several syntax highlighting issues but those aren't deal-breakers like broken indentation.
I'm sympathetic, I help maintain elixir-mode for emacs. I know it's hard to get this stuff right. But all things considered, Atom is unusable for Python for me. I was using it for working with JS & React but now that web-mode seems to have ironed at many kinks, I'm back to Emacs.
Know off-hand if there is a fix for JS auto-indenting in the works? My atom seems to just indent everything one level more than the last, never out-denting back. This is something which I've found JetBrains IDEs to be really good at, but at this point Atom has so many useful / fun packages and is so easily extensible that I don't think I'll switch back any time soon.
If there's already a package (I know about FixMyJS which...sorta works...) which does this well, please share!
EDIT: rainbow parens would also be KILLER in Atom, but last time I looked it sounded like it was non-trivial to modify the colors like that.
Doesn't matter, it works now. This isn't a moral question about which project has had the fewest bugs in their respective lifetimes. It's a practical question about which mode gets auto-indentation right right now.
edit: I don't know the answer to your question. What I do know is that it's really hard to get indentation right in Emacs for languages with significant whitespace where new lines are the only marker, and I assume the same is true for TextMate (which Atom piggybacks on for indentation). I'm not an expert on emacs, emacs lisp or creating language modes for emacs, but I do have a decent amount of experience[1]. So when I say I'm sympathetic I mean it down in my bones.
But still, if an editor can't get auto-indentation right, it's a deal-breaker.
Oh, I didn't mean it as a moral question or smack-talk or anything like that. I was just noticing that Python seems to be neglected by a lot of editors. I'm normally an Emacs user, but I gave up on it for Python because I had to spend too much time fighting it on indentation, so I was kind of surprised to see it mentioned in your comment and it made me think.
No, python-mode works beautifully for me. There are a couple very minor hiccups (I think there's some error with indentation after a method with no `return` statement or some such) but it's not a deal breaker.
Congrats on the release, Will!
This would make for a killer default env for MIT's 6.815 course (http://ocw.mit.edu/courses/media-arts-and-sciences/mas-531-c...) (presently taught in Python).
Also, ahem, I believe it is now time to JUPYTER ALL THE REPLS.
Nice work. Question for anyone using light table or similar environments on a day-to-day basis: does this statement-by-statement eval and output scale to larger projects? It makes a nice demo for contained scripts, in particular those working with a concrete dataset (image, samples). I have trouble imagining what it is like for larger, more abstract stretches of code.
I like to break my code up into little functions that are easy to test, so that flow works well for me.
Even more powerful, though, is autocomplete from the running environment. It means that (just like in the Chrome Dev Tools) when you start typing something, the autocomplete suggestions include all of the valid names that are defined. It really helps in navigating complex APIs like Torch: https://www.dropbox.com/s/e6hriw5quwct65a/Screenshot%202015-...
Pretty awesome, this is something I had been thinking about since using light table and julia - live programming, visualization and bringing auto complete and live syntax checking to julia. Very cool! I think these methods if they work on a larger scale will ultimately be a better way to program.
The development experience for statically typed languages is often _amazing_ compared to that of dynamically typed ones; we sometimes choose dynamically typed ones anyway because of the flexibility and speed of development they give. I'd be very happy with an environment that provided dynamically typed languages the same analysis, checking, completion, etc that statically typed languages take for granted.
> I'd be very happy with an environment that provided dynamically typed languages the same analysis, checking, completion
Thinks like tern.js[0] or my own Aulx[1] provide that with varying success. Visual Studio's JS autocompletion is also stellar. The techniques used could be applied (with tweaks) to most dynamic languages.
Yes! I like this very much. This is the favorite feature I used in LT (though I've wished to delve more in its architecture), I never really got the hang of external REPLs and browser sessions.
I recently tested Wallaby.js, which brings LT approach to testing. Now I wonder if the logic in Hydrogen could be extended to call module's tests and bring results just like the evaluation messages come. I think both immediate coding and testing might make coding more intuitive and reliable.
Is there an Atom to Jypyter bridge or something? How does Hydgoren and Atom communicate with Jypyter kernel?
Jupyter provides a spec for a ZeroMQ-based messaging API, which kernels in each language have implemented. Hydrogen acts as a client to those kernels the same way that the Jupyter frontend does, sending execution requests to the kernel and displaying responses.
I'd love to see live test results in Atom too! It would make it so much easier to be confident in your code's correctness.
Thank you. I managed to miss that when reading the first time. I'm currently learning testing with the TAP protocol [1], which might be simple enough to bring into Atom or Oxygen and also use in Jypyter languages. I know that Python and JavaScript supports it.
Just had another thought. Regular Jypyter kernel supports multiple connections. Have you tested connecting to Oxygen's Python kernel from Notebook or IPython session? I'm thinking that console + Atom is nicer environment for a coder than Notebook. Afterwards the session could then be saved as a Notebook.
Anyways, I must now find time to dig into this! I don't like to leave my editor just to look at code execute nor tests run, there is more than enough context switching in programming.
I have a question for those who are either still using Light Table or have switched away from it:
I've been meaning to start a project in ClojureScript and was thinking of using Light Table as my editor. I vaguely recall seeing news about development of Light Table slowing down, but despite this, would you guys still recommend Light Table today for Clojure/ClojureScript development? In its current state, how does it compare to editors like Atom/Sublime and whatever other options that are out there for Clojure development?
A filled circle with a ring round it that has an intersecting filled circle is not an accurate representation of how a hydrogen atom looks. It is an artistic simplification. There are any number of ways of interpreting it.
That looks so cool! I'm not an Atom user anymore (jumped back to Sublime), but this is the kind of thing that makes me want to jump back again. Wondering if there is an equivalent for Sublime.
SublimeCodeIntel doesn't do quite the same thing, but does at least provide intelligent code completion for languages including Python. I think it can be a bit buggy, though - and this actually has the autocompletes come from the kernel, which is clearly better.
In short, I'm in the same boat about wanting to jump back to Atom. Just want to wait on improved performance, which I hear is in the works.
As recently as today I thought IPython might be worth looking into -- I've heard too many good things about IPython to ignore it, but I didn't really know how to get started.
I guess I don't have that excuse any longer! My only concern is that my mind will have trouble adjusting to the evolving state of the "app" I'm working on -- it seems like values in lines above others change, which then change values at other places, not just below the code? Will take some getting used to.
If you're on the latest Firefox (38), then it has been insanely crashy. Even with the 38.0.1 update that supposedly fixed a crash bug, the browser still crashes on a lot of websites. I'm not sure why Mozilla felt the need to push a suboptimal version out, but it is making me think of leaving Firefox again (been very unstable for me the past few versions).
In practice, different kernels have various oddities or holes in their implementation of the spec. I'm accommodating them when I can and posting issues when I can't. Let me know if you find a kernel that doesn't work!
How is the Ruby support? A Rails console in the file I'm writing sounds epic. No longer would I need to clumsily suck the interesting lines back out of irb history using copy/paste.
I find this a surprising reaction, just because for so many devs I've known, it's common to keep a "sketchpad" interpreter open to mess about with code ideas. And these are all dedicated TDD folks. Perhaps if the dev(s) in question don't really understand TDD, but I think that's a cultural problem rather than a tooling problem.
In my experience, "getting" TDD is about two main things. First, internalizing what to test & why to test. (Fortunately, we've got a lot of help these days on the "how to test" front.) Second, having that moment when having tests makes your life-as-developer easier, or perhaps just possible. (Re: "possible", I recently upgraded a mature, legacy Rails 2.3 app to Rails 4.2. My blessings upon the devs prior to me who saw fit to create a comprehensive and well-maintained test suite. Without that, there would have needed to be a "throw it away and start afresh" discussion. Perhaps even project cancellation.)
Most of the credit goes to the Jupyter team and the people who have implemented the kernels for various languages. The Jupyter API spec is what has made this possible. I'm really looking forward to what can be done next (hint: https://github.com/jupyter/notebook/issues/99)
When Atom was first launched I mentioned that it might make sense to port the interesting parts of LT over to it since the core editor isn't what's important (and it's also a ton of work to get right). LT has found its way into lots of projects, from the Chrome Dev Tools to XCode and IntelliJ, which is a tremendous honor for us - it's great to see it coming to Atom as well.