If you want an intro to JSP, you might find helpful an annotated version [0] of Hoare's explanation of JSP that I edited for a Michael Jackson festschrift in 2009.<p>For those who don't know JSP, I’d point to these ideas as worth knowing:<p>- There’s a class of programming problem that involves traversing context-free structures can be solved very systematically. HTDP addresses this class, but bases code structure only on input structure; JSP synthesized input and output.<p>- There are some archetypal problems that, however you code, can't be pushed under the rug—most notably structure clashes—and just recognizing them helps.<p>- Coroutines (or code transformation) let you structure code more cleanly when you need to read or write more than one structure. It’s why real iterators (with yield), which offer a limited form of this, are (in my view) better than Java-style iterators with a next method.<p>- The idea of viewing a system as a collection of asynchronous processes (Ch. 11 in the JSP book, which later became JSD) with a long-running process for each real-world entity. This was a notable contrast to OOP, and led to a strategy (seeing a resurgence with event storming for DDD) that began with events rather than objects.<p>[0] <a href="https://groups.csail.mit.edu/sdg/pubs/2009/hoare-jsp-3-29-09.pdf" rel="nofollow">https://groups.csail.mit.edu/sdg/pubs/2009/hoare-jsp-3-29-09...</a>
This is referenced(1) as a core inspiration in the preface to “How to Design Programs” but i never researched it further because i’ve found the “design recipes” approach in htdp to be pretty solid in real life problems.<p>1. Analyse the problem and derive appropriate data representations, write out illustrative examples<p>2. Write a signature for the function - what does it consume and what does it produce. Spend time to get a concise definition of the computation it performs.<p>3. Create some illustrative examples of what the function does<p>4. Outline the function<p>5. Fill in the gaps to complete the definition of the function<p>6. Tidy up by converting some of those illustrative examples into tests<p>There’s a further practice to this of iterative refinement - taking what you learn as you apply this process and use that info to refine what you did.<p>This is a pretty solid way to go about things and it’s utterly trivial to bring a colleague up to speed with what you’re doing at any step when you need a hand. The biggest gap in practice of this method that i’ve found is a lack of concern for efficiency. It’d be fairly trivial to produce an n^3 solution following these steps when an n solution exists.<p>I was always swayed by the “make it work, make it right, then make it fast” approach before.<p>(1) … Actually i just went and opened the book, the actual reference is to Michael Jackson’s method for creating COBOL programs which is the progenitor of JSP.
Heh. I remember when the concept of subroutines was considered dangerously subversive.<p>Structured Programming was thought of as revolutionary. Most folks were either doing COBOL or Assembly, at the time. C was just beginning to feel its oats (It was still thought of as a mostly academic language, but it spawned a few languages that were considered "workhorse" languages, like PL/1).<p>I did start using Pascal, in the 1980s, because that was Apple's native language. It was a very strange language, coming from Assembly, FORTRAN, BASIC, and PL/1.
> In Chapter 3 of Principles of Program Design[1] Jackson presents two versions of a program, one designed using JSP, the other using the traditional single-loop structure.<p>I think I've come back around to seeing some merit in the "traditional" version. All the state is declared before the main loop. You could stop the program after any iteration of the single loop, save the explicitly declared state, and restart where you left off. The logic inside the loop can be applied to any record and state.<p>In the double-loop version, your place in the control flow is part of the state. If you stopped, you wouldn't know where to start up again. There's also a state variable (firstLineOfGroup) declared inside the loop.<p>I know why I prefer the "traditional" version: it can easily be refactored to be functional, and making the state explicit means it doesn't have to be refactored if I want to store the state externally or switch from a batch architecture to a streaming architecture. The JSP version is inherently imperative and needs to be refactored before it can be used in a different architecture. Funny how ideas like that alter your taste.
There's an old Rob Pike talk where he asks the audience:<p>"So how many of you are familiar with the work of Michael Jackson"
Most of the crowd raises their hand to which he replies
"Really? Quite a few! Well as you know, Michael Jackson developed Jackson Structural Programming".<p>He was seemingly unaware of the popstar of the same name.<p>- <a href="https://www.youtube.com/watch?v=HxaD_trXwRE&t=44s" rel="nofollow">https://www.youtube.com/watch?v=HxaD_trXwRE&t=44s</a>
Disclaimer: I have done exactly 0 research on JSP before today and come from python/lisp land.
Being in the middle of developping an OpenAPI application with python's Pydantic (an extension of type annotations), I can't help but feel python is <i>this</i> close to being a combination of JSP and data model definitions.
To go one step further if you write your modules with Hy (a lisp that interops & ~transpiles to python), you get a pretty darn elegant codebase that is a rather direct mapping of your domain problem to expressions which look a lot like these JSP examples.<p>Maybe I'm only just discovering for myself the "power of typed languages" (feel free to rib on duck typed devs here) but it feels like a huge progress in terms of productivity, bug count and readability. I love modern python.
I've just got "Structured Program Design Using JSP" off the bookshelf. Haven't looked at it in about 30 years!<p>I was once sent on a work course to learn how to write COBOL using Jackson Structured Programming. I _loathed_ it. I remember thinking that<p>a) it tried reduce the programmers role to little more than that of an automoton
b) it was completely at odds with my views (30 years ago and still today) that good software development is a blend of the technical and creative/artistic.<p>Happily very little of my working life involved actually using JSP (well Java Server Pages excluded).
For such a young discipline, it's amazing how much of software practice used to be standard operating procedure and is now all but forgotten.<p>At one time Dijkstra had to actually <i>argue</i> for structured programming. No-one would take the counter position today.<p>The equivalent debate nowadays is between languages that separate statements and expressions and expression-oriented[0] languages.<p>[0]: <a href="https://en.wikipedia.org/wiki/Expression-oriented_programming_language" rel="nofollow">https://en.wikipedia.org/wiki/Expression-oriented_programmin...</a>
I started out from a BTEC (changed to BECTEC and 2 years instead of just 1 year shortly after I did mine) and was taught COBOL. First Job doing COBOL and I wrote a program, really upset the analyst - as with JSP exception handling done way differently than just using GOTO (a COBOL verb I'd never used or was even aware of as was hard core JSP). Was explained the whole aspect of efficiency and with many aspects of code - what looks neat and nice today over time will get modified and how it was easier to modify something with GOTO's over some elegant JSP layout. That and efficiency of the code - performance.<p>So I learned the usual lesson many do when you go from Educational ideals into Working reality. Real World business don't run on cutting edge changing soon as that changes, legacy/stability and historical aspects do play out. So whilst you may know a better way, there are many factors that make that impracticable. Sure if rewriting your code-base and hardware to the cutting edge of the time was viable then people would do it, but testing and verification of code - when done properly takes longer than the time to build the latest cutting edge system. Let alone the whole cost factor.<p>I imagine many have comparable stories upon their move from the realms of Education into Work. Do share as be nice to read what brain-walls today's first workers encounter.
For those not familiar with the JSP style alluded to in the comments, and its contrast to the "traditional style," here's an example of a function that splits a string into words. The "traditional" version was shown by a famous computer scientist in a conference talk a few years ago; I translated it to JS to provide some anonymity :-).<p>JSP's claim to greater clarity is based on the correspondence between the code blocks and the structure being processed: the body of the outer loop processes a group (of gap and word); the body of the inner loops process a gap and a word respectively. The traditional style, in contrast, is like a state machine, and can't be viewed structurally---you need to think about what's happening at each point. This makes it harder to modify the code (eg, by adding something that happens once per word, which is now in two places) and often leads to bugs.<p>This same structural clarity is why, in my view, code that uses list functionals like map/reduce is usually more comprehensible than traditional imperative code.<p><pre><code> // JSP version of a split function
split_jsp = function (s) {
words = [];
i = 0;
while (i < s.length) {
while (is_white (s[i]))
i++;
word = "";
while (is_alpha (s[i]))
word += s[i++];
if (word.length > 0) words.push(word);
}
return words;
}
// "traditional" version of a split function
split_traditional = function (s) {
words = [];
word = "";
for (i = 0; i < s.length; i++) {
ch = s[i];
if (is_white (ch)) {
if (word != "") words.push (word)
word = "";
}
else
word += ch;
}
if (word != "")
words.push (word);
return words;
}
is_white = ch => (ch == ' ' || ch == '\t' || ch == '\n')
is_alpha = ch => ch != undefined && (/[a-zA-Z]/).test(ch)</code></pre>
Read the book, which I obtained from the British Council library, when I was around 15. I have to say that the book made quite an impression on me at the time.
i believe this is equivalent to a modern functional effect system, which compiles an AST (typically a hosted monadic sub language, or equivalently a s-expression with control flow) into a DAG intermediate language. The DAG is abstract and is then further interpreted or compiled into an execution target, which evaluate the DAG with late bound runtime properties like asynchrony, exceptions, side effects, garbage collection, structured concurrency. the key idea is that the DAG is abstract and has no notion of the runtime behaviors like asynchrony; structured programming is about capturing the computation’s essential structure as a DAG and then using that structure to reflect the target runtime behavior. E.g. interpreting edges of the DAG as callbacks. Structure is also about constraints (what you can’t or shouldn’t do) and for example a DAG can’t express goto. But a DAG can express stack frames and lexical closures (by nesting).
I was taught this when working at British Gas in the mid 80s. I remember this being followed by Delta 3GL which allowed you to allocate code to the pre and post hooks etc of each node. Your function ‘places’ were there and you just assigned code. It was a very methodical way of working and IMO left less room for error.
I tried to follow Jackson’s book on Problem Frames, did not complete the book, though I’d consider trying to read it again. Its a non-formal or semi-formal methodology that emphasizes understanding the structure of problems and domains before solution design. Its a technique of architecture and systems engineering.
I have to admit that when I first heard the Jackson reference in <a href="https://youtu.be/HxaD_trXwRE?t=00m44s" rel="nofollow">https://youtu.be/HxaD_trXwRE?t=00m44s</a> I thought it was about the other Jackson.
this is how I was first taught how to design software. I found it quite unnatural and didn't really use it. But it did help me start thinking about how to structure software.