Run code inline in Atom using Jupyter kernels(github.com) |
Run code inline in Atom using Jupyter kernels(github.com) |
Good work.
Although Bret Victor deserves lots of appreciation for his work, most of his ideas are actually how Xerox PARC workstations and Lisp Machines used to enable developers to program more productively.
So if anything the best part of his work is making young generations aware of what the industry lost when those systems failed to gain wide market acceptance.
Lisp may have been the first language with a REPL (as far as I'm aware it was either Lisp or Forth), but REPLs have evolved over the years, and plenty of modern programmers were familiar with REPLs before Bret Victor's views on instant feedback became popular.
It was a graphical REPL that could embedd live objects, which were still active to further interactive changes.
Also the ability to have the whole OS exposed via the REPLs is hardly available in modern systems.
Not alk REPLs are made alike.
So, we actually did lose some things with the new and shiny REPLs - Macros.
No debating your statement that there are other good programming environments with other shiny features^^
I've used the Jupyter emacs integration (https://github.com/millejoh/emacs-ipython-notebook) but in the end, I stuck with org mode.
For an example of what you can do in org mode (in emacs), here is part of a "dashboard" I created for one of my products: https://i.imgur.com/QUFbIBk.png
And an example of how I design: https://i.imgur.com/MeRYn1L.png
You can essentially use org-babel to recreate an approximation to the notebook environment which si cool
With hydrogen, are there cells? What happens if I want to rerun everything? Will I get no output except the output of the last line?
> Will I get no output except the output of the last line?
If the return value is one line, it prints neatly after the executed block. If it's more than one it inserts a little pane with the results, with options to copy the data or open it in a new buffer.
While it doesn't currently exist, someone might implement something like this for Sublime Text in the future.
There is already discussion about Jupyter lab here on the front page - https://news.ycombinator.com/item?id=12098180
This is the first example I've seen of the power that using Electron in Atom can give, and it makes me super exited!
I regularly included build steps as comments in the first few lines of C and Pascal sources. No makefile necessary.
You could also arrange for code to run on actions like 'cd' (to set up environments, for instance; your editor window could become a context of readily selectable commands based on the directory you were in).
Oh, and 1987.
Emacs is a very polarising environment and there are many programmers for whom it is simply not the right code editor.
I do recognize, however, that being tied to emacs (the only complete implementation of org-mode / org-Babel today) is a liability. I wonder if some smart person will figure out a portable implementation in something else. Of course, it won't match the flexibility or extensibility of emacs, but perhaps it can still surpass Jupyter / RMarkdown.
I mention RMarkdown together with Jupyter simply because org-mode / org-Babel nearly addresses both the dynamic notebook use case as well as the document publishing use case (including nice academic feature like cross-references, which aren't supported in Markdown).
There are issues with Jupyter in that distro too, But hydrogen had some nps js error regarding a missing lib or something. So many stacks in these things...
Suppose you had Jupyter installed using the following process:
https://www.dataquest.io/blog/digitalocean-docker-data-scien...
Often times the result of running some bit of code is to see the end result in a browser because the code resulted in sending a bunch of HTML or JSON as a response.
Also in the above case your code isn't self contained to a block of code. Chances are you have a web server, along with a database and cache server. Most of my projects are also encapsulated in half a dozen Docker containers. How is this plugin going to know what to do with that?
Starting up an entire stack of programs to live preview a few lines of code would end up being slower than just saving the file and reloading the browser to see feedback.
I only glanced the top of the README which compares the project to what Light Table was trying to solve and then showed an animated gif of inline code evaluation examples.
The dark one isn't really ideal for a cell-by-cell Jupyter-like implementation
A major feature Babel offers, which Jupyter doesn't seem to, is passing data among code blocks in different languages. Any language Babel supports [1] can receive results from any other in the receiving language's native idiom, so there's no need to marshal temporary files or what-have-you in order to exchange data among blocks - Babel takes care of that for you. In a case where multiple transformations are necessary to get from source data to results, this makes it very easy to express each in a language well suited to it, without having to spend a bunch of time and mental energy on menial file shuffling.
The same is true for most other representations of data that Org mode supports. In particular, Org tables, which themselves have many features of spreadsheets, can be sourced in code blocks in the same way as the results of other code blocks, and a code block can generate an Org table as a result. These tables can be imported and exported as CSV, too. My work is professional rather than academic, but I can imagine a lot of cases in which this capability would be useful in the latter context, and Jupyter doesn't seem to offer it. (It's hard to tell, because Jupyter's documentation seems pretty thin overall - not something which can be said of Org mode.)
On the whole, Jupyter looks like a pretty nifty tool, and one which would be accessible to people who don't already use Emacs. I'm not sure how I would feel about recommending Emacs to someone just for Org mode, although I've heard several people say they picked up Emacs for precisely that reason and have stuck with it. But, if you already use Emacs and don't have contextual reasons (such as everyone else around you using Jupyter) to choose one tool over another, I wouldn't hesitate to recommend investigating Org mode first, because it is very nearly a strict superset of Jupyter. (It'll be a few years before you can easily embed a video in an Emacs buffer; right now you'd need to use a pre-release version with some extra compile options.)
[1] http://orgmode.org/worg/org-contrib/babel/languages.html
I should learn org-mode though. I've heard so much praise for it!
As for modern systems not allowing the whole OS to be exposed via a REPL, there is at least one actively developed OS that allows this, and that's Oberon. The most recent revision of the Oberon OS was from 2013.
The version 3 with the Gadgets framework was quite cool.
The only modern OS environments that come close to these experiences are Windows with .NET/VS/Powershell and OS X with Playgrounds, the OS X Frameworks and Applescript.
Don't get me wrong, it is great what they are doing and I for one enjoy Notebooks, Playgrounds, modern IDEs, tooling that allows for both for JIT and AOT, while offering safety.
Just a bit nostalgic how things could have been different.
For example, when Google brought out ChromeOS and Dart, I thought there was a perfect opportunity to have a similar experience, but that is not how it turned out to be.
You can still hook up a remote debugger to your kernel, I guess, but that's not quite the same then is it.
EDIT: I guess I should expand a bit on that answer.
Take Oberon, which like Java has the misfortune of using the same name for the language and the respective OS.
It was based on Niklaus Wirth experience on using the Xerox Star system with Mesa/Cedar environment.
The original Native Oberon used as only executable format shared libraries. Depending on the OS variant, they were either fully AOT, or JITted on load.
There was a convention on procedures that could be made visible to the REPL or mouse commands and what type of input they would act upon.
So you could either do module.procedure parameters at the CLI, select some text at a given open window or embedded object (think OLE) and select a module.procedure at the toolbox of loaded modules.
Very simple set of primitives exposing the whole OS, both CLI window and other GUI elements as programmable elements.
You see a bit of this way of working on the ACME editor used in Plan 9, specially later on Inferno with Limbo.
Stream processing should be equally mighty as list processing. What about system level access?
Edit:
> both CLI window and other GUI elements as programmable
Sure, X sucks, but it supports that. X might be infamously complicated, but there's a security hole, either way.
How do you in X protocol select an object that represents a table in a word document and add an extra column with the standard deviation of the other rows?
Just a possible example of the type of composition that was possible.
