Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Very interesting article. I'm gonna read it in more detail tomorrow. Thanks for sharing it.

However, I did note that you lumped LabVIEW in with other visual "tools" and scripting tools. LabVIEW is a fully featured, general purpose language. You can do anything in it you can do in other languages, and there's plenty you can do in it that other languages can't. I don't know of any language that allows you to program desktop PCs, embedded high-level programs, real-time programs, and FPGAs with the same language. Maybe C/C++ with Vivado HSL. But...C/C++.

LabVIEW compiles to DFIR, an intermediate dataflow language, and then that compiles down to LLVM IR, which is handed off to LLVM. You can call .NET assemblies and C/C++ DLLs. It has value-based OOP, various (rather unique) implementations of polymorphism, built-in multithreading across cores, immutable data, a nice event structure for building GUIs, is highly performant, and a ton of other features. It has built-in support for basically any protocol (HTTP, TCP/IP, UDP, etc.), so it can talk to basically anything. If it doesn't have something built-in, you can obviously build your own or pull in some .NET or C/C++ dependency. So yes, you could rather easily write a raytracing engine or a GraphQL library in it. In fact, LabVIEW is damn fast, so it is great at things needing to be performant, especially if they can be parallelized.

LabVIEW is "specialized" to certain industries for three main reasons. (1) How well it ties in to NI's hardware and other test and measurement and scientific hardware. (2) It is expensive, but now there is a free Community version. (3) Non-acceptance amongst "mainstream" programmers of visual programming languages. So it actually has little to do with the language and more to do with factors external to the language.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: