Live data from Hacker News

Why I like Clojure

sulami.github.io

111–120 of 155 posts

Re: Why I like Clojure

#111
post #94

Earlier quoted context omitted.

That seems like an unusual first project. Any reason you chose it? Were you more interested in the language semantics?

It was because (1) a project I was thinking of would lean heavily on memoized calls, and (2) it would allow me to learn about less basic features like introspection and (3) to quickly see how cleanly the language was designed to not be disappointed later on.

You could check out Clojure's built-in memoize (https://clojuredocs.org/clojure.core/memoize)

Re: Why I like Clojure

#112
post #90

I tried to learn (get to know) Clojure by writing a library for cacheing (memoizing) function calls. I thought it would be a simple exercise, but it turned out to be not so easy at all, with lots of special cases.

Clojure's implementation of `memoize` is here:

https://github.com/clojure/clojure/blob/master/src/clj/cloju...

What were the special cases for your use case?

Re: Why I like Clojure

#113
post #99
post #68

Earlier quoted context omitted.

Composing libraries instead of buying into a framework is a wonderful thing. It allows a developer to use just the parts they want, integrate them with just what the developer needs, and get on with whatever they're doing. It's a beautiful idea, and it can enable amazing levels of productivity. With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the…

> I found the ecosystem incredibly immature This does not match my experience at all. There is a thing called sane defaults. You solve a problem by decomposing it to simple elements, and then combine them to sane defaults, while still giving full power to your users. Examples of sane defaults in areas you mention: - authorization/authentication: buddy ( https://github.com/funcool/buddy ) has both core library with cr…

I did also find the ecosystem to be not-so-mature a few years ago. Compared to something like Rails or various Java collections of tools it feels like things are less available or simply a poorly-made Clojure veneer over and underlying Java tool.

Ecosystem takes a while.

(Yes, I was using both JDBC and Ring as well as other things like Leiningen. Core.async was a notable exception as something done better in Clojure than elsewhere)

Re: Why I like Clojure

#114
as i was talking to a friend about clojure i came up with an analogy i cant shake: clojure is what happens when you just make your programmer directly write an AST. a bit reductionist, but anyone care to debate this?

Re: Why I like Clojure

#115
post #114

as i was talking to a friend about clojure i came up with an analogy i cant shake: clojure is what happens when you just make your programmer directly write an AST. a bit reductionist, but anyone care to debate this?

Isn't that the point of lisp and homoiconicity in general? That you're writing an AST that you can also treat as a data structure?

Re: Why I like Clojure

#116
post #48

Clojure Help: This is super apropos since I am JUST learning Clojure via the Clojure Koans. Any tips from clojurists on getting the repl (and readline) working fluently? I'm using Leiningen but it's not responding as I'd expect. I would think this would all set up more effortlessly. Tips on getting a new Clojure setup working would be appreciated.

I use Leiningen as well and I have no issues with it. REPL startup is a bit slow, as is expected from most JVM programs but a bit more so for Leiningen.

You can start the JVM in well under a second, the problem is most JVM programs don't care about startup time thus startup becomes slow. Most JVM apps are designed to be long lived.

Re: Why I like Clojure

#117
post #68

Earlier quoted context omitted.

Composing libraries instead of buying into a framework is a wonderful thing. It allows a developer to use just the parts they want, integrate them with just what the developer needs, and get on with whatever they're doing. It's a beautiful idea, and it can enable amazing levels of productivity. With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the…

This is a great conceptual point that I think can be missed by folks who prefer a constellation of quality library-style code over a single framework. It's true that the *nix ecosystem is a case of the former over the latter, and I think that can work nicely for library level code that is used to build applications. But, it's hard to build protocols; or maybe, more accurately, it looks like successful ones emerge rat…

> For folks who have production experience in Clojure: how valuable is Java interop in your experience? ]

Very, there a lots of high quality Java libraries, and interop makes it easy to use them. Especially when integration with other software (databases, message queues, etc) being able to use the Java client libraries is a blessing.

Re: Why I like Clojure

#118
post #68

Earlier quoted context omitted.

Composing libraries instead of buying into a framework is a wonderful thing. It allows a developer to use just the parts they want, integrate them with just what the developer needs, and get on with whatever they're doing. It's a beautiful idea, and it can enable amazing levels of productivity. With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the…

This is a great conceptual point that I think can be missed by folks who prefer a constellation of quality library-style code over a single framework. It's true that the *nix ecosystem is a case of the former over the latter, and I think that can work nicely for library level code that is used to build applications. But, it's hard to build protocols; or maybe, more accurately, it looks like successful ones emerge rat…

> how valuable is Java interop in your experience?

Clojure is designed to be a hosted language, and so Java interop is first class and integral to it. In fact, the standard library specifically excludes anything that overlaps with Java's, and is designed to complement the existing Java standard library.

> How often are you able to get away with using the most idiomatic parts of the Clojure-land ecosystem, and how often do you have to reach for Java-land?

It's not really like that, they complement each other and work in a symbiosis. Yes, sometimes it feels like the worst part of Clojure is Java, but not reinventing the wheel and leveraging battle tested Java libraries and tooling was a very smart pragmatic decision, so it's also the best part of Clojure. Just know using Java from Clojure is very idiomatic in of itself.

> How easy is interop in terms of traceability?

Pretty much seamless.

Re: Why I like Clojure

#119
post #68

Earlier quoted context omitted.

Composing libraries instead of buying into a framework is a wonderful thing. It allows a developer to use just the parts they want, integrate them with just what the developer needs, and get on with whatever they're doing. It's a beautiful idea, and it can enable amazing levels of productivity. With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the…

Really though, Clojure web apps are at the php-no-framework level security days, not joking. The most used HTML templater(hiccup) doesn't do any secure output escaping, bad password/session management, auth*, sql injection, bad encryption methods, its all there.

Hiccup has functionality to perform escaping with `h`. It doesn't do it by default though, for performance reasons and nesting of Hiccup in Hiccup. Normally, you'd just want to sanitize right before returning your response.

Doing it that way you can also perform more selective sanitation if needed.

Hiccup2 does sanitation by default, still in beta though.

The common SQL lib is java.jdbc or next.jdbc and they use prepared statements by default. Can you explain more where you see common risks for SQL injections?

I'm not sure what you mean by bad password and session management? Normally, the common lib people use is ring-defaults https://github.com/ring-clojure/ring-defaults what about these do you feel are insufficient? Maybe do a pull request about it.

Auth and encryption I agree, but the untold reason is that people just use Java bountycastle and Apache Shiro or other for that. Buddy is the most popular Clojure one https://github.com/funcool/buddy , but honestly, for that stuff, you want something super battle tested, that means popular, and Clojure as a whole isn't popular enough for that, so really just pull in a Java lib done, it works flawlessly within Clojure.

Re: Why I like Clojure

#120
What I like most about Clojure is the interactivity: I can quickly test and iterate on ideas in my editor connected to a REPL. To me, this is the main advantage of Clojure.

Clojure's focus on the REPL, immutability and simple datastructures make it possible to inspect data and redefine functions in running systems.

In other languages I spend a lot of time making small edits, setting breakpoints, starting the debugger, waiting for the program to start, etc, where in Clojure I can just redefine and inspect stuff immediately, allowing very short feedback loops when programming.

A lot of Clojure tooling emphasizes short feedback loops: component with it's reload function to restart systems, figwheel/shadowclj with live reload of browser apps, which is a huge productivity boost.

Once I got used to the quick feedback loops that Clojure provides, all the other languages feel bulky and slow to develop in.

Post reply on HN