Algorithmic thinking is fatally overrated. Top-down deconstruction of complex problems is a trap into which generations of modern programmers endlessly fall, because all the algorithmic skills in the universe won't make up for a foundational ignorance of the problem domain. This is why so many modern business and government software systems royally suck: because the people—modern professional software engineers—who build them have zero knowledge or interest in learning the jobs those systems are meant to do.
What Logo taught was bottom-up constructionism, where you learn the problem space first though exploration and experimentation. As you go, you compose your own vocabulary of custom words to more efficiently describe it, until you've built up both your own understanding of the problem space and your own set of tools for working within it that you can start to construct solutions to the problems at hand.
For instance, if your task is to draw a city then you don't start by designing the finished roadmap with industrial, commercial, and residential zones, and the complete list of structures that should appear on each—because unless you're already an professional city planner you have zero knowledge or experience in how cities are structured or work. Instead, you start by learning the basics, such as how to construct a house using only the general-purpose primitives you get for free: lines and angles. Using only those, you can create your own words for drawing simple geometric shapes: rectangles, triangles, circles. You can then compose those into words for drawing the outline of a simple building (a rectangle with a triangle on top), a window (a grid of 4 rectangles), a door (a rectangle with a circle for doorknob).
Once you've got that vocabulary, you can very rapidly iterate a whole variety of words for drawing various shapes, sizes, and types of buildings, choosing to keep the words that work best and discarding the ones that don't. While you're learning how buildings are built, you can experiment with adding other kinds of words for drawing trees, park benches, traffic lights, and so on. And once you've built up your own "city-building" vocabulary, you can very rapidly experiment with different kinds of city structures and layouts to learn what works well and what doesn't, once again capturing the successful compositions as your own reusable words.
By the time you're done exploring this particular problem space, not only do you have a really good personal understanding of how cities are put together, you've also got an incredibly powerful—and shareable—language for building cities very quickly and efficiently. Thus your original problem requires only a little more top-down work to arrive at a complete solution. And then, if your first completed city isn't entirely to its inhabitants' taste, that same set of tools also enables you to rebuild it very quickly and easily as well; nothing is set in stone, and improvements made at one level automatically propagate to all subsequent levels as well. Or, you could even introduce them to some of the city-building vocabulary you've already created and let them adapt and enhance your initial cities for themselves.
...
BTW, if this bottom-up approach sounds vaguely familiar to older programmers, that's because it is: it's exactly how Lisp and Forth systems build things (and Logo, which is a hybrid of the two). When the CS profession created Algol, it made a fatal error: it mistakenly declared Algol a general-gurpose language when it was, in fact, a Domain-Specific Language: a procedural number-crunching language specifically designed for the subset of computer users whose job was to write procedural number-crunching systems. And that broken thinking has been steadily baked in ever since—through, C, Pascal, C++, Java, Swift, Python, JavaScript, and so on.
So now we have generations of modern mainstream programmers who are experts in using incredibly complex, dumb, and limited "programmer languages", and absolutely no clue about the real-world problems (accounting, asset management, shipping, etc) that they're being tasked to solve; and worse, they don't even consider learning anything about those problem domains because they are Professional Programmers and all that stuff is completely beneath them. And then they wonder why user requirement specs are useless, and user requirements endlessly flux, and the users hate every system they build.
Modern mainstream programming culture is a profoundly anti-human artifice, not just for users but for developers too, and it seriously needs to go because it's not so much a problem-solver as problem-generator. But for programming to change, the languages need to change first. Right now we have languages that dictate to their users (developers) how they will (and won't) do their jobs. What's needed are languages which their users can teach how to do their jobs for them. In other words, the truly general-purpose languages are Lisp-y ones, because those are the [meta-]languages that enable the user to build her own languages—i.e. her own tools—that do exactly what she wants in exactly the way she wants it done. Forcing every language user to be subservient to the particular ideologies and whims of a tiny handful of Richies, Stroustrups, Lattners, et al is not just wrong but astonishingly foolish too. While those guys may be incredibly smart inside their own incredibly narrow field they know next to nothing of the needs and wants of every other person on the planet; so why on Earth would they (or anyone else) think them the right people to dictate exactly what languages everyone else should use?
...
Languages are the tools we create for ourselves in order to express our own particular needs and wants efficiently and precisely, and in turn help to shape how we think. Languages and mindsets that teach tool use, not tool creation, are mindless exercises in OCD Aristotlean ontology, not actual learning.
Which brings us back again to Seymour, because Logo's goal was never to teach was not how to build cities or write software or manage projects, because these are all extremely specific problem domains only of interest or relevance to a small subset of people. Instead, Papert was trying to instill in all children the foundational skills and insights that underpin all human creativity and creating—open enquiry, structured thinking, analytical problem-solving; the ability to learn for themselves—and so empower every single one of them to grow into an adult who knows how to learn and build and solve for herself in whatever pursuits she chooses. Next to that, teaching CompSci in classrooms is petty beans indeed.
--
TL;DR: Teach a person how to fish, and she can make supper. Teach her how to learn for herself, and she can make worlds.
