Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: New visual language for teaching kids to code (pickcode.io)
420 points by csmeyer 10 months ago | hide | past | favorite | 170 comments
Pickcode is a new language and editor for getting kids started with coding. The code editing experience is totally structured, where you select choices from menus rather than typing. I made Pickcode after experiences teaching kids both block coding (Scratch, App Inventor) and Python. To me, block coding is too far removed from regular coding for kids to make the connection. Pickcode provides a much clearer transition path for students to Python/JS/Java. Our target market is middle/early high school kids, and that’s who we’ve tested the product with during development.

On the site, you can do tutorials to make chatbots, animated drawings, and 2D games. We have a full Intro to Pickcode course, as well as an Intro to Python course where you make regular console programs with a regular text editor. There are 30 or so free lessons accessible with an account, and the rest are paywalled for $5/month.

For professional programmers, the editor is probably pretty frustrating to use (no vim keybindings!), but I hope it’s at least interesting to play with from a UI perspective. If you have kids aged 10-14, I’d love any feedback you have from trying it out with them. I love talking to users, reach out at charlie@pickcode.io!




Is 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.


The Basic I used had

    LET X=10


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?


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'm curious, why not get a kids sized keyboard?


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.

https://www.youtube.com/watch?v=2HwmO_GZfzI


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.


> The code editing experience is totally structured, where you select choices from menus rather than typing

Very cool! I wish there were something like this for working adult programmers, a general purpose structured editor for programming languages. When I program the intentions I form are in the first instance semantic (define a function here, check a condition there). Why shouldn't I just directly communicate my semantic intentions to the editor? Why do I have to first serialize my intentions into a string for the editor to then parse, in a error-prone process which introduces the possibility of silly syntactic errors like typos, mismatched brackets, operator precedence errors etc, rather than just semantic incorrectness?

Such an editor wouldn't necessarily have to be keyboard unfriendly any more than Excel is keyboard unfriendly. I guess it could also work something like input method editors for East Asian languages where you type into a "composition window" and make selections from a "candidate window" for insertion.


Many have tried this. It is definitely not in the class of "nobody else has thought of this" so much as "tons of people have thought of this and tried it and smash up against some major problems right away".

AIUI, in this case, the major issue is that it is very tempting to try to impose a constraint that all intermediate states the code passes through are semantically valid. However while superficially appealing this turns out to be a crippling constraint. Even the best of us tend to think in somewhat more sloppy terms and then fix up code after the fact, even on a line-by-line basis. Being forced to be completely valid 100% of the time turns out to be a big mismatch. I am inclined to believe this mismatch is fundamental. Only vanishing fractions of a percent of humans, if any, think this way. Even professional mathematicians report that they tend to work this way in practice, in that they tend to leap ahead and then back-fill the rigor, rather than strictly working forward one step at a time, and if even they don't work in this manner, who does?

Programming has settled on semantically-aware autocomplete and suggestions, and that's probably the actual optimum, not just a symptom of some kind of laziness.

It is possible that if somebody really pushed through the development that the problems are solvable, but I'd advise anyone taking it on that if there's any fruit here, and there may well be, it is not low hanging.

As saurik mentioned, the Lisp world through emacs is the closest you can get to this, but again AIUI you can still do anything you want, it's just that you have a lot of tools that encourage "more" semanticness, not that it is enforced absolutely rigidly.


A related concept is compilers that keep going after the first error. Though I kind of like the hard-mode idea of a compiler that has only one error message, "fail".

BTW: could provide valid options (perhaps highlighted), not constraints. (...maybe been thought of already)


> AIUI, in this case, the major issue is that it is very tempting to try to impose a constraint that all intermediate states the code passes through are semantically valid. However while superficially appealing this turns out to be a crippling constraint.

This really isn't much of an issue in a language with holes as a first class concept, like Agda or Haskell.


Aren't there quite a few of these? Scratch or its cousin Snap (https://snap.berkeley.edu/snap/snap.html), or even a visual flow editor for React (https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...) or the similar https://retejs.org/


You wish there was something like this for adult programmers?

Blythe Omnis 7 in ... (checks CV/resume) ...1996 (and earlier), a 'RAD' platform/solution that worked across Windows and Macintosh... (I landed the job because I was the ONLY candidate who had even heard of this software, because I read a short article in a magazine once...)

https://en.wikipedia.org/wiki/Omnis_Studio

Clicking to program with drop-down lists (and popups) just wasn't all that well thought out. So - you would see your program as a listing. When you tried to edit a line, it would popup a modal dialog box, where you could edit... just that one line... Intellisense/code-completion were of course non-existent... ahahahahaha (laughs maniacally)

