Testuale rispetto a Linguaggi di Programmazione Grafica

StackOverflow https://stackoverflow.com/questions/13678

Domanda

Faccio parte di una high school team di robotica, e c'è un certo dibattito su quale linguaggio utilizzare per programmare il nostro robot.Stiamo scegliendo tra C (o forse C++) e LabVIEW.Ci sono pro per ogni lingua.

C(++):

  • Ampiamente usato
  • Una buona preparazione per il futuro (la maggior parte di programmazione posizioni richiedono testo-base di programmatori.)
  • Siamo in grado di espandere la nostra C codebase dall'anno scorso
  • Ci permette di comprendere meglio ciò che il nostro robot sta facendo.

LabVIEW

  • Più facile da visualizzare il flusso del programma (blocchi e i fili, invece di linee di codice)
  • Più facile insegnare (Apparentemente...)
  • "Il futuro della programmazione grafica." (La penso così?)
  • Più vicino al Robolab sfondo che alcuni nuovi membri possono avere.
  • Non c'è bisogno di conoscere intimamente quello che sta succedendo.Basta dire il modulo a trovare la palla rossa, non c'è bisogno di sapere come.

Questa è una decisione molto difficile per noi, e abbiamo discusso per un po'.Basati su quelli pro per ogni lingua, e l'esperienza che hai, cosa pensi sia la migliore opzione è? Tenete a mente che non siamo necessariamente andare per pura efficienza.Speriamo anche per preparare i nostri programmatori e per un futuro in programmazione.

Inoltre:

  • Pensi che la grafica lingue come LabVEIW sono il futuro della programmazione?
  • È un linguaggio grafico più semplice per imparare un linguaggio testuale? Io credo che si dovrebbe essere di circa altrettanto difficili da imparare.
  • Vedendo come ci sono partailly radicata nell'aiutare le persone a imparare, quanto possiamo contare su moduli predefiniti, e quanto dovremmo provare a scrivere sul nostro? ("Buoni programmatori di scrivere del buon codice, grande programmatori copia del codice." Ma non è la pena di essere un buon programmatore, prima?)

Grazie per i consigli!

Edit:Vorrei sottolineare questa domanda più:Il capitano della squadra, pensa che LabVIEW è meglio per la sua facilità di apprendimento e di insegnamento. È vero? Penso che C può essere insegnato facilmente, e principianti-livello di attività dovrebbe essere ancora in giro con C.Mi piacerebbe molto sentire le vostre opinioni. C'è qualche motivo che digitando mentre{} dovrebbe essere più difficile di quanto la creazione di una "mentre la scatola?" Non è altrettanto intuitivo che i flussi di programma riga per riga, solo modificato dall'ifs e passanti, come è intuitivo che il programma scorre attraverso il filo, solo modificato da ifs e loop!?

Grazie ancora!

Edit:Ho appena realizzato che questo cade sotto il tema "la lingua di dibattito". Spero che va bene, perché parla di ciò che è meglio per uno specifico ramo della programmazione, con determinati obiettivi.Se non...Mi dispiace...

È stato utile?

Soluzione

Prima del mio arrivo, il nostro gruppo (Dottorato di ricerca gli scienziati, con il minimo di programmazione sfondo) aveva cercato di implementare un'applicazione LabVIEW su-e-fuori per quasi un anno.Il codice era in disordine, troppo complesso (front e back-end) e, soprattutto, non ha funzionato.Io sono un appassionato programmatore, ma non aveva mai utilizzato LabVIEW.Con un piccolo aiuto da LabVIEW guru, che potrebbe aiutare a tradurre il testo progamming paradigmi ho conosciuto in LabVIEW concetti è stato possibile codificare le app in una settimana.Il punto qui è che la codifica di base concetti di avere ancora da imparare la lingua, anche uno come LabVIEW, è solo un diverso modo di esprimere la loro.

LabVIEW è grande per l'uso per quello che è stato originariamente progettato per.cioèprendere i dati da schede DAQ e visualizzazione su schermo, forse, con alcune piccole modifiche in-tra.Tuttavia, la programmazione algoritmi non è da meno e vorrei anche suggerire che è più difficile.Per esempio, nella maggior parte dei linguaggi procedurali ordine di esecuzione è generalmente seguita riga per riga, utilizzando pseudo matematica (e cioè y = x*x + x + 1) mentre LabVIEW vorrei implementare l'uso di una serie di VI che non necessariamente seguono una dall'altra (es.da sinistra a destra) sulla tela.

Inoltre la programmazione di una carriera più che conoscere la tecnica di codifica.Essere in grado di chiedere aiuto/di ricerca per le risposte, scrivere codice leggibile e lavorare con il codice legacy sono tutte competenze chiave che sono innegabilmente più difficile in un linguaggio grafico come LabVIEW.

Credo che alcuni aspetti della programmazione grafica può diventare mainstream - l'uso di sub-VIs incarna perfettamente il 'black box' principale di programmazione e viene utilizzato anche in altre lingue astrazioni come Yahoo Pipes e la Apple Automator - e, forse, alcuni di futuro linguaggio grafico che rivoluzionerà il modo in cui si programma LabVIEW per sé non è un massiccio spostamento di paradigma nel design di un linguaggio, abbiamo ancora while, for, if il controllo di flusso, typecasting, programmazione guidata dagli eventi, anche oggetti.Se il futuro sarà davvero scritto in LabVIEW, C++ programmatore non avere troppi problemi il crossing-over.

