Tangible Functional Programming by Conal Elliott • apps are user-friendly (usable, concrete, visual) but limit functionality, aren't composable • software libraries are programmer-friendly (composable, abstract, syntactic) The dream is: unlimited access to functionality, usably and composably. How? • Unix pipes are a composable text-mode UI, but we lose the GUI. • A Tangible Value is a typed value (model) paired with a GUI (view, controller). GUIs are composable whenever their underlying values are composable: eg unix-like pipelines, function composition. http://conal.net/blog/posts/tangible-functional-programming-a-modern-marriage-of-usability-and-composability

@Edward de Jong / Beads Project I’d recommend a second look at Conal’s work. Tangible Functional Values is not about GUI-building. It’s about value/product/output creation. The aim is to make the programming experience tangible and more approachable for non-linear thinkers. The non-composability of Unix pipes is one of the motives for the work—instead of the (untyped) single-output-single-input of pipes, Tangible Functional Values lets any (type-compatible) output feed into any (type-compatible) input. More importantly, this isn’t accomplished by a nodes-and-wires interface, but by a manipulable display of the values (the output), i.e. a display of “what you have”. So you feel like you are manipulating the things rather than the computation. Conal’s goal wasn’t to create a usable system, but to reduce this idea to its core elements, and he did so admirably. Centering values/outputs in the programming experience is moderately rare in FoC systems (and is perhaps a key feature of spreadsheets!). I like to call this mode of programming “value-centric” (as opposed to algorithm-centric or AST-centric). Of the value-centric programming systems I’m aware of, Conal’s is always the example I think of first because of its elegant simplicity (even if it is missing a few features to make it practical!).

@Brian Hempel Thanks for the spreadsheet analogy. Although watching the video, I didn't see see the equivalent of "editing the equation". Can you suggest related work that I should look at? I'm trying to understand these ideas well enough to implement them in a system for creating 3D models using pure functional programming.

Well there’s no text editing in Conal’s Eros as originally conceived so you’re right to wonder where it is. But Eros and spreadsheets both display values more prominently than code and invite manipulation on those values.

Value-based programming has some niches where it makes sense, like audio/video signal processing where the work product are data streams, and there is often a continuous flow to these streams you don't stop and think about them and wait for some input from the user. In graphical interactive software you have a lot of state, lots of widgets, and management of 500 things on the screen at the same time becomes a major chore. Even the portfolio management system i worked on in FORTRAN back in the day on mainframes did batch processing that included a fair amount of state as we were always accumulating numbers into buckets for sorting and categorizing purposes. None of the projects i have worked on would be convenient at all inside a data centric world. I understand Doug's art generation language would benefit from this, but i consider this area a very specialized niche. I think of a spreadsheet as a poor-man's database. It is fundamentally a 3.5 dimension system; you have a 2D sheet, which you can break into sub-rectangles, so i call that 2.5 dimensions, and the 3rd dimension is the array of named sheets you can have. As long as your data can fit into that dimensionality it works okay; especially since MS beefed up Excel to support about a million rows. But showing the data and hiding all the formulas makes most spreadsheets unauditable black magic systems, and really quite dangerous. It is a well known thing in business consulting to find out that some part of a company's fundamental processes have been automated via Excel. There is no question in my mind that a very robust data editor coupled with a graph database could give Excel a run for its money, but going up against the MS machine is an expensive process. Just like IBM they use the F.U.D. technique for suppressing competition.

And honestly Excel doesn't scale so well. As for the MS machine, I did not learn until visiting Microsoft (a good many years back now) how they had a real value proposition in supporting business seemingly separate from their role as a pedler of, iffy to my eyes, software.

At $12 a month per person, for an Office 365 license, MS has an almost insurmountable advantage. Google has been doing their best to cut off their air supply by gradually beefing up Google Sheets, and it is having some effect, but as a programming system once you go beyond simple stuff Excel is pretty ugly. But fully understand why people stay in Excel, because the current popular programming stack, HTML/CSS/JS/Frameworks is more than 10x the effort to learn.

@Edward de Jong / Beads Project Imperative programming (and shared mutable state) was a reasonable idea in the 1950's, 60's and 70's, when programs were small, processors had a single core, and internet-related security holes were not a concern. But imperative programming doesn't scale. The legacy of imperative and shared-mutable-state programming is responsible for our current software crisis. The future of coding is pure functional programming and immutable values. Large programs with shared mutable state can't be fully understood or debugged. This problem becomes much worse with multiple cores. The imperative programming community's response to multi-core programming was mutable state shared between threads and processor cores, guarded by mutexes. This is a catastrophically bad programming model. You can't understand or debug the code. The solution is to eliminate shared mutable state. Imperative programming doesn't scale to large numbers of cores--mutual exclusion mechanisms steal most of your performance. The solution is to eliminate shared mutable state. Machine learning with TensorFlow is an important example of massively multi-core programming. What makes it possible is that TensorFlow is a pure functional language. Unfortunately it has to be embedded in Python, because we don't have a mainstream pure functional language yet. As an aside, I find it tragic that my personal computer has a 1000 cores (most in the GPU), and most of these cores must remain idle because my system software and apps are written in weak, stone age imperative languages that don't provide a simple and efficient way to distribute computation across a huge number of cores. Imperative programming is a catastrophy for software security. In the imperative model, any function call can change any state in the entire system. This is the root cause of most security flaws. A sort function can encrypt all your files, display a ransom message, and phone home to an internet malware server. And we are seeing these kinds of exploits in supply chain attacks on open source software repositories. Pure functional programming puts security first: functions cannot have side effects, and functions have no access to data that isn't passed as an argument. The type system can trivially guarantee that a sort function will not intentionally spawn a bitcoin miner, or accidently corrupt shared mutable state outside of the array that you are sorting. A common response to the inherent insecurity of imperative code is sandboxing. It's a backwards approach. What if architects built buildings out of contact-sensitive explosive materials, then attempted to mitigate the resulting safety issues using a complex system of nested blast barriers. Imperative programming is inherently insecure, and pure functional programming is the answer.

@wtaysom In what ways do you think Excel doesn't scale? Thinking of 1) Having all values at all times on the screen, 2) Obfuscation and debuggability of logic 3) 1 million rows limit 4) Slow updates for big files. ...?

@Ricardo A. Medina (4) is what I had in mind though having just opened a 400,000 row file I happened to have handy to time some operations, I find Excel laggy but less laggy than remembered. (Could be new hardware or some performance improvement with tables. This is macOS mind you.)