cosa mi occorre per iniziare? [Archivio]

yorkeiser

17-10-2007, 16:44

Dipende da cosa ti interessa maggiormente: sviluppo di applicativi, programmazione web o che altro ?
I miei (e ripeto miei, quindi non validi universalmente) consigli comunque sono:

- Per imparare i fondamenti, parti dal c. Ti basta un editor di testo ed un semplice compilatore c. Se vuoi un IDE leggero e funzionale, io consiglio sempre lcc.

- Per imparare a fare cose un pochino più elaborate (ad esempio gestionali, interfacce grafiche) io andrei su Java: scaricati l'ultimo SDK direttamente dal sito della sun ww.sun.com, come IDE sicuramente consigliato Eclipse

- Se vuoi fare programmazione orientata al web, ti puoi installare un webserver (consiglio Apache) ed un db (Oracle, mySql) e poi ti puoi sbizzarrire: puoi sviluppare in php (si integra bene con mySQL), in Java (servlet/JSP) oppure puoi anche chiedere aiuto a mamma Microsoft (C#/ASP che - dicono, a me non pare - vanno bene con SQLserver, oltre che ovviamente con Oracle). Io però, come sempre, consiglio di stare lontani da tutto quanto porti il marchio Microzozz :)

Ovviamente avrai bisogno di manuali e documentazione; basta andare su google e fare qualche ricerca, la rete è piena di materiale - anche libri - gratuito. L'importante è solo sapere in quale campo sei più interessato

M_82

17-10-2007, 16:55

cavolo, è già complicato così. comunque:
- Per imparare i fondamenti, parti dal c. Ti basta un editor di testo ed un semplice compilatore c. Se vuoi un IDE leggero e funzionale, io consiglio sempre lcc.
dove me lo scarico? esiste per linux? c'è in synaptic?

M_82

17-10-2007, 17:01

allora: mi sono scaricato gcc da synaptic (penso sia giusto, no?). per quanto riguarda l'editor? "vi" va bene o serve qualcosa di diverso?

variabilepippo

17-10-2007, 17:04

c'è in synaptic?

Se vuoi programmare in C/C++ sotto Linux installa GNU GCC (lo trovi di sicuro nei vari repository) ed un ambiente di sviluppo. Tra i più gettonati trovi Anjuta e KDevelop, altrimenti usa vim o emacs.

Considera però che il C è un linguaggio low-level, avrai bisogno di molto tempo, di un ***buon libro*** e di tanto impegno per vedere risultati confortanti.

M_82

17-10-2007, 17:10

beh, impegno e tempo (per modo di dire) li metto volentieri. per via del buon libro, non esistono delle buone guide in .pdf nella rete? io ho trovato per es. http://edu.os3.it/html/manual/imparare_c.pdf che ne dici? può andare?

variabilepippo

17-10-2007, 17:15

Per iniziare senza spendere nulla va bene, quando avrai finito di studiarlo potrai decidere autonomamente se approfondire il C o se passare ad un altro linguaggio.

M_82

17-10-2007, 17:16

grazie 1000 per il tuo aiuto, davvero molto gentile.
proverò a vedere cosa riesco a combinare...
ciao:)

k0nt3

17-10-2007, 17:30

^TiGeRShArK^

17-10-2007, 17:32

Io però, come sempre, consiglio di stare lontani da tutto quanto porti il marchio Microzozz :)

:mbe:
veramente asp.net usando il C# è MOLTO meglio di PHP.
PHP è un inutile accrocchio che se non fosse così facile trovare hosting gratuito dubito che qualcuno sano di mente userebbe.

dimenticavo...
iniziare a procrammare col C :doh:
no comment va che poi riparte per l'ennesima volta il solito flame.. :doh:

M_82

17-10-2007, 17:34

se sei in gnome va bene anche un semplicissimo gedit, mentre su kde kate è il meglio
di materiale on-line ne trovi a valanghe su C, anche non pdf ma html o qualsiasi altra cosa. se sai l'inglese poi è molto meglio.
grazie per il consiglio. io sono abituato con gedit, allora continuo ad usare quello... per le guide, conosco bene l'inglese; cercherò un pò con google.
grazie:)

^TiGeRShArK^

17-10-2007, 17:36

usa vi solo se lo sai già usare, altrimenti perderai un pò di tempo a imparare solo quello :D
se sei in gnome va bene anche un semplicissimo gedit, mentre su kde kate è il meglio :cool:
di materiale on-line ne trovi a valanghe su C, anche non pdf ma html o qualsiasi altra cosa. se sai l'inglese poi è molto meglio.

in ogni caso tra non più di 4 risposte qualcuno ti convincerà a iniziare da python.. è tipico di questo tipo di discussione :asd:
veramente piuttosto che il C sarebbe molto meglio anche il BASIC :asd:
sicuramente ti spari molto meno sui coglioni :O
E cmq si possono fare programmini anche decenti in basic..
Io ai bei tempi avevo messo mani ad un programma per acquisire tramite scheda di acquisizione ISA le letture di un fotometro per osservazioni astronomiche sul periodo delle stelle variabili.
Oltre ad almeno una 50ina di altri svariati programmini e giochini vari :asd:

M_82

17-10-2007, 17:40

veramente piuttosto che il C sarebbe molto meglio anche il BASIC
ditemi voi, io sono in grado solo di ascoltare in questo forum...:) :(

^TiGeRShArK^

17-10-2007, 17:47

ditemi voi, io sono in grado solo di ascoltare in questo forum...:) :(

guarda...
la mia era solo una battuta di iniziare col BASIC dato che oggi come oggi sarebbe piuttosto una follia..
Ma dal mio punto di vista iniziando col C avresti una curva di apprendimento MOLTO + difficoltosa rispetto ad altri linguaggi, e SOPRATTUTTO, dopo aver imparato il C ti troveresti a dover "disimparare" tutto quello che hai appreso, perchè TUTTI i linguaggi oggi usati, al contrario del C, sono linguaggi ad oggetti.
Utilizzando il C impareresti solo la programmazione procedurale e poi faresti una grandissima fatica ad apprendere la programmazione ad oggetti.
E io ne so qualcosa dato che ai tempi ho iniziato dapprima col Basic, poi sono passato al C, quindi al C++ e infine a Java & all the rest....
Ma la programmazione ad oggetti l'ho iniziata a vedere realmente solo con JAva.
Alla fine il C++ mi sono sempre trovato ad utilizzarlo in maniera procedurale..
vabbè che in effetti dopo circa una decina d'anni in cui avevo appreso quella mentalità m'è venuto un pò difficile modificarla :fagiano:
Cmq io ti consiglierei di iniziare da un linguaggio + ad alto livello del C (così non bestemmi per fare anche una cosa banalissima) e soprattutto con un linguaggio AD OGGETTI (così non sprechi il tuo tempo a dimenticare quello che hai imparato con un linguaggio procedurale).
Tnato lo so che partirà il flame... :D
quindi io ti dico di scegliere tra Java e Python. :p

variabilepippo

17-10-2007, 20:22

Tnato lo so che partirà il flame

Speriamo di no...

Io sconsiglio il C come linguaggio "didattico", se proprio vogliamo "restare in famiglia" è meglio puntare su un C++ moderno (STL e Boost a manetta), senza strane miscele "verso il basso".

Come ho detto anche in precedenza: è necessario conoscere BENE il C, e ciò richiede MOLTO tempo, prima di potersi togliere certe soddisfazioni. :)

cionci

18-10-2007, 08:13

Da synaptic per avere C e C++ pronti scarica il pacchetto build-essential...

yorkeiser

18-10-2007, 10:03

:mbe:
veramente asp.net usando il C# è MOLTO meglio di PHP.
PHP è un inutile accrocchio che se non fosse così facile trovare hosting gratuito dubito che qualcuno sano di mente userebbe.

dimenticavo...
iniziare a procrammare col C :doh:
no comment va che poi riparte per l'ennesima volta il solito flame.. :doh:

Il mondo è bello perchè è vario, inutile disquisire sui punti di vista :)

k0nt3

18-10-2007, 10:26

^TiGeRShArK^

18-10-2007, 18:05

azzarola... avevo detto non più di 4 risposte e invece è stata la quinta :D

- è assolutamente falso che bisogna disimparare il C per imparare a usare altri linguaggi, anzi al contrario c'è tutta una famiglia di linguaggi C-like che ti sarà più facile da comprendere (tra cui java)

- io non ho avuto molte difficoltà a passare dalla programmazione procedurale a quella a oggetti. anzi IMHO la prima è un prerequisito della seconda. proprio vario sto mondo :D

@^TiGeRShArK^
anche io ho mosso i primi passi in basic, ma mi sono accorto presto dell'errore e sono passato al pascal con cui ho imparato tutto sulla programmazione procedurale :Prrr:
sei davvero sicuro di saper programmare ad oggetti? :asd:
Anch'io pensavo di saperlo fare... ma l'esperienza ti apre gli occhi ;)
E cmq la sintassi di un programa è la cosa + facile da imparare.
Molto + importante e + difficile è imparare la mentalità.
E se impari una mentalita procedurale poi tenderai sempre a portarti qualche strascico di essa anche quando pensi di stare programmando ad oggetti :p
E tra l'altro..
mi spieghi cosa avrebbe + il pascal del BASIC? :mbe:

variabilepippo

18-10-2007, 18:34

mi spieghi cosa avrebbe + il pascal del BASIC?

Gli oggetti, a partire dalla preistorica versione 5.5 di TP? La possibilità di integrare nativamente codice Assembly? Le prestazioni? La portabilità (vedi FreePascal)? La sintassi di base in comune con linguaggi moderni come l'Object Pascal di Delphi? Una serie di regole sintattiche che obbligano il programmatore a scrivere codice "pulito"? Per esempio... :rolleyes:

Dijkstra, uno dei padri dell'informatica insieme a Knuth sosteneva che:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration".

^TiGeRShArK^

18-10-2007, 19:13

Gli oggetti, a partire dalla preistorica versione 5.5 di TP?

Pascal is a structured imperative computer programming language, developed in 1970 by Niklaus Wirth as a language particularly suitable for structured programming. A derivative known as Object Pascal was designed for object oriented programming.

Qui non mi pare stiamo parlando delle caratteristiche ad oggetti dell'object pascal, quanto piuttosto stiamo confrontando i linguaggi basic e pascal nella loro caratteristica principe: la programmazione strutturata. ;)

La possibilità di integrare nativamente codice Assembly?

Se non erro anche questa caratteristica è stata introdotta dalla versione 5.5.. ma qui potrei anche sbagliare :p
E comunque non vedo cosa c'entri con le capacità didattiche di un linguaggio :mbe:
tra l'altro il codice macchina lo potevi usare anche in BASIC tramite le istruzioni peek e poke.
Ovviamente era molto macchinoso...
ma altrimenti spiegami come avrei fatto ad interfacciarmi alla scheda di acquisizione ISA del fotometro senza queste istruzioni? :D

Le prestazioni?

Non hanno alcun rilievo quando si parla di "didatticità" di un linguaggio.
Tant'è vero che da molti sono consideraati MOLTO + didattici linguaggi come il java e il python che sono in media + lenti del C/C++ :p

La portabilità (vedi FreePascal)?

Bhè..
inutile ricordarti su quante macchine diverse dell'epoca girava un interprete BASIC :D

La sintassi di base in comune con linguaggi moderni come l'Object Pascal di Delphi?

E questo cosa avrebbe a che fare con la maggiore facilità di apprendimento di un linguaggio rispetto ad un altro? :mbe:
E, per la cronaca, anche la sintassi del basic è stata ripresa dal Visual Basic.
Quindi non mi pare un punto a favore del Pascal, anche nel caso si dovesse considerare..
Solo che io proprio non lo considererei :D