Come postcript direi che il C/C++ è più adatto alla robotica, in quanto gli studenti saranno, senza dubbio, avere a che fare con sistemi embedded e Fpga a un certo punto.Programmazione a basso livello di conoscenza (bit, registri, etc.) sarebbe un contributo prezioso per questo genere di cose.

@mendicanti In realtà LabVIEW è molto usato nell'industria, in particolare per i sistemi di controllo.Concesso NASA improbabile che uso per sistemi satellitari ma poi sviluppo software per lo spazio-sistemi di del tutto diverso il gioco della palla...

Altri suggerimenti

Ho incontrato una situazione in qualche modo simile nel gruppo di ricerca attualmente sto lavorando in.Si tratta di un gruppo di biofisica, e stiamo usando LabVIEW in tutto il luogo per controllare i nostri strumenti.Che funziona a meraviglia:è facile da assemblare un'interfaccia utente per il controllo di tutti gli aspetti di strumenti, di visualizzarne lo stato e per salvare i vostri dati.

E ora devo trattenermi dallo scrivere un pagina 5 di sfogo, perché per me LabVIEW è stato un incubo.Fammi provare a riassumere alcuni pro e contro:

Disclaimer Io non sono un esperto LabVIEW, potrei dire cose che sono di parte, out-of-data o semplicemente sbagliato :)

LabVIEW pro

  • Sì, è facile da imparare.Molti di Dottorato di ricerca del nostro gruppo che sembra aver acquisito competenze sufficienti per hack via in poche settimane, o anche meno.
  • Librerie.Questo è un punto importante.È necessario esaminare attentamente questo per la tua situazione (non so di che cosa avete bisogno, se ci sono buone LabVIEW librerie per esso, o se ci sono alternative in altre lingue).Nel mio caso, trovare, ad esempio, una buona e veloce la creazione di grafici libreria in Python è stato un problema importante, che mi ha impedito di riscrivere alcuni dei nostri programmi in Python.
  • La tua scuola può già installato e in esecuzione.

LabVIEW contro

  • Forse troppo facile da imparare.In ogni caso, sembra che nessuno si preoccupa per imparare le migliori pratiche, in modo che i programmi di diventare rapidamente un completo, irreparabile disastro.Certo, anche questo è destinato ad accadere con linguaggi basati su testo, se non stai attento, ma IMO è molto più difficile fare le cose bene in LabVIEW.
  • Ci tendono ad essere principali questioni in LabVIEW con la ricerca sub-VIs (anche fino alla versione 8.2, credo).LabVIEW ha il suo modo di sapere dove si trova biblioteche e sub-VIs, che lo rende molto facile da completamente rompere il vostro software.Questo rende grandi progetti, un dolore, se non hai qualcuno che sa come gestire questo.
  • Ottenere LabVIEW per lavorare con il controllo di versione è un dolore.Certo, può essere fatto, ma in ogni caso mi piacerebbe astenersi dall'utilizzare il built-in VC.Check out LVDiff per LabVIEW diff strumento, ma anche non pensare di fusione.

(Gli ultimi due punti, lavorare in un team su un progetto difficile.Probabilmente questo è importante nel tuo caso)

  • Questo è personale, ma trovo che molti algoritmi semplicemente non funzionano quando programmato visivamente. E ' un casino.
    • Un esempio è la roba che è strettamente sequenziale;che diventa ingombrante e piuttosto velocemente.
    • È difficile avere una panoramica del codice.
    • Se si utilizza sub-VI per le attività di piccole dimensioni (così come non è una buona pratica per rendere le funzioni che consentono di eseguire un compito, e che stare su uno schermo), non si può semplicemente dare loro nomi, ma devi disegnare icone per ciascuno di essi.Che diventa molto fastidioso e ingombrante nel giro di pochi minuti, quindi è diventato molto tentato non mettere la roba in un sub-VI.È semplicemente troppo di una seccatura.Btw:fare una vera icona, può assumere un professionista ore.Vai a provare a fare un unico, immediatamente comprensibile e riconoscibile icona per ogni sub-VI si scrive :)
  • Avrete tunnel carpale entro una settimana.Garantito.
  • @Brendan:udite!udite!

Osservazioni conclusive

Come per il "devo scrivere il mio moduli" domanda:Non ne sono sicuro.Dipende dal tuo vincoli di tempo.Non perdere tempo a reinventare la ruota, se non è necessario.E ' troppo facile passare giorni e giorni a scrivere codice di basso livello e poi rendersi conto di aver esaurito il tempo.Se questo significa che si sceglie di LabVIEW, andare per esso.

Se ci sarebbe un modo facile per combinare LabVIEW e, ad esempio, C++, mi piacerebbe sentire su di esso:che può dare il meglio di entrambi i mondi, ma I dubbi ci sono.

