Quale linguaggio in ambito web

[Tesinevb]

vuoi una dritta, sviluppa in asp
frontavant javascript

hih hi hi... just as well

[pabloski]

Originariamente inviato da Antonio23

trova le differenze.

e che vuol dire? il punto è che il programmatore è un elemento chiave in tutto questo sistema

se si vuole invece focalizzare l'attenzione sul linguaggio, allora è ovvio che il miglior linguaggio è quello che fornisce le migliori astrazioni possibili per il tipo di problema da risolvere

ovviamente è il problema ad essere determinante in questo caso

[pabloski]

Originariamente inviato da Antonio23

come che vuol dire? i confronti vanno fatti a parita' di esperienza del programmatore

E perchè mai? Quello studio intendeva dimostrare che la bilancia pende molto di più dal lato del programmatore, piuttosto che da quello del linguaggio.

Il punto era dimostrare che le competenze umane superano di gran lunga la "facilità d'uso" di qualsiasi linguaggio.

[WarDuck]

Se posso aggiungere un'osservazione, la produttività dipende anche dagli strumenti che ti mette a disposizione il sistema.

Nello specifico esistono molti tool ormai Java/C++ che consentono di realizzare rapidamente applicazioni, anche con GUI.

In Python la cosa è ancora un po' scarna, anche se bisogna ammettere che Jetbrains rilasciando PyCharm gratuitamente ha fatto una bella mossa .

Programmando in C++ con Vim accuso un po' la cosa, specie quando bisogna passare da un file ad un altro e via discorrendo , motivo per il quale mi sono fatto il pass accademico per CLion che proverò al più presto .

[pabloski]

Originariamente inviato da Antonio23

senza contare che, nel caso specifico, e' MOLTO piu' difficile diventare un programmatore esperto di C++ rispetto a diventare un programmatore medio di Python.

Ma infatti lo studio misurava l'efficienza del programmatore non quella dello strumento.

[pabloski]

Originariamente inviato da WarDuck

Jetbrains rilasciando PyCharm gratuitamente ha fatto una bella mossa .

JetBrains ha cambiato le regole, adesso vuole che gli paghiamo l'abbonamento

Ho letto parecchi commenti di gente un tantinello incazzata.

[cdimauro]

Originariamente inviato da WarDuck

Nello specifico esistono molti tool ormai Java/C++ che consentono di realizzare rapidamente applicazioni, anche con GUI.

In Python la cosa è ancora un po' scarna, anche se bisogna ammettere che Jetbrains rilasciando PyCharm gratuitamente ha fatto una bella mossa .

Molto interessante. Ho dato un'occhiata e ho visto che, ad esempio, supporterebbe PyQT, ma in che modo semplificherebbe la vita per lo sviluppo di applicazioni dotate di GUI, con Python?

Normalmente uso Visual Studio + PTVS per lavorare in Python, e quando devo fare qualcosina su Linux risolvo velocemente con SublimeText3, ma una soluzione unica cross platform mi farebbe comodo, se ne valesse la pena.

Programmando in C++ con Vim accuso un po' la cosa, specie quando bisogna passare da un file ad un altro e via discorrendo , motivo per il quale mi sono fatto il pass accademico per CLion che proverò al più presto .

Lo credo bene: Vim non è un editor, ma uno strumento di sevizie.

Originariamente inviato da pabloski

Ma infatti lo studio misurava l'efficienza del programmatore non quella dello strumento.

Comparando programmatori con esperienza diversa, con strumenti diversi? E' una ricerca del tutto inutile, come hanno già cercato di spiegare.

Un risultato utile sarebbe stato quello di avere una sola variabile in gioco. Ad esempio programmatori esperti con linguaggi diversi, o programmatori alle prime armi sempre con linguaggi diversi.

[71106]

Originariamente inviato da WarDuck

Sarà in rampante ascesa, ma ha ancora quote ben basse rispetto agli altri, è la moda del momento, vedremo quanto regge.

