Clojure web security is worse than you think

https://hackworth.be/2014/03/26/clojure-web-security-is-worse-than-you-think/

by r4um • 12 years ago

147 99 12 years ago

St-Clock• 12 years ago

I believe this warning could apply to any young ecosystem or micro-framework (e.g., bottle). Could web applications written in Go, or to a lesser extent, node.js, suffer from the same shortcomings?

After working so much in Django, I've been interested in smaller, leaner solutions, but then, as my feature list keeps growing, I find I miss all the bells and whistles provided by larger frameworks. I did not think of the security implication before reading this article.

asdf1234• 12 years ago

I've looked at a lot of Node, Sinatra, and Compojure web apps and the vast majority of them are vulnerable to a variety of attacks. CSRF protection in particular is almost never handled and when it is it's often not done properly.

leephillips2• 12 years ago

CSRF protection is handled by Django, for example, by default - an example of something you'd be giving up if you decided that Django is too "big"; now you need to figure this out yourself and find a library that provides it or program it yourself and hope you get it right.

phillmv6• 12 years ago

Could web applications written in Go, or to a lesser extent, node.js, suffer from the same shortcomings?

Yes, and they do. And there's no "lesser extent"; if I can't set up a fresh node app with the correct defaults for all of this stuff - if it's not safe out of the box, and I don't have to go out of my way to pick crappy settings - then it's just as vulnerable.

People made a lot of fun out of the Rails vulns that hit last year but they were the visible growing pains of having to mature a framework. It's not about the individual bits, it's about the ecosystem at large.

jerf2• 12 years ago

My dream someday is to write a secure-by-default web framework. I've been collecting a list of things it needs to do. It's not surprising that few-to-no frameworks get it even remotely right... there's a lot more to it than meets the eye. CSRF, for instance, is hard to get right. There's a lot of "CSRF" implementations out there, where the scare quotes are part of how I'm naming them. There's headers to avoid clickjacking, which you really ought to default to the strongest protection level and make the user explicitly loosen if they need it. There's "Content Security Policy" headers that ought to be configured. And there's a pervasive problem where the security model for resource access is just laughable... it's up to you to hopefully authenticate a user correctly, and hopefully, you authorize them (hopefully, your framework realizes those are two distinct concepts! but I gotta tell you, the odds are against you), and hopefully, resources don't default to being universally available, and hopefully, that code is all correct.... there's stuff you really ought to do to the querystring to prevent enumeration attacks that would be interesting, there's the whole matter of whether your template permits, encourages, or begs you to shoot your entire site full of cross-site scripting attacks unless you laboriously explain to the template system each and every time "no, I don't want an XSS here... no, I don't want an XSS here... no, I don't want an XSS here" (even after 15+ years of experience here, I still can not reliably work in a templating system like this, something always slips through)... session management is a great deal harder than it looks... framework users should probably actually not be given access to the user's cookie in any direct form because that's begging for problems (darned near anything you can do to a cookie is insecure), to say nothing of how they ought to default to no HTTP and Secure... it's a nightmare out there.

route662• 12 years ago

I would want to turn the question around and (genuinely, not rhetorically) ask: which ecosystems right now do have a good security baseline? Am I wrong when I guess Java/.Net/Ruby and possibly more recent PHP frameworks?

jaegerpicker• 12 years ago

ASP.NET MVC 4 and later is pretty decent, Rails is getting better but recently had a large series of problems, and django is one of the most secure by default web frameworks that I've ever used. Django really gets a lot of things (sessions, CSRF, XSS, etc..) right out of the box. Grails is pretty decent but I don't have a lot of in depth Java framework experience but it seems to vary based on the framework.

MAGZine• 12 years ago

Symfony on PHP has a great security baseline--though it's pretty complicated.

manishsharan2• 12 years ago

I will leave this here http://www.javalobby.org/articles/acegisecurity/part1.jsp

john2x2• 12 years ago

I felt some relief after watching the presentation. I thought I was just a whiny newbie who was spoiled by Python/AppEngine (although I guess the spoiled part is true). Turns out it is a real issue with the Clojure ecosystem.