Ma assicurarsi che voi e il vostro team di trascorrere del tempo di apprendimento delle migliori pratiche.Guardando l'altro codice.Imparare gli uni dagli altri.La scrittura fruibile, comprensibile codice.E divertirsi!

E ti prego di perdonarmi per il suono tagliente e forse un po ' pedante.E ' solo che LabVIEW è stato un reale incubo per me :)

Penso che la scelta di LabVIEW o non scende se si vuole imparare a programmare in una lingua di uso comune come una capacità commerciabile, o semplicemente si vuole ottenere roba fatta.LabVIEW consente di Ottenere Roba Fatta molto velocemente e in modo produttivo.Come altri hanno osservato, non magicamente di dover capire cosa si sta facendo, ed è del tutto possibile per creare una diabolica pasticcio se non anche se aneddoticamente, i peggiori esempi di cattivo stile di codifica in LabVIEW sono in genere perpetrati da persone che sono esperti in un testo in lingua e si rifiutano di adattarsi a come LabVIEW funziona perche 'sanno già come programma, dannazione!'

Questo non implica che di programmazione LabVIEW non negoziabili, di abilità, di corso;solo che non è come il mercato di massa come il C++.

LabVIEW rende estremamente facile da gestire diverse cose da fare, in parallelo, il che si potrebbe avere in una situazione di controllo di robot.Condizioni di gara il codice che deve essere sequenziale non dovrebbe essere un problema (es.se lo sono, si sta facendo male):ci sono tecniche semplici per assicurarsi che succedono cose nel giusto ordine, se necessario, il concatenamento del subVI utilizzando l'errore di filo o di altri dati, utilizzando notificatori o code, la costruzione di una macchina a stati di struttura, anche utilizzando LabVIEW della struttura in sequenza, se necessario.Di nuovo, questo è semplicemente un caso di prendere il tempo di capire gli strumenti disponibili in LabVIEW e come funzionano.Non credo che il cruccio di dover fare subVI icone è molto ben diretto;è possibile creare rapidamente una contenente alcune parole del testo, forse con un colore di sfondo, e che andrà bene per la maggior parte degli scopi.

'Sono linguaggi grafici la via del futuro" è un red herring basato su una falsa dicotomia.Alcune cose che ben si adatta ai linguaggi grafici (codice in parallelo, per esempio);altre cose seme di testo in lingue molto meglio.Non mi aspetto di LabVIEW e di programmazione grafica per andare via, o conquistare il mondo.

Per inciso, sarei molto sorpreso se la NASA non utilizzo di LabVIEW nel programma spaziale.Qualcuno è stato recentemente descritto nella sezione Info-LabVIEW mailing list come avevano utilizzato LabVIEW per sviluppare e testare il controllo in anello chiuso di volo superfici azionati da motori elettrici del Boeing 787, e ha dato l'impressione che LabVIEW, è stato ampiamente utilizzato nel piano di sviluppo.È anche utilizzato per il controllo in tempo reale in Il Large Hadron Collider!

Il più attualmente per ottenere ulteriori informazioni e aiutare con LabVIEW, a prescindere da National Instruments' proprio sito e forum, sembra essere LAVA.

Questo non risposta è una domanda direttamente, ma si può prendere in considerazione una terza opzione di miscelazione in un linguaggio interpretato. Lua, per esempio, è già usato nel campo della robotica.E ' veloce, leggero e può essere configurato per essere eseguito con punto fisso di numeri al posto della virgola mobile poiché la maggior parte dei microcontrollori non hanno un FPU. Via è un'altra alternativa simile utilizzo.

Dovrebbe essere abbastanza facile scrivere un sottile livello di interfaccia in C e poi lasciare che gli studenti si siano allentati con interpretati script.Si potrebbe anche impostare per consentire l'esecuzione di codice per essere caricati in modo dinamico senza dover ricompilare e lampeggiante di un chip.Questo dovrebbe ridurre il iterazione del ciclo e consentono agli studenti di imparare meglio da vedere i risultati più velocemente.

Io sono di parte contro utilizzo di strumenti visuali come LabVIEW.Mi sembra sempre di colpire qualcosa che non è o non piuttosto lo voglio fare.Così, io preferisco il controllo assoluto si ottiene con il codice testuale.

LabVIEW altro punto di forza (oltre a librerie) è la concorrenza.Si tratta di un linguaggio di flusso dei dati, il che significa che il runtime può gestire la concorrenza per voi.Quindi, se si sta facendo qualcosa di altamente concorrenti e non voglio avere a che fare tradizionale di sincronizzazione, LabVIEW può aiutare lì.

Il futuro non appartiene a linguaggi grafici come sono oggi.Esso appartiene a chi può venire con una rappresentazione del flusso di dati (o un altro di concorrenza-friendly tipo di programmazione) che è semplice come l'approccio grafico è, ma è anche analizzabile dal programmatore di propri strumenti.

C'è uno studio pubblicato sull'argomento ospitato da National Instruments:

Uno Studio di Grafica vsDi Programmazione testuali per l'Insegnamento DSP

Specificamente guarda LabVIEW contro MATLAB (rispetto a C).

