Rascal

No, qualified, though in that I can learn the whole language rather than a subset of the language. I am currently reading "The C++ Primer, 6th Ed" and "A Book on C" I like reading the Primer but I feel somehow that a lot of what I am reading simply isn't very applicable as it refers to C11 rather than C99. The Material in A Book on C... seems to presuppose that one has a basic knowledge of C and this makes many of the examples... Cryptic. Some I can read and understand fully and many might as well be ideograms for all I can get from them. in most cases the answers to my questions are to be found here but figuring out how to search for them is frequently a real challenge as there are many references to many things, many of which are not necessarily accurate or relevant i.e. for earlier versions of the IDE or simply "first attempts", It gets difficult at times to find good information. Sometimes I think I cry just to hear myself cry...

Doc

Why not just get a ChipKit and keep the same programming environment?

Yes, it may take a bit of work to port some unsupported libraries, but still less work than porting to an entire new language...

And at a price of $175 it seems over priced when compared to its competitors (Rasberry Pi, Beagleboard, etc...)

http://store.rascalmicro.com/products/rascal-beta-unit

Docedison:
My only real issue with the Arduino is learning the language...

Since you note in your profile that you are a retired electronics engineer, I'm not sure if what I am going to write will have much bearing, but it is what I would recommend to anyone getting into programming. It is a basic level of knowledge to keep in mind, especially if your intention is to become a professional software developer: Focus on the structure, not on the language.

What I mean by that, is that in virtually all modern (and not so modern) high-level programming languages you are likely to encounter, all utilize essentially the same concepts, and the same forms. This is mainly because (especially with more recent programming languages) they all have influenced one another. I would honestly surmise that the languages of the past which have mostly influenced languages of today, would be Fortran, C/C++, and Pascal.

All have basically the same control/branching structures. All have more or less the same forms of variable assignment structures. All have functional/procedural structures.

Of course, only C++ (discounting any more recent versions of Fortran and/or Pascal) has object-orientation. You can clearly see its influence, though, on other languages like Java, PHP, etc.

Languages like BASIC clearly have a flavor of Fortran about them (when I was a kid, translating Fortran code I found in books at the library over into BASIC for my home computer was something I enjoyed doing). I'm not sure where others like Python, Lua, and Perl fit in, but despite certain differences, they too have similarities with the legacy languages.

Once you understand the structures, the rest is just syntax. Think of it like the "romance languages" (Spanish, Italian, French): They all have a very similar structure, with the rest being syntax (it isn't quite the same, though, human languages being human and all, and subject to a much wider array of social, political, and other forces which don't exert themselves in the same way on computer languages, not to mention the age difference); if you learn one, you can (in theory) pick up the others much easier than, say - English or German.

That said, there are programming languages out there (but none you are likely to encounter or use) that will make you go "WTF?" - and some of them are based on interesting constructs meant to make them easier to utilize in certain scenarios or for certain purposes. Once you begin to appreciate what the world has settled on (mostly) for "standard programming structures", looking into these other languages can be an interesting diversion (like LISP, Prolog, Brainf*ck and Whitespace, etc)...

LOL, wanderson beat me with nearly the identical comments on RaspPi and $175 price.

Only thing I could add is if you want that internet control, the BitLash library could go a ways...

cr0sh:
I would honestly surmise that the languages of the past which have mostly influenced languages of today, would be Fortran, C/C++, and Pascal.

All have basically the same control/branching structures. All have more or less the same forms of variable assignment structures. All have functional/procedural structures.

I really don't think Fortran has had much influence on any language in the last 40 years. Indeed I think that more recent incarnations of Fortran have been more on the receiving end of such influence.

cr0sh:
Of course, only C++ (discounting any more recent versions of Fortran and/or Pascal) has object-orientation. You can clearly see its influence, though, on other languages like Java, PHP, etc.

C++ object orientation, like the additions for pascal like languages and presumably fortran like, are really add-ons. You can use OO methods, but you are not required to. Which is why Arduino code for the most part doesn't tend to use much of the OO functionaility.

cr0sh:
Languages like BASIC clearly have a flavor of Fortran about them (when I was a kid, translating Fortran code I found in books at the library over into BASIC for my home computer was something I enjoyed doing). I'm not sure where others like Python, Lua, and Perl fit in, but despite certain differences, they too have similarities with the legacy languages.

