Hacker News new | past | comments | ask | show | jobs | submit login
Standard ECMA-4 Flow Charts, 2nd Edition (1966) [pdf] (ecma-international.org)
31 points by ingve 12 days ago | hide | past | favorite | 7 comments

I still find myself diagraming some general code bits at an extremely high-level, to help guide programming and communicate with team members.

I don't think I've ever formally used the "standard EMCA Flow Chart" notation, but I can see the benefits in standardizing upon forms (diamond shape for branches, "page" symbols, "disk" symbols, etc. etc.)

Do you have other style standards for whiteboards and such? Perhaps it is the industry I'm in, but the notation in the referenced doc feels super common even if the standard name might not be. I'm thinking about whiteboard scrawls, project requirements, ASCII abominations in email, etc.

UML was all about that. I find myself doing sequence diagrams very often. (https://en.wikipedia.org/wiki/Sequence_diagram)

Overall, UML was over-engineered and too complicated for most people to learn. Nonetheless, the various diagram-styles are great for communication and white-boarding purposes. https://en.wikipedia.org/wiki/Unified_Modeling_Language#Diag...

Ah, I see. That speaks to why I believe flowchart vocabulary is so common around me. I'm used to working in teams where UML would be largely unknown, whereas the flowchart(or basic BPMN¹) spans the non-compsci folk too.

¹ https://en.m.wikipedia.org/wiki/Business_Process_Model_and_N...

UML statecharts are OK too.

The structure diagrams, much less so, and I still think "really?" whenever I see a use case diagram. Adding a stick figure and lines and circles to something that should be expressed in sentences and paragraphs is just absurd.


They still teach these utterly useless charts in secondary school here in the US. Their value was eliminated with the invention of structured programming.

Applications are open for YC Summer 2021

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