Keine Kenntnisse mit Programmieren - Wie Lernen?

Das verstehe ich bis heute nicht, muss irgendwas psychologisches sein. {, ->, ; und ( sind OK, aber [ und : sind es nicht?

OK, vielleicht habe ich zuviel Lisp programmiert ;)

Alex

ich glaube auch nicht das es da wirklich was zu verstehen gibt. Sprich logische Gründe können das nicht sein. Das ist eine schnöde Frage der Konditionierung. Das eine hilft meinem Lesefluß, das andere hemmt ihn. Offenbar stehe ich damit ja nicht ganz alleine da, also gibt es noch mehr Konditionierte :)
 
ich glaube auch nicht das es da wirklich was zu verstehen gibt. Sprich logische Gründe können das nicht sein. Das ist eine schnöde Frage der Konditionierung. Das eine hilft meinem Lesefluß, das andere hemmt ihn. Offenbar stehe ich damit ja nicht ganz alleine da, also gibt es noch mehr Konditionierte :)

Doch, es gibt logische Gründe.

Propertys gestalten die veröffentlichte Information deutlich besser.

a) Es werden keine Ivars publiziert. Wieso auch? Was geht das den Nutzer der Klasse an, zumal er in der Regel ohnehin nicht darauf zugreifen kann. Das hat mich an C-Sprachen schon immer gestört.

b) Dafür publiziert es die wichtige Informationen zur Kapselung (retain, copy ).

Das alles hat aber nichts mit der Dot-Syntax zu tun. Diese ist bei Propertys wie wie expliziten Accessoren möglich. Und sie ist auch gut, da sie, wie in dem verlinkten Artikel von Alex gezeigt, eine andere Semantik hat.

Ich wurde auch auf Assembler konditioniert. Veraltete Kondtionierungen sollte man als eigenen Fehler begreifen und nicht moderneren Technologien vorwerfen.
 
Doooch, von mir :)

Es ist nicht allzuviel Unterschied; ich würde es mal so sagen: da keine Mehrfachvererbung, etwas einfachere Handhabung von Konstruktoren und dem Fehlen von Destruktoren halte ich Objective - C für etwas einfacher. Dazu gibt es, auch Dank dem Erfolg des iPhone SDK, eine Fülle von recht aktuellen Büchern zum Thema, welche sich an Einsteiger richten. Dabei wird oft nicht nur auf die Sprache selbst, sondern auch auf das eng verbundene Cocoa - Framework eingegangen.
Folgende Empfehlungen:
1: Learn C on the Mac (C als Einstieg für C++/Objective - C scheint mir sinnvoll. Das Buch behandelt C auf Mac, i.e. mit XCode. Von der IDE abgesehen sind die Beispiele plattformneutral).
2. Objective-C und Cocoa (mein Favorit für den direkten Einstieg. Band 2 ist noch nicht erschienen, leider, für Einsteiger aber ohnehin nicht nötig).
Jetzt schon. :)

3. Learn Objective - C on the Mac
4. Der Klassiker "Hillegass". Ich bevorzuge zwar No. 2 in der Liste, aber das Buch von A. Hillegass gilt als Standardwerk, weswegen es erwähnt sein sollte. Generell findest Du zB auf Amazon jede Menge Bücher mit Rezensionen....
 
Hallo zusammen,

kann mir vielleicht hier jemand auch mit der englischen Literatur zum Thema weiterhelfen, würde auch gerne ins Programmieren einsteigen. Gibts es irgendwelche Bücher die in der Zwischenzeit veröffentlicht wurden, die ihr empfehlen könnt? Sprache ist echt egal, trotzdem englisch bevorzugt.

Gruß Felix
 
IMHO nur neue Auflagen. Die Bücher selbst sind noch die alten Empfehlungen.
 
  • Gefällt mir
Reaktionen: areito
IMHO? Entschuldigung für die dummer Frage, aber was soll das bedeuten?
 
In My Humble Opinion
 
  • Gefällt mir
Reaktionen: Coldplayer und _ebm_
Okay danke!
 
Moin zusammen.
Ich würde sehr gerne in die Mac- / iOS-Programmierung einsteigen.

Dazu benötige ich nach meinen bisherigen Rechergen Objective C und Cocoa?

Erfahrungen habe ich in C und Visual Basic unter Windows, auch wenn nicht mehr wirklich viel davon da ist die Grundstruktur ist es.

