Come iniziare a programmare? [Archivio]

akfhalfhadsòkadjasdasd

12-01-2015, 21:14

Ciao a tutti, sono una nuova iscritta. Ho 15 anni e mi piace molto l'informatica, con il computer credevo di saper fare qualcosa, ma da quando ho iniziato a leggere in modo più approfondito gli algoritmi e la programmazione in generale ho capito di essere una principiante. A scuola non studiamo informatica, quindi non sono agevolata da questo punto di vista. Conosco le basi del computer, ma la mia sapienza in merito è molto limitata. Mi sono iscritta al forum per poter imparare qualcosa di più e provare a iniziare la programmazione di qualcosa di semplice, ma non so come si comincia, quali conoscenze teoriche servono, nè da cosa iniziare (C++ forse?). Vi sarei immensamente grata se poteste darmi qualche dritta.
Echo

Ciao,

forte! :D

Io mi darei anche un obiettivo a cui arrivare. Magari fare un tuo sito web con una applicazione utile? E' tutto alla tua portata ed inoltre, entro certi limiti, anche gratis.

Per fare qualcosa da piazzare su internet, tipo un sito, puoi usare PHP e poi iniziare a vedere cosa è una banca dati, ad esempio con mysql. Arriverà anche il momento in cui ti servirà anche sapere qualcosa su javascript e una buona conoscenza di html e css non guasta

Io ho iniziato a fare cose interessanti con Java, ma attualmente lavoro quasi unicamente con C#.

C++ usato poco e niente e non parliamo del buon vecchio C.

Francamente parlando, se vuoi smanettare un po' puoi anche prendere il primo tutorial per javascript che ti capita a tiro, leggere un po', aprire il notepad, scrivere il primo 'Hello World'

salvare il file con estensione .html

cliccare sul file per aprirlo col browser, il browser eseguirà il codice javascript e la pagina html mostrerà subito i risultati.

esempio

<html>

<body>

<p id="qua"> </p>

<script>
var a = "ciao mondo";
console.log("console: " + a);
document.getElementById("qua").innerHTML = a;
</script>

</body>

</html>

Nel frattempo consiglierei di studiare un libro come ha indicato cdimauro.

Come linguaggio per iniziare e anche finire vanno sicuramente bene java, c#, python.. o magari ruby :)

ingframin

13-01-2015, 10:43

Ciao a tutti, sono una nuova iscritta. Ho 15 anni e mi piace molto l'informatica, con il computer credevo di saper fare qualcosa, ma da quando ho iniziato a leggere in modo più approfondito gli algoritmi e la programmazione in generale ho capito di essere una principiante. A scuola non studiamo informatica, quindi non sono agevolata da questo punto di vista. Conosco le basi del computer, ma la mia sapienza in merito è molto limitata. Mi sono iscritta al forum per poter imparare qualcosa di più e provare a iniziare la programmazione di qualcosa di semplice, ma non so come si comincia, quali conoscenze teoriche servono, nè da cosa iniziare (C++ forse?). Vi sarei immensamente grata se poteste darmi qualche dritta.
Echo

Per intanto a matematica come sei messa? :)

Concordo con Cesare e gli altri che hanno consigliato python, ma siccome ognuno dice la sua ti consiglio un libro diverso (fatto per gli studenti delle superiori però...):
https://inventwithpython.com/
Il primo libro, "Invent your own computer games with Python and Pygame" serve a imparare a programmare.
Quella dei giochi è una scusa per spiegare le basi dell'informatica e della programmazione usando python e facendo esercizi non pallosi.
Il secondo, "Make games with graphics!" è il seguito del primo e affronta argomenti più complessi (e più dedicati ai giochi).
Il terzo parla di crittografia, per ora è inutile...
Si possono tutti scaricare liberamente dal sito in PDF.

Se preferisci l'approccio hardcore:

- Deitel e Deitel -> http://www.apogeonline.com/libri/9788850323869/scheda >> C++

- Sempre Deitel e Deitel -> http://www.apogeonline.com/libri/9788850323883/scheda Java

Ne hanno anche uno per C.

Per Python:
Imparare Python di Mark Lutz:
http://www.amazon.it/Imparare-Python-Mark-Lutz/dp/8848125956

In bocca al lupo!
Per qualunque cosa chiedi sul forum, le guerre di religione ci sono sempre... Strano che nessuno non se n'è ancora uscito con LISP :P

ingframin

13-01-2015, 10:44

Perché?
Prima di passare al web non è meglio almeno scrivere un bubble sort?

Ciao,

forte! :D

Io mi darei anche un obiettivo a cui arrivare. Magari fare un tuo sito web con una applicazione utile? E' tutto alla tua portata ed inoltre, entro certi limiti, anche gratis.

Per fare qualcosa da piazzare su internet, tipo un sito, puoi usare PHP e poi iniziare a vedere cosa è una banca dati, ad esempio con mysql. Arriverà anche il momento in cui ti servirà anche sapere qualcosa su javascript e una buona conoscenza di html e css non guasta

Io ho iniziato a fare cose interessanti con Java, ma attualmente lavoro quasi unicamente con C#.

C++ usato poco e niente e non parliamo del buon vecchio C.

Francamente parlando, se vuoi smanettare un po' puoi anche prendere il primo tutorial per javascript che ti capita a tiro, leggere un po', aprire il notepad, scrivere il primo 'Hello World'

salvare il file con estensione .html

cliccare sul file per aprirlo col browser, il browser eseguirà il codice javascript e la pagina html mostrerà subito i risultati.

esempio

<html>

<body>

<p id="qua"> </p>

<script>
var a = "ciao mondo";
console.log("console: " + a);
document.getElementById("qua").innerHTML = a;
</script>

</body>

</html>

Nel frattempo consiglierei di studiare un libro come ha indicato cdimauro.

Come linguaggio per iniziare e anche finire vanno sicuramente bene java, c#, python.. o magari ruby :)

akfhalfhadsòkadjasdasd

13-01-2015, 12:05

Perché?
Prima di passare al web non è meglio almeno scrivere un bubble sort?
Per l'esame di fondamenti di informatica, certamente si'.

Come obiettivo in generale sarebbe piu' bello scrivere un tetris con javascript oppure realizzare una applicazione web: magari una versione semplificata di doodle dot com in php e mysql.

Ritengo che entrambe le cose siano istruttive e una piccola sfida.

ingframin

13-01-2015, 14:39

Per l'esame di fondamenti di informatica, certamente si'.

Come obiettivo in generale sarebbe piu' bello scrivere un tetris con javascript oppure realizzare una applicazione web: magari una versione semplificata di doodle dot com in php e mysql.

Ritengo che entrambe le cose siano istruttive e una piccola sfida.

Qui sta il problema: rifare doodle.com non è una piccola sfida, è una sfida enorme.
C'è da progettare un database, da gestire HTTP, da gestire mille frazze e mazze...
Anche il tetris, se sei alle prime armi (ma anche alle seconde/terze) è una discreta sfida.

-Echo-

13-01-2015, 16:19

akfhalfhadsòkadjasdasd

13-01-2015, 18:29

Qui sta il problema: rifare doodle.com non è una piccola sfida, è una sfida enorme.
C'è da progettare un database, da gestire HTTP, da gestire mille frazze e mazze...
Anche il tetris, se sei alle prime armi (ma anche alle seconde/terze) è una discreta sfida.

Da una parte c'è il pensiero 'vorrei iniziare a sapere cosa significa programmare (e/o progettare e quant'altro)'.. o saperlo fare.

Io ho suggerito che è bene avere uno scopo a cui arrivare, qualcosa di concreto, in modo da motivare e finalizzare l'apprendimento.

certo: fare una versione semplificata di doodle non è semplice, ma non è detto che sia un problema, qualcosa di non semplice :)
E' avere un progetto. Potrebbero volerci mesi, ci vorrà volontà.

k0nt3

13-01-2015, 22:06

Ciao a tutti, sono una nuova iscritta. Ho 15 anni e mi piace molto l'informatica, con il computer credevo di saper fare qualcosa, ma da quando ho iniziato a leggere in modo più approfondito gli algoritmi e la programmazione in generale ho capito di essere una principiante. A scuola non studiamo informatica, quindi non sono agevolata da questo punto di vista. Conosco le basi del computer, ma la mia sapienza in merito è molto limitata. Mi sono iscritta al forum per poter imparare qualcosa di più e provare a iniziare la programmazione di qualcosa di semplice, ma non so come si comincia, quali conoscenze teoriche servono, nè da cosa iniziare (C++ forse?). Vi sarei immensamente grata se poteste darmi qualche dritta.
Echo

E' davvero incredibile il fatto che nel 2015 ancora non insegnano informatica a scuola, ai miei tempi facevamo un corso sperimentale di informatica alle scuole medie e usavamo i floppy :sofico:
Tornando a noi.. tanti ti diranno che Python è il miglior linguaggio per iniziare, altri C, altri Java ecc.. la verità è che si può imparare a programmare con qualsiasi linguaggio.
Detto questo ti consiglio almeno all'inizio di non perdere troppo tempo a imparare un linguaggio, ti servono soprattutto basi di logica e matematica per affrontare gli algoritmi.
Allo stesso tempo riconosco che vedere dei risultati concreti è molto importante per motivarti ad andare avanti, per cui ti consiglio di dare un'occhiata qui http://scratch.mit.edu/
Scratch è un ambiente di programmazione grafico ideato dal MIT per insegnare a programmare ai ragazzi.
Non farti ingannare dall'aspetto giocoso, ci si fanno cose anche abbastanza complesse. Inoltre tutto quello che impari è agnostico dal punto di vista del linguaggio. In pratica ti servirà sempre.
Qui trovi alcuni video tutorial http://scratch.mit.edu/help/videos/
Inutile dire che su youtube ne trovi a valanghe ;)

@cdimauro certe cose non cambiano mai :asd:

cdimauro

13-01-2015, 22:20

E nemmeno tu. :D

Visto che hai citato il MIT, vediamo un po' cosa usano come linguaggio introduttivo alla programmazione: http://ocw.mit.edu/courses/intro-programming/

:fiufiu:

k0nt3

14-01-2015, 07:29

E nemmeno tu. :D

Visto che hai citato il MIT, vediamo un po' cosa usano come linguaggio introduttivo alla programmazione: http://ocw.mit.edu/courses/intro-programming/

:fiufiu:

Per fortuna al Politecnico di Milano iniziano ancora con il C.. solo a pensare a tutti quei __ mi viene la pelle d'oca :eekk:

Ma indipendentemente dal tuo credo religioso.. penso che imparare a programmare al giorno d'oggi sia molto diverso rispetto al passato. E' vero che ora l'informatica è pervasiva, ma ciò con cui abbiamo a che fare è infinitamente più complesso di prima. Questa complessità però è nascosta molto bene dentro una scatoletta confezionata ad arte.
Il problema è che per un/a ragazzo/a è paradossalmente più difficile "entrare nella scatoletta" per vedere come funziona.
Per questo secondo me Scratch è assai interessante. Permette ai neofiti di sbirciarci dentro.. e se poi capisci che fa per te, quello che hai imparato serve con qualsiasi linguaggio di programmazione (e non solo).

ingframin

14-01-2015, 08:47

Intanto echo è fuggita via... :doh:

ingframin

14-01-2015, 12:29

Ormai è diventata l'ennesima discussione che puntualmente si ripresenta in un sacco di post...le numerose filosofie si scontrano sempre XD

Ma infatti, troppi sofismi...
Ma basta prendere un libro di quelli introduttivi/didattici (tipo quelli di Deitel e Deitel ad esempio...) e si parte da li...
Nessuno di noi ha fatto addestramenti speciali dal gran maestro giapponese nella pagoda dispersa nel bosco per imparare a programmare.
Un po'di impegno e di buona volontà e si parte.
Poi c'è sempre tempo per mettere una pezza sulle lacune.
Echo ha 15 anni, ha tutto il tempo di fare le cose per bene e con calma, senza strafare. Non è che il mese prossimo deve andare a lavoro per Google!

akfhalfhadsòkadjasdasd

14-01-2015, 12:46

e che è successo, la caccia ai discepoli? :sofico:

ognuno ha dato alcuni riferimenti, quelli che ritiene essere i piu' opportuni.

-Echo-

14-01-2015, 13:27

Ciao a tutti, non sono sparita, ma a causa dello studio non ho molto tempo da passare su internet. Io frequento il secondo anno di liceo scientifico, e abitando in una zona di montagna con poche scuole mi è impossibile prendere una scuola più ricca di informatica. Detto questo, ho capito che per iniziare devo darmi una bella letta agli algoritmi e quando saprò padroneggiarli abbastanza bene potrò iniziare a (cercare di) programmare in un linguaggio tipo Python, C oppure usando Scratch.
Fino a qui ci sono? :)

!fazz

14-01-2015, 15:38

ennesima discussione trita e ritrita per questo faccio solo un sunto dei ragionamenti fatti molte volte in passato

non esiste un linguaggio migliore di un altro esiste un linguaggio più adatto di un altro per risolvere uno specifico compito ma ciò è ininfluente (o influente in minima parte) sul processo di apprendimento alla programmazione

la cosa da imparare è scomporre un problema complesso in una serie di problemi più semplici, in modo tale da poter essere tradotto in un arbitrario linguaggio di programmazione.

l'unica cosa che posso consigliare ad un principiante è di iniziare con linguaggi abbastanza semplici nella struttura del linguaggio e con un debugger molto chiaro in modo da facilitare la risoluzione dei bachi altrimenti si rischia di rendere la fase di apprendimento frustante per delle quisquiglie,

una volta acquisite le basi della programmazione si impiega poco a passare da un linguaggio ad un altro

quindi in defintiva van bene qualsiasi linguaggio ad esclusione di c, c++, assembly et similari che per quanto potenti sono solo una frustazione per il neofita, meglio andare di java, phyton .net ecc ecc

-Echo-

14-01-2015, 17:14

Ok,grazie mille a tutti, speriamo che con il tempo si riesca a tirar fuori qualcosa di buono. :D

cdimauro

14-01-2015, 18:30

Come al MIT e cdmauro, anche io direi di cominciare con Python, vista la semplicità almeno iniziale dell'approccio (anche nella mia università adesso hanno modificato il percorso e si comincia con Python).

Però comincerei ancora da più indietro, cominciando con la teoria degli algoritmi e un'infarinatura molto base di architettura dei calcolatori.
Soprattutto gli algoritmi sono importanti, perchè, come dice sempre un mio ex professore: "è molto più importante conoscere la metodologia, piuttosto che lo strumento! Lo strumento è solo un mezzo per raggiungere lo scopo che si vuole raggiungere ATTRAVERSO il metodo"
Anche lo strumento è importante, ed è il motivo per cui si è passati da C a Java, e di recente a Python. Se non lo fosse si potrebbe cominciare direttamente col linguaggio macchina. ;)

Concordo sul resto.
Per fortuna al Politecnico di Milano iniziano ancora con il C..
Perché in Italia siamo sempre indietro, come al solito.
solo a pensare a tutti quei __ mi viene la pelle d'oca :eekk:
De gustibus, ma... ci sono anche in C e C++.
Ma indipendentemente dal tuo credo religioso.. penso che imparare a programmare al giorno d'oggi sia molto diverso rispetto al passato. E' vero che ora l'informatica è pervasiva, ma ciò con cui abbiamo a che fare è infinitamente più complesso di prima. Questa complessità però è nascosta molto bene dentro una scatoletta confezionata ad arte.
Il problema è che per un/a ragazzo/a è paradossalmente più difficile "entrare nella scatoletta" per vedere come funziona.
Per questo secondo me Scratch è assai interessante. Permette ai neofiti di sbirciarci dentro.. e se poi capisci che fa per te, quello che hai imparato serve con qualsiasi linguaggio di programmazione (e non solo).
Vedi sopra. E non è una questione di religione, visto che parliamo di questioni prettamente tecniche.

