Which programming language to learn

I think this is the standing myth, but it misses BASIC's historical origins. BASIC was named because the authors wanted a very basic language. But it's early popularity was not its simplicity, but its interactivity. I would suggest it was one of the very early IDE's (integrated development environments). If you were a beginner and were going to write a program in the '70's, you have your choice.

1) Learn how to launch BASIC. Start typing. 2) Or learn how to launch an editor, learn the system file structure and save your edited source with only allowed character names and extensions, learn how to launch a compiler, with half a dozen command line parameters, which implies learning the command line structure of the system as well, learn how to launch an assembler, again with command line parameters, extensions, and file modifications, learn how to run a linker, etc., and then see if your program did anything but crash. The differences were astounding. BASIC accomplished this by being interactive. You could enter your program, edit your program, run your program, all from the terminal. So BASIC became popular by being interactive.

Lest we forget interactivity was what made the Personal Computer, well, personal. Most contact with computers in the 1970's was through a punch card deck. Someone else took care of the JCL cards that proceeded and followed your job, and a print out was all you got back. Unless you were a system guy, you never saw the part where all that was done. The JCL (or the paper tape, or even the front switch panel) was the interactive part.

Now those days are gone. The new "Basic"s aren't interactive any more. They are roughly like any conventional language. Hence only the leagacy of "simple" carries Basic forward, and the simpicity stands in the way of useability, without the advantage of interactivity. Yet it tends to be a very low performance language, speed-wise.

Yes, sorry. Generally promoting Forth falls to me, here (self appointed). Been down sick for over a week (or should I say very weak).

Forth retains its interactivity (most versions), runs natively on the final system, has good speed (particularly for a language retaining interactivity), and has unparallel code compaction. Forth is generally available at very reasonable prices, as well as in freewear "unsupported" versions.

In robotics, the wonderful thing about Forth is, again, its interactivity. You don't have to wonder what value some variable holds, you can query it and see. You don't have to wonder if some output is high or low, you can query it and see. You don't have to wonder what some input from a sensor is, you can query it and see. You don't have to wonder if changing some variable slightly would do, you can just set the value and try it. You don't have to wonder if some servo is working or not, you can just try it, set it where you want, and see if it follows. And so on. They way you do these sorts of changes with conventional debugging are usually convoluted and complex, and done with very expensive ICE equipment, while Forth programmers feel totally enabled with a tiny bag of tools readily at hand.

Interactivity. Nearly a lost concept in the world of modern programming.

You might want to atleast have a look at Forth. MPE is one of the remaining leading vendors, and is resident in the UK.

-- Randy M. Dumse

Caution: Objects in mirror are generally more confused than they appear.

Hello,

I am programmer by profession. Robotics is just my hobby. I use Java (J2ME - Java in cell phones) for robotics.

See:

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.

S> I have recently become interested in robotics - I've done a bunch of ...

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:

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 ...

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

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

Robotics is a wide field, with widely varied sets of interests and activities. Without a doubt you should evaluate the IPRE program

. 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

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.

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 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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

You're welcome.

Coincidentally, there used to be a pascal compiler marketed by a company called TMT.

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

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

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

Where "virtually no one" includes the developers of small projects like the Linux kernel and X11.

Sorry. Didn't realize these were considered microcontrollers, and that this group was no longer about robotics.

-- Gordon

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!

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

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.

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

Overly broad AND utterly inaccurate!

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