Newsgroup: it.comp.lang.delphi
Titolo: Labirinto

Faccio un do di spamming ( ï¿œ spamming, quando segnalo un link al mio 
sito?, altrimenti non ricordo come si dice )
 
E' un po che sono fermo, se volete vederlo, altrimenti non guardatelo ( 
src inclusi ).
 
http://www.baragin.it/html/delphi/programmi/labirinto.zip
 
 
Ne approfitto per fare il classico quiz di agosto.
 
Che versione di Delphi usate? Prospettive per il futuro?
 
Ciao.
-- 
-------------------------------
per scrivere in privato
togliere "1975nosp"
 
to reply remove "1975nosp"

 Che versione di Delphi usate? Prospettive per il futuro?
 
Mi aspettavo piu' qualcosa del tipo "bikini, topless o che altro?" :-D
 
Io al momento uso d6, d7, d2009 e sto muovendo i primi passi su xe4.
Sto puntanto sopratutto alle cose piu innovative (almeno per me..) come cloud (amazon), livebindings e FM2.
 
Riguardo le prospettive, forse (e dico forse!) avendo:
 
supporto nativo windows 32 e 64 bit
ios e macos
Android ( quando ci sara..)
 
anche gli ital-ioti si renderanno conto che non c'e' solo .Net e che con delphi fai parecchie cose interessanti, escluso ovviamente (ma non per tutti) lo sviluppo WEB per la parte front-end per la qual cosa esistono non pochi strumenti come python, java, php.
 
A.

 Che versione di Delphi usate? Prospettive per il futuro?
 
Delphi?! Baaasta Delphi... mai piu'.
 
-- 
http://www.kiva.org
 
http://www.wwoof.it
 
http://www.superzeta.it
 
http://subumani.blogattivo.com
 
Per il ng it.hobby.hi-fi: a*fan*ulo 'sta ca**o di hifi/hiend, tutte
put*an*te.
C/++/#, .net, wxWidgets, CodeTyphon, Eclipse,
Firebird, Oracle & altro.
La troppa confidenza fa perdere la riverenza.
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

Mi autoquoto perche' ho dimenticato una cosa.
Fino ad oggi, davanti alle richieste di avere anche il supporto per linux si sono sempre "nascoti" dietro il dito del "lo usano in pochi: stiamo dando priorita' a cose piu' comuni come mac e android...".
Dopo il rilascio di quello che serve  per android, questo alibi sparira'.
A quel punto o ne trovano un altro oppure mettono in pista qualcosa per il "pinguino".
Gia' poter sviluppare servizi/daemon privi di interfaccia utente sarebbe un bel passo avanti....
 
A.

> Delphi?! Baaasta Delphi... mai piu'.
 
??
 
A.

 Dopo il rilascio di quello che serve  per android, questo alibi sparira'.
 
Ciao Alberto,
non voglio riaprire l'ennesimo topic pro/contro linux, ma la mia
opinione resta sempre la stessa: emb. non farà mai un "delphi per
linux", semplicemente perchè non c'è alcun mercato.
 
Per linux chi vuole restare ancorato alla metodologia di sviluppo basata
su object pascal + rad "alla delphi" c'è sempre l'ottimo Lazarus,
altrimenti può passare al C++ di Qt che oggi ha un trend tra i migliori
(ultimamente il supporto alla compilazione per android è stato
irrobustito e kde lo utilizza come framework ufficiale di sviluppo).
 
Annotazione a margine per Alberto: dalla varsione 5 del framework sono
anche presenti le classi per creare nativamente servizi/demoni.
 
-- 
morde
Android
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

 su object pascal + rad "alla delphi" c'è sempre l'ottimo Lazarus,
 
Hai esperienza DIRETTA E PERSONALE nell'uso di lazarus? 
Se si, cosa hai sviluppato?
 
Riguardo c++ e QT...tanto di cappello.
 
A.

 Non c'e' mercato lato CLIENT, ma lato server, sopratutto WEB, si.
 
Infatti avevano anticipato che forse, e va sottolineato _forse_, avrebbero proposto qualcosa *lato server* per Linux in futuro.
 
Una cosa che era stata assicurata (almeno per ora) è che un ambiente tipo Kylix e/o un'esperienza simil CLX fosse esclusa; in questo campo, comunque, se ci si vuole proprio cimentare le alternative ci sono (e alcune sono già state scritte nel thread).
 
Ciao,
  Marco.
 
-- 
MARCO BREVEGLIERI
#Home: 
http://www.marco.breveglieri.name
 
#Blog: 
http://www.compilaquindiva.net
 

 Dopo il rilascio di quello che serve  per android, questo alibi sparira'.
 
