Przemyślenia po pół roku patrzenia w binarki LV

[mefistotelis]

Naskrobałem trochę ostatnio o tym co wiem, i o tym co myślę, na temat LV.

Artykuł angielski:
https://gist.github.com/mefistotelis/31 ... 49c90032df

[PiDi]

Never Asked Questions about NI LabVIEW
Is LV application as fast as one written in C?
Is an executable built in LV hard to reverse-engineer?
Is LV environment secure?
Does it mean I shouldn't use LV?
So is NI bad to the bone?

Pierwsze cztery pytania były zadane już wiele razy i wiele odpowiedzi na nie padało, jak podpowiada mi google. Co do ostatniego, to na pewno słyszałem tego typu pytania na żywo To trochę złośliwości na początek. Byłoby też łatwiej, gdybym rozumiał kontekst tego artykułu - co on ma właściwie pokazywać? Do meritum:

1. Zacznijmy od najgrubszej sprawy:

But it also generates the possibility of silencing criticism and limiting visibility of unfavorable content. And these are taking place as well.
(...)
It's a bit worse with unpaid zealots, as these are writing insane things about how good LV is. Somehow their comments are rarely removed, while any negative opinions are heavily moderated on the official forums.

Nigdy nie spotkałem się z tym, żeby ktoś cenzurował negatywne opinie na jakimkolwiek forum (jeśli tylko jest wyrażona w sposób kulturalny). To, co piszesz, to ciężkie oskarżenia w kierunku NI. Masz na to jakieś konkretne dowody?

2.

Is LV application as fast as one written in C?

Jaka miara "szybkości"? Jakieś konkretne wyniki porównania? Jaka aplikacja? Dlaczego ją optymalizujemy pod względem "szybkości", jaki z tego pożytek?

Arguments about program optimization are irrelevant, you can optimize C code as well, and get way better results for code size and performance.
(...)
Conclusion: LV is by design slower than C.

Oczywiście, możliwości optymalizacji w C są dużo większe w porównaniu do LabVIEW, co do tego nie ma wątpliwości. Tylko wracając do pytań powyżej - co optymalizujemy i po co?
W odpowiedzi do konkluzji, powinna ona brzmieć: "C by design allows you to write very highly optimized programs because it gives you unlimited low-level memory operations. Therefore, C is by design faster than most other languages".

That's because LV only compiles small chunks of code, and keeps them in separate VI files. This impairs the optimizer, giving it limited possibilities to influence the code.

To po prostu nie jest prawdą. Kompilator LabVIEW potrafi wykonać wszystkie optymalizacyjne cuda, o których piszesz ("It re-uses strings, re-uses parts of functions, in-lines functions and expands loops."). I w żadnym wypadku kompilacja przeprowadzana przez LabVIEW nie polega na sklejeniu małych kawałków kodu z poszczególnych VI w jeden niezoptymalizowany blok. Dobry punkt startowy w temacie: https://www.ni.com/pl-pl/support/docume ... -hood.html

Not to mention, the code from each VI is executed under control of the LV Runtime Environment

Obligatoryjne "podobnie, jak .net i Java".

3.

Is an executable built in LV hard to reverse-engineer?
(...)
Conclusion: LV is by design easy to reverse engineer.

Tu się generalnie zgodzę, jako że nie ma szczególnych zabezpieczeń wbudowanych w exe tworzonego przez Application Builder. Ale mimo to: konia z rzędem temu, który zrobi pełny reverse-engineering średniej aplikacji z 2000 VIjów.

4.

Is LV environment secure?
(...)
Conclusion: It is unlikely that the environment is secure.

Tu nawet bym się pokusił o więcej i powiedział, że LabVIEW nie jest bezpieczne w rozumieniu bezpieczeństwa IT ze względu na znane podatności (nawet niedawno jakaś trzecia strona publikowała taki zestaw). Równocześnie nie znane mi są żadne przypadki próby ataków przy pomocy LabVIEW.

5.

Does it mean I shouldn't use LV?
(...)
If you're a 'real' programmer, LV has nothing to offer you.

Nie wiem kim są "prawdziwi" programiści. Kilkadziesiąt programów, które napisałem lub przyłożyłem do nich rękę, działa u wielu klientów i są, jak sądzę, dość realne (i programy, i klienci też). Programiści w firmie też wyglądają na prawdziwych, ale musieliby się sami wypowiedzieć na ten temat. Znam też trochę innych programistów LabVIEW z Polski i ze świata i przypuszczam, że oni też są prawdziwi... Chociaż fakt, ostatnio widuję ich raczej online niż na żywo, hmmm

