Newsgroup: it.comp.lang.vo-clipper
Titolo: Nostalgia del Clipper

Ciao a tutti
scusate questo OT, mi chiamo Augusto e lavoro da 13 anni in questo campo.
Ogni tanto vengo preso da nostalgia e vengo a leggere i post di questo
newsgroup. Rimpiango gli anni d'oro del Clipper, l'ho abbandonato da quando
la nantucket (si scriveva cosi'???) e' stata comprata dalla C.A.... Ricordo
che attorno al Clipper c'era fervore, tanta gente che lo utilizzava,
librerie, codici di esempio...poi il nulla o quasi. Leggevo prima che non
riuscivate a raggiungere un numero di 25 persone per un meeting....e allora
mi chiedevo se ne valeva veramente la pena di spendere tempo e risorse su
tale linguaggio. Dico queste cose con un profondo senso di rammarico e con
la speranza di una solenne smentita. Giuro che riprenderei subito i manuali
in mano e mi rimetterei a programmare....sono sicuro che chi ancora lo
utilizza ne' e' convinto, ma vorrei capire quali saranno gli sviluppi futuri
sempre che ce ne siano.
Grazie per qualsiasi risposta.
--------------------------------
Inviato via 
http://usenet.libero.it

 tale linguaggio. 
Ti posso assicurare che VO è uno strumento molto potente e versatile per 
creare applicazioni gestionali, ma si tratta di uno strumento fatto 
soprattutto per professionisti.
Io personalmente non uso uno strumento perchè lo usano in tanti, ma perchè mi 
permette di fare il mio lavoro meglio e in minor tempo. Finchè VO sarà 
supportato, lo userò.
Saluti
Wolfgang
Merano

Non ho capito bene, parli di uno sviluppo futuro di Clipper?
Se č cosě mi sa che fai meglio a lasciare i libri li dove sono......
Ciao.
                            Francesco

 Se č cosě mi sa che fai meglio a lasciare i libri li dove sono......
Se non ricordo male la GrafX sta lavorando a Clipper 5.4
--
Alessandro Maiucchi
maiu...@libero.it
http://maiucchi.supereva.it
(Basta!-Scrittura creativa-Rush-Queen-Kiss-Blade Runner)

 ha scritto nel messaggio
news:192Z106Z120Z226Y...@usenet.libero.it...

Penso che le 25 persone (tra cui anch'io) l'anno scorso erano piu' di 50.
Penso che in italia ci siano piu' di qualche centinaio di sviluppatori in
VO.
Penso che in italia ci siano migliaia di di sviluppatori Clipper ( anch'io)
e che molti ancora non abbiano scelto il linguaggio per windows.
Penso che nel mondo ci siano molti sviluppatori VO.
Penso che il VO 2.6 uscira' il 15/ottobre/2002
Penso che e' gia' in cantiere la versione 3.0 (.NET)
Ciao,
      Fabrizio Malaguti


 sempre che ce ne siano.
Gli sviluppi, piů che futuri, direi che sono attualissimi. Secondo me
non c'č mai stato tanto movimento come oggi intorno a questo tipo di
linguaggi.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 Se č cosě mi sa che fai meglio a lasciare i libri li dove sono......
E perché? Non vedi quanti tipi di strumenti diversi esistono oggi basati
sui linguaggi xBase? Preferisci forse il Visual Basic o schifezze MS del
genere?



Sul loro sito non vedo niente in proposito...


Scusa ma facciamo paragoni che non stanno in piedi. Clipper è un linguaggio
dos, VB, per quanto faccia schifo, è comunque un linguaggio windows. La
compatibilità verso i sistemi dos sta scomparendo, già xp l'ha resa
tollerata, ma pare che andrà man mano sempre più scemando.
La domanda iniziale era:
<<....e allora mi chiedevo se ne valeva veramente la pena di spendere tempo
e risorse su
tale linguaggio.>>
Secondo me la risposta è no!

 Penso che e' gia' in cantiere la versione 3.0 (.NET)
Volevo solo puntualizzare che Clipper non è solo VO. Ci sono tantissimi
altri strumenti commerciali e open source per tutte le piattaforme.
Quindi la scelta per chi viene da Clipper è vastissima.


 Secondo me la risposta è no!
Se parliamo di CA-Clipper sono d'accordo con te ma se parliamo di
linguaggio allora, ad esempio, neanche per VO ne varrebbe la pena e
invece sappiamo che c'è qui molta gente che la pensa diversamente.


 Quindi la scelta per chi viene da Clipper è vastissima.
In questo hai perfettamente  ragione. Rispondevo solo ad Augusto che era
perplesso del fatto che ad un meeting di VO ci siano solo 25 persone.
Poi aggiungo che con .NET della Microsoft  :-<  si arrivera' al fatto che
ogni linguaggio andra' bene (cambiera' solo la sintassi di come uno scrive i
programmi).
Ciao,
      Fabrizio Malaguti


 programmi).
Conoscendo ormai la MS e i suoi prodotti da ormai un ventennio, dubito
molto che .NET andrà molto oltre quello che esiste già adesso con
Windows, le sue API e le varie interfacce per la gestione dei databases.


tollerata, ma pare che andrà man mano sempre più scemando.
La questione non e' Clipper, ma piuttosto una implementazione moderna
di questo linguaggio.  Per quel che mi riguarda penso che Clipper sia
morto, io non credo che la versione che sta sviluppando GrafX abbia un
futuro, e' solo una patch.
Pero' come molti, mi auguro che qualcuno produca una versione moderna
di Clipper o "linguaggio xbase", la richiesta c'e', la base del
linguaggio e' valida, e (IMHO) finora il vuoto lasciato da Clipper non
e' ancora stato colmato.
ciao, acc.   
a...@libero.it

mezzo sgorbio che è stato fino alla Summer 87.
Tsk tsk, tu sputi nel piatto in cui mangi ;-)
A suo tempo la Summer 87 era un'ottimo prodotto.
ciao, acc.   
a...@libero.it

 e' ancora stato colmato.