Questo alibi rimarrà sempre perché, nonostante si sia giunti su OSX, iOS e Android, gli scenari che aprono e le cose che si possono aggiungere sono sempre infinite. Persino sulla VCL le novità non sono mai finite... :)
 
E poi non dimenticare che possono sempre nascere altri alibi, ad esempio "WinRT". :)
 
Comunque sia, devo dire che l'alibi lo condivido perché, molto egoisticamente, non uso abitualmente la piattaforma Linux quindi preferisco che le migliorie si indirizzino sulle altre piattaforme. :P


 Delphi?! Baaasta Delphi... mai piu'.
 
Come dissero nel 1995 e in tanti altri anni successivi... :)


 Come dissero nel 1995 e in tanti altri anni successivi... :)
 
L'avessi (io) detto nel 1995 adesso farei festa :-)) A star dietro a
delphi mi sono perso tante altre belle cose. Che ora rimpiango.


 delphi mi sono perso tante altre belle cose. Che ora rimpiango.
 
(Se non sono cose personali), tipo? :)


 Se si, cosa hai sviluppato?
 
Torniamo indietro a quattro anni fa: avevo sviluppato piccole desktop
application per fare pratica, mentre studiavo lazarus, poi avevo
progettato insieme a guastatore (vero esperto di lazarus) uno spooler di
processi, una specie di BPM, che si chiamava Altius. BTW, c'č ancora la
pagina aperta su ghitub (ah... bei tempi!) [1]
https://github.com/slapshot/altius
 
 
Dopo la progettazione rigorosa e attenta usando UML e scrivendo tutto in
inglese (l'idea era di reclutare in seguito altri sviluppatori
world-wide) la cosa non andň piů avanti perchč cambiai lavoro e
Guastatore ebbe anche lui dei problemi analoghi.
 
L'anno successivo trovai sul web un progetto GPL e supportato
commercialmente che faceva quello che avrebbe fatto Altius e anche molto
di piů [2], quindi la mia esperienza con Lazarus fině lě, senza essere
mai veramente incominciata.
 
Ai tempi avevo seguito per mesi e mesi la mailing list di lazarus e
avuto sempre delle risposte competenti e puntuali, Guastatore che (ai
tempi) utilizzava lazarus in produzione per dei suoi lavori mi ha sempre
sostenuto e consigliato.
 
Per questo motivo consiglio Lazarus senza timore di smentita a chiunque
volesse continuare a sviluppare come in delphi sotto linux: non vedo
migliore RAD in circolazione per il pinguino, considerando che ha una
community molto coesa e forte. E leggo ora che anche Marco ipotizza che
difficilmente vedremo mai embarcardero proporre qualcosa lato linux..
 
[1] 
https://github.com/slapshot/altius
 
[2]
http://www.sos-berlin.com/modules/cjaycontent/index.php?id=62&page=osource_scheduler_introduction_en.htm
 


 delphi mi sono perso tante altre belle cose. Che ora rimpiango.
 
Io non rimpiango il mio passato da sviluppatore delphista, perchè grazie
a lui ho portato a casa la pagnotta per quasi un decennio :)
Tuttavia, ho due cose sul groppo che non riesco a levarmi: il non aver
portato avanti Java e la programmazione server side, e non essermi fatto
l'esperienza con Visual Studio e .Net..
 
Rimpiango di non aver imparato in modo approfondito e veramente
competente Visual Studio + .Net perchè essere oggi un professionista
skillato con VS dà molte più garanzie che essere l'equivalente in
delphi. Per skillato, parlamoci chiaro, intendo dire di uno che sa dove
mettere le mani, conosce i tool e le librerie per togliersi d'impaccio
quando qualcosa va *molto* storto e la situazione precipita.
 
Con l'uso di Eclipse invece sto recuperando terreno, ma java è un mondo
completamente diverso dal compilato win32, dalle DLL, dalla memoria, dai
COM..con Java è tutto ingegnerizzato: si ragiona su UML, si va sui
concetti, si porta allo stremo il riutilizzo grazie ai pattern e alle
interfacce,e non immagini quanto si riesca a costruire meccanismi
potenti con una gerarchia di interfacce ben congegnata.
Ho avuto l'occasione di entrare a sviluppare su un framework
mastodontico, migliaia di sorgenti e decide di sottoprogetti (è un
desktop), per due mesi ho studiato sul libro dei GOF e sul framework del
progetto su cui mi trovavo, poi una volta imparato e messo in pratica,
ho ricevuto indietro tutti gli interessi: con poche righe combino i
pattern giusti e derivo le classi necessarie, e tutto gira come voglio,
senza bisogno di impazzire su memoria, dump dello stack e dei registri..
ma come dicevo sopra, è proprio un'altro mondo, java.


 pagina aperta su ghitub (ah... bei tempi!) [1]
 
 
