[Projekt] Type Research Programming Language

[Lord Delvin]

Gerade zum Debuggen eines Tests gebaut:

Code: Alles auswählen

  type def print(this : int) : void {
    var format = new CString("%i\n");
    printf1i(format, this)
    delete format
  }

  type def printf1i (format : CString, value : int) : int extern c.printf

  type def dump {
    "Upper "!!; print(Upper.instances)
    "Lower "!!; print(Lower.instances)
  }

Ich sag' mal die Standardbibliothek hat noch sehr niedrig hängende Früchte, was Usability und neue Features angeht :-/
Man merkt das R im Namen eben doch sehr deutlich, wenn man was damit produktiv macht.

[x1m4]

Wonach kompilierst du denn, direkt Assembler? Imo die größte Hürde im Compilerbau ist die Optimierung, da hättest du große Vorteile wenn du z.B. nach LLVM IR oder so kompilierst. Da hast du dann fertige Werkzeuge zum optimieren und "quasi" Plattformunabhängigkeit oben drauf.

[Lord Delvin]

Also die größte Hürde ist es nicht mehr, aber ja ist LLVM IR.
Die Abstraktionsebene der LLVM IR Funktionsrümpfe und der TIR Funktionsrümpfe unterscheidet sich bis auf Typinformationen nicht mehr wirklich, d.h. es würde keinen Sinn ergeben Zeit zu investieren und sich selbst mit Lowering und Optimierungen auseinanderzusetzen.

Die Hürde mit der ich mich hier auseinandersetze sind eigentlich rekursive Templates und anderes Zeug das sich in deren Dunstkreis dann ergibt.
Keine Ahnung ob sich daraus dann mal eine produktiv nutzbare Sprache ergibt oder ob die Ideen woanders eingebaut werden. Wäre mir gleich.
Allerdings sehe ich momentan nicht, welche größere Sprache die Ideen übernehmen kann, da sich daraus relativ weitreichende Konsequenzen ergeben.

Ich hab' mal angefangen ein paar Tutorials zu schreiben, einfach damit es was gibt, ich mich selbst an was orientieren kann und ich sehe, wie ich die Sprache selbst gerne verwenden würde. Wenn die fertig sind gibt's auf jeden Fall noch ein Bugfix Release :)
Man merkt einfach worauf ich wert gelegt habe und was es jetzt einfach gibt, damit man langsam mal was damit machen kann.

[Lord Delvin]

Bin mit Tutorials und Bugfix Release durch: https://github.com/tyr-lang/releases/re ... tag/v0.6.1

Die Tutorials zu schreiben hat die ganze Sache auf jeden Fall etwas runder gemacht.
Man hat einfach gemerkt, dass die Standarbibliothek viel zu dünn ist, um nennenswert was damit zu machen.
Eigentlich gab es ja nur den ganzen Array-Container-Teil mit dem ich die ganzen rekursiven Templateeigenschaften testen wollte.

Vermutlich kann man das ganze Projekt ab der nächsten Version dann offensiv bewerben.
Mal schauen wie lange ich bis dahin brauche.

[Lord Delvin]

Irgendwie ist mir beim Implementieren der Standardbibliothek aufgefallen, dass ich all die Jahre kein break und continue eingebaut hatte. Nachgedacht, zwei Stunden hingesetzt, getestet, läuft jetzt. Kommt mit dem nächsten Release :)

Ich kann einfach nicht nachvollziehen, warum es nicht gelingt bei professioneller Softwareentwicklung Zeit in eine saubere Codebasis und Architektur zu stecken. Dass sich Anforderungen ändern kann nicht das Argument sein, da das bei meinem Forschungsprojekt ja auch so ist.

[Alexander Kornrumpf]

Irgendwie ist mir beim Implementieren der Standardbibliothek aufgefallen, dass ich all die Jahre kein break und continue eingebaut hatte. Nachgedacht, zwei Stunden hingesetzt, getestet, läuft jetzt. Kommt mit dem nächsten Release :)

Ich kann einfach nicht nachvollziehen, warum es nicht gelingt bei professioneller Softwareentwicklung Zeit in eine saubere Codebasis und Architektur zu stecken. Dass sich Anforderungen ändern kann nicht das Argument sein, da das bei meinem Forschungsprojekt ja auch so ist.

Ich bin überzeugt, dass die meisten "professionellen Softwareentwickler" schlicht keine besonders guten Programmierer sind. Das wird nicht der einzige Grund sein, aber "sie können es nicht besser" ist bestimmt eine Komponente.

[Schrompf]

Irgendwie ist mir beim Implementieren der Standardbibliothek aufgefallen, dass ich all die Jahre kein break und continue eingebaut hatte. Nachgedacht, zwei Stunden hingesetzt, getestet, läuft jetzt. Kommt mit dem nächsten Release :)

Ich kann einfach nicht nachvollziehen, warum es nicht gelingt bei professioneller Softwareentwicklung Zeit in eine saubere Codebasis und Architektur zu stecken. Dass sich Anforderungen ändern kann nicht das Argument sein, da das bei meinem Forschungsprojekt ja auch so ist.

Ich würde eher vermuten, dass professionelle Softwareentwicklung nen größeren Umfang und echte User hat.

[Alexander Kornrumpf]

Ich würde eher vermuten, dass professionelle Softwareentwicklung nen größeren Umfang und echte User hat.

Harsch, aber ist natürlich auch richtig. Sieht aus als hätte der Threadersteller das hier alleine gebaut, das macht ja viel aus. Wenn du erstmal 10+ Jahre Legacy hast und der größere Teil der Codebase von Leuten kommt, die nicht mehr in der Firma sind, sieht die Welt natürlich ganz anders aus.

Aber die eigentliche Frage ist, wieso schaffen wir es als Industrie immer noch aus dem "diesmal aber echt in schön" Greenfield-Projekt das nächste "unwartbare" Legacy-Projekt werden zu lassen. Irgendwo muss da ja was schief gehen, was durch Umfang und User eigentlich nicht zu erklären ist.

Das gesagt habend mach ich ganz gerne Legacy. Ich glaube die Leute die immer nur Greenfield machen wollen, sind Teil des Problems und nicht der Lösung.

[Schrompf]

Ja, war ein bissl grob, sorry. Aber es stimmt halt. Die Menge an realen Zwängen, denen man im Alltag unterliegt, ist halt amtlich. Ich hab nur selten ein "ich mach neues Feature und refactore dafür X und Y, damit sich das elegant integriert" und dafür sehr oft "Wir brauchen ne Ausnahme für Kundin ABC" oder "Die Spec sagt zwar X, aber wir kriegen seit ner Woche Daten mit Y" oder auch "Angeblich timeouted ne TCP-Verbindung, aber bei uns irgendwie selbst nach ner Stunde nicht, und das hat letztens ein Drittel aller Agents auf jedem Server für nen Zombie reserviert. Wir müssen uns jetzt was überlegen, wie wir tote Clients erkennen".

Ist halt Tagesgeschäft. Sowas kannst Du nur vermeiden, indem Du halt kein Tagesgeschäft hast.

