Discussione:
Perché non Lazarus?
Aggiungi Risposta
Enrico Bianchi
2021-09-08 08:36:47 UTC
Rispondi
Permalink
Premessa: lurko, lurko, lurko. Sia perché non saprei come rispondere ad alcune
domande, sia perché nonostante mi sia sempre piaciuto Pascal e Delphi, non l'ho
mai usato. Detto questo, noto che molti, anche per svecchiare le proprie
applicazioni, usano nuove versioni di Delphi invece di approcciarsi ad altro. E
per approcciarsi ad altro intendo non solo ad usare altri linguaggi (alla fine
so che ci sono dei vincoli per cui questa strada non è sempre fattibile), ma
anche ad altre implementazioni di Delphi, dichiarate come compatibili con il
prodotto di Embarcadero. Mi riferisco quindi a Lazarus che, quando l'ho visto ai
tempi, mi sembrava un'ottima alternativa a Delphi (ovviamente il mio giudizio
era viziato da un occhio inesperto). Da qui mi chiedo, perché non usarlo non
dico per nuovi progetti, ma per manutenere gli attuali progetti ovvero per
aggiornarli e portarli avanti?

Enrico
Alberto Salvati
2021-09-08 13:59:54 UTC
Rispondi
Permalink
Una buona e santa volta dovremmo essere chiari e dire senza mezzi termini che delphi e affini sono da mollare IERI.

Alcuni motivi per i quali Delphi è da mollare ieri sono questi:

1) regressione del prodotto, ovvero cose che prima funzionavano e ora no:

2) appesantimento del prodotto con cose di cui, nella maggior parte dei casi, non frega una beata minchia a nessuno, una su tutti lo sviluppo mobile.

3) confrontando il rapporto qualità/prezzo di delphi con quello di visual studio, delphi perde pesantemente


4) delphi era un precursore, adesso è un centometrista sfiancato che rincorre gli altri


5) conseguentemente ai precedenti punti, le terze parti che producono componenti per delphi sono oramai poche (doa, devex, devart, ipworks...), e credo che si ridurranno ancora.

6) è inaccettabile leggere "conrtibuisci alla documentazione" nella guida in linea di un prodotto che non solo non è free o opensource, ma che costa non poco....

7) magari, se scodellassero una versione di delphi "lite", diciamo una enterprise priva degli ammenicoli inutili tipo fm2 e mobile, ad un prezzo onesto, diciamo 2ui 2k, forse si potrebbe farci un pensiero



Per ciò che riguarda lazarus, basta una sola frase: elegante soluzione con una inelegante implementazione dovuta ad una gestione del progetto a mio avviso cinofallica.
Un caso vissuto il 1a persona è quello del WST che non riuscivo a far funzionare in nessun modo.
Alla fine salto' fuori che WST non era compatibile con la versione di lazarus che usavo; l'unica soluzione era un downgrade di lazarus....
Immagina situazioni analoghe su altro...
Tutto ciò in quanto lo sviluppatore di WST non aveva (giustamente!) tempo per l'adeguamento.
Sottolineo il giustamente: lazarus si basa sul lavoro di volontari!

Altrettanto giustamente IO non mi giocherei le natiche verso un cliente dandogli il porting da delphi a lazarus di una applicazione....
La speranza è che magari qualcuno "grande e grosso ma sul serio" acquistasse lazarus...Allora forse, ma dovrebbero passare almeno un paio d'anni...
Ma anche lì nulla è scontato....L'acquisizione di Sun da parte di Oracle ha portato non pochi casini nel mondo java....

