When I taught my daughter about programming I actually installed an old copy of Visual Basic 6.0 and it was really good for that. You draw the UI and the interact it with it mostly procedurally. She created a small useful application out of it. It's kind of crazy that in 2016 all our programming environments are more complicated than VB6.

That observation is fascinating to me. Isn't it possible that we're judging it with adult eyes? To me, kids can filter out "ui complexity" that's not relevant to whatever exploration they are doing. Examples I think of:

A microwave oven[1] might have 25 separate buttons on it but a 6-year old will know the 2 buttons to press to heat up the popcorn. Yes, the keypad complexity handles more advanced techniques of 2-stage cooking with different power levels etc but the child just ignores all of that.

Or, how many of us grew up with those multi-component integrated stereo racks?[2] The front panel has all those buttons, sliders, knobs, and lights. And yet, a small child knows how to turn the FM knob to find his favorite radio station or rewind a cassette to replay a song.

I also see video games[3] that 6 to 8 year olds play (even if the game wasn't intended for that younger age group). To me, the screenshots show a complex "dashboard" at the bottom of weapons or other status. (I'm not a Starcraft player and it all just looks complicated and confusing to me.)

I think kids can look at the "complex" F12 screen the same way as microwave ovens, stereo receivers, and Starcraft screens: ignore the non-relevant UI elements and just type "alert ("hello");"

[1]https://www.google.com/search?q=microwave+oven+keypad&source...

[2]https://www.google.com/search?q=integrated+stereo+rack+turnt...

[3]https://www.google.com/search?q=starcraft+ii+screenshot&sour...

I believe the timer is clockwork.

Touch-sensitive membrane buttons like the ones the use on the front of microwaves are much cheaper than mechanical timers.

Most of appliances provide functions expected from devices of their class and follow obvious patterns that you quickly internalize. I have a running bet with my friends that I can operate any electronic appliance without a manual. The hardest case I've ever had so far was setting the clock on a microwave that provided alternative functionality under "START" button when the oven doors were open. It took me a few minutes to crack that one.

[0] - https://xkcd.com/627/

This is what I miss about older technology - especially dumbphones. The input always worked, and always worked with the same timing. I could operate my Sony Ericsson K800i without looking at the screen because my brain memorized the sequences of buttons and timings of common operations. Joystick press, up, up, press, down, press, wait about a second, press, done. Compare with Android phones which routinely ignore or misinterpret input ("that was a swipe, not a press!"), and hang at unpredictable moments for unpredictable amount of time (usually also ignoring input while hung).

(At least every microwave I ever operated was pretty loud when cooking.)

$c00000 - FAKE FAST LOCATED

What miss most is using tools like ExoticRipper to grab music modules from memory after reset, to then play them at leisure and examine/change them with a tracker. Or playing around with the "Action Replay" modules I-III, that blew my mind too. Making a pause toggle by connect the mass of the case to a specific pin of the extension slot, haha, I was so scared doing it and so shocked it actually worked. I may not have learned so much I ended up still using (except today I prefer Renoise to all other DAW), but I sure learned a lot about learning, that is, wildly poking around to figure things out.

I've been thinking of switching over to some other environment the next time we do that. The immediacy and integration into an environment he already uses every day are compelling advantages, and it'll be a shame to lose them. But it does feel like the downsides easily outweigh the benefits.

And then there's interfacing the other way around, which the Canvas doesn't help at all with or makes even more complicated. It's somewhat easy to explain an onClick handler for a HTML button; doing a useful onClick handler for a canvas, or body-level onKeyDown handler are again much more complicated affairs.

You could create GUIs and easily share self-contained exes with your friends. Also very cool was the documentation, complete, offline and and with lots of examples.

I initially got into programming through Apple HyperCard/HyperTalk on the outdated school computers, but it was rather clunky and limiting in what you could do without going through the C interface.

Not really. The VB6 exes required a huge runtime to be installed. Plus all the visual controls lived inside of OLE DLLs als native code and you had to ship these too (and register them on the target machine)

This was the biggest motivator for me to move to Delphi because that actually produced self-contained exes and allowed you to call any Windows API directly without any COM wrappers in between.

And you had a real type system. And pointers. But you still had an easy GUI editor and a very good class library that was incredibly easy to use.

I think 'online' [1] is the word you wanted to use. ;)

[1] https://en.wikipedia.org/wiki/Online_help

I think you can still download the whole MSDN help library for offline use, but I don't believe that nowadays that would be enough for daily work use. Lots of useful info and example use is scattered around blog posts and StackOverflow answers now, instead of being a part of the documentation itself.

I decided I wanted to learn to "program" when I was 8, but I had no mentors, and no adults I knew could tell me how programs were made. I found QBasic lurking in the C drive, and got some books from the library, but without anyone to help my 8 year old brain couldn't get far alone. I got it to switch resolutions and draw some static pictures, but nothing else. I was frustrated.

