per l'elettronica quale linguaggio e' da preferire?

Il 12 Mag 2008, 15:02, Il Razziatore ha scritto: [...]

Non ho detto che mi piace la tendenza, ma non posso fare a meno di notare che è LA tendenza.

Il problema dei software scritti male, con riferimenti ad implementazioni di una data release, e il ricorso a metodi/oggetti dichiarati deprecated non può dipendere dall'utente finale. Come utente finale, dal mio canto, posso solo aiutare mio padre, che utilizza i software ufficiali scaricati dal sito del ministero delle finanze, scritti in Java (piuttosto con i piedi), e posso soltanto fare dei piccoli batch che lanciano i JAR puntando ai binari della versione JRE che il software pretende per poter funzionare, settando in un dato processo batch anche le variabili ambiente che il JRE vuole conoscere per fare il suo lavoro. E' una porcata, ma almeno funziona. :) Per non parlare degli aggiornamenti (poco) automatici di XP, che non riescono a conciliarsi tra versioni differenti di .NET, piantando TUTTI gli aggiornamenti (poco) automatici del pc in questione...

Beninteso, preferisco spaccare il bit e scrivere un programmillo per un micro, piuttosto che aprire, in ufficio, uno dei nostri colossali progetti Java ed impazzire con infiniti livelli di gerarchie di oggetti... :) Sai, qui abbiamo i "Technical Architects"... :-|

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

Matricola ha scritto:

Si lo so che la tendenza c'è. Come c'è la tendenza dell'università ( sopratutto la mia ) a dire Java è bello. Sai programmare in Java allora si che sei Cool... In pratica hanno reso la mia laurea Ingeneria Informatica ( scritto con le due I maiuscole ) in un corso della regione ( scritto con la C e la R minuscole ). Io più sto la dentro è più mi deprimo. Non sai quante cose mi passano davanti agli occhi. A me Java non piaceva prima di entrare li dentro, ti lascio imaginare ora che vedo gente che non sa un H di informatica che si crede il padre eterno perché riesce a fare

miopippo = new Pippo( );

e se gli domandi "cos'è Pippo? cosa c'è dentro?" vanno nel pallone ( prof compresi... ) e ti iniziano a dire "mah dovrebbe essere un freamework a... sai al CMS che impacchetta a sua volta..." insomma inizia ad arrampicarsi sugli specchi cercando di ricordarsi come erano messe le scatole nere una dentro all'altra per poi concludere " insomma fa questo tu basta che lo istanzi"... e lui è un Programmatore? anzi no peggio lui è un Ingenere Informatico?

Una mia amica, a cui voglio molto bene, ogni volta mi fa cadere le braccia. Si è laurata ed è andato tutto bene ma non capisce un H di informatica ( come piffero ha fatto a laureasi in Ingeneria allora? ) voleva provare Linux, ha messo una macchina virtuale e ha selezionato l'imagine del DVD ma non gli partiva io gli ho detto

"Hai modificato il bios in modo che parte da CD?"

e lei "Ah no!" e scompare da msn dopo un po' ricompare e mi dice "no niente non funziona"... hai capito cosa aveva fatto e coma mai non funzionava? Quando mi fa ste cose non so se piangere o ridere...

Il problema del software scritto male e che c'è in giro troppa gente presa dalle aziende che non sanno un tubo di quello che stanno facendo. Li prendono dalla strada gli fanno un corso di un piao di ore e gli cuciono addosso la giacca di "programmatori"... ma per piacere programmatori è un altra cosa. Pero' è questa la tendenza, e tutto questo lo dobbiamo a Java...

Me too, me too...