A.
ca75
2021-09-08 19:29:23 UTC
Rispondi
Permalink
se mi tengo le vecchie versioni esiste un motivo :)
e queste funzionano ancora.
Post by Alberto Salvati
2) appesantimento del prodotto con cose di cui, nella maggior parte dei casi, non frega una beata minchia a nessuno, una su tutti lo sviluppo mobile.
vedi sopra.
Post by Alberto Salvati
3) confrontando il rapporto qualità/prezzo di delphi con quello di visual studio, delphi perde pesantemente
con VS posso creare un programma che parta direttamente di chiavetta usb
senza installazione?
Post by Alberto Salvati
7) magari, se scodellassero una versione di delphi "lite", diciamo una enterprise priva degli ammenicoli inutili tipo fm2 e mobile, ad un prezzo onesto, diciamo 2ui 2k, forse si potrebbe farci un pensiero
magari senza registrazione, cosi posso installarla senza questo problema
un pensierino lo farei pure io.
--
-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"
Alberto Salvati
2021-09-09 08:36:41 UTC
Rispondi
Permalink
Post by ca75
con VS posso creare un programma che parta direttamente di chiavetta usb
senza installazione?
Il problema non è vs ma il tipo di applicazione.
Post by ca75
magari senza registrazione, cosi posso installarla senza questo problema
un pensierino lo farei pure io.
La registrazione serve per impedire copie "aumm aumm".


A.
ca75
2021-09-09 19:35:05 UTC
Rispondi
Permalink
Post by Alberto Salvati
Post by ca75
con VS posso creare un programma che parta direttamente di chiavetta usb
senza installazione?
Il problema non è vs ma il tipo di applicazione.
Tutti controlli standard, niente DB, niente gestione server o altro.
Post by Alberto Salvati
Post by ca75
magari senza registrazione, cosi posso installarla senza questo problema
un pensierino lo farei pure io.
La registrazione serve per impedire copie "aumm aumm".
E' anche un disincentivo, dovesse un giorno non essere più registrabile
o lasci un codice di sblocco?

E le versioni gratuite?


Oppure la tecnica del "turbo C++", creavi una versione economica da
120.000 lire con un buon manuale. Solo per il manuale non valeva la pena
copiarlo.

Se poi uno vuole copiarlo, molto facilmente si cerca il crack su
internet e la registrazione la passa.
--
-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"
Enrico Bianchi
2021-09-09 11:22:08 UTC
Rispondi
Permalink
Post by ca75
con VS posso creare un programma che parta direttamente di chiavetta usb
senza installazione?
A quanto pare sì: https://stackoverflow.com/a/50706274/5695585

Enrico
P.S. ad oggi parlare di .NET Core e .NET è ininfluente, la versione Core è
oramai l'unica versione disponibile tanto che c'è stata la riunificazione anche
a livello di nome (.NET si riferisce a questa versione)
Enrico Bianchi
2021-09-09 11:16:29 UTC
Rispondi
Permalink
Post by Alberto Salvati
5) conseguentemente ai precedenti punti, le terze parti che producono
componenti per delphi sono oramai poche (doa, devex, devart, ipworks...),
e credo che si ridurranno ancora.
Ecco, questo mi sembra un buon motivo per avvallare la tua posizione, anche se
la mia domanda era un'altra :)
Post by Alberto Salvati
Alla fine salto' fuori che WST non era compatibile con la versione di lazarus
che usavo; l'unica soluzione era un downgrade di lazarus....
Immagina situazioni analoghe su altro...
Occhio, questo è una situazione trasversale al linguaggio e al tipo di progetto.
A tal proposito, te ne posso raccontare due:

- La prima è successa qualche anno fa. Sviluppavo in Go (https://golang.org/)
per un'azienda dove utilizzavamo delle librerie proprietare. Queste librerie
(rilasciate sotto forma di oggetti precompilati da integrare nel progetto)
ci erano state fornite per una sola versione del compilatore ovvero non
potevamo fare l'upgrade del compilatore perché altrimenti non compilavano.
- La seconda è di qualche mese fa. Per l'IDE Java che uso (Intellij IDEA) un
utente ha sviluppato un plugin che a mio avviso è un must have. Il plugin è
open source e regolarmente hostato su GitHub. Con l'ultimo aggiornamento
dell'IDE, a causa della rimozione di alcuni parametri, il plugin ha smesso di
funzionare. Ci sono voluti almeno quattro mesi per riavere il plugin
funzionante a causa del fatto che lo sviluppatore non ha tempo da dedicarci e
a causa del fatto che lo sviluppatore non vuole creare una comunità di
sviluppo attorno al progetto per portarlo avanti.
Post by Alberto Salvati
Ma anche lì nulla è scontato....L'acquisizione di Sun da parte di Oracle ha
portato non pochi casini nel mondo java....
Da javista di vecchia data non direi. A parte i (relativi) casini da Java 8 a
Java 9, dovuti al fatto che si è voluto ristrutturare l'intero progetto (e ci
stava), il passaggio da una versione Java ad un'altra si tratta spesso di
prendere il jar e farlo ripartire sulla nuova versione della JVM. Dico spesso
perché il problema è sempre "il manico" e da quanto si è dipendenti dai
componenti che si usano (io stesso in un passaggio da Java 1.4 a Java 7 dovetti
rimettere mano al codice perché in 1.4 usavo una libreria JNI che nella nuova
release non serviva)

