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

> Notice that the original code hasn't changed. The only information transmitted in the answer is the corrected diagram. That is because to the person asking the question, the diagram is a better representation of their mental model. As such, getting an corrected diagram has an effect on their mental model but looking at the code doesn't.

This argument (that he tries to make several times in the article) does not hold.

Almost every time, the diagram is a _lower level_ representation of the program than the code is. And then he says "look! you can't figure this out from the code" (so therefore diagrams are better), but if the code was similarly represented in a lower level, you totally could.

And similarly, if the diagram happens to _not_ contain this extra lower level information, you can't figure it out from the diagram either.

I'm not saying diagrams aren't good, they can be great, it's just the reasons in this article aren't particularly compelling. But maybe I'm missing the point.



[post author] You are right. Any "language" visual or other wise used for communication has to include the level of detail trying to be communicated. In the Rust memory layout example, Rust syntax doesn't spell out its memory layout in Rc<T> definitions.

The point though is that the two users of the language _decide_ to communicate in a visual representation! Why is that?

They could spell it out in text, adding that lower level to the text, and yet they don't. That is a sign the users are thinking about it visually and the visual representation maps better to what they hold in their head.


Most of his examples are derived from the code?

They're generally showing consequences of the code, like the layout in memory or the swimlane diagrams. This isn't quite the same thing as code.




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

Search: