Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Run code inline in Atom using Jupyter kernels

github.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Run code inline in Atom using Jupyter kernels

#41

Post by preek »

ZenoArrow wrote: post #33
pjmlp wrote: post #7

> Hydrogen was inspired by Bret Victor's ideas about the power of instantaneous feedback and the design of Light Table. 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 indu…

If you try hard enough, you could tie any new development to the past. 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.

Yet, if you do know Lisp, you realize that not too many languages feature a true REPL with the R not just reading in Text that gets evaluated, but actually being a Reader.

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

Re: Run code inline in Atom using Jupyter kernels

#42

Post by posterboy »

pjmlp wrote: post #40
ZenoArrow wrote: post #33

Earlier quoted context omitted.

If you try hard enough, you could tie any new development to the past. 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.

The way one interacts with the Xerox PARC and Lisp Machines environments is much richer experience than a plain REPL. 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.

That REPL is called a command line. Sure, it's not the same, but then it does not run on a virtual machine either (OK, LISP isn't necessarily, either).

You can still hook up a remote debugger to your kernel, I guess, but that's not quite the same then is it.

Re: Run code inline in Atom using Jupyter kernels

#43

Post by denfromufa »

olsgaard wrote: post #28

What Jupyter Notebook is missing is a good text/code editor and what good text/code editors are missing is Jupyter Notebook like write and execute. This is the first example I've seen of the power that using Electron in Atom can give, and it makes me super exited!

Have you tried PyCharm with jupyter notebook?

Re: Run code inline in Atom using Jupyter kernels

#44

Post by denfromufa »

tomw2005 wrote: post #21
glogla wrote: post #4

Many times I wanted to switch from Sublime Text to Atom, but I always went back for some reason (slowness, not remembering open files upon restart, etc). Maybe this will make me swich for good.

The fact that Atom was free and Open Source is mostly why I switched. You'll be happy to find that it does restore your last session as default now (add in the Project Manager plugin to make switching between projects easier too). Personally I haven't noticed any speed issues but YMMV.

I regularly about few hundred MB files in Sublime. The only alternative is VIM with plugins.

Re: Run code inline in Atom using Jupyter kernels

#45

Post by ZenoArrow »

pjmlp wrote: post #40
ZenoArrow wrote: post #33

Earlier quoted context omitted.

If you try hard enough, you could tie any new development to the past. 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.

The way one interacts with the Xerox PARC and Lisp Machines environments is much richer experience than a plain REPL. 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.

My point is that REPLs (and other dynamic programming tools) have been in constant use since they were invented, and although respect can be paid to the originators of the approach, we're not really experiencing a rediscovery of those first ideas, but rather we're experiencing an evolution of the ideas they started. In other words, there's been plenty of activity in this area between when they were invented and now, let's not discount that activity.

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.

https://en.wikipedia.org/wiki/Oberon_(operating_system)

Re: Run code inline in Atom using Jupyter kernels

#48

Post by pjmlp »

posterboy wrote: post #42
pjmlp wrote: post #40

Earlier quoted context omitted.

The way one interacts with the Xerox PARC and Lisp Machines environments is much richer experience than a plain REPL. 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.

That REPL is called a command line. Sure, it's not the same, but then it does not run on a virtual machine either (OK, LISP isn't necessarily, either). You can still hook up a remote debugger to your kernel, I guess, but that's not quite the same then is it.

That is not even close.

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.

Re: Run code inline in Atom using Jupyter kernels

#49

Post by pjmlp »

ZenoArrow wrote: post #45
pjmlp wrote: post #40

Earlier quoted context omitted.

The way one interacts with the Xerox PARC and Lisp Machines environments is much richer experience than a plain REPL. 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.

My point is that REPLs (and other dynamic programming tools) have been in constant use since they were invented, and although respect can be paid to the originators of the approach, we're not really experiencing a rediscovery of those first ideas, but rather we're experiencing an evolution of the ideas they started. In other words, there's been plenty of activity in this area between when they were invented and now,…

I was an Oberon user for a while, back when it was still being developed.

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.

Re: Run code inline in Atom using Jupyter kernels

#50

Post by posterboy »

pjmlp wrote: post #48
posterboy wrote: post #42

Earlier quoted context omitted.

That REPL is called a command line. Sure, it's not the same, but then it does not run on a virtual machine either (OK, LISP isn't necessarily, either). You can still hook up a remote debugger to your kernel, I guess, but that's not quite the same then is it.

That is not even close. 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,…

> That is not even close.

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.

Post reply on HN