[Lord Delvin]

Ja, war ein bissl grob, sorry. Aber es stimmt halt. Die Menge an realen Zwängen, denen man im Alltag unterliegt, ist halt amtlich. Ich hab nur selten ein "ich mach neues Feature und refactore dafür X und Y, damit sich das elegant integriert" und dafür sehr oft "Wir brauchen ne Ausnahme für Kundin ABC" oder "Die Spec sagt zwar X, aber wir kriegen seit ner Woche Daten mit Y" oder auch "Angeblich timeouted ne TCP-Verbindung, aber bei uns irgendwie selbst nach ner Stunde nicht, und das hat letztens ein Drittel aller Agents auf jedem Server für nen Zombie reserviert. Wir müssen uns jetzt was überlegen, wie wir tote Clients erkennen".

Ist halt Tagesgeschäft. Sowas kannst Du nur vermeiden, indem Du halt kein Tagesgeschäft hast.

Also ich glaube bezogen auf dieses Projekt es ist ein bisschen von beidem; ich habe sehr viel Erfahrung in dem Bereich und nehme mir die Zeit alles so zu bauen, wie es eigentlich sein müsste. Die Sachen, die ich vor zehn-fünfzehn Jahren gebaut habe wären in so einem Szenario auch nicht besser geworden als das, was ich an guten Projekten professionell erlebe. Ist in der Ecke eher mein zehntes als mein erstes Projekt.

Den Teil mit dem Greenfield, "sie können es nicht besser" und den Ausnahmen sehe ich auch so. Bei den Ausnahmen muss man halt hart bleiben; halte ich aber auch nicht immer durch. Das kannst du auch nur, wenn dir deine Umgebung vertraut, dass deine Härte nicht Verbohrtheit, Faulheit oder Irrglaube ist. Und einen Ruf, der dich um einen Releasezwang entlastet, muss man sich in der Regel auch erst erarbeiten. Das braucht man aber, wenn man Code in einer brauchbaren Qualität ausliefern möchte. Genauso braucht man eine Umgebung, in der man die ganzen kaputten Zwischenlösungen auch wieder rückbauen kann, weil man sonst eben schnell in genau der Situation ist, die wir vermutlich alle kennen, selbst wenn man es eigentlich besser wüsste.

Den Teil mit dem Umfang sehe ich nicht so; meine Erfahrung ist, dass das hier etwa so groß ist, wie das was professionell ein Zehnerteam aus Durchschnittskräften macht. Erstaunt mich selbst immer wieder. Letztlich unterschätzt man aber einfach, wie viele tausend Codezeilen es erfordert, sowas wie f[x](y) zu verarbeiten, wenn die Typtheorie halbwegs interessant ist.
Ich meine in manchen Sprachen dürfen Typparameter nicht die Typen anderer Parameter sein, also z.B. Box[T : Type, Initial : T] (bzw. mit <> in C++). Man kann da auch den statischen Typ eines Laufzeitklassenparameters als Rückgabetyp einer Funktion verwenden, wie z.B. beim Checked-Cast-Operator in Class: public type def ! (this : Class, ref : Object) : this
Oder man hat das eben wie in C++, dass man keine Prüfung bekommt und templates auch nicht einfach aus dlls oder Äquivalenten davon lesen kann.
Ein Teil der Wahrheit zu dem Projekt ist sicher auch, dass viele der Probleme, die ich da bearbeite, zu den komplexesten zählen, die ich kenne und mich die Herausforderung reizt. Deswegen ist die Standardbibliothek auch so mikrig; das wäre halt vor allem Arbeit.
Und man muss halt auch sehen, dass ich den wirklich komplexen Teil als Postdoc gebaut habe und nie was publiziert habe, weil ich nicht musste, weil es nur sehr viel Zeit gekostet hätte und weil ich es eh nie auf eine Professur geschafft hätte.

Außerdem arbeite ich seit über einem Monat an Funktionstemplates, um sie so hinzubekommen, wie ich mir das vorstelle. Da sind so kleine Erfolge zwischendurch motivierend :)

Und ich glaube was hier noch fehlt: Ich mache keinen Support. Wirklich keinen. Das hängt zwar ein bisschen an keiner nutzt das, ist für mich aber ein anderer Aspekt, weil ich auch bei guten Profis sehe, wie viel ihrer Zeit einfach von Lastlevel-Support aufgefressen wird.

Professionell mache ich auch lieber Legacy als Greenfield. Ich habe auch schon 10+ Jahre Legacy-Projekte gesehen, die eigentlich dieselbe Qualität hatten, wenn man mal verstanden hatte, worum es eigentlich geht. Wenn das so ist, haben die meistens aber auch einen enormen funktionalen Umfang. Nicht zu vergleichen was z.B. meine Bank in meinem Onlinebanking vor meinen Augen abzieht. Wo man einfach Wochenlang daran scheitert Nachrichten ordentlich auszuliefern und dann stolz darauf hinweist, dass man sie jetzt in vier Tabs sortiert hat...egal, gehört hier nicht hin :)

[Krishty]

Aber die eigentliche Frage ist, wieso schaffen wir es als Industrie immer noch aus dem "diesmal aber echt in schön" Greenfield-Projekt das nächste "unwartbare" Legacy-Projekt werden zu lassen. Irgendwo muss da ja was schief gehen, was durch Umfang und User eigentlich nicht zu erklären ist.

Entropie? Es gibt mehr Möglichkeiten, ein Projekt zu verkacken, als es wartbar zu machen?

Konkret: Ich sehe „schreibe das wartbarste Programm, das X tut“ (mir ist klar, dass wir nicht das Superlativ suchen, sondern halbwegs wartbar auch reichen würde, but bear with me) als leichte Umformulierung von „finde das kürzeste Programm, das X tut“ (man zählt halt die internen Regeln für Veränderungen dazu).

Letzteres ist ein bekanntes Problem in der Datenkompression -- „Finde die kürzeste Repräsentation, die den Dekompressor die Datei X erzeugen lässt“ beschreibt jeden Kompressionsalgorithmus ever.

Aber auch in jeder Wissenschaft -- „Finde das kürzeste Regelwerk, das den Zustand eines Systems in der Gegenwart in den Zustand in der Zukunft umwandelt“ beschreibt jede Wissenschaft ever (bemerkt, dass Occam’s Razor impliziert ist).

Die kürzeste mögliche Repräsentation eines Programms ist die Kolmogorov-Komplexität, und IMHO ist sie eines der faszinierendsten Phänomene der theoretischen Informatik. (Weshalb sie hier auch mein Hammer ist und alles andere ein Nagel.)

Das Ding ist: Die Kolmogorov-Komplexität ist nicht berechenbar. Like, so unberechenbar, dass es nicht einmal eine Lösung geben kann für „Ich habe 2 Jahre diesen Algorithmus zurechtgestutzt; ist seine Kolmogorov-Komplexität minimal oder könnte man theoretisch noch einen kürzeren schreiben, der genau so funktioniert?“

