Richmond, a few years ago, I discovered with amazement that exists a tendency in education who propose that teachers should become skilled entertainers and compete along television hosts, radio personalities, actors and musicians for the time and attention of their customers... I mean, their students.
https://www.theguardian.com/education/m ... ng-schools
Of course, there is another side for this coin:
http://teaching.monster.com/benefits/ar ... tertainers
In some countries, the most effective effort to reach the education market only requires to
1) bribe someone who make decisions or
2) bribe an influential member of the ruling political party.
In fact, Who are most interested in the advantages provided by using LiveCode in education?
Private schools and DIY learners.
I need to reiterate this idea:
Learning LiveCode as First Computer Language opens the door to learn and master other computer languages. Even so, I am sure that we could find people who said otherwise... that learning first a very-high level computer language effectively cripple forever the imagination and other cognitive functions required for learning more traditional computer languages like C or Assembler... That is not true.
Clearly, that is not true.
For example: How could you use LC to teach about pointers and memory management techniques?
The answer is:
Create a simulation where techniques of memory allocation, heap deallocation, array allocation, memory ownership models, and memory leaks are represented visually as an array of color graphics or pixels.
Of course, someone could say: "But that is only a simulation, not the real thing!" but precisely because of that, teachers have better control over student's learning outcomes. Instead of avoid catastrophic errors, teachers could show each one of them and teach students how to avoid repeating these mistakes in their code.
And... one more thing:
Eric S. Raymond recently wrote: http://esr.ibiblio.org/?p=7724#more-7724
"Ever since the very earliest computer languages it’s been understood that every language design embodies an assertion about the relative value of programmer time vs. machine resources. At one end of that spectrum you have languages like assembler and (later) C that are designed to extract maximum performance at the cost of also pessimizing developer time and costs; at the other, languages like Lisp and (later) Python that try to automate away as much housekeeping detail as possible, at the cost of pessimizing machine performance.
In broadest terms, the most important discriminator between the ends of this spectrum is the presence or absence of automatic memory management. This corresponds exactly to the empirical observation that memory-management bugs are by far the most common class of defects in machine-centric languages that require programmers to manage that resource by hand."
"Over time, there’s been a gradual shift from languages that require manual memory management to languages with automatic memory management and garbage collection (GC)"
And that explains a lot...