di  -  venerdì 19 ottobre 2012

Anders Hejlsberg è l’uomo che ha realizzato i linguaggi (e i framework) con cui tutti i programmatori si sono quasi sicuramente confrontati durante il loro percorso professionale.

 

Anders Hejlsberg

Durante gli studi universitari presso la Technical University of Denmark (1980, Lyngby), realizza  alcuni programmi per i microcomputer Nascom tra cui uno specifico compilatore Pascal, commercializzato come Blue Label Software Pascal (BLS Pascal per il Nascom-2). Il passo successivo è il porting del compilatore sui sistemi operativi CP/M e DOS, con il nome iniziale di Compas Pascal divenuto poi PolyPascal, in seno alla PolyData.

Proprio grazie al Compas Pascal, Hejlsberg entra in contatto con Borland, che prende in licenza il compilatore al fine di integrarlo nel nascente IDE Turbo Pascal e stringe un accordo con il suo creatore per apportare le necessarie modifiche. Ma qui sorge un problema: Hejlsberg è in Danimarca mentre Borland in California (Scott’s Valley). Così la società guidata da Kahn invia al giovane programmatore un “velocissimo” modem a 9.600-baud in modo da poter condividere gli sviluppi con il team Borland, tipicamente inviando le modifiche negli orari notturni statunitensi.

Il risultato di tale lavoro è la prima versione del Turbo Pascal, un IDE rivoluzionario per il 1983 (rilasciato ufficiale il 20 novembre) che apre la strada verso un nuovo modo di fare sviluppo, grazie ad un prezzo pari a 1/10 (49,95$) di quello dei concorrenti e un compilatore velocissimo, merito proprio dell’ottima programmazione in assembly di Hejlsberg.

Una curiosità: per promuovere il proprio Turbo Pascal, Borland pubblica su Dr. Dobb’s Journal of Software una striscia di fumetti chiamata “Le Avventure di TurboMan”, il supereroe dei programmatori.

The Adventures of TurboMan

Borland viene così proiettata nell’olimpo delle Software House e Hejlsberg (nel 1989) si trasferisce in California per seguire direttamente lo sviluppo del Turbo Pascal, anche in seguito ai problemi finanziari della sua PolyData.  Assunto il ruolo di Chief Engineer di Borland, si concentra unicamente sullo sviluppo del Turbo Pascal fino alla sua più discussa versione: la 5.5, dotata del supporto alla programmazione Object Oriented (OO).

Turbo Pascal 5.5

Per abbracciare il nuovo paradigma OO, però, il (Turbo) Pascal richiede una profonda revisione Anders pianifica la realizzazione dell’Object Pascal (partendo dallo specifico Draft Apple sull’argomento), alias Delphi. I tecnico danese assume il ruolo di Chief Architect del nuovo progetto insieme a Chuck Jazdzewsk­.

Oltre alla nuova filosofia Object Oriented, il Delphi si pone come strumento di sviluppo cooperativo, superando l’idea che lo sviluppo del software potesse essere affidato ad un’unica persona, così come affermato dallo stesso Hejlsberg:

“Back in the old Turbo Pascal days, it was possible for one person to write and maintain an entire product. This is no longer the case. Delphi was built by a team.”

[A tempi del Turbo Pascal era possibile per una persona scrivere e manutenere un intero prodotto. Ora non è più così. Delphi stesso è stato realizzato da un Team]

Nel 1996 Hejlsberg è pronto per una nuova sfida: assumere il ruolo di Chief Architect in Microsoft relativamente allo sviluppo di Visual J++ e delle librerie Windows Foundation Classes (alias WCF), pensate, inizialmente,  per la creazioni di GUI professionali per Windows sfruttando il linguaggio Java. J++ comunque non abbraccia in pieno le specifiche SUN, scatenando una causa legale con Microsoft che porterà all’abbandono ufficiale del linguaggio. Parte del Core di J++ verrà utilizzato per realizzare J#, un linguaggio CLR Based con una sintassi java-like, oggi non più supportato da Redmond.

Nel frattempo arriva però la madre di tutte le sfide: realizzare la nuova infrastruttura Next Generation Windows Services (NGWS), che dovrà servire come base per lo sviluppo delle future applicazioni di Rete. Il nuovo ambiente si differenzia fortemente dal precedente Windows DNA, utilizzando XML come formato standard di comunicazione ed interscambio dei dati. Il progetto prosegue con forza e nel 2000 comincia ad assumere la nomenclatura ufficiale di .Net Framework.

Le prime versioni preliminari di NGWS sono scritte nel linguaggio Simple Managed C (SMC), ma Hejlsberg non è soddisfatto e mette insieme un Team per lo sviluppo di un nuovo linguaggio: Cool, ovvero “C like Object Oriented Language”.

Il nome Cool piace anche alla divisione Marketing che, inizialmente pensa di mantenerlo, ma successivamente, per ragioni di copyright, decide di depennarlo in favore di C#. Chiaramente il nuovo linguaggio è fortemente influenzato dall’esperienza maturata da  Hejlsberg durante lo sviluppo di Delphi e oggi è uno dei linguaggi più utilizzati e apprezzati, unitamente al framework dotNet e all’ultima creatura (in ordine temporale) di Hejlsberg; il Language Integrated Query (LINQ).

Nel 2001 Hejlsberg riceve il Dr. Dobb’s Excellence in Programming Award, per il suo fondamentale contributo per il Turbo Pascal, Delphi, C# e .Net. Inoltre gli è stato conferito il Recognition Award for Outstanding Technical Achievement per il suo contributo al linguaggio C#, unitamente a Scott Wiltamuth, Shon Katzenberger, Todd Proebsting, Peter Sollich, Erik Meijer e Peter Hallam.

