deathshadow
Posts: 7
Joined: Sun Apr 15, 2012 7:17 pm
Contact: Website

Re: Gumberoo - making a new Learning Language

Sun Apr 15, 2012 9:33 pm

Posting this across several forums... Wasn't certain if here or "educational" would be more appropriate, but given my opinion of the state of "education"...

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 a math teacher, now studying up for her masters 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... though I will have 'handles'; more on that later.

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: 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 to Start" writeCentered "or 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"
Very rough example of what I have in mind for language syntax and grammar.

In terms of status, I just finished off the expression tokenizer and evaluator. I chose to start with that because it's IMHO one of the hardest bits to code. Was struggling with one little bug, but that was the tokenizer treating the open of a function as a separate entity from the opening opening parenthesis of a sub-expression. Doh.

I also have function calls implemented, which run quickly because the tokenizer is compiling to state-based lookups -- meaning when the interpreter gets to the token for a function, the next byte is an array index into the function list -- so I can call it thus:

functionList[currentData^]^(expression);

Where currentData^ is the current byte stored in the code, and expression is the function to evaluate what's inside the function call. (and all sub-expressions)

The expression engine is a simple three stage expression/factor/value system... you call expression, it calls factor, which first calls value to, well... get a value to work with. Value checks to see if we're pulling an immediate, a function, or a variable, returns kind... factor then checks for a 'second stage' operator like multiply/divide/exponent, if present pulls a value and does it and loops to check for another second stage, if not it returns to expression which checks for first stage operations (addition/subtraction) and does those, looping through first stage operators, again calling factor for their values.

