"Programming in Lua"+"Lua Reference Manual". Ein paar Abende Bettlektüre, und das Jahrespensum ist drin (das war jetzt alles?). Eine Sprache mit dynamischem Typing, Closures, Coroutinen, einer einzigen Datenstruktur. Syntax paßt auf ein DINA5-Blatt ohne groß zu quetschen. Mit die schnellste Skriptsprache, die es so gibt. Mit dem aktuellen luajit-Compiler mittlerweile durchaus auch schon mal schneller als C bei Numerik.
Einige Firmen bieten Weiterbildung für ihre Mitarbeiter an. Klar, in einem Zweitageskurs oder so wird man nicht viel lernen, und ein Kurs für Prolog oder Ada wird man auch nicht an jeder Ecke finden, aber zumindest die Grundlagen könnte man lernen. Vielleicht bei Google anfangen, falls die noch 20% der Arbeitszeit für eigene Projekte genehmigen.
Am besten ist natürlich, selbständig zu sein. Wenn man es nicht übertreibt mit den Projekten, dann gibt es Zeiten, in denen es recht ruhig ist und man sich mit eigenen Projekten beschäftigen kann.
--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Aber ich weiss was du meinst. Ich schreibe in letzter Zeit auch Matlab Programme die schneller sind als der C counterpart. Das Ausschlaggebende ist, das in oft C so pseudo optimiert geschrieben wird, während die Arbeit an Algorthmen fast alle scheuen.
"Numerical Recipes in C" ist da übrigens ein Verbrechen. Man ist viel besser damit bedient, das Original für Fortran zu kaufen und selbst in C zu übersetzen (am besten C99, dann klappt es auch mit der Übergabe mehrdimensionaler Felder variabler Dimension ohne daß man selbst mit Adreßarithmetik anfangen müßte).
Die übersetzen einen Feldzugriff a(i,j) in einen Zugriff a[i][j]. Wobei dann a als double *a[n+1][] deklariert ist oder so. Man also für jedes Feld ein Pointerarray mitschleppt, was den Optimizer vergrault und Adreßarithmetik durch Speicherzugriffe ersetzt. Auf 1-basierte Arrays. Bißchen Verschnitt ist immer.
Krank, krank, krank. Besser das Zeug gleich in Fortran lassen und mit passenden Deklarationen direkt aufrufen.
Oder halt bedarfsweise die Fortran-Fassung konsultieren und selbst übersetzen. Die Autoren sind dazu unfähig gewesen.
Ultraschall Beam Field Simulation ist nicht gerade von Pappe. Einem von uns ist dabei allerdings ein Pentium abgefackelt (kein Scherz). Die Sun war schon sehr leistungsfaehig, aber eher was fuer Wissenschaftler. Kaeufliche Software dafuer war rar und oft schroecklich teuer.
Bei uns an der Uni waren die Dinger in den 90ern Datenbankserver, da=20 gabs diese Software noch nicht mal f=C3=BCr Windows, mangels=20 Windows-Server-Betriebssystem. Auf Win 3.11 oder NT 3.51 hab ich sowas=20 nie laufen sehen. Auch einige CAD-Systeme liefen auf den Suns, und damit =
Ok, bin ich wohl in einer anderen Welt aufgewachsen. Selbst Ende der
80er waren unsere Datenbanken PC-basiert. Alles gusseisern unter DOS, damals noch mit Netzwerk ueber Koaxkabel. MRP Systeme und so weiter, das gab es schon.
Ein fettes CAD lief im Hauptwerk bei Seattle auf nicht-PC Hardware (Mentor). Das war's dann aber schon, auch da war der Rest alles PCs und es war immerhin eine Firma mit rund 1000 Leuten.
Ich kaufte mir Mitte 1990 einen gebrauchten PC für damals 2500 DM, der hatte immerhin schon eine 10 Megabyte Festplatte.
Auf der befanden sich unter anderem Raubkopien von Turbo Pascal und AutoCad, damals in der Version 5 oder so.
Funktionierte mit Herkules-Grafik und 1 MB RAM.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
Wissenschaftler schreiben sich ihre Software selber, weil für Forschungen i.A. gar keine kaufbare Software verfügbar ist. M$ hat z.B. keine Cern2010-Suite im Angebot. Die Software wird dann oft in so "rückständigen" Programmiersprachen wie Fortran geschrieben, weil es da seit Jahrzehnten eingeführte und optimierte Numerikpakete mit hoher Auflösung gibt. Ansonsten ist fast beliebig viel freie Software verfügbar, ein Grossteil der "Linux"-Software ist von Systemen wie Solaris oder BSD portiert.
Weiss ich nicht mehr. Die Leute von der Doku nannten ihren Teil immer Open Access obwohl es das offiziell erst spaeter gab und wir hatten erst
1986. Die Produktion benutzte ein MRP System auf das auch der Einkauf Zugriff hatte.
So ein Luxus :-) ... 1MB RAM hatte mein erster PC damals nicht.
Als ich mich selbststaendig machte besorgte ich einen Tandon 386er mit
1MB RAM, der dann aber locker flockig fast 10000DM kostete. Plus NEC Multisync der nochmals etliche Tausende kostete. Den ruestete ich auf
5MB hoch und damit konnte ich endliche Orcad, Word, Works und noch andere gleichzeitig und sofort laufbereit im Speicher sitzen haben.
Auf unserer lief ein gekauftes suendhaft teures Simulationsprogramm was es nur fuer die Sun gab, war der Grund warum sie zaehneknirschend angeschafft wurde. Das riss alles ein tiefes Loch ins Budget.
Fortran finde ich nicht rueckstaendig, habe selbst mal mit programmiert. Auf Lochkarten :-)
So habe ich es gelernt. Als ich es für eine Studienarbeit anwenden mußte gab es sogar schon einen Zeileneditor. Und Sonntag nachts um drei konnte ich ruhig, ungestört und vor allem interaktiv ohne Batchbetrieb im Institut arbeiten. War nett.
Ich glaube zu der Zeit wartete ich noch ein paar Jahre auf die D-Mark und übte mich voller Vorfreude mit meinem ZX81 an diverser Programmierung.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
Kann mich noch gut erinnern wie mir ueber einem ZX80 oder ZX81 Prospekt aus Frankreich das Wasser im Mund zusammengelaufen ist. Doch ich war Student, das Dingen sollte fast 1000 Francs kosten und die hatte ich akut nicht.
Vattern hatte zuhause einen IBM 5100, mit Basic und APL, aber das war relativ weit weg von Aachen. Ausleihen ging auch kaum weil das Ding bleischwer und wuchtig war.
Das habe ich mir nicht angetan, und aus dem Grund die Schaltplaene zu meiner Diplomarbeit nicht auf dem Racal-Redac System gemacht, sondern klassisch in Tusche auf Vellum. Waere wohl auch nur sonntags um drei Uhr nachts gegangen.
Mit den Fortran Programmen war das was feines. Wir hatten Stanzer von Juki und IBM. Dauernd besetzt und die Juki gingen oefter kaputt. War zwar offiziell, aehm, nicht gestattet, aber ich brachte dann Werkzeug mit und reparierte das Dingen. Danach kam ich immer als erster dran :-)
Der ZX81 kam IMHO mal um die 200 DM, ich habe den 1984 mit 16 kB RAM gebraucht in Dresden für 2000 Mark Ost gekauft. Gute Investition.
Später hatte ich dann noch leihweise einen C128 auf dem ich was in dbase programmierte (der lief ja auch unter CP/M).
Ein identisches Gerät stand beim Besitzer und Nutzer meiner Software der beide finanzierte.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
Genau weiss ich das auch nicht, der Vorgänger (ZX80) soll auch noch deutlich teurer gewesen sein. Der hatte auch einiges mehr an Bauelementen, der ZX81 war mehr oder weniger nur noch der Prozessor, der grosse Asic und der RAM.
Achtung, 1 MB:
formatting link
Genial einfach, insbesondere auch die Bilderzeugung für den Fernseher mit NOP-Befehlen der CPU.
Wir zogen beide unseren Nutzen draus, sonst wäre ich nicht zu der mehrmonatigen Leihstellung gekommen.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
Die scheinen sogar den 65MHz Resonator rumgerissen zu haben. Vor solchen Schaltungsentwicklern muss man den Hut ziehen. Zwei Chips, RAM, ROM, Modulator, fertig ist der Rechner.
Heutzutage ist das irgendwie anders. Uns ist bei einem uC mal nur ein grober 8-bit Timer uebriggeblieben und beim Meeting kam dann lediglich der Vorschlag, den naechst-dickeren uC zu nehmen weil der mehr 16-bit Timer hat. Als ich die Verwendung dieses 8-bit Timers plus NOP vorschlug guckten mich die SW Leute an als haette ich einen totalen Frevel ausgesprochen. Igitt ...
Ah, ok, ich dachte das waere eine Dauerleihgabe gewesen :-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.