Newsgroup: it.comp.macintosh
Titolo: XCode: tanto per capire

Lo strumento "ufficiale" per sviluppare applicazioni professionali in
ambiente mac e' xcode?
O meglio... e' l'XCode il visual studio del mondo mac?
ave
-- 
[Billy]
http://www.impressionistabili.it/

 O meglio... e' l'XCode il visual studio del mondo mac?
xcode (modellazione + coding), e interface builder (design interfaccia*)
*in realta' IB e' piu' di un semplice designer di interfacce ma per
comprenderlo dovresti capire come le applicazioni cocoa "serializzano" gli
oggetti.
-- 
Em Portugal se conservará sempre o Dogma da Fé ecc.

 O meglio... e' l'XCode il visual studio del mondo mac?
Sì.
Se ti serve sapere altro spara pure.
[f/up iapox]
-- 
 - ∞
-- 
http://infinite-labs.net

 ambiente mac e' xcode?
Uno dei tanti.
-- 
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.

 Uno dei tanti.
Visto che CodeWarrior non c'è più, l'unica alternativa è gcc +
texteditor.


 texteditor.
Errata corrige: per applicazioni *native*. (Non so se Eclipse CDT va su
Mac...)


 texteditor.
Per nulla. Python + IB fa la stessa cosa (con meno tempo).
Idem Ruby + IB.
Poi volendo c'è sempre RB.


 Poi volendo c'è sempre RB.
Vero, non me lo ricordavo.


 Uno dei tanti.
No, gli altri non sono "ufficiali", Buona Pasqua. :-)
-- 
Per contattarmi:
http://formmailto.com/saltydog

 No, gli altri non sono "ufficiali", Buona Pasqua. :-)
Più ufficiali che distribuiti con OS X e installati di default...


 Vero, non me lo ricordavo.
E c'è anche un perchè... :P


 Più ufficiali che distribuiti con OS X e installati di default...
Installati di default, no.


 Installati di default, no.
Python + wx si. :)






Non comprendo.


 Non comprendo.
Xcode č il tool made in Apple, e chiaramente Apple lo propone e lo
sponsorizza piů di tutte le altre possibili soluzioni di sviluppo.
Solo molto recentemente Apple sta aprendo all'integrazione di soluzioni
non native, ma ancora queste non appaiono come la proposta ufficiale di
Apple; questo lo si desume anche abbastanza facilmente dalle pagine del
sito Apple dedicate agli sviluppatori, il link che ho fornito ne č un
esempio.
Penso che Billy Farina sappia dell'esistenza, almeno vagamente, di
qualche ambiente di sviluppo adatto alla nostra piattaforma, ma che un
link come quello risponda con maggiore precisione alla sua domanda.


 No, gli altri non sono "ufficiali", Buona Pasqua. :-)
Sotto xcode c'e' gcc.
gcc da sempe e' l'alternativa freeware degli sviluppatori.
E' questo che non capisco, ho utilizzato per anni c++ builder e ora
visual studio c#... sviluppare applicazioni professionali significa
anche investire e sganciare qualche soldo per utilizzare tools avanzati.
Questo mi manca in mac os x. La possibilita' di spedere qualche
centinaio di euro per poter aver qualcosa di piu' di xcode.
Non e' polemica....  ma con xcode (oltre ad essere costretto ad
utilizzare object C che non conosco e quindi trovo ostico) mi sembra di
essere tornato indietro di qualche anno.
ciao.... buona pasquetta.. ormai.
;)
-- 
[Billy]
http://www.impressionistabili.it/

 tools avanzati
Non so se si possa parlare di tools avanzati ma esistono anche i
compilatori Intel per Mac OS X.
Questo e' il C++:
http://www.intel.com/cd/software/products/asmo-na/eng/266992.htm
Poi dovrebbe esserci anche il Fortran e poi boh?
-- 
Ciao da Francesco B.

 centinaio di euro per poter aver qualcosa di piu' di xcode.
Capisco sia sconcertante ma non capisco perché ti manchi.
Se proprio vuoi buttar soldi, er, spendere danaro, puoi sempre comprare
i compilatori PowerPC di IBM e x86 di Intel.


 essere tornato indietro di qualche anno.
Nessuno ti obbliga ad usarlo eh :-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

 anche investire e sganciare qualche soldo