Una serie di regole sintattiche che obbligano il programmatore a scrivere codice "pulito"? Per esempio... :rolleyes:

Su questo ti lascio il beneficio del dubbio poichè in pascal ci ho solo giochicchiato e non ci ho mai programmato seriamente.

Dijkstra, uno dei padri dell'informatica insieme a Knuth sosteneva che:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration".
Non credo che ai tempi in cui abbia pronunciato questa frase la programmazione ad oggetti fosse tanto sviluppata :D
e anche se fosse, in quel caso, dubito che si sarebbero pronunciati a favore della versione non ad oggetti del pascal ;)

k0nt3

18-10-2007, 19:16

Gli oggetti, a partire dalla preistorica versione 5.5 di TP? La possibilità di integrare nativamente codice Assembly? Le prestazioni? La portabilità (vedi FreePascal)? La sintassi di base in comune con linguaggi moderni come l'Object Pascal di Delphi? Una serie di regole sintattiche che obbligano il programmatore a scrivere codice "pulito"? Per esempio... :rolleyes:

Dijkstra, uno dei padri dell'informatica insieme a Knuth sosteneva che:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration".
*

ps. ho visto il mio primo oggetto proprio in pascal :read:

k0nt3

18-10-2007, 19:22

k0nt3

18-10-2007, 19:36

^TiGeRShArK^

18-10-2007, 19:38

@^TiGeRShArK^
urca mi fai venire i dubbi :eek: no beh ormai programmo quasi solo a oggetti da un bel pezzo, di esperienza ne ho un pò.
java apre la mente riguardo agli oggetti, ti costringe a entrare nella mentalità giusta IMHO, cosa che altri linguaggi non fanno perchè troppo permissivi.
hai proprio ragione sul fatto che la mentalità è la cosa più importante :D ma io ho idee strane e penso che per programmare a oggetti bisogna comunque saper programmare in maniera procedurale (nel piccolo). la mentalità da programmazione a oggetti emerge soprattutto quando si condidera la struttura nel complesso del programma, cioè come le classi interagiscono ecc.. a grandi linee ovviamente, non penso di poter esporre il concetto di programmazione a oggetti in una frase :fagiano:
guarda.. a me sinceramente i dubbi son venuti quando ho iniziato a lavorare su diamondcrush...
e all'epoca per fortuna m'ero fatto un pò di esperienza con java tra 9 mesi di tesi e il tempo passato in TILAB..
però lo stesso mi sono reso conto che imparare bene a programmare ad oggetti, soprattutto se sei partito dalla programmazione procedurale non è affatto scontato.
Poi può essere benissimo che tu sai programmare perfettamente ad oggetti..
io ho solo riportato la mia esperienza personale (e c'è da dire che cmq alle spalle avevo + di 10 anni di programmazione prettamente procedurale... quindi cambiare punto di vista non è che mi è venuto proprio facile :stordita: )

^TiGeRShArK^

18-10-2007, 19:40

per la faccenda Pascal vs. Basic:
essenzialmente la differenza è lo scopo per cui questi linguaggi sono stati creati. Pascal è stato creato per insegnare la programmazione strutturata, mentre Basic è stato creato per permettere ai "non addetti ai lavori" di programmare. c'è una sottile differenza :D
si, cmq l'ho già detto che il pascal lo conosco solo all' "acqua di rose", ma sono sempre due linguaggi nati per usare il paradigma di programmazione strutturata ;)

k0nt3

18-10-2007, 19:55

guarda.. a me sinceramente i dubbi son venuti quando ho iniziato a lavorare su diamondcrush...
e all'epoca per fortuna m'ero fatto un pò di esperienza con java tra 9 mesi di tesi e il tempo passato in TILAB..
però lo stesso mi sono reso conto che imparare bene a programmare ad oggetti, soprattutto se sei partito dalla programmazione procedurale non è affatto scontato.
Poi può essere benissimo che tu sai programmare perfettamente ad oggetti..
io ho solo riportato la mia esperienza personale (e c'è da dire che cmq alle spalle avevo + di 10 anni di programmazione prettamente procedurale... quindi cambiare punto di vista non è che mi è venuto proprio facile :stordita: )
penso che sia estremamente complicato stabilire qual'è il percorso corretto, perchè una volta funziona e una volta no ecc..
forse il mio passaggio agli oggetti è stato più graduale del tuo e soprattutto non avevo 10 anni di programmazione prettamente procedurale alle spalle.
come ho detto ho visto i primi oggetti in pascal, ma al tempo li vedevo come qualcosa di un pò più potente dei record (credo si chiamavano così le struct di pascal.. mannaggia ne è passato di tempo!). poi ho avuto altri incontri ravvicinati con oggetti quando ho deciso di imparare il C++, ma essenzialmente programmavo ancora in maniera procedurale con l'aggiunta di qualche classe dove serviva. alla fine ho conosciuto java e a quel punto ho visto tutti i tasselli andare al loro posto :cool:
devo dire anche grazie a un corso di ingegneria del software :fagiano:

D4rkAng3l

18-10-2007, 20:13

cavolo, è già complicato così. comunque:

dove me lo scarico? esiste per linux? c'è in synaptic?

LOL :D

D4rkAng3l

18-10-2007, 20:20

Noi ad informatica iniziamo prima col C per imparare il paradigma procedurale, poi passiamo al secondo anno a fare Java per imparare il pardigma ad oggetti e al terzo anno ad intelligenza artificiale si vede pure il Prolog per la programmazione logica :D

Il problema di iniziare con C non credo sia tanto passare alla programmazione ad oggetti dopo quanto più che altro il fatto che essendo un linguaggio abbastanza di basso livello (che opera direttamente con strutture molto vicine alla macchina) se non sei obbligato a farlo per passare un esame potresti scoraggiarti e lasciar stare del tutto.

variabilepippo

18-10-2007, 20:32

Premessa: la tua domanda era "mi spieghi cosa avrebbe + il pascal del BASIC? ". Immagino che tu abbia un'età confrontabile con la mia, dunque ricorderai bene che le applicazioni mainstream, a cavallo tra gli anni '80 ed i '90, venivano sviluppate essenzialmente in 2 linguaggi: C e Pascal, il BASIC (se escludiamo le sue incarnazioni più recenti, ma che a parte il nome hanno poco a che vedere con il Beginner's All purpose Symbolic Instruction Code) era poco più di un giocattolo.

stiamo confrontando i linguaggi basic e pascal nella loro caratteristica principe: la programmazione strutturata.

Non mi sembra che il BASIC abbia il merito di favorire un approccio moderno alla programmazione strutturata. In quali corsi di programmazione veniva/viene usato come linguaggio didattico?

E comunque non vedo cosa c'entri con le capacità didattiche di un linguaggio

La tua domanda iniziale mi sembra molto chiara, non si riferiva direttamente all'aspetto didattico (nonostante ciò il Pascal, ancora oggi, viene annoverato tra i linguaggi didattici per eccellenza e non tra quelli considerati "deprecated").

Non hanno alcun rilievo quando si parla di "didatticità" di un linguaggio.
Tant'è vero che da molti sono consideraati MOLTO + didattici linguaggi come il java e il python che sono in media + lenti del C/C++

Non perdiamo di vista la domanda iniziale. Anch'io, nel 2007, suggerirei un altro linguaggio (il Python) tra quelli adottabili per muovere i primi passi ma la questione era un'altra.

E, per la cronaca, anche la sintassi del basic è stata ripresa dal Visual Basic.

Che culo... :D

Non credo che ai tempi in cui abbia pronunciato questa frase la programmazione ad oggetti fosse tanto sviluppata

Non vedo il nesso tra il senso della frase ed il fatto che la OOP non fosse tanto sviluppata.:confused:

e anche se fosse, in quel caso, dubito che si sarebbero pronunciati a favore della versione non ad oggetti del pascal

Ne dubito fortemente, in ogni caso l'unico dato di fatto è che sconsigliavano vivamente il BASIC. :D

^TiGeRShArK^

18-10-2007, 21:35

Premessa: la tua domanda era "mi spieghi cosa avrebbe + il pascal del BASIC? ". Immagino che tu abbia un'età confrontabile con la mia, dunque ricorderai bene che le applicazioni mainstream, a cavallo tra gli anni '80 ed i '90, venivano sviluppate essenzialmente in 2 linguaggi: C e Pascal, il BASIC (se escludiamo le sue incarnazioni più recenti, ma che a parte il nome hanno poco a che vedere con il Beginner's All purpose Symbolic Instruction Code) era poco più di un giocattolo.

ehmmm...
non lo so :fagiano:
probabilmente tu sei un pò + vecchiotto :D
io ho quasi 27 anni cmq :p
Ma diciamo che ho iniziato abbastanza precocemente a programmare :asd:
E cmq si. il basic ai tempi ovviamente non poteva competere come "potenza" con gli altri linguaggi presenti.
Ma il thread mi pare che parli della solita diatriba con quale linguaggio iniziare, e la mia domanda era ovviametne volta in quel senso ;)

Non mi sembra che il BASIC abbia il merito di favorire un approccio moderno alla programmazione strutturata. In quali corsi di programmazione veniva/viene usato come linguaggio didattico?

Immagino nessuno oggi come oggi.
Come d'altronde spero il pascal.
Ai tempi nelle scuole dell'obbligo ed ai superiori penso che lo scenario tra basic e pascal era un pò + combattuto essendo presenti un pò tutti e due i linguaggi.

La tua domanda iniziale mi sembra molto chiara, non si riferiva direttamente all'aspetto didattico (nonostante ciò il Pascal, ancora oggi, viene annoverato tra i linguaggi didattici per eccellenza e non tra quelli considerati "deprecated").

dovevi leggerla nell'ottiva del thread ;)
anche se ammetto di essere stato poco chiaro avendo dato per scontato "l'oggetto" del thread :D

sirus

18-10-2007, 22:09

Il mio consiglio è cominciare con un qualsiasi linguaggi di programmazione che comporti programmazione procedurale e solo dopo passare ad un linguaggio ad oggetti che ti obblighi realmente ad utilizzare gli oggetti.
Il linguaggio procedurale che ti consiglio è il C perché credo che tutti i programmatori dovrebbero conoscerlo almeno un minimo, per quanto riguarda la il linguaggio ad oggetti mi sentirei di proporti il Java (lascia perdere il C++) anche se dopo poche letture sul C# devo dire che il Java sta perdendo un po' ai miei occhi (purtroppo il C# non è una scelta molto valida in ambiente GNU/Linux).
Per gli strumenti di sviluppo direi che gcc e Gedit o Kate a seconda del tuo desktop environment vanno benissimo per il primo stadio di apprendimento e successivamente Java 2 SDK ed Eclipse diventano quasi un must.

PS: non mi sentirai consigliare il Python perché non mi piace anche se ha l'enorme vantaggio di obbligare il programmatore ad indentare il codice cosa che purtroppo in pochi fanno agli inizi.

k0nt3

18-10-2007, 22:20

la vera forza di java non è il linguaggio ma il framework ;) però anche il linguaggio con la sua semplicità (che via via si sta perdendo) fa la sua parte

variabilepippo

18-10-2007, 22:31

^TiGeRShArK^

18-10-2007, 22:40

Quali sono i vantaggi di tale approccio? :rolleyes:

*

sirus

18-10-2007, 22:53

k0nt3

19-10-2007, 09:17

L'approccio ad oggetti è riferibile alla programmazione "in the large" ma per quanto riguarda la programmazione "in the small" direi che ci ritroviamo sempre e comunque in campo procedurale; questo perché le macchine che abbiamo a disposizioni sono procedurali.
è un pò quello che sostengo io.. cioè nella programmazione a oggetti rimane sempre una componente procedurale, almeno per i linguaggi OO più diffusi oggi.

