C# auf dem Mac

C# unter OS-X zu programmieren ist genau so ein sinnloxen Unterfangen wie Objektiv-C in Windows.

Das sind sprachen die sehr stark ans Betriebssystem gebunden sind. (wenn man das so nennen kann.) Muss es unbedingt C# sein? Ich mein diese ganze .NET Kram ist doch echt müll. Macht es doch, wenn es objektorientiert sein soll, in C++ oder Java...
 
Wenn die Aufgabe an's .NET Framework gebunden ist, bleibt wohl nicht viel. Wenn du ne Aufgabe bekommst, die Cocoa mit XCode vorsieht, wirst du wohl auch kaum GCC empfehlen, oder? ;)

Wieso ist .NET Müll? Weil's von Microsoft ist? Immerhin reden wir hier von einem sprachübergreifenden Framework, das verwalteten Code bietet und nen Haufen Schnittstellen zu Technologien wie Direct X und den SQL Server.

Klar ist .NET ans System gebunden. Ist ja auch von Microsoft. XCode ist auch ans Betriebssystem gebunden. Da regt sich keiner drüber auf.

Wenn ich mir die grottige Oberfläche von X11 antun muss, weil jemand meint, dass ja C++ völlig ausreichend ist und seinen Kram für Linux, BSD, Xenix, Yupiyayey, Windows und Amiga OS zu programmieren, weil er zu faul ist, seine Idee auf mehrere Plattformen umzusetzen, dann verzichte ich lieber auf die Software.

Bloß weil in den 70er Jahren mal C entwickelt wurde und man den User zwingen kann, den einmal programmierten Rotz auf ewig mit derselben grottigen Oberfläche auf jedem zukünftigen Betriebssystem zu verwenden, muss man es nicht tun.

Irgendwo muss man mal Prioritäten setzen. Entweder ich programmiere mit XCode für den Mac oder mit .NET für Windows. Java läuft zwar auf meinem Sofa, meiner Küchenreibe, meinem Handy, meiner Anzughose und meinem Herzschrittmacher. Schneller und schöner wird es dadurch aber auch nicht. :p
 
Wenn die Aufgabe an's .NET Framework gebunden ist, bleibt wohl nicht viel. Wenn du ne Aufgabe bekommst, die Cocoa mit XCode vorsieht, wirst du wohl auch kaum GCC empfehlen, oder? ;)

Das ist jetzt offtopic, aber Dir ist schon klar, dass Xcode gcc verwendet? Auch für Cocoa? Daher ist dieser Vergleich etwa so als wenn Du sagen würdest: "Wenn jemand einen VW will, dann würdest Du ihm auch keinen Passat empfehlen"

Alex
 
Ich geb zu, der Vergleich war nicht gut. Ich meinte gcc pur. Textmodus und Schmerzen a la Turbo C 3.0. :D

Sagen wir also statt gcc lieber Lattice-C. ;)

Edit: Wobei das auch ein blöder Vergleich ist, weil es ja nicht um die Sprache geht, sondern um das Framwork. Streichen wir einfach meinen letzten Absatz im letzten Post. :D
 
beitrag #22 /signed

.net framework ist m.E. eine hervorragende entwicklungsbasis. dass diese von microsoft kommt, spielt überhaupt keine rolle, auch die haben gelernt und stellen JEDEM vb.net // c# // c++.net // j# usw in den express varianten inkl ms sql server 2005 GRATIS zur verfügung. das schöne bei der entwicklungs ist, dass es unerheblich ist, womit davon nun das programm "erstellt" wurde, durch die .net runtimes läuft "alles mit allem".

man kann mit simplen texteditoren und commandline compilern programmieren, aber dann doch bitte auch auf nem commandline linux ohne grafische benutzeroberflächen. da wäre er wieder, der kopfschuss durchs knie - ohne tutorial :p

topic: c# und .net framework entwicklung unter gratis VirtualBox "null problemo", extra zu partitionieren, sich windows aufm mac installieren und den macosx vorteil damit weginstallieren entzieht dem mac-kauf die grundlage :p - aufgrund der beta der VirtualBox (die bei mir immernoch glänzend läuft) sind regelmäßige backups des wichtigen natürlich ohnehin unerlässlich :)
 
Nur um es nochmal klar zu stellen:
Er muss etwas in DirectX machen. Da kannst du alles andere als Windows vergessen.
 
