-
Java e ... il restohttp://www.tiobe.com/index.php/content/paperinfo/t...

Java in 13 anni e' passato dal 25% a poco meno del 20% del mercato
C resiste (E resistera'), mentre C++ e' piombato.
Poi ci sono le briciole, C# e Python e altri linguaggi che non vale neppure la pena menzionare: PHP, VB .NET, JavaScript, Perl, ...
Cosa voglio dimostrare con cio' ? Che ho investito bene sul mio futuro, anche se i fondi acquistati di recente hanno subito un tonfo del 15% in un mese
**Modificato dall'autore il 14.10.2015 14:55**`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-14 16:11:14.0 alle 2015-10-14 16:11:14.0Scritto da: Giambo
> http://www.tiobe.com/index.php/content/paperinfo/t...
>
> Java in 13 anni e' passato dal 25% a poco meno del 20% del mercato
> C resiste (E resistera'), mentre C++ e' piombato.
Non capisco cosa abbia preso il posto di java.
>
> Poi ci sono le briciole, C# e Python e altri linguaggi che non vale neppure la pena menzionare: PHP, VB .NET, JavaScript, Perl, ...
>
> Cosa voglio dimostrare con cio' ? Che ho investito bene sul mio futuro, anche se i fondi acquistati di recente hanno subito un tonfo del 15% in un mese
E non dimentichiamoci della bolla bitcoin.
>
> **Modificato dall'autore il 14.10.2015 14:55**
-
Re: Java e ... il restoScritto da:
> > http://www.tiobe.com/index.php/content/paperinfo/t...
> >
> > Java in 13 anni e' passato dal 25% a poco meno del 20% del mercato
> > C resiste (E resistera'), mentre C++ e' piombato.
>
> Non capisco cosa abbia preso il posto di java.
IMHO questo indice e' un po "farlocco":
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.
IMHO quel 5% che ha perso Java e' stato "roicchiato" da una miriade di nuovi linguaggi di programmazione "di nicchia":
Scala, Erlang, Dart, Go, ...
> > Cosa voglio dimostrare con cio' ? Che ho investito bene sul mio futuro, anche se i fondi acquistati di recente hanno subito un tonfo del 15% in un mese
>
> E non dimentichiamoci della bolla bitcoin.
Quella era una balla, ma i fondi Biotech e' la verita'
!
E a breve Yoda guadagnera' piu' di me, e' lanciatissimo ed e' diventato un punto di riferimento dei suoi ex-colleghi
**Modificato dall'autore il 14.10.2015 16:36**`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Java e ... il restoScritto daAlessandrox(XYZ)Trollil 2015-10-15 17:51:30.0 alle 2015-10-15 17:51:30.0Trollate totali: 11553ma dart non era l'alternativa al javascript secondo la vacca (e secondo guugle)?
**Modificato dall'autore il 15.10.2015 17:53**Ma smettila di secernere cazzate!
-
-
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-15 23:23:38.0 alle 2015-10-15 23:23:38.0Scritto da: Giambo
> http://www.tiobe.com/index.php/content/paperinfo/t...
>
> Java in 13 anni e' passato dal 25% a poco meno del 20% del mercato
> C resiste (E resistera'), mentre C++ e' piombato.
>
> Poi ci sono le briciole, C# e Python e altri linguaggi che non vale neppure la pena menzionare: PHP, VB .NET, JavaScript, Perl, ...
>
> Cosa voglio dimostrare con cio' ? Che ho investito bene sul mio futuro, anche se i fondi acquistati di recente hanno subito un tonfo del 15% in un mese
>
> **Modificato dall'autore il 14.10.2015 14:55**
Javascript però non rappresenta un'alternativa rispetto agli altri linguaggi... ha un monopolio.-
Re: Java e ... il restoScritto daAlessandrox(XYZ)Trollil 2015-10-16 17:47:42.0 alle 2015-10-16 17:47:42.0Trollate totali: 11553e chi l' avrebbe imposto?Ma smettila di secernere cazzate!
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-16 21:22:59.0 alle 2015-10-16 21:22:59.0Scritto da: Alessandrox
> e chi l' avrebbe imposto?
Non mi risulta che i comuni browser siano in grado di interpretare altri linguaggi di programmazione al di fuori di javascript.
Cos'altro conosci per manipolare dinamicamente lo stile e il DOM delle pagine web?
Ha un monopolio nell'ambito della programmazione web perché non ci sono altre alternative... sarà diverso quando ci sarà web assembly.-
Re: Java e ... il restoScritto da:
> Scritto da: Alessandrox
> > e chi l' avrebbe imposto?
>
> Non mi risulta che i comuni browser siano in grado di interpretare altri linguaggi di programmazione al di fuori di javascript.
> Cos'altro conosci per manipolare dinamicamente lo stile e il DOM delle pagine web?
>
> Ha un monopolio nell'ambito della programmazione web perché non ci sono altre alternative... sarà diverso quando ci sarà web assembly.
Linguaggi che "transpilano" in javascript ce ne sono quanti ne vuoi.Young professional woman and busy mom.-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-16 21:28:35.0 alle 2015-10-16 21:28:35.0Scritto da: ::1
> Scritto da:
> > Scritto da: Alessandrox
> > > e chi l' avrebbe imposto?
> >
> > Non mi risulta che i comuni browser siano in grado di interpretare altri linguaggi di programmazione al di fuori di javascript.
> > Cos'altro conosci per manipolare dinamicamente lo stile e il DOM delle pagine web?
> >
> > Ha un monopolio nell'ambito della programmazione web perché non ci sono altre alternative... sarà diverso quando ci sarà web assembly.
>
> Linguaggi che "transpilano" in javascript ce ne sono quanti ne vuoi.
Non so cosa significhi "transpilare", immagino voglia dire che possono essere tradotti in javascript.
Esempi?-
Re: Java e ... il restoScritto da:
> Scritto da: ::1
> > Scritto da:
> > > Scritto da: Alessandrox
> > > > e chi l' avrebbe imposto?
> > >
> > > Non mi risulta che i comuni browser siano in grado di interpretare altri linguaggi di programmazione al di fuori di javascript.
> > > Cos'altro conosci per manipolare dinamicamente lo stile e il DOM delle pagine web?
> > >
> > > Ha un monopolio nell'ambito della programmazione web perché non ci sono altre alternative... sarà diverso quando ci sarà web assembly.
> >
> > Linguaggi che "transpilano" in javascript ce ne sono quanti ne vuoi.
>
> Non so cosa significhi "transpilare", immagino voglia dire che possono essere tradotti in javascript.
>
> Esempi?
Una lista piuttosto estesa è nella wiki di coffeescript (che è quello che preferisco tra questi):https://github.com/jashkenas/coffeescript/wiki/Lis...
Young professional woman and busy mom.
-
-
-
Re: Java e ... il restoScritto daAlessandrox(XYZ)Trollil 2015-10-16 22:43:45.0 alle 2015-10-16 22:43:45.0Trollate totali: 11553quindi mi stai dicendo che c'è stato un gombloddo dei browsers per imporre il javascript?Ma smettila di secernere cazzate!
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 02:59:14.0 alle 2015-10-17 02:59:14.0Scritto da: Alessandrox
> quindi mi stai dicendo che c'è stato un gombloddo dei browsers per imporre il javascript?
Non si chiama complotto, si chiama "standardizzazione". Una cosa che hanno avuto almeno in parte il buon senso di fare i produttori dei vari browser è di non essersi reinventati ognuno il proprio linguaggio di programmazione personale.
Hanno invece almeno parzialmente fallito nel creare uno standard sul linguaggio stesso, visto che praticamente ogni browser si basa su una propria versione personale di ECMAScript... internet explorer in particolare cata fuori dal coro rispetto ai suoi concorrenti.
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 11:35:58.0 alle 2015-10-17 11:35:58.0Scritto da:
> Scritto da: Alessandrox
> > quindi mi stai dicendo che c'è stato un gombloddo dei browsers per imporre il javascript?
>
> Non si chiama complotto, si chiama "standardizzazione".
In questo caso si chiama "coglionaggine".
Javascript poi è particolarmente orrendo. Andava giusto bene all'inizio del WEB, quando l'unico suo utilizzo era far lampeggiare qualcosa... dopo anni di tentativi di migliorarlo sono riusciti a renderlo a malapena accettabile. La cosa triste è che un'intera generazione di programmatori è stata cresciuta con questo linguaggio di merda che ha insegnato loro tutti i concetti in modo sbagliato.
Grazie al cielo nella programmazione tradizionale non sei obbligato ad usare un linguaggio solo perché piace a chi ha fatto il SO.
Quello che dovevano fare SUBITO è una virtual machine con un suo "codice macchina" e poi lasciare liberi i programmatori di programmarci nel linguaggio da loro preferito (come succede in .NET e persino nella JVM).
Invece a distanza di 20 anni siamo ancora qui a giocare con quella merda di linguaggio e il meglio che possiamo fare è "compilare in javascript"... solo da poco si sta cominciando a parlare di "webassembly"... vedremo se finalmente potremo sbarazzarci di quell'accozzaglia di cretinaggine che è javascript.-
Re: Java e ... il restoScritto da:
> Quello che dovevano fare SUBITO è una virtual machine con un suo "codice macchina" e poi lasciare liberi i programmatori di programmarci nel linguaggio da loro preferito (come succede in .NET e persino nella JVM)
Ai tempi Netscape pesava una tonellata, se ci mettevi dentro pure una VM che a partire ci metteva una manciata di secondi ("Java e' lento !"), ti saresti sparato nelle palle.
Del resto le Applet Java all'interno del Browser hanno fatto la fine che e' sotto gli occbi di tutti, e solo Flash e' sopravissuto, e non di certo perche' girava in una VM.`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 12:40:39.0 alle 2015-10-17 12:40:39.0Scritto da: Giambo
> Scritto da:
>
> > Quello che dovevano fare SUBITO è una virtual machine con un suo "codice macchina" e poi lasciare liberi i programmatori di programmarci nel linguaggio da loro preferito (come succede in .NET e persino nella JVM)
>
> Ai tempi Netscape pesava una tonellata, se ci mettevi dentro pure una VM che a partire ci metteva una manciata di secondi ("Java e' lento !"), ti saresti sparato nelle palle.
Basta farlo avviare in background su un altro thread, tanto basta che lo faccia una volta e si sta un po' a scrivere un link o a cliccare su un link in ogni caso.
I "tempi di netscape" erano nel 1990... cosa ha impedito fino ad ora, a distanza di 25 anni, su macchine multi-core e multi GHz, di adottare una VM adatta?
> Del resto le Applet Java all'interno del Browser hanno fatto la fine che e' sotto gli occbi di tutti,
Per via del fatto che la JVM viene avviata solo "on demand", chiaramente una VM inserita in un browser si avvia una volta sola all'avvio del browser (e può farlo in un processo separato che non blocca l'interfaccia) e per via del gran numero di bug e potenziali problemi di sicurezza che Java esponeva gli utenti. La JVM purtroppo permette di fare troppe cose, incluso l'accesso diretto ad Internet, ai file sul disco, ecc. Una VM per browser non deve permettere nulla di tutto questo.
> e solo Flash e' sopravissuto, e non di certo perche' girava in una VM.
Flash è sopravissuto perché ci sono ancora idioti che lo usano per i video. Se non fosse per i video Flash sarebbe morto almeno da 10 anni.-
Re: Java e ... il restoScritto da:
> > > Quello che dovevano fare SUBITO è una virtual machine con un suo "codice macchina" e poi lasciare liberi i programmatori di programmarci nel linguaggio da loro preferito (come succede in .NET e persino nella JVM)
> >
> > Ai tempi Netscape pesava una tonellata, se ci mettevi dentro pure una VM che a partire ci metteva una manciata di secondi ("Java e' lento !"), ti saresti sparato nelle palle.
>
> Basta farlo avviare in background su un altro thread,
Non cambia nulla, devi lo stesso aspettare che parta.
E poi hai la VM in memoria, e ai tempi 64MB erano un lusso
> I "tempi di netscape" erano nel 1990... cosa ha impedito fino ad ora, a distanza di 25 anni, su macchine multi-core e multi GHz, di adottare una VM adatta?
Il consenso di tutti i maggiori produttori di Browsers.
Ci hanno provato Google e Microsoft indipendentemente, i risultati sono sotto gli occhi di tutti`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 13:37:34.0 alle 2015-10-17 13:37:34.0Scritto da: Giambo
> > Basta farlo avviare in background su un altro thread,
>
> Non cambia nulla, devi lo stesso aspettare che parta.
Cambia invece. Se all'utente mostri subito la GUI, anche se alcune operazioni deve ancora completarle, dai l'impressione di un programma scattante, veloce e responsivo.
Per questo ad esempio si mettono gli script in fondo alle pagine HTML e non all'inizio. Per questo i SO tendono a mostrarti la GUI prima ancora che il boot sia completato (vale per Windows ma anche per Linux).
Metti che la VM richiede 5 secondi di caricamento... intanto mostro la GUI, così l'utente può cominciare a scrivere l'URL e magari posso anche scaricare le pagine web e le risorse loro associate mentre sto aspettando... poi appena la VM è pronta mostro la pagina WEB.
Lo devo fare una volta sola, all'avvio del browser, che in genere viene avviato poche volte in una giornata e resta attivo per molto tempo.
> E poi hai la VM in memoria, e ai tempi 64MB erano un lusso
Si ok, ma non credo che dal 2000 in poi ci fossero tutti questi problemi di RAM e velocità dei processori. Come ho detto, javascript è nato inizialmente su Netscape per fare 4 cazzate, non era né pensato né progettato per diventare il linguaggio standard del WEB.
> Il consenso di tutti i maggiori produttori di Browsers.
Eppure quando Netscape ha introdotto javascript non ha aspettato il consenso di nessuno.
Il problema oggi non è tanto il consenso, quanto il sabotaggio degli altri browser nei confronti di tecnologie che non gli piacciono o che appartengono alla concorrenza.
> Ci hanno provato Google e Microsoft indipendentemente, i risultati sono sotto gli occhi di tutti
Né Google né Microsoft hanno tentato di introdurre una VM agnostica a livello di linguaggio. Entrambe hanno voluto spingere il loro linguaggio né più né meno di quello che aveva fatto Netscape ai tempi... ma mentre VBScript era una cagata pazzesca, Dart è invece un miglioramento NOTEVOLE rispetto a javascript. Avrebbe avuto senso adottarlo, anziché boicottarlo come hanno fatto i coglioni a Mozilla e Microsoft solo perché non era roba loro.-
Re: Java e ... il restoScritto da:
> Né Google né Microsoft hanno tentato di introdurre una VM agnostica a livello di linguaggio. Entrambe hanno voluto spingere il loro linguaggio né più né meno di quello che aveva fatto Netscape ai tempi... ma mentre VBScript era una cagata pazzesca, Dart è invece un miglioramento NOTEVOLE rispetto a javascript. Avrebbe avuto senso adottarlo, anziché boicottarlo come hanno fatto i coglioni a Mozilla e Microsoft solo perché non era roba loro.
Sei un fanboy del cazzo, dart fa schifo. rassegnati.Young professional woman and busy mom.-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 13:49:42.0 alle 2015-10-17 13:49:42.0Scritto da: ::1
> Scritto da:
> > Né Google né Microsoft hanno tentato di introdurre una VM agnostica a livello di linguaggio. Entrambe hanno voluto spingere il loro linguaggio né più né meno di quello che aveva fatto Netscape ai tempi... ma mentre VBScript era una cagata pazzesca, Dart è invece un miglioramento NOTEVOLE rispetto a javascript. Avrebbe avuto senso adottarlo, anziché boicottarlo come hanno fatto i coglioni a Mozilla e Microsoft solo perché non era roba loro.
>
> Sei un fanboy del cazzo, dart fa schifo. rassegnati.
Vedremo che fine farà javascript nonappena si potrà scegliere il linguaggio con cui sviluppare per il WEB.
-
-
Re: Java e ... il restoScritto da:
> > > Basta farlo avviare in background su un altro thread,
> >
> > Non cambia nulla, devi lo stesso aspettare che parta.
>
> Cambia invece. Se all'utente mostri subito la GUI, anche se alcune operazioni deve ancora completarle, dai l'impressione di un programma scattante, veloce e responsivo.
Al giorno d'oggi, la GUI e' costruita in javascript, senza di esso non vedi un piffero.
> > Il consenso di tutti i maggiori produttori di Browsers.
>
> Eppure quando Netscape ha introdotto javascript non ha aspettato il consenso di nessuno.
E a chi avrebbe dovuto chiedere ? Era IL produttore di browser.
> Il problema oggi non è tanto il consenso, quanto il sabotaggio degli altri browser nei confronti di tecnologie che non gli piacciono o che appartengono alla concorrenza.
Esatto.`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 15:34:21.0 alle 2015-10-17 15:34:21.0Scritto da: Giambo
> > Cambia invece. Se all'utente mostri subito la GUI, anche se alcune operazioni deve ancora completarle, dai l'impressione di un programma scattante, veloce e responsivo.
>
> Al giorno d'oggi, la GUI e' costruita in javascript, senza di esso non vedi un piffero.
Sto parlando della GUI del browser, non quella della pagina WEB.
> > Eppure quando Netscape ha introdotto javascript non ha aspettato il consenso di nessuno.
>
> E a chi avrebbe dovuto chiedere ? Era IL produttore di browser.
Balle. Javascript è stato introdotto (Maggio 1995) 5 mesi dopo la prima versione di Netscape (fu introdotto nella versione 2).
Sul mercato c'era già Mosaic da almeno 2 anni... e prima di Mosaic c'era il browser WorldWideWeb da almeno 4 anni (rinomitato in seguito in Nexus).
Non è che prima (e in contemporanea) di Netscape non ci fosse nulla. L'introduzione di javascript ha creato una feature in Netscape incompatibile con gli altri browser dell'epoca, eppure nessuno si è messo a piangere dicendo "ma così rompete il uebbe!"... se l'avessero fatto oggi saremmo ancora alle pagine WEB statiche.
Con questo NON voglio dire che è bene introdurre cambiamenti che rompono gli standard, ma che quando una nuova tecnologia si rende disponibile, e questa tecnologia ha chiari vantaggi rispetto a quella precedente, non ha nessun senso osteggiarla e mettersi a piangere, soprattutto quando chi ha prodotto quella tecnologia è disposto a dartela aggratis.
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 15:38:13.0 alle 2015-10-17 15:38:13.0Scritto da:
> ma che quando una nuova tecnologia si rende disponibile, e questa tecnologia ha chiari vantaggi rispetto a quella precedente
P.S. Rispetto a Javascript anche il GWBasic sarebbe un chiaro progresso.
-
Re: Java e ... il restoScritto da:
> > > Eppure quando Netscape ha introdotto javascript non ha aspettato il consenso di nessuno.
> >
> > E a chi avrebbe dovuto chiedere ? Era IL produttore di browser.
>
> Balle. Javascript è stato introdotto (Maggio 1995) 5 mesi dopo la prima versione di Netscape (fu introdotto nella versione 2).
Che quota di mercato aveva Netscape nel 1995 ?
> Sul mercato c'era già Mosaic da almeno 2 anni...
E dopo un anno praticamente non lo usava piu' nessuno
> Non è che prima (e in contemporanea) di Netscape non ci fosse nulla.
Quel che dico e' che Nestscape quando ha introdotto javascript poteva farlo fregandose altamente della concorrenza "inesistente"`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo
-
-
-
-
-
-
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 12:30:41.0 alle 2015-10-17 12:30:41.0Scritto da:
> Scritto da:
> > Scritto da: Alessandrox
> > > quindi mi stai dicendo che c'è stato un gombloddo dei browsers per imporre il javascript?
> >
> > Non si chiama complotto, si chiama "standardizzazione".
>
> In questo caso si chiama "coglionaggine".
>
> Javascript poi è particolarmente orrendo.
Tutti i linguaggi debolmente tipizzati sono orrendi.
Non ho mai capito perché alcuni programmatori si fanno le seghe sulla tipizzazione debole. Nella maggior parte dei casi quando scrivi una funzione ti aspetti che il dato in ingresso sia di un tipo ben preciso. Se per esempio mi faccio passare una path (quindi una stringa) e quello che mi arriva è un oggetto, può darsi che forse c'è qualcosa che non va... significa che colui che ha scritto il codice che chiama la mia funzione ha sbagliato qualcosa.
Egli ovviamente non si renderà conto del suo errore, in quanto la mia funzione verrà eseguita come se niente fosse per poi produrre, dopo una lunga catena di istruzioni, un output sballato.
Ergo, se voglio rendere la vita più facile a chi userà la mia funzione e dovrà debuggare il proprio codice, all'inizio della mia funzione controllo che quella variabile sia una stringa, e se non è lancio un'eccezione.
In un linguaggio strongly-typed questo non è necessario, in quanto il controllo lo fa il compilatore.
Forse sono io che non sono ben agganciato alla filosofia weakly-typed, ma anche le API di javascript richiedono di passare a determinate funzioni delle variabili di un certo tipo, ma soprattutto i diversi tipi possiedono al loro interno dei metodi differenti.
Javascript inoltre è una cagata anche per altre cose: se chiedi il ventesimo elemento di un array che di elementi ne ha solo 10, non viene lanciata un'eccezione... ti ritorna silenziosamente "undefined" : questo genere di cose è infatti quel genere di cagate che piacciono molti a chi sostiene la tipizzazione debole, così puoi scrivere cagate tipo while(array[k]).
Anche nel C se sfori sopra l'ultimo elemento di un array ti ritrovi a raccogliere valori non pertinenti, ma la questione è diversa: il C lo fa perché è così che un computer funziona, mentre javascript lo fa perché lo VUOLE fare.
Mi pare di capire che secondo la mentalità di alcuni programmatori un linguaggio di programmazione che non fa crashare l'applicazione, o che ti permette di compilare in ogni caso, ti renda la vita più facile.
Mi viene da pensare che questi preferirebbero avere un tumore asintomatico che li mangia lentamente senza che se ne accorgano, piuttosto che un tumore che causa dei chiari sintomi.
Se la tua applicazione crasha fai brutte figure davanti al cliente? Vero. Quale figura fai invece se un programma di contabilità che hai dato a un'azienda contabilizza le cose in maniera sbagliata e fa tutto questo in maniera silenziosa?
È giusto che quando un'applicazione crashi quando c'è qualcosa di sbagliato. Se non vuoi che crasha, allora programma e testa come si deve.
-
Re: Java e ... il restoScritto da:
> Tutti i linguaggi debolmente tipizzati sono orrendi.
High five
!
> Se per esempio mi faccio passare una path (quindi una stringa) e quello che mi arriva è un oggetto, può darsi che forse c'è qualcosa che non va... significa che colui che ha scritto il codice che chiama la mia funzione ha sbagliato qualcosa.
Il compilatore dovrebbe aver gia' bestemmiato ...
> Forse sono io che non sono ben agganciato alla filosofia weakly-typed,
Credo che alla fine il tutto si riduca ad avere meno overhead possibile ...`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo
-
Re: Java e ... il restoScritto da:
> Scritto da:
> > Scritto da:
> > > Scritto da: Alessandrox
> > > > quindi mi stai dicendo che c'è stato un gombloddo dei browsers per imporre il javascript?
> > >
> > > Non si chiama complotto, si chiama "standardizzazione".
> >
> > In questo caso si chiama "coglionaggine".
> >
> > Javascript poi è particolarmente orrendo.
>
> Tutti i linguaggi debolmente tipizzati sono orrendi.
>
> Non ho mai capito perché alcuni programmatori si fanno le seghe sulla tipizzazione debole. Nella maggior parte dei casi quando scrivi una funzione ti aspetti che il dato in ingresso sia di un tipo ben preciso. Se per esempio mi faccio passare una path (quindi una stringa) e quello che mi arriva è un oggetto, può darsi che forse c'è qualcosa che non va... significa che colui che ha scritto il codice che chiama la mia funzione ha sbagliato qualcosa.
> Egli ovviamente non si renderà conto del suo errore, in quanto la mia funzione verrà eseguita come se niente fosse per poi produrre, dopo una lunga catena di istruzioni, un output sballato.
>
> Ergo, se voglio rendere la vita più facile a chi userà la mia funzione e dovrà debuggare il proprio codice, all'inizio della mia funzione controllo che quella variabile sia una stringa, e se non è lancio un'eccezione.
>
> In un linguaggio strongly-typed questo non è necessario, in quanto il controllo lo fa il compilatore.
>
> Forse sono io che non sono ben agganciato alla filosofia weakly-typed, ma anche le API di javascript richiedono di passare a determinate funzioni delle variabili di un certo tipo, ma soprattutto i diversi tipi possiedono al loro interno dei metodi differenti.
>
> Javascript inoltre è una cagata anche per altre cose: se chiedi il ventesimo elemento di un array che di elementi ne ha solo 10, non viene lanciata un'eccezione... ti ritorna silenziosamente "undefined" : questo genere di cose è infatti quel genere di cagate che piacciono molti a chi sostiene la tipizzazione debole, così puoi scrivere cagate tipo while(array[k]).
>
> Anche nel C se sfori sopra l'ultimo elemento di un array ti ritrovi a raccogliere valori non pertinenti, ma la questione è diversa: il C lo fa perché è così che un computer funziona, mentre javascript lo fa perché lo VUOLE fare.
>
> Mi pare di capire che secondo la mentalità di alcuni programmatori un linguaggio di programmazione che non fa crashare l'applicazione, o che ti permette di compilare in ogni caso, ti renda la vita più facile.
>
> Mi viene da pensare che questi preferirebbero avere un tumore asintomatico che li mangia lentamente senza che se ne accorgano, piuttosto che un tumore che causa dei chiari sintomi.
>
> Se la tua applicazione crasha fai brutte figure davanti al cliente? Vero. Quale figura fai invece se un programma di contabilità che hai dato a un'azienda contabilizza le cose in maniera sbagliata e fa tutto questo in maniera silenziosa?
>
> È giusto che quando un'applicazione crashi quando c'è qualcosa di sbagliato. Se non vuoi che crasha, allora programma e testa come si deve.
Usa l'attrezzo migliore per il lavoro che devi fare. Se hai un martello tutto ti sembrerà un chiodo.
(in inglese sono così fighe, tradotte in italiano fanno un po' pena...)
Young professional woman and busy mom.-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 13:41:31.0 alle 2015-10-17 13:41:31.0Scritto da: ::1
> Usa l'attrezzo migliore per il lavoro che devi fare.
Già, peccato che questo concetto, fino ad ora, sul WEB è stato osteggiato. Con i Javascript-fanboy che volevano solo Javascript e niente altro.
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 15:31:43.0 alle 2015-10-17 15:31:43.0Scritto da: ::1
> Scritto da:
> > Scritto da:
> > > Scritto da:
> > > > Scritto da: Alessandrox
> > > > > quindi mi stai dicendo che c'è stato un gombloddo dei browsers per imporre il javascript?
> > > >
> > > > Non si chiama complotto, si chiama "standardizzazione".
> > >
> > > In questo caso si chiama "coglionaggine".
> > >
> > > Javascript poi è particolarmente orrendo.
> >
> > Tutti i linguaggi debolmente tipizzati sono orrendi.
> >
> > Non ho mai capito perché alcuni programmatori si fanno le seghe sulla tipizzazione debole. Nella maggior parte dei casi quando scrivi una funzione ti aspetti che il dato in ingresso sia di un tipo ben preciso. Se per esempio mi faccio passare una path (quindi una stringa) e quello che mi arriva è un oggetto, può darsi che forse c'è qualcosa che non va... significa che colui che ha scritto il codice che chiama la mia funzione ha sbagliato qualcosa.
> > Egli ovviamente non si renderà conto del suo errore, in quanto la mia funzione verrà eseguita come se niente fosse per poi produrre, dopo una lunga catena di istruzioni, un output sballato.
> >
> > Ergo, se voglio rendere la vita più facile a chi userà la mia funzione e dovrà debuggare il proprio codice, all'inizio della mia funzione controllo che quella variabile sia una stringa, e se non è lancio un'eccezione.
> >
> > In un linguaggio strongly-typed questo non è necessario, in quanto il controllo lo fa il compilatore.
> >
> > Forse sono io che non sono ben agganciato alla filosofia weakly-typed, ma anche le API di javascript richiedono di passare a determinate funzioni delle variabili di un certo tipo, ma soprattutto i diversi tipi possiedono al loro interno dei metodi differenti.
> >
> > Javascript inoltre è una cagata anche per altre cose: se chiedi il ventesimo elemento di un array che di elementi ne ha solo 10, non viene lanciata un'eccezione... ti ritorna silenziosamente "undefined" : questo genere di cose è infatti quel genere di cagate che piacciono molti a chi sostiene la tipizzazione debole, così puoi scrivere cagate tipo while(array[k]).
> >
> > Anche nel C se sfori sopra l'ultimo elemento di un array ti ritrovi a raccogliere valori non pertinenti, ma la questione è diversa: il C lo fa perché è così che un computer funziona, mentre javascript lo fa perché lo VUOLE fare.
> >
> > Mi pare di capire che secondo la mentalità di alcuni programmatori un linguaggio di programmazione che non fa crashare l'applicazione, o che ti permette di compilare in ogni caso, ti renda la vita più facile.
> >
> > Mi viene da pensare che questi preferirebbero avere un tumore asintomatico che li mangia lentamente senza che se ne accorgano, piuttosto che un tumore che causa dei chiari sintomi.
> >
> > Se la tua applicazione crasha fai brutte figure davanti al cliente? Vero. Quale figura fai invece se un programma di contabilità che hai dato a un'azienda contabilizza le cose in maniera sbagliata e fa tutto questo in maniera silenziosa?
> >
> > È giusto che quando un'applicazione crashi quando c'è qualcosa di sbagliato. Se non vuoi che crasha, allora programma e testa come si deve.
>
> Usa l'attrezzo migliore per il lavoro che devi fare. Se hai un martello tutto ti sembrerà un chiodo.
(in inglese sono così fighe, tradotte in italiano fanno un po' pena...)
"Se tutto ciò che hai è un martello, ogni problema ti sembrerà un chiodo."
La prima volta che l'ho letta era attribuita a Bill Gates
-
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 13:29:08.0 alle 2015-10-17 13:29:08.0Scritto da:
> > Javascript poi è particolarmente orrendo.
>
> Tutti i linguaggi debolmente tipizzati sono orrendi.
Vanno bene per scripting semplice, non vanno bene quando devi lavorarci sopra a lungo.
Comunque Javascript è particolarmente orrendo per tutta una serie di motivi... dalle variabili globali automatiche alla mancanza del concetto di classe (sostituito da quella merda di "prototipo") che mi pare sia stato introdotto solo di recente nel tentativo, appunto, di aggiustarlo... dalla mancanza di una vera programmazione multithreading a livello di linguaggio (con i computer odierni con sempre più core è una stronzata non usarli, si, ci sono i web workers, ma sono un aggiunta recente, appunto ancora nel tentativo di aggiustare javascript e non fanno parte del linguaggio [niente semafori, niente memoria condivisa, niente canali come in Go, inoltre i web worker hanno tutta una serie di limiti http://stackoverflow.com/questions/14785761/limita...
, ecc]) alla sua gestione degli eventi che rende necessarie librerie aggiuntive per renderne la programmazione APPENA passabile (Dart ha affrontato il problema con gli async/await come in C# https://www.dartlang.org/articles/await-async/
).
> Non ho mai capito perché alcuni programmatori si fanno le seghe sulla tipizzazione debole. Nella maggior parte dei casi quando scrivi una funzione ti aspetti che il dato in ingresso sia di un tipo ben preciso. Se per esempio mi faccio passare una path (quindi una stringa) e quello che mi arriva è un oggetto, può darsi che forse c'è qualcosa che non va... significa che colui che ha scritto il codice che chiama la mia funzione ha sbagliato qualcosa.
In Dart per esempio se specifichi un tipo (sono opzionali) e glie ne passi un altro lui ti avvisa, permettendoti di individuare bug in fase di sviluppo prima di scoprirli "sul campo" come invece accade con javascript.
https://www.dartlang.org/articles/optional-types/
Non solo, ma una volta debuggato il programma puoi dirgli di rimuovere i controlli in produzione, così da non introdurre rallentamenti dovuti al controllo dei tipi.
> Egli ovviamente non si renderà conto del suo errore, in quanto la mia funzione verrà eseguita come se niente fosse per poi produrre, dopo una lunga catena di istruzioni, un output sballato.
Esatto.
> Ergo, se voglio rendere la vita più facile a chi userà la mia funzione e dovrà debuggare il proprio codice, all'inizio della mia funzione controllo che quella variabile sia una stringa, e se non è lancio un'eccezione.
Ma anche se voglio rendere la vita più semplice a me stesso, non solo a terze parti. Fare errori capita.
> In un linguaggio strongly-typed questo non è necessario, in quanto il controllo lo fa il compilatore.
>
> Forse sono io che non sono ben agganciato alla filosofia weakly-typed,
No, sono gli altri che sono dei cretini. E più giovani esponi a questo genere di programmazione più cretini ci saranno in futuro, purtroppo.
> Javascript inoltre è una cagata anche per altre cose: se chiedi il ventesimo elemento di un array che di elementi ne ha solo 10, non viene lanciata un'eccezione... ti ritorna silenziosamente "undefined" : questo genere di cose è infatti quel genere di cagate che piacciono molti a chi sostiene la tipizzazione debole, così puoi scrivere cagate tipo while(array[k]).
Già.
> Anche nel C se sfori sopra l'ultimo elemento di un array ti ritrovi a raccogliere valori non pertinenti, ma la questione è diversa: il C lo fa perché è così che un computer funziona, mentre javascript lo fa perché lo VUOLE fare.
>
> Mi pare di capire che secondo la mentalità di alcuni programmatori un linguaggio di programmazione che non fa crashare l'applicazione, o che ti permette di compilare in ogni caso, ti renda la vita più facile.
È chiaramente gente che non ha mai lavorato su progetti più grossi di 200 righe di codice.
> Mi viene da pensare che questi preferirebbero avere un tumore asintomatico che li mangia lentamente senza che se ne accorgano, piuttosto che un tumore che causa dei chiari sintomi.
>
> Se la tua applicazione crasha fai brutte figure davanti al cliente? Vero. Quale figura fai invece se un programma di contabilità che hai dato a un'azienda contabilizza le cose in maniera sbagliata e fa tutto questo in maniera silenziosa?
Esatto.
> È giusto che quando un'applicazione crashi quando c'è qualcosa di sbagliato. Se non vuoi che crasha, allora programma e testa come si deve.
Puoi sempre supportare il try-catch per dare un bel messaggio d'errore all'utente e non far crasciare il programma ma farlo riprendere da uno stato sicuro... ma vallo a spiegare ai javascriptari che invece preferiscono permettere alle loro funzioni di fare cazzate invece di darti un cazzo di errore...-
Re: Java e ... il restojavascript gira intorno alla dinamicità; posso avere una funzione che ha un numero di argomenti variabili e opzionali, posso sostituire una funzione, è un linguaggio con tratti funzionali (map/reduce/filter + closures); puoi sostituire il prototipo di un oggetto al volo.
Lo descrivi come se fosse un linguaggio pieno di errori e tutti i siti del mondo stanno cadendo a pezzi; ma non è così. Gmail non dovrebbe neanche esistere secondo le tue parole.
Invece conoscendolo ci si può lavorare bene, si può soprattutto sfruttare il dinamismo per produrre codice molto "smart".
Il tradeoff è quello che descrivi, ma i vantaggi sono innegabili.Young professional woman and busy mom.-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 15:27:08.0 alle 2015-10-17 15:27:08.0Scritto da: ::1
> javascript gira intorno alla dinamicità; posso avere una funzione che ha un numero di argomenti variabili e opzionali, posso sostituire una funzione, è un linguaggio con tratti funzionali (map/reduce/filter + closures); puoi sostituire il prototipo di un oggetto al volo.
> Lo descrivi come se fosse un linguaggio pieno di errori e tutti i siti del mondo stanno cadendo a pezzi; ma non è così. Gmail non dovrebbe neanche esistere secondo le tue parole.
> Invece conoscendolo ci si può lavorare bene, si può soprattutto sfruttare il dinamismo per produrre codice molto "smart".
> Il tradeoff è quello che descrivi, ma i vantaggi sono innegabili.
Parlouma italian, boiafauss!
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-18 14:22:06.0 alle 2015-10-18 14:22:06.0Scritto da: ::1
Quali delle cose che elenchi non si possono fare con i più comuni linguaggi? Prendiamo C# per esempio...
> posso avere una funzione che ha un numero di argomenti variabili
params[] ------> https://msdn.microsoft.com/it-it/library/w5zay9db....
> e opzionali
https://msdn.microsoft.com/en-us/library/dd264739....
> posso sostituire una funzione
Puoi cambiare il corpo di una funzione al volo? Espandi!
> è un linguaggio con tratti funzionali (map/reduce/filter + closures);
LINQ, ed è molto più elaborato rispetto ai tre metodi che hai in javascript.
Le lamba expression di C# rendono la programmazione funzionale molto elegante.
> puoi sostituire il prototipo di un oggetto al volo.
Intendi dire ad esempio: Array.prototype = MyPrototype; ?
Oppure, Array.prototype.newMethod = function() { ... }; ?
> Lo descrivi come se fosse un linguaggio pieno di errori e tutti i siti del mondo stanno cadendo a pezzi
Non so lui cosa dice.
Io dico che come linguaggio non mi dispiace, mi piace giocherellare con le sue caratteristiche quasi un po' esoteriche. Il problema è che queste sue caratteristiche esoteriche lo rendono error-prone, e dal momento che anche gli IDE potenti come visual studio non offrono un granché per quanto concerne javascript (d'altra parte la mancanza di tipizzazione delle variabili non aiuta l'intellisense).
Hai quasi paura a fare un refactor del codice.
La sensazione è quella di aver a che fare con degli strumenti troppo rudimentali per gli standard moderni... certo, questi sono i vizietti dei programmatori moderni. I veri programmatori erano quelli degli anni 60-70: opcode, assembly e tanta pazienza.
-
Re: Java e ... il restoScritto da:
> Scritto da: ::1
>
> Quali delle cose che elenchi non si possono fare con i più comuni linguaggi? Prendiamo C# per esempio...
>
> > posso avere una funzione che ha un numero di argomenti variabili
>
> params[] ------> https://msdn.microsoft.com/it-it/library/w5zay9db....
arguments è più flessibile.
> > e opzionali
>
> https://msdn.microsoft.com/en-us/library/dd264739....
>
> > posso sostituire una funzione
>
> Puoi cambiare il corpo di una funzione al volo? Espandi!var f = function(a,b) {return a + b}; f = function(a) {return a + 1}; f = console.log.bind(null);
> > è un linguaggio con tratti funzionali (map/reduce/filter + closures);
>
> LINQ, ed è molto più elaborato rispetto ai tre metodi che hai in javascript.
> Le lamba expression di C# rendono la programmazione funzionale molto elegante.
Linq non è neanche lontanamente dinamico.
> > puoi sostituire il prototipo di un oggetto al volo.
>
> Intendi dire ad esempio: Array.prototype = MyPrototype; ?
>
> Oppure, Array.prototype.newMethod = function() { ... }; ?
>
> > Lo descrivi come se fosse un linguaggio pieno di errori e tutti i siti del mondo stanno cadendo a pezzi
>
> Non so lui cosa dice.
> Io dico che come linguaggio non mi dispiace, mi piace giocherellare con le sue caratteristiche quasi un po' esoteriche. Il problema è che queste sue caratteristiche esoteriche lo rendono error-prone, e dal momento che anche gli IDE potenti come visual studio non offrono un granché per quanto concerne javascript (d'altra parte la mancanza di tipizzazione delle variabili non aiuta l'intellisense).
> Hai quasi paura a fare un refactor del codice.
>
> La sensazione è quella di aver a che fare con degli strumenti troppo rudimentali per gli standard moderni... certo, questi sono i vizietti dei programmatori moderni. I veri programmatori erano quelli degli anni 60-70: opcode, assembly e tanta pazienza.
Sono livelli diversi, oggi si può ragionare di più in astratto perché il costo dell'operazione della macchina è diventato irrisorio.
**Modificato dall'autore il 18.10.2015 15:08**Young professional woman and busy mom.-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-18 15:23:14.0 alle 2015-10-18 15:23:14.0Scritto da: ::1
> > params[] ------> https://msdn.microsoft.com/it-it/library/w5zay9db....
>
> arguments è più flessibile.
Mai incontrato nessun problema con la flessibilità di params. La flessibilità di cui parli in javascript non solo è inutile, ma è pericolosa, perché ti porta a fare errori stupidi che con un linguaggio SERIO avresti evitato.
> > Puoi cambiare il corpo di una funzione al volo? Espandi!
>
>> var f = function(a,b) {return a + b}; > f = function(a) {return a + 1}; > f = console.log.bind(null); >
Puoi farlo anche in C#, nei rari casi in cui serve, con i delegati (o le Action e le Func) a patto che mantieni l'elenco e il tipo dei parametri uguale... ma difficilmente vuoi cambiare l'elenco dei parametri in una funzione "on the fly" visto che romperesti il codice che la usa altrove.
Come ho detto, e ripeto, javascript ti invoglia ad scrivere codice di merda e non fa nulla per prevenirti di fare cazzate gravi. Cazzate che, per lo più, scopri solo a runtime... SE le scopri tu e non il cliente.
> > > è un linguaggio con tratti funzionali (map/reduce/filter + closures);
> >
> > LINQ, ed è molto più elaborato rispetto ai tre metodi che hai in javascript.
> > Le lamba expression di C# rendono la programmazione funzionale molto elegante.
>
> Linq non è neanche lontanamente dinamico.
Mai trovato un problema reale che non fosse risolvibile senza tutta questa "dinamicità" di cui parli. Con in più la possibilità di scrivere codice compatto, capibile e con poche possibilità di sbagliare.
Il fatto è che la "flessibilità" di javascript non serve mai, sta lì solo a romperti le balle quando devi fare il debug e a farti fare errori quando programmi. Javascript è probabilmente il peggior linguaggio oggi esistente.-
Re: Java e ... il restoScritto da:
> Scritto da: ::1
> > > params[] ------> https://msdn.microsoft.com/it-it/library/w5zay9db....
> >
> > arguments è più flessibile.
>
> Mai incontrato nessun problema con la flessibilità di params. La flessibilità di cui parli in javascript non solo è inutile, ma è pericolosa, perché ti porta a fare errori stupidi che con un linguaggio SERIO avresti evitato.
>
> > > Puoi cambiare il corpo di una funzione al volo? Espandi!
> >
> >> > var f = function(a,b) {return a + b}; > > f = function(a) {return a + 1}; > > f = console.log.bind(null); > >
>
> Puoi farlo anche in C#, nei rari casi in cui serve, con i delegati (o le Action e le Func) a patto che mantieni l'elenco e il tipo dei parametri uguale... ma difficilmente vuoi cambiare l'elenco dei parametri in una funzione "on the fly" visto che romperesti il codice che la usa altrove.
>
> Come ho detto, e ripeto, javascript ti invoglia ad scrivere codice di merda e non fa nulla per prevenirti di fare cazzate gravi. Cazzate che, per lo più, scopri solo a runtime... SE le scopri tu e non il cliente.
>
> > > > è un linguaggio con tratti funzionali (map/reduce/filter + closures);
> > >
> > > LINQ, ed è molto più elaborato rispetto ai tre metodi che hai in javascript.
> > > Le lamba expression di C# rendono la programmazione funzionale molto elegante.
> >
> > Linq non è neanche lontanamente dinamico.
>
> Mai trovato un problema reale che non fosse risolvibile senza tutta questa "dinamicità" di cui parli. Con in più la possibilità di scrivere codice compatto, capibile e con poche possibilità di sbagliare.
>
> Il fatto è che la "flessibilità" di javascript non serve mai, sta lì solo a romperti le balle quando devi fare il debug e a farti fare errori quando programmi. Javascript è probabilmente il peggior linguaggio oggi esistente.
Non hai visibilità di quello che ti permette. Un linguaggio molto dinamico può diventare un punto di forza.
Qui
si parla di lisp, ma javascript non è così dissimile (macro a parte).
Young professional woman and busy mom.-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-18 16:39:59.0 alle 2015-10-18 16:39:59.0Scritto da: ::1
> Scritto da:
> > Scritto da: ::1
> > > > params[] ------> https://msdn.microsoft.com/it-it/library/w5zay9db....
> > >
> > > arguments è più flessibile.
> >
> > Mai incontrato nessun problema con la flessibilità di params. La flessibilità di cui parli in javascript non solo è inutile, ma è pericolosa, perché ti porta a fare errori stupidi che con un linguaggio SERIO avresti evitato.
> >
> > > > Puoi cambiare il corpo di una funzione al volo? Espandi!
> > >
> > >> > > var f = function(a,b) {return a + b}; > > > f = function(a) {return a + 1}; > > > f = console.log.bind(null); > > >
> >
> > Puoi farlo anche in C#, nei rari casi in cui serve, con i delegati (o le Action e le Func) a patto che mantieni l'elenco e il tipo dei parametri uguale... ma difficilmente vuoi cambiare l'elenco dei parametri in una funzione "on the fly" visto che romperesti il codice che la usa altrove.
> >
> > Come ho detto, e ripeto, javascript ti invoglia ad scrivere codice di merda e non fa nulla per prevenirti di fare cazzate gravi. Cazzate che, per lo più, scopri solo a runtime... SE le scopri tu e non il cliente.
> >
> > > > > è un linguaggio con tratti funzionali (map/reduce/filter + closures);
> > > >
> > > > LINQ, ed è molto più elaborato rispetto ai tre metodi che hai in javascript.
> > > > Le lamba expression di C# rendono la programmazione funzionale molto elegante.
> > >
> > > Linq non è neanche lontanamente dinamico.
> >
> > Mai trovato un problema reale che non fosse risolvibile senza tutta questa "dinamicità" di cui parli. Con in più la possibilità di scrivere codice compatto, capibile e con poche possibilità di sbagliare.
> >
> > Il fatto è che la "flessibilità" di javascript non serve mai, sta lì solo a romperti le balle quando devi fare il debug e a farti fare errori quando programmi. Javascript è probabilmente il peggior linguaggio oggi esistente.
>
> Non hai visibilità di quello che ti permette.
Ho visibilità dei casini che comporta, e questo mi basta per buttarlo nel cestino senza pensarci due volte. È la stessa ragione per cui programmare in C e C++ sarebbe da evitare se si può scegliere... la loro flessibilità si ritorce contro il programmatore con molta facilità. Quello che a prima vista sembrano i punti di forza del linguaggio, sono in realtà i suoi punti deboli.
Meno possibilità di fare cazzate un linguaggio ti offre e meglio è. Ovviamente devi avere anche una certa flessibilità di espressione, il linguaggio non deve diventare un ostacolo, ma quando diventa troppo permissivo, quando da per scontato che ti ricordi troppe questioni in sospeso (tipo... devo liberare la memoria dopo averla usata, devo ricordarmi che questa funzione ha 2 argomenti interi e non posso cambiarla in una funzione con 3 stringhe sennè rompo quella parte del codice che ho scritto 3 mesi fa 6000 linee più su, ecc)... in quel momento diventa un cattivo linguaggio, perché non tiene conto del fatto che TU sei un essere umano e che le cose te le scordi e che ti può capitare di sbagliare.
Un buon linguaggio deve saperti interrompere e/o avvertire nel momento in cui che quello che fai ha poco senso o può farti fare cazzate gravi... e questo non lo puoi ottenere con linugaggi come javascript, perché non solo è troppo permissivo, ma proprio perché è così permissivo è anche difficile costruire strumenti (IDE, compilatori, ecc) che riescano ad identificare gli errori più comuni PRIMA ancora che tu lanci il programma.
Poi se vuoi tieniti pure javascript, contento tu, ma dai la possibilità a me di usare qualcosa di meglio. Alla fine, avere una VM nel browser, permette esattamente questo. Se a te piace quell'accozzaglia di schifezze che è javascript vai pure avanti ad usare javascript, io preferisco un linugaggio che mi avverte quando faccio cazzate e che mi impedisce di farle e un linguaggio che permette a strumenti esterni (IDE, compilatori, ecc) di individuare eventuali errori e dirmelo mentre sto scrivendo il codice e non dopo 3 mesi quando mi chiama il cliente dicendomi che qualcosa non va in quella particolarissima situazione che capita solo quando plutone è in congiunzione con urano... perché a quel punto non mi ricordo più quello che ho fatto, ci perdo tempo sopra io che devo stare a rileggermi tutta quella pappardella (e la cosa non mi diverte) e sono un costo anche per il cliente che poi deve sborsare dobloni quando magari un semplice controllo sui tipi mi avrebbe permesso di risolvere la cosa immediatamente mentre la scrivevo.
-
-
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-18 21:10:17.0 alle 2015-10-18 21:10:17.0Scritto da: ::1
> Scritto da:
> > Scritto da: ::1
> >
> > Quali delle cose che elenchi non si possono fare con i più comuni linguaggi? Prendiamo C# per esempio...
> >
> > > posso avere una funzione che ha un numero di argomenti variabili
> >
> > params[] ------> https://msdn.microsoft.com/it-it/library/w5zay9db....
>
> arguments è più flessibile.
D'altra parte non è che sia una feature essenziale, visto che per passare un numero variabile di dati puoi utilizzare semplicemente un array.
La maggiore flessibilità di javascript è data in gran parte (correggimi se sbaglio) dal fatto che è weakly-typed, ma la tipizzazione forte non è una cosa fatta per rompere il cazzo, per il gusto di fissare delle regolette rigide... serve ad aiutare te e l'intellisense; se cerchi di metterti una mela nel culo potrebbe far male.
Comunque i limiti dati dalla tipizzazione forte sono raggirabili. Con i genrics e le interfacce puoi produrre metodi e classi riutilizzabili e utilizzando variabili di tipo object puoi ficcare in una variabile qualsiasi cosa tu voglia.
Certo, può essere pericoloso farti passare object in un metodo, in quanto il casting può fallire. Ma la stessa cosa vale per javascript: se chiami il metodo reduce sul parametro, e quel parametro non è un array, ti viene lanciata un'eccezione nel culo.
> >
> > Puoi cambiare il corpo di una funzione al volo? Espandi!
>
>> var f = function(a,b) {return a + b}; > f = function(a) {return a + 1}; > f = console.log.bind(null); >
>
È possibile fare la stessa cosa anche con C#. È meno elegante, ma lo puoi fare se proprio vuoi.class Program { static void Main(string[] args) { Func<object[], object> myFunc; myFunc = p => (int) p[0] + (int) p[1]; Console.WriteLine(myFunc(new object[2] { 2, 2 })); // 2 + 2 myFunc = p => (int) p[0] + 1; Console.WriteLine(myFunc(new object[1] { 2 })); // 2 + 1 myFunc = delegate (object[] parameters) { Console.WriteLine("Hi " + parameters[0]); return null; }; Console.WriteLine(myFunc(new object[1] { "Suora" })); // Hi Suora Console.ReadLine(); } }
>
> Linq non è neanche lontanamente dinamico.
Perché no?
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-18 21:31:25.0 alle 2015-10-18 21:31:25.0Scritto da:
Ops
Console.WriteLine(myFunc(new object[1] { "Suora" })); // Hi Suora
-
-
-
-
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 13:58:27.0 alle 2015-10-17 13:58:27.0Scritto da:
>
> Puoi sempre supportare il try-catch per dare un bel messaggio d'errore all'utente e non far crasciare il programma ma farlo riprendere da uno stato sicuro...
Il try-catch per come la vedo io deve essere usato SOLTANTO per gli errori non deterministici.
Per esempio, nel momento in cui tu richiedi la connessione a un serve o l'utilizzo di una risorsa del sistema operativo, è giusto utilizzare il try-catch in quanto tu, programmatore, non puoi garantire che l'operazione avrà successo. Non puoi garantire al tuo cliente che il suo sistema informatico funzionerà sempre bene, che il loro sistemista sia competente e che i loro switch e router non verrano fuliminati durante un temporale. Siccome non hai il controllo sull'ambiente, tu appunto PROVI a fare quella cosa ma senza poter promettere nulla.
Se però il tuo try-catch cattura degli errori di programmazione che si possono risolvere (come ad esempio le classifiche NullReferenceException) oppure delle eccezioni che si possono evitare semplicemente facendo delle validazioni, allora per come la vedo io c'è qualcosa di sbagliato.
Il codice deve essere scritto correttamente, punto e fine. Tu non PROVI a eseguire il tuo codice, ma lo ESEGUI, perché parti dal presupposto che funzioni correttamente, e se così non è allora fai meglio a scoprirlo in fase di testing.
Per esempio, io mi aggancio alla filosofia di non catturare mai l'eccezione madre Exception, perché così facendo catturi anche degli errori di programmazione. A me sta anche bene che catturi una NullReferenceException, ma allora metti un messaggio d'errore onesto all'utente, del tipo: "L'operazione non è stata portata a termine in quanto nell'applicazione è presente un bug. Si lo so, sono un coglione".
-
Re: Java e ... il restoScritto daNon Autenticatoil 2015-10-17 17:25:40.0 alle 2015-10-17 17:25:40.0sarebbe almeno teoricamente possibile tradurre un codice jscript in uno GO o Dart? E che risultato potrebbe avere in termini di qualità e prestazioni?
-
-
-
-
-
-
-
-
-