[HN Gopher] A personal history of visual programming environment...
___________________________________________________________________
A personal history of visual programming environments (2021)
Author : narner
Score : 49 points
Date : 2022-12-22 15:25 UTC (7 hours ago)
(HTM) web link (nickarner.com)
(TXT) w3m dump (nickarner.com)
| hermitcrab wrote:
| I remember being blown away the first time I saw the visual
| programming tool that came with Silicon Graphics workstations.
|
| Visual programming works great as long as you restrict it to a
| particular domain (e.g. data processing, visualization, audio
| processing etc).
| buescher wrote:
| Iris Explorer. I would probably still be blown away today. The
| examples that came with it made you think you were driving a
| supercomputer. It turned out to be rather hard for me to get it
| to do anything it wasn't already set up to do, but maybe I just
| missed the point.
|
| IBM's open-sourced OpenDX is similar in scope and appears to
| run fine on Linux. I haven't used it in anger.
| DubiousPusher wrote:
| > as long as you restrict it to a particular domain
|
| why?
| hermitcrab wrote:
| There have been various attempts to replace general purpose
| text-based languages (such as C++ or Python) with visual
| programming. I don't think any of them have been very
| successful. The level of abstraction is too low to be a good
| fit with visual programming. You end up with massive
| spaghetti diagrams. For something like data processing the
| level of abstraction can be much higher and is a much better
| fit for visual programming.
| leetrout wrote:
| I enjoyed reading this. I knew of quartz composer but I never did
| anything with it.
|
| I love visual tools and I think they are underutilized today. I
| cut my teeth in ~2005 with Houdini[0] and Fusion[1] which are
| both heavily graph / node based (and procedural).
|
| Most recently I have been rekindling my love for visual
| programming and flow based programming and plan to spend some
| time in January and February doing more research around flow
| based programming for infrastructure management.
|
| I plan to get this sort of info published on my website which I
| have neglected for half a decade or more but if you are
| interested in visual programming you might enjoy checking these
| out:
|
| Unit from Samuel Timbo:
|
| https://github.com/samuelmtimbo/unit
|
| https://ioun.it/
|
| A video of me exploring what I figured out about it (while also
| learning to stream) https://www.youtube.com/watch?v=vwknTfGVDq8
|
| Behave-Graph from Ben Houston:
|
| https://github.com/bhouston/behave-graph
|
| And the products I learned so long ago
|
| [0] Houdini https://www.sidefx.com/products/houdini/
|
| [1] Fusion https://www.blackmagicdesign.com/products/fusion
| runlaszlorun wrote:
| Oh cool. Some interesting stuff in there thanks for posting.
| vegetablepotpie wrote:
| I played around with Quartz Composer when I had my Macintosh.
| It was neat finding an obscure app deep in the directory
| structure that you could use to create interesting visuals. It
| was like my little secret.
|
| I found out you could use it to create screen savers and iMovie
| effects. It provided a lot of opportunities to tinker.
|
| The one thing that was annoying was that it didn't offer a lot
| of control over the final visuals. I was used to Flash giving
| you frame by frame control, which you did not have in Quartz
| Composer.
|
| You could create some cool effects, have some interactivity,
| but it seemed very limited and niche.
| rzzzt wrote:
| I had a brief encounter with Natron, but could not really
| understand what is going on in it:
| https://natrongithub.github.io/#features
| incanus77 wrote:
| Quartz Composer was IMHO one of the coolest things to come out
| of Apple ~15 years ago in the early days of their Core
| Animation layer-based rendering framework. When I was first
| freelancing, I got a gig working on some displays for a large
| law firm and chose QC. Was able to do things like fancily
| display customer testimonials and the like, but have a Mac mini
| running things which had a shared folder that staff could just
| drop scans of letters in. It was the best of both worlds --
| amazing programmatic 3D rendering and Mac ease of use for the
| non-technical people.
|
| I also used it briefly for some small about box effects in my
| apps, which allowed me to programmatically insert text or
| imagery based on the user's registration or other variable data
| and just plug it into the inlets in the QC animation that was
| used.
|
| It was basically a totally programmer-exposed motion graphics
| package. Too good.
| s1mon wrote:
| I also came at some of this stuff from an early background in
| electronic music and modular synthesis (which is all about making
| the connections between functional blocks visual/visceral).
|
| I've used Max/MSP and Grasshopper. I find them really great for
| building up interactive tools which have a bunch of
| inputs/controls.
|
| The one down side of these tools is that they can turn into
| visual spaghetti code which is hard to trace.
|
| I strongly recommend the last two links in the article for their
| visual catalogs of visual programming environments.
| itishappy wrote:
| Visual spaghetti gets real bad real quick, but I find the
| process of despaghettification to be incredibly gratifying.
| Well routed graphs make my brain produce happy chemicals.
| Glench wrote:
| Related reading some of you may enjoy: My Heart Feeds a Series of
| Tubes: https://medium.com/message/my-heart-feeds-a-series-of-
| tubes-... A nostalgic love letter to Yahoo Pipes
| joseph4521 wrote:
| Visual programming is still very much used today if we count
| Unreal Engine blueprints, Blender shader nodes, Unity shader
| graph, etc.
| sbuk wrote:
| Have a look at SideFX Houdini - the whole environment is node
| based. Building models can take some getting used to, but it's
| really powerful.
|
| https://www.sidefx.com/products/houdini/
| 808nrlnd303 wrote:
| SideFX and derivatire started out as one team at first then
| they split and touchdesigner was born. TD is a powerhouse.
| https://derivative.ca
|
| Then there is https://cables.gl that is all web based and
| pretty neat to play around with.
|
| /best regards yours truly node junkie
| itishappy wrote:
| Surprised nobody's mentioned LabView yet! Anybody have
| experience/opinions using this? Their versioning is one of the
| worst I've ever seen, but they have a impressively comprehensive
| ecosystem of industrial test equipment.
|
| https://www.ni.com/en-us/shop/labview.html
| runlaszlorun wrote:
| I haven't used LabView much myself but did work at a company
| whose product replaced it with .Net tooling. I got a sense that
| some common programming idioms become spaghetti. I want to say
| maybe that there wasn't a proper loop in LabView?
|
| Take this with two grains of salt. I'm not actually a LabView
| user and what I know comes from a company replacing it.
| OkayPhysicist wrote:
| LabVIEW is a trap. If you are considering using LabVIEW for
| making product software, consider systems with better developer
| ergonomics, such as having your engineers write Python while
| being water boarded.
|
| The problem is that LabVIEW, the language and IDE, comes with
| LabVIEW, the integration library for your NI sensors and test
| equipment and other doohickies. So slapping a program together
| to gather some data and display it is trivial. But over time,
| you're going to start to add business logic. And at first it
| might be bearable: You're code will end up spaghetti
| periodically, but you'll refactor a little bit and it'll be
| fine. But your codebase will expand and expand, well beyond the
| relatively trivial amount of machine interface code and
| eventually you'll just be developing software, but in LabVIEW.
|
| And that's where LabVIEW's fundamental, inescapable flaws
| begin. A sample, in no particular order:
|
| 1. LabVIEW has a 1:1 correspondence between functions, files,
| and user interfaces. Every time you see a function (subVI in
| LabVIEW parlance), and want to know what it does, you'll end up
| opening 2 windows: the user interface, which for 90+% of vis is
| never actually shown to the user, or holds any relevant
| information whatsover, but has to be opened nonetheless), and
| the code, which may be trivial, or may be complex, but you had
| no way of knowing before you dove in. Because it takes up a
| whole window, you get far and beyond less information density
| than in a textual programming language, which pushes towards
| inlining a lot of repeated code, but because the actual
| experience of writing LabVIEW is so miserable, you'll want to
| implement a lot of stuff as subVIs. It's a lose-lose.
|
| 2. LabVIEW's pretty-path for software development is
| untestable. At some point, you'll say "Ah, I can make user
| interfaces actually work the way anybody wants them to using
| Events!". Events are lovely, except you cannot test them.
| Period. Despite LabVIEW being uniquely situated to allow for a
| system for inserting mocking code between all those user
| interfaces you've been making and your code, they refuse to do
| so, and since LabVIEW is proprietary garbage, you can't even
| fix this yourself.
|
| 3. Pixel art for subVI icons. Here, you get make a terrible
| choice: When looking at some LabVIEW code, do you want to A)
| have basically no way to distinguish between different
| functions without hovering over them (imagine if all your
| function names were func1() func2() etc, until you selected
| them), or B) spend an obnoxious amount of time designing little
| hieroglyphics for future programmers to decipher. The only
| silver lining is that you're fucked either way.
|
| 4. Laying out wires. Have you ever thought to yourself: "You
| know what I need? More freedom of choice when it comes to
| expressing myself through data flow"? Well good news! LabVIEW
| will give you an endless amount of personal freedom when it
| comes to expressing how data goes from the output of one
| function to the input of the next. Make sure to lay it out in a
| nice sane way, otherwise you will progressively go mad. If you
| get bored, you can always try and use the built in layout
| engine which, besides being written by an engineer who's idea
| of a tidying up is pushing all his crap against one wall and
| marveling at his newfound floor space, will also creatively
| route your wires all over the place. If you really enjoy
| formatting your code, LabVIEW might be a good choice.
|
| 5. On the topic of wires: You never really appreciate how much
| context gets encoded in variable names until you don't have
| any. Compared to other issues it's not THAT big a deal, but
| you'll miss it.
|
| 6. Version control: The diff tool works most but not all of the
| time, and the merge tool rarely can even load vis and when it
| can, it's utterly worthless anyway. Resolve all merge conflicts
| with "theirs" or "ours", or just abandon a branch based
| workflow altogether. Also, those binary blobs spontaneously
| change sometimes when opened.
|
| 7. No built-in support for Key-Value data structures. This
| leads to a lot of LabVIEW code falling back to either awkward
| structs (anonymous or otherwise), or using just a bunch of
| wires that should just always go everywhere together.
|
| 8. The interface is not resizeable. You cannot zoom in, you
| cannot zoom out, and if you deign to complain about it to NI
| you'll be told that you can avoid zooming out by making more,
| smaller vis, which besides making the issues of having too many
| Vis even worse, also completely fails to address the fact that
| I want to zoom in so that the tiny 5 pixel wires are a little
| more legible.
|
| 9. On the topic of things NI is aware of but is either too
| stubborn or dimwitted to fix: LABVIEW BREAKS ALT-TAB. Yes,
| that's right, the language where you need to regularly juggle
| having dozens of windows open breaks the most basic form of
| shortcut navigation. When you alt-tab to a Vi window, it brings
| every Vi window on top of whatever else you were doing. All
| several dozen of them. If you had the misfortune of having a VI
| running while you did that, that VI doesn't appear on the alt-
| Tab menu list at all. It's still there, buried somewhere, but
| you're going to have to drag every last window around to dig
| for it, like a Saint Bernard looking for an avalanche survivor.
| Again, don't bother complaining to NI about this, since they'll
| just spout some crap about how they can't fix it because it's
| just how Windows works. Nevermind the fact that this is the
| ONLY program I've ever seen that fucks up Alt-Tab like this.
|
| In short, don't use LabVIEW for anything, unless it's some kind
| of S&M thing between you and your engineers.
| hermitcrab wrote:
| No zoom? Wow. I've written a visual programming tool for data
| wrangling and I addd zoom pretty much on day 1 of coding.
| runlaszlorun wrote:
| Any reason why we don't have a visual tool that builds an AST?
|
| I know that there have been a lot of insultingly bad visual
| tools. And I totally get why we often use text. And most of us
| are comfortable in our own IDE or what not setups.
|
| But if you honestly take a step back, we're trying to mimic a
| more graphical approach in text- curly braces, syntax
| highlighting, identation, etc.
|
| I think the world is missing out on entire categories of folks
| who could be programming while we debate curly braces vs
| indentation and whether semi-colons are a good thing or not.
|
| In the near future, will they look back and laugh?
| buescher wrote:
| Do you mean something like Scratch/Snap!?
|
| https://scratch.mit.edu/
|
| https://snap.berkeley.edu/
___________________________________________________________________
(page generated 2022-12-22 23:02 UTC)