Hacker News new | past | comments | ask | show | jobs | submit login

    > Beyond any educational benefit, what do you see as the 
    > advantages of programming in this way?
For me (and I'm just getting started here, I've only been playing around with this in earnest in the context of the little blog engine, and there are certainly many different ways of going about it), it makes the process of exploratory coding feel very different. Instead of thinking up a series of classes or functions that might solve the problem, and starting to write them -- I instead start by outlining (literally) what I want the program to do, and then describe the functionality in paragraphs, and then implement those paragraphs.

When the paragraphs have code below them that does what they say they do, the thing works. When I end up coding myself into a corner, I rewrite the paragraph and change the code. It's really a very different process than usual. It's also definitely more work than just doing code and omitting comments -- it takes a bit of elbow grease to prevent the comments from becoming lies ... but it's the same type of work as preventing bits of your codebase from becoming dead code.

For me, it seems to make me organize code into smaller functions grouped together into sections, use less classes, and care more about putting things in the place where you're talking about them, and less about putting similar things together in one block of code. For example, I started to require things close to the paragraph where I first mention them, instead of putting all requires at the top of the file. At least, that's how it feels so far.




I'm glad to know I'm not the only person who works this way. My source files often have a paragraph or two at the top that explains my intentions for that class/module as well as explains the usage of my domain language. I never see this in other people's code though.

I agree with people who say that the code itself should read very clearly, but the fact is that even when writing an article or paper you have to disambiguate your own writing, clarify your usage of terms and present some context up front. Otherwise people can take away a very mistaken impression of your text, and it is certainly no less true for code.


Quite interesting, I do something similar to that on a smaller scale. When I do a class/method, I usually just put comments describing what's going to happen and that makes me thing of cases I might have missed otherwise and then I add the code below each comment.

Will try literate coffeescript next time I use it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: