Newsgroup: it.comp.macintosh
Titolo: Iniziare a programmare

Vorrei iniziare a programmare su osx?
Di linguaggio conosco abbastanza bene java.
Cosa mi consigliate?


-- 

I'm using an evaluation license of nemo since 89 days.
You should really try it!
http://www.malcom-mac.com/nemo

 
object c. oppure se vuoi qualcosa di "piů semplice" ruby o python

  object c. oppure se vuoi qualcosa di "piů semplice" ruby o python
si ecco, non vorrei iniziare con "roba pesante" :-)
:-)


 Cosa mi consigliate?
Python.
Poi Objective-C e tutto l'ambaradan di xcode, ma fatti le ossa col
bellissimo python :-)
Ciao
-- 
Riccardo Campana
pabel...@gmail.com
"Physics is like sex: sure, it may give some practical
results, but that's not why we do it"  (Richard Feynman)

 Di linguaggio conosco abbastanza bene java.
Ahia. Ha una brutta tendenza deformativa.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 Cosa mi consigliate?
il linguaggio "nativo" e' l'objective c (che e' tutto meno che pesante)
da leopard in poi il bridge java sara' deprecato mentre molta spinta (in
egual misura) verra' data ai bridge per python e ruby

 colbellissimo python :-)
Maaaaa...per python che editor si usa?
XCode?


  Ahia. Ha una brutta tendenza deformativa.
Devi dirlo alla mia universitą :-P


 Maaaaa...per python che editor si usa?
Uno qualsiasi; qui ti consiglieranno TextMate, io uso Smultron...


 le GUI in Swing.
Allora forse č il caso di lasciar perdere Python/Jython e puntare
su Ruby/JRuby, supportati ormai espressamente dalla Sun e da NetBeans 6.
La blogosfera rubinante ha una fortissima presenza Mac: basta dare
un'occhiata allo stile del nuovo aggregatore dedicato a JRuby
(
http://www.jrubyinside.com/
) che alcuni giŕ iniziano a preferire
decisamente a RubyCocoa.

 Vorrei iniziare a programmare su osx?
-Si faccia una domanda e si dia una risposta.-

 su Ruby/JRuby, supportati ormai espressamente dalla Sun e da NetBeans 6.
ma la domanda era programmare una sun o cosa? :-)

  -Si faccia una domanda e si dia una risposta.-
Marzullo style!


 ma la domanda era programmare una sun o cosa? :-)
Gli store Apple si reggono ancora su Java e sia in iTunes, sia
nel nuovo Finder di Leopard, di Cocoa io non ne vedo poi molto,
mentre un'ulteriore manciata fresca di Sun si scorge nello ZFS
e in Xray.
Guardando al lato lucroso di Mac OS X relativo alle applicazioni
enterprise e di rete, io ci vedo Java e potenzialmente sempre più
Ruby, non certo Cocoa o Python.

 qui ti consiglieranno TextMate
C'è un motivo: vale ogni centesimo che costa.
-- 
 - ∞
-- 
http://infinite-labs.net

 Ruby
A dire la verità sono parziale verso il rubino come linguaggio favorito,
ma solo perché lo ritengo più... "elegante"? Solo per una mia preferenza
personale.
(Come osavo canticchiare: Il pitone non èèèèèèè un serpenteeeee... è un
linguaggio potenteee, che ti apre la meenteee...)


 Ruby, non certo Cocoa o Python.
parliamo di server o di client?
lato client java e' out, lato server mi sa che e' osx che ha i suoi
problemi

 per cui complessivamente preferisco il serpente.
Cosa non ti convince pienamente di ruby? Ho iniziato a studiarlo in
questi giorni, python invece non lo conosco...
Ciao
Andrea
-- 
http://myretrocomputing.altervista.org

In article &
lt;nemoTue07...@diesel.cu.mi.it
&gt; MarcoGT -
Campioned'Europa 2007  &
lt;a...@me.com
&gt; wrote:
Ma scusate un attimo:
ruby serve solo per sviluppare programmi per il web?
Si basa su rails? Ma rails cosa č esattamente? Un framework?
Se volessi sviluppare app stand-alone, ad esempio di calcolo, ruby va
bene?


MarcoGT - Campione d'Europa 2007 wrote:
Ma rails cosa è esattamente? Un framework?
Rails è un framework che applica il paradigma Model-View-Controller
alla programmazione Web. Uno dei primissimi application servers MVC ad
affermarsi prepotentemente sul mercato fu WebObjects di NeXT a cui
ancora oggi si ispirano dichiaratamente non pochi degli innumerevoli
framework Java EE cha affollano il panorama (ad esempio, Tapestry e
Cayenne).
Si son scritti interi libri su Rails come agile sfidante a certe
lungaggini improduttive a cui si sono adagiati i tool Java, tipo le
caterve di file di configurazione in XML da settare ripetutamente.
In Rails basta invece seguire delle convenzioni piuttosto sensate
e far leva sul dinamismo a runtime di Ruby per evitare la configurazione
manuale di molte interrelazioni che vengono invece stabilite 
automaticamente seguendo criteri piuttosto logici ed intuitivi.



 fare GUI con Cocoa io ho sempre usato Python
Con py-objc?
-- 
Jollino
Salvaguardia dell'italiano: 
http://www.nokappa.it
Cerchi spazio web? Io mi trovo bene con Servage:
http://www.servage.net/?coupon=cust24439

 lato client java e' out,
E' pur sempre presente ancora nei box per il digitale terrestre e
negli smartphone veri, che costituivano in fondo il target
originario del progetto Oak.
Non č poi chiaro chi sia stato il vero vincitore nella battaglia per la
conquista del Web multimediale-interattivo ora che JavaScript 2.0 si sta
sempre piů riavvicinando a Java (classi, packages, macchina virtuale) e
Adobe č finita a ricorrere proprio ad Eclipse come ambiente di sviluppo
per Flex e il nuovo AIR.

 Ruby, non certo Cocoa o Python.
