4 ms·

My experience is in line with yours, debugging loops and functions is a big pain point. However, I think there's a much better solution to be had here, which i

by bicubic 10y ago

My experience is in line with yours, debugging loops and functions is a big pain point. However, I think there's a much better solution to be had here, which is to add more powerful debugging capabilities to Notebook. I think Notebook has potential for new debugging paradigms, imagine for example being able to break anywhere in a cell and get a new 'forked cell' which operates in the context of the code that you just broke into. I think that's the better direction to go instead of reverting to the very interfaces and paradigms that we moved away from.

nl 10y ago
I'm not sure (And by that I don't mean I disagree: I'm genuinely unsure). To me, the traditional IDEs do work well for debugging and software development. Notebooks are great for explanatory examples and interactive experiments. I think these are different to the type of software development I do when I use an IDE. For example, I find notebooks great for rapid iteration of parameters when I'm doing "data science", or indeed most of the feature extraction->modelling->prediction data science pipeline. What I don't find them good for is developing new algorithms. It isn't clear to me if this is an inherit limitation of the notebook format, or just something where it needs new developments. (To be clear, I've also used both Zeppelin and Beaker notebooks and don't see any particular advantages. I've also used R Studio, but I don't really know enough R to comment sensibly on that)
radiowave 10y ago
This sounds like a promising idea. As someone who still reaches for a Smalltalk environment when I need to prototype something, ipython notebook is about the closest thing I've ever found to the style of interaction you get with a Smalltalk REPL (aka "workspace"). Smalltalk deliberately blurs the lines between a text editor and REPL, and the debugger takes this a step further - a combined editor and REPL, within a suspended execution context. It could be argued, for example, that coding within the suspended context of a failed unit test, while the code underneath your cursor has this REPL-like liveness, is the non-cargo-cult way of doing TDD. I'm not trying to claim Smalltalk as the Greatest Thing Ever, but its existence (and its "otherness" - from the point of view of today's conventional style of development) are evidence that there are useful tools to be had, somewhere down a road less travelled.
- muraiki 10y ago
  I learned enough Smalltalk to make prototypes with Seaside. I love the way notebooks work and to make them more Smalltalky would be wonderful not only for programmers but for the field as a whole.
nikitakit 10y ago
I agree, the notebook could really have much more powerful debugging. I've actually been working on implementing something to that effect for Python (see http://kitaev.io/xdbg http://kitaev.io/xdbg). But it's been really hard to figure out who already has experience with similar workflows, because these tend to be isolated to particular language or devtools communities. Apparently I need to take a closer look at Smalltalk.

by bicubic 10y ago

nl 10y ago

I'm not sure (And by that I don't mean I disagree: I'm genuinely unsure). To me, the traditional IDEs do work well for debugging and software development. Notebooks are great for explanatory examples and interactive experiments. I think these are different to the type of software development I do when I use an IDE. For example, I find notebooks great for rapid iteration of parameters when I'm doing "data science", or indeed most of the feature extraction->modelling->prediction data science pipeline. What I don't find them good for is developing new algorithms. It isn't clear to me if this is an inherit limitation of the notebook format, or just something where it needs new developments. (To be clear, I've also used both Zeppelin and Beaker notebooks and don't see any particular advantages. I've also used R Studio, but I don't really know enough R to comment sensibly on that)

radiowave 10y ago

This sounds like a promising idea. As someone who still reaches for a Smalltalk environment when I need to prototype something, ipython notebook is about the closest thing I've ever found to the style of interaction you get with a Smalltalk REPL (aka "workspace"). Smalltalk deliberately blurs the lines between a text editor and REPL, and the debugger takes this a step further - a combined editor and REPL, within a suspended execution context. It could be argued, for example, that coding within the suspended context of a failed unit test, while the code underneath your cursor has this REPL-like liveness, is the non-cargo-cult way of doing TDD. I'm not trying to claim Smalltalk as the Greatest Thing Ever, but its existence (and its "otherness" - from the point of view of today's conventional style of development) are evidence that there are useful tools to be had, somewhere down a road less travelled.

muraiki 10y ago
I learned enough Smalltalk to make prototypes with Seaside. I love the way notebooks work and to make them more Smalltalky would be wonderful not only for programmers but for the field as a whole.

nikitakit 10y ago

I agree, the notebook could really have much more powerful debugging. I've actually been working on implementing something to that effect for Python (see http://kitaev.io/xdbg http://kitaev.io/xdbg). But it's been really hard to figure out who already has experience with similar workflows, because these tend to be isolated to particular language or devtools communities. Apparently I need to take a closer look at Smalltalk.