Julia vs PtPython REPL

Erik Engheim
6 min readNov 15, 2017

So I finally got around to trying out the PtPython REPL which you recommended John. I can only comment on my out of the box experience using it, as I don’t have time to do any sort of extensive review of it. Perhaps you can correct my impressions if I do it great injustice.

My first reaction is that I find it unpolished. The Julia REPL feels like it might have less features but those are more polished and well thought out. But I’ll come back to that. Let me address the various points you raised.

This reads like an article by someone going from one language to another and frustrated by the small differences — one result of which is frustration, and another is that you don’t make the best choices for the “new” language. I recently taught myself Go and initially suffered the same problems.

That is almost what it was. It was my out of the box experience from using Python again after a long hiatus. I’ve used plenty of languages over the years, so this is not new to me. What this was perhaps more about was the fact that after all these years away from Python I had frankly expected more progress. That standard REPL bundled with Python today did not feel much different from the one I used 16 years ago when I first started using Python.

At the time Python was light years ahead of most mainstream alternatives. Python is often held up as paragon of ease of use and elegant design. While it is a good language I am not sure if it quite lives up to its hype in this day and age. Today I think the main selling point is the size of its community and breath of packages, not so much the language itself.

I’ll just make two points.

First, I got Julia 0.6 out this morning and while rediscovering the frustration of Arrays vs Lists as well as counting from 1,

I don’t know what you refer to with respect to arrays vs lists. Could you elaborate? In fact I think arrays are really done right in Julia. I have long wanted a language to properly handle multidimensional arrays.

I think the 1 based indexing is greatly exagurated as a problem in Julia. First of all Julia supports arrays with arbitrary indexing through offset arrays at no performance cost. Secondly if you do mathematics, you should already be used to this indexing. And that is the target group. I am neither a scientists or mathematician, but have never found this problematic when using other 1 based languages such as Lua or Matlab.

noted that the Julia repl is nicer than it was back at 0.3 but poor in comparison to ptpython. Ptipython gives all the ipython enhancements plus it allows me vim mode editing within the repl and a switch to vim (key v) for more complex tasks. Emacs style obviously for those that prefer it. Also has ? as well as help().

I think I have to respectfully disagree with you. While it does seem like quite a nice REPL and a great improvement on the default Python one, from my short usage of PtPython I experienced several annoyances:

  1. The completion menu flickers constantly as you are writing code. This is very distracting. The completion menu moves as you type, which draws you attention unessesarly to it. At least the Julia Juno environment keeps it in a stable position while you type as to not distract too much.
  2. Almost anything you write gives a suggestion for completion which are mostly not what you want. Just write some numbers and it suggest and, if, in etc. Hit complete and it adds the completion right adjacent to the expression you wrote, making it illegal syntax.
  3. Out of the box I could not see the arguments to functions. This works right away in Julia in a natural way and allows you to narrow down selection of the right function based on the arguments type. With some tweaking I got this working, but it still felt a bit awkward to use. However the way the help docs can be displayed is very nice.
  4. I could not figure out how history works. Julia REPL works almost exactly like the fish shell which I use. You just start typing something and hit arrow up or down to cycle through things in history which being with the same letters. This is functionality which is quite easy to discover because up and down arrow already cycles history in most shells. This is probably my most used feature and I could not discover anything comparable in PtPython.
  5. The multiline edit fit my workflow poorly. I frequently have to make small changes to previously written code. In Julia you make the change and hit enter in the middle of the code and you are done. Again this is similar to the behavior of most shells. In PtPython I have to move the cursor all the way to the end to finish every tiny edit. It breaks the flow and requires learning a new habit as it runs counter to what you expect from other shells.
  6. When you cycle through history with the arrow keys, the cursor jumps to the bottom of any multiline edit in your history, and it doesn’t cycle to the next match until your cursor jumps all the way to the top again. So going through three different 5 line class definitions would require 15 arrow key taps! Such poor ergonomics seems to be everywhere in PtPython.

It is nice that PtPython does path name completions in strings like the Julia REPL. However I did not find any nice way to integrate with the unix shell, nor could I get the ? help to work. This is one of the things I like about the Julia REPL. It supports multiple modes and you can add more modes with plugins. Hence you can add a C++ REPL mode and a debugger mode e.g.

What I also missed is a way of viewing source code for function and jumping to the source code. Is there a way to do this? I couldn’t figure it out. In Julia I can use the less or edit macros for this. I edit use all the time. I find that a lot more useful for doing complex editing that fitting a whole emacs or vim style editing aparatus inside my REPL.

Second, although Julia is fast once its running (the examples on the front page exaggerate it though but lets not go there), its not fast to start. If you use julia to write shell scripts you need to take into account the jit compilation. On most machines that’s going to take 200–300ms for a small script and in that time a sh script or even a python script will have finished and spent most of the time waiting around.

That was certainly a problem in the past when I wrote a TextMate bundle utilizing Julia scripts. But with precompiled packages this is much less of a problem today. What scenarious exactly do you see this a a problem? I’ve never experienced this a a problem. However I don’t really write scripts but functions. I stuff all my utility functions in a file and fire that up in the Julia REPL and keep it there. There is no need for little utilities to run from a unix shell. They might as well run straight from the Julia shell as needed.

Of course some Julia code has to be integrated as scripts as they are e.g. run by the build system of my IDE. In the cases I’ve done that, I am processing so much code that I’ve seen big net gains from using Julia instead of e.g. bash.

So, personally I like Julia, but its not the holy grail.

No language is, but isn’t it a bit odd to call out Julia on this? Julia is a relatively unknown language. Python is the established player with immense popularity. If anything, should we not rather point out that Python is not the holy grail, and that there are actually quite a lot of other nice, lesser known languages out there, such as Julia?

--

--

Erik Engheim

Geek dad, living in Oslo, Norway with passion for UX, Julia programming, science, teaching, reading and writing.