5 ms·

> there's a DAG underneath Would you or someone care to elaborate? Do we mean the 'linking' between 'nodes' (cells) as an interpreter/compiler would do over a

by K0SM0S 7y ago

> there's a DAG underneath Would you or someone care to elaborate? Do we mean the 'linking' between 'nodes' (cells) as an interpreter/compiler would do over a file/object structure? Thus I assume, opening a world of options e.g. for vectorizing performance, type checking and all? If so, we have in one such notebook a true slice of "visual" IDE the kind of which Microsoft could only ever dream about! (so far) ;-) [Side-related note: I'm amazed at the emergence of the notebook paradigm over the last 10 years, accelerating for at least 2-4 now. See how they do it at Netflix. There's a case to be made that the notebook paradigm could really bridge wide open the "programming rift" between nerds and, well, everybody else, at least in skill-driven professional contexts. There's a short way from here to a slew of clever domain-driven script languages plugging straight into BI.]

TeMPOraL 7y ago
> Would you or someone care to elaborate? Do we mean the 'linking' between 'nodes' (cells) as an interpreter/compiler would do over a file/object structure? A DAG, or Directed Acyclic Graph. The most familiar example would be dependency graphs between packages. Or the dependency graph of your code (as interpreter/compiler would look at it). Or, any dependency graph in general. So the way reactive programming works - whether in React, ObservableHQ, or Excel - is this: you have these computation units (cells, pure functions) which have dependencies and they themselves are dependent upon. This forms your calculation graph, which you calculate by starting at the node without dependencies and evaluating one node after another in topological order[0]. The main optimization this permits is reducing the number of calculations: since dependencies are accounted for and navigable, whenever a node X changes, only nodes that depend on it need to be recomputed (and their dependants, recursively). "vectorizing performance, type checking and all" are not related to this concept. Reactive programming deals just with the dependency graph and (re)computing the right amount of nodes in the right order. Contrast that with a typical REPL model (or Jupyter model), where you execute cells one after another in the order you wrote them, and they mutate the global state of the application. RE your side note: yes, the notebook thing is a curious phenomenon, especially in a worse-is-better way (why did it have to be first Python, and now JavaScript?!). It's much older than that, though - you could trace its origin through things like Mathcad (essentially a buggy Jupyter requiring lots of clicking, but which produced a convincingly-looking math papers, and could do proper symbolic calculations out of the box), back to the early Lisp era (you don't have to type things into a Lisp REPL; if you type them in a file and annotate with comments as you go, you get a half-baked plaintext Jupyter). -- [0] - https://en.wikipedia.org/wiki/Topological_sorting https://en.wikipedia.org/wiki/Topological_sorting - i.e. you turn a graph into a sequence sorted so that the dependencies come before the things that depend on them.
- K0SM0S 7y ago
  Ah, I see now, thank you very much for the detailed explanation. Having used Excel for years as a barebones "logical framework" of sorts (before I knew better, in my teens, to solve various optimization problems in games notably like "best in slot" or "best resource distribution"), I've internalized a deep intuition for reactive programming. I had never realized this was an actual paradigm! On optimization / O(n), models tend to (d)evolve into highly recursive 'traps' with this approach, in my experience. I learned the value of e.g. indexes, isolating concerns, generally larger but flatter surfaces indeed. RE notebooks: I had no idea there was such a history of that. It's interesting that the approach only became somewhat popular recently.
  - TeMPOraL 7y ago
    You're welcome! Fun thing I recently discovered about Excel: there's a button in it, Formulas tab > Formulas Auditing > Trace Dependents (and the other - Trace Precedents), which makes Excel start drawing arrows between cells, letting you explore the underlying calculation DAG. Could you tell me more about those 'recursive' traps? RE notebooks, personally I blame it to a combination of a) Python taking the scientist community by storm (perhaps thanks to scipy), where prior popular scientific toolkits were proprietary, b) popularization of lightweight markup languages (like Markdown) and c) popularization of browser as runtime. There is history of scientists using org-mode for computational notebooks and publishing purposes, ticking both a) (powerful, open toolkit supporting not only Python, but just about anything) and b) very good markup language (org mode), but this ties potential collaborators to Emacs, so it had no chance to popularize. I don't know the relative timeline of org mode code evaluation vs. IPython/Jupyter, so I can't say whether this qualifies as prior art.
    - K0SM0S 7y ago
      > Could you tell me more about those 'recursive' traps? Well, these feel like 'traps' insofar as you suddenly fall into a crawl where things were fine just a step before. It's really a hands-on engineering kind of situation. You can't feel it much with small datasets. So I'm sure you know the kind. I really tried to write something worth reading but I'm afraid, after about a page at it, these are just the ramblings of a young mind before learning to program, etc. Here's the gist: - I discovered circular dependency, breaking the DAG. - Off-by-one-errors on base cases. - O(n^x) without realizing, which hurts later. It's just that now I know much more expensive words and concepts to describe or solve these 'traps'. ;-) RE notebooks, I think Python is the language of choice of science and data for various reasons that made it a no-brainer for IPython/Jupyter, whose primary purpose was clearly datavis afaict. You can plug community kernels¹ for just about any language, though I'm not sure how much it integrates with tooling (I know Julia is popular for math in Jupyter). Despite having a terminal opened 24/7, I never actually tried Emacs and org mode and I feel I missed a whole space in that regard... Notebooks in their current form are certainly popular, but I hear too many good features in other paradigms that leave room for improvement (or yet another strong solution). [1]: https://github.com/jupyter/jupyter/wiki/Jupyter-kernels https://github.com/jupyter/jupyter/wiki/Jupyter-kernels

