e.Biscom ora è FastWeb

Ufficiale


Milano – Nelle scorse ore è stata finalizzata la fusione per incorporzione di FastWeb nella holding e.Biscom, che da oggi cambia ragione sociale e diventa FastWeb.

La società in una nota ha comunicato non solo l’approvazione della nuova denominazione dell’azienda ma anche la nomina di Stefano Parisi a consigliere. Lo stesso Parisi è poi stato nominato amministratore delegato della nuova FastWeb.

Nelle prossime ore sarà anche modificato il nome del titolo quotato in Borsa, al Nuovo Mercato.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • caffenero scrive:
    Re: Forza pitone!
    - Scritto da: Anonimo
    Purtroppo lo è.Continuo a non capire.Il concetto eppure mi pare semplice: se uso "hard tabs" (come dovrei) rimangono sempre e cmq hard tabs, punto.L'interprete stabilisce l'indentazione solo ed esclusivamente in base ai tab presenti. A quanti spazi siano espansi in fase di visualizzazione da parte dell'editor è assolutamente irrilevante, a patto che in fase di ri-salvataggio non si introducano magheggi assurdi tipo riconvertirli in spazi.E difatti non ho MAI avuto problemi simili.A meno che non si programmi con word, allora capisco. ;)
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Alex¸tg

    fatto che il mio editor abbia i tab
    settati

    a 8 spazi e il tuo a due (tre,
    quattro...)

    NON è assolutamente rilevante....Purtroppo lo è.
    Uhm... il fatto e` che alcuni editor
    convertono internamente i tab in spazi, e
    poi in sede di salvataggio cercano di
    riapprossimare gli spazi che eventualmente
    potresti aver cancellato o aggiunto, con uno
    o piu` codici di tabulazione. Qualsiasi editor degno di questo nome consente di usare "hard tabs" (cioè il nudo caratterino ASCII, che produce tabulazioni spaziate a larghezza fissa), "soft tabs" (mere sequenze di spazi), ed anche "smart tabs" combinando tabulazioni e spazi tramite un "righello" a posizioni variabili, simile a quello dei word processor. La presenza di questo inutile ordigno, prono a produrre effetti esilaranti non appena si cambia la dimensione delle tabulazioni, è cmq legata ad una esigenza assolutamente sentita quando ho iniziato a programmare: ridurre l'ingombro su disco dei sorgenti, comprimendo gli spazi con l'uso di un singolo carattere. L'uso di TAB embedded nel testo era comunque deprecato già negli anni 80 nei sorgenti COBOL, nei quali l'indentazione HA un senso e non può essere soggetta alle libere interpretazioni dell'editor - in visualizzazione come in fase di salvataggio.QEdit, Aurora, TSE e quant'altri consentono comunque di spazzare via i caratteri TAB in modo definitivo, convertendoli una tantum in spazi (ciò che peraltro si può fare anche con un paio di righe in AWK +SED o Perl), come anche di riconvertire l'indentazione in combinazioni di TAB e spazi.www.literateprogramming.com/c++critique.pdf Beh, è una raccolta di argomentazioni molto in voga nell'advocacy di comunità come java e delphi/pascal. Una cosa meno usuale e più divertente è vedere quanti programmatori controllisti embedded e realtime usano regolarmente il C e odiano cordialmente il C++, per motivi un po' più articolati :D
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: caffenero
    ...nnno. Dunque, su questo discorso delle
    tab vedo che molti (me compreso, agli inizi)
    non hanno le idee molto chiare.
    Il tab è un char speciale, che viene
    salvato all'interno del file di testo... ilLo so, e` il codice ASCII #9.Gran parte della parte standard dell'ASCII la so a memoria :D
    fatto che il mio editor abbia i tab settati
    a 8 spazi e il tuo a due (tre, quattro...)
    NON è assolutamente rilevante....Uhm... il fatto e` che alcuni editor convertono internamente i tab in spazi, e poi in sede di salvataggio cercano di riapprossimare gli spazi che eventualmente potresti aver cancellato o aggiunto, con uno o piu` codici di tabulazione. Comunque, e` vero che un problema dovrebbe essere risolto, quello di tabulazioni e spazi in combinazioni multiple, tipo tab+tab+tab+spc+spc, per allineare blocchi fatti di piu` punti di tabulazione. Se il Python se la prende per una cosa del genere, probabilmente non ha senso farla e quindi il listato non e` passibile di errori di interpretazione in questo senso (in combinazioni del genere, come puoi immaginare, la dimensione della lunghezza in spazi del tab nell'editor di turno combina solo disastri).[...]
    Usare il tab garantisce sempre e cmq
    coerenza nella struttura, permettendo allo
    stesso tempo di rispettare i gusti "visivi"
    del programmer di turno ;)In Python, ora che mi ci fai pensare, probabilmente si`, perche` l'indentazione ha un significato e non e` influenzata da questioni di stile, ma io pensavo ad altri ambiti, dove a volte e` necessario, per rispettare uno stile e non sprecare troppo spazio, andare a scrivere "in mezzo" ai tabs. Generalmente, pero`, per quel che mi riguarda uso combinazioni di spazi e tab, con dimensione fissa del tab a 8 spazi. ConText, il mio editor, gestisce bene la conversione di gruppi di 8 spazi in tab.
    Che begli accenti... ;) Anche tu tastiera
    USA, eh? Anche io, ma con i dead keys... :DEh, si`. Non mi ci trovo proprio con l'italiana... son dolori quando devo scrivere qualcosa in un ufficio da un cliente. D'altronde ai tempi in cui comprai l'Amiga500, uno dei primi a Kickstart+Workbench 1.2, non esisteva proprio la versione con tastiera italiana... e l'abitudine ha fatto il resto. E poi odio i caratteri che escono dall'intervallo 0-126, e anche nella parte 0-31 mi piacciono solo quelli standard (8 backspace, 9 tab, 10 line feed, 11 vertical tab, 13 carriage return, 27 escape).
    Peccato, mi avrebbe fatto piacere farlo
    leggere a un amico talebano del C++Ero partito da una ricerca su Google con "I hate C++"... hmm, avevo trovato... "my C++ page of hate", e da li` avevo seguito un link... 'spetta...Eccola! Eccola! Trovato...http://www.literateprogramming.com/c++critique.pdf
    Beh, noi maledetti nerd abbiamo di questi
    vizi ti capisco. A proposito, vedo dal tuo
    profilo che sei un programmatore pisano del
    '75 di nome Alessandro.
    Ma pensa le coincidenze... anche io :DEeeh?Ti chiami Alessandro, del '75, sei programmatore e pisano?E che e`... sei il mio alter-ego? Sorprendente...
  • caffenero scrive:
    Re: apropos di py e nuovi paradigmi...
    Ecco, Zope è una cosa che prima o poi devo approfondire. Speigaci meglio cosa intendi col tuo post, in modo da darci un "appetizer" :D
  • caffenero scrive:
    Re: Forza pitone!
    - Scritto da: Alex¸tg
    E` vero, e l'idea e` tutto sommato buona,
    anche se poi mi vengono in mente un bel po'
    di ambiti in cui le tab sono addirittura
    proibite perche` non si sa mai come il text
    editor di turno le interpretera`... ma e` un
    problema marginale....nnno. Dunque, su questo discorso delle tab vedo che molti (me compreso, agli inizi) non hanno le idee molto chiare.Il tab è un char speciale, che viene salvato all'interno del file di testo... il fatto che il mio editor abbia i tab settati a 8 spazi e il tuo a due (tre, quattro...) NON è assolutamente rilevante.... significa solo che il mio listato sarà più largo, il tuo più stretto ;) Proprio per questo NON si dovrebbero usare gli spazi al posto dei tab... Mettiamo che '$' mi rappresenti la tab:def pippo() if x == 10: print 'a' else print 'b'sarà salvato come:def pippo()$if x==10$$print 'a'$else$$print'b'Usare il tab garantisce sempre e cmq coerenza nella struttura, permettendo allo stesso tempo di rispettare i gusti "visivi" del programmer di turno ;)
    Comunque la mia considerazione verteva sul
    fatto che piu` funzionalita` si aggiungono a
    un linguaggio, piu` possibilita` ci sono per
    il programmatore e piu` il linguaggio
    diventa "potente", pero` allo stesso tempo
    il programmatore deve apprendere la gestione
    delle varie funzionalita`, e quindi diventa
    anche piu` complicato. Non mi ricordo piu`
    pero` com'e` che mi era venuto in mente di
    menzionare 'sta cosa...Che begli accenti... ;) Anche tu tastiera USA, eh? Anche io, ma con i dead keys... :D
    Eehh... e poi scrivi IMVHO per farti
    perdonare? :D
    Qui si rischia il flame, ma in effetti,
    straight from the heart, e` quel che penso
    anch'io tutte le volte che vengo obbligato a
    usare il C++. Eppure, devo ammettere, un
    tempo mi piaceva, ma poi appunto col tempo,
    mi sono stufato del modo in cui mi
    costringeva a lavorare... o forse, piu`
    semplicemente, ho voglia di cambiamento e lo
    "stile C" m'e` un po' venuto a noia.Stessa cosa per me.
    Concordo appieno, e credo che la questione
    delle classi virtuali "appiccicate con la
    colla" a una sintassi ormai vecchia e
    rattoppata, siano in molti a odiarla o
    quantomeno a guardarla storta. Mesi fa
    trovai un illuminante PDF con una relazione
    sulle incongruenze del C++, ma ho perso il
    link...Peccato, mi avrebbe fatto piacere farlo leggere a un amico talebano del C++
    Avessi tempo approfondirei col Python, se
    non altro per il gusto di sperimentare il
    maggior numero di linguaggi possibili, ma ho
    paura di non averne... e di rimanerci
    attaccato (addicted).Beh, noi maledetti nerd abbiamo di questi vizi ti capisco. A proposito, vedo dal tuo profilo che sei un programmatore pisano del '75 di nome Alessandro.Ma pensa le coincidenze... anche io :D
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Alex¸tg(...)
    E` vero, e l'idea e` tutto sommato buona,
    anche se poi mi vengono in mente un bel po'
    di ambiti in cui le tab sono addirittura
    proibite perche` non si sa mai come il text
    editor di turno le interpretera`... ma e` un
    problema marginale.E alla luce di questo e' consigliato di usare spazi anziche' tab. '' Giving indentation semantic meaning is a stroke of genius.'' -- Joel Spolskyhttp://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=3721
    Avessi tempo approfondirei col Python, se
    non altro per il gusto di sperimentare il
    maggior numero di linguaggi possibili, ma ho
    paura di non averne... e di rimanerci
    attaccato (addicted).questo l'ho letto ora, e' divertentissimo:"Python Is Not Java"http://dirtsimple.org/2004/12/python-is-not-java.html''...The CPython dictionary implementation uses one of the most highly-tuned hashtable implementations in the known universe. No code that you write yourself is going to work better, unless you're the genetically-enhanced love child of Guido, Tim Peters, and Raymond Hettinger.''(...)''...compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that.''--dee
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Anonimo[...]
    aspetto non rappresentativo delle
    caratteristiche del linguaggio che nasce per
    essere potente, flessibile e dinamico e
    queste sono caratteristiche che vanno spesso
    in conflitto con la facilita' d'uso e la
    leggibilita'. tuttavia e' possiblieSi, ma ripeto qui: non era una critica, ma una semplice considerazione. Se il linguaggio e` potente, quel che conta potrebbe essere la coerenza interna, una sintassi pultia e un'organizzazione razionale, ma non proprio la semplicita`. Approvo infatti il discorso del non cercare a tutti i costi la retrocompatibilita`, anche se solo finche` il linguaggio non e` perfezionato: poi, ci andrei coi piedi di piombo con le eventuali aggiunte.
    utilizzarlo con produttivita' anche da chi
    di concetti quali meta-meta classi,
    decorator e quant'altro non ne vuol sentir
    parlare, senza nulla togliere a chi invece
    e' interessato a una programmazione molto
    avanzata e alla sperimentazione di nuovi
    paradigmi.
    #aSenz'altro vero, ma tutto sommato questo dovrebbe essere vero anche per altri linguaggi, se non per tutti. In fin dei conti si puo` programmare in C con un compilatore C++...
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: caffenero
    Sta venendo fuori una gran bella
    discussione, complimenti ai partecipanti.Si', tanto che sono andato a recuperarla col timewarp.
    Sono sempre il thread starter, mi sono
    registrato così ci si capisce :DBenvenuto, caffe` nero.Ora me n'hai fatta venire voglia...
    Allora, sul discorso "indentazione" beh...
    un modo per rendere chiara la divisione in
    blocchi di un programma DEVE esserci, se non
    per il compilatore/interprete almeno per il
    poveraccio che (ri)leggerà il
    codice... trovo che l'indentazione sia di
    per sé il metodo più naturale
    per fare questo: se ci pensate, con
    l'approccio pitonico l'interprete utilizza
    lo stesso paradigma dell'essere umano. Le
    tab sono molto "visive", molto naturali,
    IMVHO.Bah, perche` essere cosi` umile...prendi esempio da me: IMPO, In My Proud Opinion :)E` vero, e l'idea e` tutto sommato buona, anche se poi mi vengono in mente un bel po' di ambiti in cui le tab sono addirittura proibite perche` non si sa mai come il text editor di turno le interpretera`... ma e` un problema marginale.Comunque la mia considerazione verteva sul fatto che piu` funzionalita` si aggiungono a un linguaggio, piu` possibilita` ci sono per il programmatore e piu` il linguaggio diventa "potente", pero` allo stesso tempo il programmatore deve apprendere la gestione delle varie funzionalita`, e quindi diventa anche piu` complicato. Non mi ricordo piu` pero` com'e` che mi era venuto in mente di menzionare 'sta cosa...
    Le potenzialità del py nell'ambito OO
    sono decisamente maggiori che quelle del
    C++, castrato da una sintassi ORRENDA e da
    una fondamentale mancanza di coerenza
    interna, il tutto in nome della
    stramaledetta compatibilità col C.Eehh... e poi scrivi IMVHO per farti perdonare? :DQui si rischia il flame, ma in effetti, straight from the heart, e` quel che penso anch'io tutte le volte che vengo obbligato a usare il C++. Eppure, devo ammettere, un tempo mi piaceva, ma poi appunto col tempo, mi sono stufato del modo in cui mi costringeva a lavorare... o forse, piu` semplicemente, ho voglia di cambiamento e lo "stile C" m'e` un po' venuto a noia.
    Ad esempio, il fatto che in C++ si possano
    mescolare classi virtuali e non dà
    adito a pastrocchi inenarrabili in casi
    appena complessi di ereditarietà...
    per cosa, poi? Per poter ottimizzare il
    codice evitando il late-binding di un
    metodo? E allora cosa lo uso a fare un
    linguaggio a oggetti?
    In Py (come in Java) l'ereditarietà
    è SEMPRE "virtual" e il metodo
    chiamato è SEMPRE quello della classe
    più derivata (ovvero quella
    più specifica, ovvero come DEVE
    essere se il programma è ben
    strutturato).Concordo appieno, e credo che la questione delle classi virtuali "appiccicate con la colla" a una sintassi ormai vecchia e rattoppata, siano in molti a odiarla o quantomeno a guardarla storta. Mesi fa trovai un illuminante PDF con una relazione sulle incongruenze del C++, ma ho perso il link...Avessi tempo approfondirei col Python, se non altro per il gusto di sperimentare il maggior numero di linguaggi possibili, ma ho paura di non averne... e di rimanerci attaccato (addicted).
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Anonimo
    nuovo? a me sembra qualcosa di vagamente
    "logico" alla PROLOG, per capirci: tu scrivi
    una serie di regole e poi lasci che il
    motore inferenziale del linguaggio trovi la
    soluzione partendo da dei fatti (nel tuo
    caso: "Is it raining" (yes/no))

    se poi stavi parlando solo della sintassi e'
    un'altro discorso.Stavo appunto parlando solo della sintassi, niente a che vedere con un approccio alla PROLOG. Per quanto riguarda l'impostazione di base, infatti, il mio ideale rimane strettamente procedurale: esegui da cima a fondo, in sequenza (salti, subroutines e altre ovvieta` a parte), ed esegui per filo e per segno quel che scrivo. Casomai, l'event-driven puo` essere implementato in un linguaggio procedurale.
    questo tipo di approccio logico va benissimo
    in certi contesti e per risolvere un certo
    tipo di problemi... ma e' disastroso in
    altri. python e' un linguaggio general
    purpose, non dimenticarlo.Sissi` infatti il mio discorso valeva solo come "wannabe" esempio di sintassi leggibile. Comunque, quello che ho fatto io nell'esempio voleva illustrare il concetto, e cosi` com'e` e` poco piu` che una piccola parte di un'idea. Poi, se qualsiasi cosa ho detto suona come una critica al Python, e` del tutto involontario. Non conoscendolo neanche a fondo, come faccio a criticarlo? Il riassunto era: "peccato, neanche qui hanno fatto qualcosa del genere", ma senza alcuna pretesa.
  • Anonimo scrive:
    Re: apropos di py e nuovi paradigmi...
    - Scritto da: Anonimo
    chi ha gia' dato un occhio a Zope3 ?sto leggendo lo zope3 book, scaricabile da qui:http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage/Zope3Book
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Alex¸tg(...)
    boh... ecco, non e` che voglia discutere
    quanto il concetto sia giusto o sbagliato,
    ma quanto meno mi sembrerebbe qualcosa di
    davvero nuovo. nuovo? a me sembra qualcosa di vagamente "logico" alla PROLOG, per capirci: tu scrivi una serie di regole e poi lasci che il motore inferenziale del linguaggio trovi la soluzione partendo da dei fatti (nel tuo caso: "Is it raining" (yes/no))se poi stavi parlando solo della sintassi e' un'altro discorso.questo tipo di approccio logico va benissimo in certi contesti e per risolvere un certo tipo di problemi... ma e' disastroso in altri. python e' un linguaggio general purpose, non dimenticarlo.poi ovviamente googlando un po' si arriva a "Pythologic -- Prolog syntax in Python ":http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303057ma questi sono crimini contro l'umanita' :) ciao.--dee
  • Anonimo scrive:
    apropos di py e nuovi paradigmi...
    chi ha gia' dato un occhio a Zope3 ?dopo anni e anni che se ne parla credo che stia nascendo finalmente una vera architettura a componenti e aldila' del linguaggio utilizzato (py) introduce veramente un modo nuovo di pensare, progettare e realizzare sw.se non lo avete ancora fatto vi consiglio vivamente di perderci un po' del vostro tempo
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Alex¸tg
    anywherebb.com/linoleum.html Molto interessante.Quando avrò un po' di tempo (ovvero presumibilmente mai, ma non pongo limiti al destino) gli darò un'approfondita occhiata.Tempo fa un mio amico progettò qualcosa di simile, ma mai portata a compimento. Il suo sistema però includeva la possibilità di introdurre dei "traduttori" da un linguaggio ad alto livello (C, ad esempio) al suo meta-assembly.In questo modo era possibile programmare sia direttamente in meta-assembly sia in linguaggi di livello più alto.Peccato che non fu mai portato a termine.Ho letto gli altri tuoi messaggi e mi trovo d'accordo con le tue opinioni sull'approccio OO. Penso che la nomea di "moda" sia una considerazione aggiuntiva ma che alla base l'OO sia semplicemente un "nuovo" paradigma da seguire. Sposta i problemi su altri piani rispetto alla programmazione strutturata/procedurale ma non li elimina affatto.Conosci REBOL? http://www.rebol.com/
  • caffenero scrive:
    Re: Forza pitone!
    Sta venendo fuori una gran bella discussione, complimenti ai partecipanti.Sono sempre il thread starter, mi sono registrato così ci si capisce :DAllora, sul discorso "indentazione" beh... un modo per rendere chiara la divisione in blocchi di un programma DEVE esserci, se non per il compilatore/interprete almeno per il poveraccio che (ri)leggerà il codice... trovo che l'indentazione sia di per sé il metodo più naturale per fare questo: se ci pensate, con l'approccio pitonico l'interprete utilizza lo stesso paradigma dell'essere umano. Le tab sono molto "visive", molto naturali, IMVHO.Le potenzialità del py nell'ambito OO sono decisamente maggiori che quelle del C++, castrato da una sintassi ORRENDA e da una fondamentale mancanza di coerenza interna, il tutto in nome della stramaledetta compatibilità col C.Ad esempio, il fatto che in C++ si possano mescolare classi virtuali e non dà adito a pastrocchi inenarrabili in casi appena complessi di ereditarietà... per cosa, poi? Per poter ottimizzare il codice evitando il late-binding di un metodo? E allora cosa lo uso a fare un linguaggio a oggetti?In Py (come in Java) l'ereditarietà è SEMPRE "virtual" e il metodo chiamato è SEMPRE quello della classe più derivata (ovvero quella più specifica, ovvero come DEVE essere se il programma è ben strutturato).Un'altra cosa che mi piace molto è la cosiddetta "introspection", ma qui si va davvero nel complesso.Per chi volesse approfondire con un libro scritto da dio e liberamente scaricabile, consiglio www.diveintopython.org.Tante banane, tutte aggratis.Occhio che non è roba per principianti, ma lì si vedono davvero i "pezzi" che si possono fare col serpentone.
  • Anonimo scrive:
    Re: Forza pitone!

    ASK Is it raining (yes/no)?
    IF yes THEN it's raining
    IF it's raining SAY Bring an umbrella.
    IF it's NOT raining SAY Have a nice sunny
    day!
    ENDmolto carino e interessante, ma non ha niente a che fare con la filosofia del python. il fatto che python definsca i blocchi in base all'indentazione e' un aspetto non rappresentativo delle caratteristiche del linguaggio che nasce per essere potente, flessibile e dinamico e queste sono caratteristiche che vanno spesso in conflitto con la facilita' d'uso e la leggibilita'. tuttavia e' possiblie utilizzarlo con produttivita' anche da chi di concetti quali meta-meta classi, decorator e quant'altro non ne vuol sentir parlare, senza nulla togliere a chi invece e' interessato a una programmazione molto avanzata e alla sperimentazione di nuovi paradigmi.#a
  • Anonimo scrive:
    Re: Forza pitone!
    Bel post.Non quoto e non rispondo ai punti perche` erano talmente obiettivi che non sapei cosa aggiungere o su cosa non concordare.Oddio, concludendo, c'e` un fatto: mi aspettavo di meglio da Python, per come me ne avevano, ogni tanto, parlato. Credevo fosse qualcosa di veramente umanamente leggibile, mentre ora che ne vedo alcuni esempi (avrei potuto farlo prima, ma ho poco tempo) non so cosa pensare. O meglio, una cosa mi viene in mente.E` un paradigma che ho sempre tenuto presente: un linguaggio non puo` essere semplice e potente allo stesso tempo. Il Python riduce, per esempio, la difficolta` nel leggere il codice eliminando le graffe dai blocchi strutturali, ma allo stesso tempo introduce l'indentazione obbligatoria. Un po' come l'idraulico disperato che tappa un buco per aprirne un altro: mi fa questa impressione.Io speravo che ci fossero concetti davvero innovativi.Per esempio:ASK Is it raining (yes/no)?IF yes THEN it's rainingIF it's raining SAY Bring an umbrella.IF it's NOT raining SAY Have a nice sunny day!ENDQuesto e` alquanto leggibile, ma come lo si interpreta?Be', una parola chiave potrebbe essere riconosciuta dal fatto che e` scritta tutta in maiuscolo. E gli argomenti sono delimitati da due parole-chiave, con la END alla fine che potrebbe anche non essere necessaria se si considera la fine del sorgente come ulteriore delimitatore. La stringa "it's raining" viene presa come il nome di un flag booleano, e il costrutto "THEN it's raining" come un assegnazione del valore TRUE a quel flag. La parola-chiave NOT, assieme a sinonimi come NO, NO LONGER, NOTHING, NOBODY, potrebbe definire una condizione che si verifica se la preposizione non e` vera. E cosi` via... personalmente avevo fatto un esperimento simile per un programma che eseguiva degli script per "adventures" a base testo, e devo dire che non veniva poi male. A proposito, e` qui:http://anywherebb.com/software.html (scorrere fino a "The Narrator")boh... ecco, non e` che voglia discutere quanto il concetto sia giusto o sbagliato, ma quanto meno mi sembrerebbe qualcosa di davvero nuovo. Mentre Python mi sembra, a prima vista, una riedizione di cose gia` viste, con relativamente lievi cambiamenti. Dato che di Python non so quasi una cippa, pero`, e` un parere da prendere con le pinze.==================================Modificato dall'autore il 02/12/2004 11.39.09
  • Anonimo scrive:
    Re: più basso livello di così....
    - Scritto da: Alex¸tg(...)

    Allora dovresti puntare a qualcosa di molto
    piu` semplice, ma capisco: intendi un
    compromesso. Be', che ci vuoi fare, mi ci
    trovo bene con tutte le entita` globali e
    senza dover considerare i concetti della
    OOP, che per la mia mentalita`, nata nei
    primi anni 80 quando la OOP era ben al di
    la` dal diffondersi, sono semplicemente
    controintuitivi. Non e` che tecnicamente la
    OO mi sembri una pessima idea: e` come viene
    implementata. Python non lo conosco se non
    di fama, ma in C++ mi fa proprio una pessima
    impressione: dover risalire fiumane di
    riferimenti per capire cosa fa una delle
    funzioni che andro` a chiamare... no, no,
    non mi aiuta.l'approccio Py e' piu' semplice. e non e' nemmeno necessario usare l'OOP per programmare in Python. Python non concepisce nemmeno public/protected/private... e la OOP in python non e' assolutamente invasiva come in altri linguaggi.C++ invece e' piuttosto complesso. non lo trovo nemmeno un gran linguaggio... ci sono voluti *anni* prima che qualcuno riuscisse a creare un compilatore compliant con il linguaggio. Objective C e' un altro tentativo di inserire concetti OO al "vecchio" C, esperimento pienamente riuscito IMO.. ora MacOSX si programma anche in Objective C (Cocoa e gli altri layer della GUI) mentre MS ha preferito lasciare da una parte C++ e sostituirlo con qualcosa di piu' usabile, C#, che somiglia piu a java che al C++.ciao.--dee
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Alex¸tg(...)
    Assolutamente il contrario per quanto mi
    riguarda: la parte OO di un linguaggio,
    visto che la OOP e` solo una possibile
    estensione della funzionalita`
    esclusivamente sintattica di un
    linguaggio, e` del tutto superflua per
    quanto mi riguarda, e ne complica la lettura
    dal punto di vista tecnico, anche se forse
    non da quello umano.discutibile, l'astrazione e' importante. che l'astrazione sia ottenuta mediante OOP o altri approcci e' da vedere.ma non posso fare a meno di notare che l'OOP anni addietro era stato spacciato come la panacea di tutti i mali, mentre non e' ovviamente cosi'. ora stanno blaterando di AOP (aspect oriented programming) che dovrebbe risolvere alcuni problemi dell'OOP. ironicamente alcune cose dell'AOP si possono gia' fare da anni LISP... e con i decoratori (@) del python 2.4 risulta molto semplice anche con quest'ultimo (si poteva fare gia' da prima, ma era bruttino da vedere).tenete anche conto che a parte l'OOP esistono anche linguaggi basati su altri approcci come quello funzionale (LISP, scheme, haskell...), procedurali (C, pascal...). conoscendo Py vi dico che il pitone e' una puttana, nel senso che nel linguaggio e nelle funzioni built-in ha nozioni di programmazione procedurale, funzionale e OOP. inoltre Py e' fortemente imperativo come approccio. tu gli dici cosa fare e lui lo fa, ad esempio:if x %2 == 0: del foo(): print "I'm foo"else: def foo(): print "I'm the other foo"foo()la funzione foo stampera "I'm foo" o "I'm the other foo" a seconda del che il valore di x sia pari o dispari. L'approccio funzionale in Python e' ottenuto con lamdba, map, filter, reduce e la moltitudine di funzioni nel modulo itertools. L'approccio OOP e' built-in dalla prima versione, fortunatamente senza la complessita' del C++. in python ci sono anche le meta-classi, ma non ho ancora avuto tempo di affrontarle :)


    E Bruce Eckel è d'accordo con me
    8)

    www.artima.com/intv/aboutme.html ...e
    se va

    bene a lui, buona camicia a tutti :D

    Ma lui puo` dire quel che gli pare, come del
    resto io... buona fortuna al Python,Eckel ha preso na mazzata quando , arrivando da java ,ha inziato a lavorare con python. lui dice:"It seems the compromise in Java is marketing (...) I feel Python was designed for the person who is actually doing the programming, to maximize their productivity. "non posso non concordare.
    comunque: fa sempre bene qualcosa di nuovo.
    Peccato per la moda della OO, ma pazienza...come ho scritto e' *stata* una moda, e sun e MS hanno pensato bene di progettare due linguaggi fortemente OO, java e C#... sul quale basare il loro business. personalmente non trovo che i risultati siano cosi eccezionali :-)--dee
  • Anonimo scrive:
    Re: più basso livello di così....
    - Scritto da: Anonimo
    Beh, allora complimenti. :) Parlavo di
    linguaggi ad alto livello e OO, paragonare
    Py ed ASM non ha assolutamente senso.Ok, vero.Mi ero dimenticato che escludevi il basso livello.
    Conosco bene l'assembly, e non vorrei mai
    buttarlo via (anche perché è
    impossibile ;). Tuttavia...Non fraintendermi, non programmerei volentieri in assembly un progetto che puo` essere fatto in un altro modo. D'altra parte per esempio adoro spudoratamente il PHP, proprio mi fa piacere scrivere roba in PHP, mi ci diverto direi. :)Programmo attualmente nel mio linguaggio ideale, che e` un compromesso, apparentemente paradossale, fra le prestazioni del basso livello e la portabilita` dell'alto. Vedi altra risposta...
    Questa non te la passo. Innanzitutto l'OO
    è un aggiunta SEMANTICA non da poco,
    direi fondamentale. Che poi non sia sempreBe', e` una questione di forma mentis, immagino.Io non la considero fondamentale perche` oltretutto mi ci trovo proprio male. Dal 1996 quando la incontrai per la prima volta, non ho mai potuto fare a meno di considerare almeno l'implementazione C++ della OOP qualcosa di cui non sentivo il bisogno, ergo di superfluo. Comunque e` vero che la mia risposta aveva qualche frecciatina nei suoi confronti, che in fin dei conti e` immeritata. D'altronde, de gustibus...
    adatta posso darti ragione: non si
    microprogramma un controllore in C++, si usa
    ASM. Allo stesso modo prova a sviluppare un
    GROSSO progetto software in asm, e dimmi che
    senso ha... visto peraltro che i compilatori
    odierni fanno nel 90% dei casi un ottimo
    lavoro.Si puo` sviluppare un grosso progetto in ASM. Non e` confortevole ma si puo`. Nel mio linguaggio, che e` molto vicino all'ASM, non ho difficolta` per progetti di media grandezza: di quelli grandi ne ho uno soltanto in corso, e per ora mi ci trovo comunque bene. Insomma: avere una serie di subroutines con un nome ben preciso, magari smistate in librerie, per me e` come avere una serie di funzioni smistate in classi e containers alle quali si possono associare metodi. Non ci vedo molta differenza nell'operare su un oggetto con un metodo, o nel chiamare una funzione che ha per argomento un "oggetto", un "qualsiasi cosa sia".
    Del punto di vista "tecnico" mi importa
    molto meno che di quello umano, dato che
    alla fine chi produce codice è
    proprio l'essere umano. Il linguaggio in cui
    lo si esprime è quindi fondamentale,
    per manutenibilità del codice,
    riusabilità, etc.Allora dovresti puntare a qualcosa di molto piu` semplice, ma capisco: intendi un compromesso. Be', che ci vuoi fare, mi ci trovo bene con tutte le entita` globali e senza dover considerare i concetti della OOP, che per la mia mentalita`, nata nei primi anni 80 quando la OOP era ben al di la` dal diffondersi, sono semplicemente controintuitivi. Non e` che tecnicamente la OO mi sembri una pessima idea: e` come viene implementata. Python non lo conosco se non di fama, ma in C++ mi fa proprio una pessima impressione: dover risalire fiumane di riferimenti per capire cosa fa una delle funzioni che andro` a chiamare... no, no, non mi aiuta.
    E poi dai, chiamare "moda" l'OO... ;) Siamo
    nel 2005, eh?Considerandola non fondamentale, per me rimane una moda del momento, e sospetto che prima o poi passera`: piu` poi che prima, ma secondo me passera`.
    LOL! Buon coding, e se ti servisse qualche
    scheda perforata fammi un fischio! :D:PMi basta un LFB truecolor, uno spazio flat in memoria, tastiera e dispositivi di puntamento, sockets berkeleyane, stampa wysiwyg, audio PCM in/out, e poche altre cose, e sono a posto. Le schede e la OOP tientele... :DPS. Fa piacere vedere che si puo` discutere scherzosamente invece di picchiarsi sugli errori di battitura.
  • Anonimo scrive:
    Re: Forza pitone!
    In Py non ha molto senso una cosa del tipo "gotoxy" per posizionare il cursore. Pertanto se vuoi un controllo "fine" di simili cose, usi un apposito toolkit (credo che esistano i binding python-ncurses per le interfacce su console...)Detto questo:name = raw_input("Inserisci: ")print "testo: %s" % namefine programma.Volendo essere ancora più stringati:print "testo: %s" % raw_input("Inserisci: ")Una riga ;)
  • Anonimo scrive:
    più basso livello di così....
    (sono il tizio del primo commento)- Scritto da: Alex¸tg
    No, per le "pure prestazioni" il top rimane
    l'assembly nativo.
    E se lo vuoi anche cross-platform, mi dovro`
    fare pubblicita`.Beh, allora complimenti. :) Parlavo di linguaggi ad alto livello e OO, paragonare Py ed ASM non ha assolutamente senso.
    Non si butta mai via niente, ma la scelta
    sarebbe probabilmente buona. Io l'assembly
    lo terrei per forza di cose, pero`:
    d'altronde, e` all'assembly che va a finire
    tutto quello che scrivi in qualsiasi
    linguaggio di livello piu` alto. E in barba
    alla programmazione strutturata e all'OOP,
    il microprocessore nons a cosa sia un blocco
    condizionale, che si traduce in un salto, o
    una classe di funzioni, che sempre
    subroutines sono.Conosco bene l'assembly, e non vorrei mai buttarlo via (anche perché è impossibile ;). Tuttavia...
    Assolutamente il contrario per quanto mi
    riguarda: la parte OO di un linguaggio,
    visto che la OOP e` solo una possibile
    estensione della funzionalita`
    esclusivamente sintattica di un
    linguaggio, e` del tutto superflua per
    quanto mi riguarda, e ne complica la lettura
    dal punto di vista tecnico, anche se forse
    non da quello umano.Questa non te la passo. Innanzitutto l'OO è un aggiunta SEMANTICA non da poco, direi fondamentale. Che poi non sia sempre adatta posso darti ragione: non si microprogramma un controllore in C++, si usa ASM. Allo stesso modo prova a sviluppare un GROSSO progetto software in asm, e dimmi che senso ha... visto peraltro che i compilatori odierni fanno nel 90% dei casi un ottimo lavoro.Del punto di vista "tecnico" mi importa molto meno che di quello umano, dato che alla fine chi produce codice è proprio l'essere umano. Il linguaggio in cui lo si esprime è quindi fondamentale, per manutenibilità del codice, riusabilità, etc.E poi dai, chiamare "moda" l'OO... ;) Siamo nel 2005, eh?
    Ma lui puo` dire quel che gli pare, come del
    resto io... buona fortuna al Python,
    comunque: fa sempre bene qualcosa di nuovo.
    Peccato per la moda della OO, ma pazienza...
    *si chiude nel bunker di mattoni refrattari*LOL! Buon coding, e se ti servisse qualche scheda perforata fammi un fischio! :D
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Alex¸tg
    No, per le "pure prestazioni" il top rimane
    l'assembly nativo.
    E se lo vuoi anche cross-platform, mi dovro`
    fare pubblicita`.A me interessa. Hai scritto un macro-assembler portatile?Ha mica "moduli di traduzione" per Motorola 68K e ARM?
  • Anonimo scrive:
    Re: Forza pitone!
    - Scritto da: Anonimo
    Certo, per le "pure prestazioni" il top
    rimane C++ ma il Python riesce a stupire
    anche in questo, rivelandosi a volte
    incredibilmente veloce.No, per le "pure prestazioni" il top rimane l'assembly nativo.E se lo vuoi anche cross-platform, mi dovro` fare pubblicita`.
    IMVHO, se dovessi "tenere" due soli
    linguaggi e gettare via tutti gli altri la
    mia scelta cadrebbe su Python e C++.Non si butta mai via niente, ma la scelta sarebbe probabilmente buona. Io l'assembly lo terrei per forza di cose, pero`: d'altronde, e` all'assembly che va a finire tutto quello che scrivi in qualsiasi linguaggio di livello piu` alto. E in barba alla programmazione strutturata e all'OOP, il microprocessore nons a cosa sia un blocco condizionale, che si traduce in un salto, o una classe di funzioni, che sempre subroutines sono.
    linguaggio NON OO, e i linguaggi non-OO sono
    il Male ;)Assolutamente il contrario per quanto mi riguarda: la parte OO di un linguaggio, visto che la OOP e` solo una possibile estensione della funzionalita` esclusivamente sintattica di un linguaggio, e` del tutto superflua per quanto mi riguarda, e ne complica la lettura dal punto di vista tecnico, anche se forse non da quello umano.
    E Bruce Eckel è d'accordo con me 8)
    www.artima.com/intv/aboutme.html ...e se va
    bene a lui, buona camicia a tutti :DMa lui puo` dire quel che gli pare, come del resto io... buona fortuna al Python, comunque: fa sempre bene qualcosa di nuovo. Peccato per la moda della OO, ma pazienza...*si chiude nel bunker di mattoni refrattari*
  • Anonimo scrive:
    Re: Forza pitone!

    Il C è un linguaggio NON OO, e i linguaggi non-OO sono il MaleIl Python e' fatto in C...cmq a parte questo pienamente daccordo con te, il Python e' un linguaggio fantastico, estremamente dinamico e innovativo.
  • Anonimo scrive:
    Re: Forza pitone!
    dai un occhiata pure a RUBY allora...
  • pippo75 scrive:
    Re: Forza pitone!
    visto che usi pyton, non e' che mi faresti un favore, mi dici come si scrive un programma simile in P., grazie.#include #include main(){ char testo[10]; gotoxy(10,10); printf("inserisci: "); scanf("%s",testo); printf("testo: %s",testo); getch();}
  • Anonimo scrive:
    Forza pitone!
    Eccellente. Ho scoperto Python solo recentemente, ma lo trovo geniale ed incredibilmente produttivo. Certe scelte sintattiche sono di una eleganza sconosciuta nei "tradizionali" linguaggi di programmazione... La semantica espressiva è di una potenza senza pari. All'inizio il discorso dell'indentazione obbligatoria (e la relativa assenza di graffe) può spiazzare, poi ci si rende conto che è una scelta giusta ed obbliga a produrre codice leggibile e coerente.La comunità è molto attiva e ci sono un sacco di documentazioni ed estensioni di terze parti al linguaggio --che peraltro nella sua versione base è completissimo.Certo, per le "pure prestazioni" il top rimane C++ ma il Python riesce a stupire anche in questo, rivelandosi a volte incredibilmente veloce.IMVHO, se dovessi "tenere" due soli linguaggi e gettare via tutti gli altri la mia scelta cadrebbe su Python e C++.Niente flame war di Javisti delusi o talebani del C, per favore... conosco bene anche loro, ma nel 2005 non ne vedo davvero l'utilità: Java è il C++ interpretato, leggermente "ripulito" e straordinariamente obeso, sia nella sintassi che nelle performance. Il C è un linguaggio NON OO, e i linguaggi non-OO sono il Male ;)E Bruce Eckel è d'accordo con me 8) http://www.artima.com/intv/aboutme.html ...e se va bene a lui, buona camicia a tutti :D
Chiudi i commenti