Very early basic were indeed Fortran like though thankfully less import on hollerith coding, but once Gates got his empire going, he changed it in many modern ways. Modern basics don't look like, nor have much in common, with traditional fortran

cr0sh:
Once you understand the structures, the rest is just syntax. Think of it like the "romance languages" (Spanish, Italian, French): They all have a very similar structure, with the rest being syntax (it isn't quite the same, though, human languages being human and all, and subject to a much wider array of social, political, and other forces which don't exert themselves in the same way on computer languages, not to mention the age difference); if you learn one, you can (in theory) pick up the others much easier than, say - English or German.

All true, but it is not just syntax, it is methodology. There is a world of difference between a traditional strucutural coding approach (which I think still works very well for embedded programs) and object oriented techniques which were originally developed for building very large applications.

cr0sh:
That said, there are languages out there (but none you are likely to encounter or use) that will make you go "WTF?" - and some of them are based on interesting constructs meant to make them easier to utilize in certain scenarios or for certain purposes. Once you begin to appreciate what the world has settled on (mostly) for "standard programming structures", looking into these other languages can be an interesting diversion...

Forth is an excellent example of a different language, LISP is another... Both make my eyes water...

wanderson:
Which is why Arduino code for the most part doesn't tend to use much of the OO functionaility.

What Arduino code would you be referring to? Most (if not all) of the Arduino library utilizes OO substantially. Serial, Servo, Wire, SPI, Ethernet, etc are all objects.

If you are referring to user code, that's entirely up to the user. The vast majority of samples are written in straight C because they are targeted towards non-programmers.

I write the majority of my own projects utilizing C++.

jraskell:

wanderson:
Which is why Arduino code for the most part doesn't tend to use much of the OO functionaility.

What Arduino code would you be referring to? Most (if not all) of the Arduino library utilizes OO substantially. Serial, Servo, Wire, SPI, Ethernet, etc are all objects.

If you are referring to user code, that's entirely up to the user. The vast majority of samples are written in straight C because they are targeted towards non-programmers.

I write the majority of my own projects utilizing C++.

The Arduino libraries use more of the OO nature of C++, but not by much. One specific example is that I/O tends to be function/procedure based rather than stream based. Another is that even when OO techniques are used the actual implementations are by nature limited. An example that comes to mind is the print functionality which doesn't cover all of the actual object/type possibilities within the standard environment.

OO methodologies do not seem to work well for devices with such limited resources. By nature good OO design tends to be less concerned with resource use, which makes sense since OO was developed to build programs that are larger than any uC can hope to run. And efficient use of resources is the over riding concern of embedded design.

OO methodologies do not seem to work well for devices with such limited resources.

I think that's a common misconception. The constraints imposed by these limited resource micros are no less constraining using procedural methodologies than they are with OO methodologies. The vast majority of OO features have little to no real impact on either code size or code performance. And the few exceptions that do exist should be taken into consideration even when used on PC based platforms (at the very least, the programmer should be aware of the impact they have).

Encapsulation: Classes in and of themselves have no impact on binary size or performance. A handful of functions and global variables will take up just as much ram and flash as a class encapsulating them.

Inheritance: Excluding virtuals (which is really polymorphism), utilizing inheritance also has no impact on binary size or performance. It's just good code reuse practice.

Polymorphism: This does impose some overhead in both performance and RAM (as a vtable needs to be created and then used at runtime to determine which virtual method needs to be called). If used extensively, the RAM overhead can certainly get out of hand, but judicious high level usage can still provide some value-add even on these micros.

Function Overloading: Another handy feature that does get used extensively by the Print class. Again, no impact on code size or performance.

Operator Overloading: Same as Function Overloading.

Templates: The only thing Templates change is the amount of code you have to write, and it reduces that. Another win there.

Now, once we start getting into comparing the C 'standard' library to the STL, things become less favorable, but that's mitigated by the fact that Arduino does not provide an implementation of the STL (though one or two third party implementations are floating around out there), nor is it a valid reason for not utilizing all the other strengths of the C++ language.

Code written for re usability will almost always be more bloated than code customized for the specific task. O-O only makes sense if the design objective is reusability. The Arduino platform is a perfect example. What little OO in the Arduino, which is what makes it so easy and begginner friendly is precisely why the Arduino way is so much slower and more flash intensive than straight C/C++ for the AVR written for specific tasks.

