[Split Thread] Differences between PROS and VEXCode and Respective Documentation

[anon4126930]

@sazrocks

Unless there are a ton of instances of smart cables melting that I’m completely unaware of, the current draw of the motors (and the gauge of the wires) has nothing to do with smart ports failing on the brain or motor. The RS485 data pins are even completely separate. Also, V5 smart cables have increased wire thickness specifically to support the higher current loads from things like V5 11w motors. Can you elaborate on what you mean by “thin wires”?

I have guessed that motor ports breaking is likely due to thin wires. Regardless if that is the culprit, ports are still breaking. Perhaps the true reason may be static, which could indicate that the static discharge is shorting electronics where they should not be. I don’t know. There’s a problem and it’s still occuring throughout almost half a decade, including but not limited to white screens.

@sazrocks

While most of the functionality of the V5 system is available in both environments, this does not at all mean that they are “identical”. Under the hood they each have some pretty significant differences such as entirely different scheduler types, different ways the program binaries are made/stored on the brain, and different supported C++ versions. And of course, the API for each environment is entirely different.

I want to repeat. Despite minor differences, both PROS and VEXCode are near identical on paper and functionality. If you treat both of them as a black box, where one side is the VEX API, and the other is the front-end, despite minor differences, they are near identical on paper and functionality.

If you set aside LVGL and the graphics, the VEXCode’s event callbacks, PORT1, etc. and the small minor differences, VEXCode and PROS are nearly identical. I have even made my own LVGL menu before, I have made my own VEXCode menu. Of course the menus are different, but I’m not talking about those things as most people in VEX don’t use the menu’s as much as they use the core components (motors, controller buttons, sensors, etc). The front end is treated identically.

For example:

1. Mutexes (besides the wording give/take, and lock/unlock, they are identical)
2. Motor creation (besides the PORT1, reversed and 1,-1, they are identical)
3. Tasks (besides VEX task functions require returning int, they are identical)
4. I can continue, but you get my point.

Fundamentally, besides minor differences (such as LVGL and PROS depot), PROS and VEXCode are identical. There doesn’t need to be such redundancies, when you can probably incorporate much of PROS functionality into VEXCode especially given the financial incentive to do so, by being able to control the market of learning, a core component to hook people into the VEX ecosystem by showing its simplicity and ease of use.

I believe you are disagreeing solely for the sake of disagreeing. I am unsure if you are trying to play devil’s advocate or you don’t necessarily care about the fundamentals. Fundamentally, the front end is handled nearly the same by the end-user. I have confirmed this as I have written my own library that is drag-and-droppable between a PROS and VEXCode project with preprocessor checks. They are treated nearly the same.

@sazrocks

Neither VEXCode nor PROS “is” a VSCode extension. Both have VSCode extensions to facilitate their ease of use in VSCode, but both are more than the extension itself.

I mean a VSCode extension isn’t merely a VSCode extension as they have typescript, jsons, etc. I don’t get your point. I believe you’re likely disagreeing solely for the sake of disagreeing. I can say the sun is yellow, and you can tell me that “well, actually the sun is a greenish-yellow.” It just sounds like context that isn’t necessary, but just to find a reason to disagree simply because you wish to.

Yet again, I’m talking about fundamentally. Not unnecessary specifics for an “actually” response, if that makes sense.

@sazrocks

Ignoring the logistical complexity/impracticality of this (the libraries are not really “mergable”, they are completely different), you would also have to ask if the PROS team is willing to do this alongside VEX. To that end, I’m not even sure how possible it would be legally, depending on how the end product would be licensed you may need to get the consent of all PROS contributors for their code to be relicensed.

They don’t have to be “mergable.” They can do either the following:

1. They simply can incorporate the same PROS front end as pros:: namepace or something of the like, that interfaces with the VEXcode infastructure. But that’s a suggestion.
2. Or you can simply extend the vex:: namespace to handle the same PROS constructors

Some useful additions could be incorporating the = operator overloading that the older ROBOTC and PROS C users love. But honestly, I feel like you’re missing the point. I’m talking about fundamentally, both PROS and VEXCode are identical in the front end and there really doesn’t need to be two systems that almost do the same exact thing for C++.

As per the whole PROS thing, I’m just talking about the fundamentals. You don’t really need to copy anything with PROS. You just merely add functionality into the VEXCode libraries that doesn’t yet exist fully that may exist with PROS (i.e. -1 and 1 for ports), so that you don’t need to incorporate a new device to all of the other systems (basically, it’s redundant to have to incorporate a sensor into a C++ library twice), yet have access to new sensors when they release.