Die Erkenntnis daraus ist, dass es keinen Algorithmus gibt, der dich zu einem optimalen Datenkompressor führt. Ebenso kann es keinen Algorithmus geben, der dich zur Weltformel führt. Oder einen, der dir sagt, wie du ein Neuronales Netz optimal trainieren kannst.

Zugleich gibt es unendlich viele Programme, die dich zur Lösung führen, aber mit beliebig viel Umweg. Ich kann schließlich jedes funktionierende Programm auf unendlich viele Weisen verkomplizieren und habe das gleiche, aber schlechter wartbar. [citation not needed]

Ich würde sagen, dass es deshalb auch kein Regelwerk geben kann -- weder sozial noch sonstwie --, das dich die interne Komplexität eines Projekts minimieren lässt, und damit den Wartungsaufwand. Wir sind da auf Ad-Hoc-Initiative und Erfahrung angewiesen. Bei einem Ozean aus Entscheidungen, die uns zu schlechtem Code führen (siehe Schrompfs Beispiele) und einer kleinen, nicht bestimmbaren Menge von Entscheidungen, die uns näher ans Optimum bringen, stehen unsere Chancen einfach nicht gut.

Ich sehe die Eingangsfrage mittlerweile ähnlich naiv wie „Wenn man die Weltformel haben will, warum gibt man nicht alles, was man über Physik weiß, in einen Computer ein und lässt ihn sie ausrechnen?“

(Entschuldige den Thread-Hijack, Lord Delvin; ich lese halt immer mit. Entschuldigt auch, falls meine Antworten wieder Monate dauern. Ich darf nicht immer so viele Mittagspausen opfern)

[Alexander Kornrumpf]

Es gibt einen sehr großen Unterschied dazwischen, nicht im Allgemeinen sagen zu können ob ein Programm das kürzeste ist und es nicht für ein bestimmtes Programm sagen zu können. Wenn ein Programm z. B. zwei Kopien von printf enthält um zwei Zeilen zu printf-n dann kann man sofort sehen, dass es ein kürzeres Programm gäbe was dasselbe tut. _Das_ ist das Niveau auf dem die Industrie sinngemäß operiert. Wir sind nicht an der Grenze des theoretisch möglichen und nach deinen sonstigen Postings zu urteilen, weißt du es auch.

Ja, es ist schwer das in eine Regel zu gießen. Weil es das Gegenteil ja auch gibt: zwei Methoden durch ifs zu einer bastardisiert. [Bin nicht sicher ob ihr das kennt, und versteht was ich meine.]

Wieso, fragt sich der geneigte Junior, sagt mir Alex im selben Review, ich soll hier eine Methode rausziehen, aber dafür diese andere Methode inlinen [also richtig die zwei Fälle ausschreiben, nicht dem Compiler sagen er soll es inlinen]. Dass sich das widerspricht wenn man sehr naiv dran geht ist aber nicht der Punkt. Der Punkt ist dass Alex halt mit einigermaßen guter Treffsicherheit vorher sehen kann, wie das Ergebnis aussehen wird. Trotz Kolmogorov.

Und natürlich, manchmal machst du das Refactoring und das Ergebnis ist weniger schön als erwartet (siehe sinngemäß anderer Thread mit dem fehlgeschlagenen SSE). Meistens hast du dann dabei was gelernt. Mal hat man Glück, mal hat man Pech. Aber dass man einfach gar nichts besser machen könnte, weil das Universum sowieso den Hitzetot stirbt stimmt halt nur für Zoomstufen für die ich nicht bezahlt werde.

[Lord Delvin]

