Newsgroup: it.comp.macintosh
Titolo: Mac e programmazione

Ciao a tutti, questa volta vi disturbo per una curiosità.....
sono switcher da pochi mesi e, quando usavo win, mi divertivo a 
programmare (a livello hobbistico) con visual basic. Passato a mac ho 
iniziato a giocare con realbasic che, a quanto leggo sul web, sembra il 
corrispettivo del VB. Mi chiedo questo... come mai sul VB di trovano in 
rete tutorial, corsi e quant'altro anche in italiano, mentre per il RB, 
che ritengo molto superiore IMHO, c'è molto poco? Ma gli utenti mac su 
cosa programmano? Ho forse sbagliato linguaggio? Non penso che sia un 
discorso legato alla differente diffusione dei due linguaggi anche 
perchè mi sembra che la comunità mac sia molto più attiva di quella 
win........ allora cos'ha il povero realbasic che non va? Perchè non 
interessa?
Grazie a chi mi vorrà rispondere

 non interessa?
Perche' (IMHO) se provi Cocoa ti diverti molto di piu' ;-)

ma cocoa che linguaggio usa?

 ma cocoa che linguaggio usa?
Quello che vuoi (entro certi limiti). La libreria è scritta in
ObjectiveC, quindi è un'ottima scelta.
Un'altra ottima scelta è lavorarci in Python.
Se no si può usare Java (ma è tristissimo... già lavorare in Java è
triste, avendo poi a disposizione tutti i meravigliosi linguaggi di cui
sopra...).
Puoi lavorarci in C o in C++ (ma non è particolarmente comodo, anzi).
Puoi lavorarci in Perl o Ruby, ma non lo ho mai fatto e non so come
venga.
-- 
L'idiozia trascende il mezzo con cui viene espressa.

 ma cocoa che linguaggio usa?
E' stato creato con in mente objective C

 Oppure in Python. Eventualmente Python + Cocoa.
Non conosco ancora molto Objective C (pare carino ma non adatto a
principianti), quindi Python + PyObjc (+cocoa) sarebbe anche il
consiglio mio.
Alex

 principianti)
Mah, io venivo dal Visual Basic (orrore!) e con ObjC ci ho imparato il C
:)
 - ∞

 consiglio mio.
Allora questa era la mia stessa impressione fino a quando non ho letto
il libro di Hillegass. In pratica lo presenta in una maniera talmente
semplice che davvero può essere affrontato da (quasi) tutti.
Certo, rimane un poco più complesso di Python (il linguaggio). Tuttavia
è "già pronto per essere usato con Cocoa". La documentazione è quasi
tutta per ObjC etc etc etc. 
Ovvero una persona con una mente abituata a risolvere problemi
incrociare informazioni etc etc non avrà grossi problemi a migrare i
concetti che apprende su Cocoa std to "pyCocoa".
Tuttavia temo che ad alcuni la cosa possa creare scompensi. Sto vedendo
cose da chiodi a riguardo.


 corrispettivo del VB.
Dovresti avere sul DVD di sistema l'ambiente di sviluppo Apple. Puoi
usarlo con diversi linguaggi, tutti IMHO meglio del Basic...
A me piace molto Applescript

 purpose mostra tutti i suoi limiti eh...
Non so, io ci faccio solo cazzatine :-) Però per un principiante mi pare
una buona scelta.
Non conosco Python o Perl ma per quel poco che conosco C++ o Java direi
che li può evitare come la peste :-)

 Usa AppleScript, o passa a Cocoa.
La seconda. E accendo
-- 
www.malcom-mac.com/blog
software development for Mac/Win
nemo - cocoa newsgroups reader for macintosh

 motivi per non imparare Java ].
Oops mi allacciavo ad altri rami del 3ad in cui si parlava dei linguaggi
supportati da Xcode.
In quanto a Java e similari per me un linguaggio è difficile quando
invece di scrivere "if a = 5 then" che lo capisci al volo scrivi
geroglifici. Sarà che non ho tanta voglia di sbattermi a interpretare
geroglifici :-)

 geroglifici 
