1. The compiler error messages suck. A typical error is shown in the following screenshot.

   

   GCC telling me something is neither a struct nor union is more informative. The spewing garbage gcc emits if I accidently put a brace after function forward delcaration is easy to figure out. But this? "B is A and C is A and that is not compatible." Where does one even start?

2. LabView lacks expressiveness for everything besides connecting to a piece of hardware. It is literally easier to work with arrays in C than labview. That's a pretty low bar, NI, and you're failing. It sucks at array handling, struct handling, string parsing and plotting. The only thing it does well is make it easy to connect up a piece of hardware. This is only easy because the drivers already exist.
3. Labview is unstable. It segfaults all the time. This is unacceptable. I can't remember the last emacs or gcc or python segfaulted.
4. Oh you thought string handling in c was painful? Just wait until you try it LabView.
5. By default, Labview does not abort on an error, but instead just keeps trucking along, passing the error from one sub-VI to the next. Why this seems like a reasonable thing to do is beyond me. This leads to the standard paradigm that the contents of every subvi are wrapped in a giant case-structure that tests if any error was passed in and only executes in the error free case.

6. Generating an error message is exercise in frustration. First you, must register the error message in C:\Program Files/National Instruments/bowls of/god_forsaken.desert/. Then you must restart LabView. Then you wire up an error handling VI with about 45 connectors just to print one error message. Compare this to matlab:

   error('you gave me dumb input.')
   

c++ :

throw std::invalid_argument("you gave me dumb input.");

Python:

raise ValueError('you gave me dumb input.')

1. Labview sucks at code re-use. There doesn't seem to be any equavalent to adding an import path as in python or include as in c. If they would just let me do this manually like matlab or python or c++ does, things would be so much easier. As it is, it takes 2 fucking hours to transport code from one project into another. Every time you move a file, it takes you 20 minutes to harrangue labview into updating all the references to that file. Moving the file means that every vi that called that file gets changed, which is a nightmare for source control. Matlab, python and c++ are all WAY better at this. What labview does is the equivalent of hardcoding the absolute path of every include everywhere a header is used.
2. "Naming" things sucks. One of the perrenial truisms of writing software is that naming things is hard. With LabView, you are thrown back to Egyption hiroglyphics and get to describe a function by drawing a "descriptive" picture into a 32 pixel box.
3. The one-file-one-function paradigm. Every subvi needs its own file. Every class needs its own file and every method in that class needs its own file. And each of those files needs two windows. Its a fucking nightmare. And in order to "name" this functions, you have to draw a hiroglyphic. This is one of the major contributing factors to spaghetti code: it's such a hassle to break things apart into small components that people just don't.

The IDE sucks. Because the language is closed and proprietary, you have you choice but to us the NI IDE. With text, if you don't like notepad, use emacs; if you don't like emacs use vim; if you don't that, use sublime; if none of those float your boart use VSCode. If you're still not happy, write your own. I dont even know where to start on how much the IDE sucks, so lets start randomly.

