gian82 ha scritto:
Per +m2+ : non mi sembra fuori strada,
per curiosità, perchè consigli in modo così netto delphi rispetto a c#? ,
non è tanto delphi vs "qualcosa", bensì "monolitico" vs "qualsiasi altra cosa".
quando il deploy è delicato, più "mondezza" hai sotto (roba microsoft, .net, aggiornamenti, service pack, stica.. e così via), più è facile avere drammi, errori, difficoltà, incompatibilità.
aggiornamenti che piallano tutto e così via.
se, al contrario, hai un singolo EXE, che funziona senza nulla (niente DLL, niente ODBC, niente activex, niente OCX, niente COM, niente sticz...) è estremamente più facile il deploy.
estremamente più facile il debug.
estremamente più affidabile (perchè il programma ce l'hai in "mano", e sai benissimo cosa fa e cosa no).
più strati vuol dire più complessità, più bug, più errori, più disastri, più incompatibilità.
---
non è difficile fare un intero ERP (qualora necessario) portabile. Quando vuoi correggere un bug, banalmente aggiorni l'eseguibile e bon, sei CERTO che non avrai problemi di DLL, di vecchie versioni, di stixxx...
il programma più affidabile, quello privo di bug è (parafrasando) quello che NON c'è.
---
Nel caso specifico, dovendo poi "interoloquire" con dispositivi hardware, sistemi quali Java non sono adatti (troppo rottura di @@ con l'HW), men che meno PHP o qualsiasi altra cosa server-side.
Ci vuole un "qualcosa" che giri esattamente sulla macchina, "parli" coi dispositivi, e colloqui con chi deve "parlare".
Questa è la strada che seguirei.
---
Per un sistema ad hoc, cioè di mia progettazione, userei invece C e openbsd/netbsd/freebsd, a seconda dei driver disponibili (perchè "parlare" con l'hardware in modo affidabile è tutto tranne che banale o privo di grattacapi)