ma soprattutto (@variabilepippo).. quali sarebbero i vantaggi dell'approccio inverso? :fagiano:

sirus

19-10-2007, 09:40

è un pò quello che sostengo io.. cioè nella programmazione a oggetti rimane sempre una componente procedurale, almeno per i linguaggi OO più diffusi oggi.

ma soprattutto (@variabilepippo).. quali sarebbero i vantaggi dell'approccio inverso? :fagiano:
:asd: ogni tanto andiamo anche d'accordo... :stordita: questo è un post da incorniciare. :sofico:

variabilepippo

19-10-2007, 10:36

ma soprattutto (@variabilepippo).. quali sarebbero i vantaggi dell'approccio inverso?

L'imparare fin da subito a pensare in termini di oggetti e non in termini di "mere sequenze di istruzioni", attività che rende difficile per chi ha un solido background di programmazione procedurale comprendere i complessi meccanismi della OOD (Progettazione orientata agli oggetti). Un oggetto ha dei meccanismi di funzionamento totalmente diversi rispetto a quelli che si trovano nel codice procedurale.

Troppo spesso ci si illude di programmare "ad oggetti", mentre in realtà ci si limita a creare "metodi" che vengono usati come se fossero "procedure", o viceversa.

Basta dare un'occhiata a codice "C++" scritto da chi ha imparato partendo dal C, anche i professionisti tendono (è difficile scrollarsi di dosso certe abitudini) a mescolare C e C++. Non è un caso che nei più recenti testi sul C++ si proponga un approccio radicalmente diverso: partiamo dagli oggetti, poi vediamo cosa scrivere nei metodi ricordando che strutture dati e funzioni standard non vanno ricreate ogni volta da zero.

In fondo la progettazione bottom-up ha molti limiti se confrontata con la top-down, ed ancora più in fondo la programmazione procedurale e quella ad oggetti rappresentano due paradigmi diversi e per molti versi complementari, invece (IMHO) si commette spesso l'errore di vedere la prima propedeutica per la seconda. :(

variabilepippo

19-10-2007, 10:39

sirus

19-10-2007, 10:53

Basta dare un'occhiata a codice "C++" scritto da chi ha imparato partendo dal C, anche i professionisti tendono (è difficile scrollarsi di dosso certe abitudini) a mescolare C e C++. Non è un caso che nei più recenti testi sul C++ si proponga un approccio radicalmente diverso: partiamo dagli oggetti, poi vediamo cosa scrivere nei metodi ricordando che strutture dati e funzioni standard non vanno ricreate ogni volta da zero.
Nessuno mette in dubbio che questo sia vero ed è per questo che mi sento di sconsigliare il C++ come linguaggio di programmazione orientato agli oggetti per il semplice fatto che non "obbliga" il programmatore a pensare ad oggetti (cosa che al momento mi viene più naturale nonostante abbia avuto forti basi di programmazione procedurale).
Volendo ben vedere anche il Java non è il linguaggio più orientato agli oggetti che sia disponibile ma al contrario del C++ è già un bene che anche il più piccolo programma che si può scrivere è un micro-oggetto.

Quello che io ed immagino anche k0nt3 vogliamo dire è che anche affrontando un problema con una visione ad oggetti, la parte più "atomica" del programma sarà sempre una sequenza di istruzioni.
Prendi un esempio stupidissimo, la classe Cubo; è bello vedere il Cubo come un oggetto con il quale si può interagire tuttavia i suoi metodi (diciamo, superfice, volume e non so che altro) saranno sempre delle piccole sequenze di istruzioni che altro non possono essere che procedurali.

Non mi sono chiari i concetti di "programmazione in the large" e "programmazione in the small"... Cosa intendi? :confused:
Sono dei concetti che ho trovato su un libro (molto didattico) di programmazione orientata agli oggetti che mi sono piaciuti molti ed ho fatto miei. :D
Con "programmazione in the small" mi riferisco alla parte più piccola che si può trovare all'interno di un programma (tipicamente la programmazione di un metodo), mentre con "programmazione in the large" mi riferisco ad una visione più completa di tutto il programma ossia alla parte più strettamente legata alla progettazione ed all'interazione delle componenti di un programma (oggetti nel caso della nostra discussione).

AnonimoVeneziano

19-10-2007, 10:55

Ma uno che inizia a programmare oggi è in grado di comprendere il concetto di "Oggetto" ?

La cosa che mi preoccupa un po' è soprattutto la qualità della documentazione che si trova in giro.

La maggior parte dei tutorial / libri sull'argomento "Programmazione in [metti il tuo linguaggio OO preferito qui]" si basa quasi sempre sulla già per scontata conoscenza del paradigma procedurale e in genere si parte proprio dalla programmazione procedurale per poi introdurre il concetto di oggetto come una estensione (Il concetto della "Struct con funzioni" che , ahimè, non muore mai) . Se si vuole far partire qualcuno con la programmazione ad oggetti a mio parere bisogna anche consigliare un testo valido che orienti la sua mentalità nella direzione giusta, sennò tanto vale farlo partire col più classico C e via (come immagino abbia fatto la maggiorparte dei partecipanti a questo thread, nel bene o nel male).

Ciao

k0nt3

19-10-2007, 11:09

Non mi sono chiari i concetti di "programmazione in the large" e "programmazione in the small"... Cosa intendi? :confused:
l'essenza della programmazione OO sono le relazioni fra le classi, ma preso un particolare metodo di una particolare classe (cioè quello che intendevamo con "in the small") vedi praticamente programmazione procedurale (sempre considerando i tipici linguaggi a oggetti diffusi oggi*).
iniziare con la programmazione OO quindi richiede una certa visione d'insieme (tipica visione OO) e inoltre anche tutto quello che bisognava sapere per la programmazione procedurale. troppa carne al fuoco, ma sappiamo che il mondo è vario, quindi rimango sull'IMHO

* faccio sempre questa precisazione perchè ad esempio Scala è un linguaggio funzionale "in the small" e a oggetti "in the large"

variabilepippo

19-10-2007, 11:14

Prendi un esempio stupidissimo, la classe Cubo; è bello vedere il Cubo come un oggetto con il quale si può interagire tuttavia i suoi metodi (diciamo, superfice, volume e non so che altro) saranno sempre delle piccole sequenze di istruzioni che altro non possono essere che procedurali

Il problema sta tutto qui, io sostengo che prima si costruisce il cubo e poi si pensa a scrivere le "piccole sequenze di istruzioni" mentre voi propendete per l'approccio inverso. L'ingegnere che progetta un edificio deve fare tutta una serie di considerazioni, calcoli complessi e scelte progettuali e non si preoccupa del singolo mattoncino. D'altra parte se ci si abitua a ragionare in termini di mattoncini, al massimo si potrà costruire un'autorimessa, a meno di essere carpentieri fuori dall'ordinario. :)

La programmazione procedurale e quella ad oggetti sono diverse ed ovviamente la seconda richiede, nella fase FINALE, l'implementazione di routine, ma se si sceglie di seguire la strada procedurale-->oggetti si rischia di non sfruttare al massimo i vantaggi del paradigma ad oggetti (che comunque NON è la panacea propagandata da molti).

Se si vuole far partire qualcuno con la programmazione ad oggetti a mio parere bisogna anche consigliare un testo valido che orienti la sua mentalità nella direzione giusta,

Concordo, però esistono buoni libri sull'argomento, l'importante è non sceglierne uno di quelli che mescolano le carte di due mazzi diversi: il mazzo procedurale e quello ad oggetti.

sirus

19-10-2007, 11:21

Il problema sta tutto qui, io sostengo che prima si costruisce il cubo e poi si pensa a scrivere le "piccole sequenze di istruzioni" mentre voi propendete per l'approccio inverso. L'ingegnere che progetta un edificio deve fare tutta una serie di considerazioni, calcoli complessi e scelte progettuali e non si preoccupa del singolo mattoncino. D'altra parte se ci si abitua a ragionare in termini di mattoncini, al massimo si potrà costruire un'autorimessa, a meno di essere carpentieri fuori dall'ordinario. :)
Non sono d'accordo. Anche io, come tutti gli altri che hanno partecipato a questa discussione ed hanno proposto l'approccio procedurale > oggetti, vedo per prima cosa un programma nella sua interezza e solo nella fase finale vado a dare un implementazione (immancabilmente procedurale) per le parti più piccole del programma, proprio come fai tu e credo come fanno tutti coloro che programmano ad oggetti. Ma in questo caso stiamo parlando di progettazione e non propriamente di programmazione.

E' innegabile che agli inizi è difficile pensare che ci si metta a scrivere un programma che richieda un'operazione di progettazione tanto approfondita.
Non so come hai iniziato, forse i tuoi primi progetti erano molto grandi, ma quando ero agli inizi stampavo "Hello, World!" a video ed ero felice di farlo :D e non credo che per un programma simile sia necessario l'approccio che hai proposto a meno che ci si vada ad intestardire con inutili problemi di sovra-ingegnerizzazione. :Prrr:

k0nt3

19-10-2007, 11:21

Il problema sta tutto qui, io sostengo che prima si costruisce il cubo e poi si pensa a scrivere le "piccole sequenze di istruzioni" mentre voi propendete per l'approccio inverso. L'ingegnere che progetta un edificio deve fare tutta una serie di considerazioni, calcoli complessi e scelte progettuali e non si preoccupa del singolo mattoncino. D'altra parte se ci si abitua a ragionare in termini di mattoncini, al massimo si potrà costruire un'autorimessa, a meno di essere carpentieri fuori dall'ordinario. :)

ecco io penso che se prima non si impara a costruire UN mattoncino è difficile imparare a metterne in relazione molti.
secondo me mettere in relazione mattoncini è un argomento avanzato e richiede già una certa dimestichezza con la programmazione.
in effetti qui si mette in luce uno dei più grossi equivoci nella storia dell'informatica... ho sentito gente affermare che l'uomo ragiona a oggetti e quindi programmare a oggetti non richiede trasformazioni di visuale nella nostra mente :mbe:
mi domando come mai qualcuno ha scoperto come funziona la nostra mente e non ha preso il nobel :fagiano:

k0nt3

19-10-2007, 11:26

Non sono d'accordo. Io vedo per prima cosa un programma nella sua interezza (progettazione ad oggetti) e solo nella fase finale della progettazione vado a dare una specifica (immancabilmente procedurale) per le parti più piccole del programma, proprio come fai tu e credo come fanno tutti coloro che programmano ad oggetti.

implementazione forse :p

ps. ma ti hanno fatto usare JML? :mbe: mi sembra strano visto che usi la parola "specifica" come se fosse una parola come tutte le altre :asd:

sirus

19-10-2007, 11:28

ho sentito gente affermare che l'uomo ragiona a oggetti e quindi programmare a oggetti non richiede trasformazioni di visuale nella nostra mente :mbe:
Forse non ragioniamo ad oggetti (sinceramente alle volte mi chiedo se sono o meno un essere che ragiona :asd: ) tuttavia è palese che una volta appresa la progettazione ad oggetti sia molto più semplice passare da quello che sono le nostre idee al programma vero e proprio, il salto da compiere è sicuramente inferiore rispetto a quello necessario per passare dalle nostre idee ad un programma completamente procedurale.

sirus

19-10-2007, 11:29

implementazione forse :p

ps. ma ti hanno fatto usare JML? :mbe: mi sembra strano visto che usi la parola "specifica" come se fosse una parola come tutte le altre :asd:
Con specifica intendevo implementazione... ;)
Purtroppo ho anche avuto il dispiacere di utilizzare JML. :muro:

