The underlying hardware is mutable / imperative.
Load number into register A --
Load number into register B --
Add A B and store result --
Functional and data-driven / declarative interfaces are only made possible because of the imperative "ugliness" (reality) that supports it.
In order for students to understand computing e2e, they need to understand imperative programming.
In order for students to become capable of designing robust, powerful, and elegant systems, they will need to understand functional/declarative programming.
The children know school math. And their blackboard is declarative and not imperative. Why would you suddenly introduce implicit state?
i=i+1 is just confusing without a good and formal introduction. And once you have that introduction, your most of the way to modelling state in a functional declarative computing model.
I agree with you. I probably wouldn’t invest much time learning patterns for solving higher level problems in an imperative way, but spending some time with a breadboard, then some circuit emulators, then machine code -> assembly -> systems programming will definitely give kids (a bit older than the target for this tool perhaps?) an important basis in the underlying physical reality of their programs.
Functional and data-driven / declarative interfaces are only made possible because of the imperative "ugliness" (reality) that supports it.
In order for students to understand computing e2e, they need to understand imperative programming.
In order for students to become capable of designing robust, powerful, and elegant systems, they will need to understand functional/declarative programming.