Was haltet ihr von Mono/C#?

[Amin]

Es kann sein, das man in anderen Sprachen tatsächlich weniger Code schreiben muß. Wobei das, wie gesagt, nur so sein kann! Das Vorurteil, das man in C++ mehr Code schreiben muß, ist eine Halbwahrheit. Es wird wohl daher kommen, das damals keine C++-Standard-Library existierte und deshalb sehr viel mehr Handarbeit leisten mußten.

Aber das ist heute nicht mehr nötig, weil C++ seit 1998 normiert ist (und darin eine Standardlibrary spezifiziert ist). Heute ist auf jeder ernsthaften Platform eine C++-Standardlibrary verfügbar. Denn eines muß man bedenken: auch die C++-Welt entwickelt sich weiter. Und viele kennen nur die C++-Welt aus den 80er und 90er. Aber wir haben heute 2008.

Ein Beispiel. Wenn ich in C++ ein dynamischen Container mit Strings haben will. Was mache ich da?

vector<string> vec;

Ist doch recht kurzer Code, oder? Jetzt kann jemand kommen, und sagen ich muß zwei Zeichen mehr eintippen als in Sprache X. OK, dann kann ich auch nichts mehr gegensetzen.

Von Bjarne Stroustrup gibt es einen netten Satz:
"Without a good library, most interesting tasks are hard to do in C++;
but given a good library, almost any task can be made easy."

Und man muß sagen, die meisten sind ja eher Benutzer einer Library. Die wenigsten implementieren große komplexe Libraries oder Frameworks. Man sollte sich deshalb als C++'ler mit der Standardlibrary beschäftigen um sie nutzen zu können (und somit effektiv zu sein).

Und jedem C++'ler ist zu empfehlen, sich im Opensource-Lager umzuschauen. Bereits die Boost-Libraries decken sovieles ab, um das Leben leichter zu machen. Adobe hat auch viele seiner Libraries frei gegeben:
http://stlab.adobe.com/

Man muß aber aufpassen, es gibt da draussen auch Libraries, die nicht zu empfehlen sind.

 

[Amin]

Hmm, eher auf das erstere .

Ist halt aus der Sicht eines Perl-Skripters.... und gelegenheits Nutzer von "ordentlichen" Sprachen.

Was würdet ihr mir empfehlen, Ich möchte seit langem mal mehr mit den besagten "ordentlichen" Sprachen machen, habe mit D angefangen, aber die Libraries sind so rar, dass es einfach so große Hürden gibt etwas zu bewerkstelligen welche man als Anfänger nicht überwinden kann. Java ist nicht drin, so gern es mir leid tut, nein. C++?

Hem, ein Java-Fan wird dir Java empfehlen. Ein C-Fan wird dir C empfehlen. usw.

Was ist denn dein Ziel? Willst du dich intenstiv mit einer Sprache auseinander setzen? Dann ist C++ ein guter Kandidat. Die Sprache ist sehr umfangreich. Einige Dinge sind sehr interessant, wie z.B. Meta-Programmierung mit Templates. Ich pers. kann damit nicht viel anfangen, weil ich dafür kein Anwendungsgebiet habe, aber es ist ganz interessant, wenn man da mal reinschnuppert. Ansonst steht einem mit C++ sehr viel offen, da es dafür sehr viele Libraries gibt.

Interessant ist auch die Möglichkeit, z.B. mal ebend Lua oder Python einzubetten. So kann man mit C++ den statischen Code schreiben und mit den Scripts mal was dynamisches scripten. Geht natürlich auch mit anderen Sprachen, aber bei C++ sind die Gegensätze zu Scriptsprachen viel extremer. Sprachen wie Java oder Smalltalk sind durch ihre VMs schon recht script ähnlich. Bei C++ wird alles zur Compiletime gelöst. D.h. die Denkweise ist anders.

Auch hast du in C++ dieses OO-Paradigma nicht in Stein gemeisselt. Du kannst auch proceduralen Code mit OO-Code mischen. Oder auch Template-Funktionen schreiben.

Nichts muß, alles kann in C++- Oder wie das C++-Standardisierungs-Komitee so schön sagt: "You pay only for what you get!"

 

[omni]

nur mal so

Da will ich auch mal in die Diskusion mit einstegen.

Zwar bin ich keine pro aber ich habe mich schon mit den aufgelisteten Sprachen beschäftigt.
C# aufgrund eines gemeinsamen Projektes mit nem Freund, Java wie schon zuvor erwähnt in den posts wegen der Uni und c/c++ aus hobby und Leidenschaft.

