C oder C++ zum Einstieg?

[marcellus]

Ok jetzt blick ich überhaupt nicht mehr durch, wieso ist openoffice dann so verdammt langsam und was für ein vorzeigeprogramm hat java, openoffice scheint ja auszuscheiden.

 

[Hello World]

Ok jetzt blick ich überhaupt nicht mehr durch, wieso ist openoffice dann so verdammt langsam und was für ein vorzeigeprogramm hat java, openoffice scheint ja auszuscheiden.

Eclipse finden ja viele Leute ganz supertoll, mir dagegen gefällt NetBeans besser, aber das ist u. a. Geschmacksache.

Und was oxcinshas Posting angeht: C hat zwar einen relativ geringen Sprachumfang, aber einfach zu überblicken? Nein, das ist C nicht. C ist eine inkonsistente Scheißsprache, die Fehler geradezu herausfordert, man denke nur an die (nicht so recht vorhandene) String-Behandlung in C. Ausführliche Begründung hier.

C++ soll objektorientiertes Programmieren fördern? Naja, ich zitiere einfach mal Alan Kay, einen der Väter der oo Programmierung:
"I invented the term object-oriented, and I can tell you I did not have C++ in mind."

Und auf C eine objektorientierte Struktur aufziehen? Klar, kann man machen. Man kann sich auch einen Tretroller kaufen und dann so lange drauf rumhämmern bis es wie eine 300PS-Ducati aussieht, das ist ungefähr genauso sinnvoll. Das tolle daran ist, dass man's auch einfach lassen kann...

 

[bitmuncher]

@Hello World: Wer so wie du gegen C/C++ wettert und "fremde" Argumente heranziehen muß um das zu begründen, hat ganz offensichtlich keine Ahnung. Schonmal in Java oder C# Inline-Assembler genutzt oder in einer dieser Sprachen ein minimales Betriebssystem geschrieben? Vielleicht auch einfach mal Hardware direkt damit angesteuert? Offensichtlich nicht, denn dann wüßtest du, was das für ein Krampf ist. Wer unter Linux kein C lernt und programmieren will, wird damit leben müssen, daß er niemals direkt ins System eingreifen kann. Das geht nunmal am einfachsten mit C, da der Kernel in C geschrieben ist.
Für Anwendungsentwicklung mögen streng objektorientierte Sprachen ihren Sinn machen (leichtere Wartbarkeit, besseres Management bei großen Projekten usw.), in der Systementwicklung sind sie aber nunmal großteils sinnlos, denn dort kommt es auf Performance an und nicht auf "da habt ihr tausende Vorschriften, an die ihr euch halten müßt" und "wir laden euch mal riesige Klassen, auch wenn ihr die nicht vollständig nutzt, RAM hat ja eh jeder genug". Was bringt mir eine Sprache, in der ich die Speicherverwaltung kaum bis garnicht beeinflussen kann, wenn ich ein System entwicklen will? Garnichts! Selbst bei M$ ist der Systemkern in C++ und Assembler geschrieben. Was denkst du wohl, warum sie kein C# dafür nutzen? Genau, weil es schlicht und einfach nicht möglich ist damit einen Systemkern zu schreiben.

Jede Sprache hat ihre Vor- und Nachteile und auch Sprachen, die strenge OO-Programmierung verlangen haben diese. Ein Java- oder C#-Entwickler will nur die Schwächen seiner "Lieblingssprache" genauso wenig sehen, wie ein C- oder C++-Entwickler und hier liegt das größte Problem. Oder kurz gesagt: Solche Fanatiker wie du, die nichtmal über ihren Tellerrand blicken und irgendwelchen Dogmen anderer Leute hinterher rennen, widern mich an.

Doch zurück zum Thema, denn hier wurde nach C oder C++ gefragt und nicht nach C/C++ und andere Sprachen. Würde ich mich heutzutage nochmal zwischen diesen beiden Sprachen entscheiden müssen, würde ich C++ bevorzugen, denn damit beherrscht man auch C. Wenn man sich erstmal an C gewöhnt hat, ist die Umstellung auf C++ wesentlich schwieriger als umgekehrt. So zumindest meine Einschätzung. Alle Sprachelemente von C gibt es auch in C++. Umgekehrt ist das nicht der Fall.

 