Purtroppo sono d'accordo con te, io ho la mia soluzione di ripiego ed
alla fine sono abbastanza soddisfatto, ma il livello di produttivita'
di Clipper 5.2 era veramente eccellente, se la CA invece di fare VO
avesse fatto una specie di Harbour + FiveWin + Editor di Forms e Reports
come era nei piani originali della Nantuket, ora molti di noi sarebbero
piu' contenti.
-- 
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net


Mi ricollego al discorso di prima. Se la CA avesse incluso anche il VO SDK
le cose sarebbero andate diversamente.
In Windows c'è un grosso scoglio da superare ed è quello che il OS prende il
controllo di tutte i programmi e le risorse (a differenza del DOS che era il
programma a gestire tutte le risorse); questo comporta una gestione degli
eventi. Per facilitare questa gestione si sono diffusi linguaggi OOP. La
gestione a oggetti infatti permette di semplificare tale gestione. VO, fin
da subito gestisce tutto con la OOP. Per il resto VO è praticamente CLIPPER
con la tipizzazione delle variabili (Che lo rende veloce quasi quanto il C++
[ senza scomodare la gestione coi puntatori]  ).
Per il resto penso che VO sia valido come Harbour e FiveWin ( anche se non
li ho provati mi fido di quanto dice EMG ).
Io mi trovo bene con VO e per me, ora,  non avrebbe piu' senso optare per
gli altri. Comunque io considero VO l'erede naturale del CLIPPER.
Ciao,
      Fabrizio Malaguti


 A suo tempo la Summer 87 era un'ottimo prodotto.
Scherzi? Forse hai dimenticato che tipo di linguaggio era? Ti faccio
solo un esempio: non aveva le variabili locali...


 e' ancora stato colmato.
Prova le Fivewin e ti convincerai del contrario. Prova Harbour o
xHarbour. Il Clipper esiste ancora ed è più vitale che mai.


 piu' contenti.
Ragazzi, andate un pochino a vedere le novità della Fivetech e poi mi
dite. Tutto quello di cui parlate già esiste.


 Comunque io considero VO l'erede naturale del CLIPPER.
Non tutti la pensano cosi' altrimenti non staremo a parlare di questo
argomento ad ogni pie' sospinto.


 renderli disponibili.
Vero. Anche la Fivetech ha sempre fornito quelli delle Fivewin (non solo
delle GUI ma di tutta la libreria tranne il core più interno) e
rappresentano veramente un valore irrinunciabile.


Ti faccio solo un esempio: non aveva le variabili locali...
Fammi un esempio di un linguaggio simile (sempre dello stesso periodo)
che le aveva.  ;-P
ciao, acc.   
a...@libero.it

piu' contenti.
Secondo me VO e' un ottimo linguaggio, quello che non mi piace e' che:
- e' chiuso, troppo chiuso, dannatamente chiuso !!!
- ha diversi bug, e quel che e' peggio mal documentati
- ha una pessima assistenza
ciao, acc.   
a...@libero.it

Il Clipper esiste ancora ed è più vitale che mai.
Non mi riferivo all'utilizzo di Clipper, (guarda che io lo uso tutti i
giorni), ma allo sviluppo dello stesso che e' morto da tempo.  Il
fatto che CA lo abbia ceduto e' abbastanza significativo.
ciao, acc.   
a...@libero.it

 che le aveva.  ;-P
No, non c'era. Ma utilizzando altri compilatori (Turbo Pascal, Turbo C)
la differenza si sentiva e come.


 fatto che CA lo abbia ceduto e' abbastanza significativo.
Neanch'io mi riferivo al compilatore CA-Clipper ma al Clipper come
linguaggio di programmazione.


Mah... linguaggio chiuso proprio non direi !!!  Adesso poi che hanno messo
l'SDK nella 2.6

l'SDK nella 2.6
Mi riferivo a Clipper !
ciao, acc.   
a...@libero.it

la differenza si sentiva e come.
Vero, ma con quei linguaggi di database proprio non se parlava !
Le alternative a Clipper erano: QuickSilver, dBase o Cobol.
Ognuno aveva i suoi difetti, IMHO Clipper offriva di piu'.
ciao, acc.   
a...@libero.it

 Mi riferivo a Clipper !
Veramente anch'io avevo capito che ti riferissi a VO. La tua frase
lasciava pochi dubbi. Comunque, se parlando di chiusura ti riferivi a
Clipper, io non condivido affatto. A me Clipper è sempre sembrato uno
strumento estremamente aperto.


 Ognuno aveva i suoi difetti, IMHO Clipper offriva di piu'.
Senza dubbio. Il S87 aveva molte comodità per la gestione dei database
ma come linguaggio in sé, considerando che la tecnologia c'era da un
pezzo, valeva molto poco.
A proposito: mi sono accorto che non riesco più a far funzionare le
Norton Guides del Clipper sul mio Windows XP Pro SP1. Nessuno sa come
posso fare?


