Talk:Jackson structured programming

Modern programming languages

Is Perl and c modern programming languages? I wouldn't say so. C# and Java are modern, Perl and C are not. -- (Anon user)

Well, C is a 1970s implementation of the structured programming concepts of the 1960s that became popular during the 1980s, so calling it modern could be stretching things a bit in the 2000s ... -- Derek Ross | Talk 23:32, 11 April 2006 (UTC)

All fair points. Fixed, I hope, by rephrasing. – Jonhallett 19:34, 4 July 2007 (UTC)

I realize that most "developers" nowadays have drunk the .NET and Java kool-aid, but the reality is that C is still one of the top ten languages in demand in the marketplace. .NET, itself, was written in C++ and most Mac development is Objective C (both of which languages are variants of C). Cuda development is all C, in fact, device drivers of all sorts are written in C. Generally, where performance is a priority, software engineers reach for C, not C# or Java.-98.204.114.111 (talk) 14:24, 8 December 2009 (UTC)

Popular, yes. Modern, no. Those are different things. 141.136.240.5 (talk) 04:01, 20 July 2019 (UTC)

Iterators

Is it worth mentioning that in a "modern" programming language mismatched input/output structures can be handled by writing an iterator to present the structure of the input in a way that is convenient for the output routine? JSP is beneficial when programming in a language like Cobol or C that only allow a single thread of execution. I don't have a citation for that, so maybe via a See Also link? (Abandondero (talk) 23:02, 29 October 2021 (UTC))

Diagram Clarification - Very Important!

The diagrams need to be clarified.

You can not end a JSP diagram with an iteration or selection. You must end it in a Sequence.

Also, when an iteration is shown, you must give a termination point. I.e., do this, until that happens. - posted by 193.1.212.126

I would defend the accuracy of the diagrams against those two points. For the first point, Jackson's Principles of Program Design has many examples in which an iteration or a selection is used at the bottom level. It is true that you can't mix sequence, iteration and selection on the same level, but there are no restrictions on the final level. For the second point, Jackson doesn't add conditions to iterations until very late in the design process, at the point when he fleshes out the operations with the primitive operations. None of the diagrams is intended to show that step. -- Jonhallett 17:10, 3 July 2007 (UTC)

There is some confusion over terminology in the preceding paragraphs. I will try and clear that up. A box with an asterisk in the corner is not, necessarily, an iteration. It is the box above that is the iteration. For example: "Hand" might be regarded as a sequence of "Thumb" and "Hand Body"; "Hand Body" might be an iteration of "Finger". In this case, if "Finger" is not further decomposed into joints, sections or whatever it is a sequence, BUT IT HAS AN ASTERISK in the corner because it is an iterated component. So "You must end it in a Sequence" is correct, but the bottom level component might be an iterated (selected) component and thus have an asterisk in the corner. I hope this helps, Starkebogen 4 October 2020. — Preceding unsigned comment added by Starkebogen (talk • contribs) 06:26, 4 October 2020 (UTC)

JSP is *not* Functional Decomposition

Therefore it should not say that an operation consists of other operations ClemMcGann 14:31, 9 January 2007 (UTC)

Structure clashes

These are mentioned in the article, but the example turns out not to contain one. It would be nice to include material on the kinds of classic problems which are discussed in Jackson's book - boundary clash, interleaving clash and the collate algorithm, particularly those resolved via a pipeline of processes

Kitwallace (talk) 16:32, 22 January 2008 (UTC)

Under criticism it mentions that the method described only works for a Context-Free Grammar, without a citation. This criticism only applies to the incomplete description given on this page. The method will only work if there are no structure clashes. Is there a relationship between structure clashes and context free grammars?

The complete JSP method addresses the problem of structure clashes with Back Tracking and Program Inversion.

Ged Byrne (talk) 11:55, 31 May 2010 (UTC)

So, this "criticism" should be deleted - ClemMcGann (talk) 15:59, 30 June 2010 (UTC)

This article is woefully inadequate in explaining structure clashes, which provide the underlying insight for JSP. The example needs to be reworked, or a more suitable example should be provided that illustrates the usefulness of thinking separately about the structure of the input and the structure of the output, and observing the structure clashes between them. This article is also entirely missing the discussion of methods of implementation: multi-threaded (one thread corresponding to input, the other to output), and various serializations thereof; simple cases where the two threads correspond more-or-less 1-to-1, complex cases which require callbacks, and---I forget the name of this one, but it's the method where a function can return in the middle and resume where it left off when called again afterwards.