In gewisser Weise passt hier hin, weil es eigentlich die Frage beantwortet, warum ich nicht mehr Werbung mache und warum ich mit meinen Änderungen so schnell bin. Momentan ist, durch die fehlenden User eigentlich nichts in Stein gemeißelt. Ich habe z.B. bei den Switches einen Fehler gemacht, der zu unnötigen Mehrdeutigkeiten führt, den ich jetzt einfach noch beseitigen kann, weil sich niemand beschweren wird.
Genauso das mit dem inline/split habe ich gerade auf Datentypebene in der IR bei den Templatedatentypen erlebt. Tatsächlich sogar direkt zweimal hintereinander, weil ich beim ersten Umbau beim Umbauen dann plötzlich zeigen konnte, dass meine Annahmen über die Verwendung falsch waren (im Prinzip Alex' Erfahrung, nur als Fehlschlag).

Was ganz gut funktioniert ist, die wahrgenommene Realität akkurat abzubilden. Gerade bei Problemen die man tagtäglich so hat. Da ist ein Optimum bzgl. Kolmogorov-Komplexität auch oft nicht gefragt. Ich meine da werden oft Sachen nicht gemacht, wo man locker eine Größenordnung kosten sparen würde, wenn man von den Optimierungen selbst nicht ausreichend profitiert oder wenn man glaubt, dass nur noch einer im Team den Code verstehen würde.

Das Problem, und da kommen wir jetzt zum Thema zurück, ist, dass man in einer Programmiersprache, wenn man mal angefangen hat, Nutzer zu haben, eigentlich den Bestand in Stein meißelt. D.h. an dem Punkt kann man nur noch erweitern, aber nicht mehr umbauen. Das ist halt blöd, wenn man irgendwas braucht, das vielleicht nur ein Promille des Codes betrifft, aber eben für sowas wie die Typisierung von Iteratoren oder Views erforderlich ist. Ich glaube ich würde das Projekt lieber bis zu meiner Rente alleine weitertreiben und kaputte Wechselwirkungen beseitigen können als es gleich zu Releasen, zu Oversellen und dann alle sechs Wochen mit der nächsten korrupten Makrokategorie als Teillösung um die Ecke zu kommen. Ich will dieses Release Templates und Generics kombinieren und ich glaube nicht, dass das mal jemand so gemacht hat; ich glaube auch nicht, dass ich das auf den ersten Wurf so hinbekomme, dass ich nicht noch zweimal irgendwas gravierendes ändern muss.

@Kristy passt schon; ich lese auch viel mehr, als ich kommentiere. Ich meine wenn Leute das in ihrer Mittagspause unterhaltsam fänden könnte ich auch öfter was aufschreiben, an dem ich gerade arbeite. Bei einigen Designfragen fehlt mir auch echt irgendwie ein sinnvolles Forum, um da was diskutieren zu können, seit ich nicht mehr an der Uni arbeite. Wahrscheinlich wäre es sogar ausreichend hilfreich, wenn ich meine Gedanken für andere nachvollziehbar aufschreibe, um den Aufwand zu rechtfertigen.

EDIT: HAHAHAHAHA: https://www.heise.de/hintergrund/Progra ... ag.beitrag

[Krishty]

Danluu hat eine tolle Liste mit Dingen, die Software-Entwicklung verbessert haben:

So here's the important calibration: what things HAS the software trade adopted more broadly than TDD [Test-Driven Development], and why? Could the problem just be that getting *anything* into widespread use is extraordinarily hard?

Only thing I can think of is version control

Answers to this will be highly dependent on your estimate of TDD uptake, but here are a few practices that seem more widely adopted to me (scoped to relevant developers, so something like distributed tracing would only be among operators of distributed systems at scale):

unit testing, CI, package managers, GC languages, REPLs, staged deploys, using DBs in place of flat files, JSON, protobuf et al., serverless precursors at the time (Heroku, etc.), current serverless, distributed tracing, metrics and dashboards, any kind of type safety beyond C,

basically every single security measure in use today other than just having passwords (recall that the "smashing the stack" article was written in '96 and it was trivial to own basically any software or company at the time and the timeframe GPH gives starts in '95),

the treatment of ops as first-class and everything that followed from that, whether you want call that DevOps or SRE or anything else, having a build that mostly works, (recall that MS used to have a process where builds didn't work most days; https://danluu.com/microsoft-culture/),

high-cadence releases (recall that MS used to have a process where merging into head took days), package management, hermetic builds, incremental build caching, real symbol-based syntax highlighting / refactoring that requires a compiler in the loop, IDEs, ORMs, bug tracking,

VCS with multi-file commits (not supported by RCS!), VCS where merging generally works (arguably not common until git), monorepos, distributed version control, ECC RAM, ECC at rest, encrypted communications, backing up at all, distributed backups, multi-monitor setups for devs,

use of laptops for devs, immutable X, autoformat tools, etc.

I'm going to stop here since my full list would be > 10x this long and this seems like more than enough to demonstrate that TDD isn't just a victim of new practice uptake being nearly impossible.

[Alexander Kornrumpf]

Ich erinnere mich noch gut, muss so gegen 2006 gewesen sein, da war ich mit einem Kommilitonen bei der "Java User Group Cologne" zu einem "IDE Shootout". Sun war noch ein Ding und Sun dachte noch das Netbeans ein Ding sein könnte. Jedenfalls Netbeans und Eclipse hatten "Evangelisten" geschickt - I shit you not, das war der Jobtitel - also glorifizierte Verkäufer. JetBrains - ich verstehe jetzt erst beim Tippen, dass der Name sich satirisch auf NetBeans reimt - war damals noch eine sehr kleine Firma und sie hatten ihren russischen Chefentwickler (oder dessen Vize, ganz genau weiß ich es nicht mehr) geschickt. Der hat dann in diesem harten, russischen James Bond Akzent, mal die Refactorings demonstriert, die IntelliJ kann. Und dem Hörsaal ist die Kinnlade runtergefallen. Und dann hat er den Logik-Analyser gezeigt.

NetBeans hatte als Killerfeature ein GUI-Zusammenklicktool - denk das "Visual" in "Visual C++" damals - IntelliJ hat die Sprache verstanden. Plottwist: kein Mensch klickt sich in 2022 ein GUI, wir haben Browser für sowas. IntelliJ versteht Java besser, als viele Java-Entwickler es tun. Es ist ein echter Gamechanger. Leider verstehen dieselben Java-Entwickler die Features von IntelliJ natürlich auch nicht.

Ich mag Java nicht besonders und ich finde es sehr schwierig Martin Fowler zuzuhören aber was JetBrains damals aus der Zusammenführung dieser beiden Entitäten gemacht hat ist auch heute noch beeindruckend. IntelliJ ist ein unglaubliches Stück Software, das natürlich nur funktionieren kann, weil Java eine relativ einfache Grammatik hat. Man soll sich ja nicht von seinen Tools abhängig machen, aber wenn ich IntelliJ nicht habe fühle ich mich regelrecht beraubt.

Der Standard für alles was nicht Java, C++ oder C# ist, scheint ja nun VSCode zu sein und das ist echt arm dagegen. Also natürlich ist ein Editor keine IDE, aber es fehlt halt sooo viel. Oder ich habe nicht die richtigen Plugins installiert, klar. Aber auch das erwachsene Visual Studio, als ich das dank MSDNAA noch bekommen konnte, kam halt mit IntelliJ nicht mit. Wie gesagt, Visual Studio startet natürlich mit dem Handicap dass es C++ parsen muss, aber ihr beschwert euch ja hier einmal im Monat, dass IntelliSense euch rumzickt. IntelliJ tut das nie.

Es gibt die Leute die sagen, dass eine IDE nur ein Pflaster auf die Schusswunde von Javas Geschwätzigkeit ist, aber das finde ich ein schwaches Argument, denn wie gesagt hätte ich dieses Featureset auch gerne für Node.js. Also die Umkehrung dass man die IDE nur braucht _weil_ Java so geschwätzig ist gilt jedenfalls nicht.

Und dann gab es schon immer die Typen, die mit vim alles viel schneller können weil die wesentliche Metrik beim Programmieren ja, wir wissen es alle, Typing Speed ist. </sarcasm> wie man 2006 gesagt hätte.

Das Hauptargument für TDD, so wie ich es verstehe, ist dass du gefahrlos Refactorings machen kannst. Ich glaube dass das nicht zu 100% stimmt, aber sagen wir zu 80%. Die Pointe ist, zu 80% kann ich das mit IntelliJ auch, ohne einen Test zu schreiben. Es kann einfach an sich schon Code in semantisch äquivalenten anderen Code überführen.

Natürlich gibt es noch andere Gründe, warum TDD cool ist (sein könnte, wenn man es richtig machte?) aber das nur mal so als Datenpunkt.

[Lord Delvin]

Ich mag Java nicht besonders und ich finde es sehr schwierig Martin Fowler zuzuhören aber was JetBrains damals aus der Zusammenführung dieser beiden Entitäten gemacht hat ist auch heute noch beeindruckend. IntelliJ ist ein unglaubliches Stück Software, das natürlich nur funktionieren kann, weil Java eine relativ einfache Grammatik hat.

Die Grammatik ist nicht das Problem. Die Problem ist in gewisser Weise die Ausdrucksfähigkeit bzw. der Zusammenhang zwischen dem was du vor dir siehst und dem was es bedeuten kann. In Java kannst du eine Datei parsen, das Projekt übersetzen und du kannst die semantischen Zusammenhänge korrekt herstellen. Weil es keine Macros gibt und weil Importe nicht die Semantik *importierter* Klassen ändern können.

Es gibt die Leute die sagen, dass eine IDE nur ein Pflaster auf die Schusswunde von Javas Geschwätzigkeit ist, aber das finde ich ein schwaches Argument, denn wie gesagt hätte ich dieses Featureset auch gerne für Node.js. Also die Umkehrung dass man die IDE nur braucht _weil_ Java so geschwätzig ist gilt jedenfalls nicht.

Ja das sehe ich auch nicht so. Sowas wie refactor method signature hat nichts mit getippte Zeichen pro Funktionalität zu tun. Zumal man mit Eclipse auch zu Java 7 Zeiten echt selten selbst irgendwelche Typen getippt oder Felder o.ä. definiert hat. Einfach verwendet und die Definitionen hingefixt.
Java bewegt sich da aber eigentlich seit Einführung des Modulsystems auch etwas von weg. Man ist zwar noch nicht in der C++-Welt, wo es einfach im Allgemeinen gar nicht möglich ist, sinnvollen toolsupport zu liefern und sowas wie CLion einfach nur deswegen gut funktioniert, weil man annimmt, dass die meisten Entwickler meistens Code schreiben, der sich eigentlich wie Java verhält, aber ich sehe immer mehr Bugs in IDEs, die es so zu 7er-Zeiten nicht gegeben hätte. Einfach weil die Zuordnungsregeln auf semantischer Ebene sehr komplex geworden sind. Es ist einfach blöd, dass es anonyme innere Klassen *und* lambdas gibt. Das macht es bei Fehlern einfach schwer, irgendwas sinnvolles vorzuschlagen.

Aber wenn ich gerade die Aufmerksamkeit guter Leute habe, hätte ich mal eine Frage:
Ab und zu braucht man Funktionsargumente, sowohl zur Laufzeit als auch in Templates.
Wenn ich das in einer Sprache einbaue, habe ich verschiedene Optionen.

1. Ich mache es wie Java 8 und verwende interfaces. Das hat den Vorteil, dass ich keine Syntax für Funktionstypen brauche; es hätte auch den Vorteil, dass ich keine Funktionstypen brauche, die habe ich aber schon, weswegen das für mich nicht gilt. Es hat den Nachteil, dass ich dann entweder Syntax wie anonyme innere Klassen oder sowas wie die SAM-Regel brauche, damit man einfach bei der Verwendung Funktionen in die entsprechenden Interfaces konvertieren kann. Beides finde ich nicht so richtig gut.
2. Ich mache, was ich bisher gemacht habe: Es gibt Syntax, um von einem Ausdruck einen Typ zu extrahieren. Das geht auch für Funktionen; im Prinzip wie decltype in C++. Der Vorteil ist, dass es das schon gibt. Ein Nachteil ist, dass es ziemlich unintuitiv ist. Ein weiterer, dass man gewisser Maßen einen Prototyp der Funktion definieren muss, um sie Verwenden zu können, also sowas wie

   Code: Alles auswählen

   BiFunction[T : Type, R : Type] { type def apply(x : T, y : T) : R; }

   . Das widerum hat den Nachteil, dass ich glaube, dass man manche Typen nicht hinschreiben kann oder es zumindest keinen leicht erkennbaren Weg gibt, das zu machen, z.B. Templatefunktionen, in einer Templateklasse.
3. Ich führe Syntax für Funktionstypen ein. Das hat den Nachteil, dass der intuitivste Weg nicht parsbar ist, d.h. ich brauche ein Schlüsselwort. Den C bzw. C++ Weg, die Namen in die Typen zu mischen fand ich nicht gut. Das Funktionsdefinitionsschlüsselwort wäre def. D.h. ich würde als Syntax sowas einführen wie

   Code: Alles auswählen

   f(pFun : def (int) : int) : int

   , was eine Funktion wäre, die einen Funktionsparameter einer Funktion int ⇒ int nimmt und selbst einen int zurückgibt. Entsprechend wäre

   Code: Alles auswählen

   f(pFun : def (String) : def (int) : int) : int

   ein Funktionszeigerargument, dass zu einem String eine Funktion von int nach int zurückgibt.

Also bei Option drei wäre die Signatur einer Sortierfunktion:

Code: Alles auswählen

type def sort[T : Type, cmp : def (T, T) : bool](data : Array[T]) {...}

und die Verwendung sowas wie

Code: Alles auswählen

var arr = new Array[int](...)
// ...
sort[int, int.`<`](arr)

Wäre im nächsten Schritt dann natürlich erforderlich, wie in Ada, sowas zu bauen, dass es mir erlaubt `<` aus T automatisch als default für cmp zu nehmen, wenn es denn definiert ist. Sowas ist in C++-artigen Templates natürlich leichter implementiert.

Nebenbei wäre ein Nachteil von Option 3, dass ein hypothetischer Toolsupport jetzt das Problem hätte, dass def nicht nur im Rumpf eines Datentyps vor einer Funktionsdefinition stehen kann, sondern überall wo ein Ausdruck erlaubt ist, was fast überall ist. Das würde ich hier für mich in Kauf nehmen, passt aber ganz gut zu meiner Argumentationslinie gegen Toolsupport für modernes Java. Es hat natürlich das ganz praktische Problem, dass man wenn man ein Feld definiert und nach dem ':' den Typ vergisst und danach eine Objektfunktion kommt, die Fehlermeldung extrem wirr sein kann. So Situationen hat man auch bei Fragen, ob ein - vor einem Literal zum Literal gehört oder nicht, weil "x-1" dann "x" "-1" wird, was sich nicht einfach verarbeiten lässt :)

EDIT: Eigentlich ist Option 3 genau das, was Ada und Go gemacht haben, nur dass sich die Schlüsselworte und die Syntax marginal unterscheiden. Die einzige ernsthafte Alternative zur Syntax in dieser Option wäre ein "=>" Operator-Keyword einzuführen und das anstelle des Doppelpunkts zu verwenden. Wird keinen allzugroßen unterschied machen und der Weg mit dem def ist vermutlich etwas besser zu lesen.

[Alexander Kornrumpf]

Ich finde -> am leichtesten zu verstehen, oder wenn das schon vergeben ist =>. Dann wahrscheinlich Rusts fun, was man aber wahrscheinlich mit der normalen Funktionsdeklaration von Rust verwechseln würde, dann def. Also das jetzt für den menschlichen Leser. Was für Sprache und Tools am besten wäre kann ich nicht beurteilen.

[Lord Delvin]

Ich finde -> am leichtesten zu verstehen, oder wenn das schon vergeben ist =>. Dann wahrscheinlich Rusts fun, was man aber wahrscheinlich mit der normalen Funktionsdeklaration von Rust verwechseln würde, dann def. Also das jetzt für den menschlichen Leser. Was für Sprache und Tools am besten wäre kann ich nicht beurteilen.

Ok danke; ich muss mir mal überlegen, wie sehr mich die Assoziativität von -> bzw => stört. Wäre beides ein Operatorkeyword und für die Entscheidung erstmal gleichwertig. Der fun/def-Weg wäre halt quasi ein Präfixoperator, der aus einem Ausdruck einen Funktionstyp macht. Muss mir mal ein paar Beispiele aufschreiben und dann entscheiden.

[Schrompf]

=> ist in quasi allen Programmiersprachen "größer-gleich". Ich würde dringend davon abraten, mit solchen Quasi-Standards zu brechen. -> ist nur in C++ üblich, das müsstest Du gefahrenarm nehmen können.

[Lord Delvin]

Du meinst >=, oder?

EDIT: Hab mal kurz das angeschaut: https://www.rosettacode.org/wiki/Intege ... on#C.2B.2B Sieht für mich so aus, als würde => entweder so wie von mir vorgeschlagen, als placement oder als then verwendet, nicht aber für den eigentlichen Vergleich.

[Alexander Kornrumpf]

=> ist in quasi allen Programmiersprachen "größer-gleich". Ich würde dringend davon abraten, mit solchen Quasi-Standards zu brechen. -> ist nur in C++ üblich, das müsstest Du gefahrenarm nehmen können.

Nicht wirklich. Lies nochmal genauer.

Spoiler: https://www.w3schools.com/js/js_arrow_function.asp

[NytroX]

"=>" ist tatsächlich bereits in einigen Sprachen ein Shorthand für eine Function-Definition (JavaScript, D, C#, ...), daher würde ich auch davon abraten, das für was anderes zu benutzen.

"->" ist eine gute Möglichkeit, das wird auch schon oft als Separator von Input- und Output-Argumenten verwendet, (z.B. in C++, Rust, Haskell, ...)

Allerdings kommt das auf deinen Parser an, manchmal ist ein Prefix-Keyword/null-denotation leichter umzusetzen.

Aber spätestens wenn eine Funktion eine Funktion entgegen nimmt und eine andere Funktion zurückgibt wird es in jeder Syntax schwer lesbar. Daher ist es fast egal :-)

[Schrompf]

Stimmt, ich meinte >=. Supported zwar indirekt mein Argument :) , aber formell isses ok.