if (a == 5){
}
non ci vedo nulla di geroglifico. Usare = sia per assegnamento che per
uguaglianza è davvero brutto. Usare lunghe locuzioni per fare un
assegnamento altrettanto.
Detto questo se consideri difficile un linguaggio per una cosa di cui
sopra...
Se ti può rincuorare in Python è
if a == 5:


 Oppure in Python. Eventualmente Python + Cocoa.
Ciao, prima di tutto ti ringrazio della risposta. Ho googlato un po' su 
python e mi sembra abbastanza 'user friendly', ma ci sono delle cose che 
non mi sono chiare:
1. cosa mi serve x creare una finestra con editfield, pulsanti e 
quant'altro e poi programmarci in python? (dai tutorial in rete vedo che 
si possono creare applicazioni a 'riga di comando'
2. una volta creato un programma posso compilarlo in modo che funzioni 
senza python? posso farlo anche per windows? (vorrei creare applicazioni 
con il mio mac e poi, eventualmente creare l'eseguibile che giri anche 
su win)
3. Cosa devo scaricare (mi pare che sia tutto opensource) per fare tutto 
ciò (ho un mac mini con tiger)
Ringrazio tutti per le eventuali risposte.
Mi scuso se stò virando verso l'OT!

 Oppure in Python. Eventualmente Python + Cocoa.
Io mi son trovato bene ad usare il Perl per alcuni script che mi
gestiscono i miei archivi, solo che da quanto ho capito è quasi
impossibile creare con facilità una GUI per script in Perl. L'unica
soluzione veloce per le GUI sarebbe il Python? Dovrei imparare un nuovo
linguaggio (ma è difficile?) e riconvertire i sorgenti in Perl...
Saluti ;)

 ciň (ho un mac mini con tiger)
pyobjc di certo.  Eventualmente Python2.4 e ammennicoli; forse un
ambiente GUI cross-platform se proprio devi.
Parti da 
http://undefined.org/python/
 e prendi Macpython 2.4.1 (il 2.4
produce codice piu` veloce, inoltre e` un pochino piu` ricco del 2.3),
TigerPython24fix, ed altre cose che ti servano (tipo, che so, flashticle
se vuoi leggere/scrivere file di Macromedia Flash); poi da
http://pythonmac.org/packages/
 l'istaller di pyobjc (e altre cose che ti
servano, che so, macfile per interfacciarti ai resourcefork dei file
mac) -- pyobjc comprende py2app, quindi sei a posto.
http://pyobjc.sourceforge.net/
 ha tutorial sull'uso di pyobjc, ecc ecc.
Alex

 e` affatto un passo semplice, anzi. 
Quindi potrebbe essere "deformazione professionale" il fatto che
AppleScript mi sembri tutto tranne che lineare? Boh! :)


 consiglio mio.
Io avevo intravisto un bell'ambiente visuale che in qualche modo mi ricorda 
delphi (forse l'unico rimpianto di win): Revolution-Dreamcard, ma non mi č 
per niente chiaro se "transcript" il linguaggio sottostante, sia un vero e 
proprio linguaggio di programmazione con tutte le sue cosine (ho in mente le 
liste di python...per dirne una).
Trovato pochino in rete su questo "transcript".
-- 
"Sono quel che sono"
Braccio di Ferro

 ciò (ho un mac mini con tiger)
Per Python è già installato sul Mac. A seconda di quello che vuoi fare
potresti avere bisogno di qualche libreria esterna (PyObjC per lavorare
in Cocoa, cosa che io consiglio).
Per wx hai già tutto. Idem Tk. Semmai dai un occhio a Tk subito. È
brutto da vedere, ma per buttare su qualcosa di rapido funziona.


 linguaggio (ma è difficile?) e riconvertire i sorgenti in Perl...
No. Python è oltremodo facile da imparare.


 insieme: AppleScript sulla GUI, altro per i task di basso livello.
Certamente. Il fatto è che in buona sostanza un "programmatore" anche
hobbysta imho è più probabile che si scontri con i problemi di
AppleScript.
La conoscenza di AppleScript è (per lo meno per me) relativamente
disgiunta dall'ambito di "programmazione", rientra piuttosto nel campo
di "usare al meglio il sistema". Non che con questo intendo che AS non è
programmare... spero si sia capito il mio contorto discorso.


 Da programmatore a programmatore: si`, lo e`.
Uhmmm perfetto ^_^ 


 Trovato pochino in rete su questo "transcript".
... un piccolo browser interno che ti fa accedere a tutto l'universo
della programmazione in transcript.
Gli archivi della lista di discussione sono su Google.
-- 
Per contattarmi:
http://formmailto.com/saltydog

 la'
linkato che per GTK mi fan ben sperare :D
 - ∞

 quasi esclusivamente nell'interazione con altre applicazioni
Se non contiamo il mal di testa che fa venire il debugger di AS Studio e
i NSReceiverCantHandleCommandError o quelchel'e' invece di messaggi di
errore intelleggibili, sempre in AS Studio...
 - ∞

 lato utente" ma anche oltre, se ne hai.
Diciamo che:
Quel sistema l'ho odiato. quello vecchio. adesso c'è il cosidetto
CampusNet. Lo odio ancora di più. Comunque funzionare funziona.
Fra le "figate": per iscriversi agli esami ci vuole una password (che io
non ho). Se la voglio devo andare a perdere una giornata in segreteria.
Risultato, 10 giorni prima dell'esame chiamo il docente per telefono.
Almeno il vecchio sistema chiedeva numero di matricola, nome e cognome.
E io personalmente non ho visto un abuso uno, quindi evidentemente
bastava.


 linkato che per GTK mi fan ben sperare :D
Ok... ma adesso...


 campo in cui AS rimane in ogni caso leader indiscusso :-)