Was würdet ihr einem Neueinsteiger also empfehlen? Direkt Bücher für XXX€ kaufen oder gibt es gute/brauchbare Nachschlagewerke online?
 
Ich würde schon direkt Bücher kaufen. Aber erst etwas später, vielleicht. Leider gibt es noch nichts/wenig für die aktuellsten Versionen (Xcode/iOS).

Kleiner Tip bzw. Vorschlag: zieh Dir für den Anfang die Podcasts auf iTunes U rein. Suche nach CS193P, es handelt sich um eine ausgezeichnete Einführung der Stanford University - bei der auch Apple Mitarbeiter als Gastlektoren auftreten. Die letzte Version (Fall 2010, Paul Hegarty) fand ich die bisher beste. Es gibt auf der Webseite zur Vorlesung auch die Präsentationen und Beispielprojekte. Übrigens: sehr kurzweilig. Die Vorlesungen machen tatsächlich auch Spass.

Danach bist Du evtl. bereit für die Apple - Dokumentation, die recht gut ist, aber eben kein Tutorial. So würde ich das (heute) machen.

Alles kostenfrei, übrigens.

Viel Spass
 
Was würdet ihr einem Neueinsteiger also empfehlen? Direkt Bücher für XXX€ kaufen oder gibt es gute/brauchbare Nachschlagewerke online?

Ich kann dir mittlerweile Xcode von Null auf Hundert empfehlen. Sehr nützliche und hilfreiche Podcasts, die im iTunes Store zum Download zur Verfügung stehen. Die geben eignetlich sehr hilfreiche Tips und auch Bücherempfehlungen.
 
Ok danke euch beiden, werde ich mir morgen mal anschauen bzw. anhören.

Wenn von Xcode gesprochen wird, ist ja die Programmierumgebung un Compiler, bezieht das dann immer Objective C und Cocoa mit ein?
 
Ja - und mehr. Mit Xcode kannst auch C, Objektive-C++ oder "gemischt" programmieren. Das Cocoa - Framework ist recht stark mit Objektive-C verbunden, ist also auch bei Xcode mit dabei
 
naja, die Natürlichsprachlichkeit geht *mir* eben durch die eckigen Klammern verloren. Für mich erschweren sie den Lesefluß. vermutlich bin ich auch durch die alten C Sprachen vorbelastet. Denn für mich ist sowas wie:

Lisa->throw(new Ball(red),tom);

lesbarer als [Lisa throw:[Ball withColor:red] to:Tom]

weil eben besser strukturiert als die natürliche Sprache! Bis ich da die eckigen Klammern und :-Segmente richtig aufgeteilt habe, bin ich in der anderen Syntax längst weiter.
Das ist aber ganz sicher subjektiv! Der OO-Ansatz von Objective-C ist klar besser und macht die Syntax-Problemchen mehr als wett. Das Problem nicht zu wissen welcher Parameter was ist, beheben entweder die IDEs durch das einblenden der Doku sehr gut oder man behilft sich eben mit dem Build-Pattern und hat dann auch das benannte setzen von Attributen im Konstruktor.

Wer meint mit Mehrfachvererbung "mehr" zu haben, der irrt. Damit macht man sich relationale Strukturen kaputt(Symetrie und Kommuntativität leiden). Was immer dann auftritt wenn man Listen von mehrfach abgelittenen Objekten hat oder compare,deepcopy oder equals-Methoden auf solchen Objekten realisiert. Vererbung war das große Credo als OO noch neu war. Das Vererbung eine Lösung für Sonderfälle ist und das OO viel besser damit genutzt wird das ein Objekt ein Interface implementiert ist heute viel wichtiger ( in Objective-C wie in Java wie in ...). Es macht also Sinn das Objective-C sich da bewußt selbst beschränkt und auch auf den Mechanismus der Interfaces zurückgreift.

Ich würde sogar behaupten wollen das ein Objective-C ohne diese kleine Hemnis der eckigen Klammern/Doppelpunkt Syntax aufgrund seiner sonstigen großen Vorteile C++ längst an die Wand gespielt hätte. Wer von den üblichen C-Sprachen kommt ( C,C++,Java) der ist mit Objective-C einfach gehemmt und genau das reduziert die Akzeptanz fürchte ich. Umgekehrt wer mit Obejctive-C groß geworden ist, der wird es als besonders natürlich und lesbar empfinden und nicht verstehen warum andere damit schwerer klar kommen. Ich könnte wetten das man mit ein paar kleinen Änderungen bezüglich der Atrribute und Klammerei der Sprache eine deutlich höhre Akzeptanz verleihen könnte. Ein Versuch wäre das wert.

Wieso ist das besser strukturiert?
Das beinhaltet einen Vergleich. Bei einem Vergleich geht man am besten so vor, dass man eine gemeinsame, möglichst enge Obergruppe bildet die Unterschiede aufzählt und dann argumentiert, wieso die Unterschiede zu der Behauptung führen.

Da ich deine Behauptung nicht nachvollziehen kann, bitte ich dich, das für mich zu machen. Gerne auch anhand eines anderen Beispieles:
Code:
lisa->getParent()->say( "something" );
[[lisa parent] say:@"something"];
Ich verstehe hier nämlich nicht, wieso ich bei "Funktionssyntax" die Klammern kennen muss. Vielleicht sollte ich sie hinzufügen:
Code:
(lisa->getParent())->say( "something" );
[[lisa parent] say:@"something"];
 
Wieso ist das besser strukturiert?

ich hatte in den Sätzen davor so oft *für mich* geschrieben, dass ich es dort dann irgendwann weggelassan hab. Mein Beitrag ist bitte nicht allgemeingültig, er gilt nur für mich. *Ich* bekomme bei der Objective-C Syntax einfach keinen Lesefluß hin. Das ist emotional, man sperrt sich automatisch gegen etwas was einem Mühe macht es zu lesen. Die eckigen Klammern stören einfach meinen Lesefluß. Ich habe im letzten Urlaub Scala gelernt nebenbei. Da fallen viele Klammern weg, Semikola ebenfalls und trotzdem/gerade drum ist die Sprache für *mich* lesbarer. Viele sehen das anders und beschweren sich über Scala das den Puristen nicht funktional genug und den OOlern "zu komplex" gilt.

Du versuchst da etwas rational zu verstehen, was keinen rationalen Grund hat. Ich müßte mir nen Präprozessor schreiben der mir die eckigen Klammern zu meinem Sourcecode hinzufügt und der statt +/- vor Methoden Schlüsselworte ( wie static o.Ä.) verwendet und die Sprache wer mir angenehmer. Rational ist das nicht.
 
"Für mich" war mir klar. Ich wollte auch wissen, warum es für dich so ist.

Allerdings hattest du etwas davon geschrieben, dass es besser strukturiert sei. Und das hatte ich jetzt nicht mit Emotionen in Verbindung gebracht, ob nun für dich oder für alle.
 
Wie geschrieben, es müßte heißen "für mich liest es sich strukturierter", das war einfach lapidar formuliert. So wie es da steht ist es einfach nicht vollständig.

Das mit dem Umgewöhnen habe ich übrigens durchaus probiert. Als ITler ist man es ja gewohnt Denkmodelle und Schreibweisen über Bord zu werfen - trotzdem bleiben dabei nat. ganz persönliche Präferenzen ( auch wider die Vernunft). Ich habe es mit Objective-C und dem Hillegass auch lange probiert. Die Idee hinter dem OO Ansatz von Objective-C ist mir dabei sehr sympatisch - ich sehe die vielen Vorteile durchaus, gearde dafür ist der Hillegass ein gutes Buch. Allein die Sprache an sich, ist für mich "unangenehm", das mit dem Präprozessor war kein Witz. Wenn man in die Syntax ein bisschen Ruby reinkreuzt, dann würde ich vermutlich eher Gefallen finden. Würde man eckige Klammern das sein lassen was sie in C-Sprachen gemeinhin sind (Indizes), mir viele es sehr viel leichter. Keine Ahnung warum das so ist :noplan:
 
Ich empfehle für diejenigen, die mit XCode bzw. mit Cocoa anfange, sich zuerst das EBook "Become an XCoder" von Apple anzusehen. Ist gratis und hat auch einige Seiten :D
 
Was ist sehr gerne mache ist, die durchgearbeiteten Kapitel oder Abschnitte eines Buches als Audio zu speichern und unterwegs oder bei anderen Tätigkeiten per iPod hören.
Finde ich ein guter weg um den Stoff nochmal durchzugehen.

Gruß Dennis
 
Zurück
Oben Unten