Klar ist .NET ans System gebunden. Ist ja auch von Microsoft. XCode ist auch ans Betriebssystem gebunden. Da regt sich keiner drüber auf.

Was ist denn das für ein schwachsinniger vergleich...
vergleichst hier ne IDE mit dem Framework... LOL

Und bezüglich Java. Dir ist wohl nicht klar das
in vielen Firmen normale Java-Clients eingesetzt werden.
Warum wohl unterstützen ALLE automatisierten Testwerkzeuge Java?

Und das Java-Oberflächen nicht gut aussehen, zeigt
auch nur das du dich damit überhaubt nicht auskennst.

1. Kann man das Look&Feel veränder so das sie wie eine native
Anwendung aussieht. Das ist genau 1 Zeile Code die man, wenn
man ich Java Oberflächen programmiert, implementieren sollte
2. Sieht das Standard-Swing-Look&Feel seit Java5 echt super aus.
Erinnert stark an Aqua...

Wenn ihr schon .NET vergleich, dann bitte mit J2EE. Und hier hat J2EE
die Nase vorn.
Nur sollte man beachten das
.Net nicht an eine Sprache, aber ans Betriebssystem gebunden ist
J2EE an Java als Sprache gebunden ist, aber plattformunabhängig läuft.

Also wieso sollte ich eine Client-Server Lösung mit .NET schreiben,
wenn mir mit J2EE egal ist was der Kunde für eine Client-Server OS-Lösung einsetzt?
 
deus-ex schrieb:
Wenn ihr schon .NET vergleich, dann bitte mit J2EE. Und hier hat J2EE
die Nase vorn.
Nur sollte man beachten das
.Net nicht an eine Sprache, aber ans Betriebssystem gebunden ist
J2EE an Java als Sprache gebunden ist, aber plattformunabhängig läuft.

richtig :) aber bitte mit weniger Vehemenz (
deus-ex schrieb:
schwachsinniger vergleich...
) die sachlichen Argumente tuen es doch voll und ganz ;)
 
Und bezüglich Java. Dir ist wohl nicht klar das
in vielen Firmen normale Java-Clients eingesetzt werden.
Was ist denn das für ein Argument? In vielen Firmen werden genauso auch .Net Clients eingesetzt, insbesondere da dort Windows verbreiteter ist und die Erfahrung ist, daß die .Net-Clients sehr zuverlässig und stabil laufen. ;)
Und das Java-Oberflächen nicht gut aussehen, zeigt
auch nur das du dich damit überhaubt nicht auskennst.

1. Kann man das Look&Feel veränder so das sie wie eine native
Anwendung aussieht. Das ist genau 1 Zeile Code die man, wenn
man ich Java Oberflächen programmiert, implementieren sollte
2. Sieht das Standard-Swing-Look&Feel seit Java5 echt super aus.
Erinnert stark an Aqua...
Das aussehen ist halt sehr subjektiv und Aqua in einer Windows-Umgebung wirkt genauso fremd, wie eine X11-Anwendung unter OSX. ;)
Wenn ihr schon .NET vergleich, dann bitte mit J2EE. Und hier hat J2EE
die Nase vorn.
Behauptet Sun oder wie? Ich denke MS behauptet das Gegenteil. :D Nein im Ernst es gibt einsatzbereiche wo J2EE besser geeignet ist und es gibt genauso viele Einsatzbereiche wo .NET wesentlich besser geeignet ist und J2EE in jedem Fall vorzuziehen ist.
Nur sollte man beachten das
.Net nicht an eine Sprache, aber ans Betriebssystem gebunden ist
J2EE an Java als Sprache gebunden ist, aber plattformunabhängig läuft.
Auch diese Aussage ist nicht ganz richtig, da auch .Net durch Mono (eingeschränkt) plattformunabhängig ist, genauso wie Java (ebenfalls eingeschränkt, wenn auch weniger stark) Plattformunabhängig ist.
Also wieso sollte ich eine Client-Server Lösung mit .NET schreiben,
wenn mir mit J2EE egal ist was der Kunde für eine Client-Server OS-Lösung einsetzt?
Vielleicht weil es in den meisten Fällen mehr Sinn macht .Net zu nehmen, da bereits auf den Clients .Net läuft und man so das Optmimum herausholen kann (Windows Server mit Windows Clients ist nun einmal sehr verbreitet und spielen logischer Weise hervorragend zusammen. ;)
 
