I considered posting this in the 'projects' section, but I don't think this is far enough along code-wise for that yet, and I need more input before I
There is a question here, so bear with me as I explain the situation (and get what I have done so far down as text for my own reference)
It's an idea that kind of hit me while puttering in my garage that's quickly turning into a museum... Was playing with Applesoft basic on a IIe platinum and Extended Color Basic on a Coco... and it hit me that I started using these types of languages when I was 9 or 10... sure, I was already doing 1802 machine language before that, but really this is where I started learning to do anything remotely close to a 'real' program...
... where are these today? Where is todays "sit a ten year old down with big colorful 40x25 (or less) text display, with a simple per-line editor, and a simple/easy language that any pre-teen that can read should be able to grasp? While I don't think line numbered BASIC was ever the proper answer and was more imposed by the hardware limitations, I do think with some modernizations an interpreted language designed for children as a starting point BEFORE having to dive into real editors, complex file management, idiotic nonsense like 'make'... setting up a server or parser... Just something they click "start it" and they can use it... (and no, visual studio is not the answer).
I started looking for languages that fit the bill -- Even FreeBasic seems so obsessed with giving you modern compiler type controls and functionality it's lost sight of being ... a beginners language. For todays systems most of these languages barely provide the graphical and audio tools ROM BASIC back in the 8 bit days did! SURELY we can do better? I mean... what are we gonna do, sit a pre-teen down with Python? RUBY? I think not.
Also, I've been looking at the Raspberry Pi -- some folks are talking about BBC basic or an emulation of same, but really the limitations of that language are a waste on that level of hardware... if you're going to enhance the language for modern stuff, at that point why not build a new language that doesn't have 1970's/1980's scale limits?
The R-Pi has two video outs; HDMI and Composite. It's a $25-$35 device -- why not target the composite out as the primary 'middle ground' operating mode? A cheap ARM device with composite out could be a real learning tool for the underprivileged, the people who still dumpster dive for CRT's... Composite means 'real world' 320x240 is about the upper limit for useful video resolution, so the old DOS 40x25 text mode is probably the best target for it's native operating mode. They are touting it as for 'education', put a composite output on it, have a bargain basement price-point; but who is this really for?!? College level maybe, late high school at best; but they seem to be thinking strictly in terms of learning hardware for advanced users -- as evident by the hoops one has to jump through just to get Debian to boot on it, much less the convoluted setup they seem to expect people to use to program on it... did we mention the choices are Debian, Arch or Fedora with C as the main language? Same hardware could easily be re-tasked to a 'give the kid an old TV and let them "play"' with a simpler language.
I've already chosen the language I'm writing my language with, and the initial targets. I'm going with Free Pascal since so far as programming languages go Pascal is my first love. It also opens the door to easily targeting multiple platforms since FPC can target ARM, PPC and x86, under Linux, Windows or OSX... even has some rudimentary support
For libraries I'm sticking with SDL for mode setting, input handling and sound with OpenGL for video (just to make sprite rotating/transparency fast/easy).
As such I'm thinking my initial target specifications will be:
700mhz ARM11/1ghz x86
OpenGL capable video
Linux,Windows,OSX (OS must provide/support SDL)
(P.S. If anyone can get OpenGL/SDL working in FPC under Lion, I'd love to hear how!)
So far all I've got coded is the expression tokenizer, floating point expression evaluator and math functions, and just starting in on variables -- which is where the question (I'll get to it, I promise) comes into play. I'm still VERY open on the syntax and procedure names as I'm kind of making it up as I go along -- on purpose. I don't want to plan out an entire language specification and then realize I've shoe-horned bad functionality into it.
At the same time I'm thinking about the things that I'd have killed to have back then, so I'm putting together a list of things that this new language should or shouldn't have.
line numbers -- no language other than basic does this, unless you're actually hand compiling ASM.
scope -- confuses nubes, let's get logic flow in their head, THEN move them to a language with scope
Return values -- since we don't have scope, let's not confuse them with the difference between a subroutine/procedure/function.
Userland objects -- way too complex for new programmers to handle. Hell, I know some people who've programmed for years and can't grasp them. (and keep coming to me for help - they need to take a time-out and spend some quality time with Object Pascal, Modula or Smalltalk)
Pointers -- again, complex concept, many mainstream languages seem to do just fine without them.
40x25 4:3 text mode default -- for composite video users
64x32 16:9/16:10 text mode option -- for HDMI users and other platforms. Keep the text big and friendly.
Built in editor -- duh.
Real time line-entry tokenizer -- when a line is finalized in the editor (you hit enter), compile it's token string, then paste the strings together when you 'run' it. This works great in many of the 'faster' basic interpreters.
Immediate mode -- I often scoff at this -- Apparently there are new names for this same concept like "IDLE" or "REPL" -- but the idea is to be able to type in a command and have it run immediately.
One assignment/procedure per line limit -- give the one line code obfuscators a kick in the junk. Oh noes, you might actually have clear concise legible code, not that.
Simple full word syntax -- NO abbreviations or vague/cryptic names -- duh.
Labels -- using them much like in assembler. People often seem 'scared' of assembly when a decent Assembler (aka anything non-AT&T syntax) is the simplest thing in the world. In this case a label is just a entry point you can 'goto' or 'gosub' -- though I'm planning on calling it 'jump' and 'call'... just like in ASM... because those are really good words for it. CALL means it will be coming back, JUMP means go there without plans of a return. This will keep the concepts of loops and subroutines simple.
System Objects -- things like sprites, audio files, etc; give them methods and properties. This will let the programmer get used to the idea of calling methods or properties, without the headache of them learning how to make their own. Baby steps; basically the same thing mySQLi or PDO can provide in PHP for getting people into objects without actually getting 'into' objects.
Sprite Engine -- on top of the normal old school plot, line, etc, I'm thinking give them a full openGL accellerated (where available) sprite engine. I'm talking a tile editor, tile management tools, the ability to load sprites or animations onto a variable of type 'sprite' with ease... collision detection, crude physics like gravity and momentum, etc... Get as much of the 'hard' stuff of graphics out of the way so all you'd have to do as a programmer is handle user input and AI logic.
SoftSynth -- the old funky 8 bit synthesizers have always had a soft spot with developers, but I'm thinking more along the lines of a multi-option synth -- wavetable, multi-waveform additive, etc... Give it it's own simple piano roll type format and possibly it's own song editor... you want to let kids compose music today, whaddayagonna do? Hand them a copy of Sonar? Reaper? PLEASE. Again, I know adults who can't figure those out. (and keep coming to me for help)
keydown status -- inkey$ sucked, readchar sucks, input really sucks when you're writing a game. That's what kids will WANT to do -- write games, lets give them the proper tools for handling input.
In any case, there are a few concepts I'm still on the fence on that I've gotten as suggestions; I'm interested in feedback on these in particular (though feel free to weigh in on the concepts so far).
Typecasting -- Should I or should I take a page from PHP on this one? Personally I LIKE strict typecasting on everything -- I was thinking originally on using tokens to indicate type... A$ is a string, A# is a integer, A% is a float... Would this be too complex? Confusing since they could have the same names? Is explaining runtime assignment errors or "why is this returning zero" going to be harder than explaining needing different types.
As it is I'm scratching the idea of even having a difference between integers and floats; all numeric variables are going to be 64 bit "Double"... I MAY consider just saying "oh well" and using the 80 bit "extended" type, but that's probably overkill.
So... Should I scrap my plans to have strict typecasting?
resolution neutral coordinate system -- the age of pixels is coming to a close; so while I'm thinking 320x200 as the main target, I'm also thinking a vector format for higher resolutions that doesn't care what the render target is. Still hammering this idea out, it's on the 'it would be nice, but not necessary' list.
Of course, the one part I'm REALLY not looking forward to is adding better syntax error detection (right now the tokenizer just blindly compiles whatever you type in, and the expression parser just blindly tries to run it)... but it's still coming along nicely for a project I've been working on maybe 30 minutes a day the past week.
Any ideas, opinions, etc on the project would be appreciated. Once I get it to where you can type in an actual program and have it run I'll probably put together a site for it and toss up a kickstarter page to get some revenue attached to it.
Though I'm really not into this for profit (though justifying my time would be nice), I just want to give kids today a modernized version of the tools I learned on as a pre-teen. The ones that opened the door to me putting on the big boy pants and writing real software for business before I was even out of high school.
... and at the same time dodge 'adult intervention' in the learning process, which can often be a total killjoy. I'm aiming for something that a grade-schooler (I figure third or fourth grade-up) can sit down with a book akin to the old TRS-80 Color Computer Basic manual (one of the BEST for learning programming as a child) and without any assistance learn to write a simple game in under an hour.
Side note about that image -- hey look folks, ACTUAL aside's!
It's not a unrealistic goal - those of us who grew up in the Vic-20, C-64, Atari 400/800, Apple II and TRS-80 era know it isn't.
So, opinions, ideas? Am I wishing for a time that's long past? Was I just a weird kid some 34 years ago? Let's hear it!
P.S. Sorry for long post, but this is also a 'status update' of sorts.