Which programming language to learn

On Sun, 2 Sep 2007, RMDumse wrote:


Randy, This tongue in cheek response was meant in jest, and in no way to slag your products. My main problem with BASIC, is that some people will call any simple language "basic" regardless its syntax/roots. Standardization remains the one real problem here.

been there, done that!

Forth has all the interactivity and simplicity of BASIC, is generally faster, more compact and portable, and has the added advantage of ANS/ISO standardization, embedded assembly, simple multitasking, various levels of hardware register and interrrupt support etc. etc. While it has a steeper learning curve than BASIC, IMHO, it is well worth the effort!

MPE is a fine company, and they (Stephen Pelc) offers a free programming in Forth .pdf tutorial which is a *VERY* good introduction to Forth:
    http://www.mpeltd.demon.co.uk/arena/ProgramForth.pdf
Additionally, free/GPL'ed versions of Forth exist for classic 8 bit (8051/8088/6502/6809) processors, as well as more recent (PIC/AVR/ARM etc) SoC's and versions for Windows, Unix, Linux, Mac, some with X-development tools for metacompilation and meta assembly ...

Thanks, Randy, and again, BASIC is not really a language for babies, and engineers who prefer soldering to coding, but Forth offers a *VERY* good alternative for the embedded developer, IMHO ...
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Too_Many_Tools wrote:

One of the biggest differences is that its pretty easy to get your application written in C to run on a $2.50 (qty 1) CPU. Using avr-gcc I once put a 600 byte application on an AVR that cost less than $2.50 from DigiKey.
Microchip has been the darling of hobbyists in the past. Today I suggest looking at the Atmel AVR products. Also the free WinAVR and other avr-gcc tool chains.
Don't go more than a day into your project without some form of revision control. Starting cold turkey you should give preference to Subversion. TotoiseSVN would be my recommendation for Windows. CVS is also a good choice. Nightly backups is not as good altho you should routinely backup the version control repository.
You should commit your changes every time you have mostly completed something. Use short descriptions to the commit, "Started serial command processing routines." Should commit several times per day, and always at the end of the day. Then for fun use the version comparison functions in TortioseSVN (or TortoiseCVS) and it should become obvious why one should use version control if it wasn't already.
Ironically one of the most common practical uses I get of CVS and SVN (have projects under both that are not practical to convert) is file synchronization between machines. Just go to the project directory and "update". CVS or SVN goes to the proper place and updates local files and/or flags those that have changed locally so that one can reconcile the differences.
http://www.bdmicro.com/ has good AVR stuff, robotics oriented. I have used a MAVRIC board to prototype before laying out my own board optimized for my application.
For $40 this is an awfully good value for programming and in-circuit debugging of most (double check first) AVRs which support JTAG interface: http://www.ecrostech.com/AtmelAvr/AvrIceCube/index.htm
The $4 10-way Ribbon Cable and $3 Cable Adapter are very handy. If you need them you will have spent more than $7 in frustration learning that you needed them. Forgot why the Cable Adapter is needed.
The AVR Dragon for $52 will handle some newer JTAG AVRs the ICECube will not, has Debug Wire the ICECube lacks, but will not handle the larger AVRs (as used on the MAVRIC boards) that ICECube does.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
dapunka wrote:

check out this site.......http://www.rentron.com/PicBasic2.htm
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hello,
I am programmer by profession. Robotics is just my hobby. I use Java (J2ME - Java in cell phones) for robotics.
See: http://www.RoboHobby.com
We created J2ME-based robot, with uses phone camera as a sensor and it is even possible to see where the robot is going.
If you want to program microchips, I recommend you to use C language (not C++). C language is supported for a lot of devices (chips). It is most popular language (after assembler) for microchips.
Also BASIC is supported on some chips. All the other languages (C++, Phyton, Java, etc.) are not so popular.
If you ask me personally, I like Java because I use this language for programming things of any size - big data driven systems, web sites, cell phones, PDAs, etc. It works on many platforms and I like this language very much.
Sincerely, Oleg -----------------------

...
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 29 Aug 2007 07:21:23 -0700, dapunka wrote:

Speaking as a programmer who has spent quite a few years programming embedded systems, in a variety of languages...
I wouldn't use C for anything larger than a page or two of code; but it does tend to generate fast, compact, code, and there are a million and one compilers for it, many free. OTOH the language itself is rather poor, IMO, it lacks many useful features and, unless you're very careful can produce buggy code - the programmer is expected to check everything "manually" (for example array bounds).
You can mitigate this to an extent with program analysis tools such as LINT however. (To put this in context, I was once contracted to perform QA on some C code for a mobile phone manufacturer. I analysed code in handsets which were already on sale, and found over thirty "fatal" errors in the first week). I wouldn't program in C without LINT nowadays, and I'd advise you to do the same. The GNU C compiler can also perform some static program checks, and is free.
C++ tends to generate bulkier code, and it's not much of an improvement on C in terms of the language itself.
FORTH, as others have pointed out, is ideally suited to certain kinds of embedded systems, the interactivity is extremely useful (one study, using smalltalk, found that programmers using interactive programming environments were up to ten times more productive than the traditional edit-compile-run alternatives), the code, although generally interpreted, executes very quickly and is generally very compact. However, there are generally no safeguards against programmer error, and the language lacks pretty much every high-level feature you might want (although you can usually write your own). I like FORTH, I've written a lot of code in it, and even one or two compilers for it; but I wouldn't use it for large scale projects.
My favourite language du jour is pascal - there are lots of good compilers for it (www.freepascal.org have a good one, and it's, as the name suggests, free).
It's a better language than C, IMO, it's more readable, more consistent, runs equally quickly and there as almost as many free components for it as C, thanks mainly to Borland.
The best advice I can give you is to pick a language and tools which most reduce the possibility of programmer error - and of the four described here, that's pascal.
However, if you can find a compiler for it, I'd recommend Ada: it's a modern language with lots of high-level features and it was designed to allow comprehensive static checking, and to work efficiently in embedded systems. I haven't worked with it, though, so I can't recommend it from actual experience.
Eiffel is also a very interesting language in that regard - again, I've not used it, but I hear very good things about it.
HTH
--
=======================================================================
= David --- If you use Microsoft products, you will, inevitably, get
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
David Mitchell wrote:

Robotics is a wide field, with widely varied sets of interests and activities. Without a doubt you should evaluate the IPRE program http://wiki.roboteducation.org/Main_Page . It focuses on a (freshman) course introducing "computer science" with what early schooling calls "manipulables" - namely robots. The tool is built on Python, a functional programming language which is readily learned by fifth graders and up. It is widely used, both at the core of very sophisticated web apps, and for autonomous robots carrying a linux / mac / windows cpu or netbook.
IPRE is certainly a rewarding personal investment. If not the only robotics language you will learn, your IPRE study will certainly carry you a long way in early simplicity, and later complexity, of robotic developments.
If simplicity is your only goal, try parallax's basic.
~ ~ Bill
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

FORTH is the interpreted assembly language of the English Electric KDF9 computer. It is even more buggy than C, and is at a lower level. The code, being interpreted, runs at a slower speed, at least 5 times slower, than the compiled code from C.
C is generally a better bet than assembly language these days, because of the advances made in optimisations. You'd be hard pressed to write code with fewer instructions than that generated by the C compiler. OK, occasionally you might get a better use of registers, but such improvement will be piecemeal.
In C you might write "a = b + c" and all the underlying machine code will be generated correctly. In FORTH, you must write a whole load of lower-level code to achieve the same, any line of which code can introduce a difficult-to-find bug.
To come back to the OP, to really understand what's going on from an engineering perspective, some time spent with assembly language is, however, valuable.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 18 Nov 2009 09:09:13 +0000, Phil O. Sopher wrote:

I'm not sure what you're saying here, I'd just write: b @ c @ + a !
It's not so intuitive; but that's partly because it's variable based, and FORTH generally isn't.
That's actually one of the reasons why it tends to run so quickly - programs tend to be optimised, to an extent, as they're written.
It's hard to give a reasonable example, but if you compare these two functions written in C and FORTH...
C
int smallest(int a, int b) {     if (a<b) {         return a;     }     else {         return b;     } }
FORTH ===: smallest     2DUP > IF SWAP ENDIF DROP ;
Now I know that these aren't realistic examples, (you'd almost certainly write something as small as this as a #define using the ?: function in C, for example), but my point is that you need the register optimisation in C because you're accessing variables, typically more than once; whereas in FORTH they just remain on the stack, and you manipulate them using the stack primitives - which are written to execute as quickly as possible.
If you have a "proper" compiler for FORTH (and they do exist), they typically optimise the top 'n' stack items into registers (where 'n' can be anything from 1 to 6), so the FORTH example is pretty-much self- optimising: a "proper" FORTH compiler generally executes about ten times as quickly as an interpreter, usually about as fast as C.
This is very handy, as optimisation is one of the greatest sources of hard-to-find compiler errors.
--
=======================================================================
= David --- If you use Microsoft products, you will, inevitably, get
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Nov 16, 10:16am, David Mitchell

==============================================> = David --- If you use Microsoft products, you will, inevitably, get

I think a lot of you have missed the point a bit. There are really two questions here and they are closely related. Before you decide on a language you have to pick a processor and it's environment. Whether it be C, C++, Pascal, Forth, Basic or Assembly, only matters if the langauge is supported by a compiler for the environment you need it on.
When it comes to many small controllers your choices are usually very limited: Assembly is alaways a choice, C is usualy also usually a choice, then things start to thin out a bit after that. Is there even a Pascal version that cross compiles to a Pic or AVR? I always liked forth but again the target makes the choice.
C has gotten a lot of bad press but is really as structured as C++ if the programmer makes it that way. The problem is most programmers try to get "slick" using C and go to lengths to make it bad, though usually not intentionally. C++ prevents a lot of that but the overhead is horrendous when it comes to a small chip. For that matter most C embedded applications don't even use Malloc() as there is no support for it in that environment.
For a beginner for small embedded applications I would recommend both C and the Assem for the target as a learning point. If you already know Pascal or Forth or C++ you are probably not a beginner :) If you are a part time hobbist and it is available for your target, Basic is a viable choice ( use subroutines not goto's). When you want to get better control shift to C. When your project grows Java and C++ or C# or ?? become an option, again the target determines your options more than the language.
Monty
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Nov 16, 12:16pm, David Mitchell

==============================================> = David --- If you use Microsoft products, you will, inevitably, get

David, thanks for revisiting this discussion.
I agree with your comments and choices.
While I understand the reasons for C's popularity, I consider it to be a poor language for large programs.
Pascal and other languages like Ada are better.
TMT
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 22 Nov 2009 12:29:20 -0800, Too_Many_Tools wrote:

You're welcome.

Coincidentally, there used to be a pascal compiler marketed by a company called TMT.
--
=======================================================================
= David --- If you use Microsoft products, you will, inevitably, get
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Too_Many_Tools wrote:

Virtually no one uses straight C these days, and in fact most C compilers for microcontrollers are C++.
The *best* language for robotics would be one specifically written for the task. Many people have tried; so far, none have caught on to any significant degree. I imagine it's because people are still undecided what a robot should do. Creating libraries, data structures, and other language elements is still too task-centric. What works for one project fails miserably for another.
I don't see how Pascal, Ada, C, C++, Basic, Lisp, Cobol, Fortran, Forth, or any other language is better or worse than another, because it really comes down to how well the libraries and compiler match the hardware. There are no standards in robot hardware, so if you were (for example) coding in Pascal the suitability of the language would depend on such things as existing libraries for controlling servos, sensors, and other hardware, or at the least, how willing you are to write these libraries yourself.
If I were developing a robot with advanced vision analysis I might opt for a PC with Windows XP, so I could leverage the very powerful DirectShow architecture. That pretty much limits me to using C++, because that's about the only language that can tap into the real power of DirectShow (you can use .NET for record/playback functions, but you really need C++ to write real-time imaging filters).
Whether or not Pascal/Ada/whatever is a better language is a moot point. For such a robot described above I can't use these except as wrappers, so they're off the table from the get-go.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Where "virtually no one" includes the developers of small projects like the Linux kernel and X11.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Joe Pfeiffer wrote:

Sorry. Didn't realize these were considered microcontrollers, and that this group was no longer about robotics.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

It's just that the claim as stated was overly broad, and there are some large projects out there that provide pretty easy counterexamples. Though, as a matter of fact, the SBC mounted on my iRobot Create is a 486 running Linux. And pretty much all the code I've written for it is written in C.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Joe Pfeiffer wrote:

Overly broad AND utterly inaccurate! <g>
I've been too long in one corner of the robotics workshop. Gotta get out more often to see what other people are doing!
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Too_Many_Tools wrote:

Virtually no one uses straight C these days, and in fact most C compilers for microcontrollers are C++.
The *best* language for robotics would be one specifically written for the task. Many people have tried; so far, none have caught on to any significant degree. I imagine it's because people are still undecided what a robot should do. Creating libraries, data structures, and other language elements is still too task-centric. What works for one project fails miserably for another.
I don't see how Pascal, Ada, C, C++, Basic, Lisp, Cobol, Fortran, Forth, or any other language is better or worse than another, because it really comes down to how well the libraries and compiler match the hardware. There are no standards in robot hardware, so if you were (for example) coding in Pascal the suitability of the language would depend on such things as existing libraries for controlling servos, sensors, and other hardware, or at the least, how willing you are to write these libraries yourself.
If I were developing a robot with advanced vision analysis I might opt for a PC with Windows XP, so I could leverage the very powerful DirectShow architecture. That pretty much limits me to using C++, because that's about the only language that can tap into the real power of DirectShow (you can use .NET for record/playback functions, but you really need C++ to write real-time imaging filters).
Whether or not Pascal/Ada/whatever is a better language is a moot point. For such a robot described above I can't use these except as wrappers, so they're off the table from the get-go.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

I'm not sure that the statement above is true. For example, I never found a C++ controller for PIC16Fxxx series (not that I would want one.)
I agree with everything else you say below.

-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
waynegramlich wrote:

Okay it might have been an over-simplification for ALL controllers. Then again, where did Picant go? Didn't they do a C++ compiler for various PIC chips? Their domain seems now to be parked and unused. Either this is saying something about the PIC or about C++ compilers! <g>
Anyway, I tend to think of things like the GNU GCC toolchain and microcontrollers supported by it, e.g. AVR. I should re-educate myself about the lack of good C++ tools among the (still pricy) compilers for some of the other controllers people are still using...
Let us not forget that it isn't the compiler that matters, but the libraries the compiler brings to the table, thus making your job easier. I happen to think classes are the better way to share and implement reusable libraries.
Given the limited instruction set of the typical microcontroller, and its relative lack of hardware (over a microprocessor system), C++ for uC tends to be much more a concept than a full fledged implementation of OOP. But the concept is notable. Imagine the state of progress if we always had to re-invent the wheel each time we developed something new. I'm fine using someone else's servo class, and adore not having to know how it works unless I feel the need to futz with it.
I'm not sure why you wouldn't want an object-oriented version of a compiler for any task, regardless of the target. I guess I've gotten so used to the paradigm that I now dislike procedural programming. I'm not knocking it, but if given a choice, I know which one I'd make.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

I used to make a living working on the Sun Microsystems C++ compiler. C++ compilers are big huge complicated beasts. To the best of my knowledge there have been fewer than 10 successful C++ compiler implementations.

Technically, you can compile C++ code for the AVR using GCC, but I'm not sure how well supported it is. The supported library for the AVR is for C, not C++. It must be exciting to support C++ exceptions for the AVR.

Again, I'm not aware of many C++ libraries tasked towards robotics for the smaller microcontrollers (e.g. 8-bit and 16-bit.) Maybe Microsoft Robotics studio? I don't know, maybe somebody else can point to some C++ robotics libraries.

Agreed, libraries and classes are great.

The only reason for not wanting such a compiler is that it does not fit. I actually do program my AVR's in an object oriented language. I just do not use C++ (or Java) because they require very substantial run-time support.
Please note, I largely agree with you. I just do not think C++ has penetrated the 8-bit micro controller world with any level of success.
-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.