variabilepippo

19-10-2007, 11:32

ecco io penso che se prima non si impara a costruire UN mattoncino è difficile imparare a metterne in relazione molti.

Vedi, io ho iniziato TANTI anni fa con la programmazione procedurale (Pascal e C) e, nonostante sviluppi in Object Pascal, C#, C++, Python, ancora oggi tendo a ragionare prima in "termini sequenziali" e POI in "termini di oggetti". Questo problema è comune a molti di quelli che hanno iniziato nello stesso modo, alcuni non se ne rendono conto, altri sì.

Se potessi tornare indietro inizierei direttamente con un buon libro (anche oggi, alla fine del 2007, non sono molti) sulla OOP, indipendentemente dal linguaggio: è un problema di mentalità, una volta scavati certi "solchi" è difficile seguire un percorso diverso.

k0nt3

19-10-2007, 11:37

Forse non ragioniamo ad oggetti (sinceramente alle volte mi chiedo se sono o meno un essere che ragiona :asd: ) tuttavia è palese che una volta appresa la progettazione ad oggetti sia molto più semplice passare da quello che sono le nostre idee al programma vero e proprio, il salto da compiere è sicuramente inferiore rispetto a quello necessario per passare dalle nostre idee ad un programma completamente procedurale.
si ovviamente ne sono al corrente ;) il punto non sta tanto su come ragioniamo, ma sui vantaggi di una "visuale" rispetto all'altra. la visuale OO senza ombra di dubbio è molto adatta a mettere insieme vari tasselli, mentre la visuale procedurale è adatta a costruire i tasselli da mettere insieme. tutto qui

ps. eh JML un dispiacere? aspetta di sentire nominare alloy :rotfl:

k0nt3

19-10-2007, 11:56

Vedi, io ho iniziato TANTI anni fa con la programmazione procedurale (Pascal e C) e, nonostante sviluppi in Object Pascal, C#, C++, Python, ancora oggi tendo a ragionare prima in "termini sequenziali" e POI in "termini di oggetti". Questo problema è comune a molti di quelli che hanno iniziato nello stesso modo, alcuni non se ne rendono conto, altri sì.

