I'll tell them to give back their PhDs in computer science then. No doubt you've got a lot more experience in programming then them or me. :yikes:

This really is a very stupid arguement. USE THE RIGHT TOOL FOR THE JOB. And this thread has gotten rather off topic.

Agreed. It's turned into just argument about C++. While I will say your topic is somewhat relevant, if you'd like to continue the discussion, I suggest you take it out of this thread, so it's not distracting the real discussion.

As for my "inside sources," let's just say I have information from two very reliable, well known sources that say we may be dealing with a new control system that doesn't use PBASIC, provided that IFI can make enough for the 2004 season. Whether we'll "C" this controller next year or not remains to be seen... but my sources say we will :p

Well actually even if they decided to go with just plain basic or another variant of it should be easy to convert it to that. I personally hope that it turns out that way. Most of the basic compilers out there either sport compatibilty with pbasic or share similar commands while improving upon it.

True....I didn't really think about that when I posted it. My other argument is the tokenizer.dll. Will they still use that, or is it gonna be another library.

I wander what cool new hardware features there will be. I hope there are more io ports such as some general purpose bidirectional ttl or cmos compatible pins and a real lcd.

Honestly, if they're telling you that one programming language is inherently better than another in totality, they're doing you and everyone else a disservice. A specific feature of a programming language may be better implemented or better supported than another, but saying it is completely better is just ignoring too many of the other features of the programming language.

Plus, I've met a good number of people with PhD's who really don't know what they're talking about. Or at least don't have as good an understanding as they should.

Matt

TOtally is not a word I used. There are a few cases where C++ may be a better language is some ways then some other languges. But few programmers will ever see the need to use them. Someone doing general applications will never see them. In some operating systems features perhaps. And maybe in low memory configuration embedded systems. But darn few of either of those as the VMs for Java and C# get better. In many cases you'd be better off going to assembly before C++.

But in general terms you can say that one language has more good features then another and/or that one language has more bad features then another. And clearly for general applications Java and C# are MUCH better languages then C++.

Of the 9-10 languages I've used professionally (and a bunch more for fun) C++ is in the lower middle of the ones I'd use again if I had the choice. Above DIBOL and below OOP COOBOL .NET.

Key word there is choice, just because you like it better does not automatically mean it's better. What type of programming have you done? I do 3D programming mostly and I find C++ works great for that. I am also learning how ot program Motorola MCUs, in C and a little assembler, I wouldn't dare use .NET for that. The better language can't just be picked.

He is right. But the simpilist point, that covers this whole off-topic stuff is "USE THE RIGHT TOOL FOR THE JOB".

But Matt is right. C++ is recommended over a lot of langauges for 3D programming. You wouldn't use VB for it, because that would make it run to slow. I'm not sure if C# can do 3D. ASP can't handle 3D at all. Nor PHP. C might.

But still, read my sentence, and repeat that over and over (repeate the stuff inside the quotes that is) if you don't know what language to use for a project.

Heck, I'm using MFC for my editor (I was using the C++ Win32 API, but that was causing more confusion than anything). MFC is great for what I wanna do. But it isn't to good for making games.

A little bit of a lot of things. Some operating systems internals. There was a print/batch system where some of the work was done in Assembly language and some in BASIC (Basic-PLUS actually). I've done OS work for a couple of companies (the companies that created the hardware and OS) in a couple of assembly languages. I've done some high performance stuff using array processors which obviously was in FORTRAN. Some applications (accounting etc) that was done in languages like COBOL, DIBOL, versions of BASIC, etc. Test software for high performance systems in a bunch of languages.

Are you saying that no language is better then any other? They're all the same?

Neither of the two camps in this argument is going to convince the other that either one is right or wrong.

Don't get me wrong. I have an opinion, which I have, more or less, already expressed. I don't claim to be an objective observer. I just am all too familiar with arguments like this.

One suggestion: drop it.

So, about that new control system...

I've heard that teams will have the ability to use the same syntax as we've all been familiar with, for past years, in PBASIC. I assume this is a fall-back-plan for teams who can't cope with such a fundamental change, so quickly (possibly analogous to what some teams experienced with the introduction of an autonomous mode). What do you think the chances are that they (IFI) would use a product like a PICBasic compiler, rather than develop the translational software in-house?

