Ironically just this week, I put my four year old in front of an apple 2 emulator running apple logo, and he was far more engaged and interested than any of the modern “kids learn to code” toys of today.
Even the “updated” logos I found sucked because they throw you into a notebook not a repl. For young kids, a repl is way less overwhelming and confusing, because you’re “talking to the turtle.” Even the error messages are better: “I don’t know how to X.” The kid loved seeing the turtle talk back. These notebook oriented ones kind of lost the original thesis of logo form Paepert.
If you might be more interested in a modernized version of Apple Logo, you should check out https://turtlespaces.org -- I too grew up with Apple Logo and thought it would be great to create a 3D version of it. It has a REPL just like the original, and the 'I don't know how to...' error messages too!
I guess the main difference between MakeCode and most other kids learning environments is that it starts with a real language (TypeScript) and then exposes a subset of it through graphical blockly interface (while allowing usage of both). Having a real language makes it easier for more advanced users to create libraries, which can be exposed (as blocks which map 1:1 to functions) to less advanced ones. It also doesn't place an artificial ceiling on user's abilities.
The library approach in micro:bit is mostly used for interfacing external hardware, but in https://arcade.makecode.com/ it allows for the entire 8-bit game engine to be implemented in-system.
Southern California, I think they gave 2 to every elementary school in California iirc. -- EDIT: so, I guess it was not till the 80s they gave them out to all the schools. I thought we got them in the second grade, but maybe it was 4th grade. http://hackeducation.com/2015/02/25/kids-cant-wait-apple
They are :) It's not as huge as Scratch is but our Logo interpreter gets a reasonable amount of traffic, enough to make it worthwhile to develop, anyway
I like that strings and arrays (not their individual elements) are marked with `[]` and `$`, just like BASIC. Beginners tend to have a shorter attention span and can't easily reason that some names defined earlier are arrays or strings, so that would be easier to understand for them as long as you disallow names that only differ by those markers (and give a helpful error message, for now Easylang doesn't seem to do that though).
Reminds me of Logo as well (I worked for the top producer of Logo implementations). Would be interesting to read some comment on its lineage from the designers.
I am a computer science teacher and have developed a teaching and learning programming language with an easy-to-use browser IDE. There are several tutorials integrated - from a programming course for beginners to recursive programming.
The programming language and IDE run entirely in the browser, there is no communication with the server after the web page is loaded. Since it is designed as a PWA, it also works offline.
This language has a very simple structure: There are numbers and strings as data types, arrays of these data types, and arrays of arrays. Unlike Python, it is statically typed and has explicit end-of-block delimiters.
Since the language is kept very compact, it suits beginners on the one hand, and the browser environment on the other. The environment loads quite fast, and the IDE is also able to parse and format the code up to the current line on every "enter". The language is written in C and runs using WebAssembly. JavaScript is used for the graphical user interface and graphical output.
So many things that go from initial concept, to full implementation, then thinned out, and back to a full implementation in a new technology. A good example is from centralized mainframes and terminals, to desktop computers, then client-server, then thin client, rich client, and finally rich client in a web browser with centralized app hosting on a cloud server.
The future of programming environments could be the 'browser', not as in web, but the Smalltalk kind. There wasn't concepts of source files, and edit/compile/run weren't so distinct. Producing 'an executable' was merely saving the environment state. A platform that could work like that adding recent advancements like versioning and remote collaboration could be powerful and easy to use. Deployment could also be a very not-so-different thing than saying run that image on up-to-N concurrent hosts configuration.
One thing that I'd like to see attempted differently is removing the 'procedural' style so prevalent that it's barely even noticed as a choice. Immutable datastructures makes lots of things simpler. Not rebinding values to named 'variables' can also eliminate classes of bugs and sources of confusion. This can be done badly as in XSLT where you end up using recursion for the simplest things. There can also be better ways like the functional style that's gaining some adoption, e.g. map, filter, take_while, drop_while. Basically changing our thoughts into starting values, ending values, and transformation expressions in a declarative style, rather than the nitty gritty of pretending to be a CPU combining registers, loops, conditions etc.
I used to program in Smalltalk and as it faded from popularity I wondered why. It seemed so much better in many ways.
Now I think the problem with the image-based programming is that while it is easy for a single programmer it makes collaboration more difficult. Why? Because it is very difficult or impossible to "merge" two or more images.
My changes might work when added to a default virgin image, but there is no such thing as virgin default image when every Smalltalk provider has their own and multiple versions of them. Any image is as good as any other.
The ability to change anything in the image really means the ability to depend on any fact about the current image. If you apply your changes in an environment/image where any one of those facts no longer holds you will get unpredictable results.
That's really well said. I've read this before but the way you've described it makes more sense to me. I can see that a similar problem made lisp difficult to catch on, as each application or company was its own ecosystem creating its own dialect with so many bits and pieces that the core language is such a small part as to not really be considered transferable knowledge between shops.
I thought making it all cloud-based with realtime collaboration would help, but it wouldn't be nearly enough. At scale there needs to be ensurances of stability--something like realtime tests. I have no idea how something like that could be made to work efficiently enough to be effective.
It is also interesting to think from the viewpoint of Curry-Howard Isomorphism. Programs are proofs. Progress in mathematics relies on the ability of mathematicians to use other mathematicians proofs as their lemmas. That is possible because all mathematicians speak the same language.
But if every programmer has their own version of the base-library that hinders collaboration. And still the base-library must also somehow evolve all the time. Like you say, not an easy problem, but as in mathematics the ability to use other people's software as "lemmas" I think is (or should be) the key problem of Software Engineering research.
I can relate this to what does happen between ecosystems. We 'black-box' subsets of the problem by splitting up into front-end, back-end, microservices, datastores, etc. This does give some interoperability between languages/ecosystems. Within each language/ecosystem there are library/packages that can serve as a shared/reusable base but still have many challenges in that there typically is no agreed-upon contract. We're even drifting from stability that we had before in that languages themselves evolve more rapidly now often having version/point-version numbers or add-in extensions.
Another thing that keeps happening is that languages become popular because of the platform it's tied to gets popular with little correlation to how good the language is in any sense, other than it being adequate to produce a working program. There's at least some possibility of convergence with LLVM backends, wasm or jvm and .NET. I think there will still be more (low-code, online collaborative) before there's any culling and less.
From the name I was expecting a readable lang, perhaps drawing inspiration from ruby.
The only thing that makes this an easy lang is apparently based on the Dennis M. Ritchie quote at the top of the documentation - "A language that doesn’t have everything is actually easier to program in than some that do"
You can make web apps, for that you need a web space. Or you can install the programs locally in the web browser storage with the code runner - that's a PWA (progressive web app).
Eh. I don't like the terminology of "installing" programs into the runner. Having to explain what a VM is with programs to run in it before you even start coding is what turns beginners off from learning.
You don't need the "Code runner" to code. The Web IDE is enough for that. With the "Code runner", which is a PWA, you can save programs locally and run them offline.
