3 ms·

I'd probably argue the opposite. Dataflow is a natural way to think about ML activities. The problem is that no mainstream languages offer dataflow as a first

I'd probably argue the opposite. Dataflow is a natural way to think about ML activities. The problem is that no mainstream languages offer dataflow as a first class construct; at best it's a set of libraries. That creates some impedance mismatch between intent and implementation. That compilers already do dataflow under the covers would hopefully mean that implementing a first-class dataflow language wouldn't be too hard.

giornogiovanna 8y ago
What would a language primitive for "dataflow" look like, and what would it offer over an implementation as a library?
- spinningslate 8y ago
  There are a few things, nicely covered in "Concepts, Techniques and Models of Computer Programming" by Van Roy and Heridi [0]. Briefly: 1. First-class dataflow variables 2. Syntax for creating flows (c/f pipe in *nix shell) 3. Transparent parallelisation All of these things exist in libraries of various sorts, but can feel cumbersome compared to native syntax. [0] https://mitpress.mit.edu/books/concepts-techniques-and-models-computer-programming https://mitpress.mit.edu/books/concepts-techniques-and-model...
- nikofeyn 8y ago
  a wire.
amelius 8y ago
By that argument, dataflow is also a natural way to think about NumPy/SciPy programs. However ... that's not really true. Humans prefer to think in terms of operations (consecutive steps) and labels for intermediate results. The most important situation where this is important is if the dataflow is dynamic. A dynamic graph can make it unclear what is assigned to what, at which point in time, and programming becomes a mess.