Il vostro linguaggio di programmazione fa schifo, qualunque esso sia

[71104]

Originariamente inviato da FagioloOne

Sto lavorando per creare un video game ed effettivamente java preferisce lavorare usando un uso smodato di Buffer anche dove tu ti chiedi il perche'.

io non è che sono il primo venuto per quanto riguarda Java: in Java ci sto programmando anche io in questo periodo per la tesi e comunque ci programmo da anni; ma tutta questa inutile bufferizzazione non credo d'averla mai vista.

Per le eccezioni su java acchiapparle tutte e' veramente uno strazio e' brutto non gestire anche quelle non obligatorie. (Mio personale modo di programmare)

devi acchiapparle tutte. la situazione sulle eccezioni in realtà è parecchio complessa: andbin ha spiegato molto eloquentemente la differenza tra quelle checked e quelle unchecked e i loro rispettivi significati, quindi se tu ipoteticamente non catturassi delle eccezioni checked il tuo programma sarebbe semplicemente buggato, perché non gestirebbe determinati casi d'errore che non dipendono da te, ma che si possono benissimo verificare anche se il tuo programma è perfetto (esempio: mia sorella inciampa in un cavo ethernet ). in altre parole Java ti obbliga ad eliminare alcuni tipi di bug. tuttavia è anche vero quello che il team di C# ha risposto a Bruce Eckel nell'intervista (vedi qua: http://www.artima.com/intv/handcuffs.html), ovvero che certe volte il numero di possibile eccezioni (checked, aggiungo io) che un pezzo di codice potrebbe lanciare è spropositato, e chi usa quel pezzo di codice fa un banale "catch (Exception e)" e le gestisce tutte allo stesso modo; un difetto di Java è che non permette di gestire molte eccezioni diverse allo stesso modo, e questo riduce la produttività e allunga il codice da scrivere. c'è anche da dire che il team di C# ha "risolto" la cosa in un modo che non mi piace, ovvero tutte le eccezioni sono unchecked. ma dico io, ci vuole tanto a definire un linguaggio dove l'istruzione catch prende una lista di eccezioni anziché un'eccezione sola?

edit - aggiungo anche: una delle prime cose che mi ha detto il tipo che mi sta seguendo nella tesi è che lo strato di software che io sto sviluppando deve avere una casistica d'errore semplice: non devo mettermi a lanciare una dozzina di eccezioni da ogni metodo (ce ne sarebbero a volontà visto che devo comunicare con due database di tipo diverso, uno MySQL e l'altro LDAP), ma mi ha detto di scrivere solo 4 eccezioni:

• SystemException - per tutti i gli errori locali (ad es., non trovo un file di inizializzazione, oppure è corrotto)
• NetworkException - per problemi di rete (es. mia sorella inciampa nel cavo ethernet )
• SecurityException - per gli access check falliti (es., non ho i permessi per scrivere alcuni dati sul database)
• DataException - i dati su uno dei due database sono corrotti

praticamente mi sta facendo eliminare manualmente il problema della numerosità delle eccezioni. e già 4 eccezioni sono tante: sono tutte checked perché tutte quante rappresentano condizioni di errore incontrollabili dal programma (notare gli esempi che ho fatto), quindi significa che ogni singola chiamata alla libreria che sto sviluppando dovrà essere circondata da ben 4 catch, a meno che qualcuna delle 4 eccezioni non venga propagata; e non c'è altra soluzione! figuriamoci se le propagavo tutte direttamente senza suddividerle per argomento: erano una dozzina di catch a chiamata.

[cdimauro]

Originariamente inviato da 71104

non c'è motivo ma mi pare che non ci sia neanche problema; anzi, (leggi sotto)

appunto, quindi hanno fatto contenti tutti; che problema c'è?

Perché aumenta inutilmente la complessità del linguaggio, e il numero di cose che bisogna conoscere.

Ecco qua: http://www.netfunny.com/rhf/jokes/99/Nov/perl.html

in particolare: "more than one way to do it..."

Inoltre:

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

e sennò come lo inserisci il codice in mezzo all'HTML? oppure intendi che devono cominciare con quel tag anche i programmi standalone, non mischiati all'HTML?
in questo secondo caso è pazzesco

La seconda che hai detto.