Se potessi tornare indietro inizierei direttamente con un buon libro (anche oggi, alla fine del 2007, non sono molti) sulla OOP, indipendentemente dal linguaggio: è un problema di mentalità, una volta scavati certi "solchi" è difficile seguire un percorso diverso.
ho notato che è un problema abbastanza diffuso. secondo me il punto è che la programmazione procedurale non è adatta per progetti di una certa complessità strutturale e per questo motivo se una persona si trova a usare lo strumento sbagliato per lungo tempo rimane senza dubbio "segnato" da questo fatto.
ma finchè si sta imparando a programmare i programmi sono di una complessità praticamente irrilevante e quindi non penso che la programmazione OO dia molti benefici in questo caso (anzi forse confonde). certamente consiglio sempre di imparare la programmazione OO non appena si è raggiunta una certa dimestichezza con la programmazione procedurale.
ma come dicevo prima non pretendo che questo sia un metodo applicabile in generale.. è quello che credo possa adattarsi nella maggiorparte dei casi.
in tutto questo non stiamo considerando il paradigma funzionale che probabilmente è adatto a persone che vengono da una formazione più matematica, ma come il paradigma procedurale non è adatto a costruire cose di una certa complessità (dove per ora l'OOP regna incontrastata).

fek

19-10-2007, 12:26

però lo stesso mi sono reso conto che imparare bene a programmare ad oggetti, soprattutto se sei partito dalla programmazione procedurale non è affatto scontato.

Esatto. Devi disimparare la maggior parte dei paradigmi che hai imparato nella programmazione procedurale e impararne di totalmente nuovi.
Imparare il paradigma procedurale e poi passare al paradigma ad oggetti e' la cosa peggiore, meglio il percorso inverso: ma l'obiettivo e' imparare entrambi i paradigmi e non solo quelli. L'obiettivo e' imparare piu' strumenti possibile, imparare quando usarli e soprattutto quando NON usarli.

Ad esempio forzare un paradigma ad oggetti per una soluzione che non lo richiede e complicare il design e' sbagliato e va evitato.

fek

19-10-2007, 12:35

Troppo spesso ci si illude di programmare "ad oggetti", mentre in realtà ci si limita a creare "metodi" che vengono usati come se fossero "procedure", o viceversa.

Basta dare un'occhiata a codice "C++" scritto da chi ha imparato partendo dal C, anche i professionisti tendono (è difficile scrollarsi di dosso certe abitudini) a mescolare C e C++. Non è un caso che nei più recenti testi sul C++ si proponga un approccio radicalmente diverso: partiamo dagli oggetti, poi vediamo cosa scrivere nei metodi ricordando che strutture dati e funzioni standard non vanno ricreate ogni volta da zero.

Esatto anche questo. Programmare e' complesso, quindi per un novizio l'approccio migliore e' mantenersi ad un livello di astrazione il piu' alto possibile, e imparare a descrivere la soluzione di un problema con un linguaggio il piu' possibile vicino al suo modo di pensare e piu' lontano possibile dai dettagli della macchina. Piu' aumenta la confidenza, piu' si puo' entrare nei dettagli e scendere nei livelli di astrazioni fino ad arrivare al C, ad esempio.

Inutile, ad esempio, ingolfare chi impara con concetti a basso livello come la gestione della memoria che lo distraggono dall'obiettivo che deve imparare: i meccanismi per formulare la soluzione ad un problema.

variabilepippo

19-10-2007, 12:36

ho notato che è un problema abbastanza diffuso.

È più diffuso di quanto si creda, spessissimo le classi vengono viste solo come "contenitori" di codice procedurale e non come entità concettualmente diverse, ciò è dovuto in parte al limitato (quando va bene) tempo che si dedica alla progettazione di una gerarchia di classi ed in parte ai "danni" derivanti dallo studio dell'approccio procedurale. Se si riesce a creare una buona struttura di classi, implementare il codice all'interno dei metodi è relativamente semplice, purtroppo non vale il viceversa.

il paradigma procedurale non è adatto a costruire cose di una certa complessità (dove per ora l'OOP regna incontrastata).

Se non sbaglio sistemi operativi, compilatori, virtual machine e tanti altri progetti di una certa complessità vengono "ancora" sviluppati in C. :rolleyes:

variabilepippo

19-10-2007, 12:39

Esatto. Devi disimparare la maggior parte dei paradigmi che hai imparato nella programmazione procedurale e impararne di totalmente nuovi.
Imparare il paradigma procedurale e poi passare al paradigma ad oggetti e' la cosa peggiore, meglio il percorso inverso: ma l'obiettivo e' imparare entrambi i paradigmi e non solo quelli. L'obiettivo e' imparare piu' strumenti possibile, imparare quando usarli e soprattutto quando NON usarli.

Ad esempio forzare un paradigma ad oggetti per una soluzione che non lo richiede e complicare il design e' sbagliato e va evitato.

Quoto al 100%. :)

sirus

19-10-2007, 12:40

Se non sbaglio sistemi operativi, compilatori, virtual machine e tanti altri progetti di una certa complessità vengono "ancora" sviluppati in C. :rolleyes:
Credo che questo sia valido per una parte di ogni progetto che hai citato. Per esempio è facile che il kernel di un sistema operativo sia scritto in C mentre tutto o quasi quello che sta sopra il kernel sia scritto in C++ o linguaggio similari.
Sui compilatori non posso dire nulla ma se ci riferiamo al solo compilatore e non all'intero IDE credo che effettivamente sia tutto scritto in C e lo stesso discorso vale per i sistemi di virtualizzazione.

fek

19-10-2007, 12:42

Se non sbaglio sistemi operativi, compilatori, virtual machine e tanti altri progetti di una certa complessità vengono "ancora" sviluppati in C. :rolleyes:

In realta' no. Alcuni kernel di OS diffusi sono ancora scritti in C per questioni di compatibilita' con una larga code base legacy che non avrebbe senso convertire ad un linguaggio piu' ad alto livello.
Il kernel di Windows, ad esempio, ha ancora larghe parti in C per questione di compatibilita', ma la sua architettura e' totalmente "ad oggetti".
Per un kernel di un OS nuovo non avrebbe alcun senso scrivere in C piuttosto che in C++. BeOS era scritto in C++ ed e' tutt'oggi forse il migliore OS che abbia mai usato.

Il compiltatore C++ del VS2005 e' interamente scritto in C++ e compilato con se' stesso.

^TiGeRShArK^

19-10-2007, 12:49

^TiGeRShArK^

19-10-2007, 12:51

Esatto anche questo. Programmare e' complesso, quindi per un novizio l'approccio migliore e' mantenersi ad un livello di astrazione il piu' alto possibile, e imparare a descrivere la soluzione di un problema con un linguaggio il piu' possibile vicino al suo modo di pensare e piu' lontano possibile dai dettagli della macchina. Piu' aumenta la confidenza, piu' si puo' entrare nei dettagli e scendere nei livelli di astrazioni fino ad arrivare al C, ad esempio.

Inutile, ad esempio, ingolfare chi impara con concetti a basso livello come la gestione della memoria che lo distraggono dall'obiettivo che deve imparare: i meccanismi per formulare la soluzione ad un problema.

ari-quotissimo :D

fek

19-10-2007, 12:52

k0nt3

19-10-2007, 12:54

È più diffuso di quanto si creda, spessissimo le classi vengono viste solo come "contenitori" di codice procedurale e non come entità concettualmente diverse, ciò è dovuto in parte al limitato (quando va bene) tempo che si dedica alla progettazione di una gerarchia di classi ed in parte ai "danni" derivanti dallo studio dell'approccio procedurale. Se si riesce a creare una buona struttura di classi, implementare il codice all'interno dei metodi è relativamente semplice, purtroppo non vale il viceversa.

esatto e come avrai notato è più difficile progettare che implementare.. quindi perchè iniziare dalla parte più difficile? richiede conoscenze più profonde

Se non sbaglio sistemi operativi, compilatori, virtual machine e tanti altri progetti di una certa complessità vengono "ancora" sviluppati in C. :rolleyes:
è una cosa abbastanza condivisibile.
per quanto riguarda i sistemi operativi e le VM è una faccenda che riguarda l'interazione con i livelli più bassi (necessariamente procedurali) e le prestazioni. niente vieta di fare tutto a oggetti, ma non si sa bene se i vantaggi sono più degli svantaggi per ora. sicuramente un giorno lo saranno.
inoltre è possibile ragionare a oggetti anche in C solo che il linguaggio non ti aiuta per niente ed è richiesta molta immaginazione :p
per quanto riguarda i compilatori invece c'è un discorso a parte (in parte valido per alcune componenti dei sistemi operativi). praticamente non c'è niente da progettare in un compilatore, si sa a priori come va fatto :Prrr:

fek

19-10-2007, 12:56

è una cosa abbastanza condivisibile.

No, non lo e'. Non c'e' alcun motivo per preferire il C al C++ nella scrittura di un qualunque software (a parte i motivi di compatibilita' con codice legacy gia' elencati).

sirus

19-10-2007, 12:56

Al thread starter consiglierei di iniziare con un linguaggio ad alto livello come Ruby o Python e poi passare a C# e Java appena si sente pronto ad affrontare qualcosa di piu' complesso. E infine, ma dopo molto tempo, passare al C++ per dare uno sguardo a qualcosa di davvero complesso.
Allo stato attuale sceglierei Ruby e C# anche se rimango dell'idea che una base di programmazione procedurale sia necessaria.

k0nt3

19-10-2007, 12:57

Esatto. Devi disimparare la maggior parte dei paradigmi che hai imparato nella programmazione procedurale e impararne di totalmente nuovi.
la programmazione procedurale è UN paradigma che io sappia.. e non ritengo molto saggio dimenticarsi del concetto di variabile, di array, di salto condizionato, di ciclo ecc.. di programmazione procedurale in poche parole.

fek

19-10-2007, 12:58

Allo stato attuale sceglierei Ruby e C# anche se rimango dell'idea che una base di programmazione procedurale sia necessaria.

Alla fine tutto e' necessario per un buon programmatore, anche conoscere l'architettura a bassissimo livello di una CPU. La questione qui e' come arrivare ad accumulare tutti questi strumenti e da dove iniziare. Certamente e' meglio iniziare da cio' che e' piu' vicino al tuo modo di ragionare e modellare i problemi piuttosto che a quello della macchina.

k0nt3

19-10-2007, 12:59

Al thread starter consiglierei di iniziare con un linguaggio ad alto livello come Ruby o Python e poi passare a C# e Java appena si sente pronto ad affrontare qualcosa di piu' complesso. E infine, ma dopo molto tempo, passare al C++ per dare uno sguardo a qualcosa di davvero complesso.
certo meglio imparare 3 paradigmi tutti insieme :sofico: niente di più semplice

fek

19-10-2007, 13:01

la programmazione procedurale è UN paradigma che io sappia.. e non ritengo molto saggio dimenticarsi del concetto di variabile, di array, di salto condizionato, di ciclo ecc.. di programmazione procedurale in poche parole.

Sono stato molto lasco nella definizione. Programmazione procedurale o ad oggetti e' una collezione di paradigmi di programmazione, non un paradigma. Ma va comunque bene parlare di paradigma ad oggetti e paradigma procedurale per intendersi.

I concetti di variabile o vettore non c'entrano nulla con la programmazione procedurale, sono concetti che vanno al di la' dei paradigmi che li usano.

fek

19-10-2007, 13:03

certo meglio imparare 3 paradigmi tutti insieme :sofico: niente di più semplice

Non mi sembra di aver consigliato cio'.

variabilepippo

19-10-2007, 13:06

In realta' no.

Basta dare un'occhiata ai sorgenti di progetti tipo JVM, VirtualBox/Qemu/..., Linux & decine di altri sistemi operativi, compilatori di qualsiasi genere per rendersi conto che di "oggetti" da quelle parti ne girano davvero pochi.

kernel di Windows, ad esempio, ha ancora larghe parti in C per questione di compatibilita', ma la sua architettura e' totalmente "ad oggetti".

Hai accesso al codice di Windows? Puoi postare qualche riferimento al fatto che l'architettura sia "totalmente ad oggetti"? Nella documentazione del DDK ci sono molte note nelle quali si sconsiglia di realizzare drivers con linguaggi ad alto livello (C++ su tutti).

Per un kernel di un OS nuovo non avrebbe alcun senso scrivere in C piuttosto che in C++. BeOS era scritto in C++ ed e' tutt'oggi forse il migliore OS che abbia mai usato.

Ho usato BeOS per buona parte del 1997 ed in effetti è (era) un ottimo sistema operativo, però non mi risulta che ci siano altri sistemi operativi moderni (non parlo di toy-OS) sviluppati in C++. Esempi?

Il compiltatore C++ del VS2005 e' interamente scritto in C++ e compilato con se' stesso.

Riferimenti?

k0nt3

19-10-2007, 13:08

Sono stato molto lasco nella definizione. Programmazione procedurale o ad oggetti e' una collezione di paradigmi di programmazione, non un paradigma. Ma va comunque bene parlare di paradigma ad oggetti e paradigma procedurale per intendersi.

I concetti di variabile o vettore non c'entrano nulla con la programmazione procedurale, sono concetti che vanno al di la' dei paradigmi che li usano.
volevo dire programmazione strutturata per l'esattezza.. ho detto procedurale per generalizzazione, ma erroneamente

k0nt3

19-10-2007, 13:10

Non mi sembra di aver consigliato cio'.
hai consigliato python e ruby che sono due linguaggi multiparadigma

fek

19-10-2007, 13:10

Hai accesso al codice di Windows? Puoi postare qualche riferimento al fatto che l'architettura sia "totalmente ad oggetti"? Nella documentazione del DDK ci sono molte note nelle quali si sconsiglia di realizzare drivers con linguaggi ad alto livello (C++ su tutti).

Ho accesso a parti del codice (non tutto). E' molto interessante leggere Windows Internals dove e' descritta l'architettura ad oggetti del kernel, nonostante sia scritto in larga parte in C.

Ho usato BeOS per buona parte del 1997 ed in effetti è (era) un ottimo sistema operativo, però non mi risulta che ci siano altri sistemi operativi moderni (non parlo di toy-OS) sviluppati in C++. Esempi?

Cesare ti sapra' dare piu' esempi di quelli che conosco io a memoria. Il problema con gli OS e' che non si tende a svilupparne di nuovi perche' sono oggetti abbastanza "complessi". E quelli che esistono devono portarsi dietro molto codice legacy che non ha senso convertire a linguaggi ad alto livello.

Riferimenti?

Herb Sutter ne ha parlato spesso e volentieri.

fek

19-10-2007, 13:12

hai consigliato python e ruby che sono due linguaggi multiparadigma

Come qualunque altro linguaggio. Puoi programmare ad oggetti anche in C e assembly. Polemica sterile.

Ho consigliato due linguaggi ad alto livello che prediligono un paradigma ad oggetti sul quale consiglio di concentrarsi all'inizio.

k0nt3

19-10-2007, 13:20

Herb Sutter ne ha parlato spesso e volentieri.
questo non implica che sia a oggetti, magari lo è, ma non si capisce dal fatto che viene usato C++

Come qualunque altro linguaggio. Puoi programmare ad oggetti anche in C e assembly. Polemica sterile.

non è affatto una polemica.
C non supporta la programmazione a oggetti, il fatto che la puoi ottenere è un altro conto.

Ho consigliato due linguaggi ad alto livello che prediligono un paradigma ad oggetti sul quale consiglio di concentrarsi all'inizio.
perchè non imparare un linguaggio esclusivamente a oggetti allora?

fek

19-10-2007, 13:24

non è affatto una polemica.
C non supporta la programmazione a oggetti, il fatto che la puoi ottenere è un altro conto.

Il C supporta la programmazione ad oggetti perche' si puo' programmare ad oggetti.
Cio' che il C non mette a disposizione sono strumenti per facilitare la programmazione ad oggetti.

perchè non imparare un linguaggio esclusivamente a oggetti allora?

Perche' sia ruby sia python sono didatticamente ottimi linguaggi che consiglio, piu' di Smalltalk che e' decisamente arduo da masticare (tipico esempio di linguaggio fortemente ad oggetti).

Lo scopo e' introdurre un novizio alla programmazione, non ad una collezione di paradigmi in particolare.

mindwings

19-10-2007, 13:34

concordo con quello che dice fek :D
ammetto che non so ancora modellare come si deve una soluzione ad un problema , certe volte faccio poca analisi e vado gia ad occuparmi dei dettagli... un approccio completamente sbagliato :( . Un programmatore
deve saper risolvere problemi , il linguaggio è uno strumento e basta . Python è pseudocodice eseguibile quindi , quale strumento migliore per esprimere
soluzioni di un problema senza occuparsi dei dettagli :O

variabilepippo

19-10-2007, 13:35

Ho accesso a parti del codice (non tutto). E' molto interessante leggere Windows Internals dove e' descritta l'architettura ad oggetti del kernel, nonostante sia scritto in larga parte in C.

Ho avuto modo di dare un'occhiata al codice di Windows NT sul quale poggiano di sicuro anche 2000 e XP e dubito che Vista sia stato riscritto da zero, non ricordo di aver visto un'architettura ad oggetti né codice object-oriented propriamente detto. Russinovich e Solomon scrivono infatti:

"Most of the operating system code is written in C for portability and because C development tools are widely available. C doesn't directly support object-oriented constructs, such as dynamic binding of data types, polymorphic functions, or class inheritance. Therefore, the C-based implementation of objects in Windows borrows from, but doesn't depend on, features of particular object-oriented languages."

Di conseguenza non capisco come sia strutturata "l'architettura totalmente ad oggetti" di Windows. :confused:

E quelli che esistono devono portarsi dietro molto codice legacy che non ha senso convertire a linguaggi ad alto livello.

Nell'articolo C++ for Kernel Mode Drivers - Pros and Cons (http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx) si discutono gli svantaggi ed i vantaggi dell'uso di un linguaggio high-level nello sviluppo di codice kernel-mode. Il riferimento diretto ai drivers, ma molte considerazioni valgono anche fuori dal contesto specifico. Non è esclusivamente un problema di codice legacy...

Herb Sutter ne ha parlato spesso e volentieri.

Mi deve essere sfuggito, eppure seguo molto i lavori e le pubblicazioni di Sutter. :cry:

AnonimoVeneziano

19-10-2007, 13:38

Python è pseudocodice eseguibile quindi , quale strumento migliore per esprimere
soluzioni di un problema senza occuparsi dei dettagli :O

mah, su questo avrei dei dubbi :D

A me python sembra tutt'altro che leggibile lol :p

k0nt3

19-10-2007, 13:42

Il C supporta la programmazione ad oggetti perche' si puo' programmare ad oggetti.
Cio' che il C non mette a disposizione sono strumenti per facilitare la programmazione ad oggetti.

ma per favore, il C non supporta la programmazione a oggetti perchè te la devi costruire a partire dalla programmazione procedurale

Perche' sia ruby sia python sono didatticamente ottimi linguaggi che consiglio, piu' di Smalltalk che e' decisamente arduo da masticare (tipico esempio di linguaggio fortemente ad oggetti).

Lo scopo e' introdurre un novizio alla programmazione, non ad una collezione di paradigmi in particolare.
java non potrebbe essere un esempio di linguaggio a oggetti semplice da masticare?
il punto a cui voglio arrivare comunque è che se inizi con ruby o python noterai che i primi programmi che scrivi sono procedurali perchè questi due linguaggi supportano anche questo paradigma (in realtà ruby è imperativo per dovere di cronaca).
allora la questione è:
meglio imparare tutti i paradigmi usando un solo linguaggio o imparare ciascun paradigma con un linguaggio distinto? la risposta è boh, però so per certo che imparare diversi linguaggi è cosa buona e giusta™

fek

19-10-2007, 13:46

Di conseguenza non capisco come sia strutturata "l'architettura totalmente ad oggetti" di Windows. :confused:

Innanzi tutto chiariamo un concetto: programmare ad oggetti significa modellare i concetti di un sistema per mezzo di oggetti che sono una collezione di dati e di operazioni su questi dati.
Se guardi l'API di Windows esposta dal kernel, e' un'insieme di oggetti (mutex, processi, thread ad esempio) con le loro operazioni.

Vedi tutte chiamate tipo:
Operazione(Oggetto, parametri...)

Anche la documentazione parla sempre in termini di "oggetti".

Il kernel di Windows e' un ottimo esempio di design ad oggetti, implementato in C per questioni storiche e di convenienza economica.

Nell'articolo C++ for Kernel Mode Drivers - Pros and Cons (http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx) si discutono gli svantaggi ed i vantaggi dell'uso di un linguaggio high-level nello sviluppo di codice kernel-mode. Il riferimento diretto ai drivers, ma molte considerazioni valgono anche fuori dal contesto specifico. Non è esclusivamente un problema di codice legacy...

Occhio che in questo articolo si discutono i vantaggi e svantaggi dell'uso di determinati costrutti del C++ (ad esempio new, l'uso di oggetti temporanei creati sullo stack, etc...).
Io non scriverei un driver usando oggetti temporanei a tappeto, ad esempio. Ma non lo scrivere in C perche' non ha alcun senso visto che non c'e' un costrutto C che non possa essere scritto in C++ con la medesima efficienza.

sirus

19-10-2007, 13:46

mah, su questo avrei dei dubbi :D

A me python sembra tutt'altro che leggibile lol :p
Concordo, anche a me non piace il Python. :asd:

mindwings

19-10-2007, 13:47

già che siamo in tema . Come si impara a modellare la soluzione di un problema? Consigliate delle letture in merito ? grazie:)