Man, I think my PTSD is kicking in, I need a drink/smoke or something.


For example https://github.com/nocode-js/sequential-workflow-designer is designed in this way, that you program some logic by setting predefined actions in a proper order. You program at the high level.


I am under the impression that this is what people who program in Lisp experience when working with Emacs, where they get to think in and work with forms rather than mere text.


ASTs


One of my favorite features of Scratch is that it's impossible to create syntax errors. The blocks either fit together, or they don't. I think this makes it easier for kids to pick it up and start playing without specific instruction or tutoring.

After following the first couple of steps of the rectangle tutorial, I started clicking around and doing my own thing. I ended up with "call math paint.forward()", giving me a syntax error. Obviously that line is garbage, but I can't figure out how the math instruction is supposed to work. I'm sure if I followed some more of your tutorials I'd have it explained to me, but I think discoverability is important too.


They don’t make syntax error, but they also don’t complaint if something is out of place. Says, you manipulated the blocks and one was popped out, the program will still run but don’t work correctly. When there are a number of blocks, it could be quite hard to spot because the blocks can overlap each other. Then there is also a problem with forgetting arguments for a block. Still runs but don’t work.

Visual programming is definitely better for kids, but I think it requires a more strict approach and a better debugging ability than Scratch.


Yeah certainly Scratch is a bit light on debugging support. Or was 6-8 yrs ago.


Another nice thing about Scratch, well actually blocks, is that you can fairly easily adopt it to a new language. We used blocks to allow IoT customers to configure their device to react to events & push events to other devices and this all transformed into a JSON config that was uploaded.


Congrats! It looks really nice. It reminds me of when we developed a block-based version of our ProcessingJS editor at Khan Academy. It was a little clunky UI wise and hard to maintain, so we eventually dropped it, but this looks pretty slick. I love that you're giving new programmers more ways to get into typed programming! (I tend to also think most block coding is too far removed).


It should be possible to auto-generate these block editing UI's starting from an abstract description of the syntax, as used e.g. in a tree-sitter parser. Sometimes this kind of block-based editing is also integrated with type checking to enable smart, query-based filling of "holes", as seen perhaps most prominently in editors for Agda (a pure functional language).


Yeah, we actually took that approach for the block-based experiment for Khan Academy. I think we ran into issues with auto generating the blocks for JS prototype based classes, if I recall correctly, but I can't remember exactly what the issues were. I don't know what approach OP is using.


Reminds me of ZX81's BASIC: you didn't type keywords. There was a key for each one on the specialized keyboard. The editor was context-sensitive - in other words, a parser-driven lexical analyzer was you. At the time, it seemed a little magical to me that it knew whether you wanted to type a word/number versus a keyword, and what kind of keyword (but really, the pedagogically relevant aspect was that I knew).

BTW Significant to the ZX81 was the memory saved by storing tokens instead of their text representation. Yes. It had 1k RAM kids - including display memory (no separate GPU). This parsing when entered would also make runtime faster.


This is a very polished site but I’m not sure I agree with your goals. It’s an impressive IDE however I’d focus on a subset of Python rather than a new language. Otherwise you’ll find people will dismiss it because Scratch is easier to teach (schools where teachers are developers) and Python is more useful to learn (programmer parents teaching kids).

I’m a software developer who has assisted my wife’s primary school / kindergarten with programming classes. So somewhat familiar with the problems that exist in this space.


Do you know of a "subset of Python" alternative? Would be interesting to have a natural bridge to "real" programming.


I think this is exactly what you're looking for: https://youtu.be/fmF7HpU_-9k?si=YkEBUIJNshdujAW5


wow that’s a really well presented talk! Best I’ve seen in a long while. I found myself getting excited about the subject matter like I was a child. She definitely knows how to engage her audience.

Thanks for sharing


thanks my 10yo who is in to scratch really likes that (hedy.org)


Related:

Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - Nov 2022 (14 comments)

Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - July 2022 (32 comments)

Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - May 2022 (4 comments)

(Reposts are fine after a year or so! links to past threads are just to satisfy extra-curious readers)


Looks great!

I am working on some similar concepts but for music programming:

https://glicol.org

I feel that it would be great if there could be some examples on the landing page directly.

When I try a lesson, I get stuck; The hint is on the right but it's not very obvious; perhaps you can rearrange it like Svelte Tutorial (https://learn.svelte.dev/tutorial/welcome-to-svelte)

for the syntax I am not sure; have you considered using LOGO?


I showed it to my 13yo daughter. Her first question was, "Can you share it with people?" (Her favorite aspect of Scratch is the community). I said I don't know, then clicked on the Try a lesson button. She saw the page and said,"Teachers probably like this" and went back to her book.


