eXma » Diskutieren » Computer und Technik
Startseite - Veranstaltungen - Mitglieder - Suche
Vollständige Version anzeigen: Programmiersprachen
rakete
/edit by mod: ausgegliedert aus dem Thread suche guten c compiler wegen ausführlicher Abschweifung vom eigentlichen Thema
Zitat(aktsizr @ 31 Oct 2007, 23:27)
Halbtot? Was meinst du wohl wieviel von deinem LieblingsOS noch laufen würde, wenn die Nazis C verbieten würden? Pfff...
*


Ich wollte nicht C diffamieren... es wirkt nur kurios, das jemand ohne Programmierkenntnisse sich in eine (zumindestens nach Aussage meiner Lehrer) recht komplexen, aussterbenden, nicht-objektorientierte Programmiersprache einarbeiten muß...

sicher sind 99% aller Gnome Programme und Gnome selbst in C geschrieben, dies ist aber eher auf den Umstand zurückzuführen, daß die Entwicklung von Gnome nun schon ein paar Jahre im Gange ist und dort eher alteingesessene Programmierer am Werk sind...

Objektorientierte Sprachen sind eindeutig die Zukunft und auf lange Sicht werden auch die letzten C Programmierer aussterben oder auf C++, C#, Phyton und Java umsteigen...

oder seh ich das etwa komplett falsch? Ich laß mich gerne belehren, aber nur mit schlüssigen Argumenten wink.gif
SidKennedy
ot: weg von der objektorientierung - hin zur aspektorientierung...auch die objektorientierte programmierung wird so wie man sie bis heute noch kennt durch andere techniken abgelöst...zum beispiel vom code-weaving wie bei der aspekt-orientierten programmierung
rakete
Du unterstreichst mein Posting indem du mir zwischen den Zeilen zustimmst, auch wenn es auf den ersten Blick so aussieht als würdest Du mir wiedersprechen..

die aspektorientierte Programmierung steckt noch in den Babystiefeln und ist nicht als Alternative, sondern eher als eine konzeptionelle Weiterentwicklung der objektorientierten Ideologie zu sehen...
Killerspieler
Zitat(rakete @ 01 Nov 2007, 10:52)
Objektorientierte Sprachen sind eindeutig die Zukunft und auf lange Sicht werden auch die letzten C Programmierer aussterben oder auf C++, C#, Phyton und Java umsteigen...

oder seh ich das etwa komplett falsch? Ich laß mich gerne belehren, aber nur mit schlüssigen Argumenten wink.gif
*


Wie willst du denn bitte ein Betriebssystem in Java oder C# schreiben? Bei C++ geh ich noch mit, weil der intern auch nur C-Code erzeugt. Für manche Dinge gibt es eben Sprachen die einfach dafür passen, und das ist C für Betriebssysteme. Die werden nicht so einfach aussterben. Auch denk ich nicht, dass sich irgendeine andere Sprache durchsetzen wird um Software für Linux zu schreiben, eben weil C schon soweit etabliert ist.
rakete
hmm... das stimmt, c ist schon sehr nah an der Hardware, da kann vieles nicht mithalten...

aber werden nicht schon jetzt sehr viele Proggis für Linux in Phyton geschrieben? kenn die Sprache nicht, habs aber schon viel gelesen, besonders im Zusammenhang mit Red-Hat Linuxen...

Ich denke ich hab mich auch etwas sehr aus dem Fenster gelehnt, nach erneuten Recherchen bin ich zu dem Schluß gekommen, dass C in der unteren Betriebssystemschicht nicht wegzudenken ist (zumindestens nicht in absehbarer Zeit), somit ist klar das es c sein muß, wenn nah an der Hardware programmiert wird, was hier ja der Fall zu sein scheint...

sorry, ich bin halt Informatiker nah an der Anwendung, weit weg von der Hardware... smile.gif
aktsizr
AOP sehe ich nur als Erweiterung zu OOP Sprachen. Python wird auf RH nicht mehr oder weniger genommen als anderswo - damit lässt sich eben recht schnell etwas recht großes implementieren (z.B. eine Portage-/Paketverwaldung oder so). C wird wohl noch eine weile erhalten bleiben. Dort wo es 'eh dirty zugeht brauchste mit eigentlich OO gar nicht erst anfangen - da hilft dann nur noch Disziplin.
SidKennedy
generell ist es denkbar in jeder sprache alles mögliche zu programmieren. auch betriebssysteme. man braucht nur die passenden compiler, die am ende der compilier-kette eben maschinencode auswerfen wink.gif
mmarx
Java ist der letzte Dreck (gut, der Vorletzte, Cobol raeumt da ab): Class-obsessed und Pattern-obsessed.