[Lord Delvin]

Aber spätestens wenn eine Funktion eine Funktion entgegen nimmt und eine andere Funktion zurückgibt wird es in jeder Syntax schwer lesbar. Daher ist es fast egal :-)

Das

Code: Alles auswählen

((T) -> T) -> (T) -> T

oder

Code: Alles auswählen

 def (def (T) : T) : def (T) : T

oder

Code: Alles auswählen

 ((T) : T) : (T) : T

Das dritte wäre dann die Option mit dem natürlichen Kandidaten als Trennsymbol, da sieht man aber auch glaub' ich direkt, warum das nicht mehr parsbar wäre. In meinem Hirn Funktioniert Option 2 am Besten. 'fun' oder 'func' würde ich da als Keyword nicht einführen, da beides neue wären und sich das mit dem def eigentlich selbst erschließt.

Den Pfeil würde ich auch eher für sowas wie Lambdaexpressions verwenden, was bei mir nicht dieselbe Syntax haben kann. Das ist aber was, wo ich momentan wirklich dagegen bin, weil ich mit Blockparametern eigentlich eine gute Alternative habe.

[Alexander Kornrumpf]

Ich weiß nicht wie relevant das für eine research language ohne Nutzer ist (*scnr*) und ob wir mit lambda dasselbe meinen (ich meine eine anonyme Funktion, die ihren äußeren scope capturen kann), aber das will man in einer Sprache eigentlich schon haben heutzutage. Ich glaube, dass man die Möglichkeit Funktionen zu übergeben auch anders / weniger nutzt wenn man die Funktion nicht einfach inline hinschreiben kann. Für mich sind die beiden Konzepte Funktionsparameter und "Lambdas" in der Anwendung zumindest sehr nahe beieinander.

