Pagina 4 di 4 primaprima ... 2 3 4
Visualizzazione dei risultati da 31 a 38 su 38

Discussione: Un consiglio

  1. #31

    Meglio che vada...

    darkblOOd è stato un piacere!!!

    Che significa rulez???
    Linguaggi : C/C++
    SO: WinXP, Slack 10

  2. #32

  3. #33
    Utente di HTML.it L'avatar di darkblOOd
    Registrato dal
    Jul 2001
    Messaggi
    2,212

    Re: Meglio che vada...

    Originariamente inviato da Habdul
    darkblOOd è stato un piacere!!!
    ciao, buon lavoro

  4. #34
    Utente bannato
    Registrato dal
    Jul 2002
    Messaggi
    99
    Posso farvi notare che questa discussione è stata condotta come se esistessero solo il C e il VB.net???

    Io mi sentirei di consigliare anche altre ottime alternative come Java, Delphi e Python per esempio.

    rikyxxx

  5. #35
    Originariamente inviato da rikyxxx
    Posso farvi notare che questa discussione è stata condotta come se esistessero solo il C e il VB.net???

    Io mi sentirei di consigliare anche altre ottime alternative come Java, Delphi e Python per esempio.

    rikyxxx
    mi sono lasciato prendere un po' la mano...

    Quando si discute con qualcuno competente è + bello!!!
    Linguaggi : C/C++
    SO: WinXP, Slack 10

  6. #36
    Ciao,

    scusate se mi intrometto, ma mi pare che in questo tread si faccia molta polemica e ben poca sostanza.

    Per prima cosa non sta scritto da nessuna parte che la programmazione ad oggetti sia migliore a quella procedurale. Dipende da molte cose. Da cosa si deve fare e con quali risorse. Dall'inclinazione del programmatore, ecc.

    La programmazione ad oggetti ha tanti vantaggi, ma è molto sprecona di risorse e poco sicura (in quanto implementi codice che non controlli fino in fondo).

    Come sapete esistono linguaggi di alto livello e di basso livello (assembly e C), con i primi programmi in maniera veloce e più semplice, con i secondi hai un controllo totale della macchina, cosa è meglio? dipende da quello che devi fare. Applicazioni mission critical andrebbero fatte solo con i secondi, applicazioni normali con i primi.

    Chi sa programmare (veramente e non per propria affermazione) in assembly o in C, passa agli altri linguaggi in pochissimo tempo e si porta dietro il fondamentale bagaglio della conoscienza della macchina. Per il vero c'è da dire che a volte a costoro risulta ostica la OOP, ma come detto non sta scritto da nessuna parte che sia necessaria, chi la prescrive come tale la conosce solo perchè non sa programmare applicazioni complesse in maniera procedurale.

    Per concludere .... meglio un ottimo programmatore in C o VB o Java che uno pessimo negli stessi linguaggi.

    Ciao.
    Marco Allegretti
    shishii@tiscalinet.it
    Lang: PERL, PHP, SQL.
    Linux user n° 268623 Fedora Core 10, Fedora Core 6, Debian Sarge on mips

  7. #37
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,466
    Ciao,
    scrivo di nuovo per aggiornarmi sull'argomento molto interessante, anche se ormai se ne è già parlato talmente tanto sul forum...

    Rispondendo a shishii, trovo che poi non si sia fatta tanta polemica...o meglio, ne ho vista moltà di più su newsgroup che frequento abitualmente o altri forum.

    Sulla questione riguardante "OOP meglio/peggio della procedurale", devo dare atto a shishii che, pur essendo io stesso un maniaco della programmazione ad oggetti, non è mai stato dimostrato che quest'ultima sia effettivamente migliore o peggiore di quella procedurale.
    Programmo in Delphi e leggo spesso articoli, ma soprattutto libri...in Delphi la OOP è tutto, ma anche nei testi che ho letto la programmazione ad oggetti non è mai stata presentata come la cura per tutte le malattie.
    I metodi "procedurale" e "ad oggetti" sono semplicemente due modi diverse di scomporre un problema per poterlo analizzare e codificare affinchè sia risolvibile a livello software; con l'approccio "procedurale", si cerca di suddividere il problema in operazioni che vengono più o meno ripetute, di analizzare quali variabili siano da rendere pubbliche o private.....dal lato della programmazione ad oggetti, si scompone il problema in entità, oggetti appunto, che interagiscono tra loro ed espongono alcune caratteristiche mentre ne nascondono altre.
    L'approccio che si sceglie dipende tutto dal modo abituale di pensare del programmatore.
    Quando lavoravo con VB, il mio modo di sviluppare un'applicazione era prettamente "procedurale" (del resto, non si poteva fare molto diversamente)...ho cominciato a scoprire le classi e mi sono accorto che VB tarpava le ali, non aveva tutto quello che serviva ad un programmatore che, avendo raggiunto un certo livello in termini di esigenze di strumenti, doveva bloccarsi o aggirare il problema in altro modo. In Delphi, invece, ho trovato tutto quello che mancava.

    Sul fatto che la programmazione ad oggetti sia "sprecona" di risorse, bisogna sempre vedere di cosa si sta parlando. Parlo di Delphi poichè lo conosco bene: tutto il codice sorgente è a disposizione, quindi è possibile verificare cosa viene effettivamente fatto alla creazione di un oggetto; inoltre non ci vuole molto a verificare, anche con il semplice Task Manager, quando spazio in memoria viene allocato. Credo che l'uso della programmazione ad oggetti abbia certi vantaggi che, se sfruttati adeguatamente, possono valere la pena di sprecare qualche byte; se devo allocare qualche oggetto per essere certo di non avere variabili globali disponibili a più procedure che potrebbero rendere difficili le operazioni di debugging, ad esempio, allora preferisco di gran lunga l'uso della OOP. Al massimo, posso dare atto che, in certi casi, l'uso della OOP renda il codice più pesante, ma penso che la potenza delle macchine di oggi non renda questo aspetto un problema...inoltre, dipende sempre dal debugger. Un'applicazione procedurale in VB, pur essendo procedurale, sarà sempre più lenta di un'applicazione sviluppata ad oggetti con linguaggi che la supportano (forse fatta esclusione di Java, ma quest'ultimo ha delle giustificate prerogative di portabilità).

    Per quanto riguarda la scelta del linguaggio migliore, si ricade sempre sulla solita questione. E' ovvio che per applicazioni mission critical sono senza dubbio più indicati linguaggi come il C e l'Assembly...anche se c'è da dire una cosa: se i programmi realizzati con questi linguaggi dovranno girare su Windows 98, il gioco non vale la candela vista la stabilità di quest'ultimo.

    Sono comunque d'accordo con la conclusione di shishii. Il programmatore "buono" non si distingue dal linguaggio conosciuto o preferito, sia questo VB, Delphi, C, Java...è una opinione del tutto personale, ovviamente, ma credo che nella programmazione si debba aver cura di molti particolari (allocazione minima delle risorse, scelta dell'algoritmo migliore, buona progettazione, deallocazione sicura della memoria, ecc.) chi li ha, indipendentemente dal linguaggio che utilizza, è bravo.

    Per fare un esempio: programmando in Delphi, sono abbastanza abituato a screditare il mondo VB, specialmente quello dalla versione 6 in giù...tuttavia, non penso che un programmatore VB sia un cattivo programmatore, poichè pur essendo dell'opinione che Delphi sia meglio, esistono programmatori Delphi che combinano più danni di altri programmatori VB, che invece sono comunque più puliti e attenti nella stesura del codice, e che raggiungono quindi risultati migliori.

    Ciao!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

  8. #38
    Utente di HTML.it
    Registrato dal
    Oct 2002
    Messaggi
    2,894
    Ho speso 10 Euro di bolletta telefonica per leggere il tuo post, cmq sono d'accordo!

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.