[HN Gopher] Show HN: New visual language for teaching kids to code
___________________________________________________________________
Show HN: New visual language for teaching kids to code
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!
Author : csmeyer
Score : 278 points
Date : 2023-11-21 16:16 UTC (6 hours ago)
(HTM) web link (pickcode.io)
(TXT) w3m dump (pickcode.io)
| bitwize wrote:
| 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
| pmontra wrote:
| 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
| badcppdev wrote:
| "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.
| OnlyMortal wrote:
| From experience, no.
|
| When you have to correct their code you know their ability.
| indigochill wrote:
| 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.
| codingdave wrote:
| 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.
| OnlyMortal wrote:
| 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).
| jfarmer wrote:
| 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.
| MichaelRo wrote:
| >> 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.
| zolland wrote:
| > it's not they have trouble learning programming. They have
| trouble learning anything
|
| sheesh
| HumblyTossed wrote:
| > 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.
| hnlmorg wrote:
| 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.
| HumblyTossed wrote:
| 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.
| hnlmorg wrote:
| 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. :)
| 1659447091 wrote:
| 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.
| lo_zamoyski wrote:
| 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.
| sssilver wrote:
| How I wish these "for children" programming languages were more
| focused on functional programming, rather than being so
| imperative.
| csmeyer wrote:
| 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.
| pamelafox wrote:
| 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.
| benrutter wrote:
| 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)
| hnlmorg wrote:
| 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.
| lolinder wrote:
| 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
| indigochill wrote:
| > 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.
| hutzlibu wrote:
| "It's funny that you and a sibling have essentially opposite
| asks"
|
| Trying to please everyone is the road to madness, while
| acomplishing nothing.
| bittwiddle wrote:
| 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.
| esafak wrote:
| 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.
| sidlls wrote:
| 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.
| dndn1 wrote:
| 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
| uticus wrote:
| > 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!
| uticus wrote:
| 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.
| DonaldPShimoda wrote:
| > 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-...
| uticus wrote:
| > 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/#smalltalkA
| ndC...
|
| [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.)
| spdegabrielle wrote:
| It's DrRacket not Dr. Racket
| pamelafox wrote:
| 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).
| zozbot234 wrote:
| 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).
| pamelafox wrote:
| 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.
| qez2 wrote:
| 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.
| chaosprint wrote:
| 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?
| altruios wrote:
| 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.
| csmeyer wrote:
| Will do
| intpx wrote:
| 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
| westurner wrote:
| awesome-python-in-education > Interactive Environments:
| https://github.com/quobit/awesome-python-in-education#intera...
| cbhl wrote:
| 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.
| csmeyer wrote:
| 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
| rsweeney21 wrote:
| 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!
| latchkey wrote:
| I'm curious, why not get a kids sized keyboard?
| rsweeney21 wrote:
| I didn't know there was such a thing. :)
|
| Might need to get him one for christmas.
| DonHopkins wrote:
| Commodore PET! ;)
|
| https://commons.wikimedia.org/wiki/File:Commodore_PET_keybo
| a...
| 867-5309 wrote:
| pretty sure my PET had a chunky black keyboard and the
| tape drive was separate
| mikelnrd wrote:
| You might like Kano's small keyboard, can find them on
| eBay: https://youtu.be/Z0I-vw6Wc0U?si=U2XV2f0ZB9vvqQnu
| soulchild77 wrote:
| 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. ;-)
| fn-mote wrote:
| > 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.
| AmosLightnin wrote:
| 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.
| pkdpic wrote:
| 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.
| darkwater wrote:
| 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!)
| pkdpic wrote:
| 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.
| luqtas wrote:
| 3 y/o can form simple sentences like "dad is playing"
|
| why they can't understand "x = 3"?
| darkwater wrote:
| Because one is rooted in sensorial life and the other is
| purely abstract?
| luqtas wrote:
| the grammar on a language isn't abstract too?
|
| anyway, heheh, Scratch aims to teach basics concepts of
| coding to children older than 6 y/o; who knows if Python
| is easier?
| IshKebab wrote:
| GDScript is a surprisingly good language. Better than Python in
| many ways (e.g. it has `var` and `const`).
| jcelerier wrote:
| > 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 :)
| zozbot234 wrote:
| 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.
| whstl wrote:
| 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.
| jcelerier wrote:
| > 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.
| pass_the_salt22 wrote:
| 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
| semitones wrote:
| 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.
| hk__2 wrote:
| OP is talking about children, not computer science students.
| erikerikson wrote:
| "students" doesn't exclude children.
| pass_the_salt22 wrote:
| 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.
| maweki wrote:
| 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.
| nocsi wrote:
| 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.
| hnlmorg wrote:
| 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.
| semitones wrote:
| 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
| hyperthesis wrote:
| 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.
| aragonite wrote:
| > 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.
| saurik wrote:
| 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.
| hyperthesis wrote:
| ASTs
| jerf wrote:
| 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.
| hyperthesis wrote:
| 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)
| jjkaczor wrote:
| 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.
| solardev wrote:
| 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/c111454c
| 9fd2f74d37d1e8a4e739...) or the similar https://retejs.org/
| b4rtazz wrote:
| 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.
| sitkack wrote:
| 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".
| account-5 wrote:
| 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.
| csmeyer wrote:
| $5/month for unlimited lessons. That fact should be put on the
| landing page, it's on the todo list
| account-5 wrote:
| 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.
| bennyp101 wrote:
| 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?)
| csmeyer wrote:
| Nice idea! Adding a ticket for it
| Karliss wrote:
| 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.
| csmeyer wrote:
| 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.
| layer8 wrote:
| 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.
| postalrat wrote:
| So "forward" is something you click and it shows all possible
| expressions for a new line?
| csmeyer wrote:
| 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.
| wruza wrote:
| I always wanted `set` in regular languages instead of (or in
| addition to) =/==.
| secret-noun wrote:
| 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.
| CoastalCoder wrote:
| 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 how 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...
| timClicks wrote:
| 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.
| csmeyer wrote:
| Thanks, tim! charlie@pickcode.io whenever you have feedback
| omneity wrote:
| 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.
| matsemann wrote:
| 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.
| dang wrote:
| 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)
| dgudkov wrote:
| It's not visual.
| mortallywounded wrote:
| 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.
| csmeyer wrote:
| An 8 year old would set the Pickcode record by one year, no
| reason not to try!
| luqtas wrote:
| > 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?
| swayvil wrote:
| 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.
| n_plus_1_acc wrote:
| How dies it compare to https://hedy.org/?
| Retr0id wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-21 23:00 UTC)