Zitat
An apprentice software engineer approaches a Master software engineer and explains "I have been appointed lead on the next design effort. I will find unique and distinct ways of solving the problem. I have seen other implementations of the project application and I am sure I can do better." The Master merely shakes his head in pity and walks away.

A month later, the same apprentice approaches the master defeated and says "Master, the design is taking far too long. I feel like I am stuck on what should be the most trivial issues. Is there something you can give that can help me?" The Master smiles and presents the apprentice with a freshly printed copy of his latest PatternLanguage (written especially for efforts in which the apprentice was involved). The apprentice accepts the bound pages, perks up and walks away confidently.

Another month later, the same apprentice approaches the master gleefully waving the Master's PatternLanguage print-out and explains "Master, your patterns are wonderful! Not only did they give me new insight into how to solve my problems, but they imparted a great deal of wisdom on how many of my design issues were common and have been addressed time and time again by other masters. In fact, I recently finished work on a tool to automate the application of your patterns. It will be as simple as picking the right patterns and telling the tool to generate code. My manager thinks that it's great and he says that all new projects will design their applications using the tool. You, sir, are a hero!"

At this, the Master promptly takes his bound copy of the PatternLanguage away from the apprentice and rips it to shreds. He then angrily casts the torn papers to the floor, shakes his head disapprovingly, sighs, and walks away.

(KoansMetaphorsAndParables)


Aber Hautpsache ist halt, man treibt den Java-Hype weiter und stempelt erstmal alles, was nicht-objektorientiert, dafuer aber international standardisiert ist, als boese ab.
SidKennedy
und hast du auch eine eigene meinung zu dem thema?
rakete
thema war doch eigentlich: "suche gute c entwicklungsumgebung für Linux"

meine Frage war dann: warum mit c anfangen? ist doch viel leichter mit z.B. java einzusteigen

Antwort war: weils für die Uni c sein muß...

damit ist die Diskussion doch hinfällig, das hier ist perse kein Thread über objektorientiert vs. nicht-objektorientiert... dafür könnte man allerdings einen eigenen Thread aufmachen...
loco
mmarx for president..
the man knows what he talks about lol.gif
stabilo
Jo. Scheint so.
"Class-obsessed und Pattern-obsessed".

Erklär mal bitte, warum es schlecht ist, dass eine Sprache rein objektorientiert ist. Und den Nachteil von Patterns musst du mir auch erklären.
stth
das einzige, was wirklich scheiße an c++ ist, ist die stl-bibliothek. die lässt einen nicht gerne machen, so wie man will und alles als std::[stlcontainerihresvertauens]<type*> zu deklarieren macht absolut keinen spaß. SO. wobei ich c++ für standardaufgaben, die viel speicheraufkommen sofort gegen java tauschen würde, wenn es dort einen delete-operator gäbe. grund: freundlichere compilerfehlerausgaben.


m&m arks: jede sprache für seinen zweck.
programmier mal hochparallel ohne fortran
programmier mal hardwarenah oder echtzeitanwendungen ohne assembler/c
....

deine quelle lässt übrigens schlimmes ahnen biggrin.gif
mmarx
Class-obsessed geht weiter als nur reine Objektorientierung; insbesondere zwingt einem Java auf, wie man sein Programm zu organisieren hat (naemlich in Klassen, und dabei jede Klassen in eine eigene Datei et cetera).

Patterns an sich sind einfach mal deshalb scheisse, weil wiederkehrende Muster in Quelltexten _voellig unterschiedlicher Programmen_ bedeuten, dass die Sprache (oder die Programmierer) an dieser Stelle defizitaer ist, ansonsten gaebe es ja irgendein Feature, mit dem man diese Muster beseitigen kann.

Sun straeubt sich zum Beispiel, mal const in Java zu integrieren, weil es da diverse Patterns gibt, mit denen man das nachbauen kann (ist ja kein Ding, wenn man da statt einem Schluesselwort pro Methode ein komplettes Interface fuer braucht, man hat ja eine gute IDE und die Zielgruppe wird sich schon nicht beschweren).
stth
Zitat(mmarx @ 01 Nov 2007, 17:57)
Class-obsessed geht weiter als nur reine Objektorientierung; insbesondere zwingt einem Java auf, wie man sein Programm zu organisieren hat (naemlich in Klassen, und dabei jede Klassen in eine eigene Datei et cetera).

