|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Monday 12. June 2006, 14:10 MEW (#1)
|
|
|
|
|
BASIC hat mein Leben versaut. Also haltet euch
fern davon und fangt gar nicht erst an. Wenn
euch langweilig ist, geht doch einfach zum YMCA
oder raucht eine. Rauchen tötet ja bekanntlich auch die Zeit.
Ich kann sehr gut verstehen, wenn jemand damit alte
Programme am Leben erhalten will und sei es nur aus Sentimentalität. Bei den ganzen neuen Features frage ich mich aber ernsthaft: Wer will damit bitte
*neue* Software schreiben? Masochisten? Das solche Personen dann auch noch PPC-kompatible Programme mit Pointers und so hinbekommen, das glaub ich dann doch eher nicht. Das bekommt ja kaum der durchschnittliche C-Programmierer hin und da ist das nun wirklich nicht so schwer, wenn man die Sprache mal lernt und nicht nur falsch-learning-by-frickling exerziert.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>Rauchen tötet ja bekanntlich auch die Zeit.
ne, rauchen tötet mit der zeit, nicht die zeit ;)
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 12. June 2006, 16:18 MEW (#5)
|
|
|
|
|
"Rauchen tötet ja bekanntlich auch die Zeit."
Oh mein Gott, sie haben die Zeit getötet! Bastards!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 12. June 2006, 14:38 MEW (#2)
|
|
|
|
|
> So sind weit höhere Auflösungen möglich als mit SCREEN 12 und SCREEN 13 bei QBasic.
Whoa!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BASIC-Bashing ist in, aber ich möchte behaupten, dass es so schlimm nicht ist.
Disclaimer: Habe mit BASIC angefangen, dann kamen x86-Assembler, C, C++, dann ein bisschen Python und Ruby.
Wer Assembler kennt, weiss dass BASIC gar nicht soweit davon entfernt ist. Du kannst noch so schöne Strukturen in einer HLL schreiben, auf dem Prozessor wird das schlussendlich alles zu LET, IF und GOTO (bzw. MOV, CMP, JMP).
Wer seinen Horizont nicht auf BASIC begrenzt, wird - so behaupte ich - davon keinen Schaden erleiden.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 12. June 2006, 21:08 MEW (#7)
|
|
|
|
|
Du bist doch das beste Beispiel. In Deiner Liste taucht nicht eine einzige funktionale Programmiersprache auf. Allerdings ist x86-Assembler noch schlimmer als BASIC. Das merkt man besonders, wenn ehemalige Assembler-Spezialisten versuchen Code in einer Hochsprache zu optimieren. Man sollte wenigstens noch ein paar ganz andere Assemblersprachen gesehen haben. Die überlegen ständig was für Assembler-Code wohl dabei herauskommt und machen damit den Code unleserlich und oft sogar kaputt, wenn es die Sprache erlaubt (C und C++).
Das merkt man ja auch an Deiner Argumentation(?), dass da sowieso nur Maschinencode herauskommt. Das klingt für mich so logisch wie: Wer Assembler beherrscht kann auch Windows schreiben, ist ja bloß Maschinencode. Ehemalig Assembler-"Profis" ignorieren meist auch, dass die CPUs, die sie mal programmiert haben nicht mehr Stand der Technik sind. D.h. was vor ein paar Jahren noch ein ganz toller Trick war, bremst auf modernen CPUs bloß aus. Dafür gibt es eben Compiler. Ein aktueller Compiler weiß in der Regel wesentlich besser wie er für eine bestimmte CPU optimiert. Zur Not kann man dann immer noch nachhelfen, aber die meisten Performanzprobleme ergeben sich aus sub-optimalen Algorithmen und lassen sich mit Mikrooptimierungen bestenfalls kaschieren.
Was Assembler betrifft, das geht doch völlig an der Sache vorbei. Code muss verständlich, wartbar, wiederverwendbar und vor allem korrekt sein. BASIC
und Assembler bieten dem Programmierer in absoluter gar keiner Hinsicht Unterstützung. Etwas Assembler wissen kann nicht Schaden und hilft in C Pointer zu verstehen, aber insgesamt ist es relativ nutzlos. Du brauchst ganz sicher nicht Assembler benutzt haben um gute bzw. performante Software zu schreiben.
|
|
|
|
|
|
|
|
|
|
|
|
|
>Ein aktueller Compiler weiß in der Regel
> wesentlich besser wie er für eine bestimmte
> CPU optimiert.
Das wird immer wieder behauptet, aber ich glaube es nicht.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 12. June 2006, 22:01 MEW (#9)
|
|
|
|
|
Dann betrachte es einfach von der anderen Seite: Zeig mir Code bei dem der perfekte Assembler-Programmierer einen relevanten Performanzgewinn erziehlt. Dann lass ihn das auch noch mindestens für AMD64 und PPC machen. Wenn Du zum MPlayer-Core-Team gehörst oder eine 3D-Engine schreibst, dann glaub ich Dir sogar, dass Assembler wichtig ist. Für 90% (eher mehr) aller Anwendungen und Entwickler ist Assembler völlig uninteressant.
Vor allem kann ein Compiler abhängig davon wie Code verwendet wird, diesen u.U. komplett weglassen. Zeig mir das mit Assembler und zeig mir den Code noch mal einem Refactory, wenn sich einiges an der Struktur geändert hat.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 13. June 2006, 08:57 MEW (#12)
|
|
|
|
|
DAS Beispiel ist meiner Meinung nach
GMP.
Die wissen was sie tun und haben den Code für verschiedene CPUs optimiert. Klar ist, dass mit Assembler keine grösseren Programme geschrieben werden können, jedoch ist es bei gewissen Bereichen sicher angebracht.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 13. June 2006, 13:48 MEW (#14)
|
|
|
|
|
Ich halte nicht C für ungeeignet, sondern 08/15 Programmierer ungeeignet für C. C ist kein High-Level-Assembler. Wer das behauptet hat weder C noch Assembler verstanden.
Java ist einfach nur Schrott und im kommerziellen Bereich weit weniger verbreitet als es Dir die Uni
oder die Webseite Deiner Wahl weismachen will. Java ist die natürliche Konsequenz aus dem C++-Debakel.
Ich könnte mich mit sehr vielen Sprache anfreunden z.B. Eiffel aber auch Scheme. Leider kann man es sich nicht wirklich aussuchen, wenn man Software nicht komplett im Alleingang schreiben will. Letztlich sollte es immer auf den Einsatzzweck ankommen, aber das ist meist nur eine Floskel, an die sich die wenigsten halten.
Ich bin auch der Meinung, dass das Wissen um Assembler und innere Vorgänge überschätzt wird. Das
ist mit ein Grund warum 70% aller Informatiker ihr Studium abbrechen und besser an die FH gegangen oder gleich eine Lehre gemacht hätten. Solches Wissen ist nur zum Teil wichtig und kann von jedem Interessierten leicht erworben werden. Viel wichtiger sind mathematisches Verständnis (Leistungskurs Mathematik an der Schule ist ein Dreck dagegen) und abstraktes Denken.
Das schlägt sich auch dann in Programmiersprachen und Programmen nieder. Meist geht es hier in Babyschritten von A nach B. Konzepte und gute Algorithmen sind ein "Afterthought". Ohne die JDK wäre Java genauso "nutzlos" wie C und jeder würde sofort eine bessere Sprache nehmen.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 13. June 2006, 23:35 MEW (#17)
|
|
|
|
|
Was "Range Checking" etc. angeht, so bleibt die Entwicklung ja nicht stehen. Das hier gibt einen
guten Überblick über den Stand der Technik:
http://article.gmane.org/gmane.linux.ubuntu.hardened.general/149/
Damit dürfte C in naher Zukunft weit weniger gefährlich sein. Natürlich werden Programme dadurch nicht korrekt.
Das eigentlich Problem bei C sind nicht die NUL-terminierten Strings selbst, sondern eher die hirnverbrannten Funktionen der libc. Und damit meine ich nicht nur strcpy() sondern eher alle.
strlen() und strchr() sind so gerade noch erträglich. C hätte eben irgendwann eine Bibliothek ähnlich der JDK oder auch der Eiffel SDK bekommen müssen. Natürlich gehört das nicht in den C-Standard selbst. Bibliotheken gibt es auch genug.
Schwierig ist nur die guten zu finden. Bei Java und Eiffel stand hier immer eine einzelne Firma dahinter. Bei C war das nie der Fall, deshalb konnte wohl auch keine vernünftige und umfassende Bibliothek herauskommen.
Um Stack-Overflows zu verstehen braucht man aber keine tiefen Assembler-Kenntnisse und um beim Thema zu bleiben ganz sicher keine Basic-Kenntnisse. Außerdem kann "zu viel" Wissen auch zu falschen Annahmen führen z.B. das Rekursion immer Stack fressen muss. Wenn man sich z.B. bei Wikipedia über Scheme informiert, sieht man das "tail recursion"
sehr effizient sein kann und Rekursion bei funktionaler Programmierung oft das A&O ist. Mir ist auch klar, dass vieles was mathematisch elegant gelöst ist, ihn Hardware das Gegenteil davon ist.
Andererseits fehlen vielen Programmierern recht grundlegende mathematische Kenntnisse, die extreme Optimierungen darstellen können. Natürlich macht ein Mathematiker an sich keinen guten Programmierer - oft sogar einen schlechten, da sie i.d.R. Perfektionisten sind und "elegante" Lösungen wollen. Und ein Programmierer ohne mathematischen Background wird für viele Bereiche nicht geeignet.
Deshalb gibt es ja auch Chefprogrammierer oder Software-Architekten, die sich die passenden Algorithmen überlegen und vielleicht gerade noch schwierige implementieren. Der Programmierer implementiert dann den ganzen Rest nur nach Vorgaben. Man sollte sich gut überlegen, welche der beiden Aufgaben einem wirklich liegt bzw. ob man überhaupt beruflich "hacken" will.
"Just because it's valid C code doesn't mean it compiles."
Das häufigere Problem ist eher: "Just because it compiles or even runs doesn't mean it's valid C code." Hätte es keine Alphas gegeben, wäre
AMD64 ein Ladenhüter geworden.
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Antwort _dazu_ kommt allerdings
von Niklas Wirth... (Oberon halt,
oder seine diversen Vorgänger.)
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
|
|
|
|
Was "Range Checking" etc. angeht, so bleibt die Entwicklung ja nicht stehen. Das hier gibt einen guten Überblick über den Stand der Technik:
Sorry, aber das ist reine Symptombekämpfung.
Das eigentlich Problem bei C sind nicht die NUL-terminierten Strings selbst, sondern eher die hirnverbrannten Funktionen der libc. Und damit meine ich nicht nur strcpy() sondern eher alle.
strlen() und strchr() sind so gerade noch erträglich. C hätte eben irgendwann eine Bibliothek ähnlich der JDK oder auch der Eiffel SDK bekommen müssen. Natürlich gehört das nicht in den C-Standard selbst. Bibliotheken gibt es auch genug.
Erfahrungsgemäss ist das Konzept der 0-Terminierung per se schon problematisch, nicht nur wegen allfälliger Overflows. Die schlechten Bibliotheksfunktionen sind aber das Hauptproblem. Das überhaupt eine Bibliothek für Grundoperationen benötigt wird, ist allerdings an sich schon irritierend. Ausser man betrachtet C tatsächlich als High Level Assembler, dann macht das durchaus Sinn.
Deshalb gibt es ja auch Chefprogrammierer oder Software-Architekten, die sich die passenden Algorithmen überlegen und vielleicht gerade noch schwierige implementieren. Der Programmierer implementiert dann den ganzen Rest nur nach Vorgaben.
Nein, dieses Konzept ist praktisch ausgestorben. Technische Vorgaben beschränken sich heutzutage meist auf die Schnittstellen zur restlichen Software. Darum ist es wichtig, fachlich (was wollen die von mir?), mathematisch (wie berechne ich das?) und technisch (wie berechnet der Computer das?) auf der Höhe zu sein.
--
GPL ist der Versuch, den Ring gegen Sauron einzusetzen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 14. June 2006, 09:42 MEW (#21)
|
|
|
|
|
Klar bekämpft es nur Symptome. Aber wer schreibt noch Exploits, wenn diese nicht mehr funktionieren?
Crashen kann ich auch Programme, die in fast jeder anderen Sprache geschrieben sind, solange diese nicht fehlerfrei sind.
NUL-terminierte String sind als gemeinsames Interface z.B. für Funktionen wie open() völlig in Ordnung. Das heisst ja nicht das man sämtlichen Text oder sämtliche Strings so verwalten muss, soll oder will.
Also Scheme ist meiner Ansicht nach kein HLA und hat String-Funktionen nicht eingebaut. Ich sehe auch ehrlich gesagt nicht den Vorteil von Sprachfeatures gegenüber einer standardisierten Bibliothek. Der Effekt ist doch derselbe nur verwässere ich bei letzterem die Syntax nicht Dingen, die letztlich für viele nur Gimmicks sind.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rein technisch sind syntaktische Kommandos einfacher in effizienten Code umzusetzen, als Funktions- oder Methodenaufrufe. Auch sind sie in der Regel intuitiver und besser lesbar.
Selbstverständlich geht es auch anders. Smalltalk und Ruby, sowie abgeschwächt auch Python und zumindest ein Teil der LISP-Dialekte, setzen auf ein Minumum an syntaktischen Elementen. Jedoch ist die Syntax so ausgelegt, dass die Aufrufe "natürlich" aussehen. Ein Beispiel (in Smalltalk):
a < b ifTrue: a = b
Dies sind drei Signalisierungen (Methodenaufrufe) und kein einziges, syntaktisches Kommando. ALGOL-ähnlich würde es etwa so aussehen:
a.lt(b).ifTrue(lambda(a.set(b)));
--
GPL ist der Versuch, den Ring gegen Sauron einzusetzen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wer braucht funktionale Programmiersprachen?
Kannst Du Assembly? Sicher nicht, sonst wür-
dest Du nicht solch einen Kommentar abgeben.
Der Prozessor arbeitet nunmal imperativ, und
mich hat BASIC genausowenig wie PHP versaut.
Ich will nur nichts mit von anderen Leuten ge-
schreibseltem BASIC- oder PHP-Kot zu tun ha-
ben, jedoch ist eigenen, sauberen Code in die-
sen Sprachen zu schreiben möglich, wenngleich
nicht leichter als in anderen Sprachen. Nur
ist die Einstiegshürde geringer.
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 13. June 2006, 23:58 MEW (#18)
|
|
|
|
|
Na ja, wer braucht MirBSD? Brauchen tut es wohl niemand. Einsetzen tut es aber beispielweise Google. Nein, nicht MirBSD (meines Wissens) sondern
eine funktionale Programmiersprache:
http://labs.google.com/papers/mapreduce.html
Natürlich braucht man nicht jeden Kleinkram damit schreiben, aber effektiv schreibt doch fast jeder riesen Programme in seiner Lieblingssprache. Mozilla in C++ schreiben ist vielleicht naheliegend aber nicht sonderlich sinnvoll. Der MS IE ist AFAIK auch in C++ geschrieben. Es bloß eine Frage der Zeit bis in beiden gleich viele und meist auch gleichartige Bugs gefunden wurden. Von nicht-kritischen Bugs will ich gar nicht erst anfangen, bugzilla.mozilla.org kann schließlich jeder selbst lesen. Gut vieles liegt auch eher an
den zahlreichen verkorksten Web-Standards.
Ich verschiedene Assemblersprachen benutzt, hauptsächlich x86, aber auch 8085 (ja nicht 8086 oder 8088) und diverse Pseudo-Assemblersprachen für Lehrzwecke. x86-Asm liegt aber bald 10 Jahre zurück, damals noch in Kombination mit Turbo-Pascal. Mode 13h, Multi-Threading per Timer-IRQ etc. Nicht wirklich ernsthaft, schon gar nicht professionell, aber recht ausgiebig. Lesen kann ich es noch, nur leider verwendete damals jeder die Intel-Schreibweise unter DOS/Windows und allen Büchern, die ich so gelesen habe, während man heutzutage (unter Unix) für Assembler (z.B. nasm) die AT&T-Schreibweise nutzt. Das ist recht nervig, weil Ziel und Quelladdresse hier vertauscht sind.
Auch für Betriebssysteme braucht man nur sehr wenig Assembler, hauptsächlich im Bootloader, fürs Context-Switching und in den Low-Level-MMU-Funktionen. Wie man bei BSD gut sehen kann, kommt man dort mit sehr wenig Assembler aus.
Das Code von anderen lesbar sein muss, ist ja gerade des Pudelskern bei ernsthafter Software-Entwicklung. Jede Sprache erlaubt im Prinzip sauberen Code zu schreiben. Nur wenn, die oft mühsam entwickelten Techniken dafür nicht Konsens sind, dann kann man im Team damit nicht effizient arbeiten. Das ist bestenfalls sinnvoll bei kleineren One-Man-Projekten.
Das ist aber auch ein Grund warum Sprachen wie Java so "beliebt" sind. Damit kann eben jeder irgendwie programmieren und die Wirtschaft freut sich über die Programmiersklaven. Solange Endverbraucher kaputte Software und solche mit völlig überzogenen Hardwareanforderungen akzeptiert, wird sich das wohl auch in dem Bereich nicht ändern.
|
|
|
|
|
|
|
|
|
|
|
|
|
nasm verwendet die Intel-Syntax (aber kaputt,
pushf expandiert zu pushfd im 32-Bit Modus,
um den Opcode pushf zu kriegen muß man pushfw
schreiben), und gottlob kann man gas auch auf
Intel-Syntax umstellen, und seither ist's mein
Assembler der Wahl.
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 14. June 2006, 01:25 MEW (#19)
|
|
|
|
|
"Wer braucht funktionale Programmiersprachen?"
Stimmt, wer braucht ueberhaupt verschiedene Programmiersprachen, wenn man doch alles in Assembler programmieren kann?
Im Ernst: Funktionale Sprachen sind fuer manche Einsatzzwecke genial, zB zum schreiben von Interpretern, nicht umsonst wurde Pugs in Haskell geschrieben.
Ausserdem lassen sich einige Algorithmen funktional deutlich besser erklaeren als mit haesslichem Pseudo-Pascal-Pseudocode.
|
|
|
|
|
|
|
