railroad vs block diagrams

[Weiss]

Interested to know the opinions on use of railroad diagrams. I used block diagrams when first expksed to programming, back in late 80's. Straightforward and well understood, kind of fell natural. But now I am going through books where there is extensive use of railroad diagrams, and not a single block diagram.

My concern is, should I get used to them, are they better in a long run? I am having design issues, and feel that block diagrams would be more natural representation of a flow. But, I would like to hear from more experienced folks. Right now I really have to work if I want to decypher railroad diagram, and even then it is still ambiguous.

[MarkMLl]

I think this is domain-specific, plus also depends to some extent on the mandated style of the company you're affiliated with.

B. used railroad diagrams exclusively for language descriptions, and- from memory- most if not all command syntax etc. Other companies use (E)BNF for languages, or even some "more recent" notation.

Then when you're moving into application design there's the "tried and tested" flowchart with standardised outlines, plus many /many/ more recent design methodologies some of which use boxes and some which try to be entirely textual.

So I guess that much if not all of the answer is "it depends who you're talking to".

MarkMLl

[VisualLab]

B. used railroad diagrams exclusively for language descriptions, and- from memory- most if not all command syntax etc. Other companies use (E)BNF for languages, or even some "more recent" notation.

That's exactly right. Railroad diagrams are definitely better at explaining the syntax of a language than (E)BNF. Especially if someone doesn't already know the details of the language syntax very well. (E)BNF is a formal notation that is not useful for learning programming. It was invented to describe the grammar of (formal) programming languages. It is useful for people designing new languages ​​and their compilers or interpreters.

Then when you're moving into application design there's the "tried and tested" flowchart with standardised outlines, plus many /many/ more recent design methodologies some of which use boxes and some which try to be entirely textual.

Block diagrams were invented to show how a program, procedures or algorithms work. But people, as usual, like to complicate things. And after many years, a monster called UML was created: a set of many diagrams grouped into structure diagrams and behaviour diagrams. Out of all this, usually only a few types of diagrams are used most often (activities, classes, interactions, states). An activity diagram is basically an block diagram "on steroids". They are still widely used because of their clarity.

So I guess that much if not all of the answer is "it depends who you're talking to".

Yes.

[MarkMLl]

That's exactly right. Railroad diagrams are definitely better at explaining the syntax of a language than (E)BNF. Especially if someone doesn't already know the details of the language syntax very well. (E)BNF is a formal notation that is not useful for learning programming. It was invented to describe the grammar of (formal) programming languages. It is useful for people designing new languages ​​and their compilers or interpreters.

I'd tone that down frankly. I'm not 100% certain who invented railroad diagrams but they were in part popularised by the ease with which they could be printed on line (drum/chain) printers after their early exposure describing ALGOL.

BNF was largely contemporaneous with FORTRAN. EBNF was primarily associated with Modula-2. I'm cautious about calling either of those "formal languages" in the current sense, since they're a long way from being provably correct etc.

Flowcharts (plastic template stuff) were more of a top-down thing used by systems analysts and their ilk.

From the early 60s onwards, their was ongoing work to define compiler-compilers in further-extended BNF-like notations. I don't believe that either Backus or Naur were involved, Wirth definitely wasn't. You can machine-process something like (E)BNF into a compiler, you can't do the same for a flowchart.

So again: more than anything else the notations are distinguished by their domain.

MarkMLl

[VisualLab]

BNF was largely contemporaneous with FORTRAN. EBNF was primarily associated with Modula-2. I'm cautious about calling either of those "formal languages" in the current sense, since they're a long way from being provably correct etc.

Flowcharts (plastic template stuff) were more of a top-down thing used by systems analysts and their ilk.

From the early 60s onwards, their was ongoing work to define compiler-compilers in further-extended BNF-like notations. I don't believe that either Backus or Naur were involved, Wirth definitely wasn't. You can machine-process something like (E)BNF into a compiler, you can't do the same for a flowchart.

I only meant their application. Three different notations: (1) train diagram, (2) block diagram and (3) EBNF. And their completely different applications.

Sticking to the topic:

• for semi-graphical presentation of language instructions - railway diagram,
• to present an algorithm or program operation (procedure/function) - block diagram.

[Weiss]

Sticking to the topic:

• for semi-graphical presentation of language instructions - railway diagram,
• to present an algorithm or program operation (procedure/function) - block diagram.

I find block diagrams easier and clearer than railroads, in language context. Logic doesn't know what it is describing. I like BNF too.