This is Clojure. It's functional, but more as a side effect of focusing intently on simple, immutable, persistent data structures and their compositions. I'd strongly recommend looking into it, along with many of the presentations by its initial author Rich Hickey.
I’d suggest you watch Rich’s talk “Simple made easy”. [1]
It’s one of his main points that something like a language being “hard to approach” can be overcome by spending a little effort to learn it (as opposed to sticking with something like Kotlin just because its easy to pick up because it’s familiar). The benefits of learning the unfamiliar (in his case, he’s speaking specifically about Clojure) being that it allows you to write code that is much simpler to reason about.
I have no particular beef with Kotlin (or most any languages... right tool for the job and all), but I have lately become infatuated with Clojure and many of Rich’s viewpoints.
Eh, I've used languages that were "hard to approach", one of my favorites (Erlang) is one of those (I use quotations especially because learning all of Erlang's syntax takes about a day).
This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems.
Picking up Kotlin or Clojure is not "harder to approach" by virtue of what's provided in this context, it's harder because Clojure syntax uses parenthesis.
Like that's literally it.
Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity.
I think a lot of developers feel "It looks funny" is not a fair critique of a useful tool, but just look at Erlang vs Elixr. I love Erlang, much more than I like Elixr, but Elixr gained mind share in large part because it's Ruby-like.
Cognitive overhead is lower working with a language that at least "looks like", what you're used to, and more developers know C-like languages, thus a language like Kotlin is "easier to approach" but necessarily "easier" in the way the presentation talks about
> Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity.
I don't think this is true. I think it would be easier for "most people," but definitely not simpler. Easy meaning close at hand, simple meaning one strand, one braid, independent, less context necessary. Clojure syntax is the AST of the program, right there in front of you, in literal notation. There are fewer special cases, fewer moving parts interacting. C syntax requires spinning up a virtual machine in your mind and executing multiple statements. C is easier because we've already spent the time and effort to familiarize ourselves with it, but it has more complexity. Compare a 954 line ANTLR grammar for C [1] with a 261 line Clojure grammar [2].
> Cognitive overhead is lower working with a language that at least "looks like", what you're used to, and more developers know C-like languages, thus a language like Kotlin is "easier to approach" but necessarily "easier" in the way the presentation talks about.
I would agree, using Rich's definitions of simple and easy, that Kotlin is easier for the majority of developers than Clojure. This follows immediately from the definition of easy.
> This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems.
I would recommend Rich Hickey's talk "The Language of the System" [3]. The programming language(s) used are part(s) of the system and have an effect on its design. I don't think this is a misapplication of the "Simple made Easy" presentation, I think it hits the nail on the head.
I feel like this comment is throwing semantics in a blender and pouring it out into the shape you want... but I guess that's the thing about arguing semantics, it usually devolves to that...
So I guess I'll just keep my recommendation to Kotlin and you can keep your recommendation to Clojure
That is very, very far from the truth. You obviously haven't probably tried Clojure.
I think, among all the languages being actively used in the industry (in business, not academy), Clojure perhaps can be crowned as the simplest of them all.
The ingenious of Rich Hickey was to design it the way that the essentials were made simple and complicated stuff either unnecessary or pushed onto the edges of the ecosystem.
Clojure can be learned à la carte - from the basics to more advanced things. Or if you want to dive straight into more difficult topics, you still can do it, and preliminaries would be minimal.
I can argue that Clojure is easier to learn than Kotlin, Python, Javascript, or Ruby. That is not a mere opinion - I know many people for whom Clojure was the very first language. And they tried to apprehend other PLs later, and it was a confusing and frustrating experience for them.
It is easy to start with Clojure. One simply needs to be less skeptical about things that people (mostly those who are unfamiliar with the language) criticize it for:
- They say, "It is hosted on JVM. JVM means Java, and I hate Java", and therefore ignore the fact that JVM is a very robust piece of tech, and you don't need to write any Java at all to use Clojure, you don't even really need to know Java.
- They say, "JVM has a slow startup time." But once you try Clojure's REPL (which is a real REPL, unlike in other, non-lispy languages), it becomes a non-issue.
- They say, "It is a Lisp, and parentheses look scary." But once you learn structural editing idioms, it becomes so frustrating to deal with all the punctuation in other languages.
- They say, "It is dynamically typed." But once you learn Clojure.Spec you may discover that you can do things with it, that most type-systems simply can't.
I encourage everyone to try to learn some Clojure, because it is fun.
Ha, I've used Clojure, see my thoughts above in the other thread.
By the way, I love Java, love Kotlin even more. Don't bring the JVM and other languages down to Clojure's level just because Clojure is clutching onto the JVM's coattails.
I couldn't answer in the other thread because your reply got downvoted (and rightfully so) and went "dead." I get it. You personally hate Clojure. The reasons though objectively, are your own personal and nothing to do with the design of the language.
You felt that Clojure doesn't bring any value. Well, there are thousands of people who think differently, not just me. I have grown to distrust fanboys, and even more so, haters. If you hate a programming language that consistently being ranked among others at the top of "the most loved" category, there's something wrong with your assumptions about that language.
Please don't waste your energy trying to write another lengthy comment. Your argumentation is flawed, but I won't spend my time trying to prove you wrong because you wouldn't see the truth even if it hit you right between your eyes.
Clojure notoriously known for attracting older, experienced, "grumpy" developers. Programmers with years of experience and seasoned in many other languages, because it simplifies many things. "Out of the Tar Pit" - as the phrase and as the widely known paper, accurately characterizes principles that Clojure has built on. And If your only take on the language (I quote your own words), is: "Clojure is a garbage language," then I guess I misjudged your programming experience level. Maybe you haven't struggled enough with other PLs to the point that it gets so tiresome you start thinking about retirement.
Please, how long of a response is there to a comment that boils down to:
"I have no concrete rebuttal so I'm going to refute your objective points about it's shortcomings with nonsense about retirement age programmers and whining you weren't nice while systematically listing all the things wrong with it and all the alternatives beat it at it's own game"
Java and Kotlin and Erlang (again, literally my "pet favorite language" since, predictably you're going "lalalalala you just dont get simple languages lalalalal") are all languages known to be used by programmers to make useful stuff, at a success rate much much higher than Clojure.
Offhand, I’d say “too much theoretical math in the starting and middle stages of mastering the language.” Syntax that is based around/descended from APL. Lambda calculus prominently featured in the learning process. Things like that.
It’s definitely a feel argument, and thus highly subjective.
I'm not a FP expert, but I do try to use FP as much as possible and yes, I agree that there is some serious dorkiness possible with certain PLs.
Anecdote, not data, but I've found that Rust, Erlang, and F# (if MS stack) tend to be in the sweet spot of expressive enough without drowning in symbols, without being as mushy as, say, Python/Ruby/pick something.
That said, I do not recommend immutable libraries. Here are the reasons:
1. They provide false comfort. Nothing in JS is truly immutable. People are just going to end up breaking the rules (purposely or inadvertently).
2. Boxing and unboxing regular JS objects becomes a pain in the ass and a maintenance horror show. You'll never know what an object is and you'll have to jump through countless hoops to get plain old JS objects to do anything with anyway.
Much better is to educate developers, and make sure code is properly reviewed before merging. Immutability doesn't need to be built into the language. Code customs and practices can go a long way.