Ma il tool ufficiale è gratuito, anche se professionale. Se proprio vuoi
spendere dei soldi però, le alternative non ufficiali non mancano, e ce
ne sono perfino a pagamento.
Io stesso ho pagato una discreta cifra per avere il tool commerciale che
ritengo più adatto a me e alle mie esigenze.


 esempio.
Č un esempio di quello che io dico: per esempio proprio da lģ c'č un
puntatore verso lo sviluppo in PyObjectiveC e Python.


 essere tornato indietro di qualche anno.
Pare strano che un 'programmatore professionista' trovi così difficile
imparare Objective C. Come linguaggio è parecchio facile da usare,
specie rispetto a soluzioni molto più ingessate che sono la fuori.
Poi per non parlarti del fatto che puoi chiamare Cocoa da Python o da
Ruby. Certo, potresti venirmi a dire che trovi troppo difficile anche
quello. 


 essere tornato indietro di qualche anno.
Pare strano che un 'programmatore professionista' trovi così difficile
imparare Objective C. Come linguaggio è parecchio facile da usare,
specie rispetto a soluzioni molto più ingessate che sono la fuori.
Poi per non parlarti del fatto che puoi chiamare Cocoa da Python o da
Ruby. Certo, potresti venirmi a dire che trovi troppo difficile anche
quello. 
-- 


 essere tornato indietro di qualche anno.
Pare strano che un 'programmatore professionista' trovi così difficile
imparare Objective C. Come linguaggio è parecchio facile da usare,
specie rispetto a soluzioni molto più ingessate che sono la fuori.
Poi per non parlarti del fatto che puoi chiamare Cocoa da Python o da
Ruby. Certo, potresti venirmi a dire che trovi troppo difficile anche
quello. 
Per non dire poi del fatto che ObjectiveC è parecchio più carino di C#.
Per non parlare poi di Python e di Ruby.


 zona un pezzo grosso di una di esse, se gli va di intervenire). 
Se dici Google, in effetti il business e` basato su tools open source (e
infatti cerchiamo di supportare l'open source in svariati modi, dal
Summer Of Code, a 
code.google.com
, a tanti ma tanti dipendenti che
rilasciano e mantengono codice open source di varia natura).
Per chi programma in C o in C++, se i soldi non sono un problema, puo`
meritare vedere come girano i compilatori intel; io personalmente ho
lasciato perdere quando ho saputo che detti compilatori non supportano
(per ora) Objective C (si possono fare librerie in C o C++, compilarle
con questi compilatori, e chiamarle da codice ObjC, ma mi pare un poco
complicato; se e quando intel decidera` di aggiungere il supporto
diretto per Objective C magari ci daro` un'altra occhiata).
A proposito, non l'ho provato, ma Giovanni Bajo ha rilasciato un
packaging per Windows di gcc 4.1 che, dice, genera codice migliore di
Visual Studio 2003 (e altrettanto compatibile con Python; VS 2005 per
ora non e` compatibile con Python, o almeno non in modi facili).  Se
questo e` vero, sarebbe una bella ironia per chi invece vorrebbe pagare
centinaia di dollari per avere "di meglio di gcc":-)
Alex

 puntatore verso lo sviluppo in Py
Dove? Non lo vedo... ;-PpPp
A parte gli scherzi, sembra quindi un buon punto di partenza per uno
sviluppatore che voglia chiarirsi le idee sulla situazione, non trovi?


Tre volte per la foga ?

 E quindi?
Non ci siamo capiti (senza dubbio per colpa mia). Pazienza. Grazie dello
sforzo. ciao.
-- 
[Billy]
http://www.impressionistabili.it/

 ne sono perfino a pagamento.
Quali? 
ciao e grazie.
-- 
[Billy]
http://www.impressionistabili.it/

 
http://www.intel.com/cd/software/products/asmo-na/eng/266992.htm
Ottima segnalazione. Provo a vedere se vale i soldi che costa e poi ci
penso.
ciao e grazie
-- 
[Billy]
http://www.impressionistabili.it/

 Quali?
RealBasic, ad esempio, o Revolution, ma credo ce ne siano anche per i
linguaggi con cui hai più confidenza.


 Nessuno ti obbliga ad usarlo eh
no... ma qualcuno mi obbliga a svilupparci sopra qualcosa..... ma con
che?
Non nego di aver fato dei tentativi con obj c e xcode ma non riesco ad
abituarmi.
;)


 risparmiare tempo in sviluppo non e' un problema.... anzi.