Non vedi Python perchč i pythonisti non fanno tanto casino quanto i
rubysti.
Tra l'altro invece a me sembrerebbe che Apple spinga parecchio Cocoa. E
inoltre fino ad ora le gui in Java sono state un flop. Promettono magie
con la 1.6, sono migliorati, ma da roba nativa sono sempre lontani.


 su Ruby/JRuby, supportati ormai espressamente dalla Sun e da NetBeans 6.
Jython è da lasciare perdere si. 
Ma se come motivo di buttarsi su Ruby indichi Swing, che è stato in
buona sostanza il campo in cui Java ha più floppato... come dire, non mi
sembra un eccellente consiglio.
Ruby è un buon linguaggio, ma io da una cosa come Swing mi terrei
lontano *anche* in Ruby.


 personale.
Io per deformazione professionale quando vedo un parser che per generare
un albero di sintassi astratta si deve affidare all'euristica sto
*male*.


 questi giorni, python invece non lo conosco...
Discorso lungo. Lo conosco e lo uso da tempo. Mi piace anche piů di
molte altre cose.
Ma ci sono molte piů cose che non mi convincono rispetto a Python. Ci
sono anche cose che mi piacciono di piů. Ma č in buona sostanza la mia
opinione personale, non un 'fatto scientifico'.


 Con py-objc?
yes.


 bene?
Per un'applicazione stand-alone certo. Va bene eccome. In particolare
per un'applicazione di calcolo direi di no. Ruby in se e per se non è un
linguaggio veloce, ma menre Python ha librerie numeriche
iper-ottimizzate, in Ruby non c'è nulla di paragonabile. È uno degli
ambiti in cui non lo vedo ottimamente.


Guido <gu...@home.less> wrote:

tutta roba che con osx, per ora (e per una altro bel po'), c'entra na
fava
cmq, forse avevo capito male io, ma il post originario parlava di
sviluppare applicazioni PER osx non digitali terrestr ne' applicazioni
web, quindi non resta che cocoa nei 3 gusti, objc python e ruby: java e'
out!

 Tra l'altro invece a me sembrerebbe che Apple spinga parecchio Cocoa.
o sono scemo io o per lo sviluppo di applicazioni per osx, nei prossimi
n anni, c'e' solo cocoa e quando non ci sara' piu' cocoa non ci sara'
piu' osx

 opinione personale, non un 'fatto scientifico'.
per ora, come fatto scientifico, mi pare manchi un compilatore di
bytecode... si e' vero, arrivera', ma per ora non c'e'

 bene?
per il calcolo e' pessimo
io uso python + numpy + matplotlib + ipython per altre esigenze guarda
in scipy
altrimenti con'objc *che e' un soprainsieme del C* ci puoi riutilizzare
tutte le libreire C, se ti servono C++ eppol ha previsto anche questo
con l'objc++ che in sostanza permette di fare convivere classi objc e
classi c++ nello stesso programma (non possono ereditare le une dalle
altre pero'!), addirittura su leopard il modello di eccezioni di objc
diventa quello del c++...

 rubysti.
Mi riferivo più che altro all'integrazione di Python in Mac OS X.
Fino a Panther, Apple distribuiva con MacPython un IDE e un Package
Manager creati proprio dalla comunità ma oggi non li trovi più, IDLE è
seminascosto e, anche a causa della mancanza delle readline, devi
comunque compilarti/installarti a parte i Python 2.4/2.5.
Il repository di PyObjC non è aggiornato da mesi e metà dei tentativi
di installazione remota dal Cheese Shop tramite easy_install falliscono.
Se si dà poi concretamente uno sguardo nei meandri di Mac OS X, di
scritto in Python si trova solo mailman (per lo meno nella versione
Server), dei  wrapper alle routine di CoreGraphics usati per i fax e,
in Leopard, il nuovo Calendar Server; per supportare quest'ultimo hanno
integrato Twisted ma, per quanto riguarda la programmazione Web e di
rete. la floridezza di qualche anno fa della promettente piattaforma
Zope/Plone è ormai solo un lontano ricordo.

 out!
C'è già da anni una quarta possibilità, visto che da sempre Mac OS X
integra un bridge Perl per il Foundation Kit (Apple lo usa ad esempio
negli script Perl dell'installer) e ci sono buone possibilità che
Leopard integri pure CamelBones, un bridge Perl che si estende
all'Application Kit.

 Zope/Plone è ormai solo un lontano ricordo.
Solo per chi non vede cosa sta promettendo (e mantenendo) Twisted +
Nevow. 
Dopo di che quale è il discorso? Applicazioni desktop? Programmazione in
generale? Programmazione web? Io vedo chiaramente un'espansione di
Python, specie negli ambiti tecnologicamente avanzati 'di frontiera'.
Ruby si sta espandendo di più perchè di moda (e vediamo quanto dura) e
perchè si fanno più pubblicità.
Ma non ci sono rischi di concorrenza e di mangiarsi il mercato, per
dire.


 bytecode... si e' vero, arrivera', ma per ora non c'e'
Si. Ma quello che voglio dire č che nel caso in cui in Ruby ci fossero
librerie (che non conosco) al livello di numpy (in codice nativo), il
gap verrebbe chiuso, anche se Ruby č in se piů lento di Python. 


 meno maturo.
dimentichi zope. :-)

 Nevow. 
scusate se mi intrometto, ma zope è tutto fuorché morto. Anzi, tutt'ora
ha dei vantaggi che altri framework non hanno.
Plone non mi piace, ed infatti non lo uso.
Ho visto altre soluzioni per il web in python ma, twisted imho è troppo
complesso da usare puro, django non è ancora stabile, turbogears mi
sembra un po' un'accozzaglia di codice.

 sembra un eccellente consiglio.
Alla recente JavaOne ci si è stupiti come mai Sun abbia avuto il
coraggio di dare così tanta rilevanza al nuovo JavaFX dalle
scarsissime possibilità di successo, quando da anni lo SwingBuilder
di Groovy offriva già analoghe comode scorciatoie alla verbosità
ormai tipica di Java.
Il nome "Groovy" era quanto mai azzeccato: finalmente un po' di
divertimento rilassato grazie alla simpatica sintassi riecheggiante
SmallTalk, Python e Ruby ma con in più la possibiltà di attingere
comunque alle librerie e ai framework avanzati disponibili per la
piattaforma Sun. Grails (l'ex Groovy On Rails) sta infatti raccogliendo,
com'era prevedibile, non pochi entusiasmi, ma il fatto che Sun
lo abbia da sempre ostracizzato potrebbe far pensare che si siano
ormai rassegnati a far portare in auge proprio JRuby.

 wrote:
Vorrei iniziare a programmare su osx?
Di linguaggio conosco abbastanza bene java.
Ho deciso...mi butto su OBJ-C e Cocoa...vorrei imparare il C :-)
Dite di acquistare un buon libro?
Consigli?

-- 

I'm using an evaluation license of nemo since 90 days.


 *male*.
Come si dice: se funge e funge il 100% del tempo...
-- 
 - ∞
-- 
http://infinite-labs.net

 ha dei vantaggi che altri framework non hanno.
Dovremmo discuterne su iclpy però concordo sul fatto che non sia morto.
Sui vantaggi.. boh... dimmi tu che lo usi :D
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 ormai rassegnati a far portare in auge proprio JRuby.
Beh ora JRuby lo stanno spingendo parecchio. Anche la community Ruby è
interessata. Staremo a a vedere


 all'Application Kit.
sono un poì' in ritardo inoltre perl e' sostanzialmente una schifezza
confronto agli altri due nell'ambito del general purpose programming

 di installazione remota dal Cheese Shop tramite easy_install falliscono.
vogliamo paralre di leopard?
eddai non ci credo che non sai nulla, stai cercando di fare fud?

 gap verrebbe chiuso, anche se Ruby č in se piů lento di Python. 
il fatto e' che non ci sono e, no, non sono convinto che tutto il ghep
verrebbe chiuso, certo molto ma tutto no, cazzo l'interprete ruby legge
l'ascii ogni volta che esegue, e' quasi grottesco!

 Consigli?
l'imperdibile hillegass e la documentazione dell'ADC (apple developer
connection: fatti un account gratuito li e scricati gli ultimi tuls end
docs) 

 yes.
Interessante, prima o poi mi ci metterň pure io. ;)
Cosě, tanto per sapere, quanto objective C nei tuoi progetti? Voglio 
dire, programmi praticamentei n Python e usi Cocoa solo per le GUI o 
cosa?
-- 
Jollino
Salvaguardia dell'italiano: 
http://www.nokappa.it
Cerchi spazio web? Io mi trovo bene con Servage:
http://www.servage.net/?coupon=cust24439

 interessata. Staremo a a vedere
Per forza. Ci sono tanti rubysti che vengono da Java (e che hanno ancora
simpatia per tale piattaforma). Il progetto in se č interessante, per
inciso.


 sembra un po' un'accozzaglia di codice.
Come dicevo Twisted è per gente molto on the edge che 'tira' la
tecnologia. Non tutti possono farlo e probabilmente non in tutti gli
ambiti si può fare.
Django non lo definirei 'non stabile', anche se a me non fa impazzire.
Di turbogears invece mi hanno parlato bene in molti.


 Come si dice: se funge e funge il 100% del tempo...
Se funge un po' per caso, la cosa non mi fa buona impressione.
Fra l'altro non dimentichiamoci che sono noti gli esempi che lo fanno
impazzire. E fortuna che al momento non vengono particolarmente
intuitivi da fare, ma in se e per se non è roba 'vietata' in Ruby o
particolarmente difficile da scriverci. È solo non troppo sensata.
Poi se metti insieme il fatto che puoi avere una classe sparpagliata su
n-mila files *e* che la sintassi di una variabile locale e di un metodo
sono *esattamente* la stessa, ci si trova in un altro piccolo imbarazzo.
Nulla da dire eh. Normalmente non da fastidio. Normalmente.
E sono tante piccole cose che in qualche modo mi lasciano incerto. Mi
spiego: mi diverto tantissimo a scrivere codice in Ruby. Il linguaggio
mi piace. Ma ci sono cose che mi lasciano perplesso come quelle sopra
menzionate. Mi viene da chiedermi: quando mi daranno problemi?
Esattamente come di recente mi sono per la prima volta imbattuto in
problemi con Rails. Finchè fai le cose per cui è pensato funziona
benissimo. Ma appena esci un poco dal seminato, devi andare a bucare un
po' di strati di black-magic [ cosa che per inciso mi diverte ].
Insomma per dire che non è tutto oro quello che luccica (e comunque
considero Rails al momento la migliore alternativa per applicazioni web
di struttura standard, complesse a piacere ].


 l'ascii ogni volta che esegue, e' quasi grottesco!
Dai uliano, a generare un albero di sintassi astratta ci va un
cazziliesimo di secondo rispetto ai calcoli che uno si trova a fare.
Poi non conoscendo librerie di calcolo, non saprei dirti se la tua
impressione è corretta o meno.


 cosa?
Programmo *esclusivamente* in Python. Posso chiamare tutto cocoa
(foundation, app kit etc) da Python.
NSFoo.alloc().init()
f = NSFoo.fooWithString_('boo')
f.boo_withMoo_('boo', 'moo')
etc. si impara presto, te lo fanno vedere nel sitarello.


 dimentichi zope. :-)