LV allows to build a simple application fast and with no prior knowledge.

A z pewną wiedzą pozwala nawet na zbudowanie dość złożonych aplikacji, co poświadczam osobiście (i przepraszam za kolejny argument z doświadczenia).

There is a reason why LV isn't conquering any territories ruled by other languages. It is definitely not the best general solution.

Tu się absolutnie zgodzę, nie chciałbym pisać aplikacji mobilnej czy webowej w LabVIEW. Ale właściwie tylko ze względu na ograniczoność narzędzi do tego. Sama filozofia programowania w LV jak najbardziej nadaje się do ogólnego przeznaczenia, a może nawet w kilku miejscach przewyższała istniejące rozwiązania.

But there are specific use cases in which LV is as good as other environments.

I tu się też zgodzę, ale po dołożeniu, że są przypadki użycia gdzie LabVIEW jest lepsze niż inne środowiska (choćby test&measurement).


Edit: poprawiony znacznik formatowania "code" na "quote"

[mefistotelis]

Dzięki za merytoryczną odpowiedź.

Nigdy nie spotkałem się z tym, żeby ktoś cenzurował negatywne opinie na jakimkolwiek forum (jeśli tylko jest wyrażona w sposób kulturalny). To, co piszesz, to ciężkie oskarżenia w kierunku NI. Masz na to jakieś konkretne dowody?

Czas życia mojego konta na NI to - do czasu aż się za oceanem obudzą.
I nie, nie pisałem nic obraźliwego. Odpowiadałem na pytania odnośnie reverse-engineeringu. Odpowiedzi zniknęły, a ja mam:

Jaka miara "szybkości"? Jakieś konkretne wyniki porównania? Jaka aplikacja? Dlaczego ją optymalizujemy pod względem "szybkości", jaki z tego pożytek?

Porównania można znaleźć w necie, ja nie zamierzam robić. Jak ktoś nie uwierzył w argumenty odnośnie designu, to w wyniki testów uwierzy?
No chyba że poszukamy na serwerach NI, tam znalazłem że jest tak szybkie jak C. Wikipedię sam poprawiłem, bo pisało że wszelkie różnice to wyłącznie kwestia że ktoś nie wie jak się w LV optymalizuje "kod graficzny".

Oczywiście, możliwości optymalizacji w C są dużo większe w porównaniu do LabVIEW, co do tego nie ma wątpliwości. Tylko wracając do pytań powyżej - co optymalizujemy i po co?
W odpowiedzi do konkluzji, powinna ona brzmieć: "C by design allows you to write very highly optimized programs because it gives you unlimited low-level memory operations. Therefore, C is by design faster than most other languages".

A dlaczego sprowadzamy różnice do operacji na pamięci? To jest ważne, ale znaczenie ma też chociażby program flow. LabVIEW minimalnie wykorzystuje stos. Jak odwołujesz się tam do czegoś, zazwyczaj oznacza to dodanie nowego joba do list w LVRE. To wprowadza overhead.

Co optymalizujemy i po co - nie ma znaczenia, bo w każdej kombinacji LV będzie wolniejsze. Czy optymalizujemy kod modyfikując go, czy optymalizacje wykonuje kompiler - i tak LV jest wolniejsze od C/C++. Czy optymalizujemy na rozmiar, czy na szybkość wykonania - znów, wynik ten sam.

To po prostu nie jest prawdą. Kompilator LabVIEW potrafi wykonać wszystkie optymalizacyjne cuda, o których piszesz ("It re-uses strings, re-uses parts of functions, in-lines functions and expands loops."). I w żadnym wypadku kompilacja przeprowadzana przez LabVIEW nie polega na sklejeniu małych kawałków kodu z poszczególnych VI w jeden niezoptymalizowany blok. Dobry punkt startowy w temacie: https://www.ni.com/pl-pl/support/docume ... -hood.html

Bardzo dobry artykuł. I kolejny punkt jasno pokazujący że wszystko na serwerach NI to też marketing.
To co mogę ci zaoferować w to - wypakuj sobie binarkę zbudowaną przez LV, zobacz co jest w środku. Stworzyłem do tego narzędzia.
Ja się ich trochę naoglądałem. Nawet zacząłem dyskusję na forum LAVA gdzie zasugerowałem że można mówić tu o "natywnym kodzie, ale wirtualizacji biegu egzekucji", oczywiście spotkało się to z oburzeniem ale argumenty jasno potwierdziły moje przypuszczenia.
LVRE ładuje kod i informacje o formatach danych z pojedynczych plików VI. Nazywają to "linkowaniem" bo spełnia to formalną definicję.
Optymalizacje o których pisałem zachodzą wyłącznie w obrębie jednego pliku VI. To gigantyczne ograniczenie.

