Posting this across several forums... This is a bit lengthy a post, but it's because I'm going to outline my entire reasoning for starting this project.
For some time I've been of the opinion that education on the whole is failing to... well, educate. Between teachers being paid more than twice that of the average citizen bankrupting our schools, to poor standardized test performance, social promotion, and kids graduating high school with what when I was a kid would have been considered a 4th grade reading level, it is painfully apparent to me that the entire "institutionalized" educational system is failing to deliver. There's a reason we're seeing budget cuts, program cuts, and even mass layoffs or outright firings. Just ask Providence, Rhode Island about that one.
The gaps in what's being taught too -- like apparently physics is a single class at the junior high locally, that isn't even offered to standards level students?!? That's frightening to me.
My ex-fiance was/is a math teacher, now studying up for her masters after a year of subbing, and everything she's told me reinforces this -- what the kids coming into her high school class had for knowledge being a fraction of what we were expected to know 30 years ago at the 4th grade level... much less concepts like "social promotion" and the rapid decline of results in standardized tests leading to the inexorable conclusion that modern school is little more than glorified daycare!
NOT that from my time in the system roughly two or three decades ago delivered anything I use today past the 6th grade. My schools didn't even have computer classes; though certainly some of them had computers that were locked away due to a lack of qualified staff or at best used as typewriter replacements for the ONE typing course. (great when there were no printers).
I think back to when I was learning -- and what did I REALLY learn to program on? I discount the Cosmac Elf because it was a limited toy more about learning the hardware side of things; but really it was the TRS-80 Model 1 and Color Computer, Atari 800, and the Commodore Vic-20 where I started actually being able to write software; Software that left my math teacher's jaws hanging open in wonder all before I even got to Junior High.
I look at the state of computing today, and... where are the equivalents to ROM BASIC that a ten year old kid could sit down with something simple like say... "Getting Started with Extended Color Basic" and by the end of the book be able to write something simple like pong all on their own? Something they can sit down, turn the machine on and just start using?
On the hardware side we have new devices like the Raspberry Pi -- cheap, simple... but on the software side they have it booting into Debian or Fedora and expect the people 'learning' to be alternating between gEdit and Bash? "for education" leaves me thinking they are aiming for college age -- in which case they're almost pricing themselves UNDER the market.
Near as I can tell (and I'm three weeks into this) there is NO suitable language / development environment I would be comfortable handing to a ten year old like I would a C=64 to go with the Pi's "for education" concept. Sure there's talk of doing things like making it boot to a BBC emulator or porting BBC basic to it; but that's ridiculously crippled if authentic, a bit complex due to choices that were made due to hardware restrictions that no longer exist, and if you were to modernize it, why not at that point just make a new programming language?!?
If nothing else, seriously, what is a child from today going to care about BBC Basic in terms of what they can do with it?
More so since to make kids interested in learning; what made me and those of us interested in programming back then in the first place?
Games? I know I wrote my share and typed my share of them out of magazines, and contributed my own to the various rags of the era.
Music? All of you who spent hours on your C=64 making SID files or later on the Amiga MOD scene...
Graphics? I remember being all impressed when I made my Coco draw Garfield on the screen using the DRAW statement...
Combine graphics and music, and this is what the demoscene was all about! Democoders being some of the most hardcore programmers ever.
Also when it comes to the pi, with the low price it would be a great entry level for the people who can't afford a modern PC or even a netbook/tablet... and if we're talking the poor why leave our dumpster diving friends with TV's out of the equation? The pi has a composite out, yet all the current software is pretty much MEANT for HDMI resolutions -- why not a 'old school' style 40x25 UI, since that's about the upper limit you can push composite anyways? (with 320x240 graphics underneath).
... and lets not leave out people who already have hardware; cross platform is easy these days what with SDL and OpenGL.
So... I'm doing it. I'm making a new interpreted language with an immediate mode, in-built editing tools, with 40x25 text and 320x240 as it's primary targets (with support for higher resolutions).
It will be called... Gumberoo; with it's mascot Menlo, the friendly Gumberoo. (as opposed to his evil cousin Anur, the baby eating Gumberoo)
For those who don't know, the Gumberoo is a North American legend of a hairless bear with a thich black bullet resistant hide and long almost alligator like mouth full of teeth.
Gumberoo was chosen because few people use the name, it's not trademarked to anything, the domain was available, and it sounds cute and friendly, even if the actual mythological creature was generally considered a monster. Taking a monster and making it friendly is nothing new -- Just look at Nessie or Ferdinand the Bull.
I'm writing this entire project using Free Pascal, and I may switch to objectPascal syntax just to make it easier when it comes time to deal with xCode for iOS/OSX. I chose Pascal not just because it's the language I'm most comfortable with, but for code clarity and because FPC can now target a wide variety of languages, and now ships with working SDL and OpenGL on SDL units... that it can now target ARM, x86, AMD64/EM64T, PowerPC and even SPARC... is really the icing on the cake. Lands sake, it might be possible to build this for the Wii or DS... or at least make the interpreter work there.
Besides, I'd sooner put a bullet in my head than deal with GCC. I'd sooner hand compile 8k of Z80 machine language than deal with 50 lines of C code.
So far I'm working up several lists... Broken into subsections; "Development" means targets I can likely achieve unassisted and when complete will mean it's reached Beta status. "Final" are what will be required for it to be considered 1.0
--------------------
Target Audience
--------------------
4th graders and up. I want this to be interesting enough for making games to hook kids, advanced enough to still entertain adults, and
--------------------
Hardware/OS
--------------------
OS Platforms
Development: Linux, Windows
Final: OSX, iOS, Android
CPU's
Development: x86, AMD64/EM64T
Final: ARM
Minimum of 700mhz ARM8. (what's in the pi)
Memory
Should be able to run full featured in less than 32 megs free space. (basically half what's left over after a 'massive' Fedora install on the Pi)
--------------------
Language
--------------------
variable types -- there will only be three types of variables, "number", "string" and "array". Number will either be 64 bit double precision or 80 bit extended. With modern hardware there's no reason to confuse people new to programming with the difference between byte, word, dword, integer, longint, etc... If you add a number to a string it will auto-convert to string, If try to add a string to a number it will throw a error during tokenization.
tokenizing editor -- per line editing much akin to the old line basic, but it will also let you scroll through the listing rather than using immediate mode commands like LIST. When you hit 'enter' to finish editing a line, the tokenizer will compile the line to bytecode.
break/continue -- one thing interpreted basic used to provide was actually a very robust debugging tool in being able to break and continue code. You could ^C, or you could use a command like 'break' to halt execution, change the values of a variable or look at variables, type "continue" and it would... continue with your changed values. You don't get that from compiled languages...
Immediate mode -- there are lots of new names for doing this, but the result is the same... you type in a line of code and it runs immediately, as opposed to 'deferred' where it runs later. Since I'm going to have the tokenizer compile by line, performing immediate mode operations should be simple.
No Scope -- Scope is a very complex concept that I've repeatedly over the years seen confuse people new to programming. Let's get logic flow into their heads BEFORE we confuse them with scope.
No userland objects -- objects are hard enough in a real language, much less in one without scope. It's a complex concept better left for better languages. Besides, user created objects in an interpreted language is most always a bad idea, and doesn't do objects proper justice. (see PHP)
System Objects -- however, introducing the notion of system objects having properties and methods is simple, and can be considered a baby-step into the world of objects.
Basically, provide objects, just don't confuse them by letting them try to make their own.
No line numbers -- I might be patterning on ROM BASIC, but lets at least TRY to make this a real language.
Labels -- since we don't have line numbers, we'll need something to point at. Rather than getting things all fancy with functions I'd like to keep it simple as line numbered basic was, so we'll have labels. Probably start them with a colon like in some assemblers.
No user function calls -- we'll have subroutines, but to keep the tokenizer (and expression evaluator) clean and simple, we'll not introduce that concept.
No return values -- since we lack scope and user made functions, there'll be no mechanism for RETURN to actually pass values.
Pointers -- uhm, no...
No Peek/Poke -- multi-platform from the start, there's no reason (and in some cases no way) to let people blindly access memory.
Useful state based input handlers -- inkey$ sucked, readchar sucked, input really blows chunks if you're writing something realtime like a game... so I'm thinking a 'ifKeyDown' language construct to read if a key is pressed, and a 'inputmap' function letting you quickly map out what to do or call when a key is down during a logic loop. This is one of the things we used to have to peek into memory for in the first place.
Sprite and animation engine -- The ability to assign a variable as a sprite, load textures from a png file, probably incorporate a simple sprite editor into it. This is something we'd have killed for back in the day, as even getImage/putImage and it's various equivalents across platforms were slow, painful and not that useful... I'm thinking on having these rendered using OpenGL and/or OpenGL ES so rotation, scaling and depth-sorting can be easily done. Also should incorporate collision detection.
"world mapping" -- the ability to place tiles into a large 'world map' that can be scrolled around in the background.
Backbuffered video -- a requirement for game animations that don't suck. Since I'm thinking OpenGL this is easy to do on the back end.
Rudimentary automatic physics -- mono-directional gravity (Mario), radial gravity (SpaceWar), drag, possibly having automatic reactions for collisions like bounce rates.
Audio playback -- likely WAV, Ogg or MP3.
Simple multivoice composer -- piano-roll type tool for making your own music and being able to call it from inside your program.
Programmable Synthesizer for making custom sound effects... I'm thinking multi-operator and introducing the concepts of ADSR, but in a simple way kids can grasp; kind of like what was built into a Casio VL-Tone, except having it sound good. A soft-synth would allow games to sound the same regardless of platform without relying on existing (or not existing) midi capabilites. If I could figure out the VL-tone at age 8, I figure a 10 to 12 year old can probably handle it today.
I'm still playing with the syntax, but so far I'm aiming for a simple program to look something like this:
Very rough example of what I have in mind for language syntax and grammar.Code:bufferVideo makeSprite player 32x32 player.loadTiles "playerSprites.png" loadSound "thrust.wav",thrustSound :menu player.hide clear stopSounds at 0,16 writeCentered "Simple Game Demo" write writeCentered "Press <SPACE> to Start" writeCentered "or <Q> to quit" inputMode buffered flushKeyBuffer renderFrame :menuKeyLoop inputMap = ' ' jump gamestart = 'q','Q' jump exitgame endInputMap jump :menuKeyLoop :gameStart clear player.moveTo 0,0 player.setMomentum 0,0 player.setAngularGravity 180,10 player.setDrag 1 player.show :mainLoop renderFrame inputMap = "q" jump menu = "a",arrowLeft,numberPad4,digitalLeft player.addMomentumX -1 = "d",arrorRight,numberPad6,digitalRight player.addMomentumX 1 = "w",arrowUp,numberPad8,digitalUp player.addMomentumY -1 player.setAnimationRow 2 call thrust = "s",arrowDown,numberPad2,digitalDown player.addMomentumY 1 player.setAnimationRow 2 call thrust endInputMap jump mainLoop :thrust if thrustSound.stopped thrustSound.play else thrustSound.sustain endIf return :exitGame stopSounds clear writeCentered "Thanks for Playing"
... to be continued
Reply With Quote
Bookmarks