Live data from Hacker News

Folk wisdom on visual programming

drossbucket.com

81–90 of 168 posts

Re: Folk wisdom on visual programming

#82
post #73

Earlier quoted context omitted.

> I used LabVIEW extensively for a few months I’m not sure that a few months is enough to understand the true pros and cons of a language. I’m using Elixir in my day job now and have used F# for side projects, and it’s not clear to me any one is faster to program in, especially for GUIs. LabVIEW actually shines, contrary to popular but inexperienced opinion, for large projects. I have used LabVIEW rather extensively,…

Unless you game for a living, you usually work a lot more than you game.

That’s true to a degree, but I think the discrepancy is still there. Experts in LabVIEW build up key commands to do things for them, and there’s even an ability to custom implement these using LabVIEW itself. Also, for some reason other fields seem to love these visual tools like TouchDesigner and Grasshopper. Programmers can be quite myopic when it comes to their programming preferences and perspectives.

For tools that require precise placing of wires like LabVIEW and vvvv, mouse strain and also the time it takes is indeed an issue. I am personally interested in sane but beautiful automatic layouts for visual languages, but this is most certainly a difficult problem. For example, if I could make an algorithm that basically makes LabVIEW (or a similar language) reorganize diagrams the way that I do, that would be great.

I think one inspiration are editing bays that professional video editors and also audio professional use. They have heavy use of software intermixed with hardware interfaces to perform their jobs.

Re: Folk wisdom on visual programming

#83

I wrote a spreadsheet based rules engine at Honeywell in around 2003 which enabled the business to maintain the business rules for all sales contracts that ran through the automation and control systems division. This gave them the ability to define forms, subsets of forms (legal or otherwise), notifications and approvals. I had its own natural language based expression language which the super users and business ana…

I'd love to hear how you integrated a Java and TCL backend with spreadsheets. I'm assuming this isn't something you can do with excel?

(Logistics at the small business I work at, is run on a mess of excel spreadsheets with complicated formulas and occasionally VBA for some email functionality. I have a feeling we're doing things horribly wrong, but I don't know of any better way to do things with our zero IT budget.)

Re: Folk wisdom on visual programming

#84
post #75
post #73

Earlier quoted context omitted.

> I used LabVIEW extensively for a few months I’m not sure that a few months is enough to understand the true pros and cons of a language. I’m using Elixir in my day job now and have used F# for side projects, and it’s not clear to me any one is faster to program in, especially for GUIs. LabVIEW actually shines, contrary to popular but inexperienced opinion, for large projects. I have used LabVIEW rather extensively,…

You may know of it already and it may not solve all of or any of your problems because I don't have experience with Labview outside of Eng 101 in college, but using something like Flow in elixir may make your experience with pipes less frustrating from the description you gave here. Flow is basically a GenStage backed data processing library that allows you to build out some parallel pipelines with various timings, t…

Thanks for the mention of Flow. I have heard of it but haven’t used it. I am admittedly still getting my feet wet with Elixir, so I’m still learning the ecosystem, which has a pretty steep learning curve. The language itself is quite nice and the tooling is pleasant. You just “mix ” and “mix ” to working programs.

