I find it interesting that Python, despite being widely described as a simple language, takes the opposite approach. The language isn’t simple at all , it prefers to make things easy. This preference even appears (in the contrapositive) in the “Zen of Python”: “Complex is better than complicated.”
As a specific example, Python 3.7 introduced dataclasses, making them dependent on type hints when they could have been completely orthogonal. The language design ignored this talk’s advice against “complecting” features.
> I wrote a #clojure program for logic A in 4 hours. I've been asked to rewrite it in #python because of some product requirements. It's been 3 days since i've started and still on the first 25% of it. Note: I'm using python for more than 13 years.
Check any Clojure forum - clojureverse, clojurians slack, mailing-list. Talks from conferences. Clojure/conj , ClojureD, ClojureX, etc. Click around, check the profiles. Then you'd probably see that majority of Clojure users are not that young. Most of them come to Clojure after learning other, very often multiple programming languages. Many of them have tried all sorts of different tools before finally discovering Clojure.
You see it over and over again, people claiming that Python, and other popular PLs have little to offer in comparison to Clojure ecosystem. And your only explanation is "it's a cult"? Yeah, sure. Clojurists are just a bunch of losers who simply failed to learn Python. It is a pretty cool cult to be in, it is based on ideas endorsed by people like Guy Steele, Gerald Jay Sussman, Paul Graham, Matthias Felleisen, Brian Goetz, and many others.
Gosh, I remember when JAVA was like that!
What are you talking about? Walmart has built their receipt processing in Clojure. Apple uses it (afaik for payments processing). Cisco has built their entire security platform in Clojure - security.cisco.com. Funding Circle has built their peer-to-peer landing platform in Clojure. Nubank - the largest independent digital bank in the world and sixth-largest bank in Brazil been using Clojure extensively. There are many other companies very actively using Clojure. Pandora, CircleCI, Pitch, Guaranteed Rate, etc. It's even used at NASA.
It's a the third most popular JVM language after Java and Kotlin, and the most popular alt-js PL (if you don't consider Typescript as alt-js). It's the most popular language among PLs with a strong FP emphasis - it is more popular than Haskell, Elm, Idris, OCaml, Erlang, Elixir, F#, Purescript, and (recently) Scala.
Clojure is very ripe for the prime-time. The ecosystem is really nice. A lot more nicer than most other languages. It is an extremely productive tool. But of course skeptics be like: "but it's dyyying ...", "it ain't popular ...", "but all those parentheses ...", "it's a cult ...", etc.
See the first graph at https://clojure.org/news/2020/02/20/state-of-clojure-2020 where you can see what portion of respondents have reported using it for work over the years.
One of the most entertaining ones I watched was "Spec-ulation". It is less general than some of the more shared/cited ones but really funny.
I highly recommend giving the talk a listen to.
2) simple code is easy to read, but hard to write.
If you're a programmer, and you're not surrounded by people conflating both words, consider yourself lucky. What does a coworker really means by "I did the simplest possible thing" ?
For example, for me, statement 1 is false. Simplicity is also subjective
I am one of the people conflating the terms.
Are they used from the devs pov? Like what's easiest for you (add one more parameter to this function or another special case handled with its) might make things more complicated.
From the customer pov simple or easy is the same, or?!
Simple = One thing not 'mixed - linked - folded' with anything else. That's why he says it is objective - if you look at something and see it's mixed up with something else, it's not simple (in his terms, now it's complex - eg many things woven together)
Easy = Near to you. Near in as you know it already, or you have it already and so on.
His talk is for the dev pov, but even outside of dev, simple does not mean easy all the time.
For example, (and something I am struggling with right now) it is simple to lose weight - eat less calories than you burn each day. Simple.
But I can attest it is far from easy.
He claims that certain (often popular) tools and practices adhere to ease rather than simplicity, which introduces accidental complexity. And he introduces term „to complect“ which is now widely used in the Clojure community.
Many of the concepts and comparisons he talks about can be found in the design of Clojure and Datomic.
I personally often picture complexity as a graph of nodes and edges:
- The more edges you add, the more complex the thing it describes.
- The more rules you can deduce about the graph (for example "it is a unidirectional circle-like") such as the flow of the edges, counting etc. the less complex it is.
The imagery in the talk describes it similar: Complexity is more knotted and interwoven. Simplicity is more straight-forward, clear and composable.
Ease is described as something being "near", also in the dimension of time. Something you already know or can learn/do quickly.
The talk goes on describing how simplicity requires up-front investment and time to achieve and also how ease and simplicity sometimes overlap and when they are at odds.
Maybe Hickey just didn't prioritized "types" as high as some other ideas to spend his time on. And in my opinion he focused on the right things and achieved something really great.
As general advice stay positiv, focus on the things you like instead of telling everyone what you don't like, it's better for your mental health ;)
I think this statement is unfair.
I don't think there is a widely used statically typed language that is nearly as expressive and simple as spec. Also the opt-in nature of it retains the advantages of dynamic typing.
Is it some kind of paradigm that exist in Clojure but not in procedural languages?
Stuff like this is not specific to clojure, however it would be harder to have an embedded rules system in your language if its not a lisp. You'd probably have have to resort to a string based DSL (something like drools in java).