No... anche semplicemente se bisogna trafficare con stringhe et similia
:)


 Non mi piace.. no no per niente ;) Mi da un'idea di sporco bohhhhhh
No. AppleScript è pulitissimo. Ma non devi vederlo come un general
purpose. Come dicevo altrove ci sono cose che un linguaggio di alto
livello normalmente modella benissimo, AppleScript invece no.
Altre cose invece che in AS sono pulitissime (anche se talvolta possono
parere relativamente diverse da quello che uno si aspetta).
Per esempio già il fatto che pur essendo un linguaggio "easy" abbia
gestione delle eccezioni (anche se diciamo odio il fatto che le
eccezioni non vanno a nome e non si sa chi lancia cosa), sia
completamente ad oggetti (anche se non sembra) ha un suo peso.


 No. Python è oltremodo facile da imparare.
Si`.  Ma Sembro dice che si puo` facilmenta inGUIare anche il Perl,
quindi se Marcellus preferisce puo` restar con quello.
Personalmente, ero un hotshot di perl ai tempi gloriosi della 4.* (anche
in 3.*, precedentemente, me la cavavo), poi ho scoperto Python e l'ho
trovato molto piu` adatto (infatti di Perl 5.* so il minimo
indispensabile per capire che non mi piace;-).
Ma tutti i gusti son gusti.  Evidentemente c'e` una categoria di persone
che PENSA in perl, come io penso in Python: a Google Python e` un
linguaggio ufficialmente adottato e supportato, perl no, e nonostante
questo un tot di sysadm (e qualche altro non-programmatore, come alcuni
esperti di reti) continua a farsi occasionali script "suoi personali" in
perl (lo so perche` poi tocca a me e alle persone che coordino
trasformare quegli script in Python per farne "software in produzione"
-- Google giudica che perl sia "difficile da manutenere" quindi un .pl
NON puo` essere passato all'empireo del "software in produzione", un .py
invece si`).
Nondimeno, Google ha supportato anche progetti Perl nell'ambito della
"Summer of Code".  E Larry Wall, Allison Randal, Damian Conway e Randal
Schwartz sono tutti dei simpaticoni (ormai li conosco bene, per
frequenti incontri a varie conferenze e workshop "open source"!), quindi
suggerisco vino e tarallucci, eh?-)
Alex

 Progammato in Perl con interfacccia in AppleScript Studio: 1 giorno.
Però, non male (peccato che non ci siano i sorgenti AS). Una info:
possiedo MacOS X Panther e di default ho lo "Script Editor". Quello che
intendi tu è tutt'altra cosa? E' incluso in XCode?
Ieri sera ho provato ad iniziare a convertire gli script Perl in Python,
ma è un lavoraccio, in particolare mi sono scontrato con molti
"Indentation error" (a tal proposito volevo chiedervi se BBEdit è in
grado di indentare automaticamente il codice dei sorgenti Python) e
altri problemi causati dalla non perfetta conoscenza del Python.
Grazie e saluti ;)

 Gli archivi della lista di discussione sono su Google.
