LabVIEW

La eNTiDi ha usato LabVIEW in passato: un esempio di software sviluppato è il progetto pubblico CANopen for LabVIEW. Lo sviluppo è stato interrotto (e non verrà più ripreso) una volta che ci si è resi conto che non era un ambiente di sviluppo in linea con la nostra visione di software.

I pregi

LabVIEW è un ambiente di sviluppo e nel contempo un linguaggio di programmazione grafico. È diffuso nel settore dell'automazione, quindi trovare driver o supporto per questo prodotto software è relativamente semplice. La stretta interconnessione tra interfaccia grafica e logica del programma consente di eseguire prototipazioni software in modo estremamente rapido ed intuitivo: se i driver di un dispositivo sono disponibili, trasferire il segnale dal cavo allo schermo è questione di minuti.

I difetti

Parte dei difetti è dovuta alla scelta di usare un linguaggio di programmazione grafico invece di esprimere la logica in formato testo. Questo non sarebbe un grosso problema se la logica fosse comunque rappresentabile via testo, scelta operata per esempio dalla Siemens che in Step5 consentiva la programmazione in KOP e FUP (grafici), entrambi mappabili a codice AWL (testo). Purtroppo LabVIEW registra il codice in formato binario proprietario, quindi dal punto di vista logico ogni VI è una scatola nera inaccessibile che porta ai seguenti (enormi) problemi:

• i programmi sono legati all'ambiente di sviluppo: succede qualcosa a LabVIEW (o al PC dove è installato) e di colpo i progetti diventano un inutile ammasso di file;
• operazioni base come vista, ricerca e sostituzione devono passare dall'ambiente di sviluppo;
• per ogni VI devono essere definite informazioni non sempre rilevanti (in particolare l'icona del VI e l'interfaccia grafica);
• il merging è talmente costoso da risultare impraticabile.

In definitiva l'SCM viene ridotto ad una database di copie, invalidando un buon 20 anni di innovazioni nel controllo versione.

A ciò vanno aggiunti i problemi specifici di LabVIEW, alcuni dei quali sorprendenti per un prodotto che vanta più di 33 anni di sviluppo:

• l'ambiente di sviluppo è pieno di errori: per esempio il tentativo di una rimappatura "furba" dei nomi dei campi durante la modifica di un cluster typedef può rendere un progetto inusabile senza che lo sviluppatore se ne accorga (soluzione: non modificare un cluster typedef!);
• molte operazioni sono ridondanti: per esempio si può settare lo stato di un pulsante in almeno 4 modi differenti;
• esiste una quantità enorme di "trucchi" abilitabili tramite combinazioni di tasti e azioni con il mouse: l'ortogonalità è totalmente assente;
• le informazioni relative al codice sono sparse nell'ambiente integrato: parte nella finestra di dialogo delle proprietà del VI, parte nell'icona e parte nella finestra di G code;
• il VI è un file unico che contiene sia la parte "sorgente" che la parte "compilata": l'assurdità di questa scelta fa si che se si modifica un tipo dati usato spesso nel progetto, tutti i VI si modificano per ricompilazione (questa "feature", unitamente al fatto che i VI sono file binari, rende appunto il controllo versione una barzelletta);
• il forum di supporto è surreale: gli utenti vengono sistematicamente colpevolizzati di fronte ad un palese bug in LabVIEW.

Hai un VI corrotto? Colpa tua che non fai le copie di backup!