
Pickcode is the best way to get started doing real programming.Pickcode is a new language and editor that visually guides you through writing code to make chatbots, animated drawings, and games.
Pickcode is the best way to get started doing real programming.
Pickcode is a new language and editor that visually guides you through writing code to make chatbots, animated drawings, and games.



Pickcode empowers you to start learning to code with confidence before progressing to more advanced languages.
Ready to get started now?
Try your first lessonIs there a good reason to require `var`, `set`, and `call` keywords? BASIC doesn’t have those. From my (admittedly dim) memories starting programming as a kid, those keywords would have been an unnecessary complication.
For example in LOGO, you’d just write
forward 10
left 90
In comparison, call paint.forward(10)
call paint.left(90)
seems excessive and noisy.The keywords are there on every line to make them easy to verbally read. This is most important in the case of set x = 7, the keyword makes it clear that we're trying to mutate a variable, not assert equality.
Even though technically we could make forward() a method at the top level in the context of a paint program, we chose to make things more OOPy to prepare them for later when students get to the 2D game engine and there can be multiple sprites to control.
I always wanted `set` in regular languages instead of (or in addition to) =/==.
Edit: well actually, I want a whole development studio like this for professional development. You are the closest of anything else to my vague idea of what programming should look like. I feel bad for the kids who later will have to move from this to what we call "our software development stacks".
Pascals := is concise and intuitively obvious, so obviously it never caught on.
Good news https://go.dev/tour/basics/10
So now Go has a single good feature!
>Pascals := is ...
:= is Algol's. Algol had a much bigger European influence than American, and other euro languages like Pascal followed its traditions
Hard to type though
> I always wanted `set` in regular languages instead of (or in addition to) =/==.
TCL ftw!
I felt like the naming was a little unintuitive here. `forward` and `left` seem to be directions of movement (especially if I want the painter to "move left"). Instead, `forward` means to draw/move, while `left` is a CCW rotation (even though it supports a negative argument)
call paint.draw(10)
call paint.rotate(90) // or even rotate("up")
speaks better to me.The LOGO terminology is an abbreviation of "move forward 10 steps, turn left 90 degrees", omitting "move"/"turn" and the units, as those are implied. LOGO uses a "turtle" as an avatar carrying out the instructions, like a little robot you program. See https://en.wikipedia.org/wiki/Turtle_graphics.
Python also comes with an implementation: https://docs.python.org/3/library/turtle.html
I agree that the paint prefix doesn’t quite match that conception.
Guess I'm showing my age, but the first version of BASIC that I learned had the "gosub" command [1] for subroutine calls.
N.B.: I'm using one-based indexing for my links here because that's apparently what early BASICs used [2] :)
[1] https://picaxe.com/basic-commands/program-flow-control/gosub...
[2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
Yes, but the built-in commands don't use that. You write
PRINT "Hello"
and not GOSUB PRINT "Hello"
Rather, you'd write GOSUB 690
to run your subroutine that starts at line 690.ZX Spectrum?
I remember that when I had to enter code printed in magazines/books it always seemed the Spectrum was the one that required that particular modification.
(Usually there would be a BASIC listing with modifications for C64, BBC, Spectrum, and other systems. "On line 30 add LET", etc.)
Yes! I had a Timex Sinclair. We had no cassette player, etc so, if you wanted to play a game, you were typing it in. There was one we’d always go back to. It prob wasn’t more than 50 line, tbh. But we typed it in so many times, we started to be able to do it from memory. I’m guessing it was a great way for a kid to internalize programming at a young age.
Agreed, this was my first impression as well. I spend my whole day in front of much more complex code, but trying to put myself in the shoes of a young kid, I would be really misled by this (unnecessary) noise.
I think it is needed for easily moving the code up and down. Notice that the kids don’t have to write the code. So because everything is clickable, it helps to have the keywords there in the design.
I realize that, but it’s still complicated and noisy from a reading perspective.
When I was first learning to program as a kid I really liked having LET x = 2, or Perl's sigils, etc. It helped remind me of things as simple as assignation being left to right.
Out of curiosity, why did Perl's sigils help? I don't see what they have to do with assignments being left to right.
Mostly it made it obvious which terms were variables. Of course, this was something like 30 years ago so I don't remember well.
It will be added as kool syntactic sugar later in v2! Stay tuned for updates!
</s>
Totally agree, it was my first thought too on call/var nonsense.
So "forward" is something you click and it shows all possible expressions for a new line?
[dead]
I've been introducing my 10yr old to Godot. He's been building games in Scratch for the past 6 months. He loves Scratch, but is also frustrated by it's limitations. I thought he'd be happier with a real scripting language.
When we started writing some GDScript he quickly became frustrated by all the typing! His hands are too small to master touch typing. It takes forever to type a variable name + method call + ...
This looks like the perfect balance. Going to check it out!
Oh that's such a good point about the typing speed limitation I never would have thought of that for some reason.
I've been doing super light python lessons with my 3yo and I was wondering why we were moving slower than he seemed capable of in terms of understanding what I was saying but you just made me realize how long it was taking him just to type brackets and quotation marks etc.
I like this project and am looking forward to trying it. I'm starting to adopt a "the more the merrier" mentality with kids programming. Might as well expose them to the dynamic of having a bunch of different languages / workflows to choose from.
You are teaching Python to your 3yo son?? I mean, maybe he is a genius but I do really wonder what a 3yo can possibly understand about programming (and you even make him type!)
lol, yeah it's so unclear what they really *understand* at that age other than what color hotwheels car they get if they can write a for loop.
3 y/o can form simple sentences like "dad is playing"
why they can't understand "x = 3"?
Because one is rooted in sensorial life and the other is purely abstract?
the grammar on a language isn't abstract too?
anyway, heheh, Scratch aims to teach basics concepts of programming to children older than 6 y/o; who knows if Python is easier?
edit: typo... coding =/ programming
it doesn't seem like much more of an abstraction than an abstract numeric symbol equalling a certain number of physical objects (ie 3 = * * * )
in my limited experience basic variable use isn't much of a stretch for a 3yo
I mean, at that age, they haven't even really learned basic algebra; they still have to learn things like the order of operations, manual addition and subtraction, and manual multiplication and division.
Don't you remember reading books as a kid with child characters saying things like "I was pretty good at math class until they started introducing letters to the problems; I don't understand it at all anymore!" Things like that show that variables aren't directly intuitive to all children.
I know who dad is. Who is x?
I got my kid one for his pi, he liked it. Served him well. But they often seem to have issues with missing symbols needed for basic programming and dysfunctional keys. Also weird key layouts etc.
Anyway they're fingers can handle normal keyboards super quickly, we could have given him a standard keyboard when he was 2 if there had been a reason.
I didn't know there was such a thing. :)
Might need to get him one for christmas.
Commodore PET! ;)
https://commons.wikimedia.org/wiki/File:Commodore_PET_keyboa...
pretty sure my PET had a chunky black keyboard and the tape drive was separate
You and Pete Shelley.
that's the one!
You might like Kano's small keyboard, can find them on eBay: https://youtu.be/Z0I-vw6Wc0U?si=U2XV2f0ZB9vvqQnu
This has been my experience as well. I introduced my son to Scratch when he was 8 and now, 2 years later, he's creating quite advanced games in it I wouldn't have thought possible.
But whenever I show him "real" programming languages, he's like: I can do all of that with Scratch as well - without having to type all that stuff.
We tried GameMaker and produced some cool results together, but as soon as I turn around, he's back at his Scratch projects.
Sometimes I wonder if it'd have been better had he started with code right away. Like I did back in the days. ;-)
> But whenever I show him "real" programming languages, he's like: I can do all of that with Scratch as well - without having to type all that stuff.
Dear Hacker:
Your son is already doing things kids four years older would be amazed by.
Let him come to "real" programming on his own.
Heck, show him Snap and let him write programs with call/cc in "Scratch". Maybe you can hook him on interesting visual programming projects that require passing around functions as data (like creating a calculator or a model of a computer).
The manual explains how to write an object-oriented system in Snap, so you're really not going to be holding the kid back if you can get him in that way.
The iterated function systems also look cool and can be approached that way. The Beauty and Joy of Computing curriculum has a decently broad and intellectually challenging selection of project that can be done in Snap.
EDIT: I believe Snap can make calls to REST interfaces; you could write the back end and he could do the front end calls and use the data.
I worked on Scratch for 6 years, in charge of the online community. We often encountered adult programmers who were surprised by what was possible in terms of complex projects with Scratch. There was usually a great deal of concern about how the transition to "real" (text based) programming languages would go. It always seemed strange to me, this attachment to text based programming as the only "true" "real" etc. programming. At any rate, I saw quite a few kids make that transition without any problems. I've still never seen any systematic evidence that moving from tiles to text presents significant difficulty, and yet so much energy is devoted to "solving" this problem.
I believe we're all deformed (sometimes disfigured) victims of our own struggle. I'd listen to the kid instead and asked what's wrong with me, looking at the imposed complexity I deal with, with no one among healthy people to understand the matter, dare I to complain.
This was my experience getting into programming as a kid. I just wanted to make things and the games I made in Scratch were cooler than printing to the console in C++ (especially as a slow typer).
I eventually learned html/css which let me build real websites and see them in my browser. At some point you hit a wall with what you can make and are forced to learn js/php/python/etc.
honestly I think a 3yo is capable of learning bash before python if you put it in between them and paw patrol (or whatever they're into, for mine its beastie boys music videos currently... sigh)
Limitation-wise I felt that it's not obvious to the kid what to do in Scratch to manage complexity - what to do when the program becomes "too big".
And just pointing out the problem and asking what could be done helped get them on track to think about the issue and ... find several ways that Scratch does allow. Splitting a program into multiple objects / agents for example.
Scratch is way more powerful than first glance or first programs hint at.
GDScript is a surprisingly good language. Better than Python in many ways (e.g. it has `var` and `const`).
http://its-not-its.info Old enough to have a 10 years old child but still doesn't know English
Have you considered a netbook? Small keyboard :)
Congrats for launching Pickcode! The attention to detail is great and shows that you care.
As an aside on the topic at large, I find there are (at least) two schools of thought in the visual programming space, when intending to make programming more accessible to non-developers.
Some efforts focus on reducing the overhead of learning syntax, by leveraging the visual interface, but do not hide their imperative nature nor the need for an algorithmic mindset. In effect we can think of these as IDEs but with varying levels of accessibility. I surmise that Pickcode and Scratch belong to this category.
Other groups explore different programming paradigms instead, that might fit the visual metaphor to varying levels of success. They also induce different mindsets to their users compared to imperative programming. Node-red is a great example of this, which explores flow based programming (a close relative of functional reactive programming). Another is Labview, a dataflow-based close relative with more magic in it (really rather smart defaults and naming of internal variables). Apple Automator also comes to mind.
I don't think either pattern is necessarily better or worse. I just find it useful to think of this distinction (imperative vs reactive) for visual languages, which leads to very different end-user experiences.
Your post reminded me of how teaching an elm (a functional language) workshop to novices was almost simpler than to professionals. The novice brain wasn't corrupted by imperative C thinking, of sorts.
Yeah, functional and/or declarative programming can be surprisingly easy for beginners. They can just describe what they want and then see the magic unfold.