per l'elettronica quale linguaggio e' da preferire?

Il giorno Mon, 12 May 2008 01:07:25 +0200, "triller" ha scritto:

Il VB6 non è più supportato e venduto da anni, conviene usare il VB2008 Express anche se è più complicato.

Oltretutto si può scaricare gratuitamente dal sito Microsoft.

-- ciao Stefano

triller ha scritto:

Cosa intendi di preciso? Ti riferisci alla creazione di software di controllo per apparecchiature elettroniche? Fra i due citati il VB2008 è il migliore (avrei voluto scrivere meno pegiore :-)), per i motivi indicati da SB.

Se t'interessa un linguaggio opensource e multipiattaforma (win, linux, mac) prova a dare un'occhiata a Python.

Ciao

Devi considerare vari fattori:

- affidabilit=E0

- software sviluppato per essere diffuso od usato per fini personali.

- piattaforma su cui deve girare.

- tempi di sviluppo.

- uso commerciale od hobbistico

- possibilit=E0 di upgrade

- compatibilit=E0 volta ad aggiornamenti del sistema operativo.

- necessit=E0 o meno di interfaccia grafica.

- interfacciabilit=E0 con diversi programmi.

- possibilit=E0 di proteggere i sorgenti.

- ecc, ecc.

Visual Studio rappresenta sicuramente un ottimo investimento per uso professionale, ma concordo sul fatto che non =E8 n=E9 facile, n=E9 immediato. Tuttavia, credo sia garanzia di portabilit=E0 verso l'alto ed offre risorse praticamente al confine con l'immaginazione. Permette di programmare in diversi linguaggi e di compilare anche per palmarini (CE), cosa notevole, direi. Una lacuna non piccola =E8 rappresentata dal fatto che non nasconde perfettamente il sorgente operando traduzioni in un linguaggio intermedio (puoi programmare in un linguaggio ed ottenere una buona traduzione in un altro). Tuttavia, d=E0 la possibilit=E0 di rendere poco leggibile il tutto non palesando le label ed altre cose. Mi sto interessando anche io alla questione.

Devo dire che i pi=F9 grandi passi li ho compiuti utilizzando un caro, vecchio ZX Spectrum (Basic e linguaggio macchina Z80), GWBasic e Qbasic. L'immediatezza di questi sistemi mi ha permesso di evitare il peso di dover assimilare conoscenze non funzionali ad interagire con l'hardware.

Per la sperimentazione e le messe a punto utilizzo vecchi, semplici PC che permettono un rapido e chiaro accesso alle seriali ed altre periferiche. Il bus ISA offre una versatilit=E0 ancora impareggiabile.

Una volta messo a punto l'hardware, ci si occupa del software per US (Utento Stupido, non in senso dispregiativo, per=F2).

Ciao.

Francesco Sacchi ha scritto:

Ma visto che il firware sarà scritto in C non convine fare anche l'interfacca PC in quel linguaggio? Io se dovessi scrivere un applicazione "client" di un mio "coccio" usere il C ( o per passione personale il pascal ).

Ma mai e poi mai il VB ( :D ).

"Investimento" in che senso? L'ottima versione "Express Edition" è gratuita. Non credo che l'OP sia interessato alla versione a pagamento.

Non capisco cosa intendete dire. L'ambiente di sviluppo (Visual Studio 2008) è eccezionalmente comodo e configurabile, secondo me è molto superiore agli ambienti Borland e a vari altri gratuiti (ne ho provati 3 o 4). Poi, il Basic è il linguaggio di programmazione da sempre rivolto ai principianti per la sua semplicità. Non capisco perché non debba essere né facile né immediato.

Cristiano

Il giorno Mon, 12 May 2008 11:09:36 +0200, "Cristiano" ha scritto:

Credo anch'io. Oltretutto l'op ha citato la Express nel suo post.

