[News]Go: new open source programming language from Google

[s0nnyd3marco]

Originariamente inviato da PGI-Bis

Sì.

Secondo me la fai troppo semplice. Considera che per scrivere un linguaggio, un compilatore, un layer di macchine virtuali ecc non basta un programmatore che lavori nei week end a tempo perso, ma un team di sviluppo ed un bel po di tempo.

Tu saresti in grado di scrivere da solo un compilatore, diciamo C++ in quanto tempo? un qualcosa che sia funzionante parlo.

[zulutown]

Originariamente inviato da banryu79

Non so niente della realtà esistente in Google, ma sbaglio di molto se penso che con i loro mezzi (sia economici, che culturali e tecnologici, nonchè l'esperienza accumulata) possano tranquillamente fare R&D come dio comanda?

consentire anche all'ultimo arrivato (che magari è un genio, mentre magari i responsabili R&D sono solo dei mezzi-geni) di aver visibilità con progetti fatti da lui ti consente sulla quantità di progetti proposti di trovare anche qualcosa di interessante

[_Claudio]

Originariamente inviato da s0nnyd3marco

Secondo me la fai troppo semplice. Considera che per scrivere un linguaggio, un compilatore, un layer di macchine virtuali ecc non basta un programmatore che lavori nei week end a tempo perso, ma un team di sviluppo ed un bel po di tempo.

Tu saresti in grado di scrivere da solo un compilatore, diciamo C++ in quanto tempo? un qualcosa che sia funzionante parlo.

Un compilatore di un linguaggio esistente lo scrivi (funzionante e usabile) forse in una settimana perchè esistono le specifiche, strumenti che facilitano molto lo sviluppo (flex, yacc, bison... mai sentiti?).
Se bisogna progettare un linguaggio nuovo, il problema non è tanto nello scrivere il codice ma tanto nel trovare la grammatica corretta e definire correttamente le traduzioni, roba che viene fatta su carta.
Poi è ovvio che un linguaggio nuovo non potrà competere con Java, C++, ecc... (sicuramente batterebbe ad occhi chiusi python )
però non è nemmeno detto che nella sua prima versione sia da buttare e inutilizzabile.

[s0nnyd3marco]

Originariamente inviato da _Claudio

Un compilatore di un linguaggio esistente lo scrivi (funzionante e usabile) forse in una settimana perchè esistono le specifiche, strumenti che facilitano molto lo sviluppo (flex, yacc, bison... mai sentiti?).
Se bisogna progettare un linguaggio nuovo, il problema non è tanto nello scrivere il codice ma tanto nel trovare la grammatica corretta e definire correttamente le traduzioni, roba che viene fatta su carta.
Poi è ovvio che un linguaggio nuovo non potrà competere con Java, C++, ecc... (sicuramente batterebbe ad occhi chiusi python )
però non è nemmeno detto che nella sua prima versione sia da buttare e inutilizzabile.

Ok, ma il parsing del linguaggio fino ad arrivare ad un albero sintattico è solo una parte del problema. Considera che poi devi trasformarlo in codice macchina o bytecode e quindi devi avere una conoscenza piuttosto approfondita del sistema operativo o della vm che sta sotto. Chiaramente tutto è fattibile. Ma credo che scrivere un compilatore, anche utilizzando strumenti di parsing già disponibili, sia cmq un lavoraccio e che alla fine porti pochi benefici, anzi probabilmente più grattacapiche altro. Dubito che un compilatore self made sia affidabile, ottimizzato e collaudato come uno che è su piazza da diversi anni.
Se poi decidi di scrivere un linugaggio nuovo, oltre a dover decidere la grammatica, che sia innovativa, priva di incongruenze ecc il compito diventa ancora più arduo. Tieni presente che un linguaggio di programmazione nuovo privo di librerie è praticamente inutile.

PS: guarda che il python, rispetto a tutti gli altri linguaggi interpretati, scala molto bene.

[khelidan1980]

Originariamente inviato da s0nnyd3marco

Ok, ma il parsing del linguaggio fino ad arrivare ad un albero sintattico è solo una parte del problema. Considera che poi devi trasformarlo in codice macchina o bytecode e quindi devi avere una conoscenza piuttosto approfondita del sistema operativo o della vm che sta sotto.

E chi la detto?Credo che il 90% dei linguaggi sia semplicemente scritto in C

[_Claudio]

Originariamente inviato da s0nnyd3marco

Ok, ma il parsing del linguaggio fino ad arrivare ad un albero sintattico è solo una parte del problema. Considera che poi devi trasformarlo in codice macchina o bytecode e quindi devi avere una conoscenza piuttosto approfondita del sistema operativo o della vm che sta sotto. Chiaramente tutto è fattibile. Ma credo che scrivere un compilatore, anche utilizzando strumenti di parsing già disponibili, sia cmq un lavoraccio e che alla fine porti pochi benefici, anzi probabilmente più grattacapiche altro. Dubito che un compilatore self made sia affidabile, ottimizzato e collaudato come uno che è su piazza da diversi anni.
Se poi decidi di scrivere un linugaggio nuovo, oltre a dover decidere la grammatica, che sia innovativa, priva di incongruenze ecc il compito diventa ancora più arduo. Tieni presente che un linguaggio di programmazione nuovo privo di librerie è praticamente inutile.

PS: guarda che il python, rispetto a tutti gli altri linguaggi interpretati, scala molto bene.

Trasformare in codice macchina o bytecode fa parte di quello che chiamo traduzione.
Che poi sia un lavoro poco utile in ambito lavorativo è indubbio, così come che sia poi inutilizzabile vista la mancanza di librerie e poco performante nella sua prima versione.

Ma non è assolutamente vero che ci vogliono mesi di lavoro in team per crearne uno, basta avere le competenze giuste e le idee ben chiare in testa.

[s0nnyd3marco]

Originariamente inviato da khelidan1980

E chi la detto?Credo che il 90% dei linguaggi sia semplicemente scritto in C

Il compilatore e, se previsto, la vm, ma quello che ti esce dalla compilazione è bytecode o codice macchina.

[PGI-Bis]

Originariamente inviato da s0nnyd3marco

Tu saresti in grado di scrivere da solo un compilatore, diciamo C++ in quanto tempo? un qualcosa che sia funzionante parlo.

Certamente sì, e penso che ci impiegherei più o meno tre anni lavorativi, perchè ci sono una marea di cose che dovrei studiare. Però considera che io sono un praticone: da uno che ha studiato informatica penso sia lecito pretendere una performance un pelino più agile.

Dico "certamente sì" perchè il compito richiederebbe semplicemente studio e applicazione: i compilatori sono una tecnologia consolidata per cui esistono riferimenti in quantità industriale.

Dubito fortemente che sarei in grado di apportare una qualsiasi innovazione durante il percorso, se non per classica "botta di culo": per mirare a quello bisogna avere una comprensione del problema semplicemente diversa da quella che è richiesta per una mera riproduzione di ciò che già si fa.

[s0nnyd3marco]

Originariamente inviato da _Claudio

Trasformare in codice macchina o bytecode fa parte di quello che chiamo traduzione.
Che poi sia un lavoro poco utile in ambito lavorativo è indubbio, così come che sia poi inutilizzabile vista la mancanza di librerie e poco performante nella sua prima versione.

Ma non è assolutamente vero che ci vogliono mesi di lavoro in team per crearne uno, basta avere le competenze giuste e le idee ben chiare in testa.

Concordo con te, tranne per le tempistiche. Cmq mi avete messo la pulce nell'orecchio. Appena trovo un briciolo di tempo inizio a documentarmi approfonditamente.

[s0nnyd3marco]

Originariamente inviato da PGI-Bis

Certamente sì, e penso che ci impiegherei più o meno tre anni lavorativi, perchè ci sono una marea di cose che dovrei studiare. Però considera che io sono un praticone: da uno che ha studiato informatica penso sia lecito pretendere una performance un pelino più agile.

Dico "certamente sì" perchè il compito richiederebbe semplicemente studio e applicazione: i compilatori sono una tecnologia consolidata per cui esistono riferimenti in quantità industriale.

Dubito fortemente che sarei in grado di apportare una qualsiasi innovazione durante il percorso, se non per classica "botta di culo": per mirare a quello bisogna avere una comprensione del problema semplicemente diversa da quella che è richiesta per una mera riproduzione di ciò che già si fa.

Sono d'accordo con te: il scrivere un compilatore tradizionale, ovvero privo di brillanti innovazioni, è un compito di puro studio e applicazione. Per quanto riguarda l'aspetto "da uno che ha studiato informatica... " consentimi di dissentire. Sto facendo la specialistica di ing info a ts e lavoro come programmatore, e ti assicuro che purtroppo la maggior parte dei corsi e dei piani di studio sono del tutto insufficienti per la preparazione ad un compito del genere. Spesso ho dovuto cercare in rete o studiarmi per conto mio determinati argomenti in cui avrei voluto un maggiore approfondimento da parte dell'univ.
Senza contare che la maggior parte dei studenti purtroppo è la solo per il titolo.

[khelidan1980]

Originariamente inviato da s0nnyd3marco

Il compilatore e, se previsto, la vm, ma quello che ti esce dalla compilazione è bytecode o codice macchina.

ma non è vero dipende da cosa vuoi fare,se ti scrivi un linguaggio interpretato ti basta un interprete scritto in C,stile ruby,dobbiamo metterci d'accordo se il target è scrivere un nuovo linguaggio,oppure un compilatore vero e proprio

[khelidan1980]

Originariamente inviato da s0nnyd3marco

Sono d'accordo con te: il scrivere un compilatore tradizionale, ovvero privo di brillanti innovazioni, è un compito di puro studio e applicazione. Per quanto riguarda l'aspetto "da uno che ha studiato informatica... " consentimi di dissentire. Sto facendo la specialistica di ing info a ts e lavoro come programmatore, e ti assicuro che purtroppo la maggior parte dei corsi e dei piani di studio sono del tutto insufficienti per la preparazione ad un compito del genere. Spesso ho dovuto cercare in rete o studiarmi per conto mio determinati argomenti in cui avrei voluto un maggiore approfondimento da parte dell'univ.
Senza contare che la maggior parte dei studenti purtroppo è la solo per il titolo.

ma secondo me è anche giusto,il cercare qualcosa in più fa la differenza a mio modo di vedere,a livello di persona

[nico159]

http://www.dalkescientific.com/writi..._tasklets.html
Stackless Python faster than Go

[cdimauro]

Molto interessante, grazie!

[s0nnyd3marco]

Originariamente inviato da khelidan1980

ma non è vero dipende da cosa vuoi fare,se ti scrivi un linguaggio interpretato ti basta un interprete scritto in C,stile ruby,dobbiamo metterci d'accordo se il target è scrivere un nuovo linguaggio,oppure un compilatore vero e proprio

Prima si parlava che se uno sviluppatore non trova un compilatore adatto ai suoi scopi può scriversene uno. Io ho solamente fatto notare come tale compito mi sembrava piuttosto gravoso e di sicuro non di facile realizzazione, in quanto richiederebbe parecchio studio e riflessioni. Chiaramente i compilatori sono molto difusi, quindi anche la documentazione a riguardo. Se poi si usa anche un parser e un analizzatore lessicale già disponibile ci si toglie una parte del compito, ma non tutto. Per quanto riguarda la mia esperienza da programmatore (circa 16 mesi), nella maggior parte dei casi si riutilizza cose già scritte da altri piuttosto che iniziare qualcosa di nuovo, tranne che non si è proprio costretti.

Tornando on topic, trovo lodevole che google investa in molte iniziative, anche se non sempre portano a un fine.
Non capisco perche abbiano deciso di fare un n-esimo linguaggio, quando esistono molteplici concorrenti simili a Go, vedi python o ruby, tanto per citarne alcuni. Non vedo nessuna caratteristica cosi innovativa da far abbandonare uno di questi per passare a Go.
Se sperano di sostituire il C++ con questo, beh, ho solo una cosa da dire: Auguri

[vhost87]

Originariamente inviato da s0nnyd3marco

Prima si parlava che se uno sviluppatore non trova un compilatore adatto ai suoi scopi può scriversene uno. Io ho solamente fatto notare come tale compito mi sembrava piuttosto gravoso e di sicuro non di facile realizzazione, in quanto richiederebbe parecchio studio e riflessioni. Chiaramente i compilatori sono molto difusi, quindi anche la documentazione a riguardo. Se poi si usa anche un parser e un analizzatore lessicale già disponibile ci si toglie una parte del compito, ma non tutto. Per quanto riguarda la mia esperienza da programmatore (circa 16 mesi), nella maggior parte dei casi si riutilizza cose già scritte da altri piuttosto che iniziare qualcosa di nuovo, tranne che non si è proprio costretti.

Tornando on topic, trovo lodevole che google investa in molte iniziative, anche se non sempre portano a un fine.
Non capisco perche abbiano deciso di fare un n-esimo linguaggio, quando esistono molteplici concorrenti simili a Go, vedi python o ruby, tanto per citarne alcuni. Non vedo nessuna caratteristica cosi innovativa da far abbandonare uno di questi per passare a Go.
Se sperano di sostituire il C++ con questo, beh, ho solo una cosa da dire: Auguri

Se l ha fatto è perché avrà successo, come la maggior parte dei prodotti della grande G. Siamo fiduciosi

Così cdimauro abbandonerà quella schifezza del pitone per passare a Go

[s0nnyd3marco]

Originariamente inviato da michele.broggi

Se l ha fatto è perché avrà successo, come la maggior parte dei prodotti della grande G. Siamo fiduciosi

Così cdimauro abbandonerà quella schifezza del pitone per passare a Go

Perche' tutto questo astio nei confronti del pitone? Nonostante sia abituato a linguaggi tipo c++ c# e java, lo trovo estremamente facile e comodo. Personalmente l'ho usato principalmente per progetti relativamente piccolini, al max 2000 line, ma da quello che dicono scala veramente bene.

[cdimauro]

Hai perfettamente ragione, ma credo che michele.broggi stesse scherzando.

[vhost87]

Originariamente inviato da cdimauro

Hai perfettamente ragione, ma credo che michele.broggi stesse scherzando.

Esatto, hai colto in pieno. Era una presa in giro al pitoniano

Anche io uso il pitone (per piccolissimi progetti) e penso che lo utilizzerò più spesso...

[s0nnyd3marco]

Originariamente inviato da michele.broggi

Esatto, hai colto in pieno. Era una presa in giro al pitoniano

Anche io uso il pitone (per piccolissimi progetti) e penso che lo utilizzerò più spesso...

Credevo fosse una frecciatina sottoforma scherzosa