Conclusion: LV is by design easy to reverse engineer.

Tu się generalnie zgodzę, jako że nie ma szczególnych zabezpieczeń wbudowanych w exe tworzonego przez Application Builder. Ale mimo to: konia z rzędem temu, który zrobi pełny reverse-engineering średniej aplikacji z 2000 VIjów.

No właśnie o to chodzi - jak zrobisz odzyskiwanie do jednego pliku VI, masz już wszystko. Tysiące, miliony - nie ma znaczenia. Każdy plik VI wciąż siedzi jako oddzielny plik VI w zbudowanym EXEku. Nawet ostatnio powstały obfuscatory które usuwają nazwy plików VI z wnętrza. Ciekaw jestem czy to nie odpowiedź na mój otwarty kod.
Jest ograniczenie - to co upubliczniłem jest dla LV14, ktoś mi płakał że w nowych wersjach zmienił się kontener używany wewnątrz pliku EXE i mój tool nie działa.

It is unlikely that the environment is secure.

Tu nawet bym się pokusił o więcej i powiedział, że LabVIEW nie jest bezpieczne w rozumieniu bezpieczeństwa IT ze względu na znane podatności (nawet niedawno jakaś trzecia strona publikowała taki zestaw). Równocześnie nie znane mi są żadne przypadki próby ataków przy pomocy LabVIEW.

Prawda, mi też nie. Z tym że to wyłącznie kwestia względnie małej popularności.

Does it mean I shouldn't use LV?
(...)
If you're a 'real' programmer, LV has nothing to offer you.

Nie wiem kim są "prawdziwi" programiści. Kilkadziesiąt programów, które napisałem lub przyłożyłem do nich rękę, działa u wielu klientów i są, jak sądzę, dość realne (i programy, i klienci też). Programiści w firmie też wyglądają na prawdziwych, ale musieliby się sami wypowiedzieć na ten temat. Znam też trochę innych programistów LabVIEW z Polski i ze świata i przypuszczam, że oni też są prawdziwi... Chociaż fakt, ostatnio widuję ich raczej online niż na żywo, hmmm

Powinienem to poprawić.. tego typu terminologia nie sprzyja merytoryce. Podejrzewam że rozważałeś ostrzejszą odpowiedź .

LV allows to build a simple application fast and with no prior knowledge.

A z pewną wiedzą pozwala nawet na zbudowanie dość złożonych aplikacji, co poświadczam osobiście (i przepraszam za kolejny argument z doświadczenia).

Przyznam, w używaniu LV zgodnie z przeznaczeniem mam małe doświadczenie. Odrzucają mnie ograniczenia które narzuca język graficzny, jak też zamknięte środowisko.

There is a reason why LV isn't conquering any territories ruled by other languages. It is definitely not the best general solution.

Tu się absolutnie zgodzę, nie chciałbym pisać aplikacji mobilnej czy webowej w LabVIEW. Ale właściwie tylko ze względu na ograniczoność narzędzi do tego. Sama filozofia programowania w LV jak najbardziej nadaje się do ogólnego przeznaczenia, a może nawet w kilku miejscach przewyższała istniejące rozwiązania.

Piszę w C, C++, Pythonie. Pisałem też w Pascalu, Basicu, Javie, C#, Php. No i Asm'y oczywiście. Mam swoje preferencje, ale generalnie w każdym z tych języków mógłbym coś tam zmajstrować. A gdy tak majstruje, używam narzędzi Unixowych - grep, sed, bash, systemów wersjonowania kodu, innych narzędzi przetwarzających tekst.

Mój styl pracy jest silnie nastawiony na rozwiązywanie problemów i silnie zoptymalizowany. I w tej formie - kompletnie niekompatybilny z LV.
Stąd nie mogę całkowicie, w 100% wykluczyć że to nie jest moje uprzedzenie. Ale jestem niemal pewien że nie. LV wrzuca programistę w pewną górkę, maksimum lokalne, pod względem tak wydajności jak i stopnia zrozumienia całego systemu egzekucji. W jakimś stopniu robią to wszystkie narzędzia o zamkniętym kodzie, w przypadku LV to jednak wyjątkowo jaskrawe - bo LV ma własny kompiler, własny linker, własny loader, nawet własny format plików z kodem. Z tego miejsca bardzo trudno jest uciec. Wyżej LVRT nie podskoczysz.

[mefistotelis]

Mała prezentacja mojego toola:
https://www.youtube.com/watch?v=E5R8xyA0puo