Il linguaggio più richiesto nel mondo del lavoro...

[WarDuck]

Originariamente inviato da carter100

Mi vergogno a chiederlo, ma non so a che ti riferisci...
A che ti riferisci?

In pratica sta dicendo che Microsoft offre più sicurezza di Oracle

[carter100]

Originariamente inviato da WarDuck

In pratica sta dicendo che Microsoft offre più sicurezza di Oracle

Ah ok, grazie

[marco.r]

Originariamente inviato da WarDuck

Io preferisco di gran lunga il C al C++...

Se devo programmare con un paradigma Object Oriented, tantovale buttarmi su Java.

In molti ambiti Java però è da escludere (così come altri linguaggi come il C#) per cui l'alternativa resta tra il C e il C++ (o cose più di nicchia come il Forth...).
Il problema piuttosto è che in alcuni casi (e.g. dispositivi embedded) la versione del compilatore è un vecchio gcc e per il C++ questo pesa negativamente.


In ogni caso stai approcciando il problema alla rovescia. Non è che "devi" programmare con un linguaggio OO e quindi scegli quello che devi scegliere... ma devi risolvere un certo problema e in base ai vincoli scegli il linguaggio che puoi usare... se poi è uno OO tanto meglio, ma quello viene dopo.

[fero86]

Originariamente inviato da carter100

Mi vergogno a chiederlo, ma non so a che ti riferisci...
A che ti riferisci?

a C#, un linguaggio di programmazione della piattaforma .NET prodotto da Microsoft. é un linguaggio molto potente e all'avanguardia, anche grazie alla piattaforma .NET. se vuoi dargli un'occhiata scarica Microsoft Visual C# 2008 Express, é gratuito (volendo c'é anche la release candidate della 2010).

Originariamente inviato da WarDuck

I vantaggi non derivano tanto dal linguaggio in se, quanto appunto dal paradigma OO che facilita molto un certo tipo di programmazione.

non necessariamente: é stato mostrato che la programmazione orientata agli oggetti di per se' non produce vantaggi significativi in termini di produttivitá rispetto alla programmazione procedurale.

io non stavo affatto parlando di programmazione orientata agli oggetti, stavo parlando solo di C++, che tra l'altro fornisce una sua peculiare interpretazione della programmazione orientata agli oggetti. il C++ permette di essere piu produttivi del C perché offre costrutti piu potenti che permettono di scrivere programmi piu significativi a paritá di numero di linee di codice.

Tuttavia se devo programmare OO forse è il caso di pensare a linguaggi più evoluti tipo Java o C#.

come ti ha spiegato marco.r, uno non é che "deve programmare OO"; uno deve risolvere un problema molto pratico che non ha nulla a che vedere con la programmazione orientata agli oggetti, e per farlo ha a disposizione un determinato insieme di strumenti tra cui forse anche linguaggi orientati agli oggetti.

E' chiaro che il tuo compromesso è una certa perdita di efficienza

premettiamo che le questioni di performance non sono legate ai linguaggi di per se', che sono solo specifiche di sintassi, semantica e spesso librerie predefinite.

detto questo esistono alcuni linguaggi che favoriscono la performance e per i quali esistono implementazioni intrinsecamente piu performanti; per esempio la specifica del linguaggio Java impone la semantica del bound checking sugli array e questo causa necessariamente una perdita di performance che invece non caratterizza linguaggi non gestiti come C e C++.

ció posto le performances finali dei programmi risultanti dalla compilazione di questi linguaggi sono in generale una questione piu complessa di come la fai tu e le tue affermazioni non sono valide nel caso generale. nel caso generale un programma Java puó essere molto piu performante di un programma scritto in C++, ad esempio perché rimanda la deallocazione della memoria dinamica a momenti di maggiore disponibilitá di risorse di calcolo.

Appena ho un po' di tempo inoltre mi piacerebbe dare un'occhiata a Go, il linguaggio di programmazione di Google.

e a me?

Originariamente inviato da WarDuck

In pratica sta dicendo che Microsoft offre più sicurezza di Oracle

non proprio visto che il post di PGI-Bis aveva senso mentre questa frase non ne ha.

[WarDuck]

Originariamente inviato da fero86

[..]
non necessariamente: é stato mostrato che la programmazione orientata agli oggetti di per se' non produce vantaggi significativi in termini di produttivitá rispetto alla programmazione procedurale.

Ho forti dubbi su questo.

Originariamente inviato da fero86

io non stavo affatto parlando di programmazione orientata agli oggetti, stavo parlando solo di C++, che tra l'altro fornisce una sua peculiare interpretazione della programmazione orientata agli oggetti. il C++ permette di essere piu produttivi del C perché offre costrutti piu potenti che permettono di scrivere programmi piu significativi a paritá di numero di linee di codice.

Tutte le cose che potrebbero veramente facilitarmi la vita in C potrebbero essere implementate usando paradigmi object oriented, che di fatto rappresenta una delle caratteristiche fondamentali che fanno la differenza tra C e C++ (insieme ai template forse).

Originariamente inviato da fero86

come ti ha spiegato marco.r, uno non é che "deve programmare OO"; uno deve risolvere un problema molto pratico che non ha nulla a che vedere con la programmazione orientata agli oggetti, e per farlo ha a disposizione un determinato insieme di strumenti tra cui forse anche linguaggi orientati agli oggetti.

Non ho mai detto il contrario.

Ho detto che preferisco C come linguaggio rispetto a C++.

Perché è più semplice, più "elementare" forse nei costrutti che offre (nonostante il suo essere di più basso livello).

E visto che di fatto una delle caratteristiche più rilevanti di C++ è il supportare la programmazione ad oggetti, ho fatto presente che in questo contesto esistono linguaggi più evoluti.

Originariamente inviato da fero86

premettiamo che le questioni di performance non sono legate ai linguaggi di per se', che sono solo specifiche di sintassi, semantica e spesso librerie predefinite.

Anche qui non ho mai detto il contrario, pensavo fosse ovvio che mi riferissi alle implementazioni.

Originariamente inviato da fero86

detto questo esistono alcuni linguaggi che favoriscono la performance e per i quali esistono implementazioni intrinsecamente piu performanti; per esempio la specifica del linguaggio Java impone la semantica del bound checking sugli array e questo causa necessariamente una perdita di performance che invece non caratterizza linguaggi non gestiti come C e C++.

ció posto le performances finali dei programmi risultanti dalla compilazione di questi linguaggi sono in generale una questione piu complessa di come la fai tu e le tue affermazioni non sono valide nel caso generale. nel caso generale un programma Java puó essere molto piu performante di un programma scritto in C++, ad esempio perché rimanda la deallocazione della memoria dinamica a momenti di maggiore disponibilitá di risorse di calcolo.

E' ovvio che se dovessimo stare qui a snocciolare per filo e per segno tutti i vari aspetti prestazionali, a partire dal processo di compilazione fino all'esecuzione a runtime non la finiremmo più.

Tuttavia ogni qualvolta mi sono trovato davanti ad un programma Java, magari con relativa GUI, mi ha sempre dato l'impressione di non essere granché reattivo (quantomeno sotto Windows).

Magari mi ha detto sfiga...

Originariamente inviato da fero86

e a me?

Originariamente inviato da fero86

non proprio visto che il post di PGI-Bis aveva senso mentre questa frase non ne ha.

Rileggi bene il suo post allora .

[fero86]

Originariamente inviato da WarDuck

Ho forti dubbi su questo.

ti linko il documento che descrive lo studio a cui mi riferivo, c'é l'ho tra i preferiti perché é bellissimo
http://www.csm.ornl.gov/~v8q/Homepag...0printable.pdf

Tutte le cose che potrebbero veramente facilitarmi la vita in C potrebbero essere implementate usando paradigmi object oriented,

a quali cose ti riferisci?

Non ho mai detto il contrario.

hai detto:

Tuttavia se devo programmare OO forse è il caso di pensare a linguaggi più evoluti tipo Java o C#.

ma, a meno che tu non stia lavorando per un esame, non ti si presenterá mai la necessitá stretta di fare programmazione orientata agli oggetti, nessuno viene a pagarti per chiederti di scrivere un programma qualunque che peró sia orientato agli oggetti. i clienti ti pagano per avere un programma che esegue determinati compiti, e questo per te é un problema che puoi risolvere con un determinato insieme di strumenti tra cui forse anche linguaggi orientati agli oggetti.

Ho detto che preferisco C come linguaggio rispetto a C++.

la tua preferenza non ha senso perché grossomodo il C++ non toglie nulla al C, ma piuttosto aggiunge costrutti utili che ti aiutano ad accorciare il codice, a volte di molto.

(nonostante il suo essere di più basso livello).

il C non é di piu basso livello del C++: anche in C++ puoi lavorare su ogni singolo byte di memoria accessibile, provocare buffer overflow, accedere alle API dei sistemi operativi odierni, ecc.

E visto che di fatto una delle caratteristiche più rilevanti di C++ è il supportare la programmazione ad oggetti, ho fatto presente che in questo contesto esistono linguaggi più evoluti.

non lo nego, e per tutta risposta faccio presente che non sempre sono delle alternative.

Anche qui non ho mai detto il contrario, pensavo fosse ovvio che mi riferissi alle implementazioni.

non pensarlo su un forum come questo perché gente come cdimauro é in grado di flammare per giorni su "piccolezze" del genere.

E' ovvio che se dovessimo stare qui a snocciolare per filo e per segno tutti i vari aspetti prestazionali, a partire dal processo di compilazione fino all'esecuzione a runtime non la finiremmo più.

d'altra parte non possiamo neanche stare a scrivere le cazzate indimostrabili che senti in corridoio: qualche principiante inesperto potrebbe berle.

Rileggi bene il suo post allora .

che dire, a me continua a sembrare sensatissimo.

[Tommo]

C++ serve quando serve un linguaggio di alto livello che sia anche veloce.

Farà schifo quanto vi pare, ha una tonnellata di bugs, ma ha un qualsiasi senso valutare la produttività a livello assoluto?
Io per esempio ormai lo uso da anni e faccio molto più e meglio con C++ che con altro.

Inoltre, valutare il "linguaggio" non ha alcun senso, andrebbero valutate anche le librerie... e il C++ è molto gettonato ad alti livelli perchè ha librerie "coi controcazzi" per circa tutto quello che può essere programmato

Poi certo, per lavoro sicuramente il più usato è Java.
Ma credo che non siano posti di lavoro qualificati quanto quei pochi C++, proprio no.
Infatti quel sondaggio TIOBE a pensarci bene è ben stupido, sarebbe come dire che il miglior mestiere è l'operaio perchè lo fanno tutti e gli altri sono inutili perchè ce ne sono pochi

PS&OT: nonostante questo C++ è veramente una brutta bestia per il threading avanzato... c'è qualche linguaggio che offra un parallelismo task-based di fabbrica?
In C++ per quanto mi impegno viene brutto lento e poco flessibile.

[fero86]

Originariamente inviato da Tommo

Farà schifo quanto vi pare, ha una tonnellata di bugs,

bugs? in un linguaggio?
semmai in un solo specifico compilatore, ma a me non sembra di vederne da decenni... l'ultima volta che mi é crashato il compilatore Microsoft é stato quando usavo Visual C++ 6, fine anni '90.

ma ha un qualsiasi senso valutare la produttività a livello assoluto?
Io per esempio ormai lo uso da anni e faccio molto più e meglio con C++ che con altro.

questo discorso mi piace molto
(non ironico)

Inoltre, valutare il "linguaggio" non ha alcun senso, andrebbero valutate anche le librerie... e il C++ è molto gettonato ad alti livelli perchè ha librerie "coi controcazzi" per circa tutto quello che può essere programmato

si per se' non é che abbia granché, le librerie a cui ti riferisci sono perlopiu di terze parti. il fatto é che il C++ non ha una piattaforma, al contrario di Java e dei linguaggi .NET, perché é fatto per altri scopi: é fatto per stare al di sopra di altre piattaforme, come Win32/COM.

Infatti quel sondaggio TIOBE a pensarci bene è ben stupido, sarebbe come dire che il miglior mestiere è l'operaio perchè lo fanno tutti e gli altri sono inutili perchè ce ne sono pochi

veramente TIOBE non mi sembra dire questo: mi sembrano molto chiari nel loro operato, loro creano semplicemente la statistica dei linguaggi di cui si parla di piu nel web, che poi non é detto che siano i migliori ma presumibilmente sono i piu usati.

[WarDuck]

Originariamente inviato da fero86

ti linko il documento che descrive lo studio a cui mi riferivo, c'é l'ho tra i preferiti perché é bellissimo
http://www.csm.ornl.gov/~v8q/Homepag...0printable.pdf

Rispondo solo ora che sono stato un po' impicciato oggi...

Appena ho del tempo lo leggerò, ad ogni modo ci sarebbe ancora da chiedersi allora come mai il paradigma OO ha preso piede rapidamente.

In realtà mi sembra evidente che il suo avvicinarsi più all'utente che alla macchina possa rendere liberi di concentrarsi sul problema piuttosto che sulla pura implementazione.

Originariamente inviato da fero86

a quali cose ti riferisci?

Tanto per incominciare le collections, l'accesso ai files e ai vari stream di I/O... poter creare nuovi tipi e controllarne l'accesso, la possibilità di poter usare ereditarietà e polimorfismo che in alcuni casi sono una manna dal cielo.

Magari anche per implementare un certo tipo di type safety (ma questo credo si possa fare anche senza costrutti OO).

Ogni volta che leggo cose tipo 1+true = 2 inorridisco.

Originariamente inviato da fero86

hai detto:
ma, a meno che tu non stia lavorando per un esame, non ti si presenterá mai la necessitá stretta di fare programmazione orientata agli oggetti, nessuno viene a pagarti per chiederti di scrivere un programma qualunque che peró sia orientato agli oggetti. i clienti ti pagano per avere un programma che esegue determinati compiti, e questo per te é un problema che puoi risolvere con un determinato insieme di strumenti tra cui forse anche linguaggi orientati agli oggetti.

Infatti ho detto "SE devo programmare OO", nel senso "SE ho bisogno di programmare usando il paradigma OO".

C'è un SE davanti, non ho mai detto che DEVO farlo per forza.

Originariamente inviato da fero86

la tua preferenza non ha senso perché grossomodo il C++ non toglie nulla al C, ma piuttosto aggiunge costrutti utili che ti aiutano ad accorciare il codice, a volte di molto.

Adesso sono io che lo chiedo a te: tipo (OO escluso, quindi anche cose derivanti da esso)?

Ed in ogni caso è il come lo fa il problema.

Originariamente inviato da fero86

il C non é di piu basso livello del C++: anche in C++ puoi lavorare su ogni singolo byte di memoria accessibile, provocare buffer overflow, accedere alle API dei sistemi operativi odierni, ecc.

Si qui hai ragione mi sono spiegato male io.

Intendo dire che C++ offre dei costrutti più complicati, di più alto livello, rispetto a C.

Originariamente inviato da fero86

non pensarlo su un forum come questo perché gente come cdimauro é in grado di flammare per giorni su "piccolezze" del genere.

Io invece credo che a volte ci si sforzi di NON voler capire, o si faccia finta, non si sa bene per quale motivo, forse per deformazione professionale.

Originariamente inviato da fero86

d'altra parte non possiamo neanche stare a scrivere le cazzate indimostrabili che senti in corridoio: qualche principiante inesperto potrebbe berle.

Se per questo tu hai solo citato un aspetto, che è quello della deallocazione di memoria fatta dal garbage collector, che di fatto E' SOLO UN ASPETTO.

Cmq tralasciando l'aspetto prestazionale, che non è oggetto né del topic né della mia considerazione iniziale, quello che voglio dire è che mi piacerebbe poter disporre di un linguaggio basato su C ma rivisto con una sintassi possibilmente lontana anni luce da quella che il C++ usa per implementare l'OO, in tal senso esprimevo la mia curiosità su Go.

[Tommo]

Originariamente inviato da fero86

*cut*

Come "bugs" intendo parti contrastanti, imprecise, indefinite nella specifica e nei maggiori compilatori cioè MSVC e g++...
e di quelle ce ne sono un fottio se vai a mettere il naso dove il C++ non dovrebbe.

Che so, template + funzioni virtuali? Multiple inheritance? Singleton usate da una DLL? Reflection? 1+true?
Le menate che il C++ ti tira addosso sono tantissime, inutile nasconderlo.
E dopo aver tentato per parecchio di abbatterle sono giunto alla conclusione che è meglio lasciar stare il can che dorme

PS: se le librerie sono di terze parti non m'importa, tantissime sono gratis e tantissime fanno cose che in altri linguaggi dovresti fare meno efficientemente nel caso migliore, e rifarle da 0 in quello peggiore.
Basta dare un occhiata al campo dei giochi, XNA su Xbox sta stretto pure agli indie.

PPS @warduck: non mi viene proprio in mente una possibile applicazione moderna che possa davvero essere realizzata con paradigma imperativo... quindi il SE si può benissimo togliere per quanto riguarda dei progetti reali.

[carlito9987]

Ciao a tutti, lavoro da ormai 3 anni nel mondo dell'informatica e posso dirvi che, a mio parere non c'è un linguaggio in assoluto più utilizzato.
Sicuramente conoscere bene C è un gran vantaggio, dato che in molte aziende unix è pane quotidiano!

Tuttavia non possiamo dire di certo che è il più utilizzato, personalmente ora nella mia azienda vedo molte richieste su .NET e java. Conoscere però dei linguaggi di programmazione non è sicuramente la cosa migliore, siamo nell'era della Business Intelligence.... conoscere Business Objects, SAP o anche i vari CRM ti facilita sicuramente la ricerca del lavoro!

Ovviamente tengo a precisare che questo è solo un mio parere.... Buona giornata a tutti!

[fero86]

Originariamente inviato da WarDuck

Appena ho del tempo lo leggerò, ad ogni modo ci sarebbe ancora da chiedersi allora come mai il paradigma OO ha preso piede rapidamente.

che c'entra, anche quello procedurale ha preso piede rapidamente

In realtà mi sembra evidente che il suo avvicinarsi più all'utente che alla macchina

opinabilissimo: l'utente é una cosa completamente ignota e misteriosa.

possa rendere liberi di concentrarsi sul problema piuttosto che sulla pura implementazione.

questa non é neanche lontanamente una caratteristica intrinseca della programmazione orientata agli oggetti. un linguaggio procedurale puó essere di altissimo livello ed astrarre completamente da puntatori, allocazioni dinamiche di memoria e tutto quello che di implementativo ti possa venire in mente. anche JavaScript, per dire, puó essere usato in maniera procedurale.

Infatti ho detto "SE devo programmare OO", nel senso "SE ho bisogno di programmare usando il paradigma OO".

C'è un SE davanti, non ho mai detto che DEVO farlo per forza.

c'é una differenza tra il non doverlo fare per forza e il non doverlo fare mai...

Adesso sono io che lo chiedo a te: tipo (OO escluso, quindi anche cose derivanti da esso)?

perché escludi la programmazione orientata agli oggetti? il mio discorso non la esclude.
per il resto potremmo metterci i templates e i tipi reference, specialmente i primi. volendo, in un certo senso, potremmo metterci anche i namespaces. con l'ultima revisione poi ovviamente ci mettiamo anche le espressioni lambda, che accorciano tantissimo. altro non mi viene in mente; ci sarebbe il foreach ma la Microsoft non l'ha (ancora?) implementato, forse perché neanche serve considerando la funzione for_each e le lambda expressions.

Ed in ogni caso è il come lo fa il problema.

giusto, infatti anche Visual Basic 6 se é per questo introduceva la programmazione a oggetti. qualche argomentazione utile a riguardo?

Io invece credo che a volte ci si sforzi di NON voler capire, o si faccia finta, non si sa bene per quale motivo, forse per deformazione professionale.

sacrosanta deformazione professionale. le persone vanno trattate come computers: vanno fatte funzionare, altrimenti sono inutili.

Se per questo tu hai solo citato un aspetto, che è quello della deallocazione di memoria fatta dal garbage collector, che di fatto E' SOLO UN ASPETTO.

e infatti l'ho citato solo a titolo esemplificativo, e non c'é bisogno di gridare

Cmq tralasciando l'aspetto prestazionale, che non è oggetto né del topic né della mia considerazione iniziale, quello che voglio dire è che mi piacerebbe poter disporre di un linguaggio basato su C ma rivisto con una sintassi possibilmente lontana anni luce da quella che il C++ usa per implementare l'OO, in tal senso esprimevo la mia curiosità su Go.

se vuoi c'é anche l'Objective C... vedi tu se conveniva allontanarsi anni luce dalla sintassi del C++

[Gold]

Originariamente inviato da khelidan1980

mah mi sa che in italia l'altra metà del cielo diventa 1/4, la situazione di java sul mercato italiano non penso cambierà di molto considerando la staticità delle aziende nostrane,io lavoro per una grossa banca italiana( forse la più grossa mi dicono ) e ora stanno passando da cobol a java, usare java 1.4 è già un lusso,e così è per tutto il panorama bancario, poi in altri campi non so, ma quì mi sa che java avrà vita lunga, molto lunga

Ehi khelidan, non e' che questa grossa banca ha a che far con la nazione ed il lavoro?

Mi sembra d'averla gia' vista uesta situazione...

Saluto

[WarDuck]

Originariamente inviato da fero86

che c'entra, anche quello procedurale ha preso piede rapidamente

Come che c'entra, c'entra perché ognuno di questi paradigmi ha migliorato il modo di intendere la programmazione rispetto al momento in cui è stata introdotta, facilitando il compito soprattutto al programmatore.

Altrimenti staremmo ancora a programmare con 0 e 1.

Originariamente inviato da fero86

opinabilissimo: l'utente é una cosa completamente ignota e misteriosa.

Originariamente inviato da fero86

questa non é neanche lontanamente una caratteristica intrinseca della programmazione orientata agli oggetti. un linguaggio procedurale puó essere di altissimo livello ed astrarre completamente da puntatori, allocazioni dinamiche di memoria e tutto quello che di implementativo ti possa venire in mente. anche JavaScript, per dire, puó essere usato in maniera procedurale.

Non ci vedo nulla di opinabile sul fatto che la programmazione orientata agli oggetti aiuti a descrivere meglio molte tipologie di problemi reali.

Cmq si hai ragione sul fatto che si possano usare linguaggi procedurali di alto livello.

Originariamente inviato da fero86

perché escludi la programmazione orientata agli oggetti? il mio discorso non la esclude.

Perché ti avevo appena finito di dire che mi fa cacare la sua sintassi per gestire l'OO

Ed è di fatto la cosa che giustifica maggiormente il passaggio da C a C++, nonostante:

Originariamente inviato da fero86

per il resto potremmo metterci i templates e i tipi reference, specialmente i primi. volendo, in un certo senso, potremmo metterci anche i namespaces. con l'ultima revisione poi ovviamente ci mettiamo anche le espressioni lambda, che accorciano tantissimo. altro non mi viene in mente; ci sarebbe il foreach ma la Microsoft non l'ha (ancora?) implementato, forse perché neanche serve considerando la funzione for_each e le lambda expressions.

Sui template sono ovviamente d'accordo, del resto già l'avevo detto io.

Metti queste cose al C, poi... era tanto difficile non fare una sintassi così schifosa per le classi?

Originariamente inviato da fero86

giusto, infatti anche Visual Basic 6 se é per questo introduceva la programmazione a oggetti. qualche argomentazione utile a riguardo?

Non ho mai programmato in Visual Basic 6, ho provato col .NET, ma devo dire che non mi piace molto il linguaggio.

Originariamente inviato da fero86

sacrosanta deformazione professionale. le persone vanno trattate come computers: vanno fatte funzionare, altrimenti sono inutili.

Le persone NON sono computer. Le persone dovrebbero avere l'intelligenza di capire di cosa si sta parlando anche senza dovergli specificare tutto per filo e per segno.

Soprattutto su un forum pubblico, per quanto di nicchia possa essere questa sezione è accessibile al pubblico, non dovrebbe essere vista solo come un circolo privato destinata a pochi eletti.

Originariamente inviato da fero86

se vuoi c'é anche l'Objective C... vedi tu se conveniva allontanarsi anni luce dalla sintassi del C++

No grazie .

[cdimauro]

Originariamente inviato da WarDuck

Appena ho un po' di tempo inoltre mi piacerebbe dare un'occhiata a Go, il linguaggio di programmazione di Google.

Ne approfitto per fare un po' di spam.

Originariamente inviato da fero86

non necessariamente: é stato mostrato che la programmazione orientata agli oggetti di per se' non produce vantaggi significativi in termini di produttivitá rispetto alla programmazione procedurale.

io non stavo affatto parlando di programmazione orientata agli oggetti, stavo parlando solo di C++, che tra l'altro fornisce una sua peculiare interpretazione della programmazione orientata agli oggetti. il C++ permette di essere piu produttivi del C perché offre costrutti piu potenti che permettono di scrivere programmi piu significativi a paritá di numero di linee di codice.

Se i vantaggi della programmazione a oggetti vengono meno, tolte le classi al C++ non rimane molto di significativo. E l'uso delle macro del C potrebbe sopperire a un altro utile strumento: i template.

premettiamo che le questioni di performance non sono legate ai linguaggi di per se', che sono solo specifiche di sintassi, semantica e spesso librerie predefinite.

detto questo esistono alcuni linguaggi che favoriscono la performance e per i quali esistono implementazioni intrinsecamente piu performanti; per esempio la specifica del linguaggio Java impone la semantica del bound checking sugli array e questo causa necessariamente una perdita di performance che invece non caratterizza linguaggi non gestiti come C e C++.

Non necessariamente. Non dimentichiamoci che Java ha un compilatore JIT che ottimizza il codice a runtime, e può modificare il compilato in base alle informazioni raccolte dal profiler. Ad esempio rimuovendo il controllo sugli indici degli array se si accorge che l'accesso è "safe".

Originariamente inviato da WarDuck

E' ovvio che se dovessimo stare qui a snocciolare per filo e per segno tutti i vari aspetti prestazionali, a partire dal processo di compilazione fino all'esecuzione a runtime non la finiremmo più.

Tuttavia ogni qualvolta mi sono trovato davanti ad un programma Java, magari con relativa GUI, mi ha sempre dato l'impressione di non essere granché reattivo (quantomeno sotto Windows).

Magari mi ha detto sfiga...

Questo non depone a sfavore di Java, ma della libreria che viene utilizzata per implementare le GUI.

Java, con JNI, può benissimo accedere alle API native per le GUI esposte dal s.o. su cui gira.

Sarebbe interessante vedere all'opera una GUI realizzata in Java, ma con le API Win32.

Originariamente inviato da fero86

ti linko il documento che descrive lo studio a cui mi riferivo, c'é l'ho tra i preferiti perché é bellissimo
http://www.csm.ornl.gov/~v8q/Homepag...0printable.pdf

Non mi sembra uno studio generale. Magari per quei progetti ha dato maggior frutti la programmazione procedurale, ma questo non dimostra che è sempre preferibile a quella a oggetti.

In realtà non potrà mai esserci nessuna dimostrazione formale della maggior produttività di un paradigma rispetto a un altro.

Poi ci sarebbe da tener conto della varietà di implementazioni possibili.

non pensarlo su un forum come questo perché gente come cdimauro é in grado di flammare per giorni su "piccolezze" del genere.

Purtroppo capita di avere a che fare con utenti testardi, che proprio per il fatto di discutere di piccolezze la tirano per le lunghe, quando basterebbe fermarsi alle definizioni (presentate).

Fortunatamente noto che le lezioni servono, visto che adesso vedo parlare correttamente di linguaggi in termini di sintassi e semantica.

Originariamente inviato da Tommo

C++ serve quando serve un linguaggio di alto livello che sia anche veloce.

Farà schifo quanto vi pare, ha una tonnellata di bugs, ma ha un qualsiasi senso valutare la produttività a livello assoluto?
Io per esempio ormai lo uso da anni e faccio molto più e meglio con C++ che con altro.

E non è un giudizio "assoluto" anche questo?

Inoltre, valutare il "linguaggio" non ha alcun senso, andrebbero valutate anche le librerie... e il C++ è molto gettonato ad alti livelli perchè ha librerie "coi controcazzi" per circa tutto quello che può essere programmato

Puoi avere tutte le librerie che vuoi (e devi anche conoscerle, e averle a disposizione, tra l'altro), ma certe cose si fanno più velocemente con altri linguaggi.

PS&OT: nonostante questo C++ è veramente una brutta bestia per il threading avanzato... c'è qualche linguaggio che offra un parallelismo task-based di fabbrica?

In C++ per quanto mi impegno viene brutto lento e poco flessibile.

Ma come, non c'erano librerie "coi controzzi" per tutto?

Originariamente inviato da WarDuck

Ogni volta che leggo cose tipo 1+true = 2 inorridisco.

In Python puoi farlo. Il tipo bool discende direttamente da int.

Ed è una cosa che non apprezzo, perché avrei preferito un tipo a sé stante, come in Pascal, e la relative bacchettate sulle mani mischiandoli con altri tipi.

Il problema è che Python non ha mai avuto un tipo booleano, perché non ne ha mai avuto bisogno (esistono piuttosto espressioni che possono essere logicamente "vere" o "false").

Per tradizione, molti programmatori hanno definito due variabili allo scopo (true/True/TRUE e false/False/FALSE) assegnando loro i valori 1 e 0 rispettivamente.

Così, diversi anni dopo, sono stati introdotti i simboli (con Python 3.x sono diventate keyword) True e False negli oggetti built-in standard, facendoli discendere da int in modo da preservare la compatibilità con le applicazioni già esistenti.

Originariamente inviato da fero86

questa non é neanche lontanamente una caratteristica intrinseca della programmazione orientata agli oggetti. un linguaggio procedurale puó essere di altissimo livello ed astrarre completamente da puntatori, allocazioni dinamiche di memoria e tutto quello che di implementativo ti possa venire in mente. anche JavaScript, per dire, puó essere usato in maniera procedurale.

Io direi piuttosto che Javascript può essere usato in maniera a oggetti.

se vuoi c'é anche l'Objective C... vedi tu se conveniva allontanarsi anni luce dalla sintassi del C++

Che c'entra. L'Objective-C mica ha abbandonato la sintassi del C. Ha "semplicemente" aggiunto le classi.

Originariamente inviato da WarDuck

Metti queste cose al C, poi... era tanto difficile non fare una sintassi così schifosa per le classi?

Ringrazia Stroustrup e dai un'occhiata a Objective-C e Perl.

[fero86]

Originariamente inviato da WarDuck

Come che c'entra, c'entra perché ognuno di questi paradigmi ha migliorato il modo di intendere la programmazione rispetto al momento in cui è stata introdotta, facilitando il compito soprattutto al programmatore.

Altrimenti staremmo ancora a programmare con 0 e 1.

ma se fosse una questione di tempo adesso dovremmo programmare usando solamente il paradigma funzionale (che sta prendendo piede), mentre invece se si programma in F# lo si usa congiuntamente a quello a oggetti.

Non ci vedo nulla di opinabile sul fatto che la programmazione orientata agli oggetti aiuti a descrivere meglio molte tipologie di problemi reali.

io si visto che é una affermazione soggettiva ("molte") e che non si puó dimostrare formalmente nel caso generale.

Perché ti avevo appena finito di dire che mi fa cacare la sua sintassi per gestire l'OO

in tal caso quando dici di preferire il C al C++ solo per una religiosa questione di gusti (poco sensata poi visto che come aspetto le sintassi dei due linguaggi si somigliano) specificalo subito che si evita di perdere tempo a discutere con uno che fa dell'informatica una questione di gusti. o magari, sapendolo prima, ti rispondo che per una pura questione di gusti a me piace un casino il Brainfuck.

Ed è di fatto la cosa che giustifica maggiormente il passaggio da C a C++, nonostante:

non per me.

Metti queste cose al C, poi... era tanto difficile non fare una sintassi così schifosa per le classi?

de gustibus non disputandum est: per me quella sintassi rulla un casino, e allora?
e comunque io non userei l'aspetto "estetico" della sintassi di un linguaggio come motivazione per non usarlo.

Non ho mai programmato in Visual Basic 6, ho provato col .NET, ma devo dire che non mi piace molto il linguaggio.

mi sono espresso col culo
riformulo meglio: giusto, infatti per esempio anche Visual Basic 6 diceva di essere un linguaggio a oggetti, ma naturalmente oggi ci viene da ridere.
quindi, visto che come dici tu c'é modo e modo di aggiungere costrutti ad un linguaggio, hai qualche argomentazione utile riguardo il modo in cui lo fa il C++ (nei confronti del C ovviamente)? sottintendevi forse qualche aspetto negativo di qualche costrutto del C++?
tralasciando peró l'aspetto estetico della sintassi per favore (vedi sopra).

Le persone NON sono computer. Le persone dovrebbero avere l'intelligenza di capire di cosa si sta parlando anche senza dovergli specificare tutto per filo e per segno.

dallo per scontato e non otterrai mai niente di buono dall'altro. se non "specifichi tutto per filo e per segno", cioé se non dai all'altro specifiche ben precise, l'altro (oltre a lamentarsi della carenza di specifiche, magari pure a posteriori) potrebbe interpretare fantasiosamente.

Soprattutto su un forum pubblico, per quanto di nicchia possa essere questa sezione è accessibile al pubblico, non dovrebbe essere vista solo come un circolo privato destinata a pochi eletti.

non vedo alcun nesso con le frasi precedenti...

No grazie .

non ti si capisce molto, lo sai? adesso non ti piace l'Objective C? e allora perché ti lamenti del C++? sono due linguaggi diversi che con due sintassi diverse aggiungono la programmazione a oggetti al C, e non te ne va bene nemmeno uno. peró dici che non era per niente difficile fare una sintassi che invece ti aggradasse esteticamente. a me sembri un incontentabile, e chi scrive le specifiche di un linguaggio non puó certo stare appresso ai tuoi capricci.

Originariamente inviato da cdimauro

Se i vantaggi della programmazione a oggetti vengono meno, tolte le classi al C++ non rimane molto di significativo. E l'uso delle macro del C potrebbe sopperire a un altro utile strumento: i template.

restano i tipi reference e le lambda expressions. i tipi reference accorciano il codice perché i riferimenti sono sempre validi (non sono mai nulli o "dangling") e quindi non devi fare controlli, e i vantaggi delle lambda expressions mi sembrano evidenti.

Non necessariamente. Non dimentichiamoci che Java ha un compilatore JIT che ottimizza il codice a runtime,

rettifica: una sua particolare implementazione ce l'ha

e può modificare il compilato in base alle informazioni raccolte dal profiler. Ad esempio rimuovendo il controllo sugli indici degli array se si accorge che l'accesso è "safe".

evitiamo di inventarci altre chimere, lo fa o non lo fa? io non lo so.
se non lo fa evitiamo di parlarne in astratto perché la fattibilitá di un software non é mai garantita al 100% finché quel software non lo sviluppi e non finisci effettivamente nei vicoli ciechi in cui ti porta.

Questo non depone a sfavore di Java, ma della libreria che viene utilizzata per implementare le GUI.

e che ne sai che nei programmi usati da WarDuck la performance penalty era causata dalla GUI? hai fatto il profiling di tutti quanti?

Sarebbe interessante vedere all'opera una GUI realizzata in Java, ma con le API Win32.

AWT su Windows usa quelle.

Non mi sembra uno studio generale. Magari per quei progetti ha dato maggior frutti la programmazione procedurale, ma questo non dimostra che è sempre preferibile a quella a oggetti.

certo, peró costituisce un controesempio per l'affermazione inversa: la programmazione a oggetti non é sempre preferibile a quella procedurale (che é quello che volevo dire inizialmente a WarDuck).

Fortunatamente noto che le lezioni servono, visto che adesso vedo parlare correttamente di linguaggi in termini di sintassi e semantica.

per inciso, non mi rimangio nulla di quello che ho scritto quella volta: sono ancora dell'idea che, vista la situazione attuale, non sia affatto possibile programmare drivers per Windows in C++.

Che c'entra. L'Objective-C mica ha abbandonato la sintassi del C. Ha "semplicemente" aggiunto le classi.

non ho capito
neanche il C++ l'ha abbandonata.

[WarDuck]

Sono in un forum pubblico non per lavorare o per fare l'analisi dei requisiti, ma per svago, e non ho intenzione di parlare per mezzo di specifiche formali o sintassi matematica per descrivere i miei gusti.

Mi fa cacare la sintassi di Objective-C e C++, si hai ben detto, nessuno deve stare appresso ai miei gusti semplicemente perché non pretendo che gli altri debbano pensarla come me o tantomeno modificare il loro comportamento sulla base di questo.

Poi secondo quale teorema il fatto che mi faccia schifo C++ implica che mi debba piacere Objective-C?

D'altronde se a tutti fossero piaciuti i linguaggi di cui parliamo probabilmente non ci sarebbe stato motivo di crearne degli altri.

Per la maggior parte dei linguaggi di cui stiamo parlando, la differenza non risiede nella classe di problemi che possono risolvere (che è la stessa), ma è il come lo fanno che li rende diversi, la sintassi che usano per farlo (con dei pro e dei contro naturalmente).

Quindi è normale che nel momento che debba scegliere qual è il linguaggio più adatto a risolvere un determinato problema sceglierò quello che mi consente di farlo agevolmente (ergo la cui sintassi mi consenta di farlo in maniera decente e perché no, piacevole alla vista).

Direi di chiuderla qui, prometto che mi impegnerò per farmi piacere C++.

[cdimauro]

Originariamente inviato da fero86

restano i tipi reference e le lambda expressions. i tipi reference accorciano il codice perché i riferimenti sono sempre validi (non sono mai nulli o "dangling") e quindi non devi fare controlli,

Poca roba. Puoi anche evitare di far controlli se sei "sicuro" che non verrà mai passato un puntatore nullo.

e i vantaggi delle lambda expressions mi sembrano evidenti.

Non fanno ancora parte del linguaggio, mi pare.

rettifica: una sua particolare implementazione ce l'ha

Era quel che pensava anche MS quando ha realizzato la sua implementazione di Java. Poi Sun ha deciso di farle causa, l'ha pure vinta, e MS ha dovuto far marcia indietro.

A parte questo, mi pare evidente dal contesto che si parlasse di implementazioni. Riporto una parte eloquente del tuo precedente messaggio:

premettiamo che le questioni di performance non sono legate ai linguaggi di per se', che sono solo specifiche di sintassi, semantica e spesso librerie predefinite.

detto questo esistono alcuni linguaggi che favoriscono la performance e per i quali esistono implementazioni intrinsecamente piu performanti; per esempio la specifica del linguaggio Java impone la semantica del bound checking sugli array e questo causa necessariamente una perdita di performance che invece non caratterizza linguaggi non gestiti come C e C++.

Il contesto mi sembra chiaro (ne ho evidenziato una parte), e la mia risposta pure, visto che esistono implementazioni di Java in cui il bound checking può e viene tranquillamente eliminato, nonostante la semantica del linguaggio la preveda.

evitiamo di inventarci altre chimere, lo fa o non lo fa? io non lo so.
se non lo fa evitiamo di parlarne in astratto perché la fattibilitá di un software non é mai garantita al 100% finché quel software non lo sviluppi e non finisci effettivamente nei vicoli ciechi in cui ti porta.

La fonte è un po' vecchia (è ferma alla versione 1.3 di Java), ma trovi qualcosa qui, e ne riporto alcune parti salienti:

Java HotSpot Server VM Optimizations
Range check elimination -- The Java programming language specification requires array bounds checking to be performed with each array access. An index bounds check can be eliminated when the compiler can prove that an index used for an array access is within bounds.
[...]
Java HotSpot Server Compiler
[...]The optimizer performs all the classic optimizations, including dead code elimination, loop invariant hoisting, common subexpression elimination, and constant propagation. It also features optimizations more specific to Java technology, such as null-check and range-check elimination.

Un paper molto interessante sull'argomento lo trovi qui.

Ovviamente in 10 anni HotSpot è stato enormemente migliorato, e oggi Java (nella sua migliore incarnazione) ha prestazioni comparabili a quelle del C.

e che ne sai che nei programmi usati da WarDuck la performance penalty era causata dalla GUI? hai fatto il profiling di tutti quanti?

AWT su Windows usa quelle.

AWT è quella cosa per cui se devi scrivere un semplice "Hello, world!" ti carica 600 classi (800 con SWT, se non ricordo male). Per cui il suo peso sulla reattività ce l'ha.

Su Windows io non dicevo di usare AWT, ma di sfruttare le API Win32 come fanno altri programmi, se vogliamo che l'unica variabile da confrontare rimanga il linguaggio.

certo, peró costituisce un controesempio per l'affermazione inversa: la programmazione a oggetti non é sempre preferibile a quella procedurale (che é quello che volevo dire inizialmente a WarDuck).

Non posso che concordare. Come uso ripetete spesso, la pietra filosofale nell'informatica non è stata ancora inventata.

per inciso, non mi rimangio nulla di quello che ho scritto quella volta: sono ancora dell'idea che, vista la situazione attuale, non sia affatto possibile programmare drivers per Windows in C++.

Di questo ne abbiamo già ampiamente discusso, e non voglio riaprire il flame (anche perché ognuno è rimasto con le proprie idee: sarebbe tempo perso).

Per me è sufficiente che sia ben chiaro il concetto di linguaggio -> sintassi & semantica.

non ho capito
neanche il C++ l'ha abbandonata.

Niente, volevo solo far notare che, pur avendo una base comune (il C, e la sua sintassi) C++ e Objective-C hanno preso strade completamente diverse per quanto riguarda la programmazione a oggetti.

Battuta infelice, a questo punto.

Originariamente inviato da WarDuck

Sono in un forum pubblico non per lavorare o per fare l'analisi dei requisiti, ma per svago, e non ho intenzione di parlare per mezzo di specifiche formali o sintassi matematica per descrivere i miei gusti.

Mi fa cacare la sintassi di Objective-C e C++, si hai ben detto, nessuno deve stare appresso ai miei gusti semplicemente perché non pretendo che gli altri debbano pensarla come me o tantomeno modificare il loro comportamento sulla base di questo.

Poi secondo quale teorema il fatto che mi faccia schifo C++ implica che mi debba piacere Objective-C?

D'altronde se a tutti fossero piaciuti i linguaggi di cui parliamo probabilmente non ci sarebbe stato motivo di crearne degli altri.

Per la maggior parte dei linguaggi di cui stiamo parlando, la differenza non risiede nella classe di problemi che possono risolvere (che è la stessa), ma è il come lo fanno che li rende diversi, la sintassi che usano per farlo (con dei pro e dei contro naturalmente).

Quindi è normale che nel momento che debba scegliere qual è il linguaggio più adatto a risolvere un determinato problema sceglierò quello che mi consente di farlo agevolmente (ergo la cui sintassi mi consenta di farlo in maniera decente e perché no, piacevole alla vista).

Direi di chiuderla qui, prometto che mi impegnerò per farmi piacere C++.

Qui concordo: anche per me la sintassi fa la sua parte.

Se prendiamo Perl, chi nega che si possa programmare a oggetti? Ma provate a farlo, e poi ne riparliamo.

A me la sintassi del C++ non piace, e dopo diversi anni non credo che ci siano ancora margini per farmela piacere. Non mi va, punto e basta.

[cionci]

Originariamente inviato da cdimauro

Ovviamente in 10 anni HotSpot è stato enormemente migliorato, e oggi Java (nella sua migliore incarnazione) ha prestazioni comparabili a quelle del C.

Certo...se fanno implementazioni in C come queste
http://shootout.alioth.debian.org/u6...&lang=gcc&id=5

enum color_t color_complement(enum color_t c1, enum color_t c2)
{
   switch (c1)
   {
   case color_blue:
      switch (c2)
      {
      case color_blue:      return color_blue;
      case color_red:       return color_yellow;
      case color_yellow:    return color_red;
      }
   case color_red:
      switch (c2)
      {
      case color_blue:      return color_yellow;
      case color_red:       return color_red;
      case color_yellow:    return color_blue;
      }
   case color_yellow:
      switch (c2)
      {
      case color_blue:      return color_red;
      case color_red:       return color_blue;
      case color_yellow:    return color_yellow;
      }
   }
   assert(0);
   return 0;
}

Cosa che si risolveva banalmente con una matrice 3x3.


PS: mi sono fermato al primo codice

[cdimauro]

Non che le versioni per gli altri linguaggi siano migliori, eh!

Molti traducono l'algoritmo pari pari.