[marcellus]

Eclipse ist eine java Entwicklungsumgebung, die werd ich nicht wirklich kennen, wenn ich keine ahnung hab von Java. Es muss doch irgendein vorzeige java programm geben, dass jeder kennt. Wwi so bekannt wie open office, firefox, gimp, bash oder irgendwas das ich vllt schon mal zwischen den Fingern gehabt haben könnte.

 

[bitmuncher]

Die "Vorzeigeapplikation" für Java dürfte vermutlich derzeit der Looking Glass 3D-Desktop sein (lg3d). Hat aber auch noch seine Schwächen das Teil und beweist in guter Java-Manier, wie gut man RAM fressen kann. Auch der Bittorrent-Client Azureus ist in Java geschrieben. Aber ein wirklich überall bekanntes Programm, das in Java geschrieben wurde, fällt mir spontan nicht ein. Seine wirklichen Stärken zeigt diese Sprache eh nur bei Server-Applikationen wie JBoss u.ä. Bei Applikationen mit GUI hatte sie schon immer Probleme/Nachteile (vor allem was die Geschwindigkeit betrifft) gegenüber ähnlichen Applikationen in C++ oder C.

 

[Hello World]

@Hello World: Wer so wie du gegen C/C++ wettert und "fremde" Argumente heranziehen muß um das zu begründen, hat ganz offensichtlich keine Ahnung.

Welchen Grund gibt es, etwas nochmal aufzuschreiben, was jemand anders schonmal sehr gut formuliert hat? Aber gut, Du kannst gerne noch ein paar Gründe gegen C hören:

