Let me supplement physical toys (which are most important for sure) with some additional ideas for building future programmers.
Children ages 3-7 are really just beginning to learn how to think abstractly, which is a pretty core competency for programming. So when you say you want to teach fundamentals of coding, you really aren't even at "coding" yet. You're really at the fundamentals of math, language, reasoning, and problem solving and curious mindsets.
So what are the fundamentals of coding that 3-7 year olds can actually do?
1) Math - I would scour the web for all the different ways you can do basic math with any type of physical object (pencils, fruit, whatever). You may think it's too simple, but if you take a cognitive approach to this, practice must be done at some point with mapping a number of any object to it's linguistic representation in one's mind. Practice counting up/down, sorting stuff into groups and sets, quantity, patterns (2x3, 3x2, are they the same? what's different?) etc, and doing simple arithmetic with actual objects. This is new to them and is fundamental to everything else.
2) Language - have adult conversations with your kids, and no not about adult topics, but with adult words and with adult grammar; no "baby-talk" in other words. And it's not about purposely choosing large and obscure words to obfuscate, but picking accurate words that probably leave little holes in understanding for the child to try and reason about. Hopefully they will ask if they don't know, or may even surmise correctly about word/phrase meaning. This might help with...
3) Reason/problem solving - Encourage experimentation in everything. If they see you constantly trying new things and failing gracefully and focusing more effort on finding solutions then hiding failures, you've taught them one of the most important lessons of all. Try, try, try many times, then go ask someone. You should be unquestionably the expert in some things, and a complete novice that asks questions and learns quickly in other things, and they should watch you in both situations. Seeing role models do both is an immensely powerful thing to observe to young children. It shows that adults can be both powerful professionals and learners. Where do you think they learn to laugh at, criticize, and fear failure? It's cultural. Make failure just another step to mastery.
4) Curious mindsets - in every category above, there are always opportunities to ask "why do you think this is?" or "how do you think this works?". You might get gibberish most of the time but it doesn't matter, they are going through the thought process and will get better with age. They need to be very comfortable with those questions at early ages and keep being willing to answer them. When they stop caring, THAT'S the problem.
So to try and answer your question more concretely, you can buy expensive toys made for programming but I don't see what it will accomplish. LEGOs are the gold standard, but really, every-day objects can do much of the above. Build a fort! Why are we building a fort? How do we do it? Tell me the steps for building a fort so we can do it again someday. How do we improve this fort? Tell me the steps for improving...
I think AI politicians or complex algorithms just risk being a more complicated form of legalese that even less people can understand (legalese in code/math form). With law in code form like that, you need to demand much more of the education system (scary!) to allow people to vote on PRs, if you even do that democratically. Otherwise, even more faith is put in the hands of the designers/core-maintainers as representatives, much like we already have. More ways to obfuscate direct effects and hide side-effects.
I truly think there is something there though, something from the open-source process that can make government more efficient and productive, but it's probably not in the way we are thinking. It probably looks less like software maintenance and more like science, dare I say political science. Crowd-source solutions and organize experiments across counties and states in a way that's data driven, not politics and need-for-reelection driven.
Speaking as a Workflowy user to your concerns, it's the best of all worlds for me:
- nightly export to dropbox as plaintext and a backup as a type of json format with more metadata. If Workflowy goes away tomorrow, I have everything and can continue in an editor if I like. But until then, I use the pretty web interface.
- multiple device support. I am not going to mess with ssh on my mobile devices. I use Workflowy for everything from extended note-taking and long-form writing to quick pre-set searches on the go for reference; and that's on all my various interfaces (and sometimes other peoples too).
- Workflowy is easy enough for laypersons to view and/or collaborate in seconds. No setup necessary on their end.
Of course a well rounded education comes from many sources and factors, both internal and external. But in general I feel that:
STEM training = literacy for the jobs we have now
Liberal arts training = big picture training for innovation that we have yet to do.
Remember this John Adams quote:
"I must study politics and war that my sons may have liberty to study mathematics and philosophy. My sons ought to study mathematics and philosophy, geography, natural history, naval architecture, navigation, commerce, and agriculture, in order to give their children a right to study painting, poetry, music, architecture, statuary, tapestry, and porcelain."
Education has moved in this direction, but our economy has not innovated alongside it to make work for them.
Of the handful of people I know that have bought Tesla's, they are very much not of the hacking mindset. I'm not saying this is forever true, but I think the type of person that can actually afford one usually has the "premium" and "executive" mindsets (if I can makeup some terms). That is, they'd rather pay extra for 98% of everything they want and not have the worry of needing to get their hands dirty (the premium mindset). And if there is a problem? They replace/trade-in/buy more premium services to get what they want. They have "their people" take care of it. These aren't intended to be negative descriptions, but more of an informal observation of how people in executive positions with resources available tend to prioritize their time and effort. But of course you'll eventually get more hackers drawn to the car in time.
There are certainly software hackers who are not interested in hacking mechanical devices, working on cars, or even understanding them. I'm not one, but most of the other software devs I know are. Their cluelessness about how cars work is almost funny.
Most software devs don't have the Hacker Mindset (TM) at all. If you use "sw devs" and "sw hackers" interchangeably, that's the source of your confusion.
For every starry-eyed and future creating technologist, who really does see the best-case scenario for what current and near-future technologies can accomplish, they need to always be shadowed by a team of altruistic business/PR/advertising-savvy advocates who can remind them how the worst among us are going to screw it all up so that our hero-geniuses can bake safeguards into the systems they create from the onset.
Technically, this might be syntax, but as someone who is learning Racket (and programming) in the beginning stages, it's so much less syntax to remember then even python (underscore, double underscore, with, decorators, list comprehensions etc all have their own syntax nuances), the only syntax I see in Racket is the s-expression, the quote, and the dots. Everything else is just the flow of programming logic. It really does free my mind to work on the problem domain itself! Been enjoying SICP so much.
Racket doesn't get quite as bad (well it does but it tries to keep things looking like S-exps) but consider CL's Loop macro http://www.unixuser.org/~euske/doc/cl/loop.html loop is (from what I understand) idiomatic too. Yes it's a macro (so is (defun ...) though) but it's syntax a CLer needs to know in order to deal with CL in the wild. Format is famously even worse.
Yes, but I thought his point was more that whilst Lisp has a very easy, simple and regular syntax, ie. (func arg1 arg2 (func arg3)) and so on, it's less simple and regular when you get to the loop macro (loop arg keyword arg keyword...). Hence why I mentioned the Iterate library as something a lot of people use to get back to the regular syntactical appearance.
It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.
> It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.
What you describe is just the data syntax for s-expressions. Not the syntax of the programming language Lisp.
> What you describe is just the data syntax for s-expressions. Not the syntax of the programming language Lisp.
Exactly. The data syntax if what most people worry about. The names of the verbs (funcs/methods/etc.) may change from language to language, but the data syntax is what trips people up. I think Lisp has one of the simplest and clearest. There are very few cases of "oh you can't write that there, only nouns are allowed in that position".
I agree with your point, but I think we're arguing slightly different points here ;)
It's debatable whether "simple and regular syntax" is a strength or a weakness. Lisp/Scheme might be too regular for their own good. Consider the following statements in Scheme, for instance:
(lambda x (+ x x))
(cond (> x 2) (+ x x))
(if (> x 2)
(do-this when-true)
(also-do-this when-true))
They are syntactically correct (technically), but they are probably not what you meant. So you still have to pause and ask yourself how cond works... except the parser will not help you.
That is to say, a problem with s-expressions is that they are so regular that everything looks the same, and when everything looks the same, it can become an obstacle to learning. Mainstream languages are not very regular, but they are more mnemonic. I think Lisp works best for a very particular kind of mind, but that for most programmers its strengths are basically weaknesses.
SBCL will warn or error at compile time on the first two, and there are similar issues to the third one in many languages; it's a semantics issue more than a syntactic issue.
An equivalent to iterate/loop where each compound form need be replaced by an anonymous function and each binding is replaced by a dictionary entry could be implemented completely as a function. Is this also new syntax?
If not, how is the macro different other than implicitly changing the evaluation?
for a more simple example, why is the idiom CALL-WITH-FOO (implemented as a function) not syntax while WITH-FOO (implemented as a macro) is? What precisely is syntax is somewhat nebulous (if I use a regex library in C, have I added syntax to the language? Regexes certainly are syntax, despite being wrapped in a C string).
Children ages 3-7 are really just beginning to learn how to think abstractly, which is a pretty core competency for programming. So when you say you want to teach fundamentals of coding, you really aren't even at "coding" yet. You're really at the fundamentals of math, language, reasoning, and problem solving and curious mindsets.
So what are the fundamentals of coding that 3-7 year olds can actually do?
1) Math - I would scour the web for all the different ways you can do basic math with any type of physical object (pencils, fruit, whatever). You may think it's too simple, but if you take a cognitive approach to this, practice must be done at some point with mapping a number of any object to it's linguistic representation in one's mind. Practice counting up/down, sorting stuff into groups and sets, quantity, patterns (2x3, 3x2, are they the same? what's different?) etc, and doing simple arithmetic with actual objects. This is new to them and is fundamental to everything else.
2) Language - have adult conversations with your kids, and no not about adult topics, but with adult words and with adult grammar; no "baby-talk" in other words. And it's not about purposely choosing large and obscure words to obfuscate, but picking accurate words that probably leave little holes in understanding for the child to try and reason about. Hopefully they will ask if they don't know, or may even surmise correctly about word/phrase meaning. This might help with...
3) Reason/problem solving - Encourage experimentation in everything. If they see you constantly trying new things and failing gracefully and focusing more effort on finding solutions then hiding failures, you've taught them one of the most important lessons of all. Try, try, try many times, then go ask someone. You should be unquestionably the expert in some things, and a complete novice that asks questions and learns quickly in other things, and they should watch you in both situations. Seeing role models do both is an immensely powerful thing to observe to young children. It shows that adults can be both powerful professionals and learners. Where do you think they learn to laugh at, criticize, and fear failure? It's cultural. Make failure just another step to mastery.
4) Curious mindsets - in every category above, there are always opportunities to ask "why do you think this is?" or "how do you think this works?". You might get gibberish most of the time but it doesn't matter, they are going through the thought process and will get better with age. They need to be very comfortable with those questions at early ages and keep being willing to answer them. When they stop caring, THAT'S the problem.
So to try and answer your question more concretely, you can buy expensive toys made for programming but I don't see what it will accomplish. LEGOs are the gold standard, but really, every-day objects can do much of the above. Build a fort! Why are we building a fort? How do we do it? Tell me the steps for building a fort so we can do it again someday. How do we improve this fort? Tell me the steps for improving...