Hi All.
Please indulge my “ignorant” question.
If we had to attribute Grasshopper a programming paradigm… which one would it be? After your answers I’d dive in to deepen the knowledge, but I’m “needing” to know to give some soundness to my intuition based ideas…
Flow Based Programming (FBP), which is a paradigm more than a language.
GH isn’t “pure” FBP but very much in that direction. Invented in the late sixties and used commercially by IBM in the seventies.
FBP can be implemented in any language, since it’s a way of thinking (paradigm).
== The basic idea ==
The paradigm: Think of FBP as a factory where the “machines” are the (GH) components (separate classes specialized for doing one thing) and the wires are the routing (colored lines on the floor) showing how the raw materials (the data) should flow through the facility (GH definition/Canvas).
In the physical world we could call exactly the same concept for “Flow Based Material Processing”
A classic book (free to download) describing the basics. There’s a second edition for sale.
Some thoughts on the subject by the inventor (or at least one of them which developed the ideas into something very powerful and useful):
5 Likes
The problem with your question is that it can intersect from many perspectives, it’s ambiguous. From the UI, it’s a visual programming editor. If you look at the question from the UX, it’s procedural modeling. If you look at it from the end result, it’s a 3d parametric object program. If you look at it from somewhere else, it’s a plug-in for Rhino…
2 Likes
That’s not aspects of the “paradigm”. A paradigm is about the though process, not how you implement it.
FBP works equally well both as pure text and with support of visual canvas (like GH). One example of textual based FBP for scientific workflows in Bioinformatics (and used also by NASA), is implemented in pure Go, no other UI involved than notepad.
I know about this particular software because my son developed it. He also enhanced Spotify’s Luigi to better support workflows in High performance Computing, HPC (similar use, similar naming, namely SciLuigi)- It’s opensource on Spotify’s github accont.
FBP is a paradigm more than any particular technology, visual or textual.
// Rolf
4 Likes
Thanks very much @RIL. I asked because I was trying to fit GH into this allegedly four paradigms of imperative/declarative/functional/object oriented (which I don´t know if can be merged or are excluding towards each other) and trough my poor intuition it didn´t properly fit in any of the four…
Now onto my next question…
Would it be possible to build interactive objects in GH? I believe @DanielPiker’S kangaroo actually does it, right?
My goal, simplified is:
Building two BReps in Rhino
Embed in GH
Test collision by moving them in Rhino UI
IF collision happens then check for some BRep property and do something depending on it.
I guess this contradicts the FBP because I’d like to embed the data into the object and in GH, data usually flows parallel but not IN the object, right?
Would that be possible/reasonable in GH?
I’m developing a conceptual model for information-based design and using GH for prototyping, but I don’t know if I have hit a wall…
One of my premises (almost wish) is that my model should be possible without the need to ad-hoc coding…
FBP can utilize “any technique”. Again, think of a factory producing stuff. You can push and you can pull, you can have sensors reacting on incoming materials from another machine. But one machine will NEVER EVER “call” directly into another machine. One GH Component should (ideally) NEVER EVER call into another component. Components in GH are pure OOP where a class has many similarities with a physical machine, so OOP is fine if kept in a cage (think of physical machines, they don’t store materials inside them… which was one of the several TERRIBLE mistakes in which OOP got off track many decades ago).
Many different concepts and techniques can be used and orchestrated inside a flow based system.
Anyway, the only way in which one machine “communicates” with another machine in a physical factory is by spitting out processed materials so that downstream machines (think also gh components) can pick them up when they arrive. That’s the “factory paradigm” which also GH supports.
In a factory, when you want something done you pick a suitable machine and feed in some raw material, or in GH, you pick a component, and feed it with some raw data. And so on.
In that flow of data, processing and distribution events, you can use many different approaches, but you ruin the whole idea (paradigm) if you let one machine “call into” another machine, or GH: one component call into another component. Sliders and such aside. Any paradigm which makes upstream “calls” asking for data or as to imperatively force some process, is no-no. That’s not “flow”, it’s … it’s … abuse. 
Each machine, or GH component, opens up an input - when it has the time to do so, and then it does it’s thing, and puts it on a pallet outside the machine. That’s how far each machine or component may “reach” out from its confinement. OOP inside a component is perfectly fine. It’s doesn’t affect the paradigm one bit. No one wouldn’t even know if the code inside a component is OOP or procedural, functional, or whatever, an it doesn’t matter either. Just like it doesn’t really matter if a milling machine is driven by electricity, fossil fuel, nuclear powered steam punk, or whatever, as long as it does its thing, and no more.
The only major concept apart from the mentioned “machines → material flow → machine” is the art of “orchestration”. And here lays much of the good stuff - you can rewire more or less fool-proof components or machines (in most cases they have been battle-tested for some time) and no or extremely few silly bugs will surprise you no matter how you reorganize the factory / data processing. And if you have bottle necks, just stack machines /components side by side and run the process in parallel (GH unfortunately doesn’t support parallel computing by rewiring components as to let users “orchestrate” the data processing more efficiently).
And so on, and so on. Orchestration is best performed NOT by OOP but by Erlang (it can handle zillions of concurrent processes simultaneously… since it was designed for that, for telecom (massive numbers of phone calls going on all the time). That’s the “orchestration” part. A jazz orchestra also comes to mind, but only to some extent.
Factory is the best metaphor describing this paradim. A factory deals with all the problems and and phenomenons which also a software system deals with, or should be able to handle. And factory way’s of thinking isn’t a very brand new paradigm. People have mastered complex processes thousands of years before we invented computers (and immediately started to mess things up).
A factory is “material centric” and many of our software systems should be more “data centric”. Now they are often the opposite - namely Application Centric (meaning, feed some raw material into the machine, or application, and the machine snatches it an stores it and…). Application Centric leads to Integration Hell.
// Rolf
3 Likes
10^6 Thanks @RIL your explanation is amazingly didactic and I think it gave me a clue as to how i should be modelling my prototype to stay inside grasshopper and remain true to my concepts.
I believe can check the situation among the BReps by feeding it as data to an external machine and it can then output order to the subsequent segment in the flow of operations…
Again thanks for taking the time for such a clear explanation!
Some people will never accept that the Application Centric approach fits all problems (because it doesn’t) was a mistake. There are examples where Application Centric is just fine, CAD software for example (but only if the data is not totally trapped inside…, I mean, we all know about the terrible integration problems between CAD systems and BIM and Business systems and…)
ALL those problems are due to data being “encapsulated” inside applications / objects or databases, applications which all have their own way of defining data and… you’re lost.
One proof of the masive scalability of data centric concept - AND capability to handle soch massive complexity that no human has yet come close to any such complexity - is the human cell, where the “factory” is the so celled ribosome, and the machines are…
Let me go straight at it:
#1. Make arrays.
#2. Regardless of whether your data is complex or not, stuff them into arrays, and
#3. let a bunch of machines run down the array and refine the data, with incredible speed.
(No data races there no. And game developers know exactly why this is how it’s done).
OK, that was about speed an concurrency, but what about complexity?
Look at this clip. Here you have FBP in full action. Molecular machines running up and down “arrays” of data (DNA/RNA) and processing billions of data snippets, each second. In “concert”. And no or very little “dataraces” or “deadlocks” (the main problems with parallel computing).
Starting at t=451 so you hit the ground running:
Factory was the word. Speed and Complexity solved. (ages ago). It’s about the paradigm. All tricks and techniques are allowed, as long as you don’t abandon the paradigm. The way of thinking.
// Rolf
I didn’t talk about aspects, I talked about contexts.
In philosophy, paradigms are the patterns that describe a field, like a standard or consensus about a system. In programming, everything is constructed above other paradigms somehow. So you have to cut your ZBuffer somewhere. But forget it, as a programming language paradigm, GH is Flow-based programming.
I doubt the production managers view their way of organizing processes and material flow as a “language”. Just like factories are organized and produces “all kinds of stuff” in “all kinds of ways” also FBP and GH) can be wired together in different ways, even the same end result can be achieved by wiring different components in different ways.
So its not so much about language, but if it is, FBP can be practiced using any language. 
To my knowledge FBP (as defined by J.P Morrison) has been implemented in Java, C++, Lua Javascript, Go and probably more. To be clear, FBP is not constrained by language.
Instead there’s an increasing awareness about the benefits with data being “freed” from the processes that operate on them. Including Applications. And most software designers (including you of course) knows that, depending on the end goal, if you structure your data in a certain way, you can perform the data processing more efficiently. But if you stop there and be content with achieving good performance processing a specific task, that doesn’t mean that the data is easily accessible for “the rest of the world” (which it often needs to be). This is why Data Centric, in general, is also very important (meaning that you should only locally prepare and structure your data for efficient processing, but then “unpack” the data again to a more accessible format after the refinement is done, and so on).
It really is a way of thinking. A language? Nah. I speak Swedish, but I can do equally well speaking English. Language doesn’t matter (expect for Spanish, and Mandarin of course, then I’m lost… and all the other languages as well )
One last thing – looking at the video clip, I want to clarify that it does of course not matter if the “machines” or processes run along the data/arrays, or if the data (arrays) runs or flows through the processing machines. Same idea either way.
// Rolf
You have a very small interpretation of what the language means. The categorization that separates flow-based programming from the rest of the same family of programming paradigms is in fact its language, which is graphical and graph-based. With that you communicate with the machine to do a task or think algorithmically.
Graph based doesn’t imply visual or graphical, although that 's one implementation. Use a map or a way-description with words only. What’s important is how you think about it.
I linked to a 100% text based implementation, of the same paradigm. It’s a way of thinking, which can be expressed or implemented, in any language. Using OOP in the implementation is fine, functional is fine as well, reactive concepts, yes of course, apart from plain languages.
Regarding “visual languages” (yes, such languages do exist) there’s exactly zero unbreakable connection to visibility, but also no given syntax. “Graph” also means entirely different things depending on which visual notation or “syntax” you use.
Example of two different visual languages depicting entirely different things:
Example #1. Data flows. Data has Direction and flows from left to right (which is presupposed), etc. How data is moving and transformed.
Example 2: Data stands still. How data belongs. What meaning data has, its semantics. Data’s structure. Data’s relations to other data. None or little of that in the previous “language”.
Example 3. 100% textual, like SciLuigi and SciPipe.
Different languages but the way you organize and process data can be handled using any language, with or without diagrams, which also exist in different “languages”, like the two above (Flow of data or its structure & semantics (UML in example 2).
FBP isn’t depending on any particular “language” visual or textual. Or, use any language! (which is what separates FBP from any particular “language”).
// Rolf
You can create GH definitions without using any graphics, writing code with text, and any FBP language can be represented with graphics, you only need an entity that draws the component. This is because language is more than you think, it is not only a representation of the content of a system (syntax), it is also the communication rules of a system (grammar). The same language can have several ways to be represented. Besides, you cannot adequately understand a programming paradigm, which is what he asked, without the concept of language, as a concept, not as an implementation. Programming is communicating with computers.
In this case, you can use the input-process-output form as if it were your word in your language, and even if you do not include an image, it is still a graphic paradigm because it is 100% compatible with visual representation, due to how simple it is. Y that’s why is so limited.
You make it more complicated than it is. So many nuances are not necessary. This is something very explicit and easy to understand. Flow diagrams, connect nodes from outputs to inputs. What you say about thinking is algorithmic thinking, it is a paradigm of thinking, not programming. But confusion is normal if you ignore the context of what you define. And by the way, you as a human have a much more complex way of thinking than a flow diagram. Humans are not so basic, perhaps our way of representing yes, but our brain is not. Our human way of thinking is more similar to liquid state machines or eco state machines, which is the paradigm that graph-based database softwares use to represent and run knowledge graphs. Where instead of having a simple schema like input-process-ouput, we have entity-relation or other that include actions. It is another form of symbolic language, regardless of its implementation, because it allows you to communicate and represent everything using other principles more sophisticated. Being a symbolic language, like FBP, it can also be represented visually, with graphics, always.
EDIT: To clarify, all flow diagrams (understood as process connection, not as drawings) are networks but not all networks are flow diagrams, because there are networks whose circuit is not defined until you read or write, or networks that do not follow a directional flow, bc they behave like waves.
But that’s fine, you don’t have to see it like I do, it’s just an opinion that encompasses yours I think, because I’m not opposing you, just opening the field of vision.
1 Like
I think if you want to refer to those four paradigms you could a GrassHopper definition (as opposed to the underlying implementation of the GrassHopper software) uses functional programming methods but, like most practical functional programming languages, it is not purely functional because state can exist outside the flow, in the GrassHopper document, Rhino document and in the python interpreter (and probably many other locations).
I like Rolf’s Flow Based Programming definition, though as a fluid dynamicist I wonder whether it is really the ‘flow’ (quantity and quality of objects flowing) which is important to a GH definition or rather the processes - the nodes, factories, ‘functions’, leading back to thinking of it as functional programming …?
good luck with your work!
Graham
To elaborate a wee bit: Flow-based programming is a subset of Dataflow programming, which is a subset of Declarative programming. Making Grasshopper fundamentally declarative (in addition to being visual), but then of course the scripting components implement Imperative programming languages. Everybody wins 
5 Likes
Factory was my message. You mess it up by trying to make a paradigm into a question about language.
Focus = think factory, means = use (whatever language).
Who is (insisting on) making things complicated?
// Rolf
1 Like
They are all essential. But the way the data “flows” is different in how logic (or code) doesn’t “intertwine” like it does in imperative languages. GH is quite “declarative” in that sense. But that comes with “flow” (as flow goes downstreams “intertwine” won’t happen, which implies declarative, so there we are, landing in the fact that flow implies other concepts like declarative and also functional and… so on.)
Addendum: One important aspect of the paradigm of FBP is the word i used earlier, the “orchestration” of all the constituents of the system. As we have said, components can have any complexity inside, and use any language, and even any other paradigm inside, but to the “world outside” (to the Canvas if speaking GH) it is about how you orchestrate, or coordinate, everything that happens. Like @AndersDeleuran points out, classes and “imperative” paradigm is used inside GH components, but the point with GH is the orchestration of all these components.
Speaking of a poem, it uses words. My posts also contains words, but that doesn’t mean I’m writing poems here.
// Rolf
1 Like
And yet I feel a little lost again… 
It is you who reinvents the wheel using ideology and forced guru analogies. It’s simpler than what you’ve written before. As I said before, go ahead just like the artists of the 20th century inventing new -isms to create nothing new. 
Don’t try to explain to bark beetle’s what a forest is.
// Rolf
1 Like