variabilepippo

19-10-2007, 13:48

Concordo, anche a me non piace il Python

Molto meglio il C, vero? :sbonk:

^TiGeRShArK^

19-10-2007, 13:49

Molto meglio il C, vero? :sbonk:

:asd:

fek

19-10-2007, 13:50

ma per favore, il C non supporta la programmazione a oggetti perchè te la devi costruire a partire dalla programmazione procedurale

Ti stai, nuovamente creando le tue definizioni per darti ragione.
Si puo' programmare ad oggetti in C? Si'. Quindi supporta il paradigma ad oggetti, ma non lo facilita con alcun supporto.
Fine della questione.

java non potrebbe essere un esempio di linguaggio a oggetti semplice da masticare?

Potrebbe ma personalmente non lo consiglio perche' l'ambiente Java non e' facile da masticare per un novizio.

il punto a cui voglio arrivare comunque è che se inizi con ruby o python noterai che i primi programmi che scrivi sono procedurali perchè questi due linguaggi supportano anche questo paradigma (in realtà ruby è imperativo per dovere di cronaca).

Il punto al quale vuoi arrivare e' errato perche' nessuno costringe a scrivere i primi programmi procedurali, ma ruby e python promuovono paradigmi ad oggetti che sono piu' naturali per il novizio.

Dal sito di Ruby:
You may program procedurally if you like (but it will still be object-oriented behind the scenes).

sirus

19-10-2007, 13:54

Molto meglio il C, vero? :sbonk:
Sinceramente non vedo tutta questa difficoltà nel leggere del codice C e non mi pare che Python sia molto più leggibile e se devo scegliere se fare un programma in C oppure in Python (supponendo di non utilizzare il paradigma ad oggetti) scelgo molto più volentieri il C. :O

mindwings

19-10-2007, 13:56

Sinceramente non vedo tutta questa difficoltà nel leggere del codice C e non mi pare che Python sia molto più leggibile e se devo scegliere se fare un programma in C oppure in Python (supponendo di non utilizzare il paradigma ad oggetti) scelgo molto più volentieri il C. :O

forse è questione di abitudine :D

k0nt3

19-10-2007, 13:58

Ti stai, nuovamente creando le tue definizioni per darti ragione.
Si puo' programmare ad oggetti in C? Si'. Quindi supporta il paradigma ad oggetti, ma non lo facilita con alcun supporto.
Fine della questione.

se qui c'è qualcuno che inventa definizioni ad arte sei te mi sa :D
hai appena detto che il C supporta la programmazione a oggetti ma non fornisce supporto ad essa. mi sa che viene fuori una contraddizione

Potrebbe ma personalmente non lo consiglio perche' l'ambiente Java non e' facile da masticare per un novizio.

in cosa è più difficile rispetto a python o ruby?

Il punto al quale vuoi arrivare e' errato perche' nessuno costringe a scrivere i primi programmi procedurali, ma ruby e python promuovono paradigmi ad oggetti che sono piu' naturali per il novizio.

il primo programma in python sarà questo con ogni probabilità
print "Hello, world!"
in ruby
puts "Hello, world!"

fek

19-10-2007, 14:02

se qui c'è qualcuno che inventa definizioni ad arte sei te mi sa :D
hai appena detto che il C supporta la programmazione a oggetti ma non fornisce supporto ad essa. mi sa che viene fuori una contraddizione

Innanzi tutto rilassati e rivolgiti con rispetto, perche' quando hai torto la butti sempre sul personale.
In quello che ho scritto non c'e' alcuna contraddizione, stai facendo molta confusione fra i concetti di supporto e supporto nativo.
In C puoi programmare ad oggetti? Si'. Quindi supporta la programmazione ad oggetti ma non fornisce alcuno strumento sintattico per facilitarla.

in cosa è più difficile rispetto a python o ruby?

Rispondi tu alla domanda.

il primo programma in python sarà questo con ogni probabilità
print "Hello, world!"
in ruby
puts "Hello, world!"

Stai mandando un messaggio puts all'oggetto (implicito) standard output. E' un programma ad oggetti, e come tale e' implementato nel runtime.

"You may program procedurally if you like (but it will still be object-oriented behind the scenes)."

variabilepippo

19-10-2007, 14:04

Se guardi l'API di Windows esposta dal kernel, e' un'insieme di oggetti (mutex, processi, thread ad esempio) con le loro operazioni.

Vedi tutte chiamate tipo:
Operazione(Oggetto, parametri...)

Anche la documentazione parla sempre in termini di "oggetti"

Anche la tazzina di caffè che sto bevendo è un "oggetto", peccato che non abbia nulla in comune con la "programmazione ad oggetti" né con il concetto di "oggetto" comunemente accettato in OOP. Alla voce "oggetto" del mio dizionario c'è scritto:

"cosa con una forma definita spec. prodotta dall'uomo"

quindi qualsiasi cosa, anche un mutex o un processo risultano "oggetti", io userei il termine "entità" per non creare confusione con altre accezioni del termine "oggetto"...

Vedi tutte chiamate tipo:
Operazione(Oggetto, parametri...)

Quelle esposte dalla Windows API sono funzioni (http://msdn2.microsoft.com/en-us/library/aa383688.aspx), o sbaglio?

Occhio che in questo articolo si discutono i vantaggi e svantaggi dell'uso di determinati costrutti del C++

Non parliamo certo di costrutti di secondaria importanza... Riporto le conclusioni:

Summary
Microsoft neither endorses nor prohibits the use of C++ for kernel-mode drivers. This conservative position is driven in part by the issues described in this paper, and in part by the need to support all platforms. You must be aware of known problems and risks described in this paper before attempting any development in C++ for kernel mode, and you should be alert for other issues not yet identified.

Microsoft is actively investigating ways of making C++ more usable in the kernel. It is not yet known whether all of the C++ features that can be applied to user-mode code can be made available for kernel-mode code.

• The use of the C++ compiler as a “super-C” is typically expected to work, but such use of the compiler is at the developer’s own risk.

• It is currently impractical to identify problematic C++ constructs mechanically, so developers must carefully analyze the compiler output to ensure that the generated code is suitable for kernel mode.

• Before committing to the use of C++, you should carefully assess whether it will work for you. In particular, you should test C++ constructs early in the development process, to ensure that the constructs do not cause the problems described in this paper or otherwise violate the principles of kernel-mode driver writing.

• Some of the problems discussed in this paper might not become apparent until near the end of development, and that solving them might require code to be completely rewritten.

• Several of the most insidious problems are extremely difficult to reproduce on demand while testing the driver, so a driver with an inherent unreliability might appear to run for extended periods with no problems and fail at random times. This reinforces the need for careful analysis.

In breve, "Programmatore avvisato, mezzo salvato: NON usate il C++ per il codice kernel mode". ;)

fek

19-10-2007, 14:14

quindi qualsiasi cosa, anche un mutex o un processo risultano "oggetti", io userei il termine "entità" per non creare confusione con altre accezioni del termine "oggetto"...

Nella documentazione sono proprio definiti "objects" e sono implementati come tali.

Quelle esposte dalla Windows API sono funzioni (http://msdn2.microsoft.com/en-us/library/aa383688.aspx), o sbaglio?

E' proprio qui il punto. Si puo' programmare ad oggetti anche in assembly. Se tu scrivi una cosa come questa:

struct Mutex
{
// members
};

Initialise(Mutex* mutex, ...);

... stai scrivendo ad oggetti, perche' stai definendo un oggetto Mutex come un insieme di proprieta' e un insieme di messaggi ai quali risponde che fanno parte della sua interfaccia pubblica. Se guardi l'API di Win32 e' quasi interamente scritta in questo modo, infatti e' un ottimo esempio di design ad oggetti. Puoi creare ottimi design ad oggetti senza mai derivare un singolo oggetto, ad esempio (anzi, spesso e' consigliato non abusare dell'ereditarieta').

Non parliamo certo di costrutti di secondaria importanza... Riporto le conclusioni:

Anche questo e' un punto interessante: molti pensano che programmare in C++ significa usare costrutti come new, eccezioni, template. Non e' vero.
Programmare in C++ significa usare il linguaggio nella maniera piu' semplice per risolvere il problema: puoi scrivere milioni di righe di codice in C++ senza usare le eccezioni (ad esempio in un gioco non le usi mai).

Quell'articolo sta descrivendo tutti i potenziali problemi che i costrutti del C++ possono creare in kernel mode, ma e' ovvio: in kernel mode non ti metti a lanciare eccezioni o a creare oggetti globali allegramente che vengono inizializzati con ordine casuale.

Ogni costrutto di un linguaggio e' di secondaria importanza se non serve a risolvere il proprio problema. Non va usato.

In breve, "Programmatore avvisato, mezzo salvato: NON usate il C++ per il codice kernel mode". ;)

Microsoft non dice di non usare il C++, dice che ci sono dei problemi con molti costrutti ad alto livello e li descrive. E poi conclude:

Microsoft neither endorses nor prohibits the use of C++ for kernel-mode drivers. [...]
The use of the C++ compiler as a “super-C” is typically expected to work, but such use of the compiler is at the developer’s own risk.

Ecco, dovessi scrivere un driver, userei il C++ come un "super-C", perche' e' stato disegnato anche per questo scopo.

AnonimoVeneziano

19-10-2007, 14:16

Molto meglio il C, vero? :sbonk:

Nessuno ha detto che il python fa schifo in senso generico. E' un linguaggio molto funzionale e pieno di potenziale , ma ... "da leggere" fa schifo :p

E' proprio brutto , con tutti quei "self" e "__" boh , è brutto :Prrr: (Certo, la "bellezza" di un linguaggio non è comunque uno dei parametri migliori per descriverne la bonta ...)

k0nt3

19-10-2007, 14:20

Innanzi tutto rilassati e rivolgiti con rispetto, perche' quando hai torto la butti sempre sul personale.
In quello che ho scritto non c'e' alcuna contraddizione, stai facendo molta confusione fra i concetti di supporto e supporto nativo.
In C puoi programmare ad oggetti? Si'. Quindi supporta la programmazione ad oggetti ma non fornisce alcuno strumento sintattico per facilitarla.

ho trovato questa definizione di supportare un paradigma, ma non quella che hai dato te http://web.cs.mun.ca/~ulf/pld/archi.html
«A language is said to support a style of programming [aka paradigm] if it provides facilities that makes[!] it convenient (reasonably easy, safe, and efficient) to use that style. A language does not support a technique if it takes exceptional effort or exceptional skill to write such programs; it merely enables the technique to be used. For example, you can write structured programs in Fortran, write type-secure programs in C, and use data abstraction in Modula-2, but it is unnecessarily hard to do because these languages do not support those techniques.
Support for a paradigm comes not only in the obvious form of language facilities that allow direct use of the paradigm, but also in the more subtle form of compile-time and/or run-time checks agains unintended deviation from the paradigm. ... Extra-linguistic facilities such as standard libraries and programming environments can also provide significant support for paradigms.»
quindi è diverso dire che C permette la programmazione OO, rispetto a supporta la programmazione OO..

Rispondi tu alla domanda.