Il solito magna magna, che devi fà, ormai lo sappiamo che Node.js è na mazzetta.

E' evidente che quelle ottimizzazioni sono nate dall'esigenza di qualcuno, e poi altri hanno seguito.

E poi hanno interrotto i lavori per 3 anni con la scusa che avevano trovato un coccio di un vaso dell'antica Roma quando in realtà sappiamo bene che erano semplicemente finiti i soldi perchè erano volate troppe mazzette. Ora hanno ripreso con queste novità con dei nomi "fancy" e sbrilluccicosi ma in realtà stanno solo aspettando di buttarcelo al c**o per la milionesima volta sapendo perfettamente che tanto non diremo niente.
(il massimo della protesta che ne uscirà sarà una striscia di ZeroCalcare e una dose limitata di clicktivismo )

Che devi fà amico mio, è l'Italietta che si lamenta del ducetto e bestemmia la Chiesa Cattolica su fèsbuc ma nel frattempo celebra gli sfarzosi funerali del Casamonica con la colonna sonora de Il Padrino.

Javascript come ha detto giustamente Cesare è nato come un linguaggetto e adesso qualcuno vuole promuoverlo a linguaggio di primo livello per fare tutto. Dio ce ne scampi e liberi sinceramente.

Pensa se fosse stato PHP anzichè JavaScript.

Originariamente inviato da Shirov

Discussione interessante.... qui sostituirei oggettivamente con soggettivamente, almeno considerando un nucleo di una ventina di linguaggi... certo non i casi estremi come brainfuck... anche perchè la parola "migliore" credo sia molto soggettiva, appunto....

Io invece reinserirei esattamente quella parola, "oggettivamente", poichè è facile definire criteri oggettivi in base ai quali giudicare la bontà di un linguaggio. Per esempio: un sistema di tipi forte, statico, e inferito, è oggettivamente migliore di un sistema di tipi debole e/o dinamico; un linguaggio che raggiunge le Turing-completezza con un numero di costrutti minore è oggettivamente migliore; e così via.

[71106]

Originariamente inviato da pabloski

E perchè mai? Quello studio intendeva dimostrare che la bilancia pende molto di più dal lato del programmatore, piuttosto che da quello del linguaggio.

Il punto era dimostrare che le competenze umane superano di gran lunga la "facilità d'uso" di qualsiasi linguaggio.

Se il punto fosse stato quello lo studio avrebbe dovuto essere svolto a parità di linguaggio, ossia avrebbe dovuto essere un confronto tra programmatori esperti che lavorano in C++ e programmatori medi che lavorano sempre in C++.

[cdimauro]

Originariamente inviato da 71106

Pensa se fosse stato PHP anzichè JavaScript.

E' uguale: dei due non se ne salva nessuno. Javascript non è certo meglio di PHP.

Io invece reinserirei esattamente quella parola, "oggettivamente", poichè è facile definire criteri oggettivi in base ai quali giudicare la bontà di un linguaggio. Per esempio: un sistema di tipi forte, statico, e inferito, è oggettivamente migliore di un sistema di tipi debole e/o dinamico;

Ma anche no: non hai dato alcuna definizione/metrica che possa quanto meno essere discussa. "Migliore" in base a quale criterio?

un linguaggio che raggiunge le Turing-completezza con un numero di costrutti minore è oggettivamente migliore; e così via.

Il primo linguaggio che ho studiato all'università in TAMC (Teoria e Applicazione delle Macchine Calcolatrici; quindi poco meno di 25 anni fa: sono vecchio, lo so ) quando si è discusso di calcolabilità e di Turing-completezza è stato "S", dove S mi pare stia per Simple, in quanto era il linguaggio più semplice e minimale a potersi fregiare di questo titolo. Infatti aveva soltanto TRE costrutti che, se non ricordo male, erano:
- azzerare un registro;
- incrementare di uno un registro;
- saltare a un altro indirizzo se il contenuto di un registro era zero o diverso da zero (non ricordo quale dei due fosse).

