3 ms·

For a powerful counter-example, look at the industry-standard visual effects system Houdini, made by SideFX. Houdini programs (actually referred to as 'scenes')

by nezumi 14y ago

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.

bugsbunnyak 14y ago
Another one: http://www.mevislab.de/home/about-mevislab/ 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.
Derbasti 14y ago
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.
- gruseom 14y ago
  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.
  - dopamean 14y ago
    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.
    - gruseom 14y ago
      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.
podperson 14y ago
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.

by nezumi 14y ago

bugsbunnyak 14y ago

Another one: http://www.mevislab.de/home/about-mevislab/ 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.

Derbasti 14y ago

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.

gruseom 14y ago
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.
- dopamean 14y ago
  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.
  - gruseom 14y ago
    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.

podperson 14y ago

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.