As someone for whom programming first really "clicked" after using NetLogo in a CS class in highschool, I love the idea of this project and the interface! For kids the most important thing is to get them _excited_ about programming, and this seems like it could do a good job


This is pretty cool, The UI is a little tough-- deleting code blocks is clunky. its also hard to break out of the type modals there should also be some kind on context aware help dialogue to tell you what operator/type you have active is/does


> If you have kids aged 10-14, I’d love any feedback you have from trying it out with them.

I can give you my feedback from when I was 10-11: I was trying to learn RPG Maker 2000 / XP's scripting which was kinda similar to this and got so frustrated by the limitations of the visual editor ( https://steamuserimages-a.akamaihd.net/ugc/27362763067155240... ) that I went straight to learning C and C++, which I pretty much managed to a basic level. trust kids :)


Yeah I think block editing is largely aimed at kids who literally wouldn't be able to comfortably type at a keyboard, which definitely wouldn't apply by the time you're 10.


I don’t know much about this tech, but judging from the screenshot, it looks like a mix of imperative programming and visual editing that is the worst of both worlds.

I’m not surprised you moved to C.

(On the other hand, it looks like a super nifty way of having a primitive interpreted language without a parser/lexer)

I feel like visual programming gets a bad rap because of things like this. As an electronic engineer that used to love LabView and life long user of NI Reaktor and Max/MSP, those tools are fantastic if you don’t approach them with an imperative programming mindset.


> I feel like visual programming gets a bad rap because of things like this. As an electronic engineer that used to love LabView and life long user of NI Reaktor and Max/MSP, those tools are fantastic if you don’t approach them with an imperative programming mindset.

aha, in the long run I ended up making https://ossia.io which is as VPL as it can get. Yet it still embeds multiple textual languages.


Ah, this looks great. This is how you do it, by being able to customize by embedding you get the best of both worlds.


One quick comment: is there an open-ended sandbox where I can just write whatever code where I want? Even after creating an account I couldn't find such a button, or even the "pay $5/mo upsell" button.

I feel like such a mode would be useful for instructors that are working through a problem with their students, ideally without having to go through all the lessons first.

As for students, once they get proficient in a language they'll want to use it to make things -- from what I've seen in other learn-to-code environments kids end up co-opting the later lessons to do so if you don't give a way for them to create new projects.


Click the “Home” button on the sidebar while logged in and you’ll see a new project button. The sidebar might be default hidden on mobile


My biggest feedback is in the UI information displayed.

Before I try, before I 'log in', I have no way on the landing page - or navigating around a bit - to find out how much it costs. That knowledge up front would make me as a buyer feel much more trust. To hide that behind UI sign-ups always strikes me as underhanded (forcing someone to invest attention as a sales tactic feels too manipulative to me to consider the service helpful and not a money grab).

Easy fix, just display how much it costs upfront.


Will do


Languages for "teaching kids how to code" tend to be either:

1. very visual/non-text (eg: scratch)

2. usability IDE/language tools (what this appears to be)

#1 is fine. But #2, these should be present in software the adults use. But it's not, which is an embarrassing indictment of our approach to computing. The fact that we don't have Victor-esque feedback by default in our IDEs is a blight.

____

Tangent: famously, in the US and much of the western world (for some reason... meaning Disney, mostly), the culture got it into its head that animations are cartoons which are exclusively "for kids", and if you watch animation, you're a kid. But in fact, there's nothing inherent about the medium of animation which necessarily makes it just "for kids", and another culture (Japan) which does not have that cultural assumption got some great art out of it (Anime).

It's weird what we decide is "for kids" and limit ourselves.


I disagree with this take. I have found immeasurable advantages to working with non-IDE/non-hold-my-hand-editors when programming. The separation of concerns (editing text versus compiling and running a program) are valuable to me as a developer. I remember as a child learning code in environments like BASIC, Pascal, TCL, Inform6, etc. And knowing that I could use my preferred text editor that I had a mental model about was a big win. I could lookup references in a book and learn easily. In contrast to IDEs which always got in my way confusing the heck out of me when really I just wanted to type examples from the books I got from the library.

Call me old fashioned but I have a hunch that the separated and minimalist approach has value in learning programming. To this day I still find doing things with minimalist tools I am far more productive than my counterparts who hunt and peck through menus and mouse clicks. A big advantage I think it this separation and minimalism primmed my brain to see way to compose tools and ideas instead or relying on what the system tells me I can and cannot do.


Looks pretty cool, I’ll give it a go on a computer tomorrow!