java è più difficile all'inizio perchè sei costretto a costruire come minimo un oggetto e quindi sei costretto a essere consapevole di programmare a oggetti.
ma a questo punto mi sono dimenticato perchè stavamo dicendo che è meglio iniziare subito dagli oggetti :fagiano:

Stai mandando un messaggio puts all'oggetto (implicito) standard output. E' un programma ad oggetti, e come tale e' implementato nel runtime.

ci vuole molta fantasia.. io da quel codice non vedo niente di tutto ciò

fek

19-10-2007, 14:20

Nessuno ha detto che il python fa schifo. E' un linguaggio molto funzionale e pieno di potenziale , ma ... da leggere fa schifo :p

E' proprio brutto , con tutti quei "self" e "__" boh , è brutto :Prrr: (Certo, la "bellezza" di un linguaggio non è comunque uno dei parametri migliori per descriverne la bonta ...)

Anch'io non amo particolarmente Python, anzi.

fek

19-10-2007, 14:25

ho trovato questa definizione di supportare un paradigma, ma non quella che hai dato te

Invece e' esattamente equivalente: il C ha tutti i costrutti necessari per programmare ad oggetti (strutture e funzioni), ma non ha alcun costrutto che facilita questo compito (le classi).

Non si programma ad oggetti quando si scrive una classe, ma quando si incapsula codice e dati e si stabiliscono le relazioni fra oggetti in termini di scambi di messaggi.
Il C ha tutto il necessario per supportare questo stile.

java è più difficile all'inizio perchè sei costretto a costruire come minimo un oggetto e quindi sei costretto a essere consapevole di programmare a oggetti.
ma a questo punto mi sono dimenticato perchè stavamo dicendo che è meglio iniziare subito dagli oggetti :fagiano:

Java e' piu' difficile per un neofita perche' si trova di fronte un ambiente ostico da configurare e comprendere, per questo non lo consiglio. Dover comprendere come funziona il CLASS_PATH per un neofita non e' esattamente ideale, ad esempio. Ho fatto fatica io a configurare l'ambiente Java per Diamonds la prima volta ed arrivo da 20 anni di programmazione.
Il linguaggio in se' e' assolutamente ottimo e non c'e' nulla di complesso nel dover definire un oggetto per un neofita. E' ostico per chi e' abituato a anni di programmazione procedurale.

ci vuole molta fantasia.. io da quel codice non vedo niente di tutto ciò

Non ci vuole fantasia, basta sapere che vuol dire programmare ad oggetti, infatti non faccio fatica a credere che tu non ci veda nulla di tutto cio'.

variabilepippo

19-10-2007, 14:36

Nella documentazione sono proprio definiti "objects" e sono implementati come tali.

A questo punto dovresti definire cos'è un "oggetto" ed in che senso un thread, nella Windows API, sia implementato come tale. Dove sono i metodi? Si può ereditare un mutex? Esistono "oggetti semaforo" polimorfi?

Se guardi l'API di Win32 e' quasi interamente scritta in questo modo, infatti e' un ottimo esempio di design ad oggetti.

Punto di vista molto personale, a me sembra un design ASSOLUTAMENTE procedurale, come tutte le vecchie API. Discorso diverso per framework più moderni come VCL, MFC, .NET e Java nei quali si lavora con dei VERI oggetti. Infatti definire una variabile di un certo tipo e richiamare proceduralmente delle functions non ha nulla del paradigma ad oggetti.

Anche questo e' un punto interessante: molti pensano che programmare in C++ significa usare costrutti come new, eccezioni, template.

Se usi solo ciò che potrebbe compilare un compilatore C stai effettivamente programmando in C. Il C++, come ben sai, ha delle caratteristiche (sintattiche E concettuali) che lo differenziano dal C, si può decidere (consapevolmente o inconsapevolmente) di non usarle per una lunga serie di motivi, ma in tal caso non si sta programmando in C++.

k0nt3

19-10-2007, 14:38

Invece e' esattamente equivalente: il C ha tutti i costrutti necessari per programmare ad oggetti (strutture e funzioni), ma non ha alcun costrutto che facilita questo compito (le classi).

Non si programma ad oggetti quando si scrive una classe, ma quando si incapsula codice e dati e si stabiliscono le relazioni fra oggetti in termini di scambi di messaggi.
Il C ha tutto il necessario per supportare questo stile.

il C in realtà non ha niente di tutto ciò. ha solo le struct e i puntatori a funzione.
ma anche ammettendo che fin qui lo sforzo non è eccessivo, è arduo pensare alla programmazione OO senza ereditarietà, information hiding, polimorfismo ecc..

Java e' piu' difficile per un neofita perche' si trova di fronte un ambiente ostico da configurare e comprendere. Il linguaggio in se' e' assolutamente ottimo e non c'e' nulla di complesso nel dover definire un oggetto per un neofita. E' ostico per chi e' abituato a anni di programmazione procedurale.

ma non è affatto ostico da configurare. anzi è più semplice rispetto a molti altri ambienti.
ritengo ostico iniziare con class nome {... main() ...} per il semplice fatto che questo richiede un bel pò di teoria alle spalle, mentre per main() {...} basta sapere cos'è una funzione

EDIT: ho visto ora la modifica :p

Non faccio fatica a credere che tu non ci veda nulla di tutto cio'.
il problema è che non si capisce quale oggetto manda il messaggio allo standard output. perchè si possa parlare di scambio di messaggi è necessario un mittente e un destinatario :fagiano:

k0nt3

19-10-2007, 14:42

ma soprattutto il C non permette di programmare a oggetti in maniera sicura perchè ad esempio il compilatore non ti avvisa se stai violando il paradigma OO, quindi rientriamo sempre nella definizione di permette ma non supporta

fek

19-10-2007, 14:44

A questo punto dovresti definire cos'è un "oggetto" ed in che senso un thread, nella Windows API, sia implementato come tale. Dove sono i metodi? Si può ereditare un mutex? Esistono "oggetti semaforo" polimorfi?

Non ti fossilizzare sulla sintassi, ma guarda la semantica di cio' che si sta scrivendo.
Initialise e' un "metodo", un "messaggio" inviato all'oggetto "Mutex" che risponde eseguendo un'azione (si inizializza in questo caso).
Herb Sutter, addirittura consiglia di implementare in C++ i metodi come free function esterne alla definizione della classe, e questo ha una logica.

Si puo' ereditare un Mutex:

struct MyMutex
{
struct Mutex parent;
// ... my new properties
};

InitializeMyMutex(MyMutex* mutex, Mutex* parent, ...);

Ma di nuovo: puoi scrivere ad oggetti senza mai ereditare nulla. Un oggetto e' una collezione di proprieta' ed azioni che svolge (o messaggi ai quali risponde).

Punto di vista molto personale, a me sembra un design ASSOLUTAMENTE procedurale

Non e' un punto di vista, e' un design ad oggetti.
Ti consiglio un libro di Lippman che descrive come i costrutti del C++ sono implementati in C, e' assolutamente da non perdere perche' spiega proprio questi concetti meglio di come possa fare io.
Un oggetto C++, in C, e' implementato dal vecchio CFront esattamente con codice simile a quello che ho scritto qui.

Se usi solo ciò che potrebbe compilare un compilatore C stai effettivamente programmando in C. Il C++, come ben sai, ha delle caratteristiche (sintattiche E concettuali) che lo differenziano dal C, si può decidere (consapevolmente o inconsapevolmente) di non usarle per una lunga serie di motivi, ma in tal caso non si sta programmando in C++.

Ti consiglio vivamente di leggere Design And Evolution of C++ di Stroustrup che afferma proprio il contrario di quello che dici: il C++ e' stato espressamente disegnato di modo da poter essere usato semplicemente come un C migliore e usarlo come C migliore significa proprio programmare in C++.

Non devi usare per forza un costrutto solo perche' il linguaggio lo prevede, ma devi usare i costrutti che servono a te.

k0nt3

19-10-2007, 14:45

per quanto riguarda le difficoltà dell'ambiente java.. il classpath inizialmente lo puoi tranquillamente ignorare. per imparare java è più che sufficiente quello che c'è di default nel framework.

^TiGeRShArK^

19-10-2007, 14:46

Nessuno ha detto che il python fa schifo in senso generico. E' un linguaggio molto funzionale e pieno di potenziale , ma ... "da leggere" fa schifo :p

E' proprio brutto , con tutti quei "self" e "__" boh , è brutto :Prrr: (Certo, la "bellezza" di un linguaggio non è comunque uno dei parametri migliori per descriverne la bonta ...)

gli __ sono cose che non si possono vedere secondo me :asd:
mi stanno profondamente sulle bolas :O
infatti a livelo prettamente di "lingua" preferisco ruby rispetto al python :fagiano:

fek

19-10-2007, 14:48

il C in realtà non ha niente di tutto ciò. ha solo le struct e i puntatori a funzione.
ma anche ammettendo che fin qui lo sforzo non è eccessivo, è arduo pensare alla programmazione OO senza ereditarietà, information hiding, polimorfismo ecc..

E' arduo per te pensare alla programmazione OO senza ereditarieta' e polimorfismo. Ho scritto interi sistemi ad oggetti senza mai ereditare e senza una funzione virtuale (in C++).
Al di la' del fatto che si puo' fare polimorfismo in C, e' supportato, basta avere strutture e funzioni.
Non c'e' nulla che lo faciliti.

ma non è affatto ostico da configurare. anzi è più semplice rispetto a molti altri ambienti.
ritengo ostico iniziare con class nome {... main() ...} per il semplice fatto che questo richiede un bel pò di teoria alle spalle, mentre per main() {...} basta sapere cos'è una funzione

Lo ritieni ostico tu che sei abituato a programmare proceduralmente. Io no.

il problema è che non si capisce quale oggetto manda il messaggio allo standard output. perchè si possa parlare di scambio di messaggi è necessario un mittente e un destinatario :fagiano:

Questo e' un problema tuo. Nel momento in cui e' chiaro il concetto di programmazione ad oggetti, e' chiaro come quel codice stia spedendo un messaggio allo standard output per visualizzare una stringa. Il destinatario e' sott'inteso.

x = 2 + 2;

L'oggetto 2 riceve il messaggio + con argomento 2. L'oggetto x riceve il messaggio di assegnazione con argomento 4. Smalltalk e' implementato esattamente cosi'.

k0nt3

19-10-2007, 14:49

Si puo' ereditare un Mutex:

struct MyMutex
{
struct Mutex parent;
// ... my new properties
};

InitializeMyMutex(MyMutex* mutex, Mutex* parent, ...);

non stai ereditando da un oggetto, ma stai creando una struct che contiene un'altra struct. te ne accorgi che non si tratta di ereditarietà perchè se provi a utilizzare MyMutex come se fosse Mutex succedono casini.
inoltre InitializeMyMutex non sta mandando un messaggio perchè manca il mittente del messaggio

k0nt3

19-10-2007, 14:52

E' arduo per te pensare alla programmazione OO senza ereditarieta' e polimorfismo. Al di la' del fatto che si puo' fare polimorfismo in C, e' supportato, basta avere strutture e funzioni.
Non c'e' nulla che lo faciliti.

il polimorfismo non è supportato. è permesso usarlo fornendone un'implementazione, ma non è supportato

Lo ritieni ostico tu che sei abituato a programmare proceduralmente. Io no.

non sono affatto abituato a programmare proceduralmente. programmo esclusivamente a oggetti da un pò di anni

Questo e' un problema tuo. Nel momento in cui e' chiaro il concetto di programmazione ad oggetti, e' chiaro come quel codice stia spedendo un messaggio allo standard output per visualizzare una stringa. Il destinatario e' sottinteso.

il mittente manca.. non il destinatario

fek

19-10-2007, 14:52