Der Grabenkampf ist auch völlig sinnfrei!

Beide Seiten bieten für einen ähnlichen Bereich unterschiedliche Lösungen an. Dabei kommt es immermehr zu einer Durchflechtung. Die Kommunikationswege zum Datenaustausch sind definiert und es ist klar das .NET und JEE (2 and 5) immer mehr koexistieren und zusammenarbeiten werden. Es wäre doch auch traurig dem Markt einem Anbieter zu überlassen.

Ich persönlich sehe in der Plattformbindung von .net einen Nach- wie auch einen Vorteil. Als was man es empfindet ist eben sehr subjektiv und sicher Fallbezogen und ganz sicher hier keinen "Mein Framework ist länger"-Flamewar zu starten!
 
  • Gefällt mir
Reaktionen: peterg und pdr2002
Ich denke während gruenerzwerg C# programmiert ist er nicht auf MacOSX angewiesen. An seiner Stelle würde ich zu der BootCamp Lösung greifen. Volle Prozessorgeschwindigkeit und zum MacOSX zurück ist es auch nur ein kurzer Weg. Ich habe auch schon alles mögliche versucht, aber C# scheint auf dem Mac noch keinen Einzug gehalten zu haben :-\
 
Ich denke während gruenerzwerg C# programmiert ist er nicht auf MacOSX angewiesen. An seiner Stelle würde ich zu der BootCamp Lösung greifen. Volle Prozessorgeschwindigkeit und zum MacOSX zurück ist es auch nur ein kurzer Weg. Ich habe auch schon alles mögliche versucht, aber C# scheint auf dem Mac noch keinen Einzug gehalten zu haben :-\
Offiziell wird dies auch nicht geschehen, aber das Projekt Mono arbeitet daran, wenn auch bis jetzt nur mit bescheiden Erfolg. ;)
 
Es gibt auch weitere Look&Feels für Java. Als neues Look&Feel für neue Java-Versionen wird wohl Nimbus gehandelt:

nimbus.png


Ausprobierbar unter:

http://swinglabs.org

Der Hauptvorteil von Java wird ja "bald" sein das es offiziell OpenSource unter der GPL wird. Somit ist man im Notfall nicht mehr an Sun gebunden.
 
Hallo an den Themensteller,

habe mir mal die Mühe gemacht und den Link zum Kurs angesehen.

Wenn Du nicht aus sehr speziellen Gründen Deinen Mac wirklich brauchst, würde ich für diesen Zweck auf einen Windows-PC mit Vista und den empfohlenen Komponenten wechseln. Ansonsten kann es Dir immer wieder passieren, dass Du nach einer arbeitsreichen Nacht bemerkst, dass Dein Programm an irgendeiner Inkompatibilität zum Original scheitert. Auch auf die Kombination Mac/BootCamp würde ich mich nur einlassen, wenn ich sehr genau wüsste, was ich da mache.

Für mich läuft das auf die Alternative "Liebe zum Mac" vs "Erfolg im Studium" hinaus.

Peter
 
Hmmm dieses Nimbus erinnert mich ein wenig an Solaris...

Wie auch immer, ich stimme nicht so ganz allem zu was heir zu .net und der j2ee gesagt wurde. Die meisten J2ee Apps laufen doch wo? Auf Servern, richtig und davon sind die meisten noch gottseidank Microsoft frei heutzutage, auch wenn manche Firmen immer mehr auf Windows Server setzen.

Ja, ihr koennt es wahrscheinlich oben rauslesen, ich habe ein Problem mit .net. Es regt mich auf, dass sich Microsoft nicht an Standards halten kann und versucht seine eienen durchzubringen. Fuer mich ist .net herzlich sinnlos. Man haette auf Plattformunabhaengigkeit setzen sollen, anstatt auf die CLR Sprachen, oder mit ein wenig Zeit auf beides.
So ist es doch super, dass ich mit C sharp loslege und ein Kollege mit VB, toll... aendert nur trotzdem nix daran, dass es an Windows gebunden ist.

Damit bleibt .net fuer mich eine schoene einfache Moeglichkeit Programme oder kleine Spiele fuer Windows zu coden. Fuer alles andere, vor Allem im Enterprise Bereich ist es somit fuer mich wenig tauglich.
 