One thing I noticed, when I did the rectangle demo, I’d click on the “123” to input a number, but my phone showed the full keyboard, would be nice if it defaulted to numbers for that. (Obvs it’s not designed for a phone but I assume the same on a tablet?)


Nice idea! Adding a ticket for it


> Pickcode provides a much clearer transition path for students to Python/JS/Java. Our target market is middle/early high school kids, and that’s who we’ve tested the product with during development

there's any paper backing this claim?


Well, this is not the n-th visual block language but an IDE with realtime reruns of modified code.

Tangentially, but not so much: I was talking with a 17 yo last weekend. She teached Python herself a couple of years ago and they are teaching it now in her class. She can't understand how her classmates can have difficulties understanding

  x = 5
  y = 6
  z = x + y
I asked the value of z to a 30 yo that was listening to the conversation and he first answered 5 + 6, then looked at us, thought again and said 11.

The student then told me that some of the other students eventually understood that z takes the value of 11 but their question was "how a machine can do that" and nobody answered to them. I wonder if a little of assembler on a toy CPU could be a better starting point. For example this Machine Code for Kids card game [1] They are selling the cards from the home page of the site (I'm not affiliated with them, I just bought a few decks.)

Or a two bits binary adder with logic gates.

[1] https://punkx.org/4917/guide.html


I sometimes use a Turing Tumble to demonstrate this: https://upperstory.com/turingtumble/

I've also had occasional success first convincing them they know how to add "mindlessly", by just manipulating symbols, and then explaining that we can have machines do it mindlessly, too. I don't use those words, ofc.

For example, you might ask them "Imagine you had a younger sibling who couldn't add. Maybe they didn't even know what numbers were. Could you teach them how to add by just telling them what symbols to write down as they looked through the symbols in the addition problem? Maybe there's an index card labeled '6+3' and on it is written '9'. You tell them to look for the correct index card and write down the corresponding symbol."

You can also explain binary to any interested student who is 13+ and then the idea that a machine can do it becomes a lot easier.

This video of Richard Feynman explaining how computers works is very good: https://www.youtube.com/watch?v=EKWGGDXe5MA

He uses a metaphor I've gotten a lot of mileage out of. Imagine you have a clerk who can add and multiply like a regular person. Now imagine there's someone else who knows only how to add and count, but have no idea what multiplication is.

If they can add and count fast enough, it'll look to an outsider like they not only know what multiplication is, but they can do any multiplication problem almost instantly.

Computers are like that: dumb but fast.

If they do something fast enough they give the illusion of "understanding", kind of like movies give the illusion of motion by swapping out still images fast enough.


>> She can't understand how her classmates can have difficulties understanding

Because most people are completely illiterate with respect to mathematics. I wouldn't hold high hopes on their ... whatever the opposite of "functional illiteracy" is.

One idea in case you talk to that "17 yo" again. Ask her to ask her classmates to compute "{{2} over {3}} over {4} + {5} over {{6} over {7}} = ?", here's a visual view of this operation with fractions: https://imgur.com/IqhEsmX

I bet the discombobulated by "z = x + y" also get flabbergasted by fractions. If so, it's not they have trouble learning programming. They have trouble learning anything, q.e.d.


> Because most people are completely illiterate with respect to mathematics.

Maybe, but...

>>The student then told me that some of the other students eventually understood that z takes the value of 11 but their question was "how a machine can do that"

... it's possible their block wasn't math, but they were hung up on the fact that they didn't think a *computer" could do math like that.

> They have trouble learning anything, q.e.d.

I doubt that. There are probably a dozen other more plausible reasons.


I would be very very surprised (and very very disappointed) if anyone is confused and/or surprised that a computer can do basic addition.

If those sorts of people exist then they’d be totally blown away at the capabilities of a pocket calculator.


That still leaves questions that ideally the class should explain:

- How does the computer understand that it needs to add

- How can the computer go from these 3 lines of text to "sure, let's add"

- Why does text even mean anything to the computer

- For that matter, sure it can add, but HOW? It's not like it has a pencil and paper.

Because indeed the infrastructure between these 3 lines of text and the addition is not trivial. These are legitimate questions.


I said:

"... they didn't think a *computer" could do math like that."

Emphasis on "like that" meaning laid out like that. Context can affect people's reasoning. Maybe they've never seen code.


I’m not really sure I get the distinction but I guess this is just one of those occasions that I’m just going to struggle to relate to.

Thanks for sharing the anecdote though. :)


> it's not they have trouble learning programming. They have trouble learning anything

sheesh


"how a machine can do that" > "nobody answered" is a really key takeaway here.

Do teachers understand coding enough to answer basic questions like that? I'm curious about whether they do.