It's how I did it all those ages ago when I wrote a Clipper interpreter in DiBol (I should track down the code for that)... tried and true method. I think it's even how Prof. Wirth did it in his p-code interpreter. (as opposed to C with it's 17 stage nightmare)

Means a wee bit of nesting, but nothing FPC can't handle.

So the code is coming slowly. I'm working up a website for the project and hope to soon get that up live... but I've not really set up a time limit on getting this into the beta stage. I may release some binary demos before this goes beta, but for now I'm keeping the code private as, well... during development I don't work well with others. Once I have it to the point of text mode and input handling complete, I'll be opening up the code to the public.

I have had suggestions to make a Kickstarter page for it. I'd like to get something to show for actual working tokenizer (read "caching bytecode compiler" in 'modernspeak') and interpreter first.

Was also thinking on making the IDE web-aware, so kids could easily share their games online with others.

So... good idea, crazy idea, who cares? Any ideas/suggestions welcome... well -- apart from "oh just write a book about python" or "why don't you make a UML implementation", in which case bugger off! Dealt with that already in two different places, and to me that's a sign that said individuals don't get the concept.

Sorry for the long post... Wait, no I'm not; The TLDR crowd can kiss right off too!

P.S. This has to be the MOST annoying forum I've ever tried to use; between the editor that's flat out broken in Opera, the fat bloated slow javascript nonsense, the 'crappy little stripe' fixed width, absurdly undersized fixed metric fonts it's a miracle I was even able to make a post here.

deathshadow
Posts: 7
Joined: Sun Apr 15, 2012 7:17 pm
Contact: Website

Re: Gumberoo - making a new Learning Language

Sun Apr 15, 2012 9:34 pm

Wow, and code blocks are busted too, white-space stripping PRE. Thanks turdpress...

spurious
Posts: 343
Joined: Mon Nov 21, 2011 9:29 pm

Re: Gumberoo - making a new Learning Language

Sun Apr 15, 2012 9:40 pm

bullet points would be good.. can't be CBA reading all that!

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 5:41 am

Even BASIC programmers have realised that function calls are good, and subroutines aren"t. That"s only one area of wrong in your OP.

Making a language for teaching doesn"t mean making (yet another) language that"s deliberately brain-dead and useless for anything else.

Simon

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 3:42 pm

it's not hard to work out how to drive the editor here - it's not brilliant, but it is possible to enter code blocks and so on in it. Lighten up a bit!

However, what you're after is basically BASIC - with half the functionality of a modern BASIC left out.

Re-reading your post (which really reads like a rant now). No function return values? Even Dartmouth BASIC had DEF FN in 1964. Your expression engine sounds er, interesting... Try looking up Dijkstras Shunting Yard algorithm sometime. No looping, one pass through the input line and build the output RPN stack. Fast and efficient and allows you to specify any precedence order you like....

So you want no line numbers, but you want labels - well you need labels becuase you don't want line numbers but you want subroutines... So isn't a subroutine call to a line with a label just another way of calling a named subroutine/procedure?

I do wonder if you're inventing a solution to a problem that's not there - if you want "sprite" based stuff, look at scratch. If you want BASIC, Brandy is there and working (a Linux variant of BBC Basic) my own BASIC, RTB works just fine too (uses SDL, but is written in C, using your beloved GCC And limiting yourself to 320x200 when you can be adaptable. My BASIC will recognise the underlying screen resolutions and automatically pick one suitable, or you can override it. It's not hard (standard SDL) you want more sprites and control, just import the SDL libraries into Python/PyGame.

And if you want "ROM Basic" on the RPi.. Then "watch this space" as it were. I have a test system where by I can boot a Linux PC directly into my own BASIC (no X needed) and it really won't be hard to produce an SD image that will do just this on the RPi, however I'm in two minds about it. I'm thinking it might actually be better to login on the command-line (no X) then run RTB. Not sure yet.

Anyway.

Good luck with it and keep us informed with progress.

Gordon
--
Gordons projects: https://projects.drogon.net/

deathshadow
Posts: 7
Joined: Sun Apr 15, 2012 7:17 pm
Contact: Website

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 7:29 pm

GordonH said:


it's not hard to work out how to drive the editor here - it's not brilliant, but it is possible to enter code blocks and so on in it. Lighten up a bit!


In my browser of choice the script is broken so the only way to enter a response is with the HTML editor; the idiotic bloated wysiwyg garbage won't let me type a blasted thing; saw the other thread about phpBB coming soon; sad when that insecure accessibility train wreck would be a step up.

It's stuck in a uselessly narrow fixed width, with inaccessible font sizes making me dive for the zoom and still not getting enough width to have useful text; with the hoops I'm having to jump through just to make a normal post IMHO it's a miracle there are people posting here. This is probably my last attempt at posting here until it does get switched over.

GordonH said:


However, what you're after is basically BASIC - with half the functionality of a modern BASIC left out.


Because by the time you have a 'modern' BASIC I wouldn't give it to a ten year old.

GordonH said:


Re-reading your post (which really reads like a rant now). No function return values? Even Dartmouth BASIC had DEF FN in 1964.


Which didn't make real user functions, it just made aliases to expressions. There's a difference... and why you rarely if ever saw a real program that used def fn.

GordonH said:


Your expression engine sounds er, interesting... Try looking up Dijkstras Shunting Yard algorithm sometime. No looping, one pass through the input line and build the output RPN stack. Fast and efficient and allows you to specify any precedence order you like....


RPN always creeped me out -- I was looking at that last week though; Manually managing a stack and making TWO passes; one to turn it into RPN then one to perform the RPN, actually seems more complex than expression/factor/value... it also means it's NOT one pass and it IS looping -- TWICE.

You're the second person to mention it though -- I dismissed it originally, but I'll take the time to make a proper version of it to see if it's actually faster, or is just a waste of time; it looks to me like it manually manages the stack in the manner I'm using function calls to... and would use as many if not more calls. The only advantage I can see is doing the RPN conversion on the tokenizer side might speed up when it comes time to execute.

GordonH said:


So you want no line numbers, but you want labels - well you need labels becuase you don't want line numbers but you want subroutines... So isn't a subroutine call to a line with a label just another way of calling a named subroutine/procedure?


Yes, and doing so is closer to hardware (jump/call) than using normal procedures would.

GordonH said:


I do wonder if you're inventing a solution to a problem that's not there - if you want "sprite" based stuff, look at scratch.


That's one of the ones I looked at -- and again it's NOT something I'd consider using for education given it's train wreck of documentation, disastrously broken and useless website, and bizarre/oddball method of building programs.

GordonH said:


If you want BASIC, Brandy is there and working (a Linux variant of BBC Basic)


Which is bland, boring and has NOTHING to make it interesting for kids.

GordonH said:


my own BASIC, RTB works just fine too (uses SDL, but is written in C, using your beloved GCC


You have a link to that? Never heard of it and my google-fu failed me.

GordonH said:


And limiting yourself to 320x200 when you can be adaptable. My BASIC will recognise the underlying screen resolutions and automatically pick one suitable, or you can override it. It's not hard (standard SDL) you want more sprites and control, just import the SDL libraries into Python/PyGame.


Usually 'adaptable' doesn't adapt very well to low resolutions -- and would confuse the target audience as to "why does this look different across machines?"

GordonH said:


And if you want "ROM Basic" on the RPi.. Then "watch this space" as it were. I have a test system where by I can boot a Linux PC directly into my own BASIC (no X needed) and it really won't be hard to produce an SD image that will do just this on the RPi, however I'm in two minds about it. I'm thinking it might actually be better to login on the command-line (no X) then run RTB. Not sure yet.


Given my target audience having them even have to think about logging in or the command line may be self defeating... but we likely have two different audiences in mind. My primary target is pre-teens; the simplifications I'm making are based on what I remember of my experiences from 30 years ago, discussions with several people just starting in programming, and watching my neighbors child struggle in both math and physics... and trying to learn either Ruby or Python; I'm seeing first hand a child struggle with concepts that to be honest, aren't needed for them to write a program.

Well, that and nobody seems to know how to write easy to follow documentation anymore... or even provide documentation. Some of the projects you mentioned, Scratch in particular, were the inspiration for this in the same way Stryper was an inspiration for Metallica. It made them swear never to wear spandex on stage.

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 8:12 pm

deathshadow said:


GordonH said:


it's not hard to work out how to drive the editor here - it's not brilliant, but it is possible to enter code blocks and so on in it. Lighten up a bit!


In my browser of choice the script is broken so the only way to enter a response is with the HTML editor; the idiotic bloated wysiwyg garbage won't let me type a blasted thing; saw the other thread about phpBB coming soon; sad when that insecure accessibility train wreck would be a step up.

It's stuck in a uselessly narrow fixed width, with inaccessible font sizes making me dive for the zoom and still not getting enough width to have useful text; with the hoops I'm having to jump through just to make a normal post IMHO it's a miracle there are people posting here. This is probably my last attempt at posting here until it does get switched over.


Why even bother? you're whinging about phpBB, whinging about your browser. Is there anything you don't whinge about?

I'm not happy with this system either, but I make-do because it's all we have right now - unless you, me or someone else wants to come up with something better. Do you have the time or inclanation to so? I don't... And this is the world of web-based blogs, micto blogs, logs and documentation. It's not going away, so if your browser is struggling, then move to something else. Firefox is still OK for me.


GordonH said:


However, what you're after is basically BASIC - with half the functionality of a modern BASIC left out.


Because by the time you have a 'modern' BASIC I wouldn't give it to a ten year old.


You don't need to give all if it to them. Just teach them a little at a time. If they're keen they'll come back and ask for more.


GordonH said:


Re-reading your post (which really reads like a rant now). No function return values? Even Dartmouth BASIC had DEF FN in 1964.


Which didn't make real user functions, it just made aliases to expressions. There's a difference... and why you rarely if ever saw a real program that used def fn.


They're real enough. Useful too. And what does it matter what they are? Olde BASCI had one-line functions, modern ones have multi-like functions. Just like Pascal, C, etc. Most new ones support recursion too.


GordonH said:


Your expression engine sounds er, interesting... Try looking up Dijkstras Shunting Yard algorithm sometime. No looping, one pass through the input line and build the output RPN stack. Fast and efficient and allows you to specify any precedence order you like....


RPN always creeped me out -- I was looking at that last week though; Manually managing a stack and making TWO passes; one to turn it into RPN then one to perform the RPN, actually seems more complex than expression/factor/value... it also means it's NOT one pass and it IS looping -- TWICE.


OK, t's 2 processes but it doesn't have to be. You can evaluate right off the back of the shunting yard though - it spits out stuff right in RPN format, so you can evaluate it immediately rather than storing it on a stack.


You're the second person to mention it though -- I dismissed it originally, but I'll take the time to make a proper version of it to see if it's actually faster, or is just a waste of time; it looks to me like it manually manages the stack in the manner I'm using function calls to... and would use as many if not more calls. The only advantage I can see is doing the RPN conversion on the tokenizer side might speed up when it comes time to execute.


A proper version? There is only one version - the one Dijkstra wrote the year before I was born. Wikipedia has an excellent explanation of it's rules too. Utterly trivial to add in rule 1.5 to handle array indices too.


GordonH said:


So you want no line numbers, but you want labels - well you need labels becuase you don't want line numbers but you want subroutines... So isn't a subroutine call to a line with a label just another way of calling a named subroutine/procedure?


Yes, and doing so is closer to hardware (jump/call) than using normal procedures would.


Young people won't appreciate hardware jumps - not initally anyway. Remember this is the "smartphone" generation we're dealing with.


GordonH said:


I do wonder if you're inventing a solution to a problem that's not there - if you want "sprite" based stuff, look at scratch.


That's one of the ones I looked at -- and again it's NOT something I'd consider using for education given it's train wreck of documentation, disastrously broken and useless website, and bizarre/oddball method of building programs.


Train wreck - there's that phrase again. If you're not happy with it, then do something about it - OK, you are, you're writing a new language, but maybe start on the documentation.


GordonH said:


If you want BASIC, Brandy is there and working (a Linux variant of BBC Basic)


Which is bland, boring and has NOTHING to make it interesting for kids.


It was fantastic 30 years ago though. It's still there and there is a commercaial version still selling for Windows, so someone somewhere thinks its OK.


GordonH said:


my own BASIC, RTB works just fine too (uses SDL, but is written in C, using your beloved GCC


You have a link to that? Never heard of it and my google-fu failed me.


I'm not surprised googles not got anything yet - mostly becuse I've not put much online about it yet. There's some stuff if you click the link in my signature at the bottom, but also look at: http://unicorn.drogon.net/rtb/ there's some pre-release stuff there including Linux x86 and ARM executables...


GordonH said:


And limiting yourself to 320x200 when you can be adaptable. My BASIC will recognise the underlying screen resolutions and automatically pick one suitable, or you can override it. It's not hard (standard SDL) you want more sprites and control, just import the SDL libraries into Python/PyGame.


Usually 'adaptable' doesn't adapt very well to low resolutions -- and would confuse the target audience as to "why does this look different across machines?"


So are you going to scale 320x200 to 1920x1080? That's going to look somewhat... Chunky...




GordonH said:


And if you want "ROM Basic" on the RPi.. Then "watch this space" as it were. I have a test system where by I can boot a Linux PC directly into my own BASIC (no X needed) and it really won't be hard to produce an SD image that will do just this on the RPi, however I'm in two minds about it. I'm thinking it might actually be better to login on the command-line (no X) then run RTB. Not sure yet.


Given my target audience having them even have to think about logging in or the command line may be self defeating... but we likely have two different audiences in mind. My primary target is pre-teens; the simplifications I'm making are based on what I remember of my experiences from 30 years ago, discussions with several people just starting in programming, and watching my neighbors child struggle in both math and physics... and trying to learn either Ruby or Python; I'm seeing first hand a child struggle with concepts that to be honest, aren't needed for them to write a program.

Well, that and nobody seems to know how to write easy to follow documentation anymore... or even provide documentation. Some of the projects you mentioned, Scratch in particular, were the inspiration for this in the same way Stryper was an inspiration for Metallica. It made them swear never to wear spandex on stage.


Scratch, Python, etc. are all open-source. Im' sure that if you offered to help them (re) write their documenation they might welcome you with open arms..

Gordon
--
Gordons projects: https://projects.drogon.net/

deathshadow
Posts: 7
Joined: Sun Apr 15, 2012 7:17 pm
Contact: Website

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 9:28 pm

GordonH said:


Why even bother? you're whinging about phpBB, whinging about your browser. Is there anything you don't whinge about?


What's a whinge? Is that like a wind resistant hinge or something? I mean I know I'm a total rouge, constantly honing in on things that for all intensive purposes does little to rain in the problems I see all around. Oh the huge manatee.

That's a joke. I'm willing to bet nobody gets it… Which would only further prove my statements about the state of education.

GordonH said:


Do you have the time or inclanation to so?


Would NOT be the first time!

GordonH said:


You don't need to give all if it to them. Just teach them a little at a time. If they're keen they'll come back and ask for more.


At which point they can 'graduate' to a real language.

A lot of people think about beginner programming languages as being like a bike with training wheels. As you give them more functionality you take the wheels off. I consider this to be a mistake at the elementary level because it often means having concepts in place to achieve even the simplest of things that they just aren't going to get.

You don't typically give a toddler or even kindergartner a real bicycle! You give them a tricycle or a big wheel; you don't see a lot of adults, much less teenagers, riding big wheels down the street.

I'm thinking Duplo, not Lego Technix; I'm thinking Erector Set, not arc welder. I'm thinking alphabet blocks, not Merriam-Websters. They get to the point where they need or want more, they can put on the big boy pants.

Oddly, that seems to be the part I'm having the hardest time conveying. Once I get a proper website up for this project (given that 6 years ago websites were my bread and butter and I still have around six clients I maintain despite being retired — that's the easy part) I'm hoping people will grasp that... break it down into multiple subpages, dumb it down for the herpaderp masses, instead of just dumping it all in one long post that kneejerks the ignorant into "AAAH, WALL OF TEXT!" mode.

GordonH said:


They're real enough. Useful too. And what does it matter what they are? Olde BASCI had one-line functions, modern ones have multi-like functions. Just like Pascal, C, etc. Most new ones support recursion too.

RE:def fn and functions


I did argue with myself about it, but I keep going back to my target audience and thinking back to when I was learning BASIC and PASCAL — DEF FN seemed completely pointless and confusing. The concepts of userland functions compared to a gosub I really didn't grasp until around age 13 or 14… when I was able to grasp Machine language well before that. The difference is splitting hairs once you hit a certain point in your learning, but it's an advanced concept that really doesn't belong and serves little practical purpose — IMHO — in a learning language for pre-teens.

GordonH said:


OK, t's 2 processes but it doesn't have to be. You can evaluate right off the back of the shunting yard though – it spits out stuff right in RPN format, so you can evaluate it immediately rather than storing it on a stack.


Uhm.. if you don't build the full RPN stack first, you won't have a proper execution order. All expression engines tend to have that limitation. Either that or you end up subbing out the evaluations in which case you've turned it back into expression/factor/value!

GordonH said:


A proper version?


As in to port it to the same language accepting the same style input and tokenization so I can do a fair side-by-side comparison; Either that or I convert mine to C… The latter not exactly really high up my to-do list.

GordonH said:


Young people won't appreciate hardware jumps – not initally anyway. Remember this is the "smartphone" generation we're dealing with.


Oddly that's WHY I'm going that route — it's a simpler concept… though I've repeatedly found I've got an entirely different definition of "simpler" than my fellow programmers… It's like people want programming to be difficult; See C which IMHO is needlessly cryptic and annoyingly complex… compared to machine language! If you're going to make a high level language, Lands sake make a high level language! (again, Wirth fan)

GordonH said:


Train wreck – there's that phrase again. If you're not happy with it, then do something about it – OK, you are, you're writing a new language, but maybe start on the documentation.


Engineering 101. Specification, implementation, documentation. It's a lot simpler and clearer to document something once you have the specification implemented. Otherwise you'll waste as much time editing and revising the documentation as you do implementing it.

GordonH said:


It was fantastic 30 years ago though. It's still there and there is a commercaial version still selling for Windows, so someone somewhere thinks its OK.


100% true; the same could be said about AppleSoft Basic, C=64 Basic, and the dozens of others that came before it. But without expanding it's capabilities, removing things that are outdated and/or pointless, and giving a consistent cross platform experience that actually does fun stuff by modern standards. It's dated, it could use a refresh.

Which is what your Basic seems to be out to do.

GordonH said:


There's some stuff if you click the link in my signature


You have a signature? Aha, my zooming in 150% to make it so I could actually read the text (we need to track down the people who still advocate declaring text on websites in pixels and execute the lot) was making the broken markup hide it.

Looks good as projects go… could use some REAL graphics primitives though since that's the first thing I'd expect kids to give for. You might also want to look at "getting started with extended color basic" for the Coco though; your documentation is a bit dry and could lead to premature glazing.

GordonH said:


So are you going to scale 320x200 to 1920x1080? That's going to look somewhat… Chunky…


HEY! I resemble that comment

Jokes aside, there's nothing 'wrong' with chunky per-se… though that could be my having released a 160x100 16 color game for DOS last year… Skews my perspective just a bit. Besides, the original street fighter or out-run looks just fine in MAME.

Also remember, I'm thinking Duplo. I often think we're TOO obsessed with resolution and detail, and in the process have lost much of the charm and simplicity… and more than anything I'm aiming for simplicity. Telling ten year olds to edit twenty separate 512x512 truecolor sprites in Photoshop or the GIMP and save it as a PNG really isn't on the agenda.

GordonH said:


Scratch, Python, etc. are all open-source. Im' sure that if you offered to help them (re) write their documenation they might welcome you with open arms..


True, but I don't entirely agree with a lot of the choices made in those languages; most certainly not given my target audience and motivation.

It's funny because I should like Python, I really should! Strict formatting rules are something I've been in favor of for a long time… it just rubs me the wrong way with it's noodle-doodle handling of 'classes', lack of visible closing elements apart from whitespace, and host of other things that IMHO just mean sloppy code. The minuscule stock function library does little to endear it either.

Could be worse though, we could be talking Rust. The programming language for people who thought C was a bit too verbose and clear… which is akin to saying the Puritans who founded Boston in 1630 did so because the CoE was a little too warm and fuzzy for their tastes.

Heh, starting to get a handle on managing all my posts using raw HTML.

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 9:33 pm

Nice to see you"ve got people talking - I can see value in enthusiasts banging their heads together to meld the best bits of all languages into a new language and then sprinkling a little bit of inovation on top – if anyone else has the time and inclination to organise such a bandwagon I would be interested in jumping on it.

I imagine such a project could initially have value as a hypothetical standard rather than a practically usable entity – until it reaches a level of refinement that attracts boffins willing to make it a reality. It could be a constantly evolving standard which periodically throws off packaged real-world manifestations

I can see that the Pi has potential to provide a focal point for such an endeavour and that the language could evolve alongside the hardware sharing the goals of flexibility, accessibility and practicality.
Ostendo ignarus addo scientia.

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12414
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 10:02 pm

Well, I do agree that "Brandy basic", without any graphics support is brain-dead. If you want a kid to start programming things beyond "hello world" you should at least support drawing lines and such. Just having text only will bore the hell out of these kids.

You need colorful graphics, and hopefully sprites and such, and yes sound too, just like the original BEEB.

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 10:12 pm

deathshadow said:


GordonH said:


Why even bother? you"re whinging about phpBB, whinging about your browser. Is there anything you don"t whinge about?


What"s a whinge? Is that like a wind resistant hinge or something? I mean I know I"m a total rouge, constantly honing in on things that for all intensive purposes does little to rain in the problems I see all around. Oh the huge manatee.


We're an ocean apart - you're in New Hampshire, I'm in Devon, olde england. So your red (or a rogue? I know what a manatee is.


That"s a joke. I"m willing to bet nobody gets it… Which would only further prove my statements about the state of education.


Or the state of the countries we live in.



GordonH said:


Do you have the time or inclanation to so?


Would NOT be the first time!

GordonH said:


You don"t need to give all if it to them. Just teach them a little at a time. If they"re keen they"ll come back and ask for more.


At which point they can "graduate" to a real language.


Exactly. Or if they don't have the knack, learn cooking. (I do both)


A lot of people think about beginner programming languages as being like a bike with training wheels. As you give them more functionality you take the wheels off. I consider this to be a mistake at the elementary level because it often means having concepts in place to achieve even the simplest of things that they just aren"t going to get.


Or give them more of the same until tehy're comfortable to move off on their own...


You don"t typically give a toddler or even kindergartner a real bicycle! You give them a tricycle or a big wheel; you don"t see a lot of adults, much less teenagers, riding big wheels down the street.

I"m thinking Duplo, not Lego Technix; I"m thinking Erector Set, not arc welder. I"m thinking alphabet blocks, not Merriam-Websters. They get to the point where they need or want more, they can put on the big boy pants.

GordonH said:


They"re real enough. Useful too. And what does it matter what they are? Olde BASCI had one-line functions, modern ones have multi-like functions. Just like Pascal, C, etc. Most new ones support recursion too.

RE:def fn and functions


I did argue with myself about it, but I keep going back to my target audience and thinking back to when I was learning BASIC and PASCAL — DEF FN seemed completely pointless and confusing. The concepts of userland functions compared to a gosub I really didn"t grasp until around age 13 or 14… when I was able to grasp Machine language well before that. The difference is splitting hairs once you hit a certain point in your learning, but it"s an advanced concept that really doesn"t belong and serves little practical purpose — IMHO — in a learning language for pre-teens.


It's just a construct - it makes the parser a little easier and breaks programs up into chunks.. BBC Basic introduced (to me) DEF PROC - which seemend natural as BASICs I'd used previously already had DEF FN. I've carried this into my basic too.


GordonH said:


OK, t"s 2 processes but it doesn"t have to be. You can evaluate right off the back of the shunting yard though – it spits out stuff right in RPN format, so you can evaluate it immediately rather than storing it on a stack.


Uhm.. if you don"t build the full RPN stack first, you won"t have a proper execution order. All expression engines tend to have that limitation. Either that or you end up subbing out the evaluations in which case you"ve turned it back into expression/factor/value!


Go read up on shunting yard. What it spits out is RPN and you can start to evaluate that as soon as you have enough tokens/words/numbers to evaluate. I don't in my implementation as I have a notion that one day I'll cache it to save re-running the shunter and possible save a bit of time, but right now I'm looking at some turtle graphics running at 200 frames a second in my BASIC on a 2GHz processor and thinking it's fast enough...


GordonH said:


A proper version?


As in to port it to the same language accepting the same style input and tokenization so I can do a fair side-by-side comparison; Either that or I convert mine to C… The latter not exactly really high up my to-do list.

GordonH said:


It was fantastic 30 years ago though. It"s still there and there is a commercaial version still selling for Windows, so someone somewhere thinks its OK.


100% true; the same could be said about AppleSoft Basic, C=64 Basic, and the dozens of others that came before it. But without expanding it"s capabilities, removing things that are outdated and/or pointless, and giving a consistent cross platform experience that actually does fun stuff by modern standards. It"s dated, it could use a refresh.


Do something completely new then!


Which is what your Basic seems to be out to do.


My basic set out to fill a desire to run a program I wrote some 30+ years ago on the Apple II. It was a pure nostalgia project. At the end of every year I set myself a little project and last years was to write my own BASIC to re-run those programs. Now, I really like my basic, it's grown on me and I'm finding myself writing little programs in it just for fun, so I'm going to share it with others.


GordonH said:


There"s some stuff if you click the link in my signature


You have a signature? Aha, my zooming in 150% to make it so I could actually read the text (we need to track down the people who still advocate declaring text on websites in pixels and execute the lot) was making the broken markup hide it.


Maybe you need glasses if you keep having to zoom to 150%


Looks good as projects go… could use some REAL graphics primitives though since that"s the first thing I"d expect kids to give for. You might also want to look at "getting started with extended color basic" for the Coco though; your documentation is a bit dry and could lead to premature glazing.


So what's a real graphics primitive look like?


GordonH said:


So are you going to scale 320x200 to 1920x1080? That"s going to look somewhat… Chunky…


HEY! I resemble that comment

Jokes aside, there"s nothing "wrong" with chunky per-se… though that could be my having released a 160x100 16 color game for DOS last year… Skews my perspective just a bit. Besides, the original street fighter or out-run looks just fine in MAME.

Also remember, I"m thinking Duplo. I often think we"re TOO obsessed with resolution and detail, and in the process have lost much of the charm and simplicity… and more than anything I"m aiming for simplicity. Telling ten year olds to edit twenty separate 512x512 truecolor sprites in Photoshop or the GIMP and save it as a PNG really isn"t on the agenda.


I do have "sprites" on the agenda for RTB and sound when I can be bothered. The sprite editor will be written in RTB. Sound I was going to emulate the Beeb to an extent.


GordonH said:


Scratch, Python, etc. are all open-source. Im" sure that if you offered to help them (re) write their documenation they might welcome you with open arms..


True, but I don"t entirely agree with a lot of the choices made in those languages; most certainly not given my target audience and motivation.

It"s funny because I should like Python, I really should! Strict formatting rules are something I"ve been in favor of for a long time… it just rubs me the wrong way with it"s noodle-doodle handling of "classes", lack of visible closing elements apart from whitespace, and host of other things that IMHO just mean sloppy code. The minuscule stock function library does little to endear it either.


Python has it's followers - like the folks who designed the RPi and who are putting toether a lot of educational material for it - all written in Python AIUI...


Heh, starting to get a handle on managing all my posts using raw HTML.


The buttons at the top seem OK for me. The only time (here) I dive into HTML is when inserting code - e.g.

HGR
NUMFORMAT (5, 1)
PENDOWN
oa = 0
CYCLE
FOR ang = 0 TO 360 STEP 0.1 CYCLE
old = TIME
PROC spir(Black, oa)
PROC spir(Purple, ang)
now = TIME
HVTAB (0, 0)
PRINT ang; " "; now - old; " "; 1000 / (now - old);
UPDATE
oa = ang
REPEAT
REPEAT
END
//
DEF PROC spir(col, ang)
LOCAL i
COLOUR = col
PENUP
MOVETO (GWIDTH / 2, GHEIGHT / 2)
TANGLE = 0
PENDOWN
FOR i = 2 TO GWIDTH CYCLE
MOVE (i)
RIGHT (ang)
REPEAT
ENDPROC
--
Gordons projects: https://projects.drogon.net/

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 10:13 pm

@mahjongg

pretty lights – bleep bleep – you need that to get kids hooked but once the thrill has worn off you need to give them something they can grow with. The pi costs £30 so kids won"t think twice about binning it if they out grow it
Ostendo ignarus addo scientia.

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 10:17 pm

mahjongg said:


Well, I do agree that "Brandy basic", without any graphics support is brain-dead. If you want a kid to start programming things beyond "hello world" you should at least support drawing lines and such. Just having text only will bore the hell out of these kids.

You need colorful graphics, and hopefully sprites and such, and yes sound too, just like the original BEEB.



I thought Brandy did suport graphics, but although I've run it up to compare a few things I've not actually tied it's graphics!

However:



I've got a Beeb on my workbench - I'll be re-remembering the envelope and sound commands soon!

Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12414
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 10:25 pm

deathshadow said:


Posting this across several forums... Wasn't certain if here or "educational" would be more appropriate, but given my opinion of the state of "education"........Sorry for the long post... Wait, no I'm not; The TLDR crowd can kiss right off too!

P.S. This has to be the MOST annoying forum I've ever tried to use; between the editor that's flat out broken in Opera, the fat bloated slow javascript nonsense, the 'crappy little stripe' fixed width, absurdly undersized fixed metric fonts it's a miracle I was even able to make a post here.


Just Wow!

I do not understand why there are so many "academic objections" post, your reasoning and decisions seem sound to me.

To get a kid to learn programming, it foremost has be be FUN! and it looks this will be fun, and also SIMPLE (the second most important condition). Not as simple as LOGO though where nothing much more was possible after you had drawn a dragon (the mathematical recursive figure) . You need color, you need movement, and you need sound, all the things that attract. I also think its great, not running under any GUI, but simply booting right into the interpreter, just like in olden days.

basing the video on Composite resolutions, also seems a good idea, it makes things more synoptic and manageable, and opens the PI up for working well with older TV's.

I could say much more, but for now I only want to say. Thanks!

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12414
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 10:36 pm

GordonH said:


I thought Brandy did suport graphics, but although I've run it up to compare a few things I've not actually tied it's graphics!


Ah, okay, it seems that Brandy does indeed do elementary graphics, like drawing lines and boxes and such. I stand corrected.

Because Brandy is multi-platform it does seem to support only the lowest common denominator of all these platforms. I wonder if Brandy basic, for example, supports sprites and such.

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12414
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 10:40 pm

pygmy_giant said:


@mahjongg

pretty lights – bleep bleep – you need that to get kids hooked but once the thrill has worn off you need to give them something they can grow with. The pi costs £30 so kids won"t think twice about binning it if they out grow it


Well, once they are hooked they naturally will want to progress to something more advanced, like Python, or C.

But "getting them hooked" is exactly the point.

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12414
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: Gumberoo - making a new Learning Language

Mon Apr 16, 2012 10:45 pm

pygmy_giant said:


@mahjongg

pretty lights – bleep bleep – you need that to get kids hooked but once the thrill has worn off you need to give them something they can grow with. The pi costs £30 so kids won"t think twice about binning it if they out grow it


Well, once they are hooked they naturally will want to progress to something more advanced, like Python, or C.

But "getting them hooked" is exactly the point.

Progressing to something more advanced doesn't need to involve "chucking out the Raspi" though.

By the way, I agree that this forum's editor is a bit shoddy, just try copy and paste and you will see an example.

And the double posting is another example.

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: Gumberoo - making a new Learning Language

Tue Apr 17, 2012 11:16 am

Perhaps - better if the language they start with turns into a lifelong tool rather than just a stepping stone - learning another language could be a barrier to some.
I am hoping the Pi will get me back into programming but don"t want the hastle of learnig python if it is not comprehensive/fast enough and I feel outdated with C++.
C++ is scary for beginners and although I haven"t tried it some people say python is limited - is that unfair?
Perhaps there are too many languages already and the last thing we need is another to confuse people and friendly community support and good libraries for the languages we already have is whats needed.
Ostendo ignarus addo scientia.

deathshadow
Posts: 7
Joined: Sun Apr 15, 2012 7:17 pm
Contact: Website

Re: Gumberoo - making a new Learning Language

Tue Apr 17, 2012 10:44 pm

pygmy_giant said:


I am hoping the Pi will get me back into programming but don"t want the hastle of learnig python if it is not comprehensive/fast enough and I feel outdated with C++.


You might want to give Free Pascal a look. while I've not got a real Pi yet to test on, in QEMU with the Pi Debian image it works just fine.

It's what I'm writing this project with for a number of reasons; clean syntax language, all the functionality I could ever want, and it comes 'out of the box' with SDL and OpenGL bindings that 'just work' in Linux or Windows… and it compiles to native code; as opposed to python which compiles to VM…

…and for all the talk about "Virtual Machines" the majority of them are just over-glorified bytecode interpreters. If they weren't, they wouldn't be parsing bytecode, they'd just be letting machine language run. The BEST of them are JIT compilers or have been lucky enough (like Java on the Cortex A7 and higher with Jazelle) to have many of it's operations turned into real cpu codes, the worst of them are overglorified interpreters with a fancy coat of paint!

From what I've seen, Python and PHP fall into the latter category

My tokenizer compiles to state based bytecode – I'm still calling my interpreter an interpreter, not a "virtual machine"…

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12414
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: Gumberoo - making a new Learning Language

Tue Apr 17, 2012 11:30 pm


pygmy_giant said:

Perhaps - better if the language they start with turns into a lifelong tool rather than just a stepping stone - learning another language could be a barrier to some.


Wow, you sound like (my countryman) Dijkstra, who said something like "learning BASIC will spoil someone's programming abilities forever". But then there wasn't a programming language he did not have negative comments about!

Really. Being able to do any kind of programming creates a "mindset", and when you progress you will notice that all programming languages have very much in common.

IMHO reaching this "mindset" is more important than the actual language you are programming with. I started with hand assembling 6502 assembly language, but even that learned me many concepts that I found back in higher languages.

What should be a very important lession is that programming can be FUN!

That was what made the BBC computer, (and the spectrum, MSX etc) such an important first encounter with computers. It was simply fun to be creative with them.




deathshadow
Posts: 7
Joined: Sun Apr 15, 2012 7:17 pm
Contact: Website

Re: Gumberoo - making a new Learning Language

Wed Apr 18, 2012 1:26 am

mahjongg said:


That was what made the BBC computer, (and the spectrum, MSX etc) such an important first encounter with computers. It was simply fun to be creative with them.


Could also be why I have a somewhat different perspective on this — as a Yank I"ve never even SEEN a BBC Micro in person, and the only Sinclair I ever had was a zed-ex 80. (which I did give the ROM upgrade to bring it up to a 81)…

Or for those of us on this side of the pond, it"s called a Timex-Sinclair 1000… which to be frank was a rinky toy even compared to a Trash-80 model 1 with level one BASIC.

What you said about mindset is my take on it too… To be honest I often laugh at a lot of "languages" even having separate names; PHP and Javascript come to mind — since in the simplest of terms they"re interpreted C with a slap of paint over them... and yet to people just starting out they seem to think they're all so different from each-other. I've even had people argue that they aren't anything alike... serious whiskey tango foxtrot territory.

Or as one of my instructors told me in the service, "A pilot is more than a AFSC –  it"s all about attitude!" The best programmers I"ve ever known were all prima donna"s,  with attitude to spare. The easily intimidated, the unwilling to change or to force change on others — well, they might be better off taking up knitting.

Since as George Bernard Shaw said many times better than I ever could:

The reasonable man adapts himself to the world. The unreasonable one persists in adapting the world to himself — therein all progress depends on the unreasonable man.


User avatar
nick.mccloud
Posts: 804
Joined: Sat Feb 04, 2012 4:18 pm

Re: Gumberoo - making a new Learning Language

Wed Apr 18, 2012 8:23 am

deathshadow said:


The reasonable man adapts himself to the world. The unreasonable one persists in adapting the world to himself — therein all progress depends on the unreasonable man.


Very true - and more often than not the unreasonable man has to go and get on with his project and not waste time trying to convert everyone to his way of thinking until he has a solution.

Imagine if Edison ran round telling everyone to wire up their houses and ditch gas lamps BEFORE he'd invented the light bulb?

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Gumberoo - making a new Learning Language

Wed Apr 18, 2012 8:56 am

deathshadow said:


mahjongg said:


That was what made the BBC computer, (and the spectrum, MSX etc) such an important first encounter with computers. It was simply fun to be creative with them.


Could also be why I have a somewhat different perspective on this — as a Yank I"ve never even SEEN a BBC Micro in person, and the only Sinclair I ever had was a zed-ex 80. (which I did give the ROM upgrade to bring it up to a 81)…

Or for those of us on this side of the pond, it"s called a Timex-Sinclair 1000… which to be frank was a rinky toy even compared to a Trash-80 model 1 with level one BASIC.


The history and usage of these old system is somewhat intersting (well to me, anyway!) I never really was into the Sinclair kit, having started on the Apple II, then BBC Micro at that level. I was part of the team to evaluate micros for schools in the late 1970's (a few years before the Beeb was released) and we had the Apple II, PET and TRS80 to choose from - The Apple won hands down because it was colour and had high resolution graphics. the Beeb a few years later was everything the Apple wasn't -  promoted by the BBC, a bit faster, better graphics and sound although (curiously) slightly less RAM (32KB vs. 48KB) But thats the difference a few years made then.

The ZX series made excellent home computers though - mostly because they were affordable. The Apple/PET/TRS80 weren't. Then Beeb, when it arrived was - but only just. It was probably price alone that really made the difference. That's (hopefully!) what will make the difference with the RPi. It's very affordable and for the price very hard to beat!

Anyway, have you some examples of your Gumberoo code so we can see what it looks like yet? When I was developing my BASIC, I wrote lots of little programs even before the interperter was finished - although most BASICs are fairly similar anyway, it was good to have something to work to.

Gordon
--
Gordons projects: https://projects.drogon.net/

Joefish
Posts: 95
Joined: Wed Jan 25, 2012 10:31 am

Re: Gumberoo - making a new Learning Language

Wed Apr 18, 2012 11:46 am

It's easy to say that cheap home computers with BASIC built-in led to a generation of programmers, but it skips over an important point which was that BASIC was fairly limited, so many of those who tried it then determined to learn the assembly language of the native processor.

Starting with a simple language, then transferring those skills and expanding them in another language and/or environment is what makes a good programmer.  Not desperately clinging to one language no matter what.  That's the code-monkey to middle-manager career path, and our college system can churn out more than enough of those.

I'm not sure that we need another beginner's language exactly, but if someone wants to write their own they shouldn't let peer pressure disuade them from having a go.  But then again they shouldn't expect people to take it too seriously until it can be shown to work.

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Gumberoo - making a new Learning Language

Wed Apr 18, 2012 11:52 am

Joefish said:


It's easy say that cheap home computers with BASIC built-in led to a generation of programmers, but it skips over an important point which was that BASIC was fairly limited, so many of those who tried it then determined to learn the assembly language of the native processor.


Which is something I've been saying for a long time - those who are keen won't let BASIC stop them learning more - getting people interested in the first place is the issue at hand.

It's not that difficult to make a BASIC that looks like a "higher" level language (my BASIC has switch statements and associative arrays FWIW), but getting newbies to go "wow" at their first program, even if it just prints their name is hopefully the start.

Gordon
--
Gordons projects: https://projects.drogon.net/

Return to “Other projects”