Pregi e difetti di Java (split da [Java]Esempi di programmi)

[numberinn]

per quanto java sia un linguaggio a mio parere piuttosto idiota

Perchè scusa?

[zello]

A me sinceramente non piace, perché, con la scusa di voler creare una sorta di "C++ semplice", ha:
- reso obbligatorio il paradigma ad oggetti; come dice Stepanov, "dire che tutto è un oggetto non significa nulla". Manca tutta la parte di programmazione generica, e tutto deriva da un fantomatico "Object" che di fatto rende comuni classi che non hanno nulla in comune.
L'effetto collaterale è che - per avere collezioni - devo "castare" ad Object e "ricastare" alla classe specifica (l'ultimo downcasting è necessariamente controllato a runtime), mentre in linguaggi con funzionalità parametriche posso avere collezioni parametrizzate sul tipo degli oggetti, e i cast non sono necessari (si pensi a std::list<T> o agli altri contenitori della STL di c++)

- nascosto i puntatori rendendo tutto un puntatore; questo mi impedisce di applicare comodi stili di gestione del lifetime degli oggetti, tipo il "resource allocation is initialization". In pratica, in C++:

Codice: Seleziona tutto

class A
{
public:
     A(){}
     ~A(){}
};

int main()
{
     A a;
     ...
     ...
     return 0;
}