posso fare?
Potresti provare WEG dal sito di Dave Pearson
(
http://www.davep.org/clipper/
), o da altri siti che hanno tools free
per Clipper.
ciao

 per Clipper.
Grazie, proverò...


Mi riferivo a Clipper !
Anzi no, mi riferivo a VO !  Azz... devo proprio essere rincoglionito,
avevo inteso "chiuso" riferito allo sviluppo.
Ricapitolando:
Clipper e' morto nel senso che lo sviluppo dello stesso e' terminato
da un pezzo, anche se qualcuno (compreso il sottoscritto) spera ancora
in un atto di clemenza da parte di GrafX.
VO, e' un ambiente chiuso, nel senso che e' praticamente impossibile
integrarlo con altri strumenti di sviluppo (make, editor, etc.).
Come linguaggio non e' affatto male, anzi, e se a qualcuno piace cosi'
com'e' fa bene ad utilizzarlo.  Per quanto mi riguarda, ogni volta che
sento parlare di repository e ogni volta che vedo l'editor di VO mi
viene da piangere.
ciao, acc.   
a...@libero.it

 ciao, acc.   
a...@libero.it

 in un atto di clemenza da parte di GrafX.
Brian aveva annunciato di pensare a un ulteriore sviluppo del Clipper in 
quanto in certi paesi si vende ancora, e ci sono delle giornate nelle 
quali lui vende più Clipper che VO. Una volta in un messaggio nella ng 
internazionale ha scritto che gli è costato parecchio a convincere la CA 
a rifare una partita di Clipper.
Saluti
Wolfgang 
Merano

 sembra che altri linguaggi utilizzano un proprio repository.
Non cosě che io sappia.
Delphi ha un file di testo per il codice ed un file binario/testo (a seconda
delle versioni) per i form. Tutto puň essere compilalto anche da linea di
comando. VB ha un file di testo che contiene tutto form e codice, il C/C++
normalmente ha files di testo e la make.


 sembra che altri linguaggi utilizzano un proprio repository.
Posso dire, conoscendolo, che il Visual Basic non lo utilizza e si basa
semplicemente su di un insieme di file di testo. Per altri strumenti non
ti so dire.


 Nel secondo caso serve a poco.
Una volta associato il file, con l'editor di VO si puo' modificare il file.
Il prg viene modificato di conseguenza. VO comunque mantiene il tutto nel
repository. Non ho mai provato a fare il contrario, cioe' una volta
associato il file modificarlo con un altro editor e verificare se il
repository rimane allineato al prg (secondo me si, pero' dovrei verificare).
ciao,
     Fabrizio Malaguti


 repository rimane allineato al prg (secondo me si, pero' dovrei verificare).
questo funziona. Lo uso in due differenti situazioni continuamente:
1) le stringtable che contengono le traduzioni vengono creati dal mio 
dictionary editor - un programma scritto in VO e esterno alla IDE. Al prossimo 
compile VO si legge il file dentro il repository.
2) ho del codice condiviso tra più progetti, anzi, tutte le mie librerie sono 
composte da moduli associati a file esterni. Se modifico una libreria in un 
progetto, al prossimo compile negli altri progetti le variazioni le ho anche 
li.
Saluti
Wolfgang
Merano

sembra che altri linguaggi utilizzano un proprio repository.
L'IDE di VO (quello attuale) non e' nulla di eccezionale, anzi,
rispetto agli altri IDE (attuali) e' piuttosto superato e quel che e'
peggio e' anche piuttosto scomodo.
Pero' a mio avviso questo e' un problema secondario, quello principale
resta la "chiusura" sia del compilatore (vedi make), che di tutto
l'ambiente (formati "proprietari", niente standard).
ciao, acc.   
a...@libero.it

linguaggio di programmazione.
Sono d'accordo, come mi pare di aver gia' detto, il vuoto lasciato da
Clipper non e' ancora stato colmato, chissa', se dopo il C hanno fatto
il C++ cosa vuoi che sia aggiungere due + dopo la parola Clipper :-)
ciao, acc.   
a...@libero.it

 li.
Questo e' positivo, per vari motivi e' una funzionalita' importante. C'era anche
in VO 1.0?


 il C++ cosa vuoi che sia aggiungere due + dopo la parola Clipper :-)
Continuo a non capire. Harbour contiene già praticamente tutto quello
che faceva Clipper più molte estensioni solo che è a 32 bit
multipiattaforma. Cosa si può volere di più?


 in VO 1.0?
Mi pare che il concetto di "libreria" sia ben precedente sia a VO che
allo stesso Clipper.


 l'ambiente (formati "proprietari", niente standard).
Anch'io all'inizio ho storto il naso per il fatto di non avere piu' la
possibilita' di eseguire da console il MAKE di un programma ( come si usava
fare in CLIPPER), pero', ora che mi ci sono abituato non mi sembra poi tutta
questa mancanza.
Per quanto riguarda i formati proprietari e lo standard potresti essere piu'
preciso? Perche' cosi' non riesco ad inquadrare il problema.
Ciao,


 ti so dire.
Non conosco l'IDE del VB ( a dire la verita' non ho mai considerato VB un
linguaggio da tener conto e mi sono sempre rifiutato di conoscerlo meglio );
Comunque di che versione di VB parli? Perche' penso che quello del  
VB.NET
dovrebbe essere simile a quello del C# /C++.NET ecc).
La mia č piu' una domanda che un'affermazione.
Ciao,
      Fabrizio Malaguti
P.S.
    Non centra nulla con tutto cio'. Hai programmato sullo ZX SPECTRUM negli