Per iniziare non serve fermarsi sui dettagli né tanto meno andare a vedere "com'è fatto dentro" qualcosa.
Ciao a tutti, non sono sparita, ma a causa dello studio non ho molto tempo da passare su internet. Io frequento il secondo anno di liceo scientifico, e abitando in una zona di montagna con poche scuole mi è impossibile prendere una scuola più ricca di informatica. Detto questo, ho capito che per iniziare devo darmi una bella letta agli algoritmi e quando saprò padroneggiarli abbastanza bene potrò iniziare a (cercare di) programmare in un linguaggio tipo Python, C oppure usando Scratch.
Fino a qui ci sono? :)
Usa Python col libro che ho messo in firma, che parte proprio dall'inizio, e man mano ti spiega e fa cimentare anche con gli algoritmi. E' un libro che ti porta per mano e ti conduce nella conoscenza di entrambe le cose: basi della programmazione (tramite il linguaggio) e algoritmi.

Divertiti.

k0nt3

14-01-2015, 19:46

Devo ammettere che sono ignorante sotto il punto di vista di Scratch...mio fratello, che ha 6 anni in meno di me, l'aveva usato al primo anno di superiori, ma noi abbiamo cominciato fin da subito con il C, e devo ammettere che la base di quel linguaggio mi è servita tantissimo, anche se poi, spostandomi su altri linguaggi (a lavoro andiamo di C#, F# e ASP.NET), non ho praticamente più avuto bisogno di dichiarazioni esplicite dei puntatori, allocazione/deallocazione manuale della memoria (tranne i casi in cui abbiamo necessità di usare IDisposable), e macchinosità sul lavoro con stringhe.

Provando Scratch (in ottica di insegnare a usarlo ai miei nipoti) mi ha fatto un'ottima impressione. Per esempio mi ha sorpreso la gestione di più "thread" in parallelo, viene molto naturale. Poi il meccanismo dei blocchi che si incastrano è molto carino per imparare gli algoritmi. Io invece ho dovuto iniziare con carta e penna :D
Sul C ci sono anche alcuni "pro", oltre ai soliti "contro".
Per esempio capire come funzionano i puntatori non è affatto inutile, ma serve quando si usano i tipi riferimento in Java e simili.
Infatti la maggiorparte delle persone che non sono passate da C fanno fatica a capire esattamente come funziona il passaggio di oggetti come parametro ai metodi.

Perché in Italia siamo sempre indietro, come al solito.

Non credo sia una questione di arretratezza, ma di scopi differenti.
Al politecnico non ti insegnano a programmare, ma ti insegnano come funziona un computer per prima cosa. In questo C non è affatto male.
Se invece lo scopo è imparare a programmare e basta ci sono senza dubbio strade più accessibili. Comunque non vuol dire che siano per forza migliori, a volte faticando si impara di più.

cdimauro

14-01-2015, 20:05

Provando Scratch (in ottica di insegnare a usarlo ai miei nipoti) mi ha fatto un'ottima impressione. Per esempio mi ha sorpreso la gestione di più "thread" in parallelo, viene molto naturale. Poi il meccanismo dei blocchi che si incastrano è molto carino per imparare gli algoritmi. Io invece ho dovuto iniziare con carta e penna :D
Sul C ci sono anche alcuni "pro", oltre ai soliti "contro".
Per esempio capire come funzionano i puntatori non è affatto inutile, ma serve quando si usano i tipi riferimento in Java e simili.
Infatti la maggiorparte delle persone che non sono passate da C fanno fatica a capire esattamente come funziona il passaggio di oggetti come parametro ai metodi.
Prima ancora c'era il Pascal, se permetti.
Non credo sia una questione di arretratezza, ma di scopi differenti.
Al politecnico non ti insegnano a programmare, ma ti insegnano come funziona un computer per prima cosa. In questo C non è affatto male.
Se invece lo scopo è imparare a programmare e basta ci sono senza dubbio strade più accessibili. Comunque non vuol dire che siano per forza migliori, a volte faticando si impara di più.
Per farti male hai sempre tutto il tempo davanti a te.

k0nt3

14-01-2015, 20:23

EDIT

cdimauro

14-01-2015, 20:26

OK, ho editato anch'io.

cdimauro

14-01-2015, 20:52

Senz'altro, il paradigma è fondamentale, ma il linguaggio aiuta, e pure molto. Specialmente con Python, che nasconde anche il compilatore, che usa internamente, per non parlare poi dell'interprete "live" che inizialmente ti consente di smanettare immediatamente senza nemmeno dover imparare il concetto di editor. ;)

ingframin

15-01-2015, 05:24

Questo lo dici tu XD (io ho lavorato in un'azienda che si chiama Sensei :D )

:eek:

Anche lo strumento è importante, ed è il motivo per cui si è passati da C a Java, e di recente a Python. Se non lo fosse si potrebbe cominciare direttamente col linguaggio macchina.

http://download.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf
:rolleyes: :D :Prrr:

ingframin

15-01-2015, 05:27

Ok,grazie mille a tutti, speriamo che con il tempo si riesca a tirar fuori qualcosa di buono. :D

Ne sono più che sicuro!:)

cdimauro

15-01-2015, 05:54

Sisi inizialmente l'IDLE è fantastico, e puoi anche scrivere qualche programmino semplicissimo, prima di passare ovviamente ad un editor di testo tipo notepad++, sublime text o kate
Sublime Text forever, SE non devo usare Visual Studio.:cool:
http://download.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf
:rolleyes: :D :Prrr:
E' così potente che non me lo fa nemmeno scaricare:

"Non è stato possibile trovare il server remoto"

:D :D :D

P.S. -Echo-: IGNORA tutti questi messaggi. E' gente malata di geekite.:p

ingframin

15-01-2015, 07:50

Strano...
Prova da qui:
http://savannah.nongnu.org/projects/pgubook/
C'è un'area "download" in alto alla pagina.
In pratica è un corso di introduzione all'informatica che usa Assembly come linguaggio e parte dall'architettura dei calcolatori.
Usa GAS sotto linux per essere precisi.
È un buon libro ma troppo mastodontico secondo me...

Però alla fine, nella sezione "moving on from here" consiglia il libro su python che hai in firma XD

cdimauro

15-01-2015, 17:09

Strano...
Prova da qui:
http://savannah.nongnu.org/projects/pgubook/
C'è un'area "download" in alto alla pagina.
Da qui ho potuto scaricarlo, finalmente. Grazie! :)
In pratica è un corso di introduzione all'informatica che usa Assembly come linguaggio e parte dall'architettura dei calcolatori.
Usa GAS sotto linux per essere precisi.
È un buon libro ma troppo mastodontico secondo me...
Ma non solo mastodontico. A parte il fatto che ha cannato completamente il significato di iniziare a programmare, che è alla base di tutto, mi chiedo come diavolo faccia a proporre GAS per scrivere assembly, che è nato per le macchine e non per gli esseri umani. Usasse almeno la notazione Intel, che di gran lunga più semplice... :stordita:
Però alla fine, nella sezione "moving on from here" consiglia il libro su python che hai in firma XD
Visto. :D
Io invece, che usavo Sublime Text fino a poco più di 4 mesi fa e ne ero un sostenitore accanito, da quando ho cambiato azienda e mi hanno consigliato di installare notepad++......bè ora non ci rinuncerei mai...ha delle feature utilissime e comodissime per l'editing avanzato che su sublime text non saprei mai dove trovare.

Poi è anche vero che con Sublime Text non mi sono mai messo a studiare gli shortcut salvavita, quindi è anche possibile che mi ricrederò più avanti :)

Tra parentesi, invece dove lavora la mia ragazza, usano pesantemente TextPad, che prima di oggi non avevo mai sentito :)
Dovrebbe essere diffuso in ambito Mac.

Con gli editor, come per gli IDE, al solito è una questione di gusti / abitudini / comodità.

Ho provato Notepad++, ma non m'è piaciuto.

Con Sublime Text, invece, è stato a more a prima vista, per non parlare del fatto che posso estenderlo "abd libitum" grazie al fatto che posso scrivere plugin in Python.
Tra l'altro esistono diversi pacchetti con plugin già pronti. C'è un repository per questo. Potresti controllare lì. Al limite elenca le funzionalità che ti mancano, perché potrebbe essere utile inserirle come feature request.

-Echo-

16-01-2015, 16:47

Ciao a tutti, vi aggiorno su come stanno procedendo le cose: ho iniziato a leggere il libro consigliato da cdimauro, quindi ho scelto di usare Python per questo primo approccio alla programmazione. L'unico dubbio che mi è venuto è se ho le necessarie conoscenze matematiche per poter andare avanti, oppure ad certo punto dovrò per forza fermarmi. Cosa ne pensate?

cdimauro

16-01-2015, 17:56

Questa cosa mi sembra molto interessante :)

Stasera a casa faccio qualche smanettata...questi plugin sono elencati sul sito di Sublime Text?
No, ma nel forum dell'editor (http://www.sublimetext.com/forum/) ci sono due apposite sezioni per i plugin.

Comunque qui (https://packagecontrol.io/) trovi un sito appositamente dedicato ai plugin di Sublime Text. :cool:
Ciao a tutti, vi aggiorno su come stanno procedendo le cose: ho iniziato a leggere il libro consigliato da cdimauro, quindi ho scelto di usare Python per questo primo approccio alla programmazione. L'unico dubbio che mi è venuto è se ho le necessarie conoscenze matematiche per poter andare avanti, oppure ad certo punto dovrò per forza fermarmi. Cosa ne pensate?
Puoi andare tranquillamente. Il corso richiede conoscenze molto semplici, elementari, di matematica.

Tra l'altro non so se ci hai fatto caso, ma per ogni capitolo sono presenti degli esercizi coi quali puoi cimentarti con le nozioni appena apprese. Quindi non devi soltanto studiare, ma al contempo sperimentare, smanettare, ed è il modo migliore per apprendere.

deadbeef

16-01-2015, 23:53

Complimenti a tutti per aver trasformato questo thread in una guerra santa a colpi di linguaggi esoterici, editor ed ambienti di sviluppo. Che l'entropia sia con voi.

Tommo

17-01-2015, 01:57

Questi thread sono cosi' regolari che dovrebbero insegnarne l'algoritmo a Programmazione 1 :asd:

In realta' ogni diatriba nasce dal fatto che l'informatica ha due aspetti complementari ma opposti: da una parte i concetti astratti e gli algoritmi, dall'altra il far girare uno specifico computer nel modo piu' efficiente possibile.

Per cui esistono due modi fondamentalmente opposti per approcciarla:
a) partire dall'astratto con linguaggi tipo Python o a volersi far male F# o Haskell, per poi man mano scoprire come sono implementati;
b) partire da come funziona un computer a livello basilare e salire man mano con l'astrazione, di solito usando C o se masochisti C++ o ASM (o Rust).

Entrambi i metodi sono perfettamente validi, quale e' migliore dipende solo dal carattere della persona e dai suoi interessi.
E comunque un programmatore degno di questo nome IMO deve conoscere entrambi gli aspetti prima o poi.
Ma ovviamente e' molto piu' divertente dibattere se Python e' meglio di C all'infinito arrivando a nulla :asd:

-Echo-

17-01-2015, 07:53

Puoi andare tranquillamente. Il corso richiede conoscenze molto semplici, elementari, di matematica.

Tra l'altro non so se ci hai fatto caso, ma per ogni capitolo sono presenti degli esercizi coi quali puoi cimentarti con le nozioni appena apprese. Quindi non devi soltanto studiare, ma al contempo sperimentare, smanettare, ed è il modo migliore per apprendere.
Ok, ancora una volta grazie mille per le spiegazioni. Oggi continuerò a leggere il libro, nel caso mi trovassi in difficoltà farò di nuovo uso delle vostre conoscenze chiedendovi delucidazioni :)

cdimauro

17-01-2015, 14:21

Di nulla. Divertiti.

@deadbeef: purtroppo capita sempre così, ma alla fine l'obiettivo è stato raggiunto mi pare.

@Tommo: se l'obiettivo è quello di imparare a programmare partendo dall'inizio, lo strumento da utilizzare è molto importante. Il C NON è un buon linguaggio per iniziare, e questo lo dovresti sapere bene.

Poi che andando avanti magari ci sarà la necessità di farsi del male con dettagli di più basso livello, penso sia una cosa normale. Ma prima di correre impariamo a camminare, no? ;)

Tommo

17-01-2015, 14:27

@Tommo: se l'obiettivo è quello di imparare a programmare partendo dall'inizio, lo strumento da utilizzare è molto importante. Il C NON è un buon linguaggio per iniziare, e questo lo dovresti sapere bene.

Personalmente sono contento di aver iniziato dall'alto livello (GM->Unity->Java->C++, praticamente) ma ci sono parecchie persone che preferiscono andare dal particolare al generale, specie nel mondo della programmazione dove (non odiatemi ci sono ricerche che lo dicono :asd: ) molta gente ha tratti autistici ed e' naturalmente attirata dai dettagli piu' specifici che riesce a trovare.

Dato un particolare approccio lo strumento che scegli e' importante, e' vero, ad esempio non ha senso partire con una roba vecchia o buggata o PHP... ma non puoi dire che l'approccio di chi parte dal basso con C e' "sbagliato" perche' dipende dalla persona.
Cioe', tu chiaramente preferisci l'alto livello e vedi il basso livello come "farsi male", altre persone potrebbero vederla in modo del tutto opposto e preferiscono ragionare in termini di come funziona il processore, e "farsi male" e' scrivere pseudocodice in Python. A ognuno il suo :D

E' un problema di insegnamento, non di linguaggio, e non si puo' risolvere coi meriti del linguaggio soltanto senza tenere conto di chi impara.

cdimauro

17-01-2015, 17:03

Allora, come dicevo prima, perché non iniziare direttamente col linguaggio macchina? E perché si è passati da C a Java, e negli ultimi tempi da Java a Python?

Se fosse un problema di insegnamento, come affermi, ciò non dovrebbe succedere.

IMO è palese che, invece, un linguaggio di alto livello consente un approccio di gran lunga più facile per iniziare alla programmazione, rispetto a uno di più basso livello.

Qui nessuno afferma che non si debba andare a scavare nei dettagli e vedere via via a più basso livello cosa succede. Ma è qualcosa che puoi fare benissimo DOPO averti fatto le basi della programmazione.

Tommo

17-01-2015, 21:28

Si e' passati da Java a Python perche' nel contesto di "linguaggio di alto livello per insegnare gli algoritmi" Python e' migliore di Java.
A parte la sintassi piu' semplice, non ti forza a esporre la gente all'OO quando ancora non sanno scrivere Hello World e dover balbettare "eh lo vedremo poi" per non confondere ancora di piu' :asd:

Non si e' mai "passati da C a Java" del tutto perche' non a caso i corsi rilevanti (sistemi operativi, calcolatori, grafica, etc) ancora usano C a pacchi, perche' quei corsi insegnano un'altra cosa. Sarebbe stupido e/o impossibile insegnare SO in Python.

