Newsgroup: it.comp.macintosh
Titolo: python<->objective-c

Che ne pensate di questo progetto?
http://pyobjc.sourceforge.net/
Conosco il C e il Java, ma siccome vorrei imparare a sviluppare usando 
cocoa/xcode, forse mi conviene imparare il python (che mi attira molto) 
piuttosto che l'objective-c (di cui trovo poca documentazione...e che si 
usa esclusivamente per cocoa...)...
che ne pensate?
Programmare in java-cocoa mi lascia un po perplesso...qualcuno ha 
esperienze in merito?
grazie!
ciao!

 esperienze in merito?
Perchè?
-- 
criticalkernel software
http://www.criticalkernel.com/
mail: 
malco...@fuckspam.gmail.com
aim: malcombsd

 esperienze in merito?
Sorry, non provato (quel po' di Java che ho fatto era AWT o Swing, non
so come vada con Cocoa o con altri framework grafici).
Alex

 sicuramente è più supportato da apple...
"Sicuramente"?  Ci sono applicazioni fatte da Apple in Java, come parte
di MacOSX 10.3?  In Python si`...
Alex

  
avevo seguito il tutorial sul sito della apple...ma alla fine bisognava 
scontrarsi comunque con l'obj-c...
forse accadrà anche con python...però il python ha delle grandi 
qualità, a differenza di java che grazie all'università mi è diventato 
abbastanza antipatico :)

 quel MB sto invece a disagio;-).
nessun problema di spazio ;)
bene...la scelta è fatta :)

 abbastanza antipatico :)
Ecco appunto. Sono in tanti a pensarla cosi`.
L'unico pregio appartente di Java e` che grazie alle pressioni di
marketing Sun e` molto richiesto (e quindi si trova molto lavoro).
Il rovescio della medaglia? Domanda e offerta. Piu` programmatori Java,
meno costa assoldarne uno (non e` proprio cosi` grezza, ma insomma...
Alex aveva alcune statistiche a riguardo, mi pare).
-- 
RiK0
Non credo negli schemi non vincenti.

 abbastanza antipatico :)
'Scontrarsi' mi pare un po' esagerato, ma secondo me conviene saperlo
_leggere_ perche` le doc sono in quei termini (come, che so, conviene
saper leggere Visual Basic se fai COM su Windows, perche` le doc sono in
quei termini)...
Alex

 :P
...sono "applicazioni"...?-)
Alex

 Alex aveva alcune statistiche a riguardo, mi pare).
Si`, "Software Development" fa un sondaggio annuale sulle retribuzioni
degli sviluppatori con varie caratteristiche; anche quest'anno quelli
Python sono in testa.  Ma quelli Java non se la passano male: se vuoi
bassa manovalanza semigratis, assumi sviluppatori Visual Basic, quelli
si` che, a giudicare dal sondaggio, costano proprio una cicca.
Alex

 ...sono "applicazioni"...?-)
quelle python lo sono? :-)
bah tra i due non sceglierei nessuno dei due, poi questione di esigenze
^_^


 
ho letto da qualche parte che Quartz, il "motore grafico" di OSX, è 
scriptabile in python...

 quei termini)...
cercherò di farmi un infarinatura di obj-c...ma prima do un occhiata al 
pitone :)

 ^_^