Se tu venissi da un ambiente come il VB3..VB6 ti saresti accorto della differenza. La gestione del Framework innanzitutto, poi il modo radicalmente diverso di fare certe cose, (ad esempio l'introduzione dell'oggetto StringBuilder per le stringhe), insomma ci sono diverse cose che non permettono di usarlo ne facilmente ne immediatamente per chi è partito con il VB classico.

Io che ho iniziato con il GwBasic e il QuickBasic posso dirti che è un salto simile a quello del passaggio da programmi a linea di comando (i vecchi DOS) e quello con interfaccia ad eventi, con la diffrenza che i vantaggi sono minori.

Poi usando .net si imparano ad apprezzare anche i suoi lati positivi, che ci sono, ma ti assicuro che la cosa non è né facile né immediata.

-- ciao Stefano

gratuita.

mediato.

to superiore agli

ai

mmediato.

Immediatezza e semplicit=C3=A0 sono in funzione dell'abilit=C3=A0 e preparaz= ione dello sviluppatore. Per chi deve tuffarsi in un simile ambiente, l'impatto =C3=A8 notevole. La semplicit=C3=A0 del Basic riguarda il passato perch=C3=A8 ormai tutti i linguaggi orientati agli oggetti differiscono nella sintassi ma non troppo nella struttura. La vera difficolt=C3=A0 sta nel cogliere globalmente le potenzialit=C3=A0 me= sse a disposizione sotto .NET che, per essere usato in modo coerente, impone di scrivere i programmi sotto una nuova visione, anzi pre- visione. Scrivere codice "blindato" =C3=A8 pi=C3=B9 veloce, facile ed immediato che scriverlo in modo da permettere espandibilit=C3=A0.

Molte volte capita che un committente non abbia le idee chiare su ci=C3=B2 che vuole e frequentemente chiede variazioni al software, fino ad arrivare al punto che la versione finale differisce a tal punto dall'idea di partenza che il codice risulta molto "sporco" e mal strutturato. Facilmente poi si raggiunge il collasso, ovvero, una situazione in cui =C3=A8 pi=C3=B9 conveniente riscrivere da capo tutto col senno di poi piutto= sto che tentare l'ennesimo rattoppo, e questo, magari, per implementare una semplice funzioncina (la goccia che fa traboccare il vaso). Il committente, da inesperto, rifiuter=C3=A0 di capire ogni problematica da lui stesso generata e pretender=C3=A0 che il programmatore lavori (sottopagato) per aggiungere quella "quisquilia" da egli richiesta.

L'abilit=C3=A0 sta nel capire l'incertezza del richiedente e scrivere codice GIA' pronto a ricevere la gran parte delle future richieste per non incorrere nella trappola di cui sopra. Quindi, quello che pu=C3=B2 essere un utilizzo del linguaggio minimale, non soddisfa le richieste commerciali in cui uno sviluppatore DEVE essere a buona conoscenza dello strumento che utilizza, anche per non fare brutte figure. Non =C3=A8 la prima volta che dietro all'impossibilit=C3=A0 di un tecnico, u= n collega pi=C3=B9 competente scorga la via d'uscita.

Se devo usare VisualStudio al 10% corro solo il rischio di risultare non professionale perch=C3=A9 esistono programmatori che, usando SOLO quello, lo padroneggiano al 99% e rappresentano irrefutabilmente i giudici verso il mio operato. Meglio usare ambienti pi=C3=B9 piccoli in cui, spendendo le stesse energie, ottengo una buona padronanza.

Tutto ci=C3=B2 accade anche con l'hardware, ed =C3=A8 molto peggio. Garantisco.

Io ho iniziato con il basic della Commodore (con il VIC 20) e a piccoli passi (ma proprio piccoli) sono arrivato a VS 2008 C++ col framework .NET. Se avessi fatto il salto diretto dal basic del VIC 20 al C++ di VS 2008 avrei subito un shock da infarto! :-) Facendo le cose per gradi, non ho trovato intoppi col .NET, sebbene sia un bel po' "strano" quando lo vedi per la prima volta.