Eventuell kann man das mit anonymen Funktionen, die nicht capturen retten, wenn man als alternative eine sehr knappe syntax für currying (?) [ich meine das binden von Parametern an eine Konstante, sodass man eine Funktion mit weniger Parametern bekommt] hat, aber da werden die Übergänge dann wohl irgendwann fließend.

Ich hoffe dass wir jetzt nicht ausversehen dieses 20 Jahre alte Thema wieder vorholen: http://people.csail.mit.edu/gregs/ll1-d ... 03277.html

[Lord Delvin]

Ich weiß nicht wie relevant das für eine research language ohne Nutzer ist (*scnr*) und ob wir mit lambda dasselbe meinen (ich meine eine anonyme Funktion, die ihren äußeren scope capturen kann), aber das will man in einer Sprache eigentlich schon haben heutzutage.

Also die Idee ist schon, etwas auszuprobieren, dass mir etwas über realitätsnahe Programmierung beibringt. D.h. die Sprache sollte so sein, dass man sie verwenden würde, wenn irgendwer eine Runtime, Standardbibliothek und Werkzeuge stellen würde. Alleine kann man das nicht, selbst mit den Mitteln von heute.

Die Diskussion würde ich nicht weiterführen wollen, nicht zuletzt weil ich sagen würde, dass Java und vor allem auch C einfach mehr genutzt wird als Scheme :)

Der Punkt für mich sind folgende Beabachtungen:
Erstmal ist es so, dass eine Sprache Paradigmen in Form von Typisierung und Syntax unterstützt.
Dass OOP FP simulieren kann oder andersrum ist eine verbreitete Illusion, weil man durch die Simulation den Toolsupport kaputt macht bzw. nicht im entferntesten an das rankommt, was man hätte, wenn man gleich das gewünschte eingebaut hätte.
Auf OOP-Seite ist das primär Effektbeschränkung, also z.B. bei bestimmten Subtypen dann die konkreten Implementierungen doch zu kennen.
Auf FP-Seite ist das imho Inlining bzw. Rewriting, was man mit OOP so nicht machen würde.
Manueller Aufwand sind beide Simulationen immer.
Es ist aber leider auch so, dass man nicht einfach in eine Sprache OOP und FP reinbauen kann und glauben, dass das funktioniert.
In aller Regel muss man dann beides irgendwie einschränken, um nicht die Vorteile zu verlieren und erhält dann Fragmente, die nur bedingt kompatibel sind.

Vorabbemerkt muss ich sagen, dass ich großer Fan mancher Muster und Konzepte bin, die die FP-Welt hervorgebracht hat; ich würde generics und deren collection-Implementierungen dazu zählen.
Das Problem mit FP sind vor allem Leute, die FP gut finden.
Die interessieren sich selten dafür, wie Code oder sonst irgendwas tatsächlich repräsentiert ist.
Die glauben auch, das Haskell irgendwie deklarativer ist, als C.
Ich habe auch persönlich noch keinen effektiven Weg gefunden, mit so Leuten zu argumentieren.
Anonyme Funktionen benötigen neben Syntax im Prinzip Funktionstypen, Namen bzw. Repräsentation anonymer Funktionen, dynamische Hüllen für statische Zugriffe und einen Zeigertyp für Funktionszeiger mit Hülle.

Funktionstypen sind kein Problem, die brauche ich schon für die Overloadresolution und die Typinferenz, sind also da.

Namen und Repräsentation bekommt man hin; zur not zählt man die einfach irgendwie durch und präfixt das mit dem Namen der statisch umhüllenden Funktion. Das ist eigentlich dasselbe wie der Zugriff auf ein implizites this. Die Repräsentation ist eigentlich dasselbe wie von einem flachen Typ mit einem def apply.

Die Hülle ist so eine Sache; als Außenstehender denkt man immer erstmal, die Hülle zu identifizieren wäre das Problem. Das stimmt aber nicht. Der Compiler kennt die Definitionen alle und muss sie auch kennen, weil er ja irgendwas machen muss um die Zugriffe zu realisieren. An den Definitionen noch einen Marker unterzubringen, dass man jetzt in einer dynamischen Hülle geteilt existiert ist auch nicht schwer.
Das Problem hier, ist die Bedeutung dieses Markers.
Wenn es eine reine Copy-In-Hülle wäre, wie das z.B. in Java gemacht ist, dann könnte ich das vermutlich auch über ein komplett freies Wochenende implementieren.
Wenn die Hülle By-Reference-Semantik haben soll, dann hat man ein Problem, weil dann für die statische gebundene Variable die Lebenszeit plötzlich nicht mehr durch den Stackframe der statisch umhüllenden Funktion beschränkt wäre, was bedeutet, dass sie nicht auf dem Stack realisiert werden kann, was wiederum bedeutet, dass man Autoboxing braucht, was neben viel Aufwand vor allem ein massives Performanceproblem ist. Meine Erfahrung mit Scala war je nachdem was man so gemacht hat, ein Faktor 10 bis 100. Da ist bei mir Praxisrelevanz zuende.

