You should probably be commenting your code better then. Regardless, why do you even need to show non-programmer your code?
Or you could use something like TortoiseHg to get real version control. The point is really that for a piece of software that we’re paying for, it offers less than we should expect from something that price. Again, I do think RobotC is that right choice for many, many teams but that doesn’t mean you shouldn’t give the alternatives a shot.
We (most of the time) write comments for us as programmers. When you’re working with one or two people on a project, everyone gets the same shorthand. Things like “Left Front Motor, Port 2” are clear to everyone looking at the robot or code. Comments like “4 in ~697 ticks(?) TEST” and “600 is LB KO” not so much.
The people I work with on us on the team really aren’t “builders;” we would rather just do fun things with code. Some of that we like to present to Judges at competitions for award consideration, or to our coach/team mates as a sort of “This is what we’ve been doing for the last month.” And while they’re always happy just seeing the mechanism or sensor inputs do things, we like to be able to take the code and say “Here’s what we’re doing to make that happen.” The flowcharts were a nice way to say “We check this sensor value here, and if X is true, we do this. Or if Y is true, we do this.” Everyone could get a basic idea, and understand how it works. Now that it “looks like code,” they just give up listening straight off.
That’s the advantage of EasyC. It’s easy for everyone to understand. Can you go back and clean up your code to make it almost readable by other people? Sure. We normally do. But we didn’t have to when the function to read the Ultrasonic had its picture on the tile.
I’d like to respond to some of the points that have appeared in this thread about ROBOTC.
Something we’ve done in the past (you can ask jpearman) is to have frequent private beta releases that address specific issues. We’re happy to include more folks on these releases, just let us know if you submit an issue and we can alert you when we have a build for you to play around with that has the issue resolved.
Now that’s not to say we won’t implement them (see pointers - the community make a strong case for pointer support, so we spent the development time to add it with ROBOTC 3.5) - however, when there are “advanced” languages such as PROS/ConVEX out there that will allow users to do this then the incentive to go through the implementation becomes less and less. The example is when a user requests a feature, we then spend months to add it, only to find out they already moved away to another language. During that time, we missed out on fixing/improving things that the larger population would have benefited from.
–
We’re happy to see ConVEX and PROS come and service a need for the “highest end” users. ROBOTC’s primary focus is supporting classrooms and teachers and giving those users the tools (programming, curriculum, support, training, etc) to enable more students to experience robotics - either in the classroom or in competition. We can all sit here and discuss for hours the advantages/disadvantages to every solution but at the end of the day I think all our goals are the same: trying to get more students engaged in STEM and Computer Science. Just like there are 100s of models of cars on the road, there will be multiple programming languages available - I think the goal is to keep everything positive and not to discourage users from joining the robotics community.
As for ROBOTC 4.0 - we’re working on releasing a BETA version of ROBOTC 4.0 this week. Our main objective for the last 6 months has been bringing the VEX IQ platform to ROBOTC. The VEX IQ system has taken a lot longer than we had anticipated, so some of the 4.0 specific features we had hope to implement (better text editor, refreshed GUI) will be coming as a later 4.0 update. One cool thing that we’ve done is that a single ROBOTC license will allow you to program both VEX IQ and VEX Cortex - we think this will help younger students migrate as they mature from VEX IQ to VEX Cortex. If you have other features or annoyances (to fix) you’d like to see in a future 4.0 update, please feel free to let us know.
As always - we love feedback and do take every bit of it to heart. If you have requests/features/bugs/comments/concerns, please do not hesitate to let us know. You can always contact us via our support channels (http://www.robotc.net/support), or feel free to send me an e-mail directly (address is below).
The point wasn’t to bash a specific bug - it was to demonstrate that it doesn’t really matter how many people are using a product, there will still be bugs and you can’t rely on strength in numbers.
I guess this is a case of you learn something new every day - I apologize for spreading misinformation. I just expected that breakpoints in a non-main thread would halt execution and switch the debugged to that thread so I assumed things only worked in the main thread. Now I know that I can switch threads if I’d like.
Why can’t these betas be public?
At the end of the day it’s not command line compilers that people want but rather a way to integrate RobotC into a more full featured and cross-platform environment like Eclipse. I realize it seems like this is for the .1%, but you have to remember that many of the folks in the robotics clubs are coming off of classes like AP Computer Science and have experience using a “real” IDE. Furthermore, the numbers for the Bots n Stuff community VEX wiki shows that nearly 20% of the community is using Mac or Linux. Obviously a cross-platform experience is not something that only “1 in 1000 users will actually use.” It’s something that 200 in 1000 users will use.
I feel like if a user requested something then others probably want it as well. Just because you lost one user doesn’t mean you shouldn’t develop the feature. Obviously somebody thought this feature was important enough that they switched their programming environment and you should do what you can to make sure others don’t leave in the future either.
I like how this was worded very much. I hope that it’s clear that I’m not trying to drive users away from RobotC but rather I’m just trying to spark discussion considering the pros and cons of each enviornment.
I’m not sure an integrated license is really necessary per-se. Most middle school robotics clubs have the software on the school computers and let kids use it. Middle schoolers aren’t bringing in their laptops and installing RobotC and then bringing it up to the high school.
===
In conclusion, I also believe that RobotC is an excellent tool for most teams. The problem that I have is that it doesn’t seem to me to be catered to the 99% of now but rather the 99% of 8 years ago. The reality is that folks, especially programmers, are using operating systems other than windows. They are taking advanced classes and have learned skills like version control. Then they go join the robotics club and are left using windows in a virtual machine to run a program which feels awkward in comparison to a real IDE. I think instead of concentrating on features the RobotC folks really need to look at the overall user experience and finally implement requested features like projects. The IDE needs to be cross platform and it should ideally be extendable - advanced users should be left with the ability to do advanced things. I sincerely believe that Pros or ConVEX can be modified to the point that they are just as usable as RobotC or RobotC can be made to be just as modular and high-end as Pros and Convex. It’s just a matter of which happens first.
PS - Regarding projects, this literally just needs to be a tree view that we can look at files from. Something like the gedit file browser plugin (pic) would be more than satisfactory.
I’d also like to mention that I am one of the users that has left for an alternate environment. That does not mean that I won’t come back. That means I’m waiting for a few features, mainly cross-platformness, before I’ll be coming back.
Personally, I think that the 99% of 8 years ago is the 95% or more of today. There are many, many schools that use RobotC whose students use windows and don’t need cross platform.
(NPP = Notepad++)
GUI…
If RobotC had command line compiling, Notepad++ could compile RobotC code. I am quite sure that there are many people who are unsatisfied with the RobotC GUI (who would rather use npp?).
Or what if there was a plugin for Eclipse? RobotC could stay shareware and release a plugin for Eclipse or another IDE.
As far as NPP vs RobotC IDE goes…
It is unsurprising that a Text Editor (Notepad++) that was created to be a Text Editor is a better Text Editor than a Compiler (RobotC IDE) that tries to be a Text Editor.
…
If command line compiling does come out, then I would be able to use Notepad++ to call RobotC from the command line.
If it happens than the Compiler (RobotC IDE) that was created to be a Compiler will (probably) be a better Compiler than the Text Editor (Notepad++) that tries to be a Compiler.
Does that make sense? 
In 2005, Mac and Linux had a combined market share of about 6.5% and today it’s closer to 14% (source), not to mention the fact that tech people like us are more likely to use Mac and Linux[citation needed]. Almost 20% of Bots ‘n’ Stuff using Mac and Linux is pretty significant.
Edit: There are many people that use windows and don’t need cross platform. There are also many people who use mac and linux, though, and I don’t understand why there even needs to be a debate over whether or not they should be supported. Serial communications behave similarly across operating systems so it’s not like they would be reinventing the wheel or anything here. They don’t even need to port the IDE - just the compiler and uploader, and there’s already 2 open source uploaders that could be modified by them to work with RobotC.
Being able to use NPP wouldn’t be enough to get me to switch back - I really need the cross platform ability. Our team has 4 programmers - 2 use linux and 2 use mac. There’s no way I could convince them to switch back.
But I do agree that command line ability would be a step in the right direction.
There are ways to do cross platform development, Java, Qt, Xojo and Mono to name a few. However, even when using these each platform ends up needing some custom code. I have developed some cross platform applications, what looks great on a Mac sometimes can look terrible on Windows, even simple control redrawing can be a real pain (historically no double buffering on windows).
But the big problem is testing, it’s bad enough when just supporting a single platform, multiply that by three and the time needed to test the code properly becomes a significant burden.
Yea right. It’s similar but there is platform specific idiosyncratic behavior that can take hours to sort out. Sometimes it’s not always your own code, take the prolific serial port driver for example, behaves quite different under some versions of OSX compared with Windows. Even hardware doesn’t always play nice, the cortex which now looks like a “standard” serial communications device on Windows didn’t work at all on OSX which is why I had to write a new driver.
I’ve never had any major issues using Java+SWT. I can certainly sympathize with web development being like that but I don’t typically have issues with desktop application development.
I don’t know, I’ve just never had any such problems using Java. Sure the platforms behave a tad differently, but most of the differences can be blackboxed with libraries like SWT and Rxtx.
The cortex drivers would certainly be difficult but, again, I don’t really see what would be a major show stopper here. It would be a pain to get it all sorted out, but I don’t think I’m asking for anything really absurdly difficult.
I mean tbh I’m probably gonna stick with ConVEX either way so perhaps it isn’t worth the effort, I just think cross-platform would be a huge plus for RobotC and it would certainly make me reconsider which platform our team supports.
Something to throw out there as well is that PROS was developed and is maintained by a small group of students here at Purdue with full undergrad or graduate course loads as well as other commitments such as jobs and research at the University. So if there is a bug and we haven’t quite addressed it yet I promise we will get to it! 
I am amazed we have gotten done as much as we have and hope to build some great tutorials, howto’s, do’s & don’ts this summer once classes are out.
