I think that at least some of Clojure's success has to be attributed to Paul Graham. Its not that Graham had any part in Clojure development, or that Hickey "stole" ideas or any such nonsense, but Graham was promoting the notion that lisp was a massive missed opportunity by the software engineering community. He was promoting Lisp at a time where lisp was largely dead, and so the idea that a new lisp was necessary was passed around at around the same time that Rich was developing Clojure. So essays like "Beating the Averages" really solidified in people's minds the idea that there was reason to invest in Lisp. It kind of laid down the kindling that Clojure would later need in order to catch fire. Not saying this to give Graham credit for anything he didn't do. Just explaining how I personally saw Clojure. I read Graham's essays, heard the stories about how amazing Common Lisp was, read some of the books that were being published at the time about Common Lisp - which was understood to have serious issues. All that kind of primed the pump for me to become interested in Clojure. I suspect I was not alone in that.
Great point. I was a huge fan of PG's essays and read Beating the Average soon after it came out -- the "paradox of Blub" stuck with me ever since and floats back into my mind whenever I speak with managers who think in terms of a "lowest common denominator" software development environment, to maximise interchangeability of programmers, on the faulty assumption that it really doesn't matter what programming languages or tools you use, so you should pick the one that's "easiest to hire for".
Both Paul Graham and Peter Norvig pointed people to Clojure as a practical lisp to learn as soon as it started gaining momentum. Also worth mentioning that both Scala and Clojure benefited from changing processor architectures and distributed cloud applications and the need for parallelism and concurrency respectively in these situations, especially as both javascript and python really struggled to get out of single-threaded limitations and the OO java concurrency constructs made people feel like they needed a PhD to get it right. Both Clojure and Go are two philosophically divergent examples that emerged out of this environment because of the greatly improved experience of handling concurrency.
I'm really glad to see you safe and sound, Sir. Please don't abandon the community and Clojure. Thank you for your contribution to us humanity trying to model this universe parts in our software. Managing complexity (or simplicity) is quite tiring...
@@basilpalichev6732 yea he retired from "commercial software development". Also: "I look forward to [...] maintaining and enhancing Clojure [...] as an independent developer once again." (source: clojure website, news section, August 4th 2023)
@@basilpalichev6732 yea he retired from "commercial software development". Also: "I look forward to [...] maintaining and enhancing Clojure [...] as an independent developer once again." (source: clojure website, news section, August 4th 2023)
Great journey. I'm happy to say that since 2016 I am able to for 99% of the time write clojure for a living. First as a consultant, now as a founder of a Saas Company. Thanks Rich for all that you started. I was so done with Java back then, and I am now pretty evangelical (even though i hate that generally) about how things are done in Clojure, and by what rationale. Aside; love the guitars and instruments :-)
Or as he said at 34:06 : experienced developers who are tired of it :-) Not that I was that experienced, but appearantly experienced enough to be tired of it :-)
It's been over ten years since I first saw one of Rich's talks, while searching for whatever happened to lisp and scheme. I think the biggest eye-opener was seeing how bad the foundations of modern programming were. When the world saw that they had made a wrong turn, most of them just kept going instead of stopping to look at the map.
Once you've programmed 50 recursions you can do it in your sleep. I'm self taught and I went from VB to scheme. When Hickey says this poses a problem for professional programmers it makes me wonder what they do all day.. :)
One of the questions was about languages introducing optional typing, Python was given as an example but also JavaScript but the fact is that JavaScript is not moving towards static typing as this question was stating. There are other languages that have optional typing and are aiming to replace JavaScript like TypeScript, etc. but JavaScript itself has not been introducing optional typing, that's a very false claim. BTW. Great to hear Rich Hickey speak about Clojure and programming, it is always a treat.
Thanks for a wonderful video. I'm curious what he meant here: czcams.com/video/nD-QHbRWcoM/video.html "I wanted to fix that aspect of lisps of it being built on abstractions... I wanted to redo that and try to put abstractions at the bottom" In what was are older lisps built on abstractions?
I am getting confused about this tbh. I thought that Lisps helps us build little languages that raise the level of abstraction so that we can model the problem domain on its own terms. That is the whole appeal to me of Lisps and powerful languages in general. Does he mean that to make powerful higher level abstractions more foundational after they have been found out? Or that traditional lisps low level was too low level (e.g. seqs are more general than lists and therefore should be at the bottom, primitive layer)
I think he means he wanted to make a Lisp built on abstractions instead of "concretions" . A quote from another talk of his: "But Lisp had a bunch of things that needed to be fixed, in my opinion. It was built on concretions. A lot of the design of more abstractions and CLOS and stuff like that came after the underpinnings." github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/EffectivePrograms-mostly-text.md The point being that the way you work with the basic datastructures in Common Lisp depends heavily on their underlying implementation. Instead, you want an abstract interface on top that doesn't care whether your lists are made up of cons cell or arrays. Contrast this with Clojure, where every sequential data structure has the exact same interface, ("first", "next", "more", "cons").
STILL the best hair in programming.
Every one of Rich Hickey's talks are wonderful!
I think that at least some of Clojure's success has to be attributed to Paul Graham. Its not that Graham had any part in Clojure development, or that Hickey "stole" ideas or any such nonsense, but Graham was promoting the notion that lisp was a massive missed opportunity by the software engineering community. He was promoting Lisp at a time where lisp was largely dead, and so the idea that a new lisp was necessary was passed around at around the same time that Rich was developing Clojure.
So essays like "Beating the Averages" really solidified in people's minds the idea that there was reason to invest in Lisp. It kind of laid down the kindling that Clojure would later need in order to catch fire.
Not saying this to give Graham credit for anything he didn't do. Just explaining how I personally saw Clojure. I read Graham's essays, heard the stories about how amazing Common Lisp was, read some of the books that were being published at the time about Common Lisp - which was understood to have serious issues. All that kind of primed the pump for me to become interested in Clojure. I suspect I was not alone in that.
Great point. I was a huge fan of PG's essays and read Beating the Average soon after it came out -- the "paradox of Blub" stuck with me ever since and floats back into my mind whenever I speak with managers who think in terms of a "lowest common denominator" software development environment, to maximise interchangeability of programmers, on the faulty assumption that it really doesn't matter what programming languages or tools you use, so you should pick the one that's "easiest to hire for".
He also literally recommended Clojure multiple times when people asked him which Lisp to use.
Both Paul Graham and Peter Norvig pointed people to Clojure as a practical lisp to learn as soon as it started gaining momentum. Also worth mentioning that both Scala and Clojure benefited from changing processor architectures and distributed cloud applications and the need for parallelism and concurrency respectively in these situations, especially as both javascript and python really struggled to get out of single-threaded limitations and the OO java concurrency constructs made people feel like they needed a PhD to get it right. Both Clojure and Go are two philosophically divergent examples that emerged out of this environment because of the greatly improved experience of handling concurrency.
I agree with you, Paul Graham's essay drove interest for me in Clojure. He does get some credit.
"Clojure... it's adequate" - Rich Hickey
I'm really glad to see you safe and sound, Sir.
Please don't abandon the community and Clojure.
Thank you for your contribution to us humanity trying to model this universe parts in our software.
Managing complexity (or simplicity) is quite tiring...
He has retired though 😅
@@basilpalichev6732 yea he retired from "commercial software development". Also: "I look forward to [...] maintaining and enhancing Clojure [...] as an independent developer once again." (source: clojure website, news section, August 4th 2023)
@@basilpalichev6732 yea he retired from "commercial software development". Also: "I look forward to [...] maintaining and enhancing Clojure [...] as an independent developer once again." (source: clojure website, news section, August 4th 2023)
@@basilpalichev6732 he retired from "commercial software development". But he still maintains and improves Clojure.
Great journey. I'm happy to say that since 2016 I am able to for 99% of the time write clojure for a living. First as a consultant, now as a founder of a Saas Company. Thanks Rich for all that you started. I was so done with Java back then, and I am now pretty evangelical (even though i hate that generally) about how things are done in Clojure, and by what rationale.
Aside; love the guitars and instruments :-)
Or as he said at 34:06 : experienced developers who are tired of it :-)
Not that I was that experienced, but appearantly experienced enough to be tired of it :-)
Finally, I miss having hickey talks. The changed me.
You are immutable by default bro
Like you fkn know him lmaooo stfu
It's been over ten years since I first saw one of Rich's talks, while searching for whatever happened to lisp and scheme. I think the biggest eye-opener was seeing how bad the foundations of modern programming were. When the world saw that they had made a wrong turn, most of them just kept going instead of stopping to look at the map.
Clojure made me a better functional programmer.
Really enjoyed the answers to the questions~
I ❤️ Clojure!
thx for sharing
Nice!
Rich is musician, Clojure is a musical instrument.
Someone please tell it to him.
Read your comment.
Looked at the room behind rich.
I think he knows.
He touched on this topic in his talk "Design, Composition and Performance".
i love clojure and clojurescript
Thanks!!
Nice shout out on smalltalk
我在想, 纯函数和不可变性作为设计原则, 是能替代一些类型系统的逻辑控制功能. 类型也无非是数据上的谓词.
Question from @CodeReport at 54:30
我运气还挺好的, 2008年那会的小情人跟我说MIT的学生都学Scheme入门, 那会还没有Clojure呢, 我是2010年左右学的Java, 后来突然就发现Clojure了, 还奇怪这东西怎么早没有, 原来是还没有被发明出来啊. 然后写了几年Clojure, 顺便连数学证明的问题都解决了, 已经玩上Cubical Agda, 连本科时候一头雾水的理论物理也被安排的明明白白.
Would adding tail call optimisation break backwards compatibility? If somehow the JVM gained TCO would there be an obstacle to adding it to Clojure?
no. it would be easy to add it.
"Somehow" is called Project Loom and it's in development.
Once you've programmed 50 recursions you can do it in your sleep. I'm self taught and I went from VB to scheme. When Hickey says this poses a problem for professional programmers it makes me wonder what they do all day.. :)
for loops that mutate accumulator vars, haha.
One of the questions was about languages introducing optional typing, Python was given as an example but also JavaScript but the fact is that JavaScript is not moving towards static typing as this question was stating. There are other languages that have optional typing and are aiming to replace JavaScript like TypeScript, etc. but JavaScript itself has not been introducing optional typing, that's a very false claim.
BTW. Great to hear Rich Hickey speak about Clojure and programming, it is always a treat.
Zenlisp for my personal data. I like the idea of Clojure but it lags too much on my pi.. :)
no it doesn't
I’m so sceptical about dynamic languages. But I am very curious about clojure
I think its great that Ted Haggard left worship business for programming langage podcast!
Thanks for a wonderful video.
I'm curious what he meant here: czcams.com/video/nD-QHbRWcoM/video.html
"I wanted to fix that aspect of lisps of it being built on abstractions... I wanted to redo that and try to put abstractions at the bottom"
In what was are older lisps built on abstractions?
I am getting confused about this tbh. I thought that Lisps helps us build little languages that raise the level of abstraction so that we can model the problem domain on its own terms. That is the whole appeal to me of Lisps and powerful languages in general. Does he mean that to make powerful higher level abstractions more foundational after they have been found out? Or that traditional lisps low level was too low level (e.g. seqs are more general than lists and therefore should be at the bottom, primitive layer)
I think he means he wanted to make a Lisp built on abstractions instead of "concretions" . A quote from another talk of his: "But Lisp had a bunch of things that needed to be fixed, in my opinion. It was built on concretions. A lot of the design of more abstractions and CLOS and stuff like that came after the underpinnings." github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/EffectivePrograms-mostly-text.md
The point being that the way you work with the basic datastructures in Common Lisp depends heavily on their underlying implementation. Instead, you want an abstract interface on top that doesn't care whether your lists are made up of cons cell or arrays. Contrast this with Clojure, where every sequential data structure has the exact same interface, ("first", "next", "more", "cons").
@@frwdrik Thanks! That makes a lot of sense to me. Thanks for helping me understand.