Patterns an sich sind einfach mal deshalb scheisse, weil wiederkehrende Muster in Quelltexten _voellig unterschiedlicher Programmen_ bedeuten, dass die Sprache (oder die Programmierer) an dieser Stelle defizitaer ist, ansonsten gaebe es ja irgendein Feature, mit dem man diese Muster beseitigen kann.

Sun straeubt sich zum Beispiel, mal const in Java zu integrieren, weil es da diverse Patterns gibt, mit denen man das nachbauen kann (ist ja kein Ding, wenn man da statt einem Schluesselwort pro Methode ein komplettes Interface fuer braucht, man hat ja eine gute IDE und die Zielgruppe wird sich schon nicht beschweren).
*


DANN NIMM DOCH WAS WAS DAS SO TUT UND NICHT java. MANN!
loco
tja er muss wohl unbedingt java nehmen, es wird ja schließlich 'gehyped' lol.gif
stth
jo noch ein vorteil von java: gegenseitiger auschluß von threads in einer routine nur mit einem schlüsselwort: synchronized. wenn ich da an das mutex- und signalgeflexe in c denke.

€ i came to the . and then forgot it...
mmarx
Zitat(stth @ 01 Nov 2007, 18:06)
DANN NIMM DOCH WAS WAS DAS SO TUT UND NICHT java. MANN!
*


Tu ich doch auch; ich meckere nur trotzdem ueber Java. :P
stth
dann is ja gut
tingel
Zitat(mmarx @ 01 Nov 2007, 17:57)
...
Patterns an sich sind einfach mal deshalb scheisse, weil wiederkehrende Muster in Quelltexten _voellig unterschiedlicher Programmen_ bedeuten, dass die Sprache (oder die Programmierer) an dieser Stelle defizitaer ist, ansonsten gaebe es ja irgendein Feature, mit dem man diese Muster beseitigen kann.

Nehmen wir z.B. mal das Proxy Pattern - soll dafür jetzt ein Konstrukt in die Sprache eingeführt werden?
Zitat
Sun straeubt sich zum Beispiel, mal const in Java zu integrieren, weil es da diverse Patterns gibt, mit denen man das nachbauen kann (ist ja kein Ding, wenn man da statt einem Schluesselwort pro Methode ein komplettes Interface fuer braucht, man hat ja eine gute IDE und die Zielgruppe wird sich schon nicht beschweren).
*

Konstanten in einem Interface unterzubringen ist kein Pattern im eigentlichen Sinne. Dafür ein neues Schlüsselwort in die Sprache zu integrieren wäre vollkommen redundant und Redundanz in einer Sprache führt zu unsauberen, schlecht lesbaren Code.

Wenn du dein Programm nicht in Klassen unterteilen willst und einen großen Klotz in Java haben willst - bitte schön. Machst du dir eine einzige statische Klasse Main und kippst dort deinen Code rein - sinn macht das zwar keinen, aber du hast ja die Wahl wink.gif
mmarx
Es geht nicht um Konstanten, sondern um konstante Methoden; insbesondere darum, const correctness zu erzwingen. Und dafuer lohnt sich ein Schluesselwort sehr wohl.
stabilo
Zitat(mmarx @ 01 Nov 2007, 17:57)
Class-obsessed geht weiter als nur reine Objektorientierung; insbesondere zwingt einem Java auf, wie man sein Programm zu organisieren hat (naemlich in Klassen, und dabei jede Klassen in eine eigene Datei et cetera).

Patterns an sich sind einfach mal deshalb scheisse, weil wiederkehrende Muster in Quelltexten _voellig unterschiedlicher Programmen_ bedeuten, dass die Sprache (oder die Programmierer) an dieser Stelle defizitaer ist, ansonsten gaebe es ja irgendein Feature, mit dem man diese Muster beseitigen kann.
*


Übrigens gibt es noch andere Sprachen, die dir Objektorientierung vorschreiben. Mecker doch mal über Smalltalk..

Den zweiten Absatz versteh ich echt nicht. Warum ist die Sprache dann defizitär? Und was ist an den Mustern scheiße?

Und wie stth schon sagte - die kannst gerne alles in eine riesengroße Klasse hauen und zig innere Klassen bauen. Ob das die Leserlichkeit vom Code erhöht, ist allerdings fraglich..
tingel
Zitat(mmarx @ 01 Nov 2007, 20:08)
Es geht nicht um Konstanten, sondern um konstante Methoden; insbesondere darum, const correctness zu erzwingen. Und dafuer lohnt sich ein Schluesselwort sehr wohl.