anni 80' ? Anch'io ne possedevo uno e mi divertivo molto a programmare con
quel giocattolone evoluto ( a quell'epoca andavo all'universita'; bei
tempi!!!).


 Merano

 creare un programma che lo faccia
Forse nella versione che hai visto non c'era', ma dalla versione 4 in poi
c'e' l'explorer del sorgente che visualizza tutti gli elementi (classi, metodi,
variabili, ecc.) in forma di albero, inoltre c'e' una funzionalita' simile
ad Intellisense di MS che permette di completare il testo e di navigare
tutto il sorgente.
-- 


 modalità console (almeno per xHarbour, Harbour verrà aggiornato presto).
Che differenza c'e' tra xHarbour e Harbour?


 tempi!!!).
Io ho imparato a programmare sullo ZX81 prima e sullo Spectrum poi.


 Che differenza c'e' tra xHarbour e Harbour?
Sono due progetti paralleli che cercano di esprimere due modi di
sviluppare diversi, più aggressivo e dinamico il primo, più pacato e
ragionato il secondo. In pratica penso che, alla fine, convergeranno.


 in VO 1.0?
Sě. All´inizio condividevo persino le librerie tra VO1 e VO2.
Saluti
Wolfgang
Merano

 problema con quest'ottica risolverebbe tanti problemi.
sicuramente funziona. Però devo aggiungere una cosa: per lo sviluppo a gruppi 
non metterei codice in sviluppo in rete: uno sta modificando e provando e 
un´altro si tira dentro codice incompleto...
Il mio approcio sarebbe: usare file esterni, ma locali. Regolarmente si 
possono aggiornare poi i file locali dalla rete - e ovviamente chi esegue 
modifiche sulle librerie deve stare molto attento a copiare in rete solo file 
testati e finiti.
Saluti
Wolfgang
Merano

 quasi totalita' dei sistemi di sviluppo lo fa.
a parte che sono convinto che una bella parte della produttività con VO sia 
dato proprio dalla IDE con il collegamento con il repository: esiste uno 
strumento che avevano usato gli sviluppatori originali che permette esattamente 
quello che tu vuoi. È uno strumento da riga di comandi che esegue il build di 
librerie, DLL e EXE.... Se non mi sbaglio, dovrebbe essere compreso anche nella 
2.6, se no basta chiedere a Brian.
Saluti
Wolfgang
Merano

preciso? Perche' cosi' non riesco ad inquadrare il problema.
AEF ti dice niente ?  Comunque quello che da piu' fastidio e'
l'impossibilita' di intervenire dall'esterno direttamente sui
sorgenti.  Con altri ambienti questi e' possibile e immediato, con VO
devi per forza entrare nell'ambiente "esportare" o salvare pezzo per
pezzo con copia/incolla.
ciao, acc.   
a...@libero.it

Provalo ora e ricrediti. :-)
Ehi credi che non abbia nulla da fare ?  Se perdo tempo con queste
amenita', chi fronteggera' le truppe di Stroggos ?  Poi lo spieghi tu
al comandante James che il suo marine preferito si trastulla con i
linguaggi di programmazione mentre c'e' una guerra in atto ?  ;-)
ciao, acc.   
a...@libero.it

 ragionato il secondo. In pratica penso che, alla fine, convergeranno.
Hanno litigato?
Certo che quel Linares ha un caratterino... ha litigato con il
distributore americano di fivewin, ha litigato con Alaska-Software ed
ora se ho ben capito porta avanti un progetto che si stacca da harbour.
Che ne dici?
Comunque ho letto velocemente alcune delle cose che discostano xHarbour
da Harbour/Clipper e le approvo. Non vedo niente di male a far evolvere
il linguaggio.


 testati e finiti.
Non sarebbe meglio utilizzare il CVS che esiste proprio per questo?


 linguaggi di programmazione mentre c'e' una guerra in atto ?  ;-)
Uhm... di che si tratta? Mi ricorda qualcosa ma non riesco a
focalizzare...


 il linguaggio.
No, infatti. Faccio un esempio in cui si vede la differenza di
approccio: diverso tempo fa sottoposi un codice che utilizzava funzioni
di Clipper non documentate e che Harbour non riusciva a compilare.
Ebbene, dopo pochissimo tempo Ron mi scrisse che le aveva implementate
anche su xHarbour che quindi riuscì a compilare perfettamente quel
programmino. Harbour ancora oggi non lo compila.


 direttamente nell'IDE).
Le "API di Delphi" ? e che sono ? si mangiano.
Lo credo che ti hanno deluso, hanno mentito ;) Si puo' fare benissimo.
--------------------------------
Inviato via 
http://usenet.libero.it

focalizzare...
Ettecredo stai sempre li' a pistolare su quello scatolozzo nero
antidiluviano, con ZPU a 7.5 bit,  aggiornati che e' ora !!!  ;-)
ciao, acc.   
a...@libero.it

 EMG


 EMG


 tutto il sorgente.
Ok. grazie dell'informazione. In effetti mi sembra di ricordare che la
versione che vidi io era la 3.0. Immaginavo comunque che nelle versioni
seguenti la Borland avrebbe colmato la lacuna.
Ad ogni modo, dopo aver preso in esame almeno una dozzina di tools di
sviluppo, nel 1999 presi la decisione di migrare dal CLIPPER 5.2 al VO 2.5.
Ciao,
      Fabrizio Malaguti


 pezzo con copia/incolla.