Dazu kommt dann noch Ressourcenverwaltung, da es plötzlich nicht mehr einfach möglich ist, zu entscheiden, wann man irgendwas freigeben darf.
Mir ist ehrlich gesagt unklar, wie man realitätsnah Autoboxing ohne GC implementieren kann.
Keinen GC zu haben war für mich aber eine bewusste Entscheidung die nicht revidiert wird.

Ein Funktionszeiger ist einfach ein Zeiger.
Bei mir sind alle Zeiger auch tatsächlich Hardwarezeiger, d.h. ihre Repräsentation ist die Adresse des Ziels.
Wenn man gute Performance haben will, wäre mir auch nicht klar, wie man das anders erreichen soll.
Ein Zeiger auf eine anonyme Funktion kann, wenn diese eine nichtleere Hülle hat, aber ganz offensichtlich kein Funktionszeiger sein.
Das kann ich auf zwei Wegen beheben: Entweder ich führe zwei Arten von Funktionszeigern ein oder ich mache die bestehenden Funktionszeiger kaputt.
Beides ist Implementierungsmäßig erstmal kein Problem, den Aufwand wird man aber vermutlich unterschätzen :)

Mein größtes Problem mit FP-Jüngern ist eigentlich, dass viele von denen glauben, dass λ x . 1 denselben Typ haben sollte, wie die innere Funktion in λ y. λ x. y. Ist ja beides eine Funktion von int nach int. Das ist vollkommen absurd, weil sich die Repräsentation fundamental unterscheidet und Computer nunmal nicht Funktionsdefinitionen als zugrundeliegende Berechnungseinheit haben. Zumindest kaufe ich meinen Arbeitsspeicher nicht in GigaFunctions und meine CPU wird nicht in GigaFunctionApplications/s ausgewiesen.


Jetzt ist meine Erfahrung, dass die praktische Verwendung von λ-Ausdrücken eigentlich auf Callbacks und FP-Collection-APIs beschränkt ist.
Nicht zuletzt, weil sowas wie das Scala-ParserCombinators-API einfach unfassbar viel Sprachsupport hat, damit man die Schachtelung der Ergebnisse implizit rückgängig machen kann. (da gibt es sowas das grob ~[x, ~[y, z]] mit case x ~ y ~ z flach klopft).
Was wiederum dazu führt, dass es kaum Menschen verstehen und in vielen Sprachen mit FP-Erweiterungen auch nicht mit der Einfachheit von Scala verwendet werden kann, btw. in nicht-GC-Sprachen hat man auch hier ein massives Ressourcenverwaltungsproblem bei einer Lösung, die fachlich etwas supersimples macht.

Der Punkt für mich jetzt ist, dass ich sowieso schon einen "Calloperator" apply habe. Bei vielen UI-Callbacks sollte man die Funktionen ohnehin irgendwie gruppieren und hätte dann eine spezifische Listenerklasse.
Bei den Collections habe ich eine komplett andere Lösung, die eigentlich meine Reaktion auf die desaströse Performance der Scalacollections ist: Man darf in Tyr Blöcke an Funktionen weitergeben, wenn man die aufgerufene Funktion direkt inlined.
Die Einschränkung heilt das Problem mit der dynamischen Lebenszeit und dem Stackframe.
Das Vorgehen erlaubt dir aber die Abstraktion der Collection zu implementieren, d.h. du musst nicht mehr wissen, wie man am besten alle Elemente aus einem HashSet oder sowas rausnimmt.
Damit das funktioniert, erlaube ich zudem lokale Variablen der aufgerufenen Funktion in den übergebenen Blöcken zu binden.
Das hat interessanterweise als Konsequenz, dass man Sachen machen kann, die mit λs nicht gehen, weil sozusagen zwei anonyme Funktionen *denselben* Parameter binden.
In der theoretischen Betrachtung ist das also wieder ein ganz anderes Konzept.
Die Ressourcenverwaltung löse ich, indem manche Funktionen das aufgerufene Objekt freigeben (mem.consumed).

Ein Beispiel wäre hier etwa forall.
Du sagst, dass du die lokale Variable c nennen möchtest.
Du übergibst einen Block

Code: Alles auswählen

 c == 10i8 

Und es kann dir scheißegal sein, ob da jetzt ein Iterator oder ein Index zum Iterieren verwendet wird. Genauso wie du nicht darüber nachdenkst, wie man abbricht, wenn man die Antwort kennt oder in welcher Reihenfolge man die Elemente auswählt. Das sollte dann in der Beschreibung der konkreten Implementierung von forall stehen.

Wenn man an der Stelle sicher ist, dass man einen ArrayBuffer in der Hand hat, im Beispiel ist das so, dann bekommt man die effiziente Implementierung.
Wenn nicht, dann gibte es halt die allgemeine.

Nebenbei bemerkt ist das statische Neubinden von inline-Funktionen bei präziserem Zielobjektstyp auch sowas, das man nicht erreichen kann, wenn man OOP mit FP simuliert. Da kassiert man neben dem Overhead auch die Wahl suboptimaler Algorithmen.

Meine zugrundeliegende Wette bei λ vs generalized Binder (Block+Blockparameter) ist natürlich, dass das double-inlining insgesamt günstiger ist, als der Overhead durch die Closures.
Meine Annahme hier ist, dass einerseits sowieso meistens der Code von double-inline nach Optimierung nicht mehr ist, als das was man mit Closures erzeugen würde.
Ebenso nehme ich an, dass Ausführungszeit der Anwendung und Lebenszeit der Entwickler die wesentlichen Optimierungsziele sind.

Ich glaube aber, wenn Sprachen wie C++ oder Java jetzt auch noch generalized Binder abwärtskompatibel nachrüsten würden, dann würde das mehr Chaos als Ordnung stiften.

(der Beitrag ist Urlaub, keine Mittagspause;) )

[Alexander Kornrumpf]

Danke für die ausführliche Antwort.

