View Full Version : Aiuto scelta linguaggio...
m4dbra1n
04-05-2009, 17:58
Ciao a tutti,
apro questo thread perché ho dei dubbi su che linguaggio scegliere per creare un programma che mi aiuti nella gestione dell'assistenza a lavoro.
Faccio il tecnico hw/sw in un piccolo negozio d'informatica, per cui niente di mastodontico, ma il file fatto dal "boss" con Filemaker inizia a presentare alcuni problemi: lentezza indicibile; impossibilità di avere una lista di clienti; impossibilità di sapere se e quando sono già stati da noi.
Ora, nonostante abbia già programmato a scuola (io non mi ritengo tale, ma sono un perito tecnico in informatica...) con VB e C++, essendo 4 anni che non programmo neanche x diletto, avevo pensato di virare su qualche altro linguaggio 2 alcuni motivi:
- supporto multilingua, qualora vorrei rilasciarlo in rete (ci vuole un linguaggio che supporti Unicode, o sbaglio?)
- portabilità su più piattaforme (quindi penso che per questo java sia l'ideale: gira su molti sistemi indipendentemente dalla macchina...oppure flash?)
Detto questo, cosa mi consigliate? Rimango su VB o C++ e amen, o vedo se riesco ad esplorare altri lidi, tipo Java, Python, Delphi, etc?
E se lo sviluppassi in maniera web-based? Basterebbe imparare PHP, MySQL e CSS? O magari mi conviene modificare qualche CMS?
Fatevi avanti con tutti i vostri pro e contro per il linguaggio, mi serve di capire che strada prendere.
Grazie in anticipo ;)
CIAO!
||ElChE||88
04-05-2009, 18:04
Dimentica VB e C++ (uno è poco portabile, l'altro è inutilmente complesso per quel che devi fare).
Mi sa proprio che Java fa al caso tuo.
m4dbra1n
04-05-2009, 18:11
Quindi devo vedere di imparare Java e come interfacciarlo ad un db, così potrò avere finalmente la lista degli utenti, degli interventi x utente, numero di interventi mensili, annuali, etc...
Ed in più non dovrei avere problemi a tradurlo in qualche altra lingua o su altri sistemi, visto che basta aver installato il runtime java, giusto?
CozzaAmara
04-05-2009, 20:14
Ruby, Python?
cdimauro
04-05-2009, 20:30
Se realizzi un'interfaccia web ti spicci prima con un linguaggio dinamico, come Python o Ruby.
Per Python esiste un progettino carino (http://pyjs.org/) che permette di realizzare velocemente GUI web, e di poterle convertire anche in applicazioni standalone (quindi che funzionano anche senza browser).
Inoltre per interfacciarti a un db è molto più comodo e pratico farlo con un Python.
m4dbra1n
04-05-2009, 21:04
Se realizzi un'interfaccia web ti spicci prima con un linguaggio dinamico, come Python o Ruby.
Per Python esiste un progettino carino (http://pyjs.org/) che permette di realizzare velocemente GUI web, e di poterle convertire anche in applicazioni standalone (quindi che funzionano anche senza browser).
Inoltre per interfacciarti a un db è molto più comodo e pratico farlo con un Python.
Stavo pensando che forse devo rimanere sul classico, visto che nn abbiamo un serverino acceso 24/7/365 dove installare apache, mysql, etc... e dove quindi poter utilizzare una web app.
Sempre sul classico 2 sono le soluzioni:
1 - Windows: è la piattaforma principale dove lo utilizzerei, addirittura su una sola postazione, per cui potrei anche utilizzare linguaggi vecchi ma che 1 pò conosco come VB;
2 - Multi-OS, multi-lingua: qui devo per forza utilizzare linguaggi che poggino su una base comune installabile a tutti gli OS, quindi un runtime, come Java.
Per quanto riguarda Python, c'è qualche problema a utilizzarlo su + piattaforme? Va cmq installato un runtime similmente a Java o altro?
Diciamo che cmq il mio caso attualmente è il primo, avevo pensato all'eventualità del cross-platform multi-lingua così, soprattutto perché tramite google non se ne trovano molti di programmi del genere open o cmq gratuiti, a parte il Gestione Assistenza di Ken1986 e qualche altro...
cdimauro
04-05-2009, 21:20
Stavo pensando che forse devo rimanere sul classico, visto che nn abbiamo un serverino acceso 24/7/365 dove installare apache, mysql, etc... e dove quindi poter utilizzare una web app.
Con Python non ti serve apache: tiri sù un serverino HTTP con poche righe di codice.
Al posto di MySQL io userei FireBird (http://www.firebirdsql.org/), che è presente anche in soluzione embedded (quindi niente da installare), che è pure un engine SQL "migliore".
Sempre sul classico 2 sono le soluzioni:
1 - Windows: è la piattaforma principale dove lo utilizzerei, addirittura su una sola postazione, per cui potrei anche utilizzare linguaggi vecchi ma che 1 pò conosco come VB;
2 - Multi-OS, multi-lingua: qui devo per forza utilizzare linguaggi che poggino su una base comune installabile a tutti gli OS, quindi un runtime, come Java.
Per quanto riguarda Python, c'è qualche problema a utilizzarlo su + piattaforme?
No.
Va cmq installato un runtime similmente a Java o altro?
No. Poi ci sono soluzioni come questa (http://www.py2exe.org/index.cgi/FrontPage) che ti permettono di generare applicazioni standalone.
Diciamo che cmq il mio caso attualmente è il primo, avevo pensato all'eventualità del cross-platform multi-lingua così, soprattutto perché tramite google non se ne trovano molti di programmi del genere open o cmq gratuiti, a parte il Gestione Assistenza di Ken1986 e qualche altro...
Guarda, se usi Google App Engine secondo me risolvi un sacco di problemi:
- ti fa da hosting (gestito tutto da Google, compresi backup, manutenzione, ecc.);
- hai già Python "installato";
- hai un database a disposizione;
- hai un potentissimo framework già "installato" (Django (http://www.djangoproject.com/)).
Devi soltanto scrivere il codice, caricarlo su Google App Engine, ed è già immediatamente utilizzabile 24h/24 senza installare nulla.
Guarda, se usi Google App Engine secondo me risolvi un sacco di problemi:
- ti fa da hosting (gestito tutto da Google, compresi backup, manutenzione, ecc.);
- hai già Python "installato";
- hai un database a disposizione;
- hai un potentissimo framework già "installato" (Django (http://www.djangoproject.com/)).
Devi soltanto scrivere il codice, caricarlo su Google App Engine, ed è già immediatamente utilizzabile 24h/24 senza installare nulla.
Siccome sto imparando django, potresti spiegarmi in due parole come funziona google app engine?
Una volta finito il sito devo uppare solo i vari file urls.py, views.py, i modelli ed i template? Insomma solo tutta la cartella del progetto del sito che ho creato?
cdimauro
04-05-2009, 22:20
Sì, dopodiché il tuo sito sarà operativo.
Similmente a quanto avviene come un qualunque altro sito di hosting che ti offre spazio per i file dei tuoi progetti, un interprete e l'engine del tuo database.
Qui il vantaggio è che ti viene offerto un ambiente completo con tanto di framework web già incluso, e devi soltanto uppare i file del codice vero e proprio del sito che hai realizzato.
Sì, dopodiché il tuo sito sarà operativo.
Similmente a quanto avviene come un qualunque altro sito di hosting che ti offre spazio per i file dei tuoi progetti, un interprete e l'engine del tuo database.
Qui il vantaggio è che ti viene offerto un ambiente completo con tanto di framework web già incluso, e devi soltanto uppare i file del codice vero e proprio del sito che hai realizzato.
Interessante.. Quindi potrei utilizzare django su qualsiasi host su cui sia installato python+mysqldb semplicemente uppando anche la cartella di installazione di django? :eek:
Mentre invece a quanto ho capito il vantaggio di google app engine è che devi uppare solo i file del tuo progetto...
cdimauro
05-05-2009, 08:17
Interessante.. Quindi potrei utilizzare django su qualsiasi host su cui sia installato python+mysqldb semplicemente uppando anche la cartella di installazione di django? :eek:
Sì. L'installazione di un "pacchetto" in Python generalmente comporta la semplice copia dei file nella cartella standard Lib/site-packages, ma si possono benissimo copiare anche nella cartella del progetto stesso.
Ad esempio io a casa non ho mai installato né Python né tutti i package che uso: me li sono copiati dal computer di lavoro, e funziona tutto senza problemi. :p
Mentre invece a quanto ho capito il vantaggio di google app engine è che devi uppare solo i file del tuo progetto...
Sì, perché Django ce l'hai già a disposizione: devi soltanto... usarlo. :D
m4dbra1n
09-05-2009, 20:59
up!
usa Excel o Access con il VB integrato.
Dimentica VB e C++ (uno è poco portabile, l'altro è inutilmente complesso per quel che devi fare).
Mi sa proprio che Java fa al caso tuo. Visual Basic rispetto a Java non é cosi tanto poco portabile: l'unico supporto ufficiale che Java ha e VB no é quello per Linux ma per il resto VB funziona anche sui dispositivi mobili...
||ElChE||88
09-05-2009, 22:32
Visual Basic rispetto a Java non é cosi tanto poco portabile: l'unico supporto ufficiale che Java ha e VB no é quello per Linux ma per il resto VB funziona anche sui dispositivi mobili...
Eh be... dici poco. Ma Mac? :fagiano:
Eh be... dici poco. Ma Mac? :fagiano:
Ho un collega che ha Mac.
Mac di qui, Mac di la', Mac di su'.
E poi quando deve fare "qualcosa" passa sulla macchina virtuale con windows...
(PS: apro e chiudo qui. Non so praticamente nulla di Mac)
Eh be... dici poco. Ma Mac? :fagiano: eccone un altro che non conosce Rotor :fagiano:
eccone un altro che non conosce Rotor :fagiano:
Aggiungi pure due posti a tavola. Che cacchio è rotor? :D
Ho un collega che ha Mac.
Mac di qui, Mac di la', Mac di su'.
E poi quando deve fare "qualcosa" passa sulla macchina virtuale con windows...
(PS: apro e chiudo qui. Non so praticamente nulla di Mac)
Ecco, se non sai, meglio non parlare ;)
Ecco, se non sai, meglio non parlare ;)
Ma vedo... vedo lui con la macchina virtuale. :)
^TiGeRShArK^
10-05-2009, 03:17
Ma vedo... vedo lui con la macchina virtuale. :)
se programma per windows ci credo :doh:
anche io quando devo usare visual studio faccio partire parallels oppure rebootto con bootcamp in windows 7.
Se devo programmare in java/python/ruby uso tranquillamente mac os x.
!k-0t1c!
10-05-2009, 11:07
Senza nulla togliere alle soluzioni proposte fin'ora, vorrei suggerirti di usare VB.NET o C# e SQL Server Express.
I vantaggi sono i seguenti:
La sintassi di tutti e due i linguaggi ti sembrerà già familiare
L'interfaccia grafica la puoi disegnare facilmente con Visual Studio
Il database lo crei in Visual Studio agevolmente con pochi click e il Data Access Layer lo crei trascinando le varie tabelle in un diagramma (niente di più semplice, davvero)
Fatto quanto detto nel punto precedente ti servirà scrivere davvero poche righe di codice (essenzialmente la logica del tuo applicativo) ed avrai finito, senza esserti dovuto sporcare le mani con le grane peggiori.
m4dbra1n
10-05-2009, 16:41
eccone un altro che non conosce Rotor :fagiano:
Neanche io so cos'è :D illuminateci, anche se si va OT
Senza nulla togliere alle soluzioni proposte fin'ora, vorrei suggerirti di usare VB.NET o C# e SQL Server Express.
I vantaggi sono i seguenti:
La sintassi di tutti e due i linguaggi ti sembrerà già familiare
L'interfaccia grafica la puoi disegnare facilmente con Visual Studio
Il database lo crei in Visual Studio agevolmente con pochi click e il Data Access Layer lo crei trascinando le varie tabelle in un diagramma (niente di più semplice, davvero)
Fatto quanto detto nel punto precedente ti servirà scrivere davvero poche righe di codice (essenzialmente la logica del tuo applicativo) ed avrai finito, senza esserti dovuto sporcare le mani con le grane peggiori.
Avevo pensato infatti di andare su .net, vorrei provare la versione express del visual studio 2008 e vedere che ci esce...
Microsoft Rotor é un'implementazione ufficiale di .NET con licenza shared source fatta in maniera tale che per essere portata su nuove architetture sia sufficiente reimplementare uno strato (detto PAL, Platform Abstraction Layer) il piu sottile possibile; la cosa importante é che l'implementazione ufficiale di Microsoft comprende anche un PAL per Mac.
m4dbra1n
10-05-2009, 17:53
Microsoft Rotor é un'implementazione ufficiale di .NET con licenza shared source fatta in maniera tale che per essere portata su nuove architetture sia sufficiente reimplementare uno strato (detto PAL, Platform Abstraction Layer) il piu sottile possibile; la cosa importante é che l'implementazione ufficiale di Microsoft comprende anche un PAL per Mac.
Grazie x la spiegazione :D
!k-0t1c!
10-05-2009, 18:01
Avevo pensato infatti di andare su .net, vorrei provare la versione express del visual studio 2008 e vedere che ci esce...
Ottima scelta, se te la senti prova addirittura C# e non VB.NET (su internet troverai comunque molto più materiale per C# che per VB.NET) e vedrai che non è affatto ostico. In ogni caso sono sicuro che troverai la creazione del DB e l'uso di LINQ-to-SQL molto intuitivi e questo certamente taglierà il tempo di sviluppo :)
m4dbra1n
10-05-2009, 18:20
Chiedo venia, ho detto una pirlata: le versioni express sono solo x le singole parti del visual studio :P
Cmq adesso mi scarico i vari express e vedo quale usare
Ho notato invece che x quanto riguarda la componente SQL, c'è sia la versione express 2008 che la compact, che penso sia migliore per la redistribuzione, in quanto il setup occupa max 5 MB
Potete dirmi quali sono le differenze tra la versione express 2008 e la compact dell'SQL Server? A parte, da quello che ho capito io, la portabilità...
PS: quale versione dovrei scaricare dell'SQL Server? Basta solo il runtime o devo scaricare il pacchetto completo? Guardate qui link (http://www.microsoft.com/express/sql/download/)
!k-0t1c!
10-05-2009, 19:14
SQL Server Express, non compact. Compact ha un sacco di limitazioni, tra cui l'impossibilità di accesso simultaneo (credo sia in lettura sia in scrittura) da più utenti e il fatto che il designer di LINQ-to-Entities non supporta SQL Compact. Inoltre sul PC di sviluppo ti consiglio l'edizione Express with Tools.
||ElChE||88
10-05-2009, 20:17
Microsoft Rotor é un'implementazione ufficiale di .NET con licenza shared source fatta in maniera tale che per essere portata su nuove architetture sia sufficiente reimplementare uno strato (detto PAL, Platform Abstraction Layer) il piu sottile possibile; la cosa importante é che l'implementazione ufficiale di Microsoft comprende anche un PAL per Mac.
Rotor?
Questo? (http://en.wikipedia.org/wiki/Rotor_(software_project))
Sembra più indietro di Mono.
m4dbra1n
10-05-2009, 21:38
Rotor?
Questo? (http://en.wikipedia.org/wiki/Rotor_(software_project))
Sembra più indietro di Mono.
Di Mono avevo sentito parlare; andando sul sito ho visto che supporta tantissimi linguaggi di programmazione e vari ambienti di sviluppo: comodissimo :D
Ho visto però che ci sono 2 entità da scaricare: Mono e MonoDevelop x C# e .net. Avendo lasciato da tempo la programmazione, mi spiegate perché?
Thanks :D
||ElChE||88
10-05-2009, 21:47
Di Mono avevo sentito parlare; andando sul sito ho visto che supporta tantissimi linguaggi di programmazione e vari ambienti di sviluppo: comodissimo :D
Ho visto però che ci sono 2 entità da scaricare: Mono e MonoDevelop x C# e .net. Avendo lasciato da tempo la programmazione, mi spiegate perché?
Thanks :D
MonoDevelop è l'IDE (l'editor insomma).
m4dbra1n
11-05-2009, 00:25
MonoDevelop è l'IDE (l'editor insomma).
Se MonoDevelop è l'IDE, Mono è un framework multi-linguaggio?
Mi sa che devo informarmi meglio da qualche parte :(
Che ignoranza :cry:
!k-0t1c!
11-05-2009, 01:48
Mono è un'implementazione che punta ad essere pienamente compatibile con lo standard CIL come definito in ECMA 335 e come implementato da Microsoft.
Poi aggiunge qualche fronzolo qua e la, ma il succo è questo. Diciamo che di fatto è usata come piattaforma per supportare applicativi .NET in ambienti non windows. E' da notare che, tuttavia, sono presenti numerosi e gravi bugs che impediscono un'esecuzione "liscia" di un'enorme numero di programmi. Grazie alla sponsorizzazione da parte di Novell si spera tuttavia che questi problemi siano risolti in tempi ragionevoli per acquisire compatibilità realmente cross-platform di tutti gli applicativi e delle librerie che non fanno uso di tecnologie troppo strettamente legate a windows per essere implementate altrove.
m4dbra1n
11-05-2009, 02:01
Grazie ancora per tutte le spiegazioni ;)
Vorrei saperne di + su 2 linguaggi specifici di cui si legge bene in giro ma che non ho mai provato: Python e Ruby.
Ci sono differenze per cui scegliere uno più che l'altro? Il codice è + leggibile e pulito di altri? Hanno dei moduli in meno rispetto ad altri linguaggi per cui occorre fare salti mortali per implementarli?
Python l'avevo anche installato tempo fa, ma poi non avendo tempo e voglia la sera che tornavo da lavoro ho lasciato stare :fiufiu:
cdimauro
11-05-2009, 08:04
Grazie ancora per tutte le spiegazioni ;)
Vorrei saperne di + su 2 linguaggi specifici di cui si legge bene in giro ma che non ho mai provato: Python e Ruby.
Ci sono differenze per cui scegliere uno più che l'altro?
Ovviamente la sintassi in primis. :D
Qui si va su una questione di gusti. Ad esempio, c'è chi vuole i blocchi esplicitamente (Ruby usa la keyword "end" per questo) e chi adora i blocchi che sfruttano soltanto l'indentazione (soluzione di Python). Ci sono quelli a cui piace avere più strumenti per fare la stessa cosa (Ruby; di derivazione PERL come filosofia) e quelli a cui piace "one and only one way" Python. E così via, son tante le cose di cui si potrebbe parlare.
Personalmente trovo la sintassi di Python molto più chiara e leggibile.
A parte questo, Python ha dei tipi di dati più ricchi e in generale una libreria standard molto più vasta, e queste cose ti possono portare a scrivere codice più velocemente.
Il codice è + leggibile e pulito di altri?
Di gran lunga.
Hanno dei moduli in meno rispetto ad altri linguaggi per cui occorre fare salti mortali per implementarli?
Come dicevo prima, Python è abbatanza dotato. Poi è ovvio che paragonato a Java ha molta meno roba, e nei casi in cui serva in genere si supplisce con librerie esterne (nel sito ufficiale c'è un ricco repository facilmente consultabile).
Python l'avevo anche installato tempo fa, ma poi non avendo tempo e voglia la sera che tornavo da lavoro ho lasciato stare :fiufiu:
Allora visto che l'hai installato... torna a provarlo. :D
Poi se hai problemi puoi chiedere pure qui, dove ormai trovai un bel po' di utenti che usano o hanno imparato questo linguaggio. :)
^TiGeRShArK^
11-05-2009, 09:02
Allora visto che l'hai installato... torna a provarlo. :D
OT tutto a posto in quel di firenze? :p
cdimauro
11-05-2009, 11:22
E' andato benissimo, ben oltre le mie aspettative. :)
Vediamo se riesco a fare un articolo per AD (per questo mercoledì) in cui ne parlo, così vi racconto un po' come ho passato questi giorni.
E' andato benissimo, ben oltre le mie aspettative. :)
Vediamo se riesco a fare un articolo per AD (per questo mercoledì) in cui ne parlo, così vi racconto un po' come ho passato questi giorni.
Cos'è AD? Sono molto curioso comunque! :) Purtroppo mi sono perso la conferenza :(
"l'uso del typing statico conduce al dover conoscere le differenze tra i vari type" - ekerazha
Ma LOL! :D Dai smettila di sparare sulla croce rossa!
!k-0t1c!
11-05-2009, 12:00
Pur apprezzando Python e capendo il senso del dynamic typing vorrei sottolineare quanto in diversi contesti sia preferibile lo static typing, e a tal proposito rimando i curiosi all'intervista ai creatori di Twitter sul perché anno abbandonato ruby per passare a Scala
banryu79
11-05-2009, 12:27
e a tal proposito rimando i curiosi all'intervista ai creatori di Twitter sul perché anno abbandonato ruby per passare a Scala
Potresti rimandarci postando il link?
cdimauro
11-05-2009, 12:29
Cos'è AD? Sono molto curioso comunque! :)
Appunti Digitali (http://www.appuntidigitali.it/).
E' un blog tecnologico (legato sempre ad hwupgrade) e faccio parte della redazione (ho una rubrica fissa per il mercoledì pomeriggio).
Visto che si parla di tecnologia, penso possa essere molto interessante.
Purtroppo mi sono perso la conferenza :(
Fra qualche mese dicono metteranno i video. Speriamo bene (per la scorsa PyCon abbiamo aspettato quasi un anno).
Ma LOL! :D Dai smettila di sparare sulla croce rossa!
Ipse dixit :fiufiu: :p
Pur apprezzando Python e capendo il senso del dynamic typing vorrei sottolineare quanto in diversi contesti sia preferibile lo static typing, e a tal proposito rimando i curiosi all'intervista ai creatori di Twitter sul perché anno abbandonato ruby per passare a Scala
Sarà sicuramente interessante, ma come giustamente dici tu, dipende dal contesto.
A parte questo, faccio presente che realtà "di spessore" come Google, YouTube, Yahoo, Microsoft, IBM e persino la NASA facciano ampio uso di Python, per cui evidentemente gli svantaggi sono decisamente inferiori rispetto ai vantaggi. ;)
Pur apprezzando Python e capendo il senso del dynamic typing vorrei sottolineare quanto in diversi contesti sia preferibile lo static typing, e a tal proposito rimando i curiosi all'intervista ai creatori di Twitter sul perché anno abbandonato ruby per passare a Scala
Non penso fosse solo una questione di dynamic vs static typing.
Considera anche che Alex Payne (il ragazzo che sta dietro all'API di twitter), sta scrivendo un libro su Scala :)
banryu79
11-05-2009, 12:33
Non penso fosse solo una questione di dynamic vs static typing.
Considera anche che Alex Payne (il ragazzo che sta dietro all'API di twitter), sta scrivendo un libro su Scala :)
Minchia, è il fratello del più celbre Max?! :D
[ok, super OT e super cazzata del lunedì mattina]
cdimauro
11-05-2009, 12:57
Non penso fosse solo una questione di dynamic vs static typing.
Considera anche che Alex Payne (il ragazzo che sta dietro all'API di twitter), sta scrivendo un libro su Scala :)
Questo potrebbe far pensare (male :D), ma per me non è una pregiudiziale.
Preferisco leggere le motivazioni, appena saranno disponibili.
CozzaAmara
11-05-2009, 13:00
Potresti rimandarci postando il link?
http://www.techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/
http://www.artima.com/scalazine/articles/twitter_on_scala.html
forse si riferiva a questa.
m4dbra1n
11-05-2009, 13:14
Mi fa piacere che il mio thread d'aiuto sia diventata una piccola piazzetta :)
Solo che parlate di tante cose che nn conosco, tipo SCALA: urge informarmi, anche solo per mia curiosità :D
cdimauro
11-05-2009, 13:26
http://www.artima.com/scalazine/articles/twitter_on_scala.html
forse si riferiva a questa.
Letto tutto.
Il problema principale a quanto pare sono le prestazioni.
Poi ci sono dei problemi che riguardano Ruby, e altri che trattano i linguaggi dinamici in generale.
Ci sarebbe di che disquisire, perché alcune cose sono condivisibili, altre no. Anche perché possono essere legate, ad esempio, all'implementazione del linguaggio e non al linguaggio di per sé.
Scala è un linguaggio staticamente tipato, funzionale imperativo e OO (multiprospettiva insomma).
http://www.scala-lang.org/
In rete trovi le solite cose: è più bello, è più conciso, è più sintetico. Naturalmente è fuffa.
Supporta i funtori (le funzioni come tipi di dato), ha una punta di "type inference" (posso evitare di dire: "Int x" se dal contesto risulta che x non possa che essere un Int), ha le case class che sono una specie di pattern matching sui tipi e tante altre cose.
Gira sulla piattaforma Java ed è in grado di usare il parco librerie di quest'ultima.
Una delle cose interessanti che lo riguardano è il fatto che a volte i programmi scala risultano un pelo più performanti dei programmi Java. E' bizzarro considerando che il byte code della JVM è "incline" al linguaggio Java.
Purtroppo ci hanno già fatto un web framework, quindi andrà a ramengo come tutte le buone idee quando incontrano i server web.
banryu79
11-05-2009, 13:42
Letto: molto interesante!
Ci sarebbe di che disquisire, perché alcune cose sono condivisibili, altre no. Anche perché possono essere legate, ad esempio, all'implementazione del linguaggio e non al linguaggio di per sé.
Sì, questo è il nocciolo della questione secondo me e sono parzialmente d'accordo.
Nell'intervista emerge chiaramente che è il motivo delle pure prestazioni del back-end ad aver creato la necessità di switchare da Ruby a qualcos'altro.
Ma nell'approfondire le motivazioni, da quello che Payne e gli altri dicono io ho capito che per quella parte ben precisa di software passare a un type system statico è stato un sollievo, nel senso che prima invece si lavorara con un type system dinamico e questa caratteristica dava dei grattacapi in più.
!k-0t1c!
11-05-2009, 14:08
Sì, questo è il nocciolo della questione secondo me e sono parzialmente d'accordo.
Nell'intervista emerge chiaramente che è il motivo delle pure prestazioni del back-end ad aver creato la necessità di switchare da Ruby a qualcos'altro.
Ma nell'approfondire le motivazioni, da quello che Payne e gli altri dicono io ho capito che per quella parte ben precisa di software passare a un type system statico è stato un sollievo, nel senso che prima invece si lavorara con un type system dinamico e questa caratteristica dava dei grattacapi in più.
Esattamente! A prescindere dalle performance (sarebbe unfair comparare tipizzazione statica e dinamica) il punto è che per la programmazione in-the-large la tipizzazione dinamica può diventare scomoda da gestire, specie se si vole fare un'accurata gestione delle eccezioni. Inoltre il fatto che il compilatore sia già in grado di dare informazioni su usi impropri e che l'intellisense faccia il suo lavoro ad un certo punto diventa molto comodo. La type inference ora molto di moda (F#, Haskell, OCaml, Scala etc) poi rende lo static typing meno verboso di quanto non sia tradizionalmente ;)
cosa intendi per "accurata gestione delle eccezioni"?
!k-0t1c!
11-05-2009, 14:18
cosa intendi per "accurata gestione delle eccezioni"?
Intendo una gestione che riesca a recuperare dal numero massimo di casi imprevisti la normale esecuzione e che quando ciò non sia possibile fornisca il numero massimo di informazioni per rintracciare la fonte del problema, dopodiché fallisca senza creare troppo ritardo, ed eventualmente consenta di informare in maniera rilevante e concisa l'utente dell'accaduto (qualora opportuno).
banryu79
11-05-2009, 14:22
Esattamente! A prescindere dalle performance...
Sono propenso ad essere parzialmente d'accordo anche con questa tua opinione.
Parzialmente, perchè stiamo comunque parlando di un caso specifico (quello documentato nell'intervista) dove quel tuo "a prescindere dalle performance" non si può di fatto prescindere: è il vero e primo motivo, a sentir loro, della scelta nel sostituire Ruby con qualcos'altro, per quel pezzo specifico dell'applicativo.
Facendo una deduzione logica posso supporre che, se fosse stato solo per il "problema" del type system non avrebbero sentito la neccessità di passare a qualcos'altro.
@EDIT:
Che poi il tipo di type system, e il modo in cui sono state gestite le problematiche che i problemi che questo tipo di type system ha generato durante la stesura del codice, in quella parte del sistema, abbia concorso nel determinare le non soddisfacenti prestazioni può anche starci.
Però l'osservazione di cdimauro sull'implementazione (efficiente) del linguaggio mi sembra maggiormente responsabile del loro problema.
Esattamente! A prescindere dalle performance (sarebbe unfair comparare tipizzazione statica e dinamica)
Non e' poi cosi' unfair. Ci sono linguaggi molto dinamici che permettono di ottimizzare le parti critiche del codice specificando esplicitamente i tipi, ottenendo performance paragonabili a quelle dei linguaggi completamente statici.
il punto è che per la programmazione in-the-large la tipizzazione dinamica può diventare scomoda da gestire, specie se si vole fare un'accurata gestione delle eccezioni.
In che senso ? Esempio ?
Inoltre il fatto che il compilatore sia già in grado di dare informazioni su usi impropri e che l'intellisense faccia il suo lavoro ad un certo punto diventa molto comodo.
Un buon IDE per un linguaggio dinamico mantiene una connessione aperta con un interprete sottostante per cui e' in grado di dare
un livello di informazioni paragonabile a quello che si ottiene un linguaggio statico.
!k-0t1c!
11-05-2009, 15:16
Edit: rimossa parte a causa di un fraintendimento nella lettura dell'affermazione a cui rispondevo
In che senso ? Esempio ?
Leggi il mio post sopra, è sbrigativo ma parlare di questo richiederebbe un topic a sé. Inoltre quante e quali eccezioni vadano gestite e come è oggetto di dibattiti ancora molto aperti, quindi cerco di non divagare e di restare sull'oggettivo.
Un buon IDE per un linguaggio dinamico mantiene una connessione aperta con un interprete sottostante per cui e' in grado di dare
un livello di informazioni paragonabile a quello che si ottiene un linguaggio statico.
cdimauro mi ha consigliato per Python Komodo IDE e dopo le mie lamentele riguardo ad un completamento carente mi ha detto che va già di lusso così. Se trovi un IDE che offra qualcosa di paragonabile all'intellisense che ho in Visual Studio anche solo per per F# - che è ancora in CTP ed ha un supporto per il completamento sintattico di cui si lamentano in tanti tra gli affezionati utenti di VS - allora fammi sapere. Quanto al conoscere gli errori prima dell'esecuzione prendi Visual Studio, aggiungi ReSharper e vedi cos'è possibile con la tipizzazione statica. Poi pensa di doverlo fare con un linguaggio tipizzato dinamicamente e impallidisci pure :)
Questo è vero solo su porzioni di codice altamente utilizzate e facilmente ottimizzabili (es. quelle di algoritmi computazionalmente complessi). Mediamente le performance sono inferiori perché il costo di utilizzare un compilatore JIT eccederebbe i benefici (vd. progetto IronPython che cerca il giusto bilanciamento).
Non ho mica capito cosa c'entri il fatto di avere un compilatore just-in-time con lo specificare i tipi dei dati in un linguaggio dinamico. Credo che Marco facesse un altro discorso...
cdimauro
11-05-2009, 15:51
Letto: molto interesante!
Sì, questo è il nocciolo della questione secondo me e sono parzialmente d'accordo.
Nell'intervista emerge chiaramente che è il motivo delle pure prestazioni del back-end ad aver creato la necessità di switchare da Ruby a qualcos'altro.
Esatto.
Ma nell'approfondire le motivazioni, da quello che Payne e gli altri dicono io ho capito che per quella parte ben precisa di software passare a un type system statico è stato un sollievo, nel senso che prima invece si lavorara con un type system dinamico e questa caratteristica dava dei grattacapi in più.
Credo sia dovuto all'estrema dinamicità di Ruby.
Per fare un esempio, con Ruby anche se scrivi 1 + 1 non sei mai sicuro che il risultato sia 2, e soprattutto che ti venga restituito un numero intero, perché puoi ridefinire gli operatori anche degli oggetti built-in.
E' indubbio che sia una caratteristica allettante nella misura in cui si possono arricchire le classi "primitive", ma al contempo è estremamente pericolosa.
Comunque altri linguaggi dinamici non soffrono di problematiche di questo tipo.
Intendo una gestione che riesca a recuperare dal numero massimo di casi imprevisti la normale esecuzione e che quando ciò non sia possibile fornisca il numero massimo di informazioni per rintracciare la fonte del problema, dopodiché fallisca senza creare troppo ritardo, ed eventualmente consenta di informare in maniera rilevante e concisa l'utente dell'accaduto (qualora opportuno).
Francamente non capisco perché non dovrebbe essere possibile con un linguaggio dinamico.
Mi faresti l'esempio di un caso in cui è possibile farlo con un linguaggio statico e, invece, no con un dinamico?
Sono propenso ad essere parzialmente d'accordo anche con questa tua opinione.
Parzialmente, perchè stiamo comunque parlando di un caso specifico (quello documentato nell'intervista) dove quel tuo "a prescindere dalle performance" non si può di fatto prescindere: è il vero e primo motivo, a sentir loro, della scelta nel sostituire Ruby con qualcos'altro, per quel pezzo specifico dell'applicativo.
Facendo una deduzione logica posso supporre che, se fosse stato solo per il "problema" del type system non avrebbero sentito la neccessità di passare a qualcos'altro.
La penso come te. Tra l'altro traspare proprio dall'intervista che la fonte principale dei problemi siano proprio le performance, perché avevano paventato anche l'ipotesi di abbandonare soltanto Ruby on Rails, rimanendo quindi a lavorare con Ruby.
@EDIT:
Che poi il tipo di type system, e il modo in cui sono state gestite le problematiche che i problemi che questo tipo di type system ha generato durante la stesura del codice, in quella parte del sistema, abbia concorso nel determinare le non soddisfacenti prestazioni può anche starci.
Però l'osservazione di cdimauro sull'implementazione (efficiente) del linguaggio mi sembra maggiormente responsabile del loro problema.
Sì, ma a parte questo credo si tratti anche di cattiva programmazione.
Perché se nel tuo codice ci troppi controlli per verificare il tipo di un oggetto passato, cosa di cui infatti si lamentano, a me si storce il naso: è indice di uno stile di programmazione che non si può certo definire "OOP".
Questo è vero solo su porzioni di codice altamente utilizzate e facilmente ottimizzabili (es. quelle di algoritmi computazionalmente complessi). Mediamente le performance sono inferiori perché il costo di utilizzare un compilatore JIT eccederebbe i benefici (vd. progetto IronPython che cerca il giusto bilanciamento).
Veramente di recente Google ha avviato un progetto per accelerare notevolmente le prestazioni dell'implementazione di Python: http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
Giusto in questi giorni alla PyCon ho scambiato due chiacchiere con uno degli sviluppatori, Fredrik Lundh, e hanno in mente grandi idee.
Fortunatamente le idee che ho implementato nella mia implementazione di Python (http://www.pycon.it/conference/talks/beyond-bytecode-a-wordcode-based-python) sono complementari/diverse, e credo saranno integrabili (non so se tutte) in esso, ottenendo ulteriori benefici.
A mio avviso c'è ancora molto da dare nel campo delle ottimizzazioni dei linguaggi dinamici, e sottolineo dinamici (quindi senza "aiuti" per specificare eventualmente il tipo di un dato).
cdimauro mi ha consigliato per Python Komodo IDE e dopo le mie lamentele riguardo ad un completamento carente mi ha detto che va già di lusso così. Se trovi un IDE che offra qualcosa di paragonabile all'intellisense che ho in Visual Studio anche solo per per F# - che è ancora in CTP ed ha un supporto per il completamento sintattico di cui si lamentano in tanti tra gli affezionati utenti di VS - allora fammi sapere. Quanto al conoscere gli errori prima dell'esecuzione prendi Visual Studio, aggiungi ReSharper e vedi cos'è possibile con la tipizzazione statica. Poi pensa di doverlo fare con un linguaggio tipizzato dinamicamente e impallidisci pure :)
Impallidire no: i risultati sono buoni, seppur inferiori rispetto a una soluzione per linguaggi statici.
Che soffrono anch'essi di problemi di intellisense, se si programma in maniera "peregrina".
Diciamo che con un codice abbastanza pulito / nei canoni, fanno discretamente il loro lavoro.
Di recente son passato ad Eclipse + PyDev. Sono ancora in sperimentazione, ma al momento mi trovo molto bene, specialmente per il completamento automatico, che è decisamente più efficiente e ben fatto. Finora non ho avuto problemi di "mistyping", e ciò mi sembra un ottimo indicatore delle possibilità che ci sono in questo campo anche per i linguaggi dinamici.
Francamente non capisco perché non dovrebbe essere possibile con un linguaggio dinamico.
La questione è un po' più complicata (cioè divertente) della semplice impossibilità.
E se non dovessi andare a tagliare il mio dannatissimo prato (fatene parcheggi, dico io!) ne parleremmo subito :D.
Dirò solo "pluggable type system".
cdimauro
11-05-2009, 16:04
Visto che non ho ancora capito, aspetterò che tu finisca di tagliare il prato. :D
!k-0t1c!
11-05-2009, 16:32
Francamente non capisco perché non dovrebbe essere possibile con un linguaggio dinamico.
Come ti è già stato fatto notare non è tanto una questione di possibilità quanto di semplicità (o complicatezza, in questo caso). Ribadisco che se vogliamo parlare di questo punto possiamo aprire un nuovo thread e sarò lieto di dimostrare come la conoscenza a priori di alcune informazioni su un tipo possono rendere molto rapido ed efficace del codice di gestione delle eccezioni.
Sì, ma a parte questo credo si tratti anche di cattiva programmazione.
Perché se nel tuo codice ci troppi controlli per verificare il tipo di un oggetto passato, cosa di cui infatti si lamentano, a me si storce il naso: è indice di uno stile di programmazione che non si può certo definire "OOP".
Hai mai considerato che possano essere controlli volti a fini di sicurezza?
Banalmente come per alcuni metodi si usa specificare che se un oggetto è null va lanciata un'eccezione in un linguaggio dinamico può aver senso specificare che se un oggetto non è di un certo tipo va fatto altrettanto (specie negli unit tests, indispensabili nella programmazione in the large).
Veramente di recente Google ha avviato un progetto per accelerare notevolmente le prestazioni dell'implementazione di Python: http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
Giusto in questi giorni alla PyCon ho scambiato due chiacchiere con uno degli sviluppatori, Fredrik Lundh, e hanno in mente grandi idee.
Fortunatamente le idee che ho implementato nella mia implementazione di Python (http://www.pycon.it/conference/talks/beyond-bytecode-a-wordcode-based-python) sono complementari/diverse, e credo saranno integrabili (non so se tutte) in esso, ottenendo ulteriori benefici.
A mio avviso c'è ancora molto da dare nel campo delle ottimizzazioni dei linguaggi dinamici, e sottolineo dinamici (quindi senza "aiuti" per specificare eventualmente il tipo di un dato).
Avevo già letto tutti e due gli articoli e pure eliminando il GIL ed abbandonando il bytecode temo che anche con queste ottimizzazioni le performance non saranno ancora paragonabili, tuttavia mi sembra più ragionevole mantenere il discorso su tecnologie che sono stabili ed in uso e non sul livello dei prototipi.
Impallidire no: i risultati sono buoni, seppur inferiori rispetto a una soluzione per linguaggi statici.
Che soffrono anch'essi di problemi di intellisense, se si programma in maniera "peregrina".
Diciamo che con un codice abbastanza pulito / nei canoni, fanno discretamente il loro lavoro.
Di recente son passato ad Eclipse + PyDev. Sono ancora in sperimentazione, ma al momento mi trovo molto bene, specialmente per il completamento automatico, che è decisamente più efficiente e ben fatto. Finora non ho avuto problemi di "mistyping", e ciò mi sembra un ottimo indicatore delle possibilità che ci sono in questo campo anche per i linguaggi dinamici.
L'impallidire non era sul risultato ma sullo sforzo per sviluppare qualcosa di vagamente paragonabile, che infatti ad oggi non esiste.
Per quel che ho provato io appena si inizia ad usare un minimo di method chaining, comunque, il completamento va a farsi benedire ed lo stesso fa il rilevamento degli errori. Spero comunque in un'evoluzione del campo, per quanto il problema sia oggettivamente più ostico che per un linguaggio statico (questo credo sia *ovvio*).
@shynia: giusto, editato, mi ero saltato non so perché qualche parola e avevo interpretato diversamente. Certo comunque dover specificare i tipi in maniera statica all'interno di un linguaggio dinamico per avere performance paragonabili a quelle di linguaggi tipizzati staticamente vuol dire alzare bandiera bianca sulle pefrormance del linguaggio dinamico stesso...
banryu79
11-05-2009, 16:51
@shynia: giusto, editato, mi ero saltato non so perché qualche parola e avevo interpretato diversamente. Certo comunque dover specificare i tipi in maniera statica all'interno di un linguaggio dinamico per avere performance paragonabili a quelle di linguaggi tipizzati staticamente vuol dire alzare bandiera bianca sulle pefrormance del linguaggio dinamico stesso...
Io la vedo più come un "usare lo strumento giusto al posto e al momento giusto".
Cioè versatilità.
Questo se si parte dall'ipotesi che, in un linguaggio di programmazione, il fatto di avere a disposizione un sistema dei tipi dinamico fornisce un utilità. (Sospetto che, come in molte altre situazioni, al di là dei gusti personali, si tratti sempre di un trade-off: ci sono circostanze dove l'uno è più conveniente dell'altro).
@EDIT:
non so cosa sia un "pluggable type system", ma dal nome mi suona proprio come un qualcosa che mi offre una possibilità di scelta.
Siete andati come al solito OT :D
Sto ancora aspettando qualcuno che abbia voglia di scrivere un post per questo thread: http://www.hwupgrade.it/forum/showthread.php?t=1979444
Almeno la finiamo con questi thread che alla fine si traducono in discussioni molto interessanti per gli esperti, ma poco interessanti per chi ha fatto la richiesta.
Non che la discussione non sia interessante, ma sarebbe meglio discuterne in thread separati ;)
cdimauro
11-05-2009, 17:12
Come ti è già stato fatto notare non è tanto una questione di possibilità quanto di semplicità (o complicatezza, in questo caso). Ribadisco che se vogliamo parlare di questo punto possiamo aprire un nuovo thread e sarò lieto di dimostrare come la conoscenza a priori di alcune informazioni su un tipo possono rendere molto rapido ed efficace del codice di gestione delle eccezioni.
Va benissimo, apri pure il thread, perché l'argomento mi sembra interessante.
Hai mai considerato che possano essere controlli volti a fini di sicurezza?
Banalmente come per alcuni metodi si usa specificare che se un oggetto è null va lanciata un'eccezione in un linguaggio dinamico può aver senso specificare che se un oggetto non è di un certo tipo va fatto altrettanto (specie negli unit tests, indispensabili nella programmazione in the large).
Vero, ma le unit test servono a effettuare proprio questi test.
E la programmazione a oggetti, col polimorfismo, a eliminare i controlli di cui si parlava.
Avevo già letto tutti e due gli articoli e pure eliminando il GIL ed abbandonando il bytecode temo che anche con queste ottimizzazioni le performance non saranno ancora paragonabili, tuttavia mi sembra più ragionevole mantenere il discorso su tecnologie che sono stabili ed in uso e non sul livello dei prototipi.
Le prestazioni non saranno mai comparabili, ma sicuramente abbastanza elevate da non impedire a priori l'adozione di un linguaggio dinamico come Python.
Per lo meno offrirà ottimi spunti di riflessione anche a chi è abbastanza orientato sui linguaggi statici.
A parte che, come per tutte le cose, le prestazioni sono EVENTUALMENTE un requisito di un progetto.
Per quanto riguarda la rimozione del GIL, è ancora da vedere (e non è il mio obiettivo :D).
Comunque non si tratta esattamente di prototipi. Il progetto di Google ha delle milestone, e già la prima è stata raggiunta.
Nel mio caso, avevo una sola milestone, ed è stata praticamente raggiunta (ho delle cose da fixare, ma a parte questo funziona tutto). :cool:
L'impallidire non era sul risultato ma sullo sforzo per sviluppare qualcosa di vagamente paragonabile, che infatti ad oggi non esiste.
Per quel che ho provato io appena si inizia ad usare un minimo di method chaining, comunque, il completamento va a farsi benedire ed lo stesso fa il rilevamento degli errori. Spero comunque in un'evoluzione del campo, per quanto il problema sia oggettivamente più ostico che per un linguaggio statico (questo credo sia *ovvio*).
La situazione non è così disperata, te l'assicuro. Tu prova PyDev e poi mi dici. :cool:
@shynia: giusto, editato, mi ero saltato non so perché qualche parola e avevo interpretato diversamente. Certo comunque dover specificare i tipi in maniera statica all'interno di un linguaggio dinamico per avere performance paragonabili a quelle di linguaggi tipizzati staticamente vuol dire alzare bandiera bianca sulle pefrormance del linguaggio dinamico stesso...
Infatti se ne può fare anche a meno, offrendo ugualmente prestazioni elevate e accettabili. ;)
cdimauro
11-05-2009, 17:13
Siete andati come al solito OT :D
Sto ancora aspettando qualcuno che abbia voglia di scrivere un post per questo thread: http://www.hwupgrade.it/forum/showthread.php?t=1979444
Almeno la finiamo con questi thread che alla fine si traducono in discussioni molto interessanti per gli esperti, ma poco interessanti per chi ha fatto la richiesta.
Non che la discussione non sia interessante, ma sarebbe meglio discuterne in thread separati ;)
Hai ragione.
Per il thread segnalato, appena torno a Catania scrivo qualcosa. :D
L'ot è più presunto che reale. Forse è perchè si tende al "parlar forbito" e gli argomenti sembrano diventare oscuri. In verità sono questioni semplicissime e dovrebbero interessare a chi si accinga a scegliere un linguaggio se non altro per capire cosa si stia maneggiando una volta che la scelta sia stata fatta.
Signori, sarò breve! (disse appoggiando sul tavolo trecento fogli di appunti).
L'impossibilità a cui mi riferisco quando parlo di linguaggi dinamicamente tipati è l'impossibilità di fornire al programmatore informazioni sulle operazioni che possono essere compiute su un certo dato.
E' un'impossibilità di principio e deriva dal fatto che quando parliamo di "assenza di un tipo" in compilazione in verità parliamo di "presenza di ogni tipo".
Giusto per non tralasciare i dettagli, con il termine "tipo" nei linguaggi di programmazione si intende un insieme di operazioni applicabili agli elementi dell'insieme di tutti i valori computabili. La definizione di questo insieme di operazioni genera un sottoinsieme: di tutti i valori computabili considero solo quelli che possono partecipare alle operazioni definite.
Ebbene in un linguaggio dinamicamente tipato mancano quei sottoinsiemi ergo ogni valore appartiene all'insieme di tutti i valori computabili, cioè di tutti i valori su cui possono essere compiute delle operazioni.
Ora se su ogni valore posso compiere qualsiasi operazione non solo le funzioni di autocompletamento di un IDE sono in linea di principio arbitrarie ma lo stesso IDE non può comprovare l'esattezza di ciò che scrivo al di là della mera idoneità sintattica.
Se prendiamo Python, ad esempio, l'invocazione x.unMetodoCheNonEsiste() non è provabilmente errata e un IDE che tentasse di dirlo tenterebbe una stupidaggine perchè deve considerare la possibilità che il tipo di x sovrascriva getattr.
La questione è anche più delicata dal punto di vista dell'esecuzione. La divisione dell'insieme dei valori computabili in tipi e la definizione di relazioni tra questi costituisce la struttura del programma. In linguaggio staticamente tipato questa struttura è comprovabile durante la scrittura del programma. Io posso escludere l'idoneità di un valore alla circolazione all'interno di un certo ramo del software che scrivo perchè quell'idoneità è espressa dalla presenza o assenza dello operazioni a cui parteciperebbe nel suo tipo. In un linguaggio dinamicamente tipato manca questa prova di idoneità.
Quindi i linguaggi "dinamici" fanno schifo e bisogna assolutamente evitarli? Assolutamente no. Bisogna, come per ogni cosa, studiarli con grande attenzione. Facendolo si arriva a soluzioni come il citato pluggable type system.
Come tutte le soluzioni eleganti è "intuitiva".
Un sistema di tipi opzionale per un linguaggio dinamicamente tipato parte dalla considerazione che la definizione del tipo a cui appartiene un dato è un meta-dato e questo metadato è usato dal programmatore e dal compilatore per comprovare la validità di un valore come operando.
Annotando i valori con il meta-dato costituito dalla dichiarazione del suo tipo e preprocessando il codice si ottiene quella comprovabilità strutturale che è una conseguenza della tipazione statica senza obbligare l'intero sistema ad esserne partecipe. Le stesse annotazioni possono essere usate da un compilatore ad hoc per bypassare il collegamento dinamico tra un valore ed il suo tipo. Si tratta di un esperimento già eseguito con successo sulla piattaforma Smalltalk (vedi StrongTalk) da Sun Microsystem.
Paradossalmente potremmo dire che l'uso di un linguaggio dinamicamente tipato richiede una conoscenza dei tipi molto più approfondita di quella necessaria per l'uso di un linguaggio staticamente tipato perchè nel primo caso non c'è nessuno che controlla per noi. Volendo, tuttavia, si possono tranquillamente creare strumenti che lo facciano.
banryu79
11-05-2009, 18:22
Signori sarò breve: :sbavvv: Comunque non ho ancora capito cos'è un pluggable type system.
Ad esser franco, speravo di poter godere di una tua spiegazione, PGI.
L'alternativa è appellarsi a Google e leggere ciò che il fato mi propone tra le prime 10 entry dei risultati della ricerca: fattibile, ma meno interessante di un tuo post :D
!k-0t1c!
11-05-2009, 18:27
Congratulazioni PGI, molto eloquente :)
Comunque non ho ancora capito cos'è un pluggable type system.
Con il termine "type system" ci si riferisce ad un qualsiasi insieme di dichiarazioni di tipo che siano in qualche modo tra loro correlate.
Ad esempio l'insieme delle dichiarazioni di classi e interfacce standard di Java costituiscono il suo type system così come è un type system l'insieme di dichiarazioni di classi e modulli standard in Python ed allo stesso modo è un type system l'insieme delle dichiarazioni di tipi di dato contenuti nelle specifiche C.
Il "pluggable" type system è un sistema di tipi, cioè un insieme di dichiarazioni di tipi di dato, definito come una libreria del linguaggio anzichè come parte del linguaggio stesso comprovabile attraverso uno strumento di verifica del codice sorgente.
Si tratta "banalmente" di definire i tipi come annotazioni, annotare il codice dove si vuole che sia considerata la tipazione e far controllare ad uno programma ad hoc, che può benissimo essere un modulo dell'IDE, che le operazioni compiute su un valore annotato siano presenti nella dichiarazione di tipo-annotazione.
E' come dire che se ho:
var x;
non posso dire che operazioni posso compiere su x perchè x supporta ogni genere di operazione ma se dico:
@Number var x;
e posso rincondurre a @Number le operazioni "+" e "-" allora posso anche far controllare ad un programma che "x" partecipi esclusivamente alle operazioni "+" e "-".
Non è un caso che tra gli usi delle annotazioni in Python 3.0 sembri essere citata anche il controllo (presuppongo statico) dei tipi.
cdimauro mi ha consigliato per Python Komodo IDE e dopo le mie lamentele riguardo ad un completamento carente mi ha detto che va già di lusso così. Se trovi un IDE che offra qualcosa di paragonabile all'intellisense che ho in Visual Studio anche solo per per F# - che è ancora in CTP ed ha un supporto per il completamento sintattico di cui si lamentano in tanti tra gli affezionati utenti di VS - allora fammi sapere. Quanto al conoscere gli errori prima dell'esecuzione prendi Visual Studio, aggiungi ReSharper e vedi cos'è possibile con la tipizzazione statica. Poi pensa di doverlo fare con un linguaggio tipizzato dinamicamente e impallidisci pure :)
Non ho mai trovato un editor decente per un linguaggio dinamico in stile python, ruby etc. Ma per linguaggi come lisp ce ne sono e alcuni ide commerciali fanno faville. Bisogna tenere inoltre presente che il ciclo di sviluppo con un linguaggio dinamico e' totalmente diverso. Non c'e' "un prima dell'esecuzione". C'e' sempre un interprete attivo che esegue e mi dice tutto. Non vado a guardare i metodi definiti dall'interfaccia dell'oggetto, ma prendo (ho gia') un oggetto di test su cui faccio l'inspect, e magari l'autocompletamento fuzzy dei metodi. Detto questo mi fermo e resto in attesa dei thread relativi, siamo effettivamente OT :P
cdimauro
11-05-2009, 21:20
Non è un caso che tra gli usi delle annotazioni in Python 3.0 sembri essere citata anche il controllo (presuppongo statico) dei tipi.
Piccolissima nota "di servizio". No, sono soltanto annotazioni utili per arricchire la descrizione degli argomenti o del valore di ritorno di una funzione / metodo.
Non vengono assolutamente usate per specificare il tipo del parametro.
Python attualmente non ha alcuna forma di tipizzazione statica, ma fortunatamente ci sono diversi literal (letterali) del lexical analyzer e alcuni costrutti del linguaggio che consentono di fissare in maniera precisa il tipo degli oggetti specificati. Insomma, si può fare la "classica" type inference. :D
Chiusa nota di servizio. :)
banryu79
12-05-2009, 18:08
Grazie PGI,
sempre preciso ed esaustivo :)
Il "pluggable" type system è un sistema di tipi, cioè un insieme di dichiarazioni di tipi di dato, definito come una libreria del linguaggio anzichè come parte del linguaggio stesso comprovabile attraverso uno strumento di verifica del codice sorgente.
Praticamente, se non ho frainteso o tratto deduzioni errate, quello che permetterebbe è di spostare il controllo dei tipi di un sorgente da "compile time" a "pre-compile time"; oltre a permettere l'utilizzo di un type system importato come libreria, e quindi, teoricamente, "moduli" diversi dello stesso sorgente-applicativo potrebbero utilizzare diverse definizioni di insiemi dei tipi.
Ciò permetterebbe una sorta di specificità/specializzazione maggiore nelle diverse partizioni logiche/funzionali di un applicativo andando a fornire allo sviluppatore uno strumento la cui utilità potrebbe, per natura, essere paragonata, almeno parzialmente, a quella che si ottiene con l'utilizzo dei DSL in un progetto?
Si tratta "banalmente" di definire i tipi come annotazioni, annotare il codice dove si vuole che sia considerata la tipazione e far controllare ad uno programma ad hoc, che può benissimo essere un modulo dell'IDE, che le operazioni compiute su un valore annotato siano presenti nella dichiarazione di tipo-annotazione.
Ok, mi è chiaro.
Mi viene in mente questa riflessione: un pluggable type system arrecherebbe vantaggio a un "linguaggio con sistema dei tipi dinamico" perchè permetterebbe, a discrezione dello sviluppatore, di introdurre un controllo dei tipi in parti specifiche del sorgente, la dove ritiene auspicabile una maggiore garanzia in tal senso; viceversa gli continuerebbe a lasciare la liertà di non annotare per forza le variabili che dichiara e usa.
Un pluggable type system porterebbe dei vantaggi anche a un "linguaggio con sistema dei tipi statico"?
Della serie che, se da un lato costringe ad annotare sempre tutte le variabili, dall'altro potrebbe continuare a permettere, vista la sua natura "pluggable" (importatato come libreria), l'utilizzo di diverse librerie dei tipi in diverse parti del sorgente?
Oppure non avrebbe semplicemente più senso parlare di static e dynamic type system?
Ultima domanda, e poi la smetto: attualmente, sia in un linguaggio con type system statico, che in un linguaggio con type system dinamico, durante la compilazione del sorgente, "quando" e da parte "di chi" avviene il controllo sulla correttezza dei tipi?
Se un linguaggio supportasse un "pluggable type system", e il controllo venisse effettuato da un software apposito che si manifesta come un modulo dell'IDE a "pre-compile time", questo cambiamento porterebbe a una semplificazione del modulo software facente parte del processo di compilazione "tradizionale" che prima aveva la responsabilità di fare questo controllo?
Scusate la densità di domande ma l'argomento mi affascina e la mia ignoranza in materia è grande.
@EDIT
La questione è un po' più complicata (cioè divertente) della semplice impossibilità.
E se non dovessi andare a tagliare il mio dannatissimo prato (fatene parcheggi, dico io!) ne parleremmo subito .
Dirò solo "pluggable type system".
Magari avrò sparato tante ipotesi-cazzata, qui sopra, ma adesso mi pare di intuire meglio questo tuo intervento, considerato nel consteso a cui si faceva riferimento all'epoca (ieri sera) del tuo post.
m4dbra1n
12-05-2009, 19:03
Siete andati come al solito OT :D
Sto ancora aspettando qualcuno che abbia voglia di scrivere un post per questo thread: http://www.hwupgrade.it/forum/showthread.php?t=1979444
Almeno la finiamo con questi thread che alla fine si traducono in discussioni molto interessanti per gli esperti, ma poco interessanti per chi ha fatto la richiesta.
Non che la discussione non sia interessante, ma sarebbe meglio discuterne in thread separati ;)
Si è vero sono andati OT, e a dir la verità mi sono 1 pò perso dopo alcuni post :D
Tra l'altro chiedo scusa, non avevo visto l'altro thread altrimenti avrei chiesto lì :muro:
Cmq, prima che iniziassero a divagare verso lidi per me sconosciuti :D , una mano per capire meglio mi è stata data, per cui:
THANKS EVERYBODY ;)
Lì non puoi postare, presto, spero, ci saranno i contributi di tutti gli utenti più esperti ;)
PS: In C#, versione 4.0, sono stati inseriti i tipi dinamici, con valutazione ovviamente solo run-time, per i fan del weak-type (ma anche per i non-fan, in alcune comode occasioni)
cdimauro
13-05-2009, 08:43
Il weak typing però è un'altra cosa. Quello offerto da C# 4.0 mi sembra più che altro il classico dynamic typing.
Python, ad esempio, è un linguaggio dinamico, ma strongly typed. Non è weak typed.
banryu79
13-05-2009, 09:17
Python, ad esempio, è un linguaggio dinamico, ma strongly typed. Non è weak typed.
Ho trovato questa pagina (http://wiki.python.org/moin/StrongVsWeakTyping) interessante, circa il dibattito su cosa considerare valida come definizione di weak type (gioisci: è un'estratto di post di vari thread di comp.lang.python).
cdimauro
13-05-2009, 10:57
Molto interessante. Grazie per il link.
Da tutto ciò penso che sia sensato ritenere Python "strongly typed", come avevo scritto prima. :)
banryu79
13-05-2009, 14:06
Incuriosito,
ho continuato ad approfondire un pochino la questione e il ruolo dei type system nei linguaggi di programmazione.
Ho una curiosità: la type safety di un linguaggio.
Che cosa si intende dicendo che un linguaggio è "type safe"?
Quanto è importante la type safety in un linguaggio?
Domando a voi, perchè leggendo in questa pagina (http://en.wikipedia.org/wiki/Type-safety) sembra che la type safety sia un requisito essenziale.
Inoltre c'è un link a questa risorsa (http://www.cis.upenn.edu/~bcpierce/courses/629/papers/Saraswat-javabug.html), che sarebbe un articolo di un certo Vijay Saraswat, ricercatore della AT&T, a quanto sembra, che dimostra che il linguaggio Java non è type safe.
La segnalo perchè penso possa interessare a molti (io devo ancora leggere l'articolo).
@EDIT:
Scusatemi, la ricerca è datata 1997: probabilmente il problema della type safety la documentato non esiste più (forse); resta comunque una lettura interessante.
Big Bamboo
13-05-2009, 18:24
Cerco di tornare in tema.
Prima di decidere su che linguaggio di programmazione buttarti, assicurati (nel caso tu voglia fare un'applicazione web-based) che cosa offre l'hosting che hai scelto. E' inutile consigliare linguaggi di programmazione esotici quando gli hosting più economici offrono php/.net
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.