Compound that with OO's feature of masking the low level implementation, and you have a mechanism that will produce bloated code when used by typical programmers. Now it is certainly possible for a seasoned OO programmer to write code that is as efficient as that written in straight C or even asm, provided they pay attention to the low level implementation of that code. And if they are doing that there is little (to no) benefit in the OO approach over the previous Structured approach. OO only becomes a clear advantage when the resources are for all intents unlimited or when the project size is extremely large. And that would be defined large on a scale where even the most extensive and powerful embedded application would still qualify as small.

wanderson:
Code written for re usability will almost always be more bloated than code customized for the specific task.

That is a rather vague statement, and while I wouldn't argue it's technical validity, I will absolutely argue it's practical impact. I'm assuming here that you really mean optimized when you say customized, since virtually any code one would write can be considered 'custom'. The reality is, very few projects require optimized code to get the job done. Reusability should ALWAYS be a design objective, with optimizations performed only where deemed necessary to meet the goals of the project.

wanderson:
Compound that with OO's feature of masking the low level implementation

I wholeheartedly disagree with that statement. Masking of low level implementation has nothing to do with OO vs procedural. If you're using a third party library that isn't open source, then the implementation of that library is masked from you regardless what language it's written in. If the sources are available, then it's implementation isn't masked.

wanderson:
Now it is certainly possible for a seasoned OO programmer to write code that is as efficient as that written in straight C

I've already shown that the majority of C++ features incur no overhead with regards to code size or performance. Bottom line is, there is nothing inherently inefficient about C++ compared to C. That's a fallacy, plain and simple. Yes, it takes experience to write efficient code, but an inexperienced programmer is just as likely to write inefficient C code as they are C++ code. And for the record, though not really applicable to the Arduino, the STL is a very efficient library.

wanderson:
OO only becomes a clear advantage when the resources are for all intents unlimited or when the project size is extremely large.

Again, I have to disagree. The advantages of OO code become clear with just a few thousand lines of code, which doesn't even come close to pushing the limits of the Arduino unless it makes extensive use of RAM or utilizes some fairly large third party libraries (the latter case really meaning it's much larger than a few thousand lines of code).

Encapsulation alone is far better than having a few dozen global variables and dozens of functions whose only real organization is in their naming convention. Hell, it's better than having half a dozen globals and a handful of functions in even a small project.

Polymorphism: This does impose some overhead in both performance and RAM (as a vtable needs to be created and then used at runtime to determine which virtual method needs to be called). If used extensively, the RAM overhead can certainly get out of hand, but judicious high level usage can still provide some value-add even on these micros.

Polymorphism without new() is like a fish without a bicycle.

And what is a fish going to do with a bike?

And what is a fish going to do with a bike?

Have you used new() on Arduino?

florinc:

And what is a fish going to do with a bike?

Have you used new() on Arduino?

Nope.

C'mon guys, give c++ a break, lol.
jraskell has some great points that I would back up if I wasn't heading to work soon ( great excuse I know! ), and comparing polymorphism to new is silly. Polymorphism just like everything else comes in two flavours... dynamic and static.

