Newsgroup: it.comp.lang.delphi
Titolo: [Semi OT] Delphi e .Net

Mi sto ponendo molte domande su questa storia di .NET.
Se non vado errato, questa nuova robaccia di zio Billy dovrebbe
essere presentata ufficialmente (di sicuro con il solito nutrito
contorno di schermate blu, dump esadecimali e gpf come se piovesse...)
il mese prx.
Ma, visto che in questa robaccia ha le mani in pasta quel tipo di cui
non ricordo il nome che ha lavorato anche su delphi, forse non dovrebbe
essere tanto male, o no?
Ma qui mi chiedo...
al momento che esce .Net, di delphi cosa ne sarà?
Borland continuerà a seguire solo Kilyx "mollando" delphi e WinSozz?
I 2 prodotti (delphi e 
vb.net
) sono effettivamente in
concorrenza o si pongono su target e/o livelli differenti?
Nel 2' caso, borland sfornerà un "qualcosa" paragonabile a 
vb.net
?
VbNet sarà OOP o zio Billy continuerà a spacciare quel modo
orribile di programmare come OOP?
Scusate se ho remixato cose che magari non hanno alcuna attinenza,
ma ci sto + capendo un saciccio in questo casino.
Bye
AS
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 wrote in message
news:355e49247264f1f096...@mygate.mailgate.org...


 al momento che esce .Net, di delphi cosa ne sarà?
Il C#, che e' forse la cosa piu' interessante di .NET, 
e' Anders Hejlsberg, l'inventore del Turbo Pascal.
E' sicuramente una novita' che non puo' essere
ignorata, ma in ogni caso il polpettone .NET (che e' un 
layer API object oriented e memory managed) va inghiottito
tutto intero, perche' MS ha annunciato che l'uso che oggi si 
fa delle API classiche non sara' piu' supportato dalle
future versioni di Windows.
La domanda e': ci sara' un Delphi .NET ?
Puo' darsi che non sia aggiornato, ma non so darti una 
risposta (e penso che non sappiano ancora dartela nemmeno
in Borland).  Per adesso, con Delphi, e' solo possibile
costruire oggetti 
ASP.NET
.


 e' Anders Hejlsberg, l'inventore del Turbo Pascal.
Scusa, ho esagerato sconfindando nella impersonificazione.
Volevo dire che il C# e' stato inventato da A.H.


 in Borland).  
Quindi, se non ho capito male, un ipotetico 
delphi.net
 si dovrebbe
appoggiare al layer di cui sopra?
Se č cosě, č come se tutti i linguaggi Windows si appoggiassero
ad un unico modulo di runtime come ora si appoggiano alle API
di WinSozz....
Ho deciso di cambiare lavoro...
Scelgo qualcosa di + semplice: il dba di oracle!
AS


 future versioni di Windows.
premesso che la mia conoscenza di .NET è pressochè nulla ... posso chiederti
una dolorosa "conferma al 100%" di quanto hai scritto?
Tu dici che il gruppo di Gates si prende la libertà di cestinare milioni di
programmi che sfruttano direttamente l' API di Windows? Sinceramente mi
semrbra strano ... ma poi in questo modo imporrebbero la ricreazione di
*tutti* i Framework la cui esistenza si fonda sulle System Call messe a
disposizione dall'ambiente Win32 e la riscrittura di tutti i programmi che
fanno riferimento a quei Framework (salvo che non ci sia un aggiornamento
indolore da parte del produttore del Framework)  ...
Sono perplesso ... è possibile (mi sto arrampicando sugli specchi) che venga
fornito una sorta di sottosistema di emulazione che permetta alle vecchie
WinAPI based application di funzionare sul magico mondo .NET? Un po' come è
stato fatto per il vecchio DOS sulla piattaforma Win32 ...
Ciao! :-)
--
- Carlo -
c.b...@libero.it

 di WinSozz....
