#Jupyter lighttable software#
#Jupyter lighttable code#
#Jupyter lighttable windows#

These two projects at the time of inception have definitely paved the way for something better than the current paradigm of files and folders to take hold.

Eve: a programming language with an IDE that has a radically more human friendly approach to coding.

#Jupyter lighttable code#

Light Table: is an IDE that came before Atom/VS Code and Brackets.Let’s focus on what Chris Granger has done in this space: Light Table and Eve.

#Jupyter lighttable software#

There are two people working on fundamentally different software development experiences, Bret Victor and Chris Granger, there are others too, but these two people have had an outsized impact on new ways of thinking about programming. 💡 Here’s my concept for a functional text editor This is not a new idea, but maybe in the past, it wasn’t the right time for it. They’re not the best representation, in fact functions might provide a better one.Īs no IDEs think this way I decided to try and create a prototype for a new kind of IDE taking this idea as its guiding principle. We use files to store code because they’re a convenient way to serialize code. Up until now I always thought about code as a collection of files, connected through imports.īut really we import functions, not files. I guess my final thought on this is that if we were to offer customization of display options, I would try to see whether one can do that via some custom MIME type solution, rather than introduce new types in a shared package.This concept is still mind blowing to me. Are there some key examples of custom drill down behavior of some types that are sort of canonical why that is so useful? I think I’m also not 100% sold that in general it would be good to be able to “hide” the actual structure of the types one is using, as a user I probably just want to be able to explore whatever structure the types that show actually have? But I’m not super familiar with the tree drill down in Juno, so should probably look more into that. There are some ways around that, but they are complicated and at least for a first version I’d like to avoid them. We generally consider the REPL process as owned by the user, not us, so we don’t want to load any package into the user/REPL process to avoid any package versioning conflicts with stuff that the user might have/want to load. We generally try to not rely on any packages in the REPL process. I plan to add support for “Julia Notebooks” that will mimic R Notebooks from RStudio (in particular in terms of file format).īut why not use TreeViews for this? I’m not super happy with the API either, but the idea of having a customizable structured display is very important imho. I’m pretty sure someone will build a Jupyter notebook extension. The core VS Code team is adding UI for notebooks, and then extensions can provide their own implementations for different backends. I’m probably most excited about the notebook UI that is coming to VS Code. also has tree drill down during debugging). you’ll be able to drill down into composite types, arrays and dicts).īut before we ship that, we’re going to ship a debugger in VS Code (which, btw. It won’t use TreeViews.jl, but just be based on standard Julia type logic (i.e. We will be getting a workspace view in the VS Code extension soon ™, and it will have tree drill down into composite types. The VS Code team had been working on something where one could show custom stuff between code lines, but I’m not sure whether that is going to ship anytime soon. I think adding progress reporting to VS Code would be feasible at this point, I’m pretty sure there are enough UI hooks to do that. Similarly, given the developer’s other focuses, I’m sure VSCode has some nifty stuff for data science.

That’s hard to match, though over time as VSCode adopts those features it’ll start to feel similar. With DifferentialEquations.jl I decided to start using Juno in Atom almost the day it came out (before that it was LightTable), so now there’s been about 4 years of issues, discussions, and PRs that make it great to use with DifferentialEquations. VSCode could get what Juno has.īut in some sense, the two have had somewhat of a different focus.

#Jupyter lighttable windows#

Recently TreeViews.jl was sectioned off, so a REPL-based version of treeview outputs could be made, and then with new windows etc.

IIRC That has only in the last few months been changed with VSCode? That’s a question for but that’s really been the big deal since those tree views are pretty essential for some applications (like differential equations where the nesting can get quite deep). The window system is much more flexible, so a lot of the inline results and progress bar stuff was only really doable in Atom. Are there further reasons to continue to maintain Juno beyond momentum?