Very interesting dissertation though somewhat off topic.....
We though, "tend to read what we understand rather than understand what we read..." My statement was to understanding Linux, FIRST in order to learn and use the language for the Rascal (Python? cool but later)...
I am having enough trouble learning C and C++ for now. I am one of those people who do things in a serial manner... You know... learn to walk before I run the NY marathon.
The language is slowly coming to have meaning for me as I learn it. I have no desire whatsoever to become anything more than reasonably familiar with C and see what happens from there.
I have more years of electronics experience that most of the people I interface with here in the forum do in writing code... (again I don't wish to be mis-understood I won the hard way, by persevering to the bet of my ability.
I am NOT trying to offend people here who are in my age bracket. I know who you are and I respect your knowledge more than I can say. There are however others that don't see what I am trying to say.
I WILL do the same with C and C++. Remember I bought my first Arduino Uno in March of this year and everything else is going well. I can write a sketch to a limited degree, I understand enough of the process to make a sketch do as I want and I learn more every day.
I thought the Rascal to be an interesting device for 'Forum Chatter" Highly educational and very frequently amusing reading the threads generated by this Idea and many more like it...
The Rascal is way out of my league now and I will not divert my attention elsewhere until I am more comfortable with the Arduino brand of C and C++ as these devices taken singly and as building blocks (I bought 2 328,5V Pro mini's for stand alone radio interconnected tasks for "This Years Grand Project")...

Doc
Next year I have no doubt I will be after another project but the Arduino will do for now...

jraskell:

wanderson:
Compound that with OO's feature of masking the low level implementation

I wholeheartedly disagree with that statement. Masking of low level implementation has nothing to do with OO vs procedural. If you're using a third party library that isn't open source, then the implementation of that library is masked from you regardless what language it's written in. If the sources are available, then it's implementation isn't masked.

Of course simple, traditional functional code can mask the low level implementation. But it is easier to write low level C with an appreciation of what the assembly output will be than it is higher level functional based code and especially OO code. It is a question of what is practical, not possible...

jraskell:
I've already shown that the majority of C++ features incur no overhead with regards to code size or performance. Bottom line is, there is nothing inherently inefficient about C++ compared to C. That's a fallacy, plain and simple. Yes, it takes experience to write efficient code, but an inexperienced programmer is just as likely to write inefficient C code as they are C++ code. And for the record, though not really applicable to the Arduino, the STL is a very efficient library.

You are incorrect when you claim "no overhead", though a "proof" would require comparison of the produced assembly. However, that ignores the crux of my claim. OO code, produced for reusability, will include components that are simply not needed for every application. This is also the problem with functional based libraries of code. A simple example is code that handles multiple data types, when only one is needed for a given application. It is not a question of the "theoretical" use of any approach but the practical.

Here is a specific example. I was attempting to test some code on an ATTINY2313. The core code was small enough for both FLASH and RAM conditions; however, by attempting to use the Serial object I was exceeding available resources. The only way to get that code to work, involved, using low level C code to transmit serial data (of the specific form I needed). At that level OO approaches would be indistinguiable from straight C or really even assembler...

wanderson:
OO only becomes a clear advantage when the resources are for all intents unlimited or when the project size is extremely large.

Again, I have to disagree. The advantages of OO code become clear with just a few thousand lines of code, which doesn't even come close to pushing the limits of the Arduino unless it makes extensive use of RAM or utilizes some fairly large third party libraries (the latter case really meaning it's much larger than a few thousand lines of code).

Encapsulation alone is far better than having a few dozen global variables and dozens of functions whose only real organization is in their naming convention. Hell, it's better than having half a dozen globals and a handful of functions in even a small project.
[/quote]

Encapsulation is easily obtainable in a straight functional approach. Indeed the concept was incorporated as a desirable programming practice long before the practical use of OO tools...

Just my view on the matter

Of course simple, traditional functional code can mask the low level implementation. But it is easier to write low level C with an appreciation of what the assembly output will be than it is higher level functional based code and especially OO code. It is a question of what is practical, not possible...

You are incorrect when you claim "no overhead", though a "proof" would require comparison of the produced assembly.

I believe that was a fairly accurate analysis. Wrapping a non-member function into a class will not add overhead and 'Interface' does not generate instructions. The C++ compiler exploits the added semantic information associated with public inheritance to provide static typing.

OO code, produced for reusability

This is one major problem. Object Orientated paradigm's especially inheritance are not for code re-use. If that is your sole reason for using an OO paradigm, you are using it incorrectly.

The purpose of inheritance in C++ is to express interface compliance (subtyping), not to get code reuse. In C++, code reuse usually comes via composition rather than via inheritance. In other words, inheritance is mainly a specification technique rather than an implementation technique.

pYro_65:
Wrapping a non-member function into a class will not add overhead and 'Interface' does not generate instructions. The C++ compiler exploits the added semantic information associated with public inheritance to provide static typing.

OO code, produced for reusability

While this is true in some cases, and possibly even most, it is not always true... and that is the crux of the problem. When programming for an embedded environment OO features insulate the programmer from the hardware

pYro_65:
This is one major problem. Object Orientated paradigm's especially inheritance are not for code re-use. If that is your sole reason for using an OO paradigm, you are using it incorrectly.

You may not be old enough to remember when OO was first being prosletyzed, but code re-use was the major selling point at that time. Interface compliance or inheritance was primarily sold as a method of improving the ability to re-use code over the methods that were then available. Indeed the additional design requirements were only able to be justified by the labor savings such re-use would allow for...

pYro_65:
The purpose of inheritance in C++ is to express interface compliance (subtyping), not to get code reuse. In C++, code reuse usually comes via composition rather than via inheritance. In other words, inheritance is mainly a specification technique rather than an implementation technique.

Again, what your describing is part of the OO design approach... And I believe your interpretation differs from mine due to your modern experience base, while mine is influenced by the religions earlier sales pitch...