Quindi un *compilatore* in cosa ti velocizza lo sviluppo?
Il compilatore Intel produce codice più ottimizzato, è vero. 
Non ho bench per vedere se sia più o meno veloce a compilare, ma direi
che i grossi risparmi di tempo li hai in altra maniera, piuttosto che
cambiando compilatore.


 sviluppatore che voglia chiarirsi le idee sulla situazione, non trovi?
Si. Senza dubbio, anchhe se potrebbe essere un filino dispersivo.


 Tre volte per la foga ?
No: sono tre supersede.


 sforzo. ciao.
Direi che sei tu che non hai capito il mio post (tanto è vero che non
hai risposto a nulla). 
Ti ho indicato diversi sistemi per velocizzare (e più di quanto tu possa
sperare, è verosimile ipotizzare un x4 rispetto a C++ e un x2-x3
rispetto a Java o analogo) lo sviluppo. 
Poi il fatto che anche questi tool siano non solo gratuiti ma anche
liberi, è un notevole plus.
Tipicamente per quanto un IDE ti faccia risparmiare tempo a fare cose
ripetitive, un tool che ti permetta di *metaprogrammare* (e quindi di
*non* scriverle quelle cose) ti fa risparmiare ancora più tempo.


 cambiando compilatore.
Contando che se non si usa GCC non so se vada la compilazione
distribuita di Xcode (distcc).


 distribuita di Xcode (distcc).
Bella domanda. Ma non ho troppa voglia di cercare la risposta :)


 Per non parlare poi di Python e di Ruby.
Ti ho gia' risposto.


 difficolta'..
Se hai dei problemi parlane pure che siamo qui a dare una mano ;)


 per compilarlo con C++ invece che C come linguaggio)
Come linguaggio base. Objective-C è un superset esatto di C, con .mm
invece viene usato il C++ come base da estendere con le estensioni di
Objective-C (consentendo così l'uso di codice C++).


 difficolta'..
Come ti dicevo, senza scendere in questione di gusti, ObjectiveC è un
linguaggio che si intromette molto poco fra il programmatore e il suo
obiettivo. Questo è uno dei motivi per cui mi piace.
Poi chiaramente finchè la teniamo sul piano dei gusti, la discussione
muore subito. 


 Purtroppo va di moda :(
Oddio, l'ALTRA alternativa per implementare i bottoncini "Annulla" è far
girare il run loop alternandolo al lavoro da fare. Non che sia
impossibile, ma è scomodo. >_<


 impossibile, ma è scomodo. >_<
Mi sa che non ci stiamo capendo :)
Ci sono chiaramente tantissimi modi di strutturare un'applicazione.
Cambiano anche entro certi livelli a seconda che l'applicazione sia
desktop o server.
Tipicamente in entrambi i casi soluzioni asincrone funzionano parecchio
bene. Nota che nella programmazione Cocoa (a differenza che in quella
Java) è cosa nota che quando è possibile modellizzare le cose tramite
NSNotification sia meglio che farlo usando dei thread.
I thread in questo caso servono solo ad eventualmente staccare un lavoro
molto lungo. Ma finchè non c'è condivisione di stato (e quindi non siamo
propriamente in paradigma stateless alla Haskell-Erlang, ma solo ad una
approssimazione di esso), le cose funzionano abbastanza bene.
Ma si possono usare in tale caso spesso anche i processi. 
In generale i thread sono una notevole complicazione e spesso non
necessaria. Funzionano bene a bassissimo livello, ma salendo il gioco
comincia a non valere la candela. 


 ;)
Dipende molto  anche dal tipo di applicazione che devi sviluppare,
io mi sono trovato benissimo per applicazioni che interagiscono con in
db di mysql. L'objective C non l'ho trovato particolarmente ostico,
anzi. Comunque puoi sempre far ricorso al c e al c++. Comunque questa è
una posizione molto personale, preferisco di gran lunga xcode di Visual
.net Studio.
Ciao

 moltissimo).