No. basta associare il tuo prg e modificarlo anche con l'editor Microsoft
(DOS), poi rientri in VO e compili.
All'inizio importavo così i miei sorgenti CLIPPER per tradurli in VO. Solo
che una volta tradotti toglievo l'associazione al file esterno e mi rimaneva
solo l'AEF. Per quanto riguarda l'AEF! nessuno è perfetto è solo il modo con
cui vengono memorizzati i sorgenti nel repository.


 Inviato via 
http://usenet.libero.it

 antidiluviano, con ZPU a 7.5 bit,  aggiornati che e' ora !!!  ;-)
No, a parte gli scherzi: mi dici di cosa si trattava? Sono curioso...


 Scusa, non conosco il CVS (o almeno la sigla non mi dice niente). Sarebbe?
Control Version System. E' uno strumento che consente di fare
aggiornamenti in rete ad un progetto a cui lavorano molti programmatori
e di poter tornare indietro a qualunque step dello sviluppo. Molto
utilizzato nei progetti open-source.
EMG
--


 basso livello come col C - puntatori, strutture dati, ecc).
Assolutamente no! Il Pascal è filosoficamente agli antipodi rispetto al
C. Il Pascal cerca amorevolmente di proteggere il programmatore
avvolgendolo con una rigida struttura di controllo laddove il C gli
dice: fai quello che ti pare, se ti fai male sono affari tuoi. :-)


passare alla gestione dei puntatori ed il gioco è fatto.
Non sono dello stesso parere, specie con riferimento a C++, che
secondo me e' tutta un'altra cosa.  Anche rispetto al C le
similitudini sono a livello estetico (lo stesso vale per Clipper),
internamente sono profondamente diversi.
ciao, acc.   
a...@libero.it

dice: fai quello che ti pare, se ti fai male sono affari tuoi. :-)
Il Pascal ti consente di ricorrere a tali porcherie che lo stesso
D.M.Ritchie rimarrebbe sconvolto, o forse entusiasta ?!? ;-)
Che poi ci sia qualche integralista che nega anche l'evidenza, e' un
altro paio di maniche.
ciao, acc.   
a...@libero.it

No, a parte gli scherzi: mi dici di cosa si trattava? Sono curioso...
Stroggos e' il pianeta di Quake.
ciao, acc.   
a...@libero.it

 universita' (facolta' di archeologia ?).
??? La programmazione strutturata è alla base dell'informatica moderna.
Forse pensi erroneamente che la OOP l'abbia cancellata ma questo non è
affatto vero. La struttura portante su cui si basa la OOP è proprio la
solita vecchia PS. Strutture solide si costruiscono solo su fondamenta
altrettanto solide.


 Stroggos e' il pianeta di Quake.
Azz!!! Mi pareva! I miei giochi preferiti...


 altro paio di maniche.
Che c'entra l'integralismo? Parliamo senza dubbio di due linguaggi
diversi che, sfortunatamente, hanno lo stesso nome. Ma il Pascal di cui
parlo io non ha certamente le caratteristiche da te citate.


parlo io non ha certamente le caratteristiche da te citate.
Il Pascal veniva spesso citato come esempio di linguaggio strutturato
e dotato di regole molto rigide.  In realta' questo linguaggio
consente molte piu' liberta' di quello che qualcuno vorrebbe far
credere, e forse le caratteristiche di cui sopra potevano andare bene
se confrontate con i linguaggi presenti all'epoca in cui il Pascal
cominciava a diffondersi (Basic in primis).
Se dovessi tradurre un listato in C in un altro linguaggio a mia
scelta, sceglierei sicuramente il Pascal, che e' quello che mi
consente la conversione piu' rapida possibile.
ciao, acc.   
a...@libero.it

altrettanto solide.
Forse mi sono espresso male, non volevo dire che la programmazione
strutturata e' superata, anzi il contrario.  Volevo dire che mentre
una volta era poco diffusa quindi era vista come qualcosa di
inoovativo, oggi e' praticamente una scelta obbligata, tutti i
linguaggi nuovi si basano su questo concetto.  Addirittura ci sono
linguaggi nati come "non strutturati" che con le evoluzioni successive
hanno ereditato questa caratteristica (es: VisualBasic).
ciao, acc.   
a...@libero.it

 consente la conversione piu' rapida possibile.
Continua ad essere più che evidente, dal tuo discorso, che ti riferisci
a particolari implementazioni ed estensioni attuali del Pascal. Ti
assicuro che il Pascal di Wirth era fondato sulle regole rigide alle
quali accennavi. Già il TurboPascal era un mezzo stravolgimento.
Intendiamoci, non sto affatto dicendo che il Pascal di Wirth sia meglio
o peggio dei "Pascal" attuali, solo che il primo era un linguaggio
accademico atto a dimostrare sul campo la coerenza delle teorie
informatiche allora in auge (e quindi ad insegnarle) mentre i secondi
sono implementazioni pragmatiche fatte per essere utilizzate nel mondo
del lavoro.


 sostanza e' la stessa.
Be', allora quasi tutti i linguaggi sono uguali, dato che, alla fine,
tutti diventano codice macchina. Invece lo strato di astrazione, più o
meno spesso, che si interpone tra il livello del programmatore e il
livello della macchina è della massima importanza e non è riducibile a
differenze solo sintattiche, solo semantiche o solo filosofiche ma a
tutte e tre insieme (e forse ad altri aspetti che ora sto tralasciando).
Lo strato interposto dal C è quindi abbastanza sottile rispetto a quello
del Pascal. Il C++ cerca invece di offrire più facce mescolando strati
di diversi spessori (è forse il linguaggio più pragmatico che esista).


 invece che in Pascal, non trovi?