Non lo conosco e non lo uso, per cui non mi viene istintivo parlare di
qualcosa che non ho mai usato. 
Beh, ho usato le zope interfaces dentro twisted, ma non credo che valga
:P


 si ecco, non vorrei iniziare con "roba pesante" :-)
Non è solo questione di 'pesante'. È che una volta che hai imparato
Python ci fai praticamente di tutto. Imparato Ruby ci fai quasi
praticamente di tutto. 


 C'č un motivo: vale ogni centesimo che costa.
Esatto. In effetti io sarei anche disposto a pagarlo il doppio.
E comunque va bene anche se poi uno cambia linguaggio.
Per Ruby offre un supporto ancora maggiore che per Python.


 Uno qualsiasi; qui ti consiglieranno TextMate, io uso Smultron...
Beh, ci sono quelli che facilitano e quelli meno.
Di recente ho provato KomodoEdit, una versione free del celebre IDE. E
devo dire che non funziona affatto male.


 diventa quello del c++...
Questo me lo sono perso... hai un link?


 Ho deciso...mi butto su OBJ-C e Cocoa...vorrei imparare il C :-)
De gustibus. Io non ti indirizzerei in questa direzione.
Ah, e per imparare il C, Objective-C non ha nulla a che vedere. Per
imparare il C ci vuole sudore ed esperienza *in C*.


 impressione è corretta o meno.
se fosse solo calcolo, ok

 Questo me lo sono perso... hai un link?
ehm... aspetta ottobre :-/

 eddai non ci credo che non sai nulla, stai cercando di fare fud?
A quello provvede già l'orrida chimera che hanno scelto per logo... :P
Non sono poi certamente nemmeno l'unico a dire che alla PEAK hanno
ormai qualche problema di troppo.

Guido <.> wrote:

cazzo c'entra peak con pyobjc?
stai decisamente facendo fud
(a sto punto fanculo nda e diciamocelo che pyobjc cosi come pure la
controparte ruby sono preinstallate in leopard, e quindi che il
probabile motivo percui pyobjc non vede aggiornamenti e' che l'hanno
preso in mano direttamente da eppol)

 wrote:

scappata per scappata te la dico tutta, vale solo a 64 bit, ma entro il
medio termine dobbiamo convincerci che 32 bit sparira'... cosi' come
carbon

 preso in mano direttamente da eppol)
Domani uscirà a ritmo serrato RubyCocoa 0.12, annunciato nella mailing
list direttamente da Sansonetti di Apple. Due linguaggi, due politiche
di riservatezza completamente diverse? Non credo.

 (foundation, app kit etc) da Python.
Buono a sapersi, mi installerň PyObjC e proverň a combinarci qualcosina. 
Grazie!


 di riservatezza completamente diverse? Non credo.
eppure pyobjc se ne sta li bello e solare, preinstallato nelle ultime
due pre-rilis di leopard... visto che in tigger non c'era, immagino che
c'e' capitato per caso? alla eppol hanno deciso di mettercelo anche se
era in stato di sfacelo? hanno fatto pure la presentazione al wwdc 06
trattando i linguaggetti di scripting con pari dignita' o me lo sono
sognato?
poi vogliamo dire una bella versione 0.12 sara' pure nuova di trinca ma
come numerazione non e' molto incoraggiante, eh

 imparare il C ci vuole sudore ed esperienza *in C*.
E qualche sacrificio di sangue al dio dei puntatori


 ormai qualche problema di troppo.
Cosa c'entra PEAK?
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 
Sě Sě ti credo, un sacco di gente ha problemi con easy_install. Io a
volte. Č anni luce indietro "gem" o "cpan"






beh, meglio cosi'... visto che qui qualcuno vuole per forza suonare a
morto sul pyobjc meglio che se ne parli...

 per farlo) e in questi compiti i cazzillesimi magari qualcosa contano
Come dicevo, bisogna vedere caso per caso. Ma stiamo discutendo sul
sesso degli angeli: la libreria numerica supercazzuta e stabile per Ruby
*non* c'č.


 carbon
Ok. Ad ogni modo posso sempre battere i blog per maggiori informazioni.
Minchia vedo già in giro le ISO taroccate di Leopard, vuoi che qualcuno
che ha già infranto la legge non chiacchieri anche su nda che non ha
firmato? :)


 morto sul pyobjc meglio che se ne parli...
Tra l'altro non capisco il perchč. Bah.


 praticamente di tutto. 
Beh, immagino che siano entrambi turing complete ;)
E' anche un discorso di COME lo fai, quel tutto :)

 E' anche un discorso di COME lo fai, quel tutto :)
