preplish VS jupyter

> what's wrong with that?

Why nothing at all, of course. A REPL need not be more than a way to test and explore syntax, functions, and logical structures.

> the user experience is REPL-ish and it can help some people learn the _basics_ of the language

PREPLISH exists for Perl ^_^

https://github.com/viviparous/preplish

If this is for testing of syntax or of trivial code, it sounds like a good use-case for running a local REPL. (Example: https://github.com/viviparous/preplish)

This is a simple REPL project and the readme lists other Perl REPLs.

https://github.com/viviparous/preplish

Perl's concise syntax makes working in a REPL a pleasure. Python has a REPL but the design of the language makes it expand both in length (for loops) and in width (tabs).

I am a recent convert to working in a REPL first to test programming ideas.

I made this solution for some of my simple data wrangling: https://github.com/viviparous/preplish

I tried the module it in a Perl REPL (https://github.com/viviparous/preplish) and got the following ravings that are worthy of a US loony politician:

I agree with you that the immediate start-up and feedback is a great benefit to the coder. This is why I dislike complex, Rube-Goldbergian REPL systems.

There is a use-case for a throw-away interaction with a REPL. For example, how does $builtinFuncX work, or how would $data best be imported into a structure?

A REPL can also be a good initial approach to a more ambitious problem. In this case, a REPL can be good for focus and discipline.

If the second case is going to answer your concern and be constructive, it's necessary to be able to build the code for sharing and cleanly export the code for re-use.

I've had success tackling challenges using REPLs for Python and Perl [1] in both ways. But no tooling is going to solve the problem of a sloppy teammate who claims success just because "it compiles" and "it works on my box". A person who knows how to build good tooling goes further.

[1] https://github.com/viviparous/preplish

It is Jupyter is a Rube-Goldbergian nightmare. Python is a memory hog. There are better solutions, to be sure.

A simple REPL is all that's needed to both do A-type and B-type data exploration. (I won't use the term "data scientist", it's an exaggeration in most cases.)

Python has a REPL, R has a REPL, Perl has PDL and both a simple REPL (https://github.com/viviparous/preplish) and a more complex one (https://metacpan.org/pod/Reply).

Jupyter should not be used as an IDE because it is the wrong tool for development. A-type data explorers just want a painless UI and may not care much about the horrible agglutination of incomplete/slow/broken solutions that Jupyter represents.

For ipython, you'd better use some more specialized package like https://github.com/emacs-jupyter/jupyter, not the generic python support.

I have seen this thread, but I don't want to have to put an extra source block to set the renderers in every org file where I use plotly. Does anyone have a good solution for the moment? Any help is appreciated.

Should no one take you up on the bounty, I suggest trying emacs-jupyter instead. I've had better luck with it in the past.

For anybody following along with the examples, a few points/tips that might help newcomers:

1. (By default) before you can use Python source blocks, you need to have the Org Babel Python functionality loaded which is most easily done by evaluating the elisp (require 'ob-babel), but there are other ways also [1].

2. The first example, which uses the print function, will not output anything because the Python blocks by default are evaluated inside a function body and the return value is returned to Org [2]. To return the printed output instead, you need the header argument ":results output". There is an example of this syntax later in TFA.

3. If you are serious about replacing (or complementing) other Jupyter tools with Org mode, you might want to eventually look at emacs-jupyter [3], which provides a more advanced handling of outputs and also supports other (i.e. non-Python) kernels.

Also, I don't think I've ever seen anything like the debugging example and when I tried to replicate it out of curiosity, the block simply failed with a bdb.BdbQuit exception. Am I missing something? What is supposed to happen?

[1] https://orgmode.org/manual/Languages.html

[2] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-...

[3] https://github.com/nnicandro/emacs-jupyter

Emacs, Sublime Text 3 and Atom Pulsar can all do this with arbitrary Jupyter kernels with the emacs-jupyter/code-cells, helium and hydrogen packages, respectively.

You can use emacs as a jupyter client if that would help in your case https://github.com/nnicandro/emacs-jupyter

I've been using code-cells together with emacs-jupyter, the combination of the two lets you work pretty much identically as you would in Atom with Hydrogen, Sublime with Helium, or VSCode with the Jupyter Python extension; you just delimit code cells with #%% and execute in a separate Jupyter REPL buffer. It does require some getting used to the key bindings though (or some tweaking to make it more similar to what you're used to).

For writing source blocks: https://github.com/nnicandro/emacs-jupyter