C e' meglio del linguaggio macchina perche' ti nasconde inizialmente i dettagli piu' difficili anche se rimane vicinissimo a come funziona la CPU... senza ottimizzazioni e features avanzate e' facile trovare 1:1 come viene mappato il codice.
E poi il linguaggio macchina ormai e' un'IR che non serve quasi a nulla conoscere, se non per leggere che cosa produce il compilatore. Tanto i processori x86 nemmeno lo eseguono piu' direttamente.

E comunque tornando al mio discorso, "un linguaggio di alto livello consente un approccio di gran lunga più facile per iniziare alla programmazione":
-"facile" e' soggettivo
-"programmazione" e' soggettivo. A seconda del campo che ti interessa un linguaggio di alto livello potrebbe essere del tutto inadatto allo scopo, eg. se vuoi imparare come scrivere roba efficiente.

cdimauro

17-01-2015, 21:59

Ma qui lo scopo è chiaro: iniziare a programmare (partendo da zero; o quasi).

Non c'entrano nulla i corsi più avanzati, come quello dei s.o., di rete, o persino delle architetture, dove devi già possedere delle nozioni di programmazione, altrimenti non puoi seguirli.

P.S. I processori x86 eseguono il codice macchina, come qualunque altro processore. Che poi internamente facciano uso di un'unità RISC per l'esecuzione delle (micro)operazioni, è un altro discorso. L'ISA rimane quella x86, e la micro-implementazione nulla dice al programmatore, che si troverà davanti sempre il codice x86.

P.P.S. -Echo-, ignora questi commenti. :fagiano:

wingman87

19-01-2015, 09:16

... Python ti costringe ad editare, quindi ti aiuta a scrivere good code, importante per capire poi dove uno sbaglia.

Scusa coffe_killer ma l'hai già scritto più volte... quello che vuoi dire è "indentare", non "editare" :)

ingframin

19-01-2015, 12:08

Oh volendo...
http://www.freebasic.net/
Che c'`e di meglio del Beginner's All-purpose Symbolic Instruction Code? :D
È nato apposta per insegnare la programmazione...

cdimauro

20-01-2015, 06:11

Già. Ormai Python ha preso il posto del BASIC per quanto riguarda la didattica: è decisamente più facile da imparare.

Riguardo al discorso che facevi prima, un programmatore deve imparare a risolvere problemi. Ciò che hai descritto prima è roba di basso livello che NON è necessaria per risolvere un particolare problema. In particolare la gestione delle stringhe in C è scandalosa, al contrario di quello che hai dipinto, ed è uno dei motivi per cui è stato introdotto il tipo string in C++. Come hai detto bene, il punto cardine è che le stringhe in C sono array; con tutte le conseguenze del caso, inclusi i problemi di sicurezza che ne derivano. La gestione delle stringhe in C è l'ultimo dei motivi per cui consiglierei questo linguaggio...

cdimauro

20-01-2015, 18:27

Pensa che io invece la penso esattamente al contrario.
Questo l'avevo intuito. :D
IMHO, nonostante il modo scandaloso della gestione delle stringhe, il C ti mette davanti delle problematiche, su questo argomento, che una volta sbattutaci la testa e imparato cosa fa e perchè, poi buttarsi su altri linguaggi diventa mooooooooooolto più semplice.
Quindi sei per "metodo giapponese": se non soffri non godi, insomma. :p

Ovviamente non sono d'accordo, perché stai semplicemente portando la complessità / difficoltà intrinseca del C a livello di "megaesercizio" da risolvere.

A questo punto con lo stesso principio allora tanto vale imparare col linguaggio macchina (magari del processore Itanium): se sopravvivi sarai un programmatore "coi fiocchi".

Imparare a programmare non è questo. Non è che impari a nuotare meglio se l'istruttore ti mette dietro uno squalo...
Per imparare secondo me dovrebbero essere insegnati parallelamente Python e C al primo anno di informatica...così si impara bene a padroneggiare un linguaggio di alto livello ed uno di basso, con tutte le problematiche di gestione che ne conseguono in entrambi i casi.
E invece no, perché imparare a programmare significa saper risolvere problemi, non andare a guardare a basso livello cosa succede, a meno che non sia necessario / parte dei requisiti del problema da risolvere.

Se parti da zero, il tuo obiettivo primario è assimilare il concetto di algoritmo e applicarlo nella risoluzione di un problema. Come mai sono nati i diagrammi di flusso, lo pseudocodice, i diagrammi a blocchi (di cui non ricordo il nome al momento; concettualmente simili a quelli di flusso, ma consentivano di esprimere anche i cicli e le condizioni in maniera più strutturata), ecc.? Per astrarre e consentire di risolvere un determinato problema evitando di perdere tempo nei dettagli di più basso livello.

Con ciò, sia chiaro, non dico che non bisogna imparare o C o non andare a vedere cosa succede a livelli di astrazione più bassi. Ma penso che tutto ciò debba essere fatto DOPO che uno si sia fatto le ossa e acquisito il concetto di problem solving, oltre ad aver accumulato una buona base di conoscenza relativamente agli algoritmi più importanti.
Poi passerei alla programmazione ad oggetti (per gusti personali lascerei stare il Java e mi butterei sul C#) e in seguito alla programmazione web.
Son tutte cose che puoi fare benissimo anche con Python. Anzi, con Python puoi cimentarti anche nella metaprogrammazione. E' un linguaggio abbastanza completo dal punto di vista delle varie prospettive di sviluppo del codice. ;)
Infine mi studierei bene un IDE avanzato (secondo me VS è un passo avanti a tutti, poi adesso che rilasciano la community edition gratuitamente....da bava alla bocca XD) e, se si sceglie Visual Studio, un po' di programmazione funzionale, che salva le chiappe in molte occasioni :)
Vedi sopra: Python offre diversi strumenti in tal senso. Oltre al fatto che c'è un meraviglioso plugin per Visual Studio (Python Tools for Visual Studio).

Ma al momento tutto ciò è overkill. Per adesso è sufficiente lanciare Python col suo prompt dei comandi, e divertirti a smanettare pacioccando con pezzetti di codice, e vedendo immediatamente il risultato delle nostre azioni. Non c'è nulla di meglio per imparare a programmare. ;)

cdimauro

20-01-2015, 23:15

Sono un pascaliano, e dunque amo questa famiglia di linguaggi & derivati, per cui non apprezzo i linguaggi C-like. Ma fra questi, se proprio dovessi scegliere, C# sarebbe al primo posto.

Python Tools for Visual Studio è un plugin dell'IDE, quindi è scritto in C# e usa .NET.

Riguardo al C, anch'io lo uso, ma non mi diverto affatto, a causa di tutta una serie di motivazioni che non sto qui a riportare. Per me il C rimane un male necessario.

Al momento sto sviluppando un emulatore 8086 in Python, che porterò poi in C non appena sarà finito. Perché questo trambusto? Perché con Python realizzare un modello è di gran lunga più semplice, veloce, manutenibile e modificabile, inclusa l'importantissima e delicatissima fase di testing.
Il port in C farà uso dell'intera test suite (automatica) che sto realizzando, la quale rimarrà interamente in Python. Ciò mi garantirà una certa affidabilità di tutto il lavoro fatto.

Come vedi uso Python, C, e in generale qualunque strumento ritengo opportuno, in base allo scopo che devo raggiungere. Sono un professionista e, sebbene abbia i miei gusti, le mie scelte sono frutto di analisi e ponderazione. ;)

[Kendall]

21-01-2015, 09:10

Per lo stesso motivo odio profondamente il Java che, seppur simile nello spirito al C#, non ha nessun IDE all'altezza di VS; personalmente ritengo Eclipse una porcheria.

Di IDE per Java estremamente valide ce ne sono. Intellij IDEA è davvero un ottimo prodotto (non ai livelli di VS, ma comunque davvero una IDE eccellente).
A prescindere da questo, anche io preferisco il C#, e di gran gran lunga rispetto al Java. Quindi se posso, il Java, lo evito.

!fazz

21-01-2015, 11:35

Te lo consiglio caldamente, incrementa, insieme a tutte le feature di Visual Studio, la produttività al 1000% :)
Io ormai sono uno sviluppatore C# convinto, anche se il Python rimarrà sempre nel mio cuore, visto che mi ha tolto le castagne dal fuoco in un sacco di occasioni, soprattutto nel progetto della tesi (applicazione per Android in Python....extreme programming allo stato puro :) ).
Per lo stesso motivo odio profondamente il Java che, seppur simile nello spirito al C#, non ha nessun IDE all'altezza di VS; personalmente ritengo Eclipse una porcheria.

Ma mi pare di capire che tu VS lo usi vero?

Io, avendolo usato per ora solo in ambito accademico (3 anni di superiori e 2 di università(poi si è passati ad altro dalla seconda metà del secondo anno)) non l'ho trovato così opprimente. Ho visto anche un pochino di C++ lavorando per un progetto di domotica, ma lì si usavano le boost, quindi il linguaggio nudo e crudo non l'ho mai usato.

Ma lo fai per passione o per lavoro?
Perchè se è la seconda, sarei curioso di sapere che lavoro fai :D

imho, per tentare di far rientrare l'ot mostruoso che avete creato, l'uso di un IDE avanzato per un neofita è una tra le cose più sbagliate che si possono fare, un ide avanzato serve, come giustamente qualcuno ha già detto, per incrementare la produttività di un programmatore esperto ma per un neofita è un casino di menu e funzionalità astruse dal nome esoterico (refactoring e che è uno strumento per creare le piste per un videogioco di corse????:D :D :D )

al programmatore neofita servono solo queste 2 cose
1) evidenziatura delle keyword
2) il tasto compila ed esegui
3) una chiara error list

dopo qualche giorno serviranno in aggiunta questi 2 tool
4) step by step
5) watch

e basta

non so voi ma io quando insegno programmazione le basi più basi le faccio con carta, penna e pseudocodice e inoltre non schifo neanche l'uso di vba che al neofita è comodissimo

1) ha volte ha pure una certa utilità nell'automazione d'ufficio e saperlo male non fà
2) creazione semplificata di gui
3) non richiede l'installazione di un mattone stile visual studio (excel l'hanno tutti)
4) un debugger chiarissimo (importantissimo)
4) dà la possibilità di registrare macro e visualizzare il codice cosa che è utile per l'apprendimento autonomo delle basi di programmazione che sono ricordo

la comprensione di un problema complesso e la sua scomposizione in problemi più semplici interconnessi e la traduzione di essi in una serie passi--> algoritmo

i mal di testa dovuti ai segmentation fault (cit) lasciamoli a gente che quanto meno è in grado di capire come è un vettore :D :D

deadbeef

21-01-2015, 11:53

coffe_killer cambierai idea su Java il giorno in cui in aziende con server/mainframe Unix/Linux based chiederai se il tuo software in .NET ci gira e ti rideranno fragorosamente in faccia

[Kendall]

21-01-2015, 15:02

coffe_killer cambierai idea su Java il giorno in cui in aziende con server/mainframe Unix/Linux based chiederai se il tuo software in .NET ci gira e ti rideranno fragorosamente in faccia

Questo è un commento senza senso.
È OVVIO che non si puó fare tutto in C#, cosí come non si puó fare tutto in Java. Ogni linguaggio primeggia per specifici campi d'impiego.
Ció non toglie che si possa fare una analisi estrapolata da tutto ció e valutare pregi e difetti del linguaggio in sé.

cdimauro

21-01-2015, 20:22

cdimauro

22-01-2015, 20:37

Personalmente ho rivalutato abbastanza Netbeans, però non l'ho mai usato seriamente purtroppo.
In ogni caso ti consiglio di provarlo :)
L'ho usato per un po' di anni, poco per Java, ma soprattutto per Python, per il quale esisteva un buon plugin. Purtroppo a partire dalla versione 7 non è stato più supportato, per cui mi sono dovuto rivolgere ad altri IDE. Dopo tanti giri e IDE provati, qualche anno fa ho deciso di dare una seria possibilità a Python Tools for Visual Studio, e... ci sono rimasto: per me non c'è di meglio, anche se non è uno strumento perfetto, ma è in continuo sviluppo e miglioramento.
Scusa non avevo proprio letto la tua firma...comunque ho visto il tuo know-how su Linkedin...lavori proprio in un bel posto secondo me :)
Grazie. Mi piace molto e ho tanti stimoli. Diciamo che non mi annoio di sicuro. :p
PS: mi hai dato l'ispirazione di aggiungere anche io il profilo Linkedin alla firma :)
In verità ho fregato l'idea a un altro utente. :stordita:

cdimauro

22-01-2015, 23:21

Ti rispondo in pubblico, perché può interessare anche altri.

Alla prima domanda: abbiamo posizioni per gli impieghi più disparati, vista la varietà di business che facciamo.
Se, invece, ti riferivi alla filiale in cui lavoro io, ci occupiamo essenzialmente di debugger. Per cui i ruoli ricercati generalmente sono quelli di sviluppatore e quello di QA, cioé i due ruoli opposti ma sinergici: chi sviluppa il codice e chi deve controllarne la qualità.

Per la seconda domanda, e sempre se ti riferisci alla mia filiale, non serve necessariamente esperienza coi debugger, ma certamente le conoscenze di molto basso livello sono apprezzate. Non sono strettamente necessarie se devi sviluppare l'interfaccia grafica per un plugin di Visual Studio o Eclipse oppure per il nostro System Debugger, ad esempio. Idem se devi svolgere il ruolo di QA in quest'ambito, dove serve principalmente come funziona un debugger.
Se, invece, la domanda era relativa alle posizioni dell'intera azienda, il concetto è simile, ma relativo all'ambito della posizione.

Comunque la descrizione della posizione aperta è di per sé sufficiente a definire ciò che ci serve per quel ruolo, ma è chiaro che se hai anche altra esperienza è sicuramente apprezzata.

-Echo-

01-02-2015, 11:43

Ciao a tutti, torno a farmi viva. Sto leggendo il libro (anche se vado a rilento per via dello studio) e ho iniziato a smanettare con Python, anche se per adesso non ho fatto altro che le cose più basilari e semplici. Mi piace un sacco, e vorrei avere più tempo da dedicargli ma purtroppo è quello che è. Inoltre sul libro era posta una domanda che non riuscivo a capire, dopo ve la posto, se potete aiutarmi a capirla. È comunque molto appassionante e mi ci diverto anche, quando da i risultati (anche se semplicissimi) come print ("Hello, World!") è una piccola vittoria.

cdimauro

01-02-2015, 12:18

Ottimo. Vedo che hai imboccato la strada giusta. :)

Riporta pure i problemi che hai, e ne discuteremo, ma ti consiglio di aprire un thread apposito, perché credo che questo abbia ormai esaurito il suo compito. ;)

-Echo-

02-02-2015, 08:27

Grazie ancora, provo a riflettere su quella domanda e se non trovo soluzione aprirò un nuovo thread. :)

71106

06-04-2015, 12:51

non esiste un linguaggio migliore di un altro

Non è vero, esistono linguaggi oggettivamente migliori di altri. Haskell è oggettivamente migliore di PHP, per qualunque compito.

Prima che arrivino le solite obiezioni tutte sbagliate: evitiamo di confondere il linguaggio con le librerie a corredo. Anche se credo che Haskell vincerebbe ugualmente visto che le librerie a corredo di PHP fanno cagare una più dell'altra.