e proprio questo è il punto. quando stai nel mondo dell'IT il punto
chiave è la fattibilità *effettiva*, non quella *pratica*.
In *teoria* potrei costruire una macchina di turing e emularci il mac.
In pratica sarebbe alquanto scomodo, cosa dici?
Per cui *in pratica* ci sono determinate cose che in Python fai
agevolmente e in Ruby no. Un esempio è il calcolo scientifico. Un'altro
esempio è un complesso servente di rete. In Ruby puoi farlo, ma per
avere le stesse performance e facilità di uso che in Python hai gratis
grazie a Twisted (per dire), devi lavorarci sopra di più.
In altri ambiti sono perfettamente equivalenti oppure c'è un vantaggio
nell'altra direzione. 
Ma non è una questione di *linguaggio*, in effetti. È una questione di
*librerie* disponibili per quel linguaggio.


)
Nella realtà dei fatti Perl è, infatti, una piattaforma ancora
consolidatissima tra gli amministratori di rete e i webmaster
professionisti e non vedo il motivo di ridicolizzarla, ora che
tra l'altro hanno anche loro i loro bravi cloni di Rails,
tipo Catalyst... :P
In Linux i programmi realizzati com PyGTK sono molto più
che decenti ma sotto Mac OS X le applicazioni desktop scritte
con Tk e i wxWdigets sono improponibili per uno uso serio:
questa aspettativa per il bridge con Cocoa nell'ambito
"general purpose" non farà che continuare probabilmente
a disilludere (io ho appena cestinato seduta stante Miro, una
tra le poche applicazioni desktop vere in PyObjC che sembrava
promettere di più, l'ex DemocracyPlayer).
Chi sta dietro a PyObjC stesso ammette il silenzio di tomba
all'ecesso in cui sono piombati:
"CoreGraphics is not yet wrapped, or rather is not wrapped
in a publicly released version of PyObjC.
I really have to write about what I've been working on for
a while..."
-- Ronald Oussoren
"Yeah -- you and me both (though mostly you)."
-- Bill Bumgarner
(
http://news.gmane.org/group/gmane.comp.python.pyobjc.devel
)
Ma bisogna saper leggere dietro le righe. Non si tratta
di mirabolanti nuove interfacce col Core Animation di Leopard
ma, come scritto sopra, solo di testare ancora l'interfacciamento
con le librerie Carbon e in C/C++ di Mac OS X.
Perché Carbon e il C/C++ in Mac OS X ci stanno per rimanere
ancora per un bel po'.
-- 
Using Opera's revolutionary e-mail client: 
http://www.opera.com/mail/

 ancora per un bel po'.
soprattutto il carbon a 64bit?

 soprattutto il carbon a 64bit?
Sono appena usciti File Maker 9, la Master Collection di Adobe
e i primi ragguagli su Office 2008...

 e i primi ragguagli su Office 2008...
office puo' anche morire a 32 bit che nessuno se ne accorge, se adobi
non passa a 64 mi sa che sono cazzi amarissimi... mi giunge voce che ps
cs3 non veda piu' di 3 giga di ram... assurdo comprarsi un macpro a che
pro? :-(
cmq e' ovvio che carbon e' praticamente gia' deprecato da ora e che
potrebbe sparire dal 10.7 per non dire prima... a seconda del fidbec che
ricevono dalle major

 farebbero schifo, per nulla!.)
ho perso quei 5 min di tempo per dare un occhio al sito
questi sono dei dementi, e quello sarebbe un luc nativo??? coi menu
dentro a ogni finestrella? percarita'ddiddio!! dio ce ne scampi e liberi
(a quel punto c'e' ben poca differenza a fare girare le gtk sotto
xwindos)

 all'ecesso in cui sono piombati:
Ecco, questa è una cosa interessante. Io apprezzo sia Ruby che Python.
Dici che RubyCocoa è più promettente? Vedo che l'svn è decisamente più
attivo ma potrebbe dipendere dal fatto che ha molti meno anni :D


 dentro a ogni finestrella? percarita'ddiddio!! dio ce ne scampi e liberi
Dove sono gli screenshots?


 Dove sono gli screenshots?
non molto lontani
http://developer.imendio.com/projects/gtk-macosx

 
http://developer.imendio.com/projects/gtk-macosx
urendo


 urendo
  Il peggio non č l'aspetto. Č l'usabilitą.
-- 
Nicola D'Agostino
<!-- 
http://www.nicoladagostino.net
 -->
<!-- 
http://www.storiediapple.it
 -->
<!-- 
http://www.nezmar.com
 -->

   Il peggio non è l'aspetto. È l'usabilità.
vero. ma una volta che le cose funzionano, ci si può lavorare sopra.
il duro è portare il backend su quartz. 


 nell'albero dei sorgenti delle Gtk.
quindi *ufficialmente* il port gtk pr mac e' una cagata assurda :-D?

 il duro è portare il backend su quartz. 
il duro e' farlo bene... 


sembra in realtà che di Cocoa ne abbiano messo troppo: per riuscire
ad ottenere prestazioni migliori della controparte sotto X11,
tenteranno di rimpiazzare sempre più parti con chiamate Carbon
a più basso livello.

  urendo
Sarà anche urendo ma come pensi di trasformare un programma pensato
per avere i menù nella finestra in uno con stile nativo? Dovresti
avere un algoritmo in grado di capire cosa volesse fare il
programmatore...alquanto impossibile.
Il porting di GTK vuole solo eliminare l'uso di X11 ed avere una cosa
che giri nativa, poi saranno i vari programmatori che dovranno
sistemare i loro software perchè su Mac OS X vengano visualizzati come
si deve, quello screen non dimostra altro che il porting di GTK è a
buon punto tanto da far girare Gimp.
War3333


-- 

I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at 
http://www.malcom-mac.com/nemo

 buon punto tanto da far girare Gimp.
Sě sě, sfondi una porta aperta. A me gtk piace tantissimo ma ritengo che
il suo look and feel su OSX sia un pugno in un occhio, tutto qui


 programmatore...alquanto impossibile.
Č niente di piů di quello che fanno Swing/SWT e Qt. Per cui direi nulla
di lontanamente impossibile: viene fatto tutt'ora.


 di lontanamente impossibile: viene fatto tutt'ora.
Al momento l'ostacolo più grande nel convertire i menù GTK
in un singolo menù Carbon/Cocoa è che nei primi è possibile
inserire qualsiasi widget. In Mac OS X solo con Leopard gli
elementi dei menù potranno essere qualsiasi NSView.

 nulladi lontanamente impossibile: viene fatto tutt'ora.
Si, ma hanno chiamate particolari per fare quello che dici tu, prendi
per esempio il programma Java della Sogei lo stile dei widget è quello
di OSX ma il menù è dentro ogni finestra, per le Qt è lo stesso hanno
una serie di widget per disegnare le finestre ed i pulsanti in stile
con Mac OS ed anche una serie di chiamate specifiche per avere il menù
unico sulla barra ma stà tutto al programmatore scrivere in modo che
su Mac OS questo venga usato.
Le GTK+ non lo hanno mai avuto, forse lo inseriranno in questo
porting, e comunque i programmatori non hanno mai pensato i loro
programmi per questo utilizzo quindi un po' di adattamento andrebbbe
studiato.
Per lo stile dei widget mi sembra che GTK+ abbia uno stile simile ad
acqua solo che si vede che non viene usato in queste versioni.


 il suo look and feel su OSX 
Essendo completamente skinnabile, non ci vorrà molto a usare HITheme per
disegnare le cose come fa OS X invece di usare bitmap.
-- 
 - ∞
-- 
http://infinite-labs.net

 disegnare le cose come fa OS X invece di usare bitmap.
(... dopo che sia assodato che funzioni correttamente, ovviamente.)


 Di turbogears invece mi hanno parlato bene in molti.
non mi piace molto la sintassi sua. Si vede troppo che è tanto roba
diversa messa assieme.

 una 1.0...
Eh eh conosco un fottìo di siti Django in produzione che se la cavano
egregiamente. Vero che l'api non è stabilissima ma c'è parecchia cura
per la stabilità del codice. Gli sviluppatori son bravi :)
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 vero. ma una volta che le cose funzionano, ci si può lavorare sopra.
  Teoricamente vero. Nella pratica non va a finire mai bene:
l'interfaccia va pensata durante, se non proprio prima del motore. Cito
ancora una volta in proposito quanto scrive in "The Inmates..." Cooper.
-- 
Nicola D'Agostino
<!-- 
http://www.nicoladagostino.net
 -->
<!-- 
http://www.storiediapple.it
 -->
<!-- 
http://www.nezmar.com
 -->

 inserire qualsiasi widget. 
Effettivamente hai ragione, anche se da non programmatore GTK non ci
avevo mai pensato.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 acqua solo che si vede che non viene usato in queste versioni.
Tutti hanno stili che clonano aqua. Ma quello che conta è anche il feel.


 l'interfaccia va pensata durante, se non proprio prima del motore.
Ma qui non è questione di 'pensare' l'interfaccia. È questione di fare
il porting di una libreria. 


 il porting di una libreria. 
  Allora non capendo chiedo: il disastro di interfaccia in Gimp (ad
esempio) a chi è adducibile? 


 esempio) a chi č adducibile? 
Gimp č un disastro di suo in quanto a interfaccia <g>



[SNIP]
[SNIP]
[SNIP]
Conlude con:
"The best part of this is that maintenance of these metadata
files can be shared between the users and developers of a number
of language bridges and with some luck framework authors will
start shipping metadata files with their frameworks."
Che vi avevo detto?
Le novità più importante è di poter interfacciarsi con
il Foundation Kit ed altre tecnologie non strettamente
Cocoa... :P

 Cocoa... :P
Oops: intendevo Core Foundation.

 esempio) a chi č adducibile? 
A chi ha pensato l'interfaccia del Gimp e solo a lui.
Ma dovresti venire qualche volta su icod. Magari indurresti a ragionare
un po' di teste calde.


 un po' di teste calde.
  Ti ringrazio ma temo di non avere "i numeri": non sono (per scelta)
programmatore o sviluppatore quindi dubito sull'apporto che darei con le
mie riflessioni ed obiezioni su cosa si ritrova in mano l'utente una
volta che lo sviluppatore ha finito.


 a più basso livello.
sono dei dementi completi
hanno messo troppo cocoa ma i menu' li hanno lasciati nelle finestre
(per non paralre del resto del luc... )

 esempio) a chi è adducibile? 
checche' se ne dica gimp e' un disastro a prescindere dall'interfaccia,
e' proprio il motore che fa cagare

Guido <.> wrote:

ed e' un male?
dico il potercisi interfacciare?

 e' proprio il motore che fa cagare
Puoi motivare questa affermazione (disturbi intestinali a parte)?



tanto per dirne una,immagine grande apri un filtro e spippoli un po con
gli slider: lendo da fare pieta', fai la stessa cosa in ps, un razzo
quale e' il motivo?
bad design: gimp ricalcola tutti i punti dell'immagine anche se ne
mostra nella finestra meno di un milione: pusha i dati su per la catena
di processing, ps fa i calcoli al volo solo per quello che si vede pulla
i dati da visualizzare e processa solo quelli
(il concetto di coreimage alla adobi lo conoscevano da tempo, e' pure lo
stesso del java imaging sarcazzo che non mi ricordo... ma gimp, almeno
l'ultima volta che l'ho guardato lo ignora bellamente)

 volta che lo sviluppatore ha finito.
Guarda, la maggior parte delle persone su icod non sono programmatori.
Non in senso stretto, magari hanno fatto un sitarello PHP di tanto in
tanto, ma insomma, il loro mestiere è un altro.


 i dati da visualizzare e processa solo quelli
Bella li. Inchiodati. Ma almeno quando poi applichi tiene buono quello
che ha calcolato oppure ricalcola? :P


 che ha calcolato oppure ricalcola? :P
je sais pas, ma e' comunque irrilevante: 
da un punto di vista utente quello che caga il cazzo pesantemente e' la
lentezza di risposta quando regolo il filtro, se ogni volta che sposto
un cursore devo aspettare 15 secondi per vedere l'effetto dopo 3 mosse
non mi ricordo nemmeno come mi chiamo, poi quello che ci mette il filtro
e' tuttosommato irrilevante
(se dovessi indovinare direi che ricalcola: nel il metodo pull la tua
immagine e' spesso scalata quindi fa dei conti su cose che sono medie di
pixel... i risultati non servono quindi a un beneamato cazzo)

 (per non paralre del resto del luc... )