• Keine Unterstützung für generische Programmierung.
• Keine Möglichkeit, das Carry-Bit abzufragen und so auf arithmetische Überläufe zu reagieren.
• Keine Arrays, nur verkappte Zeiger.
• kein vernünftiges Modulsystem (nein, #include ist das nicht!)
• lächerliche Standardbibliothek
• nichtmal ein String-Datentyp
• total versupptes Typsystem

Schonmal in Java oder C# Inline-Assembler genutzt oder in einer dieser Sprachen ein minimales Betriebssystem geschrieben? Vielleicht auch einfach mal Hardware direkt damit angesteuert? Offensichtlich nicht, denn dann wüßtest du, was das für ein Krampf ist.

Wenn Assembler unbedingt nötig ist, kann man ja P/Invoke oder JNI für geschwindigkeitskritische Teile verwenden.

Wer unter Linux kein C lernt und programmieren will, wird damit leben müssen, daß er niemals direkt ins System eingreifen kann. Das geht nunmal am einfachsten mit C, da der Kernel in C geschrieben ist.

Das ist kein Argument für C, sondern gegen monolithische Kernel. Für hardwarenahe Programmierung gibt es wesentlich bessere Alternativen als C. Man denke an Ada, welches überall da eingesetzt wird, wo es auf unbedingte Stabilität ankommt, z. B. Militär, Flugsteuerung, Kernkraftwerke usw., und das hat verdammt gute Gründe. Es werden auch neue Low-Level-Programmiersprachen entwickelt, z. B. BitC

Für Anwendungsentwicklung mögen streng objektorientierte Sprachen ihren Sinn machen (leichtere Wartbarkeit, besseres Management bei großen Projekten usw.), in der Systementwicklung sind sie aber nunmal großteils sinnlos, denn dort kommt es auf Performance an und nicht auf "da habt ihr tausende Vorschriften, an die ihr euch halten müßt" und "wir laden euch mal riesige Klassen, auch wenn ihr die nicht vollständig nutzt, RAM hat ja eh jeder genug". Was bringt mir eine Sprache, in der ich die Speicherverwaltung kaum bis garnicht beeinflussen kann, wenn ich ein System entwicklen will? Garnichts!

Wenn Du mein Posting mal richtig gelesen hättest, wäre Dir vielleicht auch aufgefallen, dass es mir überhaupt nicht um prozedural vs. oo geht, im Gegenteil: Bei dem von mir geposteten Link wurde C mit Modula-2 verglichen, welches ebenfalls prozedural ist.

Selbst bei M$ ist der Systemkern in C++ und Assembler geschrieben. Was denkst du wohl, warum sie kein C# dafür nutzen? Genau, weil es schlicht und einfach nicht möglich ist damit einen Systemkern zu schreiben.

Blabla...
http://research.microsoft.com/os/singularity/
Da hast Du Dein OS in C#, und Du kannst Dir denken, dass man bei Microsoft nicht an Sachen forscht, die man nicht irgendwann verkaufen kann.

Jede Sprache hat ihre Vor- und Nachteile und auch Sprachen, die strenge OO-Programmierung verlangen haben diese. Ein Java- oder C#-Entwickler will nur die Schwächen seiner "Lieblingssprache" genauso wenig sehen, wie ein C- oder C++-Entwickler und hier liegt das größte Problem. Oder kurz gesagt: Solche Fanatiker wie du, die nichtmal über ihren Tellerrand blicken und irgendwelchen Dogmen anderer Leute hinterher rennen, widern mich an.

DU hältst an dem völlig idiotischen Dogma fest, dass Low-Level-Programmierung nur mit C möglich sei. Und wenn sich jemand erlaubt, C zu kritisieren, dann hörst Du nur das, was Du hören willst, statt mal zu lesen, was Dein Diskussionspartner *wirklich* geschrieben hat. Schau DU erstmal über DEINEN Tellerrand, bevor Du anderen unterstellst, das nicht zu tun.

Doch zurück zum Thema, denn hier wurde nach C oder C++ gefragt und nicht nach C/C++ und andere Sprachen.

Kein Kommentar...

Würde ich mich heutzutage nochmal zwischen diesen beiden Sprachen entscheiden müssen, würde ich C++ bevorzugen, denn damit beherrscht man auch C. Wenn man sich erstmal an C gewöhnt hat, ist die Umstellung auf C++ wesentlich schwieriger als umgekehrt. So zumindest meine Einschätzung. Alle Sprachelemente von C gibt es auch in C++. Umgekehrt ist das nicht der Fall.

Trotzdem ist es schlecht, in einem C++-Programm malloc() statt new zu benutzen, und das ist nur ein Beispiel, wo sich C und C++ grundlegend unterscheiden.

 

[bitmuncher]

@Hello World: Siehst du, genau das meinte ich... Du siehst "deine" Vorteile in OO-Programmierung, ich sehe aber durchaus auch Vorteile in Sprachen, die mir mehr Freiheiten lassen. Es ist einfach mal Fakt, daß _jede_ Sprache ihre Vor- und Nachteile hat und es eine reine Geschmackssache ist, welche man nutzt. Wenn du dich nicht um Speicherverwaltung kümmern willst, dann bittesehr, laß es halt, aber akzeptiere einfach, daß es Menschen gibt, die gern effektive Programme schreiben, die nicht unnötig Ressourcen fressen.

Wie dir sicherlich (oder vermutlich auch nicht) aufgefallen ist, habe ich u.a. darauf aufmerksam gemacht, wo OO-Sprachen ihre Vor- und Nachteile haben. Die Vorteile von C willst du ganz offensichtlich nicht sehen, sondern nur die Nachteile. Von daher halte ich jegliche weitere Diskussion mit dir für absolut sinnlos. Du gehörst nämlich zu den Menschen, die so auf ihr Dogma eingeschossen sind, daß sie andere Sichtweisen nicht akzeptieren. Außerdem zeigt mir deine Behauptung, daß es keine Arrays in C gäbe, daß du offenbar noch nie in C programmiert hast und daher ganz offensichtlich hier von etwas redest, wovon du keine Ahnung hast. Ich hoffe nur, daß du kein Linux benutzt, denn dort ist fast der komplette Kernel in "bösem C" geschrieben (der Rest ist "böses Assembler-Zeug"). Wir können uns aber gern mal auf der Kernel-Mailingliste über Sinn und Unsinn von OO-Sprachen in der Systemprogrammierung unterhalten. Das Thema hatten wir zwar dort schon mehrfach, aber offenbar ist bei einigen immernoch nicht angekommen, warum z.B. der Linux-Kernel nicht in einer OO-Sprache geschrieben ist.

Aber interessant zu wissen, daß es immernoch so engstirnige Leute wie dich da draußen gibt.

 

[Hello World]

@Hello World: Siehst du, genau das meinte ich... Du siehst "deine" Vorteile in OO-Programmierung,

Um die Postings anderer Leute auf eine Art und Weise zu ignorieren wie DU es tust, bedarf es schon einiger Übung auf diesem Gebiet. Aber Leute wie Du hören halt nur das, was sie hören wollen, damit sie den Diskussionspartner hinterher möglichst gut als engstirnigen Fanatiker Darstellen können.
Hier jedenfalls nochmal ein Zitat aus meinem letzten Posting:

Wenn Du mein Posting mal richtig gelesen hättest, wäre Dir vielleicht auch aufgefallen, dass es mir überhaupt nicht um prozedural vs. oo geht,

Dann weise ich nochmal auf meine (unvollständige!) Liste mit Nachteilen von C hin. *Kein einziger* davon bezieht sich auf die prozedurale Natur von C.

ich sehe aber durchaus auch Vorteile in Sprachen, die mir mehr Freiheiten lassen.

Die von mir genannten Nachteile haben auch nichts mit "mehr Freiheiten" zu tun. Man könnte *jedes* dieser Features auch implementieren *ohne* dem Programmierer irgendwelche Freiheiten zu nehmen.

Es ist einfach mal Fakt, daß _jede_ Sprache ihre Vor- und Nachteile hat und es eine reine Geschmackssache ist, welche man nutzt.

Das ist kein Fakt, sondern ein weiteres Deiner Dogmen. Es gibt durchaus objektive Kriterien, nach denen man eine Sprache bewerten kann

Wenn du dich nicht um Speicherverwaltung kümmern willst, dann bittesehr, laß es halt, aber akzeptiere einfach, daß es Menschen gibt, die gern effektive Programme schreiben, die nicht unnötig Ressourcen fressen.

Du legst mir hier Sachen in den Mund, die ich nie gesagt habe! Weder in meiner Liste von Nachteilen von C noch auf der verlinkten Seite wurde je die manuelle Speicherverwaltung kritisiert.

Wie dir sicherlich (oder vermutlich auch nicht) aufgefallen ist, habe ich u.a. darauf aufmerksam gemacht, wo OO-Sprachen ihre Vor- und Nachteile haben. Die Vorteile von C willst du ganz offensichtlich nicht sehen, sondern nur die Nachteile.

C hat außer der weiten Verbreitung keine Vorteile gegenüber moderneren Low-Level-Sprachen wie Ada.

Außerdem zeigt mir deine Behauptung, daß es keine Arrays in C gäbe, daß du offenbar noch nie in C programmiert hast und daher ganz offensichtlich hier von etwas redest, wovon du keine Ahnung hast.

Wieder einmal reißt Du Äußerungen aus dem Zusammenhang und versagst völlig wenn es darum geht, das zu lesen was dasteht und nicht das, wovon Du gerne hättest, dass es dasteht. Hier nochmal meine Äußerung bzgl. Arrays in C:

Keine Arrays, nur verkappte Zeiger.

Schonmal gemerkt, dass viele Leute nicht int main(int argc, char* argv[]) schreiben, sondern int main(int argc, char** argv)? Ein Array in C *ist* ein verkappter Zeiger, mit dem kleinen Unterschied, dass der Speicher auf dem Stack reserviert wird statt auf dem Heap.
Hier nochmal ein paar äquivalente Schreibweisen zu a[j] mittels Zeigerarithmetik.

Ich hoffe nur, daß du kein Linux benutzt, denn dort ist fast der komplette Kernel in "bösem C" geschrieben (der Rest ist "böses Assembler-Zeug"). Wir können uns aber gern mal auf der Kernel-Mailingliste über Sinn und Unsinn von OO-Sprachen in der Systemprogrammierung unterhalten.

Ich gebs auf. Was hast Du nur für einen Komplex mit OO-Sprachen? Liest Du überhaupt die Postings anderer Leute, oder willst Du nur trollen?

<belanglosese Getrolle>

Du mich auch mal...

 

[Lord Kefir]

Ist euch schon mal aufgefallen, dass ab einem bestimmten Erfahrungslevel die Sprache zur totalen Nebensache wird?

Gruß, Lord Kefir

 

[Hello World]

Ist euch schon mal aufgefallen, dass ab einem bestimmten Erfahrungslevel die Sprache zur totalen Nebensache wird?

Gruß, Lord Kefir

Und genau aus diesem Grund sollte sie so einfach, transparent und unauffällig wie möglich sein.

 

[Lord Kefir]

Und genau aus diesem Grund sollte sie so einfach, transparent und unauffällig wie möglich sein.

Falsch - genau aus diesem Grund ist es scheiß egal mit welcher Sprache Du arbeitest.

Davon abgesehen denke ich nicht, dass es z.B. Deinen Arbeitgeber interessiert, welche Sprache Du ganz toll findest und welche blöd.

Gruß, Lord Kefir

 

[tr0nix]

Eclipse ist eine java Entwicklungsumgebung, die werd ich nicht wirklich kennen, wenn ich keine ahnung hab von Java. Es muss doch irgendein vorzeige java programm geben, dass jeder kennt. Wwi so bekannt wie open office, firefox, gimp, bash oder irgendwas das ich vllt schon mal zwischen den Fingern gehabt haben könnte.

Ich denke du findest beeindruckende Java-Applikationen eher im J2EE (http://de.wikipedia.org/wiki/J2EE) Bereich als auf dem Home Desktop. Kommt z.B. in Online-Banking Applikationen vor. Hier in der Bank haben wir praktisch ausschliesslich J2EE Applikationen und die rocken teilweise echt.. und sind auch schnell.

War auch nie Java Freund weil es eine Zeit gab, wo jede Website ein Java Applet haben musste und mein Browser ständig den Geist aufgab deshalb. Von dort kommt auch das Gerücht, dass Java "langsam" sei. Unterdessen sehe ich Java sehr erfolgreich im Enterprise Einsatz und habe auch meine Meinung darüber überdacht (auch wenn ich es selbst überhaupt nicht gerne Programmiere.. lieber Perl .

//Edit: Eclipse ist übrigens schon lange nicht mehr eine nur-Java IDE, du kannst auch in vielen andere Sprachen damit entwickeln. Aber auch hier bevorzuge ich vi für meine kleinen Tools

 

[bitmuncher]

[ein letztes Offtopic]

... oder willst Du nur trollen?
...
Du mich auch mal...

Nett, wenn ein Troll mir vorwerfen will hier rumzutrollen Du hast einen stressigen Tag wunderbar erheitert. Ich mußte fast aufpassen, daß unser Projektleiter nicht vom Stuhl fällt vor lachen. Danke dafür.

Im Internet werden jene Menschen als Troll bezeichnet, die „Beiträge“ verschicken, mit denen sie erkennbar provozieren wollen, ohne einen wirklichen Beitrag zur Diskussion zu leisten.

Nichts anderes tut schon dein erster Beitrag in diesem Thread. Wie man in der Schule damals sagte. "Thema verfehlt. 6. Setzen."

Schließen wir die Diskussion damit ab. Die gehört hier nicht her.

[/ein letztes Offtopic]

[Ontopic]
Bevor ich hier aber wirklich in's Trollen verfalle, möchte ich nochmal zu C++ raten. Ja, es gibt Unterschiede zwischen C und C++, was die Art des Programmierens und die Strukturierung der Programme angeht. Trotzdem beinhaltet C++ alle Sprachelemente, die C hat. Die Umstellung von C++ zu C ist daher einfacher als umgekehrt. Außerdem ist C++ für die Anwendungsentwicklung aufgrund seines objektorientierten Angangs gerade für Anfänger einfacher, da man nicht so schnell den Überblick verliert. Hinzu kommt, daß große Applikationen in Klassen aufgeteilt werden können, für die der Projektleiter in Zusammenarbeit mit den Entwicklern feste Interfaces definiert, so daß die Verteilung der Entwicklung auf mehrere Entwickler vereinfacht wird. Es spielt dann keine Rolle mehr, wie die Funktionen innerhalb der Klasse arbeiten und welche Parameter sie brauchen, solange die public-Funktionen sich an die vorher festgelegte Interface-Definition halten und die Daten rausgeben, die erwartet werden. Sicherlich läßt sich ähnliches auch mit C umsetzen (wie der Linux-Kernel beweist), aber 1. ist der Aufwand größer und 2. bedarf es einiger Erfahrung um eine saubere modulare Struktur mit einer prozeduralen Sprache wie C umzusetzen.

[/Ontopic]

Im übrigen ist der Linux-Kernel schon seit Version 2.6 nicht mehr als strikt monolithisch zu bezeichnen, sonst würde nämlich das komplette System abstürzen, wenn mal ein Treiber-Modul versagt. Man kann ihn monolithisch erstellen, muß es aber nicht. Wenn man es tut, hat man einen schnelleren, aber auch anfälligeren Kernel. Tut man es nicht und bindet alle Treiber/Hardware-Unterstützungen als Modul ein, ist er zwar etwas langsamer, dafür spielt es dann aber auch keine Rolle mehr, wenn mal ein einzelner Treiber Fehler verursacht, solange es nicht einen Treiber für elementare Funktionen (HD-Zugriff u.a.) des Rechners betrifft. Das nur als Nachtrag zu "Das ist kein Argument für C, sondern gegen monolithische Kernel." (Zitat von Hello World als Reaktion darauf, als ich sagte, daß man für die Kernel-Entwicklung unter Linux C benötigt.). Ich hoffe, daß ich nicht der einzige bin, der keinen Sinnzusammenhang in seiner Äußerung sieht.

 

[Thomas80]

Eclipse ist eine java Entwicklungsumgebung, die werd ich nicht wirklich kennen, wenn ich keine ahnung hab von Java. Es muss doch irgendein vorzeige java programm geben, dass jeder kennt. Wwi so bekannt wie open office, firefox, gimp, bash oder irgendwas das ich vllt schon mal zwischen den Fingern gehabt haben könnte.

Schon mal was von UML Tools gehört.
Viele von denen sind in Java programmiert :

z.B. ArgoUML, Magic Draw, PoseidonUML, Visual Paradigm, IBM Rational Rose ( auf Eclipse basierend)....

Die neue Version von Lotus Domino (Outlook Konkurrenzprodukt) basiert ebenfalls auf Eclipse RCP. Damit sind Anwendungen eigentlich so schnell wie native Anwendungen.




Zum Thema :

In 50 Jahren ist es eh egal, in welcher Sprache man programmiert. Denn dann wird nicht mehr objektorientiert/komponentenorientert programmiert, sondern vielmehr modellorientert.

Der Softwareentwickler entwirft Modelle und wirft einen Transformator an. Dieser Transformator übersetzt das Modell in die gewünschte Sprache...

 

[bitmuncher]

In 50 Jahren ist es eh egal, in welcher Sprache man programmiert. Denn dann wird nicht mehr objektorientiert/komponentenorientert programmiert, sondern vielmehr modellorientert.

Der Softwareentwickler entwirft Modelle und wirft einen Transformator an. Dieser Transformator übersetzt das Modell in die gewünschte Sprache...

Nunja, derzeit bezweifel ich noch, ob sich das durchsetzen kann, da die meisten Programmierer sich dagegen sträuben. Wir machen in unserer Firma gerade die ersten Erfahrungen mit NetCCM und unsere Entwickler sind alles andere als begeistert davon. Solange es da keine Standards gibt, wird es schwierig diese Technologie einzuführen, da ein Entwickler für sein Produkt immer auf eine Entwicklungsumgebung angewiesen ist. Würde ich jetzt z.B. ein OpenSource-Projekt mit NetCCM umsetzen, bräuchte jede/r, der/die mitentwickeln will, auch NetCCM. Er/Sie könnte also nicht mehr zur Lieblings-IDE greifen, sondern müßte sich erstmal in eine Software neu einarbeiten, der er/sie bisher evtl. noch nie benutzt hat. Hinzu kommt, daß die meisten Entwickler wissen wollen, wie der Source aussieht um z.B. Optimierungen besser durchzuführen. Mit solchen Tools ist Optimierung aber nur noch bedingt möglich. Darin sehen bei uns die Leute die größte Schwäche. Sie müßten eine Software grundlegend in dieser Entwicklungsumgebung umsetzen und danach optimieren. Ist die Optimierung abgeschlossen, treten Probleme auf, wenn man dann z.B. für eine Erweiterung wieder zum Modellierungstool greifen will.
Wobei ich wirklich hoffe, daß sich diese Technik durchsetzt, da sie dem Prinzip des RAD (Rapid Application Development) sehr zugute kommen würde. Allerdings denke ich, daß sie erstens nur in der Anwendungsentwicklung eingesetzt wird und zweitens müßte sie sich schon binnen der nächsten 10 Jahre durchsetzen. In 50 Jahren werden wir hoffentlich schon die ersten Quantencomputer haben. Dann wird vermutlich eher in Zuständen programmiert als in Modellen.

 

[enr00]

ciht so vulgär bitte sähr

C ist eine inkonsistente Scheißsprache

Ich habe zwar noch keine Ahnung von C, bin aber der Meinung, dass ein Minimum an Respekt gegenüber der Sprache und deren Nutzern angebracht ist...

 

[musiKk]

Also um es salopp auszudruecken, geht mir diese Fehde hier gehoerig auf den Sack. Diese ellenlangen "ich zitiere jetzt mal alles von dir und widerlege es einzeln"-Diskussionen bringen den Forennutzern nichts. Sowas nach PM verlagern...

Und ueberall ein "imho" hindenken bitte.

 

[Thomas80]

Nunja, derzeit bezweifel ich noch, ob sich das durchsetzen kann, da die meisten Programmierer sich dagegen sträuben. Wir machen in unserer Firma gerade die ersten Erfahrungen mit NetCCM und unsere Entwickler sind alles andere als begeistert davon.

Interessanter Link...ich werd mir mal die Testversion runterladen und ausprobieren, was es mehr kann als AndroMDA

Solange es da keine Standards gibt, wird es schwierig diese Technologie einzuführen, da ein Entwickler für sein Produkt immer auf eine Entwicklungsumgebung angewiesen ist.

MDA ist ein Standard für die modellgetriebene Entwicklung.

Und eine (Teil)Implementierung dieses Standards ist z.B. AndroMDA.

Ich durfte während meines Praktikums bei Lufthansa eine Java-Anwendung ( auf Hibernate und Strut basierend) mehr oder weniger zusammenklicken.

Bei standardisierten Dingen (z.B. MVC Controller) funktioniert der modellgetriebene Ansatz ganz gut. Eine solche Applikation händisch per Code zu schreiben, würde zehnmal so lange dauern und wäre deutlich fehleranfälliger.

Würde ich jetzt z.B. ein OpenSource-Projekt mit NetCCM umsetzen, bräuchte jede/r, der/die mitentwickeln will, auch NetCCM. Er/Sie könnte also nicht mehr zur Lieblings-IDE greifen, sondern müßte sich erstmal in eine Software neu einarbeiten, der er/sie bisher evtl. noch nie benutzt hat.

Deshalb müssen sich solche Tools auch an die IDE anpassen. In Eclipse gibts ganz brauchbare Plugins für OpenArchitectureWare; ebenfalls eine MDA Implementierung

Hinzu kommt, daß die meisten Entwickler wissen wollen, wie der Source aussieht um z.B. Optimierungen besser durchzuführen. Mit solchen Tools ist Optimierung aber nur noch bedingt möglich. Darin sehen bei uns die Leute die größte Schwäche.

Das stimmt schon. Aber die Leute, die an diesen MDA-Tools arbeiten, sind derzeit gespalten :
Man kann Änderungen in der Metaebene ( also direkt am Modell) durchführen und dann nochmals den Code generieren oder man gibt im Modell/Code "protected regions " an, die für die nachträgliche manuelle Bearbeitung dienen.

Ist die Optimierung abgeschlossen, treten Probleme auf, wenn man dann z.B. für eine Erweiterung wieder zum Modellierungstool greifen will.

Die Leute von OMG haben sich auch für dieses Problem Gedanken gemacht. Deshalb findet die Modellierung immer auf mindestens zwei Abstraktionsebenen statt. Da wäre das Modell und dann gibts das Modell, welches das Modell beschreibt (Metamodell). Dadurch kann man das Modell auch nachträglich erweitern. Stichwort MOF.

 

[bitmuncher]

Werde mir das AndroMDA mal anschauen und den Link an unsere Entwickler weiter leiten. Evtl. wäre das ja eine Alternative. Danke für diese zusätzlichen Infos, aber laß uns den Thread nicht abdriften lassen. Die Stichworte in deinem Beitrag werden mich dank Google bestimmt zu weiteren Infos zum Thema führen.

 

[Hello World]

Du hast einen stressigen Tag wunderbar erheitert. Ich mußte fast aufpassen, daß unser Projektleiter nicht vom Stuhl fällt vor lachen. Danke dafür.

Dein Verhalten ist klassisch für jemanden, der offensichtlich keine Argumente mehr hat. Wer wirklich Ahnung hat, der ist auch bereit das einzugestehen. Leute wie Du dagegen versuchen, den Diskussionspartner lächerlich zu machen...

Im übrigen ist der Linux-Kernel schon seit Version 2.6 nicht mehr als strikt monolithisch zu bezeichnen, sonst würde nämlich das komplette System abstürzen, wenn mal ein Treiber-Modul versagt. Man kann ihn monolithisch erstellen, muß es aber nicht. Wenn man es tut, hat man einen schnelleren, aber auch anfälligeren Kernel. Tut man es nicht und bindet alle Treiber/Hardware-Unterstützungen als Modul ein, ist er zwar etwas langsamer, dafür spielt es dann aber auch keine Rolle mehr, wenn mal ein einzelner Treiber Fehler verursacht, solange es nicht einen Treiber für elementare Funktionen (HD-Zugriff u.a.) des Rechners betrifft.

Das ist von vorn bis hinten kompletter Schwachsinn. Zunächst mal gibt es die Möglichkeit, Teile des Kernels in Module auszulagern, schon viel länger als Linux 2.6. Ferner ist es ist völlig egal, ob Du einen Treiber als Modul oder direkt in den Kernel kompilierst. Solange ein Treiber nicht in einem separaten Adressbereich ausgeführt wird (sprich: in einem separaten Prozess), kann auch prinzipiell jeder Treiber jeden anderen stören oder das System zum Absturz bringen. Linux ist monolithisch, und das lässt sich auch nicht ändern, ohne _sehr_ große Teile des Kernels neu zu schreiben. Außerdem hält Linus Torvalds nicht viel von Microkernel-Systemen, weswegen das nicht passieren wird.
Übrigens führt im Gegensatz zu Deinen Behauptungen auch nicht jeder Fehler in einem Treiber gleich zu einem Systemabsturz.

Das nur als Nachtrag zu "Das ist kein Argument für C, sondern gegen monolithische Kernel." (Zitat von Hello World als Reaktion darauf, als ich sagte, daß man für die Kernel-Entwicklung unter Linux C benötigt.). Ich hoffe, daß ich nicht der einzige bin, der keinen Sinnzusammenhang in seiner Äußerung sieht.

Na dann muss ich Dir wohl ein bisschen auf die Sprünge helfen. Ein Microkernel-System zeichnet sich dadurch aus, dass alles, was nicht absolut essenziell ist (sprich Speicher- und Prozessverwaltung sowie IPC) in separaten Prozessen läuft. Diese kommunizieren über wohldefinierte Protokolle miteinander, die sich - und das ist das wichtige - prinzipiell in jeder Sprache implementieren lassen. Und das ist ein gewaltiger Unterschied zu Linux, wo die Entwicklung von Treibern in anderen Sprachen als C praktisch kaum möglich ist (sieht man von FUSE ab, bei dem Dateisysteme im Userspace implementiert werden). Das Buildsystem, die Schnittstellen, einfach alles ist irgendwie C-spezifisch.