Show HN: DeepUI Programming Studio – A different approach to programming

Initially, Torvalds wanted to call the kernel he developed Freax (a combination of "free", "freak", and the letter X to indicate that it is a Unix-like system), but his friend Ari Lemmke, who administered the FTP server where the kernel was first hosted for download, named Torvalds's directory linux.

Yes, there's a lack of money in Free Software. Yes, there are consequences from that, like the abandonment of certain projects. That doesn't mean non-paying users are somehow guilty of something, that's a poisonous attitude.

What's really annoying about LabVIEW is, that its programming paradigm is kind-of functional, but it doesn't go the full effort and forces you to do things, which one kind of expects are abstracted away, and things become a mess. Let me explain my top pet peeve:

In LabVIEW the main concept are so called VIs: Virtual Instruments. A VI consists of a number of inputs called "Controls", some logic in between and outputs called "Indicators". Inside a VI you have the full range of programming primitives like loops (which interestingly enough can also work like list comprehensions through automatic indexing, but I digress) "variables" (in the form of data flow wires) but no functions. VIs are what you use as function. And if everything happens through VI inputs and outputs and you don't use global variables, feedback nodes or similar impure stuff it's pretty much functional.

Somewhere your program has to start, i.e. there must be some kind of "main" VI. But VIs mostly behave like functions, so if you hit "run" for the main VI it will just follow its data flow until every input has reached what it's wired to and all subVI instances have executed and thats it. That's perfect for a single shot program, like you'd have on the command line or executing to serve a HTTP request, however it's kind of the opposite of what you want for an interactive program that has a visual UI. Sure there is that "run continuously" mode which will just loop VI execution. But all what it does is re-evaluate and execute each and every input and subVI again and again and again. If you're using LabVIEW in a laboratory setting, which is its main use, you probably have some sensors, actuators or even stuff like lasers controlled by this. And then you do not want to have then execute whatever command again and again. There is a solution to this of course, which are called "event structures". Essentially its like a large "switch" statement, that will dispatch exactly once for one event. Of course this caters only toward input manipulation events and some application execution state events. And you can not use it in "run continuously" mode without invoking all the other caveats. So what you do is, you place it in a while loop. How do you stop the while loop? Eh, splat a "STOP" button somewhere on the Front Panel (and don't forget to add a "Value Changed" event handler for the stop button, otherwise you'll click STOP without effect until you manipulate something else).

And then in the Event structure you have to meticulously wire all the data flows not touched by whatever the event does through so called "shift registers" in the while loop to keep the values around. If you forget or miswire one data flow you have a bug.

What seriously annoys me about that is, that in principle the whole dataflow paradigm of LabVIEW would allow for immediate implementation of FRP (functional reactive programming): re-evaluation and execution of only those parts of the program that are affected by the change.

The other thing that seriously annoys me is how poorly polymorphism is implemented in LabVIEW and how limited dynamic typing is. I'd not even go as far as saying that LabVIEW does type inference, although at least for primitive types it covers a surprisingly large set of use cases. Connect numeric type arrays to an arithmetic operation and it does it element wise. Connect a single element numeric type and an array and it again does things element wise. Have an all numeric cluster (LabVIEW equivalent of a struct) and you can do element wise operations just as well. So if we were to look at this like Haskell there's a certain type class to which numeric element arrays, clusters and single elements belong and it's actually great and a huge workload saver! Unfortunately you can't expose that on the inputs/outputs of a VI. VI inputs/outputs always have to be of a specific type. Oh yes, there are variants, but they're about as foolproof to use as `void*` in C/C++. So the proper way to implement polymorphism in LabVIEW is to manually create variants of your VI for each and every combination of types you'd like to input and coalesce them in a polymorphic VI. And since you have to do it with the mouse and VIs are stored in binary this is not something you can easily script away. Gaaahhh…

Not in OP's video. There's literally no way to escape the full-screen without pressing the escape key. You can't even double-click. I'm actually impressed by how user-hostile that video is.