Programming Software Now Included in All VEX Kits

VEX wants this robotics program to expand out farther than it already has. One of the main things that they want to do is create more programmers. They have implemented parts of their plan to grow the like for programmers by making Robot Skills a combination of Driver and Programming Skills, increasing the importance of AP’s, or Autonomous Points, and now, by making the most used and the most easy way to program robots (in my opinion of course :))at their dispense free. That is my take on this whole thing.

As for the debate going on here, I would have to agree with @phantom285A. VEX wants to get people interested in things that they would have never thought of doing before. IF you replay the ESPN2 airing of VEX Worlds 2016, the leader of Swampbotics (I think, so don’t quote me) said that he was an average jock who tried something new and loved it. PROS is for it’s name: Pros, or generally for established teams who want to try something new to try some different things on their robot. While it is an amazing program, RobotC has a lot of the same things, but it is easier for the general populous to pick up, while having many complex functions that established teams can still use and win competitions with. The only thing that PROS was overall better at than RobotC was the price. Now that isn’t the case anymore.

Another big thing that RobotC has going for it is that it works across all of the VEX platforms (IQ included) - this is a pretty big thing for Middle Schools with both IQ and VRC. For Elementary kids, they may have 3-5 years of experience with RobotC by the time they get to Middle School these days.

This sounds about right… PROS isn’t designed for anyone to learn programming. PROS is intended for people who have learned how to program and want the full flexibility you’d expect out of embedded programming. Having come directly from an embedded systems related internship, I know first hand that a lot of the ideas that PROS has (and will continue to have) translate very directly into industry norms. That’s not something any other environment for the VEX platform can boast.

That being said, if everyone would like to see learning this platform to be easier, I’d love to see that happen. PROS is maintained by several university students and is supposed to be a community effort - so we don’t necessarily have the time to dedicate to making all the curriculum a company can do. If anyone is interested in helping in this regard (or any) - feel free to shoot us an email at pros_development (at) cs.purdue.edu or DM me personally.

except for one other …

Oops :slight_smile: sorry. ConVEX too

PROS in my opinion is much better for learning. There’s so many more resources to learn C than ROBOTC and once you learn C you only need to learn the PROS API. And as long as it isn’t anything related specifically to the PROS API you can ask for general C advice. And if it’s something pertaining specifically to the PROS API it usually doesn’t take very long to get an answer here on the VEX Forum. I’m currently am the only programmer on my team but there’s other interested and I’m having them go through this tutorial or whatever tutorial they want, then I’ll show them how to use the PROS API.

But ROBOTC is C. It’s true there are some advanced features missing but 99% of student code will not use those features anyway.

James while I admire your work and everything you do for the community I believe you’re wrong and are going back on what you’ve previously said. You stated today:

When a simple google search restricted to the vex forum will find multiple posts of yours in the past claiming otherwise:

In that same post later on:

In another post:

In a much more recent post:

Now with that and by definition of a sebuset, how can a subset of a language be the language?

Okay that was a little overkill. It is pretty much all included in the statement “99% of student code will not use those features” .

It is pretty much C. Does it follow the C standard perfectly to the letter, obviously not. If it did we wouldn’t be having this conversation. That doesn’t mean that the students are not learning c. The learning curve of ROBOTC is a lot less steep than PROS. It makes sense for 99% of the user base to use ROBOTC. If it didn’t people wouldn’t use it so much.

Ouch, I feel like a politician now with quotes being used out of context. Here is the original thread from which some of those were taken.
https://vexforum.com/t/robotc-pointers-enums-structs/20252/1

