Chas didn't really explain why we'll love it anyway. On the more general note, I believe programming language philosophy is bifurcated into two groups: 1) those who believe a good programming language is chockful of "good" features, regardless of the complexity that may result; and 2) those who believe a good programming language is small, simple, easy to learn, easy to use, flexible, extensible, and productive. The software industry has obviously followed the first group. That's why we have large complex languages like C++, Java, JavaScript, C#, Scala, Rust, Swift, etc., and fairly complex languages like Python, Ruby, Clojure, Kotlin, TypeScript, Dart, etc. I prefer the second group which enjoy small simple languages like Smalltalk, Scheme, Go, Lua, etc. My favourite small, simple, easy to learn, easy to use, flexible, extensible, and productive programming language is Smalltalk. It's a timeless classic. In fact, this year Smalltalk celebrates its 50th anniversary: - ruclips.net/video/MDgbUCtCKak/видео.html - ruclips.net/video/TQQ1oXM7Nms/видео.html
@@apestogetherstrong341 why do you say that? i find go to be a small, simple language, particularly when you start doing concurrency. every other language i've tried has seemed to offer lots of non-orthogonal functionality for this.
We need to create a programming language that reads and writes like English. It would be a reduced set of English expressions library, that would be paired with verified functional codes in the background. Or I had the idea, that the comments would be translated to viable code. So you can use the comments to actually write code.
People have been saying things like this since the dawn of programming. Thing is, English is a ridiculously complex language and by the time you distill it down to the point at which you have something consistent and logical it'll be no better than any existing, declarative language (e.g. SQL).
Having seen COBOL in a professional environment this is probably not going to work out like you'd hope. Even the syntax for SQL is garbage due to optional noise words. Do you really want to say ADD NUMBER TO NUMBER2 GIVING MYRESULT. Because that's exactly what adding 1 + 1 looks like in COBOL. (OK you can use COMPUTE clauses but that's newfangled) On the up side you can write fun stuff like ADD PAIN TO SUFFERING GIVING EMPLOYMENT. STOP. RUN.
Mathematicals notation have been invented to reduce verbosity (when there was still no computer) "one plus one equals two" vs "1+1=2" Going back to full verbosity is not an evolution at all Yet I understand your point that sometimes code can be very hard to decode, but in those cases that means that writting it fully verbose would take so much space that the burden would anyway be superior to the burden of understanding all these symbols. The key lies more in having no more symbols than needed to express a program, and clojure is a very good language in that direction.
Among human languages English is a terrible one in several obvious ways. Human languages also have a completely different purpose from programming languages. Fortunately, it's very easy and fun to learn programming languages vastly different from each other, and I fail to see any advantage at all in trying to make a programming language resemble English. A partial attempt to do so was SQL, called a 'fourth generation language'; so ugly, imprecise, and awkward that things like knex keep being developed to avoid having to use it.
i think one of the problems is that human languages like english are extremely ambiguous. we only understand what is being said because we know so much about the world and assume huge amounts of context that is only supplied by our experience. computer languages need to be unambiguous.
If this is the worst parts of Clojure then I am sold. The issues are not even that bad when compared to what I am used to in JS and especially Java.
I thought Chas has got away from clojure, glad to see him around :)
He did, this talk is from 2012.
Maybe if Clojure sucked a bit less, he would have stayed
Thank you!
This says published in 2020, but was it recorded much earlier? It mentions Java 7 and Clojure 1.5 seeming as "new" releases.
This is old video from infoq.
@@zhangjian3654 Makes sense! Still good info
Chas didn't really explain why we'll love it anyway.
On the more general note, I believe programming language philosophy is bifurcated into two groups: 1) those who believe a good programming language is chockful of "good" features, regardless of the complexity that may result; and 2) those who believe a good programming language is small, simple, easy to learn, easy to use, flexible, extensible, and productive.
The software industry has obviously followed the first group. That's why we have large complex languages like C++, Java, JavaScript, C#, Scala, Rust, Swift, etc., and fairly complex languages like Python, Ruby, Clojure, Kotlin, TypeScript, Dart, etc.
I prefer the second group which enjoy small simple languages like Smalltalk, Scheme, Go, Lua, etc.
My favourite small, simple, easy to learn, easy to use, flexible, extensible, and productive programming language is Smalltalk. It's a timeless classic. In fact, this year Smalltalk celebrates its 50th anniversary:
- ruclips.net/video/MDgbUCtCKak/видео.html
- ruclips.net/video/TQQ1oXM7Nms/видео.html
Go is the first group. It only deceives you to believe it is simple
@@apestogetherstrong341 why do you say that? i find go to be a small, simple language, particularly when you start doing concurrency. every other language i've tried has seemed to offer lots of non-orthogonal functionality for this.
Clojure rock!!
so did I miss it? where's the "You'll Love It Anyway" part?
😂
Clojure is tough to love in 2021. So many better options out there.
@@ZelenoJabko illuminate, please?
@@kiana5066 u mean enlighten?
@@02orochi i mean "sho mi da wey, brada"
Thanks!!
We need to create a programming language that reads and writes like English.
It would be a reduced set of English expressions library, that would be paired with verified functional codes in the background.
Or I had the idea, that the comments would be translated to viable code.
So you can use the comments to actually write code.
People have been saying things like this since the dawn of programming. Thing is, English is a ridiculously complex language and by the time you distill it down to the point at which you have something consistent and logical it'll be no better than any existing, declarative language (e.g. SQL).
Having seen COBOL in a professional environment this is probably not going to work out like you'd hope. Even the syntax for SQL is garbage due to optional noise words. Do you really want to say ADD NUMBER TO NUMBER2 GIVING MYRESULT. Because that's exactly what adding 1 + 1 looks like in COBOL. (OK you can use COMPUTE clauses but that's newfangled) On the up side you can write fun stuff like ADD PAIN TO SUFFERING GIVING EMPLOYMENT. STOP. RUN.
Mathematicals notation have been invented to reduce verbosity (when there was still no computer)
"one plus one equals two" vs "1+1=2"
Going back to full verbosity is not an evolution at all
Yet I understand your point that sometimes code can be very hard to decode, but in those cases that means that writting it fully verbose would take so much space that the burden would anyway be superior to the burden of understanding all these symbols.
The key lies more in having no more symbols than needed to express a program, and clojure is a very good language in that direction.
Among human languages English is a terrible one in several obvious ways. Human languages also have a completely different purpose from programming languages. Fortunately, it's very easy and fun to learn programming languages vastly different from each other, and I fail to see any advantage at all in trying to make a programming language resemble English. A partial attempt to do so was SQL, called a 'fourth generation language'; so ugly, imprecise, and awkward that things like knex keep being developed to avoid having to use it.
i think one of the problems is that human languages like english are extremely ambiguous. we only understand what is being said because we know so much about the world and assume huge amounts of context that is only supplied by our experience. computer languages need to be unambiguous.
I agree it sucks very much.