Lo fanno gia'.  Tutti usano le DLL di sistema.
In realta', il succo non cambia.
Credo (e sottolineo *credo*) si tratti solo della possibilita' 
di gestire un framework di interfaccia col sistema operativo 
in modo nativo (creare oggetti, distruggerli, ecc...).  
Immagina un oggetto TForm, che anziche' appartenere alle 
librerie VCL, appartiene, invece, alle librerie di sistema.
Da un certo punto di vista e' intrigante.


 WinAPI based application di funzionare sul magico mondo .NET?
Non ne ho idea.  Certamente MS ha un interesse minimo 
nel farlo.  Lei punta su Visual Studio .NET.


Scelgo qualcosa di + semplice: il dba di oracle!
Si guadagna bene? :)
-- 
Lawrence "Rhymes" Oluyede (
rhy...@myself.com
)
"Per cambiare, per diventare un'altra
cosa dobbiamo prima sapere cosa siamo"
(Bruce Lee)

Si guadagna bene? :)
Oracle, oltre ad essere un ottimo DBMS, costituisce un vero
e proprio ambiente di programmazione ed e' molto richiesto.
La figura di "programmatore Oracle" non e' affatto male.
-- 
Andrea Laforgia - walkietalkie(at)
libero.it
"Meglio cieco che negro" (Stevie Wonder)

La figura di "programmatore Oracle" non e' affatto male.
mmm mi metterò sotto allora ma come si impara?
sappi  che io ho un pc e basta..


 sappi  che io ho un pc e basta..
Se puoi permetterti Oracle fammene una copia pirata! :-)
Oracle è sicuramente il miglior DBMS disponibile, una garanzia di sicurezza
per i dati. Il mio docente di basi di dati in università spesso diceva "La
definizione di DBMS non è appropriata per Oracle, infatti questo è molto di
più ... si avvicina più ad un vero e proprio Sistema Operativo!" ...
ovviamente era una definizione esagerata, però lascia intuire la sua
grandezza. Mi risulta però che le licenze costino molto.


grandezza. Mi risulta però che le licenze costino molto.
Esagerata, ma non molto distante dal vero.
Oracle e' un'opera dell'ingegno a dir poco mostruosa e,
forse, battuta solo da DB2 di IBM, che e' un altro colosso
indistruttibile.
Tempo fa si mormorava che la stessa MS tenesse i suoi dati
sotto Oracle (cosa molto strana, a detta di tutti, visto che
produce SQL Server!). Che non si fidi di se stessa ? :)
In ogni caso, se e' vero che le licenze di Oracle costano
parecchio (Oracle9i Enterprise, se non erro, oscilla da 800
a 24000 dollari, la Standard da 300 a 9000) e' anche vero
che da 
http://otn.oracle.com
 e' possibile scaricare le
versioni gratuite per lo sviluppatore.
Di Oracle esiste anche una versione Light, chiamata POL
(Personal Oracle Light).


 (Personal Oracle Light).
Oracle9iLite5.zip (364,604,166 bytes)
Lite?? cavoli :) con il 56k ci metto 3 mesi...
Comunque anche se potessi scaricarla da un amico avrei
bisogno di informazioni :) In pratica che posso fare di
concreto con Oracle?


Diciamo che, in ambito di database client/server relazionali,
si fa forse prima a dire cosa NON puoi fare con Oracle....
Sfogliando rapidamente il manuale della 9i, mi sono fatto l'idea
che o hanno pensato a tutto o ci sono andati maledettamente vicini.
Terabyte di dati, stored procedure scritte anche in java, multipiattaforma,
10.000 parametri sul server da configurare che ti fanno magari bestemmiare
alla grande, ma ti garantiscono una grande flessibilità, possibilità
di intervenire ad un livello che ti permette di configurare l'organizzazione
logica dei dati ed il modo di gestire gli indici, query configurabili
per l'esecuzione in parallelo.
Dimenticavo, nella doc si parla anche di oggetti, ma non chideremi
dettagli: ho sfllgiato la guida molto rapidamente in un raro attimo 
di respiro.
Ma, prima di tutto, FUNZIONA.
Tieni conto che x gli sviluppatori è gratis.
Lo pagano solo gli utenti finali, e non poco....
Se vuoi fare dei test, sappi che il server gira anche su Win2000prof,
a differenza di M$Sql, che VUOLE un server (NT o 2000) altrimenti
col kakkio che si installa..
Bye
AS


 di WinSozz....