1. Their wiring algorithm sucks. Sometimes you can delete a single segment. Sometimes you can't. The "cleanup block-diagram function" is worthless, it just makes things more of a mess. If you try to replace a sub-vi, it takes 5 minutes because re-connecting the terminals to the now mess of broken wires just results in broken wires because somehow labview has spread hidden wire all over my diagram and you re-connect in the middle of the wire so you get a dangling wire.
2. There is no auto-formatting tool. In sane languages, we get black or gofmt or clang-format or rustfmt. But in G, you get to spend hours tidying up your wires manually.
3. You know how every modern IDE has refactoring tools like "rename symbol"? None of this exists in LabView. It is such an archaic piece of garbage you are stuck with search and replace, which doesn't work very well. It cannot search for basic things, like a shared variable.
4. Every time you click on any LabView window, it will bring all of LabView's windows (of which there are dozens) to the top and bury any other window you have open. This completely breaks Alt-Tab as well. It's enough to make Mother Teresa kill a chipmunk. Their own engineers are idiots and think this is "just the way it is because labview runs as a single process." Five minutes spent watching the processes and windows on your computer should be enough debunk that lunacy.
5. Anytime you open a settings dialog box, LabView blocks you from looking at anything else. Try this in simulink. You can have bunches of dialogs open simultaneously.
6. The "cleanup block diagram" tool was designed by a five year whose idea of "clean your room" means chuck everything, no, everything, into a pile and call it a day.
7. When I copy and past a local variable (which is associated with a block diagram control or indicator), LabView will create a new control/indicator and associate the new variable with it. This is literally never what I want. What I asked for was a copy of the variable, not a copy of the thing the variable refers to.
8. When pasting something on the block diagram (resp., front panel) that results in something on the front panel (resp., block diagram) LabView somehow, in its infinite wisdom, sticks it two screens away. Half the time I can't even find it. The only remedy is to double click on the item in the block diagram so it will pop you into the right location in the front panel. But then, you are so far away from everthing else, you have no idea which direction to even start dragging it. This problem is exacerbated becasue NI refuses to implement zoom-out functionality in the IDE.
9. The functionality of most functions, even simple things like multiplication, is hidden behind menu after menu. This means it is impossible to know what a given piece of code does by reading the code. It is also impossible to compare the difference between two pieces code by looking at them: the LVDiff tool is no help here, because it cannot tell you the difference.
10. They refuse to add zoom to the block diagram editor. LabView is closed source so there does not exist an alternative editor. They claim that if you need to zoom-in then your block diagram is too complicated. Potentially, but what I really want is to zoom IN (not out) so I can connect all those tiny fucking wires to 16 square pixel box.
11. There is no way to copy or paste data into an array. If your try to copy the array, it will copy a damn screenshot of the array, as if this is somehow useful to anybody.
12. Using the mouse for everything sucks. It sucks re-arranging wires. It make my wrist hurt and my soul ache.

1. Labview doesn't have any concept of returning from a function early. I.e., in any sane programing language, you can do something like

   function fun(a, last_err)
      if some_condtion{
         return
      }
      # All the code in fun() is supposed to do.
   

   Instead, you have to write the equivalent of

   function fun(a, last_err)
      if some_condition
         # do nothing
      else
         #All the code fun() is supposed to do.
   

   This is needless excessive verbosity. It doesn't look to bad here, but it is rediculous for more complex functions. It is the G equivalent of needing one extra level of indentation for every function because basically every function is wrapped in an error checking case structure.

2. A dictionary/hash-map type. Matlab implements as the Map type, python as the eponymous dict, c++ as std::map or std::unordered_map.
3. No built-method to access the end of an array. In matlab, one simply writes x(end) and in python, x[-1].
4. No support for continuing a loop iteration. This is basic stuff. Even c can do it.
5. No support for logical array indexing. In other words, there is no equivalent to the numpy expression x[x==1].
6. No support for indexing an array from a vector of indices. In other words, there is no equivalent to idx = [1,3,6,8]; z = x[idx];
7. There is no built-in way to access the members of a cluster by name. C.f., with python's getattr, for example.
8. There is no built in method to flatten a matrix to single column or row.
9. Arrays without orientation. In my opinion, only Matlab and Eigen get this right. I can understand why, for a general purpose programming language like python or c, it is not useful to have an orientation associated with an array. For a programming language targeted at scientific computing, it is, in my opinion, imperetive that arrays have an orientation. Labview is not a general purpose language. It is targeted at scientific computing. Therefore, it is a major flaw that arrays do not have an orientation.
10. Labview does not throw an error if you index outside of an array. In what world is that sane??
11. Race conditions for the common folk! LabView is marketed towards non-CS folk. CS folk have a healthy respect for the pitfalls that come with multi-threading and concurrency. NI, evidently wishing to democratize these dangers, exposes them as first class citizens to the newbie, since the execution order of the dataflow paradigm is non-deterministic.
12. Case structures are a horrible excuse for if-then-else statements, especially when they are nested. Part of the problem is that the only way to see all of the control flow is to manually click through each one. With text, you can see all of it by just, like, looking. Unless you found on editor that has mandatory code folding.
13. Plotting. Never in my life have I seen such shitty support for plotting. In every sane scientific programming language — matlab, python, julia— hell even plplot in c – it is trivial to add plots to a figure with something like a "hold on" statement. In LabView, you have to append the new data to plot to an array containing the existing data and re-plot everything. Now, remember that the only way to get each set of data to where it needs to go is draw another wire across the screen. Fuck that noise.