Enrico
Alberto Salvati
2021-09-09 12:32:32 UTC
Rispondi
Permalink
Post by Enrico Bianchi
Occhio, questo è una situazione trasversale al linguaggio e al tipo di progetto.
Si.
Ma converrai con me che un ide/compilatore portato avanti da volontari è più ballerino rispetto ad un prodotto a pagamento....
Qua non si parla di plugin, siano essi "nice to have" o "must to have".
Qua si parla che WST non funziona, punto.
E senza WST in lazarus i webservice NON LO SVILUPPI, punto.
Che poi delphi, pur essendo a pagamento, è diventato un prodotto "penale", è un altra storia.
Post by Enrico Bianchi
funzionante a causa del fatto che lo sviluppatore non ha tempo da dedicarci e
a causa del fatto che lo sviluppatore non vuole creare una comunità di
sviluppo attorno al progetto per portarlo avanti.
Già questo per me non va, salvo che non sia un plugin che fa qualcosa di stellare.
Post by Enrico Bianchi
Post by Alberto Salvati
Ma anche lì nulla è scontato....L'acquisizione di Sun da parte di Oracle ha
portato non pochi casini nel mondo java....
Da javista di vecchia data non direi.
Non parlavo di casini tecnici ma politici.
Che poi, a mia sensazione , java lo hanno un po rovinato quella è un altra storia.

A.
Enrico Bianchi
2021-09-13 18:41:32 UTC
Rispondi
Permalink
Post by Alberto Salvati
Si.
Ma converrai con me che un ide/compilatore portato avanti da volontari è più
ballerino rispetto ad un prodotto a pagamento....
Ne convengo, ma il mio punto era un altro
Post by Alberto Salvati
Qua non si parla di plugin, siano essi "nice to have" o "must to have".
(era per fare un esempio, di situazioni del genere ne trovi millemila)
Post by Alberto Salvati
E senza WST in lazarus i webservice NON LO SVILUPPI, punto.
Personalmente non ho mai sviluppato webservice, ma solo api REST, non riesco a
vedere l'impatto per questo dettaglio (limite mio)
Post by Alberto Salvati
Già questo per me non va, salvo che non sia un plugin che fa qualcosa di stellare.
Se sviluppi secondo il paradigma 12 factor app (https://12factor.net/), è quasi
indispensabile perché ti permette di definire un env file e di caricarlo durante
l'esecuzione o il debug del progetto. Non averlo è stato parecchio scomodo (gli
IDE di Jetbrains prevedono l'inserimento di variabili, ma solo una per volta e
dipendenti dalla confiturazione del progetto)
Post by Alberto Salvati
Non parlavo di casini tecnici ma politici.
Quello di fatto è stata una conseguenza, anche se ad oggi risolta più o meno
bene (l'unico pezzo che rimaneva "vincolato" era J2EE, ora rinominato in
JakartaEE)
Post by Alberto Salvati
Che poi, a mia sensazione , java lo hanno un po rovinato quella è un altra storia.
In che senso? A mio avviso da Java 8 a 16 ci sono state parecchie introduzioni
che hanno facilitato la vita (i record sono comodissimi)