Produttivita`, manutenibilita`, leggibilita`, un linguaggio che non
aggiunge problemi a quelli inerenti alla tua applicazione ma ti aiuta ad
ogni passo -- il tutto senza l'indigeribilita` (escluso che per i PhD in
matematica) che (chissa` perche`!) pare caratterizzare tutti i linguaggi
con queste caratteristiche sino a Python escluso (Lisp e parenti vari,
Dylan, SML, Haskell, ...).  Dopo Python, con caratteristiche analoghe e`
emerso Ruby; altri ce ne saranno, ma come diffusione, non e` che si
vedano molto in giro (Boo, Prothon, Vyper, ...), mentre Ruby e ancor di
piu` Python hanno delle comunita` attive e vitali.
A proposito, ma Dylan, o non era un progetto Apple, a suo tempo?  Che
fine ha fatto, sparito con i vari Copland ecc?  Era (e` ancora, ma non
e` molto diffuso) praticamente un Common Lisp senza la sintassi concreta
tipica dei Lisp.  Vabbe`, magari non proprio altrettanto potente, ma
siamo li`, dalle macro all'approccio basato su multimethod, e comunque a
sintassi infissa.  Con tante feechurz che molti (non io) sognano in
Python, dalle macro alla dichiarazione statica facoltativa (come
ottimizzazione x aiutare il compilatore, che almeno e` l'inquadramento
giusto;-).  Chissa` dov'e` finito...!
Alex

 scriptabile in python...
Si`, fra le cosette carine incluse in MacOSX c'e` un modulo chiamato
CoreGraphics che appunto lo permette.  Ad esempio, un programma Python
(a linea comandi) per sapere quante pagine hanno dei file PDF e`:
import sys, CoreGraphics
def pageCount(pdfPath):
    pdf = CoreGraphics.CGPDFDocumentCreateWithProvider(
          CoreGraphics.CGDataProviderCreateWithFilename(pdfPath))
    return pdf.getNumberOfPages()
for f in sys.argv[1:]:
    print '%4d %s' % (pageCount(f), f)
Magari whamoo ci fa vedere la versione con GUI usando EasyDialogs, una
volta tanto non dovrebbe ingrassare di molto queste 7 linee;-).
Comunque a me ha fatto + comodo come commandline, per tenere d'occhio
sistematicamente l'andamento del libro in termini di # pagine (a un
certo punto erano piu` di 800, abbiamo dovuto potare severamente per
scendere a 600 circa, per stare entro le 700 quando si aggiungeranno
prefazioni, indici ecc).  Per carita`, sono sicuro che si fa altrettanto
bene in perl o Applescript o Java (o C++?-), ma fatto cosi` e` piccolo,
veloce, leggibile, e comodo, e tanto mi basta...
Alex

 veloce, leggibile, e comodo, e tanto mi basta...
ecco, ora lo so che sto per dire una stupidata... ma non facevi prima ad
andare a vedere l'ultima pagina che numero ha?! ;)
-- 
FabFour
Life is what happens to you while you're busy making other plans
Per email private togli le parti in MAIUSCOLO e ".invalid"
http://www.commissariatobellanapoli.it

 A che target di lettori si propone?
A chiunque conosca un pochino (o un moltino) di Python.  Non ne serve
molto: fra i revisori tecnici ci siamo assicurati di avere anche un
non-Pythonista (programmatore esperto, ma strettamente Java) cosi` da
garantire che anche il pitonista principiante tragga beneficio da fette
molto sostanziali del libro.  All'altro estremo, anche gli autori e i
revisori tecnici python-guru hanno imparato non poco dalle piu` "spinte"
e avanzate delle ricette e discussioni del libro.  Ovviamente il
"bersaglio grosso" e` il pitonista medio.  Soprattutto nei primi
capitoli, abbiamo inserito abbastanza "sidebar" per riassumere i
concetti elementari d'informatica che ricorrono nella discussione ma al
praticante praticone possono mancare -- dalla notazione big-O, a cos'e`
una closure, un predicato, la lazy evaluation, una metaclasse, ... sino
ad alcuni concetti fondamentali di analisi numerica (!).
Fammi esemplificare con quest'ultima che e` un mio pallino; l'ho anche
insegnata all'universita`, e un dettaglio che avevo sempre faticato a
spiegare bene e` questo: perche` sommare Nmila numeri (float) nel modo
ovvio (un ciclo con in mezzo un "totale = totale + numeretto[i]") perde
precisione, e perche` e percome si puo` fare di meglio?  Non dico
sciorinare i teoremi, dico spiegare in due parole l'essenza del problema
e della classica soluzione.  Beh, c'era una ricetta che offriva appunto
la soluzione classica, sostanzialmente traslitterata dal Fortran o dal C
o che (non cambia), ma senza spieghe.  Grazie all'abilita` maieutica di
Anna (che di analisi numerica capisce il giusto, ma, di come si insegna,
tantissimo), siamo riusciti a tirare fuori dal mio inconscio poche righe
che _finalmente_, mi pare, fanno _capire_ il perche` del problema e
della soluzione.  Gli analisti numerici purosangue ghigneranno, ma
secondo me ai 99% dei praticanti della programmazione _serve_, che le
cose si spieghino a livello comprensibile e chiaro, piuttosto che non
limitarsi a usare qualcosa che non si capisce per nulla, magari da una
libreria, come se fosse un'incantazione di magia nera...
Alex

grazie dell'esauriente spiegazione!
quando uscirą il cookbook nuovo dovrei essere gią "pythonista", ci farņ 
un pensiero :)

 quelle python lo sono? :-)
si.


 andare a vedere l'ultima pagina che numero ha?! ;)
No, questo mi avrebbe richiesto assai piu` lavoro manuale (aprendo e
controllando decine di file, tenendo a mente o copyandpastando
altrettanti numerelli per avere il totale...).  Con il comandino, zap,
fa tutto lui (volendo anche da cron, ma non ho avuto bisogno di questo
dettaglio), con opportuno *.pdf o che per dire quali capitoli voglio
verificare, totali a scelta con un filtro (altro programmillo) o
integrati, ecc.
I GUIomani queste cose non le capiscono... vedi Oxygen, il programmino
per XML che uso (commerciale, ma non caro): ha una simpatica capacita`
di trasformare docbook->PDF con XSLT e XFO ragionevolmente smanettabili.
Ma *SOLO GUI*: se voglio smanettare un paio di parametri e rifare tutti
i PDF di ogni capitolo ecc, sono 20-25 cicli di operazioni manuali GUI
"carica questo, fai quello, salva qui".  Il maledetto lavoro ripetitivo,
noioso, meccanico da cui i computer ci DOVEVANO liberare, ricordi...?
Una GUI dovrebbe come minimo essere pienamente scriptabile (al che resta
la palluccia di una visualizzazione su schermo che non serve, ma
pazienza).  Meglio ancora, le funzionalita` dovrebbero essere tutte
accessibili ANCHE da commandline.  E no, non mi basta l'accrocco per
fare "quasi uno script di GUI" che ci sara` in tiger: voglio la
commandline, cosi` posso senza problemi eseguirla in remoto, metterla in
un makefile, in un cron, e quant'altro.
Quando finalmente avro` il tempo di respirare devo capire come mettere
insieme una toolchain Docbook -> {XSLT, XFO} -> PDF tutta commandline,
mannaggia... non l'accrocco via TeX o simili, una verace...
Alex

 si.
come ho già detto preferisco codice compilato a quello interpretato.
Preferisco di gran lunga objective-c che soprattuto con le ultime
versione di X ha eliminato quel poco di differenza che si nota dal C
nella chiamata dei metodi.


 si.
sarà!


 nella chiamata dei metodi.
differenza che non sono mai riuscito ad apprezzare (nel senso di
notarla).


 un makefile, in un cron, e quant'altro.
Il "quasi uno script di GUI" e' solo Applescript sotto mentite spoglie.
Comunque sempre piu' programmi stanno iniziando ad aggiungere nel bundle
un programmino da linea di comando (come l'ultima versione di
SubEthaEdit... export EDITOR="see -w" :D).
 - ∞

 SubEthaEdit... export EDITOR="see -w" :D).
E` cosa buona e giusta!-)
Alex