Zum Post Mono\C#: es muss ja schon ein Grund geben wieso sich ein paar Leute aufmachen eine Port für c# zu schreiben oder? die Sprache ist nähmlich in einigen Punkten ausgeklügelt. Nur kommt das Problem auf als c Etnwickelr das man sich irgendwann von der Masse der layers die zwischen einem und der Machine stehen erdrückt fühlt und bei Problemmen erstmal ahnungslos darsteht und nicht weis was den schiefgelaufen sein könnte.

Um nur ein Beispiel zu nennen: Meine Freundin hat 3 Semster Informatik hinter sich gehabt bevor ich noch an die Uni denken wollte. Und ich muste ihr erklären was die funktion DrawCircle() intern macht. Verständlich den es ist ja auch irgendwie sinnfrei in einem Informatikstudium Sachen zu lernen die die Wirklichkeit durch Abstraktion verschleiern. Da ist es doch klar das man vor der funktion wie ein Toastbrot sitzt und nur stupide verlangen kann das sie ein Kreis zeichnet. Im endeffekt wirds ja eh in prozeduralen bytecode umgesezt also was solls. Da weichen leider die Unis ab von ihrerm Ziel einem beizubrigen wie etwas funktioniert, sondern (wollen) FH like nur zeigen das es funktioniert.

Was die java Verbreitung angeht bin ich auch der Meinung das es nicht gerechtfertigt ist was grad abgeht das jeder hans mit dem Trend mitschwimmen will. Ich meine im web hats java nunmal nicht geschaft klar hier und da giebts mal ein Applet und in den unis etwas heufiger aber der Platzhirsch bleit hier eben flash. Was serverside scripting angeht wie JSP zu php weis man ja wohin der wind weht. Im HPC bereicht ist sowieso schluss für derartige Programiersprachen. Leider wurde mir in der Uni diese Sprache quasi angedreht und ich kann mich nicht wirklich dagegen wehren das geht sicherlich vielen so. aber so richtig überzeugend wirkt das auf mich nicht wen ein Prof was von optimierung erzählt und wie man es in java macht.

Was die IDE's betrift nehmen sich java und C# ja nun nicht viel NetBeans und Eclips brauchen länger als Photoshop um zu starten. Hat man mal den Luxus eines VS 6.0 probiert blickt man nur noch herab auf derartige Zumutungen. Dies gilt auch für VS 8(C#) mit ihren gefühlten 30 subfenstern in der Entwicklungsumgebung wo man 3 Monitore braucht um mal eine Seite code vollständig anzeigen zu lassen. Erstrecht für features die schon in der Sprache sind aber man sie nicht mit der IDE einsetzen kann weils halt erst nächstes Jahr in die IDE implementiert wird.

C# soewie Java ist ansich nicht schlecht wenn man "schnell" was funktionsfähiges hinkleistern will des geldes wegen, aber Qualität darf man da nicht erwarten man setzt sich da ja auch nicht dermaßen mit dem Programm auseinander gerade wegen des Argumentes das man etwas schnell schreiben kann, da werden libs verwenden ohne geteste zu haben ob die eigene Implementierung schneller läufet oder nicht, nee das ist vorgegeben und wird benuzt und damit basta. Und da unterscheidet man sich nicht von Leuten die Fakten aus der BILD für bares Geld nehmen.

Nun sind wir abber alle nicht mega reich und so ist es nunmal besonders bei MS produkten viel geld zu holen ist und gerade deswegen ist es aus wirtschaftlicher Sicht sehr gut das es mono/c# gibt. Dieses Argument scheint aber für java in den lezten 2/3 jahren auch zu zu Treffen da ich bis vor kurzem zB. in der "ct" nur anzeigen für Jobangebote gesehen habe die allesamt java Programmierer suchten. Zum glück schimmert jezt wieder ein bischen Vernunft durch, sodas die java Flut sich auf ziemlich die hälfte reduziert hat.

