Originariamente inviato da franzauker
Ognuno ha le sue opinioni.
In merito a questioni che sono opinabili: i fatti, come la matematica, non dipendono dalle opinioni.


Originariamente inviato da franzauker
Personalmente mi fido più di me che di persone di borland/codegear etc, tranne 3 o 4 persone che conosco e di cui mi fido.
Non c'entra nulla la conoscenza o la fiducia nelle persone specifiche.

Dubito fortemente che milioni di sviluppatori Delphi utilizzino il prodotto e i suoi componenti efficacemente solo se conosco di persona qualche persona fidata all'interno della società, che tra l'altro è un pochino distante da noi...

Tutto questo c'entra ben poco con quello che stavo dicendo io.


Originariamente inviato da franzauker
Tra l'altro di bug nei codici borland, dal delphi 2 con cui ho iniziato, ne ho trovati un bel po'.
I bug esistono in qualsiasi software, ed è senz'altro ben più facile introdurli riscrivendo qualcosa di già fatto, soprattutto se funziona bene (magari da più di una decina d'anni), come nel caso del TClientDataSet.

I componenti Delphi sono fatti per essere utilizzati; vi sono bug specifici, ma non si può ricondurre a bug qualsiasi errore riscontrato per mancanza di conoscenza dello strumento, né pretendere di abbandonare preventivamente un approccio solo perché "vi sono stati dei bug", poiché applicando lo stesso principio allora si potrebbe dire che è meglio sviluppare un'applicazione usando direttamente le API di Windows, invece dei componenti VCL, premesso che il compilatore rimane comunque realizzato da un'altra persona... magari si fa in modo di conoscerla direttamente, così da poter usare i suoi prodotti con fiducia.

Scherzi a parte, cerchiamo di rimanere coi piedi per terra, e prima di implementare a mano un sistema "middle tier" valutiamo tecnicamente le soluzioni disponibili.


Originariamente inviato da franzauker
Per quanto mi riguarda, più è "basso" il livello di oggetti che usi, più è facile/immediato sia capire cosa funziona (e cosa no)
La conoscenza del "basso livello" è sempre utile per diagnosticare i problemi approfondendo l'architettura del sistema che si sta utilizzando, e in questo senso Delphi è senz'altro uno degli ambienti più apprezzabili perché coniuga il RAD a un linguaggio e ad una libreria - di cui viene fornito il codice sorgente - che permettono di andare a fondo l'architettura e di inserire, all'occorrenza, elementi nel "cuore" dell'applicazione (es. gestire direttamente i messaggi inseriti in coda da Windows).


Originariamente inviato da franzauker
sia soprattutto portarlo verso altre piattaforme ove gli oggetti "avanzati", magari non ci sono.
In realtà, avviene esattamente il contrario: più si penetra a basso livello, più è difficile realizzare qualcosa di portabile, che invece ad alto livello potrebbe essere tranquillamente supportata poiché il fornitore della libreria o dei componenti può garantire e soprattutto "mascherare" la differenza tra ambienti e piattaforme.


Originariamente inviato da franzauker
xE' per me del tutto normale portare in un pomeriggio un progetto da 1.2 milioni di righe da ABS a mysql, per fare un esempio.
Guarda, non posso affermare il contrario perché ovviamente non ho la possibilità di dimostrarlo, ma non ci credo.


Comunque, in riferimento a quanto detto sopra, è chiaro che vi possono essere casi particolari, o diverse sfumature, o condizioni in cui una soluzione è preferibile rispetto ad un'altra: il vero problema è che, leggendo le tue risposte, sembra che si vada per assolutismi, cioè per assiomi che valgono per qualsiasi caso esistente, e nell'ambito dello sviluppo ben difficilmente ci sono soluzioni o tecniche adattabili a qualsiasi esigenza.

Se le affermazioni fossero accompagnate da una contestualizzazione legata al caso specifico, allora sarebbe diverso, ma se si dice che "una soluzione manuale è sempre preferibile a qualcosa di già sviluppato" senza circostanziare il suggerimento, a me pare inaccettabile, perché è palese che non può essere *sempre* così.

Ciao!