You raise an interesting class of user. The professional programmer who also comes home and starts tinkering with mcu projects. I am such an animal.
In my case after of a working day of fighting with Makefiles, building cross compilers, rebuilding Linux kernels, hacking on the Linux drivers etc etc etc I really don't want all that hassle for small projects in the evening when there is precious little time for a hobby. That often reduces me to the "casual" programmer class where a dead simple "type code hit F11" IDE is great.
So I still think the overall classification of users into "casual" programmers and professional" programmers is valid.
As a casual programmer I tried to use Eclipse two or three times .
Always stoped after some time because there is always a small part of the IDE lacking and I was unable to compile or execute my program.
Used VB or visual C# before with no problem.
Perhaps I dont install something properly but become very frustated with Eclipse and feeling it is for professionals.
You raise an interesting class of user. The professional programmer who also comes home and starts tinkering with mcu projects. I am such an animal.
In my case after of a working day of fighting with Makefiles, building cross compilers, rebuilding Linux kernels, hacking on the Linux drivers etc etc etc I really don't want all that hassle for small projects in the evening when there is precious little time for a hobby. That often reduces me to the "casual" programmer class where a dead simple "type code hit F11" IDE is great.
So I still think the overall classification of users into "casual" programmers and professional" programmers is valid.
I would also like it if it was that simple, however that isn't really the point I was trying to make.
We, as Parallax Semiconductor "casual consumers" are not the ones who will generate the sales volume necessary. Those who will (professionals) are the ones that this effort is to target. Those professionals (or the decision makers who govern those professionals), and their expectations are what this effort is to focus upon.
The technology decision maker (or makers) at an organization are not always the ones doing the day-to-day work (more managers than technicians). In those cases, keywords/buzzwords like "C", "C++", or "Eclipse" are deemed acceptable, and "proprietary language" and "proprietary IDE" are warning flags. "Proprietary" is added cost, since they will have to pay to have their employees trained/re-trained on this to be productive.
From a professional's standpoint, unless the technology is strong/well-known, knowing a proprietary technology is not a "selling point" for themselves or their career, and can limit their future opportunities. Regardless of my personal opinion of Spin as a language, I have to accept that it is proprietary, and, if I were looking for a position in that industry I would most likely not mention that I have knowledge of that language/technology unless it was specifically applicable (already being used there).
There have already been several efforts by the "casual" user to make Parallax technologies more user friendly which have been mentioned. Those are separate efforts with a separate focus (ease of use and added functionality not provided by Parallax). I am sure that whatever the end result of this effort, it can and will be adapted to the needs of the hobbyist market, but to include them in the initial effort would only increase the scope and dilute the end result.
I would like to ask the converse question: Why, for professional developers, must an IDE be more complicated than "hitting F11 to load?" By providing Eclipse, are we saddling them with what they expect, rather than giving them a tool they could love? IOW, why does "professional" have to equal "hard"? (And, yes, if there's a MAKE file involved anywhere, it's hard.)
I'm not a big fan of IDe's, but IDE's that I have used include a debugger, and some have a simulator. They must also have a set of command-line tools and make files, so the the engineering department's build guy can run daily builds using a script. The IDE shields the developer from having to create make files himself.
I don't use debuggers much myself -- I pefer debugging with printf's. However, when I do use a debugger it must be simple to use with almost no learning curver required. It needs to debug at both the source level and the assembly level. The IDE needs to make it simple to set breakpoints, watch variables and do all the other things that a debugger does.
Phil,
It's not a matter of the professional dev tools being hard (some are, some are not), it's more a matter of those tools being more capable. Especially when dealing with large scale projects. Another factor is familiarity with a tool. Some professional devs will have used their tool of choice daily for years, and even if it is a little harder at first, they are used to it and prefer it over something new and different.
Thanks Roy: understood. Just so I'm clear, what does a tool like Eclipse offer that could not be incorporated into a simpler IDE like the current Propeller Tool? The thing I'm trying to get at here is this: If Parallax offers two tiers of dev tools, one for pros and one for hobbyists, one of those will inevitably monopolize Parallax's development resources(internal or external) at the expense of the other. In order to eliminate that possibility, it would be nice if one dev tool could satisfy both needs without too much compromise. Do you think that would be a realistic objective? If not, can Eclipse (or something similar) be scripted to behave in a more user-friendly manner for novice programmers who don't require all the bells and whistles?
Phil,
I think a good solution is moving the compiler and downloader to command line tools that the PropTool calls, instead of it being integrated. Then use those same command line tools at the foundation for the Eclipse (or other IDE) stuff. This solution actually enables them to more easily support many different IDEs or build environments.
Then work on the command line tools benefits all IDE tools including Prop Tool. Also, Prop Tool could be extended to work with whatever GCC compiler they/we come up with. Also, Prop Tool could more easily support Prop 1 and Prop 2 (and Prop 3 etc.). Parallax would really only need to maintain Prop Tool IDE and the command line tools. The stuff needed to get Eclipse (or other IDEs) working with their command line tools is pretty simple. If they want to do a more sophisticated integration into Eclipse (or other IDE), then there is that work, but still the main core thing is the compiler(s) and downloader(s) that would be shared across everything.
Thanks, Roy. That makes sense. It's similar to what I did with the S2 GUI, which transparently uses Propellent as the compiler/loader.
BTW, in response to Leon's post, I found this link where Microchip's MPLAB manager discusses NetBeans and their reasons for choosing it as their dev platform:
Roy
I agree,new versions of propellent.dll and or propellent.exe narrows the task down and makes it more manageable for Parallax. It also
gives them control of compiled code and those using the dll or exe can trust the compiler. It also gives flexibility if the chosen platform
say Eclipse turns out to have some major issue or is just not well received by customers. I stated this case in my other posts.
@Roy/Phil,
Decoupling the compiler/loader to command-line applications sounds like a logical direction to go (GCC-based Propellent replacement?). As you had said, then even PropTool could "adapt" easier, as could any other IDE (professional or hobbyist-based).
So now we've all arrived at a conclusion that the industry supports already? That's great.
Command line tools can be supported by any IDE tool-suite in the industry.
The way it's done provides flexibility and relies on past experience.
This should be at least one good reason to consider industry standard solutions
instead of coming up with "something different" just because you can.
Of course if you have a good and easily adaptable product differentiator, you can offer that too.
Just FYI, it was my intention from the start to push for command line tools. That's part of the reason I am working on porting the x86 asm code to C/C++. So it can be the core of a command line compiler.
Just FYI, it was my intention from the start to push for command line tools. That's part of the reason I am working on porting the x86 asm code to C/C++. So it can be the core of a command line compiler.
Roy
I look forward to your results Roy. Go Go Gadget tool-box!
Just FYI, it was my intention from the start to push for command line tools. Roy
I'm not aware of any C/C++ compilers or related tools (linkers etc) that are not command line tools. For example, Visual C++, Visual Basic and Visual C# are all just wrappers around the corresponding command line tool (e.g. for C++ it is cl - see http://msdn.microsoft.com/en-us/library/ms235639.aspx).
Does anyone know of a C/C++ compiler that is not command-line oriented?
Ross, I was under the same impression. I thought GCC was only a command line compiler. My assumption from the very beginning was that the compiler and linker would be command line utilities, and the IDE would be some giant GUI thing.
EDIT : Oh, and one more thing. Please use VI for the editor -- and no cheating by using the arrow keys. The hjkl keys work fine for me.
Roy is referring to porting Chip's x86 assembly version of the Spin compiler to C, compiling the resulting source code with GCC to create a command-line Spin compiler, like Propellent. By porting the Spin compiler to C and open-sourcing it, the language will be easier to extend, and it will be possible to port the Spin compiler to other OSes.
'Seems every time GCC is mentioned, people think it's about a C cross compiler for the Prop.
The objective is create an open-source cross-platform compatible compiler suite for Propeller 2 (code name) supporting Spin, C/C++ and possibly other languages
Now, granted, you may have insight that some of us may not have, but that was what Ken had said in the first post and what I was going on. If I am completely mis-understanding the objective then apologies.
I have been operating under the understanding that C/C++ would be supported languages for the Propeller 2. If they are merely the tools being used to make the tool chain, and that it is being done for portability and to be open source then that is fine.
Parallax Semiconductor is interested in assembling a small team of developers familiar with the GCC compiler suite and perhaps the Eclipse plug-in. The objective is create an open-source cross-platform compatible compiler suite for Propeller 2 (code name) supporting Spin, C/C++ and possibly other languages. A GUI such as Eclipse would be customized to make use of the GCC optimizer.
It's both, as I understand it: GCC is the development chain that the compilers will be written with, AND AMONG THOSE COMPILERS will be a C cross-compiler for the Prop II. It's just that every time GCC is mentioned here, some folks always assume we're discussing the latter, which is not the case.
It's both, as I understand it: GCC is the development chain that the compilers will be written with, AND AMONG THOSE COMPILERS will be a C cross-compiler for the Prop II. It's just that every time GCC is mentioned here, some folks always assume we're discussing the latter, which is not the case.
-Phil
And, beyond that, the "C cross-compiler for the Prop II" will likely be GCC itself. One of the main goals of this project will probably be to write a GCC backend that generates Propeller code. This combined with a port of GNU binutils would make a complete compiler/assembler/linker tool chain for the Propeller. GDB could also be ported to provide a debugger. As most of you I'm sure know, GCC stands for the GNU Compiler Collection which includes compiler front ends for a number of languages including C, C++, Objective C, Pascal, Modula-2, etc. Potentially, all of these languages could be made to run on the Propeller although I believe the initial goal is to enable C and probably also C++.
There was a rather radical suggestion made by some nut (me) that a GCC frontend could even be written for Spin although it is uncertain whether this makes sense. Even if a Spin frontend for GCC was written, it would not replace the Spin we all know and love. It would merely be another way of compiling Spin to allow Spin code to be linked with C or other compatible GCC languages. My guess is that this is not likely to be a high priority. Spin serves its purpose just fine the way it is.
It's both, as I understand it: GCC is the development chain that the compilers will be written with, AND AMONG THOSE COMPILERS will be a C cross-compiler for the Prop II. It's just that every time GCC is mentioned here, some folks always assume we're discussing the latter, which is not the case.
That's me:) I don't understand why Spin is even in the debate about developing professional level tools for the thrust of Prop II into the mainstream commercial market. This is a "Parallax Semiconductor" thread after all. Spin should be tidied away and hidden in the cupboard along with all your other toys when important guests come to dinner.
No I don't have a downer on Spin, I like it. But it is a non standard language that does not address the business audience.
Comments
You raise an interesting class of user. The professional programmer who also comes home and starts tinkering with mcu projects. I am such an animal.
In my case after of a working day of fighting with Makefiles, building cross compilers, rebuilding Linux kernels, hacking on the Linux drivers etc etc etc I really don't want all that hassle for small projects in the evening when there is precious little time for a hobby. That often reduces me to the "casual" programmer class where a dead simple "type code hit F11" IDE is great.
So I still think the overall classification of users into "casual" programmers and professional" programmers is valid.
Always stoped after some time because there is always a small part of the IDE lacking and I was unable to compile or execute my program.
Used VB or visual C# before with no problem.
Perhaps I dont install something properly but become very frustated with Eclipse and feeling it is for professionals.
I would also like it if it was that simple, however that isn't really the point I was trying to make.
We, as Parallax Semiconductor "casual consumers" are not the ones who will generate the sales volume necessary. Those who will (professionals) are the ones that this effort is to target. Those professionals (or the decision makers who govern those professionals), and their expectations are what this effort is to focus upon.
The technology decision maker (or makers) at an organization are not always the ones doing the day-to-day work (more managers than technicians). In those cases, keywords/buzzwords like "C", "C++", or "Eclipse" are deemed acceptable, and "proprietary language" and "proprietary IDE" are warning flags. "Proprietary" is added cost, since they will have to pay to have their employees trained/re-trained on this to be productive.
From a professional's standpoint, unless the technology is strong/well-known, knowing a proprietary technology is not a "selling point" for themselves or their career, and can limit their future opportunities. Regardless of my personal opinion of Spin as a language, I have to accept that it is proprietary, and, if I were looking for a position in that industry I would most likely not mention that I have knowledge of that language/technology unless it was specifically applicable (already being used there).
There have already been several efforts by the "casual" user to make Parallax technologies more user friendly which have been mentioned. Those are separate efforts with a separate focus (ease of use and added functionality not provided by Parallax). I am sure that whatever the end result of this effort, it can and will be adapted to the needs of the hobbyist market, but to include them in the initial effort would only increase the scope and dilute the end result.
-Phil
I don't use debuggers much myself -- I pefer debugging with printf's. However, when I do use a debugger it must be simple to use with almost no learning curver required. It needs to debug at both the source level and the assembly level. The IDE needs to make it simple to set breakpoints, watch variables and do all the other things that a debugger does.
It's not a matter of the professional dev tools being hard (some are, some are not), it's more a matter of those tools being more capable. Especially when dealing with large scale projects. Another factor is familiarity with a tool. Some professional devs will have used their tool of choice daily for years, and even if it is a little harder at first, they are used to it and prefer it over something new and different.
Roy
-Phil
I don't think that anything can be done to Eclipse to make it look simpler for beginners. NetBeans would look a lot less intimidating, though.
I think a good solution is moving the compiler and downloader to command line tools that the PropTool calls, instead of it being integrated. Then use those same command line tools at the foundation for the Eclipse (or other IDE) stuff. This solution actually enables them to more easily support many different IDEs or build environments.
Then work on the command line tools benefits all IDE tools including Prop Tool. Also, Prop Tool could be extended to work with whatever GCC compiler they/we come up with. Also, Prop Tool could more easily support Prop 1 and Prop 2 (and Prop 3 etc.). Parallax would really only need to maintain Prop Tool IDE and the command line tools. The stuff needed to get Eclipse (or other IDEs) working with their command line tools is pretty simple. If they want to do a more sophisticated integration into Eclipse (or other IDE), then there is that work, but still the main core thing is the compiler(s) and downloader(s) that would be shared across everything.
Roy
BTW, in response to Leon's post, I found this link where Microchip's MPLAB manager discusses NetBeans and their reasons for choosing it as their dev platform:
I notice that he doesn't mention Eclipse by name, but I suppose it might be implied when her refers to "other platforms."
-Phil
I agree,new versions of propellent.dll and or propellent.exe narrows the task down and makes it more manageable for Parallax. It also
gives them control of compiled code and those using the dll or exe can trust the compiler. It also gives flexibility if the chosen platform
say Eclipse turns out to have some major issue or is just not well received by customers. I stated this case in my other posts.
Tom
Decoupling the compiler/loader to command-line applications sounds like a logical direction to go (GCC-based Propellent replacement?). As you had said, then even PropTool could "adapt" easier, as could any other IDE (professional or hobbyist-based).
Command line tools can be supported by any IDE tool-suite in the industry.
The way it's done provides flexibility and relies on past experience.
This should be at least one good reason to consider industry standard solutions
instead of coming up with "something different" just because you can.
Of course if you have a good and easily adaptable product differentiator, you can offer that too.
At least it only took 5 pages to get there.
Roy
I'm not aware of any C/C++ compilers or related tools (linkers etc) that are not command line tools. For example, Visual C++, Visual Basic and Visual C# are all just wrappers around the corresponding command line tool (e.g. for C++ it is cl - see http://msdn.microsoft.com/en-us/library/ms235639.aspx).
Does anyone know of a C/C++ compiler that is not command-line oriented?
Ross.
EDIT : Oh, and one more thing. Please use VI for the editor -- and no cheating by using the arrow keys. The hjkl keys work fine for me.
'Seems every time GCC is mentioned, people think it's about a C cross compiler for the Prop.
-Phil
It's still a bit unclear to me exactly what we are talking about in this thread!
I expect all will be made clear on the 17th.
Ross.
I have been operating under the understanding that C/C++ would be supported languages for the Propeller 2. If they are merely the tools being used to make the tool chain, and that it is being done for portability and to be open source then that is fine.
--trodoss
Sorry. Who knew we were thinking about the same thing
It's both, as I understand it: GCC is the development chain that the compilers will be written with, AND AMONG THOSE COMPILERS will be a C cross-compiler for the Prop II. It's just that every time GCC is mentioned here, some folks always assume we're discussing the latter, which is not the case.
-Phil
And, beyond that, the "C cross-compiler for the Prop II" will likely be GCC itself. One of the main goals of this project will probably be to write a GCC backend that generates Propeller code. This combined with a port of GNU binutils would make a complete compiler/assembler/linker tool chain for the Propeller. GDB could also be ported to provide a debugger. As most of you I'm sure know, GCC stands for the GNU Compiler Collection which includes compiler front ends for a number of languages including C, C++, Objective C, Pascal, Modula-2, etc. Potentially, all of these languages could be made to run on the Propeller although I believe the initial goal is to enable C and probably also C++.
There was a rather radical suggestion made by some nut (me) that a GCC frontend could even be written for Spin although it is uncertain whether this makes sense. Even if a Spin frontend for GCC was written, it would not replace the Spin we all know and love. It would merely be another way of compiling Spin to allow Spin code to be linked with C or other compatible GCC languages. My guess is that this is not likely to be a high priority. Spin serves its purpose just fine the way it is.
-Phil
That's me:) I don't understand why Spin is even in the debate about developing professional level tools for the thrust of Prop II into the mainstream commercial market. This is a "Parallax Semiconductor" thread after all. Spin should be tidied away and hidden in the cupboard along with all your other toys when important guests come to dinner.
No I don't have a downer on Spin, I like it. But it is a non standard language that does not address the business audience.