Eventually I found and started playing with Games Factory, then Multimedia fusion from Clickteam, which is is sort of related to this, programming without typing. It was something my 10-year old self could understand on its own! I got a solid intuition of thinking in logic, and. Being able to set up some crazy causes and effects myself was really exciting. I made some "cool" stuff, for a 10 year old.

Once I found that limiting I tried to learn text-based programming again and by that time I was able to read code and puzzle out what it did from the concepts I learned. Maybe being a couple years older helped too.

I can't stand using tools like that as an adult, but without visual programming, I probably would've given up. Yet I paid my way through college writing Java/AS3/C, and now I made a living in games.

Almost almost all modern programming environments, including JavaScript in the browser, require a lot of work to produce a simple visual.

However, Scratch feels like it does too much and becomes more like solving puzzles rather than creation.

    Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
    32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import turtle
    >>> turtle.forward(100)

In Python it'd look like

    @GtkTemplate("my_window.ui")
    class MyWindow:
        @GtkChild my_textbox
        
        @GtkCallback
        def button_clicked(self, btn):
            my_textbox.text = "Hello, World!"

I cannot think of a more complicated way to introduce someone to programming. Yes, you can use `alert` and print things, but that's about where the ease of interaction ends.

    var drawing = document.createElement('canvas');
    document.body.appendChild(drawing);
    var ctx = drawing.getContext('2d');
    ctx.beginPath();
    ctx.moveTo(0, 0);
    ctx.lineTo(100, 100);
    ctx.stroke();

2) typing your code (on this page) ... nothing happens. Element was added at the bottom of a very large page, element was not visible, so I didn't see anything happen.

3) the added element is a white box on a white background. Grand total indication of it getting added was a small adjustment in the (hidden by default) scrollbar on the right of the page ...

4) after that you want to start people out with paths and stroking and state storing and evaluating ?

Making a program like this that responds to keyboard input at all in javascript is dozens of lines, and you have to know DOM, properties, and event handlers in addition to the base language to make anything happen. Getting keyboard handling good enough to have a simple game ... let's not go there. Hundreds of lines. And of course, doesn't work on your friends machine (different browser ...).

I hope you can see that this is less than optimal to get people exited.

I am one of those guys that thinks web programming sucks, that it's far inferior for most programs as compared to Qt/QML and even to Delphi/VB like languages.

    SCREEN 13
    LINE (X1, Y1) - (X2, Y2), COLOUR

https://github.com/davebalmer/turtlewax

http://berniepope.id.au/html/js-turtle/turtle.html

The howto could be a whole lot simpler it seems, see this example, helpfully provided by neckro23 https://news.ycombinator.com/item?id=11637866

http://www.bing.com/search?q=sarcasm

I sincerely wish that the post you linked was sarcastic as well, but it was probably serious which makes the (former) QBasic programmer in me a little bit sad.

I thought it was a well intended explanation that just wasn't detailed enough.

    data:text/html,<svg><line x1=0 y1=30 x2=40 y2=50 stroke=black>

    line(0, 30, 40, 50);

There are also clumsier ways to draw lines, like with DOM manipulation in SVG or drawing stuff on a <canvas>, and those might be desirable for the extra flexibility they give you. But you don't have to start with them.

Depends on the browser. IE > 8 doesn't support it.

[0]https://developer.mozilla.org/en-US/docs/Web/HTTP/data_URIs

How's that?

I've since learned a few more languages, and I don't particularly enjoy writing complex JS programs, but I'm very glad it was there when I got started.

The problem is that as soon as you go beyond "write a series of statements and run them" and in to actually trying to write something interesting and fun with a little abstraction or actual software design then JS very quickly stops being a good choice. You can quickly hit synchronicity problems, weird scoping issues, data typing difficulties. Those are things that could easily frustrate an interested person.

A hour or two of JS as an introduction followed by learning a BASIC variant is probably a really good bet.

No. It's a language to scare - and scar - young programmers for life.

true == 1 → true

true == "1" → true

false == 0 → true

false == "0" → true

false == undefined → false

false == null → false

null == undefined → true

"\t\r\n" == 0 → true

"\t\r\n 16 \t\r\n" == 16 → true

"\t\r\n 16 \t\r\n" == "16" → false

var a = "foobar"

var b = typeof a → 'string'

var c = a instanceof String → false

[1] https://whydoesitsuck.com/why-does-javascript-suck/

I think this is something you need to blame UNIX for. Or who knows, maybe something made even earlier.

That said, there is a logic behind that. Days we usually represent with numbers. Months we often represent with names. So the month numbers are returned as an index of a sequence of names. (Not saying I like this logic, but it sort of makes sense.)

Continuing forward with bad designs doesn't absolve you from them, though. Plenty of languages avoid this--look at how .NET handles dates and times, it has no real relation to the underlying OS on either Windows or *nix.

  myArray.forEach( (item) => {
    // process item
  });

  for (item in myObject) {
    // process item 
  }