Jetzt mal ohne Witz, Computer Science existiert schon mehrere Dekaden und die Leute haben es noch immer nicht hinbekommen, eine gute Programmiersprache zu schreiben? C: - Die beste Sprache heutzutage, und das, im Kombination mit C's Alter, spricht Bände - Nur grundlegende Generics - Keine gute Compile-Time-Evaluation (damit meine ich so etwas wie C++14's constexpr) - Build-Horror - Weder Modules noch Namespaces C++: - Überall falsche Defaults wegen Rückwärtskompatibilität: enum, const-Methoden, switch-break, explicit, ... - iostreams - Build-Horror (im Gegensatz zu C hat diese moderne Sprache absolut keine Entschuldigung dafür, keine Modules zu haben) - Header-Horror, in Anlehnung an obigen Punkt kommen hier auch noch die Abscheulichkeiten mit .inl etc. dazu D: - Absolut kein Ecosystem dahinter, genauso wenig wie Libraries - __traits, __traits, __traits - Unabdingbarer GC (ja, unabdingbar! Standardbibliothek kompiliert nicht ohne) Java: - Keine Funktionen - Keine Funktions-/Methodenzeiger o.Ä. - Keine gute Compile-Time-Evaluation - GC/VM, daher extrem langsam, träge und resourcenintensiv (nicht jeder hat ein Rechenzentrum unter dem Tisch) - clone(), finalize(), clone(), finalize(), clone(), finalize() - Reinkarnation von falschen Defaults - Devs haben verbissen alles künstlich eingeschränkt Rust: - Langatmige Syntax - Keine gute Compile-Time-Evaluation - Beschnittene Generics - Diese hochgepriesene Ownership-Sache ist komplett broken und kostet wesentlich mehr Zeit und Haare als die wöchentlichen 10min Debuggen in C Golang: - Keine gute Compile-Time-Evaluation - Keine Generics - GC - Halb objektorientiert, halb dann doch nicht. Entweder alles oder nichts aber keine halben Dinge. - Man kommt sich, wie in Java, künstlich beschnitten vor Nim: - Ein-Mann-Projekt, inkl. aller Implikationen - Whitespaces als Syntaxelement Sprachen mit dynamischem Typensystem habe ich mal nicht aufgeführt weil ich mich nicht sonderlich für Kinderspielzeug interessiere.
Du müsstest erst einmal ein Komitee gründen, um in jahrelanger aufreibender Arbeit ein für alle Mal die Frage zu klären, was die Welt unter "gut" versteht.
turbo autist schrieb: > Jetzt mal ohne Witz, Computer Science existiert schon mehrere Dekaden > und die Leute haben es noch immer nicht hinbekommen, eine gute > Programmiersprache zu schreiben? Sind mehrere Dekaden denn lang? Wenn ich überlege wie lange es von den Anfängen der Elektrizität bis zu ordentlicher Elektronik gedauert hat, dann müsste man der Informatik ruhig noch ein Jahrhundert geben. Der Entwurf von Programmiersprachen ist schließlich auch ein wenig schwieriger als Schaltungen zu basteln.
Und wenn man dann noch bedenkt, dass man sich in den Jahrhunderten Elektrizität nicht einmal auf eine Netz-Spannung einigen konnte, ganz zu schweigen von deren Frequenz...
A. K. schrieb: > Du müsstest erst einmal ein Komitee gründen, um in jahrelanger > aufreibender Arbeit ein für alle Mal die Frage zu klären, was die Welt > unter "gut" versteht. "A camel is a horse, designed by a comittee!"
turbo autist schrieb: > Jetzt mal ohne Witz, Computer Science existiert schon mehrere Dekaden > und die Leute haben es noch immer nicht hinbekommen, eine gute > Programmiersprache zu schreiben? Sprachen kommen und gehen wie die Wellen im Meer. Modesprachen werden am laufenden Band erschaffen. Auch solche, die "alles besser"(tm) machen wollen. Am Punkt von D siehst Du auch schon, was dabei das Problem ist - es zählt nicht nur, wie toll die Sprache ist. Es zählt auch, welches Ökosystem man hat, für wieviele Plattformen das verfügbar ist, und wie leicht Du am Markt Programmierer bekommst, die das können. Es lohnt sich aber nicht, seine Zeit mit einer "superneuallestoll-Sprache" zu verschwenden, weil man damit nicht gefragt ist. Henne und Ei. Und für den Bereich, für den es überhaupt gedacht ist (systemnahe Programmierung), ist speziell C deswegen heute noch verbreitet, weil es ein riesiges Ökosystem hat, unzählige verfügbare Programmierer, und es einfach "gut genug"(tm) ist. Der beste portable Makro-Assembler überhaupt eben.
A. K. schrieb: > Du müsstest erst einmal ein Komitee gründen, um in jahrelanger > aufreibender Arbeit ein für alle Mal die Frage zu klären, was die Welt > unter "gut" versteht. Für Komitees ist der EU Kommissar Günther Oettinger zuständig. "We in Tschermani say, it's time so start wiss a nasser Computer Längwitsch". Letz call it E+++". "We leave se Details to se Developers in China". They have Schlitzaugen and see de sin plusplusplus signs for Developing the läng witch a lot better sän auer EU-people" do.
Ich weiß nicht, warum sich Leute einen ganzen Kasten Oettinger kaufen. Mir reicht schon die eine Flasche in Brüssel.
Die besseren Programmiersprachen verschieben die Massstäbe. Wenn du unsere heutigen Sprachen mit Fortran/Cobol/Basic vergleichst, haben wir ja eine gewaltige Verbesserung.
Vielleicht suchen wir den Schlüssel unter der falschen Strassenlaterne. Falls gute imperativen Sprachen unmöglich sind, falls sich nur für die deklarativen Programmierung gute Sprachen entwickeln lassen -- Dann müssten wir alles, was wir in den 50 Jahren lernten, vergessen und neu anfangen. Die C Programmierer wollten nicht mal ihre C Kenntnisse wegwerfen. Ärgern sich lieber mit diesem aufgeblasenen C++ herum. So bleiben wir lieber bei den alten Paradigmen, diskutieren ewig über nebensächliche Detailpunkte, suchen gar nicht nach guten Ansätzen.
Die Anforderungen aendern sich, die Konzepte aendern sich, es ist im Fluss. Es kommt immer mehr moegliches hinzu verteilte Programme, Echtzeit, Datenbanken, Web, ...
Jan schrieb: > Ich weiß nicht, warum sich Leute einen ganzen Kasten Oettinger kaufen. > Mir reicht schon die eine Flasche in Brüssel. Und mir verursachen beide nur Kopfschmerzen. Vor allem wenn die Öettinger Flasch Bier leer ist. Bei der anderen ... nur Kopfschmerzen & Übelkeit! mfg Olaf
Warum baut ihr keine perfekte Programmiersprache statt zu meckern? Könnt Ihr nicht? Och....
- Build-Horror Deshalb bleibe ich seit 35 Jahren bei Basic. Da muss man nicht builden. Das Programm ist einfach da. Alles ist wunderbar sortiert durch die praktischen Zeilennummern. Und wenn es los gehen soll, gibt man einfach 'run' ein. Kein make gcc link mit 1000senden Optionen. Einfach nur 'run' und es geht.
dunno.. schrieb: > Wieso hat eigentlich noch niemand C# genannt? Vielleicht weil sich einfach keine Sau dafür interessiert? Außerdem wurden C++ und Java schon im Eröffnungsbeitrag genannt. Daraus kannst du dir dann C# interpolieren.
PiityJ schrieb: > [BASIC] > Alles ist wunderbar sortiert durch die praktischen Zeilennummern. Stimmt. Und wenn doch mal was durcheinander kommen sollte, braucht man seinen Code einfach nur durch sort(1) zu schicken und alles ist wieder in der richtigen Reihenfolge. Fairerweise sollte man aber erwähnen, dass das in C genauso gut geht:
1 | /* 10 */ #include <stdio.h> |
2 | /* 20 */ |
3 | /* 30 */ int main(int argc, char *argv[]) |
4 | /* 40 */ {
|
5 | /* 50 */ puts("Hello, World!");
|
6 | /* 60 */ return 0; |
7 | /* 70 */ } |
>> Kannst du die tausend senden-Optionen mal aufzählen? ;-)
bei 'man gcc'
Overall Options
-c -S -E -o file -no-canonical-prefixes -pipe
-pass-exit-codes -x language -v -### --help[=class[,...]]
--target-help --version -wrapper @file -fplugin=file
-fplugin-arg-name=arg -fdump-ada-spec[-slim] -fdump-go-spec=file
C Language Options
-ansi -std=standard -fgnu89-inline -aux-info filename
-fno-asm -fno-builtin -fno-builtin-function -fhosted
-ffreestanding -fopenmp -fms-extensions -fplan9-extensions
-trigraphs -no-integrated-cpp -traditional
-traditional-cpp -fallow-single-precision -fcond-mismatch
-flax-vector-conversions -fsigned-bitfields -fsigned-char
-funsigned-bitfields -funsigned-char
C++ Language Options
-fabi-version=n -fno-access-control -fcheck-new
-fconserve-space -fconstexpr-depth=n -ffriend-injection
-fno-elide-constructors -fno-enforce-eh-specs -ffor-scope
-fno-for-scope -fno-gnu-keywords -fno-implicit-templates
-fno-implicit-inline-templates -fno-implement-inlines
-fms-extensions -fno-nonansi-builtins -fnothrow-opt
-fno-operator-names -fno-optional-diags -fpermissive
-fno-pretty-templates -frepo -fno-rtti -fstats
-ftemplate-depth=n -fno-threadsafe-statics -fuse-cxa-atexit
-fno-weak -nostdinc++ -fno-default-inline
-fvisibility-inlines-hidden -fvisibility-ms-compat -Wabi
-Wconversion-null -Wctor-dtor-privacy -Wnoexcept
-Wnon-virtual-dtor -Wreorder -Weffc++
-Wstrict-null-sentinel -Wno-non-template-friend -Wold-style-cast
-Woverloaded-virtual -Wno-pmf-conversions -Wsign-promo
Objective-C and Objective-C++ Language Options
-fconstant-string-class=class-name -fgnu-runtime
-fnext-runtime -fno-nil-receivers -fobjc-abi-version=n
-fobjc-call-cxx-cdtors -fobjc-direct-dispatch
-fobjc-exceptions -fobjc-gc -fobjc-nilcheck -fobjc-std=objc1
-freplace-objc-classes -fzero-link -gen-decls
-Wassign-intercept -Wno-protocol -Wselector -Wstrict-selector-match
-Wundeclared-selector
Language Independent Options
-fmessage-length=n
-fdiagnostics-show-location=[once|every-line]
-fno-diagnostics-show-option
Warning Options
-fsyntax-only -fmax-errors=n -pedantic -pedantic-errors -w
-Wextra -Wall -Waddress -Waggregate-return
-Warray-bounds -Wno-attributes -Wno-builtin-macro-redefined
-Wc++-compat -Wc++0x-compat -Wcast-align -Wcast-qual
-Wchar-subscripts -Wclobbered -Wcomment -Wconversion
-Wcoverage-mismatch -Wno-cpp -Wno-deprecated
-Wno-deprecated-declarations -Wdisabled-optimization
-Wno-div-by-zero -Wdouble-promotion -Wempty-body -Wenum-compare
-Wno-endif-labels -Werror -Werror=* -Wfatal-errors
-Wfloat-equal -Wformat -Wformat=2 -Wno-format-contains-nul
-Wno-format-extra-args -Wformat-nonliteral -Wformat-security
-Wformat-y2k -Wframe-larger-than=len -Wjump-misses-init
-Wignored-qualifiers -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Winit-self -Winline
-Wno-int-to-pointer-cast -Wno-invalid-offsetof -Winvalid-pch
-Wlarger-than=len -Wunsafe-loop-optimizations
-Wlogical-op -Wlong-long -Wmain -Wmissing-braces
-Wmissing-field-initializers -Wmissing-format-attribute
-Wmissing-include-dirs -Wno-mudflap -Wno-multichar -Wnonnull
-Wno-overflow -Woverlength-strings -Wpacked
-Wpacked-bitfield-compat -Wpadded -Wparentheses
-Wpedantic-ms-format -Wno-pedantic-ms-format -Wpointer-arith
-Wno-pointer-to-int-cast -Wredundant-decls -Wreturn-type
-Wsequence-point -Wshadow -Wsign-compare
-Wsign-conversion -Wstack-protector -Wstrict-aliasing
-Wstrict-aliasing=n -Wstrict-overflow -Wstrict-overflow=n
-Wsuggest-attribute=[pure|const|noreturn] -Wswitch
-Wswitch-default -Wswitch-enum -Wsync-nand -Wsystem-headers
-Wtrampolines -Wtrigraphs -Wtype-limits -Wundef
-Wuninitialized -Wunknown-pragmas -Wno-pragmas
-Wunsuffixed-float-constants -Wunused -Wunused-function
-Wunused-label -Wunused-parameter -Wno-unused-result
-Wunused-value -Wunused-variable -Wunused-but-set-parameter
-Wunused-but-set-variable -Wvariadic-macros -Wvla
-Wvolatile-register-var -Wwrite-strings
......
Ich mache hier mal Schluss, ist noch nicht mal die Hälfte.
PittyJ schrieb: > Ich mache hier mal Schluss, ist noch nicht mal die Hälfte. Da war aber keine einzige senden-Option dabei! Sagtest du nicht, es sind tausend?
Die Frage des Threadstarters ist leicht zu beantworten: Weil dann keine Programmiersprachenflamewars mehr nötig wären, in denen sich Leute in erster Linie über die Nachteile von ihnen nicht verstandener Programmiersprachen auslassen, und Dinge, die sie in ihrem jeweiligen persönlichen Favoriten entdeckt haben, als weltbewegend und einzigartig ansehen. Und da das Internet von Programmiersprachen- und anderen Flamewars lebt, gibt es eine sehr aktive Gemeinde von Programmiersprachenhackern, die dafür sorgen, daß keine Programmiersprache "gut" wird.
C#? Net! schrieb: > dunno.. schrieb: >> Wieso hat eigentlich noch niemand C# genannt? > > Vielleicht weil sich einfach keine Sau dafür interessiert? > > Außerdem wurden C++ und Java schon im Eröffnungsbeitrag genannt. > Daraus kannst du dir dann C# interpolieren. naja gefühlt ist C# mittlerweile mehr als Java und C++ zusammen ... hat aber auch den nachteil das es mehrere Größenordnungen mehr Möglichkeiten gibt genau das gleiche auszudrücken. was wäre denn eine gute Sprache? Selbst wenn du heute einen total genialen C++ code entwickeln würdest, auf den du richtig stolz sein kannst, in 10 Jahren schaust du dir den nochmal an und denkst nur, welcher trottel hat das geschrieben ...
dunno.. schrieb: > Wieso hat eigentlich noch niemand C# genannt? Weil es zu stark mit MS verbandelt ist. Wenn MS irgendwas erschafft, dann steht dahinter IMMER die Idee von "embrace, extend, destroy". Wie schon die alten Römer sagten "timeo Danaos et donas ferentes" - und was anderes als Danaergeschenke sind von MS nie zu erwarten. Deswegen ist Mono ja auch geflopt.
Wenn man bedenkt dass die Evolution 1000000 jahre gebraucht hat um sowas wie Turbo Autist hinzubekommen, dann entwickeln sich Programmiersprachen doch rasend schnell.
>Java: >- GC/VM, daher extrem langsam, träge und resourcenintensiv (nicht jeder >hat ein Rechenzentrum unter dem Tisch) extrem ist hier vielleicht ein wenig zu extrem - es kommt doch immer auf den Anwendungsfall an >Rust: >Diese hochgepriesene Ownership-Sache ist komplett broken und kostet >wesentlich mehr Zeit und Haare als die wöchentlichen 10min Debuggen in C die Ownership-Sache ist das bisher das beste was überhaupt in der langen Zeit an Sprachenentwicklung entstanden ist (Funktional setzt sich leider nicht durch) - und es geht den Rust Entwicklern und vielen anderen Entwicklern sicherlich nicht um deine 10min Debuggen trivial Probleme von dir - und klar ist auch das Konzpte/Einschränkung in dem bösesten Bereich der Dominant-Sprachen sicher nicht ohne Opfer vonstatten geht - die brauchen eben noch ein bisschen
>Weil dann keine Programmiersprachenflamewars mehr nötig wären, in denen >sich Leute in erster Linie über die Nachteile von ihnen nicht >verstandener Programmiersprachen auslassen Ja. Das ist es. Wir Programmierer haben uns nur drei mal etwas neues gelernt. Uns in neue Konzepte eingearbeitet. 1945 in die von Neumann Architektur. 1957 in Fortran. 1980 in die Disketten-Betriebssysteme. Die heutigen Programmiersprachen sind so verkrüppelt und aufwendig, weil wir alle weiteren Konzepte ignorieren. Mit den Milliarden von Transistoren könnten die Hardwareentwickler ganz andere Ansätze realisieren. Stattdessen bauen die immer neue Beschleunigungen um ein prähistorisches Rechenwerk aus 1000 Transistoren. Dieser irrsinnigen Aufwand, mit dem unsere Programmiersprachen ein paar prähistorischen Maschinenbefehle verpacken, ist überhaupt nicht notwendig. Die verbreiteten Programmiersprachen werden nur deswegen immer verwickelter und absurder, weil wir zu träge geworden sind. Weil wir uns nicht mehr in die neuen Konzepte einarbeiten wollen.
Noch einer schrieb: > Mit den Milliarden von Transistoren könnten die Hardwareentwickler ganz > andere Ansätze realisieren. Sobald es dafür einen gcc gibt, soll es mir recht sein ;
turbo autist schrieb: > Wieso gibt es keine gute Programmiersprache? Wieso gibt es keinen Weltfrieden? Es ist halt nicht so dass sich das Bessere automatisch durchsetzt. Selbst forciert setzt sich das Bessere oft nicht durch. Es wäre ja auch für ein "C-Fan" ein Vorteil, wenn es eine bessere Alterative gäbe, aber er sieht halt tausend Gründe, warum für ihn C die beste Wahl ist. Das ist die Freiheit jedes Einzelnen.
Noch einer schrieb: > Mit den Milliarden von Transistoren könnten die Hardwareentwickler ganz > andere Ansätze realisieren. Stattdessen bauen die immer neue > Beschleunigungen um ein prähistorisches Rechenwerk aus 1000 > Transistoren. > > Dieser irrsinnigen Aufwand, mit dem unsere Programmiersprachen ein paar > prähistorischen Maschinenbefehle verpacken, ist überhaupt nicht > notwendig. Es steht dir frei andere Ansätze zu realisieren. Wenn es ein gutes/tolles Konzept gibt, wirst du bald sehr reich sein. Selbst wenn du nur das Konzept darstellst und einen Prototypen auf nem FPGA aufbaust.
Noch einer schrieb: > Die heutigen Programmiersprachen sind so verkrüppelt und aufwendig, weil > wir alle weiteren Konzepte ignorieren. > > Mit den Milliarden von Transistoren könnten die Hardwareentwickler ganz > andere Ansätze realisieren. Stattdessen bauen die immer neue > Beschleunigungen um ein prähistorisches Rechenwerk aus 1000 > Transistoren. Dann mach. Es ist heute kein grundsätzliches Problem sich einen eigenen Prozessor zu basteln. Bauteile wie FPGAs sind bis zu einer gewissen Größe für den normalen Bastler erschwinglich. Eine HDL lernen und beherrschen ist natürlich nicht ganz so einfach, aber als notwendiger Zwischenschritt zur Verbesserung der Welt sicher akzeptabel. Wenn ein FPGA nicht für deinen Ansatz taugt, dann kannst du dir auch das ganze IC-Design auf Silizium-Ebene im Hobbykeller aus dem Boden stampfen: Electric VLSI Design System http://www.staticfreesoft.com/index.html Nehmen wir an, du schaffst eine überlegene Technologie. Dann gibt es mindestens zwei Wege wie es weitergehen kann: 1. Du nutzt sie still und heimlich in Projekten und Produkten um Wunderdinge zu schaffen "Any sufficiently advanced technology is indistinguishable from magic" -- Arthur C. Clark Damit wirst du reich, und keiner versteht wie du es machst. 2. Du machst sie öffentlich. Sie ist in sich selbst so überzeugend, dass sie in kurzer Zeit existierende Techniken verdrängt. Mit in sich selbst überzeugend meine ich, dass es ohne Marketing-Hype und Fanboy-Propaganda geht. Damit wirst du berühmt (und vielleicht auch reich). Jetzt kommt aber das Interessante. Täglich werden beide Ansätze hundertfach versucht. Vom Erfolg mit Ansatz 1. hören wir per Definition nichts (und egal was die Fanboys sagen, Apple ist kein Beispiel dafür). Von einem Erfolg nach Ansatz 2. hören wir aber auch nichts. > Die verbreiteten Programmiersprachen werden nur deswegen immer > verwickelter und absurder, weil wir zu träge geworden sind. Weil wir uns > nicht mehr in die neuen Konzepte einarbeiten wollen. Ich glaube, da ist etwas anderes am Werk. Das Genie vergisst immer, dass seine Erfindungen für den normalen Ingenieur oder Programmierer verständlich und anwendbar sein müssen. Was für das Genie selbstverständlich ist, ist für den Durchschnittsprogrammierer eventuell unbegreiflich. Sehr salopp und unwissenschaftlich ausgedrückt, unter der Annahme einer gewissen Intelligenzverteilung ist die Hälfte aller Programmierer dümmer als der Durchschnittsprogrammierer. C++ ist eine Programmiersprache die das schön zeigt. Mit jeder Standard-Revision wird sie komplizierter, weil das Standard-Komitee den Durchschnittsprogrammierer oder gar den normal-dummen Programmierer schon lange aus den Augen verloren hat. Java ist auch auf dem Weg dahin. Hinzu kommt gerade in der Informatik der Trend, dass Fehlerkorrektur, Bugfixing uncool ist und man lieber neue Dinge macht. So wird alter Müll in Programmiersprachen nicht behoben, sondern Standard-Komitees bastelt lieber neuen Müll dazu.
Nop schrieb: > Der beste portable Makro-Assembler > überhaupt eben. So ist es! Die ganzen "neuen" Sprachen die in den letzten 30 Jahren entwickelt wurden, haben aus meiner Sicht als Firmware-Entwickler in keinster Weise das Potential das C hat und immer haben wird. Wenn ich mich an die Hitachi-CPUs erinnere, die eine JAVA-Runtime implementiert hatten, dann wird es mir heute noch schlecht. Ich muss(te) oft lachen, wenn ich immer wieder lese, dass bspw. JAVA-Applikationen auf allen System laufen sollen. Da komme ich vor Lachen nicht in den Schlaf. So verhält es sich aus meiner Sicht auch mit den anderen "neuen" Sprachen. Wirkliche Verbesserungen haben sie nicht zu bieten. Ähm..., doch, man braucht immer leistungsfähigere CPUs/Systeme. Oft kann ich mich des Eindrucks nicht erwehren, dass die Ruby, Phyton, Java und wie der ganze unpraktikable Quatsch sich immer nennt, nur dazu gedacht sind die "Russen zu verwirren". Und wenn man sich den Quellcode von vielen Sprachen anschraut (Compiler/Interpreter): Die sind fast zu 100% in C geschrieben. Komisch oder?
(Turbo-) Pascal war genial. Ist irgendwo aber das selbe wie C, nur mit anderer Syntax, die aber um Größenordnungen einfacher zu verstehen ist, vor allem wenns um Zeiger geht. Darum geht auch C++ (z.B. using) und Golang syntaktisch wieder in diese Richtung.
Codix schrieb: > Und wenn man sich den Quellcode von vielen Sprachen anschraut > (Compiler/Interpreter): Die sind fast zu 100% in C geschrieben. > Komisch oder? Nö. GCC, LLVM, Roslyn usw. sind alle in C++ / C# geschrieben.
> ist für den Durchschnittsprogrammierer eventuell unbegreiflich
Nö. Meine Kollegen sind nicht zu dumm. Die haben halt eine Sprache so
gut gelernt, dass sie damit mühelos gutes Geld verdienen können. Kommen
gar nicht auf die Idee, sie konnten mal was ganz anderes an testen,
Prolog, Haskell oder Parallax Propeller. Spielen lieber mit den Kindern
oder tauchen in der Südsee.
Die ersten C-Compiler wurden in ASM geschrieben. Komisch, oder?
Jack schrieb: > C++ ist eine Programmiersprache die das schön zeigt. Mit jeder > Standard-Revision wird sie komplizierter In der Limesbetrachtung strebt jede hinreichend lange "erweiterte" Programmiersprache gegen Lisp. Sowohl was die Features als auch was die Unverständlichkeit angeht. ;-) Codix schrieb: > Die ganzen "neuen" Sprachen die in den letzten 30 Jahren entwickelt > wurden, haben aus meiner Sicht als Firmware-Entwickler in keinster Weise > das Potential das C hat und immer haben wird. Für Firmware ja. Nur, ich habe auch schon z.B. Xwindow-Programmierung in reinem C gemacht, und das will man einfach nicht, weil es Codehorror ist. 90% der Zeit verschwendet man mit irgendwelchen GUI-Problemen, anstatt sich auf die inhaltliche Anwendung zu konzentrieren. Deswegen hat man ja OOP erfunden, weil dieses Paradigma bei GUIs (und Simulationen) gut funktioniert. Dann haben wir ja jetzt auch noch den Trend zur Parallelisierung, und wenn eine Applikation nicht "bloß" in mehreren Threads skalieren soll (was zu Fuß schon schwierig genug ist), sondern dynamisch ganze Server zu- und wegschalten können soll, dann ist das ohne entsprechende Frameworks gar nicht mehr zu schaffen. Das Dumme ist, daß solche Frameworks zwar die Komplexität abstrahieren - aber sobald irgendwas nicht klappt wie gedacht, muß man das Framework selber AUCH verstanden haben, und eben nicht nur als Blackbox nutzen können. Weil jede Abstraktion ihre Löcher hat.
@turbo autist: Du machst es dir mit deiner Kritik sehr leicht (vielleicht ging es dir auch einfach nur darum, schon am Sonntag eine heftige Freitgasdiskussion auszulösen): Sei S die Menge aller Sprachen und F(s) die Menge aller Features der Sprache s ∈ S. Die Gesamtheit aller überhaupt jemals implementierten Sprachfeatures ist damit
Jetzt gehst ein paar willkürlich ausgewählte Sprachen der Reihe nach durch, bildest jeweils die Differenzmenge D(s) = G \ F(s) und sagst: Die Sprache s taugt nichts, weil die Features f₁, f₂, ... (f_i ∈ D(s)) fehlen. Daraus folgerst du, dass alle Sprachen schlecht sind. "Gut" ist eine Sprache also erst dann, wenn sie sämtlich Features aus G umfasst. Falls es diese Sprache – nennen wir sie g – eines Tages tatsächlich geben sollte, wirst du (zurecht) behaupten: Die Sprache g ist hoffnungslos überladen und deswegen nicht erlernbar. Zudem wird g nur so lange "gut" sein, bis eine neue Sprache mit einem Feature f ∉ G kommt. Dann müsste g mindestens um das Feature f erweitert werden, um weiterhin als "gut" zu gelten, was g aber noch überladener macht. Ein historischer Versuch, die Sprache g zu entwickeln, war PL/1. Man hat aber bald eingesehen, dass dies zu nichts führt und deswegen keine weiteren Anstrengungen in diese Richtung mehr unternommen ... ... bis vor ein paar Jahren, als MS anfing, C# zu entwickeln ;-)
turbo autist schrieb: Ich denke eher, es gibt schon etwas zu viel "gute" Sprachen, so dass es schon schwierig wird sich welche auszusuchen. Vergessen hast Du u.a. auch Haskell, Swift, Julia, Scala, OCaml und Crystal. Oder die eher als Java-Script Ersatz gedachten Kotlin und Dart. Und man muss sich schon entscheiden, ob man eher eine universelle Spache wie D, Nim, Rust, Swift will oder eher spezielle Sprachen, etwa für Web-Anwendungen. Oder Interpreter-Sprachen wie Python und Ruby, Sprachen für virtuelle Maschienen wie Scala oder Julia, oder Sprachen, die Maschienencode erzeugen wie D, Rust, Nim. Und speziell zu Nim > Nim: > - Ein-Mann-Projekt, inkl. aller Implikationen Ja, der Bus-Faktor ist natürlich etwas kritisch. Auch wenn es im Umfeld einige fähige Leute gibt, dominiert der Hauptentwickler sehr stark. Aber andererseits spricht es doch sehr für die Sprache selbst, dass das Projekt mit wenig Man-Power so weit gekommen ist. > - Whitespaces als Syntaxelement Für die, die über Einrückungen definierte Blöcke überhaupt nicht leiden können, gibt es seit kurzem die Braces Variante, so dass man wie in C {} für Blöcke verwendet. Sollte zumindest in der Git-Version schon verfügbar sein. Ich denke aber nicht, dass sich das durchsetzen wird -- für Python gab es ja auch mal eine Variante mit END Keyword, hat dann aber letztendlich auch keiner wirklich gewollt. Ich hatte übrigenz kürzlich mal spasseshalber ein Schachprogramm "from Scratch" in Nim geschrieben, und dass hat mich durchaus Überzeugt. Nur 1000 Zeilen, eine brauchbare Spielstärke, und nur ein par Wochen Entwicklungszeit. https://github.com/ngtk3/nim-chess2 Und Rust: Für mich ein durchaus interessanter Ansatz, wenn man partout keine Garbage-Collector verwenden möchte. Und sicher eine sehr gute Alternative zu C++, zumindest für Linux.
rmu schrieb: > (Turbo-) Pascal war genial. Als Spielzeug ja, und auch dafür war Turbopascal nur wegen der proprietären, zu nichts kompatiblen Erweiterungen überhaupt irgendwie nutzbar. Allein schon, daß man nur einen Returnpunkt pro Funktion hat, und daß die Reihenfolge bei der Auswertung komplexerer Logikbedingungen undefiniert ist, macht das praktisch schon unbrauchbar. Wo man in C Idiome wie "if ((ptr != NULL) && (*ptr == Bla))" machen kann, hat man in Pascal schonmal zwei Blockebenen. Und die Ideologie des "ein Ausgang pro Funktion" verschiebt die Fehlerbehandlung in den Else-Zweig des Blocks, WEIT weg von der Fehlerabfrage. Der Codehorror aus gestackter Fehlerbehandlung kommt dann noch hinzu. Also wenn ein Programm erst Ressource A alloziert, und wenn das OK geht, Ressource B, und dann Ressource C. Allokation von C scheitert aber, also muß man erst B und dann A wieder rückgängig machen. In C nutzt man dafür einfach goto, während man sich in Pascal mit Code-Duplikationen einen Wartungs-Horror baut. War aber auch egal, denn bei Spielzeugprogrammen für Lehrzwecke braucht man keine Fehlerbehandlung. Grundsätzlich hat C gegenüber Pascal (und C++) immerhin den Dogfood-Test durchgemacht, denn K&R haben nicht wie Wirth und Stroustrup Sprachen vor sich hindesigned, sondern hatten ein konkretes Projekt vor Augen und mußten dann das, was sie verzapft haben, auch jeden Tag nutzen. C wurde von Programmierern für Programmierer geschaffen und nicht von einem Akademiker oder gar einem Komitee. Das wäre dann auch eine der wichtigsten Eigenschaften, die eine Sprache IMO mitbringen sollte, um "gut" zu sein.
https://de.wikipedia.org/wiki/Brainfuck Hat Vorteile wie - gut geeignet, um Grundlagen der Computertechnik zu erlernen - extrem einfaches Sprachkonzept - hochkompakte Realisierung des Compilers - universelle Einsetzbarkeit nicht eingeschränkt "Gut" liegt immer im Auge des Betrachters.
Nop schrieb: > Allein schon, daß man nur einen Returnpunkt pro Funktion hat, und daß > die Reihenfolge bei der Auswertung komplexerer Logikbedingungen > undefiniert ist, macht das praktisch schon unbrauchbar. https://en.wikibooks.org/wiki/Pascal_Programming/Syntax_and_functions
Babbage schrieb: > https://de.wikipedia.org/wiki/Brainfuck Dann eher Whitespace: https://en.wikipedia.org/wiki/Whitespace_(programming_language) > "Gut" liegt immer im Auge des Betrachters. Genau, und Whitespace blockiert nicht die Sicht ;-)
Codix schrieb: > Ich muss(te) oft lachen, wenn ich immer wieder lese, dass bspw. > JAVA-Applikationen auf allen System laufen sollen. Na ja, spezielle Java-Applikationen laufen auf deiner Kreditkarte. Stefan S. schrieb: > Ich hatte übrigenz kürzlich mal spasseshalber ein Schachprogramm "from > Scratch" in Nim geschrieben, und dass hat mich durchaus Überzeugt. Nur > 1000 Zeilen, eine brauchbare Spielstärke, und nur ein par Wochen > Entwicklungszeit. https://github.com/ngtk3/nim-chess2 Beispiele dieser Art gibt es für jede Sprache. Leider wird dann von so einem Beispiel immer auf die universelle Verwendbarkeit geschlossen. Was aber, wenn ich zum Beispiel kein Schachprogramm schreiben möchte sondern ganz andere Probleme zu lösen habe? Was beweist dein Schachprogramm dann? Nop schrieb: > Als Spielzeug ja, und auch dafür war Turbopascal nur wegen der > proprietären, zu nichts kompatiblen Erweiterungen überhaupt irgendwie > nutzbar. ISO Pascal war in der Tat zu nichts zu gebrauchen. Turbo-Pascal allerdings hat sicher erheblich zum Erfolg von Windows beigetragen. ASM Superprofi schrieb: > Die ersten C-Compiler wurden in ASM geschrieben. Komisch, oder? Nicht komisch. Das gilt für tausende von Industrieprodukten dass sie nicht mit sich selbst hergestellt werden. Wenn du einen Nagel verwenden möchtest, kaufst du nicht einen Hochofen und versuchst den Hochofen an die Wand zu nageln.
Nop schrieb: > Als Spielzeug ja, und auch dafür war Turbopascal nur wegen der > proprietären, zu nichts kompatiblen Erweiterungen überhaupt irgendwie > nutzbar. Es gibt genug Programme, die in Pascal geschrieben wurden und wirklich brauchbar sind, z.B. die TeX-Familie. > Allein schon, daß man nur einen Returnpunkt pro Funktion hat, und daß > die Reihenfolge bei der Auswertung komplexerer Logikbedingungen > undefiniert ist, macht das praktisch schon unbrauchbar. > > Wo man in C Idiome wie "if ((ptr != NULL) && (*ptr == Bla))" machen > kann, hat man in Pascal schonmal zwei Blockebenen. Ja und. Kürzer als ein äquivalentes C-Programm ist ein Pascal-Programm vermutlich nicht. Dafür gibts keine *** Programme, keinen infix/postfix unfug, Verwirrungen wie weit ein for (int i = ...) gilt, > Und die Ideologie des "ein Ausgang pro Funktion" verschiebt die > Fehlerbehandlung in den Else-Zweig des Blocks, WEIT weg von der > Fehlerabfrage. Der Codehorror aus gestackter Fehlerbehandlung kommt dann > noch hinzu. Kann mich nicht erinnern, dass die Fehlerbehandlung da wirklich substantiell anders aussieht als in C. In Pascal gibts doch auch ein goto, wenn man in C damit leben kann warum nicht auch in Pascal? Ist aber eh müssig die Diskussion.
Yalu X. schrieb: > Die Sprache s taugt nichts, weil die Features f₁, f₂, ... (f_i ∈ D(s)) > fehlen. > Die Sprache g ist hoffnungslos überladen und deswegen nicht > erlernbar. Du hast einen Punkt übersehen. Bei einer "guten" Sprache würde gar nicht auffallen, dass diese Features fehlen. Diese Features sind nur Workarounds für Fehler in den Paradigmen. Der zentrale Kritikpunkt: Dieser turbo autist bezeichnet nur Workaround-Sammelsurien als Programmiersprachen. Konzepte, die diese Unmassen an konfusen Features überflüssig machen, schaut er gar nicht an.
Peter II schrieb: > https://en.wikibooks.org/wiki/Pascal_Programming/Syntax_and_functions Ja, natürlich wurde das später aufgebohrt, mit genau den zu nichts kompatiblen Erweiterungen. Ich sehe aber da kein "exit": http://www.pascal-central.com/iso7185.html Stefan S. schrieb: > Ich hatte übrigenz kürzlich mal spasseshalber ein Schachprogramm "from > Scratch" in Nim geschrieben, und dass hat mich durchaus Überzeugt. Ja und? Es gibt auch Spielzeug-Schachprogramme in LISP. Aber eben auch nur Spielzeugprogramme mit dem Grundgerüst, und danach ist Schluß. Jack schrieb: > Turbo-Pascal > allerdings hat sicher erheblich zum Erfolg von Windows beigetragen. Unwahrscheinlich, weil TP unter DOS lief. Die Grafikbibliothek späterer Versionen war allerdings super, wenn man nicht gerade enorme Performance benötigte. Ich hab übrigens anfänglich mit Turbo Pascal 3.0 gearbeitet. rmu schrieb: > Es gibt genug Programme, die in Pascal geschrieben wurden und wirklich > brauchbar sind, z.B. die TeX-Familie. Wirklich in ISO-Pascal? > In Pascal gibts doch auch ein goto Stimmt, mein Fehler. Ist halt schon über 20 Jahre her, da bleiben die ersten Speicherfehler nicht aus. ;-)
Jack schrieb: > Sehr salopp und unwissenschaftlich ausgedrückt, unter der Annahme einer > gewissen Intelligenzverteilung ist die Hälfte aller Programmierer dümmer > als der Durchschnittsprogrammierer. Das scheint übrigens für jede Berufsgruppe gültig zu sein ;-)
Aber mal generell wieder zum Topic auch noch.. der bereits angebrachte Punkt stimmt schon. Eine Programmiersprache, die alles könnte, wäre so komplex, daß sie unbeherrschbar wird. C++ tendiert in diese Richtung, was Stroustrup mit dem berühmten Spruch vom Beinwegschießen ja durchaus zugegeben hat. Zudem zerfällt C++ langsam in Dialekte, weil es so umfangreich ist, daß niemand alles inkl. Libraries verstehen kann, weswegen das mit Codingrichtlinien gehandhabt wird. Diese sind aber in jeder Firma unterschiedlich, was zu einem Wartbarkeitsproblem führt, wenn das Personal fluktuiert. Erst recht, wenn man auch noch Legacycode hat, weil das praktisch eine deutlich andere Sprache ist. LISP war von Anfang an so, hat diese Übung aber anders als C++ nicht mit immer komplexerer Syntax hingelegt, sondern sich lieber als Turing-Tarpit positioniert. Es gibt eigentlich nur ein Syntax-Element, so daß sich jeder LISP-Hacker effektiv seine eigene Sprache baut, weswegen es nie ein wirkliches LISP-Ökosystem gegeben hat und auch keines geben wird. C finde ich da angenehm schlank, weil es gar nicht erst versucht, auf allen Hochzeiten zu tanzen und sich tierisch aufzublähen. Der Preis ist eben, daß es für komplexe Applikationen nicht so gut geeignet ist, weil man sich schon sehr auf das "wie" mitsamt manuellem Ressourcenmanagement konzentrieren muß anstatt auf das "was". Wenn man nun eine handhabbare Sprache will, dann kann sie nicht alles leisten. Problembezogene Sprachen lösen das Problem aber, zumal sie üblicherweise mit Praxisbezug zur jeweiligen Problemstellung gemacht wurden und deswegen leicht sind, wenn man einen Bezug zum Inhalt hat. Ich habe auch schon eigene (simple und zeilenbasierte) Programmiersprachen entwickelt, die genau auf das Problem zugeschnitten waren. Nicht "gut" für jeden, aber sehr effizient für das jeweilige Problem.
Nop schrieb: > Stimmt, mein Fehler. Ist halt schon über 20 Jahre her, da bleiben die > ersten Speicherfehler nicht aus. ;-) Das wird wohl eher der GC gewesen sein. Das Konzept hat die Natur schon vor sehr langer Zeit perfektioniert ;) Oliver
ASM Superprofi schrieb: > Die ersten C-Compiler wurden in ASM geschrieben. Komisch, oder? Nein. Schon die ersten Compiler wurden in C geschrieben! Es wurden nur erste, unvollständige Vorabversionen in ASM geschrieben, notgedrungen. Einen sinnvollen C-Compiler in ASM gab es sicher nie.
Es gab tatsächlich auch vor C schon höhere Programmiersprachen. Der erste C-Compiler wurden daher nicht in C, aber auch nicht "gezwungenermaßen" in Assembler geschrieben, sondern (sehr wahrscheinlich) in der "Vorgängersprache" mit dem schönen Namen (Achtung, Überraschung !!!) B. Steht zumindest so ungefähr hier: http://csapp.cs.cmu.edu/3e/docs/chistory.html Oliver
Spaminator schrieb: > Der Entwurf von Programmiersprachen ist schließlich auch ein wenig > schwieriger als Schaltungen zu basteln. Dann frage ich mich, wieso die Leistungsfähigkeit von Rechnern immer hinter den Anforderungen irgendwelcher Softwarekonstrukte hinterher hängt. So schwierig kann es doch nicht sein, Programme zu schreiben, die mit breitenverfügbarer Hardware schnell laufen.
垃圾件 schrieb: > So schwierig kann es doch nicht sein, Programme zu schreiben, die > mit breitenverfügbarer Hardware schnell laufen. Battlefield 1 läuft bei mir mit 60 fps!
rmu schrieb: > (Turbo-) Pascal war genial. Ist irgendwo aber das selbe wie C, nur > mit > anderer Syntax, die aber um Größenordnungen einfacher zu verstehen ist, wieso "war"? unglaublich aber war: Pascal gibt es noch -FreePascal->Lazarus und Delphi Nop schrieb: > rmu schrieb: >> (Turbo-) Pascal war genial. > > Als Spielzeug ja, und auch dafür war Turbopascal nur wegen der > proprietären, zu nichts kompatiblen Erweiterungen überhaupt irgendwie > nutzbar. > ... > Wo man in C Idiome wie "if ((ptr != NULL) && (*ptr == Bla))" machen > kann, hat man in Pascal schonmal zwei Blockebenen. dafür peilt man als normalo-Hobby-Programmierer auch beim ersten Blick was gemeint ist "if ((ptr != NULL) && (*ptr == Bla))" um sowas logisch fehlerfrei beisammen zu tippen braucht man 1 Jahr für Pascal reicht es 2x if-then-else logisch zusammen zu kriegen glücklicherweise gibt es Hochsprachen, die in annähernd menschlicher Sprache zu bearbeiten sind ansonsten könnten wir gleich asm oder hex da reinhämmern
Oliver S. schrieb: > Es gab tatsächlich auch vor C schon höhere Programmiersprachen. Ja beispielsweise BASIC (1964). C konnte sich erst nach einer gezielten Diffamierungskamapagne gegen BASIC durchsetzen (Dijsktra, "GOTO statement considered harmful", 1968)
ASM Superprofi schrieb: > Die ersten C-Compiler wurden in ASM geschrieben. Komisch, oder? Der erste Pascal Compiler wurde selbstverständlich in Pascal geschrieben.
Nop schrieb: > rmu schrieb: >> Es gibt genug Programme, die in Pascal geschrieben wurden und wirklich >> brauchbar sind, z.B. die TeX-Familie. > > Wirklich in ISO-Pascal? Eigentlich ist TeX in "web" geschrieben, nennt sich literal programming, und mischt TeX-Code zur Dokumentation mit dem eigentlichen Programmcode. Der ist in Pascal, ob das ISO-Pascal ist kann ich nicht sagen. Ich kenn nur die Version, den web-code direkt nach C zu konvertieren, diverse Infrastruktur dabei auszutauschen, und das dann zu kompilieren. Ursprünglich ist aber sicher als Pascal übersetzt worden. Mike B. schrieb: > wieso "war"? > unglaublich aber war: Pascal gibt es noch -FreePascal->Lazarus und > Delphi Ist bekannt, aber es hat sich irgendwie überholt. Kenne nichts und niemanden der irgendwas in Pascal, Delphi oder Lazarus neu entwickelt. 垃圾件 schrieb: > Dann frage ich mich, wieso die Leistungsfähigkeit von Rechnern immer > hinter den Anforderungen irgendwelcher Softwarekonstrukte hinterher > hängt. So schwierig kann es doch nicht sein, Programme zu schreiben, die > mit breitenverfügbarer Hardware schnell laufen. Ist es auch nicht. Auf meinem aktuellen Rechner laufen > 400 threads, dabei sind 20 Datenblätter offen, ein paar ODT-Files und Spreadsheets, der ERP-Client, eine eclipse, ein emacs und was weiss ich noch alles. Dabei spielt noch ein mp3-player und ob im Hintergrund kompiliert wird oder nicht merkt man gar nicht.
Mike B. schrieb: > glücklicherweise gibt es Hochsprachen, die in annähernd menschlicher > Sprache zu bearbeiten sind > ansonsten könnten wir gleich asm oder hex da reinhämmern Jawoll! Das ist der beste Satz in dem ganzen Thread. Was nützt mir eine Sprache, deren Sytax so verworren ist, daß ich 3 Dolmetscher in Buchform benötige, um dem Kompiler eine für ihn verständliche Zeile vorzusetzen? Der Mist wird durch 10 neue Sprachen pro Jahr immer komplizierter, aber nicht besser. MfG Paul
PiityJ schrieb: > Deshalb bleibe ich seit 35 Jahren bei Basic. Meine vollste Zustimmung!!! Ich gehöre auch dazu;-) 10 for i = 1 to 1000 20 print i 30 next i MfG. Zeinerling
Werner F. schrieb: > 10 for i = 1 to 1000 > 20 print i > 30 next i Druck dir einfach diesen Beitrag aus, dann brauchst du nicht jedes Mal dein BASIC-Programm auszuführen. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000
Ordner schrieb: > Oliver S. schrieb: >> Es gab tatsächlich auch vor C schon höhere Programmiersprachen. > > Ja beispielsweise BASIC (1964). C konnte sich erst nach einer gezielten > Diffamierungskamapagne gegen BASIC durchsetzen (Dijsktra, "GOTO > statement considered harmful", 1968) Das war kein gezielter Angriff auf BASIC. Hier kann jeder das Original-Traktat lesen: http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf Über die Jahrzehnte ist mehr aus diesem kurzen Waschzettel gemacht worden als drin steht. Es war sicher auch keine pro C Kampagne. C hat ja sogar zwei Arten von goto. Das goto in der Sprache und long-jump in der Bibliothek.
Jack schrieb: > Es war sicher auch keine pro C Kampagne. Schon deshalb nicht, weil es damals noch gar kein C gab. :-) (BCPL als Vorläufer gab es schon.) Allerdings gab es massig FORTRAN-Code, und der strotzte nur so von GO TOs. Die beiden Worte konnte man in FORTRAN ja auch auseinander schreiben. Wer mal FORTRAN-Spaghetti gesehen hat, kann Dijkstras Motivation gewiss gut verstehen.
垃圾件 schrieb: > So schwierig kann es doch nicht sein, Programme zu schreiben, die > mit breitenverfügbarer Hardware schnell laufen. Das kommt daher, daß man immer mehr Frameworks und Abstraktionsschichten dazwischen setzt. Was wiederum daher kommt, daß man ansonsten die Entwicklungen nicht in vertretbarer Zeit (und somit auch zu vertretbarem Preis) hinbekäme. Das wiederum liegt daran, daß die Software heute weitaus komplexere Dinge tun soll als früher. Diese Komplexität versteht aber niemand mehr. Also würfelt man sich APIs und Frameworks zusammen, die das bewerkstelligen, was erwünscht wird - mit erheblich mehr Overhead halt. Mike B. schrieb: > unglaublich aber war: Pascal gibt es noch -FreePascal->Lazarus und > Delphi Delphi? Jau, hängt an Embarcadero, die gerade erst dies Jahr den Standort Spanien dichtgemacht haben und 80 Leute gefeuert haben. Damit macht man keine ernsthaften Projekte. Die Misere ging natürlich seinerzeit schon von Borland aus. Bleibt FreePascal, u.a. weil OSS, wodurch man das jederzeit warten kann, falls nötig. Gibt's da eigentlich einen offiziellen Standard, oder ist seit ISO-Pascal weiterhin nur fröhliches Gefrickel einzelner Compilerprojekte angesagt wie zu Zeiten von Turbo-Pascal? Es bleibt allerdings festzustellen, daß das 30 Jahre zu spät kommt und der Zug in der Praxis längst abgefahren ist. Für professionelle Projekte mit Zertifizierungsaspekten sowieso, aus denselben Gründen, wieso man dort nicht GCC einsetzt. > für Pascal reicht es 2x if-then-else logisch zusammen zu kriegen Ja, und die Einrückungstiefen werden dann abenteuerlich. Bei dem von mir geposteten C-Idiom sind die Dinge in einer Zeile, die eben auch direkt zusammengehören. Gut, für Hobbyprogrammierer ist das egal, deren Programme sind erstens nicht groß und werden zweitens auch nicht von wem anders später gewartet werden müssen. Ach ja, und es ist natürlich auch ein Performanceproblem, wenn die Reihenfolge der Auswertung nicht definiert ist. In C setzt man deswegen setzt in UND-Ausdrücken den unwahrscheinlichsten nach vorne, in ODER-Ausdrücken den wahrscheinlichsten. Mag aber kompensiert werden, weil man dafür in FreePascal keine Aliasingprobleme hat, wenn man nicht mit Pointern loslegt. Ordner schrieb: > C konnte sich erst nach einer gezielten > Diffamierungskamapagne gegen BASIC durchsetzen Glaube ich nicht. Basic ist eine Interpretersprache (und damals gab es noch keine Basic-Compiler), C für systemnahe Programmierung (u.a. Interrupts und so ein Zeug). Die stehen zueinander überhaupt nicht in Konkurrenz, weil Basic sowieso zu langsam war für das, wofür man C entwickelt hat. Zweitens hat C ja auch noch goto, wenn auch immerhin nicht mehr mit Zeilennummer, das war bei Basic damals wirklich übel. Drittens gleicht C das aber mehr als aus über die interessanten Möglichkeiten des Präprozessors und der Pointerarithmetik. Diffamieren mußte man übrigens nicht, das "B" stand immer schon für "Beginner" - Basic war noch nie was anderes als eine Anfängersprache. A. K. schrieb: > Der erste Pascal Compiler wurde selbstverständlich in Pascal > geschrieben. Dann hätte man aber das Bootstrap-Problem gehabt. Tatsächlich war es genau umgedreht, der erste Pascal-Compiler hat Pascal erschaffen und Wirth nur vorgeschoben.
Mike B. schrieb: > [...] > dafür peilt man als normalo-Hobby-Programmierer auch beim ersten Blick > was gemeint ist > "if ((ptr != NULL) && (*ptr == Bla))" > um sowas logisch fehlerfrei beisammen zu tippen braucht man 1 Jahr > für Pascal reicht es 2x if-then-else logisch zusammen zu kriegen Wenn man bedenkt, dass manche Leute ja nicht einmal drei Zeilen Text mit Satzzeichen versehen können, wundert mich das nicht. > "if ((ptr != NULL) && (*ptr == Bla))" Wie würde das denn in Pascal aussehen? Zwei Paare Klammern weniger? Wer sich ernsthaft noch an syntaktischen Banalitäten wie 'begin' und 'end' statt geschweifter Klammern oder '&&' statt 'and' stört, der ist mit seiner Programmierkarriere noch nicht einmnal aus dem Kindergarten gekommen...
Nop schrieb: > Für professionelle Projekte > mit Zertifizierungsaspekten sowieso, aus denselben Gründen, wieso man > dort nicht GCC einsetzt. Formal sicher richtig, praktisch aber lächerlich. Als ob ein zertifizierter Compiler weniger Ärger machen würde, als gcc oder sonstwer. Ich empfinde es als eine widerliche Farce, dass heute überhaupt noch Compiler zerzifiziert werden - ich bezweifle nämlich, dass irgendein anderer, kommerzieller Compiler eine Testsuite hat, die auch nur im Entferntesten an die Abdeckung des GCC heranreicht. Das einzige, was man sich mit dem Zertifikat erkauft, ist ein Stück Klopapier über die QS-Prozesse. Und die sind in der Industrie praktisch ausnahmslos genauso erstunken und erlogen, wie Sicherheitsbewertungen nach EN61508 und so weiter.
Jörg M. schrieb: > Warum baut ihr keine perfekte Programmiersprache statt zu meckern? Leider hat Apple/Claris die Sourcen für HyperCard/Hypertalk nie veröffentlicht (Zeit wärs ja, die Jungs habens nie weiterentwickelt). Deswegen bleibt einem nur der Mainstream :-P
Nase schrieb: > Formal sicher richtig, praktisch aber lächerlich. Würde ich so nicht sagen, denn GCC betont in der Lizenz ausdrücklich, daß sie nicht zusichern, daß das Programm für irgendeinen konkreten Einsatzzweck geeignet ist. Dazu kommt, daß man bei GCC keinen Support hat. Man kann nicht mal eben aufgrund eines Wartungsvertrages wen anrufen und am selben Tag eine Antwort erwarten. Sich das im Ernstfall zu Entwickler-Stundensätzen zusammenzugooglen wird sehr schnell sehr teuer, zumal Projektverzug noch weitere Folgen haben kann. Für privat nutze ich GCC aber auch gerne. Wenn ich da herumsuchen muß, ist das aber auch meine Freizeit, und mich interessiert's halt auch einfach. Ob meine Privatprojekte nun heute, morgen oder nächstes Quartal fertigwerden, ist auch egal. Das wäre bei FreePascal aber alles ganz genauso. Nur, was man hier auch mal sehen muß - sowohl Pascal als auch C sind prozedurale Sprachen. Klar finde ich C besser, bin ja von Pascal zu C gewechselt und wollte nie mehr zurück. Aber beide spielen in derselben Liga. C ist nur praxisrelevanter, allein wenn man sich z.B. die verfügbaren RTOS ansieht, die meistens in C daherkommen. Sie teilen aber als prozedurale Sprachen auch dieselben Begrenzungen, weil der Programmablauf sequentiell ist. Multithreading verlangt da schon Handarbeit, und vom verteilten Rechnen mal ganz zu schweigen. Da tut sich auch OOP sehr schwer. Gegen Fehler wie race conditions sind die üblichen C-Pointerfehler ja noch harmlos. Kaj schrieb: > Lisp :) Eher der hier: https://xkcd.com/224/ ^^ Wobei LISP sich genau deswegen nie durchgesetzt hat und es auch nicht wird, weil man zwar alles draus machen kann, aber keine Grundstruktur hingestellt bekommt. Demzufolge gibt es kein LISP-Ökosystem, sondern jeder LISP-Hacker macht sein eigenes Ding.
Nop schrieb: > Würde ich so nicht sagen, denn GCC betont in der Lizenz ausdrücklich, > daß sie nicht zusichern, daß das Programm für irgendeinen konkreten > Einsatzzweck geeignet ist. Das war auch eher umgekehrt gedacht: Glaubst du, dass kommerzielle Compiler irgendwie besser sind? Eher nicht. Eher im Gegenteil: Sie sichern etwas zu, was sie garnicht können... Nop schrieb: > Dazu kommt, daß man bei GCC keinen Support hat. Man kann nicht mal eben > aufgrund eines Wartungsvertrages wen anrufen und am selben Tag eine > Antwort erwarten. Hat dir das schonmal geholfen? Fairerweise jetzt mal bezogen auf Compiler. Erfahrungsgemäß debuggt man doch als Anwender zuerstmal tagelang, bis man tatsächlich beim Tool (Compiler...) angekommen ist ;-)
Nase schrieb: > Das war auch eher umgekehrt gedacht: Glaubst du, dass kommerzielle > Compiler irgendwie besser sind? Eher nicht. Eher im Gegenteil: Sie > sichern etwas zu, was sie garnicht können... Sie gehen aber auch mehr Verpflichtungen ein. Der Haftungsausschluß der GPL ist nach deutschem Recht in dieser Vollständigkeit ohnehin ungültig, weswegen er ja auch einschränkt auf die rechtliche Zulässigkeit. Aber bei kostenloser Abgabe ist da kaum mehr Vorsatz abgedeckt. Bezahlt man Geld, sieht es halt anders aus - allein die Bezahlung läßt die Haftung schon deutlich weitergehen. > Hat dir das schonmal geholfen? Fairerweise jetzt mal bezogen auf > Compiler. Mir selber noch nicht. Allerdings sind die Foren voll von Threads "GCC macht komische Sachen", die meistens nicht am GCC liegen. Wann und ob man eine brauchbare Antwort bekommt, ist halt Glückssache. Kommerziell kann man das mit einem Supportvertrag regeln. MaWin. schrieb im Beitrag #4784487: > So ein Unsinn. Es gibt viele Firmen, die Compiler auf GCC-Basis anbieten > und den Support dazu. Installsupport mit Sicherheit. Beratung auch. Ob sie aber im Ernstfall auch haftbar gemacht werden können, hängt doch sehr davon ab, was genau denn verkauft wurde. Wenn es nur der Support ist, nicht aber das Produkt selber, dann ist das eben was anderes, als wenn das Produkt selber verkauft wurde. Vom Produktverkauf können sie aber nicht leben, weil sie jedem Kunden auch die Sourcen mitsamt Buildscripten aushändigen müssen, und jeder darf das online stellen zum Gratisdownload. Da ergibt sich kein Geschäftsmodell für das Produkt selber. Das Produkt selber ist aber für ernsthafte Sachen AUCH untauglich, weil die GCC-Truppe fest im Lager der language lawyers verankert sind. Siehe Torvalds entsprechende Rants. Die scheren sich nicht darum, was mit den "Kunden" ist, die ja eh kein Geld bezahlen, sondern dafür, den Standard striktestmöglich auszulegen, so daß sie damit gerade noch durchkommen. Egal wieviel Bestandscode zerbricht. Die Schuldzuweisung ist natürlich korrekt, daß der Code selber halt nicht konform ist, aber das hilft den Kunden nicht. Ebensowenig, daß die Lizenz klar sagt "take as is". Dieses Spiel könnte sich eine Firma wie Keil nicht erlauben, weil die Kunden eine neue Version dann einfach nicht kaufen würden. Davon lebt Keil aber. Die Interessenlage ist somit eine deutlich andere - und eine, die ich für professionelle Entwicklung bevorzuge.
Für jeden Zweck gibt es ein passendes Werkzeug. Die Frage ist, ob man effizient und geschickt damit umgehen kann. Auf einem Klavier kann man beispielsweise auch nicht Gitarre spielen (und wenn, dann nur mit sehr großem Aufwand ;-) ). Aber warum gibt es eigentlich keine guten Instrumente? Man muss immer alles von Hand machen! So ein Mist aber auch!
Nop schrieb: > Multithreading verlangt da > schon Handarbeit, und vom verteilten Rechnen mal ganz zu schweigen. Da > tut sich auch OOP sehr schwer. multitherading: OpenMP ein paar pragmas verteilen und schon löpp dat, krieg sogar ich hin verteiltes Rechnen: OpenMPI (effizient geht dann aber anders ;-) ) aber nur für C/C++ bei Pascal gibts das nicht, da gibts nur die TThread-Handarbeit
Mike B. schrieb: >> "if ((ptr != NULL) && (*ptr == Bla))" > um sowas logisch fehlerfrei beisammen zu tippen braucht man 1 Jahr > für Pascal reicht es 2x if-then-else logisch zusammen zu kriegen > > glücklicherweise gibt es Hochsprachen, die in annähernd menschlicher > Sprache zu bearbeiten sind > ansonsten könnten wir gleich asm oder hex da reinhämmern Als allererste Sprache im ersten Jahr ist Pascal ja OK. Aber frag Dich mal, warum mathematische Formeln kompakt dargestellt werden. Oder Noten. Wenn Du "if (ptr && *ptr == Bla)" einmal kennst, kannst Du Code viel schneller erfassen. Sobald Du mit Programmierung Geld verdienst, zählt Produktivität. Da ist es egal, ob es im ersten Jahr ein bisschen einfacher war. Und es geht ausdrücklich nicht um die gesparte Zeit fürs Tippen (die liegt bei wenigen Minuten am Tag), sondern fürs erfassen. Und der Vergleich mit asm oder hex ist doch einfach Quatsch. Was soll das?
Torsten C. (torsten_c) schrieb:
> Aha. Naja, in C# .Net geht das eh nicht ohne (ptr != null).
Jein; kommt auf den Kontext an.
string s = null;
if (s?.Length == 3)
{
...
entspricht
if (s != null && s.Length == 3)
{
...
Nop schrieb: > Dazu kommt, daß man bei GCC keinen Support hat. Man kann nicht mal eben > aufgrund eines Wartungsvertrages wen anrufen und am selben Tag eine > Antwort erwarten. Sich das im Ernstfall zu Entwickler-Stundensätzen > zusammenzugooglen wird sehr schnell sehr teuer, zumal Projektverzug noch > weitere Folgen haben kann. Der nop hat mal wieder keine Ahnung. Schonmal mit dem IAR Support zu tun gehabt? Weil die nicht zu Potte kamen hats schonmal eines meiner Projekte verzögert. Da ist es mir lieber was zum GCC zusammenzugoogeln. Und GCC Supportfirmen gibts wie Sand am Meer, musst nur mal gidf.de aufrufen.
Flitzpiep schrieb: > Jein; kommt auf den Kontext an. Klar, der oben genannte Kontext wäre aber: string s = null; if (s? == "Bla") ... Das geht eben nicht. Aber es ginge mit (s?.ToString() == "Bla") Aber ob das wirkich besser ist?!
Nop schrieb: > Bleibt FreePascal, u.a. weil OSS, wodurch man das jederzeit warten kann, > falls nötig. Gibt's da eigentlich einen offiziellen Standard, oder ist > seit ISO-Pascal weiterhin nur fröhliches Gefrickel einzelner > Compilerprojekte angesagt wie zu Zeiten von Turbo-Pascal? Es gab einen ISO-Working-Draft "Object-Oriented Extensions to Pascal" von 1993. http://www.pascal-central.com/OOE-stds.html Der verlief aber mangels Interesse im Sande. Die heutigen Object-Pascals haben damit ziemlich wenig gemein. Der heutige De-Facto-Standard ist Delphi, an dem sich auch Free Pascal orientiert, und andere Compiler für objektorientiertes Pascal gibt es ja nicht (mehr). > Ach ja, und es ist natürlich auch ein Performanceproblem, wenn die > Reihenfolge der Auswertung nicht definiert ist. Free Pascal macht – entgegen der ISO-Norm – Short-Circuit-Evaluation, was aber abschaltbar ist. Eigentlich gäbe es in Extended Pascal nach ISO 10206) zusätzlich zum normalen "and" und "or" die Operatoren "and then" und "or else", so dass man beide Auswerteprinzipien gleichzeitig zur Verfügung hat. Aber wie alle Bestrebungen, ein einheitliches Pascal zu schaffen, wurde auch ISO 10206 weitgehend ignoriert. Eine Ausnahme ist GNU Pascal, das weitgehend die offiziellen Normen umsetzt. Dafür wurde aber GNU Pascal ignoriert und dessen Entwicklung deswegen schließlich eingestellt.
Torsten C. schrieb: > Flitzpiep schrieb: >> Jein; kommt auf den Kontext an. > > Klar, der oben genannte Kontext wäre aber: > string s = null; > if (s? == "Bla") ... > > Das geht eben nicht. > > Aber es ginge mit (s?.ToString() == "Bla") oder if (s?.Equals("Bla") ?? false) { >>> Aha. Naja, in C# .Net geht das eh nicht ohne (ptr != null). Ist also gleich doppelt widerlegt. > Aber ob das wirkich besser ist?! Nein, beides nicht. Also diesbezüglich das "(N)ein" von "Jein". ;)
Nop schrieb: > Wo man in C Idiome wie "if ((ptr != NULL) && (*ptr == Bla))" machen > kann, hat man in Pascal schonmal zwei Blockebenen. Schon mal was von {$B+} und {$B-} gehört? Wahrscheinlich noch nicht.
Zeno schrieb: > Schon mal was von {$B+} und {$B-} gehört? Wahrscheinlich noch nicht. In welchem Standard ist das dokumentiert? ;-)
Wenn Du eine wirklich gute Programmiersprache brauchst, die alle Deine Wünsche erfüllt, so schreib' sie Dir selber. Wundere Dich aber nicht wenn, außer Dir, alle anderen NICHT Deiner Meinung sind. Darüber hinaus bin ich der Meinung, dass es keine "beste" Programmiersprache gibt. Wie schon von anderen gesagt gibt es für verschiedene Anwendungsziele verschiedene besser oder schlechter geeignete Sprachen. Darüber hinaus gibt es noch die Sprache, mit der der einzelne am besten zurechtkommt und im Zweifelsfalle die auch besten Ergebnisse erreicht. Hier besteht allerdings die Gefahr, dass mit einer Sprache, die als völlig ungeeignet angesehen wird, die besten Ergebnisse erzielt werden;-)
Nop schrieb: > Mag aber kompensiert werden, > weil man dafür in FreePascal keine Aliasingprobleme hat, wenn man nicht > mit Pointern loslegt. Keine Ahnung wie du darauf kommst. Es lassen sich doch problemlos zwei Referenzen auf dasselbe Objekt erzeugen? Das ist Aliasing. Die einzige Sprache, die ich kenne, die sowas verbietet ist Rust (wenn mutable). Aber da war doch irgendwas mit Fortran, wenn ich mich recht erinnere. Nop schrieb: > Nase schrieb: > >> Das war auch eher umgekehrt gedacht: Glaubst du, dass kommerzielle >> Compiler irgendwie besser sind? Eher nicht. Eher im Gegenteil: Sie >> sichern etwas zu, was sie garnicht können... > > Sie gehen aber auch mehr Verpflichtungen ein. Der Haftungsausschluß der > GPL ist nach deutschem Recht in dieser Vollständigkeit ohnehin ungültig, > weswegen er ja auch einschränkt auf die rechtliche Zulässigkeit. Aber > bei kostenloser Abgabe ist da kaum mehr Vorsatz abgedeckt. Bezahlt man > Geld, sieht es halt anders aus - allein die Bezahlung läßt die Haftung > schon deutlich weitergehen. Dann schau mal schnell in die EULAs sämtlicher kommerzieller Software, einschließlich Kompiler. Da haftet niemand, aber zahlen darf man immer und zwar kräftig. BTW wenn du dem GCC solch ein großes Misstrauen begegnest, solltest du gehörig aufpassen. Es gibt da eine Menge Geräte im Medizin- und Sicherheitsbereich auf Linux RT Basis, natürlich gebaut mit GCC.
Die Frage nach der besten Programmiersprache würde sich vielleicht gar nicht stellen, wenn am Ende eh immer das gleiche heraus käme, egal, welche Programmiersprache benutzt wurde. Also so ähnlich wie bei einer 'portable code machine'. Kann man z.B. VHDL oder lisp eigentlich nach p-code 'compilieren'? PS: Die Frage wäre dann: "Wieso gibt es keine gute p-code-Spec?"
Mike B. schrieb: > ein paar pragmas verteilen und schon löpp dat, krieg sogar ich hin Das ist die Trivialvariante, ein paar Schleifen parallelisieren. Es ist aber wesentlich härter, Algorithmen so zu bauen, daß sie vernünftig skalieren. Mal als Beispiel - Schach scheint gut parallelisierbar, ist es aber nicht. Da haben sehr schlaue Leute eine Menge Hirnschmalz investiert. Das Problem ist, daß im Suchbaum bei halbwegs naivem Herangehen sehr viele Sachen doppelt berechnet werden, die mit nur einem Thread eben nur einmal berechnet würden. Deswegen ist die Beschleunigung nicht linear. Und mit naivem Herangehen kriegt man allenfalls bis zu 4 Kernen etwas raus, ab 8 Kernen nicht mehr, und deutlich darüber frißt der Overhead die zusätzlichen Kerne mehr als auf. Tja, und das machen die tatsächlich alles zu Fuß in C oder C++, jedenfalls bei wirklich guten Programmen. Mit dem Ansatz wäre Googles Alpha-Go auf zig Servern gar nicht erst realisierbar gewesen, denn wenn kein geteilter Speicher da ist, wird das alles noch viel schlimmer.
Sebastian S. schrieb: > Wenn Du eine wirklich gute Programmiersprache brauchst, die alle Deine > Wünsche erfüllt, so schreib' sie Dir selber. Das hat man in LISP ja schon. In jedem einzelnen Projekt, was der Grund ist, wieso es geflopt ist. Christopher C. schrieb: > Keine Ahnung wie du darauf kommst. Es lassen sich doch problemlos zwei > Referenzen auf dasselbe Objekt erzeugen? Das kann der Compiler dann aber auch sehen. Etwa, wenn man an dieselbe Funktion zweimal dieselbe Variable by reference übergibt. Für sowas wie void* oder char*, was alles und jeden aliasen darf, muß man sich in Pascal schon sehr anstrengen. > Dann schau mal schnell in die EULAs sämtlicher kommerzieller Software, > einschließlich Kompiler. Da haftet niemand EULAs sind rechtlich irrelevant. Da kann man viel reinschmieren, wenn der Tag lang ist. Ein weitverbreitetes Mißverständnis bei Softwarefirmen ist, daß EULAs geeignet sind, um die Gesetzeslage auszuhebeln.
Mw E. schrieb: > Schonmal mit dem IAR Support zu tun gehabt? > Weil die nicht zu Potte kamen hats schonmal eines meiner Projekte > verzögert. Die Defizite Deiner Rechtsabteilung sind ja nun nicht mein Problem.
Torsten C. schrieb: > Die Frage nach der besten Programmiersprache würde sich vielleicht > gar nicht stellen, wenn am Ende eh immer das gleiche heraus käme, > egal, welche Programmiersprache benutzt wurde. Dann sollte man das Object-Format (neben ABI, Calling-Convention und Name Mangling) standardisieren, aber nicht die Architektur. Relevant wäre doch nur, dass ich die Ergebnisse von einem LISP-Compiler, einem C-Compiler und einem Pascal-Compiler zu einem auch noch debugbaren Programm verkleben könnte. > Also so ähnlich wie bei einer 'portable code machine'. > PS: Die Frage wäre dann: "Wieso gibt es keine gute p-code-Spec?" Java ist meines Wissens gut spezifiziert, und bezahlt dies mit nur mäßiger Performance (und komplizierten JVMs). Warum muss es portabel mit AVR sein, wenn es am Ende ohnehin nur auf ARM64 läuft? In Sachen Performance gibt es da nur wenig Überschneidungen: Was auf ARM64 schnell ist, ist auf AVR langsam /und umgekehrt/. Willst du das wirklich? > Kann man z.B. VHDL oder lisp eigentlich nach p-code 'compilieren'? FreeHDL "kompiliert" VHDL zu C++, während GHDL direkt als GCC-Frontend implementiert ist und direkt Object-Files erstellt. GCL erzeugt Object-Files aus LISP-Code.
S. R. schrieb: > Was auf ARM64 schnell ist, ist auf AVR langsam /und > umgekehrt/. Wenn der p-code gut ist, dann holt er überall raus, was rauszuholen ist. Es muss ja kein JIT-Compiler sein. Es könnte aus p-code ja auch ASM erzeugt werden. > Willst du das wirklich? Interessante Frage. Vielleicht? Falls es gut funktioniert, warum nicht?
Nop schrieb: > ieses Spiel könnte sich eine Firma wie Keil nicht erlauben, weil die > Kunden eine neue Version dann einfach nicht kaufen würden. Davon lebt > Keil aber. Das ist ungefähr so, wie damals der "Browserwar" gerechtfertigt wurde. Anstatt dass die Leute sich Gedanken darüber machen, dass vielleicht wirklich ihr Quelltext semantische Fehler hat, wird solange am Tool herumgebastelt, bis es wieder irgendwie kompiliert. Ich kenne das doch aus eigener Erfahrung aus der Industrie: Keine Sau hat eine Vorstellung davon, was 'volatile' in C bedeutet und wie es sich auf Multitasking auswirkt. Ergebnis: Man schaltet einfach ein paar Optimierungen des Compilers ab und verbaut einen schnelleren Prozessor. Dass solche Programme semantisch einfach falsch geschrieben sind und der Compiler sie deshalb normalerweise großflächig wegoptimiert, realisiert doch niemand. Nop schrieb: > Sie gehen aber auch mehr Verpflichtungen ein. Welche Verpflichtungen denn? Gehen sie mit dir pleite und in den Knast, wenn deine Herzlungenmaschine versagt? Oder war die Risikobewertung doch nicht ganz wasserdicht? Support - ja, Haftung...? Zertifizierte Software ist Augenwischerei.
Torsten C. schrieb: > Die Frage nach der besten Programmiersprache würde sich vielleicht gar > nicht stellen, wenn am Ende eh immer das gleiche heraus käme, egal, > welche Programmiersprache benutzt wurde. Doch, würde sie. Am Beispiel von Assembler und C: Der Output eines C-Compilers war sogar wesentlich schlechter als handprogrammierter Assembler, als C erfunden wurde. Das war auch nicht der Grund, wieso man Hochsprachen erfunden hat. Es geht zentral dabei doch darum, wie leicht man in einer Sprache ein konkretes Vorhaben umsetzen kann. Weil auch die Entwicklungszeit wichtig ist. In C hat man sehr direkten Zugriff auf die Hardware, weswegen es für hardwarenahe Programmierung und Systemprogrammierung super ist. Man muß sich aus demselben Grund aber auch um alles kümmern, weswegen das für große Applikationen nicht so toll ist. C++ versucht, auf allen Hochzeiten zu tanzen und wird zusehends unübersichtlich. Man kann sagen, was man will, aber der wirkliche Knaller in der Produktivität seit C war nicht etwa OOP (ausgenommen GUIs und Simulationen), sondern vor allem automatisches Speichermanagement. Wenn man Algorithmen haben will, in denen man tausende Server zusammenschalten und wegschalten kann, dann ist auch MPI einfach keine brauchbare Option mehr. Man muß sich zuviel auf das Wie konzentrieren und kommt nicht mehr zum Was, und die Bugrate sieht entsprechend aus. Zumal es auch nicht die Frage ist, ob man damit 80% oder 90% rausholt, sondern ob die Skalierung so ist, daß man ÜBERHAUPT mit tausenden Servern gleichzeitig etwas bearbeiten kann. Dafür lohnt es sich auch, was Neues zu machen. Ansonsten wird es für hardwarenahe Programmierung in absehbarer Zeit nichts Besseres als C/C++ geben, was sich auch durchsetzt, weil es dafür nicht relevant ist, ob das Neue "schöner" oder "sauberer" ist. Oftmals ist "gut genug" ausreichend, so daß ein "besser" nicht angenommen wird. Entscheidend sind zwei Faktoren: a) wie groß ist der bestehende Leidensdruck? b) wie groß sind die Umstiegskosten? (Aufgabe bestehender Ökosysteme, Aufgabe unzähliger Source-Sammlungen, Neuentwicklung von Software - die die Kunden nicht bezahlen werden, nur weil die Programmiersprache cooler ist) Sieht man sich den Sprung von Assembler zu C an, wird unmittelbar klar, wieso das akzeptiert wurde, speziell weil die Rechner und damit auch die Software immer größer wurden. Cross-Platform wäre in Assembler gar nicht möglich. Ausnutzen von neuen Prozessor-Features hieße nicht recompilieren, sondern neu programmieren. Sieht man sich den Sprung von C zu einer ähnlich positionierten, aber "saubereren" Sprache an, dann ist der Leidensdruck nicht hoch (Hobbyisten mit C-Allergie sind schlichtweg nicht relevant), die Kosten aber schon. Was stattdessen geht, ist die Kombination aus C und Scriptsprachen wie Python. C für die geschwindigkeitskritischen Sachen, Python mitsamt dem automatischen Speichermanagement für den Rest. Das ergibt Sinn, weil der Leidensdruck da nicht heißt "C ist sooo häßlich mimimi", sondern "C erfordert manuelles Speichermanagement, Python nicht". Für Python gibt es ein großes Ökosystem, also Software ist auch reichlich da. Daß Einrückungen in Python relevant sind, halten etliche (ich auch) für schlecht, ändert aber nichts. Sieht man sich den Krampf von C für GUIs an, ist auch klar, wieso man zu OOP kam. Naja, und sieht man sich den Krampf von C/C++ bei massiv parallelem verteilten Rechnen an, dann ist auch klar, daß hier ein ernsthafter Bedarf bestehen kann.
Nase schrieb: > Anstatt dass die Leute sich Gedanken darüber machen, dass vielleicht > wirklich ihr Quelltext semantische Fehler hat, wird solange am Tool > herumgebastelt, bis es wieder irgendwie kompiliert. Das ist genau das Blameshifting der GCC-Crew. Ja, das ist sachlich völlig korrekt. Nein, die Kunden interessiert das nicht. Und zum Thema Aliasing hat Torvalds ja schon einiges gesagt. Angeblich wegen Performance, so die GCC-Leute, war strict-aliasing auf einmal default. Daten haben sie aber keine vorgelegt, die diesen Schritt gerechtfertigt hätten. Weil es language lawyers sind, die sich nicht für das Ergebnis interessieren. Außer wenn es Benchmarks zerbricht, DANN auf einmal stellen sie sich nicht hin und sagen "nanana, der Standard sagt aber, wir dürfen, und Ihr seid Schuld". Nein, dann auf einmal wird der Compiler so hingebaut, daß Specint wieder läuft, trotz undefiniertem Verhalten. Guckst Du hier: http://blog.regehr.org/archives/918 Nur: kommerziellen Firmen sind ihre Kunden ebensowichtig den GCC-Leuten die Benchmarks. Als Kunde ist klar, was vorzuziehen ist. Übrigens teste ich gerne mit strict-aliasing aktiv. Aber wenn Performance-Messungen da keinen deutlichen Gewinn gegenüber no-strict-aliasing ergeben, dann schalte ich es ab. In einer ziemlich pointer-intensiven Anwendung konnte ich übrigens keinerlei Zugewinn durch strict-aliasing messen.
Nop schrieb: > Das ist genau das Blameshifting der GCC-Crew. Ja, das ist sachlich > völlig korrekt. Das ist nicht nur sachlich korrekt, sondern in vielen Fällen die einzige Möglichkeit, aus dem Dilemma zu kommen. Was soll man denn machen, wenn zig verschiedene Leute jeweils "ihren" fehlerhaften Quelltext übersetzen wollen und dabei "ihr" liebstes Resultat erhalten möchten?
Nase schrieb: > Das ist nicht nur sachlich korrekt, sondern in vielen Fällen die einzige > Möglichkeit, aus dem Dilemma zu kommen. Wie gesagt - diese harte Tour fahren die GCC-Leute nur gegenüber Nutzern. Bei Benchmarks legen sie aber dann eine 180-Grad-Wendung hin und passen den Compiler an den Bestandscode an. Kommerzielle Firmen verhalten sich gegenüber zahlenden Kunden so wie GCC zu Benchmarks. Und nein, es ist oftmals schlichtweg praktisch nicht möglich, aus dem Dilemma rauszukommen, indem man bestehende Codebasen ändert. Deswegen compiliert der Linuxkernel mit no-strict-aliasing, und für Release empfehle ich das auch - jedenfalls solange nicht Meßdaten eindeutig einen massiven Vorteil von -strict-alising im konkreten Fall belegen. Was sie in den allermeisten Fällen schlichtweg nicht tun.
Torsten C. schrieb: >> Was auf ARM64 schnell ist, ist auf AVR langsam /und >> umgekehrt/. > Wenn der p-code gut ist, dann holt er überall raus, was rauszuholen ist. Das ist prinzipbedingt unmöglich. Schaue dir die üblichen Programmierstile für AVR und x86 an und du weißt, warum. > Es muss ja kein JIT-Compiler sein. > Es könnte aus p-code ja auch ASM erzeugt werden. Genau das tut ein JIT ja. >> Willst du das wirklich? > > Interessante Frage. Vielleicht? > Falls es gut funktioniert, warum nicht? Dann nimm Java, da bist du nah genug dran.
Lassen wir doch die Portierglaeubigen, die ihren Code auf irgendwelchen Plattformen zwischen ATTiny und Quadcore 64 Bit hin und her portieren wollen etwas weitertraeumen. Ich denk die haben genausowenig etwas portiert wie ich. Fuer mich ist ein Projekt zusammen mit der Hardware und dem Compiler, sowie dessen Version eingefroren. Ich portiere nicht mal von Compiler Version 7 nach Version 8. Neue Projekte werden mit der aktuellen Version des Compilers begonnen, und bleiben auf dieser Version. Vielleicht wird ein Teil ruebergezogen, wird dann aber angepasst. Zurueck geht's nicht mehr, Ist weder geplant, noch macht es Sinn.
Oh D. schrieb: > Ich denk die haben genausowenig etwas > portiert wie ich. Doch, zwischen x86 und Cortex-M. x86 als test bed für die business logic, weil es sich wesentlich leichter testen und debuggen läßt. Weiterer Vorteil ist, daß so ein Vorgehen automatisch ein sauberes Kapseln der Abhängigkeiten von Hardware und Betriebssystem erzwingt.
Christopher C. schrieb: > Dann schau mal schnell in die EULAs sämtlicher kommerzieller Software, > einschließlich Kompiler. Beim Konflikt zwischen Haftungsausschluss und Lizenzbedingungen und dem deutschem Recht dürfte es um sowas wie Haftung bei Vorsatz gehen.
A. K. schrieb: > Christopher C. schrieb: >> Dann schau mal schnell in die EULAs sämtlicher kommerzieller Software, >> einschließlich Kompiler. > > Beim Konflikt zwischen Haftungsausschluss und Lizenzbedingungen und dem > deutschem Recht dürfte es um sowas wie Haftung bei Vorsatz gehen. Das sowieso, der gilt übrigens auch bei FOSS mit free wie in Bier. Aber man kann sich aus der Produkthaftung nicht einseitig verabschieden, nur weil man zufällig Software herstellt. Sobald man das kommerziell macht, ist man da drin, egal was man in die EULA schreibt. Wenn da grobe Fahrlässigkeit im Spiel ist, ist man halt dran. Wäre ja noch schöner, wenn man per EULA Gesetze aushebeln könnte. Das ist übrigens durchaus keine Theorie, wenn man sich mal anschaut, was Toyota seinerzeit mit dem Camry verzapft hat. Das war haarsträubend unprofessionell. Leute sind umgekommen, und weil es US-Amerikaner waren, wurde das für Toyota sehr teuer, denn dort ist man für grobe Fahrlässigkeit mit Todesfolge nicht mit einem Trinkgeld dabei. (Quelle: http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/ )
A. K. schrieb: > Christopher C. schrieb: >> Dann schau mal schnell in die EULAs sämtlicher kommerzieller Software, >> einschließlich Kompiler. > > Beim Konflikt zwischen Haftungsausschluss und Lizenzbedingungen und dem > deutschem Recht dürfte es um sowas wie Haftung bei Vorsatz gehen. Das ist natürlich klar, dass man bei Vorsatz belangt werden kann. Nur kann man einfach auf Grund von Bugs nach deutschem Recht, wohl kaum bestraft werden. Selbst den Juristen ist klar, dass es fehlerfreie Software nicht gibt (ab gewisser Komplexität). Das würde eigentlich nur gehen, wenn sie dir das schriftlich garantieren. Aber wer wäre so wahnsinnig? Das ist schlicht unkalkulierbar. Erst recht bei Kompilern mit praktisch unendlicher Eingabemöglichkeit. Außerdem würde wohl so ziemlich niemand freiwillig haften. Da müsste man, wenns mal um richtig was geht, schon den Rechtsweg gehen. Das dürfte viel Zeit dauern und ordentlich Geld kosten.
Christopher C. schrieb: > Nur > kann man einfach auf Grund von Bugs nach deutschem Recht, wohl kaum > bestraft werden. Doch kann man - und zwar wenn die Entwicklung selber sich nicht an den üblichen oder gar vorgeschriebenen Stand der Technik gehalten hat, weil das dann keine Bugs sind, sondern grobe Fahrlässigkeit. Bei grobem Pfusch in regulierten Bereichen wie z.B. Luftfahrt können Leute dann auch durchaus in den Knast kommen.
Nop schrieb: > Doch kann man - und zwar wenn die Entwicklung selber sich nicht an den > üblichen oder gar vorgeschriebenen Stand der Technik gehalten hat, weil > das dann keine Bugs sind, sondern grobe Fahrlässigkeit. Aber um sowas geht's ja hier nun wirklich nicht. Es geht eben nur darum, dass es ein Trugschluss ist, dass man, nur weil man für einen IAR einen mittleren vierstelligen Betrag bezahlt hat, automatisch irgendeine Garantie oder gar Haftung des Herstellers mit bekäme. Für diesen (durchaus stolzen) Preis bekommt man diesbezüglich kaum mehr als für den GCC, nämlich bestenfalls eine Zusage, dass einem der Support auch zuhört und ggf. den Bug überhaupt erstmal aufnimmt. Klar bekommt man von IAR auch irgendwelche Varianten mit einer Garantie, Probleme innerhalb eines bestimmten Zeitraums zu beheben, aber das kostet dann nochmal eine Stange mehr.
Jörg W. schrieb: > Es geht eben nur darum, dass es ein Trugschluss ist, dass man, nur > weil man für einen IAR einen mittleren vierstelligen Betrag bezahlt > hat, automatisch irgendeine Garantie oder gar Haftung des Herstellers > mit bekäme. Ein Trugschluß ist eher der verbreitete Glaube, bei Software ließen sich per EULA sämtliche Gesetze aushebeln, Produkthaftung gelte nicht mehr, und man könne ohnehin machen, was man will. Und selbstverständlich kommt automatisch eine Gewährleistung (!) mit dem Kauf - genau wie bei jedem anderen gekauften Produkt. Leute, wenn Ihr jede Software akzeptiert, weil Software halt buggy ist und man ja eh nichts machen kann, dann liegt der Fehler klar bei Eurer Rechtsabteilung. Bei einem finanziell gesehen verschenkten GCC gibt es keine Gewährleistung, weil es keinen Vertrag gibt, den man notfalls mindern oder wandeln kann. Produkthaftung beschränkt sich bei geschenkter Software auch auf allenfalls Vorsatz (z.B. eingebaute Malware). Man hat dementsprechend auch kein "Druckmittel", um schnell einen Fix zu kriegen. Niemand verwendet kommerziell in sensiblen Bereichen GCC. Was anderes ist es natürlich für Geräte, die sowieso unter embedded Linux laufen - wenn das fürs Produkt denn zulässig ist, dann nimmt man natürlich auch gleich GCC, weil es halt zusammenpaßt. Oder für Projekte, die ohnehin Opensource sein sollen. Da ergibt es kaum Sinn, zwar die Sourcen zu öffnen, aber mit Keil/IAR eine Paywall vor den Build zu setzen.
Nop schrieb: > Und selbstverständlich kommt automatisch eine Gewährleistung (!) mit dem > Kauf - genau wie bei jedem anderen gekauften Produkt. Und? Die gewährleistet dir, dass das Ding überhaupt benutzbar ist. Trotzdem kann es für genau deinen Anwendungsfall einen Bug haben. Einen konkreten Bug bekommst du ja auch akzeptiert, aber eben ohne das Versprechen, bis wann der repariert sein wird. Die reparierte Version bekommst du dann schon noch, und das ist alles, was du aus dem Gewährleistungsanspruch erwarten kannst.
Nop schrieb: > Ein Trugschluß ist eher der verbreitete Glaube, bei Software ließen sich > per EULA sämtliche Gesetze aushebeln, Produkthaftung gelte nicht mehr, > und man könne ohnehin machen, was man will. Und selbstverständlich kommt > automatisch eine Gewährleistung (!) mit dem Kauf - genau wie bei jedem > anderen gekauften Produkt. Hast du diese zugegebenermaßen doch naive Kausalkette denn mal in der Praxis erlebt? Praktisch macht nämlich der kommerzielle Compiler-Hersteller mit teurem Support-Vertrag nämlich genau eines, wenn ihm wirklich einmal ernsthaft ans Bein gepinkelt werden soll: Er betreibt Blameshifting bis zum abkratzen, um dir als Kunden irgendeinen Verstoß gegen den - Trommelwirbel - C-Standard nachzuweisen, am liebsten natürlich mit undefined behaviour. Das macht er nämlich viel lieber, als horrende Strafen zu bezahlen. In dem Moment scheißt der auf dich als Kunden genauso, wie es jeder popelige Handwerksbetrieb in der freien Wirtschaft tun würde. Nop schrieb: > Niemand verwendet kommerziell in sensiblen Bereichen GCC. Dem kann ich widersprechen. Ich kann weiters bestätigen, dass viel beschissenere Compiler in viel sensibleren Bereichen verwendet werden. Meistens dann auch noch in steinmurmelalten Versionen inklusive aller ungefixten Bugs, weil ein Update schweineteuer ist. Ich kann außerdem bestätigen, dass das Niveau, auf dem in der Industrie programmiert wird, um Lichtjahre unterirdischer ist, als das, auf dem üblicherweise Open Source betrieben wird. Wach mal auf. Deine ideale Argumentation spricht mir aus der Seele. Die Praxis ist frustrierend. Und das habe ich mindestens bis SIL2 erlebt.
Jörg W. schrieb: > Einen konkreten Bug bekommst du ja auch akzeptiert, aber eben ohne > das Versprechen, bis wann der repariert sein wird. Die reparierte > Version bekommst du dann schon noch, und das ist alles, was du aus > dem Gewährleistungsanspruch erwarten kannst. Das stimmt nicht. Gewährleistung heißt nicht, daß der Händler (!) beliebig viel Zeit hätte. Frist setzen, evtl. Nachfrist setzen, Rücktritt. Mit "wird irgendwann repariert" braucht sich kein Kunde zufriedenzugeben. Das würdest Du bei einem Autokauf auch nicht akzeptieren, und anders als manche Softwarefirmen das denken, gelten für Software keine Sondergesetze. Auch die EULAs entfalten keinen Gesetzesrang - und sind ohnehin nichtig, wenn man die erst NACH dem Kauf zu lesen bekommt. Zumal bei Software der Nachweis, daß der Fehler von Anfang an drin war, trivial ist.
Nop schrieb: > Das stimmt nicht. Gewährleistung heißt nicht, daß der Händler (!) > beliebig viel Zeit hätte. Frist setzen, evtl. Nachfrist setzen, > Rücktritt. Mit "wird irgendwann repariert" braucht sich kein Kunde > zufriedenzugeben. > > Das würdest Du bei einem Autokauf auch nicht akzeptieren, und anders als > manche Softwarefirmen das denken, gelten für Software keine > Sondergesetze. Auch die EULAs entfalten keinen Gesetzesrang - und sind > ohnehin nichtig, wenn man die erst NACH dem Kauf zu lesen bekommt. > > Zumal bei Software der Nachweis, daß der Fehler von Anfang an drin war, > trivial ist. Das ist richtig - aber im konkreten Fall hilft einem das doch wenig. Bis zur Behebung können mit Fristsetzung etc. gerne mal viele Wochen ins Land gehen. Oder dem Compilerhersteller ist das zu lästig und er sagt einfach: "Och nee, hier haste Dein Geld zurück. Her mit dem Lizenzschlüssel." Dann hat man nicht viel gewonnen, außer dass man sich zusätzlich zum Projektdruck auch noch einen neuen Compiler/Toolchain suchen kann. Davon abgesehen kenne ich keinen Compilerfehler, den man nicht umgehen kann. Selbst wenn man also einen Fehler im GCC findet, dann sollte der sich umgehen lassen, bis er gefixt ist. Das Fixen dauert vermutlich weniger lange als auf das Bugfixing eines Compilerherstellers zu warten. Der wird erstmal ausführlich testen und schauenm, bevor er da etwas ändert. Unterstützung in Compilerfragen etc. - ja, das sehe ich ein. Dafür kann man sinnvoll Geld ausgeben. Aber das kann man auch beim GCC, wenn gewünscht.
Nop schrieb: > Zumal bei Software der Nachweis, daß der Fehler von Anfang an drin war, > trivial ist. Dann weis doch mal nach, dass z.B. eine fehlerhafte Optimierung - um beim Beispiel des Compilers zu bleiben - ursächlich für dein Problem ist. Möglicherweise noch eine, die nur sporadisch zum Fehler in deiner Anwendung führt (Randwerte, vorzeichenbehaftete Arithmetik und solche Schmankerl). Nop schrieb: > Das stimmt nicht. So läuft es aber. Versuch deine Rechte doch mal bei Microsoft durchzusetzen, wenn du im Business einen Bluescreen hast oder Office dir privat deine Arbeit zerschossen hat. Office hat damals(tm) fast 500 Euro gekostet.
Nase schrieb: > Dann weis doch mal nach, dass z.B. eine fehlerhafte Optimierung - um > beim Beispiel des Compilers zu bleiben - ursächlich für dein Problem > ist. Man sieht sich das Disassembly der betroffenen Routine an. Das ist bei allen Compilern der Weg, wie man Compilerfehler überhaupt nachweist. Bei GCC ist derlei üblicherweise in den Bugreports drin, weil die Compiler-Entwickler sonst nicht wissen können, was denn gefixt werden soll. Das ist auch der Unterschied zu sporadischen Abstürzen von Windows. Weis mal nach, daß die überhaupt da sind. Chris D. schrieb: > Dann hat man nicht viel gewonnen, außer dass man sich zusätzlich zum > Projektdruck auch noch einen neuen Compiler/Toolchain suchen kann. Wie lange kann ein kommerzieller Compilerhersteller das tun? Vor allem in Zeiten des Internet? Bis sich die Kundenschicht schon VOR Projektbeginn ein andere Toolchain sucht? Im Vergleich dazu besehe man sich die Reaktion des GCC-Teams auf Torvalds Rants. DAS kann sich ein kommerzieller Hersteller gegenüber seinen Kunden einfach nicht erlauben. Der Linuxkernel ist zwar eine der wichtigsten GCC-Anwendungen, aber es fließt eben kein Geld. Eine grundsätzliche Schwäche bei OSS-Projekten. Wer zahlt, bestellt auch die Musik - aber ohne Bezahlen kein Musikwunsch.
Nop schrieb: > Wie lange kann ein kommerzieller Compilerhersteller das tun? So lange, wie es Kunden gibt, die aus was für Gründen auch immer darauf angewiesen sind, Geld für eine Toolchain zu bezahlen. Und alleine das "im Falle eines Falles den eigenen Arsch retten", was man für das Geld bekommt, sorgt dafür, daß das immer genug bleiben werden, egal, wie die Anbieter da mit den Kunden umgehen. Oliver
Nop schrieb: > Man sieht sich das Disassembly der betroffenen Routine an. Das ist bei > allen Compilern der Weg, wie man Compilerfehler überhaupt nachweist. Du schon, ich vielleicht auch. 'Man' aber gewiss nicht. Praktisch läuft das eher so: - Im Feld berichtet dein Kunde von einer Baugruppe (dein Produkt), die manchmal seltsame Dinge macht. - Es läuft zwei Wochen durch die QS/Serviceabteilung deines Unternehmens, bis du davon erfährst. - Es dauert einen Monat, die betroffene Baugruppe zu dir zu schaffen, damit du per Analyse Hardwarefehler ausschließen kannst. - Du baust dir parallel dazu einen Test auf, kannst das Problem mangels Rahmenparameter von vor Ort aber nicht reproduzieren. - Der Kunde meldet sich nochmals. - Nächste Woche wird ein Vor-Ort-Termin angesetzt, damit du Fehler suchen kannst. - Beim Termin vor Ort steht die Anlage gerade, macht also auch keine Fehler. Alternativ reißt dir der Schichtleiter den Kopf ab, wenn du die Anlage anhälst um dein Debug-Zeug anzuschließen. - Du fährst wieder heim und brütest drei Tage über dem Quelltext in der Hoffnung, analytisch/formal etwas zu finden. Der Quelltext ist aber semantisch in Ordnung. - 42: Irgendwie kriegst du den Fehler dann tatsächlich zufällig nachgestellt und fängst an, das (hypothetisch korrekte) Programm systematisch zusammenzustreichen, um irgendwie auf eine reduzierte Codebasis unter 5.000 Zeilen zu kommen, die den Fehler reproduziert. Bei jedem zweiten Versuch ist der Fehler wieder weg. Goto 42. - Irgendwann beginnst du an dir zu zweifeln und druckst Assemblies aus und wälzt Datenblätter des Controllers und Bücher über Zweierkomplement oder über Linkerskripte. - Irgendwann fällt dir im Map-File auf, dass Adressen subtil verrutscht sind, was bei relokatierenden Builds ja nicht ungewöhnlich ist. Der Groschen ist gefallen und du findest ein defektes Linkerskript, durch das versehentlich ein wichtiges Register des Prozessors als RAM verwendet wird. - Mit dieser Information findest du auch den seit über fünf Monaten gefixten Bug im Tracker des Compiler-Herstellers. Du resignierst, weil die Firma nicht bereit ist, schon wieder €€€€ für ein Update zu bezahlen und frickelst händisch im Linkerskript herum. Den Bug gabs bei avr-gcc. Und jetzt denk dir noch eine MMU und Ethernet dazu. Der Compiler-Hersteller wird dich bestenfalls fragen, ob du das letzte Bulletin nicht gelesen hast. Nop schrieb: > Eine grundsätzliche Schwäche bei OSS-Projekten. Kann auch eine Stärke sein. Fork und gut.
Nop schrieb: > Wie lange kann ein kommerzieller Compilerhersteller das tun? Vor allem > in Zeiten des Internet? Bis sich die Kundenschicht schon VOR > Projektbeginn ein andere Toolchain sucht? Egal. Wie lange kannst du dir das erlauben, bis du keine Compiler mehr hast? Aktuell ist N(Compiler) << N(Kunden). Wie schnell kriegst du dein Projekt portiert? Compiler-Hersteller sind auch nicht blöd. Wenn Xilinx neue FPGAs rausbringt und die alten loswerden will, verdoppeln sie einfach die Preise. Und? Klar gibts Altera, Atmel, Cypress und so weiter. Und wie schnell hast du das Redesign durch...? Ich habe gerade Handwerker im Haus. Morgens sammle ich deren Spaxschrauben vom Garagenboden und abends kann ich ihren Müll wegräumen. Und hier ist N(Handwerker) ~ N(Kunden), die wollen mein Geld, nicht umgekehrt. Trotzdem interessierts keinen.
Nase schrieb: > - Mit dieser Information findest du auch den seit über fünf Monaten > gefixten Bug im Tracker des Compiler-Herstellers. Du resignierst, weil > die Firma nicht bereit ist, schon wieder €€€€ für ein Update zu bezahlen > und frickelst händisch im Linkerskript herum. > > Den Bug gabs bei avr-gcc. > Und jetzt denk dir noch eine MMU und Ethernet dazu. Das passt nicht Zusammen. avr-gcc ist soweit ich weiss gratis. Wenn man auf einer noch supporteten Version ist, und ein derart kritischer Bug taucht auf, wird das nicht nur die neusten Version, sondern in allen noch supporteten Versionen gefixt. Im moment vermutlich die 6.x.x, 5.x.x und eventuell 4.x.x. Wo entstehen da bitte kosten, wenn man einen neueren Kompiler nimmt und der eigene Code dem C-Standard entspricht? Und was hat eine MMU und Ethernet mit all dem zutun?
Daniel A. schrieb: > Das passt nicht Zusammen. avr-gcc ist soweit ich weiss gratis. Wenn man > auf einer noch supporteten Version ist, [...] Das war einfach ein reales Beispiel, in diesem Fall mit dem GCC. GCC ist gratis, der Bug war schon längst gefixt, aber ich hatte trotzdem mit einem alten GCC zu tun. Der Projektleiter war halt so "klug", die Toolchain komplett mit dem Projekt nebst VM einzufrieren, "damit nix passiert". Der Ablauf ist aber grunsätzlich unabhängig vom Compiler oder von der Programmiersprache überhaupt usw. > Wo entstehen da bitte kosten, wenn man einen > neueren Kompiler nimmt und der eigene Code dem C-Standard entspricht? Kannst dir ja mal Preislisten von IAR, Codevision und WND schicken lassen. > Und was hat eine MMU und Ethernet mit all dem zutun? Das macht die Fehlersuche weitaus unüberschaubarer, als der durchschnittliche Programmierer es zu handhaben vermag. Vorallem nicht, wenn man seine Build-Tools anzweifeln muss - normalerweise verlässt man sich ja beim Debuggen zumindest darauf.
Nase schrieb: > Ich kann außerdem bestätigen, dass das Niveau, auf dem in der Industrie > programmiert wird, um Lichtjahre unterirdischer ist, als das, auf dem > üblicherweise Open Source betrieben wird. Jaja genau Diese Truppe hat bei meinem Arbeitgeber auch die Macht übernommen. Da beschäftigen sich tausende leute mit irgendwelchen makefiles und optimierung des buildprozesses. Von den leuten ist ja keiner in der Lage eine SPI oder Uart zu programmieren wenn man nix passendes in der Community findet. Was rauskommt frisst alle Resourcen die der baustein hat die Geräte leisten weniger als das was 10 jahre lang gut war. Am besten alles auf Kommandozeile und mit einer primitive Debug Umgebung. Da lobe ich mir doch meinen IAR oder Keil. Zum glück habe ich nur noch 6 Monate bis zum Ruhestand.
Und warum ist es jetzt die Schuld des Compilers, dass die Kollegen nix auf der Pfanne haben?
Nop schrieb: > Niemand verwendet kommerziell in sensiblen Bereichen GCC. Gut zu wissen, dass Schummelsoftware[tm] nicht sensibel ist ;-)
hal9000 schrieb: > das was 10 jahre lang gut war. > [...] Zum glück habe ich nur noch 6 Monate bis zum Ruhestand. Solche Leute haben wir auch. Die halten verbissen an ihrem zenn Jahre alten Kram fest, weil das ja schon immer so war, verweigern jegliches Fortkommen und blockieren wichtige Entscheidungen. Deshalb darf ich mich heute auch ab und an mit völlig veraltetem Müll herumschlagen, um deren Baustellen anzupassen, mit primitivem Debugging auf DOS-Prompt. Denen ists nämlich jetzt egal, die haben nur noch ein halbes Jahr bis zur Rente und nach ihnen die Sintflut.
Angehängte Dateien:
-
compilerswitch.JPG
58 KB
Mike B. schrieb: > ... >> Wo man in C Idiome wie "if ((ptr != NULL) && (*ptr == Bla))" machen >> kann, hat man in Pascal schonmal zwei Blockebenen. > > dafür peilt man als normalo-Hobby-Programmierer auch beim ersten Blick > was gemeint ist > "if ((ptr != NULL) && (*ptr == Bla))" > um sowas logisch fehlerfrei beisammen zu tippen braucht man 1 Jahr > für Pascal reicht es 2x if-then-else logisch zusammen zu kriegen Genau für solche Sachen gibt es (bei Pascal) Compilerschalter, im konkreten Fall $B- . Diesen setze ich entweder in den Projekteinstellungen oder im Quelltext am Anfang des Programmes oder dort wo ich ihn brauche. Mal ein Beispiel für Letzteres :
1 | (* vollständige Prüfung boolscher Ausdrücke abschalten *) |
2 | {$B-}
|
3 | if (ptr <> nil) and (ptr^ = 'Bla') |
4 | then begin |
5 | ... |
6 | end; |
7 | ... |
8 | |
9 | (* vollständige Prüfung boolscher Ausdrücke wieder einschalten *) |
10 | {$B+}
|
Für so etwas braucht es keine 2 Blockebenen. Diesen Compilerschalter gibt es definitiv ab Borlandpascal 7.0 (bei Turbopascal weis ich es nicht ganz genau), Virtualpascal, Freepascal, Lazarus und natürlich auch bei Delphi. Angehängtes Bild ist aus der Hilfe von Virtualpascal. Ich mache das bei mir meist in den Projekteinstellungen, da gilt dies für alle im Projekt benutzten Quelltextdateien. Man muß bei so was natürlich die Reihenfolge beachten, also erst Existenz des Zeigers prüfen und dann den Inhalt abfragen, denn sonst kracht es falls der Zeiger nicht initialisiert ist. Das ist aber in allen Programmiersprachen so. Jörg W. schrieb: >> Schon mal was von {$B+} und {$B-} gehört? Wahrscheinlich noch nicht. > > In welchem Standard ist das dokumentiert? ;-) Wozu brauche ich da einen Standard? Mir reicht es wenn der Compiler die passenden Stellschrauben hat. Ist ja letztendlich bei C auch nicht anders. Zeno
Zeno schrieb: > Wozu brauche ich da einen Standard? In diesem speziellen Fall darf man wohl davon ausgehen, dass jeder Compiler einer Pascal-ähnlichen Sprache so einen Schalter mitbringt oder Bedingungen gleich von vorneherein kurzschliessend implementiert. Dieses Problem der Sprache ist offenkundig und die Lösung liegt auf der Hand. Für andere Sprachfeatures ist das weniger einfach. Nicht jeder Sprachschöpfer sieht die gleichen Probleme und dafür auch die gleichen Lösungen. Dann sind Standards schon nützlich.
Zeno schrieb: > Genau für solche Sachen gibt es (bei Pascal) Compilerschalter, im > konkreten Fall $B- In C gibts dafür eine eigentlich recht intuitive Regel im Sprachschatz. Zeno schrieb: > Ich mache das bei mir meist in den Projekteinstellungen, da gilt dies > für alle im Projekt benutzten Quelltextdateien. Damit hast du aber auch gleich das gravierende Problem erfasst: Es reicht nicht mehr, den Quelltext zu lesen. Beispiel: In C kenne ich die Regel mit der Short-Circuit-Evaluation, auf der dein Beispiel fußt (wenn der erste !=0-Vergleich fehlschlägt, wird der zweite garnicht erst ausgeführt). Wenn ich das irgendwo im Quelltext lese, habe ich die Semantik vollständig erschlossen. Wenn ich dasselbe in einem Pascal-Quelltext lese, muss ich erst nach Compilerschaltern und Projekteinstellungen in anderen Dateien herumsuchen, um rauszukriegen, wie so eine if-Bedingung bewertet wird. Der Quelltext ist also jetzt abhängig von Rahmenbedingungen, sofern man nicht händisch im Quelltext immer die Schalter setzt, die man gerade braucht. Beispiel: Du bindest eine Pascal-Unit ein. Jetzt müsste entweder der Autor diese Unit in selbiger die Schalter bedienen oder du müsstest nachsehen, welche Schalter der Autor erwartet. Wenn du immer mit B+ arbeitest und das in den Projekteinstellungen festlegst, kracht es in der Unit, wenn deren Autor B- benutzt hat.
Zeno schrieb: > Wozu brauche ich da einen Standard? Weil ein Standard dazu führt, dass man "Dinge" vereinheitlichen und damit verschiedene Quellen austauschen bzw. kombinieren kann. In der Nicht-Virtuellen Welt bedeutet dies, dass bei allen ein Meter auch ein Meter lang ist und wenn ich einen 100 Meter langes Kabel bestelle, ich auch 100 Meter nach meinen Vorstellungen bekomme, egal bei wem ich es bestelle.
Zeno schrieb: > Genau für solche Sachen gibt es (bei Pascal) Compilerschalter, Nein. Für solche Sachen gibt es in deinem Turbo-Pascal Compilerschalter. Ob es die bei jedem Compiler gibt, und ob die bei jedem Compiler gleich heißen und auch das im Detail das gleiche tun, weißt du nicht. Und darum gibt es Standards. Dein Programm mag ja fix auf dein TP abgestimmt sein, aber für eine wiederverwendbare Unit sollte das nicht gelten.
A. K. schrieb: > Zeno schrieb: >> Wozu brauche ich da einen Standard? > > In diesem speziellen Fall darf man wohl davon ausgehen, dass jeder > Compiler einer Pascal-ähnlichen Sprache so einen Schalter mitbringt oder > Bedingungen gleich von vorneherein kurzschliessend implementiert. Dieses > Problem der Sprache ist offenkundig und die Lösung liegt auf der Hand. Keine Ahnung ob/welche Compiler das implementieren 1), aber es gibt im Pascal-Standard (ebenso wie bspw. in Eiffel ) and_then/or_else (bzw. and then und or else) http://www.eah-jena.de/~kleine/history/languages/iso-iec-10206-1990-ExtendedPascal.pdf 1) z.B. http://www.gnu-pascal.de/gpc/and-then.html
@ turbo autist: Du bist herzlichst dazu eingeladen, die perfekte Programmiersprache für uns zu entwickeln, damit wir "Beschränkten" endlich wissen, was wirklich gut ist. Kopfschüttel
rmu schrieb: > Ist bekannt, aber es hat sich irgendwie überholt. Kenne nichts und > niemanden der irgendwas in Pascal, Delphi oder Lazarus neu entwickelt. Klappt hervorragend, sehr großes Projekt. Mess- & Regelungstechnik auf x86 Industrie PC Basis. Mit Server Anbindung, alles selbst geschrieben. In Turbo Pascal und DOS gestartet, dann gab es eine 32 Bit Version für DOS/Windows von einer kleinen amerikanischen Softwarefirma. Nach einigem Abwägen dann auf Freepascal umgestellt. Mittlerweile auf Linux portiert. Bis heute sehr gut damit gefahren. Die Bedienerfreundlichkeit von Lazarus könnte besser sein. Auch der Anfang ist für unerfahrene wohl etwas holprig. Habe damit sogar schon embedded Code für einen STM32 ARM Prozessor geschrieben und ausgeführt. Die Community ist klein aber fein.
Der E. schrieb: > Du bist herzlichst dazu eingeladen, die perfekte Programmiersprache für > uns zu entwickeln, damit wir "Beschränkten" endlich wissen, was wirklich > gut ist. Komisch, dass den noch niemand brachte. Na denn, 2 xkcds hatten wir schon, aber aller guten Dinge sind 3: https://xkcd.com/927/
A. K. schrieb: > Der E. schrieb: >> Du bist herzlichst dazu eingeladen, die perfekte Programmiersprache für >> uns zu entwickeln, damit wir "Beschränkten" endlich wissen, was wirklich >> gut ist. > > Komisch, dass den noch niemand brachte. Na denn, 2 xkcds hatten wir > schon, aber aller guten Dinge sind 3: https://xkcd.com/927/ Einfach Katahdin nehmen... "Katahdin is a programming language where the syntax and semantics are mutable at runtime... There are no special constructs in Katahdin that cannot be modified, including white-space and basic tokens." http://chrisseaton.com/katahdin/ https://github.com/chrisseaton/katahdin/
Zeno schrieb: > Ist ja letztendlich bei C auch nicht anders. Ist da sehr wohl anders. Jeder ordentliche Compiler implementiert den Standard, und man kann fast alles (außer dem OS selbst oder einem Scheduler oder andere Spezialfälle) in der Tat als strictly conforming program verfassen. Das wiederum muss sich unter allen Compilern gleich verhalten. Das heißt natürlich, dass ein solches Programm auf solche Gimmicks wie dein $B+ nicht bauen kann (-f<something> bei GCC, irgendwelche #pragmas bei anderen Compilern). Arc N. schrieb: > and_then/or_else Spät genug hat offenbar jemand eingesehen, dass shortcut evaluation ein sinnvolles Feature ist.
Was hier noch gar nicht vor kam: graphische Programmiersprachen. Ich bin der Meinung, eine richtig gute Programmiersprache muss graphische Anteile beinhalten. Weil: ein Bild sagt mehr als tausend Worte. LabView zeigt hier schon mal einen guten Weg auf. Allerdings muss man sagen, dass bestimmte Teile eines Projektes am besten klassisch einfach Zeilen-orientiert gelöst werden. Eine richtig gute Programmiersprache enthält beide Elemente in ausgeglichener Ordnung, also sowohl graphische Elemente für die strukturelle Übersicht als auch klassische Elemente für einfache Algorithmik. Die UML-Generatoren sind dahingehend eine Fehlentwicklung weil sie weder schön, noch einfach, noch übersichtlich sind. Aber verständlich ist auch: Wer sein leben lang nur die Zeilenorientierung kennt und gewohnt ist, wird sich mit anderem schwer tun. Außerdem ist es natürlich so, dass die Menschen unterschiedlich denken: Während die einen graphisch in Bildern denken, denken andere eher in Texten.
chris_ schrieb: > LabView zeigt hier schon mal einen guten Weg auf. Findest du? LabView ist ein prima Spielzeug, um mal eben einen Prüfstand mit bisschen Messen/Steuern/Regeln zu programmieren. Oder im Labor. chris_ schrieb: > Wer sein leben lang nur die > Zeilenorientierung kennt und gewohnt ist, wird sich mit anderem schwer > tun. Andersrum geht das aber auch: Wer mal ernsthaft mit graphischen Auswüchsen programmiert hat, merkt schnell, wie unflexibel und mühsam das ist. Ich kenne als Vertreter der graphischen "Programmiersprachen" jetzt LabView und im weiteren Sinne z.B. auch XILINX ISE/Vivado oder Altera Quartus für programmierbare Logik. Mit allen dreien habe ich größere Projekte (mit-)umgesetzt und bei allen dreien war ich (waren wir) anschließend heilfroh, wieder davon wegzukommen hin zu einer "textbasierten" Programmierung. Die LabView-Programme sind irgendwann einfach nicht mehr zu pflegen, weil allein schon Refactoring eine Katastrophe ist. Man kann halt nicht einfach durch den Quelltext navigieren, jedes Stück ist eher ein Bild als irgendwas systematisch Programmiertes. Bei Xilinx ists für Toplevel ganz nett, wenn man ein Blockschaltbild malen kann. Letztlich hat man aber leider auch wieder nur proprietären Binärmüll in der Hand. Daher nimmt man dann doch gerne wieder VHDL/Verilog.
Nun als jemand der sowohl in Pascal als auch in C programmiert kann ich dir folgendes sagen. Pascal ist fuer schnelle Tools besser man kommt wesentlich schneller zum Ziel. Schau dir nur mal das stringhandling an. Zig verschiedene Funktionen die sich in irgendwelchen Header Dateien befinden. Dazu dann noch unverständliche Fehlermeldungen. Wer hat noch nie suspicious Pointer conversion gesehen? Das ist in Pascal besser gelöst. Allerdings auch wesentlich langsamer. Was die Compiler Schalter in Pascal sind sind die pragmas in C eben nicht portabel. Woher kommen denn die ganzen Buffer overflow leaks? Sicher nicht von Pascal Programmen dort wird das zur Runtime überwacht. Mir ist schon klar dass Pascal sicher veraltet ist doch für schnelle Problem Lösungen setze ich das nach wie vor ein. Thomas
chris_ schrieb: > Was hier noch gar nicht vor kam: graphische Programmiersprachen. > Ich bin der Meinung, eine richtig gute Programmiersprache muss > graphische Anteile beinhalten. Naja, wie immer gilt: "Richtig gut" ist halt lediglich eine relative Bewertung, nach irgendwelchen individuellen Kriterien. Deswegen gehören DSLs* auch schon seit Jahrzehnten zum Werkzeugkasten "richtig guter" Informatiker. PS, allgemeiner Rant: Bisweilen täten E-Techniker gut daran in Sachen SW auf Informatiker zu hören anstatt selbst etwas zu "basteln". Es mag erstaunen, aber Informatiker haben während ihres Studiums nicht nur Eier geschaukelt sondern auch eine Menge sehr nützliche Dinge bezüglich SW erlernt. Dinge, von denen ein E-Techniker i.d.R. keinen blassen Schimmer hat. Sein wir ehrlich, wenn man einen E-Techniker bittet SW zu erstellen kommt dabei nicht selten genau so ein Murks heraus (aus der Sicht eines SW-Spezialisten) wie wenn man einen Informatiker bittet HW zu entwerfen (aus der Sicht eines HW-Spezialisten). *: Domain Specific Language, siehe auch https://de.wikipedia.org/wiki/Dom%C3%A4nenspezifische_Sprache
Thomas schrieb: > Schau dir nur mal das stringhandling an. Ja, das war in Pascal früher eine Zumutung. Es gab alle Stringfunktionen doppelt, einmal für PChar auf dem Heap und einmal für string, bei dem die Stringlänge im ersten Byte stand und damit auf 255 Zeichen beschränkt war. Thomas schrieb: > Zig verschiedene > Funktionen die sich in irgendwelchen Header Dateien befinden. Naja, abseits von der eher akademisch angehauchten STL hat sich da vieles getan. Strings in Qt sind zum Beispiel herrlich simpel. #include <QString> Thomas schrieb: > Was die Compiler Schalter in Pascal sind sind die pragmas in C eben > nicht portabel. Mit dem Unterschied, dass solche elementaren Dinge in C nicht per unportablem Schalter sondern im Sprachstandard festgelegt werden. Thomas schrieb: > Woher kommen denn die ganzen Buffer overflow leaks? Daher, dass Pascal in der Wildnis praktisch keine Relevanz hat... > Sicher nicht von > Pascal Programmen dort wird das zur Runtime überwacht. Wenn man den Compilerschalter einschaltet.
Jörg W. schrieb: > Spät genug hat offenbar jemand eingesehen, dass shortcut evaluation > ein sinnvolles Feature ist. Mhh. Ich bin mir da nicht sicher, ob die das nicht schon eingesehen hatten als in Ansi-C die Auswertungsreihenfolge solcher Ausdrücke noch "depents on the implementation" war. Und DAS war damals unter UNIX auch immer ein beliebter Fehler, das bekannte (*p && p->x++) ;-) Ansonsten muss ich gestehen, dass ich Lazarus (also Freepascal als Compiler) inzwischen auch gerne benutze. Macht Spass, ist plattformunabhängig und hat eine nette & hilfreiche Community. /regards
Nase schrieb: > Thomas schrieb: >> Woher kommen denn die ganzen Buffer overflow leaks? > Daher, dass Pascal in der Wildnis praktisch keine Relevanz hat... Ich frage mich immer wieder woher Leute glauben zu wissen, was relevant ist. Hast Du da stabile (!) Zahlen? Ich wäre da wirklich mal neugierig. Denn leider kriegt man ja meist nur die "paar" Ideen, die in Foren diskutiert werden. Aber das ist nur ein Bruchteil der existierenden SW. Ich kenne einige (auch aktuelle) "größere" Projekte die in Delphi entwickelt werden. Allerdings hängen da überall DICKE NDAs drauf :/ /regards
Andreas H. schrieb: > Projekte die in Delphi entwickelt werden. Da faellt mir ein sehr aktuelles Beispiel ein ;) The first cryptor to exploit Telegram https://securelist.com/blog/research/76558/the-first-cryptor-to-exploit-telegram/
1 | The Telegram Trojan is written in Delphi and is over 3MB in size. |
Ach, es ist zwar grad nicht Freitag, aber doch nett, mal wieder so einen höchstwissenschaftliche Disput genießen zu können. Ein paar Perlen sind mir dabei schon aufgefallen: rmu schrieb: > Kenne nichts und > niemanden der irgendwas in Pascal, Delphi oder Lazarus neu entwickelt. Tja, wenn du die Augen zu machst, dann siehste eben nix. Kleiner Tip: Programmiertool für STM32 von mir hier im Forum. btw: eine Lazarus-Version hab ich inzwischen auch fertig. Funktioniert gut wie die Delphi-Version. Sieht mir aber zu grau aus. Also: Mach deine Klüsen auf, dann siehst du auch was. Nase schrieb: > Als ob ein zertifizierter Compiler weniger Ärger machen würde, als gcc > oder sonstwer. Ich empfinde es als eine widerliche Farce, dass heute > überhaupt noch Compiler zerzifiziert werden - Es geht um's Geld. Ganz speziell um die Position vor Gericht, wenn es Zoff gibt - und den gibt es bei den heutigen Programmerern fast immer. Nochmal: Es geht definitiv NICHT um Sachgründe, Support oder Qualität, sondern um das Vorweisenkönnen eines Zertifikates vor dem Kadi. Jörg W. schrieb: >> Schon mal was von {$B+} und {$B-} gehört? Wahrscheinlich noch nicht. > > In welchem Standard ist das dokumentiert? ;-) Jörg, ich hab das schon immer vermutet: Du bist Beamter, sonst könntest du nicht auf so eine komische Frage kommen. Vielleicht hilft es dir, daß Standards in aller Regel von den Leuten aus der Industrie gemacht werden, die beispielsweise im VDMA vertreten sind und dort logischermaßen ihr Ding in einem passenden Standard festklopfen. Ich sag's mal brüsk: Standard ist DAS, was unsereiner macht. Basta. Aufgeschrieben wird's hinterher. 123457890 schrieb: > In der Nicht-Virtuellen Welt bedeutet dies, dass bei allen ein Meter > auch ein Meter lang ist Scherzbold! Du solltest beachten, daß ein Meter in der realen Welt eben nur dann exakt ein Meter ist, wenn du stillstehst und alle anderen auch. Sonst eben nicht, lies mal Einsteins Relativitätstheorie. So, das sollte für einen leicht verspäteten 11.11. ausreichen - HELAU W.S.
Andreas H. schrieb: > Jörg W. schrieb: >> Spät genug hat offenbar jemand eingesehen, dass shortcut evaluation >> ein sinnvolles Feature ist. > > Mhh. Ich bin mir da nicht sicher, ob die das nicht schon eingesehen > hatten als in Ansi-C die Auswertungsreihenfolge solcher Ausdrücke noch > "depents on the implementation" war. Und DAS war damals unter UNIX auch > immer ein beliebter Fehler, das bekannte (*p && p->x++) ;-) Wo hast du das denn her? Selbst lange vor ANSI-C war das schon eindeutig festgelegt. Hier beispielsweise in der Doku von 1974: https://www.bell-labs.com/usr/dmr/www/cman74.pdf (7.11 und 7.12)
> Ist ja letztendlich bei C auch nicht anders.
Ist da sehr wohl anders.
Ich denke nicht?!?
Ich denke der MS Compiler nutzt nicht mal den neuesten Standard!
Was bringen Standards wenn aber nicht jeder Compiler sie nutzt?!?
BEi PAScal ist Delphi Fakto!! der Standard, den Schalter wirst Du also
sowohl bei Delphi als auch bei PAscal7 als auch Free Pascal und Mikroe
Pascal finden finden
Somit ist es ein Standard!! Nur eben nicht von irgeneinem Gremium das
niemand braucht wenn es Usus ist
Max S. schrieb: > Ich denke der MS Compiler nutzt nicht mal den neuesten Standard! Ja, dann benutzt er aber zumindest den vorhergehenden. Wie oben gezeigt, boolean shortcut evaluation war schon vor mehr als 40 Jahren definiert, da gab's noch gar keinen offiziellen Standard. > Somit ist es ein Standard! Nun gut, dann kann man sich einfach auf nichts verlassen, sondern nur hoffen, dass es so ist. Dann sollte man sich nur nicht wundern, dass die Programmiersprache trotz netter Features ein vergleichsweises Nischendasein fristet. Und nein, daran sind nicht die anderen dann schuld.
Max S. schrieb: > Was bringen Standards wenn aber nicht jeder Compiler sie nutzt?!? Umgekehrt: Was nutzt ein Compiler, der keinem Standard folgt?
Johann L. schrieb: > Was nutzt ein Compiler, der keinem Standard folgt? Er setzt einen neuen de-facto Standard, mindestens für seinen Autor. ;-)
Max S. schrieb: > Ich denke der MS Compiler nutzt nicht mal den neuesten Standard! Microsoft hat eigene Interessen, was die Verwendung von Sprachen angeht. C und C++ sind da nicht im Fkus. > BEi PAScal ist Delphi Fakto!! der Standard, Bin grad mal quer durch die Sprachref von Free Pascal. Es scheint bei den Borland-Pascals und deren Derivaten Dialekte zu geben, Abweichungen im Verhalten gleicher Sprachelemente. Ein Problem von de-facto Standards ist die oft fehlende Klarheit, welche Sprachaspekte eine geforderte Eigenschaft sind, und wo Unterschiede in der Implementierung zulässig sind. Das erschwert sowohl in der Implementierung der Sprache als auch in der Nutzung die klare Erkenntnis, was man machen darf und was nicht. Wenn dann in neuen Versionen bereits bestehende Sprachelemente sich abweichend verhalten, dann kann das etwas überraschend kommen, weil sich erst zu diesem Zeitpunkt herauskristallisiert, was der Implementor als gemeinsamen Sprachteil versteht, und was als Implementierungsfreiheit. Formal standardisierte Sprachen versuchen in einer neuen Version des Standards so weit wie möglich Kompatibilität zum Vorgänger zu wahren.
A. K. schrieb: > Max S. schrieb: >> Ich denke der MS Compiler nutzt nicht mal den neuesten Standard! > > Microsoft hat eigene Interessen, was die Verwendung von Sprachen angeht. > C und C++ sind da nicht im Fkus. C nicht, das stimmt, aber wie kommst du auf C++? Da hat sich in den letzten ~2 Jahren bei MS sehr viel getan. Herb Sutter, Stephan Lavavej usw. sind ja nicht gerade die Schlechtesten.
Potzblitz schrieb: > C nicht, das stimmt, aber wie kommst du auf C++? Da hat sich in den > letzten ~2 Jahren bei MS sehr viel getan. Ok, ich bin da nicht ganz up to date.
Mir stellt sich beim Lesen der Beiträge gerade nur eine Frage: Ist eine gute Programmiersprache nicht die, die das gerade aktuelle Problem einfach zu lösen vermag? Klar hat jede Sprache vor- und nachteile, aber wenn damit das Problem gelöst werden kann, ...?
A. K. schrieb: > Potzblitz schrieb: >> C nicht, das stimmt, aber wie kommst du auf C++? Da hat sich in den >> letzten ~2 Jahren bei MS sehr viel getan. > > Ok, ich bin da nicht ganz up to date. Na dann :) Hier: https://www.heise.de/developer/meldung/Visual-Studio-15-Fuenfte-Preview-bringt-vor-allem-Neuerungen-fuer-C-3341903.html
Ich schrieb: > Ist eine gute Programmiersprache nicht die, die das gerade aktuelle > Problem einfach zu lösen vermag? Aber was, wenn das morgige Problem damit nicht mehr einfach zu lösen ist? Ist sie dann immer noch gut, oder ist morgen eine andere Sprache auch gut, die es heute noch nicht war? Und nach einem Jahr hast du 365,25 irgendwann einmal gute Sprachen auf der Platte?
Jörg W. schrieb: > Jeder ordentliche Compiler implementiert den Standard, und man kann > fast alles (außer dem OS selbst oder einem Scheduler oder andere > Spezialfälle) in der Tat als strictly conforming program verfassen. > Das wiederum muss sich unter allen Compilern gleich verhalten. Darüber könnte man (am besten in einem anderen Thread) trefflich streiten... Bspw. die Ausnahme, die es für die SPEC-Benchmarks gibt "The GCC maintainers subsequently disabled this optimization for the case occuring in SPEC, demonstrating that, inofficially, GCC supports C bench, not “C”" http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf > Das heißt natürlich, dass ein solches Programm auf solche Gimmicks > wie dein $B+ nicht bauen kann (-f<something> bei GCC, irgendwelche > #pragmas bei anderen Compilern). > > Arc N. schrieb: >> and_then/or_else > > Spät genug hat offenbar jemand eingesehen, dass shortcut evaluation > ein sinnvolles Feature ist. Der Standard ist von 1990. Wann gab's nochmal den ersten C-Standard? Ansi C89/ISO C90 bzw. kann ich mangels griffbereitem uralt K&R-Buch nicht sagen, ob die das vor der Standardisierung auch so gesehen haben. Zudem gilt das ganze für C++ nicht mehr sobald dort ein Typ mit entsprechend überladenen Operatoren auftaucht, dann wird alles ausgewertet...
Arc N. schrieb: > Der Standard ist von 1990. Wann gab's nochmal den ersten C-Standard? > Ansi C89/ISO C90 bzw. kann ich mangels griffbereitem uralt K&R-Buch > nicht sagen, ob die das vor der Standardisierung auch so gesehen haben. Das ältere K&R-C war auch eine Art Standard, in Form ebendieses Buches, wenngleich kein von einem Gremium wie ISO abgesegneter. Aber ein schwacher, weil darin zu wenig festgelegt wurde. Das war aber schon ein deutlich weiter entwickeltes C und unterschied sich erheblich von der ursprünglichen Version.
Arc N. schrieb: > Darüber könnte man (am besten in einem anderen Thread) trefflich > streiten... Du meinst, inwiefern dieser Benchmark "strictly conforming" ist? Aber lassen wir das, ich weiß, dass du mit den GCC-Entwicklern bezüglich der Aliasing-Regeln nicht konform gehst. Denk aber dran, dass im C-Standard solche Dinge nicht deshalb "implementation defined" sind, weil es irgendwer besonders toll fand, sondern weil es zum Zeitpunkt der Entscheidung bereits verschiedene Varianten gab, irgendwas zu implementieren, und man keine davon für ungültig erklären wollte. > Der Standard ist von 1990. Wann gab's nochmal den ersten C-Standard? 1989. Allerdings habe ich weiter oben eine C-Referenz von Dennis Ritchie von 1974 zitiert, in der dieser Aspekt bereits genauso klipp und klar festgeschrieben war.
S. R. schrieb: > Nein. Für solche Sachen gibt es in deinem Turbo-Pascal Compilerschalter. > Ob es die bei jedem Compiler gibt, und ob die bei jedem Compiler gleich > heißen und auch das im Detail das gleiche tun, weißt du nicht. Ich habe doch ausreichend Pascalimplementierungen genannt und bei den genannten ist es definitiv so.
Nase schrieb: > Beispiel: Du bindest eine Pascal-Unit ein. Jetzt müsste entweder der > Autor diese Unit in selbiger die Schalter bedienen oder du müsstest > nachsehen, welche Schalter der Autor erwartet. Wenn du immer mit B+ > arbeitest und das in den Projekteinstellungen festlegst, kracht es in > der Unit, wenn deren Autor B- benutzt hat. Nein muß der Autor eben nicht. Er könnte es in der Unit, um mal bei dem von mir zitierten Beispiel zu bleiben, auch mit zwei if Blöcken erledigen. Wie der Autor in seiner Unit mögliche Fehler abfängt bleibt ihm überlassen. Ob er dies mit Compilerschaltern, Try Blöcken oder auf irgendeine andere Art und Weise fehlerhafte Programmzustände abfängt ist ihm überlassen. Meine Projekteinstellungen bleiben davon unberührt. Das ist halt der Vorteil des Unitkonzepts von Pascal. Ja und und natürlich wird mein Programm crashen, wenn es in der eingebundenen Unit zum Fehler kommt. Zeno
Die einfachste Programiersprache ist die die man selber am besten versteht, und wenn Mann / Frau die logik versteht, dann ist das doch einfach. Meine kenntnisse: 6500 8080 Maschienensprache, ist aber schon 30 Jahre her, wo ich das gemacht hatte. 68000 Assembler AVR-GCC Object-C , Swift Basic, verschiedene varianten. HTML Also nicht jammern warum es keine gescheite Sprache gibt.
Arc N. schrieb: > Zudem gilt das ganze für C++ nicht mehr sobald dort ein Typ mit > entsprechend überladenen Operatoren auftaucht, dann wird alles > ausgewertet... Das ist tatsächlich eine gemeine Falle. Und es ist meiner Meinung nach ein guter Grund, warum man das Überladen von operator&& und || nicht hätte erlauben dürfen. Es zwingt einen aber auch niemand dazu sie zu überladen. Fällt dir ein Beispiel ein wann man einen der beiden Operatoren überladen möchte?
Zeno schrieb: > S. R. schrieb: >> Nein. Für solche Sachen gibt es in deinem Turbo-Pascal Compilerschalter. >> Ob es die bei jedem Compiler gibt, und ob die bei jedem Compiler gleich >> heißen und auch das im Detail das gleiche tun, weißt du nicht. > > Ich habe doch ausreichend Pascalimplementierungen genannt und bei den > genannten ist es definitiv so. Die Frage ist nicht, ob es für deine drei bevorzugten Implementierungen gilt, sondern ob es für alle gilt und ob du denen das ansehen kannst, ohne vorher deren Dokumentation vollständig zu lesen. Wenn an einem C-Compiler "ANSI-C" dransteht, dann kann der mindestens C89, und zwar - Ausnahmen ausgenommen - vollständig. Ein Compiler, an dem "Pascal" dransteht, kann ein beliebig schwammiges, möglicherweise imkompatibles Subset von dem, was der Delphi-Compiler kann. Und wenn da "Delphi" dransteht, gibt es zwei relevante Möglichkeiten: Es ist der Delphi-Compiler, oder es ist gelogen. Und wie sieht es mit GNU- oder ACK-Pascal aus?
Zeno schrieb: > Nein muß der Autor eben nicht. Er könnte es in der Unit, um mal bei dem > von mir zitierten Beispiel zu bleiben, auch mit zwei if Blöcken > erledigen. Aha. Hast du uns nicht gerade noch erklärt, dass es genau dafür Compilerschalter gibt? > Meine Projekteinstellungen bleiben davon unberührt. Seine aber auch. Wie gehst du denn vor, wenn du Quelltext eines Kollegen einbindest? Fragst du ihn vorher, ob du B+ oder B- einstellen musst? Oder liest du dir den ganzen Quelltext durch und schaust nach, ob er es immer brav mit zwei if-Blöcken ausprogrammiert hat bzw. mit {B+} markiert hat?
Max S. schrieb: > der Standard, den Schalter wirst Du also > sowohl bei Delphi als auch bei PAscal7 als auch Free Pascal und Mikroe > Pascal finden finden Bei AVRco-Pascal aber nicht.
Flitzpiep schrieb: > Jein; kommt auf den Kontext an. > > string s = null; > > if (s?.Length == 3) > { > ... > > entspricht > > if (s != null && s.Length == 3) > { > ... Ja, C# ist schon toll. Die armen Embedded-Ing-Fuzzies, die sich noch mit C oder C++ rumschlagen müssen, tun mir leid. Aber die denken noch, sie wären die Elite, weil sie Steinzeit programmieren.
A. K. schrieb: > Ein Problem von de-facto Standards ist die oft fehlende Klarheit, welche > Sprachaspekte eine geforderte Eigenschaft sind, und wo Unterschiede in > der Implementierung zulässig sind. Das erschwert sowohl in der > Implementierung der Sprache als auch in der Nutzung die klare > Erkenntnis, was man machen darf und was nicht. Wobei das Problem von undefinierten Eigenschaften in Nicht-C-Sprachen ein deutlich kleineres bis vernachlässigbares ist. In dem Beispiel hier der Shortcut-Auswertung ist das ja eine gewünschte Eigenschaft. D.h. wenn sich ein Pascaldialekt von einem anderen unterscheidet, dann ist das bewusst so gemacht worden (d.h. bewusst nicht-Defacto-Standard-konform) und nicht auf eine fehlende Definition zurückzuführen. In der Pascalphilosophie hat eine implizite Short-Cut-Auswertung m.E. sowieso keinen Platz, der Fallstrick, dass eine Funktion mit Nebenwirkung nicht gerufen wird, ist zu groß. Dagegen halte ich eine explizite Short-Cut-Auswertung mit or else für sehr elegant. Wenn man auf die Shortcut-Auswertung (durch Kompilerswitch) verzichtet, dann läuft man eigentlich keine Gefahr einen bestehenden Code zu sprengen. Dass es Sprachdialekte gibt ist sicherlich der Verbreitung nicht gerade dienlich. Insbesondere wenn man mit einer 100% abwärtskompatiblen Sprache konkurriert, die gerade noch gut genug ist um auf Embedded-Platformen produktiv zu sein. Dialekte ermöglichen aber auch Fortschritt, welcher durch Standardisierung und Abwärtskompatibilität stark ausgebremst wird. C ist auch so konzipiert wie Windows, es hat eine intrinsische Selbserhaltung und ein Monopolisierungsdrang. Eine automatische Übersetzung von C in eine andere Sprache ist doch kaum möglich.
Nase schrieb: > Zeno schrieb: >> Nein muß der Autor eben nicht. Er könnte es in der Unit, um mal bei dem >> von mir zitierten Beispiel zu bleiben, auch mit zwei if Blöcken >> erledigen. > Aha. Hast du uns nicht gerade noch erklärt, dass es genau dafür > Compilerschalter gibt? Lesen kannst Du schon? Dort steht "könnte", d.h. er kann es so machen, er könnte ebenso den erwähnten Compilerschalter benutzen oder er kann auch von Anfang an dafür Sorge tragen, daß der Zeiger im Beispiel garantiert zum Abfragezeitpunkt zugewiesen ist, dann brauche ich den Zeiger nämlich gar nicht zu prüfen. Nase schrieb: > Wie gehst du denn vor, wenn du Quelltext eines Kollegen einbindest? > Fragst du ihn vorher, ob du B+ oder B- einstellen musst? Oder liest du > dir den ganzen Quelltext durch und schaust nach, ob er es immer brav mit > zwei if-Blöcken ausprogrammiert hat bzw. mit {B+} markiert hat? Ja das ist halt der kleine aber feine Unterschied von Pascal zu C: Ich brauche nicht unbedingt den Quelltext um fremden Code in mein Projekt einzubinden, da die kompilierte Unit völlig ausreichend ist, wenn sie mit der gleichen Hauptversion des Compiler gebaut wurde, den auch mein Projekt benutzt. Das ist aber meist kein Problem da Pascalprogrammierer in aller Regel angeben mit welchem Compiler die weiter gegebene Unit erstellt wurde. Ich muß von der fremden Unit nur wissen welche Prozeduren und Funktionen im Interfaceteil deklariert sind (Name) und die dazugehörigen Übergabeparameter kennen. Wie der Autor der Unit die Aufgabe intern gelöst hat, wie er die Fehlerbehandlung löst ist für die Benutzung der Unit uninteressant. Das Durchforsten des Quelltextes entfällt also an dieser Stelle. Informiere Dich einfach mal über das Unitkonzept von Pascal bzw. das Packagekonzept von Delphi/Lazarus. Nase schrieb: > Max S. schrieb: >> der Standard, den Schalter wirst Du also >> sowohl bei Delphi als auch bei PAscal7 als auch Free Pascal und Mikroe >> Pascal finden finden > Bei AVRco-Pascal aber nicht. Dann ist das eben so. Dieser Pascaldialekt ist aber eher ein Nischenprodukt und wenn ich damit arbeite, dann lese ich das Handbuch dazu, wo so etwas drin steht. Im Übrigen ging es mir nur darum, zu zeigen das die von nop aufgestellte Behauptung, das so etwas wie
1 | if ((Prt != null) && (*Ptr == ...) ... |
in Pascal nicht möglich wäre, so nicht ganz richtig ist. Es gibt halt in der überwiegenden Mehrheit der für den PC benutzten Pascaldialekte diesen speziellen Schalter. Das von Max genannte AVRco-Pascal ist da eine Ausnahme. Zeno
Top-Entwickler schrieb: > Ja, C# ist schon toll. Naja so toll ist C# nun auch wieder nicht obwohl es schon einige nette Features hat, z.B. nullable Variable. Leider hat man es mal wieder nicht konsequent gemacht, indem alle Typen generell nullable sind (man muß ja die nullable Eigenschaft nicht nutzen), sondern ein spezielles Konstrukt bei der Deklaration geschaffen. Bei Structs funktioniert dieses Konzept gar nicht. Richtig interessant wird es dann aber mit WPF. Da kann fast alles verbrechen im wahrsten Sinne des Wortes, aber es ist dennoch Krampf. Zeno
Tommi schrieb: > Eine automatische > Übersetzung von C in eine andere Sprache ist doch kaum möglich. Da faellt mir spontan Emscripten ein: C/C++ -> JavaScript Abgesehen davon ist das bei anderen Sprach auch nicht besser.
Nase schrieb: > Daher, dass Pascal in der Wildnis praktisch keine Relevanz hat... Das ist sicher der Grund dafür daß jeder Programmiersprachenthread spätestens ab Seite 2 sich unweigerlich in einer C vs. Pascal Endlosschleife aufhängt. Nicht C vs. D, nicht C++ vs. Go, nicht C++ vs. Objective-C, nicht <irgendwas> vs. <sonstwas> sondern immer zielsicher C/C++ vs. Pascal oder alle vs. Pascal. Für etwas das angeblich keine Relevanz hat scheint da doch ein ganz schöner Rechtfertigungszwang auf der gegnerischen Seite zu herrschen, da scheut man auch nicht davor zurück unfairer Weise heutiges C++ mit 30 Jahre altem Universitäts-Pascal zu vergleichen weil einem gegen aktuell eingesetztes Industrie-Pascal (FPC, Delphi) schnell die sachlichen Argumente ausgehen würden.
Bernd K. schrieb: > Für etwas das angeblich keine Relevanz hat scheint da doch ein ganz > schöner Rechtfertigungszwang auf der gegnerischen Seite zu herrschen Wozu rechtfertigen? Schau dir doch einfach die realen Verhältnisse an. Die paar größeren Projekte, die in Pascal-ähnlichen Sprachen geschrieben sind und nennenswerte Verbreitung gefunden haben, kannst du schon fast an den Fingern zweier Hände abzählen. Von all denen, die mir in letzter Zeit übern Weg gelaufen sind, fällt mir gerade nur cqrlog ein (ein Logbuchprogramm für den Amateurfunk). Industrie? Kann ja sein, dass da auch zuweilen Pascal-Dialekte da sind, aber ich programmiere nun seit 26 Jahren in der Industrie, bisher hat noch kein einziger Kunde auch nur danach gefragt. (Nein, ich habe auch nicht nur Mikrocontroller programmiert in meinem Leben, daran allein liegt's also auch nicht). Ich fand Pascal damals wirklich gut, auf CP/M war es die Erlösung, um nicht alles aufwändig in Assembler hacken zu müssen. Aber die derzeitige Realität ist eine andere, und die kann ich mir nicht aussuchen, wenn ich damit meine Brötchen verdienen muss. Dafür muss ich halt (vor allem) C, C++ und Python können.
Bernd K. schrieb: > Das ist sicher der Grund dafür daß jeder Programmiersprachenthread > spätestens ab Seite 2 sich unweigerlich in einer C vs. Pascal > Endlosschleife aufhängt. Nein, aber es ist ziemlich einfach, auf ein typisches und häufiges Problem von C (Pufferüberlauf) einzudreschen und im gleichen Atemzug so sagen, dass es mit Sprache XYZ viel seltener passiert, wobei Sprache XYZ dann aber im Vergleich einen lächerlichen Marktanteil hat. Bernd K. schrieb: > Für etwas das angeblich keine Relevanz hat scheint da doch ein ganz > schöner Rechtfertigungszwang auf der gegnerischen Seite zu herrschen, Wo liegt denn Pascal im Moment z.B. im TIOBE-Index? 1,5%? 1,9%? Tschuldigung, aber so realistisch muss man auch mal sein. > da > scheut man auch nicht davor zurück unfairer Weise heutiges C++ mit 30 > Jahre altem Universitäts-Pascal zu vergleichen weil einem gegen aktuell > eingesetztes Industrie-Pascal (FPC, Delphi) schnell die sachlichen > Argumente ausgehen würden. Mangelnde Einsicht ist aber augenscheinlich auch ein Kernfeature bei Pascal-Anhängern. Du bist jetzt übrigens der erste, der ein unfaires Totschlag-Argument mit C++ konstruiert.
>Aber die derzeitige Realität ist eine andere, und die kann ich mir nicht >aussuchen, wenn ich damit meine Brötchen verdienen muss. Dafür muss >ich halt (vor allem) C, C++ und Python können. ... und Java wegen dem Handyboom. Es hängt alles von den Endgeräten und deren Betriebssystem ab. Es geht nicht mehr darum, ob eine Programmiersprache gut oder schlecht ist - das war früher wo Speicherbedarf noch ein Thema war anders. Nächste Tendenz werden dann wahrscheinlich Satzbaukasten Programmiersprachen sein ): sieht man ja jetzt schon im Bereich Homepage. Einzig und allein der Verbreitungsgrad und die Marktführerschaft ist maßgebend - da hat sich damals C gegenüber Pascal, Fortran und Forth durchgesetzt und heute ist es eben Java wegen des Handybooms und ggf. noch Objective C wegen iphone oder Visual C++ wenn es um Windows geht. Je nach Anwendungsbereich gibt es noch eine Programmiersprache, die im Bereich x marktführend ist. Damit mußt Du Dich als Programmierer abfinden, privat kannst Du gerne andere Sprachen nutzen, z.B. Ada, Fortran, Basic, Assembler, usw. - aber das interessiert sonst niemanden mehr. Das Mittelmaß setzt sich immer irgendwie durch ):
A. K. schrieb: > Ich schrieb: >> Ist eine gute Programmiersprache nicht die, die das gerade aktuelle >> Problem einfach zu lösen vermag? > > Aber was, wenn das morgige Problem damit nicht mehr einfach zu lösen > ist? Ist sie dann immer noch gut, oder ist morgen eine andere Sprache > auch gut, die es heute noch nicht war? Und nach einem Jahr hast du > 365,25 irgendwann einmal gute Sprachen auf der Platte? Ja, natürlich, wenn du jeden Tag ein Problem aus einer anderen Domain zu lösen hast, dann könnte das passieren. Ist ja auch nichts schlimmes. Eine der wichtigsten Sachen, die man im Informatik-Studium lernt, ist doch, daß man 1. das Problem analysiert 2. eine Lösungsmöglichkeit findet 3. diese Lösung in einer dafür passenden Sprache implementiert. In der Industrie wird gerne die Reheinfolge umgestellt und ide Sprachauswahl aus Schritt 0 vorgegeben. Und dann wundert man sich bei manchen Projekten, warum die Umsetzung so lange dauert und so fehlerträchtig ist. BTST. Für manche Probleme ist eben C gut geeignet, bei anderen nimmt man besser C++ oder Perl oder J oder Icon oder Erlang oder ... - die wurden ja nicht zum Spaß erfunden, sondern weil da jemand verstanden hatte, daß eine passende Sprache langfristig günstiger ist als mit einer nicht wirklich passenden "Universalsprache" (die es eben in der Realität nicht gibt) alles lösen zu wollen.
Jörg W. schrieb: > bisher > hat noch kein einziger Kunde auch nur danach gefragt. Also bei uns läuft das anders. Der Kunde stellt eine Anforderung was er haben möchte, was im allgemeinen über ein Lastenheft läuft. Wie wir das Ganze dann umsetzen, supporten etc. ist unsere Sache. Bisher hat uns noch kein Kunde vorgeschrieben in welcher Programmiersprache wir das zu tun hätten. Die einzigen die uns derzeit in eine Richtung drängen sind unsere Chefs, denn die möchten das wir alles in .net und C# machen, weil sie meinen das sei die neue Wunderwaffe. Die kommen aber allesamt nicht vom Fach weder hard- noch softwareseitig, sondern sind Betriebswirte. Zeno
Ralf D. schrieb: > In der Industrie wird gerne die Reheinfolge umgestellt und ide > Sprachauswahl aus Schritt 0 vorgegeben. Und dann wundert man sich bei > manchen Projekten, warum die Umsetzung so lange dauert und so > fehlerträchtig ist. BTST. Da hast Du den Kern getroffen. Bei uns ist es genau so (s. meinen vorherigen Post). Zeno
>Naja so toll ist C# nun auch wieder nicht obwohl es schon einige nette >Features hat, z.B. nullable Variable. Leider hat man es mal wieder nicht >konsequent gemacht, indem alle Typen generell nullable sind (man muß ja >die nullable Eigenschaft nicht nutzen) Es war falsch manche Typen implicit als Nullable zu haben - es sollte IMMER explicit angefordert werden siehe auch: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://twistedoakstudios.com/blog/Post330_non-nullable-types-vs-c-fixing-the-billion-dollar-mistake sogar der der Chef-Entwickler von .Net/C# sagt das wäre der größte von allen Fehler gewesen
bert3 schrieb: > Es war falsch manche Typen implicit als Nullable zu haben - es sollte > IMMER explicit angefordert werden Kann man so und so sehen. Wenn ih heraus finden möchte ob überhaupt Werte/Daten zugewiesen wurden ist das schon ganz praktisch. Derzeit löst man so etwas indem man die Variable auf einen Wert setzt der normalerweise nicht vorkommt, aber das ist eigentlich eine Krücke. Man könnte es auch über ein Struct (C) oder einen Record (Pascal) lösen, was aber meist keiner macht. Zeno
@Zeno Das geht trotzdem nur eben ungleichmaessig String, Struktur und class Instanzen sind IMMER implizit nullable PODs sind nur explizit nullable int x; // non-nullable int? x; // nullable - wie std::optional in C++17 Keine immer valide Referenz wie in C++ und das führt zu schlechterem Code siehe Billion Dollar bug
Bert3 schrieb: > Keine immer valide Referenz wie in C++ und das führt zu schlechterem > Code > siehe Billion Dollar bug Da könnten sich einige Sprachen Eiffel mal als Vorbild nehmen Void Safety bzw. die Sprachmittel attached/detachable/stable https://www.eiffel.org/doc/eiffel/Void-safety%3A%20Background,%20definition,%20and%20tools Jörg W. schrieb: > Aber lassen wir das, ich weiß, dass du mit den GCC-Entwicklern > bezüglich der Aliasing-Regeln nicht konform gehst. Denk aber dran, > dass im C-Standard solche Dinge nicht deshalb "implementation > defined" sind, weil es irgendwer besonders toll fand, sondern weil > es zum Zeitpunkt der Entscheidung bereits verschiedene Varianten > gab, irgendwas zu implementieren, und man keine davon für ungültig > erklären wollte. Schon klar. An solchen Stellen wäre mir ein Machtwort, von welcher Seite auch immer, lieber gewesen als ein "Kompromiss", der, wie in diesem Fall, nicht für alle gilt. Btw.: Das ist auch eines der Probleme von Microsoft (gewesen). Kompatibilität mit allen noch so kaputten Anwendungen zu wahren, anstatt klar zu sagen: Ihr nutzt hier undefiniertes Verhalten. > Allerdings habe ich weiter oben eine C-Referenz von Dennis Ritchie > von 1974 zitiert, in der dieser Aspekt bereits genauso klipp und > klar festgeschrieben war. 1974 war ich noch ein klein wenig zu jung für C ;) Ich hatte (keine Ahnung wo die hin ist) nur die C-Bibel (die Second Edition), kann allerdings nicht sagen ob das da auch drin steht (vermutlich schon, wenn es in der 1974er Referenz steht) mh schrieb: > Arc N. schrieb: >> Zudem gilt das ganze für C++ nicht mehr sobald dort ein Typ mit >> entsprechend überladenen Operatoren auftaucht, dann wird alles >> ausgewertet... > > Das ist tatsächlich eine gemeine Falle. Und es ist meiner Meinung nach > ein guter Grund, warum man das Überladen von operator&& und || nicht > hätte erlauben dürfen. Man hätte genauso gut einfach definieren können: Überladene Operatoren verhalten sich wie nicht überladene. Schöne Erklärungen zu C++ und wie es in C# anders gemacht wurde: http://stackoverflow.com/questions/25913237/is-there-actually-a-reason-why-overloaded-and-dont-short-circuit > Es zwingt einen aber auch niemand dazu sie zu > überladen. Fällt dir ein Beispiel ein wann man einen der beiden > Operatoren überladen möchte? Dazu schreibe ich zu wenig "abgefahrenes" C++. Stichwort wäre, wenn ich mich recht erinnere, Expression Template.
Arc N. schrieb: > Schon klar. An solchen Stellen wäre mir ein Machtwort, von welcher Seite > auch immer, lieber gewesen als ein "Kompromiss", der, wie in diesem > Fall, nicht für alle gilt. Der Kompromiss gilt schon für alle. Der Benchmark ist eben nur kein portables C (wie ich dich verstehe), er ist also nicht strictly conforming. Solche Kompromisse braucht es halt in einem Normengremium, denn keiner will sich von so einem Gremium seine bisherige (in aller Regel mit Bedacht gewählte) Implementierung plötzlich für ungültig erklären lassen. Wurde ja schon mal genannt, das Einzige, was in C im Laufe der Jahre in der Tat entfernt worden ist, ist gets(). Diese Funktion hätte es (in der Form) nie geben sollen. > 1974 war ich noch ein klein wenig zu jung für C ;) Ich habe da auch gerade erst den Umgang mit dem Rechenschieber gelernt (oder noch nicht einmal ganz). ;-) > Ich hatte (keine Ahnung wo die hin ist) nur die C-Bibel (die Second > Edition), kann allerdings nicht sagen ob das da auch drin steht > (vermutlich schon, wenn es in der 1974er Referenz steht) Ja, im ANSI-Standard war es auf jeden Fall schon drin. Da ich damals von Pascal (was ich vorher viel hobbymäßig genutzt habe) auf C umgestiegen bin, war mir das als eins der angenehmen Dinge aufgefallen, auf das man offensichtlich bei der Definition der Sprache geachtet hatte. Im Gegensatz zu den vielen Turbo-Pascal-Fans hier hatte nämlich das GRW-Pascal, was ich zuvor benutzt hatte, keine solche Option, man musste daher immer die geschachtelten "if" schreiben. Das zweite, was mir angenehm auffiel damals war, dass man Vergleiche einfach verknüpfen kann, weil die Priorität sinnvoll sortiert ist:
1 | if (a < b && a > c) { // … |
2 | }
|
Kann mich dran erinnern, dass man das in Pascal aus unverständlichen Gründen immer klammern musste. Scheint übrigens so zu sein, dass man dies beim Übergang von B auf C erkannt hat, und damals die Operatoren && und || zusätzlich zu den bereits existierenden & und | eingeführt hat, um eben diese beiden Dinge auf die Reihe zu bekommen.
>Wieso gibt es keine gute Programmiersprache?
Kommt aus einem Frust heraus. Was wird denn vermisst ?
-Lesbarkeit ?
-Konzepte ?
-Interne Eigenschaften ?
-spezielle Libraries ?
-bessere IDE zum Entwickeln ?
Meine Anforderungen an die Sprache:
- einfache Lesbarkeit auch nach 10 Jahren noch.
- Portierbarkeit ist nicht benoetigt.
Anforderungen an die IDE :
- Debuggen muss ein zentrales Konzept sein.
Oh D. schrieb: > Meine Anforderungen an die Sprache: > - einfache Lesbarkeit auch nach 10 Jahren noch. > - Portierbarkeit ist nicht benoetigt. Dann nimm Purebasic für den Rechner und Bascom für AVR-Kontroller. MfG Paul
Danke, ich weiss was ich habe und bin zufrieden,. Es war weniger eine spezifische Frage, als eher die Diskussion von der andeeen Seite zu beginnen. Weswegen koennte man unzufrieden sein.
Oh D. schrieb: > Meine Anforderungen an die Sprache: > - einfache Lesbarkeit auch nach 10 Jahren noch. C, die Sprache wird auch in 10 Jahren noch so sein. Schlicht und schnörkelos. > - Portierbarkeit ist nicht benoetigt. Bietet C trotzdem. > Anforderungen an die IDE : > - Debuggen muss ein zentrales Konzept sein. C mit GDB, am besten in der Kommandozeile (habe ich tatsächlich schon erfolgreich genutzt, ist gar nicht so schwer). Oder x-beliebige graphische Aufsätze dafür.
mh schrieb: > Arc N. schrieb: >> Zudem gilt das ganze für C++ nicht mehr sobald dort ein Typ mit >> entsprechend überladenen Operatoren auftaucht, dann wird alles >> ausgewertet... > > Das ist tatsächlich eine gemeine Falle. Aber nur, wenn man davon ausgeht, dass das überladene && ähnliche Semantik hat wie das native, nämlich dass es ein "Logisch And" darstellt. Diese Implikation ist aber von WG21 offenbar nicht gewollt, was auch durchaus plausibel ist: warum sollte das überladene && ein "Logisch And" sein müssen? > Und es ist meiner Meinung nach ein guter Grund, warum man das Überladen > von operator&& und || nicht hätte erlauben dürfen. Das wäre aber ein seltsames Verbot... Wenn z.B. % überladen wird, muss das ja nicht ein "modulo" sein, sondern kann z.B. auch ein Kreuzprodukt von Vektoren sein (weil * bereits durch Skalaprodukt belegt ist). > Es zwingt einen aber auch niemand dazu sie zu überladen. Fällt dir ein > Beispiel ein wann man einen der beiden Operatoren überladen möchte? Kommt darauf an, was man && machen lassen will :-) Wenn es tatsächlich sowas wie "Logisch Und" sein soll, dann zieht man sich besser auf das && für bool zurück falls möglich und überlädt z.B. den Cast-Operator für bool, der dann true liefert falls das Objekt "nicht-leer" ist (z.B. bei Arithmetik auf Mengen oder Intervallen), oder falls es nicht der Null-Vector etc ist.
Johann L. schrieb: > Aber nur, wenn man davon ausgeht, dass das überladene && ähnliche > Semantik hat wie das native, nämlich dass es ein "Logisch And" > darstellt. Diese Implikation ist aber von WG21 offenbar nicht gewollt, Vermutlich auf Rücksicht auf einen zukünftigen obfuscated C++ contest... Oliver
S. R. schrieb: > Die Frage ist nicht, ob es für deine drei bevorzugten Implementierungen > gilt, sondern ob es für alle gilt und ob du denen das ansehen kannst, > ohne vorher deren Dokumentation vollständig zu lesen. Wenn an einem > C-Compiler "ANSI-C" dransteht, dann kann der mindestens C89, und zwar - > Ausnahmen ausgenommen - vollständig. Nana, immer vollständig? Das stimmt so natürlich nicht. Die echte Hauptsache an ANSI war ja doch das Richtigstellen der zuvor extrem verquaasten K&R-Syntax bei Funktionsköpfen. Aber da du von "vollständig" redest, fällt mir gerade der AVR-GCC ein, du weißt schon, der ohne double. Ich sag's mal so: Es macht für einige Architekturen keinen wirklichen Sinn, unter größten Mühen irgend einen Standard hinkriegen zu wollen. Stattdessen ist es m.E. durchaus sinnvoll, für sowas eben eine vom Üblichen abweichende Implementierung zu haben. Sonst gehen nämlich Features der Hardware flöten und die Verwendung der betreffenden Programmiersprache wäre kontraproduktiv. Siehst du, wir landen vom Klagen über den Mangel an guten Programmersprachen über die Kontroverse C <-->Pascal schlußendlich bei Vorstellungen über die Zukunft: Ist es denkbar und auch wünschenswert, in Zukunft eine Weiterentwicklung der derzeitigen µC-Szene zu haben, mit neuen Features, die in derzeitigen programmiersprachen noch gar nicht berücksichtigt sein können? Wo es also entweder ein Umkrempeln bisheriger Programmiersprachen oder ein Brachliegen selbiger Features geben MUSS? Jörg W. schrieb: > Wozu rechtfertigen? > Schau dir doch einfach die realen Verhältnisse an. Das ist Leben von der Hand in den Mund. jaja, es machen die meisten von uns (mich eingeschlossen) dies eben genau so: Man benutzt, was grad da ist, denn man will ja in endlicher Zeit fertig werden. Und so generiert sich der Teufelskreis immer wieder von Neuem: Was da ist wird benutzt, die Hersteller produzieren vor allem das, was am meisten geht, anderes verschwindet aus dem Angebot, also benutzt man das, was da ist,.... Kreis geschlossen. Es ist eben für den Augenblick das Ökonomischste, auf den Mainstream aufzuspringen - aber es ist auf lange Sicht durchaus nicht klug. Das ist der Punkt. Du sprichst von Rechtfertigungen, die überflüssig sind, weil es ja angeblich nicht relevant ist. Also "C ist besser, weil mehr davon da ist"? Ist Masse besser als Klasse? Nein, das ist Tonnenideologie. Ich könnte jetzt stänkern, indem ich deine Worte mal auf die Verbreitung von Linux (oder FreeBSD) auf dem PC in exakt gleicher Weise gebrauche. Kurzum, wir werden in Zukunft was anderes benötigen als C, wir sollten auch auf Vielfalt achten und etwas gegen den Weg in die Monokultur tun. Und da wäre zumindest mehr Verwendung von FreePascal auf dem PC und nicht das dümmliche Ablehnen angeraten. Denn: Was man nicht praktiziert, das verkümmert und wo keine Nachfrage, dort kein Produzent. Aber wir brauchen die Vielfalt - und zwar überall. Ist ne Grundfeste unserer Gesellschaft. W.S.
Ich weise dich mal dezent darauf hin, den von dir zitierten Text nochmals zu lesen. Danke.
Jörg W. schrieb: >> Mhh. Ich bin mir da nicht sicher, ob die das nicht schon eingesehen >> hatten als in Ansi-C die Auswertungsreihenfolge solcher Ausdrücke noch >> "depents on the implementation" war. Und DAS war damals unter UNIX auch >> immer ein beliebter Fehler, das bekannte (*p && p->x++) ;-) > > Wo hast du das denn her? Ich hatte so einen Fehler mal auf einer SUN-3 (?). Da ging es genau so in die Hose, wenn NULL==p war. Seitdem halte ich mich da (bis heute) immer zurück. > > Selbst lange vor ANSI-C war das schon eindeutig festgelegt. > > Hier beispielsweise in der Doku von 1974: > > https://www.bell-labs.com/usr/dmr/www/cman74.pdf Oh, das kannte ich noch gar nicht. Von D. Richie noch selbst verfasst. Cool :-D /regards
Nase schrieb: > Wo liegt denn Pascal im Moment z.B. im TIOBE-Index? 1,5%? 1,9%? > Tschuldigung, aber so realistisch muss man auch mal sein. Und wie aussagekräftig ist der TIOBE index? /regards
>> Und es ist meiner Meinung nach ein guter Grund, warum man das Überladen >> von operator&& und || nicht hätte erlauben dürfen. Jaja, was überladen ist bricht auch irgendwann zusammen...
W.S. schrieb: > Ist es denkbar und auch wünschenswert, in Zukunft eine Weiterentwicklung > der derzeitigen µC-Szene zu haben, mit neuen Features, die in > derzeitigen programmiersprachen noch gar nicht berücksichtigt sein > können? Erstens deutet nichts darauf hin, und zweitens abstrahiert C ohnehin die Hardware zu einer logischen Maschine hin. Außerdem werden heute CPUs compilergerecht entfworfen. > Wo es also entweder ein Umkrempeln bisheriger > Programmiersprachen oder ein Brachliegen selbiger Features geben MUSS? Fehlschluß - neue Anwendungen lassen sich in Software machen, denn das ist genau der Witz an programmierbaren Computern. Für komplexere Sachen gibt's Frameworks. For komplexe Sachen in Hardware gibt's Libraries, Intrinsics und Inline-Assembler. > Kurzum, wir werden in Zukunft was anderes benötigen als C Das mag sein, aber eine weitere prozedurale Sprache bietet da bei weitem nicht genug Vorteile, weil es immer noch genau dasselbe Paradigma ist. Der Zug für Pascal ist in der Praxis einfach abgefahren, und ich finde es auch nicht weiter schade. > Aber wir brauchen die Vielfalt Beweis durch Wiederholung der Behauptung nennt sich Zirkelschluß. Nein, wir brauchen nicht dasselbe Rad in nochmal. Das ist eher hinderlich, weil die Sourcen dann nicht interoperabel sind und man in jeder Sprache alles nochmal implementieren muß, ohne daß dabei ein Nutzen herauskommt. Stichwort "Opportunitätskosten", will sagen haufenweise vollkommen sinnlos verballerte Arbeit und Kreativität, nur weil man einen Zoo haben will. Nein, Vielfalt um der Vielfalt willen ist NICHT per se gut, sondern es ist im Einzelfall deren Nutzen nachzuweisen. Du beschwerst Dich ja auch nicht, daß hier jede Steckdose 230V/50Hz hat und nicht bunte Vielfalt von 115V/400Hz bis zu 580V/15Hz aus der Steckdose kommt. Og du klager ikke heller om at jeg ikke tilføyer noe manfolg her ved bruk av andre språk, ikke sant? Ach ja, was Pascal das Genick gebrochen hat, war insbesondere die "Vielfalt" - nämlich die aus lauter brauchbaren, aber zu nichts kompatiblen Inselpascals in Verbindung mit einem gemeinsamen, aber unbrauchbaren (ud praktisch deswegen irrelevanten) Standard. Außerdem hat man nach jeder Vielfaltsexplosion in der Technikgeschichte auch eine Konsolidierungsphase, in der sich das Bewährte eben herauskristallisiert.
Nop schrieb: > Erstens deutet nichts darauf hin, und zweitens abstrahiert C ohnehin die > Hardware zu einer logischen Maschine hin. Außerdem werden heute CPUs > compilergerecht entfworfen. Es deutet nichts darauf hin? Nun, ich habe soviele Anwendungen in plain C für WinCE geschrieben, daß ich inzwischen davon die Nase voll habe. Es deutet durchaus sehr viel darauf hin, daß C bereits heute als Programmiersprache auf dem PC nicht mehr ausreichend ist. Also schreib nicht, daß nichts drauf hindeuten würde. Nur so als Beispiel. Ein zweites Beispiel sind die alljährlichen Versuche, mit all solchen Programmiersprachen wie der TO sie beklagt hat, von plain C wegzukommen. Mach also die Augen auf und sieh, was die Leute zuRecht bedrückt. Das Alberne daran ist, daß selbst diejenigen, die den Versuch wagen, nicht mehr von ihrer C-Denke loskommen können (ähem.. es ist weniger albern, sondern eher bedenklich). Und was soll das mit den heutigen CPU's? Ich schrieb von übermorgigen, weil mit zumindest klar ist, daß jetzige Erfahrungen lediglich den Wissensstand der Vergangenheit als Basis haben können. Anstatt zu tröten "Ich seh gemäß heutigem Stand keinerlei Künftiges", solltest du bedenken, daß vor vierzig Jahren auch noch keiner ans Intenet gedacht hat oder an Smartphones (wenn man mal von Spock&Konsorten absieht) oder Google oder die NSA oder Chips mit 17 nm Strukturbreiten. Und jetzt komm ich dazu, nochmal aufzuwärmen, daß es C bis heute nicht geschafft hat, zu verläßlichen saubeen Integer-Datentypen zu kommen - vom Aufräumen in anderen Dingen mal ganz abgesehen. Von Konferenz zu Konferenz kreißt der Berg immer heftiger - und er gebiert immer kleinere Mäuse. So sieht Zukunftsfähigkeit NICHT aus. W.S.
W.S. schrieb: > Und jetzt komm ich dazu, nochmal aufzuwärmen, daß es C bis heute nicht > geschafft hat, zu verläßlichen saubeen Integer-Datentypen zu kommen. Was hättest du denn gerne? - Es gibt garantierte Bitbreiten (intXX_t, uintXX_t). - Es gibt garantierte Mindestbitbreiten (int_leastXX_t, uint_leastXX_t). - Es gibt garantierte Mindestbitbreiten mit Performancevorteilen (int_fastXX_t, uint_fastXX_t). Die sind alle seit C99 fest im Standard verankert. C ist auf dem PC vollkommen ausreichend, aber - und da stimme ich dir vollkommen zu - bei weitem nicht angenehm. Es gibt deutlich bessere Alternativen. Es gibt für jeden Anwendungsbereich bessere Sprachen als C. Aber es gibt keine Sprache, die in allen Anwendungsbereichen mindestens gleich gut geeignet ist wie C. Eine Programmiersprache, die C vom Thron stoßen könnte, muss: - prozedural sein (sonst ist sie keine Alternative) - vollständig ohne dynamischen Speicher und ohne MMU klarkommen - aber von einer MMU und viel RAM profitieren können - hinreichend standardisiert sein und über alle Architekturen hinweg Compilersupport (inkl. Zertifizierung) anbieten - eine gute Codebasis haben Und da wird es plötzlich sehr dünn.
Andreas H. schrieb: > Jörg W. schrieb: >>> Mhh. Ich bin mir da nicht sicher, ob die das nicht schon eingesehen >>> hatten als in Ansi-C die Auswertungsreihenfolge solcher Ausdrücke noch >>> "depents on the implementation" war. Und DAS war damals unter UNIX auch >>> immer ein beliebter Fehler, das bekannte (*p && p->x++) ;-) >> >> Wo hast du das denn her? > > Ich hatte so einen Fehler mal auf einer SUN-3 (?). > Da ging es genau so in die Hose, wenn NULL==p war. Dürfte dann ein arger Compilerbug gewesen sein. > Seitdem halte ich mich da (bis heute) immer zurück. Grundlos. > Oh, das kannte ich noch gar nicht. Von D. Richie noch selbst verfasst. > Cool :-D Yep, ich finde das auch nett, dass die Bell Labs seine Webseite aufrecht erhalten, einschließlich eben der historischen Dinge, die er da gesammelt hat. Wenn man sich das ansieht, dann waren offenbar die Shortcuts sowie die sinnvolle Vorrangfolge zwischen Vergleich und logischer Verknüpfung (sodass man beim Verknüpfen von Vergleichen nicht klammern muss) eben genau eine der Änderungen von „B“ nach „C“, indem man eigens dafür die Operatoren && und || eingeführt hat.
W.S. schrieb: > Es deutet durchaus sehr viel > darauf hin, daß C bereits heute als Programmiersprache auf dem PC nicht > mehr ausreichend ist. Auf dem PC ja. U.a. weil man in C nicht nur Ressourcenmanagement manuell machen muß, sondern bei Multicores auch noch deren Verwaltung. Es existiert keine Sprachunterstützung für parallele Verarbeitung. Noch viel schlimmer wird es, wenn man nicht nur auf einem Rechner parallel rechnen will, sondern eine Anwendung für ganze Cluster haben will. Ist Pascal da eine Abhilfe? NEIN, denn das ist in derselben Lage. Es bietet dasselbe wie C, nur in ein bißchen anders. Wo man mit C nicht hinkommt, braucht man mit Pascal auch gar nicht erst anzufangen. Vielfalt ist da allenfalls nervig, aber nicht produktiv. "Hauptsache anders", um Fortschritt zu suggerieren, wo schlichtweg keiner drin ist, das fällt zumindest bei mir knallhart durch. Wegen "brauch ich nicht, da kein Mehrwert". > Und was soll das mit den heutigen CPU's? Ich schrieb von > übermorgigen, weil mit zumindest klar ist, daß jetzige Erfahrungen > lediglich den Wissensstand der Vergangenheit als Basis haben können. Auch die werden einen C-Compiler haben. Sie werden schlichtweg keine totalen Kracherfeatures haben, die man mit C inkl. Libs nicht nutzen kann, aber mit Pascal schon, das ist Blödsinn. Es ist schlichtweg wurscht, ob man diese CPUs jetzt mobil einsetzt, oder in welchem Prozeß sie gefertigt werden. > Und jetzt komm ich dazu, nochmal aufzuwärmen, daß es C bis heute nicht > geschafft hat, zu verläßlichen saubeen Integer-Datentypen zu kommen Das erzählst Du seit geraumer Zeit, und es ist immer noch Unsinn. Seit C99 gibt's das plattformübergreifend standardisiert, und das nutze ich auch sehr gerne. C99ist jetzt schon 18 Jahre her, was als Programmierer wirklich genug Zeit war, sich damit zu befassen, um nicht solchen Unsinn zu erzählen. > Von Konferenz zu Konferenz kreißt der Berg immer heftiger Tut er bei C schlichtweg nicht. Muß er auch nicht, sonst kommt nämlich sowas wie C++ am Ende heraus. :-P
Habe schon oft gelesen C sei gut für hardwarenahes Programmieren, gerade auch für Mikrocontroller. Aber die paar wenigen Mikrocontroller, die ich bisher in die Finger bekommen hatte, waren allesamt Havard Architekturen. Und für mehrere Addressräume auf verschiedenen Bussystemen hat C nun mal nichts in der Trickkiste. Da wird dann der Linker vergewaltigt die Havard Architektur zu einer verkrüppelten Pseudo-Van-Neumann-Maschine zu prügeln. Schon bei eigentlich trivialen Datenjonglierereien um ein paar structs zwischen Ram, Progmem und EEmem zu verlinken verdreht's mir da ratzfatz die Hirnwindungen. C ist für sowas einfach nicht gemacht. Aber gibt es überhaupt Programmiersprachen, die für Havard Architekturen geeignet sind? Außer in Assembler habe ich das in keiner der Sprachen, die ich bisher kennengelernt habe, gesehen. (C, C++, C#, Java, Ecmascript, Lua, Pascal, Basic, PHP, ...)
Thomas M. schrieb: > Habe schon oft gelesen C sei gut für hardwarenahes Programmieren, > gerade auch für Mikrocontroller. Es ist zumindest überall vorhanden und, das behaupte ich mal unbegründet, mindestens so gut wie die Alternativen. > Aber die paar wenigen Mikrocontroller, die ich bisher > in die Finger bekommen hatte, waren allesamt Havard Architekturen. Intern dürften die meisten modernen Prozessoren Harvard-Architekturen sein, das ist nicht nur auf Controller beschränkt. Aus Sicht des Programmierers geht man aber davon weg (siehe z.B. ARMs Cortex-M). > Und für mehrere Addressräume auf verschiedenen > Bussystemen hat C nun mal nichts in der Trickkiste. Wenn man genügend Bits bezahlen kann und will, geht man zu flachen Adressräumen über. Niemand nutzt mehr Segmentierung, MMIO hat sich auch durchgesetzt und bis auf die kleinen 8- und 16-Bit-Architekturen hat sich das Problem erledigt. Damit sinkt auch der Bedarf nach passenden Sprachen. Mir ist grundsätzlich keine Sprache bekannt, die mit getrennten Adressräumen wirklich gut umgehen könnte. An den Stellen springen dann die Compiler ein, z.B. hat SDCC brauchbaren Support für Banking, avr-gcc kennt __flash und __eeprom und die Kommerzcompiler wissen auch damit einigermaßen umzugehen. Das Hauptproblem ist, dass der Programmierer die Aufteilung des Problems in verschiedene Adressräume selbst vornehmen muss. Ob er das im Linker oder im Compiler macht, ist relativ egal, aber es ist umständlich.
S. R. schrieb: > Mir ist grundsätzlich keine Sprache bekannt, die mit getrennten > Adressräumen wirklich gut umgehen könnte. Mir auch nicht, und das wäre für eine Hochsprache auch nicht wirklich sinnvoll. Die Konsequenz wäre dann doch, daß man eine hardwareabhängige Hochsprache hätte, was ein Widerspruch in sich ist. Hochsprachen sollen sowas gerade abstrahieren. Das ist auch der Grund, wieso das auch in C etwas krampfig ist. Zuende gedacht hätte eine Sprache, die mit Hardwareabhängigkeiten und den tollen neuen CPU-Features von W.S. zugestopft ist, vor allem zur Folge, daß sie nicht portabel wäre. Man könnte also nicht cross-platform entwickeln, testbeds wären nicht möglich, Migrationspfade wären von vornherein verschlossen, und bestehende Software könnte man auch komplett neu schreiben. Das wäre alles ein gewaltiger vendor-lock-in, an dem einzig der Hersteller dieser CPU interessiert wäre. Eben deswegen würden die Entwickler da auch einen großen Bogen drummachen, wenn sie schlau sind.
Jörg W. schrieb: >> Seitdem halte ich mich da (bis heute) immer zurück. > > Grundlos. Also "Zurückhaltung beim Programmieren" hat sich (bei mir) eigentlich immer bewährt. Du weisst doch: "Die längste Strecke zwischen zwei Punkten ist die Abkürzung" Und diverse, später notwendige, Bugfixes bestätigen das auch immer wieder. Ok, der "Kollege", der das mal "schnell gemacht" hat war sicher pünklich zu Hause^^ /regards
Andreas H. schrieb: >>> Mhh. Ich bin mir da nicht sicher, ob die das nicht schon eingesehen >>> hatten als in Ansi-C die Auswertungsreihenfolge solcher Ausdrücke noch >>> "depents on the implementation" war. Und DAS war damals unter UNIX auch >>> immer ein beliebter Fehler, das bekannte (*p && p->x++) ;-) >> >> Wo hast du das denn her? > > Ich hatte so einen Fehler mal auf einer SUN-3 (?). > Da ging es genau so in die Hose, wenn NULL==p war. Das sieht ja auch schon auf den ersten Blick falsch aus - ich hätte (p && p->x++) erwartet. Was soll *p denn überhaupt als Check aussagen?
Andreas H. schrieb: > (*p && p->x++) kann mir jemand sagen, wo so eine Zeile denn sinnvoll sein könnte? Ich wüsste nichtmal, was die überhaupt tut. p->x++ wenn irgendein Bit innerhalb der Struktur nicht 0 ist?
Achim S. schrieb: > Andreas H. schrieb: >> (*p && p->x++) > > kann mir jemand sagen, wo so eine Zeile denn sinnvoll sein könnte? Ich > wüsste nichtmal, was die überhaupt tut. p->x++ wenn irgendein Bit > innerhalb der Struktur nicht 0 ist? Die Zeile ist kein gültiges C, kann aber gültiges C++ sein. p ist ein Pointer auf ein Struct (sieht man an p->x). Ein Struct kann in C nicht nach bool konvertiert werden, in c++ gibt's dazu nen operator. So oder so würde p bei *p bereits dereferenziert, womit wenn dieses 0 ist etwas undefiniertes Passiert. Wenn statdessen (p && p->x++) gestanden wäre, würde es bedeuten: * wenn p null ist => ergibt false * wenn p nicht 0 ist, erhöhe p->x um eins, und gebe true zurück wenn p->x davor nicht 0 war, ansonsten false
Nase schrieb: > Solche Leute haben wir auch. > Die halten verbissen an ihrem zenn Jahre alten Kram fest, weil das ja > schon immer so war, verweigern jegliches Fortkommen und blockieren > wichtige Entscheidungen. Lass mich raten, Du bist: jung, hekisch, dynamisch, erfolglos und Deiner Meinung nach unterbezahlt.....
Daniel A. schrieb: > Die Zeile ist kein gültiges C, kann aber gültiges C++ sein. Das gab es damals noch nicht.
edgar S. schrieb: > Nase schrieb: >> Solche Leute haben wir auch. >> Die halten verbissen an ihrem zenn Jahre alten Kram fest, weil das ja >> schon immer so war, verweigern jegliches Fortkommen und blockieren >> wichtige Entscheidungen. > > Lass mich raten, Du bist: > > jung, hekisch, dynamisch, erfolglos und Deiner Meinung nach > unterbezahlt..... <irony> Wie kommst Du denn darauf? Haust Du nie in einem laufenden System mal die Software weg, spielst Deine neue Version, in der Language-of-the-Year ein, stellst fest, das die alte HW das nicht packt, bestellst neue HW, baust sie ein, fixed noch ein "paar kleine Issues" und erklärst dann wissend dem (ex-)Kunden, dass die 5 Tage Ausfall der Produktionsstrasse unvermeidlich waren, wenn man auf dem Stand der Technik bleiben will und die dabei entstandenen Kosten verschmerzbar sind? Naja, manche Kunden sind schon seltsam rückständig. Denen reicht es, wenn es einfach nur funktioniert. Echt antiquiert... </irony> /regards
Thomas M. schrieb: > Und für mehrere Addressräume auf verschiedenen Bussystemen hat C nun mal > nichts in der Trickkiste. Witzigerweise ist C auf Harvard-Maschinen groß geworden (PDP-11 mit split I&D).
Jörg W. schrieb: > Witzigerweise ist C auf Harvard-Maschinen groß geworden (PDP-11 > mit split I&D). Die Adressraumtrennung zwischen Programm und Daten war nie ein Problem. Sondern die zwischen veränderbaren Daten und konstanten Daten. Und dieses Problem hatte man bei der PDP-11 nicht.
A. K. schrieb: > Und dieses Problem hatte man bei der PDP-11 nicht. Auch nur, weil man zwischen beiden nicht unterschieden hat, waren halt alles Daten. So macht's ja am Ende auch der AVR-GCC.
A. K. schrieb: > Jörg W. schrieb: >> Witzigerweise ist C auf Harvard-Maschinen groß geworden (PDP-11 >> mit split I&D). > > Die Adressraumtrennung zwischen Programm und Daten war nie ein Problem. > Sondern die zwischen veränderbaren Daten und konstanten Daten. Genau. Mein Problem ist da vornehmlich, dass ich nicht mit Bordmitteln von C dynamisch z.B. eemem alloziieren kann. Einen Heap gibts ja nur im Ram.
chris_ schrieb: > Was hier noch gar nicht vor kam: graphische Programmiersprachen. > Ich bin der Meinung, eine richtig gute Programmiersprache muss > graphische Anteile beinhalten. Bloß nicht. Sprache soll Text sein und nichts weiter. Nichts gegen Visualisierungen von Quelltexten, das kann manchmal praktisch sein. Das Arbeiten mit Spezialeditoren, die man für Bildersprachen braucht und von denen man dann abhängig ist, ist ganz nett bei kleinen und einfachen Sachen. Aber bei größeren und komplexeren Projekten ist es ein Graus. Hier klicken und da was eintragen, dann dort ein Menü aufrufen und etwas auswählen. Eine mühselige Klickerei und gegenüber dem Arbeiten mit einem guten Texteditor sehr ineffizient. Ich kenn es aus der SPS-Programmierung. Ein Kunde wollte gern die Bausteine in FUP haben, während ich gewohnt bin, mit AWL-Qelltexten zu arbeiten. Nach einigen unerquicklichen Versuchen, habe ich herausgefunden, wie die AWL-Texte gestaltet sein müssen, um in FUP darstellbar zu sein. Nun generier ich sie doch in AWL und speicher sie dann als FUP ab.
Thomas M. schrieb: > Genau. Mein Problem ist da vornehmlich, dass ich nicht mit Bordmitteln > von C dynamisch z.B. eemem alloziieren kann. Einen Heap gibts ja nur im > Ram. Du willst einen Heap im EEPROM? Dann schau dir mal ATtiny816 und Konsorten an, da scheint das zu gehen. Nach über 15 Jahren ist Atmochip endlich auf den Trichter gekommen, dass Harvard und linearer Adressraum kein Widerspruch sind :-)
Thomas M. schrieb: > Mein Problem ist da vornehmlich, dass ich nicht mit Bordmitteln > von C dynamisch z.B. eemem alloziieren kann. Einen Heap gibts ja nur im > Ram. Diese beiden Sätze kann man auch gut als kurze Ansprache bei einer Hochzeitsfeier bringen. :) schnell fort hier MfG Paul
Jörg W. schrieb: > Auch nur, weil man zwischen beiden nicht unterschieden hat, waren > halt alles Daten. So macht's ja am Ende auch der AVR-GCC. Bei der PDP-11 landeten alle adressierten Daten im Datensegment. Das war ebenso 64KB gross wie das Codesegment. Egal ob konstant oder variabel. Der AVR macht es von Haus aus auch so, indem der Startcode Flash-Daten ins RAM kopiert. Aber mangels ausreichender RAM-Kapazität stösst man dabei schnell an Grenzen. Und dann hat man es eben mit Daten im RAM und Daten im Flash zu tun, die sich mit Hardware-Pointern nicht adressieren lassen. Hätte Atmel den AVRs schon früh die Möglichkeit gegeben, Flash in den Datenadressraum einzublenden, beispielsweise in die zweite Adresshälfte, wäre der ganze Zirkus mit PROGMEM kaum jemals nötig. Allerdings wäre die Ablaufsteuerung etwas komplexer geworden.
A. K. schrieb: > Der AVR macht es von Haus aus auch so, indem der Startcode Flash-Daten > ins RAM kopiert. Yep, so wie man den Kram auf der PDP halt von der Platte geladen hat, sowohl .text als auch .data. Ich wollte ja auch nur drauf hinaus, dass es keineswegs an C selbst liegt, „nicht mit Harvard“ klar zu kommen. Das Problem des AVRs ist ja eher der insgesamt recht knappe Adressraum. Beim ARM hat (trotz Harvard) keiner ein Problem damit. > Aber mangels ausreichender RAM-Kapazität stösst man > dabei schnell an Grenzen. Das ist der eigentliche Pferdefuß. Ist gewissermaßen so, wie wenn man auf der PDP hätte die Befehle direkt von der Platte gelesen hätte und nun gleiches auch mit den konstanten Daten tun möchte. > Hätte Atmel den AVRs schon früh die Möglichkeit gegeben, Flash in den > Datenadressraum einzublenden, beispielsweise in die zweite Adresshälfte, > wäre der ganze Zirkus mit PROGMEM kaum jemals nötig. Allerdings wäre die > Ablaufsteuerung etwas komplexer geworden. Naja, dann hätten wir statt der blöden 64-Ki-Segmentierung eine 32-Ki-Segmentierung gehabt. Auch nicht ernsthaft besser, finde ich. Der MSP430 macht sowas ähnliches, das funktioniert bis zu so 40 oder 48 KiB Flash (hab' die genaue Grenze vergessen) ganz gut, danach fängt man dann mit Verrenkungen an, einzelne Funktionen per Attribut (oder Pragma oder was auch immer) einem bestimmten Bereich im Flash zuzuweisen.
Jörg W. schrieb: > Naja, dann hätten wir statt der blöden 64-Ki-Segmentierung eine > 32-Ki-Segmentierung gehabt. Für fast alle Fälle hätte das ausgereicht. Nur Programme mit sehr grossem Datenanteil im Flash wären betroffen gewesen. Und deren Daten wären sehr wahrscheinlich grosse Tabellen gewesen, auf die nur die nur relativ wenigen Stellen zugegriffen wird. > Der MSP430 macht sowas ähnliches, das funktioniert bis zu so > 40 oder 48 KiB Flash (hab' die genaue Grenze vergessen) ganz gut, > danach fängt man dann mit Verrenkungen an, einzelne Funktionen per > Attribut (oder Pragma oder was auch immer) einem bestimmten Bereich > im Flash zuzuweisen. Missverständnis? Ich beziehe mich nur auf Datenadressierung. Codeadressierung wäre genau wie jetzt rein auf Flash bezogen. Banking wäre nur aufgetreten, wenn mehr als 32KB Daten im Flash liegen. Zu MSP430: Bis (circa) 64KB Code+Daten ist diese Architektur sehr elegant und sauber. Jenseits davon kann man das nicht mehr behaupten. Da ist einfach Schluss, das war nie vorgesehen. Bei der PDP-11 war je nach Modell bei 64K oder 2x64KB ja auch Schluss. Jenseits dessen kamen Overlays und das war kein Vergnügen.
Was hat die "gute Programmiersprache" mit der Hardware-Architektur oder gar einem speziellen Prozessor von ATMEL oder TI zu tun. Mädels, ich glaube die Disskussion führt gerade in eine falsche Richtung. Es geht um eine "gute Programmiersprache" und "warum es diese nicht gibt." Bitte nicht abschweifen auf Nebenschauplätze!
1234567890 schrieb: > Bitte nicht abschweifen auf Nebenschauplätze! Der Zweig entstand aus der Frage, welche (Compiler-) Programmiersprache das Problem der Trennung in mehrere Adressräume, speziell in mehrere Datenadressräume, gut abbilden kann. Vorschläge erbeten. Tipp: Ohne Pointer und damit verwandte Konstruktionen wie Referenzparameter verschwindet das Problem.
S. R. schrieb: >> Aber die paar wenigen Mikrocontroller, die ich bisher >> in die Finger bekommen hatte, waren allesamt Havard Architekturen. > > Intern dürften die meisten modernen Prozessoren Harvard-Architekturen > sein, das ist nicht nur auf Controller beschränkt. Was auch immer das bedeuten mag. Hardvard-Architektur heißt getrennte Adressräume und Speicherbusse für Code und Daten. "Die meisten modernen Prozessoren" haben höchstens getrennte Caches für Code und Daten. > Mir ist grundsätzlich keine Sprache bekannt, die mit getrennten > Adressräumen wirklich gut umgehen könnte. Sofern man eine echte Harvard-Architektur hat, die Trennung also wirklich zwischen Code und Daten gemacht wird, kommt C ganz hervorragend damit klar. Nur wird diese Trennung meist nicht sauber durchgezogen.
Wenn du einen Blick auf den ARM Cortex-M3 wirfst, findest du eine echte Harvard-Architektur. Allerdings ist der Adressraum linear und deswegen sind sowohl Flash als auch RAM identisch adressierbar und /für den Programmierer/ sieht es aus wie eine von Neumann-Architektur. Es ist aber keine!
S. R. schrieb: > Wenn du einen Blick auf den ARM Cortex-M3 wirfst, findest du eine echte > Harvard-Architektur. Für Programmiersprachen und ihre Abbildung auf Maschinen sind nicht Datenbusse relevant, sondern Adressräume. Wie sich die Busse intern aufteilen ist dafür völlig uninteressant. Wenn man in diesem Kontext die Begriff Harvard oder von Neumann verwendet, sollte man sich folglich auf Adressräume beziehen, nicht auf Datenbusse. Diese Begriffe entstanden in einem Kontext, in dem getrennte Datenbusse auch für getrennte Adressräume standen. Ich halte es für einen klassischen Fehler, sie auf irgendwelche Datenbusse zu beziehen. Es nimmt ihnen fast jeden Wert.
A. K. schrieb: > Für Programmiersprachen und ihre Abbildung auf Maschinen sind nicht > Datenbusse relevant, sondern Adressräume. Tja, und so gesehen ist AVR eben nur eine vergurkte Harvard-Architektur - denn die Daten, welche das Problem sind und Progmem-Gefrickel erfordern, liegen ja im Flash, also im Code.
turbo autist schrieb: > ... Also Ich fahre mit der Kombination C und lua (bzw. dem extrem schnellen luajit) ziemlich gut. Deal with it.
Lukas S. schrieb: > lua Mit Lua hab ich auch mal ein bisschen rumgespielt, und zwar war das als ich mit FEMM was scripten musste, da muss man leider Lua verwenden. Was mir sofort aufgefallen ist war daß es erlaubt ist in Ausdrücken Variablen zu verwenden die gar nicht existieren und es kommt trotzdem nicht mal ne Warnung, es läuft einfach durch als wäre nichts, die Variable kommt ungefragt aus dem Nichts heraus in die Existenz und hat den Wert nil! Sowas hab ich zum letzten Mal in irgendwelchen halbgaren BASIC-Dialekten aus den 80ern gesehen, danach nie wieder. Und es ist bereits bei Version fünf Punkt irgendwas und dieser kapitale Schnitzer ist immer noch nicht behoben (vor 5 Minuten ausprobiert). Ich nominiere Lua für den diesjährigen Null-Pointer-Award.
Bernd K. schrieb: > Und es ist > bereits bei Version fünf Punkt irgendwas und dieser kapitale Schnitzer > ist immer noch nicht behoben (vor 5 Minuten ausprobiert). Weil das kein "Schnitzer" ist, sondern so gewollt ist.
Bernd K. schrieb: > Was mir sofort aufgefallen ist war daß es erlaubt ist in Ausdrücken > Variablen zu verwenden die gar nicht existieren Das ist bei vielen Sprachen so, die keine Deklaration von Variablen erzwingen, insbesondere bei Scriptsprachen. Das ist in der Tat lästig, weil man nichtmal ein rudimentäres Typensystem hat und vor allem bei Tippfehlern keine Fehlermeldung bekommt. Ich sehe sowas als grundsätzlichen Mangel einer Sprache.
So schlecht sind heutige Sprachen doch gar nicht — immerhin unterstützt C++ bereits Floppy Disks. Es stanzt zwar Löcher hinein wie in Lochkarten, aber das ist immerhin ein Anfang! http://www.xkcd.com/1755/
Nop schrieb: > Bernd K. schrieb: >> Was mir sofort aufgefallen ist war daß es erlaubt ist in Ausdrücken >> Variablen zu verwenden die gar nicht existieren > > Das ist bei vielen Sprachen so, die keine Deklaration von Variablen > erzwingen, insbesondere bei Scriptsprachen. Ich kenne jetzt nicht soviele davon, aber bei welchen ist das denn noch so?
>Ich kenne jetzt nicht soviele davon, aber bei welchen ist das denn noch
so?
Verschiedene Shell-Sprachen.
Rolf M. schrieb: > Ich kenne jetzt nicht soviele davon, aber bei welchen ist das denn noch > so? Ruby, aber dort ist nil vom Typ NilClass, also ebenfalls ein Objekt
Bernd K. schrieb: > Lukas S. schrieb: >> lua > > Mit Lua hab ich auch mal ein bisschen rumgespielt, und zwar war das als > ich mit FEMM was scripten musste, da muss man leider Lua verwenden. > > Was mir sofort aufgefallen ist war daß es erlaubt ist in Ausdrücken > Variablen zu verwenden die gar nicht existieren und es kommt trotzdem > nicht mal ne Warnung, es läuft einfach durch als wäre nichts, die > Variable kommt ungefragt aus dem Nichts heraus in die Existenz und hat > den Wert nil! Sowas hab ich zum letzten Mal in irgendwelchen halbgaren > BASIC-Dialekten aus den 80ern gesehen, danach nie wieder. Und es ist > bereits bei Version fünf Punkt irgendwas und dieser kapitale Schnitzer > ist immer noch nicht behoben (vor 5 Minuten ausprobiert). Ich nominiere > Lua für den diesjährigen Null-Pointer-Award. Das lässt sich ja auch nachrüsten: http://metalua.luaforge.net/src/lib/strict.lua.html bzw. http://lua-users.org/wiki/DetectingUndefinedVariables Mir gefällt vorallem die hohe Dynamik an der Sprache z.b. kein switch/case? kein Problem:
1 | switch = {
|
2 | ["help"] = function () print("Help:\n\n") end,
|
3 | ["exit"] = function () print("Tschüss...") os.exit() end
|
4 | } |
5 | switch[io.read("*line")]()
|
Außerdem ist lua sehr Portabel. Java (bzw. Oracle) behauptet zwar überall zu laufen, lua setzt es aber tatsächlich um: Vom Gameboy Advanced über den Nintendo DS, PalmOS, DOS, µCs/Baremetal (eLua) bis hin zu Alternativen Firmwares für Kameras.
Nop schrieb: > Ich sehe sowas als grundsätzlichen Mangel einer Sprache. Darum ist bei Perl-Code ein fehlendes "use strict;" quasi immer ein Zeichen von schlechter Qualität. Ob Lua etwas vergleichbares hat, weiß ich nicht.
S. R. schrieb: > Darum ist bei Perl-Code ein fehlendes "use strict;" quasi immer ein > Zeichen von schlechter Qualität. Wenn ein Programm nach tagelanger Fehlersuche immer noch nicht fehlerfrei läuft, kommt manch Einem der Ausdruck: use Strick in den Sinn. MfG Paul
Lukas S. schrieb: > Das lässt sich ja auch nachrüsten: Auf gut deutsch, wenn man nicht from cratch hackt, dann kann man sich darauf nicht verlassen, daß der Bestandscode so ist. > Mir gefällt vorallem die hohe Dynamik an der Sprache z.b. kein > switch/case? kein Problem: Mir gefällt das überhaupt nicht. Das war bei Lisp auch schon so, daß man sich praktisch damit eine Sprache selber definieren konnte. Das ist theoretisch ja schön, praktisch führt es aber dazu, daß jedes Projekt seine eigene Sprache hat. Eine bestehende Codebasis zu übernehmen ist mit solchen Sprachen ein ziemlicher Drecksjob. Das ist auch der Hauptgrund, wieso es zwar etliche Lisp-Hacker gibt, das aber tendentiell Einzelgänger sind und bleiben. Du kannst ohnehin kein großes Projekt mit sowas machen, weil die Fluktuation dafür sorgt, daß auch mal Leute gehen, und die Sprache dafür, daß keine neuen Leute reinkommen. Sowas ist write-only-code jenseits jeder Wartbarkeit, und solche Projekte überleben ihren Erschaffer nicht.
D. I. schrieb: > Rolf M. schrieb: >> Ich kenne jetzt nicht soviele davon, aber bei welchen ist das denn noch >> so? > > Ruby, aber dort ist nil vom Typ NilClass, also ebenfalls ein Objekt Hast du mal ein Beispiel, wie das aussieht? Ich kenne mich mit Ruby nicht aus, aber ein einfaches y = x erzeugt x nicht, sondern bringt einen Fehler, dass es nicht existiert, genau wie Python.
Rolf M. schrieb: > Hast du mal ein Beispiel, wie das aussieht? Ich kenne mich mit Ruby > nicht aus, aber ein einfaches y = x erzeugt x nicht, sondern bringt > einen Fehler, dass es nicht existiert, genau wie Python. Ja du hast recht, Variablen müssen immerhin definiert werden, habe es im Kopf mit nicht definierten Hash-Keys durcheinander gebracht, bei denen kriegt man nil.
T0: >Sprachen mit dynamischem Typensystem habe ich mal nicht aufgeführt weil >ich mich nicht sonderlich für Kinderspielzeug interessiere. Warum benimmst du dich dann wie ein Baby und heulst herum "äähhh es giiiibt ähhhh kein e ähhh g u t e n ääh Programmiersprachen ähhh" Ich empfehle dir BASIC das ist was für Mädchen.
Nop schrieb: > Tja, und so gesehen ist AVR eben nur eine vergurkte Harvard-Architektur > - denn die Daten, welche das Problem sind und Progmem-Gefrickel > erfordern, liegen ja im Flash, also im Code. Nur, wenn du zu geizig mit RAM bist ;), und auch nur, sofern es sich um konstante Daten handelt. Das „Gefrickel“ entsteht nur dann, wenn man für seine konstanten Daten nich noch extra RAM spendieren will. Normalerweise liegen die Daten ja im RAM und damit in einem separaten Adressraum.
Nop schrieb: > Das ist bei vielen Sprachen so, die keine Deklaration von Variablen > erzwingen, insbesondere bei Scriptsprachen. Das ist in der Tat lästig, > weil man nichtmal ein rudimentäres Typensystem hat und vor allem bei > Tippfehlern keine Fehlermeldung bekommt. > > Ich sehe sowas als grundsätzlichen Mangel einer Sprache. Autovivikation ist ein Feature der meisten modernen Skriptsprachen, und sie alle gehen recht unterschiedlich damit um. Lua und Perl erstellen ohne Warnung eine neue Variable, Lua initialisiert sie auf nil und Perl auf einen leeren String. In Perl kann man das durch "use strict;" verhindern, in Lua ist mir keine Lösung dafür bekannt. Ruby und Python steigen bei unbekannten Variablen -- also solchen, denen noch kein Wert zugewiesen wurde -- jeweils mit einem Fehler aus. Es ist auch nicht richtig, daß Python und Ruby kein Typsystem hätten; im Gegenteil haben beide Sprachen eine sehr starke Typbindung, wenngleich sie dynamisch ist, der Typ einer Variablen also zur Laufzeit geändert werden kann. Ein Typ ist nicht an eine Variable, sondern an ihren Wert gebunden; wenn dieser Wert einer anderen Variable zugewiesen wird, erhält sie den Typ des zugewiesenen Wertes, ungeachtet des Typs ihres vorherigen Wertes. Den Typ eines Wertes ändert Python aber nur auf ausdrückliche Anweisung. Python3 enthält zudem weiteren Support für Type Hints durch das Modul typing.
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.