Enrico
Alberto Salvati
2021-09-14 08:16:06 UTC
Rispondi
Permalink
Post by Enrico Bianchi
Post by Alberto Salvati
Si.
Ma converrai con me che un ide/compilatore portato avanti da volontari è più
ballerino rispetto ad un prodotto a pagamento....
Ne convengo, ma il mio punto era un altro
Ho capito solo dopo che tu ti riferivi a compatibilità tra delphi e lazarus.
Il primo ostacolo, da questo punto di vista sono i componenti di terze parti.
Se hai un progetto delphi che usa devex, ad esempio, sono dolori....
Post by Enrico Bianchi
Post by Alberto Salvati
Qua non si parla di plugin, siano essi "nice to have" o "must to have".
(era per fare un esempio, di situazioni del genere ne trovi millemila)
Post by Alberto Salvati
E senza WST in lazarus i webservice NON LO SVILUPPI, punto.
Personalmente non ho mai sviluppato webservice, ma solo api REST, non riesco a
vedere l'impatto per questo dettaglio (limite mio)
Una limitazione c'è.
Io sono un fatutore di REST, ma per alcune cose ti tocca ancora usare soap, tipo lo SDI che abbiamo qua in Italia.
E cmq, anche il mio era un esempio.
Post by Enrico Bianchi
Post by Alberto Salvati
Già questo per me non va, salvo che non sia un plugin che fa qualcosa di stellare.
Se sviluppi secondo il paradigma 12 factor app (https://12factor.net/), è quasi
indispensabile perché ti permette di definire un env file e di caricarlo durante
l'esecuzione o il debug del progetto. Non averlo è stato parecchio scomodo (gli
IDE di Jetbrains prevedono l'inserimento di variabili, ma solo una per volta e
dipendenti dalla confiturazione del progetto)
AZZ. Ci guardo.
Post by Enrico Bianchi
Post by Alberto Salvati
Non parlavo di casini tecnici ma politici.
Quello di fatto è stata una conseguenza, anche se ad oggi risolta più o meno
bene (l'unico pezzo che rimaneva "vincolato" era J2EE, ora rinominato in
JakartaEE)
OK.
Post by Enrico Bianchi
Post by Alberto Salvati
Che poi, a mia sensazione , java lo hanno un po rovinato quella è un altra storia.
In che senso? A mio avviso da Java 8 a 16 ci sono state parecchie introduzioni
che hanno facilitato la vita (i record sono comodissimi)
L'implementazione del paradigma OOP di java lo trovai eccellente ma ho avuto la sensazione (sottolineo, sensazione!) che nelle ultime versioni le aggiunte hanno, come dire, appesantito le cose.
Un po come ciò che è successo a .Net....oramai il framework standard è pachidermico al punto che la stessa Microsoft se ne è resa conto spingendo verso .Net Core.


A.
Enrico Bianchi
2021-09-16 09:38:14 UTC
Rispondi
Permalink
Post by Alberto Salvati
L'implementazione del paradigma OOP di java lo trovai eccellente ma ho avuto
la sensazione (sottolineo, sensazione!) che nelle ultime versioni le
aggiunte hanno, come dire, appesantito le cose.
Direi che bisogna discernere il concetto di "appesantimento". Se parliamo a
livello di performance, molto dipende da cosa è stato aggiunto. Per fare un
esempio, le lambda e gli stream aggiunti in Java 8 nonostante siano molto comodi
sono comunque computazionalmente pesanti rispetto ad esempio un for (nelle
versioni successive ci hanno lavorato per migliorare le performance, ma rimane
comunque lento). Se parliamo invece di funzionalità, tieni presente che molta
roba aggiunta da java 9 in poi è solo zucchero sintattico, ovvero non necessaria
se non per migliorare la leggibilità del codice (e ti assicuro che var i = 1 è
molto più comodo di int i = 1)
Post by Alberto Salvati
Un po come ciò che è successo a .Net....oramai il framework standard è
pachidermico al punto che la stessa Microsoft se ne è resa conto spingendo
verso .Net Core.
È una vita che mi dico di volerlo studiare, ma il tempo è quello che è e la
voglia ancora di meno...

Enrico
ca75
2021-09-16 18:24:07 UTC
Rispondi
Permalink
Post by Enrico Bianchi
comunque lento). Se parliamo invece di funzionalità, tieni presente che molta
roba aggiunta da java 9 in poi è solo zucchero sintattico, ovvero non necessaria
se non per migliorare la leggibilità del codice (e ti assicuro che var i = 1 è
molto più comodo di int i = 1)
io preferisco la versione