Die Hülle ist so eine Sache; als Außenstehender denkt man immer erstmal, die Hülle zu identifizieren wäre das Problem. Das stimmt aber nicht. Der Compiler kennt die Definitionen alle und muss sie auch kennen, weil er ja irgendwas machen muss um die Zugriffe zu realisieren. An den Definitionen noch einen Marker unterzubringen, dass man jetzt in einer dynamischen Hülle geteilt existiert ist auch nicht schwer.
Das Problem hier, ist die Bedeutung dieses Markers.
Wenn es eine reine Copy-In-Hülle wäre, wie das z.B. in Java gemacht ist, dann könnte ich das vermutlich auch über ein komplett freies Wochenende implementieren.
Wenn die Hülle By-Reference-Semantik haben soll, dann hat man ein Problem, weil dann für die statische gebundene Variable die Lebenszeit plötzlich nicht mehr durch den Stackframe der statisch umhüllenden Funktion beschränkt wäre, was bedeutet, dass sie nicht auf dem Stack realisiert werden kann, was wiederum bedeutet, dass man Autoboxing braucht, was neben viel Aufwand vor allem ein massives Performanceproblem ist. Meine Erfahrung mit Scala war je nachdem was man so gemacht hat, ein Faktor 10 bis 100. Da ist bei mir Praxisrelevanz zuende.

Ich meine das was Java macht und ich denke - aus dem Handgelenk - dass das identisch damit sein müsste einen Parameter an eine Konstante zu binden. Das was Java macht ist aus meiner Sicht reiner syntaktischer Zucker - eine Kurznotation, die es einem eben erspart der Funktion einen Namen zu geben, sie damit an eine andere Stelle schreiben zu müssen und etwaige Parameter binden zu müssen, die nicht Teil der gewollten Signatur sind.

Die Alternative - behaupte ich mal - ist nur ein verschwindend kleiner Teil der Menschen auf diesem Planeten überhaupt in der Lage zu verstehen, und die von dir genannten "FP-Jünger" sind vermutlich nichtmal eine echte Untermenge dieser Menschen.

Ein Beispiel wäre hier etwa forall.

Ehrlich gesagt, ich verstehe das Beispiel und deine Ausführungen dazu nicht. Ich denke dass Leute die schonmal mit Java oder JavaScript gearbeitet haben, erwarten dass sie sowas machen können (Pseudocode)

Code: Alles auswählen

collection.removeIf(element -> element.property > someQuasiConstantFromOuterScope)

ich nehme removeIf, weil da klarer ist was das tun soll, als bei forall.

Was ich nicht schreiben will ist (pseudocode):

Code: Alles auswählen

boolean propertyGreaterFilter(element, threshold) {
    return element.property > threshold
}

// ...

myPropertyGreaterFilter = bindLast(propertyGreaterFilter, someQuasiConstantFromOuterScope)
collection.removeIf(myPropertyGreaterFilter)

Der Grund hier ist nicht dass das "Lambda" mehr kann, sondern dass die Alternative unglaublich nervig hinzuschreiben ist.

Wenn du dafür eine vergleichbar kompakte Syntax hast, die ohne "Lambdas" auskommt, verschiebt sich das Argument dahingehend, dass die Leute die "Lambda" Syntax halt schon kennen.

[Alexander Kornrumpf]

Ich kann einfach nicht nachvollziehen, warum es nicht gelingt bei professioneller Softwareentwicklung Zeit in eine saubere Codebasis und Architektur zu stecken. Dass sich Anforderungen ändern kann nicht das Argument sein, da das bei meinem Forschungsprojekt ja auch so ist.

Ich weiß nicht ob wir das hier weiter diskutieren oder irgendwie abtrennen wollen, aber ca. alle 5 Jahre erinnere ich mich dass es "Cliffski's Blog" gibt und meistens hat sich in den 5 Jahren mindestens ein interessanter Artikel angesammelt. So auch dieses Mal.

I’ve seen coders do this. I know how this happens. It happens because not only are the coders not doing low-level,. efficient code to achieve their goal, they have never even SEEN low level, efficient, well written code. How can we expect them to do anything better when they do not even understand that it is possible?

https://www.positech.co.uk/cliffsblog/2 ... ronomical/

[Lord Delvin]

Danke für die ausführliche Antwort.

Code: Alles auswählen

collection.removeIf(element -> element.property > someQuasiConstantFromOuterScope)

[...]

Wenn du dafür eine vergleichbar kompakte Syntax hast, die ohne "Lambdas" auskommt, verschiebt sich das Argument dahingehend, dass die Leute die "Lambda" Syntax halt schon kennen.

Code: Alles auswählen

collection.removeIf element do (element.property > someQuasiConstantFromOuterScope)

Ich könnt's dir auch zumindest für ArrayBuffer, da man da was wirklich entfernen kann, in die Standardbibliothek bauen und einen Test machen. Man braucht halt eine mutable Collection.

I’ve seen coders do this. I know how this happens. It happens because not only are the coders not doing low-level,. efficient code to achieve their goal, they have never even SEEN low level, efficient, well written code. How can we expect them to do anything better when they do not even understand that it is possible?

https://www.positech.co.uk/cliffsblog/2 ... ronomical/

Ist etwas offtopic, aber im Kern kann ich das verstehen. Ich würde auch erst bei über 90% aktiv werden; ich glaube dass die Zahlen auch etwas übertrieben sind, aber nicht viel. Auf der Arbeit hab' ich auch immer versucht, den Leuten klar zu machen, dass das Ziel 16ms und nicht 2s sein müssen, für eine Nutzerinteraktion. Hab's jetzt aber auch aufgegeben. Fünfzig bin ich noch ne Weile nicht :)

[Chromanoid]

Zu Tech Debt: Selbst wenn die Architektur zunächst stimmt und alles sauber ist, kennst Du nicht die Zukunft und selbst wenn Du nach bestem Wissen und Gewissen handelst, wird es Designfehler geben. Das gebietet ja im Grunde KISS, DRY oder meinetwegen auch WET. Am Ende muss man regelmäßig Refactoring machen und alte Konzepte hinterfragen.

Ein viraler Eternal Typo hier (https://images.squarespace-cdn.com/cont ... /typo2.jpg :)), siehe "Referer" in der HTTP Spec), eine Bad Abstraction da (siehe auch https://sandimetz.com/blog/2016/1/20/th ... bstraction), sich änderndes Vokabular, unterschiedliche vermeintlich gleiche Kundenanforderungen, neue Rahmenbedingungen, wichtige aber sich langfristig als unnötig herausstellende Erweiterungen, Visionen Einzelner, die auf halber Strecke durch Arbeitgeberwechsel o.Ä. liegen bleiben, Budgetengpässe, Neuausrichtung, neue Geschäftsfelder, Fusionen... schon hat man einen riesigen Haufen technische Schulden, die sich noch nicht mal unbedingt lohnen abzubauen, weil das Produkt vielleicht eh eher eine Cash Cow ist.

Ich denke am Ende geht es häufig wohl nur mit good enough architecture https://youtu.be/PzEox3szeRc
Man sollte natürlich versuchen diesen Ratschlägen zu folgen: https://youtu.be/QYG7dFPwSrM aber das muss auf allen Ebenen der Organisation verinnerlicht werden und sich auch wirklich lohnen (haha)...

Zu Closures:
Ich mag fn, fun und Co. überhaupt nicht. Da finde ich es in Typescript schöner: type TaxCalculator = (amount: number) => number;.Nur whitespaces und Wörter als Trenner kommt mir immer irgendwie komisch vor, weil sich dadurch meist keine schöne "natürliche" Weise ergibt, wie Linebreaks und Einrichtungen zu laufen haben.