02/01/2023 - paoloholzl ha scritto:
Scopo: scrivere (come scrivo da anni) dei ‘classici gestionali’, tanto per fare un esempio un CRM (nell'esempio, senza mail automatici, sms o altre particolarità).
Lo scopo è abbastanza chiaro: se non è variato, prendo come riferimento il tipo di applicativo che già stai creando con Access.
02/01/2023 - paoloholzl ha scritto:
Usare un ambiente stabile, documentato, con un buon numero di sviluppatori e forum di supporto.
Parliamo di linguaggi e ambienti abbastanza diffusi, ma dal punto di vista della documentazione disponibile e della vastità della community, sicuramente le tecnologie Microsoft hanno maggiore supporto poiché godono di un maggiore investimento.
Bisogna comunque prendere in considerazione anche tanti altri fattori a mio avviso non secondari in questo contesto (e forse rilevanti anche per te): la compatibilità all'indietro e il supporto continuativo.
Mi spiego: Microsoft avrà senz'altro community e supporto più ampio per i propri strumenti, ma a differenza di altri produttori, i tool di sviluppo non rappresentano il suo “core business” quanto più un trampolino di lancio verso quei prodotti che realmente vuole vendere, quali Azure, SQL Server e altri servizi.
Questo per dire che, come accaduto con tecnologie quali Visual Fox Pro, J#, VB6, lo stesso VBA (non vede aggiornamenti da anni, pur continuando a esistere), oppure ancora Silverlight, Windows Phone, Microsoft Store Apps e altri casi affini, il supporto sarà pure ampio ma quando Microsoft decide di interromperlo, fossero anche tecnologie utilizzate da milioni di sviluppatori, non c'è petizione che tenga e bisogna trovare una alternativa, quindi reinvestire su formazione nelle “nuove proposte” e potenzialmente riscrivere il codice, il tutto solo per decisione del fornitore e non per una reale necessità o vantaggio.
02/01/2023 - paoloholzl ha scritto:
Usare strumenti più open source possibile.
E' un requisito piuttosto insolito, soprattutto se proveniente da chi parte da Access, che proprio opensource non è, ad ogni modo… :)
Fatto salvo Visual Studio Code (che non è RAD), direi che in termini di ambienti di sviluppo ve ne sono pochi opensource tra quelli citati.
Certo, Lazarus ad esempio lo è, mentre Visual Studio, Delphi e tanti altri non lo sono, o non sono affatto ambienti RAD.
Tuttavia, nella maggior parte dei casi sono disponibili i sorgenti dei framework utilizzati, come vale per la BCL di .NET, ma anche VCL/FireMonkey su Delphi sono distribuiti assieme al loro sorgente (per me è una risorsa fondamentale).
Qui bisogna chiarire il motivo per cui si pone l'opensource come requisito: dal mio punto di vista, il sorgente è fondamentale perché - in caso di problemi - posso esaminare del codice, capire come è stato realizzato, sfruttarlo per apprendimento e per addurre dei “workaround” se qualcosa non funziona… ci sono invece tanti altri sviluppatori che ricercano l'opensource in virtù del legame spesso presente (ma non sempre) “opensource=gratis”.
Qui bisogna quindi chiarire: si vuole l'opensource perché si è interessati ad avere il sorgente, o perché di solito chi fornisce il sorgente non richiede un pagamento? Esistono software opensource anche con licenze commerciali, magari pure molto costose, quindi è fondamentale chiarire.
02/01/2023 - paoloholzl ha scritto:
Usare fintanto che è possibile versioni Community anche per sviluppare programmi da vendere.
Qui parlano i contratti di licenza, che definiscono per filo e per segno i limiti dell'uso commerciale delle licenze.
Da parte mia, essendo uno sviluppatore software, quando esamino la fattura del commercialista, o pago l'affitto dell'ufficio, o il carburante per gli spostamenti, oppure se osservo delle semplici bollette, mi rendo conto che non è senz'altro il costo dello strumento con cui realizzo direttamente i prodotti che vendo a essere la spesa più iniqua fra tutte… ma sembra esserci una tendenza abbastanza diffusa a concentrare su questa voce di costo le considerazioni più “critiche”, spesso perché qualcuno fornisce tali soluzioni gratuitamente (laddove quel “gratis” nasconde poi ben altre insidie legate al fatto che l'introito arriva magari da qualche altra parte che non necessariamente può fare piacere).
In breve, anche su questo aspetto, così come sul punto dell'opensource, ci vedo un “voglio usare un software buono, stabile, diffuso, supportato per realizzare i miei prodotti da vendere, ma senza pagarlo”.
Non dico che sia pretenziosetto, non dico che sia sbagliato, ma in genere questa tipologia di visione - soprattutto a oggi - io la vedo estremamente miope.
02/01/2023 - paoloholzl ha scritto:
Sviluppo Stand-Alone, i programmi devono girare in rete indipendentemente dal collegamento Internet.
Il collegamento a Internet serve se una applicazione vuole sfruttarlo per comunicare con l'esterno.
Non esiste linguaggio o tecnologia, che io sappia, che impone di essere collegati per sviluppare o far girare una applicazione, a meno che non sia un'applicazione Web, ovvio.
02/01/2023 - paoloholzl ha scritto:
Possibilmente il codice risultante deve girare indifferentemente su Win o Linux, al limite anche su Android.
Discorso complesso ed enunciato in modo troppo superficiale.
Per dire, Delphi dispone di una libreria per applicazioni multi-device e multi-OS denominata FireMonkey. Modificando il target della piattaforma, con lo stesso sorgente è possibile compilare la stessa identica applicazione sia per Windows (32/64 bit) che per Mac OS che per Linux. Potenzialmente, la stessa app può approdare su Android o su iOS.
MA attenzione… sarà molto difficile che una applicazione gestionale progettata per Windows possa andare bene anche su Android, e questo non per problemi del compilatore, ma perché su Windows abbiamo a disposizione schermi di una certa grandezza, abbiamo il mouse e un tipo di esperienza utente, mentre su Android siamo di fronte a un device e a un ambiente completamente differente.
Sarà quindi preferibile fare due app, ma al netto di questo è vero che, grazie alla RTL in comune tra le piattaforme e grazie al supporto di FireMonkey, con Delphi si possono sviluppare entrambi gli applicativi condividendo e riusando la quasi totalità del codice scritto per la logica di business.
02/01/2023 - paoloholzl ha scritto:
La programmazione deve essere più RAD possibile, devo dedicare tempo al codice, meno possibile alle interfacce e alle impaginazioni dei reports.
La definizione di RAD in genere implica il dedicare pochissimo tempo al codice e maggiormente alla progettazione visuale.
Progettare un report e una UI è un compito prettamente prototipale, quindi uno strumento RAD deve consentirti di farlo visualmente, e non obbligarti a scrivere tutto il codice, che è un processo più lento.
Possibilmente, anche la progettazione visuale deve essere coadiuvata da strumenti che rendano il processo il più rapido possibile.
02/01/2023 - paoloholzl ha scritto:
Deve poter usare database server (ma questo lo fanno un po tutti), in lan.
Delphi include i componenti FireDAC: sono una libreria molto completa che, oltre al collegamento con i database server più diffusi tramite driver nativi (compilabili nell'eseguibile), offrono anche tante altre funzionalità collegate (caching, espedienti visuali, uso di SQL “locale” su dati scaricati, ecc.) che sono fruibili indipendentemente dal database server utilizzato.
Questi driver però non sono presenti nell'edizione Community, per quanto ne so.
Visual Studio o .NET in generale si basa principalmente su ADO.NET e sulle librerie che creano sovrastrutture su questa architettura.
02/01/2023 - paoloholzl ha scritto:
Più è monolitico meglio è (dal mio punto di vista), in pratica per sviluppare un gestionale ‘classico’ , dai forms ai report, devo fare meno uso possibile di componenti aggiuntivi.
Delphi compila eseguibili nativi per la piattaforma target selezionata.
Questo significa che il risultato della compilazione produce un eseguibile monolitico, un file .exe su Windows ad esempio, che contiene codice macchina per la CPU di riferimento (no runtime, no VM).
Lo stesso vale per tutte le altre piattaforme supportate.
02/01/2023 - paoloholzl ha scritto:
Il codice risultante deve essere più chiaro possibile.
Io ritengo il Pascal uno dei linguaggi più leggibili, ma qui siamo di fronte a qualcosa che va molto a gusti, ed è anche soggiogato a ciò che lo sviluppatore considera “chiaro”.
Io ad esempio, per molti colleghi non scrivo codice “chiaro”: pur aderendo a degli standard di codifica globalmente condivisi, ho clienti che faticano a leggere il mio codice perché nel loro vocabolario “chiaro” ha un significato e un aspetto differente da ciò che viene considerato “chiaro” dal resto della community.
In breve, è a malapena un requisito tecnico: il codice è chiaro in qualsiasi linguaggio, o c'è modo di renderlo tale, se lo sviluppatore è in grado di scriverlo.
Certo, magari Objective-C ha una sintassi meno accomodante di quella di tanti altri linguaggi concorrenti, ma c'è chi lo usa ancora in modo proficuo e legge benissimo ciò che scrive, o che hanno scritto altri. :)