Another talk from the conference I'm glad was presented is "How Clojure Works"[1]. Towards the end, he shows the negative effects on tooling caused by Clojure's dynamic + hosted nature. Clojure's stacktraces are a nightmare. And the painful startup time kind of negates the excitement a newcomer might have towards REPL-oriented development.

Hopefully it won't be too long until things improve.

[1] https://www.youtube.com/watch?v=8NUI07y1SlQ&list=PLZdCLR02gr...

sillysaurus3• 12 years ago

It's always better to have more people reviewing the security of an application, even if they seem like a whiny newbie.

leephillips2• 12 years ago

"the painful startup time kind of negates the excitement a newcomer might have towards REPL-oriented development."

But you just need to start up once and then work all day in the REPL. Unless you mean that the JVM startup means that Clojure is not a good choice for writing utility scripts and such.

EDIT: As pointed out to me below, and in the excellent talk linked above, it's much more the Clojure bootstrapping time, which almost dwarfs the JVM startup time.

omaranto• 12 years ago

The startup time that makes Clojure unsuitable for utility scripts and such is really Clojure's, not the JVM's! JVM start up time is actually quite small these days. See for example, http://nicholaskariniemi.github.io/2014/03/19/solving-clojur...

stcredzero12• 12 years ago

I felt some relief after watching the presentation. I thought I was just a whiny newbie who was spoiled by Python/AppEngine (although I guess the spoiled part is true).

I would hazard a guess that some of this reflects on the Clojure community. (Not that this is somehow inherent or uncorrectable.)

john2x2• 12 years ago

Oh I thought to myself that I was a whiny newbie. The community's (at least, irc and subreddit) pretty cool.

eudox• 12 years ago

Web development is very particular because of security. You can write, say, a console newsread with any programming language that has an XML parser and a curses binding. But if you want to write a web application that will actually see production, you need a web framework that has been sufficiently battle tested and audited by security-competent people.

Which is a shame, because I'd really like to be able to use Common Lisp for web development. But as much as I love the language, you have to be reasonable.

userbinator• 12 years ago

you need a web framework that has been sufficiently battle tested and audited by security-competent people

Or alternatively, you just need to be careful with keeping things simple and straightforward. IMHO frameworks only hide problems somewhere else beneath layers of complexity. Assuming a fixed bug-rate, the more code there is, the more bugs that will be present (and whether they get discovered is another issue.)

adestefan2• 12 years ago

The argument is that making things too simple is what kills you. The defaults are not secure and you need to take steps to make sure you are secure. This is one area where frameworks are huge plus. Good ones ship with security conscious defaults.

chc• 12 years ago

This isn't about bugs in the sense of "code that is incorrectly written for what it was meant to do." It's more about bugs in the sense of "code that was written correctly, but which does not do things it should do because you either didn't think of or didn't care about them when you were writing it." It is easier and often simpler to allow vulnerabilities than it is to prevent them.

adestefan2• 12 years ago

You news reader example is a poor one. There have been a ton of vulnerabilities in XML parsing libraries over the years. Of course the attack surface is different (I need to engineer an attack that makes you open my vulnerable XML stream versus bang away on your web app), but the vulnerabilities are still there and as a programmer you need to be security conscious on every platform.

ScottBurson• 12 years ago

I've used Weblocks, Slava Akhmechet's CL framework, and I think it's pretty good. The database interface is abstracted so you never have to cons up SQL directly. Session handling and CSRF protection are built in. I did find an XSS bug or two in it, which I've fixed.

You still have to pay attention to XSS when writing your app -- there's no way around that -- but I don't think there are a lot of holes in the framework itself, and it makes it relatively easy to write a secure app.

I can't offer you a guarantee, of course, but I can tell you that I'm less nervous about Weblocks than I would be about Rails.

EDITED to add: Weblocks does have a pretty substantial learning curve, but once you know how to use it, it can make for very high productivity.

moondowner• 12 years ago

The title should be: Don't assume security is happening automatically under the hood.