Penso che la grafica di lingue wil essere sempre limitata espressività rispetto a quelli testuali.Confronta il tentativo di comunicare in simboli visivi (ad esempio, REBUS o di lingua dei segni) per comunicare tramite le parole.

Per le attività più semplici, utilizzando un linguaggio grafico che di solito è più facile, ma per di più intricato, trovo che la grafica di lingue ottenere nel modo.

Un altro dibattito implicita in questo argomento, però, è di programmazione dichiarativa vsimperativo.Dichiarativa di solito è meglio per qualcosa di cui si ha veramente bisogno di un controllo dettagliato su come si fa una cosa.Si può l'uso di C++ in modo dichiarativo, ma si avrebbe bisogno di più lavoro di fronte a renderlo così, mentre LABView è stato progettato come un linguaggio dichiarativo.

Un'immagine vale più di mille parole, ma se l'immagine rappresenta un migliaio di parole che non servono e non si può cambiare, allora in quel caso l'immagine è priva di valore.Considerando che si può creare migliaia di foto con le parole, specificando ogni dettaglio e anche portando lo spettatore a concentrarsi in modo esplicito.

LabVIEW consente di iniziare rapidamente, e (come altri hanno già detto) ha un enorme libreria di codice per fare vari test, misura e controllo collegato le cose.

Il singolo più grande rovina di LabVIEW, però, è che si perdono tutti gli strumenti che i programmatori di scrivere per se stessi.

Il codice viene memorizzato come VIs.Questi sono opachi, i file binari.Questo significa che il codice è in realtà non è tuo, è di LabVIEW è.Non è possibile scrivere il proprio parser, non è possibile scrivere un generatore di codice, non è possibile fare modifiche automatiche via macro o script.

Questo fa schifo quando si dispone di un 5000 VI app che ha bisogno di qualche piccola modifica applicato universalmente.Il solo opzione è di andare VI manualmente, e il cielo ti aiuti se si dimentica una modifica in uno VI spento in un angolo da qualche parte.

E sì, dal momento che è binario, non si può fare un diff/merge/patch come si fa con linguaggi testuali.Questo effettivamente fa lavorare con più di una versione del codice di un orribile incubo di manutenibilità.

Con tutti i mezzi, utilizzare LabVIEW se si sta facendo qualcosa di semplice, o la necessità di prototipo, o non avete intenzione di mantenere il vostro codice.

Se si vuole fare vera e gestibile di programmazione, utilizzare un linguaggio testuale.Si potrebbe essere più lento di iniziare, ma si ' ll essere più veloce nel lungo periodo.

(Oh, e se avete bisogno di DAQ biblioteche, NI s got C++ e .Net versioni di quelli, troppo.)

Il mio primo post qui :) essere gentili ...

Io vengo da un embedded background nel settore automobilistico e ora sto nel settore della difesa.Posso dirvi per esperienza che il C/C++ e LabVIEW sono davvero bestie differenti con diversi obiettivi in mente.C/C++ è sempre stato utilizzato per l'embedded lavoro su microcontrollori perché era compatto e compilatori/strumenti erano facili da trovare.LabVIEW, invece, è utilizzato per il sistema di test (con test di stare come un sequencer).La maggior parte delle attrezzature di prova che abbiamo usato sono stati NI, così LabVIEW fornito un ambiente in cui abbiamo avuto gli strumenti e i driver necessari per il lavoro, con il supporto volevamo ..

In termini di facilità di apprendimento, ci sono molte molte risorse là fuori per C/C++ e molti siti web che lay out considerazioni sulla progettazione e l'esempio di algoritmi su praticamente qualsiasi cosa che si sono liberamente disponibili.Per LabVIEW, la comunità di utenti probabilmente non è così diversi come C/C++, e ci vuole un po ' di sforzo in più per controllare e confrontare codice di esempio (deve avere la giusta versione di LabVIEW, ecc) ...Ho trovato LabVIEW abbastanza facile da imparare, ma c'è un rompiscatole come alcuni hanno detto qui a che fare con il parallelismo e varie altre cose che richiedono un po ' di esperienza prima di diventare consapevoli di loro.

Quindi, la conclusione dopo tutto quello che?Direi che ENTRAMBE le lingue sono utili nell'apprendimento perché essi in realtà non rappresentano due diversi stili di programmazione e non è certamente la pena di essere consapevole e competente sia.

Oh mio Dio, la risposta è così semplice.Utilizzare LabView.

Ho programmato di sistemi embedded per 10 anni, e posso dire che senza almeno un paio di mesi di infrastrutture (molto attenti infrastrutture!), non sarà più produttivo, come si è in 1 giorno con LabView.

Se si sta progettando un robot per essere venduti e utilizzati per i militari, andare avanti e iniziare con il C - è una buona chiamata.

In caso contrario, utilizzare il sistema che ti permette di provare più varietà nel più breve lasso di tempo.Che LabView.

Penso che la grafica di lingue potrebbe essere la lingua del futuro.....per tutti coloro adhoc MS Access sviluppatori.Ci sarà sempre un posto per l'puramente testuale programmatori.