Part of my issue is the reverse shock of what text based programmers experience when moving to a visual language since I’m coming to Elixir from LabVIEW. I missing seeing certain things but am becoming accustomed to it. I’ve done text based programming a decent amount but never day to day on large code bases (and I’m new to Elixir having primarily used F# and Racket for projects and some Python for work against my will).

Re: Folk wisdom on visual programming

#85
There is a type of visual programming which is applied to virtually everything around you of some mechanical complexity: interactive geometric constraint solvers.

In CAD tools like SolveSpace, SolidWorks, Inventor and several others, the dimensions of objects are not described directly, but instead through a set of constraints such as “these are orthogonal”, “these have this distance”, “this is a tangent” etc. If you have never used it, try SolveSpace, which is free.

Albeit highly declarative, it is absolutely a programming language for a specific domain. It doesn’t try to be good at describing imperative programs or flows; instead it presents a paradigm which is very different, but fits perfectly in the problem domain of mechanical designs.

Re: Folk wisdom on visual programming

#86

Earlier quoted context omitted.

In my experience, there are three things that visual programming tools make difficult: * abstraction * version control * test automation Those are also (in my opinion) the three techniques which separate proper "software engineering" from coding/scripting, which is why visual programming tools are pretty much universally unsuited for complicated projects. The one asterisk I would put on that is tools in which the vis…

The really funny bit is that the classic visual programming tool LabView is designed mostly for test automation. But it ends up practically requiring the creation of unmaintainable spaghetti (this[1] being a classic example) and there's no test automation possible for it. It's a test automation platform so complex it needs (but doesn't have) test automation for its automation of your tests. [1] https://thedailywtf.co…

No one should ever write code like that and no experienced LabVIEW developer would find that anywhere close to acceptable. And there are no doubt analogs in the text-based world, except you may not even know it because the structure isn’t as visible.

Also, there are certainly test frameworks for testing LabVIEW code. NI has a few but then JKI, a third party company, has multiple testing frameworks including Caraya, which is similar in philosophy to something like FsUnit for F# or Elixir’s ExUnit.

https://github.com/JKISoftware/Caraya

Re: Folk wisdom on visual programming

#87
post #67
post #63

Earlier quoted context omitted.

Personally I think programming language is about a compromise between performance and convenience. For instance, I program in Python if speed is irrelevant. Rust if it is very relevant. C# if I want a large project where performance is somewhat important. I think there are a wide range of languages for each "category" where I put Python, C# and Rust above, but those 3 are my current favorites. Certain languages are v…

> Personally I think programming language is about a compromise between performance and convenience. That's one dimension, but what about popularity, maintainability, being able to hire, productivity, being able to tackle precise problems, etc.

I think concern about “ability to hire” is a bit overblown: I’ve worked at a couple places now that have taken the “hire people that know what they’re doing and they’ll figure out the language” approach, and it’s generally successful for most business applications: this is true even when the team is using unusual languages like Clojure.

Re: Folk wisdom on visual programming

#88
post #44

My feedback, based on my both long but limited LabVIEW experience > IDEs for text-based languages normally have features like code folding and call hierarchies for moving between levels, but these conventions are less developed in node-based tools. This may be just because these tools are more niche and have had less development time, or it may genuinely be a more difficult problem for a 2D layout — I don’t know enou…

> At one point, they demoed dynamic formatting (reflows the diagram as you add/move nodes without any manual management). This really needs to be made the default.

Do you by any chance have a link to a video or article where this is shown or discussed? I’m a heavy user of LabVIEW, and I am also convinced in my own explorations of creating visual languages that dynamic automatic layout is the way to go, but it is a very hard problem.

Re: Folk wisdom on visual programming

#89

Yeah, this is going to be yet another "visual programming" topic. I sort of disagree with the intro to LabVIEW: > There are a large number of visual programming tools that are roughly in the paradigm of ‘boxes with some arrows between them’, like the LabVIEW example above. I think the technical term for these is ‘node-based’, so that’s what I’ll call them. There are NOT a "large number" of visual programming tools th…

In my opinion, LabVIEW is the most general purpose and powerful visual programming language. Others I know of are vvvv gamma where the recent update basically makes it a .NET language (although LabVIEW also has .NET integration) and Pure Data. Other tools are Simulink, TouchDesigner, Max/MSP, and Grasshopper for Rhino. After that, it drops off pretty rapidly to a collection of barely used or even known about tools pr highly specialized node-based tools.

Re: Folk wisdom on visual programming

#90

Yeah, this is going to be yet another "visual programming" topic. I sort of disagree with the intro to LabVIEW: > There are a large number of visual programming tools that are roughly in the paradigm of ‘boxes with some arrows between them’, like the LabVIEW example above. I think the technical term for these is ‘node-based’, so that’s what I’ll call them. There are NOT a "large number" of visual programming tools th…

[deleted]
Post reply on HN