Wenn du meinst... Andere haben gesehen, dass ich Axel etwas ärgern wollte.
Soso. Ich denke schon, dass ich Programmierer von Datatypisten und Informatikern von Operators (Tape-Ape, Printer-Sprinter usw.) ansatzweise unterscheiden kann. Wobei die Unterscheidungen früher anders waren, insbesondere wenn man ein quasi unendliches Budget wie es das amerikanische Weltraumprogramm damals hatte. Im von mir zitierten Beispiel "Fortran-Flaw lässt Rakete explodieren" war der Coder nicht einfach der, welcher eingetippt hat, sondern jemand, welcher das Formelgewirr der Ingenieure in Code übersetzt hat.
Wer ist "die"?. Die Rede war von den "Informatikern", welche stolz dafür sind, dass sie nicht programmieren können.
Ja eben. Und meine Theorie lautet, dass die Mehrzahl der ausgebildeten Informatiker als Programmierer nicht taugt.
Ausnahme. Die Leute, die überhaupt noch in der Lage sind, neue Algorithmen zu finden, kann man IMHO an einer Hand abzählen. Von denen braucht es ja auch nicht mehr. Wenn man dann noch Pech hat, sitzen die nicht an einer Hoch- schule, sondern in einer Firma, womöglich noch der eigenen :-). Da wandert das dann in closed-source, und man muss Geld dafür ausgeben. So was gemeines auch :-]. Merkwürdiger- weise meinen die Leute heutzutage, nur die eigene Arbeit müsste bezahlt werden. Genau darum ging es mir doch.
"Rolf_Bombach" schrieb im Newsbeitrag news:459a9cb1 snipped-for-privacy@news.bluewin.ch...
genau die
Na, die besser nicht, die koennen ja noch Taxi fahren.
Leider werden sie meist zu Chefs, weil sie ja so viel Zeit haben, sich um ihre Karriere zu kuemmern.
Ja, kommt hin. Aber die Physiker und Chemiker, die programmieren, taugen dazu auch nicht.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Das ist primär ein kosmetischer Vorteil. Man kann die Formeln der Theoretiker schneller und kompakter (aber auch wesentlich besser lesbar) darstellen. Die Frage ist, wie gut der Compiler damit fertig wird. Die von DEC waren nicht bei allen Operationen wirklich günstig. Ist inlining mit Aufpfriemeln in die Anteile wirklich so schlimm? Liefert merkwürdigerweise oft den schnellsten Code. In C lassen sich komplexe Zahlen ja auch leicht realisieren. Die Operationen muss man dann halt selber definieren, und da wird viel gestümpert. Aber auch hier die Frage: Lohnt das? Schneller wird es dadurch garantiert nicht.
Gibt aber auch herstellerspezifische Dialekte, das ist dann nicht so toll.
Völlig klar. Ich wollte auf was ganz anderes hinaus, was mich eben heute so wundert. Thomas Watson hat ja schon
1943 festgestellt, dass der Markt nur etwa 5 (Super)Computer schluckt. Und klar, wer sich einen Top-Windkanal oder sogar Atomtests leisten kann, kann sich auch einen Super- computer leisten. Und wer sich einen Supercomputer leisten kann, kann sich auch einen guten Compiler leisten.
Der Rest der Welt muss sich mit weniger begnügen, insbesondere auch im Hochschulumfeld. Eine Anordnung von 10 PC-Prozessoren ist da schon der Supercomputer. Genau in diesem Umfeld wunder es mich, dass ineffiziente Strategien angewendet werden. Wie genannt eben dieses zwanghafte Umschreiben ehemals guter Fortran-Programme in schlechte C-Programme, die dann mit gratis-Compilern übersetzt werden. Das fing mit gewissen SPICEs an, ging über Mie-Streuprogramme bis hin zu Gaussian [*]und dergleichen. Oftmals gilt dann der Doktorand als billige Arbeitskraft. Da blick ich nicht mehr durch. Man spart doch kein Geld, wenn man für den Compiler nichts ausgeben will, dafür aber
10x mehr Prozessoren (oder Zeit) aufwenden muss.
[*] respektive verwandte Computerfresser der theoretischen Chemie, das Gaussian-Trauerspiel als solches will ich hier mal ausklammern.
"Karlheinz Böhme" schrieb im Newsbeitrag news:enbplb$bqv$00$ snipped-for-privacy@news.t-online.com...
Na, immerhin einer, Guido ist damit ja offenbar ueberfordert.
Hmm, jemand der Kommentarzeilen schlecht findet, sogar solche die kompakt ueberbaetterbar waeren, ist wohl schon ein seltsamer Informatiker.
Das REALEASE.TXT/VERSION.TXT/CHANGES.TXT oft verloren gehen und daher so ein Text besser unteilbar mit dem Programm verbunden ist, hast du aber wohl in deiner Karriere noch nicht erlebt. Macht nichts, das wirst du auch noch erleben, und hoffentlich daraus lernen. Ich habe gelernt.
Oh, du findest auf der WebSite auch Basic-Programme, kein Problem. Aber ich bin sicher, das du sie auch schlecht findet, dazu wirst du gar keinen Blick in deren Source werfen muessen.
Da hast du einen Punkt. Du hast richtig herausgefunden, das der Code von
1993 stammt, aus der Kommandozeile, die tatsaechlich nur 80 Zeichen konnte, mit einem Kompiler, der _MAX_PATH noch nicht kennt.
Gute geschichtliche Kenntnisse.
Und ich stimm dir zu, das bei der Uberarbeitung auf 32 bit MSVC 4.0 die Grösse hätte angepasst werden müssen. Your point.
Das ist natuerlich schade. Du erinnerst mich an die Maenner, die bei Frauen auf die scharfe Latina gucken, egal welche blode Zicke es auch sein mag, und ob Silikonbrueste oder Hohlkopf. Leider gibt es davon viele Maenner die nur auf das oberflaechliche Aussehen achten. Na ja, musst du selber wissen. Substatntielle Kritik kannst du dir damit natuerlich nicht erlauben.
Ah, einer der an der Form rummmaekelt. Bei Newsgruppen maekelst du wohl am Plenken, bei Code am fehlenden Whitespace. Sorry, Leute die sich an dermassen oberflaechlichem aufhaengen, zeigen damit nur, das ihnen das Innere offenbar mangels Tiefblick verborgen bleibt.
Ja, vor allem irrelevant. Deiner Meinung nach sind Lehrbuecher von Wirth also schlecht, waren kommerziell erfolgreiche Programme wie CP/M und GEM also Murks (reihenweise kurzbuchstabige Variablennamen), dafuer wirst du z.B. PGP (durchaus einem Meisterstueck wenn man auf unterschiedlichste Compiler portablen Code sucht), gern haben, obwohl ich dir sagen kann: Er ist praktisch unwartbar, musste ich selbst erleben darin eine Anpassung vorzunehmen. Vieler aktueller open source, z.B. auf sourceforge, hat auch schoene lange Namen, die mehr verschleiern, als erhellen.
Compiler. Leider. Es gibt also fachlich sachliche Gruende dafuer, keine virtuell vorgeschobenen, wie 'man koennte das Modul ja mal woanders gebrauchen', in einem woanders, das nie existieren wird.
Tja Karlheinz, da signalisierst du ein moegliches Problem der heutigen Zeit: Uninformierte Leute wie du, die sich vom aeusseren Anschein ihre Urteile bilden, zerstoeren Werke, die nachher nur durch schlechteres zu ersetzen sind. Viele ehemals nuetzliche und brauchbare Software ist in den letzten Jahren verschwunden, wohl durch Leute wie dich, die mit theoretischem Geschwaetz meinten, alles besser zu koennen, dann nur leider an der Praxis scheitern. Dafuer sind die nicht-funktionierenden untauglichen Programme nun hyper-objektorientiert und ueberhaupt ganz modern.
Deine open source Beispiele im Netz finde ich wo ?
Oh, ich geh den Weg, das ich mir statt dem Geschwaetz von Theoretikern lieber die Ergebnisse von kommerziell erfolgreichen Praktikern ansehen, denn den Source von z.B. CP/M, GEM und Windows gibt es inzwischen frei zugaenglich im Netz.
Und da finde ich meinen Programmierstil sehr wohl wieder (und vor allem das, was mir schon damals an den Theoriebuechern zur Programmerstellung eher hinderlich vorkam, gerade nicht). Da solltest du mal reinschauen, und vielleicht auch mit arbeiten, das rueckt dann einiges in deinen Vorstellungen wieder gerade.
Also: Innerhin hast du ja statt Guido reingeschaut, aber deine Kritik ist GROB oberflaechlich. Zumindest hat Guido nun jemanden, an den er sich sabbernd ranhaengen kann.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Ich halte es ja generell für ziemlich dämlich, darauf stolz zu sein daß man etwas nicht kann. Obwohl ich mir nicht zu fein bin, manchmal darauf hinzuweisen daß ich zwar im Computer-Business bin, aber mit Windows nichts am Hut habe. Aber schließlich kann man das damit begründen, daß PCs keine richtigen Computer sind und Windows kein richtiges Betriebssystem ;-)
Aber um nochmal auf die Informatiker zurück zu kommen: im Zweifelsfall kann ein Informatiker eher auf praktische Programmierkünste verzichten als auf Mathematik. Im Idealfall kann er natürlich beides.
Er *wird* nicht als Programmierer ausgebildet. Schau halt einfach mal in den Stundenplan eines Informatik-Studiums.
Es ist aber eine Unfähigkeit, die man den Leuten nicht spezifisch vorwerfen kann. Ein BWL-Absolvent muß nicht sofort die Buchhaltung eines Unternehmens leiten können, ein Biochemiker nicht Begonien von Pelargonien unterscheiden können und ein Lebensmittelchemiker muß keinen leckeren Schweinebraten zubereiten können. Obwohl jeder von ihnen zumindest die theoretischen Kenntnisse dafür hat.
Programmieren - gar noch im Team an einem großen Projekt - verlangt eine Vielzahl an Fähigkeiten, von denen einige nicht, oder zumindest nicht im Rahmen eines Studiums gelehrt werden können:
- solide Grundkenntnisse in Algorithmen und Datenstrukturen
- Kenntnisse verschiedener Programmierstile (funktional, prozedural, objektorientiert) und wann man sie jeweils (nicht) verwendet
- praktische Kenntnisse verschiedener Programmiersprachen und die Fähigkeit zur Einschätzung für welches Problem man sie jeweils (nicht) verwendet
- Arbeit im Team, Organisation, Dokumentation, Projektarbeit etc.
zusammen mit den notwendigen Grundlagen in Mathematik und Logik sprengen schon die ersten beiden Punkte dem Umfang eines Hochschul- studiums. Punkt 3 kommt notorisch zu kurz und ist wegen der mittler- weile recht kurzen Lebenszeit "angesagter" Programmiersprachen ohnehin ein lebenslanger Dauerjob.
Für die meist kleinen praktischen Programmierprobleme kommt noch dazu, daß es eben keinen richtigen Informatiker gibt, der die notwendigen Vorarbeiten erledigt:
- Analyse des Problems
- formale Lösung und Spezifikation
- Aufstellung des Pflichtenheftes
Kein Widerspruch.
Neue Algorithmen werden auch höchst selten erfunden, sondern entstehen meist evolutionär aus der Kombination von vorhandenen Algorithmen. In meiner Diplomphase und in den drei Jahren danach habe ich auf diesem Feld gearbeitet. In der Anfangsphase war es mehr das Kombinieren verschiedener existierender Ansätze, mittlerweile sind einige unserer Sachen als eigene Algorithmen anerkannt.
"Axel Schwenke" schrieb im Newsbeitrag news: snipped-for-privacy@xl.homelinux.org...
Oha, wenn du gesagt haettest, das du dich damit aus-welchem-Grund-auch-immer nicht beschaeftigt hast, kann man es akzeptieren, so hingegen enttarnt das die Schwaetzer, ob mit oder ohne Smiley.
Na ja. Hoehere Mathematik braucht er selten, nicht mal bei Erstellung von Projektplaenen. Wer Dinge entwirft, bei denen er nicht weiss wie sie umgesetzt werden, ist normalerweise ein schlechter Entwerfer, ob im Bau, im Automobilbau oder eben in der Softwarebranche.
Ok, es gibt haufenweise schlechter HAeuser, schlechter Autos und eben schlechter Software. Hinter guter Software steckt immer ein Kopf, der alles konnte, Entwurf und Umsetzung.
Da steht Algorithmen und Datenstrukturen, Programmieren und Programmierpraktikum drauf, neben all den theoerischen Grundlagen ueber Compiler, Datenbanken, Betriebssysteme & Co. Wer hinterher nicht programmiern kann, war wohl mehr in der Gastwirtschaft als im Hoersaal.
Sicher. In Maschbau nicht anders.
Sollte er ebeso koennen wie programmieren.
Heute, in der Zeit der kommerziellen Datenverarbeitung, erfindet man Patentierbares, nicht so was triviales wie 'Grundlegend Neues', damit ist ja kein Geld zu verdienen.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Das ist genau der Punkt: Mit einer Klasse "complex" muss der Compiler erstmal 1023 Dinge prüfen, z.B. ob nicht irgendeiner was überlagert oder an der Klasse rumgebastelt hat, bevor er die Hardware ins Spiel bringt, bei intrinsischen komplexen Zahlen geht es gleich zur Sache, weil keiner die verbiegen kann.
Kennst Du einen Formel-1 Rennwagen, bei dem Fensterheber, Klimaanlage und Soundsystem verbaut wurden ?
Nix da, Fenster ist nicht, es wird Helm getragen, Sound macht der Motor ;-)
Das Autochen dient nur einem Ziel: Nach 72 Runden (oder wieviel auch immer) als erstes die schwarz-weiß karierte Flagge zu sehen. Vor dem Rennen gibt es gerne Spitzenköche und dienstbare Geister, die jedes Stäubchen wegwischen, das braucht der Fahrer nicht selber zu machen, und danach Schampus. Aber der _Arbeits_platz selber bleibt genau dort "unbequem", wo wegen des Ziels nötig. Basta.
So ist es auch beim Höchstleistungs-Numerikrechner:
Spitzen-Compiler gerne, Grafik-Debugger gerne, aber dem Ziel "schnellste Rechnung von Welt" hat sich scheinbare Bequemlichkeit in Form von Klassen & Co. unterzuordnen. Das Ding soll schließlich keine depperte Büroklammer animieren, sondern rechnen. Und je schneller es rechnet, umso feiner ist das Grid, umso höher ist die Auflösung und die Präzision und z.B. zeitliche Reichweite der Simulation. Und all das, was man _zuverlässig_ simulieren kann, spart eine Menge Zeit und Geld.
Dem haben sich auch die "ihr braucht aber unbedingt meine 'class happy_klammeraffe' mit 3D-Grafik-Inheritance" Informatiker unterzuordnen. Numerikrechner sind kein Spielplatz, sie verursachen verflucht hohe Abschreibungen (nach fünf Jahren ist die Kiste veraltet) und dienen einem _Ziel_.
Drum ist DEC ja auch vom Markt verschwunden. DEC hatte mit der VAX lange Zeit die klassische technisch-wissenschaftliche Plattform für den "gehobenen Institutsbedarf", also schon schnell, aber nicht ganz Großrechner.
Dann haben sie aber die weitere Entwicklung verpennt und die Kunden mit der "heute MIPS, morgen Alpha, werft euer MIPS weg" Aktion vor den Kopf gestoßen. In der Zwischenzeit hatten die PC's aufgeholt.
DEC war mal eine Macht. Die hatten hier um die Ecke halb Unterföhring mit Büros bestückt, dort wo heute Pro Sieben und Premiere sind. DEC ist _das_ klassische Beispiel eines Firmenuntergangs durch Verlust der technischen Führung.
Ja, weil Aufpfriemeln immer wieder _Probieren_ beim Optimizer voraussetzt. Hingegen nützen intrinsische complex-Zahlen _Wissen_.
Oft, aber nicht immer. Das Kunststück besteht in der richtigen Kombination aus Probieren und Wissen im Optimizer, dabei hilft natürlich jede zusätzliche Information.
Der Compiler tut sich leicht damit, eine Complex-Formel in elementare reale Rechenoperationen zu zerlegen, umgekehrt geht es deutlich schwerer (Mustererkennung). Wenn nun die Hardware in Hinblick auf komplexe Zahlen konstruiert wurde (ist z.B. bei den PC-CPU's definitiv nicht der Fall, bei anderen schon), dann kann dieses Wissen dem Compiler vieles erleichtern.
Gleiches gilt für bestimte intrinsische Operationen mit Feldern und der Benutzung von Vektorregistern.
Nö, HPF ist allgemeingültig, ähnlich OpenMP.
Auch dem guten Compiler muss man helfen, wo man kann, z.B. mit Informationen.
Alles andere ist Unfug. Nochmals: Es geht nicht darum, dass sich Informatiker mit bestimmten Konzepten selbst verwirklichen. Es geht um das Ziel.
Wenn besagte Informatiker mit ihrer objektorientierten Konzeption einen spitzenmäßigen Compiler bauen, der dank zusätzlicher Informationen aus der Programmiersprache noch spitzenmäßigere Ergebnisse, sprich sauschnellen Code liefert, dann sind sie immer willkommen. In dem Compiler dürfen sie sich dann gerne mit C++ kombiniert mit Haskell-Extrakten, verfeinert mit OpenMP
- zwecks Test von noch mehr Optimierungs-Varianten - austoben.
Die wirklich guten Informatiker werden sich dann auch nicht daran stören, dass die BNF-Datei ihres lex/yacc/bison/whatever statt einer objektorientierten Syntax Fortran dekodiert. Die kommen dann vielleicht sogar und sagen: "Hey, ich hab' Dir noch das Sprachfeature eingebaut, wenn du hier im Kommentar diesunddas codierst, dann läuft Dein Programm dreimal so schnell und dank Kommentar-Pragma bleibt es portabel. Komm, wir zeigens dem Wettbewerb ..."
Das sind die Leute, die man braucht, nicht die, die einem irgendwelche Fensterheber im Formel 1 Auto aufoktroieren wollen ...
Da haben halt einige Leute auch nicht verstanden, wo das Ziel ist. Es geht hier nicht darum, dass einer seine "ich will open source bis zum letzten CPU-Microcode" Ideologie umsetzt. Aber genau so ein Mist wird gemacht.
Warum: Weil diese Leute nix anderes können. "Wer's kann, der machts, wer's nicht kann, der lehrts ..."
Der Knackpunkt ist, dass existierende (Desktop-) Computer neben elementarer Mathematik primär drei Dinge _schnell_ können:
- etwas irgendwie sortieren bzw. auf sortierte Daten schnell zugreifen ("Bäume" aller Art)
- etwas schnell indizieren im Sinne eines Hashs.
- Referenzen dereferenzieren.
Für diese Aufgaben reicht es, eine sauschnelle ausgefuchste CPU (oder auch zwei oder vier, aber eben nicht wirklich viele) mit großem, aber dummen und eigentlich auch nicht besonders schnellem (*) Speicher zu kombinieren.
Damit ist klar, dass für derartige Architekturen zwar grundsätzlich schon neue Algorithmen erdacht werden können, die sich aber immer in diesem Dunstkreis bewegen. Ich wage jetzt einfach mal ohne Beweis zu behaupten, dass die aus dieser Hardware-Konstellation erdenkbaren Algorithmen in ihrer Zahl zwar unendlich, aber in ihren Möglichkeiten sich in einem endlichen Raum ähnlich einer Kugeloberfläche ;-) bewegen.
Wenn man _real_ mehr will (und nicht nur theoretisch im Sinne einer sie_kann_alles_Touringmaschine), wird man nicht um neue Hardwarearchitekturen herumkommen.
Gruß Oliver
P.s.: (*) Wenn man genau hinsieht, dann haben wir zwar heute DDR2 DRAM mit ganz viel Speicherplatz, schnellen Bursts und imposanten goldenen Kühlkörpern, aber wirklich schneller als zu Opa's Zeiten ist der Random-Zugriff nicht geworden, und zwar noch nicht mal im Vergleich zu 64kBit Uralt-DRAMs. Es gibt zwar jetzt mehrere Bänke, aber nichtsdestotrotz braucht das Entladen der C's in die Leseverstärker immer noch fast genau so lange wie vor 20 Jahren. Die heutigen CPU's leben praktisch ausschließlich aus dem Cache, wird es wirklich _random_, dann ist es vorbei.
Der C++-Standard ist erstmal so gebaut, dass das mit "std::complex" genauso geht. Denn da hat der User nicht dran rumzufummeln. Wenn der Compiler also eine Multiplikation zweier Variablen vom Typ 'std::complex' sieht, kann er genau das gleiche tun, was er in Fortran mit den eingebauten Typen tun würde.
Dass das in der Praxis nicht gemacht wird schiebe ich (als Hobby- Compilerbauer) mehr auf den Markt. Number-Crunching wird in Fortran gemacht, weil es schon immer in Fortran gemacht wurde. In C machen wir Steuerung. Niemand außer Compilerbauern und Sprachadvokaten will Windkanäle in C++ simulieren.
Solche Mustererkennung ist aber Stand der Technik. Der VisualDSP- Compiler für Blackfin macht das z.B. bis zum Umfallen, und nutzt z.B. so abstruse Befehle wie R1 = R2 + R3, R4 = R2 - R3 (das ist *ein* Befehl, der noch mit zwei Loads oder einem Load und einem Store kombiniert werden kann und auch wird). Braucht man zufällig bei so Dingen wie MDCT. Seit ich mir den Assemblercode angeschaut habe, der da hinten rausfällt, seh ich gar nicht ein, warum ich meinen DSP-Kram in was anderem als C++ schreiben sollte. Schade, dass der gcc (den ADI meines Wissens eigentlich pushen wollte) noch nicht so weit ist.
Der Vorteil einer Mustererkennung ist dann, dass sie auch dann ein Muster erkennt, wenn im Originalquelltext was ganz anderes stand. Eine Drehung eines 2D-Punktes ist z.B. auch nix anderes als eine komplexe Multiplikation, ich würde nur vermutlich nicht auf die Idee kommen, das mit komplexen Zahlen aufzuschreiben.
Zumindest ich will niemandem irgendwas aufoktroieren. Ich will einfach endlich einen C++-Compiler haben, der beim Numbercrunching Fortran ebenbürtig ist. Leider haben meine Tage auch nur 24 Stunden, deswegen ist mein ultra-low-priority-Hobby-Compiler-Projekt erst beim Preprozessor angekommen und momentan in der Queue hinter einem schnöden Spielprogramm eingeordnet :-)
"Guido Grohmann" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net... MaWin schrieb:
Aber Guido, seit wann nennt man es trollen, wenn jemand die Wahrheit ausspricht ? Auch wenn sie dir unangenehm ist.
Oder ist Karlheinz Boehme etwa dein Pseudonym und gar nicht der Mitarbeiter von Mervisoft, der wohl irgendwas mit irgendeiner Software names Tric und PDFFactory und IntelliCAD zu tun hat?
Ich habe nicht gesagt, ich wüßte nichts von Windoze. Ich fürchte im Gegenteil, viel zu viel zu wissen. Wann immer ich das Pech hatte, mich mit Details von Windoze auseinandersetzen zu müssen, hatte ich danach Mordgelüste. Von der inakzeptablen Politik (in jeglicher Hinsicht) der Herstellerfirma ganz zu schweigen. Das Leben ist zu kurz um es mit so einem Mist zu vergeuden.
Und es gibt Alternativen. Genug.
Womöglich haben wir ja unterschiedliche Ansichten, wann Mathematik "höher" ist. Aber eine Aufwandsabschätzung für einen Algorithmus sollte ein Informatiker z.B. schon hinbekommen. Eine Aussage "Ich und Mathe - ein antagonistischer Gegensatz" paßt dazu nun wirklich nicht.
In den seltensten Fällen ist das *ein* Kopf. Meist sind es mehrere.
Genau. 2 oder auch 4 Semesterwochenstunden Programmieren. In der Zeit kann man gerade mal die Grundlagen einer Programmiersprache erklären. Wenn der Student Glück hat, kann er dieses Wissen irgendwann mal gebrauchen. Meistens hat er dieses Glück nicht, denn die Ansichten von Professoren und der Praktiker darüber, welche Programmiersprache sich für reale Probleme eignet, sind doch recht unterschiedlich.
Tatsächlich müßte er mindestens 3 Programmiersprachen lernen. Sagen wir mal C, Smalltalk und Haskell. In dieser Reihenfolge und jedesmal mit einem Praktikum mit mindestens einer Woche Programmierzeit (das entspricht dann einem Monat Gesamtzeit).
Ich hatte z.B. das "Glück" Modula-2 zu lernen. Wenn ich nicht schon BASIC und diverse Assembler-Dialekte gekonnt hätte, fakultativ C belegt hätte und mich in meiner Freizeit mit Turbo-Pascal und später C++ befaßt hätte (neben .BAT und später .sh .awk etc.) - an der Hochschule hätte ich nicht programmieren gelernt. Und als mir dann später ein jüngeres Semester Informatik sein C++ Skript zeigte, traten mir Tränen in die Augen. Das Skript "Theoretische Informatik" war hingegen nett.
Ich meine: ein Informatikstudium kann die Grundlage für eine Karriere im Informatik-Bereich legen. Aber es ist nur der Anfang. Danach kann man sich zum Powerpoint-Informatiker weiterentwickeln oder zum Programmierer. Die meisten schaffen leider nur das erste.
Du und ich wissen doch genau, daß interessante Software nicht auf Desktop-Maschinen läuft. Diese Maschinen verbringen 95% ihrer Zeit damit, auf den Benutzer zu warten. Deswegen ist ja die Stromaufnahme im idle-Mode des Prozessors auch so wichtig.
...
Jein.
Es stimmt natürlich, daß das Taktraten-Wettrennen sich momentan seinem Ende zu nähern scheint. Dito die brachiale Verbreiterung der Datenwege. Die Zukunft gehört ganz klar massiv parallelen Systemen. Das hat sogar Intel schon erkannt ;-) Leider scheint dieser Teil in der Praxis irgendwann bei ADA stehen geblieben zu sein.
Neue Algorithmen müssen aber nicht zwangsweise auf neue Typen von Hardware abzielen (spontan fallen mir da Quantencomputer ein). Im genannten Projekt ging es z.B. um die Zuverlässigkeit von Netzwerken aus unzuverlässigen Einzelteilen. Das Problem ist im allgemeinen Fall bewiesenermaßen NP-hard. Mit einigen zutreffenden Annahmen wie
- die Ausfallwahrscheinlichkeit einer Komponente liegt im unteren einstelligen Prozentbereich; und
- reale Netze enthalten vergleichsweise wenig Redundanz (mehr als 3 disjunkte Wege sind höchst selten)
lassen sich praktisch Algorithmen ableiten, die den Aufwand für "Näherungslösungen" (die nicht mehr als 1E-10 vom wahren Ergebnis abweichen, also praktisch "exakt" sind)) polynomial machen. Tatsächlich war das so frappierend viel schneller (Sekundenbruchteile statt Stunden) daß der Exponent über dem N nebensächlich wurde. Die Idee, unbedeutende Terme schon unterwegs wegzuschmeißen, wurde IIRC im Gespräch in der Kaffeerunde geboren.
Vor allem werden sie (Genoid Entwickler) mit ihrem digitalen Klumper't nie fertig.
Wie jemand sinnigerweise in diesem Thread erwähnte, daß Informatik Mathematik ist, kann die Biologie und Evolution nicht mit Mathematik erfasst werden. Die Mathematik kam erst später, nachdem sich unsere jetzige Körperform entwickelte ;) Die Behauptung Mathematik sei überall, ist nur mit und durch Theologie haltbar. Alles andre ist Neo-Moron (Atheistische Inquisitoren ;-)) Geschwafel für mich.
Na ja, so wie es Rennfahrer und Mechaniker gibt, gibt es Informatiker und Programmierer. Ob der sowie 'Schumi' auch die Technik könnte oder nicht, ist relativ.
|> Tatsächlich müßte er mindestens 3 Programmiersprachen lernen. Sagen |> wir mal C, Smalltalk und Haskell. In dieser Reihenfolge und jedesmal |> mit einem Praktikum mit mindestens einer Woche Programmierzeit (das |> entspricht dann einem Monat Gesamtzeit).
In etwa so läufts hier. Die Anzahl und Art der Sprachen hängt zwar etwas von den Vorlieben der Professoren ab, die die Einführungsvorlesungen machen, aber prinzipiell hat man bis zum fünften Semestern schon mal mindestens drei Programmier-Sprachen gesehen (und Assembler, Mikroprogrammierung und VHDL...) und auch programmiert. Oft gibts dann auch die etwas exotischeren, also Ocaml, Haskell oder auch mal Forth/Postscript. Ist also nicht so, dass die nur auf Buzzword-Java-Hacken getrimmt werden.
Das Problem sind aber die Anfangsvoraussetzungen: An sich darf/soll ein Student am Anfang nichts wissen müssen. Die Aha-Erlebnisse beim Vergleich der verschiedenen Sprachen kommen aber erst, wenn man eine schon richtig gut kann. Ich kann mich noch gut erinnern, wie ich auf einmal das Motif-Toolkit verstanden habe und dicke GUIs gebaut habe, weil es Scheme so "natürlich" zu nutzen war. Das Gewürge in C war mir vorher immer ein Rätsel geblieben...
Für richtig "ausführliches" Programmieren (und für die tiefgehenderen Vergleiche) ist aber meist keine Zeit. Schliesslich wollen die Verifizierer und Chomsky-*-Profs die Studis auch mal haben ;-) Andererseits ist es tw. auch so, dass die real existierenden Sprachen oft einigen theoretischen Ansätzen bzw. Wunschvorstellungen zuwiderlaufen und damit den Studenten "versauen". D.h. zuviel "Hacken" ist auch wieder schlecht. Mein Erstsemester-Prof hat sogar mal gemeint, dass im die Studis viel lieber sind, die noch nie was programmiert haben...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Du solltest versuchen, Dein OS in den Griff zu bekommen. Wir benutzeen Systeme, wo Sourcen eben *nicht* 'oft verloren gehen'. Wenn ich jetzt noch die Begriffe 'Repository' und 'Backup' in's Spiel bringe, bist Du vermutlich wieder eine Nacht am Googeln, was das denn nun bedeuten koennte.
So sahen BASIC Programme vor ca.25 Jahren aus; man kann sich auch weiter entwickeln.
MS C 5, Turbo C und Watcom C kannten es. Mir faellt jetzt kein Weiterer ein, aber ich habe persoenlich noch keine stdlib.h gesehen, wo diese Deklartion gefehlt haette.
Oh, danke!
Fuer Dich nochmal im Klartext zum Mitmeisseln: Wir diskutieren ueber _Softwareprojekte_. Da gibt es manchmal mehr als eine Person, die das Keyboard traktiert. Da ist das leichte Lesen des Codes immanent wichtig. Welches der beiden folgenden Beispiele (aus HELPDEC1.C) ist wohl leichter zu lesen und verstehen:
for(i=0;i
Zur Darstellung eines kurzen Sachverhalts in einem Dreizeiler in einem Lehrbuch ist das ja auch OK. In diesem Zusammenhang Herrn Wirth zu nennen, finde ich schon fast vermessen. Haettest Du den naemlich verstanden, so wuesstest Du, dass er sich fuer so wenig globale Variablen wie notwendig, Datenkapselung und Modularisierung der Sourcen ausgesprochen hat. Letztlich ist ja auch die Sprache Modula deswegen von ihm entwickelt worden. Diesen Mann als Zeuge fuer deine Machwerke zu benennen ueberschreitet schon die Grenze der Geschmacklosigkeit.
Und daraus leitest Du jetzt her, dass, je kuerzer die Variablennamen, desto besser der Code?
Bruuuhahahaha
Merkwuerdigerweise konnte ich schon vieles, was ich in meiner Laufbahn in die Tastatur gehauen habe, in anderen Projekten auch verwenden. Was ist da wohl schief gelaufen?
Jeder der mich kennt wird Dir bestaetigen, dass es gewagt ist, mich den 'uniformierten Leuten' zuzuordnen, und 'theoretischen Geschwaetzes' hat mich bisher noch niemand geziehen. Objektorieniert wird dort genutzt, wo es Vorteile bringt.
Ich glaube nicht dass mein Arbeitgeber damit einverstanden waere, unsere Sources in's Netz zu stellen. Die letzten Sources welche ich seinerzeit noch privat geschrieben habe sind vor 3 Monaten mitsamt den zugehoerigen 5 1/4 Zoll Disketten bei der Muellverwertung gelandet.
Du kennst mich nicht, deshalb lass ich Dir den Theoretiker durchgehen (ich bin schon schlimmer beleidigt worden). Dass Microsoft die Sourcen von Windows veroeffentlicht haette, habe ich gar nicht mitbekommen; aber Du wirst uns sicher die URL der offiziellen MS download Site bekannt geben.
Zu Beginn unseres Projekts haben wir zu fuenft codiert. Das was ich hier zum Besten gegeben habe beruht auf _Erfahrung_.
Ich glaube nicht, dass sich jemand an mich ranhaengen braucht; auch nicht sabbernd :-)
"Georg Acher" schrieb im Newsbeitrag news:enhej8$7b7$ snipped-for-privacy@news.lrz-muenchen.de...
So hat's bei mir 1/2 Jahr gedauert, bis es bei Lisp Aha gemacht hat, und die Programme ploetzlich 1/10 so lang und 10 mal so schnell waren.
Kein Wunder, er wird selber nie was ordentliches programmiert haben, und deren Loesungen nicht verstehen. So was habe ich mehr als 1 mal erlebt, bei Jung-Studenten aus dem Bekanntenkreis, besonders schlimm Wolfenbuettel und Ilmenau.
Ja, eben. Eine Programmiersprache mit ihren Stärken und Schwächen lernt man nicht kennen in der Vorlesung. Dazu muß man schon mal ein praktisches Problem damit lösen.
Ich würde sagen, alle Programmiersprachen, die ich so gut erlernt habe, daß ich sie jetzt praktisch verwende, habe ich gelernt indem ich ein Problem angegangen bin, für das diese Sprache offensichltich gut geeignet war (zumindest besser als das, was ich vorher schon konnte).
Die Motivation für C war: "die großen UNIX-Hobel, die nicht mit 64K- Segmentierung nerven, spechen kein TP sondern C". Bei C++ wars dann "ich brauch assoziative Arrays und will komfortabel mit Bignums und Polynomen rechnen können". Mit Ruby habe ich nur mal ein bisschen gespielt, weil es so nett und sauber ist. Allerding löst es keines meiner Probleme besser als Perl (das ich schon kann). Folgerichtig spielt Ruby keine Rolle in meinem Programmieralltag.
Dafür gibts verschiedene Gründe. Zum einen besteht halt die Gefahr, daß die Studenten auf einigen Spezialgebieten mehr wissen als der Prof. Zum anderen ist ein uneinheitliches Niveau schlecht für den Lernerfolg der Gruppe als Ganzem. Offiziell war das der Grund, warum ich Modula-2 lernen mußte. Die Sprache war damals (und heute?) praktisch nicht verbreitet, so daß alle Studenten gleich wenig darüber wußten.
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.