No offence intended, but I think the two moderators are being a little hypocritical here.Was not the whole Arduino platform for which this forum is based on, built to SIMPLIFY the coding of AVR's?

I don't believe I am being hypocritical. I think the whole IDE does an absolutely great job of simplifying coding for AVRs. With an easy-to-use interface you can be programming without Make files, complex linking, and needing to know a lot of detail.

Let me tell you a story ...

A little while back (couple of years) I had a PICAXE board. That used Basic rather than C. It was even simpler than C, right?

My son and I got some blinking lights going. Fine. So far so good. It went something like this (from here ).

But anyway, back to the story ... Then we wanted to make a "morse code" player. We wanted to make some subroutines (that you called with "gosub") to play the beeps for each letter. Then we hit a snag.

We made a subroutine to play a dot. And one to play a dash. And then one for each letter (eg. gosub dot, gosub dash, gosub dot, etc.)

There is a limit on PICAXE of the total number of gosubs you can have in a program.

http://www.picaxe.com/BASIC-Commands/Program-Flow-Control/gosub/

In the case of our part (the PICAXE 08M) it was:

Quote

All 'M' parts (obsolete) number:15 1 nested:4

That is, you could have a maximum of 15 gosub statements in the entire program! Whether or not they were nested (if you nest them you can only nest 4 deep).

That's a pretty amazing limitation. It means you can use them for blinking lights and doing simple stuff, but when you want to do something semi-serious you can't - not easily. So, suddenly it is more complex. Because you are working around limitations in the "simpler" system.

Please post technical questions on the forum, not by personal message. Thanks!

I understand where you're coming from, i started off programming in GFA BASIC - an old german written interpreter in BASIC ,i then graduated to Pascal (Object Pascal/Delphi) where I lived for a long time..

but...

Sometimes you have to accept 1 language does not fit/do all you'll pick up the language in no time.

I understand where you're coming from, i started off programming in GFA BASIC - an old german written interpreter in BASIC ,i then graduated to Pascal (Object Pascal/Delphi) where I lived for a long time..

I also programmed using this and I consider GFA as my first decent structured basic. It was the first language I could use without the need of goto's and the ability to inline assembler code was very handy. I almost feel like digging my A4000 out of the cupboard and giving it a 'for old times sake' bootup.

I want to thank everyone for sharing their stories of their first language. That's really what this is about, to make that first experience easier and with the arduino also make it fun. Once they are hooked, have them migrate to a real language.

I'm wondering if anyone has a feature from their first language that they really liked or disliked, or if there is something about my language that you would like added or changed. This will be a slow process and I probably won't be able to please many people, but I would like to hear any and all requests so I can keep them in the back of my mind.

A couple things I can probably add right off the bat is "Else If" and nested "Ifs"

I know that goto is considered evil, but it is so easy to implement. I changed it to "jump" to avoid the negative connotations. At first I had a jump absolute and relative, but that was confusing so I added :Label and now the only jump is a jump to label. That's a little more self-documenting.

Added 7SegmentInit and 7SegmentValue keywords to language. This allows a user to associate a single 7segment display to 7 digital outputs and write values to the 7 segment display. I updated the github repository listed above. I also update the SevenSegment library found on this site as it had some issues.

I tested this out using my Free Open Source Arduino Simulator described here: http://arduino.cc/forum/index.php/topic,132710.0.html

Actually, I agree with everyone here. Paulware has a really good idea for bringing in the young to the blinking lights to music realm, as does bitlash. But, the need for a lower level mess with the bits and registers language is necessary to do some of the things we want to do from time to time.

And, I can't see anything wrong with all of them existing and being available to choose from.

CrossRoads has a really good point about encouraging new engineers. But being able to sequence the lights on Mom's Christmas tree could be a good starting point to learn about one wire control for next years outside trees. My experience has been (yours is certainly different), when a teenager has to learn about libraries, objects, inheritance, etc. before they can tell the first light to shut off and turn on the second, they loose interest and go grab the video game control.

And Nick is absolutely correct in that simple things the current IDE is pretty much as simple as basic, however when you step it up just a little, you get into controls with all their complexity and obtuse language standards that will scare the kids away pretty quickly. Just imagine how odd a parsing routine that takes a user's typed input and does something with it (other than a simple menu, play fair) would look to a 13 year old that can use a rocket launcher to blow away a classmate on his xbox.

I'm all for complexity and bitwise manipulation of data streams as well as sliding abstract blocks of functions around a screen.

I just had a conversation with someone Friday that brought this home again to me. This person was fairly far advanced in engineering, making his own pcbs, and soldering smd parts. But, language skill wise he was still at C level and had never made the transition to objects. So I guess the point is people are at all sorts of different skill levels. Trying to make something easier for them so that they can innovate I think is worthwhile.

And about objects, as a friend was going over inheritance today I thought of a game that children could play that in the background is really teaching how to think in terms of object programming.

The idea is to have a "tree" of object and have the children build the "tree" from static cards. For example Vehicles might be the base-class which is at the top of the tree, motorized and wind driven vehicles could be down a level, cars/boats/planes/motorcycles could be down another level....etc. The object of the game is the organize and create the tree correctly. But really you are teaching object-oriented design, and that pattern of thinking.