Coroutines?

The so-called "criticism" appears to come from a lack of understanding just what JSP is. JSP is more than capable of dealing with tree structures and other such things which are definitely more than just context-free languages.—208.91.114.4 (talk) 23:07, 24 September 2010 (UTC)

Pretty glowy ball

Somebody seems to have changed the image for Element .. unless JSP is related to ElementOS and nobody told me. Maybe that should be corrected. Just sayin'. 79.213.113.248 (talk) 15:31, 7 February 2008 (UTC)

Nevermind, fixed it. FeepingCreature (talk) 15:45, 7 February 2008 (UTC)

Hah. The ElementOS article and associated Glowy Ball Element.png image got deleted the very minute I made my changes. Great timing. Anyway, ít's working now so I'm keeping it as it is. Feel free to change the image back to Element.png :) FeepingCreature (talk) 16:07, 7 February 2008 (UTC)

Mixed languages

Why is java used in the first example of code, but not in the 2nd? This is confusing. Either use c or java, not both.
— Preceding unsigned comment added by 193.1.212.24 (talk • contribs) 2010-11-08T10:52:01 (UTC)

Data Stream Correspondences

In the worked example the correspondences identified on the individual data stream structures are NOT carried through to the conflated program structure. Either the correspondences are incorrect, or the program structure is incorrect (it is my belief that the program structure is incorrect). When an input construct corresponds to an output construct they become a single construct when the structures are conflated. In the worked example, if "First byte" on the input stream corresponds to "Byte" on the output stream we get a single construct on the program structure, which could be labelled "Consume First byte, produce Byte". Similarly if "Remaining bytes" and "Count" truly correspond we get a single program structure construct (perhaps "Consume Remaining bytes, produce Count").

Starkebogen (talk) 03:42, 17 August 2019 (UTC) Starkebogen

Incorrect Data Stream Correspondences diagram

The comment by Starkebogen is correct. The problem is that the diagram showing the data stream correspondences is incorrect. There is nothing in the input data stream that corresponds to the "Count" element on the output data stream.

If there is no structure clash, the way to create a program structure is to "merge" the input and output data structures to create a program structure that is capable of both processing all of the input components and producing all of the output components. In simple cases (like the one illustrated) the usual way to create a program structure is to take the structure of the input data stream as the basis for the program structure. Then, if there is a component of the output data structure that isn't being created by the program structure, you add a component to the program structure to create the output data component. In this case, you add the "Output count" component to the program structure, so that it creates the "Count" output data component.

Note that "there is a structure clash" basically means that you can't create a workable program structure by merging the structures of the input and output data streams this way.

On the program structure diagram (as it currently stands), all of the components that begin with the word "Count" should really begin with the word "Process". The box labeled "Count remaining byte" should be named "Process 1 byte". In a full-blown structure diagram, two actions would be hung off of that box: (increment byte counter), and (read a byte).

Kudos to Starkebogen for catching this. I am a retired software developer and for many years taught JSP and JSD in the Washington, DC area. Stephen.R.Ferg (talk) 08:22, 25 July 2020 (UTC)

Also, on the data structure diagrams, the top-level boxes should be simply "Input file" (not: Run lengths) and "Output file" (not: Encoded run lengths). And I'd probably change "Remaining bytes" to something like "Repeated bytes". Stephen.R.Ferg (talk) 08:35, 25 July 2020 (UTC)

Question about the C code

The current C code declares variables "count" and "first_byte" *inside* the loop. Is that kosher in C? I'd expect them both to be declared at the top of the program (with variable "c") and merely assigned new values inside the loop. Even if that is legal in C, it strikes me as poor program design. But I'm not a C programmer. Stephen.R.Ferg (talk)

Yes, it's C-legal. It may be poor program design from a "standard practice" perspective. However it's good program design from a JSP perspective. Remember that the point of JSP is to make the structure of the program match the structure of the input/output data. And that includes variable declarations. -- Derek Ross | Talk 17:08, 25 July 2020 (UTC)