Linguaggi di programmazione grafica

[pier]

Salve a tutti.
Nella eterna ricerca di novità che semplifichino la vita, mi sono imbattuto in linguaggi come Flowcode, Ardublock e Minibloq.
Il primo mi sembra il più potente ma non ho ben capito se si tratta di "giocattoli" o meno.
Credo che il controllo sul codice sia praticamente nullo e questo è un problema per applicazioni "critiche" ma per il resto mi pare di aver visto potenzialità notevoli (gestione periferiche, gestione protocolli di comunicazione, etc. implementabili in modo, apparentemente, estremamente semplice).
Qualcuno del forum ha fatto esperienze in merito?

Pier

[deluca]

pier,
non ho nulla da ridire su quel tipo di approccio, scelte soggettive.......

ma che tipo di conoscenza hai dei linguaggi classici, tipo assembly, C , basic o altri di questo tipo?

[pier]

Beh, sono un grande utilizzatore di Bascom AVR e occasionalmente del vecchio 8051. Con il C sudo freddo ogni volta che mi tocca e in Assembly so' solo quel che mi basta per salvare e ripristinare i registri in caso di utilizzo di "nosave" per problemi di velocità.
Per lo stesso Arduino adottare ufficialmente un linguaggio "C like" non mi pare entusiasmante (come l'adozione dell'inglese quale lingua ufficiale e preferenziale per un prodotto italiano come quello)....
Bascom mi pare veramente una manna ma non mi spiacerebbe sperimentare anche altro (magari solo per qualche applicazione particolare) possibilmente senza buttare il tempo rifacendo esperienze che altri potrebbero avere fatto senza risultati apprezzabili

[deluca]

bene,
quindi Basic oriented,
se utilizzi Bascom-avr allora devi sperare che Mark continui a sviluppare ed aggiornare le versioni del compilatore.
Secondo la mia esperienza uno dei compilatori basic x avr + efficienti attualmente in commercio.

Quale è il taglio delle tue applicazioni?

[pier]

Le mie sono praticamente piccole applicazioni sotto i 50K di sorgente finalizzate solitamente all'ambito medicale e in genere di misura del mondo fisico.
Effettivamente prego molto per la salute di Mark .
Come alternativa ho usato PICBASIC ma, seppure oggi molto cresciuto anche nella simulazione, non mi pare concorrenziale (oltre a rivolgersi ai PIC che non amo particolarmente).
La mia curiosità sui linguaggi grafici trova linfa dalla constatazione di quanto riescono a fare linguaggi come LABVIEW (che ho avuto il piacere di incontrare in passato seppure "di striscio") o i vari "schematic capture". In fondo si tratta della differenza tra l'interfaccia carattere con le righe di comando e le GUI oggi irrinunciabili, almeno dalla massa, per la loro comodità ed apprezzate persino dai Linuxiani (senza contare che così sarei un po' più svincolato dalla salute di Mark al quale auguro comunque lunga vita)...

[js-bascom]

E' solo BETA pero' forse cerchi qualche cosa come quetso? http://avrtools.no/Main.asp?page=2

[flipper]

salve a tutti,

@js-bascom,
ma come si fa a scaricare il programma eseguibile?
Bisogna aspettare il 15 ottobre?
Sai quanto costerà?

[deluca]

flipper, i file per il donwload si trovano qui:

http://avrtools.no/Main.asp?page=10

si tratta di una versione beta-demo, la 0.4.2, ma ha molte imperfezioni e limitazioni....
io consiglierei sempre la programmazione classica cmq.

[pier]

