Newsgroup: it.comp.programmare
Titolo: scelta del linguaggio di programmazione

Ciao a tutti.
Ho intenzione di imparare un nuovo linguaggio di programmazione.
Conosco un po' di C, un po' di OOP e Visual Basic (scusate l'accostamento).
Ho pensato di buttarmi sul Delphi, ma poi gli amici mi hanno detto che visto
il desiderio di passare ad un linguaggio ad oggetti potrei passare a Java.
Non so, non vorrei che questo successone in breve tempo di tale linguaggio
non si rivelasse poi un fuoco di paglia o comunque non finisse per essere
schiacciato in qualche modo dalla MS(che non sa piu' che fare per
contrastarlo...)
Ed il C++?
Voi che ne pensate?
E' ovvio che la scelta del linguaggio dipende da cio' che uno vuol fare, ma
mi chiarite la differenza/obiettivi fra i vari linguaggi?
Le leggi di mercato che dicono?
(PowerBuilder o Delphi sono molto meglio di Visual basic a mio parere,
eppure la maggioranza richiede visual basic...)
E il C# che ne pensate?
Grazie anticipatamente a coloro che vorranno rispondermi.

E il C# che ne pensate?
Tentativo implicito di zio Bill a creare un linguaggio assoluto.
Riprende alcune caratteristiche del C++ che sono ormai state eliminate
dallo stesso perché potenzialmente dannose e talvolta inutili.
Risulta essere un mescolamento tra Java e C++.
Personalmente credo che dovrà essere pompato ancora un po' prima che
qualcuno li dia un occhiata.
Ciao.
-- 
La classifica dei prodotti MS:
C#, la migliore barzelletta di Bill Gates.
Visual C++, il meno standard dei compilatori C++.
J++, la copiatura più riuscita.
Windows, il più instabile.
Visual Basic, un esempio di prodotto decente della MS - forse l'unico -.
OutlookExpress, scandali su scandali.
La classifica degli "amici" coglioni:
Stefano Zanchi, il miglior lamer del mondo.
 


personalmente ti consiglio il c++ non avrai da pentirtene
-- 
Ciao, gengisdave
http://digilander.iol.it/gengisdave
Linux Registered User    # 198292
Linux Registered Machine # 88280

 non ti interessi.
per esempio? ti va di essere piu' preciso? sono curioso!
Grazie! :-)
--
Ciao by Beppe

>per esempio? ti va di essere piu' preciso? sono curioso!
In molti casi non sono veri e propri problemi del linguaggio in se, ma
situazioni che molto spesso sfuggono al controllo del programmatore.
Alcuni esempi:
Pensa di avere due classi base con alcuni metodi virtuali e una derivata
che imlementa entrambe le classi:
class Base1 {
         public:
                 virtual void metodo() = 0;
};
class Base2 {
         public:
                 virtual void metodo() = 0;
};
class derivata: public Base1, Public Base2 {
         // definzione
};
int main(void) {
      derivata oggetto;
      return 0;
}
 
In questo caso il programmatore istanziando un oggetto di derivata non si
accorge che derivata ha ereditato due metodi virtuali "astratti", ovverro
privi di definizione, quindi il compilatore segnala errore.
In Java questo tipo di problema non accade sia perché si ha un ereditarietà
singola sia perché il compilatore forza la definizione delle interfaccie:
public interface interfaccia1 {
         public abstract void metodo();
}
public interfaccia2 {
         public abstract void metodo();
}
public class extends Object implements interfaccia1, interfaccia2 {
        public void metodo() {}
}
In questo caso se la classe non avesse riedefinito metodo il compilatore
avrebbe segnalato errore.
Ritornando all'esempio delle classi in C++:
class Base1 {
       public:
               virtual void metodo() = 0;
};
class Base2 {
       public:
              virtual int metodo() = 0;
};
class Base3: public Base1, public Base2 {
};
Per adesso è una sitazione lecita, ma nel momento che dovrò ridefinire
metodo otterrò un errore perché ho un overloding di funzioni membro
erratto. Come puoi ben capire non vengo a conoscenza di tale situazione
finché non dovrò utilizzare metodo.
Altro esempio:
class Base1 {
       protected:
                    void metodo() {}
};
class Base2 {
       protected:
                   int metodo() { return 0 }
};
class Base3: public Base2, public Base1 {
       // classe oggetto
};
int main(void) {
    using namespace std; 
     Base3 oggetto;
     cout << oggetto.metodo() << endl;
     return 0;
} 
L'ambiguità nasce perché non si sa a quale metodo si vuol fare riferimeto.
Con il risolutore di scope si risolve tale situazione, ma pensa se metodo
fosse stato ridefinito nella classe3. Ovviamente avremmo risolto la
situazione, ma logica che sta alla base della ridefinizione di un metodo è
quella di aggiungere qualcosa ai metodi con lo stesso nome di una
superclasse.
Come puoi vedere i metodi sono con signature differente ed è facilmente
intuibile che eseguono qualcosa di differente l'uno dall'altro. 
Con la ridefinizione, almeno che non vengano richiamati esplicitamente
entrambi, uno viene oscurato e non vi si potrà più farvi riferimento.
Questo argomento non lo approfondisco perché non vi è spazio, ma pensa come
è implementato il polimorfismo tra java e C++.
Si potrebbe anche pensare di utilizzare l'ereditarietà singola in C++, ma
ben presto questo modo di procedere, specialmente dopo aver acquisito una
maggiore capacità di programmazione, risulterà limitatitivo.
Java ha aggiunto le interfaccie che sono a ereditarietà privata e le classi
stesse possono definire i metodi di una o più interfaccie.
C++ può raggiungere tale livello utilizzando le classi e l'ereditarietà
multipla, ma ritorniamo ad alcuni dei problemi che ho citato in precedenza.
Detto questo bisogna anche aggiungere  che C++ possiede alcune
caratteristiche che il linguaggio Java non propone, come l'ereditarietà
pubblica, privata o protetta, i puntatori espliciti,.... ma secondo te è
proprio un OOP adatta per chi vuole iniziare?
E' vero che tutte le sitazioni di ambiguità possono essere evitate, anche
con modi poco ortodossi, ma può stufare un principiante che a lungo andare
preferirà adottare le soluzioni di altri linguaggi OOP -vedi Eiffel -,
anche se era partito con buoni propositi verso il C++.
Cmq il sig. James Gosling ha ampiamente motivato gli aspetti che Java ha
variato rispetto al suo predecessore C++ e penso che una buona lettura
possa chiarire le idee. 
Infatti credo che per curiosità andrò a leggerle anch'io.