Sui daemon ammetto di non aver provato.
Sui Web Service provaci e poi ne riparliamo.
 
A.

 ma come dicevo sopra, � proprio un'altro mondo, java.
 
Morde... praticamente il mio pensiero.


 senza bisogno di impazzire su memoria, dump dello stack e dei registri..
 
Al giorno d'oggi, queste si fanno con qualsiasi moderno linguaggio: sebbene sviluppo da anni con Delphi, non ho mai avuto bisogno di impazzire su stack e registri; anzi, ritengo un valore aggiunto il fatto di poterli analizzare qualora ve ne fosse la necessità.
 
Se si programma lato server, posso capire, ma dal lato delle applicazioni client, e ancora di più se ci si riferisce al supporto delle piattaforme iOS e Android (in arrivo), soprattutto comparando le funzionalità RAD disponibili in Delphi con quelle del citato Eclipse, tutto questo vantaggio della programmazione Java io non ce lo vedo, o almeno non mi pare così smisurato dal rimpiangere ogni singolo giorno a partire dal 1995 di aver appreso il linguaggio Delphi.
 
Poi, come sempre, senza nulla togliere né a Visual Studio né a Eclipse, il tutto dipende sempre dal tipo di applicazioni che si devono sviluppare, in primis.
 
Ciao,
  Marco.


 inferiore.
 
Non ha senso fare il ragionamento VS -> molta concorrenza,  Delphi -> poca
concorrenza.
Ihmo, Delphi non ha piu' motivo di esistere.


Sei un troll?
 
A.

 Ihmo, Delphi non ha piu' motivo di esistere.
 
Perché?


 Perch�?
 
Delphi e' uno strumento superato. Sempre imho, neh.
M$ con gli ultimi VS ha oramai messo a disposizione strumenti di sviluppo
che il Delphi lo spernacchiano abbondantemente.
Continuare a seguire Embarcadero a tutti i costi vuol dire farsi del male.


Se tu ti trovi meglio con visual studio hai fatto bene a mandare a fanculo delphi.
Io preferisco "farmi male" con embarcadero.
 
 
 
A.

 Io preferisco "farmi male" con embarcadero.
 
Mettiamo che domani o dopodomani Emb dica a tutti: "E' stato bello,
purtroppo chiudiamo...". Che fai?  Passi a Lazarus [cosa che ho fatto io
per portarmi avanti con il lavoro :-) solo per manutenzione di vecchi
progetti]? Aspetti la cordata di investitori che faccia resuscitare il
morto (chissa perche' Lazarus si chiama cosi')?


 purtroppo chiudiamo...". Che fai?  
 
 
Perche' ti interessa sapere questa cosa?
 
A.

 Continuare a seguire Embarcadero a tutti i costi vuol dire farsi del male.
 
A tutti i costi lo hai inserito tu.
 
Non si utilizza Delphi a tutti i costi, ma finché rappresenta uno strumento adeguato alle esigenze.
 
E' ovvio che se il tuo "core business" riguarda lo sviluppo di siti 
ASP.NET
, Visual Studio è senz'altro l'ambiente che devi utilizzare, ma non è detto che questo sia il target di qualsiasi altro sviluppatore, né che la colpa sia di Delphi nello specifico.
 
Se devi raccogliere delle foglie, un rastrello sicuramente "spernacchia" una ramazza, ma se devi spazzare in terra no.
 
Ciao,
  Marco.


 morto (chissa perche' Lazarus si chiama cosi')?
 
Questa non è una argomentazione valida, poiché quel tipo di discorso lo può fare tranquillamente qualsiasi azienda, anche senza chiudere i battenti, tant'è che Microsoft lo ha già fatto (con Visual Basic 6, FoxPro, J# e tanti altri suoi prodotti), sebbene l'azienda non abbia chiuso affatto.


 E' inutile continuare a ribadire che si tratta di un'opinione: sono le
motivazioni che interessano.
 
Inizia ad utlizzare VS C# Express vedrai che di motivazioni tecniche ce ne
sono a bizzeffe. Anche lato RAD. La VCL serviva anni fa, ora
sinceramente...


 Questa non � una argomentazione valida,
 
Mecojioni


Contento tu...
 
A.

 Contento tu...
 
Mo aspettiamo la perla dell'altro...


 sinceramente...
 