Io sono allergico. Non mi piace proprio. Forse perché ho sempre avuto PC abbastanza "piccoli" ( giravo ancora con il 486 quando in giro c'erano i primi Pentium III ) ma sta di fatto che ho sempre preferito indipendentente dalla macchina fare la cosa più tranquilla possibile, e Java non mi pare "tranquillo"...

Anche perché sono un po' allergico alle librerie, che è il punto di forza di Java, sono un tipo che se ha un problema gli piace risolverselo da solo non cercare nella documentazione se esiste un oggetto URL che fa tutto quello che potresti chiedere a un URL e anche di più...

Lo trovo un po' essagerato qualche volta...

Guarda, concordo abbastanza con qualcuno dei tuoi argomenti. Tuttavia, secondo me, il problema non =E8 di Java medesimo, che =E8 un linguaggio con i suoi bravi vantaggi e svantaggi, ma pi=F9 di molte persone che lo usano senza avere troppo chiaro che meccanismi ci sono dietro ad ogni operazione. Quello che secondo me nuoce abbastanza a Java =E8 la pubblicit=E0 che se ne fa come un linguaggio "semplice", mentre non lo =E8 affatto. Seppure certi automatismi (come la garbage collection) possano semplificare la vita, non esimono il programmatore dal conoscere bene cosa viene effettuato in maniera automatica. Alla stessa maniera, certi modi di funzionare possono nascondere brutte pratiche di programmazione in codice apparentemente innocuo.

Riguardo all'uso delle librerie, bisogna riconoscere che certe cose sono piuttosto comode, ma, anche l=EC, non sono un sostituto alla perizia del programmatore, come molti amerebbero.

(E poi, lavorare a basso livello ha il suo fascino, non lo nego. Tuttavia, dopo un po', uno ha capito l'antifona e si stufa di star a scrivere blocchi di assembly che verrebbero risolti in maniera elegante da una sola linea in un linguaggio ad alto livello. Parlo per esperienza, dal 6502 al PIC, passando per il 68HC11 e il 8086, con una sprizzatina di 68k.)

Darwin ha scritto:

Diciamo che è anche per questo che non mi piace. Per la sua fama di linguaggio semplice, del fatto che prendi un qualunque tipo che passa per la strada gli fai fare 3 ore di corso e lo metti a fare programmi scadenti ma funzionano. Sia ben inteso lo si puo' fare anche in C ( anche perché diciamolo la sintassi del C forse è addirittura più semplice di quella del Java non essendoci tutta la parte del OOP ). Diciamo che vederlo così maltrattato non me l'ha fatto di certo diventare più simpatico. Poi avevo delle antipatie mie personali ( nate dalla sua lentezza e pesantezza ) e il "guaio" era fatto. Se poi ci metti pure che sono contrario ad alcune scelte progettuali che si è optato di fare...

Il problema e che invece molti vedono Java come una scatola magica che non importa cosa c'è dietro. Basta conoscere l'interfaccia...

Un professore della mia univeristà ad un mio amico ( hardwarista sfegatato... il contrario di me lui mastica molto elettronica e poca informatica ) ha detto in un corso di Analisi e Progrettazione del Software "Lei programma in c?" il mio amico allora sbigottito "Sì, perché non mi dica che qui facciamo solo le cose in Java" e lui "certo qui ci DIVERTIAMO". Che centra il divertimento con il Java? Era un corso sulla progettazione non si poteva fare in C? Stesso corso stesso professore

"non voglio vedere cicli for, utilizate Iterator" un studente allora si alza e dice "ma internamente intanto non c'è sempre un for?" e il professore "beh allora possiamo andare a programmare in assembler..."

Secondo me il male di Java non è tanto Java in se ( al quale sono contrario ) ma al fatto che usandolo molta gente ( tipo i miei prof ) spengono il cervello...

Io preferisco farmela da me la libreria, magari portarmela da progetto a progetto e migliorandola. Poi magari guardo in giro se c'è qualcosa "di meglio". Ma prima afronto il problema di petto non vado subito a vedere se c'è già una scatola nera da collegare alla mia e magari in mezzo ci metto un'altra scatola che li faccia comunicare...

Non dico questo sarebbe anacronistico. Scrivere oggi in assembler non ha praticasmente più senso. Pero' il C secondo me ofre un buon compromesso è un linguaggio ad alto linguaggio che pero' strizza l'occhio al basso livello. Che se poi vuoi apri una parentesi ASM e ti si apre un mondo.

Il Razziatore ha scritto:

Dipende. Di sicuro se usi il C avrai la possibilità di condividere alcune parti di codice (di solito protocolli), ma niente di più.

Scrivere un'applicazione con GUI in C/C++ è poco produttivo al giorno d'oggi. Se usi un linguaggio come Python hai grandi vantaggi in termini di velocità di sviluppo, manutenibilità e portabilità al solo prezzo di dover reimplementare eventuali protocolli di comunicazione.

Ciao

Francesco Sacchi ha scritto:

Io parlavo di consocenza del linguaggio. Se usi il C devi conoscere solo il C... era a questo che mi rifervo.

Non sono daccordo su questo. Esistono un sacco di toolkit che sono molto easy-to-use... scrivere un programma ( ed esempio ) con le Qt è molto semplice. Per non parlare dei vari programmi scritti con le GTK...

Non sono molto fan del Python :) ma sono gusti personali :) che poi per come sono fatto mi piace giocherellare con le API di windows e/o linux, ma capisco che non è il massimo ma mettendo qualcosa come GTK o Qt già si fa molto.

