My mind blown experience was listening to a Rich Hickey talk (maybe not [1]) that flipped upside down my accepted method of thinking about types and type system paradigms. I still love writing Haskell and Rust, but I see the warts that he is so concisely pointing out. The either type really sticks out to me now, and I see the problems with overtyping what are essentially maps, and how rigid that makes every aspect of your programs. Currently I deal with a fairly large go monolith that had some clean code practices in it, and changing a single field that is going to make it into the public API ends up being hundreds or thousands of lines of changes. Such a waste of time to CRUD what is a map of strings.
The overtyping seems not about not about static vs dynamic but about nominal typing(functions based on the abstract type) vs structural typing/row-polymorphism (functions based on specific fields). Go seems to have structural typing, though less used. Do you have the same problem with overtyping while using structural typing?
There was a very similar complaint [1] ("OOP is not that bad") favorably comparing the flexibility of OOP classes in Dart vs typeclasses in Haskell. But as pointed out by /u/mutantmell [2], this is again about lack of 'structural typing' at the level of modules with exported names playing the role of fields. First class modules in functional languages like ML (backpack proposal in Haskell or units in Racket) allow extensible interfaces and are even more expressive than classes in most usual OOP languages. First-class modules are equivalent to first-class classes [3] ie. a class expression is a value, so a mixin is a regular function which takes a class and returns a class. Both are present in Racket.
My mind wasn't exactly blown; indeed that talk and its arguments give me a sense of deja vu. And then I remembered some of the arguments behind Google's protobuf removing required/optional fields in proto3. It's really the same argument. And that argument is a fairly narrow one when it comes to representing business logic data. You still need Maybe/option types when you are dealing with computer science data. If you are implementing your own linked list, you are going to need that Maybe or option type.
I believe you that he's being concise but don't have time to watch an hour video even at 2x. Can you summarize? (I got to where he was talking about how introducing Maybe in breaking ways will break things, thought "duh" and quit watching.)
The big idea is that record types that have optional values (such as Maybe in Haskell) don't give you enough context on when, where, and how those values can be optional. Additionally, by placing things in buckets, the argument is that records and optional types are more brittle than the alternative, maps that can simply have missing keys for what would be optional. The imagery of a herd of sheep (map) versus compartments into which each sheep can go (records, Optional types, etc.) is brought up to illustrate a desire for more fluid engagement with information that may or may not exist or be needed, all of which is a description of a named aggregate of information we care about in context.
While I see the merit in his arguments, I believe his approach to data is "Clojure-like" or Lisp-like, in that it discourages explicit enumeration of all states and their possible configurations for the tradeoff of being able to sculpt these records. But, as a Haskell dev, I do not want to sculpt the records in the way he describes. I want to explicitly enumerate all the possibilities. This is, in my mind, a difference in cognitive preference. There is no right or wrong way and I think what he proposes is elegant. It is ultimately a matter of up front reasoning about the space compared with reaching a synthesis of the problem domain over time through wrestling with the problem itself. It is a statement about the efficacy of saying what can be known up front and to what extent, how much accuracy, and what utility.
I am about to launch a SaaS that pairs languages to these cognitive patterns as explicit understanding of such information can help bring together people who think similarly about information (team-building) while also opening up the possibility of expanding ones insights with alternative ideas and approaches (as his talk has done for me). The intent is to help hiring teams find devs that match their culture's programming and problem solving styles (whether that be reinforcing or doubling down on ways of thinking and acting).
You don't have half an hour to spare any time in the near future? But you do have the time to scroll HN and comment?
I'm not a huge fan of videos as content delivery mechanisms for simple facts, but this is a talk - an argument made with the intent of convincing you about something that you may find counter-intuitive. What's the point of summarising that, if it loses the granularity of the argument, its persuasive power? "Static types bad, Clojure good?"
What persuasive power are you going to lose if you cut out the jokes that 5-year plan is stripes? And that's the first 3% of the talk, so pure lossless compression
> "Static types bad, Clojure good?"
sure, this kind of summary is useless, but then is simply too short
There is no shortage of long talks that lack nuance. Just say that no, you can't effectively summarize this video, instead of doing whatever it is that you are doing here.
> There is no shortage of long talks that lack nuance.
Nuance is not the same thing as a talk designed to build an argument bit by bit and be persuasive. You could summarise an hour-long closing argument for the defence in a jury trial as 'My client is not guilty', but doing so is rather missing the point.
> Just say that no, you can't effectively summarize this video, instead of doing whatever it is that you are doing here.
x == y, but with the added implication that SBF's take on longform is not actually something to aspire to.
The point of summarizing is to condense the substance for potentially hundreds of readers into a sensible set of ideas in a couple of paragraphs. Any wise listener will stay away from talks that need full half an hour to stay “persuasive”.
>> The point of summarizing is to condense the substance for potentially hundreds of readers into a sensible set of ideas in a couple of paragraphs. Any wise listener will stay away from talks that need full half an hour to stay “persuasive”.
“I don’t want to say no book is ever worth reading, but I actually do believe something pretty close to that. … If you wrote a book, you f'ed up, and it should have been a six-paragraph blog post.” -Sam Bankman-Fried
Ironically, Nate Silver went into great detail--in his book--about what a damn weirdo SBF was even before he ended up in jail. So yeah, if you want to follow the lead of a convicted felon, well . . .
I’m not Rich, I think to summarize what he’s saying I’d need to have a better grasp of the subject material than he does.
I’ve actually struggled to get people on my team to understand what is so great about this language or the ideas behind it. Pointing people at 1 hour long YouTube videos that almost need to understand the source language to see examples of what he’s talking about haven’t been working.
I’ll think hard on how to summarize this without needing the context I have and come back to this comment. It won’t be what he’d say but I’ll share my view
The key point may be (summarizing from memory): a function signature can be backwards compatibly changed by either making a parameter it accepts nullable from a non-nullable type, and/or by making the return type non-nullable from a nullable. With union types of T | Null, this is a type safe refactor that requires no code change. The Maybe<T> variant on the other hand requires code changes no matter what.
I saw a big uproar in certain strongly typed FP communities around it, but I think it's more like different problem domains having different experiences. Many software operates in a closed world where they control everything, while other software has to communicate with other software that may change with a different schedule, owned by a different team, etc.
Rich Hickey discusses the complexities of optionality in programming, particularly in Clojure’s spec system, emphasizing the need for clear schemas and handling of partial information.
Highlights
* Community Engagement: Acknowledges the presence of both newcomers and regulars at the event.
* Fashion Sense: Introduces a humorous take on the programming roadmap focused on fashion.
* Language Design: Explores the challenges of language design, especially regarding optionality in functions.
* Null References: Cites Tony Hoare’s “billion-dollar mistake” with null references as a cautionary example.
* Spec Improvements: Discusses plans to enhance Clojure’s spec system, focusing on schema clarity and usability.
* Aggregate Management: Emphasizes the importance of properly managing partial information in data structures.
* Future Development: Outlines future directions for Clojure’s spec, prioritizing flexibility and extensibility.
Key Insights
* Community Connection: Engaging with both veteran and new attendees fosters a collaborative environment, enhancing knowledge sharing and community growth.
* Humorous Approach: Infusing humor into technical discussions, like fashion choices, can make complex topics more relatable and engaging.
* Optionality Complexity: The management of optional parameters in programming languages is intricate, requiring careful design to avoid breaking changes.
* Null Reference Risks: Highlighting the historical pitfalls of null references serves as a reminder for developers to consider safer alternatives in language design.
* Schema Clarity: Clear definitions of schemas in programming can significantly improve code maintainability and reduce errors related to optional attributes.
* Information Aggregation: Understanding how to manage and communicate partial information in data structures is crucial for creating robust applications.
* Spec Evolution: Continuous improvement of the spec system in Clojure will enhance its usability, allowing developers to better define and manage their data structures.
I'm generally an advocate for a robust, mandatory type system like Rust. But there are production scenarios where it's a hindrance. Imagine processing arbitrary JSON document containing several required properties and many additional ones. You can't possibly know what additional properties any given document will have (it's only available at runtime, with infinite variations) but it's often a hard requirement that these extra data get passed through the system. Being forced to create a concrete type for what is effectively an open map + some validation logic is awkward at best. Maps and general purpose functions that process maps are a better fit for this problem.
Yes but the concrete types at the byte level can be used to say: "these five bits are, concretely, a type tag, and always a type tag", and so it goes from there.
I don't want to be typing at the high level the same way I'm typing at the byte level.
1. https://youtu.be/YR5WdGrpoug?si=jRsXcYlwRuz0C1IN