Rich's simple made easy is the best programming video I've ever seen, and is ultimately I think what so many engineers need to "grok" to unlock better coding. I'm the "most senior" engineer (chief architect) in a company of more than a thousand engineers, and I recommend it to every junior who asks how to get better.
I will also say I used clojure + aleph to write the only significant application I ever released which never had a reported bug or outage. It ran for seven years and that application was under constant heavy load (more than 10k TPS).
The other essential talk I usually recommend is “beyond PEP8” by Raymond Hettinger.
Its was one of those things that was always on my mind, but couldn’t express it well to my peers, before encountering this talk. Plus its about both python and java, so increases the chances to be heeded by non-fp people.
A lot of programmers I’ve worked with either don’t want to learn well the environment they are working in, thus repeating stuff that doesn’t fit well, or over-engineer abstractions to force their environment to behave the way they like, and both approaches can leave the codebase in shambles.
I wrote my first trading system in Clojure because a few of the libraries we relied on were in java.
It was 2011 and I'd had about 3 years of lisp experience. I got a bit of side eye from people when I told them I was using a relatively new programming language but the fact that it was based on the JVM, which alot of HFT firms were using helped make the case.
We didn't use if for more than a few years before it was retired and rewritten, though that was due to new requirements that included C++ interop.
In the end tracking memory usage and allocations got too hard and if you've ever written something that is time sensitive you'll know just how slow memory allocation is, so you could argue I made a poor choice but for the rewrite was easy to reuse the java libraries when we moved to java.
The harder part was porting the algorithm implementation code.
The reason was that I chose a common lisp trick of first writing a DSL in Clojure that was then used to write the algos.
That was the one part that seemed worse in the rewrite as it became far more verbose and clunky.
But man was it fun, I learned more in a month than I often do in a year now.
Thanks Rich!! It's not often you get to experiment with cool tech and make lots of money doing it. I appreciate your work.
Just a small nitpick, but allocation is definitely not slow in case of the JVM, it is often faster than manually managed languages. It is a pointer bump only.
All the necessary mechanisms of a GC does have an overhead, so your point stands, but not for the mentioned reason.
> So you had to switch to C++ because Clojure / Java wasn't performant enough?
Clojure yes, java no. Many HFT firms build their systems in java and run on the jvm(specialized hardware aside), its plenty fast if you avoid memory allocations.
It is also possible Clojure is more than up to the task now and its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues at the time and a more competent developer could have made it work.
But like almost all things if you chose a very out of the mainstream language and start to have issues, most developers will point fingers at the language first.
Side note, its a miracle that Jane Street kept using OCaml after the first few years and points to how strong their core tech team was.
C++ was an external dependency brought on by other systems that needed to be integrated and is a far safer language to use. I'd imagine that if you say HFT to most developers, their first thought would be C++ even if they haven't worked in the domain before.
It's like choosing Julia for your machine learning platform and then switching to python.
It's a shame you couldn't have pitched Common Lisp. Maybe could have ported your DSL pretty quickly and wound up having SBCL output nice compiled assembly instructions and shown x% speed improvement without much effort by using a "sister language" of sorts? ABCL in 2011 would have been a harder sell, it only had its 1.0 release that October.
A few years ago another commenter noted they had developed a trading system in Lisp and C https://news.ycombinator.com/item?id=25222297 (further comments elaborate a bit) before being asked to rewrite it in Java. What keeps less popular languages alive at companies, when there's no forcing reason to get rid of it like really unacceptable performance, is a conviction (borne out as far as I can tell) that it's ok to hire people who don't know the language -- they'll get up to speed more than fast enough.
> ... its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues...
Technically it can likely be done but in practice pushing Clojure code for performance (eg, [0]) doesn't follow the usual language idioms and relies on a sophisticated understanding of the interactions between program design, Clojure, the Clojure compiler and the JVM. I'd suggest pointing more at the language than the programmer. In a situation where direct memory management is required Clojure is a weaker choice.
Although in Clojure's defence it leverages immutability to squeeze out some surprising performance benefits without much effort. I would expect Clojure code to be fast by default but challenging to hand-optimise further if that extra level of control is required. Clojure makes it easy to write code that performs well, it is a stronger language for situations where ordinary business logic changes are the productivity bottleneck.
For extremely low latency, Clojure can be an awkward fit. By default there's a lot of sugar in the syntax, so if you need to be precise about the underlying types of your data and the exact datastructure, you need to toss out most of the standard datatypes and datastructures. It's small details like: "I definitely have an array of unboxed integers, and I need to be sure this one operation won't accidentally allocate a new list of boxed integers, and that this function I'm calling doesn't dispatch dynamically" or things like that. You start using `deftype` everywhere, sometimes dipping into Java, etc. You may as well just write java at that point. However from a pure Clojure standpoint, the author of Neanderthal has done great work on making Clojure viable for high performance numerical computing.
Languages aren't "performant". You can write good or bad code in most languages, or code that isn't a good fit for a language.
That said, there are languages which will make you incur certain penalties, as there is a price to be paid for automatic memory management with garbage collection, for example. These penalties generally do not matter except for edge cases (and HFT trading might very well be one!).
There are also languages which help you write much faster code, but on a higher level. Clojure transducers are a good example: pipelines built of composable transformations, where data sequences are not fully realized between the transformations. These can provide significant performance (and memory allocation) improvements, while still letting you write high-level code.
Yes. And it really doesn't matter in practice. In a larger system this kind of performance won't matter. What will matter is design decisions, data structures, databases and access patterns — things that are much more high-level than "language performance".
> The harder part was porting the algorithm implementation code. The reason was that I chose a common lisp trick of first writing a DSL in Clojure that was then used to write the algos.
Doesn't it mean that Lisp macros should really be avoided at all costs?
Can't say for sure, given that my sample size is one.
The upsides of DSL(Domain specific languages) and macros in general is that they cut down on code duplication and give everyone using them a common language and set of tools on which to build an app. That part is awesome and I think really helped to speed up development of the algos that were built on top of the DSL.
The downside is, that you need to learn the DSL but that's a very small impact in my experience. THe larger downside as you and I point out is that those tools aren't really there for other languages so if you do plan on porting the code base to another language then maybe steer clear of macros.
But again, I wouldn't say I have anywhere near enough experience to claim to be an expert in that.
I made two large projects in Clojure: One abandoned startup SaaS and one internal system. Both were a damn joy. They taught me the immense value of loosely coupled components that exchange simple data with each other, from large server components all the way down to module-level coupling. I can only ever view gigantic, monolithic, opinionated web frameworks with a strong degree of skepticism from now on.
Lisp in general was probably the most fulfilling programming rabbit hole I ever followed down, and I don't regret a moment of it. A true gold mine of skill, ability, and thought training that changed the way I program, even in imperative/procedural languages.
The word congratulations came into English from Latin, where it was formed by combining prefix com-, meaning with, to gratulari, meaning "give thanks" or "show joy." Gratulari is derived from gratus, as is gratitude. Gratus means "pleasing," "thankful."
Having only had the good fortune to meet you in person a few times:
Congratulations, Rich. You have my deepest gratitude. It fills me with great joy to know you are taking this step. I look forward to what your next stage brings.
Few people capture this spirit like the classic "Congratulations" video from Big Man Tyrone.
While it has gone through the revolutions from sincere, to sarcastic in intent, to back again, I believe the inherently joyful attitude underpinning the original video carries the buoyishly optimism of sincere joy.
Side question: Rich seems to use etymology as a tool for original thinking and clear explanations. Are there other people who do this as well as he does?
I don't know about technologists who use it in writing or speaking like Rich, but you can trace writers' use of etymology to provoke thinking at least back to Plato. More recent, prominent examples would be Hannah Arendt's acceptance speech in 1975 receiving Denmark's Sonning Prize, in which she uses the etymology of "person", and at least Martin Heidegger's essay The Question Concerning Technology in which he plays with several, including the etymology of "technology" itself.
I’ve always been fascinated with language, and long had a hobby of looking up etymologies (my high school Latin teacher was great at pointing these out in class), but Rich’s style definitely pushed me to use it as a tool for thinking. Naming things is (famously) hard, but a strong command of language (and willingness to dig through the thesaurus) has lit the way through many difficult situations.
I use etymonline for this kind of thing often. Our complex words are compositions of lots of forgotten meaning... I find it helps to retrace those steps.
Funnily enough, your complaint here is that although it may be simple, it is not necessarily easy, while the talk is an argument that we should prefer simplicity even at the cost of some (temporary) un-ease.
I'm not sure how you got that impression from my comment.
But for the sake of argument, I'm saying "complect" is neither simple *nor* easy. It's obviously not easy since it's unfamiliar. But nor is it simple, or to be really precise, no simpler than alternatives, since it doesn't conceptually improve on plain words and phrases like "complicate", "intertwine", "mix up", "separate", "tease apart", etc. It adds nothing, really.
Your comment kind of highlights some of the errors many take away from "Simple Made Easy": that ease is in opposition to simplicity and/or that they are completely orthogonal.
Rich Hickey's talks inspired me to explore Clojure and functional programming in college. That led to a part of my career where I got to help advance an FP language (F#). Can't say it was a raging success, but it wasn't a raging failure either. Really happy things worked out the way they did, though. I still look back at my senior project, written in Clojure, from time to time and find it elegant in a unique way.
My experience was similar. I've built far more impactful things since then, but at the end of the day, the software that I'm most proud of was a calculator, of all things, that I made in Clojurescript. It was loosely based on the final chapter of SICP, and implemented an hilariously metacircular approach to transitioning the state of the register machine. Since the implementation was way more interesting than the actual application, I used Processing to visualize the register machine as if it were a rudimentary ALU (which it basically was).
If it hadn't been for Rich Hickey, or Clojure, I'm not sure I'd have the slightest inkling of how joyful and creative it can be to write software. It was an A+ experience, even if I'd be swiftly fired for trying to push logic like that into production.
FWIW, I started programming F# during your tenure at MS and in a couple of years it became a really capable cross platform option - partly MS, partly community, but definitely helped out by you. Thanks!
I remember Rich talking about how much time and money he put into Clojure–some of that money taken out of his retirement funds! I hope he has a long and fulfilling retirement with lots of happiness.
This is awesome! One, it reinforces the ongoing maturing of Clojure, the language as a team project. Two, it portends cool new things to come; the kind that can only come from a place of personal liberty. Three, BDFL is retiring from an employer, headlong into his life's work. I for one am cheering.
Congrats Rich! I met you at Stu's house during a rousing game of Marvel Champions. Thank you for Clojure, Datomic, Cognitect, and your talks. Your creations have enriched my life in many ways. I hope retirement affords you ample hammock time!
Without Clojure and the immense effort of the community around it and ClojureScript, OrgPad would not be possible and the individuals on the team would probably be stuck in some academic or corporate structures instead of having basically a two-families startup/ company. So thank you Rich and thank you to everybody else, who supported You on the journey to create something that makes coding predictable, productive and almost fun instead of laborious work. ;-)
Rich presented Clojure to our local software development group in 2008, I've been working with Clojure (both as a hobbyist and eventually professionally) ever since.
At that time I had been working with Java for years, both the conciseness of the code and the interactivity were flat-out amazing to me. It's saved me time and made me 100 times more productive.
Congratulations to Rich, I am also extremely grateful for his work!
What a great event —- we were lucky to get in on clojure when it was just getting started, and he was looking for places to promote it.
I reached out to him to come to our meeting because I met him when I took his Advanced C++ class at NYU continuing education in the 90’s. The class culminated in some advanced usage of his C++ functor library.
Well deserved, I'm looking forward to seeing what Rich does next in his free time. Clojure made me love programming again the same way Python once did (the whole Py3k fiasco soured that). I haven't used it in quite a while (switched to Common Lisp) but I'll always be happy to see more Clojure success.
I’m a designer and barely ever write production-grade code (coz I suck at it), but Rich has been my inspiration for years and I shared his talks available online across pretty much all design teams I’ve ever worked with, because they’re just full of invaluable experience and wisdom. Excited about Clojure future!
I was about to give up on a career in software development when I found Clojure in 2007.
Rich, I'll always be grateful to you for creating a language and community that got to the root of so many problems our industry still faces today. I'm confident it will continue to change the world as it has my own life.
I remember being curious about Lisp and then seeing a new Lisp-style language was coming out for the JVM. I think back in the 0.2 days (unless I'm confusing versions with Phoenix but I feel like I started using both at that version number).
I didn't end up sticking with Clojure because I don't enjoy the JVM tools/ecosystem, but Rich's talks gave me a lot to think about and I've been spending time in more FP and FP adjacent languages like Common Lisp and F# because of his thoughts and ideas.
Thanks for everything and enjoy your retirement from professional development!
Don't think Rich Hickey is "retiring" retiring, just that he's retiring from Nubank and "commerical software development".
TFA: I look forward to continuing to lead ongoing work maintaining and enhancing Clojure with Alex, Stu, Fogus, and many others, as an independent developer once again... Retirement returns me to the freedom and independence I had when originally developing Clojure. The journey continues!
Simple made easy is the most impactful talk I have watched. Made a very big impact and I still think of it frequently. I never got into clojure but I am so glad it is around.
I feel the same. I was there in the room when he gave the talk: it was the first software-devs conference I'd attended and I was so green that I struggled to understand if he was making references to Haskell or another lang I'd been introduced to in the conference's previous days by various presenters.
Some days later I started learning Emacs, Clojure, et al. and I was/am definitely the better for it.
Well-deserved retirement! I recall a history of Clojure paper mentioning that Rich was using his retirement savings in the years spent to build Clojure[0]. This provides a lot of context as to why he has wanted to maintain ownership and tight control of Clojure. Overall, Clojure is a brilliant piece of work and it has made software development fun and productive. Many great talks were also given by Rich over the years, and Datomic, though the licensing was restrictive up until very recently, has so much synergy with Clojure that it's tough going back to Postgres. :)
Congratulations to Rich. Thank you for your immense contributions, especially in code, in software design, and in inspirational and thoughtful public speaking.
I attended your presentation on Clojure at the International Lisp Conference at MIT in 2009, where we were celebrating the fiftieth anniversary of Lisp. After your talk, you were surrounded by admiring Lispers, including several of the elder statesmen of the community. These were people who, to put it mildly, were not known for being quick with praise. But one after another, they were saying things like "This is the future of Lisp!"
By the way, I love the title. It reminds me of what I wrote when I started my last job:
Hey idk if Rich reads HN but if you do thank you for being a huge inspiration to me when I first started programming around 2014. You've helped change the world for the better. Cheers!
Clojure was hugely inspirational to me and I could finally enjoy programming (focusing on algorithms). Rich has many great ideas, the database as a value is my all time favorite from him.
I’ll always have a soft spot for Clojure. It’s the only Lisp I’ve been paid to write applications in. Naturally I’ve written plenty of Elisp. I also use SBCL for personal scripts and data exploration, but that’s always been in support of delivering a solution in some other language.
While, as is to be expected, I don’t agree with every decision made for Clojure, I find it to be an entirely pleasant Lisp to work with.
So, kudos to Mr. Hickey, and thanks for sneaking Lisp back into corporate America!
There are 16 "talks" mentions as of this writing, yet I want to reiterate how important, insightful, useful and fun his talks are and watching them have been. They move a listener to a (next level). Good luck, Rich! Have a nice time in a hammock :)
Congratulations Rich! Your talks are a wellspring of inspiration, and I consider you a software “hero” (the good guys vs the locking concurrency monster).
I’ve been enjoying the fruits of your labors for more than a decade, and I have since introduced my daughter (a budding computer science student) to “simple made easy” and a bunch of your other talks.
Thanks for everything you’ve contributed to the software world. It’s a happier place to be as a result of your efforts.
This is probably great news for clojure devs. It sounds like Rich just wants his autonomy back. Being able to choose exactly what you do, and do not, work on is precious.
Clojure has changed my whole career, and many of Rich's talks directly inspired my thinking about large systems. I hope retirement gives Rich the best Hammock Time!
Your work on Clojure and other projects has been truly influential, and your talks are some of the best out there. I remember watching your "Simple Made Easy" presentation and being blown away.
The impact of Clojure cannot be overstated. It's amazing to see how far it has come since its inception. You've inspired so many developers, including myself, to explore functional programming and think differently about software design.
Problem-solving by Cognitect's standards has transformed Nubank and my approach to work. Thank you for your time here, Rich. I greatly appreciate the knowledge I've gained while collaborating with your Cognitect colleagues.
Thanks a ton Rich, Clojure is a real breath of fresh air in programming languages. I hope it continues to influence progamming for years to come, looking forward to seeing what you come up with in the future!
Rich, thank you for creating and maintaining a tool that has helped me build a successful SaaS business. I could not have done this without your work and your insights. I also learned a lot from your talks, and I do hope to meet you again at one of the Clojure conferences.
I think Clojure is a good fit in a lot of SaaS applications, especially those that are complex. It helps in dealing with complex problem domains, and lets you reuse the same code on the client side (through the magic of ClojureScript). Small benefits accumulate, and while it's possible to write anything using any language and tools, Clojure reduces the amount of code and work that I have to do, thus enabling me to run a solo-founder business.
While I never took the time to learn Clojure in depth or use it for any serious project, I feel like I've been deeply inspired by Hickey's talks. A lot of the principles he promoted helped me so much in my career as a developer.
I, for one, and super excited to see how Rich and Clojure evolve post-Nubank. Clojure and Rich's talks greatly inspired me and improved my software thinking skills - I can't say thank you enough!
I look in envy at what Rich has achieved. I think we all have ideas of how we would like a language to be, but actually sitting down and doing it to Rich's extent is something else.
As a schemer there are so many small things I would like to change that put me off using it for my personal projects, but regardless I have really enjoyed contributing to other people's Clojure projects. It is not far away from what I would consider a good starting position for my own perfect language.
I started on the JVM in '97 at University. Damn I'm old.
The company I founded uses full stack Clojure for our product development (https://kpow.io).
We're a small team pushing through a big product roadmap at pace, love programming every day, no chance we'd have made it in Java (and I quite like Java).
Thanks Rich (and Stu, and Alex, and Fogus, and David, and..)!
i’m very grateful to rich for clojure, cognitect’s libraries/tooling, and datomic. all of these have been well maintained, stable, and backwards compatible over the years.
although he’s no longer working on datomic, i really hope cognitect values growing it. it feels like such an improvement over sql to work with.
Could not disagree more strongly that Datomic is well maintained. I'd view it as a significant liability in any organization using it without very good reason. My experience operationally supporting Datomic at even a moderate scale was a total nightmare and soured me on the Clojure ecosystem as a whole.
may i ask what you consider moderate scale in terms of daily/concurrent users? i’ve had no issue with small projects, but i’m curious to know where it starts falling over
Thanks for sharing your ideas with all of us Rich. I've only dabbled in Clojure but like many others I've found the language and your talks and ideas inspirational and exciting. A rare example of successfully simplifying things, referring to your deservedly famous talk.
Best of luck in what follows! Clojure was the first Lisp I had ever learned. It was really easy to pick up and be productive with. It was data science I tried to use it for where it quickly runs into a myriad headwinds but it is a beautiful language all the same.
Thank you very much for your work Rich. I've seen your talks in person a couple of times and really admired the immense clarity of thought in every one of your ideas. And thank you very much for giving us Clojure - lots of fun memories.
I got to work in clojure for two years and it was one of the most useful experiences of my career. I still "think in clojure" even now writing Python, Java, and Go. I can't wait to use it professionally again someday.
i'ved only dabbled in clojure/lisp, but i've heard many lisp programmers talk about "thinking in lisp". can you share some of the particulars of what that means and why thinking in lisp/clojure is beneficial?
From my experience with Clojure, and how it changed my thinking:
1. I stopped thinking about OOP, classes, “patterns”, frameworks, and mostly think about what data flows through the program, how it’s (they’re?) transformed and stored. It’s a much clearer view of a system, I think.
2. I started being very conservative about mutable state. I keep mutable parts few and mostly on the top level, and compose program logic from practically pure functions. It helps with debugging issues immensely, and fewer issues arise because pieces can’t interact unpredictably.
3. I stopped caring about types/shape of data inside modules, and spec the hell out of it on module boundaries. IMO static typing is too strict for the former use case, and too loose for the latter. It allows more flexibility in implementation without actual breaking changes.
4. I now enjoy developing in REPL, updating a running program, adding features in real time. It feels so natural.
Amazing news. I saw a video cast of Rick during a meeting @ NuBank, and it looked like corporate life had sucked the life out of him [1]. So, I'm glad he got out of there, and I hope he's able to shake it off like a bad dream. Building something like Clojure require radical thinking, and creative freedom. I can only imagine how trying to fit that into your weekly scrum sprint would be draining. And in the monthly meetings where they recite the corporate values.. shivers
After two years at Cognitect (pre-nubank), I can say that his talks are more subdued than his usual way of speaking (in slack, at least). He's not as mild-mannered as he appears.
Observing a public figure and expressing concern that their workplace doesn't align with their passions isn't prying into their personal life, or speculating about their mental health. What I'm saying is: NuBank is where hopes and dreams go to die, and corporate life more generally. It's not about being "on" or "off" but about being in an environment one can thrive.
Funny, I too thought of that very video the moment I’d read the news. Rich was barely managing to feign just enough engagement without appearing rude. Happy he has escaped.
Congrats Rich! You've been a big inspiration to go off and try new things, and to not be afraid to explain and explore the nuanced underpinnings of your design.
Watching Rich Hickey's talks turned me from a "software is a grind" kind of a guy into a "software can be beautiful". Highly recommend watching every single one of his talks if you are a young programmer. It doesn't matter if you end up using Clojure or not - his philosophies and enthusiasm are infectious.
we used clojure on a pretty big project. We made the decision to rewrite in java after it became clear that some fairly big libraries we were using weren't being maintained.
It was contentious, but I'm glad we dumped clojure.
No matter how good a project is, it needs loads of support behind it
Rich has to be my favorite thinker in this space, absolutely love his talks and the way he articulates things, and I often draw from his philosophies in my work
But, I've always been turned off to Clojure by the lack of static typing (I know spec exists, but it's not really the same thing). I did a little project once to try it out, and even there I found myself spending time debugging basic issues like passing the wrong number or wrong kinds of arguments to functions
Can somebody sell me on it? I feel like I'm the target audience
It's a matter of habit. Once you get used to it, you quickly know how or why it happens and where (especially when you follow the correct workflow, see below).
Modern editors/IDEs help a lot with the typos and wrong number of args.
Some advice I would give myself when I started learning Clojure:
Think not in types, but in data. It's a different model that requires an 'aha' moment, but it's revelatory when you do get it.
If you come from an OO language, think not in objects (Elephant), but in information about objects (elephant's record, a map).
Clojure is best served REPL driven.
You can technically compile and execute, but this is not how the language shows its power.
Here's how I use it:
I evaluate code in the REPL as I write it, reload definition on every change.
Inside a `comment` block, I call the function I'm writing with the required arguments. I can quickly test how my function behaves in corner-cases.
You then construct another function, which calls the first.
You evaluate/execute the function as you write it.
So your program keeps growing, while you keep running/changing individual parts of it.
Once you get the hang of immutability and working with maps/collections, this process becomes very engaging because of the short feedback loop between thought and result.
yeah REPL driven development is pure joy. Even back when i was a JS developer i was developing a lot of my algos in devtools and then copying them to code.
It’s like having a conversation with your program while you are developing it.
I am myself not 100% sold on it, except immediately after any Rich talk (honestly, that man could sell me anything :D), but it was eye opening to me that static typing is not an end goal in itself -- it might be a local optimum, but there are many more things it can't express than it can.
Also, in case of Clojure you usually handle FP code with no side effects, written in a REPL-driven, interactive style. This combination is not as prone to typing errors in my opinion than "traditional" dynamic languages like Python and JS.
Another aspect might be the one being touched in the 'Maybe Not' talk: Static types operate on a closed-world basis, where the sum of all relevant code is available at the same time. While this is common for certain kinds of programs, it is not really true of systems which have to interoperate with services owned by different companies alltogether, having to support many different versions of other interfaces at the same time. In that case you want to be liberal in what you accept, and arguably, dynamic types are better fit for this job. I am not 100% sold on this part, mostly just reiterating what I've seen others claim, notably Oilshell's author is a big proponent of this thought.
I have the same reactions to his talks. Yet, long term, I've never been able to convince myself that clojure, common lisp or more popular ruby/python, are good choices for me in case of long running projects.
I'm not sure how being liberal in what you accept is at odds with static typing. Static typing is about encoding the rules and shapes of the data that your program *knows* how to work on. It's not preventing some other data that you don't care from existing alongside.
Even if I'm missing something, that doesn't change the fact that in most static typed languages you can fallback to some sort of "any" types. Seems to me it's better to have option to use static or dynamic types in the same program, instead of being forced to do *everything* in dynamically typed way.
Well, spec is there, so it is not only typed vs untyped but static types vs contracts. With the added ability to generate test data, I think the field is much more equal, but as I said, I also tend to fallback to statically typed languages, but that’s mostly just out of conform.
It is difficult to explain why, but there is actually a positive case to be made for dynamic typing. Their benefits are real but a lot less immediately apparent than the benefits of static typing. I think this article from Eric Normand captured some of it https://ericnormand.me/article/clojure-and-types. In my opinion languages like TypeScript where the type system is only a verification system and has no effect on the runtime, combined with its emphasis on structural types, existence of union/intersection types, etc, go a long way towards reducing the downsides of static types but not completely.
As someone who's written at least as much code in dynamically typed languages (Lisp, Clojure, Python) as static, I find this question interesting because I really don't know how we know what types to pass. I think a big part is naming and following conventions. But honestly, somehow, I don't think I've ever had problems figuring out or passing the wrong types to anything.
I wonder if he’ll still give talks. I don’t blame him if not, but he’s really good at it.
“Simple made easy” was a classic even if everyone proceeded to ignore the practical advice contained therein. And “Maybe not” is my personal favorite, a great discussion of requirements/provisions and the downsides of option types.
Because of your comment, I watched this for the first time. I agree that it deserves a spot in the classics.
For those who haven't seen it, in the presentation Rich talks about figuring out the problem before you work on a solution. It's definitely something that could be improved in myself and in a lot of people and organizations involved in software development.
I'll never forget "gem install hairball" during his talk "Simplicity Matters" at Ruby Conf 2012 where he basically told the Ruby community they were doing it wrong.
Yep, the guy has a gift. I've never touched a line of Clojure or looked at Datomic, but I'm repeatedly inspired by Rich's talks, which I come back to often.
Maybe Not is an excellent video in some ways, but I just watched it a few years later and it reminded me that as much as I love almost every Rich video, I do wish he'd spend some time reading a little deeper on type systems and theory.
For example his note about "Categorical descriptions" and then the explanation about maps/and spec at 25:00[1] seems to indicate he's unfamiliar with the difference between extensional and intensional type theory.
The core difference between the two is extensional type systems decide equality on the observable behavior of the output. For example if two functions take the same input, and produce the same output extensional type systems/theories say they are the same. The problem with this is type equality is then undecidable.
Extensional type systems also struggle because there are more than one way things might be equal! For example two string might be equal if you ignore case, but unequal if you don't. So if we want our type system to check if two functions are equal under case insensitivity an extensional type system will struggle with this.[2][3]
Now in fairness to Rich, these concepts come more from the math community, especially the notion of types being equal under different paths, and in the case of Homotopy type theory are burred in unapproachable language and concepts... even by mathematicians standards.
He also talks about select from spec, and it not preventing you from passing types broader types, and the necessity of specifying deeper type.[4] But, that's just an eliminator defined on the type[5].
Now most strongly typed programming languages suffer from the issue he identifies when talking about not making brittle systems [6] and the issues you get with coupling around taking a map/struct/product type C = A X B (e.g a map C = {A: something, B: something}), and you require A so you're function should be good but you fail to compile because the function says A, and now you're passing C.
It's frankly pretty annoying in places like Java that if you have a Point = Int x Int y you can't use it in functions which take a Tuple = Int x Int y. I'd actually say that's the common observation that both Rich, the Go Inventors, and the TypeScript folks have all made. You need to care about the extensional type of your input (and output) fairly often. And carring around the intensional type causes both dependency issues and just some general PITA's.
I will also say I used clojure + aleph to write the only significant application I ever released which never had a reported bug or outage. It ran for seven years and that application was under constant heavy load (more than 10k TPS).