by K0SM0S 7y ago

TeMPOraL 7y ago

> Would you or someone care to elaborate? Do we mean the 'linking' between 'nodes' (cells) as an interpreter/compiler would do over a file/object structure? A DAG, or Directed Acyclic Graph. The most familiar example would be dependency graphs between packages. Or the dependency graph of your code (as interpreter/compiler would look at it). Or, any dependency graph in general. So the way reactive programming works - whether in React, ObservableHQ, or Excel - is this: you have these computation units (cells, pure functions) which have dependencies and they themselves are dependent upon. This forms your calculation graph, which you calculate by starting at the node without dependencies and evaluating one node after another in topological order[0]. The main optimization this permits is reducing the number of calculations: since dependencies are accounted for and navigable, whenever a node X changes, only nodes that depend on it need to be recomputed (and their dependants, recursively). "vectorizing performance, type checking and all" are not related to this concept. Reactive programming deals just with the dependency graph and (re)computing the right amount of nodes in the right order. Contrast that with a typical REPL model (or Jupyter model), where you execute cells one after another in the order you wrote them, and they mutate the global state of the application. RE your side note: yes, the notebook thing is a curious phenomenon, especially in a worse-is-better way (why did it have to be first Python, and now JavaScript?!). It's much older than that, though - you could trace its origin through things like Mathcad (essentially a buggy Jupyter requiring lots of clicking, but which produced a convincingly-looking math papers, and could do proper symbolic calculations out of the box), back to the early Lisp era (you don't have to type things into a Lisp REPL; if you type them in a file and annotate with comments as you go, you get a half-baked plaintext Jupyter). -- [0] - https://en.wikipedia.org/wiki/Topological_sorting https://en.wikipedia.org/wiki/Topological_sorting - i.e. you turn a graph into a sequence sorted so that the dependencies come before the things that depend on them.

K0SM0S 7y ago
Ah, I see now, thank you very much for the detailed explanation. Having used Excel for years as a barebones "logical framework" of sorts (before I knew better, in my teens, to solve various optimization problems in games notably like "best in slot" or "best resource distribution"), I've internalized a deep intuition for reactive programming. I had never realized this was an actual paradigm! On optimization / O(n), models tend to (d)evolve into highly recursive 'traps' with this approach, in my experience. I learned the value of e.g. indexes, isolating concerns, generally larger but flatter surfaces indeed. RE notebooks: I had no idea there was such a history of that. It's interesting that the approach only became somewhat popular recently.
- TeMPOraL 7y ago
  You're welcome! Fun thing I recently discovered about Excel: there's a button in it, Formulas tab > Formulas Auditing > Trace Dependents (and the other - Trace Precedents), which makes Excel start drawing arrows between cells, letting you explore the underlying calculation DAG. Could you tell me more about those 'recursive' traps? RE notebooks, personally I blame it to a combination of a) Python taking the scientist community by storm (perhaps thanks to scipy), where prior popular scientific toolkits were proprietary, b) popularization of lightweight markup languages (like Markdown) and c) popularization of browser as runtime. There is history of scientists using org-mode for computational notebooks and publishing purposes, ticking both a) (powerful, open toolkit supporting not only Python, but just about anything) and b) very good markup language (org mode), but this ties potential collaborators to Emacs, so it had no chance to popularize. I don't know the relative timeline of org mode code evaluation vs. IPython/Jupyter, so I can't say whether this qualifies as prior art.
  - K0SM0S 7y ago
    > Could you tell me more about those 'recursive' traps? Well, these feel like 'traps' insofar as you suddenly fall into a crawl where things were fine just a step before. It's really a hands-on engineering kind of situation. You can't feel it much with small datasets. So I'm sure you know the kind. I really tried to write something worth reading but I'm afraid, after about a page at it, these are just the ramblings of a young mind before learning to program, etc. Here's the gist: - I discovered circular dependency, breaking the DAG. - Off-by-one-errors on base cases. - O(n^x) without realizing, which hurts later. It's just that now I know much more expensive words and concepts to describe or solve these 'traps'. ;-) RE notebooks, I think Python is the language of choice of science and data for various reasons that made it a no-brainer for IPython/Jupyter, whose primary purpose was clearly datavis afaict. You can plug community kernels¹ for just about any language, though I'm not sure how much it integrates with tooling (I know Julia is popular for math in Jupyter). Despite having a terminal opened 24/7, I never actually tried Emacs and org mode and I feel I missed a whole space in that regard... Notebooks in their current form are certainly popular, but I hear too many good features in other paradigms that leave room for improvement (or yet another strong solution). [1]: https://github.com/jupyter/jupyter/wiki/Jupyter-kernels https://github.com/jupyter/jupyter/wiki/Jupyter-kernels