They were true at that point in time, almost five years ago when ROBOTC was still on version 2.X (version history. ROBOTC V3 introduced both pointers and a local stack on a per task basis, these features addressed the two big concerns I had.

I stand corrected in that I have said that ROBOTC is a subset of C, I did say that there are some advanced features missing, I was referring to things like function pointers, however, if you consider the parts of the language that someone new to programming will learn, variable types, language syntax, program structure then it’s not unreasonable to say that ROBOTC is C.

As further proof, it’s worth looking at the code in this project.

This code was originally written for a project completely unrelated to robotics, I ported this over to the cortex about 3 years ago. There is a version in ROBOTC, a version in PROS and also one in ConVEX, the major difference between the three are the library functions that each one calls, for example
here is the ROBOTC version of one of the functions.

void
P3DebugPacket( p3pak *packet )
{
    unsigned char   *p;
    int             i;

    p = &packet->command.data[0];
    for(i=0;i<packet->cmd_len;i++)
        writeDebugStream("%02X ",*p++);
    writeDebugStreamLine("");

    return;
}

and the PROS/ConVEX version of the same one

void
P3DebugPacket( p3pak *packet )
{
    unsigned char   *p;
    int             i;

    p = &packet->command.data[0];
#ifdef  _TARGET_CONVEX_
    for(i=0;i<packet->cmd_len;i++)
        vex_printf("%02X ",*p++);
    vex_printf("\r\n");
#else
    for(i=0;i<packet->cmd_len;i++)
        printf("%02X ",*p++);
    printf("\r\n");
#endif
    return;
}

writeDebugStream is replaced by vex_printf or printf depending on which runtime library is available but it’s all C code.

If the learning curve of PROS is more steep than ROBOTC it’s certainly not by much, it’s really stinking easy to learn C and PROS is C plus the API.

C is the least forgiving language I have ever seen. It is very easy to do something horribly wrong. We are just doing our best to suggest an environment to students that won’t end in things going horribly.

Which is worse, learning how to deal with the how unforgiving C l as a person is learning the language (not really hard with the help of Google) or learning how to program in a more forgiving lanuage and then being surprised in programming in actual C and working through all the issues at once (also made easier by Google)? The answer probally varies from person to person.

I have a video going up that I shot yesterday on this subject. I won’t post it here because I used less than Vex new’s SJW policy words. I’m sure plenty of you will find it.

In short I call out the need for a new Cortex that can be programmed in higher level languages and that generally doesn’t suck and cost too much.

In regards to PROS v/s ROBOTC, I’d point new teams to ROBOTC now and experienced teams looking to step it up I’d point towards PROS. It isn’t complicated.

PROS can do more and has tons of creature comforts that people doing a lot of coding will appreciate, ROBOTC is simpler and more push button-y.

Start a petition for the new cortex if nobody from vex says they are working on it, im sure almost everybody would sign and maybe that would motivate vex to start the process in designing a new cortex.

@tabor473 “pretty much C” and ANSI C are two completely different things and that is my point. In ANSI C you walk the stack to look at how memory is managed/how it works, utilize recursion, and most importantly understand what a seg fault is. These are all critical concepts taught at the very beginning of any C programming course you will take.

As someone who has worked extensively with students these are also critical concepts that they struggle with the most. With that it would make perfect sense to apply these same concepts in a game such as the Vex competitions. It then forces students to apply the knowledge they have and allow them to create very robust solutions thus bettering themselves in the long run.

For these reasons I find that RobotC is still limiting and is not real C programming. In addition RobotC forces you to use bad coding practices in order to get the job done. To #include a .c file in order to expand your code into different files is appalling. If that was ever posted for code review in industry your peers would openly question you and reject those changes.

Now is this to say RobotC is bad? Not at all! It has its purposes for teams much like EasyC, Robotmesh, PROS, and ConVex. The issue I raised was that a statement was issued saying RobotC is C. RobotC is its own language that is C like.

Cody you haven’t been paying much attention to RECF recently have you? They confirmed the development of the new cortex and smart motors at the 2015 event partner summit. Link See the section “New Releases”.

@jpearman again I cannot stress my respect for you & your work in the past. Most notably during those dark times of Gateway & Sack Attack with all the blunders of the Integrated Motor Encoders shedding light where it desperately needed to be shown. My quotes were not intended to be out of context and I made sure to link them properly so that people could see the threads where they were drawn from. However my statement still holds that in July of 2016 you stated that RobotC is a subset of C.

You’re right, I didn’t catch that, in 2015.

But that answer isn’t exactly inspiring.
Screen Shot 2016-09-08 at 3.27.40 PM.png

They talked about it again in the 2016 event partner summit.

Any newer info you can share?