LabView has shitty support for version control. This is due to a host of reasons:

1. Vi files are binary blobs, so every time a file changes, git or whatever stores an entirely new version.

2. Their "visual" diff and merge tools suck. These tools will not work to diff controls, classes or library files. Half the time the tool crashes. The tool very, very, often has no idea what has changed. Sometimes it will give you a list of things that might have changed.

   

   The tool won't even work with the LabView project itself. This project file changes everytime a file is changed. This makes the tool all but worthless.

3. LabView hard-codes the path every a sub-vi into every single caller. In other words, if sub-vi-A is called by sub-VIs B, C and D, then B, C, and D all have the path of sub-vi-A hardcoded into them. Thus, if you change the location on disk of sub-vi-A, that results in changes to sub-vis B, C, D as well. This behavior is absolutely BATSHIT FUCKING CRAZY. Python, Matlab and c++ all handle this way better. This sucks for version control, but also really sucks for stealing a bunch of function from some other project: as soon as you move them, not only will you get a bunch errors and have to "resolve conflicts", but they will keep looking for each other in their previous location. If those files are open in another project, LabView cannot keep them straight.

1. Labview edits, on its own, files that I never opened. This is unacceptable. Moreover, these silent edits can affect hundreds of files that you never opened, and the diff tool will just tell you something generic like "vi properties changed". It's worthless. How on earth are you supposed to do a merge in a situation like this??
2. Often, merely openening a file, results in changes to that file. This will re-occur, for reasons not known to anybody, regardless of how many times you save it.
3. Related to (1) is that that (a) VIs are stored as binary files and (b) LabView insists that you manage these files from within a project. This means you not supposed to use standard workflows like git mv to rename a file. Rather, you are supposed to do this inside the project, which means that git has no knowledge that a file was simply moved. All it sees is that a file got deleted and another file got added. This completely breaks version control. The only work-around I have found is to first remove the file from your project, do git mv name_old name new, then add the file back to your project.
4. The whole situation is so grim that I have completely given up on the branche and merge paradigm in a labview project. I just end back in 1985 naming files file_ver1.vi, file_ver2.vi. Please shoot me.

1. VIs will appear broken for no evident reason. The labview linter can't tell you what's wrong. Evidently, this happens because NI's shitty IDE corrupts the vi and the only apparent solution is to copy the whole thing into a new file. How, in any sane system, is that acceptable behaivior? I ask you, when was the last time a plain text file become corrupt?
2. There is no REPL/command line. With matlab or python or Julia, once you run a script, all the variables remain availible to you at the command prompt. In LabView, they evaporate into the ether. Lacking a command line means that for every change I want to make, I have to re-run the entire program. It means to run some function or play with anything, I have to create a new vi. Heck, even c++ has a repl.
3. Crappy support for Linux and Mac. Matlab works just fine on linux. Python works great on linux. C obviously does. Xilinx Vivado works. But NI only ships a very limited feature set on their linux version which does not allow you to use any of their FPGA products.
4. It is impossible to find their documentation. Somehow, search results from google, duckduckgo etc yield NI's pages from 2010 and earlier. Compare this to matlab, where search results always land you on the latest documentation. They don't even bother to link to the new version of the documentation, in contrast to most open-source projects.
5. The documentation itself sucks. When the documentation of an open source project sucks, you can always fall back to just reading the code. National instruments insists on a Closed source model. It is therefore incumbent on NI to pruduce excellent documentation. They do not. NI's documentation is the worst I have come accross. The documentation you do manage to find sucks. Most of it reads like marketing propoganda. Compare the difference in these two landing pages about using source control with Labview versus using source control with matlab. When the PR folks didn't write the docs, it often is just self-referential nonsense: "Frobnicator: frobnicates the input".