Anche qui quoto. Era quello che cercavo di dire prima.


).


 Idem Ruby + IB.
Curiosità: java+IB?

 Curiosità: java+IB?
1. potere puoi
2. mentre i bridge per Python e Ruby saranno addirittura integrati in
MacOS X Leopard (per ora li installi a parte), quello per Java mi pare
essere deprecato (a meno che non abbiano ricambiato le cose)
3. hai una soluzione che ti allunga parecchio i tempi di sviluppo
rispetto ad ObjectiveC (per non parlare rispetto a Python o Ruby)
4. Se posso evitare Java lo faccio. 
Comunque ribadisco, potere puoi. Ma non te lo consiglio affatto.


).
È un ambito abbastanza peculiare. Anche quando si programma dalle parti
del kernel è normale lavorare con thread (poi a seconda di come è fatto
il kernel stesso eh). 
Ma in generale quando ci si alza di livello, è opportuno usare tecniche
di livello più alto. Poi nemmeno salendo troppo di livello. Già
lavorando in C spesso vale la pena di lavorare a poll invece che a
threads.


 Comunque ribadisco, potere puoi. Ma non te lo consiglio affatto.
Concordo

 E procedono ad obliterarlo sempre più di brutto.
Quindi riconfermo il suddetto. 'Sconsiglio'.
D'altra parte, oltre che per attrarre sviluppatori Java, con tutta la
bella roba che è ObjectiveC (e ora Ruby e Python), proprio non vedo il
perchè dietro a Java [ specie con il coma di WebObjects ].


 perchè dietro a Java [ specie con il coma di WebObjects ].
Scorrendo le descrizioni delle sessioni che si terranno alla
WWDC '07, si rimane comunque colpiti dai davvero tanti riferimenti
quest'anno ad AJAX e al Web 2.0, proprio in relazione a Java e a WO.
Altro che Leopard: sembrerebbe quasi che l'interesse maggiore per
Apple sia ormai di reclutare sviluppatori per l'iPhone e le nuove
altre appliances: probabilmente assisteremo all'annuncio di una
maggior apertura di queste nuove piattaforme, a meno che non
decidano di puntare tutto su widget in JavaScript... :(

 ripaga sul medio-lungo periodo rispetto al breve.
Si... valuto anche quella. Solitamente paga dopo... hai ragione.
Comunque questa discussione mi ha rinvigorito... riapro e mi riaggiorno
con il sito di macocoa e presto vi so dire.
;)
-- 
[Billy]
http://www.impressionistabili.it/

 muore subito.
D'accordo. I gusti a volte sono inquinati dalle abitudini... se io
programmo in una maniera da anni difficilmente convengo con chi fa il
contrario. Ma sono ragionevole e "aperto". Sto rivalutando la cosa dopo
questa discussione.
Capisco prima di tutto che se si vuole realizzare applicazioni
performanti e potenti si deve usare l'obj-C... inutile intestardirsi con
il cpp solo perche' si conosce solo quello..... poi per apple le carbon
sono obsolete ormai.
Non concordo sul fatto che il cpp "e' uguale all'obj-C"... forse lo e'
concettualmente ma la sintassi dell'obj fa bestemmiare il programmatore
cpp... questo non lo puoi negare.
ciao e a presto
-- 
[Billy]
http://www.impressionistabili.it/

 mi riaggiorno con il sito di macocoa
Macocoa ignora completamente i Cocoa Bindings introdotti con
Panther, Core Data introdotto con Tiger e tante altre cosucce
rifinite da Apple rispetto ai tempi arcani del modello MVC
dell'OPENSTEP: rischi di farti un'idea antiquata.

 concettualmente
Concettualmente l'Objective-C è molto vicino allo Smalltalk,
solo che è maledettamente più logorroico e, ad esempio, anche
solo per accedere agli array, invece di uno sbrigativo "at:",
costringe a dilungarsi in un "objectAtIndex:".

 cpp... questo non lo puoi negare.
Concettualmente sono linguaggi diversi. Tipicamente ObjC è un linguaggio
dinamico, C++ no. Quello che volevamo farti capire è che la transizione
C++ -> ObjC è complessivamente facile. 
Magari non userai al meglio ObjC pensando in C++, ma comunque non hai
*tantissima* roba nuova da imparare. Anzi.