Not really. But based on conversations I've had with folks who have worked on staffing such classes in schools, it is a known trade-off: A teacher who cannot answer all tech questions is better than a tech person who cannot teach. If someone exists who can do both, that is wonderful, but if you have to choose... choose a teacher.


From experience, no.

When you have to correct their code you know their ability.


Maybe some if you get lucky and find someone who's really into the subject, but it certainly wouldn't be a requirement because the people hiring for that position don't think that way. And I imagine the Venn diagram of people who know that and people who are willing to put up with how high school teachers get treated by The System (assuming we're talking about the US and not Finland) instead of getting a job in tech is pretty small.


I suspect there's some confusion here that it makes sense to iron out instead of jumping to conclusions. Maybe a pedagogical problem. I'm not so sure talking about logic gates or assembly is a good idea as that is an implementation detail. Programming is something you can do on pen and paper; there's a distinction between programming and automation.

What would happen if you take away the computer and speak strictly in the language of arithmetic? It seems they would have no trouble given the the eventual answer of 11. Perhaps they need to hear that that the computer can automate these operations, how it happens under the hood is a separate question that can be addressed separately. It is a valid question, of course, and perhaps its a sign of fascination. That would be good, but needs to be tempered by patience.


Been an old fart, I started coding on the C64 in 6502.

It wasn’t that hard to learn enough and, given I was cracking writing crack-intros, it has helped me hugely in the modern world. As an example, threading is child’s play because I did VBL interrupts.

However, the institutions today naturally teach something more relevant to getting a job as they did in my day (68k, Turbo Pascal and some C).


My first thought in this context was this is a 9th grade math problem, not programming. If the problem relating it has to do with how a computer can do it - do they not allow calculator use anymore?

I can not imagine that schooling has gone so far backwards with so many advances, or at the least I really hope that it has not. I was not even in advanced math courses and was/am average at best when it comes to math and would have thought the confusion would happen when getting to something like:

    x = "hello" 
    y = "world!" 
    z = x + " " + y
where it stops looking like something your entry level high school math class has you doing 30 odd problems a day on.


I suspect that Assembly doesn't click either if you don't know logic gates. My granddad was an impulse electronics guy, so before receiving a PC I already knew how transistors, triggers, counters, registers, adders work. He built a simple "CPU"-like thing from some journal out of ICs and explained how it works step by step. Later it helped to clear the gaps between `z = x + y`, `adc b` and something =▯- and -|< like.


Scratch has extra blocks for such things as:

set variable to [value]

change variable by [value]

which imo greatly reduce such ambiguities.


This looks cool. I've been looking for something for my son. How much will this cost in the future? I'm assuming there's a subscription model round the corner.


$5/month for unlimited lessons. That fact should be put on the landing page, it's on the todo list


Yeah that should be upfront. I've no hassle paying but do like to know how much without having to go searching or finding out during the sign up. Thanks for the quick reply.


Why would I teach this rather than a FOSS platform?


My kids don't have English as their native language.

Does anyone have experience with teaching kids how to code if they don't speak English yet? Do you only change the variable names to their native language or do you use a language where you can also translate the commands?

My assumption is that starting with English commands should work, but I don't know.


Looks great, congrats!

I made a small interpreted language on top of nodejs, for the same customers. https://github.com/MoserMichael/jscriptparse

However it turns out that you can't draw too much with node, so I didn't manage to add turtle graphics.


I see the target market is middle/high school kids. Any tips for younger kids?

I've been trying to get my daughter (8) to enjoy coding more. She does code.org and Scratch a bit, but we've been experimenting with Python/PyGame. She really likes drawing and games, but it's pretty difficult to teach.


There is all kinds of drawing and gaming programs in Scratch and its (subjectively) better cousin Snap!

Using Pen (very similar to Turtle drawing) is easy and surprisingly capable. But Pen in Scratch is limiting in term of controlling color and output texts. Snap is much better in this aspect. Blending spites and stamping can result in nice effects as well.


An 8 year old would set the Pickcode record by one year, no reason not to try!


Hey Charlie, love this. I would rename 'call' to 'make', or perhaps 'do', but this concept likes really neat.

Will give this a whirl with my girls, who are a little bit younger than your target market, and will flick you through any useful feedback.


Thanks, tim! charlie@pickcode.io whenever you have feedback


awesome-python-in-education > Interactive Environments: https://github.com/quobit/awesome-python-in-education#intera...


Rather than multiple calls to random, have you considered picking the x and y offsets randomly and then picking the color based on them?

It seems like one could tell a better story about why-that-color? If it were a function of the other random choices.


