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.
Why I like Clojure
111–120 of 155 posts
Re: Why I like Clojure
#112I 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.
https://github.com/clojure/clojure/blob/master/src/clj/cloju...
What were the special cases for your use case?
Re: Why I like Clojure
#113Earlier 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…
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
#114Re: Why I like Clojure
#115as 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
#116Clojure 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.
Re: Why I like Clojure
#117Earlier 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…
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
#118Earlier 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…
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
#119Earlier 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.
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
#120Clojure'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.