Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This style of documentation is called literate programming, and you should go and google about this term and the various implementations for various widespread programming languages if you never heard of this before. It's an eye-opener how clear, transparent and well-intertwined good code and comments can be.

I've used such a literate programming style with scientific python once in university classes and it was a breeze to prepare and hand in exercise sheets (rendered with Latex to PDF). My feeling was that today people use Jupyter/IPython notebook to archieve something similar (especially with embedding results), but a jupyter notebook is much more complex than a traditional, clean and terminal-readable literate programming source code.



We used https://coffeescript.org/#literate for some products at https://forestpin.com and it was so much easier to maintain.

One of the problems with notebooks for literate programming is that it kind of breaks down when you define a class or a long function. The entire code has to be within a single block.


Or you could use org-mode with org-babel in Emacs to get a great document allowing to use many different programming languages. The coffeescript URL already has an org in it. Coincidence? I think not! ;)


You can define a class and then use it in a different block just fine, so it's not entirely clear to me what you're referring to here?


All of the class definition has to be in a single cell. You can’t have notes within it only normal comments


I don't think this qualifies as literate programming, at least not in my book. Yes, it looks nice and everything but from my point of view OP just moved regular code comments to a side bar.

For instance, there are many comments that explain what values are stored in opaque-looking variables/parameters. But these are simply necessary (especially in data science, where almost everything is a tensor) and should be part of every decently documented program, anyway, and don't make this literate programming yet just because they're now in a sidebar.

Besides, there are a lot of comments that 1) just repeat verbatim what the code does, e.g.

    Run through each layer                   for layer in self.layers:

  (https://nn.labml.ai/gan/cycle_gan.html)
or that 2) explain what the code does because the code, at times, is unnecessarily hard to read and/or little modularized (no offense, OP).

These types of comments, I'd say, belong to the sort of comments and documentation that can (and usually should) be avoided. They don't tell me more about the code than what the code already tells me (or should/could tell me) and thus are not what I would expect from literate programming, either.

There are a whole lot of other types of comments that I would expect from literate programming, though, and these are mostly missing. There was an excellent article[0] a few years back by Salvatore Sanfilippo aka antirez (of Redis fame) where he identified the following useful comment types:

    - Function comments
    - Design comments
    - Why comments
    - Teacher comments
    - Checklist comments
    - Guide comments
Now, the OP's code checks off one or two items on that list but only in parts and in a few places. Overall, looking at the many code snippets antirez's article presents from the Redis code base, I find Redis's style is much closer to my idea of literate programming than the OP's code.

(Again, I hope OP is not taking offense to my comment. I am aware that they didn't claim they were doing literate programming.)

[0]: https://web.archive.org/web/20191224044125/http://antirez.co...

EDIT: When I wrote my comment, I hadn't looked at all the pages/files and simply assumed the others I hadn't looked at would be similar. I've now noticed, though, that some of them do follow the literate programming style quite closely. Nice. :)


Unfashionable though. I strongly believe in working this way, but in a webdev environment, such work rarely gets through code review.

The usual argument is that code should document itself, or something of the like.

Data scientists uphold the standard admirably though, as you say.




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

Search: