Moderne Programmiersprachen, 64KB Limit?!
- Ersteller darktrym
- Erstellt am
Ich bin grad dabei ein uralt(kryptisch & haufenweise gotos) C Programm, vormals Fortran, in die Moderne zu bringen, sprich Java(7). Dabei stiess ich auf folgendes Problem:
Ursache, ach ihr könnt' das selbst nachlesen, modernes Java,.
Das ist zwar hässlich, aber eines der kleineren Übel von Java, um das man zudem leicht herumarbeiten kann.
Richtig böse sind z.B. die Datum-APIs (lässt sich mit Joda-Time inzwischen weitestgehend vermeiden) oder der Mangel an vorzeichenlosen Ganzzahltypen (die Workarounds dafür sind immer eklig).
Das Schlimmste an Java ist aber, dass es trotz seiner zahlreichen Schwächen für sehr viele Anwendungen immer noch das geringste Übel ist.
darktrym
Fahnenträger
Wer kommt denn auf solche Ideen?
Sollen die Beschränkungen dazu führen, dass man seinen Code überarbeitet oder dachten die Designer der Sprache wirklich, es würde Anwendungsfälle geben, wo dies Vorteile bringt?
Das vorletzte Mal als sowas gesehen habe, war zu Turbo Pascal Zeiten, jaja die wilden 90er.
Sollen die Beschränkungen dazu führen, dass man seinen Code überarbeitet oder dachten die Designer der Sprache wirklich, es würde Anwendungsfälle geben, wo dies Vorteile bringt?
Das vorletzte Mal als sowas gesehen habe, war zu Turbo Pascal Zeiten, jaja die wilden 90er.
Ich bin in den Jahren, den ich diesen Job mache, zu dem Schluss bekommen, dass es bei allen Dingen (Programme, Programmiersprachen, Computerarchitekturen, etc) eigentlich immer drei unterschiedliche Typen gibt:
1. Elfenbeintürme. Eine oder mehrere Personen setzen sich hin und überlegen, wie Dinge sein sollten. Anschließend implementieren sie diese, stellen sie der Welt vor. Problematisch ist, dass solche Dinge meist auf theoretischer Ebene wunderbar sein mögen, aber praktisch nur sehr begrenzt sinnvoll. Bei den Programmiersprachen ist Pascal eines der erfolgreicheren Beispiele, Sprachen wie Oberon eher wenig erfolgreich.
2. Unfälle der Geschichte. Alle Projekte, die mal als kleine Frickelei begannen und entgegen der Vorstellungen des Entwicklers aus verschiedenen Gründen sehr erfolgreich wurden. Als Folge sind sie in ihren grundlegenden Dingen meist murks, die nächste Ewigkeit verbringt man dann damit drum herum zu fummeln. Das kann gut enden, wie es z.B. bei Unix der Fall war oder die Sache auch eher schlimmer machen, wie bei C++.
3. Logische, pragmatische Fortentwicklungen. Einige Praktiker haben die Schnauze vom Vorhandenen satt und entwickeln etwas Neues, was sich nahe am Vorhandenen orientiert, seine Fehler aber nicht wiederholt. Als Beispiel haben wir da C# oder amd64 als Versuch x86 brauchbar zu machen.
Java bewegt sich irgendwo zwischen allen 3 Punkten. Man wollte Dinger besser als das damals noch junge und viel mehr als heute verkrüppelte C++ machen. Man hatte die Freiheit in einem Büro zu sitzen und sich ohne Druck austoben zu können. Vor allem aber richtete sich Oak an irgendwelche Embeddedanwendungen, dass es mal große Businesssysteme antreiben würde, dachte niemand. Das führte dazu, dass Java auf der einen Seite durchaus eine schöne und runde Sache war / ist, auf der anderen aber auch relativ Realitätsfern war. Daher hat man angefangen zu frickeln, statt zu interpretieren machte man auf einmal JIT ohne die interne Architektur entsprechend anzupassen, bastelte halbherzig an der immer größer werdenden Standardbibliothek herum... Vor allem aber traute man sich dank halbherziger Rückkompatiblität nie, mal grundlegende Dinge anzupacken. Zur Sache mit den signed / unsigned Typen habe ich schon diverse, nahe von Ausreden einzustufende Begründungen gelesen. Mehr als 256 Parameter sind schön, aber verlangt sicher Eingriffe in die Laufzeitumgebung oder so. Gleiches gilt dann auch für die maximale Länge von Methoden.
Aber sind wir ehrlich. Das ist weder die Schuld der Entwickler (die nie vorhersehen konnten, was aus Java mal werden wird), noch der Manager (die wollen ein Produkt verkaufen und müssen neben neuen Funktionen auch Rückkompatiblität liefern) und schon gar nicht der Anwender (die nur was in Java bauen wollen), stattdessen das Ergebnis einer gewissen Eigendynamik. Die trifft im Prinzip jedes erfolgreiche Produkt, angefangen bei Java, über Linux und BSD, bis hin zu x86. Entweder erneuert dann irgendwann jemand die ganze Sache, wenn das Leid zu groß wird (amd64, FreeBSD 5, etc.) oder Punkt 3. von oben folgend kommt halt was neues, potentiell Besseres. Bei Java geht der Trend evtl. in Richtung Erneuerung, aber das ist schwer zu sagen.
1. Elfenbeintürme. Eine oder mehrere Personen setzen sich hin und überlegen, wie Dinge sein sollten. Anschließend implementieren sie diese, stellen sie der Welt vor. Problematisch ist, dass solche Dinge meist auf theoretischer Ebene wunderbar sein mögen, aber praktisch nur sehr begrenzt sinnvoll. Bei den Programmiersprachen ist Pascal eines der erfolgreicheren Beispiele, Sprachen wie Oberon eher wenig erfolgreich.
2. Unfälle der Geschichte. Alle Projekte, die mal als kleine Frickelei begannen und entgegen der Vorstellungen des Entwicklers aus verschiedenen Gründen sehr erfolgreich wurden. Als Folge sind sie in ihren grundlegenden Dingen meist murks, die nächste Ewigkeit verbringt man dann damit drum herum zu fummeln. Das kann gut enden, wie es z.B. bei Unix der Fall war oder die Sache auch eher schlimmer machen, wie bei C++.
3. Logische, pragmatische Fortentwicklungen. Einige Praktiker haben die Schnauze vom Vorhandenen satt und entwickeln etwas Neues, was sich nahe am Vorhandenen orientiert, seine Fehler aber nicht wiederholt. Als Beispiel haben wir da C# oder amd64 als Versuch x86 brauchbar zu machen.
Java bewegt sich irgendwo zwischen allen 3 Punkten. Man wollte Dinger besser als das damals noch junge und viel mehr als heute verkrüppelte C++ machen. Man hatte die Freiheit in einem Büro zu sitzen und sich ohne Druck austoben zu können. Vor allem aber richtete sich Oak an irgendwelche Embeddedanwendungen, dass es mal große Businesssysteme antreiben würde, dachte niemand. Das führte dazu, dass Java auf der einen Seite durchaus eine schöne und runde Sache war / ist, auf der anderen aber auch relativ Realitätsfern war. Daher hat man angefangen zu frickeln, statt zu interpretieren machte man auf einmal JIT ohne die interne Architektur entsprechend anzupassen, bastelte halbherzig an der immer größer werdenden Standardbibliothek herum... Vor allem aber traute man sich dank halbherziger Rückkompatiblität nie, mal grundlegende Dinge anzupacken. Zur Sache mit den signed / unsigned Typen habe ich schon diverse, nahe von Ausreden einzustufende Begründungen gelesen. Mehr als 256 Parameter sind schön, aber verlangt sicher Eingriffe in die Laufzeitumgebung oder so. Gleiches gilt dann auch für die maximale Länge von Methoden.
Aber sind wir ehrlich. Das ist weder die Schuld der Entwickler (die nie vorhersehen konnten, was aus Java mal werden wird), noch der Manager (die wollen ein Produkt verkaufen und müssen neben neuen Funktionen auch Rückkompatiblität liefern) und schon gar nicht der Anwender (die nur was in Java bauen wollen), stattdessen das Ergebnis einer gewissen Eigendynamik. Die trifft im Prinzip jedes erfolgreiche Produkt, angefangen bei Java, über Linux und BSD, bis hin zu x86. Entweder erneuert dann irgendwann jemand die ganze Sache, wenn das Leid zu groß wird (amd64, FreeBSD 5, etc.) oder Punkt 3. von oben folgend kommt halt was neues, potentiell Besseres. Bei Java geht der Trend evtl. in Richtung Erneuerung, aber das ist schwer zu sagen.
VAX (wurde immerhin bis ins Jahr 2000 verkauft) speichert die Anzahl der Methodenparameter in einem 8-bit-Register; bei 0xFF ist halt Schluss.
Ein Limit gibt es selbst im Standard von C (127 Parameter) und C++ (wie Java 255 Parameter).
oenone
Well-Known Member
Dort sind es Minimalanforderungen. Bei C ab C99 übrigens auch 255.
Korrekt. Wer portablen Code generieren möchte, sollte also tunlichst diese Minimalanforderung nicht überschreiten.
ISO/IEC 9899:1999 (E) §5.2.4.1 Absatz 1 Stichpunkt 11 schrieb:
Zudem sind diese Minimalforderungen in hinreichend nutzloser Form gefordert:
Auf deutsch: Es gibt keine Garantie, dass ein beliebiges beliebig kleines Programm erfolgreich übersetzt wird. Der Übersetzer muss es nur für ein einziges (von ihm bestimmtes) Programm schaffen.ISO/IEC 9899:1999 (E) §5.2.4.1 Absatz 1 schrieb:
Der einzig sinnvolle Satz in dem Abschnitt ist die Fußnote:
ISO/IEC 9899:1999 (E) §5.2.4.1 Fußnote 13 schrieb:
C++11 und C11 sind in ihren Forderungen jeweils zu ihren Vorgängern inhaltsgleich.
Unterm Strich geben also weder C noch C++ irgendwelche verlässlichen Minima an.