Live data from Hacker News

Why I like Clojure

sulami.github.io

121–130 of 155 posts

Re: Why I like Clojure

#121

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.

You can ask questions at: ask.clojure.org

And like others said, people on slack are super helpful, don't be shy, the community is great.

That said, Clojure does not invest a lot into beginners. Not a lot of tutorials, guides and tooling are similarly unfriendly and assuming you know a lot. Not trying to scare you off, just setting the right expectations.

Re: Why I like Clojure

#122
post #55

Earlier quoted context omitted.

Chapter 2 of Clojure for the Brave and True will get you an Emacs environment set up with minimal effort!

I just went through this chapter. Some of the packages are out of date and the environment does not work correctly. I'm still trying to figure out how to get emacs to connect to the repl.

Indeed not so minimal effort, I had to skip that chapter. Hopefully it will be updated in the future.

I've been using Atom so far, and I will try Cursive later

Re: Why I like Clojure

#123

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.

Thanks for all the tips. I started the book Brave, installed Cava and got it working, and am considering finally biting the bullet on emacs. Two birds with one stone!

Thanks for the tips!

Re: Why I like Clojure

#124
post #76

Earlier quoted context omitted.

You're right. Many things can be handled by packages, abstracting them away from the developer. Of course, that's assuming the developer thinks far enough ahead to remember that they need authentication, decide how they want to handle it, figure out what they want for a CSP, and so on. Other things cannot be so readily handled. Authorization, for example, isn't a concern that can be bundled into a pre-fab function. I…

> The developer didn't think about what might be in what they were logging, the package assumed that the developer did, and the result could have been avoided by a more integrated whole Umm, is there any all in one web framework that protects against this to any level of guarantee?

It's been my experience that Rails logging can and will do things like censor password fields when passed objects.

So, yes, it is possible for logging (and serialization) systems to defend against this kind of thing.

Re: Why I like Clojure

#125
post #70

I love the idea of Clojure. 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…

That's just a misconception imo. Clojure is full of frameworks. The real issue is overwhelming choice and the no handholding make your own decisions approach. Probably accentuated with a lack of beginner guides.

Have a look at Pedestal, Yada, Duct, Hoplon, Catacumba, Coast, and Fulcro.

Those are all actively maintained frameworks being used by different people in production.

On top of those, you have the meta-libs frameworks such as Luminus and Chestnuts.

And what most people don't know is a lot of Clojure devs use a Java framework, because those are also available to be used from Clojure. I have a Spring MVC Clojure app for example. Lots of folks use Vert.x for example.

So whatever your definition of mature is, Clojure has everything you need and more. If you mean mature as in, one and only one way which everyone is rallied behind and all guides and tutorials teach and use, then no.

Re: Why I like Clojure

#126
post #70

I love the idea of Clojure. 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…

there is luminus that assembles all the parts for you.

Which would be wonderful! Except for the responses of visceral disgust I get from Clojure developers when I suggest using a framework. The culture seems hostile to actually using such things.

Re: Why I like Clojure

#127
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…

> 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:

You're right! Sane defaults are incredibly powerful and let developers make the right decision by not making decisions at all.

When developers have to stop and remember to integrate a library for authZ and authN, and then integrate individual modules from it for their use case, some might opine that we have gone beyond the bounds of sane defaults.

Sane defaults for Clojure in a web context are a wonderful idea. It's unfortunate, then, that buddy is less sane defaults and more a toolkit from which someone assembling a framework has the option to choose sane defaults.

Re: Why I like Clojure

#128

Earlier quoted context omitted.

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 prep…

> 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.

One of the things that Rails' templates gets completely right is that it knows when something is nested and when it's going to be returned immediately. It is thus able to do its automatic escaping right before returning a response and not before.

At this point in history, I think this is the baseline behavior all templating systems should meet. Requiring users to remember to manually escape every output every time is begging for exploitation. Such a design error only strengthens the case that hiccup is not appropriate for serious use at this time.

Re: Why I like Clojure

#129

> homoiconicity, meaning code can be represented as a data structure inside the same language > generating strings and passing them into eval like for example in Python Python has become a pinata for language enthusiasts? Python lets you pin a decorator on a function, get the AST (a data structure AFAIK), manipulate it in a sane fashion in Python, compile it, return the result. No string munching eval require I'm all…

It's more that code and data have the same representation. For example, where is the Json of Python? Where is the Python object notation which is both how you represent Python Objects in code as well as when serialized to data over a wire?

[1 2 3] is both the serialized form of a vector as well as valid code to create a vector of itself.

Now in JS, only object data is homoiconic. In Lisps, even code expressions are homoiconic, thus (+ 1 2) is the serialized form of the list of function + and args 1 and 2, as well as valid code to add 1 and 2 together.

You do not need macros for homoiconicity. Macros is not what makes a language homoiconic. But once your language is homoiconic, it is very easy to add macros to it, and macros become much simpler to write. Which is why Lisps have macros as well.

Re: Why I like Clojure

#130
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?

That’s a fair description of the syntax, but Clojure is more than just syntax.
Post reply on HN