I'm interested in a direction like this but along the lines of allowing adept programmers to write real programs on a mobile device. Using touchscreen keyboards to write real code is pretty unwieldy.


> structured code instead of blocks or node graphs. THANK YOU. I thought I was insane, nobody understood me. I know which tool I'll give my daughter.


Looks very interesting! An annoying coincidence, however, is that in norwegian, "pick" is a homophone to a vulgar form of the word penis.


I was writing pretty cool stuff in c64 basic when I was 10. Just write it (on the dirt-primitive text editor) and run. This seems relatively troublesome.


As someone who has worked in this space before, using Blockly to help teach Arduino coding to kids, this looks fantastic!

Keep up the good work.


This is awesome. Congratulations. I wanted to introduce my kids to programming so this is very timely. Thanks for building it.


How dies it compare to https://hedy.org/?


Congratulations on the launch!


Few observations from playing around with the demo: * you claim that code editing is totally structured, but at the same time it is possible to delete one of the two parentheses thus creating broken expression, and no straight forward way to add the missing parenthesis since writing of them happens only in pairs. It feels like with exception to top level statements. * when editing it's easy to end up with stray empty tokens which result in confusing syntax errors (that's even worse than significant whitespaces in plaintext editing)

Overall it fells like this feels like worse parts of both sides: syntax errors of traditional plaintext code editing, and constrained editing ability of structured code editing.

> For professional programmers, the editor is probably pretty frustrating to use (no vim keybindings!)

It is not the lack of vim keybindings that's causing frustration, it's the lack of almost any keyboard input or ability to type in if you know what you are trying to enter and being forced to search for operators within tiny scrollable 3x3 grid. Either the editing should be a lot more constrained with clearly displayed placeholder slots like it is in scratch, or the editor should allow typing in expressions using keyboard.

Consider that the goal of project is helping transitioning from block editing to more practically used programming languages -> I would suggest exploring the second approach. Keep the current menu input method, but when a user presses a key insert or start editing appropriate type token. That is if the expression insertion menu is open and user presses a number key just start editing a number, they would have to use keyboard for entering it anyway if they clicked on number input button in the dropdown. Similar if you press + key, and + is token that's currently available in the insertion dropdown just insert '+'.

Other pain point was editing. At statement level I would say it's reasonable, but expression level any editing felt miserable. In some cases it felt like simplest way of editing is erasing everything, in other moments it felt like some kind of bad Levenshtein distance code golfing. Lets say you have expression `a+b` and you later decide to change it to `(a+b)*c`. Your options are either erase everything and rewrite from scratch or insert '()' before a+b, insert '()' after a+b, erase ) from first parentheses pair, erase ( from second parentheses pair, add * and c. Neither plaintext editing nor good block based code editing have this problem. Also you can't select and copy or move anything except whole statements.

Overall with exception of top level statements, it hardly enforces any structure of code and you can enter almost arbitrary sequence of expression tokens forming an invalid expression.That kind of defeats the point of having somewhat structured non typing based input.

Bug: In chromium the insertion dropdown shows 3x3 grid, but scrolling with mousewheel scrolls by 4 lines. Meaning you can't easily select anything from 4th row like '*'. Can't you just show all the operators? Even on mobile phone there should be enough space to show 3x9 or 5x5 grid.

Bug2: drag and dropping an if statement inside itself caused the page to hangup. Infinite loop? While dragging a statement with nested statements like if or while should highlight the whole block not just the first line.


Wow, thanks for all the feedback! I agree that expression level editing can get pretty cumbersome at times, it's the biggest design challenge in the editor I think. One thing we may add is a toggle to edit expressions in plain text and parse them back into the visual bubbles.

Re: the fact that syntax errors are possible: it is really really hard to make an editor where invalid states are impossible while trying to make expressions easy to enter. Scratch and other block languages do this by forcing you to write code in prefix order. I want to PLUS 2 and 3, vs in Pickcode where you write 2 + 3, and the expression is in an invalid state before you enter the 3. Rewriting 2 + 3 to 2 + (2 + 1) is really hard when you have to think in prefix notation. One advantage that we have is when there are syntax errors, they are necessarily at the expression level, so in the worst case the student can just scrap the line and start over, vs in plain text where the error message for a mismatched paren could land lines later.


It's not visual.


I can see it. So it is visual for me.


You can see C# or Java code as well. It doesn't make them visual programming languages.


I personally wouldn’t teach children mutable imperative programming. I think functional, data driven, declarative, “data first” programming would be a better introduction to the subject. We’ve essentially broken our own brains training ourselves to think the imperative/mutable style is normal


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.


OP is talking about children, not computer science students.


"students" doesn't exclude children.


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.