Even if using a web framework which supports security out of the box, don't take it for granted either. For example: that's a common error developers make when using Spring Security. It's powerful and full-featured, and developers get security and everything in a breeze, but when doing things on the fly misconfiguration happens and vulnerabilities are out there in the open.

whyme5• 12 years ago

I've spent the last 3 years developing in Clojure and found I was quite happy not having an all encompassing framework. It forced me to learn all these issues and understand them well enough to be able to customize each and align them with a products design.

Sure it's more work, but in my mind, it's worth it.

phillmv6• 12 years ago

It forced me to learn all these issues and understand them well enough to be able to customize each and align them with a products design.

This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails - but just because something is more fun doesn't mean you're going to get all these details right.

The attack surface in modern web apps can be such a large search space that the majority of people will never get it right. The point behind frameworks is that you can engage in efficiencies in scale when it comes to sensible defaults; even the most well seasoned and security paranoid developer can drown in the cornucopia of details that all have to be done right.

whyme5• 12 years ago

This is a standard developer response

vs. a what? I've worn many hats in my day, the least of which has been a developer hat.

There's equal risk in relying on a code base incorporating features with underlying concepts that you or your team does not understand.

I'm all for having a framework, where you can review the code and be comfortable with what you're relying on, but in the absence of having a good one, well then build one. The benefits Clojure brings to the table more than make up for the work in either case.

There's just no excuse for not knowing the concepts and not knowing if your product needs them.

mantrax313• 12 years ago

"This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails"

And the more time passes, the more problems with Rails are being discovered that have to be altered in a non-BC way.

A library makes no assumptions. It's just there and you decide how to use it. In the right hands it's more powerful than a rigid framework.

A framework that tries to teach you how to do things is by definition a pair of training wheels. Not the best setup for competing in Tour De France.

The solution to incompetent developers isn't a bigger, more rigid framework. It's education and training.

manishsharan2• 12 years ago

Web Application is one of the places where Clojure's java compatibility falls short. I have a ton of time invested in Spring + ACEGI security and it just works. I have been exploring on how to develop servlets, which can use servlet session, in Clojure and they all look very ugly compared to normal Compojure based apps. I am coming to the opinion that maybe its not ready for J2EE web apps , which is a shame as J2EE has a very rich ecosystem.

ddellacosta• 12 years ago

