nonrecursive

In that case I think he's wrong. Being "different" and being "less than" are two different things, but it sounds like he's equating them, as if by going out of your way to help under-represented groups you're implying that they're under-represented because they're inferior.

To clarify what I meant in my earlier post: Yes, they are different, by definition - one group is the majority, the others are minorities. That doesn't mean that they're different in terms of intelligence, ability, or worth. Treating minorities "differently", otherwise known as "helping", is logical. It recognizes that the majority already gets "special treatment", because those in the majority are already looking after each others' interests.

This post is mostly an exposition of the author's strongly-held opinion that A) technology communities are all currently meritocracies, which is good; B) self-imposed quotas will result in something that isn't a meritocracy, which is bad; and C) organizations which strive to help minorities (women who code etc) are bad because they try to help minorities.

I'm only going to respond to C because it's the most ludicrous. Recently, I (an asian male) was a teacher assistant at the very first ClojureBridge, and during the training I learned more about why these workshops are useful and important. They create an environment where attendees feel more comfortable learning, making it much more likely that attendees will be successful in learning to program. You can argue whether or not it's "right" that women would feel more comfortable attending a workshop geared specifically toward women, but frankly I think that's irrelevant.

The author says that these organizations give the message that "These people are different from the majority so we need to treat them differently." Well, yes. What's wrong with that? The author doesn't explain. In any case, I think this is a good thing because the majority already has special treatment, thanks to human nature. There is ample evidence that women and black people are seen as less capable, even by people who have no desire to be prejudiced. How easy will it be for you to learn if the people surrounding you all assume that you're not as smart as them just because you're a woman or you're black? It's important that these conscious efforts to combat the results of our unconscious biases exist.

Makes me think that maybe I could write the code equivalent of "Scary Stories to Tell in the Dark" using Java

This is really inspiring! I had no idea that Linda co-founded Rails Girls, and for some reason I had formed the impression that she was an illustrator before becoming a programmer. I didn't know that she had learned to draw so that she could create the book.

This advice is golden, and it's pretty cool to see such joy, enthusiasm, and generosity rewarded.

I created something similar a few years ago: http://openhercules.com/ . It supports reusing lists through an explicit clone. Source is at https://github.com/flyingmachine/openhercules .

I can't speak for hendzen, but your suggestion that women avoid tech because they're not as thick-skinned as men -- as opposed to being constantly exposed to hostility -- can easily be perceived as offensive. It sounds like you're propagating the myth that women are delicate flowers who just aren't as tough as men, which is part of what allows men to continue getting away with bad behavior.

I remember seeing the same kind of arguments about Ruby when it began to become popular. "Ruby is too dynamic. You shouldn't use it on large-scale projects."

Learning a language involves more than just learning syntax and semantics. You also need to learn how to write for maintainability. It sounds like the author is less certain about how to do that with Lisp, but instead of seeing it as a chance to learn more he writes off the entire Lisp family as impractical.

This repl snippet should show that you're not actually changing a data structure in place. Rather, you're creating a new data structure and changing an existing binding:

  user=> (def a [1 2 3])
  user=> (def b a)
  user=> (def a ["a" "b" "c"])
  user=> a
  ["a" "b" "c"]
  user=> b
  [1 2 3]

One of the ideas I'm trying to convey is that the structure of the code is different from the syntax. With Clojure, special forms like def, if, etc, provide syntax in that each one has different rules for how their arguments get evaluated or, in the case of def, how the environment is changed. On top of that, you have macros which allow you to introduce arbitrary syntax.

However, all Clojure code does have the same uniform structure. It's all composed of s-expressions, which are either atoms or other s-expressions enclosed in parentheses (for lists), braces (for maps), or brackets (for vectors).

Thanks again for this feedback, having to explain this has given me some ideas for how to improve the chapter :)

But I do apologize! It seems to me like this misunderstanding has made you a bit grumpy. I apologize if that's the case. If it's not, then I apologize for being wrong!

Thank you :-)

Thanks for the feedback, I've been finding it tricky to get the explanation right here.

