[OT] Linguaggio più adatto a gestionale

[alka]

Originariamente inviato da XWolverineX
Eeeeeehhh?
Se non è veloce lui, allora chi lo è?
Credo che dopo l'assembly, in fatto di velocità vince lui,seguito subito dopo dal C++

Presumo che stesse parlando in termini di produttività.

[colde]

Originariamente inviato da alka
Presumo che stesse parlando in termini di produttività.

Bhe ovviamente, mi sembrava sottinteso visto che uno degli argomenti del mio post era incentrato proprio su questo punto.

Concordo inoltre con alka per la questione OOP.

[king64]

Se stai scherzando, allora è una bellissima battuta...

Beh...che dire ? Durante la mia esperienza nel campo della programmazione ho scritto diverse migliaia di righe di codice , sia per programmi interi che per parti di essi, e con tutta onestà non ho sentito affatto la mancanza della programmazione ad oggetti . Uso tuttavia linguaggi orientati agli oggetti e mi trovo bene , ma come su altri post ho avuto occasione di scrivere l'approccio è più che altro filosofico e non sostanziale . Tutto dipende dal feeling che il programmatore ha con il linguaggio e la produttività , alla fine , dipende sempre dal programmatore e dalla sua creatività .

[power.mobile]

A proposito del gestionale posso dire che ne sto sviluppando uno abbastanza complesso in VB.NET associato a PostgreSql e mi trovo benissimo... ho anche usato il vb6 per accesso ai dati ma con il vb.net non c'è paragone.... non ho mai usato il delphi ma ho sentito parlare bene anche del nuovo VisualDBase....

comunque posso dire, adesso che con il .net ho conosciuto la oop, che un linguaggio come si deve non può fare a meno degli oggetti....

[king64]

comunque posso dire, adesso che con il .net ho conosciuto la oop, che un linguaggio come si deve non può fare a meno degli oggetti....

Che intendi per linguaggio come si deve ? Il C secondo te non è un linguaggio come si deve ?

[alka]

Originariamente inviato da king64
Beh...che dire ? Durante la mia esperienza nel campo della programmazione ho scritto diverse migliaia di righe di codice , sia per programmi interi che per parti di essi, e con tutta onestà non ho sentito affatto la mancanza della programmazione ad oggetti.

Senza entrare nel merito della tua esperienza, se non hai mai sentito la necessità dell'OOP, evidentemente non hai mai avuto a che fare con un progetto tale da trovare una soluzione semplice in termini di complessità basata su OOP al posto di un classico approccio procedurale.

Originariamente inviato da king64
Uso tuttavia linguaggi orientati agli oggetti e mi trovo bene, ma come su altri post ho avuto occasione di scrivere l'approccio è più che altro filosofico e non sostanziale.

Che significa "filosofico", "non sostanziale"?
Che l'approccio OOP non introduce alcun beneficio rispetto alla controparte procedurale? Questo è assolutamente falso.

La programmazione orientata agli oggetti offre benefici in termini di manutenzione del codice, di riduzione del numero di bug, di protezione dei dati dagli accessi non autorizzati e di possibilità di modellazione attraverso appositi linguaggi e tool che sono inapplicabili con altre modalità procedurali.

Il fatto che tu non senta la necessità di programmare ad oggetti e ritenga questa attività uno sport non esclude il fatto che dalla programmazione ad oggetti e dallo sviluppo per componenti derivano semplificazioni che rendono senz'altro più produttivo lo sviluppo di applicazioni.

Originariamente inviato da king64
Tutto dipende dal feeling che il programmatore ha con il linguaggio e la produttività , alla fine , dipende sempre dal programmatore e dalla sua creatività .

Ovvio che tutto dipende dal feeling del programmatore, ma se uno sviluppatore non si trova a proprio agio con la programmazione orientata agli oggetti e ci impiega il doppio del tempo nel realizzare un progetto, questo non significa che un secondo sviluppatore, che vanta esperienza e capacità in termini di organizzazione del progetto secondo un modello OOP, non riesca essenzialmente a produrre l'applicativo in tempi più brevi. Il problema in questo caso non è l'inefficienza della OOP, ma l'incapacità dello sviluppatore di programmare realmente sfruttando l'OOP.

Concludendo, confutare i vantaggi dell'OOP sostenendo che non producano benefici qualora uno sviluppatore non sia in grado di utilizzarla mi sembra un po' ridicolo.

[alka]

Originariamente inviato da power.mobile
comunque posso dire, adesso che con il .net ho conosciuto la oop, che un linguaggio come si deve non può fare a meno degli oggetti....

Ad ogni metodologia (procedurale, OOP e così via) sono legati una serie di vantaggi e svantaggi, pertanto non esiste una metodologia che si possa ritenere la panacea di tutti i mali.

Ad esempio, si deve tenere conto che generalmente i linguaggi OOP introducono overhead causato dalle istruzioni aggiuntive che servono per sorreggere il sistema stesso (ad esempio, il binding dei metodi e così via), pertanto la scelta di usare un linguaggio OOP o un framework come .NET dovrebbe essere suffragato da un'analisi che faccia propendere l'ago della bilancia da una parte o dall'altra, per una metodologia o un'altra, per un linguaggio oppure un altro, per una libreria/framework o un'altra soluzione ancora.

Nel caso in esame, visto che si parla nello specifico di "gestionale", a mio avviso utilizzare C/C++ per questioni di performance è uno spreco, in quanto la realizzazione dell'applicativo richiede l'implementazione di una cosiddetta "business logic", la connessione a database (che costituiscono già un piccolo collo di bottiglia), la visualizzazione di dati, problematiche in cui essenzialmente lo sviluppo RAD basato su OOP e un linguaggio di alto livello consentono di ottenere ottimi risultati e costituiscono, non a livello assoluto ma sempre considerando la tipologia di applicativi di cui stiamo parlando, il miglior compromesso, ed evidenzio ancora compromesso.

Concordo comunque che, con l'ingigantirsi sempre più delle dimensioni e della complessità del software al giorno d'oggi, l'uso di linguaggi ad alto livello, di librerie e di framework, soprattutto se basati su OOP, possano accelerare di molto lo sviluppo di soluzioni in quanto il buon programmatore può concentrarsi sull'architettura del software che deve realizzare, sulle funzionalità da implementare e sulle classi che meglio consentono di raggiungere i propri scopi.

[netarrow]

Originariamente inviato da king64
Che intendi per linguaggio come si deve ? Il C secondo te non è un linguaggio come si deve ?

se il C fosse stato come si deve non avrebbero inventato il C++

mi correggo, se il C fosse rimasto come si deve non avrebbero fatto il C++, prima era fra i più usati nella piazza; dopo però continuare a guardarsi i pieni quando il mondo della programmazione va avanti non era produttivo.
Prima con asm i codici sorgenti erano di decine di righe, poi già dalle centinaiala la cosa non era più gestibile, col C si arrivava a migliaia con la OOP introdotta nel C++(che prima si chiamava "C con classi", nome ridondante giustamente cambiato) puoi fare milioni di righe di codice gestendole più facilmente, l'incapsulazione e la suddivisione del codice c'era già prima, ma la OOP ha aggiunto l'astrazione, l'eredità, il polimorfismo; e poi diciamolo, anche a livello tecnico il compilatore C++ è molto più intelligente e ti aiuta ad evitare bug che col C erano diffusissimi; ma una volta o usavi quallo o usavi quello