Hacker News Reader

Comment by toolslive | Hacker News Reader

Am I the only one who doesn't like notebooks ?

I don't want to write code in a browser. For python you have something like ipython which allows you to have an interactive experience, while also allowing you to have your favourite editing environment. For ocaml, surely there are also repls that provide this kind of thing.

View on HN

My issue with REPLs is that they're often too transient. Sometimes I make a mistake on step 2 that I realize while iterating on step 10 of exploring some data. Then I need to iterate on step 2 a little, taking advantage of the ability to easily just run some of the calculations. Once I've got that, I can run the whole notebook again and make sure all my intermediate graphs look good.

The alternative is not programming purely in the repl but to have an editor where you type out your code and from where you can send bits of text to the repl to run and get feedback. All major editors have plugins to do this.

Me too, I just write .fsx scripts instead (F# interactive), it works nicely together with Plotly.NET. And can crunch / parallelize well if you want to do something over many files.

I hate em. They make people write bad code and using them for interactive development is much worse than using a REPL. I cannot understand what people see in them.

I use my IDE when I care about the production code, but I prefer notebooks when I’m just using code to understand data through visualization and statistics.

It drives me nuts that some people see this as «either or».

Linqpad is another and different take on data-driven environments. As is various «SQL admin» alternatives.

I love my fellow humans and do not begrudge you the workflow that you feel works for you.

They’re great for teaching. But I agree for actual work.

My workflow is to keep the notebook as thin as possible, and concise enough to fit in my brain. I explore the problem space and write some functions and data structures directly in the notebook, but as soon as I can, I refactor them into separate modules that I then import.

If I don’t, the notebook quickly becomes bloated, I start getting paranoid about stale cells and lose track of what I'm actually trying to do.

Ideally the notebook’s sole purpose is interactivity, as kind of a quick-and-dirty frontend when it's not worth it to write an actual frontend, everything infrastructural gets moved out.

You can write great code in notebooks; it all depends on you. Eg if you use vscode and not the browser for jupyter notebooks, you will have the same type checking and formatting as in the editor itself if you have it enabled.

For interactive development, repl is a joke. Sketching out a fully working prototype of a few hundred lines of code (possibly depending on some data and context you don't want to reload) is impossible in repl.

I totally dislike notebooks in the first place for a totally different reason. I'm really attached to my keyboard shortcuts, when I'm in a text editor or an IDE I have one specific "layout", but in the browser another. Some of my text editing shortcuts conflict with those in the browser (looking at you, ctrl-w for example).

I don't want to adapt, the shortcuts in the browser remain in the browser, and same for text editing, no overlapping.

I don't like them either. I find it hard to articulate why I don't like them. I definitely have experienced problems with them where they get into some state where the cell results are incorrect. Then, if I restart the kernel and run the cells again, I get the correct result. But I don't like them for reasons other than this one, and cannot explain why. I prefer the ipython REPL to the notebook.

Its a bit of nostalgia for me. It took a bit of work to understand ipython when I first started as a programmer, but that effort helped me in the long run. Using ipdb for breakpoints was a game changer in my first job.

And it also was a good way to get comfortable with using terminal.

Using notebooks removes all these learnings. I dislike it because it makes for less confident programmers in the long run.