Secondo la tua definizione sarebbe "oggettivamente migliore" di qualunque altro linguaggio, ma piuttosto che lavorarci preferirei mille volte scrivere codice in Brainfuck o Whitespace.

[WarDuck]

Originariamente inviato da 71106

E poi hanno interrotto i lavori per 3 anni con la scusa che avevano trovato un coccio di un vaso dell'antica Roma quando in realtà sappiamo bene che erano semplicemente finiti i soldi perchè erano volate troppe mazzette. Ora hanno ripreso con queste novità con dei nomi "fancy" e sbrilluccicosi ma in realtà stanno solo aspettando di buttarcelo al c**o per la milionesima volta sapendo perfettamente che tanto non diremo niente.
(il massimo della protesta che ne uscirà sarà una striscia di ZeroCalcare e una dose limitata di clicktivismo )

Che devi fà amico mio, è l'Italietta che si lamenta del ducetto e bestemmia la Chiesa Cattolica su fèsbuc ma nel frattempo celebra gli sfarzosi funerali del Casamonica con la colonna sonora de Il Padrino.

Al di là delle tue battute idiote e poco simpatiche, è un dato di fatto che Javascript sia nato per fare altro e "promosso" in seguito (ahimé).

Di certo non era nato come dici te per le "performance"

E anche se adesso è la moda, rimane un linguaggio "oggettivamente" mediocre.

[cdimauro]

Mediocre?!? Perché fargli un complimento?

[eraser]

Originariamente inviato da WarDuck

In Python la cosa è ancora un po' scarna, anche se bisogna ammettere che Jetbrains rilasciando PyCharm gratuitamente ha fatto una bella mossa .

PyCharm oramai nella mia azienda è lo standard da un paio d'anni

[cdimauro]

OK, allora devo almeno dargli un'occhiata. Magari nel prossimo weekend. Danke!

[71106]

Originariamente inviato da cdimauro

Ma anche no: non hai dato alcuna definizione/metrica che possa quanto meno essere discussa. "Migliore" in base a quale criterio?

Se confrontiamo ES5 con PHP 5.2 (entrambi finalizzati nel 2011), il primo esempio che mi viene in mente è l'impossibilità in PHP di scrivere espressioni come "$xyz[0]()", cioè l'impossibilità di invocare funzioni i cui riferimenti sono memorizzati in un array. Il motivo è che la sintassi di PHP, inutilmente complicata, definisce un costrutto a parte per le invocazioni che non è integrato con le espressioni. Una sintassi astratta più semplice è oggettivamente migliore di una più complessa.

Il secondo esempio che mi viene in mente è la necessità in PHP di ridichiarare localmente le variabili globali qualora le si voglia catturare in una funzione, del tutto inutile visto che implementazioni come ES5 sono evidentemente possibili. Un linguaggio che impone un determinato elemento di boilerplate è oggettivamente peggiore di uno che non lo impone.

Potremmo andare avanti all'infinito ma non ne ho voglia, solo per i primi due esempi ho scritto diverse righe e non ne valeva proprio la pena.

Secondo la tua definizione sarebbe "oggettivamente migliore" di qualunque altro linguaggio, ma piuttosto che lavorarci preferirei mille volte scrivere codice in Brainfuck o Whitespace.

Ti faccio notare mille volte che Brainfuck è molto simile al linguaggio che hai descritto.

Ad ogni modo la tua conclusione è errata, poichè hai descritto un linguaggio privo di sistema di tipi. Un sistema di tipi statico, forte, e inferito è oggettivamente migliore di uno assente.

