Neulich in der Kneipe..."Compiler sind die besseren Programmierer"?!

    Zitat von Peter S. Taler

    Schöner Code ist wenn er:

    1) Funktioniert
    2) Auch nach 2 Monaten noch verstanden wird
    3) Im Rahmen der Aufgabenstellung schnell genug ist. Ob etwas 60 oder 100ms dauert macht keinen Sinn. Wenn es eine Schleife ist, die 500.000 durchlaufen wird, bekommt die Differenz Gewicht.
    4) Wer nicht nur zum Spass programiert muss auch wirtschaftlich denken. Programme müssen/sollen bezahlbar bleiben?

    du hast gut Dokumentation vergessen.

    zu 3. ein Beispiel aus meinem Berufsleben: verschenkte Zeit verleidet dem Anwender die Benutzung des Programms. Ein Programm (meines Vorgängers), von dem die Optimierung der Produktion unter Berücksichtung aller noch offen Aufträge bis zu einem gewissen Zeitpunkt erreicht werden sollte, lief unglaubliche 7 Stunden. Nach der 1. Optimierung 3 Stunden, am Schluß < 1 Stunde.

    Zitat von autoBert

    Ein Programm (meines Vorgängers), von dem die Optimierung der Produktion unter Berücksichtung aller noch offen Aufträge bis zu einem gewissen Zeitpunkt erreicht werden sollte, lief unglaubliche 7 Stunden. Nach der 1. Optimierung 3 Stunden, am Schluß < 1 Stunde.

    Ich habe mittlerweile in der Firma den umgekehrten Fall!
    Mein vor ca. 5 Jahren als absoluter Notbehelf schnell hingerotztes Script tat anfangs seine Arbeit tadellos und schnell. Mittlerweile sind quer durch Auftragsabwicklung/Fertigung und Versand viele weitere (selbstgeschriebene) Module hinzugekommen, die sich dem logischerweise täglich größer werdenden Datenmengen bedienen müssen. Dauerte Aktion X früher nur einige Sekunden, laufen Programme heute mehrere Minuten....mich stört das sehr, aber die Kollegen sind heilfroh, denn selbst die langsamen Konstruktionen sind immer noch besser als garkeine (nicht zu erwähnen ist, dass der "Notbehelf" mittlerweile Dreh- und Angelpunkt geworden ist, weil der Verursacher dieser Krücke IMMER NOCH NICHT (richtig) funktioniert, und dieses Programm kommt, das muss hier auch mal erwähnt werden, aus einer "professionellen" Softwareschmiede mit mehreren nur an diesem Programm arbeitenden Mitarbeitern!)

    Ende vom Lied müsste eigentlich sein, die Unmengen an Daten in eine Datenbank zu schreiben und die gesamte Kommunikation / Anzeige über ein Datenbankmodul abzuwickeln. Geschätzter Aufwand: ca. 1-2 Mannmonate. Da ich der einzige bin, der sich mit der Migration bzw. mit dem Umschreiben auf eine DB-Anwendung auskennt, und ich "Programmierarbeiten" nebenbei (neben meinen eigentlichen Aufgaben) bzw. in meiner Freizeit abwickle, sehe ich da schwarz....über kurz oder lang wird das System kollabieren, und ich muss mir die dummen Sprüche seitens Softwarefirma anhören, "Sehen Sie, wir haben gleich gesagt, dass Sie das auch nicht hinbekommen!" ||

    Jetzt wird es langsam OT, geht dafür aber in die AutoIt-Richtung.

    Viele Scripte von mir bestehen nur aus Schleifen, in denen ich auf andere Software warte. Ich brauche also in meinen Scripten keine Codeoptimierung, sondern eher eine Bremse :D

    Andy: ich wollte damit meinen Vorgänger nicht heruntersetzen. Ich weiß ja, daß er zum damaligen Zeitpunkt um Welten besser als ich war (und heute sicher auch noch ist). Es war war nur als Anmerkung gedacht, wie wichtig es sein kann ein Programm zu optimieren. Er hat es zu einem Zeitpunkt geschrieben, als es sein Chef an den Kunden verkauft hat. Ich konnte mir später (jetzt als Angestellter des ehemaligen Kunden) die Zeit nehmen, die Datenstruktur und den Index der DB darauf zu optimieren und alle anderen Programme die betroffen waren anzupassen.

    Zitat von autoBert

    Andy: ich wollte damit meinen Vorgänger nicht heruntersetzen.

    Das hatte ich auch nicht so aufgefasst^^

    Zitat von autoBert

    Es war war nur als Anmerkung gedacht, wie wichtig es sein kann ein Programm zu optimieren.

    Und das ist unabhängig, ob Scriptsprache oder Compiler. Wichtig ist doch erst einmal, dass registriert bzw. untersucht wird, wie lange ein Programm läuft und dann jemand sich die Mühe macht und schaut, ob und wie "optimiert" werden kann!


    Zitat von BananaJoe

    Viele Scripte von mir bestehen nur aus Schleifen, in denen ich auf andere Software warte. Ich brauche also in meinen Scripten keine Codeoptimierung, sondern eher eine Bremse

    Bei mir genau umgekehrt, ich optimiere, weil ich selbst nicht gerne auf die Fertigstellung des Scriptes warte! Ich habe Autoitscripte am laufen, welche mit drei anderen Programmen teilweise gleichzeitig interagieren. Die Laufzeit ist abhängig vom Auftragsvolumen, welches ein Mitarbeiter im Lauf des Tages bestimmt. Da werden Daten bereitgestellt, andere Programme per Control-()-Befehlen gesteuert, dort Daten abgespeichert uswusf. Wenn das Script gestartet wird, kann es sein, dass viele andere MA auf eines der Programme und dessen DB zugreifen und alles "träge" wird. Da keiner Lust hat, eine halbe Stunde auf immer denselben Ablauf zu schauen, arbeite ich jetzt teilweise mit API-aufrufen, um Zehntelsekunden einzusparen. ZEHNTELSEKUNDEN wird einer sagen, das ist doch lächerlich...
    Ich sehe das anders. 15 Mal 200 Vorgänge pro Tag sind 3000 mal 200 Tage/Jahr ergibt 600000 Vorgänge/Jahr mal 1/10tel Sekunde ergibt 60000 Sekunden = 16 Stunden = 2 Manntage pro Jahr....

    Mal sehen was DU sagen würdest, wenn ich als dein Chef dir erzähle, dass du 2 Tage deines Jahresurlaubs abgezogen bekommst, weil dir eine ZEHNTELSEKUNDE keine "Codeoptimierung" wert ist....

    Und das bei EINEM Script/Programm von vielen, welche bei uns sowieso schon "langsame" ehemals händisch gemachte Abläufe automatisieren! Bei gerade mal 15 MA, stell sich mal einer vor, was man in Unternehmen "optimieren" könnte, welche 150, 1500, oder gar 15000 MA haben!

    Ich bin der Meinung, dass ein guter Programmierer zumindest in 99,8% aller Fälle seine Zeit vergeudet, wenn er den optimierten Code eines aktuellen Compilers übertrumpfen will. Suboptimalen Code wird auch der beste Compiler selten bis nie derart optimieren können, wie es ein guter Programmierer sicher jederzeit könnte. 1986 hatte ich mit BASIC angefangen und bin dann nach ein paar Jahren auf ASM umgestiegen. ASM hatte mich in vielen Punkten sehr begeistert, vor allem was Klarheit und Geschwindigkeit angeht. Nun befasse ich mich nur noch mit C, C++, AutoIt, FreeBASIC, Bash und PowerShell - mit C und C++ aber nur wegen spezieller Projekte.

    Falls der "AMIGA" hier für jemand ein Begriff ist... eines meiner ersten Projekte in ASM war damals (zusammen mit einem verstorbenen Freund) das Programm "FastIPrefs", eine erweiterte Version von "IPrefs" (vergleichbar mit der heutigen Systemsteuerung unter Windows), welches in C geschrieben wurde. FastIPrefs hatte das Original in fast allen Bereichen um Faktor 3~50 geschlagen, was Speed angeht, wobei wir unser Hauptaugenmerk nur auf erweiterte Funktionalität und maximale Stabilität gesetzt hatten. Heute würde ich ein so großes Projekt in ASM nur noch aus nostalgischen Gründen angehen und bei fremden Programmen nur in ganz speziellen Fällen selbst Hand anlegen, um es zu optimieren, wobei die näheren Umstände natürlich eine entscheidende Rolle spielen.


    In einem (größeren) Unternehmen würde ich als Chef allerdings zumindest einen (guten) Programmierer damit beauftragen, immer ein Auge darauf zu haben, ob es sich bei eigenen Programmen lohnt, diese in ASM zu optimieren.

    Hehe... neben mir gibt es hier tatsächlich noch einen AMIGA-Fan... wirklich erstaunlich... ich habe sogar heute noch einen funktionierenden AMIGA 2000 mit allen erdenklichen Erweiterungen hier stehen... den ich ab und an auch mal benutze. :thumbup:

    Zitat von Bitnugger

    In einem (größeren) Unternehmen würde ich als Chef allerdings zumindest einen (guten) Programmierer damit beauftragen, immer ein Auge darauf zu haben, ob es sich bei eigenen Programmen lohnt, diese in ASM zu optimieren.

    Naja, wenn 99,9% des Codes eines "guten" (HLL-)Programmierers sowieso nicht durch ASM zu toppen sind (da bin ich voll und ganz bei dir! ) stellt sich die Frage, ob es sich nicht lohnt, gleich einen "guten" Programmierer einzustellen, der (logischerweise) dann "optimalen" Code abliefert!
    Die Antwort ist völlig klar, der "gute" Programmierer lohnt sich immer!
    Nur, woher weiß denn der "gute" Programmierer, dass sein Code nahezu "optimal" ist, und wann weiß er, dass ein in ASM geschriebener (oder Sourcecodeoptimierter!!! ) Programmteil den Compiler um Längen schlägt?!
    Das weiß er nur dann, wenn er sein Werkzeug kennt. Den Compiler und dessen Compilat. Und das auch "lesen" und verstehen/analysieren kann.


    Zitat von Bitnugger

    ASM hatte mich in vielen Punkten sehr begeistert, vor allem was Klarheit und Geschwindigkeit angeht. Nun befasse ich mich nur noch mit C, C++, AutoIt, FreeBASIC, Bash und PowerShell - mit C und C++ aber nur wegen spezieller Projekte. ....[snip]....FastIPrefs hatte das Original in fast allen Bereichen um Faktor 3~50 geschlagen, was Speed angeht, wobei wir unser Hauptaugenmerk nur auf erweiterte Funktionalität und maximale Stabilität gesetzt hatten. Heute würde ich ein so großes Projekt in ASM nur noch aus nostalgischen Gründen angehen

    Wir sind uns einig, dass niemand mehr komplette Programme in ASM schreiben sollte, sondern ausschliesslich geschwindigkeits/größen-relevante Programmteile!
    Aber genau DAS ist die Intention dieses Threads! F5-drücken reicht nicht... :D

    Btw., auch ich habe in den 80ern am liebsten mit der Kombination Basic / ASM gearbeitet. Basic für das Userinterface und in/output, ASM für den geschwindigkeitsrelevanten Teil.
    Aber da war die Sache noch überschaubar, 8/16-Bit BS und (ASM/Compiler)Code haben die Hardware zu 100% ausgenutzt.
    Heutige Prozessorfeatures werden von gängiger Software (Compiler!!!) garnicht oder nur halbherzig umgesetzt. Imho setzen die heutigen X86-Compiler "technisch" Code für ca. 20 Jahre alte Prozessoren um.


    Die einzige Geschwindigkeitssteigerung heutiger Softwareprodukte resultiert aus der Compilierung mit einem "neuen" Compiler, der "schnelleren" Code aus dem "alten" Sourcecode erzeugt! Umgekehrt heißt das doch, die Käufer wurden in den vorherigen Versionen beschissen nach Strich und Faden! Selbstverständlich hätte man vor einigen Jahren schon "schnelle" Programme abliefern können, aber leider waren die vorhandenen Programmierer nur F5-Drücker.... :Face:
    Und nicht daß jemand meint, das wäre nur bei kleinen Softwareklitschen so, gestern habe ich Updateangebote von Adobe bekommen. Hauptargument fürs Update ist "20-30% schneller". Da will jemand ernsthaft haufenweise Geld dafür, weil jemand anderes (Compilerhersteller) endlich mal seinen Job ordentlich gemacht hat. Der Sourcecode wurde größtenteils jedenfalls nicht geändert (Aussage Adobe). Das Geschäftsmodell ist klasse, einmal Sourcecode reingekloppt, und mit jeder "neuen" Compilerversion ist nur nach F5-drücken das Produkt "schneller" und kann dann nochmal verkauft werden! Userinterface bissl aufhübschen, fettich! Lizenz zum Gelddrucken!

    Zitat von Bitnugger

    Ops, habe gelogen... denn seit ein paar Wochen spiele ich auch ein wenig mit AssembleIt rum...

    Hast du schon die neueste Version mit dem "schicken" Debugger? Braucht man den/einen Debugger für 64Bit?

    //EDIT
    Überleg jetzt genau was du antwortest, ansonsten bist du mein Test-Opfer! 8o Oder schlimmer noch, ich frag dich ob du mir dabei hilfst 8)

    Das "Auf den nächsten Interpreter/Compiler warten und damit das Programm schneller machen" wollte ich bei AutoIt auch schonmal machen. (mein Code holt meistens schon viel aus der dem Interpreter raus, sodass am Code herumschrauben viel Arbeit und wenig Erfolg bereutet). Aber außer, dass der Interpreter immer größer und langsamer (nur in manchen Bereichen) wird ändert sich da nicht viel^^

    Das einige Compiler immer suboptimalen Code erzeugen (für das jeweilige System) liegt zum Teil (nicht vollkommen) daran, dass die Abwärtskompatibilität gewahrt bleiben muss und daher weniger Energie in Sachen wie "Neue Prozessorerweiterungen" usw gesteckt wird. Ich wette aber, dass es Compiler gibt die den Prozessor bis zum Rand ausreizen können. Wenn man sich sowas wie z.B. die Playstation 3 ansieht und dann darauf achtet was für eine gigantische Entwicklung die Spiele in ihrer Lebenszeit (auf der gleichen Hardware wohlgemerkt) durchgemacht haben merkt man, dass da an allen Ecken geschraubt wurde. Und ich glaube nicht, dass da die Mehrzahl der Programmierer immer fähiger wurden, sondern, dass die Engines weiterentwickelt sind (besserer, schnellerer Code, hier braucht man ggf Leute die sich auskennen), und dass die Compiler die Kiste zum Schluss besser ausnutzen. Das hat aber auch ein Jahrzehnt gedauert bis die Kiste ihr volles Potential entfalten konnte und die Software die Hardware eingeholt hatte.

    Solange jedes Jahr eine "neue Architektur" rauskommt und kein "Standard" länger als ein Jahr aktuell ist kann ich auch die Compilerhersteller verstehen wenn sie da keine Lust mehr haben. Die Computer die aktuell genutzt werden sind 0 bis 10 Jahre alt und haben 32 oder 64Bit. Jede "Generation" hat irgendwelche krassen Erweiterungen. Wenn man das optimal nutzen will müsste man den Code 50x Kompilieren (für jedes System einzeln) und beim Programmstart die richtige Version wählen (Weichen im Programm selbst sind ineffizient, da es dann bei jedem "neuen" Befehl/Funktion nen riesen Overhead gibt um zum auszuführenden Code zu springen). Das ist halt alles ne blöde Kiste. Von daher: Tee trinken und entspannen und warten bis Skynet die Welt übernimmt^^

    Zitat von Mars

    Ich wette aber, dass es Compiler gibt die den Prozessor bis zum Rand ausreizen können.

    Diese Compiler werden aber nicht beliebigen Sourcecode nur durch F5-Drücken in ein bspw. schnellstmögliches Ergebnis verwandeln (können).
    "Bis zum Rand ausreizen" tun das heutzutage schon die Programmierer mittels Intrinsics(). Was allerdings nichts weiter als "SIMD-Funktionen per Hand eingefügt" ist! Und dafür kann der Compiler nix!

    Zitat von Mars

    Die Computer die aktuell genutzt werden sind 0 bis 10 Jahre alt und haben 32 oder 64Bit. Jede "Generation" hat irgendwelche krassen Erweiterungen. Wenn man das optimal nutzen will müsste man den Code 50x Kompilieren (für jedes System einzeln) und beim Programmstart die richtige Version wählen

    Ich kann mich an eine Ausgabe einer c´t erinnern, da wurden die damals "neuen" MMX-Befehle (damals exclusiv in x86-AMD-Prozessoren) händisch in ein Programm verpflanzt und auf Geschwindigkeit getestet. Gegenüber einem "normal" compilierten Code war erwartungsgemäß Faktor 2-3, je nach Problemstellung auch mal Faktor 5 in der Geschwindigkeit feststellbar. Was sich mir ins Gehirn gebrannt hat war die Tatsache, dass auf einem PowerPC das Compilat des Sourcecodes genauso schnell lief, wie der "handoptimierte" x86-Code.
    Compiler DOCH besser als ein Programmierer? Nö, denn ein PPC hatte damals "von Geburt an" 64-Bit-FP-Register, und die wurden von den Compilern auch selbstverständlich konsequent umgesetzt! Von AltiVec ganz zu schweigen! Schauschau, die Vektorbefehle in Form von Intrinsics werden vom GCC in äquivalente x86-Befehle umgesetzt wenn für x86 compiliert wird, Crosscompiling ftw!

    Wenn der Programmierer weiß was er tut, dann holt er auch das Optimum aus einem Compiler heraus! Wobei in diesem Fall (Verwendung von Intrinsics) der Compiler wiederum nichts weiter ist als ein Assembler, der den eingegebenen Code 1:1 umsetzt. Erfordert das seitens Programmierer "erweitertes" Wissen? Ja! Eine "erweiterte" Denke? Sicherlich! Wie hoch ist die Chance, einen solchen Programmierer zu erwischen? Geschätzt 5%!


    Btw. Spielconsolen, Jahrzehnte dominierte der PPC die Spielconsolenwelt. Und da waren/sind "schnelle" Programme existentiell! Die Compiler/Programmierer wurden auf die Hardware "optimiert". Auch und gerade die Programmierer! "Schnellen" (auf die Hardware "optimierten") Sourcecode reinkloppen, F5 drücken, "optimales" Ergebnis! Funktioniert doch!

    https://gcc.gnu.org/onlinedocs/gcc…ctor-Extensions :rtfm:

    Zitat von Mars

    Das "Auf den nächsten Interpreter/Compiler warten und damit das Programm schneller machen" wollte ich bei AutoIt auch schonmal machen.

    || ...
    Wobei man fairerweise sagen muss, dass bei einem Interpreter sowieso irgendwann das Maximum an Geschwindigkeit erreicht ist. Und ich denke, da ist AutoIt garnicht mal schlecht!

    Villeicht klappt es ja indirekt. In 10 Jahren haut ein AutoIttyp auf F5. Der Interpreter ist durch den besseren Compiler 3x so schnell -> Der AutoIt-Code ist auch 3x so schnell^^ Dafür dürfen die aber keine "Bugfixes" mehr einbauen, die 300kb große LuTs oder 50KB Workaround für EINEN Bug liefern. (Oder einfach den Code mal Open Source machen und die Community mal richtig toben lassen, da hätte ich auch noch Spaß dran :D)

    @'Bitnugger
    ich muss es loswerden ! Amiga no no no - only Atari ST :) und Turbo Pascal....


    Gruß

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

    Zitat von Peter S. Taler

    Atari ST und Turbo Pascal...

    Atari ST vs AMIGA - das uralte Thema... im großen Ganzen waren beide System gleichwertig, beide hatten Stärken und Schwächen.

    Der Atari ST konnte vor allem in Sachen Audio punkten. Ich stand damals vor der Entscheidung und habe hin und her überlegt, welche Wundermaschine ich mir denn nun zulegen will, mich dann aber am Ende wegen des Betriebssystem und dessen Besonderheiten für den AMIGA entschieden. Mit beiden Systemen konnte man... nein, kann man auch heute noch fantastische Sachen machen.


    :ironie:
    Meine Meinung: Ein Computer hat nur so viel Wert, wie sein User ihm einhauchen kann... und da schätze ich mal ganz gelassen, hättest du bei einem direkten Vergleich mit mir sehr alt ausgesehen... dagegen wäre selbst der Luis Trenker völlig faltenfrei! :rofl:
    [/IRONIE OFF]

    Turbo Pascal... ja, damit konnte man auch ganz nett basteln... aber kein Verleich mit Assembler wert. Die Programmierung war unter Turbo Pascal für Windows ähnlich aufwendig wie in C – mit dem zusätzlichen Nachteil, dass Windows selbst in C programmiert ist, weshalb die Schnittstellen zwischen Windows und Pascalprogramm mindestens grundlegende C-Kenntnisse erfordern. Daher gab und gibt es absolut keinen Grund, weshalb ich mir zu irgendeiner Zeit Turbo Pascal hätte antun sollen. :Glaskugel:

    Einmal editiert, zuletzt von Bitnugger (7. November 2016 um 17:48)

    Zitat von Bitnugger

    Mit beiden Systemen konnte man... nein, kann man auch heute noch fantastische Sachen machen.

    Komm mit im nächsten Jahr zur Revision, und bring das/die Schätzchen mit!!! Dort findest du weitere völlig bekloppte, die selbst heutzutage noch sehenswerte Grafik- und vor allem Audio-Demos abliefern! Vom Hardwaregebastel ganz zu schweigen 8o

    Bzgl. Ironie[modus]...Luis Trenker faltenfrei...der hätte bestimmt gedacht, Peek und Poke wären die tschechischen Geschwister von Ying und Yang :party: ...öööhhmm...nö, das sind doch Lolek und Bolek :rock: //EDIT große Abbitte an die beiden, die sind natürlich nicht tschechisch, sondern polnisch! Pan Tau ist tschechisch. T´pau ist vulkanisch... :Face:

    Zitat von Bitnugger

    Turbo Pascal... ja, damit konnte man auch ganz nett basteln... aber kein Verleich mit Assembler wert. Die Programmierung war unter Turbo Pascal für Windows ähnlich aufwendig wie in C – mit dem zusätzlichen Nachteil, dass Windows selbst in C programmiert ist, weshalb die Schnittstellen zwischen Windows und Pascalprogramm mindestens grundlegende C-Kenntnisse erfordern. Daher gab und gibt es absolut keinen Grund, weshalb ich mir zu irgendeiner Zeit Turbo Pascal hätte antun sollen.

    Als "alter" GW-Basic/Assembler-Programmierer hatte ich genau damit meine Probleme. Der einzige Grund, Turbo-Pascal damals in der Schule zu benutzen war imho der Compiler, also ein EXE-File. C war bei mir nie eine Alternative, denn die "Profis", welche von Basic zu Pascal/C umgestiegen sind, um weniger/keinen "Spaghetticode" zu generieren, waren 1/2 Jahr später nicht mal in der Lage, eine Woche vorher selbstgeschriebenen Code zu analysieren. Bevor da einer den Debugger gestartet hat, wurden halt einige hundert Zeilen Code komplett neu geschrieben :rolleyes: ....und genau dieses Vorgehen wurde übrigens viele Jahre später bei IBM zu einer Kunst ausgebaut. Da gab es dann ganze Abteilungen, die statt "ordentlich" zu debuggen (mach das mal bei hardcore-Spaghetti-C !!) Programme/Funktionen NEU geschrieben haben (incl. extra bezahlten Zeilen Kommentaren!!!). Hehe, das mit den Kommentaren war dermaßen wichtig, dass Programme geschrieben wurden, welche Kommentare in den Sourcecode einfügten. Das ist übrigens absolut KEIN WITZ!

    Ich bin später dann auf TurboBasic umgestiegen. DAS war ein geiler Compiler, und der integrierte Debugger hat auch seinen Job gemacht! :klatschen:

    Zitat von Peter S. Taler

    Atari ST und Turbo Pascal...

    Atari ST vs AMIGA - das uralte Thema... im großen Ganzen waren beide System lgeichwertig, beide hatten Stärken und Schwächen.

    Der Atari ST konnte vor allem in Sachen Audio punkten. Ich stand damals vor der Entscheidung und habe hin und her überlegt, welche Wundermaschine ich mir denn nun zulegen will, mich dann aber am Ende wegen des Betriebssystem und dessen Besonderheiten für den AMIGA entschieden. Mit beiden Systemen konnte man... nein, kann man auch heute noch fantastische Sachen machen.


    :ironie:
    Meine Meinung: Ein Computer hat nur so viel Wert, wie sein User ihm einhauchen kann... und da schätze ich mal ganz gelassen, hättest du bei einem direkten Vergleich mit mir sehr alt ausgesehen... dagegen wäre selbst der Luis Trenker völlig faltenfrei! :rofl:
    [/IRONIE OFF]

    Turbo Pascal... ja, das konnte man auch ganz nett mit basteln... aber kein Verleich mit Assembler wert. Die Programmierung war unter Turbo Pascal für Windows ähnlich aufwendig wie in C – mit dem zusätzlichen Nachteil, dass Windows selbst in C programmiert ist, weshalb die Schnittstellen zwischen Windows und Pascalprogramm mindestens grundlegende C-Kenntnisse erfordern. Daher sehe ich absolut keinen Grund, weshalb ich mir zu irgendeiner Zeit Turbo Pascal hätte antun sollen. :Glaskugel:

    Zitat von Andy

    Komm mit im nächsten Jahr zur Revision, und bring das/die Schätzchen mit!!!

    Hehe... dann bräuchte ich aber mindestens zwei sehr kräftige Kofferträger, denn mein AMIGA wiegt gefühlt mindestens 1 Tonne, denn ich habe meinen AMIGA 2000 in einen Big-Tower (65x21x~50 cm) gepackt, mit 8 oder 9 uralten, bombastisch schweren Festplatten drin, und dazu auch alle Slots mit einer fetten Karte belegt!


    Zitat von Andy

    Revision

    Hm, also doch noch zu wenig hier im Forum gelesen, denn das sagt mir jetzt nicht wirklich was.

    Zitat von Bitnugger

    Hm, also doch noch zu wenig hier im Forum gelesen, denn das sagt mir jetzt nicht wirklich was.

    ok....du wolltest es so 8o
    Chronologisch:
    Breakpoint 2010 in Bingen am Rhein vom 2.-5. April zusammen mit UEZ ein Hammer Event in Bingen!
    Danach in jedem Jahr zusammen mit UEZ nach Saarbrücken:
    Revision Demoparty 2014 Streams'n'Tools (und allgemeine Demoparty Diskussion)
    Wo ist der Thread mit den Bildern aus 2015? //EDIT Revision 2015 ... na geht doch!
    Revision 2016 - "The return of EvilBot" mit Xorianator, Lottich, UEZ und meiner Wenigkeit! Viel Spass dabei, die Namen den Personen zuzuordnen :D
    Revision 2017 und die Schnitzeljagd Vorbereitung für die nächste Revision

    Website: https://2016.revision-party.net