Nella tesina è tutto dettagliato: bisognerebbe comunque attendere Leopard
dove gli NSMenuItem sono stati rivisti a fondo e permettono finalmente
di incorporare delle NSView completamente personalizzate, come le GTK
consentono di già.
Per disegnare i controlli in stile Aqua basterebbe ricorrere semplicemente
all'Appearance Manager ma il problema più serio è che bisognerebbe mettersi
a convertire i file di risorse tra i formati Glade e i nib di Interface  
Builder,
impresa piuttosto improba visto che ci si trova davanti a due paradigmi
del tutto differenti per quanto riguarda la gestione degli eventi
associati ai controlli, da una parte i segnali e le callback, dall'altra
il pattern targert/action.

Guido <.> wrote:

a sto punto... che senso ha tutto cio'?

 dico il potercisi interfacciare?
Sostenevi che la stazionarietà di PyObjC era probabilmente solo
apparente e dovuta al fatto che Apple l'aveva fatto suo, apportandoci
magari delle importanti novità.
Io avevo invece l'impressione che la stasi fosse semplicemente
dovuta al rodaggio del BridgeSupport, una soluzione presa tout court
da RubyCocoa e che permette di usare agevolmente simboli e strutture dati
di librerie tradizionali che non possono venir esplorate a runtime,
costringendo altrimenti ad andare manualmente ad estrarsi da sé tali
informazioni dagli header.

Guido <.> wrote:

beh che apple l'abbia fatto suo e' un fatto: ce lo ritroveremo
preinstallato, quanto al lavoro fatto per avere anche l'accesso alle
librerie tradizionali ben venga, per dire prima quartz era disponibile
(limitato) solo nel python di serie di eppol (che e' nota per non
aggiornare l'iterprete) ora l'avranno tutti con ovvi vantaggi
che poi il lavoro venga dalla maggior spinta che rubicocoa ha avuto non
cambia la sostanza (e secondo me ha avuto maggior spinta anche perche'
ne aveva maggior bisogno, non solo per la moda) meglio che lo stesso
lavoro venga fatto una volta sola...

 a sto punto... che senso ha tutto cio'?
Potersi compilare direttamente dai sorgenti originali la miriade
di programmi disponibili per le GTK, poterli eseguire non più sotto
l'ambiente X11 bistrattatissimo dall'utenza Mac ordinaria e poter
potenzialmente sfruttare maggiormente i servizi di sistema nativi
di Mac OS X come il motore di resa dei font, la clipboard, il Dock,
i Launch Services, il BridgeSupport.... :)

Guido <.> wrote:

quanto a x11 se l'interfaccia e' quella cambia na gott, ecco giusto i
font nativi... che culo! :-)

 lavoro venga fatto una volta sola...
Io credo che anche il fattore moda sia importante. Pensa a quante
persone hanno sentito parlare di Ruby, pensa inoltre al fatto che la
piattaforma 'cuore' di Rails è proprio OS X e pensa a quanto sia
importante Rails nella comunità Ruby (alcuni rubysti di vecchia data
aggiungono anche purtroppo).
Peraltro io sono contentissimo del successo di Ruby. Accettare Ruby
vuole dire che anche le obiezioni dei tradizionalisti su Python vengono
a cadere. E inoltre lavorare in Ruby è piuttosto piacevole a
prescindere.


 prescindere.
mi ha incuriosito, ci ho dato un occhio, e' sicuramente carino e
utilizzabile (lasciando perdere le mie particolarissime esigenze) ma non
c'e' filing... (alcune cose di derivazione perlistica mi fanno
accapponare la pelle :-D)

 font nativi... che culo! :-)
Tra l'altro io sto cercando di arrovellarmi su quale sw di uso comune
fatto in GTK vorrei 'disperatamente' su OS X. E non trovo soluzione.
Per dire, K3B mi piacerebbe vederlo portato. Abiword già esiste...
cos'altro?


 cos'altro?
per me non e' questo il punto, per dire volendo pararsi il culo e
rimanere multipiattaforma sarebbero una alternativa in piu' a qt4 (per
ora complesso compilarselo) wx (per ora cesso sul mec)...
alla fine fanculo il multipiattaforma (e fanculo pure l'svn poco
attivo), mi sa che usero' pyobjc :-D

 accapponare la pelle :-D)
Eh, questione di gusti.


 involutissimi framework. E piano piano...
io al mio amico gli ho messo la pulce nell'orecchio quasi un paio di
anni fa... per ora pare assolutamente refrattario tutto contento dei
suoi tuls altamente ingegnieristici per il suo amato giava :-D 

 attivo), mi sa che usero' pyobjc :-D
Quello che faccio io :)


 suoi tuls altamente ingegnieristici per il suo amato giava :-D 
Ci sono sempre quelli un po' di coccio eh. :)


 accapponare la pelle :-D)
L'unico perlismo alquanto indigeribile per me è l'accoppiata
del "=>" degli hash e il ":" dei simboli, ma in Ruby 1.9 è
stata introdotta una nuova sintassi e al posto di
     :key => value
si potrà scrivere semplicemente
     key:value
