Live data from Hacker News

Why I like Clojure

sulami.github.io

71–80 of 155 posts

Re: Why I like Clojure

#71
post #68
post #63

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…

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…

Thank you for the viewpoint. It certainly has merit, but there is also the possibility of "metapackages" like luminus [1], a curated package of libraries that work well together. It's easier to make a framework in the land of libraries than vice versa.

Some of what you perceive as immature may be that the community is small, and a lot remains to be done.

[1] http://www.luminusweb.net/

Re: Why I like Clojure

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

Which libraries are people expected to plug together the security parts? I'm not pushing for clojure but a lot of other languages and frameworks are taking this approach too including Node and Go.

Wouldn't the security stuff be a part of the individual packages? Ie authentication package handles sessions and tokens, an http server/middleware with built in csp and ssl, orm, the data stuff handling serialization and data parsing?

Technically rails is composed of a bunch of smaller gems with a similar responsibility tree although without the centralized CVE distribution and pressure that creates.

When I used Clojure it was always mini frameworks which created a base set of important packages with a pluggable middleware system on top and flexible data back ends.

The individual packages need to have domain experts for their particular attack surfaces and exposures.

If anything its about a lack of eyes or community size on the various wholes, rather than expecting the end user to do the individual hardening or plumbing.

Re: Why I like Clojure

#73

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

While you can manipulate Python's AST, you can't do it in a way that looks like adding new syntax. In Clojure you can write a list comprehension as `(for [x (range 10)] x)`. In Python you can write it as `[x for x in range(10)]`. Imagine these didn't exist, and you wanted to implement them yourself. In Clojure this is possible. Its list comprehensions are implemented as a Clojure macro: https://github.com/clojure/clo…

I heard somebody make a similar argument one time in regards to Common Lisp. He said that with Java you would have to wait several years sometimes to get a feature (assuming the language developers actually cared about the feature), but with Lisp, you could just implement the feature yourself. I've always felt this is one of the strongest arguments for using a lisp-style language.

Edit: this is possible too in languages like Elixer and Ruby using macros, but eventually the readability suffers and debugging complex macros in those languages can be a nightmare.

Re: Why I like Clojure

#74
post #73

Earlier quoted context omitted.

While you can manipulate Python's AST, you can't do it in a way that looks like adding new syntax. In Clojure you can write a list comprehension as `(for [x (range 10)] x)`. In Python you can write it as `[x for x in range(10)]`. Imagine these didn't exist, and you wanted to implement them yourself. In Clojure this is possible. Its list comprehensions are implemented as a Clojure macro: https://github.com/clojure/clo…

I heard somebody make a similar argument one time in regards to Common Lisp. He said that with Java you would have to wait several years sometimes to get a feature (assuming the language developers actually cared about the feature), but with Lisp, you could just implement the feature yourself. I've always felt this is one of the strongest arguments for using a lisp-style language. Edit: this is possible too in langua…

[deleted]

Re: Why I like Clojure

#75
post #71
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…

Thank you for the viewpoint. It certainly has merit, but there is also the possibility of "metapackages" like luminus [1], a curated package of libraries that work well together. It's easier to make a framework in the land of libraries than vice versa. Some of what you perceive as immature may be that the community is small, and a lot remains to be done. [1] http://www.luminusweb.net/

You're absolutely right, it's easier to make a framework in the land of libraries.

With that said, it may be more difficult to get one used when the culture of library-land abhors frameworks. The Clojure developers I've worked with so far mostly seem repulsed by the idea of using a framework.

This leads me to fear that the ecosystem is likely to remain in the hole it has dug for itself. Possibility is wonderful, as you say, but it is unlikely to save applications being written today.

Re: Why I like Clojure

#76
post #72
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…

Which libraries are people expected to plug together the security parts? I'm not pushing for clojure but a lot of other languages and frameworks are taking this approach too including Node and Go. Wouldn't the security stuff be a part of the individual packages? Ie authentication package handles sessions and tokens, an http server/middleware with built in csp and ssl, orm, the data stuff handling serialization and da…

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. It's something application-specific that has to be re-evaluated with every single web request and is going to be subject to unique business requirements.

Frameworks tend to handle these issues by setting out a set of conventions to adhere to, within which many of these concerns are handled for you to the extent possible. It's far from perfect, but it does a lot to reduce the chances of someone forgetting (for example) that forms need anti-CSRF tokens because their form-generation function doesn't do it for them or automatically work with the form-accepting and validating functions.

Or, to use example I've seen, the logging package's ignorance of what might be sensitive in the strings its been handed turns into secrets being sent to the centralized logging system and exposed to far more people than they should be. 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.

A culture of libraries instead of frameworks can mean that each project may have to make all the decisions a framework does all over again. Is everyone going to get it right every time?

Re: Why I like Clojure

#77
post #34

Clojure/Lisp is super nice until you have a bunch of transformations to make then you've to keep everything in mind without having a named reference in front of you (unless you omit the threading operators and abuse the let statement). It becomes exhausting after a while and makes you question if you are working for the machine or the machine is working for you. Yes, it's more succinct and elegant but is it worth it?

Would Specter help here?

Not familiar with it. I will check it out. Thanks for the recommendation.

Re: Why I like Clojure

#78
post #68
post #63

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…

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.

Re: Why I like Clojure

#79

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…

most of the “port clojure to X” that I’ve seen are just top level syntax and don’t port the functional data structures over. Without those, I don’t see the point.

Beyond that, the land of libraries has sneaky little java dependencies scattered throughout. Clojure without the libraries isn’t very compelling.

As someone else mentioned, graal does a good job of making an “executable”

Re: Why I like Clojure

#80
post #32

Earlier quoted context omitted.

Clojure is concise, expressive, not noisy, opinionated (with generally appreciated opinions), dynamically typed, a Lisp, functional with some escape hatches (but not confused with being FP and OOP), and built to solve real problems. Scala is either the opposite of these, or at least not as much of these. IMO, less code is better. Clojure is about as terse as you can get and still be readable (by my opinion). Scala is…

Though Clojure jobs tend to be the highest paying. https://insights.stackoverflow.com/survey/2019#top-paying-te...

It's pretty common for niche languages. The fewer developers there are, the higher they are likely to be paid.

These jobs are pretty much impossible to get, though.

Post reply on HN