4 ms·

Data flow, and FP, are about explicitly passing all the required dependencies into any step in the process, and getting back all the results I always knew ther

Data flow, and FP, are about explicitly passing all the required dependencies into any step in the process, and getting back all the results I always knew there was some relationship between FP and dataflow. There is something profound here. However, I'm not so sure that current FP languages are capturing this something in the best possible way. To me this: http://www.lihaoyi.com/post/BasicFunctionalProgramming/CodeGraph.png http://www.lihaoyi.com/post/BasicFunctionalProgramming/CodeG... Somehow seems far inferior to this: http://www.lihaoyi.com/post/BasicFunctionalProgramming/DiagramGraph.png http://www.lihaoyi.com/post/BasicFunctionalProgramming/Diagr...

lilactown 9y ago
Some syntactic sugar can help with this a bit; here's the same code rewritten using the pipe operator in Elixir: def make_tiramisu(eggs, sugar1, wine, cheese, cream, fingers, espresso, sugar2, cocoa) beat(eggs) |> beat(sugar1, wine) |> whisk |> beat(beat(cheese)) |> fold(whip(cream)) |> assemble( soak2seconds(fingers, disolve(sugar2, espresso))) |> sift(cocoa) end It reads a lot closer to the recipe, though the nested multiple operations are still a bit hard to read. Separating them into their own named functions would probably be better.
- eyelidlessness 9y ago
  In Clojure: (defn make-tiramisu [eggs sugar1 wine cheese cream fingers espresso sugar2 cocoa] (-> eggs (beat) (beat sugar1 wine) (whisk) (beat (beat cheese)) (fold (whip cream)) (assemble (soak2seconds fingers (dissolve sugar2 espresso))) (sift cocoa) (refrigerate)))
agumonkey 9y ago
My first love was computer graphics and multimedia, the only software I liked were ones that: 1) had features called virtual entities: you don't crunch bytes, you manipulate the concepts, and only when needed you compute 2) non destructive edition: since 1) you can pile up operations without ever fearing loss of information, or memory usage for backup. The first audio editing software I had was Sound Forge, a simple one, every operation meant allocating a new space, computing, filling. This meant limited undo and higher resource requirements 3) from 1 and 2 you get laziness (examples: nothing real shake, sidefx houdini, alias wavefront maya, sekd samplitude, anything by discreet. All these made far better use of your hardware. Compared to famous but non lazy ones such as Sound Forge or 3dsmax .. your poor desktop became pro tool (sic). Well until you hit the final render button of course) Later I discovered FP and I laughed nervously. Also many many highly rated CGI software use dataflow on a lazy DAG. GHC uses this for sharing computation in the evaluation model.
- mbrock 9y ago
  Here's a nice little paper from this year's ICFP about building a video editing tool using Racket. https://dl.acm.org/citation.cfm?doid=3136534.3110274 https://dl.acm.org/citation.cfm?doid=3136534.3110274 > The Racket doctrine tells developers to narrow the gap between the terminology of a problem domain and general programming constructs by creating languages instead of just plain programs. This pearl illustrates this point with the creation of a relatively simple domain-specific language for editing videos. To produce the video proceedings of a conference, for example, video professionals traditionally use "non-linear" GUI editors to manually edit each talk, despite the repetitive nature of the process. As it turns out, video editing naturally splits the work into a declarative phase and an imperative rendering phase at the end. Hence it is natural to create a functional-declarative language for the first phase, which reduces a lot of manual labor. This user-facing DSL utilizes a second, internal DSL to implement the second phase, which is an interface to a general, low-level C library. Finally, we inject type checking into our language via another DSL that supports programming in the language of type formalisms. In short, the development of the video editing language cleanly demonstrates how the Racket doctrine naturally leads to the creation of language hierarchies, analogous to the hierarchies of modules found in conventional functional languages.

lilactown 9y ago

Some syntactic sugar can help with this a bit; here's the same code rewritten using the pipe operator in Elixir: def make_tiramisu(eggs, sugar1, wine, cheese, cream, fingers, espresso, sugar2, cocoa) beat(eggs) |> beat(sugar1, wine) |> whisk |> beat(beat(cheese)) |> fold(whip(cream)) |> assemble( soak2seconds(fingers, disolve(sugar2, espresso))) |> sift(cocoa) end It reads a lot closer to the recipe, though the nested multiple operations are still a bit hard to read. Separating them into their own named functions would probably be better.

eyelidlessness 9y ago
In Clojure: (defn make-tiramisu [eggs sugar1 wine cheese cream fingers espresso sugar2 cocoa] (-> eggs (beat) (beat sugar1 wine) (whisk) (beat (beat cheese)) (fold (whip cream)) (assemble (soak2seconds fingers (dissolve sugar2 espresso))) (sift cocoa) (refrigerate)))

agumonkey 9y ago

My first love was computer graphics and multimedia, the only software I liked were ones that: 1) had features called virtual entities: you don't crunch bytes, you manipulate the concepts, and only when needed you compute 2) non destructive edition: since 1) you can pile up operations without ever fearing loss of information, or memory usage for backup. The first audio editing software I had was Sound Forge, a simple one, every operation meant allocating a new space, computing, filling. This meant limited undo and higher resource requirements 3) from 1 and 2 you get laziness (examples: nothing real shake, sidefx houdini, alias wavefront maya, sekd samplitude, anything by discreet. All these made far better use of your hardware. Compared to famous but non lazy ones such as Sound Forge or 3dsmax .. your poor desktop became pro tool (sic). Well until you hit the final render button of course) Later I discovered FP and I laughed nervously. Also many many highly rated CGI software use dataflow on a lazy DAG. GHC uses this for sharing computation in the evaluation model.

mbrock 9y ago
Here's a nice little paper from this year's ICFP about building a video editing tool using Racket. https://dl.acm.org/citation.cfm?doid=3136534.3110274 https://dl.acm.org/citation.cfm?doid=3136534.3110274 > The Racket doctrine tells developers to narrow the gap between the terminology of a problem domain and general programming constructs by creating languages instead of just plain programs. This pearl illustrates this point with the creation of a relatively simple domain-specific language for editing videos. To produce the video proceedings of a conference, for example, video professionals traditionally use "non-linear" GUI editors to manually edit each talk, despite the repetitive nature of the process. As it turns out, video editing naturally splits the work into a declarative phase and an imperative rendering phase at the end. Hence it is natural to create a functional-declarative language for the first phase, which reduces a lot of manual labor. This user-facing DSL utilizes a second, internal DSL to implement the second phase, which is an interface to a general, low-level C library. Finally, we inject type checking into our language via another DSL that supports programming in the language of type formalisms. In short, the development of the video editing language cleanly demonstrates how the Racket doctrine naturally leads to the creation of language hierarchies, analogous to the hierarchies of modules found in conventional functional languages.