Personalmente, ho avuto modo di chiedere qual è il vero divertimento di costruire un robot se è tutto fatto per voi?Se è solo una goccia 'a trovare la palla rossa' modulo di lì e guardarlo andare?Che senso di orgoglio, vuoi per i tuoi risultati?Personalmente, non mi hanno molto.Inoltre, cosa può insegnare di codifica, o dei (molto importante) aspetto di software/hardware di interfaccia che è fondamentale nel campo della robotica?

Non ho la pretesa di essere un esperto nel campo, ma chiediti una cosa:Pensi che la NASA utilizzato LabVIEW per codice Mars Rovers?Pensi che qualcuno veramente di spicco nel campo della robotica sta utilizzando LabView?

Davvero, se chiedete a me, l'unica cosa che uso di cookie cutter cose come LabVIEW per creare questo sta per preparare sia qualche cortile robot builder e niente di più.Se volete qualcosa che vi darà qualcosa di più simile all'esperienza nel settore, costruire il tuo 'LabVIEW'tipo di sistema.Costruire il proprio trovare-la-palla module, o il vostro follow-the-line " del modulo.Sarà molto più difficile, ma sarà anche un modo più fresco di troppo.:D

Mi piace LabVIEW.Mi raccomando, soprattutto se l'altro si ricorda di aver utilizzato qualcosa di simile.Ci vuole un po ' per il normale programmatori per abituarsi ad esso, ma il risultato è molto meglio se si sa già come si programma.

C/C++ equivale a gestire la memoria.Potrete nuotare nella memoria i collegamenti e preoccuparsi di loro.Andare con LabVIEW, e assicuratevi di leggere la documentazione fornita con LabVIEW e guardare fuori per le condizioni di gara.

L'apprendimento di una lingua è facile.Imparare a programmare non è.Questo non cambia anche se si tratta di un linguaggio grafico.Il vantaggio di linguaggi Grafici è che è più facile a visual cosa farà questo codice invece di sedersi lì e decifrare un mucchio di testo.

La cosa importante non è la lingua, ma i concetti di programmazione.Non importa che lingua si impara a programmare, perché con un po ' di sforzo si dovrebbe essere in grado di programmare bene in qualsiasi lingua.Le lingue vanno e vengono.

Disclaimer:Non ho assistito a LabVIEW, ma ho usato un paio di altri linguaggi grafici tra cui WebMethods di Flusso e Modellistica, simulazione dinamica di lingue all'università e, er, MIT Scratch :).

La mia esperienza è che la grafica di lingue può fare un buon lavoro di la 'idraulico' ambito della programmazione, ma quelli che ho utilizzato attivamente ottenere nel modo di algoritmica.Se gli algoritmi sono molto semplice, che potrebbe essere OK.

D'altra parte, non credo che il C++ è grande per la vostra situazione.Consente di passare più tempo a rintracciare puntatore e problemi di gestione della memoria che si fa in lavoro utile.

Se il robot può essere controllato utilizzando un linguaggio di scripting (Python, Ruby, Perl, quello che è), quindi penso che sarebbe una scelta molto migliore.

Poi c'è ibrido opzioni:

Se non c'è nessuna opzione di scripting per il vostro robot, e si dispone di un C++ geek della tua squadra, quindi considerare che avere geek scrivere associazioni di mappare la libreria C++ per un linguaggio di scripting.Questo permetterebbe alle persone con altre specialità per programmare il robot più facilmente.Le associazioni che sarebbe stato un buon regalo per la comunità.

Se LabVIEW permette, di usare il linguaggio grafico di piombo insieme di moduli scritti in un linguaggio testuale.

Sei al liceo.Quanto tempo si deve lavorare su questo programma?Quante persone sono nel vostro gruppo?Fanno a sapere il C++ o LabView già?

Dalla tua domanda, vedo che conosci C++ e la maggior parte del gruppo non.Ho anche il sospetto che il leader del gruppo è percettiva sufficiente per notare che alcuni membri del team possono essere intimiditi da un testo di base del linguaggio di programmazione.Questo è accettabile, sei al liceo, e queste persone sono normies.Mi sento come se normali liceali sarà in grado di capire LabView in modo più intuitivo rispetto al C++.Sto indovinando che la maggior parte studenti delle scuole superiori, come la popolazione in generale, hanno paura di una riga di comando.Per voi c'è molto meno di una differenza, ma per loro è notte e giorno.

È giusto che gli stessi concetti possono essere applicati a LabView, C++.Ognuno ha i suoi punti di forza e di debolezza.La chiave è scegliere lo strumento giusto per il lavoro.LabView è stato progettato per questo tipo di applicazione.Il C++ è molto più generico e può essere applicato a molti altri tipi di problemi.

Ho intenzione di raccomandare LabView.Dato il giusto hardware, si può essere quasi out-of-the-box.La tua squadra può spendere più tempo ottenere il robot per fare quello che vuoi, che è ciò che il focus di questa attività dovrebbe essere.

Grafica Lingue non sono il futuro della programmazione;sono stati una delle scelte disponibili, creato per risolvere certi tipi di problemi, per molti anni.Il futuro della programmazione, strato su strato di astrazione della macchina di codice.In futuro, saremo chiedendo perché abbiamo perso tutto questo tempo la programmazione di "semantica" più e più volte.