Appena ho un po' di tempo ci guardo.
Ma tu lo usi ? Come ti trovi ?


 altri problemi causati dalla non perfetta conoscenza del Python.
1) se lavori in Python raccomandati assolutamente che ci siano o tutti
tab o tutti spazi (di gran lunga meglio tutti spazi). Di a BBEdit di
convertire i tab in spazi.
Buona parte degli indentation error sono dovuti a quello.
2) per indentare automaticamente chiaramente non si puň fare (a seconda
di quello che intendi). Se intendi dargli un sorgente comunque
formattato e formattarlo, non puoi. Mi spiego
if a:
  b
  c
č tanto valido quanto
if a:
  b
c
solo che fanno due cose diverse e l'editor non saprebbe quale volevi tu.
Io personalmente per lavorare con Python preferisco leggermente TextMate
perchč č un po' piů furbino ad indentare, ma BBEdit funziona comunque
benissimo.


 stato tra i primi a trarne vantaggio (ad esssere portato su Parrot).
L'ultima cosa che ho sentito in merito e` (da un tizio che si chiama Sam
Ruby: chi altri piu` adatto per seguire un porting di Python alla VM di
Perl?!-) che in realta` "python su parrot" e` indietro come i gamberi
per tutta una serie di mismatch semantici fra il linguaggio Python e la
VM; chi si occupava in precedenza del port era ossessionato dalle
prestazioni e non aveva apparentemente notato questi problemi profondi.
Questo era mesi fa (non ricordo bene se a Oscon in Agosto a Portland, o
a Euro Oscon in Ottobre ad Amsterdam), spero che il progresso in merito
sia ripreso.
Alex

 dividersi e condividere il byte-code mi sembra un gran bel passo avanti.
Potrebbe essere effettivamente interessante. Al momento il più grosso
problema con i linguaggi interpretati è che in sostanza non hanno
librerie portabili fra di loro.
Ovvero se scrivo una libreria in Python, fondamentalmente tu non potrai
usarla in Perl. Mentre se la scrivo in C/C++ e faccio un wrapper la
potrò usare in Python e tu (se ti fai il wrapper) immagino potrai usarla
in Perl.
Certo, anche avere compatibilità di bytecode potrebbe portare qualche
problema, ma forse restringendosi ad un minimo comun denominatore si
potrebbe riuscire ad avere una certa compatibilità.


 Ma tu lo usi ? Come ti trovi ?
L'ho usato parecchio finché è stato gratuito; poi l'ho valutato in vista
di una utilizzazione prevalente di crossplatform multimedia (limitante
per uno strumento di sviluppo così completo) ma per carenza di lavori
non sono mai stato spinto decisamente all'acquisto. Ora è un po' che
sono preso da altri settori della mia attività per cui ci ho perso un
po' la mano.
Ma devo dire che mi ci trovavo bene, veramente bene. Per uno che
sviluppa interfacce ed edutainment, e poi saltuariamente come me, non ho
mai provato di meglio.


 consiglio mio.
Alex, con la tua esperienca C/C++ mangerai pane e ObjC in quattro e
quattr'otto. 
Il discorso sulla complessità è il medesimo che conosci bene sui
precedenti linguaggi. Li si apprende con relativa facilità in pochissimo
tempo. Poi serve una lunga esperienza per sfruttarli pienamente e
affinare un metodo di modellazione coerente ed efficace.
ObjC non è molto diverso. Secondo me ha una curva di apprendimento
iniziale appena appena più ripida di quella del C++ (soprattutto per chi
viene da anni di pratica con questo linguaggio e fatica a digerire la
totale libertà -  anche di errore - che il nostro offre), ma nel
complesso l'intero percorso formativo è più bilanciato.
La vera complessità viene dai framework. Il più esperto programmatore
C++ ha un fremito di preoccupazione la prima volta che si trova davanti
.NET perchè sa che in dieci anni di lavoro costante non riuscirà mai a
capire se quel che sviluppa è percorribile in altri modi più efficienti,
magari sfruttando package di classi che gli sono ancora poco noti o
sconosicuti. Anche da questo punto di vista, ma è l'impressione
personale di chi viene anche dalla programmazione su NeXT, Cocoa ha una
maggiore pulizia generale e una più coerente strutturazione
(specialmente adesso che la famiglia è giunta al completamento e non si
è costretti a saltellare tra i vecchi toolbox e il nuovo framework).
Ad ogni modo, se l'obiettivo è quello di sviluppare applicazioni
specifiche per Mac e non solo applicazioni che girino sul Mac, Cocoa lo
deve imparare per forza il nostro amico. In tal caso, ObjC o Python fa
poca differenza, visto che i linguaggi in sè non presentano particolari
difficoltà... forse si potrebbe questionare sull'ObjC in relazione alla
portabilità del codice verso altre piattaforme. Anche l'accoppiata C++ -
Cocoa comunque non va dimenticata. Si sposano meno, ma non fanno danni.
Marco

 diversi linguaggi (ma non un monolite), e non e` poco.