Originariamente inviato da astorcas

Metto le mani avanti dicendo che a prescindere da questo mi sta facilitando parecchio la vita (insieme col Python, per la gioia di cdimauro )

E' cosa buona e giusta.

Originariamente inviato da 71104

ma dico io, ci vuole tanto a definire un linguaggio dove l'istruzione catch prende una lista di eccezioni anziché un'eccezione sola?

In effetti non ci vuole molto. Basta andare qui: www.python.org e lo trovi.

[nico159]

Sbaglio o manca visual basic?

[cdimauro]

Aggiungilo tu.

Penso di aver finito con PHP. Al momento c'è molta più roba per PHP che per tutti gli altri linguaggi messi assieme.

Enjoy.

Ho anche approfittato per mettere un paio di cosucce su Java.

[||ElChE||88]

Originariamente inviato da cdimauro

Al momento c'è molta più roba per PHP che per tutti gli altri linguaggi messi assieme.

Visto il livello di PHP direi che è giusto così.

[71104]

Originariamente inviato da cdimauro

Perché aumenta inutilmente la complessità del linguaggio, e il numero di cose che bisogna conoscere.

aumenta la complessità del linguaggio di uno sputo, e non inutilmente: fa contemporaneamente felici più persone allo stesso tempo. ed inoltre non aumenta la quantità di cose che devi conoscere: tu i commenti li scrivi in una sola maniera, quella che più ti aggrada.

La seconda che hai detto.

minchia

In effetti non ci vuole molto. Basta andare qui: www.python.org e lo trovi.

PS: ho rimpinguato un po' la sezione sul C++

[Hiskrtapps]

se posso permettermi, non di criticare ma di provare a integrare alcuni commenti riguardanti php (su cui concordo al 99%)

if you send the wrong number of arguments to a function call, no error is raised; the extra arguments are ignored.