Il primo Mac era scritto in pascal.
I sistemi operativi sono i programmi piu' critici e richiedono il 100%
del controllo sull'hardware almeno nella loro parte piu' centrale.
La caratteristica del C e' il controllo completo su tutto, basta vedere
la gestione della memoria e delle stringhe, questa esasperazione si
puo' ottenere anche con Delphi ma per i programmi normali non e'
richiesta, ed alle volte si preferisce pagare un po' sul lato delle
prestazioni per una maggiore gestibilita'.
-- 


 avrebbe fatto la fine di altri linguaggi caduti in disuso.
Sě, probabilmente sarebbe stato cosě. Comunque io l'ho specificato fin
dall'inizio della discussione: l'unico Pascal che conosco č quello di
Wirth e la mia analisi riguardava solo quello. Se oggi Pascal significa
un'altra cosa (bisognerebbe perň vedere se Wirth č d'accordo...) io non
ne so niente.
EMG


 internamente sono profondamente diversi.
Come ho detto prima, Al Vo mancano i namespace,i template e l'ereditarieta'
multipla e la ricchezza implementativa dell'OOP del C++. Ma praticamente in
un modo o nell'altro si riesce ad emulare tutto. Quello che sentivo la
mancanza nel Clipper, oltre all'OOP, ed invecie è presente in VO è la
gestione dei puntatori. Con tale gestione per fare alcune cose non è piu'
necessario passare al C.


 EMG


 EMG


del lavoro.
Mi riferisco alle implementazioni diffuse del linguaggio, trovo di
scarso interesse parlare di vapor-ware o comunque di software che non
ha avuto diffusione.  Comunque le similitudini di cui parlo si
applicano anche alla versione del prof. Niklaus Wirth, sempreche'
questa sia dotata di:
- funzioni
- tipi di dati simili a quelli del C
- variabili locali e globali
- strutture
- utilizzo dello stack
- utilizzo di librerie
ciao, acc.   
a...@libero.it

di diversi spessori (è forse il linguaggio più pragmatico che esista).
Forse e' bene precisare che io bado di piu' all'implementazione
pratica, cioe' all'output del compilatore, che non alla semantica del
linguaggio.
ciao, acc.   
a...@libero.it

un modo o nell'altro si riesce ad emulare tutto.
La caratteristica del C e' l'efficienza, impossibile emularla con VO.
ciao, acc.   
a...@libero.it

 anche molto simili di sintassi).
Mi domando cosa mai ci sarà di più che non quello che facciamo già ora
con tutti i linguaggi e cioè utilizzare DLL o componenti OLE. Se è solo
questo, dubito molto che la tua affermazione possa corrispondere a
verità dato che, almeno fino a questo momento, questa grossa
uniformazione non c'è stata e ogni linguaggio ha mantenuto la sua bella
individualità. E speriamo che resti sempre così altrimenti avremmo solo
un gran numero di brutte copie del già brutto Visual Basic.
EMG
--


 dati = programmi"?
Sě, certo, Niklaus Wirth, l'ideatore del Pascal.
EMG
--


 - utilizzo di librerie
E quali sarebbero le caratteristiche distintive del C? Dove le hai
lasciate? Il cast, l'assenza di un garbage collector, l'assenza del
passaggio di parametri per riferimento, il concetto di decadimento array
-> puntatore, etc, etc...


 linguaggio.
Quindi al codice macchina generato? Direi che non è questo che si
intende per studio di un linguaggio di programmazione. Comunque tutto il
discorso, se osservato dal punto di vista che hai appena esposto, cambia
chiaramente senso e allora ti posso anche dare ragione. Io invece bado
all'espressività di un linguaggio e questa si estrinseca attraverso le
sue regole sintattico/semantiche ed al modello di astrazione della
macchina che offre al programmatore. Punti di vista diversi, forse più
"elettronico" il tuo e più puramente informatico il mio (pur io stesso
provenendo dall'elettronica :-) ).


 capitolo chiuso.
<BUGIARD MODE ON>
Fai bene ;)
<BUGIARD MODE OFF>
--------------------------------
Inviato via 
http://usenet.libero.it

 > invece che in Pascal, non trovi?
Che tu ci creda o no, le differenze tra Pascal e C non sono cosi' ampie da
essere determinanti per questo ambito preciso (i sistemi operativi). Tutto
dipende dall'ambiente in cui compili. Per esempio, ci sono sistemi operativi
scritti in Pascal, i cui sorgenti sono pubblicamente disponibili. Io stesso
ho scritto, in Turbo Pascal, dei TSR (programmi residenti), attivabili con
sequenze precise di tasti, in ambienti critici, in quanto a stabilita' e
rientranza, come il DOS. Il linguaggio con cui questi programmi venivano
scritti era irrilevante, cio' che piu' contava era avere un ambiente che ti
consentisse di interfacciare codice assembly facilmente, sostituire vettori
di interrupt, ecc... ecc...


provenendo dall'elettronica :-) ).
Che vuoi farci, sono un materialista, non un poeta. ;-)
ciao, acc.   
a...@libero.it

 di interrupt, ecc... ecc...
Già, ma il Pascal non sa niente di codice assembly e vettori di
interrupt. Come ho già detto, si sta parlando di estensioni. E con le
estensioni posso far fare qualsiasi cosa a qualsiasi linguaggio.