per quanto riguarda le difficoltà dell'ambiente java.. il classpath inizialmente lo puoi tranquillamente ignorare. per imparare java è più che sufficiente quello che c'è di default nel framework.

Se ignori il concetto di classpath non riesci a scrivere nulla di vagamente utile al di la' di Hello World. Imparare a programmare significa scrivere cose utili, non salutare il mondo.

k0nt3

19-10-2007, 14:54

Se ignori il concetto di classpath non riesci a scrivere nulla di vagamente utile al di la' di Hello World. Imparare a programmare significa scrivere cose utili, non salutare il mondo.
cosa manca al framework java per fare qualcosa di utile?

fek

19-10-2007, 14:56

non stai ereditando da un oggetto, ma stai creando una struct che contiene un'altra struct. te ne accorgi che non si tratta di ereditarietà perchè se provi a utilizzare MyMutex come se fosse Mutex succedono casini.
inoltre InitializeMyMutex non sta mandando un messaggio perchè manca il mittente del messaggio

Inventi un'altra definizione. Un oggetto eredita da un altro quando ne estende il comportamento, come nel codice che ho scritto dove MyMutex estende il comportamento di Mutex e puo' essere usato come Mutex cosi':

DestroyMutex(my_mutex->parent);

Per inciso, il meccanismo di l'ereditarieta' del C++ e' implementato da CFront esattamente cosi'.

Diventa noioso e improduttivo discutere cosi'.

il polimorfismo non è supportato. è permesso usarlo fornendone un'implementazione, ma non è supportato

No, e' supportato. Esistono i puntatori a funzione che bastano e avanzano per implementare un comportamento polimorfico.

CFront implementa il meccanismo del polimorfismo in C usando tabelle di puntatori a funzione (la vtable).

non sono affatto abituato a programmare proceduralmente. programmo esclusivamente a oggetti da un pò di anni

Da quello che scrivi mi risulta difficile da credere.

il mittente manca.. non il destinatario

No, il destinatario e' sott'inteso. Il mittente e' l'ambiente che manda un messaggio all'oggetto, in questo caso l'oggetto nel quale quel codice e' dichiarato, ovvero il programma stesso. Sono le basi della programmazione ad oggetti, per questo mi risulta difficile credere che tu programmi ad oggetti quando ti mancano le nozioni di base.

The definition from SmalltalkLanguage: A message is simply a method call on an object. Smalltalk messages are perfectly synchronous (the caller waits for the callee to return a value), and not terribly different then function/method calls in other languages.

k0nt3

19-10-2007, 15:02

Inventi un'altra definizione. Un oggetto eredita da un altro quando ne estende il comportamento, come nel codice che ho scritto dove MyMutex estende il comportamento di Mutex.
il problema è che non ne estende il comportamento. sarebbe come dire che una classe fatta così:

class MyClass {
...
Integer campoIntero;
...
}

estende Integer
ma sappiamo tutti e due che non è vero

No, e' supportato. Esistono i puntatori a funzione che bastano e avanzano per implementare un comportamento polimorfico.

se lo devi implementare non è supportato

No, il destinatario e' sott'inteso. Il mittente e' l'ambiente che manda manda un messaggio all'oggetto. Sono le basi della programmazione ad oggetti.
sarà, ma le basi della programmazione OO sono che ci sono degli oggetti che mandano messaggi a altri oggetti.

fek

19-10-2007, 15:07

il problema è che non ne estende il comportamento. sarebbe come dire che una classe fatta così:

class MyClass {
...
Integer campoIntero;
...
}

estende Integer
ma sappiamo tutti e due che non è vero

Questo e' un esempio di Composizione, diverso dal concetto di Ereditarieta'.
Una macchina "e' composta da" ruote e motore, MyClass "e' composta da" un Integer, MyMutex "e' un" Mutex. Sono concetti diversi.

se lo devi implementare non è supportato

Definizione inventata.

sarà, ma le basi della programmazione OO sono che ci sono degli oggetti che mandano messaggi a altri oggetti.

Esatto, cosa che ancora non ti e' chiara e che non ti ripetero' ulteriormente.

k0nt3

19-10-2007, 15:11

Questo e' un esempio di Composizione, diverso dal concetto di Ereditarieta'.
Una macchina "e' composta da" ruote e motore, MyClass "e' composta da" un Integer, MyMutex "e' un" Mutex. Sono concetti diversi.

dal codice che hai scritto MyMutex è composta da un Mutex tra le altre cose

Definizione inventata.

almeno la mia trova riscontro in altre persone. la tua nemmeno quello

Esatto, cosa che ancora non ti e' chiara e che non ti ripetero' ulteriormente.
ma l'oggetto ambiente non esiste, è solo una roba inventata per fa quadrare i conti.

fek

19-10-2007, 15:14

dal codice che hai scritto MyMutex è composta da un Mutex tra le altre cose

No. Anche il nome che ho scelto per l'oggetto dovrebbe suggerirti l'errore che stai commettendo. Anche qui stai ignorando le basi della programmazione ad oggetti confondendo Composizione e Ereditarieta'. La differenza non e' sintattica, e' sematica.

Ad esempio in C++:

class MyObject: private Integer
{
};

Questo e' un esempio di Composition in C++ (per la verita' poco elegante ma perfettamente legale), implementato con il costrutto con il quale di solito si implementa l'Inheritance (notare la parola chiave private che in C++ indica proprio l'intenzione di fare Composition).

class Speed: public Integer
{
};

Questo e' un (comunissimo) errore di programmazione. Speed e' un oggetto composto semanticamente da un intero, ma non e' un intero, pero' e' descritto dal programmatore come tale.
Un'implementazione piu' corretta e' usare la keyword private, ma l'implementazione piu' corretta e' questa:

class Speed
{
Integer value;
};

MyMutex in C++:

class MyMutex: public Mutex
{
};

Il nome dell'oggetto suggerisce Ereditarieta' e in C si traduce cosi' (CFront lo tradurrebbe cosi'):

struct MyMutex
{
struct Mutex parent;
}

Esempio d'uso in C:

void CreateProcess(Process* process, ...)
{
MyMutex* my_mutex;
InitializeMutex(&my_mutex->parent, ...);

// ...

LockMutex(&my_mutex->parent);
}

L'oggetto processs manda un messaggio all'oggetto my_mutex di inizializzare il suo parente e poi di
lockarlo. Questo e' OO in C. Una noia mortale, meglio programmare direttamente in C++ con tutte le facilitazioni del caso.

almeno la mia trova riscontro in altre persone. la tua nemmeno quello

No. La tua non trova riscontro neppure nell'evidenza delle cose: si puo' programmare ad oggetti in C quindi lo supporta, con un supporto primitivo (funzioni, strutture, puntatori). Altri linguaggi supportano la programmazione ad oggetti con costrutti piu' avanzati (classi ad esempio).

ma l'oggetto ambiente non esiste, è solo una roba inventata per fa quadrare i conti.

Esiste eccome, il mittente e' l'oggetto chiamante. Ripeto, sono le basi della programmazione ad oggetti che stai totalmente ignorando.

k0nt3

19-10-2007, 15:25

nonostante i miei sforzi non hai ancora chiara la differenza tra permettere e supportare.
in ogni modo non ho altro da aggiungere a quello che è stato già detto, per cui penso non mi ripeterò

fek

19-10-2007, 15:28

nonostante i miei sforzi non hai ancora chiara la differenza tra permettere e supportare.
in ogni modo non ho altro da aggiungere a quello che è stato già detto, per cui penso non mi ripeterò

La differenza purtroppo per te mi e' perfettamente chiara, come mi e' chiaro il concetto di programmazione orientata agli oggetti.
Ti consiglio di indirizzare i tuoi sforzi verso qualcosa di piu' costruttivo che cercare con ogni mezzo di aver ragione su un forum negando l'evidenza e confondendo l'idea a chi, come te, questi concetti deve ancora assimilarli.

E' decisamente molto meglio che non aggiungi altro.

k0nt3

19-10-2007, 15:36

La differenza purtroppo per te mi e' perfettamente chiara, come mi e' chiaro il concetto di programmazione orientata agli oggetti.
Ti consiglio di indirizzare i tuoi sforzi verso qualcosa di piu' costruttivo che cercare con ogni mezzo di aver ragione su un forum confondendo l'idea a chi, come te, questi concetti deve ancora assimilarli.

E' decisamente molto meglio che non aggiungi altro.
e poi sarei io che vado sul personale? smettila di provocarmi affermando che devo ancora assimilare i concetti della programmazione OO, non ho certo bisogno del tuo consenso.
prova a portare delle argomentazioni valide piuttosto perchè finora ho visto ben poco.
hai detto che MyMutex eredita da Mutex anche per via del nome, ma la semantica che il C da al nome delle variabili è di tutt'altra natura, quindi di fatto stai aggiungendo qualcosa al linguaggio rendendolo più ricco. qualcosa di cui il compilatore non è al corrente però (a meno che non ne scrivi uno te)

fek

19-10-2007, 15:37

e poi sarei io che vado sul personale? smettila di provocarmi affermando che devo ancora assimilare i concetti della programmazione OO, non ho certo bisogno del tuo consenso.

Non e' una provocazione, e' la realta' che traspare da cio' che scrivi, dal momento che in un semplice costrutto non riesci ad individuare mittente e destinatario di un messaggio, e confondi i concetti di Composizione e Ereditarieta'.

prova a portare delle argomentazioni valide piuttosto perchè finora ho visto ben poco.

L'ho fatto. Rileggile con piu' attenzione e vedrai di piu'.

k0nt3

19-10-2007, 15:40

Non e' una provocazione, e' la realta' che traspare da cio' che scrivi.

linkami dove traspare allora, se ne può discutere.

L'ho fatto. Rileggile con piu' attenzione.
leggendo attentamente vedo solo affermazioni che consideri vere a priori senza ulteriori argomentazioni

variabilepippo

19-10-2007, 18:55

Non ti fossilizzare sulla sintassi, ma guarda la semantica di cio' che si sta scrivendo.

La Windows API è un interfaccia utilizzabile in maniera puramente procedurale, se vogliamo allargare il concetto di OOP al fine di inglobarvi anche l'API Win32 per me va bene, ma a questo punto mi chiedo come possono definirsi API e wrapper realmente object-oriented (composti cioè da classi, da classi ereditabili con il supporto nativo per l'ereditarietà ed il polimorfismo).

Mi chiedo inoltre come si possa distinguere, dal tuo punto di vista, un'API procedurale da una basata su oggetti...

Herb Sutter, addirittura consiglia di implementare in C++ i metodi come free function esterne alla definizione della classe, e questo ha una logica.

Una volta delineato il contesto qualsiasi cosa può avere una logica.

Ti consiglio vivamente di leggere Design And Evolution of C++ di Stroustrup che afferma proprio il contrario di quello che dici: il C++ e' stato espressamente disegnato di modo da poter essere usato semplicemente come un C migliore e usarlo come C migliore significa proprio programmare in C++.

È proprio grazie a "Design And Evolution of C++", "The C++ Programming Language (Stroustrup)", ai numerosi paper di Stroustrup, a "Modern C++ Design" di Alexandrescu, ai testi di Sutter e a Accelerated C++ di Koenig che si possono apprezzare le differenze tra C e C++.

Non devi usare per forza un costrutto solo perche' il linguaggio lo prevede, ma devi usare i costrutti che servono a te.

Certo, ma perché limitarsi al subset C (tanto vale usare direttamente il C allora) quando il C++ ci mette a disposizione una ricchissima cassetta degli attrezzi?

Per usare le parole di Stroustup:

C++ was designed primarily so that my friends and I would not have to program in assembler, C, or various modern high-level languages.