quanto possiamo contare su moduli predefiniti, e quanto dovremmo provare a scrivere sul nostro? Non si deve perdere tempo a reinventare la ruota.Se ci sono i driver di periferica disponibile in Labview, li utilizzano.Si può imparare un sacco copiando il codice che è simile in funzione da personalizzare in base alle vostre esigenze - si arriva a vedere come altre persone risolto problemi simili, e hanno di interpretare la loro soluzione, prima di poter applicare correttamente il tuo problema.Se si ciecamente copia il codice, le probabilità di ottenere il lavoro sono scarse.Devi essere buona, anche se si copia il codice.

In bocca al lupo!

Vorrei suggerire di utilizzare LabVIEW è possibile ottenere per rendere il robot che cosa si vuole fare di più facile e veloce.LabVIEW è stato progettato con questo in mente.Naturalmente C(++) sono grandi lingue, ma LabVIEW fa quello che dovrebbe fare meglio di qualsiasi altra cosa.La gente può scrivere davvero un buon software in LabVIEW offre un ampio campo di applicazione e il supporto per l'.

C'è una enorme cosa che ho trovato negativa in LabVIEW per le mie applicazioni:Organizzare la complessità del design.Come physisist trovo Labview ottimo per la prototipazione, strumento di controllo e di analisi matematica.Non c'è la lingua in cui si ottiene più velocemente e meglio di un risultato quindi in LabVIEW.Ho utilizzato LabView dal 1997.Dal 2005 sono passato completamente al .NET framework, poiché è più facile da progettare e mantenere.

In LabVIEW un semplice 'se' struttura deve essere disegnato e utilizza un sacco di spazio sulla progettazione grafica.Ho appena scoperto che molte delle nostre applicazioni commerciali erano difficili da mantenere.Più complessa l'applicazione è diventata più difficile da leggere.

Io uso di testo, linguaggi e io sono molto meglio a mantenere tutto.Se vuoi confrontare un C++, LabVIEW vorrei utilizzare LabVIEW, ma rispetto a C# non vincere

Come sempre, dipende.

Sto usando LabVIEW da circa 20 anni e ha fatto un gran genere di lavori, dal semplice DAQ per molto complessa di visualizzazione, dal dispositivo di controlli per verificare la sequencer.Se non era abbastanza buono, io di sicuro sarebbe cambiato.Detto questo, ho iniziato a scrivere codice Fortran con punchcards e usato un sacco di linguaggi di programmazione 8-bit 'macchine', iniziando con lo Z80-quelli a base.Le lingue variava da Assembler, BASIC, dal Turbo-Pascal C.

LabVIEW è stato un miglioramento notevole a causa delle sue numerose librerie per acquisizione dati e di analisi.Uno ha, tuttavia, per imparare un diverso paradigma.E hai sicuramente bisogno di un trackball ;-))

Non ho nulla di LabView (o molto sui C/C++), ma..

Pensi che la grafica lingue come LabVEIW sono il futuro della programmazione?

No...

È un linguaggio grafico più semplice per imparare un linguaggio testuale?Io credo che si dovrebbe essere di circa altrettanto difficili da imparare.

Più facile da imparare?No, ma hanno sono più facile da spiegare e da capire.

Per spiegare con un linguaggio di programmazione è necessario spiegare che cosa una variabile (che è sorprendentemente difficile).Questo non è un problema con flowgraph/nodale strumenti di codifica, come il LEGO Mindstroms interfaccia di programmazione, o Quartz Composer..

Per esempio, in questo è abbastanza complicato LEGO Mindstroms programma - e ' molto facile capire cosa sta succedendo nel...ma cosa succede se si desidera che il robot per eseguire il INCREASEJITTER blocco di 5 volte, quindi la macchina in avanti per 10 secondi, quindi cercare il INCREASEJITTER loop di nuovo?Le cose iniziano a ottenere disordinato molto rapidamente..

Quartz Composer è un grande esempio di questo, e perché non credo linguaggi grafici potrà mai essere "il futuro"

Rende molto facile per cose davvero interessanti (3D, effetti particellari, con una telecamera controllata dalla media luminosità dei pixel da una webcam)..ma incredibilmente difficile da fare cose facili, come iterare sugli elementi da un file XML, o un negozio che media il valore del pixel in un file.

Vedendo come ci sono partailly radicata nell'aiutare le persone a imparare, quanto possiamo contare su moduli predefiniti, e quanto dovremmo provare a scrivere sul nostro?("Buoni programmatori di scrivere del buon codice, grande programmatori copia del codice." Ma non è la pena di essere un buon programmatore, prima?)

Per l'apprendimento, è molto più facile sia per spiegare e comprendere un linguaggio grafico..