Something like Roc-lang, where it’s a stripped down yet capable language seems to be a good fit. But I agree solving problems with a functional approach would better develop the foundations.


I think the "real" programming part should be removed.

All programming is real programming and this encourages throwing shade on languages and people that are not deemed "real".


That sentence also seemed awkward to me


Awkward in the way you don't put a dig against the other when talking about your new thing. I am particularly cognizant of othering and language that puts people at odds.


How I wish these "for children" programming languages were more focused on functional programming, rather than being so imperative.


I built a game you might find interesting. It's basically a visual Lisp wrapped up in the idea of arranging magical cards to build spells.

https://www.bittwiddlegames.com/lambda-spellcrafting-academy...

The demo is playable in the browser too thanks to Rust + WASM.


I dunno, I think teaching functional programming to kids is an awesome goal, but at the same time most "real programming" they'll move on to (javascript, python etc) is going to be imperative.

It's probably a better learning experience for kids to be able to get to a point where they can make fun things like games and websites, and then teach them how to improve the correctness of programs.

(Obviously there are some great options for functional creation like elm, but there obviously isnt the same level of available learning resources yet)


This is the first time I’ve seen JavaScript not being described as a functional language :)

As for your more general point: it’s easy to go from functional -> imperative. It’s a lot harder to do the same thing in reverse.

Source: anyone who learned LOGO before BASIC in the 1980s.


Functions are at least first class! We have map and filter on lists, for example. I'd love to add some more advanced curriculum that focuses on teaching a more functional style.


If you want inspiration, we created a (mostly) functional-first curriculum for Snap (like SCRATCH) which still has highly visual output. https://bjc.berkeley.edu/bjc-r/course/sparks.html It's definitely trickier to bring functional programming into these sorts of environments, but I think we came up with some nice compromises there.


I agree.

