LIVE ON TWITCH: / theprimeagen Get in on Discord: / discord Get in on Twitter: / theprimeagen Got Something For Me to Read or Watch??: / theprimeagenreact
It is actually beautiful if you understand how to read it. It's hilarious watching these guys try to read code that's supposed to be read from inside to the outside as though they were reading JavaScript or c.
Well in an alternate universe where common lisp has all the facilities other languages has (mainly maintained libraries that are as powerfull as that of java and Python) CL would be a thing of beauty. Its a lisp 2 after all. Remember clojure is a lisp 1
@@Oi-mj6dv Being a lisp 2 doesn't make it by definition more beutiful. Extended syntax of Clojure, and it's neat destructuring and syntactic choices in it's core functions/macros are much cleaner IMO to CL. For example Clojure's `for` is much more leaner and as comprehensive as CL's `for`. Also in my opinion being a lisp 1 is a benefit.
@@silencioseuWhat extended syntax? It being a pseudolisp makes it uglier if anything. It's a shame that `loop for` only works on arrays and lists instead of all sequences but in practice it's not a large issue.
@zperk13 Find some quotes by Alan Kay, Paul Graham, Douglas Hofstadter, Guy Steele, Dijkstra, Yukihiro Matsumoto (Matz). See what they said about Lisp (and Clojure is a modern Lisp). You can clearly see how sarcastic those guys were about it.
"You've written not enough bash or too much bash. There is nothing in between". 😂 I've been writing a lot of Clojure lately, I really love it, but it definitely has a learning curve. I decided to learn it because I could learn functional programming and Lisp at the same time. I'm retrospect, I think it ended up being more confusing doing both at the same time, but it was doable.
You do not read Lisp from top to bottom. It's like to trying to enjoy a movie by reading the contents of its subtitles file or learning about Renaissance art while your uncle explains it over the phone. There are two crucial components you need to start with - structural editing and REPL. Every single element in Clojure is evaluable. You connect your editor to a REPL and evaluate things to understand their semantic meanings. Clojure programs are living, breathing, dynamic, and malleable entities. Reading their code without a connected REPL is challenging even for experienced clojuristas.
Whoever wrote this: I don't know why people are having a hard time reading this. I've never looked at clojure before. But I assumed it worked like some combination of common lisp and racket and the "build a lazy list recursively" design jumped right out at me. So, I think the code was mostly fine.
@@Skiamakhos It's called destucturing. It means take the first two characters from a string, and name first one ch and the second one pk, name the rest of the string rst. Maybe you could name pk peek instead, but the intention is obvious, you need the 'look ahead' character when parsing/lexing.
the thing is, clojure code is very dense, but you get the information of what is going on with patterns that really repeat a lot in other Clojure code. So once you know CLojure and it's idioms, you really get good at reading patterns which give you wings, so that you don't really have to rely on 'variable' names. I hope I expleained it better.
@@Simon-xi8tb it's like someone read Clean Code & decided to go the opposite way. Let's try & name things like it's uglified JS, kinda thing. If I was code reviewing Java with variables named like this, I'd tell the developer to go back & rename them something readable. It's not the 1950s - we don't need to scrimp so much on RAM or storage space that we stick to one or two character names for things. You make things readable by a newbie, you don't waste senior devs' time with stupid questions from the newbies.
@@Skiamakhos I agree that naming is important. But I feel like you are having a knee jerk reaction because of the unfamiliarity with Clojure constructs and not because of shorter names. The code in this video is fine and beautiful. You could write destructuring like this [current-char next-char & rest-of-the-chars] but I assure you that only Clojure newbs would write like this, and that is becuase it's such a known pattern to use a name rst for rest of the sequence.
As a long time Haskell and F# user, Clojure is my favorite language. It's not perfect (the error messages still leave a lot to be desired compared to Elm/rust), but it's definitely the most practical language I've used so far. Common lisp could possibly top it, but I'm not experienced enough with it to know for sure. Clojure has a really solid and well thought out standard library, immutable everything by default (with painless mutability when needed), super simple to use async primitives that compose well together to cover any use-case, clojure.spec for all your type-checking needs, easy interop with jvm libs, can produce native binaries with GraalVM, powerful expressive "shell" scripting with babashka, backends for js/node/react/dotnet/dart+flutter/llvm/go/erlang making it a wildly flexible fullstack language, but best of all, it has a really great development experience. The unfortunate part about just reading lisp code, is that you miss out on some of it's biggest strengths. Seriously, anyone complaining about the parens should try editing a lisp in emacs with a structural editing mode (paredit/smartparens) and a live repl environment (CIDER for clojure, or Sly for common lisp). Then try sending arbitrary sub-expressions back and forth from your repl willy-nilly, and explore the repl environment's inspection utilities. These lispy tools let you get to know your code on a much more intimate level than a typical compile cycle. The fast interactive s-expression workflow pairs really well with the immutable functional paradigm, because it naturally encourages you to make everything highly composable and testable. I thought refactoring in Haskell/F# was great because of the guaranteed type safety, but being able to just sling parens and s-expressions around makes refactoring so much easier and faster that it's hard to go back. If you're a neovim user (as I am when working with other languages), it's worth learning emacs just for this experience. Conjure is the equivalent plugin for this on neovim, but it's just not quite the same imo. And yes, don't forget the 🌈 parens. I recommend anyone curious about clojure to check out the "Rich Hickey Fanclub" repo on GitHub and go through some of the talks and writings on there, really makes you understand and appreciate the language. The book "Data Oriented Programming" by Yehonathan Sharvit is also good for understanding idiomatic clojure application design, though the book itself uses JS to illustrate the concepts, which makes it suitable even for functional programming beginners.
Common Lisp has a bunch of really good features (conditions, signals and restarts, for example), but Clojure is a lot more polished and less rough around the edges, both in the immutable data structures (which CLS only partially has), the polymorphism with multimethods and protocols (which CLS has CLOS for, which is an OO take on this concept), the multiple brackets which make the code more easily scannable, and a lot nicer macros with much fewer gotchas.
I *wish* I could adjust to and learn to use a LISP-like language. I’ve tried like 4 times and I keep bouncing off it, though. It seems fairly elegant from a math/algorithm perspective, though
If you wish, I have some light tutorials on my channel about ClojureScript (Clojure, but compiles to Javascript). Not really trying to promote anything, really, but if you see some of they, please let me know how I could make them better/easier :)
Have you learned it yet? I want to share my limited experience. I wanted to learn a LISP language and had to choose between Clojure and Racket since they seemed to fit me best. Many argued that Clojure was designed by Rich Hickey for his own use, whereas Racket is seen as a language you can adapt to suit yourself. I learned Racket because I thought I wanted that ability. But the truth is, Clojure is just better because of it's focus. Things are done the way they are for a reason. I would never recommend anyone learn Racket unless you really need that ability to create your own language. I feel Racket was easier to learn, as I find it closer to standards in LISP and there was fewer concepts to get my head around, and it was a useful step in learning LISP. But I would never go back. Clojure does things that are meant to improve or add onto LISP. And you can't always appreciate that unless you know how things used to be or are done by other LISP languages. Can't say anything about Common Lisp.
Not trying to take merit away from the solution, but to me, it seems really weird clojure code (especially the heavy use of macros shadowing clojure special forms like "if"). Made me start my own lexer and see how simple I can make it
I have a tool like that too! It's called Rust. In all seriousness, I usually get by with just ZSH and a bunch of nice command line programs. Sometimes I actually write something in Rust when I really want maximum runtime efficiency, but usually it's just that, and basically never python.
I think I also heard it somewhere else that j in clojure stands for jvm. L for lisp and c for CLR, c# land. the creator of clojure, Rich Hickey, has alot of experience in C#, java, cpp.
That's right. Clojure is a hosted language. It sits atop whatever runtime you want your program to run. Initial versions supported JVM and CLR. Later Clojurescript (JS) was added. There's also Clojure-Dart, today you can write Flutter apps in Clojure. There are Python bindings, and you can also call R from Clojure. There are a bunch of Clojure-like PLs for other platforms. For example Fennel that compiles to Lua - it's pretty cool, people writing their Neovim and Hammerspoon configs in Fennel. There's Clojure interpreter implemented in Rust, there's ClojureC for C, and Clojerl for Erlang. Learn some Clojure and you become true polyglot programmer.
I really hope prime watches a few of ritch hickeys keynotes. Specifically "simple made easy" and "speculation" because rich is such a good speaker, you come in being confused on a subject and walk out wondering how anyone could think any different
8 месяцев назад
The talk of Rich Hickey that will catch him for sure is "The Language of the System" given his inclinations.
`cons` is short for CONStruct. it's from a time, where ppl had to save on the number of characters in function names in their lisp implementations... also, when they were writing such programs on paper and blackboards. here is the evaluator for lisp code, handwritten on a green blackboard: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-aAlR3cezPJg.html
He Prime, there is a Lisp with Rust semantics, is called Carp. It compiles down to binary executables, the repl is just an interactive compiler like clang
This is kool, but wouldn't you rather sip your Clojjjure with some Cider, as in a real repl that evaluates even pieces of functions right there in the same buffer/window/pane/place? One does not merely read Clojure, one fondles and massages it...
You are comparing two diametrically opposed things. In JavaScript (or basically most non-Lispy PLs), deeply nested statements could lead to callback hell or pyramid of doom, making the code harder to read, understand, and debug. In Clojure, nested expressions are common and idiomatic due to the language's Lisp heritage and its code-as-data philosophy. In Clojure, code is composed of expressions that can be composed together, with each expression potentially being an evaluation of other sub-expressions. This doesn't lead to a pyramid of doom, since the emphasis often is on data transformation rather than orchestration of side effects. Nested expressions allow you to build complex behaviors from simpler ones in a very direct and composable manner, thereby making code concise and easy to reason about. Deeply nested statements in JavaScript often hurt readability and maintainability, while nested expressions in Clojure typically enhance them due to their emphasis on code/data composition and transformation. It is a difference of chaotic complexity versus structured and intended composition.
I would say much harder than Clojure. But looking at it as someone who hasn't done any Rust. I do Golang now, but I am ex Clojurer. To me, once you know the idiomatic patterns in Clojure and the whole mechanics of the language, which is really small btw, you get the experience that is likely not comparable to anything else. The rapid feedback that you get is insane, nothing comes close, nothing. Well, maybe Racket, but I like the opinionated nature of Clojure more. The persistent colleactions and unificatons of those with the sequence abstraction is really powerful. Working in Clojure really feels like working with data, it's really data driven development.
Parentheses there for a reason. They define the structure. Once you learn structural editing commands, the cliched "programming with Lego blocks" becomes a reality. You will stop seeing parentheses and start seeing the structure. Programming becomes like poetry. And you don't have to deal with superfluous elements like commas and semicolons. You will stop thinking about the syntax, and open the pathways for understanding semantics of programs. I also rejected Lisp for years. After learning it a bit I regretted the wasted years of my ignorance. I should've started much sooner.
There are lots of clojure evangelists at my company. They say it takes a little while to click but once it does it becomes readable and you get a lot more done in less code than with a non lisp language.
@@metelomaniac Clojure is one of the most enjoyable languages out there. "The Joy of Clojure" is one of the greatest books on Clojure. Try saying out loud "the joy of PHP" or "the joy of Java". It even sounds super weird.
@@ilemming Honestly, Java is pretty enjoyable to use nowadays. Java streams are very intuitive, and are also very powerful due to naturally allowing the data to go through a pipeline (also possible in Clojure with the ->/->> macros e.g., but it's often more readable in Java imo). In addition, immutable builders make it super easy to instantiate objects, and with ImmutableLists, function interfaces, lambdas and streams, it's usually as easy to write FP code as it is with say Clojure, if not easier sometimes (due to being able to also use OP semantics and practices). Still love Clojure, but just as a side note.
