Haben Java und C# Programmierer weniger Verständnis von Computern als Programmierer, die mit ASM, C oder C++ arbeiten? Werden technisch komplexe Aufgaben eher mit ASM, C und C++ gelöst, und sind Java und C# eher geeignet, um mal schnell Desktop Programme zusammenzuklicken? Hab das Thema gerade mit Kollegen diskutiert (jeder hatte da eine andere Meinung) und würde mich für eure Meinung interessieren!
:
Verschoben durch User
Hallo, ich denke das hat was mit der Erfahrung zu tun nicht speziell mit der Programmiersprache. Sicherlich sind einige Sprachen hardware fremder, dennoch kommt man irgendwann nicht drum herum sich mit der grundlegenden Materie zu befassen. Grüße
Yeah, Popcorn! C/C++/C#/DELPHI/JAVA/PHP und wie der ganze Quatsch heißt sind keine Programmiersprachen, bestenfalls ein absolute unlustiger und durch ständiges Wiederholen nervtötender Treppenwitz der EDV-Geschichte, bei dem einen das Blut aus Augen und Ohren läuft. ASSEMBLER bzw. Codierung per HEX-Tastatur ist das einzig Wahre! Popcorn! :-)))
cc++c#java schrieb: > Haben Java und C# Programmierer weniger Verständnis von Computern als > Programmierer, die mit ASM, C oder C++ arbeiten? Nein. > Werden technisch komplexe Aufgaben eher mit ASM, C und C++ gelöst, und > sind Java und C# eher geeignet, um mal schnell Desktop Programme > zusammenzuklicken? Und nochmal Nein. > Hab das Thema gerade mit Kollegen diskutiert (jeder hatte da eine andere > Meinung) und würde mich für eure Meinung interessieren! Eine andere Problemstellung erfordert andere Lösungsansätze, daher gibt es auch andere Programmiersprachen. In den Grenzbereichen wo es an's Eingemachte geht, brauchst Du aber immer "Bitschupser" UND "Kästchenmaler".
Du möchtest hier ne Grundsatzdiskussion vom Zaune brechen, damit mal wieder die Fetzen so richtig fliegen, gelle? OK, Leinen los zur Schlammschlacht... Ich sag dazu, daß es wohl immer Softwareschreiber geben wird, denen ihr Geschreibsel und dessen spätere Anwendung im Grunde schnurz ist. Die lechzen immer nach noch größerem Abstand zur Hardware, wozu sie auch das Betriebssystem zählen. Das sind dann die Java- und C#####-Leute, denen es egal ist, daß ihre Kunden später Java in mehreren Geschmacksrichtungen oder Dotnet 2.0, 3.0, 3.5 und 4 alle parallel auf ihrem PC installieren und pflegen müssen, weil alles zueinander inkompatibel ist. Aber versuch mal, mit C++ "mal eben schnell" ein Programm mit Oberfläche zu schreiben. Oder gar in blankem C. Das geht zwar und es kommen auch effiziente kompakte Programme dabei heraus - aber nur dann, wenn man kein Dilettant ist und man sich mit dem API auskennt. Assembler wird am PC nur in speziellen Fällen benutzt, vor allem in Bibliotheken zu Compilern, wo noch echte Effektivität nötig ist. Die immer noch vorhandene und vergleichsweise effiziente Alternative zu all dem C-lastigen Zeugs ist Pascal in Form von Delphi und/oder Lazarus: Gute visuelle Klassenbibliothek, schneller Compiler, nativer und damit schneller Code, keinerlei fette Laufzeitumgebungen wie bei Java oder Dotnet nötig. W.S.
Um noch etwas Feuer unter der Popcorn-Pfanne zu machen: Assembler-Programmierer kennen sich in der Computer-Hardware sehr gut aus. Lisp-Programmierer kennen sich in unterschiedlichen Programmiertechni- ken sehr gut aus. C#-Programmierer kennen sich ... (Hmm, überleg, kopfkratz ..., ja wo denn? Mist, jetzt habe ich diesen Satz angefangen, also muss ich ihn auch zu Ende schreiben :-/) ... vielleicht in den GUI-Bibliotheken von Windows etwas aus. Anmerkung: Das alles ist zwar richtig, sollte aber trotzdem nicht todernst oder gar persönlich genommen werden :)
@Yalu: Kannst du bitte noch weitere Sprachen kommentieren? Bisher zeigst du ja eine ganz vernünftige Meinung. ;) Was ist der Unterschied zwischen C Programmierern, C++ Programmierern und welchen die den Unterschied C/C++ nicht kennen?
Yalu X. schrieb: > Lisp-Programmierer kennen sich in unterschiedlichen Programmiertechni- > ken sehr gut aus. Kannst du das mal ein wenig ausführen? Das würde mich wirklich interessieren. (Kein Sarkasmus - eigentlich tragisch, dass man sowas in einem _Diskussions_forum sogar explizit anmerken muss.)
C-Programmierer sind die besten, lieben die Hardware und beherrschen die Software sind intellektuell am höchststehendsten und freuen sich über Überraschungen wie z.B. eine Fliege, da die totale Beherrschung von C keinen Raum mehr für Überraschungen lässt und kennen Fehlermeldungen des Compilers nur vom Hörensagen und geh wech mit diesen bunten Pillen, ich will nicht schon wieder ...
ich finde es ja eine Frechheit! das Pascal noch nicht erwähnt wurde (ausser einmal kurz delphi) also: PASCAL ist die EINZIGE wahre Programmiersprache! (Pascal gibt es auch als Script Sprache, und man kann damit .Net Code erzeugen, und Java bytecode, und Iphone apps und MacOS Anwendungen usw. theoretisch zumindest ;-) und zwischendurch zur Auflockerung auch ein paar Funktionen in ASM schreiben, wenn man lustig ist..
Mein precompiler (Brain.exe) unterstützt nur asm. Allso kann das nur die einzig vernünftige Sprache sein.
Es gibt Sprachen, die sind IMO schon für "jedermann" entwickelt worden, d.h. haben nicht soviel (historischen/nerdigen) Ballast. Ich würde mal WuschelBasic (so halb), C# und Java dazurechnen. Das Problem ist halt nur, dass Sprachen, mit denen auch DAUs gut umgehen können, dann auch oft DAU-mässig benutzt werden. Die wagen sich dann gar nicht mehr an C/++ etc. ran, und damit steigt halt der Anteil der "auffälligen" DAU-Programme aus der Ecke. Mir hat zB. mal ein Mathematiker sein >10k LOC Java-Programm gezeigt, das sehr viel gerechnet hat und (damals mangels JIT&Co) schneckenlahm war. Ich hab mir das angesehen und eigentlich nichts Java-spezifisches gefunden, man hätte das fast ohne Änderungen auch genauso in C/++ machen können. Bis auf die I/O-Routinen hat er auch nichts aus der Java-API benutzt. Aber er meinte, dass er gar kein C könnte und es deswegen in Java gemacht hat. Effektiv hat ihn das wohl >3 Monate Rechenzeit gekostet. Naja, war nicht mein Problem ;) An sich stehe ich absonderlichen Sprachen eigentlich recht tolerant gegenüber, muss sie ja nicht nutzen. Aber Objective-C ist ja echt der letzte Dreck. Das ist quasi ein C++-Assembler, der so ziemlich alle schlechten Eigenschaften von C mit fehlenden positiven Eigenschaften von C++ kombiniert. War ja zu Zeiten OK (also Anfang der 90er), wo die C++-Compiler noch Probleme mit Templates&Co hatten, aber inzwischen gibt es eigentlich keine Existenzberechtigung mehr. Gäbe es nicht die Firma, die tolles HW/GUI-Design mit saumässig schlechter SW dahinter verkauft: Apple.
zuerst dachte ich du meinst das ernst..
aber:
> (damals mangels JIT
das hat dich entlarvt..
den gibt es seit Java 1.1
also (fast) von Anfang an..
(und nur weil 1997 java "langsam war", hat das mit HEUTE ja recht wenig
zu tun..)
Java sei für DAU ist natürlich auch sehr "popcorn" verdächtig...
Doch, war ernst gemeint. Bin halt schon etwas länger im Geschäft ;) War
so 98/99 rum, da gab es von Sun noch keinen ernstzunehmenden JIT.
Hotspot kam erst mit 1.4. Der sunwjit-Kram war AFAIR so ab 1.2 dabei, da
am Anfang aber auch noch nicht für Linux.
> Java sei für DAU ist natürlich auch sehr "popcorn" verdächtig...
Sagen wir mal so, ich beobachte verdächtig viele DAUs im Java-Bereich.
Die frickeln sich teilweise riesige Programme aus unzähligen bequemen
Frameworks zusammen, dass man eigentlich staunen muss. Dann sind sie
aber schon bei den billigsten Problemen total aufgeschmissen, weil sie
keinerlei Plan haben, was da eigentlich alles so werkelt und wie man
etwas strukturierter Fehler sucht.
Georg A. schrieb: > Sagen wir mal so, ich beobachte verdächtig viele DAUs im Java-Bereich. Paul Graham nennt dies das "Python Paradox": http://www.paulgraham.com/pypar.html Wo wir gerade auf Paul Grahams Webseite unterwegs sind, dort steht auch John Foderaros Antwort auf folgende Frage: P. M. schrieb: >> Lisp-Programmierer kennen sich in unterschiedlichen Programmiertechni- >> ken sehr gut aus. > > Kannst du das mal ein wenig ausführen? Das würde mich wirklich > interessieren. http://www.paulgraham.com/chameleon.html "Lisp is a programmable programming language." In Lisp ist praktisch nichts fix, nicht einmal die von vielen gehassten hundertfach verschachtelten Klammern. Entsprechend lässt sich die Spra- che an unterschiedliche Programmierstile, -techniken und -paradigmen anpassen. Echte Lisp-Programmierer tun dies sogar bei der Entwicklung ganz "gewöhnlicher" Anwendungsprogramme, je nach Bedarf und aktueller Laune mal mehr, mal weniger. Die Klammern lassen sie aber trotzdem meist unangetastet ;-)
so, jetzt wollte ich phyton lernen, und was ist das erste was ich auf
der Homepage lese:
>Python is an easy to learn, powerful programming language.
ein Satz mit x, war wohl ..
> In Lisp ist praktisch nichts fix, nicht einmal die von vielen gehassten > hundertfach verschachtelten Klammern. Wir hatten im Studium mal ein Lisp-Praktikum (naja, war Scheme, aber auch egal). Es ist recht erstaunlich, wie da im Hirn der Übergang von "was soll der Dreck" zu "geil" geht, wenn man mal nur ein paar Grundkonstrukte verstanden hat. Es gab damals eine Anbindung an die Motif-Widgets, damit war mit fast null Aufwand ruckzuck eine GUI da. Ich habe parallel versucht, das Motif-Zeug in C zu machen und habs dann aufgegeben, weil einfach nur hässlich. Die Übergabe von Attributen ist bei einer Listen-orientierten Sprache eben einfach nur eine Parameterliste. In C musste man das mühsam Element für Element zusammenbauen... BTW: Unter "nix is fix" würde wohl auch Forth fallen. Das spaltet wohl fast noch am meisten. Die einen lieben es und machen aber auch wirklich alles damit, die anderen hassen es.
Pascal (Lazarus/Delphi) ist DIE Sparache um PC Anwendungen zu schreiben. Hingegen C für die µC. Ich habe ein dickes Programm geschrieben (EleLa, Beitrag "EleLa - Elektronik Lagerverwaltung ab V2.0"), über 40000 Codezeilen und ich finde jede Routine innerhalb weniger Klicks. Das ist einfach ein System bei der das Designen der Oberfläche und der Quellcode richtig gut zusammen spielen. C++ (zumindest vor einigen Jahren noch) ist sowas von unmöglich. Wenn man da mehr als nur eine Message-Box progt, dann bekommt man schon einen dicken Hals. Delphi hat die meisten internen Routinen nahezu komplett auf Assembler umgeschrieben und die resultierende EXE ist die schnellste überhaupt. Nicht einmal M$ bekommt das hin. C, C++, C#, C##, Java usw. ja die haben auch die Daseinsberechtigung. /Kopfkratz ??? für was denn eigentlich ? /
Markus Müller schrieb: > Pascal (Lazarus/Delphi) ist DIE Sparache um PC Anwendungen zu > schreiben. Hingegen C für die µC. Ich habe ein dickes Programm > geschrieben (EleLa, Beitrag "EleLa - Elektronik Lagerverwaltung ab > V2.0"), über 40000 Codezeilen und ich finde jede Routine innerhalb > weniger Klicks. Ein Ketzer könnte jetzt behaupten: Wenn ein Programm mit dieser Funktionalität 40000 Zeilen groß wird, hast du dafür die falsche Programmiersprache gewählt. ;-) SCNR ... und das soll natürlich keinerlei Kritik an deiner Software sein.
Markus Müller schrieb: > Pascal (Lazarus/Delphi) ist DIE Sparache um PC Anwendungen zu schreiben. Naja, ich verstehe nicht, warum da nicht längst auf Oberon umgestellt wurde. Die Unterschiede sind für einfache Programme sehr gering, die Vorteile dagegen erheblich. Und schließlich programmiert ja auch kein Mensch mehr in dem C, das Kernighan einst vorgestellt hat. Markus Müller schrieb: > Hingegen C für die µC. Hmmh, mache ich fast umgekehrt. ;-)
Weil es zu Oberon nicht genügend Infos im Internet mit kostenlosen Demo-Programmen gibt. Alleine schon eine native Komponente für Datenbankanbindung zu finden die viele DB's unterstützt ist schon nahezu unmöglich. Oberon ist nur was für Studenten, bei denen der Lehrer nur sinnloses Zeugs beibringen will ohne Sicht auf die Zukunft. Wenn jemand komplexere Anwenungen schreiben will, dann braucht es etwas mehr als eine bunte Klick-Oberfläche. Mache mal den Vergleich mit google suche: "lazarus datenbank nativ" "oberon datenbank nativ" bei Oberon zeigt google nur sinnlose Einträge.
Hier kann man sich anhand des berühmten Hello-World-Programms selbst einen Überblick über die jeweiligen Programmiersprachen verschaffen: http://www.roesler-ac.de/wolfram/hello.htm Viel Spaß, Frank
>Hier kann man sich anhand des berühmten Hello-World-Programms selbst
mit "Hello-World" ?
das wäre so, als wolle man sich mit einer Aufstellung der verwendeten
Bremsleitungen einen Überblick über Autos verschaffen..
Robert L. schrieb: > das wäre so, als wolle man sich mit einer Aufstellung der verwendeten > Bremsleitungen einen Überblick über Autos verschaffen.. Dein Spaßdetektor ist defekt, schau Dir zum Beispiel Human oder Ook an ;-)
Markus Müller schrieb: > Weil es zu Oberon nicht genügend Infos im Internet mit kostenlosen > Demo-Programmen gibt. Genau das meine ich ja. Warum hatte nicht schon Borland auf Oberon umgestellt? Das es Sinn macht steht doch außer Frage und die C-Compiler werden ja auch regelmäßig den neuen Normen angepasst. Ebenso bei den OpenSource-Derivaten, eine 40 Jahre alte Sprache als Grundlage?
cc++c#java schrieb: ich habe 1990 rum angefangen mich mit computern zu beschäftigen. damals als freiwilliges wahlpflichtfach "informatik" in der schule. programmiert wurde unter dos mit turbo pascal. später habe ich ein wenig assembler gemacht.. den lzw algorithmus mal aus dem blauen heraus implementiert, nichts großes. dann kam lange nichts.... handwerksausbildung nach versemmeltem bio/chem studium. inzwischen arbeite ich als dba/sysadmin und java/plsql/perl/php entwickler und musste auch mal einen diassembler anwerfen um ein programm zu korrigieren. > Haben Java und C# Programmierer weniger Verständnis von Computern als > Programmierer, die mit ASM, C oder C++ arbeiten? deswegen habe ich den vorspann geschrieben - es kommt darauf an welche grundlagen vorhanden sind. klar kann ein asm programmierer auf register zugreifen und unheimlich kompakten code schreiben, aber zeitnah eine funktionalität implementieren für die ein hochsprachenentwichkler 10 zeilen code braucht dauert ewig und ist wartungsintensiv. > Werden technisch komplexe Aufgaben eher mit ASM, C und C++ gelöst, und > sind Java und C# eher geeignet, um mal schnell Desktop Programme > zusammenzuklicken? "technisch komplex"... was ist da die definition? du kannst mit allem komplexe aufgaben lösen und 500 byte assembler können komplexer sein als ein 5mb .jar file. als beispiel: ich werde in naher zukunft unser drucksystem neu implementieren. dazu muss ich aus einer oracle datenbank datensätze holen und diese in pdf-files einfügen... nicht nur adresse, sondern variabel lange listen, wiederholungsgruppen, barcodes, bilder etc. entwickeln werde ich auf amd64, laufen soll es auf sparc. so was will niemand mit asm machen, so was will vor allem niemand zu fuß machen und räder neu erfinden - hier kommen frameworks ins spiel die einem viel arbeit abnehmen: jdbc, itext, jasper, jasper-reports, swing... > Hab das Thema gerade mit Kollegen diskutiert (jeder hatte da eine andere > Meinung) und würde mich für eure Meinung interessieren! jeder kann das einschätzen was er kennt ;)
> Das es Sinn macht steht doch außer Frage warum? >und die >C-Compiler werden ja auch regelmäßig den neuen Normen angepasst. und Pascal nicht? Das was in Delphi und Lazarus aktuell verwendet wird, ist 1:1 genauso "nur" eine "Erweiterung" von Pascal (um Objekte, Interfaces, Generics, usw. usw.) ich sehe da keinen unterschied zu Oberon ein paar Kleinigkeiten sind wohl anders, aber was ist besser??? laut wiki werden Objekte so erzeugt: NEW (punkt1); was ja schon mal bescheuert ist..
Robert L. schrieb: >>C-Compiler werden ja auch regelmäßig den neuen Normen angepasst. > > und Pascal nicht? C wurde doch ständig weiterentwickelt, von K&R-C über ANSI-C zu C99. Die Compiler entsprechend angepasst. Wirth hat den Weiterentwicklungen halt neue Namen gegeben, also Modula und Oberon, sonst nicht viel anders als bei C. Die zugehörigen Weiterentwicklungen wurden von den Compilerherstellern aber schlichtweg ignoriert, anders als bei C. Das verstehe ich nicht. Robert L. schrieb: > ein paar Kleinigkeiten sind wohl anders, aber was ist besser??? Z.B. das Modulkonzept mit vollqualifizierenden Bezeichnern. Das Unitkonzept ist dagegen doch undurchdachter Krampf. Auch die Kleinigkeiten, wie z.B. der Verzicht auf die unsäglichen Klammerungen mit Begin und End und das (hallo Rufus;-)) pädagogische Verbot des Semikolons vor Else haben mich sofort davon überzeugt. Edit: Dass der Parameter einer Prozedur in Klammern steht, ist doch selbstverständlich.
"leider" findet man über oberon ja nicht viel, aber: hast du irgendwelche quellen, >Oberon, 2000 offiziell in ETH Oberon umbenannt, ist eine von Niklaus Wirth >und Jürg Gutknecht entwickelte da haben 2 Typen, ein bisschen am pascal herum geschraubt, das kann man ja wohl schlecht mit der entwicklung von C vergleichen warum soll das irgendwer übernehmen, ?? >Z.B. das Modulkonzept mit was meinst du genau hab gesehen, dass der interface teil weg ist, den find ich nicht so schlecht, hab man eine Übersicht, und der "doppelte" code wird eh meist automatisch generiert.. > vollqualifizierenden Bezeichnern versteh ich nicht >Edit: Dass der Parameter einer Prozedur in Klammern steht, ist doch >selbstverständlich. laut wiki http://de.wikipedia.org/wiki/Oberon_%28Programmiersprache%29 steht scheinbar, wenn es eine methode einer classe ist aber (auch) das objekt drinnen, ich sehe da keine Verbesserung, sondern einfach nur ein "krampfhaft anders machen" wollen.. oberon (was soll da eigentlich der *) PROCEDURE (linie: Linie) Zeichne*; pascal procedure TLinie.Zeichne;
Robert L. schrieb: > da haben 2 Typen, ein bisschen am pascal herum geschraubt, Naja, aber was für Typen? Robert L. schrieb: >>Z.B. das Modulkonzept mit > > was meinst du genau Module statt Units, die einander importieren können. Das konnte Pascal nicht, Wirth hat es in Modula eingeführt. Robert L. schrieb: >> vollqualifizierenden Bezeichnern > > versteh ich nicht Bezeichner aind eindeutig, weil ihnen beim Import der Modulname vorangestell wird. Z.B.: LCD.Writeln Robert L. schrieb: > laut wiki > > http://de.wikipedia.org/wiki/Oberon_%28Programmiersprache%29 > > steht scheinbar, wenn es eine methode einer classe ist aber (auch) das > objekt drinnen, Ja, in deinem Beispiel ist das punkt1. Es wird als variabler Parameter an die Prozedur NEW übergeben. Robert L. schrieb: > oberon (was soll da eigentlich der *) > > > PROCEDURE (linie: Linie) Zeichne*; Zeichne wird exportiert, das Sternchen ersetzt den Interfaceteil der Units. Robert L. schrieb: > "leider" findet man über oberon ja nicht viel, aber: > hast du irgendwelche quellen, Du brauchst nur die Sprachreferenz, wenn du in Pascal programmierst, reicht das völlig.
>Module statt Units, die einander importieren können. Das konnte >Pascal nicht, Wirth hat es in Modula eingeführt. Mit Freepascal kann man auch Programmteile in andere Dateien auslagern und "Includen", ohne Unit einbinden.
Guido B. schrieb: > Robert L. schrieb: >> da haben 2 Typen, ein bisschen am pascal herum geschraubt, > > Naja, aber was für Typen? keine Ahnung, aber scheinbar hat es sonst niemanden interessiert, weder "Normungsinstitute", noch Hersteller .. > > Robert L. schrieb: >>>Z.B. das Modulkonzept mit >> >> was meinst du genau > > Module statt Units, die einander importieren können. Das konnte > Pascal nicht, Wirth hat es in Modula eingeführt. > kann man Units auch, nur nicht beide jeweils im interface teil, was in der Praxis eher unproblematisch ist. > Robert L. schrieb: >>> vollqualifizierenden Bezeichnern >> >> versteh ich nicht > > Bezeichner aind eindeutig, weil ihnen beim Import der Modulname > vorangestell wird. Z.B.: LCD.Writeln > und wo ist der VORTEIL? solange es in Pascal eindeutig ist, schreibt man nur Wirteln hat man 2 schreibt man LCD.Writeln (man kann auch immer LCD.Writeln wenn einem das gefällt) > Robert L. schrieb: >> laut wiki >> >> http://de.wikipedia.org/wiki/Oberon_%28Programmiersprache%29 >> >> steht scheinbar, wenn es eine methode einer classe ist aber (auch) das >> objekt drinnen, > > Ja, in deinem Beispiel ist das punkt1. Es wird als variabler Parameter > an die Prozedur NEW übergeben. > nein, damit meinte ich nicht das NEW.. beim New(xy) ist das problem, dass man nicht sofort sieht von welcher Klasse das Objekt erzeugt ist,: pascal: var x: TStrings; begin x := TStringlist.Create; wie macht man das in oberon ? > Robert L. schrieb: >> oberon (was soll da eigentlich der *) >> >> >> PROCEDURE (linie: Linie) Zeichne*; > > Zeichne wird exportiert, das Sternchen ersetzt den Interfaceteil der > Units. > "schön" > Robert L. schrieb: >> "leider" findet man über oberon ja nicht viel, aber: >> hast du irgendwelche quellen, > > Du brauchst nur die Sprachreferenz, wenn du in Pascal programmierst, > reicht das völlig. ja, ich habe aber keine Sprachreferenz, hat google auf die schnelle nicht ausgespuckt
Markus Müller schrieb: > Pascal (Lazarus/Delphi) ist DIE Sparache um PC Anwendungen zu schreiben. > Hingegen C für die µC. Ist das der versteckte Anfang des Bashings in diesem bisher harmlosen Thread? ;-) Als Gegenpunkt kann ich sagen, dass ich regelmäßig in C#.NET programmiere und das (mittlerweile) sehr angenehm finde. Bevor ich damit angefangen habe, war ich auch eher ein .NET Hasser. Aber aufgrund des Jobs bin ich da eben reingerutscht. .NET ist der Microsoft-eigene State-Of-The-Art Weg um Windows Applikationen (und mehr) zu schreiben. Das Framework kommt aus dem gleichen Hause, wie das Betriebssystem und ist deswegen praktisch immer auf dem aktuellsten Stand und hat den größten Umfang. > Ich habe ein dickes Programm geschrieben (EleLa, > Beitrag "EleLa - Elektronik Lagerverwaltung ab V2.0"), über 40000 Codezeilen und > ich finde jede Routine innerhalb weniger Klicks. > Das ist einfach ein System bei der das Designen der Oberfläche und der > Quellcode richtig gut zusammen spielen. Was hat das mit der Programmiersprache zu tun? Meinst du damit vielleicht die Entwicklungsumgebung? > C++ (zumindest vor einigen Jahren noch) ist sowas von unmöglich. Wenn > man da mehr als nur eine Message-Box progt, dann bekommt man schon einen > dicken Hals. Was haben Message-Boxen mit C++ zu tun? Du vertauschst hier Dinge in ganz großem Stil. In C++ gibt es keine Message-Boxen. Ich vermute mal du meinst MFC, der C++ Wrapper für die Windows API. > Delphi hat die meisten internen Routinen nahezu komplett auf Assembler > umgeschrieben und die resultierende EXE ist die schnellste überhaupt. > Nicht einmal M$ bekommt das hin. Was meinst du damit? Interne Routinen auf Assembler umgeschrieben? What? > C, C++, C#, C##, Java usw. ja die haben auch die Daseinsberechtigung. > /Kopfkratz ??? für was denn eigentlich ? / Aha, also ist dein Post DOCH der versteckte Anfang des Bashings. Man sollte auch einsehen, dass die Wahl einer Programmiersprache zu einem Großteil am persönlichen Geschmack liegt.
Robert L. schrieb: > kann man Units auch, nur nicht beide jeweils im interface teil, was in > der Praxis eher unproblematisch ist. Oops, schon eine Einschränkung, weil das Konzept nicht durchdacht ist. Wenn nicht im Interfaceteil, macht es keinen Sinn! Robert L. schrieb: > und wo ist der VORTEIL? Wenn du größere Projekte hast und dein Module wiederverwendbar sein müssen, erkennst du den Vorteil sehr schnell. Robert L. schrieb: > begin > x := TStringlist.Create; > > > wie macht man das in oberon ? Genauso, das NEW steckt in der Methode Create. Robert L. schrieb: > ja, ich habe aber keine Sprachreferenz, hat google auf die schnelle > nicht ausgespuckt Hoppla, googel nach "Oberon-2 report" und such dir die passende Form aus, in der englischen Wikipedia sind die Links nur auf.ps-Dateien.
>Oops, schon eine Einschränkung, weil das Konzept nicht durchdacht ist. >Wenn nicht im Interfaceteil, macht es keinen Sinn! ich weiß jetzt nicht, ob du es verstanden hast: in Pascal kann man NICHT beide units jeweils in der anderen Unit im Interface teil "importieren" (was auch logisch ist) EINE der beiden natürlich schon, d.h. die units können sich gegenseitig importieren, wenn man es "vernünftig" macht, was , wie gesagt, in der Praxis keine problem ist.. im Gegensatz dazu sagt, zumindest ein buch auf google, das zykliche importe bei oberon-2 überhaupt nicht möglich sind.. ?! >> und wo ist der VORTEIL? >Wenn du größere Projekte hast und dein Module wiederverwendbar sein >müssen, erkennst du den Vorteil sehr schnell. in Delphi gibt seit Urzeiten "packages" (Indy, JCL, JCVL usw.) die von sehr vielen personen (wieder)verwendet werden ich sehe weiterhin keinen Vorteil.. "oberon-2 report" ok, da findet man was, umfang ist ja "überschaubar" http://www.excelsior-usa.com/doc/xds/o2rep.html das ganze hat die Entwicklung der letzten 10 Jahre einfach "verschlafen".. (ich glaube auch nicht, dass vor 10 jahren, dass auch nur irgendwie "fertig" war..)
Guido B. schrieb: > Robert L. schrieb: >> da haben 2 Typen, ein bisschen am pascal herum geschraubt, > > Naja, aber was für Typen? Typen, die die Welt mit ihren Sprachkreationen maschinengewehrgleich aus vollen Rohren über einen Zeitraum von fast vier Jahrzehnten beschossen haben? ;-) Hier ist eine (nicht unbedingt vollständige) Zusammenstellung der Programmiersprachen der Herren Wirth und Gutknecht: 1966: Euler 1966: Algol W 1972: Pascal 1976: Modula 1978: Modula-2 1986: Object Pascal 1990: Component Pascal 1991: Oberon 1998: Active Oberon 2002: Zonnon Nicht, dass ich die Arbeit der beiden nicht schätzen würde. Aber wer im Mittel alle 4 Jahre eine neue Programmiersprache "auf den Markt" wirft, darf sich nicht wundern, wenn nicht jede davon zum Renner wird. Die Anwender (also die Programmierer) müssen die Sprachen ja auch erst lernen und ihre bereits bestehende Codesammlung anpassen. Außerdem gibt es ja noch zig weitere Programmiersprachenentwickler auf der Welt, die ihre Werke ebenfalls unter die Leute bringen wollen. Schau dir mal diese Rangliste populärer Programmiersprachen an: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Jede Universalsprache, die es nicht unter die ersten 20 geschafft hat, hat wohl ihr Ziel nicht erreicht. Auf den Plätzen 21-100 sehe ich aber mindestens eine Handvoll weiterer Sprachen, die meiner Ansicht einen deutlich besseren Rang verdient hätten. Genauso gibt es ein paar unter den Top 20, die ich lieber unter "ferner liefen" sehen würde. Aber das Leben ist eben hart und ungerecht, und nicht immer gewinnt der Beste :) Zum Glück sind die Programmiersprachen auf den Plätzen 21-100 nicht verboten. Jeder kann sie nach seinem persönlichen Geschmack einsetzen, und für die meisten gibt es sogar kostenlose Entwicklungswerkzeuge. Also was soll's?
Yalu X. schrieb: > Aber wer im > Mittel alle 4 Jahre eine neue Programmiersprache "auf den Markt" wirft, > darf sich nicht wundern, wenn nicht jede davon zum Renner wird. Das ist ja gerade der Denkfehler. Es sind keine neuen Sprachen sondern die Entwicklung eines Konzeptes. Hierbei wurden neue Erfordernisse anerkannt, die bestehende Sprache um diese erweitert und, und das war vllt. der Fehler, ein neuer Name vergeben. Man muss wirklich keine neue Sprache lernen. Wer in Pascal programmiert, kann in Oberon genauso programmieren. Die paar Unterschiede hat er schnell raus. Er kann zusätzlich alle Erweiterungen nutzen, wie z.B. OOP, muss ja aber nicht.
Markus Müller schrieb: > C++ (zumindest vor einigen Jahren noch) ist sowas von unmöglich. Wenn > man da mehr als nur eine Message-Box progt, dann bekommt man schon einen > dicken Hals. Der erste C++Builder ist von 1997, andere Tools waren Anfang der 1990er auf dem Markt. > Delphi hat die meisten internen Routinen nahezu komplett auf Assembler > umgeschrieben und die resultierende EXE ist die schnellste überhaupt. > Nicht einmal M$ bekommt das hin. Delphi hat einen der am schlechtesten optimierenden Compiler (der bcc ist auf dem gleichen "Niveau") > > C, C++, C#, C##, Java usw. ja die haben auch die Daseinsberechtigung. > /Kopfkratz ??? für was denn eigentlich ? / Bessere Syntax scnr... Zumindest C# hat einige Features, die in den anderen genannten Sprachen nicht oder nur extrem umständlich machbar sind u.a. LINQ, Expression Trees, dynamische Codegenerierung, höhere Typsicherheit etc. BTW Delphi/Turbo Pascal und C# sind beide maßgeblich von Anders Hejlsberg entwickelt worden... Yalu X. schrieb: > Schau dir mal diese Rangliste populärer Programmiersprachen an: > > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Wenn man sich die Methodik mit der die Ergebnisse ermittelt werden ansieht, könnte man auch zu einem anderen Schluss kommen: Die Entwickler, die eine Sprache außerhalb der Top 10/20 nutzen, kennen die Sprachen und dazugehörigen Frameworks besser als der Rest, lesen und verstehen die Dokumentation usw...
Guido B. schrieb: > Man muss wirklich keine neue Sprache lernen. Wer in Pascal > programmiert, kann in Oberon genauso programmieren. Die paar > Unterschiede hat er schnell raus. Er kann zusätzlich alle > Erweiterungen nutzen, wie z.B. OOP, muss ja aber nicht. Ähnlich könnte man bei C und C++ argumentieren. Aber wenn jemand keine neue Sprache lernen will, weil er auf die Erweiterungen nicht sonderlich erpicht ist, kann er doch gleich bei Pascal bzw. C bleiben. > Hierbei wurden neue Erfordernisse > anerkannt, die bestehende Sprache um diese erweitert und, und das war > vllt. der Fehler, ein neuer Name vergeben. Ich finde, wenn eine Sprache nicht nur um ein paar syntaktische Feinhei- ten, sondern gleich um die Unterstützung neuer Programmierparadigmen (hier OOP) erweitert wird, sollte sie auch einen neuen Namen oder zumin- dest einen Namenszusatz bekommen. Bei C heißen die Nachfolger C++ und Objective-C, bei Pascal sind es eben Object Pascal (bzw. Delphi) und Oberon. Vielleicht hätte "Inc(Pascal)" (in Anlehnung an "C++") anstelle von Oberon dessen Verwandtschaft zu Pascal deutlicher gemacht :)
Wir drehen uns im Kreis. ;-) Yalu X. schrieb: > Bei C heißen die Nachfolger C++ und Objective-C, bei Pascal sind es eben > Object Pascal (bzw. Delphi) und Oberon. Eben, C hat sich genauso weiterentwickelt, abgesehen von C++ blieb aber der Name derselbe. Während Borland bei Turbo-C diese Entwicklung mitgegangen ist, hat sie diese bei Pascal ignoriert. So wurde Modula als erster Pascalnachfolger 1978 entwickelt, Modula-2 1983 veröffentlicht. Borland brachte 1987 das vermurkste Unitkonzept. Warum? Wir werden es wohl nicht rausfinden.
@Guido B.: Wir sollten vielleicht erst einmal bzgl. des Begriffs "Weiterentwick- lung" eine gemeinsame (natürliche) Sprache sprechen. Es gibt 1. Weiterentwicklung innerhalb einer Sprache 2. Weiterentwicklung in Form von Nachfolgersprachen Beispiele für (1) sind:
1 | - K&R-C ——> ANSI-C ——> ISO-C99 ——> ISO-C11 |
2 | |
3 | - Wirth-Pascal ———> UCSD-Pascal |
4 | |\ |
5 | | ——> Turbo-Pascal |
6 | |\ |
7 | | ——> ... |
8 | \ |
9 | ——> Standard-Pascal (ISO 7185) |
Beispiele für (2) sind:
1 | - C ——> C++ ———————————————— |
2 | \ \ \ |
3 | ——> Objective-C ——> Java ——> C# |
4 | |
5 | - Pascal ————————————————> Object Pascal |
6 | \ \ |
7 | ——> Modula-2 ——> Oberon |
Guido B. schrieb: > Eben, C hat sich genauso weiterentwickelt, abgesehen von C++ blieb aber > der Name derselbe. So, wie es nach wie vor reine C-Compiler gibt, gibt es nach wie vor reine Pascal-Compiler. Beide setzen natürlich nicht mehr auf der ursprünglichen Sprachdefinition von K&R bzw. Wirth auf, sondern meist auf einem moderneren ISO-Standard. Das ist dann die "Weiterentwicklung innerhalb einer Sprache": Die Sprache hat ihr Grundgonzept und den Namen beibehalten, bei der Syntax und teilweise bei der Semantik gab es kleinere "Face-Lifts". Zeitlich versetzt, aber parallel zur jeweiligen Ursprache entwickelten sich Nachfolger wie z.B. C++ und Modula. > Während Borland bei Turbo-C diese Entwicklung mitgegangen ist, hat sie > diese bei Pascal ignoriert. Das stimmt, was die Weiterentwicklung innerhalb der Sprache betrifft, so nicht: Auch Turbo-Pascal hat sich weit von Ur-Pascal wegbewegt, sogar viel weiter als Turbo-C von K&R-C. Als OOP hipp wurde, brachte Borland Turbo-C++ also Nachfolger von Turbo-C und Delphi als Nachfolger von Turbo-Pascal auf den Markt. Auch hier lief der Fortschritt auf der C- und der Pascal-Schiene parallel. Somit stimmt deine Aussage von auch auch nicht in Bezug auf die Nachfolgersprachen. Wenn man dem Tiobe-Index Glauben schenken darf, haben die Pascal-Nach- folger (in Form von Object Pascal bzw. Delphi) ihre Vorgängerin in ihrer Popularität inzischen überholt, während C++ nach wie vor C deutlich hinterherhinkt. Was beschwerst du dich also? ;-) Ok, ich habe schon verstanden: Nicht Delphi ist für dich der beste Pascal-Nachfolger, sondern Oberon. Wenn ich dir jetzt sagen würde, dass ich auch C++ nicht für den besten C-Nachfolger halte, sondern D? D führt aber genauso wie Oberon ein Schattendasein und wird wahrscheinlich nie den Mainstream erreichen. Jammer ;-/ Insofern verläuft die Entwicklung auf der C- und der Pascal-Schiene sehr ähnlich, und es gibt überhaupt keinen Grund, sich zu beklagen und zu glauben, auf der C-Schiene verliefe die Entwicklung besser. Der einzige große Unterschied in der Entwicklung von C und Pascal (jeweils mit Nachfolgern) ist ein quantitativer: Im Tiobe-Index werden die ersten fünf Plätze durch C-Nachfolger belegt, die in Summe ein Rating von über 60% haben. Pascal und Nachfolger schaffen gerade einmal etwa 2%. An diesem Ungleichgewicht hat aber auch Niklaus Wirth persönlich (viel- leicht bewusst) seinen Anteil, da er Pascal zunächst als reine Lernspra- che konzipiert hat. Seine Ziele waren: - saubere Struktur, es wurde alles vermieden, was die Studenten zu schlechtem Programmierstiel bewegen könnte - relativ starke Typprüfung, das unterstützt ebenfalls die saubere Programmierung - relativ hohe Abstraktion, Eigenheiten des Betriebssystems und der Rechnerhardware sollten nicht bis zum Lernenden vordringen, da sie seine Konzentration vom Wesentlichen ablenken könnten Das sind alles positive Eigenschaften, aber besonders der dritte Punkt war mit einem großen Nachteil verbunden: Es wurde zwar das Lesen und Schreiben von Dateien unterstützt, aber keine Dateinamen, geschweige denn Dateipfade, da insbesondere bei letzteren jedes Betriebssystem seine eigenen Konventionen hat. Die Folge war, dass ein Programm nur hartcodierte Dateien verwenden konnte, was Pascal für die meisten Anwendungen absolut untauglich machte. Dieser und weitere (weniger signifikante) Nachteile waren mit ein Grund dafür, dass rasch mehrere Pascal-Dialekte entstanden, die diese Nachtei- le behoben. Dieser Wildwuchs behinderte aber stark die Portabilität und damit die auch Verbreitung von Pascal. Der ISO-Standard und die verbes- serten Nachfolger von Pascal sollten ihm schließlich Einhalt gebieten, doch bis dahin war C längst auf der Überholspur. C hingegen hatte ganz andere Ziele. Hauptziel war die Entwicklung des Unix-Betriebssystems. Deswegen war es sehr hardwarenah ausgelegt. Eine saubere Struktur war nur insoweit erwünscht, wie es den Programmierer bei der rechenzeit- und speichereffizienten Programmierung nicht allzu sehr behinderte. Das Ergebnis war eine Sprache, die von Wirth zwar als "mit Syntax ver- zuckertem Assembler" bezeichnet wurde, mit der man aber im Gegensatz zu Ur-Pascal fast jeden Typ von Anwendung programmieren konnte. Überzeu- gendstes Beispiel war Unix, das erste Betriebssystem, das fast komplett in einer Hochsprache geschrieben wurde. Da war eigentlich für jeden klar: Programmieren gelernt wird mit Pascal, danach werden ernsthafte Programme aber nur noch in C geschrieben. Auch heute, 40 jahre nach seiner Entstehung, ist C immer noch eine der am meisten eingesetzten Programmiersprachen, obwohl es nicht einmal objekt- orientiert ist. Und jetzt ist halt alles so wie es ist: Nix Lisp, nix Smalltalk, nix Eiffel und eben auch nix Oberon. Aber programmiert wird trotzdem mehr denn je ;-)
Hallo Yalu, ich beschwere mich ja nicht, ich möchte nur meiner Verwunderung Ausdruck verleihen. Wie könnte ich mich über FPC oder Lazarus ärgern, wo ich sie doch sehr viel benutze. Früher war es Turbo-Pascal, später Delphi, zwischendurch nur ein kleiner Ausflug mit Prospero-Pascal auf dem Sinclair-QL. Was du über das ursprünglich Pascal schreibst ist schon richtig, die Begründung mit der reinen Lehrsprache würde ich aber auf einen Übersetzungsfehler zurückführen. Es war eine rein akademische Sprache, gedacht zur Überprüfung von Algorithmen u.ä. und der Verzicht auf notwendige Ein- und Ausgaben resultierte einfach daraus, dass die verwendeten Rechner damals nur Tastatur, Kertenleser und Zeilendrucker hatten. Dafür reichte input und output. Als Wirth in Palo Alto ein Betriebssystem programmieren wollte, was Kernigham von Anfang an vorhatte, wurde dieses Problem evident. Also hat er dieses sowie einige sonstige Erweiterungen in Modula Implementiert. Die Grundsprache war immer noch Pascal, es waren nur Zusätze hinzugekommen. Das ist im Grunde bis heute (also Oberon-2 oder auch Zorron so, obwohl Gutknecht auch mal gerne eigene Wege ausprobiert) noch so. Ich habe Wirths Bücher "Compilerbau" vo 1977 und 2008 hier vorliegen und sie sind in weiten Teilen wortwörtlich identisch. Proprietäre Erweiterungen, wie die von Borland, sind eine andere Sache. Dass hierzu eine Notwendigkeit bestand, kann nicht bezweifelt werden. Dass aber alles ganz anders als von Wirth gemacht werden muss, kann ich im Nachhinein nicht verstehen. Es gab ja keine Rechteprobleme, die solche Maßnahmen in anderen Projekten erzwungen haben. Das Modulkonzept von Modula gefällt mir überhaupt nicht, es ist dem Unitkonzept von Borland aber weit überlegen. Hätte Borland dies damals übernommen, hätte es später leicht auf das Konzept von Oberon überleiten können. Ich verstehe und bin froh darüber, dass bei FPC ursprünglich die Idee größtmöglicher Kompatibiltät im Vordergrund stand. Es irritiert mich aber, dass nachdem dies wohl geschafft ist, keine Modernisierung stattfindet. Die muss die Kompatibilität ja nicht beeinträchtigen. Als ich die ersten Gedanken an meinen Compiler für die C16x-Famile verschwendet habe (der µC lädt geradezu dazu ein), wollte ich natürlich auch einen Pascal-Compiler entwickeln. Die Literatur dazu war ja auch vorhanden. Schon der Artikel in der (englischen) Wikipedia zu Oberon hat mich aber davon überzeugt, dass dies ein Anachronismus wäre. Weitere Recherchen haben das bestätigt. Und jetzt wundere ich mich nur noch darüber, dass ich offensichtlich ein solcher Sonderling bin, dass sonst niemand meine Meinung teilt. Achso, der Compiler wurde natürlich mit FPC erstellt, weil ich für Linux keinen brauchbaren Oberoncompiler gefunden habe (sic). Grüße, Guido
>zu Oberon hat mich aber davon überzeugt, dass dies ein Anachronismus >wäre. Weitere Recherchen haben das bestätigt. das ist schwachsinnig (ich hoffe man darf das hier so ausdrücken, ist aber nun mal meine Meinung) ich respektiere, dass dir Oberon besser gefällt, EINIGE Sachen sind auch sicher besser.. und du eine Überzeugung hast, usw. (erinnert fast ein bisschen an den Homöopathie Thread) aber meistens! ist es besser mit dem Strom zu Schwimmen. meistens! macht die Mehrheit nämlich das Richtige (das wissen schon unsere Gene.. aka Herdentrieb..) in deinem Fall: du musst jetzt wegen jeden Furz alles neu schreiben/umschreiben.. anstelle eine CRC32.PAS Unit zu verwenden, was dazu führt, dass man nach ein paar Minuten Aufwand eine CRC32 berechnung integriert hat, muss du sie in diesem einfach Fall, zuerst mühsam Umformatieren.. von Aufwändigeren Sachen mal ganz abgesehen.. (p.s. was am Unit konzept schlecht ist, weiß ich jetzt immer noch nicht?!)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.