esiste un linguaggio più adatto di un altro per risolvere uno specifico compito ma ciò è ininfluente (o influente in minima parte) sul processo di apprendimento alla programmazione ciò è estremamente influente. Crescere col linguaggio sbagliato è come crescere con genitori violenti e alcolizzati. Che voi ci crediate o no, ho sentito gente lodare PHP. Qualunque appello alla ragione è stato totalmente futile. L'argomento più valido che io sia riuscito a proporre è che PHP è bandito all'interno di Google (appello all'autorevolezza, ma di per se' non è un argomento valido perchè la logica prescinde dall'autorevolezza).

71106

06-04-2015, 12:53

Ottimo. Vedo che hai imboccato la strada giusta. :)

LOL! :D

Quanti ricordi di discussioni passate. :asd:

Però questa è la prima volta che ti vedo avere effettivamente successo nell'indirizzare un principiante. :D

VICIUS

07-04-2015, 20:36

Ricorda che solo i Sith ragionano per assoluti :D
Anche questo non è forse un assoluto? Meglio evitare di citare quei tre film.

Il fatto che Google bandisca PHP è semplicemente politica aziendale, Facebook ci ha costruito sopra il suo linguaggio invece, vorrà dire che non è tutto schifo probabilmente
A questo punto Facebook è costretto ad usare php. Hanno un sistema da milioni di linee di codice che non ha senso riscrivere e l'intero team di sviluppo che è stato assunto per programmare in quel linguaggio.

Il fatto che negli ultimi cinque anni abbiano speso un sacco di tempo e risorse in trans compilatori (hphpc), macchine virtuali (hhvm) ed abbiano finito per inventare un linguaggio come Hack dimostra, secondo me, che la stessa facebook non è convinta che php sia lo strumento migliore da usare.

71106

07-04-2015, 22:34

A parte gli scherzi, non sono totalmente d'accordo con il tuo pensiero... e tuttavia non conosci Haskell.

Ma ne possiamo ancora parlare, visto che confronti PHP con C#. Anche C# mi fa abbastanza schifo, ma non vedo in cosa potrebbe mai essere peggiore di PHP.

(PHP è tendenzialmente più semplice di C# da apprendere, per via della sintassi più stringata e la tipizzazione debole, La tipizzazione debole è un conclamato difetto.

La "sintassi più stringata" (che interpreto come un minor numero di costrutti astratti) invece di per se' sarebbe un pregio, ma la sintassi di PHP ha talmente tanti difetti e casi patologici che a questo punto io preferirei una sintassi più complessa ma perlomeno trattabile. Di sicuro Haskell è migliore di entrambi.

le API .NET però sono un pochino più complesso da apprendere per uno alle prime armi, anche se a lungo andare sono manna dal cielo) Come dicevo, evitiamo di buttarla in caciara con le API.

Il fatto che Google bandisca PHP è semplicemente politica aziendale, Le politiche aziendali non sono arbitrarie, specialmente quelle di Google che hanno un rationale molto dettagliato e ben argomentato.

Anche questo non è forse un assoluto? Meglio evitare di citare quei tre film. La parola "tre" qui è bellissima. :asd:

VICIUS

08-04-2015, 15:07

Il linguaggio Hack si basa fortemente su PHP, sia come sintassi sia come logiche...semplicemente vogliono buttarsi in quel mercato...secondo te uno costruirebbe un linguaggio come un derivato del PHP, se sul PHP non ha fiducia?

trans-compilatori e macchine virtuali non vedo quali benefici possano portare onestamente; è solo una politica di chiusura, aka "se vuoi usare il nostro linguaggio, devi usare hhvm, altrimenti ti attacchi"....non ci vedo niente di male in tutto ciò, ma non significa che non abbiano fiducia in PHP

Non potevano contribuire al progetto php originale cercando di migliorare runtime e linguaggio? Sono sempre stati una società estremamente aperta che ha pubblicato decine di progetti open source. Il fatto che abbiano fatto certe scelte per un punto così fondamentale della loro infrastruttura l'ho sempre percepito come una mancanza di fiducia nel linguaggio e nella comunità che porta avanti il progetto.

dua.net

08-04-2015, 16:22

Grazie a tutti per le vostre risposte e i consigli :)
Non appena ho un po' di tempo prendo visione di tutti i link che mi avete mandato. Comunque in matematica non ho problemi, a scuola stiamo studiando le equazioni di secondo grado. Penso che inizierò con Python, visto che comunque me l'avete consigliato in molti.
Echo

Ti segnalo anche la nuova traduzione italiana di Think Python:
https://github.com/AllenDowney/ThinkPythonItalian/blob/master/thinkpython_italian.pdf?raw=true

71106

08-04-2015, 21:26

Sulla tipizzazione infatti ho semplicemente scritto che PHP è più semplice, Non lo è. Tenere a mente il tipo di ogni variabile è un lavoro in più, che se fosse delegato al compilatore non sarebbe soggetto all'errore umano.

Il sistema di tipi di Haskell è statico, forte, e inferito, quindi oggettivamente perfetto poichè per ogni aspetto di design è stata effettuata la scelta oggettivamente migliore. Per quello di PHP invece è stata effettuata la scelta oggettivamente peggiore.

Poi possiamo sempre buttarla in caciara con le API.

ma visto che parli di Haskell, dato che si basa su programmazione funzionale, soffre della miriade di difetti che quel paradigma porta con sè. Parliamone.

Tenendo conto poi che PHP ed Haskell nascono per scopi ben differenti, direi che il paragone non è molto azzeccato. Confrontare due linguaggi è un compito semplice perchè i linguaggi formali, inclusi PHP e Haskell, sono in ogni caso costituiti da quattro componenti: sintassi lessicale, sintassi astratta, sistema di tipi, e semantica operazionale. Ma al di là di ciò possiamo metterci a farfugliare quello che ci pare e palinfrascare nel modo che più ci diverte, per esempio potremmo dire che tutto è relativo, che non si può fare il confronto, e che una volta qui era tutto campi.

Al contrario, C# invece si presta benissimo a tutti gli usi in cui rientra anche PHP, ma copn considerevoli miglioramenti ed agevolazioni.

Ritengo personalmente che sia all'avanguardia anni luce non solo al PHP, ma a quasi tutti i linguaggi in circolazione che rientrano nel suo campo; potresti spiegarmi perchè ti fa così schifo? E' troppo complesso. Ad esempio è uno dei pochi linguaggi con più d'una sintassi lessicale (detto in altri termini: non so tu ma io LINQ lo trovo inutilizzabile).

71106

08-04-2015, 21:31

E su questo voglio argomentare meglio:

Il sistema di tipi di Haskell è statico, forte, e inferito, quindi [...] per ogni aspetto di design è stata effettuata la scelta oggettivamente migliore.

Un sistema di tipi statico è oggettivamente migliore di uno dinamico per evidenti ragioni di performance.

Un sistema di tipi forte è oggettivamente migliore di uno debole perchè fornisce più garanzie.

Un sistema di tipi inferito è oggettivamente migliore di uno manifesto perchè così il programmatore non deve mettersi a scrivere tediosi nomi di tipi.

71106

08-04-2015, 21:37

Il fatto che abbiano fatto certe scelte per un punto così fondamentale della loro infrastruttura l'ho sempre percepito come una mancanza di fiducia nel linguaggio e nella comunità che porta avanti il progetto. Una sfiducia del tutto lecita: dalla longevità e assurdità di alcuni bug è evidente che PHP è stato creato da un incompetente ed è mantenuto da incompetenti. Tra l'altro il progetto originale non aveva neanche tutte ste pretese, se conoscete il significato dell'acronimo. In definitiva, PHP è solo un brutto incidente.

Facebook al giorno d'oggi non è più al livello di queste porcate. E' chiaro che Zuckerberg al tempo badò solamente al business senza soffermarsi sulle questioni accademiche, ma oggi Facebook è l'azienda che ha proposto un sistema di tipi statico e inferito per JavaScript.

71106

09-04-2015, 19:40

LINQ è manna dal cielo.... L'unica cosa che mi secca è non poter usare una banale funzione aggregata come "count" (cfr. SQL) perchè hanno voluto evitare di rendere "count" una keyword quando si sono resi conto che con 'sta sintassi lessicale stavano a fà porcate pesanti e che il tutto sarebbe divenuto ingestibile anche a livello implementativo. E un paio di altre cose.

LINQ ha una sintassi vagamente funzionale, ma la cosa non mi diturba affatto... Ecco, frena un momento, avevmo iniziato un discorso in proposito. Mi interesserebbe molto approfondirlo.

Poi C# mi sembra davvero semplice, forse hai dei problemi più che altro ad utilizzare Visual Studio, No, tranquillissimo, il problema è proprio il linguaggio. Non sono le API, non è l'IDE, non è la programmazione a oggetti di per se'. Non la sto buttando in caciara, il problema è proprio il linguaggio.

Tra parentesi: anche C# ha un sistema di tipi forte ma allo stesso tempo elastico... Cosa sarebbe un sistema di tipi elastico? :asd:

non vedo quali problemi possa comportare non dichiarare esplicitamente il tipo di una variabile. Nessuno, infatti a me pesano le manine a fare l'opposto.

Come dici tu, però, poi il programmatore deve ricordarsi i tipi delle variabili, od interpretarlo dal contesto... Tanto non c'è comunque possibilità di errore se il sistema di tipi è forte, e i tipi non li scrivi in ogni caso se il linguaggio che usi ha tipaggio dinamico, come PHP. Forte+inferito è sicuramente meglio di dinamico.

siccome però il programmatore non è pigro ed è molto intelligente, Ok, qui le cose sono due: o non hai mai lavorato un solo giorno in vita tua, o tu per pigrizia e stupidità sei una persona peggiore della media.

Non so tu ma io lavoro dal 2011 e di programmatori pigri e stupidi ne ho visti a scatafasci, anche in aziende molto grandi e selettive ai colloqui.

non dovrebbero avere differenze i sistemi di tipo che usa il linguaggio che sta maneggiando Lo strumento di lavoro non dovrebbe mai essere una sfida alle qualità del lavoratore, bensì un aiuto. Specialmente quando le suddette qualità mediamente scarseggiano.

sottovento

10-04-2015, 09:34

E Visual Studio è il top per questo, anche se le qualità di programmatore abbondano.
Sfido chiunque a dimostrare il contrario.
Scusate se mi intrometto nel discorso. Ritengo VS un buon ambiente; tuttavia qui e' richiesto di dimostrare il contrario.
Semplice: in VS basta scrivere