Per attività di consulenza su vari progetti, utilizzo tutti i giorni Visual Studio (e non la versione Express).
 
Se parliamo di applicazioni Windows, visto che hai citato la VCL, senz'altro quest'ultima è ben più fornita e completa rispetto a quanto si può trovare nella libreria "Windows Forms", senza considerare la gamma di componenti che è possibile trovare anche gratuitamente.
 
"Ora sinceramente" con Delphi e con la sola VCL ci sviluppi qualsiasi cosa tu stia realizzando con Visual Studio, con l'aggiunta del supporto ai temi, i Ribbon, interfacce stile Windows 8 e tante altre cose che in Visual Studio non trovi, a meno di non acquistare componenti di terze parti, che richiedono sempre e comunque il .NET Framework, salvo poche eccezioni.
 
Se si parla invece di altre librerie o tipi di applicazioni, il discorso è diverso, ma si tratta appunto di una questione di meri "tipi di impiego".
 
In verità, non si capisce neanche bene a cosa tu ti stia riferendo, visto che continui a rimanere nel vago.


 morto (chissa perche' Lazarus si chiama cosi')?
 
Borland ha chiuso, Delphi Rimane
Ashton Tate idem
Watcom, mi sempre che rimanga qualcosa.
 
 
Al limite si avr� un IDE non aggiornato annualmente.
 
Comunque penso che per MS "perdere Delphi" sia un danno.
 
 
 
-- 
-------------------------------
per scrivere in privato
togliere "1975nosp"
 
to reply remove "1975nosp"

 Poi, come sempre, senza nulla togliere n� a Visual Studio n� a Eclipse, il tutto dipende sempre dal tipo di applicazioni che si devono sviluppare, in primis.
Ho evitato di entrare nel giro dei flame, ma credo che possiamo
argomentare senza alzare i toni in un modo diverso.
 
Quello che intendo dire, fatte le dovute generalizzazioni, � che oggi tu
puoi benissimo scrivere buon codice con qualsiasi linguaggio ma l'uso di
differenti linguaggi porta a semplificazioni notevoli che possono fare
la differenza.
 
Vorrei spiegarti con un esempio triviale.
1 - In delphi per anni ho scritto codice event driven: il classico
onclick del tbutton che faceva qualcosa, ad esempio cambiava un testo in
un edit. Ma lo avrei fatto anche con visual studio, chiaro, perch�
entrambe usano un framework grafico pensato per eventi. In questo modo,
ogni form era impregnato di codice altamente accoppiato e poco coeso,
sei d'accordo?
 
2 - poi prendo java, e lui mi suggerisce una cosa diversa: sei
interessato al click di questo bottone? registrati come ascoltatore, e
sarai informato. Ecco, questo ragionamento gi� sale di livello: la
classe che si registra all'ascolto e la classe che pubblica gli eventi
non si conoscono. Inoltre, tante classi si possono registrare
all'ascolto e ognuna fare qualcosa in modo indipendente col contenuto
pubblicato. Qui gi� si usa un pattern in modo esplicito (anche l'onclik
di delphi � basato sul pattern observer, ma questi dettagli sono
volutamente nascosti dal framework: tu basta che riempi di codice
l'onclik())
 
3-  poi passo a Qt, e lui mi dice un'altra cosa ancora: il bottone,
quando cliccato, emette un segnale. Tu puoi collegare il segnale di
click a tanti slot di oggetti diversi in modo che ogni oggetto faccia
quello che vuole.
E' ancora migliore di java perch� in esso quando un oggetto pubblica
qualcosa deve scorrere la sua lista interna di observer e notificarli
tutti, e gli osservatori devono implementare un'interfaccia specifica:
c'� del lavoro da fare da entrambe le parti.
Invece con Qt puoi agganciare il click di un bottone ad un qualsiasi
slot di un oggetto, senza che quest'ultimo debba sapere perch� � stato
chiamato ad eseguire quello slot, e da chi. Totale indipendenza, facile
manutenzione e codice responsabile.
 
Come vedi, tre modi diversi per fare la stessa cosa: eppure, quando uso
un observer con java oppure mi collego col mio oggetto ad un segnale, le
cose mi vengono pi� semplici.
Sono pi� libero di pensare al disegno dalla mia architettura e alle
responsabilit� dei miei oggetti. Non mi sento incollato al sorgente
della form, dove nella procedura che gestisce l'evento devo metterci
tutto il codice, mischiando oggetti tra loro estranei e creando degli
aggregati di codice e logiche pi� difficili da manutenere.
 
Ovviamente � possibile usare i patterns, l'ereditariet� e le interfacce
anche con delphi, ma se dovessi farlo oggi (e lo sto facendo), userei
altri linguaggio pensati per facilitare questo approccio semplicemente
perch� � pi� facile e mi porta pi� vantaggi nel tempo.
That's it.


 Sui Web Service provaci e poi ne riparliamo.
 
Scrivere un WS con Lazarus per linux? Non credo proprio.
Lazarus lo userei per fare desktop application arrivando da delphi senza
dover perdere tempo ad impararmi Qt o altri linguaggi.
 
Se dovessi fare un WS leggero e non troppo complesso, io che non ho
fatto molto sviluppo server side partirei con Ruby on rails, magari da qui:
http://railsforzombies.org/
 
 
:-)


 fatto molto sviluppo server side partirei con Ruby on rails
 