è potentissima ma mal implementata e in molti casi può nauseare chi la fa.
??????????? Qualche esempio?
Anto

> ??????????? Qualche esempio?
Qualche esempio l'ho fatto nel messaggio di risposta a Pippo.
Cmq poco tempo fa sul newsgroup di Java c'è stata una lunga discussione e
si è parlato appunto dei problemi dell'ereditarietà  multipla a diamante
del C++. 
Inoltre in uno dei messaggi potrai trovare un link ad un sito dove il Sig.
James Gosling ha spiegato le sue motivazioni a riguardo con opportuni
esempi copiati dal sottoscritto e semplificato nel post precedente.
Personalmente non credo che abbia inventato Java alla carlona.
NB: mi riferivo alla OOP in quanto tale e non ad un eventuale aiuto fornito
tramite i template con la rispettiva programmazione generica.
Inoltre sono altri i punti di forza del C++  che altri linguaggi non
possiedo e conoscendoti non credo ch'io abbia bisogno di dirti quali.
PS: dato che siamo in argomento aggiungerei la nota che sono molti i
programmatori a considerare la OOP del C++ come vecchia e sorpassata e
preferiscono puntare su linguaggi come Delphi ed Eiffel.
Io non sono di questo parere, ma convengo che vi sono situazioni di
ambiguità che i suddetti linguaggi risolvono più elegantemente del C++.
Cmq ribadisco il concetto di imparare entrambi i linguaggi.


preferiscono puntare su linguaggi come Delphi ed Eiffel.
Non conosco Eiffel, però secondo me il supporto che Delphi offre
all'OOP deve ancora essere migliorato molto. L'esempio più
agghiacciante :-) è che l'utente deve chiamare esplicitamente
costruttori e distruttori. Inoltre non supporta l'ereditarietà
multipla che, pur portando molti problemi, a volte può essere molto
utile.
Ciao Anto

utile.
Teoricamente questo è vero ma la maggior parte delle volte può essere mal
implementata dal programmatore stesso, per quanto esperto sia.


implementata dal programmatore stesso, per quanto esperto sia.
E' vero, però preferisco averla a disposizione e non usarla che
doverla rimpiangere per un particolare progetto. Ricordati anche che
il C++ non è un linguaggio "balia" che impedisce all'utente di
sbagliare; fornisce delle funzionalità che possono essere sfruttate
bene oppure male, da lì in poi è compito del programmatore usarle
bene.
Cmq se ti interessa io ho realizzato il mio primo (e finora "quasi"
unico) programma OOP in Turbo Pascal 7 with objects e ho subito
sentito la mancanza dell'ereditarietà multipla.
ciao Anto

sentito la mancanza dell'ereditarietà multipla.
Io programmo anche in Java e dopotutto non sento la mancanza
dell'ereditarietà multipla.
Vabbé che tale linguaggio è decisamente superiore a molti suoi coetanei...


 costruttori e distruttori. 
E' agghiacciante anche la gestione degli oggetti "temporanei" che non 
vengono rilasciati (verificato e documentabile) ...

Vabbé che tale linguaggio è decisamente superiore a molti suoi coetanei...
Può darsi che il mio sia stato un errore di design ma mi avrebbe fatto
molto comodo.
Ho scritto un mini-framework per gestire una GUI con finestre, bottoni
e amenità varie. Avevo scritto una classe "container" (in C++ sarebbe
stato un template): tale classe si occupa di contenere altri widget al
suo interno, di disegnarli e di smistare loro gli eventi. La più ovvia
estensione di un container è stata quella di una finestra, e sin qui
niente di strano (ereditarietà singola). Quando poi ho dovuto scrivere
un controllo di tipo "frame" (contenitore di altri controlli) sono
iniziati i guai: infatti frame doveva derivare necessariamente da
"control" e quindi non poteva derivare anche da container; ho risolto
in maniera brutale con un copia-incolla da container verso frame, ma
non è quello che si dice riuso di codice... :-(
Anto