I don't have much time now and I'll try to reply with more later, but macros, special forms, and functions do indeed all have the same structure of opening parenthesis, operator, operands, closing parenthesis.

Apologies if the title submitted to HN was confusing. The actual chapter title is "Do Things: a Clojure Language Crash Course" but I felt that was too verbose here. The text is explicit about what will be covered: "In this chapter, you're going to explore the elements which comprise this Lisp core: syntax, functions, and data."

Clojure language crash course is meant to distinguish these aspects from the other aspects of Clojure: the environment, the artifact ecosystem, and the mindset. I mention this distinction in the introduction: http://www.braveclojure.com/

Other chapters begin to cover the mindset, or how to do things the Clojure way. "The Joy of Clojure" also covers this, from what I understand. Rich Hickey's talks are also great, of course.

Thanks for the feedback! I should add a link to Light Table, but I don't think I'll end up writing instructions for it as it seems like the existing docs are pretty good.

Great suggestion. Thank you!

I plan on adding that to the book. In the mean time, I have a series on Java for Clojurists: http://www.flyingmachinestudios.com/programming/how-clojure-...

Thank you for the feedback! Encouraging comments like this really help keep me motivated. I'm glad that the emacs tutorial was useful for you :)

I hope this provides a good introduction to the Clojure language, apart from concerns about building and running Clojure programs. I'd love any feedback :)

It sounds like what you might be asking is - it worth it to risk taking the time and effort to write a book? I'm going through the process right now, so maybe my thoughts can help.

I'm writing a free online book, "Clojure for the Brave and True" (http://www.braveclojure.com/), that has been picked up by No Starch. A couple of the chapters, "Start Using Emacs" and "Functional Programming" have done pretty well here on HN. I've made about $1k on leanpub so far for the unfinished book (ebook buyers will get the full No Starch ebook when it's ready).

The main thing that has worked for me has been to constantly get feedback from readers. Every time I release a chapter I tweet it, send it to my mailing list, and post it on reddit and G+. The comments have been overwhelmingly supportive. If it weren't for that kind of enthusiastic feedback, I'm pretty certain I would have given up.

Other people might have other ways to stay motivated, but this make the project much more "real" for me. I feel proud to provide my readers with quality content, and that they would choose to spend their time reading my work. It also helps to get those leanpub emails saying that someone has paid for the PDF - it's very encouraging when people pay for a free resource. To sum up this point - try thinking about what kind of process will make the risk worth it for you.

The second thing that's worked for me has been to write in a way that I, personally, find entertaining. When I sit down to write, I crank up the Lady Gaga and let out my inner idiot. It's way more fun that way, and people seem to like the result.

I hope this helps!

Thanks :D

I've been trying to find and fix the formatting errors. I think most of them are fixed by now. At least, I hope so!

I've been writing a book on Clojure, "Clojure for the Brave and True": http://www.braveclojure.com. It's meant to be an entertaining guide which focuses on getting you up and running quickly. It also explains the more novel parts of lisp in a clear, non-academic way.

It's free online and is going to be published by No Starch eventually. Hope you find it useful!

> Thank goodness she is famous, even if lesser known by the mainstream and friends can appeal to help her.

Healthcare in the US sucks, no doubt. But I'd say she's not getting support just because she's famous, which sounds cynical to me. Personally, I feel a great deal of gratitude toward her. Like others in the thread, her books helped me start my career. So it's not just about being famous - she's spent her life helping other people and now people want to help her back.

Thanks for the suggestion! I know next to nothing about data analysis so I might not ever get around to using or writing about Incanter, but I've seen it in action and it looks super cool. Thanks again :)

OK - I've updated that section. I hope it helps!

Thanks, this is exactly the kind of feedback I need. I'll work on clearing that up!

Thanks, fixed!

One thing I find myself doing over and over is taking as much logic as possible out of side effecting functions and placing that in a pure function, then passing the return value to the side effecting function.

Thanks!

Can I include this in the Emacs chapter? Please?

Thank you!