Non importa come io esco dal main (con un return a metà, lanciando un'eccezione, arrivando fino in fondo), sono sicuro che il distruttore di A viene chiamato. Questo è particolarmente importante nella gestione delle risorse come files o locks (sono sicuro di chiuderli o rilasciarli). In java non puoi fare nulla del genere (ed infatti sono previsti i blocchi finally, che in c++ non sono necessari).
- sarò io, ma ogni volta che provo ad usare java (ed in effetti è un po' che non lo faccio) per fare qualcosa di serio, incappo in un problema. Una delle ultime volte, ho provato ad usare jdbc (il ponte jdbc-odbc, per la precisione), e ho trovato che aveva tanti di quei limiti che ho dovuto scrivere tonnellate di codice per aggirare. Le prime swing erano talmente bacate da essere pressoché inutilizzabili. E tutto per ottenere prestazioni francamente indecenti.
- avere i metodi definiti subito dopo la loro dichiarazione, e non successivamente(come in object pascal o in c++) significa che diventi imbecille per comprendere l'interfaccia della classe.
- infine mi urta moltissimo che java (e c#, e molti altri linguaggi con sintassi simile al C) abbia quel tanto di differenza sintattica dal c/c++ da farmi perdere tempo a correggere errori cretini. Che bisogno c'è di non separare interfaccia e implementazione? Che bisogno c'è di specificare "public", "protected" o "private" a livello di singolo membro e non "fino a specifica successiva"? Perché in C++ al termine di una classe ci va il punto e virgola, e in java no?

[pjfry]

L'effetto collaterale è che - per avere collezioni - devo "castare" ad Object e "ricastare" alla classe specifica (l'ultimo downcasting è necessariamente controllato a runtime), mentre in linguaggi con funzionalità parametriche posso avere collezioni parametrizzate sul tipo degli oggetti, e i cast non sono necessari (si pensi a std::list<T> o agli altri contenitori della STL di c++)

nella 1.5 ci sono le collection con i template, figata

- avere i metodi definiti subito dopo la loro dichiarazione, e non successivamente(come in object pascal o in c++) significa che diventi imbecille per comprendere l'interfaccia della classe.

ma in java ci sono le interfacce
e cmq se invece di voler scrivere per forza con notepad usi un IDE decente hai tutto a disposizione senza troppi problemi, insomma questo non mi sembra un gran problema

[zello]

nella 1.5 ci sono le collection con i template

Sono tre o quattro anni che non uso java...
Resta che il paradigma ad oggetti è obbligatorio, così come la base comune, anche se questo ha alcuni vantaggi (l'intera idea di poter instanziare un oggetto dato il nome della sua classe espresso come stringa è fantastico per evitare le dipendenza da creazione).

Ribadisco che non mi piacciono i linguaggi con gc, perché il fatto di non sapere quando un oggetto viene distrutto mi impedisce comode tecniche di programmazione (almeno il c# ha un mezzo rimedio con using).

Inoltre, non mi sembra un linguaggio un granché flessibile. Mi spiego: in c++, ciò che non esiste nel linguaggio non è difficile da creare; le proprietà "alla c#" - cioé che chiamano in realtà metodi accessori - non ci sono, ma ci vuole poco ad aggiungerle:

Codice: Seleziona tutto

class A
{
public:
        class Property
        {
         public:
                Property(const std::string& value=""):m_value(value){}
                const std::string& operator=(const std::string& newvalue){
                          m_value=value;
                          //fa ciò che vuole
                          return m_value;
                }
                operator const std::string&()const{
                          return m_value;
                }
         private:
                std::string m_value;
        };
        Property stringa;
};


Questo vale anche per i delegates di c#, o per meccanismi di creazione tipo il Class.forName di java, o per altre diavolerie.
In java usi quello che c'è, il linguaggio è oggettivamente semplice, ma "estenderlo" è praticamente impossibile.

Infine: tutte le volte che ho usato java ho perso più tempo a navigare nella documentazione che a scrivere codice. Se non è cambiato nulla, le classi di sistema sono troppe, troppo legate, a volte sovrapposte, e di comprensione/utilizzo tutt'altro che semplice (JMHO).

Però "idiota" è troppo; "semplicistico", "limitante" e "rigido" rende più l'idea.

[numberinn]

Non importa come io esco dal main (con un return a metà, lanciando un'eccezione, arrivando fino in fondo), sono sicuro che il distruttore di A viene chiamato.In java non puoi fare nulla del genere (ed infatti sono previsti i blocchi finally, che in c++ non sono necessari).

C'è il garbage collector automatico e, comunque, puoi sempre richiamarlo quando ne hai voglia grazie ai metodi della classe "Runtime".

[zello]

C'è il garbage collector automatico e, comunque, puoi sempre richiamarlo quando ne hai voglia grazie ai metodi della classe "Runtime

Appunto, il lifetime degli oggetti non è deterministico.
Esempio: io ho una classe Mutex, con due membri lock e unlock. In c++ mi scriverei una classe "helper" Locker, del tipo

Codice: Seleziona tutto

class Locker
{
public:
      Locker(Mutex& mutex):m_mutex(mutex){
               mutex.lock();
      }
      ~Locker(){
               m_mutex.unlock();
      }
private:
      Mutex& m_mutex;
}


Per usarla poi in pezzi di codice come segue

Codice: Seleziona tutto

{
      Locker l(myMutex)
      ... altro codice che deve essere eseguito a myMutex acquisito
}


Quando si esce dal blocco di codice sopra - in qualunque maniera, eccezioni incluse - Locker esce di scope e viene distrutta, e il distruttore rilascia il lock su myMutex.
In java, con un'interfaccia di Mutex analoga, sono costretto a scrivere:

Codice: Seleziona tutto

{
     myMutex.lock()
     try{
           ...codice da eseguire
     }
     finally
     {
            myMutex.unlock();
     }
}


perché altrimenti, se uscissi con un'eccezione, non rilascerei il mutex.
Ovviamente, le cose sono equivalenti; tuttavia, se il tuo codice acquisisce risorse che è importante rilasciare ad un determinato momento, avere la certezza della distruzione di un oggetto è meglio che infarcire il codice di try...finally.
Peggio ancora è chiamare il garbage collector a mano, perché vanifichi il senso della gestione automatica della memoria.

[Mone]

Sincero non so quando è stato introdotto, cmq a proposito di lock, in Java c'è la parola chiave synchronized.
questo pezzo di codice prende il lock sull'oggetto myLock:

Codice: Seleziona tutto

synchronized(myLock) {
//codice da eseguire
}

Questo lock viene lasciato anche se dal blocco synchronized si esce in eccezione.

[zello]

syncronized c'è da sempre, ho preso il mutex solo come un esempio; il discorso può essere esteso a qualunque risorsa (connessioni a database, files, sockets, ciò che vuoi) tu voglia essere sicuro di rilasciare in un blocco di codice.
In java non ci sono distruttori, c'è finalize ma viene chiamato in un momento non predicibile. Questo costringe a rilasciare le risorse usando un apposito metodo (che so, FileInputReader.close() per chiudere un file) e non si può farlo nel distruttore, in maniera "automatica" (se alloco una variabile std::ifstream sullo stack, all'uscita di scope il file si chiude automaticamente).

[GAD]

C'e' sempre da tener presente lo scopo e il funzionamento della cosa, java e c# sono nati per essere imparati al volo e poter sviluppare velocemente senza porsi troppi problemi professionali.
Non per niente non si creano cose a basso livello ma si assemblano componenti prefabbricate già esistenti creando solo "un file di richiamo personalizzato". Quindi andare a sviluppare tutte le funzioni sport-pro andrebbe contro il senso dello sviluppo veloce e del linguaggio facile e senza problemi (nel senso che chi programma non se ne deve curare).
Se dovessero curarsi di tutti i dettagli tecnici perderebbero il loro scopo e si arriverebbe a creare solo un clone di c++, e non avrebbe senso avere un clone di una cosa che già esiste e funziona.

Zello, ma ti sta tanto su la programmazione ad oggetti?? a parte alcuni inconvenienti di serialization (tipo salvare in un database dove tocca mappare gli oggetti nelle variabili che li compongono) a me hanno sempre fatto comodo anche come metodo di ragionamento e rappresenzatione rispetto alla programmazione funzionale o lineare che mi pare gestibile agevolmente solo per programmi semplici e molto lineari (se ci metti dei thread e delle azioni async fa comodo organizzare ogni funzionalità a seconda di oggetti)

[zello]

java e c# sono nati per essere imparati al volo e poter sviluppare velocemente senza porsi troppi problemi professionali.

Mi sembra un po' la storia di VB (pre .net): è un linguaggio semplice, lo impari facilmente, e poi alla 5000a linea scopri che il linguaggio ha limiti tali che non riesci più a mantenere decentemente il programma. Non sto dicendo che java o c# siano giocattoli - io ci ho fatto cosine anche carine. Dico che - essendo poveri di costrutti - la volta che vuoi fare qualcosa di "particolare" diventi scemo. Il c++ - al di là di ciò che dicono - può essere semplice, a patto di non usare parti "complesse"; quello che manca, se vuoi, è una libreria a corredo che copra tutte le esigenze (come il framework .net o le librerie di sistema di java).

Zello, ma ti sta tanto su la programmazione ad oggetti??

No, assolutamente. Mi sta su dover per forza programmare ad oggetti, usare per forza il polimorfismo, essere costretto a reificare tutto quanto.
Se scarichi abuse, o se guardi winhash, noti che è impostato sostanzialmente ad oggetti. Però, se ho bisogno di una funzione che calcoli il minimo tra due valori, scrivo

Codice: Seleziona tutto

template<class T>
const T& min(const T& one, const T& two){return (one<two?one:two);}


Al massimo me lo piazzo in un namespace, non creo certo una classe.

[GAD]

Beh si, cmq sono limitazioni proprie del progetto e del suo scopo.
Se fai un linguaggio ad altissimo livello, facile da usare ed apprendere devi per forza non dare le preoccupazioni professionali che tu, da programmatore con esperienza, sei in grado di tirare fuori.
Il 90% dei personaggi che si avvicina userà gli strumenti senza mai incappare in casotti perche' non dovrà affrontare un settore troppo specifico(almeno e' quello che pensa chi produce)..il 10% invece si roderà il fegato quando incapperà nelle limitazioni,ma tutto ha limitazioni in qualche ambito, ovvio che ti incacchi a morte quando scopri la limitazione nel programma che stavi facendo tu.
Concordo che serve un ambiente piu' elastico per consentire di gestire anche cose non previste a basso livello, pero' il vero tecnico si vede anche dalle scelte che fa per sviluppare un determinato progetto.
Nel caso vb.net nativo ti va bene se lavori su un database o un gestionale ma se lo scegli per fare ad es. grafica professionale o programmi che si interfaccino con schede elettroniche a basso livello allora e' colpa del programmatore che doveva scegliere un linguaggio piu' adatto al progetto.
Per fortuna, se uno parte col piede sbagliato esistono quasi sempre dei trick per salvarsi il "sedile" come utilizzare una libreria scritta in altro linguaggio (tipo ocx in c++ ecc) ed utilizzarla come ponte tra il linguaggio ad alto livello ed il problema a basso livello.

Poi il life-motive del momento e' "uccidi i programmatori"... stanno tutti cercando di creare ambienti sempre piu' orientati al design in modo da costruire programmi in base a grafici uml senza scrivere codice... la teoria di dare alla scimmietta un mouse col quale trascinando componenti su un foglio possa creare applicazioni senza sapere cosa c'e' sotto.
Quindi programmazione castrata al massimo!

[zello]

la teoria di dare alla scimmietta un mouse col quale trascinando componenti su un foglio possa creare applicazioni senza sapere cosa c'e' sotto

La teoria dei circuiti integrati software ha qualche anno in più di me (dovrebbe essere saltata fuori nel 67) e non ha mai funzionato. Non è che a battezzarla .net o java improvvisamente si metterà a funzionare.

(poi è vero che a basso livello bisognerebbe andarci al minimo: ho perso una sera a cercare un incomprensibile bug in abuse, cambiando pure compilatore, per poi scoprire che:
- in un header avevo piazzato un #pragma pack(1) senza ristabilire l'allineamento con un #pragma pack()
- un file che includeva (indirettamente) l'header instanziava un template (allineando i campi al byte)
- un altro file reistanziava un template, il compiler utilizzava l'instanziazione precedente; ovviamente questo file non includeva l'header di cui sopra, si aspettava allineamenti alla DWORD e quindi bang appena cercavo di accedere a qualsiasi membro...)