Comment by nezumi | Hacker News Reader

Comment by nezumi | Hacker News Reader

For a powerful counter-example, look at the industry-standard visual effects system Houdini, made by SideFX. Houdini programs (actually referred to as 'scenes') are comprised of lazily-evaluated pure functions operating on a variety of data structures representing geometry, textures, shaders and so on. The system provides encapsulation, and an embedded expression language for cases where mathematical notation is more concise.

The curious thing about the world's most talented Houdini programmers is that they don't consider themselves programmers at all; their job titles normally include the term 'artist'. I've worked with people who wrote whole procedural simulations, image processing algorithms and shaders, who swore that they could not do programming.

As a seasoned coder by the time I first encountered Houdini, it took me months to get my head around it. It took me days to put together systems artists were able to build in hours. The lesson was: my knowledge of text-based, imperative programming was not directly transferrable to the node-based, procedural world.

Therefore, don't trust the judgement of a text-based programmer who declares that the tools of a visual programmer suck - it's not just a different dialect or different language, but a different medium entirely. And, effective visual programming systems are out there, but they don't have 'programming' written on them, because 'programmers' are not the target market.

Yesterday I discovered that a friend of mine is very used to many ideas in the functional programming world. She is an accountant, using Excel.

If you squint you eyes a little, Excel can be seen as functional programming: No mutable data, very short, pure functions that transform individual variables... data abstraction using intermediary tables... filter/map using pivot tables... reduce using ranges...

It is funny how much the advice of Excel wizards resembles common programming practices.

I'd be curious to know: does your friend make much use of names in Excel (i.e. assigning names to ranges and then using the names as variables in formulas)? and does she write VB code to do things that can't be done in cells?

The analogy to FP is striking, but not quite that complete. Excel doesn't let you define functions (i.e. it doesn't let you lay out formulas in cells and then call them repeatedly with different data) or types (i.e. it doesn't let you make multiple instances of a common model). It has variables, but the naming mechanism is primitive and not well integrated, so most people just work with raw cell addresses. And it arguably does have mutable data, because you can change what's in any cell at any time. I say "arguably" because one can argue the opposite: a spreadsheet defines one big pure function and if you change a cell then you're really just calling that function with a different input or changing the definition of the function. But I don't think anybody "feels" (or, for that matter, implements) spreadsheets that way. The cell contents feel like state and editing them feels like altering a machine as it runs.

To some extent it's a matter of how you frame it. If one expanded the identity of, say, a Haskell program to include both its code as it changes over time in the editor and the data that it gets applied to over time, it would seem mutable. No one looks at a Haskell program that way because we draw sharp lines between editing it, compiling it, and running it. But in spreadsheets those lines don't really exist. The program, the data it's applied to, and the editor are all together and the whole thing is live.

I use Excel a ton and do quite a bit VBA programming in my workbooks. I don't know what I'd do without names. I cant recall the last time I used a raw cell address. It is a nightmare trying to keep track of the ranges and gets exponentially worse when you have a multisheet workbook that has many references to cells on other sheets.

What's the maximum number of named ranges you've used in a spreadsheet? Don't you find the interface for defining names, or viewing them, inconvenient? It's completely divorced from the rest of the program IIRC.

She is using names a lot, but no VB.

You define your own functions with IF/ELSE and the like and then replicate that function by dragging it to other cells I suppose. So that is kind of an anonymous function that you map to a vector of data.

So instead of mutable data, lets call it side effects: There are certainly no side effects. One sheet defines a complete set of data that does not change at run time and nothing besides that sheet determines the outcome of the calculation.

Funny enough, she immediately understood the concept of mutable data and claimed that she is not thinking about her Excel sheets as mutable -- she is mostly doing data analysis and reports, so she considers her inputs very much immutable.

Well, the analogy is not perfect. But the similarity is striking.

Although the thread is old I want to add something:

"There are certainly no side effects. One sheet defines a complete set of data that does not change at run time"

-- this is not true. Just changing an input somewhere (and triggering any related recalc) counts as a side effect. Your view requires "freezing" the spreadsheet at a given point in time. This is misleading, because spreadsheets are so interactive. Even your friend, who doesn't change the inputs after entering them, still has to enter them in the first place. There are a whole lot of side effects happening while she does that.

The Achilles' heel of pure functional programming, I/O, is not a problem for spreadsheets, which are a kind of REPL. Their way of doing I/O is highly specialized (you can edit a cell but reading from a file is not so easy). But that's fine: the fact that spreadsheets aren't general-purpose computing environments is part of their strength.

It's a mistake to look at spreadsheets qua programming language without taking the UI into account, and once you do take it into account, the FP analogy breaks down. In my view, a more reliable way to understand spreadsheets is as belonging to the class of interactive computing environments populated by Lisp, Smalltalk, APL, and Forth.

It's a question of problem domain. Would I rather design a shader using a visual graph system or text? Probably the graph system. Would I rather build a user interface using Interface Builder or pure code? Probably Interface Builder. But there are plenty of cases where a visual tool will be more cumbersome than text, perhaps because no visual tool has yet been built to deal with a given problem domain, perhaps because it's not really amenable to visual representation.

Another one: http://www.mevislab.de/home/about-mevislab/

I think one of the advantages of a visual paradigm (at least for MevisLab) is that it forces modularity of all components. To avoid the wire-frame spaghetti, functionality can be encapsulated in containers with well-defined input/output ports, which makes that functionality trivially reusable in other contexts.

The productivity increase over competing frameworks is remarkable - I've seen a feature-complete demo delivered to a physician in 3 days. An experienced MS-level engineer took 3 months to implement comparable functionality in a Python/C++ framework.

Reply on news.ycombinator.com