-> puntatore, etc, etc...
Non so se in Pascal sia possibile passare parametri per indirizzo,
(anche se sono piu' propenso a credere di si), di garbage collector
non se ne parla, del resto il meccanismo di allocazione e' simile a
quello del C.
ciao, acc.   
a...@libero.it

 interrupt.
Esatto e neanche il C.


 Non so se in Pascal sia possibile passare parametri per indirizzo,
Si puo' (senza assurdi passaggi di puntatori ;).
--------------------------------
Inviato via 
http://usenet.libero.it

 Che vuoi farci, sono un materialista, non un poeta. ;-)
Allora come mai ti occupi di una scienza così impalpabile come
l'informatica? :-)
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 EMG


 <BUGIARD MODE OFF>
Nel senso che faccio bene oppure no?
ciao,
     Fabrizio Malaguti


 Sě, certo, Niklaus Wirth, l'ideatore del Pascal.
Ok mi sembrava infatti fosse l'autore di quel libro.
Ottimo libro. Fatto molto bene da cui ho ricavato tanti algoritmi in VO.
Non sapevo comunque che fosse lui l'ideatore del Pascal. Anche se potevo
intuirlo dal fatto che tutti gli algoritmi contenuti nel testo erano scritti
in quel linguaggio.
ciao,


 quello del C.
Parli dell'allocazione dinamica, immagino. Comunque le altre
caratteristiche che ho citato (e tante altre che non ho citato) non
credo possano essere trovate in altri linguaggi.
EMG
--


 Esatto e neanche il C.
Non è del tutto esatto. Il C ha la keyword asm che offre comunque un
supporto alle istruzioni assembly (più che altro un posto dove
metterle). Inoltre è possibile utilizzare una struttura dati
preesistente semplicemente assegnandone l'indirizzo ad un puntatore
(brutto) oppure, solo in C++, utilizzando l'istruzione new placement
(molto meglio).


estensioni posso far fare qualsiasi cosa a qualsiasi linguaggio.
Anche in C non esistono i vettori di interrupt, e l'assembler
incorporato e' un'estensione (presente anche alcuni compilatori
Pascal).  L'interfacciamento Pascal <-> Assember e' molto semplice,
esattamente come nel caso del C.
ciao, acc.   
a...@libero.it

 mestiere e vado a coltivare cipolle (almeno ci sono piu' soddisfazioni).
O forse dovremmo pensare seriamente a spingere di più sistemi
alternativi come Linux? Possibile che non ci sia modo di combattere
l'arroganza della MS? Dobbiamo capire bene che tutto quello che la MS
pensa di imporre fa comodo solo a lei. Non certo a noi come
programmatori (ai quali toccherà sputare sangue per adeguare le nostre
conoscenze e i nostri software) e non certo ai clienti che considerano
il computer esclusivamente uno strumento per risolvere i loro problemi
di lavoro.
EMG
--


(molto meglio).
La keyword asm e' un'estensione e non fa parte del linguaggio
originale.  Allo stesso modo tali estensioni sono presenti in diversi
compilatori Pascal, da questo punto di vista non c'e' differenza.
Una caratteristica del C invece, e' che fin dalle prime versioni, il
compilatore forniva come output un sorgente assembler da passare
successivamente all'assemblatore.  Questa caratteristica e' rimasta
nella quasi totalita' delle implementazioni, e cio' ha fatto si che
molti programmatori la utilizzassero per sviluppare programmi in
assembler.  A questa caratteristica si deve anche il fatto che spesso
i programmatori C conoscono piuttosto bene i meccanismi interni del
linguaggio e il modo in cui ottimizzare il codice prodotto.  Forse al
giorno d'oggi tutto cio' puo' sembrare meno importante di quanto lo
fosse ai tempi in cui il C cominciava a diffondersi.
ciao, acc.   
a...@libero.it

credo possano essere trovate in altri linguaggi.
Mi riferisco al modo in cui vengono allocati sia i dati che le
procedure stesse.
Che il Pascal non abbia tutte le caratteristiche del C e' ovvio, ma
questo non toglie che si somigliano.  Non ho mica detto che sono
uguali.
ciao, acc.   
a...@libero.it

l'informatica? :-)
Sempre meglio che andare a lavorare !  ;-P
ciao, acc.   
a...@libero.it

 originale.
Sei sicuro? A me risulta che faccia parte dello standard C.


 procedure stesse.
A me risulta che, ad esempio, il metodo di allocazione dei parametri sia
diverso tra C e Pascal. Comunque non č di questo che parlavo. Tu cerchi
di portare il discorso ad un livello troppo basso riguardante i dettagli
implementativi. Io invece mi riferivo alla filosofia del linguaggio e
alla sua sintassi/semantica. Sono questi gli aspetti che determinano
come si debba programmare in un certo linguaggio di programmazione, non
i dettagli implementativi che, alla fine, saranno tutti molto simili.


 Sempre meglio che andare a lavorare !  ;-P
:-))) A parte gli scherzi, non mi sembra affatto che il mestiere del
programmatore sia leggero. E', invece, molto faticoso...


 EMG


Sei sicuro? A me risulta che faccia parte dello standard C.
Puo' darsi che sia un'estensione ANSI/ISO/USL/INPS, fa un po' tu. Di
certo non esiste nel K&R.
ciao, acc.   
a...@libero.it