Se è come penso io, sarà come avere una versione della VCL
integrata direttamente nel SO. Quindi un ipotetico Delphi.NET
dovrebbe essere addirittura più snello di ora, visto che buona
parte di quello che adesso mette lui nell'EXE sarà nel SO stesso
(che di contro sarà invece più pesante e affamato di RAM, HD
e CPU...)
L'altra faccia della medaglia è che un pò tutti i compilatori .NET
finiranno per somigliare a Delphi, visto che condivideranno
un'impostazione ad oggetti simile.
Vuoi vedere che la Microsoft ha copiato l'idea .NET
da Delphi? :-( E adesso ce la propina come rivoluzionaria
(e sua originale)? :-((


Ma come la mettiamo con questioni di performance ? Per molte applicazioni è
già lenta l'api Win32. Chi mi fornirà un buon Timer.NET con tempi di latenza
minimi ? Cosa ne sarà
di tutte le applicazioni di automazione e controllo sviluppate sotto Windows
?
Dovranno migrare tutte ad un altro sistema operativo ?
Non fraintendetemi. Un sistema operativo con api rigorosamente OOP sarebbe
fantastico,
ma ho paura che la Microsoft abbia fatto il solito nuovo strato di software
mal funzionante
ed incontrollabile.
Oramai siamo agli hamburger...
Che ne direste di aggiungere una spruzzatina di ketchup e maionese ?
-=SIMO=-

mal funzionante ed incontrollabile.
Non credo, anche perche' ha acquistato diverse menti
illustri e le ha messe all'opera.
Mai giudicare, senza provare :)


 dell'equivalente procedurale.
Scusa, questa me la dovresti spiegare... io credevo
che fosse il contrario :-?

che fosse il contrario :-?
Ti sbagliavi.
Gli oggetti, grazie all'incapsulamento, uno dei cardini
della OOP, riescono, molte volte, a rendere piu' veloce il
codice.  Si puo' fare un esempio banale.
Considera un'ipotetica classe CString, che incapsula una
stringa e le operazioni possibili su di essa (es.:
GetLength, per ottenerne la lunghezza).  GetLength potrebbe
fare riferimento ad una variabile interna alla classe che
conserva costantemente la lunghezza della stringa.
Il tempo impiegato in chiamate successive a GetLength e' di
molto inferiore al tempo impiegato in chiamate successive a
StrLen.  In generale, comunque, gli oggetti possono
ottimizzare, al loro interno, l'uso di una particolare
struttura dati e la cosa bella e' che il grado di
ottimizzazione puo' essere un requisito (per esempio, la
libreria standard, distribuita con un qualsiasi compilatore
C++, secondo l'ISO C++, deve avere dei requisiti minimi in
quanto a prestazioni).


 wrote in message
news:3c499e2...@news.tin.it...


 non addirittura l'assembler) e non il C++ o il Delphi.
Falso anche questo.  
Delphi ha una velocita' paragonabile a quella del C++ 
(te lo dice uno che programma prevalentemente in C++).
Tra l'altro, il C++, per molti versi, e' molto piu' 
performante del C.  L'unico svantaggio del C++ e'
l'enorme complessita' che lo ha reso la scelta meno
consona in progetti a piu' mani, in cui e' necessaria
una conoscenza diffusa del linguaggio (vedi il kernel
di Linux).


 wrote in message
news:d31b683e5814a0760da...@mygate.mailgate.org...


 wrote in message
news:a2h2oi$91l$1...@fe2.cs.interbusiness.it...
Consideriamo il problema della concatenazione di stringhe.
Sai coma la fanno C++ e Delphi? Hai presente come si fa in C?
Bene.
Adesso supponi di averne molte da concatenare e vedrai che accantoni la
bellissima classe OOP string e torni ai puntatori inventandoti il
sistema di
ridurre il numero di allocazioni e copie.
Te lo dico per esperienza diretta.
 
    Io non abbandono un bel niente ;)   
    Il C non supporta le stringhe, non ha quindi modo di sapere dove