Un guadagno di leggibilità non da poco per Rails e altri
potenziali Domain Specific Languages (DSL's).
Per il resto, son loro stessi a deprecare gli stili più criptici
alla Perl (tipo l'uso sottinteso della variabile $_). Io poi
trovo la gestione delle espressioni regolari molto più  consistente
che in Python: con "search", "match" e "findall" là hanno esaurito
confusionariamente la schiera dei sinonimi disponibili...

 confusionariamente la schiera dei sinonimi disponibili...
Vero, a volte mi trovo a usare un tester per ricordarmi che risultati
avrei usando questo o quel metodo :-P
Però è un problema di memoria mio dato che non le uso spesso.
Non penso che tu sia uno di quelli che va in giro a dire "python fa più
schifo perché le regexp stanno in una lib e non nel linguaggio" ;-)
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 schifo perché le regexp stanno in una lib e non nel linguaggio" ;-)
Anche se ti confesso che a mio modestissimo parere avere il 'tipo'
letterale regex non è poi così male.
La cosa brutta sono i vari ~= o =~ chi se lo ricorda, che esattamente
non mi ricordo mai che semantica precisa abbia. E così via. Laddove il
gsub nelle stringhe è una figata astrale, ci sono queste altre cose che
non mi piacciono.
Come dire... sono questioni di gusti. E tutta la questione è un filino
secondaria ad altri difetti.
Tipo ultimamente mi sto convincendo che avere *solo* l'indentazione per
la separazione dei blocchi è *anche* un grosso limite. In primo luogo a
livello di tokenizer/parser è un mezzo macello. Una delle cose belle dei
linguaggi 'classici' è la regolina del tokenizer che ti butta via gli
spazi. Qui non solo non posso farlo, ma devo tenerne *tanto* conto.
Per cui ricordo da qualche parte che Guido aveva rifiutato una feature
non male, che avrebbe tuttavia richiesto di modificare di brutto il
parser in modo eccessivamente complesso. Mi sembra avesse a che fare con
un rhs su più linee, ma non ricordo con precisione la questione, ricordo
la motivazione.
Poi mi vengono in mente l'embedding. erb è semplice e lineare. limitato
finchè vuoi, ma fa il suo maledetto mestiere. In Python ci sono 850
linguaggi di embedding, e nessuno piace a tutti. Addirittura molti
scelgono di crearne uno che non assomiglia nemmeno a Python (pensa a
Django). Non è che bisogna introdurre la keyword end *perchè* così si fa
embedding.
Solo dico che alla fine questo cambio di contesto rende evidente una
potenziale debolezza del paradigma.
Per non parlare di quando per esempio si passa Python per HTML, dove
bisogna stare molto attenti agli spazi, altrimenti ci si trovano
snippets non valide (altro problema minore).
Niente di rilevante, per carità. Non è certo una 'critica' sostanziale a
Python. Ma per dire, che in fondo anche la più 'classica' delle critiche
ha un qualche fondamento. E come al solito il 90% di quelli che la
muovono, la muovono a sproposito. 
Poichè dopotutto a me utente:
1) di quanto sia difficile modificare il parser me ne sbatto le palle
2) dei linguaggi di embedding pure, dopo tutto nessuno di quelli che ho
provato è veramente male, ma soprattutto esattamente come a erb
preferisco rxml, preferisco soluzioni analoghe su Python (peccato non
trovare molta documentazione su come fare giocare nevow con dojo). Per
chi vuole una cosa 'semplice', più o meno tutti i vari sistemi di
embedding funzionano bene e si imparano in pochi minuti, per cui...
3) presentare snippet python in HTML è una cosa che una volta che uno ha
un tool è fatta per sempre.


 confusionariamente la schiera dei sinonimi disponibili...
Ma non sono sinonimi. findall vuole dire *trova tutti*. Mi pare chiaro.
search va a pescare la *prima* occorrenza dentro una stringa. Potevano
chiamarlo find? Forse.
match invece è una corrispondenza esatta. È *diverso* dal search. Ed è
implementabile in modo abbastanza più efficiente. search deve provare
lettera per lettera se quello è un possibile inizio. match invece parte
dalla prima e se il match non ha successo, bene, allora può dirti subito
'fuck'. 


 lo avessi scritto, a quest'ora sarei molto piů avanti. 
poco ma sicuro

 poco ma sicuro
Ti confesso che anche scriversi un parser C non č che sia un compito da
mezzo pomeriggio eh. O meglio, un parser alla cazzo di cane si, ma se
vuoi gestire *bene* gli errori per cercare di capire dove sono i
problemi meglio di yes/no non č proprio una strunzata :)


 problemi meglio di yes/no non č proprio una strunzata :)
ne ho una (nemmeno troppo) vaga idea, ma certo poi sei in grado di farci
quello che vuoi senza "perversioni"...

 simbolo).
Facevo più che altro riferimento all'uso degli hash per il
passaggio di argomenti e per simulare in qualche modo
i "named parameters" previsti solo per Ruby 2.0.
Se al posto di
  redirect_to :action => 'login', :id => @user
scrivo
  redirect_to action:"login', id:@user
mi sembra di guadagnarci molto in leggibilità e... scrivibilità,
anche perché i due punti sembrano proprio star a significare
"valuta per questo quel che segue".

 quello che vuoi senza "perversioni"...
Sono contrario agli 'overkill'. Siccome questo *č* poco piů di uno
script di colla con un programma Prolog, me lo tengo in tal modo.


 i "named parameters" previsti solo per Ruby 2.0.
In questo caso č carino. Ma io sono contrario nel ficcare dentro in un
linguaggio features *sintattiche* solo perchč sono carine. 
Penso ci voglia *molto* rigore per non fare diventare il tutto un
carrozzone.


 carrozzone.
In questo pericolo era caduto Groovy: per fortuna c'è stato un
cambio di guardia e hanno rielaborato una grammatica formale più
rigorosa.
Groovy ha al mio avviso la soluzione sintattica più carina e
consistente: array ed hash sono limitati entrambi da parentesi
quadre mentre le parentesi graffe sono riservate alle closures:
["Lu":"Lunedì", "Ma":"Martedi].each {key, value -> println key + "="  
+ value };

 quadre mentre le parentesi graffe sono riservate alle closures:
Ti confesso che Groovy non mi ha molto impressionato. Mi chiedo quale
sia il suo *reale* senso.


 sia il suo *reale* senso.
Provare tutte le feature possibili e immaginabili in un linguaggio <g>


 Provare tutte le feature possibili e immaginabili in un linguaggio <g>
Per quello ci sarebbe giů Oz (che riesce a farlo con una delle sintassi
piů involute degli ultimi 15 anni, perfino l'hello world č brutto).
