evanrmurphy

I also had trouble phrasing the idea in a way that didn't sound stupid.

Also, if you just resolve to always use classes instead of ids, then you can eliminate the cognitive overhead that comes with every new selector of, "Should this be a class or an id?".

I think when you find yourself writing nested selectors that are heavily dependent on the HTML structure, it's an indication that your code could be less fragile if you just used the HTML style attribute instead.

Edit: Rephrased to try and better express the idea.

Would you mind elaborating on the JavaScript point? Is it for convenience with document.getElementById or something?

Using jQuery, I tend to prefer class selectors the same as in my CSS.

Take the OP's example for the Writer monad, in which several functions needed to return a debug string "<function name> was called" in addition to their main return value. If I had these two functions+:

  (def sine (x)
    [(Math.sin x) "sine was called"])

  (def cube (x)
    [(* x x x) "cube was called"])

  (mac defWriter (name parms body...)
    `(def ,name ,parms
       [,@body (+ ,name " was called.")]))

  (defWriter sine (x)
    (Math.sin x))

  (defWriter cube (x)
    (* x x x))

+ Forgive me for indulging in the syntactic sugar from my own lisp->javascript project in these examples, but since we're dealing in JavaScript I couldn't resist. https://github.com/evanrmurphy/lava-script

You see, I already sensed that monads:

- were a way that you could sort of simulate side effects using pure functions

- had to do with the type signatures of functions

What I gleaned from the article is that monads:

- have to do with making functions composable

- work by way of the abstractions bind and unit in order to make type signatures match

Did the article harm my (lack of) understanding of monads?

Have you been able to pull this off in most cases?

In my experience, the mobile version of a site requires changes to the HTML, such as turning links into buttons and removing content.

To be sure, I'm talking about CSS for layout here, not styling. I find CSS for styling to be relatively straightforward.

However, a book is a very different investment from "maybe ten minutes of reading a how to guide".

Sorry but I'm skeptical.

If you could prove this by sharing a paragraph or two (should be all it takes, right?) teaching how to use CSS to build reliable layouts I would be grateful.

However, since Java was not intended to be a scripting language, then it should never have monopolized the material of introductory programming classes like it did. I consider Java to be a very ungentle introduction to programming when compared with Python, Ruby or Scheme.

A key tradeoff is that they must be expanded at run-time, and in doing so they incur a performance penalty that doesn't exist with compile-time macros.

I believe that in most dialects of lisp, macros must be defined before they can be called. [citation needed]

This is not to undermine your point, which I think is valid. Macros would just be an interesting exception because they're arguably the feature of lisp, and surely make up > 1% usage for that family of programming languages.

Now, I'm relatively new to literate programming, and perhaps the answer to my question(s) will be obvious to someone more experienced with it. What I wonder though every time I read about it is, who is the intended audience of all this extensive documentation? More specifically, how much knowledge of the programming language and problem space do we presume that the reader has?

There is something elegant about presuming the audience has expertise in both areas. That way you only have to worry about documenting one thing, the program, rather than three things: the program, the programming language and the problem space. Readers lacking sufficient understanding of the lang or problem space can refer to the more robust documentation about either one individually to get themselves up to speed. But I'm not sure Docco users are taking this approach.

---

[1] http://www.paulgraham.com/desres.html

On second thought, this isn't a major product at all. It's actually quite obscure. I just like it a lot.

You probably wouldn't like it. ;) Seriously though, I think what we're used to plays a tremendous role in our preference here.

> I also don't know how Emacs handles the indentation for these

For Arc, anyway, the indentation algorithm is constantly making mistakes. I always hesitate to auto-indent a region because I know I'll have to go through and manually fix things. But I'm not sure this is the language's fault - the Emacs mode probably just needs to be smarter.

> And indeed, there is a point in the learning curve where you get confused about the proper numbers of parentheses for certain kinds of expressions (so-called 'special forms'). [...] In my experience, what happens is that as you become familiar with these 'special forms', you learn to recognize the visual patterns of indentation and parentheses that are particular to each of these expressions.

Yes. This seemingly mundane topic actually interests me a great deal.

One thing that I appreciate about Arc, despite all of the language's shortcomings today (few libraries, no module system, tiny community, scarce documentation, etc.), is that its designer has taken great care to minimize the number of parentheses. The core language almost as a rule doesn't employ parentheses unless absolutely necessary, and it's nice to have a guiding heuristic like this while you're learning because it allows you to internalize the special forms more quickly.

Could you please link to some web apps built in Clojure? I really wanted to use Clojure for web development, but because I couldn't find many existing projects, I kind of concluded that if you really need to build anything serious you should be using Rails.

More recently, Jacob Rothstein started Sibilant [4], which I've been collaborating on [5]. The main difference in approach is that we're trying to design a new lisp dialect optimized for the task of writing JavaScript, rather than compiling from an existing lisp dialect that wasn't designed with this purpose in mind. Since it's such a young project, I wouldn't recommend it for production environments now, but you should keep an eye on it if you're interested in this sort of thing.

---

[1] http://common-lisp.net/project/parenscript/

[2] http://www-sop.inria.fr/indes/scheme2js/

[3] https://github.com/arohner/scriptjure

[4] https://github.com/jbr/sibilant

[5] https://github.com/evanrmurphy/sibilant

I agree. It would be a real headache. That's why I would have been really impressed if they did it. Or rather, I would have been really impressed if they found a way to do it that wasn't a headache. :)