The paper's title is Purpose-First Programming: A Programming Learning Approach for Learners Who Care Most About What Code Achieves
This URL's author says the paper's author "invented purpose-first programming," but I think it's proper to clarify that the paper's author has demonstrated positive results from a different ("new"?) learning approach, and then named it "purpose-first programming."
I would argue that "we" already value purpose-first programming - we're concerned with what the software does moreso than the syntax required to make it happen. But academia, anecdotally, doesn't usually value purpose-first programming.
Perhaps "purpose-first programming education" would be a better way to phrase it. Which, yes, is incredibly valuable. I recently adapted my learning process from tutorials to taking a problem I already know how to solve with a different language or tool and solving it with something new. It frees the mind space required to define a problem space, figure out process, etc., and allows me to focus on learning how to do that thing with this tool. Then if I'm attempting something I don't really understand, I'll use tools I understand well.
I don't understand this trivializing of her work. Her project is innovative in teaching programming and is a product of research and she coined its name. Same goes for TDD, it's an innovation in the approach to coding, and someone gave that a name. We had tests before and we valued tests but that's not the point.
I have my own reservations about her method, but that does not mean her work is trivial.
Where in "X-first programming" does that constraint come from? What seems to have happened here is that you read "purpose-first programming", inferred that it's a methodology for developing software, and then started insisting that the responsibility for your taking that leap is someone else's fault, instead of yours.
"Purpose-first programming" makes as much sense as "literate programming".
The first year computer science course that I’m currently assisting at my university has followed a curriculum and philosophy based on the book HtDP by Felleisen et al [1]. The model we follow is called the “design recipe” which teaches students to write the documentation for a function as well as some basic examples and tests, all before writing a single line of code for the function itself. The very first of all these steps is to write the purpose statement which serves to document what a function does. As a teaching tool, it helps the students to organize their thoughts and plan their function before they start.
This book is almost 20 years old. It derives from earlier works such as SICP. The concept of writing a purpose statement before you write any code is not a new idea at all. But it seems to be a very good idea. If you can’t write one sentence describing what problem your function solves then you’re probably not ready to start writing it.
The approach you're explaining makes logical sense, but that's a really boring way to learn programming. It could work for CS-students, which are pre-selected in a way, but I still wouldn't teach students that methodically. There's just no fun there.
For example, I'm an adult-ADHD developer in my 30's and really good at my work. I started programming, by just doing fun things and it's only been after few years as a developer, that I've become interested learning more about CS-theory. It's hard to be interested in such topics unless you have insight on why such things matter.
Yeah, so what we've found in the course is that the students hate doing it and tend to mess around a lot instead of following the rigorous procedure, at least with the early assignments. Later on in the course the problem sets get difficult and the students start to gain an appreciation for the process. It stops being this boring thing they're required to do and starts being a powerful tool for them to organize their thoughts instead of muddling around without making any progress.
I'm curious to hear more about what distinguishes learning to program in a "purpose-first programming" approach.
This sounds really similar to constructionist learning ideas that Seymour Papert espoused. Remember Logo? That's Seymour Papert. His paper "What's the big idea? Toward a pedagogy of idea power" is a good place to start that straddles the line between concrete and conceptual. Paper link: http://worrydream.com/refs/Papert%20-%20Whats%20the%20Big%20...
Purpose definitely should be a focus in teaching, and not only in programming but in every other subject as well. Purpose tree is the most simple and natural way to structure all the information that we study. I'm sure good learners already structure their knowledge around the idea of purpose (probably unconsciously).
Next paper: Discovery of pseudo way to code, with no code. We show, contrary to modern tribal rituals, that drawing diagrams help students visualize their plans and improve results and effectiveness. The author heralds new dawn of human-machine cognition.
Joke aside, building something for a purpose is a great way to learn, ie. just look to gamer/mod culture and self-taught techies.
OTOH, building stuff/knowledge without purpose leads too often to a blind alley, or a hopeful pivot.
I can't decide if you are making fun of diagram drawing or endorsing it, but here is my take on it.
I often start programming by "drawing" sequence diagrams, by typing up PlantUML descriptions (https://plantuml.com/sequence-diagram).
This is especially useful, if the purpose of the program is to communicate with many other programs.
A sequence diagram allows to establish a language around the purpose of the program. Having it described textually allows extremely cheap (within minutes) iteration on names, algorithms and the architecture.
Showing all these aspects concisely at once makes it possible to develop a consistent, yet concise naming scheme, which can greatly reduce misunderstandings.
You can discover disconnects of interactions, the data flow or ordering errors by simply following the arrows with your finger/pointer and reading it out loud.
Just messing around. Diagrams are cool though. Especially sequence diagrams can clarify important processes that otherwise are not so clear. I like the text-only aspect to notes and documentation, as that tend to remain accessible and light-weight.
This URL's author says the paper's author "invented purpose-first programming," but I think it's proper to clarify that the paper's author has demonstrated positive results from a different ("new"?) learning approach, and then named it "purpose-first programming."
I would argue that "we" already value purpose-first programming - we're concerned with what the software does moreso than the syntax required to make it happen. But academia, anecdotally, doesn't usually value purpose-first programming.