termina
    una stringa se non per lettura dell'intero vettore di caratteri.
    Delphi usa una struttura simile a quella del C.
    Il C++ usa una classe ottimizzata per lo scopo.
    Tieni presente che l'ordine di complessita' dell'algoritmo di
concatenazione
    di stringhe, secondo il C, e' O(n) (pessimo).    
    Un oggetto puo' sicuramente ridurre il fattore di complessita'.
In generale, in base alla mia esperienza, la OOP ti porta ad avere un
numero
maggiore di operazioni effettuate (come ad esempio chiamate a metodi),
 
    Le chiamate a metodi non sono altro che normali chiamate a funzioni,
    non implicano alcun codice in piu'.
La OOP è un modo di pensare, che ha un prezzo.
 
    No, la OOP e' un paradigma di programmazione, non un modo di
pensare.
    I prezzi che si pagano con la OOP sono molto piu' bassi di quelli
che
    si pagherebbero con la programmazione procedurale, se si cercasse di
    mettere in piedi gli stessi meccanismi.  Ci sono alcuni casi in cui
la
    programmazione classica conduce a codice + veloce e la stragrande
    maggioranza dei casi in cui non e' cosi'.
Se vuoi un esempio non informatico pensa alle schede hardware.
La modularizzazione in chip separati ha il prezzo della velocità più
bassa.
    Non c'entra nulla questo esempio con cio' che stiamo dicendo.
    La modularizzazione hardware ha un impatto sulla "fisica" degli 
    elementi coinvolti.  Il software non ha vincoli fisici come
l'hardware.
Con questo non voglio assolutamente dire che la OOP è da buttare. Anzi.
    E vorrei vedere :)
Però, come tutte le cose, ha un suo ambito di applicazione ben preciso.
    Ha un suo ambito di applicazione, ovviamente, che e' molto vasto.
In termini di prestazioni, meno cose fai meglio è.
    La OOP non fa nulla in piu' rispetto a cio' che si farebbe per via
    procedurale e, la maggior parte delle volte, lo fa meglio e in modo
    piu' performante.
L'assembler fa solo operazioni strettamente necessarie.
    Ok, scrivimici un gestionale ;)  
Più si sale di livello più operazioni "inutili" vengono effettuate,
anche se
non te ne rendi conto.
 
   Tu giudichi l'inutilita' delle operazioni solo da un punto di 
   vista prettamente quantitativo, ma non qualitativo.  
   Avere delle operazioni in piu' (ripeto: l'OOP, la maggior parte delle
   volte, non introduce alcun overhead rispetto al paradigma 
   procedurale) puo' implicare anche avere codice migliore e
   piu' performante.


    piu' performante.
Dipende tutto dagli algoritmi.
Non metto assolutamente in discussione l'OOP, che ritengo irrinunciabile.
Overhead di elaborazione ce ne sono, impliciti nei meccanismi implementati o
dovuti alla strutturazione delle applicazioni.
Ciao
GG

    piu' performante.
Dipende tutto dagli algoritmi.


dovuti alla strutturazione delle applicazioni.
Ti ripeto che non e' vero, la maggior parte delle volte.
Evidentemente abbiamo delle convinzioni derivanti da
esperienze diverse, per cui direi di troncare qui la
discussione.


 wrote in message
news:3c4c56a...@news.tin.it...