i dettagli implementativi che, alla fine, saranno tutti molto simili.
Io sostengo esattamente l'opposto, il mio modo di programmare e'
fortemente influenzato dalla consapevolezza di quello che sara' il
codice prodotto.  Qualche volta mi lascio trasportare anche dalle
regole del linguaggio, ma solo per pigrizia.
ciao, acc.   
a...@libero.it

 certo non esiste nel K&R.
No, scusa, almeno su questo mi devi dare ragione: esiste *un solo*
linguaggio C ed è quello ratificato dall'ISO. Il K&R è da moltissimi
anni solo una buffa curiosità storica.


 regole del linguaggio, ma solo per pigrizia.
Francamente non credo che questo tipo di approccio possa portare molto
lontano, specialmente parlando di progetti di una certa entità. O
meglio, ci saranno parti (normalmente molto piccole) del progetto che
necessiteranno di un'analisi di basso livello come quella da te proposta
ma per la restante parte (la stragrande maggioranza del codice) scendere
nei dettagli implementativi risulterebbe in un disastro e certamente nel
fallimento del progetto.


fallimento del progetto.
Se cosi' fosse significherebbe soltanto che il programmatore e' un
incapace.  Secondo me il problema e' un altro, e cioe' che spesso il
tutto si traduce in eccessiva perdita di tempo.  In molti casi e'
preferibile utilizzare prodotti di terze parti che alla fine costano
meno e sono gia' pronti.
Pero' devi anche considerare che se nessuno si prendesse la briga di
addentrarsi cosi' "profondamente" nel sistema, nessuno svilupperebbe
librerie aggiuntive, e le tue FiveWin non esisterebbero ;-).
ciao, acc.   
a...@libero.it

anni solo una buffa curiosità storica.
Io ho una considerazione maggiore di Kernigham & Ritchie che il C
l'hanno realizzato, e ne conoscono tutti gli aspetti e le motivazioni
che stanno dietro.
Do' invece poco peso alle standardizzazioni proposte dai vari
comitati, forse perche' sono realista.  Di fatto il C e' stato
utilizzato in svariate "salse" e per molto tempo, prima che certi
standard venissero ratificati.  Troppo tardi, i giochi erano gia'
stati fatti !
Le varie implementazioni che troviamo sul mercato, possono tenere in
considerazione di questi standard, ma di fatto avviene spesso il
contrario, e cioe' le innovazioni vengono introdotte dal produttore e
successivamente approvate dal comitato.  Io credo di essere in grado
di fare le mie valutazioni, e non vedo perche' dovrei seguire quelle
di un "comitato" che neppure conosco.
ciao, acc.   
a...@libero.it

 librerie aggiuntive, e le tue FiveWin non esisterebbero ;-).
In quel caso lo scopo del progetto era proprio quello di intervenire
sulle parti di basso livello del Clipper. Sarebbe stato ben diverso se
le Fivewin avessero dovuto anche offrire magazzino e fatturazione. A
parte l'assurdità della cosa (anche se la MS con .NET cerca di farci
credere che non lo sia), ci sarebbe stata certamente una suddivisione
del progetto in programmatori di basso e di alto livello (inteso in
senso di astrazione, non di skill).


 di un "comitato" che neppure conosco.
Questo non mi sembra affatto un atteggiamento di tipo "realista", senza
contare che non cogli i vantaggi che una standardizzazione può offrire.


contare che non cogli i vantaggi che una standardizzazione può offrire.
Se un compilatore mi offre opportunita' che ritengo valide io le uso
indipendentemente dal fatto che siano approvate o meno dall'ISO, se
non fosse cosi' non avrei mai iniziato a programmare in Clipper,
probabilmente avrei scelto il Cobol.
ciao, acc.   
a...@libero.it

 probabilmente avrei scelto il Cobol.
Sono d'accordo che la scelta del linguaggio da utilizzare non si basa
normalmente sulla sua standardizzazione (anche se forse dovrebbe) ma,
una volta fatta la scelta, non vedo perché non coglierne appieno i
vantaggi, anche quelli derivanti dal fatto che esiste uno standard
internazionale.


capisco come fai a non essere d'accordo su questo. E' talmente evidente.
[cut]
Il punto e' che spesso (come nel mio caso) le estensioni sono
utilizzate prima che vengano approvate dall'ISO, in pratica io le
utilizzo indipendentemente dal fatto che siano approvate o meno.
Poi se sono approvate, tanto meglio, sono d'accordo con te che la
definizione di uno standard e' utile, ma non e' certo questo che mi
spinge ad autilizzarle.
ciao, acc.   
a...@libero.it

 spinge ad autilizzarle.
Credo ci sia un'incomprensione di fondo: non c'è alcun problema ad
utilizzare le estensioni al linguaggio (a parte quello della
portabilità), anzi esse sono espressamente previste dallo standard.
Previste nel senso che è perfettamente lecito, per un produttore di
compilatori, estendere in qualsiasi modo il linguaggio. Non si perde la
compliance se si garantisce che un codice standard venga compilato ed
eseguito correttamente. Diverso è se un compilatore *modifica* il
linguaggio in modo tale che codice standard non venga più compilato ed
eseguito come ci si aspetta.
Spero di aver chiarito bene questo importante punto.


eseguito come ci si aspetta.
In effetti, avevo creduto che tu fossi contrario alle estensioni "non
approvate", ora e' tutto chiaro, direi che il discorso e' chiuso.
Finalmente possiamo parlare di Visual Basic... ;-P
ciao, acc.   
a...@libero.it

 Finalmente possiamo parlare di Visual Basic... ;-P
Aspetta che ho appena avuto un disturbo di stomaco... :-)))