35 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Massimo M
     scrive: 

    Ma solo a me .NET, C# (e soprattutto VB) mi stanno ampiamente antipatici tanto da voler cambiare mestiere?
    Essendo un firmwarista resto legato (e continuo ad usare) in ambiente Windows C++ Builder, che da Borland è passato a Embarcadero che oggi propone una soluzionecross platform molto originale.
    Spero si parlerà in futuro su queste pagine anche dell’ottimo Borland C++ 3.1

  • # 2
    Paolo Russo
     scrive: 

    Io invece adoro il C# per la velocità di scrittura codice, la facilità incredibile di debugging, la pulizia in generale del codice C#, la velocità con cui scrivo appliazione OpenGL(sharpGL) e in generale applicazioni con GUI. Lo utilizzo come linguaggio di prototipazione al posto di utilizzare Matlab! Quando ho bisogno di qualcosa di performante al 100% traduco poi il programma in C++. Non è assolutamente un linguaggio relegato al solo sviluppo web ;)

  • # 3
    CodeVisio
     scrive: 

    @Massimo,

    non sei il solo. Anzi se hai un lavoro contattami pure.

    Per quella che è la mia esperienza il C# e il .NET Framework sono solo delle operazioni commerciali (un incrocio mal riuscito del VB e del java, un’accozzaglia di idee differenti messe assieme, spacciate per chissà che rivoluzione). L’ennesimo cambio di apparenze fatto da Microsoft per vendere e obbligare i professionisti a imparare la stessa solfa rimescolata per l’ennesima volta e gli user ad acquistare nuovi prodotti. Invece di ascolatare le esigenze dei professionisti che creano prodotti per il loro OS si lasciano trasportare dalle menate di qualcuno che s’è svegliato storto la mattina.
    Non mi si venga a dire che il C# o il framework .NEt sono un passo avanti della scienza.

    @Felice,
    grazie per l’articolo storico!

  • # 4
    Vinx
     scrive: 

    Durante vita son venuto a contatto con diverse decine di linguaggi e ad oggi posso affermare che C# è un ottimo linguaggio per espressività, pulizia, velocità di scrittura e soprattutto per l’estrema possibilità di debug all’interno di UNO degli IDE meglio fatti dai tempi del turbo-pascal. VisualBasic l’ho sempre odiato e anche se ora è molto più C#-like come funzionalità, continuo ad odiarlo. Magari per scrivere firmware, c e c++ restano più adatti.
    Comunque nessuno è perfetto e C# non fa certo eccezione. Per alcune cose ha ancora da imparare da Java.

  • # 5
    Cesare Di Mauro
     scrive: 

    Non vedo cosa ci sia da imparare da Java. Al limite potrebbe essere il contrario. ;)

    C# l’ho apprezzato, e l’impronta Delphiana è evidente (adoro ancora questo splendido linguaggio).
    Mi spiace molto che non abbia seguito di più Delphi in alcune scelte, come ad esempio il cambio di “visibilità attuale” degli identificatori, anziché usare l’approccio Java-like di ripetere ossessivamente la visibilità per ogni dichiarazione.

    Avrei anche esteso il meccanismo di Delphi (che poi viene dal Pascal, filosoficamente parlando: le keyword type e var denotano l’inizio di una tipologia di identificatori) ad altro, come ad esempio ai membri static, e avrei fatto lo stesso con le property.

    Il linguaggio sarebbe risultato molto, molto meno verboso. Peccato. Un’occasione persa.

    Felice, perché dici che la versione 5.5 di Turbo Pascal fu controversa? Inizialmente mi lasciò perplesso, ma poi leggendo quel meraviglioso manuale di Borland che introduceva alla programmazione a oggetti (fu considerato all’epoca la migliore introduzione alla OOP), mi si aprì un mondo nuovo…

  • # 6
    CodeVisio
     scrive: 

    @Cesare Di Mauro, domanda fuori tema.

    Ma non eri te quello che sosteneva che i monitor 16:9 erano i meno indicati per gli IDE ?

    thanks

  • # 7
    Cesare Di Mauro
     scrive: 

    Non mi pare. Sono, anzi, a favore, perché generalmente gli IDE hanno dei pannelli che occupano spazio a sinistra e a destra, mangiandosi spazio utile per visualizzare il codice (il cui sviluppo è orizzontale).

  • # 8
    gennaro tangari
     scrive: 

    Ho apprezzato il Turbo Pascal prima (5.5 e 6.0) e C#/.NET dopo.

  • # 9
    CodeVisio
     scrive: 

    @Cesare,
    infatti, sono d’accordo.

    Be’, allora devo aver male interpretato la tua risposta su programmazione tempo fa.

  • # 10
    Antonio Barba
     scrive: 

    Per quel poco che ho usato C# su Windows Phone, mi sono trovato subito a mio agio venendo da un background di C++ e Java.

    Di sicuro non è un linguaggio complesso, è molto espressivo e abbastanza sintetico rispetto al Java, pur rimanendo ben leggibile. Fin’ora non ho trovato particolari difetti, ma non ho ancora una conoscenza approfondita dell’argomento per potermi fare un’opinione completa.

    Una cosa è certa, a prescindere da C#, Visual Studio resta il miglior IDE su cui abbia avuto il piacere di lavorare (in C++), ha semplicemente tutto quello che un programmatore possa desiderare, ti semplifica la vita e la gestione di progetti di qualsiasi livello di complessità e dimensioni (ho lavorato su soluzioni con parecchi milioni di righe di C++, organizzati in 25 progetti, a loro volta composti da qualche decina di migliaia di classi).

    Con gli altri IDE che uso quotidianamente, Eclipse in particolare, nonostante la gran quantità di funzioni, non raggiungo lo stesso livello di produttività, complici anche i numerosi crash e bug.

  • # 11
    Valeriob
     scrive: 

    @CodeVisio

    Vorrei sapere quali sono le tue esperienze personali che ti portano ad affermare cose che personalmente reputo assurde.
    C# con vb non centra nulla e rispetto a Java è 10 anni avanti.

    Hai sparato tanto FUD non supportato da alcuna argomentazione, quando se ti guardassi attorno vedresti quanto quella c# sia una delle comunity in cui vi + più fermento negli ultimi 5 anni. Parlo di prodotti, di innovazione, di open source, di idee etc…

  • # 12
    Crick
     scrive: 

    Concordo con chi dice che Java insegue C# ora. VB non lo considero dato che, secondo me, è diventato un pastrocchio! Avrà quasi 200 keywords e tutto per adattare un linguaggio pensato per la semplicità e l’approccio diretto senza troppi fronzoli a tecnologie e costrutti moderni. L’idea originale di java era quella di non avere, rispetto al C++ (da cui prende spunto), problematiche interpretative sulle espressioni (è risaputo che con i template del c++ è possibile fare cose assurde o scrivere espressioni così contorte da risultare difficili da capire), ecc.
    C# ha preso molto spunto da java all’inizio ma l’ha ben presto superato, con l’aggiunta di tante comodità come le property, i foreach loop e poi le annotazioni che, ancora oggi, sono anni luce avanti a quelle di java – ci sono volute 6 revisioni per avere le enumerazioni, le assert ecc.
    E’ anche vero che molto passa per le JCP che impiegano molto tempo a raggiungere draft stabili e condivise.

    Cmq Delphi per sempre. Quanto mi sono divertito con delphi solo dio e la tastiera lo sanno!

    Saluti ragazzi!

  • # 13
    CodeVisio
     scrive: 

    @valeriob,

    penso di essermi perso qualche pezzo di evoluzione della lingua italiana. Prima di risponderti dovresti spiegarmi cosa significa
    “FUD”.

  • # 14
    Alpha
     scrive: 

    È vero, C# ha tantissimo da imparare da JAVA:

    http://www.slideshare.net/jeffz/why-java-sucks-and-c-rocks-final

  • # 15
    ufo.rob
     scrive: 

    @Massimo M
    Dici “Ma solo a me .NET, C# (e soprattutto VB) mi stanno ampiamente antipatici tanto da voler cambiare mestiere?”
    e poi “Essendo un firmwarista” ma allora forse il problema non è che a te non piace ma che non sei abituato alle applicazioni per cui C# risulta migliore o anche solo più comodo.

  • # 16
    Michele
     scrive: 

    Io di Java rispetto a C# apprezzo la presenza di framework (free e opensource) per fare qualunque cosa, in questo campo è C# (o .NET) che segue facendo il porting spesso a distanza di parecchio tempo, mi riferisco ai vari framework per ORM, MVC, Code Injection, ecc.

    Qualche tempo fa ho realizzato un’applicazione web con MVC 2 di Asp.net e non c’erano componenti elementari come campi di input con l’autocompletamento e il calendario, giusto per non scedere troppo in dettaglio. Poi alla fine le ultime versioni di MVC si sono appoggiate a jquery che non è di MS.

    La situazione è un po’ migliorata ultimamente ma di solito la scelta è più limitata come anche il supporto.

    Attualmente sto lavorando con un framework di Enterprise Integration Patterns (Camel, so che esiste anche per Spring) credo che l’equivalente sia BizTalk, ma non mi pare sia free.

    Per quello che riguarda il linguaggio, ci lavoro da dieci anni e mi sono sempre trovato bene.

  • # 17
    Cesare Di Mauro
     scrive: 

    Il fatto che ti trovi bene con Java nulla toglie alla situazione di questo linguaggio, che risulta ben descritta dalle slide del link postato nel commento #14.

    Non ho mai sviluppato su web né per Java né per .NET, quindi non mi posso esprimere in merito, ma conosco la situazione di Java e .NET riguardo alle GUI, e credo non ci sia proprio paragone (dai un’occhiata alle WPF, e confrontale con Swing: un altro universo).

    Infine, se trovi più librerie per Java che per .NET mi pare normale, vista l’anzianità del primo. Mi meraviglierei del contrario. Comunque per .NET si trova già parecchia roba, che non fa rimpiangere Java, e la situazione migliora sempre…
    In ogni caso questo non riguarda né il linguaggio di per sé né la libreria standard che si porta dietro. Cose per le quali .NET è messo molto meglio, ed è da parecchio ormai che Java cerca disperatamente di inseguire .NET/C#…

  • # 18
    Michele
     scrive: 

    Sì sulle GUI per le applicazioni client sono d’accordo ho sviluppato un programma per l’assessment delle capacità cognitive per anziani con WPF e Caliburn Micro e nonostante fosse il primo lavoro con WPF, sono rimasto soddisfatto, soprattutto per la possibilità di riutilizzare il codice.
    Cesare hai mai usato Caliburn Micro? Esiste qualcosa di simile? O preferisci lavorare solo con WPF senza niente nel mezzo?

    Per Java sto realizzando adesso un’applicazione client, ma non con SWING che è piuttosto datato ma con SWT, e non è male, ma forse il confronto andrebbe fatto con qualcosa di più recente tipo JavaFX che purtroppo non ho ancora avuto modo di provare.

    Il mio intervento era volto a riequilibrare la discussione, la scelta del linguaggio è legata anche al framework che lo accompagna e alle librerie disponibili, quindi sì, si potrebbe dire che il linguaggio C# è meglio di Java, ma se devo fare un’applicazione, nel mio caso per niente esotica, che richiede l’utilizzo di un framework che in .NET non esiste e quindi mi tocca spendere un sacco di risorse per realizzare quello che manca, un linguaggio migliore non mi basta.

    Tanto per fare un’altro esempio recente con “LINQ to SQL” fino a poco tempo fa non si potevano gestire automaticamente il caricamento delle tabelle in relazione, da cui la mia scelta di usare NHibernate che è un porting di Hibernate per Java.

    L’applicazione in questione serve ad importare dati di vendita di automobili vendite in alcune zone del mondo in un database centrale, ho con Java ho trovato questo questo framework:
    http://camel.apache.org/eip.html

    Un framework programmabile a componenti che con pochissime righe di codice mi permette di importare dati da fonti molto eterogenee. Tecnicamente poteva benissimo essere fatto in .NET però non c’è niente di simile.

    Poi secondo me non è solo una questione di tempo, Java esiste dal 1995, .NET dal 2002 quindi da dieci anni, che sono veramente tanti nell’informatica però dal punto di vista dei framework continuano ad esserci meno cose.

    Quindi il mio pensiero è che la scelta di cosa sia migliore dipende da quali sono i requisiti.

    E’ un piacere discutere su appunti digitali :)

  • # 19
    LMCH
     scrive: 

    Java è nato da un progetto relativo ai set-top box (decoder interattivi) e risente della mentalità prevalente nel periodo in cui è stato messo a punto inizialmente e dell’ “ambiente culturale” dell’azienda che lo ha sviluppato.
    Infatti le prime librerie per grafica ed UI erano cose abominevoli a cui si è (parzialmente) posto rimedio con Swing.
    A livello di UI mi sembra che in generale sia preferibile utilizzare SWT.

    .Net e C# a loro volta hanno come peccato originale l’essere nati per essere l’anti-JVM ed l’ anti-Java made-in-Microsoft dopo il tentativo di embrace-extend-extinguish basato su J++ non era andato in porto … e poi si sono evoluti in un modo che ha sin troppe analogie con il percorso seguito dal VisualBasic originale (quello fino a VB6 per intendersi), ovvero tante nuove funzionalità a volte aggiunte tramite librerie ed altre volte tramite estensioni del linguaggio ma che a lungo termine ne renderanno sempre più problematica l’evoluzione (con abbandono finale, come è successo con il vecchio VB).

    Per quel che mi riguarda, sono contento di essere rimasto su C/C++ e di aver abbandonato win32 e le VCL del C++ Borland per passare alle librerie crossplatform Qt.
    Mi è più semplice riutilizzare il codice già sviluppato su più piattaforme (e con un range di piattaforme più ampio di quello supportato da .Net e JVM), sono al riparo dalle idiozie di Microsoft (riguardo .Net) ed Oracle (riguardo Java) e sopratutto posso programmare ad oggetti e pattern in C++ come deve essere.

    Dico questo perchè il 99% delle difficoltà nello sviluppare applicazioni in C++ non sono legate al linguaggio ma alla mancanza di una vera libreria ad oggetti “completa” che includa UI, grafica ecc. ecc. con Qt si ottiene quello che manca ed in versione crossplatform.

  • # 20
    Alessandro
     scrive: 

    Per quanto mi riguarda, C# é, a livello do linguaggio, uno dei piú piacevoli con cui io abbia mai lavorato. Abbastanza simile a Java e C++ da essere veloce da apprendere per chi abbia giá esperienza con questi. Rispetto a Java apprezzo alcune scelte come i foreach, operator overloading, annotations, ‘preprocessore’ (anche se potevano farlo un peletto piú potente), properties etc.

    Devo dire peró che trovo alcune parti di .Net un pó carenti: WinForm, almeno fino alla 3, aveva delle limitazioni assurde, come la presenza dello stato ‘read-only’ su alcuni controlli ma non su altri altrettanto comuni. In altri casi si doveva ricorrere all’importazione delle api win32 per avere certe importanti funzionalitá. Spesso era evidente quanto winform altro non fosse che un wrapper incompleto attorno a win32.
    Anche altre tecnologie, come remoting, parevano incomplete.

    Trovo le librerie Java in generale fatte meglio, anche se il livello di granularitá é cosí alto che ti server gestire decine di classi anche per le cose piú semplici :-)

    Infine: Visual C++ é, senza paragone alcune, il miglior IDE in circolazione. Punto. Mi trovo molto bene con Eclipse (che a differenza di qualcuno piú sopra, io ho sempre trovato straordinariamente stabile: forse un crash in 3 anni di utilizzo costante al lavoro). Peccato per l’assenza di un Editor GUI decente, ma al lavoro non mi serve (dovrei, dopo anni, dare un’altra possibilitá a NetBeans per vedere cosa é cambiato, reattivitá in primis).

    Per C++ al lavoro uso C++ Builder 10 che, beh, francamente odio: documentazione scarsa, spesso instabile, debugger minimale, edito GUI buono ma ‘vecchio’ (a meno che non sia io che sbaglio qualcosa, non c’é neppure l’Undo per le modifiche) e la stragrande maggioranza degli esempi che trovo per le librerie riguardano Delphi, anche se si riescono a ‘tradurre’ facilmente.

    A causa per usi personali sto provando in questi giorni SharpDevelop. Carino ma con diversi limiti in debug (non é che usa gdb? ;-)

  • # 21
    Cesare Di Mauro
     scrive: 

    @Michele: non conoscevo Caliburn Micro. Gli ho dato una rapida occhiata e alla prossima occasione proverò a usarlo (con IronPython O:-)

    Per il resto, da sviluppatore, non posso che concordare: se uno strumento ti consente di portare avanti il lavoro più velocemente, può essere “brutto” o “vecchio”, ma lo userò. ;)

    @LMCH: puoi vedere .NET e C# come “anti-Java”, e penso sia pure opinione comune, perché fu una risposta di Microsoft a Sun dopo le vicende di J++ & JFC. Ma non a livello concettuale, perché le differenze fra i due linguaggi/ambienti sono marcate. Le slide di cui sopra rappresentano soltanto un excursus storico che sicuramente mette in chiaro molte cose, ma è leggendo le lunghe interviste a Hejlsberg che si capisce qual è stato l’approccio allo sviluppo di questi nuovi strumenti, che non è certo quello che hai dipinto (e sul lungo termine non vedo quali problematiche dovrebbe portare).
    Per chi fosse interessato, qui http://www.artima.com/intv/anders.html troverete “pane per i vostri denti”. ;)

    Non è chiaro, invece, di quali “idiozie” di Microsoft su .NET parli. Potresti essere più chiaro?

    Poi che le Qt siano un buon framework, nulla da dire, anche se le trovo un po’ pesantucce e occupano parecchio spazio (la 4.7.4 che ho installato tempo fa si mangia più di 1GB).
    Ciò non toglie che il C++ si porta dietro le sue rogne anche con le Qt. Queste si possono occupare della presentazione, ma il data model e la business logic devi continuare a svilupparli in C++.
    Per questo, se dovessi sviluppare con le Qt, preferirei farlo usando i binding per Python (PySide; PyQt ha una licenza indigesta) piuttosto che lavorarci in C++.

    Comunque continuerò a usare le WPF o Silverlight perché mi trovo divinamente, e il multipiattaforma può non essere un valore / requisito quando c’è un mercato che è per il 90% in mano a Microsoft. Alla fine dipende tutto dalle esigenze dei clienti/partner; non mi metto a perdere tempo con un framework multipiattaforma se so che questi lavorano da anni con sistemi Windows (e anche DOS! Mai visti terminali aperti con la famigerata interfaccia a caratteri?), e molto probabilmente continueranno a fare lo stesso ancora per molto tempo.

    A me interessa portare il pane a casa, e nel più breve tempo possibile. Con la filosofia/ideali/(pseudo)religioni non si mangia…

  • # 22
    Andrea Del Bene
     scrive: 

    Sicuramente C# ha corretto alcune pecche di Java e ci mancherebbe avendo avuto tutto il tempo per farlo.
    E’ ovvio poi che le due tecnologie seguono due politiche di evoluzione molto diverse, un a più spregiudicata (quella di C#) ed un’altra più conservativa (quella di Java) ma anche molto più partecipata a livello di community di sviluppatori (tramite JSR e ralitivi comitati).

  • # 23
    Cesare Di Mauro
     scrive: 

    Perché spregiudicata? Si tratta di scelte ben ponderate, che hanno richiesto anni per arrivare dove siamo.

    Vedi l’intervista di cui ho passato il link, che è molto eloquente in merito.

    Possiamo dire, piuttosto, che avendo più o meno le mani libere, Hejlsberg ha tirato fuori un linguaggio senza troppi compromessi, mentre gli sviluppatori di Java si sono auto-vincolati alla retrocompatibilità della virtual machine e, quindi, hanno tirato fuori delle porcate come i generic…

  • # 24
    Andrea Del Bene
     scrive: 

    Spregiudicata perchè introducono molti cambianti in un tempo relativamente breve e non si fanno molti scrupoli a rompere la compatibilità con il passto. Per qualcuno può essere una buona cosa m ho sentito tanti altri bestemmiare per questa politica.
    E poi non tutto mi sembra ben ponderato ed interessanto in C# vedi l’aver reintrodotto i tipi non espliciti con la keyword var che mi sembra una porcata per far contenti i vecchi sviluppatori abituati al vb e che rende il codice meno chiaro (ho sviluppato per diverso tempo in vb quindi mi sono fatto un’idea sul campo).
    Ciò che ho detto vale anche per i generics. Dovendoli implementare conservando la retrocompatibilità si è dovuti per forza scendere a compromessi, la dove .Net ha riscritto tutto passando dalla 1.0 alla 2.0. Non è detto che in futuro il bytecode di Java non subisca modifiche, cosa che personalmente auspico e che in parte si è iniziato a fare con la 7.

  • # 25
    LMCH
     scrive: 

    @ Cesare Di Mauro
    Riguardo alle idiozie, mi riferisco principalmente al voler spingere il runtime (pensato in primo luogo per applicazioni desktop) su roba a cui va stretto a colpi di limitazioni sulle librerie standard e sulle funzionalità utilizzabili.
    Mi riferisco all’aver sottovalutato le esigenze degli sviluppatori che non vivono nel fantabosco di Redmond, mettendoci delle pezze dopo. Pure il C permette di gestire in modo portabile i puntatori e quelli se ne sono accorti DOPO che forse era una funzionalità che tornava dannatamente utile per la portabilita dei sorgenti con alcune parti unmanaged visto anche che da anni era prevista la transizione graduale verso i 64bit.
    E così dopo aver LUNGAMENTE PIANIFICATO (?) la versione 1.0 (perchè era strategica, eh) se ne sono usciti a ruota con la 2.0
    Ecc. Ecc.

    Pure ora, molti di quelli che parlano dei pregi di .Net ecc. ecc. in realtà spesso parlano delle librerie e dei tool di supporto per la programmazione con i linguaggi ed il runtime .Net (guardacaso la stessa cosa che accadeva con il vecchio VB, ovviamente in scala minore viste le tecnologie e la potenza di calcolo allora disponibile) non della bontà dell’architettura di base (che ha tutte le caratteristiche di “facciamoci il nostro Java, con qualche miglioramento ma seguendo le stesse linee guida”).
    E tutto questo mentre da anni era chiaro che la strada poi intrapresa con molti meno fondi da LLVM (Low level Virtual Machine) era un alternativa di gran lunga migliore all’approccio simil-Java.

    Per questo poi il team che in Microsoft cura lo sviluppo dell’ OS se ne è uscito con WinRT nonostante che in origine avessero presentato .Net come l’interfaccia di programmazione verso l’OS che tutti dovrebbero usare: .Net in ultima analisi è il nuovo VisualBasic pimpato con il rossetto e la parrucca bionda ma con lo stesso obiettivo (vendor ed OS lock-in) e con le stesse limitazioni.

    Poi riguardo al fatto che Qt si mangia quasi 1GB … hai per caso notato che include TUTTI I SORGENTI ED I FILE DI HELP ? ;-)

    Su Windows gli eseguibili di Qt completi (tutte le DLL e tutti i plugin) incluso WebKit occupano circa 30MB, togli webkit e scendi a 20MB, togli altre parti che non utilizzi e si scende a circa 12MB, compila staticamente e si scende ulterioremente.

    Io uso Qt pure su target Windows CE dove il runtime .Net “compatto” gira a malapena, non so se rendo l’idea.

  • # 26
    CodeVisio
     scrive: 

    @LMCH

    mi hai tolto mezzo discorso che volevo fare inizialmente..:)
    Tra un po’ arriveremo a vedre microsoft, oramai alla deriva del Non So Che C… Fare Ulteriormente, sfornare ogni 5 minuti un OS con un nuovo linuaggio e una nuova libreria/framework pur di raccattare qualche soldo per la cassa. Che poi sarà la solita minestra riscaldata con l’aggiunta di una nuova spezia. Non è mai stata capace di inventarsi nulla ed ha sempre “copiato”, come a dire il buongiorno si vede dal mattino, CP/M – dos, OS/2 – Windows, OpenGL – DirectX ecc.
    Per me c’è un’unica causa a monte di tutto e si chiama Monopolio.
    Quando sei in uno stato di monopolio, giri a vuoto, e pur di far cassa butti sul mercato una cosa “copiata” che funziona al 10% spacciandola per un progresso dell’umanità, e poi cerchi di calmare le acque degli incazzati giustamente, con le mille e uno patch.
    (una perla che mi viene in mente al volo, forse l’unico IDEE con l’editor senza la possibilità di mettere i commenti in italic ahaha, saranno una 15 anni che è in piedi questo editor?!?)

    Per inciso, la mia vuole essere una critica a grandi linee, sulla linea di comportamento/astrategia che microsoft ha tenuto per circa 15/20 anni tanti quanti sono gli anni che sviluppo e non sul singlo tool o sulla singola parola chiave del singolo linaguaggio. In parte sono soddisfatto e in partte incazzato per come si possano buttare via cose buone per rimpiazzarle con stronz. fatte da un’anarchia di manager che di programmi/sviluppo/codice/OS non ci capiscano un beneamata palo.
    Bisognerebbe chiedersi se lo stato di monopolio di microsoft abbia dato qualche beneficio o se al contrario con diversi concorrenti avremmo potuto beneficiare di qualcosa più attinente alle esigenze di sviluppatori e user. Chissà.

    Per chi vuole appronfondire può trovare un’esposizione migliore della mia qui
    http://www.ntcore.com/ andare su blog e leggersi gli ultimi due post.

  • # 27
    Cesare Di Mauro
     scrive: 

    @Andrea Del Bene:

    Spregiudicata perchè introducono molti cambianti in un tempo relativamente breve e non si fanno molti scrupoli a rompere la compatibilità con il passto. Per qualcuno può essere una buona cosa m ho sentito tanti altri bestemmiare per questa politica.

    Non mi pare che la situazione sia stata diversa con Java. Ne abbiamo estesamente parlato qui: http://www.appuntidigitali.it/8665/ie9-il-riscatto-di-microsoft-nel-panorama-dei-browser/ (ultimi commenti).

    E poi non tutto mi sembra ben ponderato ed interessanto in C# vedi l’aver reintrodotto i tipi non espliciti con la keyword var che mi sembra una porcata per far contenti i vecchi sviluppatori abituati al vb e che rende il codice meno chiaro (ho sviluppato per diverso tempo in vb quindi mi sono fatto un’idea sul campo).

    Non c’entra proprio VisualBasic, che è un linguaggio completamente diverso.

    La type inference è una caratteristica molto utile, e ricercata. Infatti è stata introdotta anche nell’ultima versione di C++, la 11: hai qualcosa da dire anche su questo linguaggio? O:-)

    Ciò che ho detto vale anche per i generics. Dovendoli implementare conservando la retrocompatibilità si è dovuti per forza scendere a compromessi, la dove .Net ha riscritto tutto passando dalla 1.0 alla 2.0.

    I problemi con la retrocompatibilità li ha avuti anche Java. Vedi link di cui sopra.

    Non è detto che in futuro il bytecode di Java non subisca modifiche, cosa che personalmente auspico e che in parte si è iniziato a fare con la 7.

    Potevano benissimo rimanere con la stessa virtual machine, ma hanno preferito implementare un meccanismo più comodo, anche se rompe la compatibilità col passato (il bytecode generato richiede necessariamente la nuova vm).

    Un po’ di buon senso non guasta. Peccato che per i generic non abbiano preso una decisione coraggiosa, come ha fatto Microsoft col passaggio dalla 1.1 alla 2.0.

    @LMCH:

    @ Cesare Di Mauro
    Riguardo alle idiozie, mi riferisco principalmente al voler spingere il runtime (pensato in primo luogo per applicazioni desktop) su roba a cui va stretto a colpi di limitazioni sulle librerie standard e sulle funzionalità utilizzabili.
    Mi riferisco all’aver sottovalutato le esigenze degli sviluppatori che non vivono nel fantabosco di Redmond, mettendoci delle pezze dopo. Pure il C permette di gestire in modo portabile i puntatori e quelli se ne sono accorti DOPO che forse era una funzionalità che tornava dannatamente utile per la portabilita dei sorgenti con alcune parti unmanaged visto anche che da anni era prevista la transizione graduale verso i 64bit.
    E così dopo aver LUNGAMENTE PIANIFICATO (?) la versione 1.0 (perchè era strategica, eh) se ne sono usciti a ruota con la 2.0
    Ecc. Ecc.

    Di questo mi sembra ne abbiamo già discusso in un thread della sezione Programmazione di hwupgrade, che dovresti conoscere molto bene: http://www.hwupgrade.it/forum/showthread.php?t=2402000&page=3

    Singolare che continui ancora con la stessa storia…

    Pure ora, molti di quelli che parlano dei pregi di .Net ecc. ecc. in realtà spesso parlano delle librerie e dei tool di supporto per la programmazione con i linguaggi ed il runtime .Net (guardacaso la stessa cosa che accadeva con il vecchio VB, ovviamente in scala minore viste le tecnologie e la potenza di calcolo allora disponibile) non della bontà dell’architettura di base (che ha tutte le caratteristiche di “facciamoci il nostro Java, con qualche miglioramento ma seguendo le stesse linee guida”).

    Se i link che passo nemmeno li leggi, lo credo bene che continui a ripetere le stesse cose. Ma non è un mio problema, a questo punto.

    E tutto questo mentre da anni era chiaro che la strada poi intrapresa con molti meno fondi da LLVM (Low level Virtual Machine) era un alternativa di gran lunga migliore all’approccio simil-Java.

    Non ti seccare, ma la prima versione di .NET è arrivata UN ANNO PRIMA di LLVM, ed era di gran lunga più utilizzabile, mentre quest’ultimo progetto è divenuto finalmente utilizzabile soltanto negli ultimi anni.

    Le sfere di cristallo non le hanno nessuno, nemmeno in quel di Redmond.

    Anche con WinRT si continua a sviluppare con gli stessi elementi di .NET, che non è stato certo stato buttato via (e lo credo bene: sarebbe stato uno sbaglio enorme).

    Per il resto non ho nulla da dire sui gusti, mentre sul lock-in puoi sempre sbizzarrirti e portare degli esempi.

    Poi riguardo al fatto che Qt si mangia quasi 1GB … hai per caso notato che include TUTTI I SORGENTI ED I FILE DI HELP ? ;-)

    I sorgenti servono soltanto a chi deve sviluppare in C++.

    La documentazione soltanto agli sviluppatori, e peraltro avrebbero potuto utilizzare un formato molto più compatto e di più comoda consultazione, come il CHM, invece di mangiarsi 250MB di spazio solo per questo.

    Considera che le Qt le avevo scaricate soltanto per farci girare un’applicazione che le richiedeva. Da utente a me di tutta quella roba non interessava e non interessa nulla, e avrebbero potuto risparmiarmela.

    Su Windows gli eseguibili di Qt completi (tutte le DLL e tutti i plugin) incluso WebKit occupano circa 30MB, togli webkit e scendi a 20MB, togli altre parti che non utilizzi e si scende a circa 12MB, compila staticamente e si scende ulterioremente.

    La cartella bin occupa 508MB, e di questi gli exe sono 15MB, le DLL 116MB, e i pdb 377MB, più una manciata di altri piccoli file.

    Io uso Qt pure su target Windows CE dove il runtime .Net “compatto” gira a malapena, non so se rendo l’idea.

    Sì, hai reso l’idea. Era da un pezzo che non leggevo più di gente usa ancora Windows CE, e che abbia problemi con Compact .NET.

    Il target da un po’ di anni a questa parte s’è spostato verso altre piattaforme, dove c’è .NET, sebbene non in versione completa, che gira molto bene.

    @CodeVisio:

    @LMCH

    mi hai tolto mezzo discorso che volevo fare inizialmente..:)
    Tra un po’ arriveremo a vedre microsoft, oramai alla deriva del Non So Che C… Fare Ulteriormente, sfornare ogni 5 minuti un OS con un nuovo linuaggio e una nuova libreria/framework pur di raccattare qualche soldo per la cassa. Che poi sarà la solita minestra riscaldata con l’aggiunta di una nuova spezia. Non è mai stata capace di inventarsi nulla ed ha sempre “copiato”, come a dire il buongiorno si vede dal mattino, CP/M – dos, OS/2 – Windows, OpenGL – DirectX ecc.

    Quanto FUD e leggende metropolitane. Il tuo odio verso Microsoft trasuda da tutti i pori.

    Comunque, di CP/M è stata copiata l’interfaccia delle API, ma null’altro, ed è dimostrato che il DOS non ne fu una copia.
    OS/2, beh, era un prodotto di Microsoft, per cui scusa se ha copiato… se stessa! :D
    Le DirectX si sono ispirate alle OpenGL come API per gestire grafica 3D accelerata in hardware, ma per il resto sono API completamente diverse. Anzi, dalle DX 9 in poi è stata OpenGL a copiare e inseguire le DirectX.

    Hai altre leggende metropolitane da riportare?

    Per me c’è un’unica causa a monte di tutto e si chiama Monopolio.
    Quando sei in uno stato di monopolio, giri a vuoto, e pur di far cassa butti sul mercato una cosa “copiata” che funziona al 10% spacciandola per un progresso dell’umanità, e poi cerchi di calmare le acque degli incazzati giustamente, con le mille e uno patch.

    Ancora vagonate di FUD e cieco odio.

    Peraltro non esiste alcun monopolio, ma al limite potresti parlare di posizione dominante.

    Il resto non lo commento nemmeno.

    (una perla che mi viene in mente al volo, forse l’unico IDEE con l’editor senza la possibilità di mettere i commenti in italic ahaha, saranno una 15 anni che è in piedi questo editor?!?)

    Tutto qui? Tolta questa feature senza la quale è sicuramente impossibile lavorare, confrontalo con gli altri IDE, e vedi se riescono a essere utilizzabili quanto Visual Studio…

    Per inciso, la mia vuole essere una critica a grandi linee, sulla linea di comportamento/astrategia che microsoft ha tenuto per circa 15/20 anni tanti quanti sono gli anni che sviluppo e non sul singlo tool o sulla singola parola chiave del singolo linaguaggio. In parte sono soddisfatto e in partte incazzato per come si possano buttare via cose buone per rimpiazzarle con stronz. fatte da un’anarchia di manager che di programmi/sviluppo/codice/OS non ci capiscano un beneamata palo.

    Anche qui FUD a valanga. E in effetti Hejlsberg è così incapace di tirare fuori un linguaggio e un framework, che ha dovuto copiare malamente dagli altri, vero?

    Bisognerebbe chiedersi se lo stato di monopolio di microsoft abbia dato qualche beneficio o se al contrario con diversi concorrenti avremmo potuto beneficiare di qualcosa più attinente alle esigenze di sviluppatori e user. Chissà.

    Non essendoci stato alcun monopolio, da premesse false non posso che seguire implicazioni altrettanto false.

    Per il resto proprio gli sviluppatori sono quelli che più amano i prodotti Microsoft, e ci sarebbe da chiedersi il perché, vista la disastrosa situazione che hai dipinto finora.

    Non so, non è per caso che tu non abbia mai lavorato con gli strumenti messi a disposizione dalla casa di Redmond?

    Per chi vuole appronfondire può trovare un’esposizione migliore della mia qui
    http://www.ntcore.com/ andare su blog e leggersi gli ultimi due post.

    Troppo lunghi. Ma se la “sintesi” è quella che hai riportato finora, non ne vale nemmeno la pena.

  • # 28
    LMCH
     scrive: 

    @ Cesare Di Mauro
    Guarda che NON A CASO avevo scritto:
    “da anni era chiaro che la strada POI intrapresa con molti meno fondi da LLVM …”

    Se ne parlava già da anni ed erano già noti i vantaggi di tale approccio basato su rappresentazione SSA e sue varianti.
    Infatti poi anche Microsoft ha aggiunto nei metadati CLR le informazioni riguardo la rappresentazione SSA, solo che sono tutta roba proprietaria di Microsoft e sono limitate come scopo all’ottimizzazione del codice CLR, perdendo i vantaggi più grossi offerti dall’usare come descrizione base e multipiattaforma del codice una rappresentazione SSA (es: poter rendere managed codice unmanaged, eseguire sia verifiche statiche che a runtime, reinstrumentare on-demand il codice ecc. ecc.) grazie al fatto che la rappresentazione SSA è molto più indipendente dall’hardware a facile da rielaborare rispetto alle istruzioni CLR.

    Riguardo la tua tirata su quanto sia pesante Qt ecc. ecc. è inutile che ti arrampichi sugli specchi, hai parlato della sua pesantezza, ecc. ecc. e poi tu stesso ammetti che ti riferivi all’ SDK multipiattaforma con sorgenti completi, tool di supporto, librerie sia release che debug e file .pdb con tutti i simboli, ecc. ecc.
    Mentre per far girare un applicazione bastano le librerie release che hanno le dimensioni complessive che avevo detto.

    Riguardo infine i “problemi” con Windows CE che mi attribuisci, non ne ho, semplicemente utilizzo hardware che fa il suo lavoro a costo minore dell’hardware che servirebbero per fare la stessa cosa con .Net ( cosa che torna utile per essere competitivi sia sul prezzo che sulle prestazioni). ;-)

  • # 29
    Cesare Di Mauro
     scrive: 

    @LMCH:

    @ Cesare Di Mauro
    Guarda che NON A CASO avevo scritto:
    “da anni era chiaro che la strada POI intrapresa con molti meno fondi da LLVM …”

    Se ne parlava già da anni ed erano già noti i vantaggi di tale approccio basato su rappresentazione SSA e sue varianti.

    OK, adesso è chiaro a cosa ti riferissi. Sì, la ricerca nel campo di compilatori e macchine virtuali è molto prolifica, forse la più attiva branca dell’informatica.

    Comunque l’approccio di Microsoft non è stato “simil-Java”. Anche questo lo spiega bene ancora una volta Hejlsberg quando parla proprio della CLR.

    Infatti poi anche Microsoft ha aggiunto nei metadati CLR le informazioni riguardo la rappresentazione SSA, solo che sono tutta roba proprietaria di Microsoft

    Non mi risulta. Proprio la CLR, infatti, è uno standard ECMA.

    e sono limitate come scopo all’ottimizzazione del codice CLR, perdendo i vantaggi più grossi offerti dall’usare come descrizione base e multipiattaforma del codice una rappresentazione SSA (es: poter rendere managed codice unmanaged, eseguire sia verifiche statiche che a runtime, reinstrumentare on-demand il codice ecc. ecc.) grazie al fatto che la rappresentazione SSA è molto più indipendente dall’hardware a facile da rielaborare rispetto alle istruzioni CLR.

    Mi sembra evidente, anche da quello che ha scritto sempre Hejlsberg, che la CLR sia stata disegnata appositamente per ottimizzare la compilazione del codice a runtime, da IL a binario, e per una migliore esecuzione.

    Quest’obiettivo era, ed è, fondamentale per gli scopi che si era prefissa Microsoft.

    Non entro ne merito perché non conosco l’SSA, ma se oltre a quello che hai riportato qui sopra non ci sono altri vantaggi tangibili rispetto a quelli che ho descritto io, male non ha fatto di certo Microsoft nel progettare la sua CLR.

    Riguardo la tua tirata su quanto sia pesante Qt ecc. ecc. è inutile che ti arrampichi sugli specchi, hai parlato della sua pesantezza, ecc. ecc.

    Sì, e continuo a dirlo. Non vedo dove starebbe l’arrampicata. Hai mai provato a lanciare un’applicazione basata sulle Qt? Direi di sì, per cui conosci bene la situazione.

    e poi tu stesso ammetti che ti riferivi all’ SDK multipiattaforma

    Ma proprio no. Da dove l’hai dedotto questo? Ecco qui:

    “Poi che le Qt siano un buon framework, nulla da dire, anche se le trovo un po’ pesantucce e occupano parecchio spazio (la 4.7.4 che ho installato tempo fa si mangia più di 1GB).”

    con sorgenti completi, tool di supporto, librerie sia release che debug e file .pdb con tutti i simboli, ecc. ecc.
    Mentre per far girare un applicazione bastano le librerie release che hanno le dimensioni complessive che avevo detto.

    E dove si trovano? Ribadisco: le ho installate perché mi servivano per un’applicazione che ne faceva uso. Sono andato sul sito (che adesso è cambiato, tra l’altro), e c’era soltanto il file “qt-win-opensource-4.7.4-vs2008.exe” da scaricare. Ho cercato poco fa le librerie, ma non le ho trovate (dove si possono scaricare?), altrimenti avrei usato quelle, visto che non avevo proprio bisogno dell’SDK (è ben noto, e dovresti saperlo ormai anche dal forum di cui sopra, che non ho nessuna intenzione di perderci del tempo, visto che prediligo ben altri strumenti ;).

    Fermo restando che, anche se dovessi svilupparci, dei sorgenti non me ne farei proprio nulla, perché preferirei farlo con Python + PySide. E per la documentazione, piuttosto che sprecare 250MB, sarebbe stato molto meglio un file .CHM che è di gran lunga più compatto e versatile.

    Più chiaro di così…

    Riguardo infine i “problemi” con Windows CE che mi attribuisci, non ne ho, semplicemente utilizzo hardware che fa il suo lavoro a costo minore dell’hardware che servirebbero per fare la stessa cosa con .Net ( cosa che torna utile per essere competitivi sia sul prezzo che sulle prestazioni). ;-)

    Ma io su questo non ho proprio nulla da dire. Da programmatore mi pare scontato che l’obiettivo principale è soddisfare i requisiti del progetto, col “miglior” compromesso possibile. Per cui se ti trovi bene così, tanto di cappello.

    Il mio era stupore, meraviglia, per il fatto che utilizzi ancora Windows CE, che ormai è preistoria, visto che le piattaforme mobile sono ben diverse, e per Microsoft c’è Windows Phone col suo .NET “ridotto” (ma molto più completo della versione Compact per WinCE). Tutto qui. ;)

  • # 30
    LMCH
     scrive: 

    @ Cesare Di Mauro
    Ti rispondo sinteticamente:

    1) I metadati con gli hint SSA non fanno parte degli standard ECMA relativi al CLR, sono stati implementati.

    2) la codifica SSA include in forma esplicita le interdipendenze dei valori che assumono le variabili (SSA = Single Static Assignment) quindi contiene molte più informazioni utili per riorganizzare ed ottimizzare un programma, non si riesce ad ottenere lo stesso risultato con un bytecode tipo CLR o Java che invece descrive l’esecuzione in termini di un processore virtuale con vari vincoli dettati dalla sua architettura.
    Un compilatore parte dai sorgenti, genera una rappresentazione interna SSA e poi genera il codice oggetto (oppure bytecode Java o CLR), nella fase di generazione vengono perse informazioni perchè si fanno delle scelte di implementazione dell’esecuzione dipendenti dall’architettura (reale o virtuale) del target.
    Se invece si mantiene una rappresentazione SSA “completa” diventa possibile ottimizzare in modo più efficace perchè non è necessario ri-estrarre la notazione SSA dal bytecode (che intanto ha perso informazioni su eventuali finte dipendenze introdotte dall’architettura virtualizzata dal bytecode CIL/Java).

    3) Riguardo Windows CE, io lo uso su schede embedded ed altra roba industriale (es: frontend e pannelli operatore ) su cui si devono far girare varie applicazione di controllo e/o supervisione, anche se ormai per nuovi prodotti si utilizza sempre più linux embedded oppure (principalmente per i pannelli operatore ed altra roba non critica) Android.
    Per questo stravedo per Qt, mi permette di saltare letteralmente da una piattaforma all’altra con le prestazioni che da il codice nativo e con al massimo con qualche modifica di poco conto visto che sviluppo il tutto fin dal principio in un ottica crossplatform.

  • # 31
    LMCH
     scrive: 

    Oops! manca un pezzo della prima frase:
    “sono stati implementati DOPO la pubblicazione dello standard ECMA e non ne fanno parte”.

  • # 32
    Andrea Del Bene
     scrive: 

    @ Cesare Di Mauro

    -I link che mi hai segnalato parlano della baruffa Microsoft/Sun. Non vedo cosa centrino parlando dei disagi che può comportare una gestione delle versioni ballerina come quella adottata da microsoft.
    -Ci sono legioni di informatici che non apprezzano tutte le caratteristiche del c++, ma non per questo vuol dire che lo si disprezzi in toto.
    Che la type inference sia “una caratteristica molto utile, e ricercata” è una tua opinione personale e la accetto come tale. Secondo me rende il codice molto meno leggibile, la posso accettare in un linguaggio di programmazione di scripting ma non in uno strong typed.

  • # 33
    Cesare Di Mauro
     scrive: 

    @LMCH: 1) OK, pensavo fossero stati introdotti prima.

    2) Il punto è che l’SSA va bene se devi scegliere una forma intermedia per applicare in maniera agevole tutte le ottimizzazioni che vuoi, e infine generare il codice oggetto desiderato. Ma ciò, come detto in precedenza, non è sempre desiderabile se hai a che fare con una virtual machine e un codice IL che dev’essere convertito velocemente in codice oggetto.
    Va bene per un approccio AOT (che .NET supporta, comunque: puoi decidere di compilare interamente un’applicazione alla prima esecuzione), ma non per uno JIT, dove l’utente sta eseguendo l’applicazione in quel preciso momento ed è lì in attesa di vederne i risultati.

    3) E’ un settore decisamente diverso rispetto a quello di cui parlavo io. ;)

    @Andrea Del Bene: se ti studi i link vedrai che i problemi di compatibilità ci sono stati anche con Java. Se non hai tempo per studiarteli, ho esplicitato il tutto nei miei commenti. Questo per dire che il taglio della compatibilità non è un marchio d’infamia che si porta soltanto Microsoft col passaggio di .NET dalla 1.1 alla 2.0.
    Ma poi se ti accorgi che è necessaria un’infrastruttura migliore per andare avanti, anche a costo di tagliare col passato, perché non dovresti farlo? Per te è meglio perseverare nell’errore (se tale si può definire) commesso? Preferisci trascinarti dietro un’infrastruttura inadeguata mettendoci qualche pezza, e inficiando lo sviluppo futuro?
    Certo che è singolare, però. Microsoft è sempre stata tacciata di guardare troppo alla retrocompatibilità (il che non è proprio vero, ma comunque le stato appiccicato anche questo), e quando non lo fa viene messa in croce. Non ha proprio pace. :D

    Per il resto la type inference non inficia di certo lo strong typing di un linguaggio: sono due cose completamente diverse. Può non piacere (e devo dire finora che sei il primo :D), ma è uno strumento comodissimo per evitare di ripetere il tipo di una variabile (o espressione) quando è già ben noto dal contesto. Va, insomma, incontro al classico principio DRY… ;)

  • # 34
    Andrea Del Bene
     scrive: 

    Se parliamo delle versioni 1.0 e 1.1 di Java e .NET non è un mistero che abbiano avuto un carattere fortemente sperimentale e quindi non c’è nulla di strano che nelle versioni 1.2(di Java) e 2.0 (di .NET) abbiano voluto correggere gli errori di gioventù.
    Quello che mi rende perplesso su .NET è il fatto che abbiano rilasciato a “fiume” un sacco di versioni a distanza di appena un anno, senza dare nemmeno il tempo di assibilare le novità.
    A questo va aggiunta anche una politica di versioning infelice sicuramente non adatta ad un prodotto che si vuole proporre a milioni di persone e che ha provocato più di un mal di pancia:

    http://www.west-wind.com/weblog/posts/2012/Mar/13/NET-45-is-an-inplace-replacement-for-NET-40

    http://www.hanselman.com/blog/RequestForCommentsIssuesWithNETAndMicrosoftProductVersioning.aspx

  • # 35
    Cesare Di Mauro
     scrive: 

    L’unica cosa sulla quale posso essere d’accordo è la politica di versioning adottata col .NET 4.5, di cui parla il primo link, ma per il resto non vedo proprio cosa ci sarebbe da additare a Microsoft.

    Il fatto che abbia rilasciato .NET 2.0, 3.0 e 3.5 a un anno di distanza l’uno dall’altro? C’è semplicemente UNA release in più rispetto, ad esempio, a quanto ha fatto Sun con Java dalla 1.2 alla 6, che sono arrivati a 2 anni di distanza l’una dall’altra. Per .NET ce n’è stata una in mezzo; tutto qui.

    Se consideriamo che dalla 2.0 alla 3.5 non è nemmeno cambiata la CLR, faccio veramente fatica a capire di cosa ti lamenti, visto che si è trattato peraltro di aggiunte al progetto 2.0: nuovi strumenti che non è nemmeno detto che t’interessino, perché dipende da quello che devi sviluppare (non è che di Java devi conoscere e usare per forza tutto).

    Per il resto mi fa piacere che sulle prime versioni di Java e .NET c’è finalmente accordo. ;)

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.