OT: Da war die frage womit man anfangen sollte. ganz klar c. man wird nicht drum herum kommen wenn man mit Computersystemen arbeiten will. im grunde gillt Kann man C kann man alles, da doch 80 % der Sprachen sich an C orientiert und man somiet eigentlich bessere Chancen hat als nur java zu lernen,. Und das Gerede über libs un der gleichen wie STL solte man eh nicht beahten es gitl eben nicht für eine Programmiersprache je mehr libs desto besser(außer natürlich in der Wirtschaft). Wer benuzt den Vector<T > ? mal erlich wen es jemand über sich ergehen lässt ne Blackbox ala STL zu benutzen der ist im Endefekt eh nur ein "End"-kunde(Konsument) und kein Entwickler. DIe großen (Firmen) haben eh ihre eigene codebase die sie seit Jahren pflegen. Da muss ich sagen ist die STL den java und C# libs weit unterlegen. Dan lieber zu c#/java wechseln

-------------------------------
my 2 cents. mfg omni.

 

[FreeBSDuser]

Ich möchte mir halt nicht in den Fuß schießen....

Später mehr, ich muss jetzt schlafen. ~EDIT to come~

 

[Ararat++]

Danke für die Antworten.

Ich werde mich wohl näher mit C befassen und dann C# lernen.

 

[indy]

> NetBeans und Eclips brauchen länger als Photoshop...
Naja, die machen aber auch geringfügig mehr.
Außerdem ist der Start von Java-Applikationen auf Windows gegenüber nativen Windows-Anwendungen nicht fair. Unter Linux/FreeBSD starten die bei mir _immer_ deutlich schneller.

> C# soewie Java ist ansich nicht schlecht wenn man "schnell" was
> funktionsfähiges hinkleistern will des geldes wegen, aber Qualität darf man da
> nicht erwarten man setzt sich da ja a...
Aber Hallo...
Ich bin jetzt seit 2001 im Bereich Softwarequalität unterwegs und ich muss dir vehement widersprechen.
Die Qualität der Software wird nicht durch die Wahl der Sprache bestimmt. Die bestimmt einzig und allein der Entwickler.
Allerdings habe ich bereits mehr C und C++-Projekte gehabt, die keine Chance zum Re-Engineering hatten, als Java- und C#-Projekte.
Der Grund ist ganz einfach: Bei den letzten beiden Sprachen ist das Abstraktionsniveau deutlich höher. Ich hatte letztens ein C++-Programm bei dem ich erstmal eine ganze Menge Zeilen gelöscht habe, die nichts getan, aber meine Kollegen verwirrt haben.

Seid bitte etwas zurückhaltender mit solchen Postulaten :-)

So long...

Der Indy

 

[indy]

> Ich werde mich wohl näher mit C befassen und dann C# lernen.

Mein Tipp: Mach's umgedreht.
Als Automechaniker lernst du auch zuerst das Fahren und dann, wie man den Motor wechselt.

So long...

Der Indy

 

[nakal]

>Mein Tipp: Mach's umgedreht.

Ne, warum? C ist high-level genug, um nicht eine Verärgerung darzustellen. Und low-level genug, um nachzuvollziehen, wie alles auf einem Rechner funktioniert. Die Sprache ist deswegen brauchbar.

Man macht oft vieles kaputt, wenn man mit falschen Konzepten anfängt. Viele kommen sofort mit der objektorientierten Keule angelaufen und noch schlimmer, mit Entwurfsmustern, bevor die kapieren, dass Code viel schöner und verständlicher ist, wenn er kurz und bündig ist.

Hier ein hervorragendes Beispiel in Java wie sich mit zunehmenden Wissen eine gewisse Dummheit entwickelt und Produktivität abnimmt.

Lernt lieber produktiv zu sein und den Code mit einfachen gut bewährten Stilmitteln sauber zu halten. C ist hervorragend um das zu lernen. Objektorientierung ist gut, aber lernt das später. Es ist nicht das Allheilmittel, wie viele Leute das gerne glauben. Garbage Collection muss auch nicht sein. Wer Garbage Collection gewöhnt ist, wird nie saubere Programme schreiben können. Es gibt nämlich mehr als nur Speicherbereiche, die man aufräumen sollte. Im Code sollte man stets hinter sich aufräumen, wenn es erforderlich ist. Java nimmt einem teilweise die Entscheidung ab, wann es erforderlich ist. Und ich weiß nicht ob das so sinnvoll ist. Bei manchen Konzepten lässt Java Sachen wie z.B. Dateien und Sockets unaufgeräumt, wenn man nicht aufpasst und auf die "Magie" der Garbage Collection vertraut.

 

[oenone]

Ne, warum? C ist high-level genug, um nicht eine Verärgerung darzustellen. Und low-level genug, um nachzuvollziehen, wie alles auf einem Rechner funktioniert. Die Sprache ist deswegen brauchbar.