Caro js-bascom, bellissimo il "giocattolino" che indichi!
Usarlo mi sembrerebbe di tornare a fare "elettronica". Carino anche il generatore di schemi quasi a livello di reverse engineering che gli dà una carica in più.
Certo che non sarà per tutte le applicazioni e condivido in generale la posizione di Deluca (almeno allo stato dell'arte) ma per alcune di queste perchè nò? E in futuro vedremo.
Per ora attendiamo il 15 ottobre ed i costi.

Un parere su Flowcode? Mi sembra molto interessante visti i costi e la possibilità di gestire AVR, PIC e ARM (!) seppure moltiplicando per n l'investimento.

Grazie
Pier

[legacy]

mah, probabilmente in futuro sara' cosi' buona parte della programmazione, e buona parte della prima didattica, pero' non so, essendo abituato all'asm e al C puro, ed avendo conosciuto per primo il pascal ai tempi delle medie, vedere quel tipo di approccio oggi un po' mi spiazza.

[pier]

Ti capisco benissimo. Mi ricordo la resistenza che avevo opposto all'avvento di windows. Trovavo il Dos molto più "professionale" ma poi ho dovuto arrendermi.
E' vero che il paragone forse non è perfettamente centrato in quanto le problematiche sono un po' diverse ma, ripeto, almeno per la "produzione di massa" allungare il collo pieni di speranza verso il futuro non mi sembra male.
In fondo se i linguaggi citati mantenessero le promesse forse si rischierebbe di risparmiare un mare di tempo e molti tra i non strettamente "addetti ai lavori e addentro le segrete cose" sarebbero messi in grado di sviluppare idee con positive ricadute per tutti...

[js-bascom]

bellissimo il "giocattolino" che indichi!

Non so se giochero mai con quel "giocattolo", io sto bene con l'ASM e uso C protestando.

Dal momento che e' un programma Atmel sara gratuito a quanto penso, comuque non fidiamoci delle date indicate perche' Atmel va fuori bordo con le date da anni!

Se non sbaglio Microchip (ed altri??) offre un programma simile gratis, quindi questo e' forse una risposta alla concorenza.

[pier]

Caro js-bascom, come invidio chi ha iniziato con il Pascal. Io ho iniziato con il diodo a vuoto e finito con il discriminatore di Foster-Seeley e puoi ben capire quanto ti sia vicino nelle tue "proteste" con il C. Purtroppo anche l'ASM non è nelle mie corde ma lotto per restare vivo!
Non so se il "giocattolo" sarà veramente gratis ma staremo a vedere. Intanto appena possibile proverò a giocare con Flowcode che mi sembra abbastanza "tosto" e vi saprò dire.
Certo che se poi questi linguaggi esportassero anche in C, come qualcuno sembra fare, si potrebbe integrare/limare risparmiando il grosso del lavoro....

Pier

[js-bascom]

Purtroppo anche l'ASM non è nelle mie corde

Quando inizia con i micro, 30+ anni fa, avere un assembler era davvero un lusso!

Molti dei miei primi "programmi" venivano inseriti in hex nel micro, infatti erano scritti in hex!

Poi al lavoro ho avuto l'opportunita di usare il Motorola Exorciser che doveva essere caricato con l'editor e poi l'assembler, tutti su nastro di carta che ci voleva piu' di un'ora.

Il C compiler non era nemmeno qualche cosa da considerare perche costavano un'occhio.

Pure io ho iniziato con i diodi a vuoto, grazie alla defunta Radio Scuola Italiana (da non confondere con Radio Elettra??)

[pier]

Grande js-bascom!
Ora mi sento un po' meno solo. Forse anche a tè termini come "placca" e "griglia" fanno battere il cuore come quando si pensa al primo amore.
Purtroppo la mia attività lavorativa non mi ha consentito di stare molto "sul pezzo" parlando di micro.
L'elettronica era solo un'attività molto collaterale e "appena sopportata" che ho cercato di non far morire nella mia mente e nel chiuso della mia stanzetta. Le mie prime esperienze con i micro nascono solo circa 10 anni fa grazie a Bascom e quindi per me tutto è molto in salita.
Comunque ho visto un po' di pareri in rete su questi linguaggi tra cui Flowcode (anche con tuoi saggi interventi) con esempi di codice che mi hanno abbastanza convinto sull'attuale scarsa utilità di questi metodi. Per il futuro vedremo ma per ora non ci resta che piangere con il C, l'ASM o continuare con Bascom per quanto possibile a meno che il giocattolo che citavi non faccia il miracolo anche se ai miracoli non credo da molti anni

Pier

[legacy]

Bah, io nel mio futuro vedo bene anche python, giusto perche' e' molto piu' produttivo del C.
L'idea e' di usare python as-is nei sistemi SoC (linux), oppure per generare codice C nei sistemi bareboard ad MPU.
Per ora sembra funzionare bene sia l'una che l'altra idea.


Per quanto riguarda il C, ne ho scritto una restrizione "safeC" andando a limare vari punti e note dolenti (e.g. if (a=b) brrr) fonti di sviste e mille guai (e.g. dimentichi un break in uno switch case), pero' non ho scritto un compilatore, ho scritto un validatore (nome in codice "la maestrina"), un modulo che si pone appena dopo cpp (pre processore) e appena prima del cc (compilatore), e che accetta o rifiuta un sorgente bacchettando le mani con vari e copiosi messaggi di errore. In questo modo ottengo sorgenti MisraC compliant senza scocciare tool pesanti ed elefantici come QAC (ok, senza pretese, QAC fa mooooolto di piu') e riduco del 20% situazioni spiacevoli ed un sacco di ore poi a cercare i bachi.

Il mio vero problema: il C++! Ha una grammatica complicatissima, e scrivere una maestrina C++ e' per me impossibile, come cercare di individuare un subset safeC++.