61–70 of 155 posts
I love the language. I’ve never found a language where I found the learning curve so shallow for being able to do so much. That said, I do find myself pining for the ability to easily compile a static executable (maybe with a small embedded runtime). Some time ago there was an attempt to port Clojure to Gambit Scheme, but that appears to have fizzled. More recently, I’ve seen Ferret, which compiles a subset of Clojur…
Earlier quoted context omitted.
A python decorator is just a syntactic sugar for : f = decorator(f) Afaik, the decorator deals with the internal function as a black box. But with lisp being a lisp, the macro writer can choose the level of blackboxiness they want to deal with. Note: I love both Python and Clojure and use them extensively.
As others have hinted at, higher-order functions like decorators can inspect and manipulate the internals of a "black box" function object with the ast module[1]. This would be comparable to a lisp function taking a quoted form, expanding and evaling it at runtime as an ad-hoc macro funcitonality as is common in more bare-bones lisp implementations. Aside from the ease of manipulating quoted forms (i.e. asts) in Lisp…
Thank you.
You compose libraries, instead of totally buy into framework A or B. Some people prefer the opposite.
However, Composition works in Clojure because everyone is using the staples: functions, maps and seqs. Pretty much everything in the language can work as one (or all!) of them.
While I also like static types, this is my argument for a well designed dynanic language like Clojure or its Lisp relatives: stuff just snaps together like magic lego bricks.
I love the language. I’ve never found a language where I found the learning curve so shallow for being able to do so much. That said, I do find myself pining for the ability to easily compile a static executable (maybe with a small embedded runtime). Some time ago there was an attempt to port Clojure to Gambit Scheme, but that appears to have fizzled. More recently, I’ve seen Ferret, which compiles a subset of Clojur…
Earlier quoted context omitted.
Python is not as flexible as Lisp in a manner of AST manipulation
Python's approach seems to be: expose functionality like the AST for the 31337 ninjas that really want to go there, while maintaining intense focus on producing a KISS tool for the other 95% of its audience.
Much like classes can be used as data transfer objects or to build out a large inheritance tree, macros can be used tactically - to DRY up things you otherwise couldn't, or introduce some readability improvement - or strategically, to lift the code up another layer of abstraction, or create DSLs that let you write your code much closer to the problem domain. Because Lisp supports them in an ergonomic way, macros are not seen as something special, but just another tool in the toolbox.
I love the language. I’ve never found a language where I found the learning curve so shallow for being able to do so much. That said, I do find myself pining for the ability to easily compile a static executable (maybe with a small embedded runtime). Some time ago there was an attempt to port Clojure to Gambit Scheme, but that appears to have fizzled. More recently, I’ve seen Ferret, which compiles a subset of Clojur…
> While the primary platform is the JVM, superbly uncool but stable and relatively performant My impression was that java has the reputation of being "uncool" but JVM is highly regarded as modern marvel. I am wrong about this ?
IT Java is uncool, but then IT is uncool even if written in Clojure (though the psychological aspect of using a "cool" language will likely dampen the existential pain of writing yet another book keeping CRUD app since now you are using s-expressions!) In my experience, people who say silly things about Java -- the technology, which certainly includes the Java Language Semantics, and JVM -- actually do not know what…
Yeah, I just don't understand the less lines of code argument. This is not the limiting factor in software development, it's just not. The limiting factor is having enough information for the immediate Use Case and enough business domain knowledge to come up with a solution that delivers value to the business. The time spent on delivering that value dwarfs the time it takes to write some extra code. Let's look at Uncle Bob's example in the linked article...
(println (take 25 (map #(* % %) (range))))
While fancy, that code is very Perlish and I think we all know the common criticisms of Perl. Also, fancy doesn't pay.
What I've found to have a much larger negative impact on a project than the language is overly complicated architectures. To the extent Clojure can help with that I'm all for it. But from what I've seen, Java 8 with some clear conventions and constraining source code to the implementation of the Function interface can get you a lot of the same benefits.
My favorite thing about Clojure: You compose libraries, instead of totally buy into framework A or B. Some people prefer the opposite. However, Composition works in Clojure because everyone is using the staples: functions, maps and seqs. Pretty much everything in the language can work as one (or all!) of them. While I also like static types, this is my argument for a well designed dynanic language like Clojure or its…
With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the ecosystem incredibly immature. It's somewhere beyond arrogant - reckless comes to mind - for most engineers to do all their own plumbing for a web service. The odds that they'll manage to design someone easily long-term maintainable are slim. The chances of authorization, authentication, potential SQL injection, and a thousand other security things being handled well is effectively none - the Clojure ecosystem often seems wildly ignorant of such things. The core philosophy of just composing the libraries you need with Ring means that anything you don't actively think of will be likely entirely neglected. This is a dangerous way to ship code that will be facing the real internet. Clojure requires you to fit absolutely every aspect of everything you're doing into your head and be handled by you, because nothing is going to do it for you. The lovely magical LEGO feeling is, sadly, a lie.
This stands in stark contrast to the level of consideration around maintenance and security that has gone into a modern, mature framework. Or a modern language where SAST is an option.
Doing low-level stuff feels absolutely amazing! The sense of control, of having your hands in the guts and the ability to do what you need without wasting time on bullshit magic, is heady and glorious. It's just perhaps worth considering that that magic can sometimes be incredibly valuable, well worth the tradeoff against the feeling of freedom.
My favorite thing about Clojure: You compose libraries, instead of totally buy into framework A or B. Some people prefer the opposite. However, Composition works in Clojure because everyone is using the staples: functions, maps and seqs. Pretty much everything in the language can work as one (or all!) of them. While I also like static types, this is my argument for a well designed dynanic language like Clojure or its…
Examples include Emacs, Linux (especially distributions like NixOS or Arch) or classical Unix utilities.
I find the ecosystem immature and full of ideas about "libraries, not frameworks" that leave developers incredibly vulnerable to their own ignorance and second-order ignorance. The number of developers I know - or even know of - that can be trusted to develop a useful and secure web application from the ground up with this kind of tooling approaches zero.
Clojure is a cool language. I can only hope the ecosystem soon matures enough to make it one that's suitable for serious use.