L'errore esiste ed è sollevato, dipende dagli errori che TU decidi reputare bloccante o no.
L'appunto che si può fare è che esistono modi diversi di giudicare gli errori e questi sono dipendenti da scelte del programmatore: che succede se qualcuno usa qualcosa realizzato da qualcun'altro, e quindi con premesse diverse? Potrei avere errori inattesi (perchè la gestione dell'errore mia è diversa dalla tua che hai sviluppato il modulo che uso)

there are two ways for end-of-line comments: // and #

anche in java puoi mettere i commenti in 2 modi: // /* e anche /**

code must be inserted between <?php and ?> tags

per separarlo dall'html, scelta saggia; lo fa anche asp e jsp.
al massimo si può dire: perchè esistono 2 start tag: <? <?php, ma dire che non servono direi che non ha senso

constants do not use $ prefix, such as variables

e quindi?

static variables cannot be accessed from an instance; they must be
accessed using the $class::variable scope operator

questa non l'ho capita. anche per accedere a una proprietà dell'oggetto in cui ti trovi devi sempre mettere $this-> davanti

[ndakota]

Originariamente inviato da Hiskrtapps

there are two ways for end-of-line comments: // and #

anche in java puoi mettere i commenti in 2 modi: // /* e anche /**

penso che intendano commenti di riga singola. In Java // è un commento end-of-line, /* questo multiriga e questo /** per la Javadoc se non erro. Hanno tutti una loro utilità.

EDIT: abitiamo a 10 minuti di distanza

[Hiskrtapps]

Originariamente inviato da ndakota

penso che intendano commenti di riga singola. In Java // è un commento end-of-line, /* questo multiriga e questo /** per la Javadoc se non erro. Hanno tutti una loro utilità.

EDIT: abitiamo a 10 minuti di distanza

se sei di milano città direi di si :-D

Per quanto riguarda il javadoc nessuno vieta di creare qualcosa di analogo per php (esiste già phpDoc in realtà) che interpreti i diversi tipi di commento in modo diverso.
e cmq in java nessuno mi vieta di mettere un commento singola riga così /* */
ma prima era stato fatto notare questo principio
There should be one-- and preferably only one --obvious way to do it.

in cui anche io credo, solo che così come sono scritte sembra che certe cose e certe scelte sbagliate siano solo di php, e se per la maggior parte delle cose può anche essere così, non lo è per tutte

[cdimauro]

Originariamente inviato da 71104

aumenta la complessità del linguaggio di uno sputo, e non inutilmente: fa contemporaneamente felici più persone allo stesso tempo. ed inoltre non aumenta la quantità di cose che devi conoscere: tu i commenti li scrivi in una sola maniera, quella che più ti aggrada.

Sì, ma il linguaggio è comunque più complesso. Poi immagina di estendere questo principio in generale: per accontentare tutti il PHP diventerebbe un porcaio (vabbé, lo è già abbastanza, ma... non c'è limite alle zozzerie che si possono aggiungere ).

Esempio: ma perché non mettiamo le stringhe multilinea come in Python. Ah, visto che ci siamo, mettiamo anche le n-mila versioni di Ruby. Ecc. ecc. ecc.

Accontentare tutti = realizzare un linguaggio di programmazione senza una sua identità e aumentando inutilmente (perché non sono state introdotte nuove funzionalità effettivamente, ma nuove modalità per esprimere gli stessi concetti) la sua complessità.

Il tutto IMHO ovviamente.

E lasciamo fanboyeggiare ogni tanto, dai.

PS: ho rimpinguato un po' la sezione sul C++

Benissimo, ma non ho tempo di leggere al momento: sto scappando qualche giorno per le ferie. Me le godrò con calma dopo.

P.S. Agli altri messaggi risponderò al ritorno.

[ndakota]

Originariamente inviato da Hiskrtapps

se sei di milano città direi di si :-D

no molto più vicino.. pioltello

[vladix]

Originariamente inviato da Hiskrtapps

if you send the wrong number of arguments to a function call, no error is raised; the extra arguments are ignored.

c'avrei giurato di aver visto questa riga nella sezione dedicata al javascript

EDIT:

Originariamente inviato da Hiskrtapps

code must be inserted between <?php and ?> tags

per separarlo dall'html, scelta saggia; lo fa anche asp e jsp.
al massimo si può dire: perchè esistono 2 start tag: <? <?php, ma dire che non servono direi che non ha senso

c'e anche "<% %>" e "<script language='PHP'></script>"

[RaouL_BennetH]

Io aggiungerei anche Visual Basic.

Il perchè è semplice:

permette a persone come me di scrivere programmi che funzionano

[sottovento]

Originariamente inviato da 71104

.
tuttavia è anche vero quello che il team di C# ha risposto a Bruce Eckel nell'intervista (vedi qua: http://www.artima.com/intv/handcuffs.html), ovvero che certe volte il numero di possibile eccezioni (checked, aggiungo io) che un pezzo di codice potrebbe lanciare è spropositato, e chi usa quel pezzo di codice fa un banale "catch (Exception e)" e le gestisce tutte allo stesso modo; un difetto di Java è che non permette di gestire molte eccezioni diverse allo stesso modo, e questo riduce la produttività e allunga il codice da scrivere. c'è anche da dire che il team di C# ha "risolto" la cosa in un modo che non mi piace, ovvero tutte le eccezioni sono unchecked. ma dico io, ci vuole tanto a definire un linguaggio dove l'istruzione catch prende una lista di eccezioni anziché un'eccezione sola?

Sono d'accordo.
Ho riletto diverse volte il "pensiero" di Bruce Eckel e non riesco a capire come le unchecked exceptions possano essere un vantaggio (per lo meno, come possano risolvere questo problema).

A dire il vero, lui insisteva molto sulle eccezioni "ingoiate" (swallow), vale a dire "tappate" dal programmatore pigro o poco accorto, ma non mi sembra abbia dato una spiegazione valida: per quale motivo le eccezioni unchecked non soffrono del suddetto problema.

Visto che ci siamo, ecco qui una chicca fresca fresca:
E' tutto il giorno che sto litigando perche' il programma scritto dal cliente (in C++ sotto Visual) va in crash senza motivo.
Dopo aver analizzato la situazione col debugger, e' chiaro che veniva sollevata un'eccezione da qualche funzione. Quale funzione e che tipo di eccezione? Non era chiaro, c'e' voluto un bel po' per trovarla.

Ed ora? Come faccio a sapere se le ho prese tutte?

La tentazione e' quella di scrivere, nel punto piu' "alto" possibile nel codice, un bel catch (...). Purtroppo non avrebbe senso, non mi riporterebbe le informazioni necessarie a fare il recovery della situazione e...

try
{
   char *p = NULL;

   *p = 'a';
}
catch (...)
{
   printf ("Eccezione\n");
}

Quindi, nel caso mettessi quel catch(...), l'applicazione non mi crasherebbe piu'! O meglio, prima o poi andra' in crash ma non sara' piu' possibile trovarlo facilmente....

[71104]

giusto! aggiornato con: "catch (...) doesn't allow to know the type of exception."

[sottovento]

Ok, ma la mia intenzione era quella di aprire un flame (beh, non proprio): perche' la checked exception sono da considerarsi il male della Terra? Perche' addirittura sono da considerarsi anti-pattern?
Perche' su Internet si leggono cose del tipo "l'esperimento delle checked-exception fatto da Sun con Java e' da dichiararsi fallito?".

Continuo a leggere pagine e pagine di materiale contro le checked exception e nessuno che riesca a convincermi.... qualcuno riesce ad illuminarmi?

Lo so che questo non e' proprio il thread giusto, ma visto che si parla di linguaggi che fanno schifo...qual e' la cosa migliore? Checked o Unchecked?

[astorcas]

Originariamente inviato da sottovento

Ok, ma la mia intenzione era quella di aprire un flame (beh, non proprio): perche' la checked exception sono da considerarsi il male della Terra? Perche' addirittura sono da considerarsi anti-pattern?
Perche' su Internet si leggono cose del tipo "l'esperimento delle checked-exception fatto da Sun con Java e' da dichiararsi fallito?".

Continuo a leggere pagine e pagine di materiale contro le checked exception e nessuno che riesca a convincermi.... qualcuno riesce ad illuminarmi?

Lo so che questo non e' proprio il thread giusto, ma visto che si parla di linguaggi che fanno schifo...qual e' la cosa migliore? Checked o Unchecked?

Personalmente sento la mancanza delle checked in C#, e tra l'altro ho letto (cosa che non mi è capitata con Java) sorgenti scritti da altri dove le eccezioni sono diventate così "leggere" che i try catch hanno sostituito gli if else.....
Se proprio devo obiettare su qualcosa mi viene da pensare: "Perchè diamine le unchecked exception che derivano sempre RuntimeException sono sottoclassi di Exception da cui derivano tutte le eccezioni checked?" sta cosa non la capisco.

[71104]

Originariamente inviato da astorcas

Se proprio devo obiettare su qualcosa mi viene da pensare: "Perchè diamine le unchecked exception che derivano sempre RuntimeException sono sottoclassi di Exception da cui derivano tutte le eccezioni checked?" sta cosa non la capisco.

quoto!! questa ce la metto subito, anche io ho sempre pensato che dovesse essere casomai il contrario, cioè Exception che deriva da RuntimeException (con altri nomi ovviamente).

edit - aggiornata; grazie astorcas.

[sottovento]

Originariamente inviato da astorcas

Personalmente sento la mancanza delle checked in C#, e tra l'altro ho letto (cosa che non mi è capitata con Java) sorgenti scritti da altri dove le eccezioni sono diventate così "leggere" che i try catch hanno sostituito gli if else.....
Se proprio devo obiettare su qualcosa mi viene da pensare: "Perchè diamine le unchecked exception che derivano sempre RuntimeException sono sottoclassi di Exception da cui derivano tutte le eccezioni checked?" sta cosa non la capisco.

Quindi sei anche tu a favore. Proprio non capisco, e soprattutto perche' dovrebbe essere un anti-pattern!?!?
Sto cercando di capire il punto di vista di chi sostiene che siano un esperimento fallito, ma proprio non ci riesco... non riesco a vedere un solo vantaggio delle unchecked

[71104]

Originariamente inviato da sottovento

Quindi sei anche tu a favore. Proprio non capisco, e soprattutto perche' dovrebbe essere un anti-pattern!?!?
Sto cercando di capire il punto di vista di chi sostiene che siano un esperimento fallito, ma proprio non ci riesco... non riesco a vedere un solo vantaggio delle unchecked

intendiamoci... servono entrambe, sia le checked sia le unchecked. è inutile mettersi a catchare tutte le possibili NullPointerException.