Il Razziatore ha scritto:

Ah, capito. Comunque se conosci solo il C un'applicativo GUI lo scrivi male, devi come minimo imparare il C++, e allora tanto vale imparare qualcosa di più produttivo :-)

Sì, hai ragione, i toolkit grafici danno molto aiuto in questi termini, ma pensa che per esempio esistono i binding di Qt anche per altri linguaggi oltre il C++: PyQt, Java Qt (jambi?), PerlQt, QtRuby... Quindi puoi unire il meglio dei 2 mondi: linguaggio produttivo + toolkit grafico figo!

Sì, è vero si fa molto, ma usando un linguaggio più moderno le cose migliorano ulteriormente. Se non hai bisogno di performance credo che ormai non valga più la pena usare il C++ (il .NET ne è la prova). E anche se ne hai bisogno, io penso che ormai si faccia molto prima a profilare e a ottimizzare le sole parti critiche che non a usare il C++ per tutto.

Per esempio il Python (CPython per essere precisi) permette di integrare abbastanza facilmente parti di codice scritte in C, che possono essere utilizzate per i punti critici. Meglio di così :-)

Ciao

Francesco Sacchi ha scritto:

Apparte che molti toolkit sono scritti in C ( e non in C++ ). GTK+ è scritto in C ad esempio... Qt è C++ ma c'è un interfaccia verso il C. Comunque è questione di gusti, io il C/C++ non lo trovo affatto poco produttivo.

Secondo me quei linguaggi che hai menzionati non sono affatto più produttivi del C++... solo solo più "Trendy" del c++ ma questo è un altro discorso.

Che poi volendo essere onesti... chi ha detto che ci deve essere l'interfaccia grafica? Per mandare 2 byte va benissimo un programma scritto in cosole stile anni 80... Un mio amico ha realizato una scheda con DSPIC, con modulo USB esterno parta attraverso USB con il suo "coccio" tramite un programma scritto il C e senza interfaccia grafica...

.NET lascialo perdere... secondo me non ci sono reali vantaggi ad usare altri linguaggi... poi, sicuramente, molto è dettato dal gusto personale...

Il problema non è il linguaggio... ma come esso viene utiliziato. Non basta aprire una parentesi e scrivere in C per avere il C... bisogna avere il compilatore C, non conosco CPython ma credo che sia sempre interpretato e quindi...

Il Razziatore ha scritto:

Si può fare tutto, anche scrivere in assembly, ma lo definiresti produttivo? Io no. Ecco il C/C++ sta lentamente diventando il corrispondente dell'assembly per i linguaggio moderni.

