One thing to remember is the intended audience for these two development systems. Most users are first time programmers who are still learning the ropes and struggling with basic syntax.
When I evaluated the two last year my first reaction was much the same as yours, ROBOTC is a subset of C and leaves out many of the capabilities I normally use. I’m thinking pointers, recursion, initialized structures, things like that. EasyC on the other hand is using the gcc-arm toolchain under the hood so these limitations do not exist. I chose to primarily use ROBOTC for two main reasons, the real time debugger which allows all systems variables, motors, sensors and many other things to be viewed when the code is running. Secondly the fact that it is running a RTOS and therefore allows different tasks to be running simultaneously. I also reverse engineered much of the communications protocol for both the serial and USB interfaces, this allowed me to write my own debugging front end which has similar but slightly different functionality to the built in debugger. I posted some screenshots of an early version here, it’s been developed a little more since then but is still not publicly available.
It’s also worth remembering that the cortex is quite simple in as much as it only controls 10 motors and has a limited number of sensor inputs. Most robots (for the last two years anyway) can be broken down into drive system, lift/arm system and intake. Add a few pots, encoders, switches and perhaps a more sophisticated sensor such as a gyro and that’s it. Code to control all this is not going to push the limits of either development system. The code for one of the more famous robots from last year when exported as text is only about 2500 lines, a fraction of some of the commercial code I work on. Because of the relative simplicity of the code I can deal with the shortcomings of ROBOTC and simply change my coding style to take advantage of it’s strengths while avoiding it’s limitations.
It doesn’t really add too much complexity and in many ways makes the code easier. For example, code controlling the drive can be completely separated from code controlling the lift/arm and intake. Monitoring a gyro as a tilt sensor or an emergency stop button can be running effectively as a background task and kept nicely out of the way. I see tasks in ROBOTC much more like processes under unix where each has it’s own job to do and can run independently.
Yes, it really only compiles one file, makes using libraries hard.
I don’t know the answer here for EasyC but ROBOTC has a file system of sorts, you can store files of other types on the cortex but support for this is currently very limited.
This is also a plus, ROBOTC has an emulator built in for testing code under windows. They also have the “virtual worlds” add on which lets you write code to control a virtual robot in a 3D environment.