Detto questo, mi sento di raccomandare un testo tecnico-base di lingua la lingua come una progressione.Per esempio, per la grafica qualcosa di simile Elaborazione o NodeBox.Essi sono "normali" per le lingue (l'Elaborazione è Java, NodeBox è Python) con molto specializzati, facile da usare (ma assurdamente potente) quadri radicata in loro..

Soprattutto, essi sono molto linguaggi interattivi, non devi scrivere centinaia di righe solo per ottenere un cerchio sullo schermo.Basta digitare oval(100, 200, 10, 10) e premere il pulsante esegui, e appare!Questo li rende anche molto più facile da dimostrare e spiegare.

Più robotica-correlati, anche qualcosa come il LOGO potrebbe essere una buona introduzione - è di tipo "FORWARD 1" e la tartaruga unità in avanti di una casella..Tipo "a SINISTRA di 90" e si gira di 90 gradi..Questo si riferisce alla realtà in modo molto semplice.È possibile visualizzare ciò che ogni istruzione, poi provare e confermare che funziona davvero in quel modo.

Mostrare loro shiney guardare le cose, essi dovranno rispondere le cose utili che imparano da C lungo la strada, se sono interessati o per progredire al punto in cui hanno bisogno di un "vero" di una lingua, loro hanno tutte le conoscenze, piuttosto che correre in sintassi-errore e compilazione di un muro di mattoni..

Sembra che se si sta cercando di preparare il nostro team per un futuro in programmazione in C(++) ma essere la via migliore.La promessa di una generale i linguaggi di programmazione che sono costruiti con visual blocchi di costruzione non è mai sembravano materializzarsi e io sto cominciando a chiedersi se sarà mai.Sembra che mentre può essere fatto per specifici domini di problema, una volta che si ottiene per cercare di risolvere molti problemi di carattere generale di un testo in base linguaggio di programmazione è difficile da battere.

Una volta ho avuto una sorta di accettato l'idea di eseguibile UML, ma sembra che una volta passato l'oggetto di relazioni e di alcuni flussi di processo UML sarebbe un bel modo pietoso per creare un'app.Immaginate di provare a legare il tutto con un'interfaccia grafica.Non mi dispiacerebbe essere smentito, ma finora sembra improbabile che saremo punto e fare clic su programmazione in qualunque momento presto.

Ho iniziato con LabVIEW circa 2 anni fa e ora lo uso tutto il tempo, quindi potrebbe essere di parte, ma la trovo ideale per applicazioni in cui l'acquisizione di dati e di controllo.

Si utilizza LabVIEW principalmente per i test in cui prendiamo le misure in continuo e il controllo delle valvole a gas e MANGIATO custodie.Questo comporta sia digitale che analogica di ingresso e di uscita con segnale di procedure di analisi e controllo di processo in esecuzione da una GUI.Abbattendo ogni parte in subvi siamo in grado di riconfigurare il test con il clic e trascinare il mouse.

Non è esattamente lo stesso C/C++, ma una simile implementazione di misura, di controllo e di analisi utilizzando Visual BASIC, appare complesso e difficile da mantenere confronto.

Penso che il processo di programmazione è più importante che l'attuale codifica della lingua e si devono seguire le linee guida di stile per un linguaggio di programmazione grafica.LabVIEW i diagrammi a blocchi per mostrare il flusso di dati (Flusso dei dati di programmazione) e quindi dovrebbe essere facile per vedere i potenziali condizioni di gara anche se non ho mai avuto problemi.Se si dispone di un C codebase un edificio in una dll permetterà di LabVIEW per la chiamata direttamente.

Ci sono sicuramente i meriti di entrambe le scelte;tuttavia, poiché il dominio è un'esperienza educativa penso che un C/C++ soluzione sarebbe più beneficiare gli studenti.Programmazione grafica sarà sempre un'opzione, ma semplicemente non fornisce la funzionalità in modo elegante, che dovrebbe rendere più efficiente rispetto di programmazione testuali per la programmazione di basso livello.Questa non è una brutta cosa - il punto di astrazione è quello di consentire una nuova visione di un dominio del problema.Il motivo credo che molti potrebbero essere delusi con la programmazione grafica, però, è che, per un particolare programma, il backup incrementale di guadagno che va dal linguaggio di programmazione C per la grafica non è quasi la stessa cosa che andare dall'assemblea C.

Conoscenza di programmazione grafica sarebbe un vantaggio per qualsiasi programmatore futuro sicuro.Ci sarà probabilmente una opportunità per il futuro, che richiede solo la conoscenza di programmazione grafica e, forse, alcuni studenti potrebbero beneficiare di alcune delle prime esperienze con esso.D'altra parte, una solida base dei fondamentali concetti di programmazione offerta da un approccio testuale andrà a beneficio tutti i tuoi studenti, sicuramente deve essere la risposta migliore.

Il capitano della squadra, pensa che LabVIEW è meglio per la sua facilità di apprendimento e di l'insegnamento.È vero?

Mi viene il dubbio che potrebbe essere vero per ogni singola lingua, o paradigma.LabView poteva sicuramente essere più facile per le persone con elettronica ingegneria;fare programmi in esso è "semplicemente" il disegno di fili.Poi di nuovo, queste persone potrebbero già essere esposti alla programmazione, pure.

Una differenza essenziale - a parte la grafica, è che LV è la domanda di base (flusso) di programmazione.Si parte dal risultato e dire, che cosa è necessario per arrivare ad essa.La programmazione tradizionale tende ad essere imperativo (andando in senso opposto).

Alcune lingue in grado di fornire entrambi.Ho creato un multithreading biblioteca per Lua di recente (Corsie) e può essere utilizzato per la domanda di base di programmazione in un altro imperativo ambiente.So che ci sono riuscito robot di eseguire principalmente in Lua là fuori (Crazy Ivan a Lua Oh Sei).

Ho dato uno sguardo a Microsoft Robotics Studio?http://msdn.microsoft.com/en-us/robotics/default.aspx

Esso consente di programmazione visuale (VPL):http://msdn.microsoft.com/en-us/library/bb483047.aspx così come moderni linguaggi come C#.Vi incoraggio a dare almeno un'occhiata al tutorial.

Il mio cruccio contro Labview (e Matlab in questo senso) è che se hai intenzione di incorporare il codice in qualcosa di diverso da x86 (e Labview ha gli strumenti per mettere in Labview su Braccia), poi dovrete buttare tanta potenza al problema, come si può perché è inefficiente.

Labview è un grande strumento di prototipazione:un sacco di librerie, di facile stringa insieme di blocchi, forse un po ' difficile da fare algoritmi avanzati, ma probabilmente c'è un blocco per quello che vuoi fare.È possibile ottenere funzionalità di fatto in fretta.Ma se pensate che si può prendere che VI e appena messo su un dispositivo vi sbagliate.Per esempio, se si effettua una vipera blocco in Labview si dispone di due ingressi e un'uscita.Che cosa è l'uso della memoria per che?Tre variabili vale la pena di dati?Due?In C o C++ si sa, perché si può scrivere z=x+y o x+=y e si sa esattamente che cosa il vostro codice sta facendo e ciò che la memoria situazione.Utilizzo della memoria può spike rapidamente soprattutto perché (come altri hanno fatto notare) Labview è altamente parallelo.Quindi, essere pronti a gettare più RAM di quanto si pensava al problema.E più potenza di elaborazione.

In breve, Labview è grande per la prototipazione rapida, ma si perde troppo di controllo in altre situazioni.Se si lavora con grandi quantità di dati o limitata, memoria e potenza di elaborazione, quindi utilizzare un testo-base del linguaggio di programmazione in modo da poter controllare ciò che accade.

Persone sempre confrontare labview, C++ e giorno "oh labview è di alto livello ed ha così tanto costruito nel funzionalità di provare l'acquisizione di dati facendo un dfft e la visualizzazione dei dati è così facile in labview provare in C++".

Mito 1:È difficile ottenere qualcosa fatto con il C++ ha il suo perché, il suo modo di basso livello e labview ha molte cose già implementate.Il problema è che se si sta sviluppando un sistema robotico in C++, è NECESSARIO utilizzare librerie come opencv , pcl ..ect e si sarebbe anche più intelligente se si utilizza un framework software progettato per la costruzione di sistemi robotici come ROS (robot operating system).Di conseguenza, è necessario utilizzare un set completo di strumenti.Ci sono infatti più alto livello di strumenti disponibili quando si utilizza il ROS + python/c++ con librerie come opencv e pcl.Ho utilizzato labview robotica e francamente algoritmi comunemente utilizzati come ICP non ci sono e la sua non è come è possibile utilizzare altre biblioteche facilmente ora.

Myth2:È più facile capire i linguaggi di programmazione grafica

Dipende dalla situazione.Quando si codifica un complicato algoritmo di elementi grafici prenderà prezioso spazio sullo schermo e sarà difficile capire il metodo.Per capire il codice labview devi leggere su di un'area che è O(n^2) complessità del codice che hai appena letto cima a fondo.

Che cosa succede se si dispone di sistemi in parallelo.ROS implementa un grafico basato architettura basata su subcriber/editore messaggi implementato utilizzando richiamata e la sua abbastanza facile per avere più programmi in esecuzione e di comunicare.Singoli componenti parallele separate rende più facile per eseguire il debug.Per esempio passo parallelo di codice labview è un incubo a causa del flusso di controllo salti forma un luogo ad un altro.ROS non esplicitamente 'tirare fuori il vostro archietecture come in labview, tuttavia si può ancora vedere il mio eseguendo il comando ros eseguire rqt_graph ( che vi mostra tutti i nodi della rete)

"Il futuro della programmazione grafica." (La penso così?)

Io spero di no, l'implementazione corrente di labview non consente la codifica con il testo-base di metodi e metodi grafici.( c'è mathscript , tuttavia questo è incredibilmente lento)

La sua difficile il debug perché si può nascondere il parallelismo facilmente.

La sua difficile leggere il codice labview, perché ci si deve guardare così tanto la zona.

Labview è grande per i dati aq e di elaborazione del segnale, ma non è sperimentale di robotica, perché la maggior parte dell'alto livello di componenti come SLAM (simultaneous di localizzazione e mapping), nuvole di punti, registrazione, elaborazione delle nuvole di punti ect sono mancanti.Anche se non aggiungere questi componenti e sono facili da integrare come in ROS, perché labview è proprietario e costoso non potranno mai tenere il passo con la comunità open source.

In sintesi se labview è il futuro per la meccatronica sto cambiando il mio percorso di carriera di investment banking...Se io non posso godere il mio lavoro, mi può pure fare un po ' di soldi e andare in pensione in anticipo...

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top