auch wenn manche Firmen immer mehr auf Windows Server setzen.
Der Witz war gut.:p
Zu Deiner Information, es sind sehr viele Firmen, die auf Windows-Server setzten und der aktuelle Windows 2003 Server ist auch garnicht mal so schlecht. ;) Und in einem solchen Umfeld mach Java eher wenig Sinn.
 
@cynic

M$ hatte doch gar keine andere Wahl als .NET zu entwickeln. MFC, WinAPI und andere geistige Ergüsse von M$ sind einfach nicht zu gebrauchen. Darum setzten immer mehr Entwickler auf Fremd-Tools, um Programme für Windows zu entwickeln. Das schmeckte M$ natürlich nicht, also hat man .NET entwickelt. Für Windows-Programmierung ist es ja auch nicht schlecht und das man es Standardtisiert hat, auch nicht.

Das es ein paar Hilflose versuche gibt das ganze Plattformunabhängig zu machen (gibt's ja mit WINE und der WinAPI ja auch), dafür kann M$ ja nix.

Wenn ein Entwickler plattformunabhängige Programme entwickeln will, nimmt er garantiert nicht .NET von Microsoft. ;) Wenn er es nicht will, kann er ja ruhig .NET nehmen. Wirft ja auch keiner Apple vor, sowas wie Cocoa zu haben. ;)

@pdr2002

Also in unserem Kundenkreis sind sehr viele sehr unzufrieden mit ihren Windows2k3 Servern. Sei es Administration, Performance oder einfach Preis/Leistung.
 
Der Witz war gut.:p
Zu Deiner Information, es sind sehr viele Firmen, die auf Windows-Server setzten und der aktuelle Windows 2003 Server ist auch garnicht mal so schlecht. ;) Und in einem solchen Umfeld mach Java eher wenig Sinn.

Bevor du jetzt darauf pochst... du sprichst von etwas ganz anderem.
Ich spreche hier nicht von AD Servern und dem ganzen Bloedsinn. ;)
 
@cynic

M$ hatte doch gar keine andere Wahl als .NET zu entwickeln. MFC, WinAPI und andere geistige Ergüsse von M$ sind einfach nicht zu gebrauchen. Darum setzten immer mehr Entwickler auf Fremd-Tools, um Programme für Windows zu entwickeln. Das schmeckte M$ natürlich nicht, also hat man .NET entwickelt. Für Windows-Programmierung ist es ja auch nicht schlecht und das man es Standardtisiert hat, auch nicht.

Das es ein paar Hilflose versuche gibt das ganze Plattformunabhängig zu machen (gibt's ja mit WINE und der WinAPI ja auch), dafür kann M$ ja nix.

Wenn ein Entwickler plattformunabhängige Programme entwickeln will, nimmt er garantiert nicht .NET von Microsoft. ;) Wenn er es nicht will, kann er ja ruhig .NET nehmen. Wirft ja auch keiner Apple vor, sowas wie Cocoa zu haben. ;)

Da stimme ich dir ja auch komplett zu. ;)
Mein Punkt ist eher die richtung, in die Microsoft .net gerne pushen wuerde. Nein die passt mir nicht, weil das in meinen Augen Ignoranz pur ist. In einigen Bereich hat Windows Server nix verloren... wollte man wirklich in diese Vorstossen, haette man es auch anders loesen koennen.

Versteht mich allerdings nicht falsch:
Ich habe vor 2 Jahren ein groesseres Projekt mit .net machen muessen. Ich finde c sharp ganz schoen. Die Sprache hat mir ganz gut gefallen und Visual Studio war auch eine Komfortable Umgebung dafuer.
 
Bevor du jetzt darauf pochst... du sprichst von etwas ganz anderem.
Ich spreche hier nicht von AD Servern und dem ganzen Bloedsinn. ;)
Ich auch nicht... ;) MS hat auch für andere Bereiche sehr gute Serverlösungen. Es gibt natürlich Bereiche, da würde ich auch keine MS-Server nutzen wollen, aber darum geht es nicht. Es geht um Client-Server Anwendungen, also zB. SQL, oder Exchange-Server und XP-Client. In diesem Bereich haben .Net basierte Anwendungen einen klaren Heimvorteil und diese Kobination ist nun einmal sehr weit verbreitet. ;)
 
Zurück
Oben Unten