Kann es sein, daß du das willst, was in Java eine statische Methode ist, die auf keine member Variablen zugreifen kann?
Aus obiger Quelle:
Zitat
In addition, a method can be declared as const, indicating that calling that method does not change the object. Such const methods can only call other const methods and cannot assign member variables.
wicked
na, das c nicht so schnell aussterben wird hat sich ja jetzt geklaert cool.gif
zum lernen find ichs uebrigens tatsaechlich nicht schlecht... sollen die leute doch lieber erst mal alles selbst machen muessen eh sie vereinfachungen vorgeworfen bekommen.
Zitat(Killerspieler @ 01 Nov 2007, 11:36)
Wie willst du denn bitte ein Betriebssystem in Java oder C# schreiben? Bei C++ geh ich noch mit, weil der intern auch nur C-Code erzeugt. Für manche Dinge gibt es eben Sprachen die einfach dafür passen, und das ist C für Betriebssysteme. Die werden nicht so einfach aussterben. Auch denk ich nicht, dass sich irgendeine andere Sprache durchsetzen wird um Software für Linux zu schreiben, eben weil C schon soweit etabliert ist.
*

in c++ kannst du auch nicht direkt nen betriebssystem schreiben... schon allein die runtime und die teilweise undefiniertheiten von wegen initialisierung etc. sind da im wege.
was aber geht, und was ms eben grad mit singularity und c# macht, ist nen minimalen loader fuer allen benoetigten kram in c & assembler schreiben und damit die benoetigten .net teile in den speicher zu schieben... was low-level-kram und error-handling angeht kommen sie natuerlich trotzdem nicht um ein paar in c/asm/et al geschriebene module drumrum.


so... vielleicht sollte man wirklich mal nen eigenen thread fuer das thema aufmachen wink.gif
mmarx
Zitat(tingel @ 02 Nov 2007, 20:19)
Kann es sein, daß du das willst, was in Java eine statische Methode ist, die auf keine member Variablen zugreifen kann?*


Nur, dass ich das auch fuer nicht statische Methoden haben will.
tingel
Ah gut, verstehe. Wäre relativ einfach zu machen, weil nur der Compiler etwas strikter sein müßte - keine Änderungen an der virtuellen Maschine sind dazu nötig...aber brauchst du das so dringend? Irgendwas gibt es immer in irgend einer anderen Sprache, was man gerne hätte - das alles zu integrieren wäre aber am Ende katastrophal, weil vollkommen syntaktisch überfrachtet.
rakete
ausgegliedert aus "suche guten c compiler" aufgrund der Diskussionsentwicklung des Themas...
EnjoyTheChris
Die pauschale Kritik an Patterns ist ja geradezu lächerlich. Es gibt für jede höhere Programmiersprache Design Patterns. Wenn es ein echtes Design Pattern ist, dann ist es auch brauchbar; weil Design Patterns per se nicht unbrauchbar sein dürfen :P

Eine Sprache anhand eines einzigen nicht vorhandenen Features als unbrauchbar abzustempeln, zeugt von großer Weitsicht. Vor allem, wenn es um ein solch essenzielles Feature geht, was unbedingt gebraucht wird.

Wie dem auch sei, es klingt so, als könnte man das angesprochene Problem rein prinzipiell über Annotations lösen.

C'ya,

Christian
mmarx
Zitat(EnjoyTheChris @ 05 Nov 2007, 00:04)
Die pauschale Kritik an Patterns ist ja geradezu lächerlich. Es gibt für jede höhere Programmiersprache Design Patterns.*


Wenn die Sprache maechtig genug ist, dann kann man eben diese Muster weiter abstrahieren; guck dir einfach mal das LISP-Makrosystem an.

Ansonsten habe ich mit keinem Wort erwaehnt, dass Const-Correctness _das einzige_ Feature ist, was ich in Java vermisse.
EnjoyTheChris
Nicht, dass ich prophetisch sein möchte, aber keine Sprache wird je mächtig genug sein, als das sie nicht ohne Design Patterns auskommt; selbst aktuelle 4GL nicht.

Das liegt einfach in der Definition eines Design Patterns bgeründet; dazu sei dir einfach mal die entsprechende VL oder aber Christopher Alexander:The timeless way of Building empfohlen.

C'ya,

Christian
stabilo
Ich glaube bald, dass mmarx nicht wirklich weiß, was ein Design Pattern ist, und WIESO man diese entdeckt hat. Und dass Pattern absolut sprachenunabhängig sind. Und dass es nicht nur objektorientierte Patterns gibt.
Wie Chris schon sagte - mal eine VL zu dem Thema besuchen, könnte zur Aufklärung beitragen...