Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Perché non Lazarus?

137 views
Skip to first unread message

Enrico Bianchi

unread,
Sep 8, 2021, 4:36:48 AM9/8/21
to
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

unread,
Sep 8, 2021, 9:59:55 AM9/8/21
to

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

unread,
Sep 8, 2021, 3:30:15 PM9/8/21
to

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

se mi tengo le vecchie versioni esiste un motivo :)
e queste funzionano ancora.

>
> 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.

>
> 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?

> 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"

ca75

unread,
Sep 8, 2021, 4:10:56 PM9/8/21
to
> 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.

Luigis

unread,
Sep 9, 2021, 3:56:37 AM9/9/21
to
Il 08/09/2021 10:36, Enrico Bianchi ha scritto:
> 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.

Alberto Salvati

unread,
Sep 9, 2021, 4:36:42 AM9/9/21
to

> con VS posso creare un programma che parta direttamente di chiavetta usb
> senza installazione?

Il problema non è vs ma il tipo di applicazione.



> magari senza registrazione, cosi posso installarla senza questo problema
> un pensierino lo farei pure io.

La registrazione serve per impedire copie "aumm aumm".


A.

Enrico Bianchi

unread,
Sep 9, 2021, 7:16:30 AM9/9/21
to
On 2021-09-08, Alberto Salvati <zzz...@gmail.com> wrote:

> 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 :)

> 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.

> 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

Enrico Bianchi

unread,
Sep 9, 2021, 7:22:10 AM9/9/21
to
On 2021-09-08, ca75 <1975no...@libero.it> wrote:

> 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

unread,
Sep 9, 2021, 8:02:30 AM9/9/21
to
On 2021-09-09, Luigis <Lui...@ls.it> wrote:

> La compatibilità con delphi non è al 100% e non è proprio indolore :(

Capito, direi che questo spiega molto la situazione

Enrico

Alberto Salvati

unread,
Sep 9, 2021, 8:32:33 AM9/9/21
to

> 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.


> 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.


> > 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.

Luigis

unread,
Sep 9, 2021, 10:25:52 AM9/9/21
to
Il 08/09/2021 15:59, Alberto Salvati ha scritto:
>
> 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

unread,
Sep 9, 2021, 3:35:19 PM9/9/21
to
Alberto Salvati ha scritto:
>> 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.
>
>
>
>> 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.

Enrico Bianchi

unread,
Sep 13, 2021, 2:41:36 PM9/13/21
to
On 2021-09-09, Alberto Salvati <zzz...@gmail.com> wrote:

> 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

> 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)

> 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)

> 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)

> 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)

> 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

unread,
Sep 14, 2021, 4:16:06 AM9/14/21
to
On Monday, September 13, 2021 at 8:41:36 PM UTC+2, Enrico Bianchi wrote:
> On 2021-09-09, Alberto Salvati <zzz...@gmail.com> wrote:
>
> > 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....



> > 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)
> > 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.



> > 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.




> > 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.

> > 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

unread,
Sep 16, 2021, 5:38:15 AM9/16/21
to
On 2021-09-14, Alberto Salvati <zzz...@gmail.com> wrote:

> 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)

> 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

unread,
Sep 16, 2021, 2:24:07 PM9/16/21
to
> 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.

Alberto Salvati

unread,
Sep 20, 2021, 4:03:58 AM9/20/21
to
On Thursday, September 16, 2021 at 11:38:15 AM UTC+2, Enrico Bianchi wrote:
> On 2021-09-14, Alberto Salvati <zzz...@gmail.com> wrote:
>
> > 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"....


> 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.



> > 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.
0 new messages