Come dicevo, la cosa veramente eccezionale, a mio avviso, è l'ambiente di sviluppo. La gestione del codice è molto efficiente (anche se avrei curato meglio i segnalibri), aspetto da non sottovalutare quando devi muoverti tra migliaia di righe di programma.

Cristiano

Sono in parte d'accordo, ma un ambiente "intrecciato" come l'EMACS dei primi anni '90 è "difficile" in sé; un ambiente come VS 2008 o 2005 è "semplice" in sé; è talmente configurabile e intuitivo che allo sviluppatore non è richiesta una particolare abilità per sfruttarlo al 100% (a parer mio).

Purtroppo ne so qualcosa. :-(

Non riesco a cogliere come sia possibile che un ambiente ben fatto come VS non possa essere sfruttato al 100%. VC6 aveva un ambiente di sviluppo veramente "sacrificato", per quanto uno lo sfruttasse al 100% (o quasi) non aveva mai l'efficienza che serviva (per non parlare dei numerosi bachi del compilatore).

Cristiano

ne

mi

plice"

=E8

lo

on

La difficolt=E0 che maggiormente si incontra sta nell'aver presente la marea di classi, oggetti, library che .NET ti mette a disposizione per poterne farne uso nel migliore dei modi.

A livello di sviluppi hardware, chiunque abbia esperienza pu=F2 confermare che nel 90% dei casi =E8 sufficientemente padroneggiare la legge di Ohm, Kirchhoff e poche altre cose per risolvere i circuiti. A livello di programmazione, =E8 sufficiente, ma essenziale, essere buoni risolutori di diagrammi di flusso.

La vera difficolt=E0 sta nel conoscere la componentistica disponibile sul mercato, i prezzi, la disponibilit=E0 commerciale, reperibilit=E0, fornitori (almeno 3), affidabilit=E0 reale, sostituibilit=E0, ecc. ecc. Questa seconda parte occupa il 95% delle risorse umane e teoricamente non appartiene alla teoria dei circuiti. Non parliamo poi delle implementazioni per ambienti IDE nuovi od aggiornati e la manutenzione dei PC che stravolgono qualsiasi programmazione di produzione. Poi, una volta in produzione, devi fare i conti con la formazione del personale che non ha nessuna intenzione di capire come collaudare il prodotto delle tue fatiche. Domanda tipica al telefono: "ma 'sto coso come lo provo?" Alcuni clienti non avevano neanche la e-mail a fronte di nomi di ditte altisonanti di alta tecnologia. Mah!

Anche le morose ostacolano la scienza. Einstein sosteneva che un ricercatore dopo i 25 anni non era in grado di produrre pi=F9 nulla di veramente creativo. A quei tempi, gli uomini si sposavano a 25 anni. :-(

Il 12 Mag 2008, 01:07, "triller" ha scritto:

Se cerchi la rapidità del ciclo di sviluppo e la leggibilità del basic, senza doverti sciroppare un framework pachidermico come .NET, prova a valutare:

Altrimenti dai un'occhiata a python o, meglio ancora, buttati su GCC e wxWidgets: non avrai bisogno di nient'altro. :)

Ciao.

-------------------------------- Inviato via

Il giorno Mon, 12 May 2008 11:55:08 +0200, "Cristiano" ha scritto:

Dipende sempre da cosa ci fai, e se lo fai per professione i tempi impiegati a capire come ha agito l'UCAS(*) nel modificare una funzione da VB a VB.net diventano importanti.

Un programma composto da migliaia di linee di codice in un blocco solo è sempre da evitare, sia esso scritto in Assembler, in C o in qualunque altro linguaggio.

E' sempre meglio suddividere in diversi files il programma e trovarsi a lavorare in un singolo blocco o modulo di qualche decina di righe, questo richiede un pò di operazioni in più all'inizio ma ti facilita il debug e la manutenzione successiva..

ciao Stefano

(*) Ufficio Complicazione Affari Semplici, che per la creazione di .net è stato oberato di lavoro :-)

SB ha scritto:

Lati positivi? DotNet è una piattaforma che voleva copiare il successo di Java ( che personalmente non mi piace ). Intrdocuendo la sua portabilità e la sua sterminata libreria. Peccato che un programma .NET sia pesante. Per non parlare della macchina virtuale... Io me ne starei più lontano possibile...

Ma forse visto che non amo Java ( e quindi neache la sua brutta copia ) non faccio molto testo...

Il giorno Mon, 12 May 2008 13:44:06 +0200, Il Razziatore ha scritto:

Questo è vero, la M$ ha avuto paura di java.

Se devi sviluppare qualcosa per il web .net ha parecchie agevolazioni, magari rispetto a VB6 e ai controlli tipo Inet pieno di bachi. Poi sul fatto che sia pesante, credo che per quelli che vogliono spingerti a cambiare pc e so questo non sia un problema, anzi...

-- ciao Stefano

A me invece piace Java, soprattutto perch=E9 =E8 molto portabile, caratteristica che per me =E8 fondamentale da un po' di tempo a questa parte. In questo modo, non sono legato ad un particolare ambiente di sviluppo, n=E9 ad un sistema operativo. Comunque, =E8 anche qui questione di gusti. Sarebbe utile che l'OP ci chiarisse cosa vuole fare con il linguaggio in questione, la richiesta =E8 un po' generica (e si =E8 divagato un po').

Il 12 Mag 2008, 13:44, Il Razziatore ha scritto: [...]

La brutta copia di Java (.NET) è frutto dei progettisti SUN che hanno scritto Java da zero e poi sono stati ammaliati dai dollaroni sonanti di Bill per fare una copia estesa della loro creatura originaria, assecondando il più classico schema della fuga di cervelli. (Almeno stando alla leggenda metropolitana che circola in ambito informatico. :)

Che ci piaccia o no, con il progressivo abbassamento del costo del silicio, la tendenza è quella di scrivere il codice mezza volta e portarlo su qualsiasi piattaforma. Se non è abbastanza performante, non si riscrive mica. Nooo, si compra hardware più potente, si aggiungono altri cluster, si aumenta la memoria, si upgradano i processori...

Questi odiosi framework/VM hanno decretato (in ambito TLC e PA) il disuso di linguaggi come il C e ostacolato la diffusione del C++, in luogo di Java e C#.

Per fortuna possiamo avere l'hobby dell'elettronica digitale. :D

-------------------------------- Inviato via

Darwin ha scritto:

Più potatile di un programma scritto in C, il compilatore Java e la JVM lo sai in che linguaggio sono scritti?

-- Il Razziatore, "Lo sviluppo di una nazione si misura anche dallo stato della sua rete ferroviaria". Camillo Benso Conte di Cavour "Per tutto quanto non previsto nel presente regolamento il capostazione deve usare senno e ponderatezza." Regolamento d'esercizio FS

----------------------------------------------- MSN : snipped-for-privacy@netscape.net ICQ : 67552596 Yhaoo : Razziatore82

----------------------------------------------- Founder of MediaPlayer Project

Matricola ha scritto:

Se permetti io come essere sensiente e come programmatore mi oppogno a questa politica ostacolando al più non posso linguaggi come il Java, dove bisogna installare 300 JVM se no non ti funziona niente. Io ho in JDK della versione 1.5 pero' ho dovuto installare anche il JRE ( che già è compreso nel JDK ) perché se no i programmi non se ne accorgono. E guai ad avere il JRE 1.6.3 se il programma vuole 1.6.0 semplicemente non parte ( mi succede tutti gli anni con unico... ) e se installi la sua versione magari non ti funziona più OpenOffice ( mi è successo anche questo... )... che poi le JRE non è che siano leggere...

Si proprio una bella portabilità del software...

Ma certo! Uso il C da vent'anni, apprezzandolo. Ci=F2 non toglie che per applicazioni in cui le risorse di calcolo non sono un problema, Java mi ha effettivamente risolto alcuni problemi di portabilit=E0.