Inoltre, se accettiamo che "lo stato è il male" perchè per il programmatore rilevarlo e tenerlo a mente è difficile o in casi estremi anche umanamente impossibile, giungiamo facilmente alla conclusione che anche il lambda calcolo non tipato è migliore di "S" perchè a parità di costrutti astratti (sono 3: variabile, funzione, applicazione) riesce a mantenere la Turing-completezza consentendo allo sviluppatore un processo mentale più semplice.

Originariamente inviato da WarDuck

è un dato di fatto che Javascript sia nato per fare altro e "promosso" in seguito (ahimé).

JavaScript, in quanto Turing-completo e basato su un dominio di valori espressivo, non è in alcun modo meno adatto alle applicazioni diverse da quelle per cui è nato.

Un argomento più solido è invece affermare che JavaScript sia subottimale per qualsiasi applicazione, sulla qual cosa concordo perfettamente; tuttavia dubito che tu sia in grado di portarlo avanti (altrimenti lo avresti già fatto).

Di certo non era nato come dici te per le "performance"

Vorresti cortesemente portare alla mia attenzione il permalink al post in cui ho scritto questa cosa? Non lo trovo.

(non che non mi fidi o abbia scarsa stima nei tuoi confronti, ma sai com'è, gira certa gentaglia sui forum che pur di avere la misera soddisfazione di mettere qualcuno a tacere in un argomento gli infilerebbe in bocca di tutto)

E anche se adesso è la moda,

Che devi fà, siamo un popolo di pecoroni. Stanno tutti arrubbà tranne noi scemi che paghiamo le tasse. Non sanno più che inventasse. Qui una volta era tutto campi. Non ci sono più le mezze stagioni.

rimane un linguaggio "oggettivamente" mediocre.

Mi hai sorpreso: non credevo che avresti mai scritto qualcosa di significativo e corretto. Bravo.

[71106]

Originariamente inviato da cdimauro

Ma anche no: non hai dato alcuna definizione/metrica che possa quanto meno essere discussa. "Migliore" in base a quale criterio?

Questo punto va chiarito meglio poichè era in risposta a un'altra questione.

Ciò che io ho scritto è:

Originariamente inviato da 71106

un sistema di tipi forte, statico, e inferito, è oggettivamente migliore di un sistema di tipi debole e/o dinamico.

Non credevo che fosse necessario chiarire ulteriormente ciò che mi sembra ovvio, ossia:

• un sistema di tipi statico è oggettivamente migliore di uno dinamico poichè il secondo permette di commettere errori che non verranno mai rivelati in fase di sviluppo (le tecniche di testing automatico mitigano il problema ma non costituiscono una soluzione completa, e comunque non sono obbligatori e di conseguenza non rendono il linguaggio "oggettivamente migliore");
• un sistema di tipi inferito è oggettivamente migliore di uno manifesto perchè rende il codice più conciso;
• un sistema di tipi forte è oggettivamente migliore di uno debole perchè fornisce maggiori garanzie (o, equivalentemente, perchè quello debole consente operazioni che vanificano qualunque controllo di tipo).

[WarDuck]

Originariamente inviato da 71106

JavaScript, in quanto Turing-completo e basato su un dominio di valori espressivo, non è in alcun modo meno adatto alle applicazioni diverse da quelle per cui è nato.

Capisco che tu sia pignolo (dicesi cacacazzi ) e voglia metterla sul formale, è vero ciò che dici, ma sarebbe un discorso abbastanza povero di contenuti se ci si fermasse a valutare un linguaggio dalla sua appartenenza o non-appartenenza alla famiglia dei Turing-Completi.

Originariamente inviato da 71106

Un argomento più solido è invece affermare che JavaScript sia subottimale per qualsiasi applicazione, sulla qual cosa concordo perfettamente; tuttavia dubito che tu sia in grado di portarlo avanti (altrimenti lo avresti già fatto).

Non ho sufficientemente tempo, voglia e pazienza per farti dissertazioni sul perché Javascript sia fondamentalmente un linguaggio mediocre, anche perché in letteratura altri l'hanno fatto al posto mio.

Questo ad esempio è un bellissimo video (breve) che illustra poche ma significative perle di javascript: https://youtu.be/20BySC_6HyY?t=84

Questo per chi ha tempo e voglia è un po' più lungo: https://youtu.be/xE8tL8NdHaY?t=444

Originariamente inviato da 71106

Vorresti cortesemente portare alla mia attenzione il permalink al post in cui ho scritto questa cosa? Non lo trovo.

(non che non mi fidi o abbia scarsa stima nei tuoi confronti, ma sai com'è, gira certa gentaglia sui forum che pur di avere la misera soddisfazione di mettere qualcuno a tacere in un argomento gli infilerebbe in bocca di tutto)

Non l'hai detto esplicitamente, vero. Ma nella discussione era uscito il discorso delle performance di PHP, e ti ho fatto notare che esattamente come è successo per Javascript nel corso del tempo sono uscite diverse implementazioni ottimizzate.

[cdimauro]

Originariamente inviato da 71106

Se confrontiamo ES5 con PHP 5.2 (entrambi finalizzati nel 2011), il primo esempio che mi viene in mente è l'impossibilità in PHP di scrivere espressioni come "$xyz[0]()", cioè l'impossibilità di invocare funzioni i cui riferimenti sono memorizzati in un array. Il motivo è che la sintassi di PHP, inutilmente complicata, definisce un costrutto a parte per le invocazioni che non è integrato con le espressioni. Una sintassi astratta più semplice è oggettivamente migliore di una più complessa.

Il secondo esempio che mi viene in mente è la necessità in PHP di ridichiarare localmente le variabili globali qualora le si voglia catturare in una funzione, del tutto inutile visto che implementazioni come ES5 sono evidentemente possibili. Un linguaggio che impone un determinato elemento di boilerplate è oggettivamente peggiore di uno che non lo impone.

Potremmo andare avanti all'infinito ma non ne ho voglia, solo per i primi due esempi ho scritto diverse righe e non ne valeva proprio la pena.

Nemmeno io, perché paginette come YourLanguageSucks offrono non pochi (non tutti, comunque) spunti allo scopo. Anche per JavaScript.

Ti faccio notare mille volte che Brainfuck è molto simile al linguaggio che hai descritto.

Vero, ma non è minimale quanto S.

Ad ogni modo la tua conclusione è errata, poichè hai descritto un linguaggio privo di sistema di tipi. Un sistema di tipi statico, forte, e inferito è oggettivamente migliore di uno assente.

L'unico tipo che esiste in S è quello intero (illimitato in dimensione, per gli stessi motivi per cui la macchina di Turing che si studia ha un nastro infinito: esigenze teoriche) ed è ovviamente statico e forte (che sia inferito non serve, perché è ovvio, esistendo un solo tipo).

S è sostanzialmente un linguaggio assembly in cui esiste un solo tipo di memoria (rappresentato dai registri) e tre istruzioni.

Inoltre, se accettiamo che "lo stato è il male" perchè per il programmatore rilevarlo e tenerlo a mente è difficile o in casi estremi anche umanamente impossibile, giungiamo facilmente alla conclusione che anche il lambda calcolo non tipato è migliore di "S" perchè a parità di costrutti astratti (sono 3: variabile, funzione, applicazione) riesce a mantenere la Turing-completezza consentendo allo sviluppatore un processo mentale più semplice.

Se per stato ti riferisci allo stato di un oggetto, non sono affatto d'accordo. La programmazione a oggetti serve a modellare determinate classi di problemi molto più semplicemente di quanto farebbero i linguaggi funzionali (e, viceversa, i linguaggi funzionali consentono di modellarne altre più semplicemente dei linguaggi a oggetti).

Lo stato di un oggetto è perfettamente e naturalmente aderente allo scopo.

JavaScript, in quanto Turing-completo e basato su un dominio di valori espressivo, non è in alcun modo meno adatto alle applicazioni diverse da quelle per cui è nato.

Permettimi: il meccanismo dei prototipi è e rimane una porcata colossale per modellare problematiche in cui il paradigma a oggetti è preferibile.

Tant'è che nelle future estensioni del linguaggio si prevede l'introduzione di vere e proprie classi per semplificarne la dichiarazione e correggere altre porcate.

Originariamente inviato da 71106

Questo punto va chiarito meglio poichè era in risposta a un'altra questione.

Ciò che io ho scritto è:

Non credevo che fosse necessario chiarire ulteriormente ciò che mi sembra ovvio, ossia:

• un sistema di tipi statico è oggettivamente migliore di uno dinamico poichè il secondo permette di commettere errori che non verranno mai rivelati in fase di sviluppo (le tecniche di testing automatico mitigano il problema ma non costituiscono una soluzione completa, e comunque non sono obbligatori e di conseguenza non rendono il linguaggio "oggettivamente migliore");
• un sistema di tipi inferito è oggettivamente migliore di uno manifesto perchè rende il codice più conciso;
• un sistema di tipi forte è oggettivamente migliore di uno debole perchè fornisce maggiori garanzie (o, equivalentemente, perchè quello debole consente operazioni che vanificano qualunque controllo di tipo).

Non era ovvio, perché non avevi definito cosa PER TE fosse migliore.

Infatti, e a MIO modo di vedere, ci sono anche degli svantaggi:
- un sistema di tipo statico non mi consente di astrarre un concetto, generando un solo codice per gestire tutti i casi, anche "futuri";
- un codice conciso non è di per sé garanzia di alcunché, perché, ad esempio, potrebbe minare la leggibilità e manutenibilità del codice;
- un sistema di tipi forte comporta problematiche nella conversione dei tipi, richiedendo operazioni di cast espliciti anche quando una conversione implicita risulterebbe, invece, "safe".

Come vedi non c'è nulla di oggettivo in quello che hai scritto finora, ma una tua, personalissima, presa di posizione su determinati aspetti dei linguaggi di programmazione.

Aggiungo (ma in parte era evidente) che A ME, per esempio, interessano più la leggibilità, manutenibilità, facilità e velocità di scrittura di codice (prototipazione rapida), possibilità di sperimentare con pezzi di codice, nonché capacità di poter testare virtualmente ogni aspetto del codice (mi riferisco alla possibilità di poter dinamicamente modificare praticamente tutto del contesto attuale dell'esecuzione, incluse funzioni e tipi built-in, in base agli scenari che ho bisogno di simulare).

[marco.r]

Originariamente inviato da WarDuck

Javascript come ha detto giustamente Cesare è nato come un linguaggetto e adesso qualcuno vuole promuoverlo a linguaggio di primo livello per fare tutto. Dio ce ne scampi e liberi sinceramente.

Penso sia un giudizio abbastanza ingeneroso.
Non c'e' nessun "qualcuno" con un piano segreto per far diffondere ulteriormente JavaScript. Semplicemente c'e' chi trova produttivo usare JavaScript, nonostante tutte le sue carenze, per cui cerca di sfruttarlo in ambiti nuovi.
A ben vedere anche Java ha cominciato come linguaggio per uno scopo specifico (set-top boxes, dove non e' andata bene), e' stato provato come linguaggio per il web (lato client, dove non e' piu' usato), applicazioni desktop (non tanto meglio) e ha trovato il suo posto come linguaggio per i web services e, grazie a Google, per Android.

[OoZic]

quante seghe mentali e quanti pipponi inutili.

domanda per gli espertoni del thread:

se javascript e' un linguaggio mediocre come mai non esiste altro linguaggio che gira nel browser?

stiamo parlando di un linguaggio nato 20 anni fa.

l'unico tentativo che mi viene in mente, fallito miseramente, e' Dart di Google.

a voi la parola