Non è più necessario preoccuparsi di allocare la memoria, i tipi di dati base sono più di alto livello, le librerie standard contengono ogni cosa.

Sì, è un altro discorso, comunque per la mia esperienza e per quello che vedo nel mondo della programmazione io penso sia così. I linguaggi moderni sono trendy proprio perché piacciano, e piacciono perché permettono di lavorare con meno grattacapi e più efficacemente.

Esattamente. Ma proprio perché la maggior parte delle volte devo fare solo degli scriptini stupidi da shell per collaudo e test posso permettermi di usare linguaggi che mi fanno risparmiare tempo a discapito delle prestazioni. Io mi faccio gli script di test in Python, ma anche la bash, il Perl o perfino il C# vanno molto bene per questo.

Non lo conosci, ed infatti non è così. CPython è l'interprete Python più diffuso ed è scritto in C. E' possibile includere sia pezzi di codice C che linkare dll. Sebbene sia vero che il linguaggio venga interpretato, le parti in C vengono compilate prima e sono quindi eseguite nativamente alla velocità che avrebbe il normale codice C. Il C sta al Python proprio come l'assembly sta al C. E credo che questo sarà sempre più vero in futuro.

Ciao

Francesco Sacchi ha scritto:

Non esageriamo per favore! Un contro è scrivere in assembler un conto è scrivere in C... nessuno scriverebbe oggi un compilatore in Asm... ma tutti li scrivono in C ci sarà pure un motivo. Gli OS sono scritti prevalemente in C ( ne esistono anche in Java ma è un altro discorso ). Anche i videogiochi sono scritti in C(++)... Esistono un sacco di reatà dove il C(++) è il linguaggio principe. Si puo' fare tutto in Java ma i risultati, IMHO, lasciano il tempo che trovano.

Il C è un linguaggio ad alto livello, il fatto che tutto il resto si stratifica sempre di più ( macchine virtuali, interpreti ecc ecc ) non fa C meno di alto livello, è solo un modo diverso di interpretare le cose. E io sinceramente preferisco il mondo classico.

Esistono libereie standard anche per il C++ e anche quelle non è che siano "poche". Se poi cerchi su internet trovi anche quella per fare i frullati ( vedi GTK+/Qt/ecc ). Diciamo il Java ( e compagni ) hanno il vantaggio di avere un SDK di centinaia di MB contenente tutto l'universo, ma siamo sicuri che questo poi sia un bene? Per me i programmi devo essere il più piccoli possibili e non devono essere legati a 200/300 MB di librerie di cui ne uso solo il 10% preferisco installarmi da me le DLL che uso ma che le uso seriamente...

Oppure perché sono "facili" da usare e i programmatori che li usano sono mediocri ma con 5 ore di corso imparano a fare programmi mediocri? Il time to market si è abbassato... ma di nuovo... è un bene?

Un attimo uno scriptino è un'altra cosa. Anche il mio PC è pieno di script che fanno di tutto e anche di più. Ma una cosa è uno script che magari deve girare solo quando accendo il PC o magari quando voglio fare alcune cose. Solo liste ( più o meno complesse ) di instruzioni che do a mano.

Un applicativo è un altra cosa. Bash lo conosco poco e di questo mi dispiace, ma questo non toglie che se devo fare un interfaccia per il mio "hardware" vado in C e mi scrivo un programma, più o meno compesso.

Dipende molto dal target...

Il che va a mio vantaggio :P

A dire il vero non ho trovato ( ho cercato ) notizie della cosa, ho trovato invece notizie del fatto che il Python sia compilato in un speudo linguaggio macchina ( tipo il .NET il Java ecc ) quindi magari esiste un BYTECODE per dire "Da qui in po' è OPCODE" ma comunque non è che la cosa mi esaliti molto...