int i = 1

gli dico in modo esplicito il tipo di variabile che voglio. So la
dimensione del dato, so il campo di esistenza perchè sono tutte cose che
gli dico io.

poi nel caso in questione ( numeri interi ) vanno sicuramente bene entrambi.
--
-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"
Alberto Salvati
2021-09-20 08:03:57 UTC
Rispondi
Permalink
Post by Enrico Bianchi
Post by Alberto Salvati
L'implementazione del paradigma OOP di java lo trovai eccellente ma ho avuto
la sensazione (sottolineo, sensazione!) che nelle ultime versioni le
aggiunte hanno, come dire, appesantito le cose.
Direi che bisogna discernere il concetto di "appesantimento". Se parliamo a
livello di performance, molto dipende da cosa è stato aggiunto. Per fare un
esempio, le lambda e gli stream aggiunti in Java 8 nonostante siano molto comodi
sono comunque computazionalmente pesanti rispetto ad esempio un for (nelle
versioni successive ci hanno lavorato per migliorare le performance, ma rimane
comunque lento).
Questo tuo esempio descrive perfettamente ciò che intendevo dire.
A tanti sfugge "il fatto che PUOI non vuol dire che DEVI" e "cambiamento non è sinonimo di miglioramento"....
Post by Enrico Bianchi
Se parliamo invece di funzionalità, tieni presente che molta
roba aggiunta da java 9 in poi è solo zucchero sintattico, ovvero non necessaria
se non per migliorare la leggibilità del codice (e ti assicuro che var i = 1 è
molto più comodo di int i = 1)
Se il var funziona come .net lo trovo comodo fino ad un centro punto in quanto ti trovi "var" ma non hai immediata conoscenza del tipo di di dato effettivo.
Post by Enrico Bianchi
Post by Alberto Salvati
pachidermico al punto che la stessa Microsoft se ne è resa conto spingendo
verso .Net Core.
È una vita che mi dico di volerlo studiare, ma il tempo è quello che è e la
voglia ancora di meno...
c# non è male. Somiglia molto a Java, ha le partial class che sono molto comode ma non hai i "set" del pascal.
E c# ha le property, che java non ha (o non aveva...).

La differenza importante, secondo me, tra java e .Net è che in java non hai un exe "monolitico" ma una logica simile al vecchio top-down basato sugli overlay.
Questo, immagino sia molto utile ai fini di utilizzo delle risorse.
In .Net hai un exe "monolitico" che necessita di essere caricato in toto in memoria e se è VERAMENTE grosso rischi lo swap su memoria virtuale....

A.

Luigis
2021-09-09 14:25:47 UTC
Rispondi
Permalink
7) magari, se scodellassero una versione di delphi ... ad un prezzo onesto, ... si potrebbe farci un pensiero
Concordo, IMHO il problema di delphi è il posizionamento del prezzo, se
solo fosse molto più "umano".

Ciao
ca75
2021-09-08 20:09:45 UTC
Rispondi
Permalink
Post by Enrico Bianchi
tempi, mi sembrava un'ottima alternativa a Delphi (ovviamente il mio giudizio
era viziato da un occhio inesperto). Da qui mi chiedo, perché non usarlo non
dico per nuovi progetti, ma per manutenere gli attuali progetti ovvero per
aggiornarli e portarli avanti?
3 pecche che ho trovato in lazarus rispetto a delphi

la velocità
la dimensione degli eseguibili
la guida in linea.
--
-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"
Luigis
2021-09-09 07:56:34 UTC
Rispondi
Permalink
Post by Enrico Bianchi
Da qui mi chiedo, perché non usarlo non
dico per nuovi progetti, ma per manutenere gli attuali progetti ovvero per
aggiornarli e portarli avanti?
La compatibilità con delphi non è al 100% e non è proprio indolore :(

Ciao.
Enrico Bianchi
2021-09-09 12:02:29 UTC
Rispondi
Permalink
Post by Luigis
La compatibilità con delphi non è al 100% e non è proprio indolore :(
Capito, direi che questo spiega molto la situazione

Enrico
Continua a leggere su narkive:
Loading...