Man macht oft vieles kaputt, wenn man mit falschen Konzepten anfängt. Viele kommen sofort mit der objektorientierten Keule angelaufen und noch schlimmer, mit Entwurfsmustern, bevor die kapieren, dass Code viel schöner und verständlicher ist, wenn er kurz und bündig ist.

Kann ich nur zustimmen. Meiner Meinung nach sollte jeder auch mal mit Assembler in den Registern rumgestochert haben, um zumindest ein kleines Verständnis dafür zu haben, wie unsere Rechner so funktionieren (am Besten kein 64bit-x86-asm, sondern was einfacheres, wie m68k oder gar 6502).

Ich würde jedoch nie jemandem C empfehlen, sondern Ada..

Gruß,
oenone

 

[danlei]

Hier ein hervorragendes Beispiel in Java wie sich mit zunehmenden Wissen eine gewisse Dummheit entwickelt und Produktivität abnimmt.

Ich konnte es einfach nicht lassen, nachdem ich den Link gelesen hatte:

(defun get-os ()
  "Returns the name of the underlying OS as a symbol."
  (intern (software-type)))

(defgeneric bash-os (operating-system)
  (:documentation "Bashes your favorite OS.")
  (:method ((operating-system (eql '|Darwin|)))
    (princ "Darwin rules!"))
  (:method ((operating-system (eql '|Linux|)))
    (princ "Linux is ok."))
  (:method ((operating-system (eql '|Windows|)))
    (princ "I pitty you.")))

Ganz ohne if, volle Kanne polymorph, yay!

 

[Kamikaze]

Das sieht für mich irgendwie lispig aus. Ich hasse das. Für mich geht Lesbarkeit über Kürze.

Wahrscheinlich ist das für einen Lisp-Programmierer gut lesbar. Für mich aber nicht.

 

[danlei]

Was für Dich nicht lesbar ist, muss für Andere nicht auch unverständlich sein.

Für mich ist dass allemal verständlicher, als die Beispiele im Link, aber ich schließe daraus nicht, dass mein Code »lesbarer« ist, sondern dass ich mich da einfach besser auskenne. Und mal unter uns: zwei Seiten Code – auf mehrere Dateien verteilt – für sowas?

 

[Kamikaze]

Es war ja auch ein Beispiel für furchtbaren Code. Wenn man alle Probleme mit Kanonen erschießt wird ein Programm nie fertig.

 

[danlei]

Ack.

Ich schrieb das nur wegen des »Für mich geht Lesbarkeit über Kürze«. Ich hab einfach die erste OO-Lösung notiert, die mir einfiel, ohne auf »Kürze« zu achten.

 

[indy]

> Man macht oft vieles kaputt, wenn man mit falschen Konzepten anfängt. Viele
> kommen sofort mit der objektorientierten Keule angelaufen und noch schlimmer,
> mit Entwurfsmustern, bevor die kapieren, dass Code viel schöner und
> verständlicher ist, wenn er kurz und bündig ist.
Um programmieren zu lernen ist meiner Erfahrung nach der prodzedurale Ansatz denkbar ungeeignet. Zumindest wenn ich mir unsere Studis so anschaue.
Mit OOP (bei uns Java) stellen sich schneller sichtbare Erfolgserlebnisse ein, die die Motivation, in die Schichten drunter zu schauen, deutlich erhöhen.

Ich unterstelle Dir, den Sinn von Entwurfsmustern nicht verstanden zu haben, denn die erlauben es, extrem kurzen Code zu schreiben, und sehr viel damit auszudrücken. In dem Moment, wo ich Technik (Speicherverwaltung) mit Fachlichkeit (Businesslogik) mischen muss, kann ich keinen kurzen Quelltext schreiben. Insofern ist für Applikationen der OOP-Ansatz C & Co. definitiv überlegen.
Sicher kann man auch in Java richtig schlecht programmieren, und die meisten ehemaligen C-ler, die heute Java lehren, machen es falsch (ich denke da an die Heiligsprechung von finalize...). Grund dafür ist, dass sie schlicht und einfach in einem Denken verwurzelt sind, von dem sie sich nicht lösen können.

So long...

Der Indy

 

[nakal]

>Um programmieren zu lernen ist meiner Erfahrung nach der prodzedurale Ansatz denkbar ungeeignet. Zumindest wenn ich mir unsere Studis so anschaue.

Das ist reine Einbildung. Das was in Java das Programm ausmacht ist sowieso prozedural. Und wenn jemand das nicht beherrscht, dann wird er auch nichts strukturieren können, weil er denn sinn nicht erkennt.

Mit OOP (bei uns Java) stellen sich schneller sichtbare Erfolgserlebnisse ein, die die Motivation, in die Schichten drunter zu schauen, deutlich erhöhen.

Wir haben bei uns der Uni das so organisiert, dass Objektorientierung für Java ziemlich spät kam. Und das war auch sinnvoll so. Ich glaube, dass da keiner so richtig Probleme mit hatte, weil man dies entsprechend motiviert hatte.

Ich unterstelle Dir, den Sinn von Entwurfsmustern nicht verstanden zu haben, denn die erlauben es, extrem kurzen Code zu schreiben,

Wenn Du das so meinst. Entwurfsmuster sind aber eher nicht dazu da um sich kurz auszudrücken.

In dem Moment, wo ich Technik (Speicherverwaltung) mit Fachlichkeit (Businesslogik) mischen muss, kann ich keinen kurzen Quelltext schreiben. Insofern ist für Applikationen der OOP-Ansatz C & Co. definitiv überlegen.

Speicherverwaltung musst Du in allen Sprachen machen. Da ist Java keine Ausnahme. Wenn man es nicht hinkriegt, dass Code übersichtlich und verständlich wird, sollte man alles einstampfen und am besten noch ein mal neu anfangen.

Sicher kann man auch in Java richtig schlecht programmieren, und die meisten ehemaligen C-ler, die heute Java lehren, machen es falsch (ich denke da an die Heiligsprechung von finalize...).

Ich habe ziemlich früh mit Java angefangen. Da gab es nicht mal Version 1.0. Und etwa zu dieser Zeit bin ich auch von Pascal auf C umgestiegen. Ich glaube, dass ich durchaus sehr gut in Java programmieren kann. Ich halte aber C fast in allen Bereichen für die bessere Wahl.

Missverstehe mich nicht. Ich halte Java für gut. Aber es reicht nicht an simples C heran und den Möglichkeiten, die sich da eröffnen. Java ist vielmehr eine Kindersprache, die die Erwachsenen umarmen, weil sie sich da voll gerne mit beschäftigen. Ihre Argumente sind bekannt und wurden hier schon aufgezählt. Alle diese Argumente laufen darauf hinaus, dass wenn man unfähig ist, mit Basiskonzepten, wie Speicherverwaltung und saubere Programmstrukturierung umzugehen, dann nimmt man sich Krücken in die Hand und lässt sich durch die Welt leiten, wie sie andere vorbestimmt haben.

Java ist Millionen von Malen missbraucht worden (allein schon Wahl der Sprache bei Projekten) und ist ein Innovationshemmer, weil es für Volksverdummung steht. Einige Professoren entdecken das jetzt. Ich habe das schon etwas länger beobachtet.

Mein Fazit: Java ist eine Uni-Sprache. Wenn man aber raus ist, sollte man etwas Vernüftiges lernen. Und eine Option ist C. Kennen sollte man aber alles, auch Java und auch Basic, damit man auch die Schwächen der Sprachen genau kennt.

Grund dafür ist, dass sie schlicht und einfach in einem Denken verwurzelt sind, von dem sie sich nicht lösen können.

Klar gibt es einiges wo Java erstmal vernünftig gelernt sein sollte. Aber ich glaube, dass das auch bei C ein Problem ist. Wenn diese Sprache nicht vernünftig beherrscht wird, dann kommt sie einem schwierig vor. Auch in C kann man ein schlechter Programmierer sein und ich kenne Leute, die von Java auf C umgestiegen sind. Die haben enorme Probleme mit einfachen Konzepten. Java verdirbt gute Leute manchmal.

 

[xbit]

Um programmieren zu lernen ist meiner Erfahrung nach der prodzedurale Ansatz denkbar ungeeignet. Zumindest wenn ich mir unsere Studis so anschaue.
Mit OOP (bei uns Java) stellen sich schneller sichtbare Erfolgserlebnisse ein, die die Motivation, in die Schichten drunter zu schauen, deutlich erhöhen.

Die Studis, mit denen ich angefangen habe zu studieren, haben erst Smalltalk und dann Java gelernt. Und ich hatte den Eindruck, dass die meisten mit Java gut zurecht kamen und was "produktives" erzeugt haben, weil Eclipse ihnen das Lesen und Suchen in der Doku abgenommen hat. Haetten die vor 'nem normalen Editor gesessen, haetten die kaum was zustande gebracht.

Ein weiteres Problem ist, dass bei uns an der Uni nicht wirklich stark auf sauberen Code geachtet hat (von Seiten der Profs). In erster Linie zaehlte, dass der Code das tut was er tun soll.

Und Pascal, urspruenglich auch prozedural und ohne Objekte, wurde in erster Linie entwickelt, um Studenten das Programmieren beizubringen.

Und ohne strukturiertes Programmieren, hilft Dir objektorientiertes Programmieren auch nicht. Das ist dann in etwa so, wie C++ Klassen verwenden, aber den Inhalt in purem C zu implementieren. Einfach zwei Konzepte mischen, die kaum etwas miteinander zu tun haben.

 

[Daemotron]

Hmm, was soll man von so einem Thread halten. Ich mag ehrlich gesagt keine der beiden Sprachen besonders gerne. Für den Web-Bereich halte ich Java schlicht für Overkill und sehe darin eigentlich nur eine Verkaufshilfe für große, teure Server (wie sie zufälligerweise von Sun hergestellt werden...). OK, Perl und auch PHP bis einschließlich Version4 wären für größere Anwendungen sicherlich kein Ersatz gewesen, aber mittlerweile stehen mit PHP5, Ruby und v. a. Python doch recht mächtige, aber eben überschaubarere Alternativen zur Verfügung.

Das .Net-Framework hingegen ist IMHO besser als sein Ruf. OK, 1.1 war noch etwas krampfig, aber mit 2.0 und den 2005er Tools (insbesondere sei hier auf VB.NET Express hingewiesen) kann man damit sehr entspannt Anwendungen für den Firmenalltag entwickeln (Client-Server oder Client-Backend z. B.). Ob man jetzt dafür C# einsetzen muss, sei mal dahingestellt. VB.NET ist (mittlerweile) ähnlich mächtig, und ich empfinde das Entwickeln damit als produktiver und ergebnisorientierter als bei C#. Ist zwar vielleicht methodisch nicht immer so schön "reine Lehre", aber außerhalb der Unis kommt's eben auf andere Dinge an als auf die Prinzipienreiterei der Programmiermethoden-Vorlesung

Kurz: In der Entwicklung moderner Webanwendungen haben IMHO beide (.NET und Java) nichts mehr verloren. Und bei Desktop-Anwendungen hängt es vom Ziel ab. Wenn nur für Windows entwickelt wird (z. B. firmenintern) würde ich aus Effizienzgründen zu .NET greifen. Für Plattform-unabhängiges finde ich die Kombination Python + QT sehr attraktiv.

 

[exor.freebsd]

Ein Glueck fuer mich, dass hier so hefftig ueber Konzepte diskutiert wird!

Ich habe gleich mit C++ und OOP begonnen und habe mittlerweile mit Schrecken festgestellt, dass ich groessere Programme und Probleme eigentlich nur mit Hilfe von OOP "erfassen" und modelieren kann. Ich habe mich quer durch Java, C#, python gehangelt und finde Java und .Net mittlerweile ziemlich abstossend und bin immer wieder beim C im C++ gelandet.

Das Problem ist jetzt, dass die (H)HLLs ((Higher) High Level Languages) als Weiterentwicklung angepriesen werden. Auf der Uni ist Java die Hauptsprache. 90% der Jobangebote sind Java. Ich finde jedoch, dass man fuer ein relativ einfaches Problem, wesentlich komplexere Werkzeuge braucht, um es zu loesen. (z.b. oop, pattern, usw)

Ich beschaeftige mich momentan mehr mit Systemprogrammierung und im speziellen mit FreeBSD und Unix-Betriebssystemkonzepten im Allgemeinen. Jetzt frage ich mich, warum hier eigentlich alles noch in C implementiert wird, und nicht z.b. in C++?

Liegt es daran, dass das ganze Know-How in C vorhanden ist und es einfach unvernuenftig waere eine funktionierende Basis zu aendern?
Weil die Programmierer C am besten (laengsten) beherrschen?
Weil C in seinem Bereich genauso aktuell ist, wie es Java in seinem ist?

Wuerden zwei Programmierer, einer mit C der andere mit Java, ein sehr umfangreiches Softwareprojekt programmieren. Es sei angenommen, dass beide Programmierer ihr Fach/Sprache/Paradigma perfekt beherrschen. Waere ein Programm dem anderen ueberlegen?

So, sorry fuer den sehr langen Beitrag, aber diese Frage draengt sich mir schon ziemlich heftig auf.

MfG

 

[BrainPain]

Auf der Uni ist Java die Hauptsprache. 90% der Jobangebote sind Java. Ich finde jedoch, dass man fuer ein relativ einfaches Problem, wesentlich komplexere Werkzeuge braucht, um es zu loesen. (z.b. oop, pattern, usw)

Warum braucht man in der OOP "unbedingt" für einfache Probleme "komplexe" Werkzeuge? Eine Ausgabe auf der Konsole schaffe ich auch ohne Composite-Pattern.

C wird in der Systemprogrammierung hauptsächlich aus Performancegründen eingesetzt. (AFAIK) OOP bringt nunmal einen nicht zu verachtenden Overhead mit sich. Von der Wartbarkeit sind OO-Programme den Prozeduralen sicherlich überlegen. Kommt natürlich auch auf die Projektgröße an und ob mit späteren Erweiterungen zu rechnen ist.
Java und .NET benötigen zusätzlich noch eine Runtime was wiederum für Overhead sorgt.

BEOS war/ist (soweit ich weiß) ein OO-OS.

Viele Grüße

 

[exor.freebsd]

Warum braucht man in der OOP "unbedingt" für einfache Probleme "komplexe" Werkzeuge? Eine Ausgabe auf der Konsole schaffe ich auch ohne Composite-Pattern.

Nur ein Beispiel was alleine schon ein simples Hello-World-Programm (wenn auch nur namentlich) enthaellt:

http://www.math.uni-wuppertal.de/~grosser/jv/haupt/node5.html

Das ist aber eigentlich kein wirkliches Problem, oder? Vielmehr macht mir zu schaffen, dass vieles an Javacode den ich gesehn habe eher dem hier gleicht!

http://developers.slashdot.org/comments.pl?sid=33602&cid=3636102
(Mir ist natuerlich schon klar, dass man das auch mit jeder anderen Sprache machen kann.)

PS.:
Jo, BeOS IST objektorientiert entworfen.

 

[Amin]

Das alles in C gemacht wird, hängt damit zusammen, das bei vielen das C++-Know How fehlt. Ist doch ganz einfach. John Carmak (von ID Soft) hatte auch immer gesagt, das er nie und nie C++ machen wird. Und was ist? Doom 3 Engine wurde dann doch in C++ implementiert. Warum? Weil er C++ gelernt hat.

Um C++ zu lernen muß man seinen inneren Schweinehund überlisten. Denn es ist klar, das man in C (und ja, auch in Assembler) jedes Problem lösen kann. Die Frage ist nur: wie bequem kann ich das machen? In C muß ich z.B. durch Switch-Case-Anweisungen die Polymorphie (Late Binding) von OOP nachbilden. Das erledigt natürlich der C++-Compiler für einen.

Und da wären wir schon bei der angeblich schlechteren C++-Performance. Nein, diese gibt es nicht! Wenn ich in C++ eine Klasse habe, ohne virtuelle Methode, habe ich technisch ein C-Struct, nur halt noch mit der Möglichkeit der Datenkapselung. 0,0% Overhead!

Wenn ich eine virtuelle Methode habe, die für Late Binding da ist, wird der Compiler eine Sprungtabelle erstellen. Und das kostet genau einen Jump bzw. einen Pointer!!! Das ist nicht mehr Overhead, als wenn ich in C das ganze mit einer Switch-Case- oder if-else-Anweisung nachbaue.

Das C++-Code damals langsam war, ist nur der Kinderschuhe zu schulden. Die heutigen C++-Compiler optimieren seeehr gut, und auch C++ als Sprache selbst hat sich mächtig weiter entwickelt.

C++ ist ein Werkzeug, das mir erlaubt viele Paradigmen nicht nachprogrammieren zu müssen. Ich kann z.B. in Assember OOP betreiben, aber mit welchem Schreibaufwand? Vieles wird doch in C gemacht, weil C ggü. Assembler weniger Schreibaufwand bedeutet. Genau das gleiche kann ich auf C++ vs. C beziehen.

Und C++ bietet mir aber viele Möglichkeiten an. Z.B. kann ich weiterhin prozedural programmieren, ich kann auch Metaprogrammierung betreiben (Code der Code erzeugt). Wie genial ist denn z.B. std::vector? Sehr genial! Es hat KEINE virtuellen Methoden! D.h. ich bekomme 100% Performance eines Arrays!

std::vector<int> vec(10); // 10 Elemente im Vector
vec[0] = 123;                            // gleiche Performance wie bei einem nativen C-Array!
vec.at(0) = 123;                       // wie vec[0], jedoch zus. mit einer Bereichsprüfung.

Vorallem die at()-Methode ist nicht langsamer als in C. Warum? Weil ich auch in C eine Bereichsprüfung machen würde, um einen Bufferoverflow zu vermeiden. Und, die at()-Methode ist nicht virtual, d.h. der Aufruf kostet nicht mehr als ein prozeduraler C-Aufruf.

Wobei ich es mir mit dem Index-Operator auch aussuchen kann, ob ich doch keine Index-Prüfung haben will. Denn der Index-Operator von vector muß laut C++-Spec keine Index-Prüfung machen. Dann habe ich sogar durch das Inlining die gleiche Performance wie bei einem C-Array (was auch Tests belegen können, habe ich mir nicht aus den Fingern gesaugt).

Denn auch beim C++-Komitee gilt offiziell: "you pay only, for what you get!"

C++ ist ein Werkzeug, nicht mehr und nicht weniger. Aber die ganze Steinzeit-Vorurteile sollte man auch irgendwann überdenken.

 

[Amin]

Warum braucht man in der OOP "unbedingt" für einfache Probleme "komplexe" Werkzeuge? Eine Ausgabe auf der Konsole schaffe ich auch ohne Composite-Pattern.

Hat ja auch keiner gesagt, das man das machen muß, oder? Es ist nicht schön, die Tatsachen zu verdrehen. Ich kann auch in Java prozedural programmieren. Das alles in eine klasse muß, ist nur nebensächlich. Gutes Beispiel ist die Math-Klasse aus Java, die benutzt man prozedural, weil alle Methoden in der Klasse static sind, und somit keinen Objekt-Bezug haben. Die Klasse fungiert dann nur noch als Namensraum... nicht optimal, aber so ist das.


Auch in C++ mußt du nichts in OO-Art lösen. Ja, selbst die ganzen Algorithmen der C++-Standard-Bibliothek sind keine Klassen, sondern Funktionen (allerdings Templates, aber die haben mit OO auch nichts am Hut).

Auch die ganzen C++-Standard-Container sind nicht wirklich OO, weil sie keine virtuellen Methoden haben. Die C++-Container machen sich aber der Datenkapselung nützlich. (also ein C-Struct, wo halt ein paar Members private sind) Ableiten/Erben von den C++-Containern kann sogar ins Auge gehen! So wenig OO sind sie.

Lediglich die IO-Streams der Std-Bibliothek und ein paar andere Dinge sind in C++ OO und ganz klassisch mit Late Binding designed. Aber in C++ wird alles so gemacht, wie es am besten lösbar ist. Man wird nicht z.B. zu OOP gezwungen. Es ist eine Multiparadigmen-Sprache.

Du kannst in C++ auch Metaprogrammierung betreiben, was in die komplett andere Richtung als OO geht: eher in Richtung Funktionale Programmierung! (nicht mit prozedural verwechseln)

Einfach mal ohne Vorurteil an die Werkzeuge rangehen. Man kann noch einiges lernen und seinen Horizont erweitern.

 

[exor.freebsd]

@Amin
Dann waeren wir also doch bei "Weil die Programmierer C am besten (laengsten) beherrschen?".

Ich stimme dir prinzipiell vollkommen zu. (Schade eigentlich dass mit dem C99 die C/C++-Kompatibilitaet gebrochen wurde). Dennoch kann es in der Realitaet anders aussehen. Auf manchen Plattformen sind C-Standardfunktionen noch immer wesentlich performanter implementiert als das C++-Equivalent! (Weis der Kukuk warum) Ich finde die Tests leider nicht mehr.

 

[exor.freebsd]

So, jetzt haben sich die Posts schonwieder ueberschnitten!

Schoen auf den Punkt gebracht. Ich erachte genau das Multi-Paradigmen-Konzept als grosse Staerke. Andere nennen es ja bekannterweise "mitschleppen von Altlasten".

Apropos Carmack: Es war fuer mich schon immer ein Raetsel, warum man eine Engine unbedingt in C statt C++ implementieren sollte. Sein Umschwung hatt imho auch mit den (heranwachsenden) Problemen von ogl zu tun.