Simple Made Easy (2011) [video](youtube.com) |
Simple Made Easy (2011) [video](youtube.com) |
This has led me to his other talks which are heads and shoulders over most comparable content. I have learned more and found more enjoyment & enlightenment in the line of thinking he presents than the alternatives. Not shitting on anyone, just giving credit where credit is due. If you are open and willing to learn and come from a "traditional" background I think you will have your mind expanded like me.
Thank you Rich! ;-)
Simple Made Easy (2011) - https://news.ycombinator.com/item?id=23905051 - July 2020 (30 comments)
Simple Made Easy (2011) - https://news.ycombinator.com/item?id=13660797 - Feb 2017 (36 comments)
Simple Made Easy (2011) - https://news.ycombinator.com/item?id=13313398 - Jan 2017 (2 comments)
Rich Hickey: Simple Made Easy - https://news.ycombinator.com/item?id=4173854 - June 2012 (42 comments)
Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video] - https://news.ycombinator.com/item?id=3135185 - Oct 2011 (99 comments)
I.e., my code is simple--and that might make your usage complex.
Of course, things can evolve from the original implementation--especially if the code is maintained by a team. What was once 'simple' (from any perspective) can become terribly appendaged yet never renamed.
It's a great talk, but it's like nobody is allowed to say "simple" anymore without mentioning Rich Hickey.
See, I just did it and didn't have to mention Rich Hickey.
I remember watching the original "clojure" talks during Christmas break too.
At least it's a found memory that I keep, as opposed to all the troubles getting a somehow functioning clojure dev environment set up back in the day... For all my whining, it has actually got better nowadays, although I still don't know if it's acceptable to use lein as opposed to boot as opposed to deps.edn as opposed to [insert tool].
I don't think I'll ever professionally work on a things where the costs of clojure (training / mental reshaping / startup performances / etc...) will be worth the benefits (using a map of tuple to sets of immutable records and solve a gnarly problem in 10 lines and 50 parens.)
But as other said, the sermons _do_ change how you program in any language.
(I just wish I understood what in meant in "Effective Programs" by "typos are not important". They are, aren't they ? A typo is a runtime error begging to occur during the demo, how is that "not important" ? Never mind.)
I would advise to immediately go watch anything from Muratori or Blow to get the exact opposite perspective, pounder the fact that they are _both_ right and wrong in their own ways.
And go back to writing typescript like everyone.
They are going to create an error that you can see and fix immediately, in the vast majority of cases. Certainly in compiled languages (like clojure), but less so in interpreted languages like python, where a misspelled variable in a hidden part of the code may not cause an exception until that part of the code is run.
At least, that's my understanding of what he means by typos being less important than other types of mistakes.
By the way, when I saw his comment originally I was surprised too. But when comparing to the other kind of mistakes he talks about I realized that, yes, I'd rather have a typo than any of the other problems! Though of course, I'd prefer to have none :)
(Now, maybe it's PTSD from that time a typo in a script botched a demo in front of important people, and, well, let's say I avoided a bunch of scaling / domain complexity / temporal cohérence / etc... issues by not having to work on the thing any more ?)
Each to their own. There's room for everyone.
https://gbracha.blogspot.com/2022/06/the-prospect-of-executi...