try
{
}
catch (

Ora, qui occorre mettere il tipo dell'eccezione da catturare. Quale aiuto ti da' VS?
E Netbeans?

Per curiosita', non ti e' mai capitato che VS non ti desse alcun suggerimento/autocompletamento, nonostante non ci sia un motivo valido per questo? O, peggio ancora, che te li desse sbagliati? Quante volte ti sei ritrovato a cancellare i file .suo, .sdf, etc? Ed in altri ambienti?
Spesso questo succede nel caso ci sia un errore sintattico nelle linee precedenti quella in editing. Ma Netbeans sembra essere piu' intelligente e riesce ad aiutare anche nelle situazioni in cui VS si e' gia' arreso.

Poi possiamo parlare dell'implementazione di default di stl in VS, ma andremmo fuori tema.

Certo, c'e' da dire che uso VS per C++/C# e Netbeans per Java, ed indubbiamente Java aiuta a sapere quali eccezioni sono sollevate nel blocco try{}, mentre per C++/C# non lo saprai mai :D Potenza del linguaggio!

Quindi: Vs e' un buon ambiente, non e' l'ottimo e ci sono parecchi problemi (come li hanno tutti). Non e' difficile trovare feature che funzionano meglio in altri ambienti. Spero che basti come dimostrazione.

PS. Ciao 71106, bentornato!!

sottovento

10-04-2015, 10:22

Onestamente, non mi è mai capitato. Sempre preciso e funzionale al momento giusto.
Bella fortuna! In ogni ufficio, qui dove lavoro, ci sono le istruzioni per rimediare al problema appese al muro, cosi' che siano ben visibili a tutti.

Aldilà che capita raramente di dover gestire esplicitamente eccezioni con blocchi try...catch, o almeno l'ho dovuto usare pochissimo anche in progetti mastodontici, gestire le eccezioni è un compito pesantissimo, e non andrebbe quasi mai fatto.

Scusa?

"Developing High-Performance ASP.NET Applications":

Do not rely on exceptions in your code. Since exceptions cause performance to suffer significantly, you should never use them as a way to control normal program flow. If it is possible to detect in code a condition that would cause an exception, do so. Do not catch the exception itself before you handle that condition. Common scenarios include checking for null, assigning a value to a String that will be parsed into a numeric value, or checking for specific values before applying math operations. The following example demonstrates code that could cause an exception and code that tests for a condition. Both produce the same result.

Perdono, forse non hai controllato bene cos'hai copiato, qui.
In questo pezzo in prosa, si dice semplicemente di non affidarsi alle eccezioni per il normale flusso di esecuzione. Siamo tutti d'accordo, nessuno avra' mai nulla da dire su questa cosa! Soprattutto in termini di prestazioni, visto che le eccezioni sono generamente implementate mediante longjmp.
Detto questo: cosa c'entra?
Inoltre le eccezioni possono essere sollevate per diversi motivi, per esempio per errori di programmazione, oppure per condizioni oggettive di errore.
L'esempio che fa' e' piuttosto chiaro: non gestire per esempio le situazioni in cui l'eccezione sollevata e' dovuta a valori nulli (i.e. NullPointerException in Java). E ci credo! Andresti a mascherare un problema, non a risolverlo!!
Diverso e' il caso di gestione di eccezioni di I/O. Cosa fa il tuo mastodontico progetto nel caso l'apertura di una socket fallisca causando un'eccezione? Oppure un momentaneo problema di rete? O di file system? Si tratta di eccezioni diverse, sarai ben d'accordo!!
Non c'e' scritto di non gestire le eccezioni! Sarebbe come dire: "abbiamo un linguaggio che supporta le eccezioni, ma non si devono usare". Ha un senso?

E questo vale per tutti i linguaggi che hanno la gestione delle eccezioni. Se per potenza del linguaggio prendi l'esempio delle eccezioni, direi che non è una dimostrazione di forza.

Spero abbia capito cosa intendo: Netbeans mi dira' quali eccezioni posso gestire perche' sollevate nel corrispondente blocco try...catch, VS no. Period

sottovento

10-04-2015, 14:45

Noi ci siamo fatti un specie di wiki sul server, ma niente che sia rilevante all'argomento che stiamo trattando; visto che qui ci lavoriamo in 30, direi che se avessimo trovato grossi problemi ne avremmo riportato evidenza nella doc.

Noi siamo in 15000, forse e' quello che fa la differenza; tuttavia se con google cerchi "visual studio intellisense stopped working" trovi una pletora di informazioni.

Poi oh, un giorno magari mi sposterò su Java, imparerò ad usare meglio Netbeans (Eclipse piuttosto mi sparo in testa) e ti darò ragione, ma al momento non posso che dissentire. Tutto qui.
Sui gusti non discuto; per quanto riguarda questo:

E Visual Studio è il top per questo, anche se le qualità di programmatore abbondano.
Sfido chiunque a dimostrare il contrario.

mi sembra di aver
- trovato una feature che in VS funziona male, mentre la concorrenza non ha problemi;
- trovato una feature che VS non ha (l'intellisense sulle eccezioni, appunto)

La sfida e' stata quindi accettata e apparentemente superata. VS e' un buon ambiente, ma ce ne sono altri altrettanto buoni e in alcune funzionalita' si sono dimostrati migliori.

Visto che siamo in vena, mi tolgo qualche sassolino dalla scarpa. Parlo di eccezioni, non di IDE ma di implementazione del linguaggio.
Nelle versioni di VS fino a VS2003 (che non e' stato abbandonato poi tanto tempo fa), le eccezioni di C++ erano implementate attraverso le SEH (Structured Exceptions) messe a disposizione dal win32.
Ne risultava che anche i possibili crash erano delle comunissime eccezioni, con tutte le conseguenze del caso. Il try...catch catturava anche i crash!

Il risultato era un codice altamente instabile, poiche'
- parti di codice potevano non andare in esecuzione, od essere interrotte senza apparentemente alcun motivo. Per esempio, un programmatore distratto poteva dereferenziare un puntatore nullo causando un crash, ma il catch(...) (la maggior parte dei catch e' a tre punti, visto che non si puo' mai sapere quali eccezioni puo' sollevare un metodo - non e' Java) lo catturava come se nulla fosse!
L'applicazione quindi continuava l'esecuzione dando risultati completamente incomprensibili/erronei
- Peggio ancora, questo causava problemi di perdita dei dati, violazioni di aree critiche, ecc. Tutte cose pericolosissime, con rischio di perdita o corruzione di dati sensibili.

Questa cosa ha sollevato un mare di proteste, dopo che i vari utilizzatori (compresa la mia azienda) avevano perso milioni di euro per questo.

Ecco, come esempio mi sembra buono.

L'implementazione e' stata poi cambiata con VS2005, salvo poi accorgersi che molte applicazioni che funzionavano con VS2003, non andavano piu' una volta passati a 2005 e successivi. Siccome riprendere in mano applicazioni vecchie costa soldi e fatica, e' stato aggiunto nelle opzioni del progetto la possibilita' di usare la vecchia implementazione, reintroducendo l'effetto catastrofico di cui sopra. Bella roba!

Non sono molto informato su altri prodotti - se mai si e' sentita una cosa simile - ma questo non era un bug: era una catastrofe, completa!

||ElChE||88

10-04-2015, 15:31

L'implementazione e' stata poi cambiata con VS2005, salvo poi accorgersi che molte applicazioni che funzionavano con VS2003, non andavano piu' una volta passati a 2005 e successivi. Siccome riprendere in mano applicazioni vecchie costa soldi e fatica, e' stato aggiunto nelle opzioni del progetto la possibilita' di usare la vecchia implementazione, reintroducendo l'effetto catastrofico di cui sopra. Bella roba!

Disastro! :eek:
Come si permettono di aggiungere un opzione per mantenere la retrocompatibilità??? :eek: :eek:
Ma non lo sanno alla microzozzz che i clienti si mantengono trattandoli di merda e cambiando API/ABI ogni 2 mesi??? :eek: :eek:

sottovento

10-04-2015, 15:43

Disastro! :eek:
Come si permettono di aggiungere un opzione per mantenere la retrocompatibilità??? :eek: :eek:
Ma non lo sanno alla microzozzz che i clienti si mantengono trattandoli di merda e cambiando API/ABI ogni 2 mesi??? :eek: :eek:

Sto parlando di implementazione delle eccezioni all'interno del compilatore, non di API. Suona qualche campanello?

71106

11-04-2015, 02:20

Approfondiamo allora, spiegami in cosa la programmazione funzionale sarebbe superiore agli altri paradigmi. Sono confuso, eravamo rimasti che tu avresti portato alla luce la cosiddetta "miriade di difetti che il paradigma funzionale porta con sè".

Spero che tu non abbia intenzionalmente usato un tono così offensivo, e che sia tutto frutto dell'inespressività di un forum. Come mai lo trovi offensivo?

Anche io lavoro dal 2011, e di programmatori stupidi e pigri che durano nelle aziende ne ho visti davvero pochi; Quindi, ad esempio, non hai mai lavorato ne' per Accenture ne' per aziende che intrattengono rapporti con Accenture, dico bene?

e il fatto che io non abbia mai avuto problemi con nessun paradigma/linguaggio/ide che mi sia trovato davanti non credo faccia di me una persona stupida, anzi tutt'altro. Questa è una cosa che chiederei piuttosto a qualcuno che debba mantenere il codice che scrivi.

Ad Accenture fanno praticamente gli stessi discorsi (incluso parlarsi addosso), salvo poi che qualcuno deve disarenare il progetto che è diventato un ammasso di pezze che difficilmente presentano un senso intellegibile.

In ogni caso, C# ha un sistema di tipi molto forte; Molto forte? :D
Questo C# deve essere un linguaggio... impressionante!

non conosco l'haskell ma credo che C# abbia un sistema di tipi altrettanto affidabile, aldilà delle simpatie che uno può avere per un linguaggio piuttosto che per l'altro...non è il linguaggio che fa il programmatore. Perdonami, ma in che modo pensi che questo accrocchio di "non conosco, ma, credo che, simpatie", e saggezza proverbiale conclusiva, possa fornire alcun contributo utile ad alcuna discussione?

E Visual Studio è il top per questo, anche se le qualità di programmatore abbondano.
Sfido chiunque a dimostrare il contrario. E' comprensibile che si faccia fatica a tenere il filo del discorso a distanza di 24 ore, ma non sei neanche costretto a rispondere.

Visual Studio non rientra in nessuno dei miei discorsi (a cui hai spontaneamente preso l'iniziativa di rispondere).

71106

11-04-2015, 02:25

Per curiosita', non ti e' mai capitato che VS non ti desse alcun suggerimento/autocompletamento, nonostante non ci sia un motivo valido per questo? O, peggio ancora, che te li desse sbagliati? Quante volte ti sei ritrovato a cancellare i file .suo, .sdf, etc? Ed in altri ambienti? Domanda inutile, i fanboy non hanno mai problemi con le loro tecnologie.

PS. Ciao 71106, bentornato!! Grazie :D

sottovento

11-04-2015, 10:05

Bah onestamente penso che ormai, non usando più nessuno VS2003, non ci siano più tutte ste catastrofi.
Se investi tanti soldi nello sviluppo di un prodotto, puoi star sicuro che continui ad usarlo. Tuttora ho visitato un cliente che lo usava, e non credo sia una mosca bianca.

Inoltre, dicevamo che in VS2005 c'e' ancora l'opzione per trattare le eccezione C++ come fossero SEH (i.e. la vecchia implementazione), quindi la grande catastrofe e' ancora dentro.
Non ho sottomano ora il mio computer da lavoro, ma se non ricordo male l'opzione in questione non e' mai stata rimossa.

Questo significa che, sebbene MS abbia risolto il problema con un'implementazione decente (questa onestamente non lo era, e decisamente non e' un parere personale), circolano ancora dei software con detta opzione attivata, poiche' funzionano solo in quel caso. O funzionano parzialmente, per esempio eseguendo la parte importante dei calcoli e poi andando in crash piu' tardi, senza motivo apparente. In tal caso l'utente bestemmia un po', ma il risultato l'ha ottenuto. Il livello e' questo

71106

14-04-2015, 14:58

Up.

@coffe_killer, è comprensibile che tu non riesca a rispondermi ma permetti che se tiri il sasso e nascondi la mano io resto curioso.

Hai scritto:

[...] ma visto che parli di Haskell, dato che si basa su programmazione funzionale, soffre della miriade di difetti che quel paradigma porta con sè.

Sono molto interessato a conoscere questa miriade di difetti.

cdimauro

24-04-2015, 20:54

Arrivo tardi causa recente PyCon, e il thread s'è ormai consumato, ma aggiungo qualcosina anch'io. :p
ciò è estremamente influente. Crescere col linguaggio sbagliato è come crescere con genitori violenti e alcolizzati. Che voi ci crediate o no, ho sentito gente lodare PHP. Qualunque appello alla ragione è stato totalmente futile. L'argomento più valido che io sia riuscito a proporre è che PHP è bandito all'interno di Google (appello all'autorevolezza, ma di per se' non è un argomento valido perchè la logica prescinde dall'autorevolezza).
Non è così: Google App Engine supporta PHP. E' anche vero che è stato introdotto dopo Python (linguaggio col quale è stato scritto GAE) e Java, ma Google è stata sostanzialmente costretta a introdurre anche PHP a causa della sua diffusione.
LOL! :D

Quanti ricordi di discussioni passate. :asd:
Già. E tu è da un pezzo che manchi, anche se c'è da dire che ormai tanti utenti di allora sono andati via, ed è un vero peccato perché siamo cresciuti tutti.
Però questa è la prima volta che ti vedo avere effettivamente successo nell'indirizzare un principiante. :D
No no: ho già condotte altre pecorelle smarrite sulla retta via. :cool:
Ti segnalo anche la nuova traduzione italiana di Think Python:
https://github.com/AllenDowney/ThinkPythonItalian/blob/master/thinkpython_italian.pdf?raw=true
Grazie, aggiorno la firma. :D
E' troppo complesso. Ad esempio è uno dei pochi linguaggi con più d'una sintassi lessicale (detto in altri termini: non so tu ma io LINQ lo trovo inutilizzabile).
Peccato, perché invece lo trovo molto comodo.
E su questo voglio argomentare meglio:

Un sistema di tipi statico è oggettivamente migliore di uno dinamico per evidenti ragioni di performance.
Senz'altro. SE le prestazioni sono realmente importanti. Ma ciò non toglie che sia possibile realizzare compilatori JIT che consentono di ottenere delle buone prestazioni anche per linguaggi dinamici.
Un sistema di tipi forte è oggettivamente migliore di uno debole perchè fornisce più garanzie.
Concordo.
Un sistema di tipi inferito è oggettivamente migliore di uno manifesto perchè così il programmatore non deve mettersi a scrivere tediosi nomi di tipi.
Questo lo puoi fare anche se il sistema dei tipi non è inferito. Francamente non capisco quale sarebbe il vantaggio. Aggiungo che ho visto Haskell parecchi anni fa, ma non m'è piaciuto e l'ho completamente rimosso ormai.
Visto che siamo in vena, mi tolgo qualche sassolino dalla scarpa. Parlo di eccezioni, non di IDE ma di implementazione del linguaggio.
Nelle versioni di VS fino a VS2003 (che non e' stato abbandonato poi tanto tempo fa), le eccezioni di C++ erano implementate attraverso le SEH (Structured Exceptions) messe a disposizione dal win32.
Ne risultava che anche i possibili crash erano delle comunissime eccezioni, con tutte le conseguenze del caso. Il try...catch catturava anche i crash!

Il risultato era un codice altamente instabile, poiche'
- parti di codice potevano non andare in esecuzione, od essere interrotte senza apparentemente alcun motivo. Per esempio, un programmatore distratto poteva dereferenziare un puntatore nullo causando un crash, ma il catch(...) (la maggior parte dei catch e' a tre punti, visto che non si puo' mai sapere quali eccezioni puo' sollevare un metodo - non e' Java) lo catturava come se nulla fosse!
L'applicazione quindi continuava l'esecuzione dando risultati completamente incomprensibili/erronei
- Peggio ancora, questo causava problemi di perdita dei dati, violazioni di aree critiche, ecc. Tutte cose pericolosissime, con rischio di perdita o corruzione di dati sensibili.

Questa cosa ha sollevato un mare di proteste, dopo che i vari utilizzatori (compresa la mia azienda) avevano perso milioni di euro per questo.

Ecco, come esempio mi sembra buono.

L'implementazione e' stata poi cambiata con VS2005, salvo poi accorgersi che molte applicazioni che funzionavano con VS2003, non andavano piu' una volta passati a 2005 e successivi. Siccome riprendere in mano applicazioni vecchie costa soldi e fatica, e' stato aggiunto nelle opzioni del progetto la possibilita' di usare la vecchia implementazione, reintroducendo l'effetto catastrofico di cui sopra. Bella roba!

Non sono molto informato su altri prodotti - se mai si e' sentita una cosa simile - ma questo non era un bug: era una catastrofe, completa!
Una curiosità: cosa dice lo standard a riguardo? Si tratta di un dettaglio lasciato al compilatore, o lo standard definisce anche il comportamento delle eccezioni per le varie implementazioni?

OoZic

24-04-2015, 22:19

quante seghe mentali :D

mio modesto parere per qualcuno che vuole cominciare a programmare:

l'ambito startup e' rischioso ma molto divertente.
in ambito startup non bisogna pensare come Google o qualsiasi altra big che deve scalare a miliardi di persone, quindi le seghe sul linguaggio "migliore" lasciano il tempo che trovano.
che poi ogni linguaggio e' un tool a tua disposizione, dipende cosa ci devi fare, non esiste il meglio in assoluto.

Detto questo se dovessi imparare a programmare al giorno d'oggi e pensassi a un mix di opportunita' di lavoro e divertimento sicuramente sceglierei uno tra questi:

Javascript: e' ovunque e cresce continuamente. Sviluppando per il web lato client e' lo standard de-facto. Lato server con Node.js si possono fare cose fantastiche: velocita' di sviluppo notevole e allo stesso tempo "performance" notevoli. Come dice il creatore di Javascript da 20 anni a questa parte "always bet on Javascript". In ambito lavorativo continuera' a crescere la richiesta, che e' gia' molto alta.

Go: lato server l'anno scorso e' esploso e prevedo continuera' a crescere. E' un linguaggio piacevole da scrivere, opinionato e moderno. Prestazioni vicine a C/C++ con tempi di sviluppo infinitamente piu' rapidi. La mascotte e' fantastica.

C/C++: evergreen, quando servono prestazioni, quando serve scalare a dimensioni tipo Google, si rende necessario, ovviamente al costo che e' un linguaggio poco piacevole da scrivere e i tempi di sviluppo si dilatano tantissimo. Impensabile usarlo per un MVP in ambito web.

Python/Ruby sono linguaggi interessanti e sicuramente piacevoli da usare ma in ambito web perderanno sempre piu' terreno perche' non possono offrire le stesse cose che offre Javascript/Go.

Java pure lo vedo in calo, non capisco perche' sceglierlo a Go.
Un vantaggio di Java e' che gira ovunque con la JVM ma con Go puoi compilare praticamente per tutte le maggiori piattaforme.
Java tiene molto soprattutto per l'ambito enterprise da quel che vedo.

C# .NET: chi lo usa ne parla molto bene come linguaggio e come "ecosistema" che comprende Visual Studio, che dicono sia probabilmente il miglior IDE. Per alcune cose tipo fare API REST ho sentito pareri molto negativi, o meglio bestemmie.

Poi ci sono tutti quei linguaggi che sono sostanzialmente di nicchia, specialmente nel functional programmming, tipo Scala con il framework Akka di cui ne parlano gran bene o Haskell. Li vedo adatti a pochi scopi quindi poco appetibili per chi comincia a programmare.

Poi c'e' PHP che fa cacare ci hanno costruito le peggio cose ed e' un linguaggio che andrebbe abbandonato nel 2015.

my 2 cents

ingframin

25-04-2015, 09:27

quante seghe mentali :D

Python/Ruby sono linguaggi interessanti e sicuramente piacevoli da usare ma in ambito web perderanno sempre piu' terreno perche' non possono offrire le stesse cose che offre Javascript/Go.

Ma il mondo non finisce col WWW.
Non so Ruby, Python è usatissimo in ambito scientifico e sta prendendo tantissimo piede nell'industria elettronica.
Ad esempio molte routine di test, sistemi di misura, sistemi di automazione, ecc... fanno larghissimo uso di Python.
Anche se python dovesse perdere terreno in ambito WWW è oramai così diffuso in altri ambiti che non credo sparirà molto presto.
Poi oh...
http://cercalavoro.monster.it/lavoro/?q=python&cy=it
Ah e Java che sta perdendo terreno...
http://cercalavoro.monster.it/lavoro/?q=java&cy=it
E Go...
http://cercalavoro.monster.it/lavoro/?q=developer-go&cy=it

Alla fine il linguaggio migliore è quello che ti permette di portare il pane a casa, tutto il resto e fuffa!

!fazz

25-04-2015, 09:33

Ma il mondo non finisce col WWW.
Non so Ruby, Python è usatissimo in ambito scientifico e sta prendendo tantissimo piede nell'industria elettronica.
Ad esempio molte routine di test, sistemi di misura, sistemi di automazione, ecc... fanno larghissimo uso di Python.
Anche se python dovesse perdere terreno in ambito WWW è oramai così diffuso in altri ambiti che non credo sparirà molto presto.
Poi oh...
http://cercalavoro.monster.it/lavoro/?q=python&cy=it
Ah e Java che sta perdendo terreno...
http://cercalavoro.monster.it/lavoro/?q=java&cy=it
E Go...
http://cercalavoro.monster.it/lavoro/?q=developer-go&cy=it

Alla fine il linguaggio migliore è quello che ti permette di portare il pane a casa, tutto il resto e fuffa!

adesso non esagerare :D

OoZic

25-04-2015, 10:36

71106

25-04-2015, 10:40

Non è così: Google App Engine supporta PHP. E' anche vero che è stato introdotto dopo Python (linguaggio col quale è stato scritto GAE) e Java, ma Google è stata sostanzialmente costretta a introdurre anche PHP a causa della sua diffusione. Tuttavia per usi interni è letteralmente proibito. Non credo che esistano fonti pubbliche che attestano ciò, ma qualcuno che anche tu conosci bene ora lavora per Google e mi ha raccontato episodi assai divertenti. :D

Già. E tu è da un pezzo che manchi, anche se c'è da dire che ormai tanti utenti di allora sono andati via, ed è un vero peccato perché siamo cresciuti tutti. fek però lo vedo ancora trollare nelle news. :asd:

(tra l'altro io ero totalmente in disaccordo, ma che devi fare, lavora per Apple e giustamente la deve difendere. :D )

No no: ho già condotte altre pecorelle smarrite sulla retta via. :cool: :rotfl:

Peccato, perché invece lo trovo molto comodo. Trovo che sarebbe stato molto più comodo se avessero potuto implementare una marea di funzioni aggregate e altre features che sono rimaste disponibili solo come metodi invocabili in maniera procedurale, al di fuori della sintassi LINQ.

Eppure la soluzione pulita non era affatto difficile, persino PHP (dico, PHP!) implementa una soluzione sintattica migliore con le "heredoc strings". Che ci vuole ad "aprire" la sintassi LINQ con una sequenza di caratteri predeterminata e a "richiuderla" con un'altra sequenza?

Senz'altro. SE le prestazioni sono realmente importanti. Ma ciò non toglie che sia possibile realizzare compilatori JIT che consentono di ottenere delle buone prestazioni anche per linguaggi dinamici. Sta benissimo il principio "early optimization is the root of all evil", io ci credo talmente tanto che l'ho pure scritto nel curriculum tra le mie "Software Engineering Skills". Ma non dimentichiamoci che quando il sistema di tipi è dinamico il rilevamento degli errori è relegato interamente alla fase di testing, e che ci sono errori che potrebbero non essere mai scoperti dagli sviluppatori, arriverebbero come sorpresa direttamente agli utenti.

Questo lo puoi fare anche se il sistema dei tipi non è inferito. Un sistema di tipi non inferito in cui non specifichi i tipi a mano è un sistema di tipi dinamico, quindi l'argomento si riduce al precedente.

71106

25-04-2015, 10:53

Ma il mondo non finisce col WWW. E, soprattutto, le tecnologie del web appartengono a cani e porci. Il mercato degli sviluppatori software è molto variegato, uno sviluppatore che conosce tecnologie un po' più esclusive di HTML, CSS, e JavaScript può arrivare a guadagnare più del doppio (a parità di età e anni di esperienza lavorativa) di uno sviluppatore web.

Io comunque credo che, almeno nel lungo termine, siano le metodologie a contare molto più delle tecnologie. Ma anche in tal caso credo che ci siano una marea di cani & porci di cui sopra che nel loro bagaglio non possiedono ne' tecnologie ne' metodologie. Vanno in giro a vendere scarse abilità di sviluppo web e se la cavano.

Tommo

25-04-2015, 11:24

Sta benissimo il principio "early optimization is the root of all evil", io ci credo talmente tanto che l'ho pure scritto nel curriculum tra le mie "Software Engineering Skills". Ma non dimentichiamoci che quando il sistema di tipi è dinamico il rilevamento degli errori è relegato interamente alla fase di testing, e che ci sono errori che potrebbero non essere mai scoperti dagli sviluppatori, arriverebbero come sorpresa direttamente agli utenti.

Ultimamente ogni volta che sento qualcuno ripetere quella frase becera parto in un rant pero' :asd:
Il principio di fondo e' corretto, non si dovrebbero mai fare micro-ottimizzazioni tipo loop unrolling o instruction reordering o scegliere una struttura dati "scorretta" (eg vettore invece di una hashmap per un dizionario) fino a che non ci sono dati certi.

Ma d'altra quando lo dice chiunque non sia un programmatore C++ significa "sto ignorando completamente le performance nel design" fino al punto di sbattersene completamente della complessita' algoritmica delle cose...
la performance e' un parametro che e' parte del design del sistema come tutto il resto, cosi' come non puoi rimuovere il coupling patchando un paio di files cosi' non puoi avere le performance massime smanacciando con le micro-ottimizzazioni after the fact.
Se non fosse cosi', JS e Java potrebbero raggiungere la velocita' di C++... ma non possono, perche' il linguaggio ti forza ad usare strutture dati e algoritmi inefficienti che il compilatore non puo' ottimizzare.

tl;dr: di solito chi si difende dietro quella frase se ne sbatte dell'esperienza dell'utente e della qualita' finale del programma, vuole solo scrivere "codice pulito" fine a se stesso. Oppure e' pigro/ignorante.

cdimauro

25-04-2015, 16:38

Tuttavia per usi interni è letteralmente proibito. Non credo che esistano fonti pubbliche che attestano ciò, ma qualcuno che anche tu conosci bene ora lavora per Google e mi ha raccontato episodi assai divertenti. :D
Non so di chi parli, ma è ben noto che in Google usino Python e C++ principalmente, poi Java, e di recente si sta facendo strada pure Go.
fek però lo vedo ancora trollare nelle news. :asd:

(tra l'altro io ero totalmente in disaccordo, ma che devi fare, lavora per Apple e giustamente la deve difendere. :D )
Non mi pare che trolli, a meno che con questo ti riferisci ai toni diciamo sopra le righe che ha usato di recente. I fatti che ha riportato rimangono fatti, a prescindere che lui lavori o meno per Apple. Altrimenti pure io dovrei smettere di parlare di processori a causa di un chiaro conflitto d'interessi. ;)
Trovo che sarebbe stato molto più comodo se avessero potuto implementare una marea di funzioni aggregate e altre features che sono rimaste disponibili solo come metodi invocabili in maniera procedurale, al di fuori della sintassi LINQ.
LINQ ha cercato di coprire i casi d'uso più comune. Purtroppo non penso si possa trovare un meccanismo generalizzabile a qualunque contesto in cui si debbano processare (recuperare, filtrare, ordinare, produrre) dati.

SQL è e rimane un buon strumento per questo tipo di problematiche, e LINQ è stato sostanzialmente basato su quello. Con tutti i pregi e difetti del caso, ma personalmente lo trovo uno strumento molto "bello" e comodo da usare.
Eppure la soluzione pulita non era affatto difficile, persino PHP (dico, PHP!) implementa una soluzione sintattica migliore con le "heredoc strings". Che ci vuole ad "aprire" la sintassi LINQ con una sequenza di caratteri predeterminata e a "richiuderla" con un'altra sequenza?
Non conosco le heredoc strings, ma da quel che scrivi mi pare il classico meccanismo di embedding di sintassi diverse da quella del linguaggio "ospite", a cui ovviamente si affianca un protocollo per il passaggio dei dati (parametri per il codice "guest").

E' una soluzione che, onestamente, non m'è mai piaciuta. Io preferisco utilizzare lo stesso linguaggio per modellare ciò che serve.

Ad esempio, con Python ho scritto una libreria per interfacciarsi coi database che mi consente di fare roba del genere:
DB.Tokens[UserID == in_UserID] = ExpireTime == '2000-01-01'

Che tradotta in SQL verrebbe (verrà):

UPDATE Tokens SET ExpireTime = '2000-01-01' WHERE UserID = in_UserID
E' una questione gusti, ma io preferisco la versione "pythonica", perché mi permette di astrarmi dal DB, usando peraltro la stessa sintassi del linguaggio, e quindi in futuro potrei cambiare anche totalmente l'engine che c'è sotto, con modifiche minimali o anche nulle.
Sta benissimo il principio "early optimization is the root of all evil", io ci credo talmente tanto che l'ho pure scritto nel curriculum tra le mie "Software Engineering Skills". Ma non dimentichiamoci che quando il sistema di tipi è dinamico il rilevamento degli errori è relegato interamente alla fase di testing, e che ci sono errori che potrebbero non essere mai scoperti dagli sviluppatori, arriverebbero come sorpresa direttamente agli utenti.
Un codice non testato non è codice. ;)
Un sistema di tipi non inferito in cui non specifichi i tipi a mano è un sistema di tipi dinamico, quindi l'argomento si riduce al precedente.
Non necessariamente. Nessuno m'impedisce di usare un ben preciso tipo (o una "famiglia", nel caso di OOP) per una determinata variabile anche con un linguaggio dinamicamente tipato. In questo caso non ci sono differenze con un linguaggio staticamente tipato, e il tipo può essere dedotto ricostruendo il workflow.

Molti IDE avanzati lo fanno anche con Python, ed è dannatamente bello vedere l'autocompletamento che agisce correttamente perché il tipo della variabile è stato inferito dal precedente codice. :D

Comunque si parlava dell'assegnazione dei nomi alle variabili, e non vedo differenze in questo senso con un linguaggio basato sull'inferenza dei tipi. Voglio dire: sono io che assegno un nome consono alle variabili, e non vedo come un linguaggio come Haskell potrebbe influenzare (positivamente, s'intende) le scelte che, in ogni caso, faccio io. :)
Ultimamente ogni volta che sento qualcuno ripetere quella frase becera parto in un rant pero' :asd:
Il principio di fondo e' corretto, non si dovrebbero mai fare micro-ottimizzazioni tipo loop unrolling o instruction reordering o scegliere una struttura dati "scorretta" (eg vettore invece di una hashmap per un dizionario) fino a che non ci sono dati certi.

Ma d'altra quando lo dice chiunque non sia un programmatore C++ significa "sto ignorando completamente le performance nel design" fino al punto di sbattersene completamente della complessita' algoritmica delle cose...
la performance e' un parametro che e' parte del design del sistema come tutto il resto, cosi' come non puoi rimuovere il coupling patchando un paio di files cosi' non puoi avere le performance massime smanacciando con le micro-ottimizzazioni after the fact.
Se non fosse cosi', JS e Java potrebbero raggiungere la velocita' di C++... ma non possono, perche' il linguaggio ti forza ad usare strutture dati e algoritmi inefficienti che il compilatore non puo' ottimizzare.

tl;dr: di solito chi si difende dietro quella frase se ne sbatte dell'esperienza dell'utente e della qualita' finale del programma, vuole solo scrivere "codice pulito" fine a se stesso. Oppure e' pigro/ignorante.
Sì, Tommo, ma nessuno sta dicendo che non si debba mai tenere conto delle performance.

Se un programmatore sviluppa una soluzione per un determinato problema, penso sia lapalissiano che debba essere utilizzabile dal cliente. ;)

Tommo

25-04-2015, 16:55

Se un programmatore sviluppa una soluzione per un determinato problema, penso sia lapalissiano che debba essere utilizzabile dal cliente. ;)

Certo, il rant non era in risposta a nessuno, era un rant partito di suo :D fosse sempre cosi' lapalissiano per tutti :asd:

cdimauro

25-04-2015, 17:13

Per tutti, tranne quelli che sono passati troppo velocemente dalla zappa alla tastiera (e sono tanti, purtroppo). Lì, in effetti, il discorso non è più così lapalissiano. :D

71106

25-04-2015, 21:57

Ma d'altra quando lo dice chiunque non sia un programmatore C++ significa "sto ignorando completamente le performance nel design" fino al punto di sbattersene completamente della complessita' algoritmica delle cose... Ti cito due fatti estrapolati dalla mia esperienza lavorativa.

Il 90% della gente tenta insistentemente di ridurre i tempi di esecuzione di algoritmi la cui complessità è già costante.
Una volta mi è capitato sotto mano un algoritmo che aveva complessità quadratica, così ne ho progettato un altro che produceva il risultato in tempo O(NlogN). La mia soluzione è stata scartata perchè i tempi di esecuzione della versione quadratica erano comunque ragionevoli. Il tutto era scritto in JavaScript e il princìpio è rimasto perfettamente valido: "early optimization is the root of all evil."

Se non fosse cosi', JS e Java potrebbero raggiungere la velocita' di C++... ma non possono, perche' il linguaggio ti forza ad usare strutture dati e algoritmi inefficienti che il compilatore non puo' ottimizzare. Per esempio...?

tl;dr: di solito chi si difende dietro quella frase se ne sbatte dell'esperienza dell'utente e della qualita' finale del programma, vuole solo scrivere "codice pulito" fine a se stesso. Oppure e' pigro/ignorante. Ti cito un ulteriore fatto estrapolato dalla mia esperienza: nel lavoro di tutti i giorni non capita praticamente mai di dover ottimizzare algoritmi di complessità più che costante e se capita ti viene praticamente vietato di farlo perchè non puoi essere l'unico del team a conoscere i princìpi matematici che stanno dietro la soluzione, quindi ti viene imposto di usare librerie già pronte (mi è successo). La maggior parte della gente si ostina ottusamente a ottimizzare algoritmi di complessità O(1), e in almeno metà dei casi non si rende mai conto che non ha senso e che stanno solo complicando il codice.

I fatti che ha riportato rimangono fatti, a prescindere che lui lavori o meno per Apple. Senti. :asd:
Io quell'orologio lo trovo da femmina. Tutte le varianti. :D
E francamente non mi sembra neanche tanto utile, o quantomeno gli esempi di utilità quotidiana che fek riportava erano eventualità estremamente rare nella mia vita (non so tu ma io dove sta la mia banca lo so :p ).

Insomma, difendeva il prodotto dell'azienda per cui lavora ma non mi ha convinto per niente (sto solo dicendo la mia, io non lo comprerei).

E si, trollava. In maniera molto spiccata. Poichè è ben noto che de gustibus non disputandum est. Se ti metti a discutere di questioni soggettive per definizione, proponendo argomenti che spacci per oggettivi sfruttando l'argomento dell'appello all'autorità, ti stai semplicemente divertendo a blastare un niubbo. :D

Non conosco le heredoc strings, ma da quel che scrivi mi pare il classico meccanismo di embedding di sintassi diverse da quella del linguaggio "ospite", a cui ovviamente si affianca un protocollo per il passaggio dei dati (parametri per il codice "guest").

E' una soluzione che, onestamente, non m'è mai piaciuta. Io preferisco utilizzare lo stesso linguaggio per modellare ciò che serve. Facciamo un esempio concreto. Diciamo che abbiamo in C# un array di numeri interi con segno e vogliamo ottenere la somma di quelli positivi. Potremmo scrivere:

int[] numbers = new int[] { ... };
return (from number in numbers
where number > 0
select number).Sum();

Ma se in C# potessimo usare, ad esempio, il carattere backtick per delimitare porzioni di codice LINQ, potremmo ipotizzare un'espressione del genere:

int[] numbers = new int[] { ... };
return `from number in numbers
where number > 0
select sum(number)`;

Il vantaggio per Microsoft è che non deve rendere keyword mezzo dizionario della lingua inglese, mentre i vantaggi per lo sviluppatore finale sono la leggibilità e il non dover mischiare paradigmi di programmazione.

Ritengo sia più semplice per tutti (sia per Microsoft che per gli sviluppatori finali), o no? Non c'è bisogno di pensare ad alcun protocollo di passaggio di dati.

Un codice non testato non è codice. ;) Non è sempre possibile testare l'intero dominio dell'input di un algoritmo, in alcuni casi il codice di testing potrebbe assumere complessità asintotica esponenziale.

Non necessariamente. Nessuno m'impedisce di usare un ben preciso tipo (o una "famiglia", nel caso di OOP) per una determinata variabile anche con un linguaggio dinamicamente tipato. In questo caso non ci sono differenze con un linguaggio staticamente tipato, e il tipo può essere dedotto ricostruendo il workflow. Non ho ben capito l'esempio a cui ti riferisci, ma "può essere dedotto ricostruendo il workflow" mi sembra inferenza (e mi sembra un'operazione statica, nel senso che va fatta a tempo di compilazione piuttosto che di esecuzione).

Comunque si parlava dell'assegnazione dei nomi alle variabili, e non vedo differenze in questo senso con un linguaggio basato sull'inferenza dei tipi. Voglio dire: sono io che assegno un nome consono alle variabili, e non vedo come un linguaggio come Haskell potrebbe influenzare (positivamente, s'intende) le scelte che, in ogni caso, faccio io. :) Quando si parlava di assegnazione di nomi alle variabili? Io ho scritto questo:

Un sistema di tipi inferito è oggettivamente migliore di uno manifesto perchè così il programmatore non deve mettersi a scrivere tediosi nomi di tipi.

VICIUS

25-04-2015, 23:22

Per esempio...?

class Rectangle {
int x, y, width, height;
}

...
Rectangle[] rectangles = new Rectangle[10];
...

In Java non c'è modo di creare struct o di controllare il layout di quello che viene allocato. L'array non contiene gli oggetti veri e propri ma dei semplici riferimenti a dove sono stati allocati nell'heap. Questo porta a cache misses ogni due per tre e al processore che fatica ad usare il prefetching.

Se fosse possibile l'incremento di prestazioni sarebbe piuttosto consistente. Non è un caso che ci siano almeno due gruppi di lavoro si stanno concentrando su questo.

71106

25-04-2015, 23:44

class Rectangle {
int x, y, width, height;
}

...
Rectangle[] rectangles = new Rectangle[10];
...

In Java non c'è modo di creare struct o di controllare il layout di quello che viene allocato. L'array non contiene gli oggetti veri e propri ma dei semplici riferimenti a dove sono stati allocati nell'heap. Questo porta a cache misses ogni due per tre e al processore che fatica ad usare il prefetching.

Se fosse possibile l'incremento di prestazioni sarebbe piuttosto consistente. Non è un caso che ci siano almeno due gruppi di lavoro si stanno concentrando su questo.

Il linguaggio non "ti forza a usare strutture dati e algoritmi inefficienti". Per ottimizzare la struttura dati di cui sopra nei termini che poni basta scrivere:

class RectangleArray {
int[] x = new int[10];
int[] y = new int[10];
int[] width = new int[10];
int[] height = new int[10];
}

VICIUS

26-04-2015, 01:31

Quello che cerco è un array di struct come in C. Non è difficile ma Java non me lo permette perché quando è stato concepito sono state fatte certe scelte. Non sono forse costretto ad usare un "array di puntatori" al posto di quello che voglio? Mi sembrava un valido esempio di quello che stesse cercando di dire Tommo.

Poi si. Ci puoi provare a mettere un po' una pezza con hack e porcate varie ma non dovrebbe essere necessario.

cdimauro

26-04-2015, 09:07

Senti. :asd:
Io quell'orologio lo trovo da femmina. Tutte le varianti. :D
De gustibus. Ma Fran non ha contestato quello, quanto l'associazione "tondo -> femminile" (se non ricordo male), riportando alcuni esempi di orologi maschili di altre marche che avevano un design simile all'AppleWatch.
E francamente non mi sembra neanche tanto utile, o quantomeno gli esempi di utilità quotidiana che fek riportava erano eventualità estremamente rare nella mia vita (non so tu ma io dove sta la mia banca lo so :p ).
Io no. :asd: A parte gli scherzi, a me è capitato di dover cercare una filiale della mia banca vicino al posto in cui mi trovavo in un certo momento. Ma in generale l'esigenza di cercare qualche posto credo sia abbastanza comune.
Insomma, difendeva il prodotto dell'azienda per cui lavora ma non mi ha convinto per niente (sto solo dicendo la mia, io non lo comprerei).
A me ha convinto, perché gli esempi che ha fatto sono di situazioni reali e che vengono risolte elegantemente e facilmente con l'AppleWatch.

Non lo compro per altri motivi:
- ho una forte tendenza a non cambiare qualcosa finché non funziona più (quello che indosso adesso è il SECONDO orologio che ho avuto in tutta la mia vita, e fai conto che le cifre dei miei anni sono identiche e una potenza di due :D);
- si tratta di progetto che è ancora immaturo, soprattutto in termini di autonomia;
- ha un costo abbastanza elevato per quello che offre.
E si, trollava. In maniera molto spiccata. Poichè è ben noto che de gustibus non disputandum est. Se ti metti a discutere di questioni soggettive per definizione, proponendo argomenti che spacci per oggettivi sfruttando l'argomento dell'appello all'autorità, ti stai semplicemente divertendo a blastare un niubbo. :D
Non ha fatto quello, dai. Per me ha trollato quando è passato sul piano personale; cosa che a mio avviso avrebbe potuto fare benissimo a meno, visto che è perfettamente in grado di sostenere una discussione argomentando (come ben sappiamo :D).

Sulle questioni soggettive vs oggettive vedi sopra.

Comunque preferirei concentrarmi sull'aspetto tecnico di questa discussione, che è già di per sé mostruosamente OT (as usual :asd: ).
Facciamo un esempio concreto. Diciamo che abbiamo in C# un array di numeri interi con segno e vogliamo ottenere la somma di quelli positivi. Potremmo scrivere:

int[] numbers = new int[] { ... };
return (from number in numbers
where number > 0
select number).Sum();

Ma se in C# potessimo usare, ad esempio, il carattere backtick per delimitare porzioni di codice LINQ, potremmo ipotizzare un'espressione del genere:

int[] numbers = new int[] { ... };
return `from number in numbers
where number > 0
select sum(number)`;

Il vantaggio per Microsoft è che non deve rendere keyword mezzo dizionario della lingua inglese, mentre i vantaggi per lo sviluppatore finale sono la leggibilità e il non dover mischiare paradigmi di programmazione.
Premesso che non vedo il problema di utilizzare keyword prese dal dizionario inglese (un programmatore in genere NON dovrebbe utilizzarle proprio perché consapevole del rischio di venir adottate da una futura versione del linguaggio), non è nemmeno necessario.

Nello specifico esempio, sarebbe sufficiente che sum fosse una funzione che accettasse una sequenza (in Python si userebbe un iteratore) e restituisse un valore di tipo intero con segno. Il compilatore provvederebbe a convertire l'espressione LINQ nella solita funzione anonima che funge da iteratore, passandola alla funzione sum.

E' soltanto un esempio, per dire che non serve affatto ampliare mostruosamente il linguaggio ridefinendo keyword ad hoc. C# ha il vantaggio di mettere a disposizione l'overloading delle funzioni, e si può sfruttare quello per risolvere la problematica in questione.

Sia chiaro, che pure a me non piace molto la soluzione attuale di LINQ, per due motivi:
- si passa dalla sintassi SQL-like a un misto di funzionale & a oggetti (usando .Sum(), per intenderci);
- è vincolata alla base, visto che è LINQ che deve definire le varie funzioni di aggregazione (anche se ci sono le estensioni dei metodi nel linguaggio).
Ritengo sia più semplice per tutti (sia per Microsoft che per gli sviluppatori finali), o no?
In realtà devi realizzare due compilatori per due sintassi diverse. Quindi doppio lavoro per Microsoft e per gli utenti. :-(
Non c'è bisogno di pensare ad alcun protocollo di passaggio di dati.
In realtà c'è ed è implicito, perché i dati vengono comunque passati alla funzione anonima che è stata creata allo scopo, e allo stesso modo vengono recuperati i risultati.
Non è sempre possibile testare l'intero dominio dell'input di un algoritmo, in alcuni casi il codice di testing potrebbe assumere complessità asintotica esponenziale.
Non di meno, i test vanno scritti. O, al limite, si va di manual testing, tirando fuori un apposito test plan e valutando i rischi di test parziali.

Veramente, nel 2015 non si può e non voglio sentir parlare di codice non testato.
Non ho ben capito l'esempio a cui ti riferisci, ma "può essere dedotto ricostruendo il workflow" mi sembra inferenza (e mi sembra un'operazione statica, nel senso che va fatta a tempo di compilazione piuttosto che di esecuzione).
Sì, mi riferivo a quello.
Quando si parlava di assegnazione di nomi alle variabili? Io ho scritto questo: "Un sistema di tipi inferito è oggettivamente migliore di uno manifesto perchè così il programmatore non deve mettersi a scrivere tediosi nomi di tipi."
OK, dovevo scrivere identificatori in generale, visto che in Python anche i tipi sono variabili. :D

Sì, anche limitandoci ai tipi, onestamente non capisco il vantaggio che può portare un linguaggio come Haskell. Limite mio, sia chiaro, perché non lo conosco.
Il linguaggio non "ti forza a usare strutture dati e algoritmi inefficienti". Per ottimizzare la struttura dati di cui sopra nei termini che poni basta scrivere:

class RectangleArray {
int[] x = new int[10];
int[] y = new int[10];
int[] width = new int[10];
int[] height = new int[10];
}

Mah, questo lo considero un hack brutto come la morte a vedersi. Concordo con VICIUS nel voler utilizzare un array di una qualunque struttura senza ricorrere a soluzione diciamo "poco ortodosse" come queste.

E' una mia esigenza di sviluppatore. Io voglio modellare qualcosa in maniera semplice e intellegibile.

GTKM

26-04-2015, 10:47

Il linguaggio non "ti forza a usare strutture dati e algoritmi inefficienti". Per ottimizzare la struttura dati di cui sopra nei termini che poni basta scrivere:

class RectangleArray {
int[] x = new int[10];
int[] y = new int[10];
int[] width = new int[10];
int[] height = new int[10];
}

Vero, ma è un hack che potrebbe/dovrebbe essere evitato, se il linguaggio (o la sua implementazione) non avesse determinati limiti.
Non è sempre possibile testare l'intero dominio dell'input di un algoritmo, in alcuni casi il codice di testing potrebbe assumere complessità asintotica esponenziale.
Non è possibile testare l'intero dominio, ma ciò può essere fatto con un sottodominio, e tenendo in considerazione "l'errore" che questo tipo di operazione si porta dietro, o no? Non ti mette totalmente al riparo dal caso disgraziato, ma credo ci sia una bella differenza rispetto al non testare completamente il codice.

Non sono dentro il mondo del lavoro ancora, ma ho la sensazione che il mancato testing dipenda più da una questione di "budget", che di limiti tecnici. Ma potete smentirmi in qualsiasi momento, ovviamente.
Io son qui per imparare :D

Tommo

26-04-2015, 12:47

Il linguaggio non "ti forza a usare strutture dati e algoritmi inefficienti". Per ottimizzare la struttura dati di cui sopra nei termini che poni basta scrivere:

class RectangleArray {
int[] x = new int[10];
int[] y = new int[10];
int[] width = new int[10];
int[] height = new int[10];
}

Chiamalo niente. Praticamente il linguaggio ti obbliga a scegliere tra efficienza e buon codice, a me pare un problema :read:
Ad esempio e' famoso il dramma in Minecraft quando hanno deciso di usare "class BlockPos" e "class Vec3" invece che float x,y,z sparsi... in C++ e' gratis, in Java causa 24000 allocazioni per frame e devasta le performance, con buona pace dell'escape analysis che funzionava solo in una minoranza dei casi.
In generale tutti i linguaggi "GC only" (un po' meno C# con la pezza dei value types) nascono da un'approccio nato negli anni 90 quando l'accesso alla memoria non era mai il collo di bottiglia (voglio dire, in JS tutto e' un'hashmap brr).
Oggi le cose sono cambiate, e per uno scherzo del destino quei linguaggi sono in proporzione piu' lenti rispetto a quando sono stati inventati :asd:
Ad esempio, oggi la maggior parte dei computer hanno cache piccole, bandwidth ridotte, e funzionano in-order affidandosi alle ottimizzazioni che fa il compilatore (leggi: sono ARM), e questo non aiuta affatto.

In ogni caso, "idiomatico" e' una cosa che esiste e se il linguaggio rende piu' facile un approccio e' quello che il 90% delle volte verra' usato.

Esiste il Default Effect (http://en.wikipedia.org/wiki/Default_effect_%28psychology%29) :D

WarDuck

26-04-2015, 15:50

Concordo con Tommo e aggiungo una piccola nota: usando le variabili in quel modo potresti avere l'effetto tutt'altro che benefico di spargere dati di un singolo oggetto in locazioni molto distanti tra loro, diversamente dal caso "aggregato".

Specialmente se gli accessi alle variabili sono correlati. Esempio: hash table. Key e Value in un unico oggetto piuttosto che un array di Key e un array di Value.

Il primo caso è preferibile, perché dopo che ho trovato la Key è molto probabile che voglia accedere al suo Value (se la Key è relativamente piccola o uso un fingerprint al 99% trovo il Value già in cache).

Nella maggior parte dei casi probabilmente sarebbe meglio tenere le variabili membro vicine tra loro (ovvero tutti quei casi in cui non hai problemi di false sharing).

PS: i recenti arm dovrebbero essere out-of-order.

71106

26-04-2015, 23:28

De gustibus. Ma Fran non ha contestato quello, quanto l'associazione "tondo -> femminile" (se non ricordo male), riportando alcuni esempi di orologi maschili di altre marche che avevano un design simile all'AppleWatch. Non ho la forza ne' il coraggio di andare a ripescare quei post ma che io ricordi fek ha più volte fatto appello all'autorità di stilisti emergenti o roba simile per sostenere le sue tesi estetiche in contrasto con le affermazioni della vittima ( :asd: ) di turno.

Io lo trovo disonesto: lo stilista emergente può affermare quello che gli pare ma ognuno ha diritto al suo parere estetico. Anzi: lo stilista emergente spesso viene usato, direttamente o indirettamente ma sempre dietro appropriata retribuzione, per influenzare l'opinione comune e far avvicinare l'oggettivo al soggettivo. Non dico nulla contro il mestiere di Apple o dello stilista emergente, mi va tutto bene finchè si lavora onestamente nel rispetto delle leggi vigenti. Dico solo che a me quell'orologio sembra un delfino che vomita arcobaleni, e la vittima ( :asd: ) di turno mi sembrava dire la stessa cosa in almeno parte dei suoi discorsi.

Io no. :asd: A parte gli scherzi, a me è capitato di dover cercare una filiale della mia banca vicino al posto in cui mi trovavo in un certo momento. Ma in generale l'esigenza di cercare qualche posto credo sia abbastanza comune. Ok, ci sto: può servire di sapere come raggiungere un posto dopo che si è già usciti di casa. Tuttavia continua a essere un'eventualità remota nella mia vita, la quale, che ti devo dire, sarà un po' troppo abitudinaria. :p
(nel senso che vado sempre negli stessi posti che già conosco)

- ho una forte tendenza a non cambiare qualcosa finché non funziona più (quello che indosso adesso è il SECONDO orologio che ho avuto in tutta la mia vita, e fai conto che le cifre dei miei anni sono identiche e una potenza di due :D); :|

Stima. :asd:

- ha un costo abbastanza elevato per quello che offre. Una tautologia nel caso di Apple.

Comunque preferirei concentrarmi sull'aspetto tecnico di questa discussione, che è già di per sé mostruosamente OT (as usual :asd: ). Tanto nun j'aregge ai moderatori di spizzarsi tutti sti muri di testo per capire che è OT. :asd:

(non c'è più il buon vecchio cionci. :D )

Nello specifico esempio, sarebbe sufficiente che sum fosse una funzione che accettasse una sequenza (in Python si userebbe un iteratore) e restituisse un valore di tipo intero con segno. Il compilatore provvederebbe a convertire l'espressione LINQ nella solita funzione anonima che funge da iteratore, passandola alla funzione sum. Se all'interno della sintassi di LINQ la parola "sum" deve fare riferimento a qualcosa di particolare le cose sono due, o è una keyword o è un nome globale. Stiamo sempre nel campo delle ipotesi ovviamente, visto che la funzione aggregata della somma non è presente in LINQ, ma non ipotizziamo soluzioni ancora più zozze di quelle che già sono. :D

Secondo me, again, "isolare" completamente la sintassi di LINQ con delle sequenze di caratteri che indicano il passaggio è la soluzione migliore perchè a quel punto, finalmente, puoi fare di LINQ tutto quello che ti pare. Dentro i backtick puoi scrivere programmi per qualunque linguaggio di programmazione che non usi i backtick nella propria sintassi.

In realtà devi realizzare due compilatori per due sintassi diverse. Quindi doppio lavoro per Microsoft e per gli utenti. :-( Non esageriamo con queste approssimazioni: si tratta solo di dividere il compilatore già esistente in due parti ben distinte che interagiscono in maniera più semplice e chiara. Col vantaggio che ai uno dei due si possono aggiungere molte funzionalità utili, come appunto le funzioni aggregate.

In realtà c'è ed è implicito, perché i dati vengono comunque passati alla funzione anonima che è stata creata allo scopo, e allo stesso modo vengono recuperati i risultati. Le "heredoc strings" di PHP producono niente altro che stringhe, ossia valori regolari del dominio dei dati di PHP. Lo stesso vale per la mia ipotetica "sintassi delimitata" di LINQ: in corrispondenza di un "LINQ literal" il parser genera una porzione di AST che, quando valutata, produce nient'altro che regolari valori del dominio della piattaforma .NET. Passi dati tanto quanto ne passi nello scrivere uno string literal. Non c'è nessun protocollo extra, nessuna procedura di marshalling / unmarshalling.

Non di meno, i test vanno scritti. O, al limite, si va di manual testing, tirando fuori un apposito test plan e valutando i rischi di test parziali.

Veramente, nel 2015 non si può e non voglio sentir parlare di codice non testato. Per carità, d'accordissimo. Ma immagino che sarai d'accordo nel riconoscere che le garanzie qui non sono al 100%.

Inoltre, punto fondamentale, stavamo parlando di una questione di design del linguaggio. Il design del linguaggio non dovrebbe mai essere peggiore con la scusa del delegare la qualità finale agli strumenti successivi nella toolchain.

Sì, mi riferivo a quello. Dunque, come dicevo, un sistema di tipi che non è ne' inferito ne' manifesto è necessariamente dinamico. Giusto?

OK, dovevo scrivere identificatori in generale, visto che in Python anche i tipi sono variabili. :D Un giorno o l'altro mi tocca darci un'occhiata più seriamente a 'sto Python. :asd:

Sì, anche limitandoci ai tipi, onestamente non capisco il vantaggio che può portare un linguaggio come Haskell. Limite mio, sia chiaro, perché non lo conosco. La teoria a me sembra chiara: un sistema di tipi statico, forte, e inferito permette di scrivere programmi correttamente tipati in maniera più concisa e senza causare alcuna penalità di performance a runtime (si, va benissimo, nel 99% dei casi la penalità è impercettibile, "early optimization is the root of all evil", but still: non c'è motivo di aggiungere cicli di clock, non fosse per altro che quell'1% dei casi).

Mah, questo lo considero un hack brutto come la morte a vedersi. Concordo con VICIUS nel voler utilizzare un array di una qualunque struttura senza ricorrere a soluzione diciamo "poco ortodosse" come queste.

E' una mia esigenza di sviluppatore. Io voglio modellare qualcosa in maniera semplice e intellegibile. Rispondo a te ma anche a tutti quelli che hanno dato dell'hack al mio snippet.

Lo è certamente, il modo in cui l'ho scritto non è il modo naturale di pensare ai dati in questione, tuttavia non si parlava di inegneria del software. Non sono molte nella vita le ottimizzazioni che rendono il codice più leggibile oltre che più performante, anzi probabilmente non ce ne sono (ne' in industria ne' in accademia).

Lo snippet è sufficiente a dimostrare che Java non "ti forza a usare strutture dati e algoritmi inefficienti", ci si può facilmente limitare a un sottoinsieme del linguaggio Turing-completo e performante (ma che strano deja vu, mi è venuto in mente asm.js :D). E' chiaro che, trattandosi di un'ottimizzazione, la leggibilità viene meno.

Concordo con Tommo e aggiungo una piccola nota: usando le variabili in quel modo potresti avere l'effetto tutt'altro che benefico di spargere dati di un singolo oggetto in locazioni molto distanti tra loro, diversamente dal caso "aggregato". Questo è interessante, ma si può rimediare anche a ciò "impacchettando" i valori a gruppi di 4:

class RectangleArray {
public static final int LENGTH = 10;

private final int[] data = new int[4 * LENGTH];

public int getX(final int index) {
return data[index * 4];
}

public int getY(final int index) {
return data[index * 4 + 1];
}

public int getWidth(final int index) {
return data[index * 4 + 2];
}

public int getHeight(final int index) {
return data[index * 4 + 3];
}
}

msangi

27-04-2015, 20:26

Questo è interessante, ma si può rimediare anche a ciò "impacchettando" i valori a gruppi di 4:

class RectangleArray {
public static final int LENGTH = 10;

private final int[] data = new int[4 * LENGTH];

public int getX(final int index) {
return data[index * 4];
}

public int getY(final int index) {
return data[index * 4 + 1];
}

public int getWidth(final int index) {
return data[index * 4 + 2];
}

public int getHeight(final int index) {
return data[index * 4 + 3];
}
}

Come gestiresti una struttura contenente attributi di tipo diverso?
In C# userei una struct senza problemi, adattare questo tuo hack mi sembra abbastanza difficile. Potresti farlo divertendoti con operazioni bitwise e cast, ma non credo sarebbe una soluzione molto pulita.

cdimauro

27-04-2015, 20:50

Non ho la forza ne' il coraggio di andare a ripescare quei post ma che io ricordi fek ha più volte fatto appello all'autorità di stilisti emergenti o roba simile per sostenere le sue tesi estetiche in contrasto con le affermazioni della vittima ( :asd: ) di turno.

Io lo trovo disonesto: lo stilista emergente può affermare quello che gli pare ma ognuno ha diritto al suo parere estetico. Anzi: lo stilista emergente spesso viene usato, direttamente o indirettamente ma sempre dietro appropriata retribuzione, per influenzare l'opinione comune e far avvicinare l'oggettivo al soggettivo. Non dico nulla contro il mestiere di Apple o dello stilista emergente, mi va tutto bene finchè si lavora onestamente nel rispetto delle leggi vigenti. Dico solo che a me quell'orologio sembra un delfino che vomita arcobaleni, e la vittima ( :asd: ) di turno mi sembrava dire la stessa cosa in almeno parte dei suoi discorsi.
Non ricordo se lo stilista fosse emergente, e onestamente non ho voglia di recuperare la discussione per un solo dettaglio.
Tanto nun j'aregge ai moderatori di spizzarsi tutti sti muri di testo per capire che è OT. :asd:

(non c'è più il buon vecchio cionci. :D )
Beh, anche cionci lasciava un po' correre, perché alla fine i thread parlano di cose molto interessanti, e i lettori hanno tutto da guadagnare nel leggerli.

Poi siamo geek per definizione, per cui rientra tutto nella norma. :p
Se all'interno della sintassi di LINQ la parola "sum" deve fare riferimento a qualcosa di particolare le cose sono due, o è una keyword o è un nome globale. Stiamo sempre nel campo delle ipotesi ovviamente, visto che la funzione aggregata della somma non è presente in LINQ, ma non ipotizziamo soluzioni ancora più zozze di quelle che già sono. :D
La seconda che hai detto: è un nome globale (o comunque che rientra nel namespace/scope attuale).
Secondo me, again, "isolare" completamente la sintassi di LINQ con delle sequenze di caratteri che indicano il passaggio è la soluzione migliore perchè a quel punto, finalmente, puoi fare di LINQ tutto quello che ti pare. Dentro i backtick puoi scrivere programmi per qualunque linguaggio di programmazione che non usi i backtick nella propria sintassi.
Lo so, ma non mi piace proprio come soluzione, perché hai di fatto estromesso del codice e l'hai ridotto a dato. E' più difficile da leggere perché si discosta da ciò a cui sei abituato e "naturale". Lo è anche per l'intellisense, che deve capire che risulta necessario eseguire il parsing di quella stringa con un altro parser dedicato. Come la mettiamo poi con eventuali errori presenti in quella stringa?
Non esageriamo con queste approssimazioni: si tratta solo di dividere il compilatore già esistente in due parti ben distinte che interagiscono in maniera più semplice e chiara. Col vantaggio che ai uno dei due si possono aggiungere molte funzionalità utili, come appunto le funzioni aggregate.
Beh, il compilatore sarà unico, ma fa uso di due parser diversi. Certamente con molto in comune, ma rimangono due linguaggi diversi che hanno bisogno di due parser diversi.

I programmatori devono anche impararli entrambi.
Le "heredoc strings" di PHP producono niente altro che stringhe, ossia valori regolari del dominio dei dati di PHP. Lo stesso vale per la mia ipotetica "sintassi delimitata" di LINQ: in corrispondenza di un "LINQ literal" il parser genera una porzione di AST che, quando valutata, produce nient'altro che regolari valori del dominio della piattaforma .NET. Passi dati tanto quanto ne passi nello scrivere uno string literal. Non c'è nessun protocollo extra, nessuna procedura di marshalling / unmarshalling.
OK, chiaro.
Per carità, d'accordissimo. Ma immagino che sarai d'accordo nel riconoscere che le garanzie qui non sono al 100%.
Certamente, ma nemmeno un linguaggio come Haskell ti garantisce che il tuo codice non avrà bug. ;)
Inoltre, punto fondamentale, stavamo parlando di una questione di design del linguaggio. Il design del linguaggio non dovrebbe mai essere peggiore con la scusa del delegare la qualità finale agli strumenti successivi nella toolchain.
Vero, e infatti non mi pare di aver mai letto di motivazioni simili riguardo alla progettazione di qualche linguaggio di programmazione.
Dunque, come dicevo, un sistema di tipi che non è ne' inferito ne' manifesto è necessariamente dinamico. Giusto?
Sì.
Un giorno o l'altro mi tocca darci un'occhiata più seriamente a 'sto Python. :asd:
Se ti piace Haskell, dubito che ti potrà piacere Python. :D
La teoria a me sembra chiara: un sistema di tipi statico, forte, e inferito permette di scrivere programmi correttamente tipati in maniera più concisa e senza causare alcuna penalità di performance a runtime (si, va benissimo, nel 99% dei casi la penalità è impercettibile, "early optimization is the root of all evil", but still: non c'è motivo di aggiungere cicli di clock, non fosse per altro che quell'1% dei casi).
La concisione la ottieni anche senza un sistema simile.

Riguardo alla velocità, dipende. Ad esempio guarda Lua confrontato con Haskell: http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=lua&lang2=ghc Questo con Lua rigorosamente interpretato, e c'è qualche caso in cui è leggermente più veloce di Haskell.

Adesso guarda cos'è in grado di fare, invece, la versione JITed di Lua: http://luajit.org/performance_x86.html

Purtroppo LuaJIT non è disponibile per essere confrontato con Haskell, ma sono sicuro che non avrebbe sfigurato. E parliamo, in ogni caso, di un linguaggio a tipizzazione dinamica. ;)

Comunque non mi hai ancora risposto riguardo alla mia domanda in questo contesto. Che vantaggi avrebbe Haskell nella nomenclatura dei tipi? :)
Rispondo a te ma anche a tutti quelli che hanno dato dell'hack al mio snippet.

Lo è certamente, il modo in cui l'ho scritto non è il modo naturale di pensare ai dati in questione, tuttavia non si parlava di inegneria del software. Non sono molte nella vita le ottimizzazioni che rendono il codice più leggibile oltre che più performante, anzi probabilmente non ce ne sono (ne' in industria ne' in accademia).

Lo snippet è sufficiente a dimostrare che Java non "ti forza a usare strutture dati e algoritmi inefficienti", ci si può facilmente limitare a un sottoinsieme del linguaggio Turing-completo e performante (ma che strano deja vu, mi è venuto in mente asm.js :D). E' chiaro che, trattandosi di un'ottimizzazione, la leggibilità viene meno.
OK, chiaro. E in questo contesto non posso che concordare.
Questo è interessante, ma si può rimediare anche a ciò "impacchettando" i valori a gruppi di 4:

class RectangleArray {
public static final int LENGTH = 10;

private final int[] data = new int[4 * LENGTH];

public int getX(final int index) {
return data[index * 4];
}

public int getY(final int index) {
return data[index * 4 + 1];
}

public int getWidth(final int index) {
return data[index * 4 + 2];
}

public int getHeight(final int index) {
return data[index * 4 + 3];
}
}

Sì, ma devi fare delle assunzioni sulla dimensione dei dati in questione. E magari sulla dimensione della linea della cache dati del processore. Questo se vuoi spremere al massimo il processore.

Mentre sfruttando il classico array di strutture sei sicuro che i dati saranno sempre e comunque vicini, a prescindere dalla particolare micro-architettura. ;)