I strongly suggest somebody write a bot on HN and maybe leverage GPT-3 to harvest collective wisdom on many topics. It's a golden mine.
Folk wisdom on visual programming
81–90 of 168 posts
Re: Folk wisdom on visual programming
#82Earlier 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.
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
#83I 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…
(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
#84Earlier 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…
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
#85In 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
#86Earlier 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…
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.
Re: Folk wisdom on visual programming
#87Earlier 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.
Re: Folk wisdom on visual programming
#88My 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…
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
#89Yeah, 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…
Re: Folk wisdom on visual programming
#90Yeah, 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…