Vado per punti, ma direi che non ho molto da aggiungere rispetto a quanto già detto nelle risposte precedenti.
29/12/2022 - paoloholzl ha scritto:
Parlo proprio di una situazione molto ristretta dal punto di vista del team di sviluppo, una o due persone, tre al limite.
Anche se io lavorassi da solo, per me (come per tanti ISV) l'uso di un sistema di versioning (es. Git, SVN o altro) sarebbe indispensabile per mantenere una storia delle modifiche apportate al software, soprattutto in fase di segnalazione e risoluzione di un bug.
Access non mi consente di usarlo, poiché il codice sorgente finisce in un file binario, per giunta omnicomprensivo. Non va bene.
29/12/2022 - paoloholzl ha scritto:
I requisiti del software sono sempre stati soddisfatti sia in termini di stabilità che di velocità.
Certamente come dico dempre su progetti con concorrenza sul DB piuttosto limitata (al massimo una quindicina di clients), DB massimo un paio di GB (più che abbastanza per la stragrande maggioranza delle piccole aziende italiane).
Come già detto, Access è un database “file based”: se usato per frontend, ci sono alternative migliori, mentre come DB è sufficiente che debba servire due postazioni mettendo l'archivio in rete e disponga di una singola tabella nella quale si trovino - diciamo - qualche migliaia di record: all'esecuzione di ogni query vi sarà un'attesa lunga e ingiustificata, dovuta al passaggio in rete di tutti i dati dei record della tabella affinché il client autonomamente individui quelli che soddisfano una determinata ricerca.
Ergo, è inefficiente (lento), poco sicuro (i dati viaggiano in rete in chiaro e non c'è gestione utenti), non ottimale.
I requisiti sono sempre stati soddisfatti poiché probabilmente provengono da una clientela che non ha mai richiesto nulla di più non avendo evidentemente valutato o saggiato le enormi differenze che ci sono nell'uso di altre interfacce utente - nel caso dell'uso come frontend - o come base di dati.
29/12/2022 - paoloholzl ha scritto:
Usare Access per sviluppare su Web è un controsenso, se hai bisogno di sviluppare su Web hai una montagna di strumenti diversi.
Lo sviluppo di applicazioni Web e di API (REST, GraphQL, ecc.), o di architetture a microservizi, o di architetture su cloud, a oggi non è più una richiesta così fuori dal mondo: prendiamo atto che Access, in qualità di tool moderno, oltre a essere inutilizzabile in questi contesti (sia come frontend che come DB) si presenta addirittura come un “controsenso”.
29/12/2022 - paoloholzl ha scritto:
Ce ne sono di davvero integrati ma sono costosissimi. Quelli gratuiti ciascuno ha dei suoi punti di forza ma vanno 'orchestrati', e comunque non ti danno mai la comodità del ‘monolito’ e anche il Web server va gestito e di solito dà più da lavorare che un Database Server.
Io sviluppo su Web prevalentemente con linguaggi gratuiti, open-source, che si installano con un banale setup e consentono di creare progetti con un clic o una singola istruzione a riga di comando.
Il comando del monolito l'ho ottengo - se mi occorre - con altre tecnologie: ad esempio, con Delphi posso incapsulare una applicazione Web in un singolo eseguibile nativo (per Windows, ma anche crossplatform a oggi) che non necessita nemmeno di installazione, ma va solamente lanciato.
Altre soluzioni sono accessibili con linguaggi di scripting che nascono apposta per queste necessità, un altro “stile” di scrivere applicazioni che con Access non sono viabili (VBA non è un linguaggio di scripting, o quantomeno non lo è tanto quanto JavaScript o Python).
29/12/2022 - paoloholzl ha scritto:
Il problema esisterebbe se ti trovassi limitato ‘troppo’, se in tutti questi anni non mi sono mai scontrato con limitazioni oltretutto la limitazione per certi versi è anche semplificazione.
Non sono stato chiaro, ma la questione è proprio questa: il problema esiste in quanto mi trovo limitato troppo.
Non sarei in grado di produrre con Access il 90% delle soluzioni che mi vengono richieste, e avrei per il restante 10% alternative più valide e produttive per realizzare la stessa cosa più velocemente, con meno sforzo, in modo più manutenibile.
Ripeto, *non* sono un “assemblatore di istruzioni” orientate a portare su maschere il contenuto di tabelle dati, ma mi occupo di ingegneria del software e lavoro con strumenti (vedi version control), collaboratori (anche occasionali), metodologie (es. unit testing), pattern, CI/CD e così via, e tutto ciò che l'industria di sviluppo di software a regola d'arte richiede oggi giorno, con le relative competenze necessarie, e Access non fornisce supporto (nemmeno limitato) a una sola che sia una di queste prerogative.
29/12/2022 - paoloholzl ha scritto:
In un mio programma di migliaia e migliaia righe di codice difficilmente inconti un GoTo e le variabili sono sempre forzate in dichiarazione esplicita.
La gestione degli errori in modalità connessa non è più così rilevante, lato DB ci pensa il DB server con le logiche relazionali che hai impostato.
Se una chiave è doppia interviene direttamente il DB ad esempio.
Lato client esce praticamente solo se hai fatto un errore nel codice i form controllano già di loro l'input con le regole impostate.
Anche qui, ripeto: la business logic che io scrivo non è solo quella che esegue una query con l'obiettivo di vedere qualcosa su una maschera, o che espone una tabella alla maschera per l'inserimento guidato di record… io devo lavorare con il file system, caricare file voluminosi, eseguire il parsing di tracciati CSV e configurazioni in formato JSON, suddividere in entità a oggetti dati e strutture complesse in memoria, produrre (da codice) documenti in formato PDF/A per l'archiviazione, contattare un servizio REST remoto, invocare un Web Service tramite SOAP, interagire con un plugin da attivare dinamicamente in base al cliente di riferimento e così via, solo per elencare alcuni scenari.
Se non hai errori da gestire è perché non hai logica all'interno del programma che faccia poco di più che visualizzare delle maschere agganciate alla base dati; in caso contrario, il programma è per forza di cose “error prone” è la fallibilità di qualsiasi passaggio logico, che può anche non essere per forza un “errore” propriamente detto e potrebbe non dipendere solo dall'input dell'utente, all'interno dell'ambiente Access si traduce nella creazione di un condizione di errore (oggetto Error) che di fatto pone due strade: debuggare (se hai Access e sei lo sviluppatore) o terminare l'applicazione. Di nuovo, nessuna resilienza, nessuna robustezza, totalmente inadeguato alla maggior parte degli scenari che non siano l'editing dei dati di una tabella.
29/12/2022 - paoloholzl ha scritto:
La base dati di Access su file non va usata se non per programmi limitatissimi per uno o due utenti.
Appunto. E in quel caso, a oggi sceglierei una alternativa più standard e più portabile, ossia SQLite, sviluppando l'interfaccia con un tool di sviluppo - es. Delphi - che non ha bisogno di distribuire alcun runtime a corredo del file eseguibile, che assieme al DB è in grado di supportare nativamente già di suo tutte le piattaforme esistenti e non solo Windows.
Certo, magari non mi interessa approdare su altre piattaforme, ma il fatto di poterlo fare è una strada viabile e aperta a sviluppi futuri che costituisce un punto di forza tale per cui mi conviene investire in quelle tecnologie, piuttosto che rimanere su Access.
29/12/2022 - paoloholzl ha scritto:
Certamente, ma quanto ti costano? Prendiamo ad esempio Delphi (amavo il Turbo Pascal) mica te lo regalano, e se devi comporre dei reports, ok mi dirai coi sono tanti tools da aggregare. Quindi hai il Debug del programma e quello del Tool, hai più cose che devono coesistere.
Ma per quello che ti occorre per lo sviluppo di un gestionale fa tante tante cose … che non ti occorrono.
Nemmeno Access è gratuito, mi risulta. In ogni caso, sebbene esista comunque una versione gratuita (Community) di Delphi che consente lo sviluppo di applicazioni anche commerciali, l'investimento è giustificato dalla produttività che si ottiene nei tempi rapidi di prototipazione visuale e produzione del programma in sé, che peraltro è un eseguibile nativo e non un file da aprire con un tool (Access).
Non ci sono cose che devono “coesistere”: se devo scrivere un programma, uso un linguaggio di programmazione e un ambiente che mi consenta di progettarlo visualmente, implementarlo dal punto di vista logico e anche testarlo, quindi mi aspetto che fornisca “built-in” tutti gli strumenti necessari a svolgere questa attività, dal reperimento del codice da un repository pubblico/privato, alla definizione della GUI, alla modellazione delle strutture dati in memoria usando OOP e altri pattern, all'esecuzione e test del programma stesso e degli eventuali test logici implementati, fino alla successiva ripubblicazione delle modifiche apportate al software stesso per rendere disponibile le modifiche al team o al “me stesso del futuro”.
Si chiama ALM (Application Lifecycle Management), o più semplicemente ciclo di vita del software.
29/12/2022 - paoloholzl ha scritto:
Ok installi venti cose diverse, te le studi, te le aggiorni, per poi scoprire che quelle che ti servivano davvero ce le avevi già in un monolito da meno di 200 euro ...
Non installo venti cose diverse, ma quelle che servono per il lavoro che devo svolgere, ciascuna orientata a perseguire il proprio obiettivo, perché mi servono per progettare, scrivere, disegnare e testare il software richiesto dal cliente e che, conoscendole a fondo, so benissimo che nel monolito da pochi euro che è Access non c'è nulla di tutto ciò, spesso nemmeno una minima parte.
Inoltre, si tratta di un'attività “una tantum”, che non deve necessariamente essere ripetuta per tutti i progetti ma eseguita una volta sola predisponendo la macchina di sviluppo per svolgere il proprio compito.
29/12/2022 - paoloholzl ha scritto:
Se non vuole un Database Server o vuole farsi fare un programma di medicina generale appoggiato su un file condiviso dico (come ho già fatto) che se lo faccia fare da qualcun altro.
Credo debba essere chiaro che sia commercialmente sia tecnicamente, questo principio lo ritengo molto sbagliato.
Sono uno sviluppatore software e non posso dire a un cliente che ha un esigenza di arrangiarsi perché quello che mi chiede voglio farlo per forza con Access e i requisiti del cliente non mi permettono di farlo.
Certo, se mi viene richiesto di sviluppare una app nativa per dispositivi iOS e magari non ho una esperienza specifica in merito, posso dire al cliente di cercare un programmatore più “skillato” per quella esigenza, ma quando i requisiti sono oltremodo generici e soprattutto vi sono soluzioni più efficaci per uno specifico problema, voler piegarli ad essere compatibili con i demand di Access è parecchio limitante.
E' il classico caso del modo di dire nel quale si vogliono vedere chiodi ovunque avendo a disposizione un martello e volendo usare solo quello. :)
29/12/2022 - paoloholzl ha scritto:
Quanto un tool con il minimo di risorse ti permette di centrare l'obbiettivo di una soluzione scalabile connessa, debuggabile stabile in rete locale per progetti gestionali su sistemi operativi recenti, a mio parere è un tool moderno.
Access non subisce cambiamenti di rilievo da almeno 20 anni, un periodo che informaticamente parlando costituisce un'era geologica, e questo è un chiaro ed evidente segnale che non viene considerato una risorsa strategica da parte di Microsoft per affrontare le sfide del futuro, le quali prevedono scenari nei quali anche per la stessa casa madre questo tool non può trovare posto assolutamente.
In termini di scalabilità, di certo non lo è affatto, né orizzontalmente né verticalmente.
Avendo un linguaggio di programmazione, dire che è “debuggabile” mi pare sia il minimo, anche perché in caso di errori a runtime il debug o l'interruzione brusca del programma sono le uniche alternative possibili.
L'uso in rete locale potrà anche essere stabile, ma è lentissimo perché fa viaggiare tutti i dati sulla rete, che essendo pure “intercettabili” non sarebbe probabilmente compliant nemmeno con alcune restrizioni rigide del GDPR in alcuni contesti aziendali, intesi quelli che fanno le cose con un minimo di serietà. Access va bene per una macchina e per un utente, in locale.
Più che un tool moderno, diciamo che Access è un software legacy che - per grazia ricevuta - rimane ancora usabile per una gamma molto ristretta di progetti e scenari.
29/12/2022 - paoloholzl ha scritto:
Ok quindi la maggioranza dei detrattori parlano di ciò che non uso di Access da 20 anni per progetti di una certa consistenza.
I detrattori parlano con cognizione di causa confrontando Access con altri tool di programmazione e storage di dati con i quali sono entrati in contatto e di cui hanno fatto la conoscenza, e grazie a questo possono fare un confronto alla pari e comprendere appieno quello che manca in Access e che invece è presente in altri tool, e perché quindi conviene maggiormente investire negli altri, cosa che invece non è possibile se lo stesso confronto lo fa un professionista che usa solo e soltanto Access e non ha mai utilizzato altri strumenti all'infuori di esso, o quantomeno non gli strumenti con cui Access viene confrontato, o che intrattiene contatti e rapporti lavorativi con clienti le cui necessita sono strettamente limitate alla richiesta di applicazioni Access.
29/12/2022 - paoloholzl ha scritto:
Ok allora trovami una procedura per la creazione del codice fiscale scritta in Kotlin.
La richiesta in sé non ha molto senso, ma - senza conoscere Kotlin in alcun modo - la procedura esiste eccome. :D
E se non esistesse, basterebbe tradurla in Kotlin da una delle tante implementazioni esistenti in altri linguaggi, col vantaggio che da quella traduzione sarebbe possibile realizzare una app mobile crossplatform e adatta a tutti i device in grado di generare un codice fiscale, mentre lo stesso codice esistente da decenni per VBA non consentirebbe di fare comunque la stessa cosa in Access, che rimarrebbe limitato al supporto desktop per Windows in ambito locale e basta.
Il problema è che, con tutti i milioni di device mobili (smartphone, tablet, ecc.) che vengono venduti, è un tool moderno quello che consente di approdare su queste piattaforme, magari riscrivendo un pezzettino di codice, e non quello che con codice vecchio di anni continua a non offrire supporto per le piattaforme e le tecnologie emergenti.
29/12/2022 - paoloholzl ha scritto:
Dal mio punto di vista è la migliore come prezzo / prestazioni e sicuramente non mi ha mai dato troppe limitazioni da dover cambiare strumento.
Se non ne hai mai viste né provate altre perché “rimbalzi” i clienti che fanno richieste non realizzabili con Access, per forza non devi cambiare strumento: nessuno si sente mai obbligato a fare ciò che non vuole assolutamente fare a prescindere. :)
29/12/2022 - paoloholzl ha scritto:
I progetti vanno valutati sugli obiettivi raggiunti o no, sulle risorse spese per raggiungerli, sulla stabilità della soluzione.
Con tutti i progetti che ho sviluppato con Access non è mai successo che non sia arrivato al risultato e i programmi ancora in usa lavorano da decenni.
Se scazzi l'analisi puoi usare il tool più bello al mondo che al risultato non ci arrivi.
Anche io ho sviluppato in Access diverse procedure che sono ancora funzionanti, ma non significa nulla: il punto - è obbligatorio ribadirlo ancora una volta - è che il software richiesto oggi giorno a società di consulenza e a sviluppatori è in larga parte totalmente fuori dalle potenzialità di questo tool, e la maggior parte degli sviluppatori che sono “detrattori di Access” lo sono in quanto si tratta di uno strumento del tutto inservibile in quei contesti, sia per requisiti necessari al software che dovrà essere prodotto, sia per le metodologie adottate, sia per le esigenze di deploy e scalabilità, sia per tutti i motivi già elencati e discussi ampiamente in questo thread.
Data questa conclusione, che è un dato di fatto abbastanza dimostrabile anche con dati alla mano (basta vedere le statistiche dei linguaggi utilizzati per l'opensource e per la costruzione del software, appunto), pur capendo appieno la gioia e l'apprezzamento verso Access di coloro che con questo tool riescono a creare con successo tutte le applicazioni che grazie ai loro requisiti ristretti possono essere generate da questo tool, non posso giudicarlo a prescindere da quelle che sono le necessità di oggi, le applicazioni richieste, le prestazioni da garantire, gli standard di sicurezza, la qualità del codice e tutti quei fattori che fanno parte dello sviluppo software moderno, e che quindi fa sì che si possa ritenere altrettando moderno tutti i linguaggi e i tool che le supportano, e non quei tool che sono compatibili con una nicchia estremamente limitata di questi (ossia maschere per inserire dati su un database locale in Windows), e per questi motivi senz'altro l'unico aggettivo che non attribuirei ad Access è quello di moderno.
29/12/2022 - paoloholzl ha scritto:
Credi che non sapessi che con l'articolo avrei suscitato un vespaio?
Non esageriamo: più che un vespaio, al massimo un paio di interventi basiti che hanno forse perso più tempo del necessario a spiegare tutte le motivazioni abbastanza lapalissiane che dimostrano ed evidenziano perché si ha una certa considerazione di un tool e che, a dispetto dell'articolo che vorrebbe sostenere il contrario, vi sono e permangono, e anzi trovano più di una conferma nell'articolo stesso, che si spertica a decantare le lodi di Access sottolineando l'ambito estremamente ristretto e specifico del suo utilizzo, del tutto minoritario rispetto a ciò che tutti gli sviluppatori a oggi cercano e pretendono di trovare all'interno di un tool simile, che sia linguaggio di programmazione, app builder o database.
29/12/2022 - paoloholzl ha scritto:
Invece scaturirà un thread molto interessante (e questo non è l'unico).
Il mio interesse è già concluso: ho aggiunto i proverbiali puntini sulle “i” in merito a certi aspetti, ma per il resto direi che tutto ciò che ho scritto in realtà lo può confermare chiunque, mentre al contrario - rilancio la sfida - attendo di conoscere nella community degli sviluppatori almeno una voce rilevante che sia disposta a sostenere la tesi dell'articolo che stiamo commentando, o che ritenga Access un tool “moderno”.
29/12/2022 - paoloholzl ha scritto:
Come informatici siamo troppo abituati a ragionare sulle tecnologie, tutte le aziende serie lavorano sulle tecnologie in relazione agli obiettivi e alle risorse.
Come informatici, ragionare sulle tecnologie e rimanere al passo direi che non è troppo… è TUTTO! :)
In relazione agli obiettivi, lo sviluppo con Access è proficuo al loro raggiungimento solo se l'obiettivo è quello di sviluppare applicazioni con Access: se parliamo di sviluppo software a livello professionale, da soli o in team, con tutti i crismi, di software che abbia una complessità di un certo livello (che non si misura di certo nel numero di maschere da creare o di tabelle da salvare sul DB, come fatto sino a ora) e che abbia bisogno di strategie di scalabilità, ridondanza e magari addirittura di CI/CD, tutti elementi fondanti dello sviluppo software moderno (anzi, ormai sono temi di cui si parla da anni), Access è fondamentalmente OUT in tutti questi contesti, nessuno escluso.
Ciao! :)