The talk he links to (https://www.youtube.com/watch?v=CBL59w7fXw4) is really fantastic. Kudos to Aaron Bedra for issuing a well-considered and practical wake-up call to the Clojure community.

I support a Clojure/ClojureScript web app in my day-to-day work. I've also written an OAuth2 workflow for friend (https://github.com/ddellacosta/friend-oauth2 ...pull requests welcome), one library Aaron Bedra spends a lot of time talking about. The story really is exactly how he describes--Clojure web security could be better. I suppose you could argue that, at least, the defaults are generally not bad...but that's because there aren't defaults in many cases.

I think the main issue is, ironically, the same thing that makes Clojure development so great: you end up composing a bunch of small libraries together, each of which do one thing well. But as Aaron points out, there are things that aren't taken care of and you can't assume they are done for you, and a lot of security is something that you don't technically need to get a web app working...

I wouldn't want to give up the approach of composing a bunch of libraries to build concise, easy-to-reason-about web apps in Clojure--I think it helps with security in and of itself--but the community could really benefit from having more libraries which nail these things down and help developers build web apps more safely, with less work.

That said, I don't think it's all bad: you can build high quality, secure web apps in Clojure, it just requires you to really pay attention to security. And we should be doing that anyways, right?

route662• 12 years ago

Another important thing he points at is to not write you own incarnation of every library you find lacking but provide patches/support/whatever to existing ones. While it might help your CV to have just another template library (which will inevitably be lacking again) on github, the ecosystem profits more from a few well defined and long-term maintained choices.

stcredzero12• 12 years ago

"Yet Another Unmaintained Library" is the new useless CS master's thesis.

freshhawk2• 12 years ago

I watched that talk yesterday and it was great, his list of issues and concerns are very justified but I wasn't excited about the proposed solutions: "just pick one templating language", "everyone use a (heavy, highly opinionated) framework", etc.

They struck me as both unrealistic considering the clojure community and a little too much "find the silver bullet" for my tastes. That said, I understand why a security focused person would want this and if my role was to be concerned about these things I would probably push in that direction as well. When taking a larger view however, this is a poor tradeoff IMO.

"I wouldn't want to give up the approach of composing a bunch of libraries to build concise, easy-to-reason-about web apps in Clojure--I think it helps with security in and of itself--but the community could really benefit from having more libraries which nail these things down and help developers build web apps more safely, with less work."

You nailed it, well said. I want a checklist and good libraries, not a framework that promises to handle things for you but quietly leaves a big hole open in that one part where you had to work around the framework to solve your problem (there is always at least one isn't there?).

You just can't avoid understanding these common attacks and how to mitigate them, at least at a surface level. You have to at least know where to apply the appropriate techniques, the implementation of that technique is left up to a well documented library written by experts.

"That said, I don't think it's all bad: you can build high quality, secure web apps in Clojure, it just requires you to really pay attention to security. And we should be doing that anyways, right?"

Not only should you be doing that, but if you aren't designing with security in mind then you are doing it wrong IMHO, "secure by default" framework or not. Either the people configuring the framework or the people writing the layers at the edges need to understand web security.

All that said, I understand the push in this direction. If you have a large team of junior devs then you want to limit their power. It's just not an approach that fits very well with Clojure. It's like Rich Hickey's attitude towards unbounded queues: there is no support for them, because you must be aware of this issue and hiding it causes bugs. There, now I've invoked Rich Hickey to justify my anti-framework bias ... so I must be right.

stcredzero12• 12 years ago

"just pick one templating language"

He has a point. Is one really that much better than another? Also, shouldn't it be possible to come up with a single library to do HTML escaping that has the suitably paranoid defaults, which is then used by all the templating languages? Is one templating language's code for that going to be so much revolutionarily better than another's?

"everyone use a (heavy, highly opinionated) framework", etc.

My understanding is that he pointed that out as a solution other environments have taken (Rails) but that there was also value in the composable way of doing things in Clojure. His actual position, I understood as, "there must be some way of unifying this for Clojure."

smrtinsert• 12 years ago

We need to give it special consideration. Web libraries could make an effort to do an internal audit and maybe post a disclaimer.

As a community we should highlight libraries with a focus on security as well. I think key is focusing on making this a community consideration early and not falling into the same pit of issues as other popular languages/frameworks which shall remain nameless for the purpose of this comment.

homakov2• 12 years ago

All non-mainstreem web frameworks are very immature in terms of web security. No CSRF/XSS/SQLi projections built in, don't even say about security headers. If you use an unpopular framework you should do all protections yourself.

mercurial• 12 years ago

AFAIK, the Flask-WTF extension for Flask does CSFRF for forms. Flask also protects from XSS per default.

yogsototh• 12 years ago

Apparently you don't know yesod[1].

[1] http://yesodweb.com

homakov2• 12 years ago

they can claim to be secure, but nobody spent enough time to audit them. Too unpopular

mantrax313• 12 years ago

SQL injection is not a problem of web frameworks, because SQL should never be a part of the web layer of an application in the first place.

collyw2• 12 years ago

It shouldn't be but that's not always possible.

joevandyk• 12 years ago

Virtually all web frameworks encourage SQL. So it is a problem. Making a private api to access the database can add a lot of needless complexity.

pc86• 12 years ago

FTA:

and session cookies don't default to http-only flags (allowing XSS attacks to steal them).

Can someone explain that to me?

cryptolect• 12 years ago

Take a look here: https://www.owasp.org/index.php/HttpOnly

dminor• 12 years ago

Setting this flag on a cookie means it can't be accessed from JavaScript, so a malicious script won't be able to determine your session (for instance).

jmnicolas• 12 years ago

So what are the secure by default web frameworks apart Django and Rails ?

gclaramunt• 12 years ago

Scala Lift

mantrax313• 12 years ago

Nothing is secure by default, even Django and Rails. You can always shoot yourself in the foot, if you don't know the basics about security.

This is why the solution isn't relying on your framework, but on your competence.

e12e• 12 years ago

For something fairly modern, you might want to have a look at web2py. It goes to quite great lengths to balance sane-out-of-the-box and developer productivity:

http://www.web2py.com/

mantrax313• 12 years ago

Many things said in that video are kinda off.

He mixes password hashes and MAC (message authentication codes), saying we should HMAC our password hashes. There's little to gain from that:

- Password hashes exist to hide passwords. The attack is to discover the original password by brute force, dictionary, rainbow tables etc. The protection against this is irreducibly slow hash algorithms and unique public salt per hash.

- MAC exists to authenticate message origin. Unlike passwords, the message is often public. The attack is therefore not to discover the message, but to manipulate the message, yet make it appear from the same origin as the original message. The protection against this is the HMAC algorithm with a secret key that only the original message author has.

HMAC-ing your password hash won't stop, or even significantly slow down any of the attacks performed against password hashes, so it feels cargo cultish to claim it's just magically more secure by using it. It's even more WTF-y to claim a password hash library should offer HMAC, or it's insecure.

Once a system is compromised, and the attacker doesn't care to recover the original password, it's far more trivial to just replace the hash or just directly read the data protected by the login directly in the DB, rather than play out a MAC attack on a pass hash. It makes no sense.

HTML escaping. You either escape for HTML or you don't. There's no sane way to escape some of it. His idea that we should be able to escape some tags, but skip (or "strip") others is a huge vector of attack as HTML is notoriously filled with edge cases that your selective escaping/stripping engine won't have. It's not trivial to parse what's a tag and what isn't a tag to a browser, trust me. It only looks trivial if you're ignorant.

If you want to allow some tags, and disable others (say, allow bold/italic on forums, but nothing else) you should go through a strict DSL allowing only those types of formatting, which are then converted to HTML. Just like HackerNews does it - I type star-word-star and I get "word" in italic. That's a DSL. That DSL could be made to look like HTML, but it won't be HTML. It's fully parsed and rebuilt from the DSL syntax tree. So it can be made safe. Selective HTML escaping without those crucial steps is almost impossible to make safe by comparison.

His rant about "there are too many templating engines - we should stop" - yeah, good luck saying we should stop and this working out.

Likewise about databases. "Let's just stop". B.S. The thing he's missing is that different DB engines have different strengths and weaknesses. That's one major reason there are so many, and why many get used in the same project. PgSQL isn't SQLite isn't MongoDB isn't Redis.

By enforcing one type of database for multiple separate project components, you don't improve security, you just cripple architecture and performance.

emidln4• 12 years ago

I'm pretty sure the intention behind something like this:

    (def a-password (-> pass
                        (hmac server-stored-key)
                        (scrypt-kdf work-factor))

is to prevent all information necessary to calculate the stored hash being on the same system where the hash is stored. By HMAC'ing and not storing that key in the database (but on the app server), you now make the attacker pull off two attacks.

You could replace HMAC with encrypt with AES (or scrypt for that matter) to get the same practical effect.

Edit: clarification

mantrax313• 12 years ago

The problem of lookup table attacks is solved by the public salt I already mentioned. HMAC protects against attacks like length extension (google it), which aren't applicable for discovering a password from a hash.

Encryption also does nothing here, because it's reversible.

Your encryption key is somewhere on your server, so whatever you encrypted (either the plain text password, or the hash) can be decrypted once, and then if it's a hash you just attack the bare hash as usual (brute force, dictionary etc.).

Instead of encryption you can just store part of the salt outside the DB, but with a good hash this is usually not needed and just pointless obfuscation.

emidln4• 12 years ago

I think this is actually works. Might want a configurable work factor for the kdf.

    (ns passwords
      (:require [pandect.core :refer [sha256-hmac]]
                [crypto.password.scrypt :as scrypt]
                [environ.core :refer [env]])) 

    (def SECRET-KEY (if-let [key (env :secret-key)]
                       key
                       (throw "Set your SECRET_KEY!!!")))

    (defn encrypt-password 
      [pass] 
      (-> pass (sha256-hmac SECRET-KEY) scrypt/encrypt))

Edit: update crypto-password code to actually call encrypt.

CmdrDats• 12 years ago

Thanks for this clarification on HMAC - I was also failing to see and understand the relevance to passwords when investigating after watching the talk.

borski• 12 years ago

This presentation echoes a lot of what we've seen. For what it's worth, we scan a lot of Clojure apps and find a lot of the types of vulnerabilities Aaron/John are talking about. Feel free to run a free scan at https://www.tinfoilsecurity.com if you want to try it out. :) Would love feedback.

danneu• 12 years ago

When I think of other developers like me that are building projects solo on top of Express/Sinatra/Compojure, the most helpful resource would be a simple checklist.

For example, the CSRF section could briefly explain what cross-site request forgery is, `<img src="http://example.com/logout">`, and recommend some approaches and good practices.

Code examples could be provided for various languages/frameworks each in its own tab. The Clojure tab could demonstrate https://github.com/weavejester/ring-anti-forgery and a `anti-forgery-form-to` macro that wraps `hiccup.form/form-to` and inserts `(ring.util.anti-forgery/anti-forgery-field)` into the form.

The XSS section could remind us to ensure that our templates are escaping user input. The Clojure tab could chart the safe vs unsafe templating libs. (Hiccup is unsafe)

The Sessions section could remind us to sign our cookies so that someone can't just change a cookie from {:user-id 42} to {:user-id 1}. And that our never-expiring authentication cookie means that anyone with that cookie can log in as that user forever. It could explain an overview of the main solutions and their drawbacks like how to back sessions by a database or set an expiration within the signed cookie.

Just like convos about crypto, discussions about security too frequently turn into some abstinence-only pamphlet.

stcredzero12• 12 years ago

Just like convos about crypto, discussions about security too frequently turn into some abstinence-only pamphlet.

As opposed to a "Purity Test" as a checklist?

stcredzero12• 12 years ago

Perhaps a better title would be "Complete beginner web apps in Clojure less secure than complete beginner web apps in other environments." (EDIT: Isn't security a perfect example of a place where (good tech + good community) > (miracle tech + bad community)?)

This brings to mind an incident, about which I'll say: While I do find that the community is friendly and a source of satisfying discussion in person, the Clojure community online is notably less beginner friendly than other language communities. (tl;dr - Attempts to "help" newbs that are really opportunities to be a language weenie considered harmful.)

I find some parallels with the Smalltalk community, which had a reputation for an "ivory tower" attitude and a "Not Invented Here" snobbishness. When I was a beginner in Smalltalk, a coworker of mine had written a nice but arbitrary little DSL specification language using Array literals and symbols. So I made some sort of comment about the syntax she'd created, and which prompted a knee-jerk reaction about how Smalltalk had a small non-ALGOL syntax -- as if I were totally unfamiliar with Smalltalk syntax.

I've had experiences like this asking about the arbitrary function definition-like syntax of Compojure web application routes. Those look somewhat like function definitions, but they're really macros. I had tried for some time to Google the answer, but no one had ever posted about the exact code to do what I wanted. (Which wasn't at all abstruse. Something like getting access to the entire request map while modifying the returned session.) Well, it turned out that all I needed to know was to not refer to the request as

    [request]

but as:

    request

But instead, I got people hounding me on IRC, saying "It's all made out of functions" - with what struck me as an almost cult-like zeal - https://www.youtube.com/watch?v=ZYTkSFRmKzM#t=5 One individual snidely comments he'd put me on "ignore" and others kept telling me to go read the source code, and how wonderful that it was all made out of functions, and how wonderful it would be once I finally understood. Well, I told them that I did understand that, and that "everything being functions" had little direct bearing on what I was asking about. I am reminded of how Smalltalkers got a chip on their shoulder from the circumstance of Smalltalk's significant differences from mainstream. (Me included, I am afraid.)

Just what kind of community treats with newcomers by assuming that the newcomers are lying and then telling them to go read Lisp macros? Also, this is only the most easily related situation I've encountered while interacting with the Clojure community. There have been others.

No non-algol patterned language has ever gained more than a niche acceptance. If Clojure doesn't want to commit long term mindshare suicide, some attention needs to be paid to avoiding inadvertent hostility to newcomers. (This includes unintentionally being a bad security-defaults minefield.) Smalltalkers had the same "read the source" knee-jerk. In the end, it didn't work out so well. Care needs to be taken to understand exactly what the newbs are asking, because they know the least about how to formulate the question. Also, if you find yourself running a simplistic "pattern match" head-daemon eagerly looking for opportunities to bedazzle the newb with your wonderful, superior, and different way of doing things, just stop. You are giving your community a "weenie" reputation and your mental energies are better used elsewhere.

reitzensteinm• 12 years ago

For what it's worth, I regularly browse the IRC logs to see if anything interesting has come up, and the only time I've ever seen any amount of conflict was when you were involved - and not the incident you're describing.

They seem generally pretty helpful to newbies, from my own selfish perspective to a fault, since I have to skip past the dozens of "how do I add to arrays" with clojurebot responses.

It might be in the way you're asking.

stcredzero12• 12 years ago

They seem generally pretty helpful to newbies, from my own selfish perspective to a fault, since I have to skip past the dozens of "how do I add to arrays" with clojurebot responses.

Lots of them seem to be stuck in "quick pattern match" mode, so in the other occasions they were "pattern matching" on my asking about a much simpler scenario than I was actually asking about -- then taking my trying to inform them their assumptions were wrong to conclude something like "he doesn't understand threads."

It might be in the way you're asking.

I say as much in my comment above -- I don't know enough about how to ask the questions in the most recognizable way. However, there seems to be an eagerness to throw everyone who doesn't otherwise match in the "total newb" bin, and once that happens, an inability to parse facts presented that should indicate that their initial mental models were wrong. ("You can't do that with thousands of threads."/"its dozens of threads" -- (EDIT: and actually, it can be as few threads as one wants.))

I posit this: There are other people like me who have asked non-typical questions, were treated in this way, then just turned their backs on Clojure. I just happen to have a very strong allergy to counterfactuals and make noise in this situation.

derefr2• 12 years ago

Just what kind of community treats its newcomers by ... telling them to go read Lisp macros?

Macros (and DSLs) are more like their own little languages than they are like simple functions. To understand a macro on a fundamental level, you have to feel the need which suggested its creation. And the simplest way to do that, I think, is to read the macro's definition, to see what the code would look like without the macro there to clean it up.

This means, though, that to the extent that a library is definted in terms of macros, you have to meditate upon that library to understand not just how it was written, but why. This is the barrier macros create: without them, you can wave around other people's APIs and code in a cargo-cult fashion, and you'll probably get what you want. Macros prohibit cargo-culting a solution together: you actually have to understand the goals the library was built to serve.

cynicalkane3• 12 years ago

This is exactly the response that is a bad response.

All the OP needed is an explanation of the syntax of a Compojure macro. If someone is asking about the syntax of a specific macro, then "you don't understand macros" is not the correct response.

And that sort of thing doesn't work anyway for 90% of people.

cynicalkane3• 12 years ago

+1 about the Clojure IRC. It's very hard to deal with. I've had a lot of conversations that went something like this:

Me: What's the preferred Clojure solution for this highly specific performance issue that I've tracked down?

IRC: Did you benchmark your code? Have you tried using functions?

Me: groan

Edit: Perhaps there are some people present who want to defend the Clojure IRC channel... I'm being 100% honest with my experiences, only slightly paraphrasing things for humor value. The above conversation actually happened, in a more verbose form.

stcredzero12• 12 years ago

Right on. The thing about the kind of language weeniedom that smart enlightened people commit, is that there are always smart, enlightened intentions behind it.

Clojure web security is worse than you think

Related Stories