I would assume fairly high. IFI doesn't have that many employees and a complete redesign of the control system would take up a lot of those employees. There is the possiblity of them contracting it out however.

I think there may be a more likely solution in that software written in PBasic may run in an emulation layer on top of another processor. If the processor was significantly powerful (and frankly, it's not hard to get a cheap powerful processor these days), it wouldn't be too difficult to do that.

Another possibility is to just have two different chips on the board (both a Basic Stamp and some other mystery chip) and it's user selectable as to which one is used.

Matt

Hmm. Thats a good point. It, however assumes a relatively powerful processor like a StrongArm Coldfire, etc. Most higher power processors must be either programmed in assemble or a compiler must be used. That would mean that FIRST would have to get a company such a MetroWerks donate the software. Microsoft and Metrowerks? not likley

On the other hand I think it is highy likley that they will use another Basic stamp like chip, such the Basic Atom, Basic X, etc. This would allow a great boost in power, with little syntax change.

While a real(ie: runs compiled code) processor would be nice, I think we will probably just see another Basic Stamp like chip. I hope im wrong though.

Not to mention interpreted code runs at a slower pace no matter how you slice it. There are also plenty of companies around that make compilers. The makers of the Basic Atom also makes compilers.

That they do. You must be referring to their MBasic compiler, which is meant to accept basic stamp code. Hmmm right back to Basic Stamps again.

I'm not quite sure what you're point with powerful processors must be programmed in assembly or a higher level language. To my knowledge, almost all processors must be programmed that way. It also wouldn't have to be a particularly powerful processor. Remember that the Basic Stamp merely interprets the compiled PBasic code and that runs on a PIC.

As far as having MetroWerks donating a compiler, I wouldn't see why not. They are owned by Motorola after all which is a big sponsor of FIRST.

That leads me to another point: I think there's a strong possibility that the new chip may be from Motorola. Motorola makes a lot of embedded chips and may be willing to give IFI a discount on them for use with FIRST. The chips are widely used and have a lot of support out there. There are also various C compilers for the processors. I think that may be a strong possibility.

Matt

please if motorola does wind up working with or without ifi on a new IO and/or RC please do not have it like another big, bulky, space wasting, White box like it has been in the past.
~Mike

It really has nothing to do with the language it has to do with how the language is read on the microcontroller.
interpretors-An interpretor reads a high level language and then tells the micro-controller what to do. It is almost exactly what a Basic stamp does. The slowest of the three choices due to the fact that the microcontroller has to read the high language.
Compilers- Compilers turn high level languages and turns it into assembly. They generally have to be designed for a specific brand of micro-controllers since each one usually has different hardware architectures. The second fastest due to the fact that the program is being translated into assembly.
Assembly- Lowest level language for any microcontroller and generally the hardest to understand. The fastest one if properly implemented.
Usually all that gets affected if you go from one type to the next is the speed of the program. It usually goes like this in order of increasing speed:
interpretors<compilers<assembly

I think it's java...anyone look up parallax's latest projects...the javalin stamp...the basic stamp...I don't think it would be too much work to replace pbasic with java by switching stamps from the same company. Likewise, I would think parallax would be pressuring IFI to be using the javalin stamp to promote sales and usage. The AP Compsci switched from C++ to Java. Will everyone taking AP Compsci right now not be familiar with java by the time it is released? In addition, Java is more practical than PBASIC pertaining to the real world. No one cares that someone programmed in PBASIC but atleast with java you earn some respect. Java is also cross-platform, I would think if they move to Java they would also support a cross-platform pbasic editor written in java..

I prefer C++, but I'd still want java over pbasic anyday.

I would rather it be not Java. Although getting rid of PBASIC makes it so much powerful. I'll know enough Java by January but I hope it's C++, it is so much simpler and well I have more experience with it. The problem is we most likely won't get the new control system until competition starts.

I think Java would be slower. It takes me about 1.5 seconds to load MSVS .NET IDE and MSVC++ 6 IDE, where as it can take me about 5 to load a Java IDE (all programmed in Java to by the way).

Ah, yes obviously java is slower. But the javelin stamp processes 8000 commands per second apparently (parallax.com). I think that would be sufficient enough for what we need. Well, I wouldn't consider C++ simplier. I would rank level of difficulty from C to C++ to Java being the easiest. C'mon to go to the next pointer in java isn't it like list.nextPtr();. Also, you might not realize how much actual support parallax has for the javelin stamp, in documentation, function lists with examples and descriptions parsed nicely, and several examples. It's actually pretty nice. It all depends how the code is stored and processed, they could compile the java code or not. I haven't read up enough on the javelin stamp to tell you.

In a somewhat related topic, I got to see the field control set that's going to be used next year the other day (IFI gave us a set for use at the Maryland State Fair Competition). Basically, they seem to look exactly like the field control components from 2003 (from the outside at least). They do support autonomous mode and they do support previous year's controllers. This may mean that there are only superficial changes to them. If anyone's really interested I may take some pictures of them and post them. You really can't tell much from just looking at it however.

Matt

There is also a lot of documentation on the BASIC stamp and PBASIC language.
I'd love to see some pictures of the controllers.

What about a FORTRAN derivative? FORTRAN has been around for years, and is still a popular programming language at Universities for math and science. Almost any mentor would know it, as many of them have taken a course in this language in college. It is incredibly easy to learn, and it is really portable. Autonomous coding by dead reckoning would be easy to - just use the etime() function. Are there any RCs, stamps, or chips that support this??? Honestly, though, I really like PBasic for this purpose. THough it is slow and awkward, it gets the job done. C# is absolute crap for an application like this (or any application...sorry, but it absolutely sucks), C is a little archaic, Java is too awkward and slow, and C++ seems unlikely for various reasons. If they do change it, it will probably be to a language similar to PBasic, probably another BASIC derivative (hopefully this one will be faster and allow more variables/variable space).

Why not take into consideration that any language will be as fast as any other on average. The microprocessor, I'm almost 100% sure, will be designed to run off that language specifically. Therefore, it's most likely going to be native code. So, whether they use C, C++, Java, PBasic, or FORTRAN I think the issue of speed is not of concern. The code will be converted into a common form of machine code anyways. Well, I still don't see why they would use an alternate to Basic or Javelin stamp by Parallax. I think usfirst is trying to move toward more autonomous programming and java would be a more applicable and practical tool for the real world and an easy switch I might add.

Two things:

#1, it's FIRST. Not USFIRST. It's been said numerous times before. Yes, the website is usfirst.org. Yes, it is the United States Foundation For Inspiration and Recognition of Science and Technology. But... the short name is, and has been, FIRST for at least 6 or 8 years.

#2, while Java may be more of a "practical tool for the real world", it has been said numerous times that the majority of embedded microprocessors run C. So, while Java is gaining wide acceptance on the Web, and a few other application areas, C is still much more prevalent in the kinds of things we are doing in FIRST.

#1, I think that's an trite claim, you seem to forget the resources available. Parallax already has a javelin stamp. Parallax, i'm sure, is trying to promote their new stamp. Parallax brags at the speed of the javelin stamp being faster than the basic stamp. What microprocessor would USFIRST use for C and would the "opportunity cost" be less than one provided by Parallax? By the way, do you think it's easier to write a Java Applet for a cell phone or a C based program. Even though I despise java, I think you lack to see the multi-purpose use of the language in your argument: "Java is gaining wide acceptance on the Web."

#2, Does it matter if someone calls it USFIRST as opposed to FIRST. I'm sorry this seems irrelevant.

Well I know plenty of microcontrollers that First can use that can be programmed in C and they usually cost a couple of dollars. The Pic's can be programmed in C and are cheap and I am sure that others can be. In fact my one book said you can have a working PIC microcontroller that can be programmed in C for as little as 20 dollars.
You say potatoe and I say potato. Potatoe. Potato. Hey lets call the whole thing off.

$20, would you mind sending me some links...I would rather buy one for $20 than pay parallax $70 for a new chip for our blimp project.

Thanks...

if you want something cheap and don't have a compiler or don't like assembly, Check out the Basic Atom pro. It usually sells for about $29 and is a bit more capable than even the bs2p series. I have one for a project im working on but haven't used it yet.
http://www.basicmicro.com