Functional programming sits on a difficulty range: spreadsheets on the low-end (debatable but I'll say it!), and on the high-end, well, I think that everything else FP sits there with minor exceptions.

I'm developing a language for numbers that is conceptually closer to spreadsheet formulae than imperative programming or hard-FP, therefore I think hopeful for this kind of task in the long-run. It's "only for numbers", so really think spreadsheet-formula type complexity, but I won't stop anybody from going wild with interpretation.

To see things you pair it with some other language like JS, but code for these "apps" can be simple/declarative and pre-rolled. I have a JS visualization library that will probably be graphical one day.

I'm working on the project website [1]. Following spreadsheet fashion some examples are a little bore, but there is a raycaster rendering to a bar chart and heart shapes, bouncing balls and projectiles, to lighten the mood for early developer-adopters or contributors.

For some more project background: by encapsulating numbers in a language (and not a mad one and one that we can safely and actually run), it can facilitate transparency for numbers. Transparency and education go hand-in-hand. I'm talking about numerical literacy primarily, but I think that too goes hand-in-hand with.. programming on computers.

[1] https://calculang-quarto-site-messing.pages.dev/examples


It's funny that you and a sibling have essentially opposite asks [0]. The other commenter's anecdote is about how even the magic of expressions resolving to values goes over some novices' heads— how much more so would a full expression-oriented language!

I'm a fan of functional programming, but I also sympathize with OP's observation that even python might be too far from the CPU to be a good introduction to computing. It probably depends a lot on the child and the teacher—a functional programming language would probably appeal more to older kids (high school) who are comfortable with math.

[0] https://news.ycombinator.com/item?id=38366268


> even python might be too far from the CPU to be a good introduction to computing

IMO Python is useful as a didactic tool not so much for teaching kids how computers work as for giving them an emotional experience of "Wow, I can make the computer do things! I'm basically a wizard!" that then might motivate some of them to keep learning about computing.

But yeah, there will also be kids who are already well past that stage and ready for meatier stuff. So probably a combination of approaches is best to provide kids with the level of detail they'll find most engaging.

Anecdotally, I grew up on Logo, Lego Mindstorms, and HTML, and got my early career started in Python before I really dug in and learned about how hardware makes the magic happen because I realized I was going to be handicapped until I knew that.


> even python might be too far from the CPU to be a good introduction to computing

That depends on what one considers to be the best way to introduce computing. I personally think kids are a lot less likely to be engaged by a bottom-up approach (start with "this is what hardware does") than a top-down approach (start with "you can make cool things with it").


"It's funny that you and a sibling have essentially opposite asks"

Trying to please everyone is the road to madness, while acomplishing nothing.


How would that help children? You want to make it easy to get into. I think imperative is simpler than functional. Let them learn to crawl first.


It depends on the complexity of the program/problem being solved. I think it’s conceptually simpler, for example, to demonstrate how a function that can’t have side-effects works than one that doesn’t by pure “accident”. The real trouble is when you want the program to do anything actually useful, like interact with anything (input/output). And since that’s where the vast majority of programming is spent, I tend to agree that imperative first is a better approach.


> To me, block coding is too far removed from regular coding for kids to make the connection...provides a much clearer transition path for students to Python/JS/Java.

Personally I wonder what the ultimate goal is. I appreciate furthering education, making connections between different concepts, etc. But starting out with something that is not Python, with the goal of ending up doing Python, seems like a funny way to approach things.

So Pickcode has some value, but not enough that I'm willing to transfer my educational time (and dollars) from other options giving my children the critical thinking skills & love of learning that let them explore and make the connections naturally. Educational materials are in a competitive space!


Following up on my own comment. Others also show changes to text-based code when changes are made to graphical-based [1], but I haven't seen any that allow working backwards, so that clicking or changing graphical highlights and shows how text changes. To me that would enforce how the two fit, rather than a one-way cause-effect.

[1] want to especially mention https://makecode.adafruit.com/, which is really well done as you can even simulate moving the board around to see what accelerometer inputs do in your code.


> But starting out with something that is not Python, with the goal of ending up doing Python, seems like a funny way to approach things.

Another project in this space is Pyret [0]. The Pyret language has been developed with the express intention of taking completely novice programmers, teaching them how to program in a language with reasonable semantics [1], and progressively add language features until they eventually switch to Python. The language is integrated into the DCIC course [2].

The idea of a language that can progressively gain features was (to the best of my knowledge) pioneered by Racket. The idea is that a particular file can be declared at a specific "language level" (I think that's the terminology), which restricts the set of features available to the user. Over the course of the semester, new features can be added as they are taught. The advantage of this approach is that students do not accidentally encounter surprising semantics that they inadvertently internalize to the detriment of their long-term learning.

The Pyret project is actually spearheaded by Shriram Krishnamurthi at Brown University, who was on the original Racket team. His career has focuses on the application of PL theory and tooling to computer science education. One of his most recent publications is particularly interesting with regard to the present topic, which is an experience report detailing what happens when students move from Racket to Pyret and from Pyret to Python [3].

[0] https://pyret.org

[1] While my use of the word "reasonable" is certainly opinionated, what I mean is that Python's semantics are simply unintuitive to many novices. I've forgotten the title of the paper I read that analyzed this, but a related paper is "Python: The Full Monty", which develops a small-step operational semantics for the core Python language. Many of the specific semantics are surprising even to seasoned Python developers! Direct PDF: https://cs.brown.edu/~sk/Publications/Papers/Published/pmmwp...

[2] A Data-Centric Introduction to Computing is a new introductory course at Brown (which is also now being implemented at a few other schools) that seeks to introduce students to computing through tables and data. There's a lot of research backing up the specific methodologies chosen by the authors. https://dcic-world.org

[3] What Happens When Students Switch (Functional) Languages (Experience Report), direct PDF: https://cs.brown.edu/~sk/Publications/Papers/Published/lkft-...


> The idea of a language that can progressively gain features was (to the best of my knowledge) pioneered by Racket.

Interesting, I did not know Racket had those connections, although I dabbled with Dr. Racket [1] a while back. It's a pretty fascinating thing to work with, especially from the educational standpoint.

Smalltalk also has ties to education, see Alan Kay's "The Early History of Smalltalk" [2]

Of course when we talk about extensibility in a programming language, I would think early examples are not only Lisp (Racket is a Lisp of course) but also Forth [3].

[1] https://docs.racket-lang.org/drracket/index.html

[2] http://worrydream.com/EarlyHistoryOfSmalltalk/#smalltalkAndC...

[3] http://www.bradrodriguez.com/papers/moving6.htm (this page describes extending the language, but is part of a larger project building a Forth from the ground up...not sure if that counts as extensibility or just a pain point, but regardless building out a Forth seems to be part of the rite of passage, so in my mind that counts as a language that is focused on extensibility. Although not necessarily focused on pedagogy.)


I haven't looked enough into Smalltalk's history — thank you for the pointer!

Although the "language levels" I'd mentioned previously are implemented with macros, the underlying concept is a little deeper than that and I don't know of an earlier example of such a system! Certainly the Lisps and Schemes did a lot of macro work, but they did not tailor applications of that work to CS education in the same way (to the best of my admittedly limited knowledge).


It’s DrRacket not Dr. Racket


Saw the domain, held out a glimmer of hope it had something to do with the PICK System or PICK BASIC: https://en.wikipedia.org/wiki/Pick_operating_system




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: