Re: Follow-up post explaining research rationale

[Ryan Frame via Digitalmars-d]

On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:
I don't think the platforms people are introduced to in CS 
education are very good at generating excitement about what 
computers can do. It would be interesting to gauge what sorts 
of things people think they might be able to create, what sorts 
of problems they think they could solve, or new interfaces they 
could implement, after their introduction to programming. What 
horizons do they see?


I think you're partly right here, but you seem to think somebody 
can read a "Learn [language] in 24 Hours" book and write awesome 
software; that isn't going to happen. Programming is a craft. I 
play classical guitar as a hobby, but I have a friend that 
embodies classical music. I can play, but because of his 
dedication to the music he is (I would argue) one of the great 
composers of our time.


When I first started playing guitar, my teacher barely had me 
playing anything, but we talked a lot about music theory, and 
that made learning easier later on. We need to be careful that 
making things easier for beginners doesn't hurt them in the long 
run.


For example, there used to be a lot of excitement about what 
computers could do for education. Those visions have not 
materialized, and it's not clear that computing is doing 
anything non-trivial in education for reasoning ability, 
unlocking math aptitude, writing creativity, etc. It might 
actually be a net harm, with its effects on attention spans and 
language development, though this will be very complicated to 
assess.


I think it is often harmful -- we're teaching people to use the 
tech rather than using the tech to teach people.


My Kiwanis club gives money to our kindergarten teachers every 
year for school supplies, and the teachers generally come and 
talk about what they're doing with the kids. The first year they 
used iPads they weren't that happy -- they should be reading from 
a book, they're too young, etc. The next year they were showing 
off what they could do with the kids now; they still had 
complaints, but they were able to help kids learn in ways they 
could not previously do.


How we use the technology determines whether it's positive or a 
negative. We just need to quit placing tech in schools because 
it's shiny and use when it's beneficial.


Forcing people to learn Vim or Emacs, grep, and poorly designed 
command line interfaces that dump a bunch of unformatted text 
at you are disastrous decisions from a pedagogical standpoint. 
(See the BlueJ project for an effort to do something about 
this.) They do nothing to illustrate what new and exciting 
things you could build with computers, and they seem to mold 
students into a rigid, conformist nix, git, and markdown 
monoculture where computing is reduced to bizarre manipulations 
of ASCII text on a black 1980s DOS-like screen, and constantly 
fiddling with and repairing one's operating system just to be 
able to continue to work on this DOS-like screen (Unix/Linux 
requires a lot of maintenance and troubleshooting overhead, 
especially for beginners – if they also have to do this while 
learning programming, then programming itself could be 
associated with a life of neverending, maddening hassles and 
frustrations). The debugging experience on Unix/Linux will be 
painful. From a pedagogical standpoint, this situation looks 
like a doomsday scenario, the worst CS education approach we 
could devise.


This reads more like a rant than an analysis of programming 
tools/procedures. You and I seem to have had very different 
introductions to programming.


The idea that we should no longer be stuck with text-based 
odd-looking programming languages and tools is kind of like 
claiming that since we can get running water on the 30th floor of 
a building, plumbers shouldn't have to deal with the mess of a 
septic tank. There must always be somebody at the low-level. The 
projects you mention that are heading the direction you prefer 
are able to do so because somebody else had done a lot of the 
messy work (or they're doing the messy work for their users). 
There will always be a programmer working in the sewers to let 
another work from the penthouse.


After we "fix" programming, are we going to tell the chip 
designers that things should be simple and intuitive enough that 
anyone can build a computer processor?

Re: documented unit tests as examples

[Ryan Frame via Digitalmars-d]

On Saturday, 14 May 2016 at 17:48:48 UTC, Andrej Mitrovic wrote:


So anyway, I think perhaps the simplest solution is to make 
ddoc inject the writeln calls (or possibly replace assertions 
altogether in the output).


The problem with replacing the assert is the loss of information.

assert(sum(2, 2) == 4);

tells me what sum(2, 2) should return merely by reading the 
example, but


writeln(sum(2, 2));

requires me to run it (or re-read the documentation for sum(), 
but the example is supposed to save me from that). Merely 
injecting the writeln() provides full return information when 
reading and executing the example (though more context should be 
provided than just the return value).