Beh, questo si puo` risolvere anche con altre macchine virtuali, o
interpreti che dir si voglia; ad esempio, Jython e` Python che gira su
JVM, IronPython e` Python che gira su dotNET (o Mono), e pypy ha un
compilatore (un po' sperimentale, a dire il vero) da Python a LLVM, la
Low-Level Virtual Machine.  Ma nessuna di queste VM e` particolarmente
ottimizzata per linguaggi dinamici (come Perl, Ruby, o Python), quindi
sicuramente c'e` spazio per una VM che invece lo sia.
Alex

 Cocoa comunque non va dimenticata. Si sposano meno, ma non fanno danni.
Se vuoi programmare qualcosa specifico per Mac sono d'accordo che merita
imparare Cocoa piuttosto che cercare di arrangiarsi con toolkit
cross-platform che potranno portarti al 99% delle potenzialita` della
piattaforma, ma mai al 100% pulito.  In questi casi, della portabilita`
t'importa {strumento in metallo, dentato, atto a tagliare legni o
metalli}.  I vantaggi di Python rispetto a ObjC sono del tipo, non hai
bisogno di preoccuparti di retain e release (fa tutto da solo), sintassi
pulita, semantica di livello piu` alto, ecc.  Sospetto che, mentre i
vantaggi di Python rispetto a C++ o Java tipicamente portano a una
riduzione di un fattore 4-5 nella quantita` di codice da produrre (forse
qualcosa di meno rispetto a Java 1.5 con generic, non l'ho ancora
provato sul serio), per app Cocoa rispetto a ObjC la diff sia piu`
ridotta, forse solo un fattore 2-3, pero` anche dimezzare il codice non
e` proprio un vantaggio da buttar via.
Cio` detto, tutta la doc Cocoa e` per ObjC, quindi bisogna almeno
saperlo *leggere*, come, che so, per usare Jython (Python per JVM)
bisogna saper leggere Java (perche` tutte le doc sono per Java), per
usare IronPython (Python per .NET) bisogna saper leggere C# (perche`
tutte le doc sono per C#), e via elencando.  Quindi, meglio imparare un
pochino di ObjC, se interessa sviluppare in questo ambito specifico.
Alex

 difficoltà...
Ma Python è più coltellino svizzero. Se si deve fare un'applicazione
scientifica, uno script di sistema, un'applicazione web, può muoversi
con lo stesso linguaggio (e la stessa filosofia di progettazione per gli
aspetti language dependent).


 Cocoa comunque non va dimenticata. Si sposano meno, ma non fanno danni.
L'accoppiata C++/ObjC, a meno che abbiano gia' incluso ObjC++ nella
distribuzione ufficiale di gcc, e' disponibile solo su OS X ed e' stata
reintrodotta da qualche anno.
Su GNUstep, ad esempio, bisogna crearsi a mano un wrapper con tutto quello
che ne consegue.
Ciao
Mirko


Personalmente ci ho lavorato poco, ma sono riuscito senza
particolari problemi a scrivere un programma che funzionante
senza modifiche su Linux e Mac (e anche su Windows, ma non 
ne posso rendere testimonianza diretta avendolo fatto 
provare ad un'altra persona).
ciao,
S.
-- 
Stefano Rodighiero      |  
http://larsen.perlmonk.org/blog
mailto:
lar...@perl.it
   |  Italian Perl Mongers: 
http://www.perl.it