Opinioni di vista. Comunque il Python ( come il Java del resto ) non mi piacciono proprio sintatticamente visto che sono linguaggio esclusivamente ad oggetti. Per me creare un oggetto per tutto non è poi una cosa così bella, esistono delle cose che modellarle come oggetti non è che viene poi così bene. ( Vedi l'oggetto Math in Java... è un oggetto? Ma fammi il favore un oggetto con tutti metodi statici e senza metodi è tutto fuor che un oggetto... )

Stiamo andando OT, spero che il NG mi perdoni un'ultima risposta. Al limite continuiamo in privato :-)

Il Razziatore ha scritto:

Qui ti sbagli. I compilatori scritti in C solo quelli iniziati qualche anno fa. Adesso si comincia ad usare altri linguaggi anche per quelli (vedi dopo).

Gli OS sono scritti

Questo è vero, ma la programmazione di sistema è uno dei pochi casi speciali in cui le performance contano davvero, e ti dirò di più, in alcune parti serve ancora l'assembly.

Anche qui ti sbagli, la nostra azienda stessa ha collaborato ad un videogioco con alcune parti scritte, indovina un po', in Python. Solo le parti del che necessitavano di performance erano in C++.

Esistono un sacco di reatà

Sono d'accordo, ma questa tendenza aumenterà sempre più. Potrai scrivere tutto in Java e avere le parti che necessitano di performance scritte in C/C++.

Bhe, in tutta onestà e senza nessuna offesa mi sembri come quelli che qualche anno fa volevano scrivere applicazioni per PC in assembly dicendo che si ha più controllo. Il C è di alto livello, ma è lo stesso troppo vicino alla macchina e ti obbliga ad occuparti in prima persona di compiti che ti distraggono dal problema a cui stai lavorando. Infatti i linguaggi di nuova generazione vengono chiamati di altissimo livello (VHLL). Io penso che sia la normale evoluzione delle cose. Più passa il tempo e più i linguaggi si avvicinano all'uomo e si allontanano dalla macchina. E non credo sia un male.

Lasciamo perdere, in C se hai il confronto tra stringhe è già tanto. In C++ con l'STL è un passo avanti, ma non è nulla in confronto alla libreria standard fornita da .net, java o python.

Se poi cerchi su internet trovi anche quella per fare i

Java infatti è rinomato per la sua pesantezza. .net ha il suo framework che però di fatto è integrato con il SO. Python ha il suo interprete ma è completamente diverso dall'approccio java, dagli un'occhiata, ti ricrederai :-)

I linguaggi

I programmatori mediocri sono sempre esistiti. Adesso faranno programmi mediocri in minor tempo. Ciò non toglie che anche i bravi programmatori faranno programmi buoni in minor tempo. E questo penso sia proprio un bene.

Parlo di applicativi più o meno complessi che vengono usati in fase di test e collaudo. Uno di essi, sviluppato insieme ad un collega, ci server per testare un protocollo di comunicazione con una macchina che muove diversi assi, inviando i vari comandi. E' scritto in python, funziona da shell (sia su linux che su win) ed è piuttosto complesso. Perché devo metterci il doppio a scriverlo in C quando in python (o altro linguaggio moderno a scelta) otteniamo anche la portabilità tra OS gratis?

Eheh ma in realtà esiste anche Jython (scritto in java), IronPython (scritto per .net) e PyPy (un interprete python scritto in ...python!). CPython è il più famoso perchè è il primo, ma anche gli altri non vanno male.

Il python, essendo interpretato, ha un suo bytecode e una sua macchina virtuale. Ma ti assicuro che è tranquillamente possibile eseguire codice C nativo, preventivamente compilato (che quindi è codice macchina). Alcuni riferimenti, in ordine casuale:

Certamente :-)

Comunque il Python ( come il Java del resto ) non mi

Non è vero, python è multiparadigma, puoi anche usare la semplice programmazione procedurale, o la funzionale (tipo lisp) o il paradigma a oggetti.

Dagli un'occhiata, ti ricrederai :-)

Ciao