Perche'?
 
A.
 
 
 
 
 

 Perche'?
 
Perch� mi � stato pensato per facilitare questo tipo di cose e i miei
colleghi me l'hanno sempre suggerito. Prova a guardarlo e poi mi dici se
avevano ragione :)


 Comunque penso che per MS "perdere Delphi" sia un danno.
 
A M$ non frega una fava di Delphi.


 perchè è più facile e mi porta più vantaggi nel tempo.
 
E' vero che Delphi si trascina alcuni elementi fastidiosi, ad esempio richiede l'assegnazione di un GUID alle interfacce, ma in generale credo sia più facile per te scrivere le architetture con altri linguaggi perché hai appreso queste nozioni nel loro contesto, ma questa è ovviamente solo un'opinione del tutto personale. :)


 A M$ non frega una fava di Delphi.
 
Per me, questa è l'unica cosa esatta che hai detto fino a ora. :)


ma questa � ovviamente solo un'opinione del tutto personale
 
Si, proprio quello che intendo dire: ho imparato le cose nel *proprio
contesto* e penso che su alcuni argomenti (grafica, gestione della
business logic, disegno dell'architettura, uso di patterns, test di
unit�) io abbia vantaggi notevoli ad utilizzare un framework diverso da
quello *da me conosciuto*, il vetusto Delphi 7.
 
Questo significa anche che con delphi ho avuto un'esperienza d'uso quasi
totalmente limitata allo sviluppo procedurale e disegni scevri di
pattern e classi, una formazione spesso da autodidatta e posti di lavoro
che quasi sempre si sono basati su codice preesistente e ruoli di
manutentore e bug fixing.
 
Mi � altrettanto chiaro che tu che hai avuto una formazione migliore e
continua con il RAD, lo possa usare con disinvoltura laddove io getterei
la spugna e passerei ad altro ambiente :)
 
Resta sempre sottinteso che le scelte degli strumenti dipendono dal tipo
di progetto che sei chiamato a sviluppare.


 la spugna e passerei ad altro ambiente :)
 
E' che, in buona sostanza, le architetture, il "disegno del software", la progettazione e così via a noi piace: dovendo realizzare applicazioni per Windows, io le ho applicate su Delphi, mentre le ho impiegate in Visual Studio quando si è trattato di 
ASP.NET
 o altri servizi basati sul framework, mentre tu le hai applicate ai framework che utilizzi per le piattaforme che ti vengono richieste. Penso che sia tutto qui. :)
 
Ciao!


 avevano ragione :)
 
Appena posso vedro' questa cosa, ma rimane "scripting", giusto?
 
A.

> Passa a Lazarus, consiglio spassionato.
 
cosa hai svilupato con lazarus?
 
A.
 

 cosa hai svilupato con lazarus?
 
Perche' ti interessa sapere questa cosa? (cit.)


 Perche' ti interessa sapere questa cosa? (cit.)
 
Giusta osservazione! 
 
Visto che suggerisci tale strumento, sarebbe utile la condivisione della tua personale esperienza.
Ad esempio, io suggerisco spesso vini ad amici, ma i vini che suggerisco io li ho bevuti.
 
A.

 di progetto che sei chiamato a sviluppare.
 
 
Magari io con QT, Java, Python o C++ mi blocco su una cosa banale, ma questo e' dovuto al dover acquisire un minimo di know-how. Il tempo usato per fare cio' e' un investimento.
 
Sudare e sfornare parolacce a nastro davanti alle paturnie di uno strumento che semplicemente non funziona o funziona in modo DIVERSO da quanto documentato e' una PERDITA di tempo, alla quale si aggiunge  la frustrazione di dover leggere post di gente che dice "magnifico, potente, comodo....".
 
Non mi aspetto la PERFEZIONE ma nemmeno un prodotto che inizi ad usare e dopo 5 minuti SEI GIA' FERMO PER CASINI SUOI.
 
A.