You often if not always need a prototype and a function declaration. You never need more than that and for local functions that aren't forward referenced you don't need the prototype. There is never a case that I know of where you need to type the function signature more than twice.
I guess I agree but I don't think it's a severe enough defect to condemn the entire language. It's something I can live with and so can many other people. It actually has the advantage that you can distribute binary forms of libraries along with a header file if you want to protect your trade secrets in the code itself. Of course, many here will think you shouldn't be writing proprietary code in the first place...
For some time, I've been thinking about C and these basic differences. New job has given me, or forced me into --depending on perspective, some drive time to mull things over.
IMHO, this comes down to how many things a person needs to know in order to do something, and how many states they need to be aware of while doing it, and what is familiar to them.
Seems to me, a killer C environment for people who prefer that lean, "single file" option SPIN + PASM provides them, might be something managed. The programmer gets presented with a place to write code. And they write it. In the background, the other stuff gets created as what they write is being parsed.
We see hints of this kind of thing in Visual Studio, which does all sorts of things to get the programming moving forward. Maybe it makes sense to push that boundary some.
An editor could be doing all sorts of stuff for you. To the experienced person, this may seem intrusive. Probably it is. But, not everybody has the body of familiarity needed to program from the command line, or work in an editor, then build with a script, whatever.
If it's all about "type it here, press F10 and go", that can happen with C, just as it can with SPIN + PASM. Just a thought I had a while back worth dropping here.
Basically, encode the common understanding into the tool. People write code, and that tool parses it, produces the meta-information needed for the compiler, etc... and it goes interactive when needed. "Did you mean this?" kind of thing.
So then, instead of a tool, you get a partner. Smart software that keeps you on task, potentially guiding you toward mastery, or best practices by making those paths as friction free as possible.
One thing I don't like about "exactly two places" is generally one of them is wrong. That is a gut level reaction, and it's due to my manufacturing background. Single sources of truth are extremely valuable. Where there are multiple ones, not associative in any way, where humans basically have to do the work, generally that work is wrong, until those humans get acclimated to the various disciplines, skills, methods, processes, means, culture needed to insure the work isn't wrong. And because of that, there is a lot of meta-activity, such as QA, check lists, and other things all employed to help get everybody where they want to be.
This is why data management exists, for example. We see it as document management, content management, PDM, PLM, Source Code management. We want to know there is a place where "the truth" is, and we want to know how we need to interact to get where ever it is we are going too.
Applying this concept to a person attempting to write a program might not be a bad idea. Instead of offering them more information and options, just manage that whole thing so they remain more focused on the task at hand, not so much meta-tasks at hand.
For a given problem, there is the work to be done, right? That might look something like this:
Identify the sensor, identify the embedded system, pins, and the hardware overall.
Identify the data provided by the sensor.
Identify how that data is used, what decisions and outcomes are needed to accomplish whatever it is.
From there, write a program!
Meta-tasks:
Build scripts.
Declarations of various kinds. (some of these are needed for the board and hardware, so there is grey area here, and we see "configs for boards" as one means of addressing this meta-task)
File names, locations.
Development environment.
And so on...
Really, if this were boiled down into some abstract, perfect world, the code itself isn't much! It's everything that is the context for the code that people struggle with.
Another way to put this:
I like inline assembly. I like it, because when inline is well implemented, the higher level language provides nearly all of the context. I can literally think up a few instructions, put them there, and know they will do what I want them to do.
Forget the non-portable nature for a moment. Different discussion.
I do this, because something in the HLL is lacking in some way. Maybe it's speed, or math. Whatever it is. Doesn't matter. I'm in a place where I need to either get something for my HLL, or work my problem in a way that is better suited to the HLL, or eliminate a requirement to favor the HLL, or get faster hardware to improve the HLL. Whatever.
Now, if I were to tackle the entire problem in assembly language, that's a mess! There is almost NO context for assembly, which means the programmer needs to specify everything. This is why we got higher level languages, and C in particular anyway! It's easier to have some context, so that we can focus on writing the code and getting there instead of all these meta tasks needed to establish context.
That in-line assembly gets the benefit of a memory map of some sorts (usually), it can use the labels and variables in my program, and it's right there, in-line, not some other file, so I can work with it in the context of the other things I'm doing.
We like COG objects for similar reasons. Once you've got one, you either include it, or paste it into your file, and the inputs and outputs of it are generally compartmentalized. Once it's there, it's there. Almost like adding hardware is.
Getting back to writing an assembly language program then. I've got to specify it all, then I've got to write lots of instructions, manage every bit, and potentially interact with other programs, or some HLL or other, and now I'm in the weeds. Too much detail.
I know, Chip uses assembly language, and I would argue he's built up a context with few dependencies, which makes it lean for his purposes, which are well defined. I also know some of us use HLL a lot for portability, and again, there are contexts built up over time, which make things lean. This is the benefit of experience.
The problem area is where people just don't have that experience. The reasons vary.
Maybe that helps to articulate what I'm getting at here. To some degree, the Arduino people understood this, and they hid a lot of things, leaving users to focus on their task more than meta-tasks. And I would argue they were successful in that they have a lot of users doing a lot of tasks too. And that's the goal, however one gets there.
So what if there was a tool that presented an interface to C that is highly managed? It provides a lot of context, doing more than hiding things from the user, but actually doing some of the work for the user? A lot of that work can be rote work.
I think that could end up looking a whole lot like SPIN does. And the beauty of it would be the user could just run with that, no worries. Maybe it's enough, and they are happy. If not, they can leave the managed space, and look at their program in it's entirety. From there, they use whatever tools they want to. So the product of this tool would be a C program anyone would understand, and it's standard. The user just didn't write all of it, unless they want to. Their partner, the tool, will have just done the right thing for them where it makes sense, and is possible to do.
There is a similar kind of thing in my CAD program I use. I go to manipulate some geometry, and it sees a variety of things, like I would. And rather than take me through all the drudgery of performing or confirming the task, it just does the right thing and I see that. If it's not the right thing, I'm offered a few choices, or can choose to dig deeper and go do it myself.
The net result is the number of things I have to keep in my head is significantly lower than it was with older, dumber CAD, where making changes required I parse the geometry, make the changes, add new things, and then verify the result makes sense geometrically, and that it's actually manifold in that it could be manufactured as a real world thing. The latter was a problem early on. People could, would, and did often make constructs that could not be mapped to the real world. Goofy things like not having each edge of a part shared by two and only two surfaces. That's manifold, and that's how the real world works and is.
Back then, people would construct things where several surfaces would all share an edge. The truth is a radius or multiple radii would be needed to describe something real, and there were checkers, wizards, assistants, and sometimes, limited workflows all aimed at preventing people from making nonsense models, or when they changed them, turning good models into nonsense.
The solution was to make the software a lot smarter. We got geometry kernels, and we got constraint managers, and those took much of the context out of the users hands, which meant taking a lot of things out of their head, which improved their ability to get the real task done. Even simple things like measuring something, then typing in a number meant errors. Software improved so that one could specify something by measuring something else entirely, reducing the numerical input provided by the user to those given numbers they are the source of, all else being computed or measured. Fat finger errors were reduced dramatically.
Today, engineers making models enjoy smart software that handles a ton of the context for them.
During this time, software engineers were also making models, and both are code like, in that there are parameters, relationships, decisions, and lots of files. Software people built up data management and we see the product of that today. SVN, Mercurial, etc... CAD focused on the context, and is now focusing on data management. A bit late, but still welcome. Today, we see smart CAD systems able to manage data for people, and it's kind of awesome.
Maybe it's time to go back and tackle some of the context problems in software. With CAD, we used to draw the object directly. A cube required a user create a bunch of lines, or planar surfaces, make them the right size, put them in the right place and trim them so that they all touched. Some time later, defining a cube meant describing how a cube is to be made and what it's function is. The CAD system would then create the cube. The little things, which caused a lot of pain and made the task hard for people unfamiliar with geometry, manifolds, surfaces, vertices, etc... just went away.
This smarter tool would parse what a user is writing and populate things, or fill in blanks, or offer choices so the user can just take them and go, or simply not have to worry about them, where possible. The trade-off would be less efficient code, or maybe working with a smaller set of functions, operators, etc... inherent in the language, but that would also bring better focus on the primary tasks too.
Again, in CAD, we lost a lot of technical CAD functions when we moved to a more structured style of create. Sometimes those things are still needed, and sometimes they still get used a lot, particularly when CAD is used in an abstract way, not for making real world manufacturable things, but inexperienced people don't worry about any of that stuff either.
I guess I agree but I don't think it's a severe enough defect to condemn the entire language. It's something I can live with and so can many other people. It actually has the advantage that you can distribute binary forms of libraries along with a header file if you want to protect your trade secrets in the code itself. Of course, many here will think you shouldn't be writing proprietary code in the first place...
I can also live with it and understand why they're necessary. Like I said earlier, it would be easy to have your makefile call a simple program that generates header files for you and I should probably be doing that instead of complaining about a 40 year old standard.
Having separate prototypes and function bodies isn't my only problem with C. I listed a few other things I don't like about the language in a previous post. However, my main problem isn't as much with C as a language in general as with C as a language for use with the propeller.
I should try out Catalina. I'll probably like it better than GCC (which was never designed to compile stuff for something with only 32KB of ram).
Isn't that a totally brain dead and wrong way to be designing a class hierarchy?
What you are saying is that a parent class needs pointers to one( or more) of it's child classes. That just seems wrong. A class should stand alone, independent of it's children.
The only reason a class would need to have knowledge of it's children is if it needs some data or methods that they are going to have when you write them, if ever. But that implies the parent is badly designed, why does it not have that data or methods already in it's own definition?
C++ gurus, am I think this through backwards or what?
Of course JavaScript thinks your Python hello world is a novel.
JS:
"Hello World!"
That would be a totally brain dead and wrong way to design a class hierarchy. You misunderstood me. I meant parents and children as in a tree or something, not class inheritance.
A book object has an array of pointers to page objects, each page object has a pointer back to its containing book.
That JS example was only made to work so people like you can brag how short their hello world programs are.
I can also live with it and understand why they're necessary. Like I said earlier, it would be easy to have your makefile call a simple program that generates header files for you and I should probably be doing that instead of complaining about a 40 year old standard.
The Arduino already has a preprocessor like that but it's written in Java.
I should try out Catalina. I'll probably like it better than GCC (which was never designed to compile stuff for something with only 32KB of ram).
You can certainly try Catalina. It's a nice product. However, I think the CMM memory model in PropGCC generates more compact code so you could argue it is better suited to the limited RAM in a Propeller. In any case, whether PropGCC or Catalina have better code density, both are pretty good. Maybe you're thinking of the standard C libraries that don't fit well on the Propeller? Try the Simple Libraries that come with SimpleIDE or just do without libraries entirely. Spin doesn't have libraries. There is no reason you can't just use the PropGCC compiler without any libraries other than the simple ones that handle multiply, divide, and certain other low-level functions.
If it's all about "type it here, press F10 and go", that can happen with C, just as it can with SPIN + PASM. Just a thought I had a while back worth dropping here.
It's a thought the Arduino creators had back in 2005. Excpet they do it with C++ which makes things even nicer for the user.
Aside: It's amazing to think that Arduino exists in large part because of Parllax and the BASIC Stamp.
"Did you mean this?" kind of thing. ... So then, instead of a tool, you get a partner.
The way you describe it it sounds really annoying. Like Clippy. But there are times when I do like this. In C/C++ of course the editor can highlight/underline syntactic errors or warnings. Why wait till compile time for that to show up? In JavaScript my editor indicates constructs that while perfectly legal are common sources of bugs. Poorly chosen comparison operators, missing semicolons etc.
One thing I don't like about "exactly two places" is generally one of them is wrong.
It's a fundamental idea in software engineering that keeping only a single copy of anything is going to be far less buggy than keeping many copies in synch. However in the case of C function declarations the compiler cross checks them every time anyway. In practice it's not a problem. You can think of it as the stuff in the header file is the single gardian of the truth and all implementations and users of those definitions have to comply with that.
One thing I don't like about "exactly two places" is generally one of them is wrong.
You can avoid this by simply making sure that you always include the header file in the source file that defines the function. Then the compiler will complain if the prototype doesn't match the function definition.
Just wanted to explore the idea of a smarter environment. @Heater, yes it would be potentially annoying to people used to and good at doing it how it's done now. However, it might get considerably less annoying once it got good enough.
I'll probably like it better than GCC (which was never designed to compile stuff for something with only 32KB of ram).
Who says?
GCC is what is used by the Arduino. The Uno only has 32K of FLASH and 5 of that is taken for the boot loader. And all of 2K RAM.
GCC is usable on AVRs with a lot less space.
GCC is used for all kind of small memory devices. Like the Motorola 6809.
propgcc can compile code to run entirely within the 496 LONGs of a COG, native PASM. I have written a version of FullDuplexSerial in C that does exactly that. How much smaller do you want GCC to compile code for?
Do you have any evidence that Catalina generates smaller code?
I meant parents and children as in a tree or something, not class inheritance....A book object has an array of pointers to page objects, each page object has a pointer back to its containing book.
OK, I'm with you now. Looks like a problem.
Perhaps your object model is wrong.
If a book can point to pages and pages can point to the book (or other books) then what we have is a graph. The nodes of the graph are the books and pages. The edges of the graph are those pointers linking everything up.
Clearly both books and pages are instances of nodes.
That tells me that both Book and Page classes should be derived from a Node class.
Of course Book and Page may well already be derived from some other class or classes so now we are the world of multiple inheritance and the complete nightmare that entails.
Alternatively this may not be an inheritance relation, perhaps it's a "has a" relation where nodes can have books or nodes can have pages or whatever else a node may carry around.
Or is it the other way around that Books and Pages both "have" Nodes.
Basically what you are missing in your simple "book and page" model is a concept of "node in a graph"
Or is that if you actually do have circular references in your data it perhaps a good idea to point that out by using a forward reference in your code?
All in all the crappy class based, object oriented paradigm is the problem here, which is of course a problem that Java has but worse. At least in C++ you don't have to use classes.
That JS example was only made to work so people like you can brag how short their hello world programs are.
You make it sound like that Hello World example is somehow a special case in JS that they "rigged" to make a short Hello World program possible.
Could not be further from the truth. The JS REPL evaluates whatever JS you type into it and spits out the result. Typing in "2 + 3" will print "5". Type the name of a function and it will print whatever that function returns. A string, like "Hello World" is a valid JS expression so that's what it prints.
There is no "only made to work" about it. It's not a special case it's just what JS does.
Just a thought experiment. Assume the Spin IDE is still available for Spin users when the Prop-2 comes out. Now the stretch... let's assume Parallax or Arduino or a third party put in the work to add the Prop-2 as a programmable device in the Arduino IDE. Would Parallax GCC users have an issue with this to the point they would abandon the Prop-2? Separately, is there a good chance current Arduino users would try the Prop-2 under this condition? I certainly would. Do you think Arduino users would flock to the Parallax IDE for the Prop-2?
It's only a joke if you think losing customers and credibility is funny.
If I get one bad meal from a restaurant I will never go back. If credibility matters to you...you better get it right.
If P2 is released with bugs it will probably sink the company. Damage to Parallax's reputation could be insurmountable. The American car industry was unable to win back an entire generation of car buyers. It's doubtful they will ever enjoy market dominance again.
Now the stretch... let's assume Parallax or Arduino or a third party put in the work to add the Prop-2 as a programmable device in the Arduino IDE. Would Parallax GCC users have an issue with this to the point they would abandon the Prop-2?
You are new to this game aren't you?
As far as I know the Arduino IDE and SimpleIDE and for sure GCC itself are Free and Open Source software.
Note the capitalization there and do google around to find out what those terms really mean today.
What that means is that anyone anywhere can take any parts of any of that software and mix it up as much as they like. Provided they offer their modified sources along with any binaries they distribute.
Do what you like, go crazy, nobody cares.
If it turns out to be useful and popular you may become famous and respected world wide like Linus Torvalds.
If you are just making a "pigs ear", well perhaps you learn something on the way. It's all good.
So, as your username is "tryit" I suggest you just try it and see how it goes.
What that means is that anyone anywhere can take any parts of any of that software and mix it up as much as they like. Provided they offer their modified sources along with any binaries they distribute.
The point of the thought experiment was to understand if it's even worth going through the trouble of modifying the Arduino IDE to accept the Prop-2. From a business perspective, it should be in Parallax's best interest to win over Arduino users - Prop2 on the Arduino IDE seems obvious. As a microcontroller enthusiast, all the different open source IDEs make about as much sense as different computer languages. A common language, C, and a common IDE used by a majority is the logical approach, IMHO. Parallax started it all with the Basic Stamp. I'd like to see them on top again.
...it should be in Parallax's best interest to win over Arduino users...
I can go with that idea. Never mind Arduino users. What about Raspberry Pi users? Or Beagle users? Or the millions of users of all kind of other stuff?
Prop2 on the Arduino IDE seems obvious
And here I believe is the fatal flaw in your plan.
Let's assume a Propeller 1 or 2 can be used from the Arduino IDE.
Let's assume that this all works so well that an Arduino user cannot tell if he is using an ATMEL AVR on his board or a Propeller.
Great.
But what is the frikken point? That Arduino user already has a dumb Smile normal MCU with the AVR. Why would he pay more for a Propeller? Especially since any such imitation will not be perfect and things will not work the way he expects.
If you think it's a good idea you are very free to do it. "Show us the code" and all that. Maybe it gets traction, who knows?
I can go with that idea. Never mind Arduino users. What about Raspberry Pi users? Or Beagle users? Or the millions of users of all kind of other stuff?
And here I believe is the fatal flaw in your plan.
Let's assume a Propeller 1 or 2 can be used from the Arduino IDE.
Let's assume that this all works so well that an Arduino user cannot tell if he is using an ATMEL AVR on his board or a Propeller.
Great.
But what is the frikken point? That Arduino user already has a dumb Smile normal MCU with the AVR. Why would he pay more for a Propeller? Especially since any such imitation will not be perfect and things will not work the way he expects.
If you think it's a good idea you are very free to do it. "Show us the code" and all that. Maybe it gets traction, who knows?
Why can't the Propeller library be a superset of the AVR library exposing all of the multi-COG goodness of the Propeller along with the more mundane features that also run on the AVR?
Why can't the Propeller library be a superset of the AVR library exposing all of the multi-COG goodness of the Propeller along with the more mundane features that also run on the AVR?
I am very sure it could be.
In the wonderful virtual playground of software all such mutant combinations are possible. However in reality these deviants do not fly.
I would argue that a thing like the Arduino is a big success in large part because every Arduino is the same. That huge community of users can share projects and code snippets and information and advice and provided it is actually correct it will work for you with your board in the USA as much as it will work for some kid in a yurt in Mongolia.
Similarly for the Raspberry Pi.
Similarly for many decades in the world of the PC and DOS and then Windows.
These network effects, propagated by means of a monoculture platform, are huge.
So yes, bolt Propeller functionality into Arduino infrastructure. Will it set the world on fire and gain traction? I very much doubt it.
Why can't the Propeller library be a superset of the AVR library exposing all of the multi-COG goodness of the Propeller along with the more mundane features that also run on the AVR?
I am very sure it could be.
In the wonderful virtual playground of software all such mutant combinations are possible. However in reality these deviants do not fly.
I would argue that a thing like the Arduino is a big success in large part because every Arduino is the same. That huge community of users can share projects and code snippets and information and advice and provided it is actually correct it will work for you with your board in the USA as much as it will work for some kid in a yurt in Mongolia.
Similarly for the Raspberry Pi.
Similarly for many decades in the world of the PC and DOS and then Windows.
These network effects, propagated by means of a monoculture platform, are huge.
So yes, bolt Propeller functionality into Arduino infrastructure. Will it set the world on fire and gain traction? I very much doubt it.
Are you saying that all of the variants of the Arduino that use its IDE are identical, even the ones with ARM or PIC32 processors? Even different PCs have different peripherals.
OK. To be honest I don't know so much about the Arduino world. I have used AVRs and ARMs and never felt the need of the hand holding of the Arduino environment. My impression, and I could be way off, is that those ARM and PIC32 Arduinos are the new kids on the block. That they account for a very small fraction of current Arduino usage. In fact I don't know why anyone would "upgrade" themselves to those devices when things like Raspberry Pis and Beagles are around.
But let's assume I'm wrong. That those ARM and PIC32 Arduinos are actually wildly popular because, well, they are Arduinos. And now we throw a Frankenstien Propeller-Arduino in there.
My argument still stands. The Franken-Propdiono is not an original Arduino nor a supported new member of the family. It's a freak side show.
Yes different PCs have different peripherals. But you cannot deny that the chain of backwards compatibility in the x86 architecture and the software from MS has carried most of the worlds computer users along for decades.
OK. To be honest I don't know so much about the Arduino world. I have used AVRs and ARMs and never felt the need of the hand holding of the Arduino environment. My impression, and I could be way off, is that those ARM and PIC32 Arduinos are the new kids on the block. That they account for a very small fraction of current Arduino usage. In fact I don't know why anyone would "upgrade" themselves to those devices when things like Raspberry Pis and Beagles are around.
But let's assume I'm wrong. That those ARM and PIC32 Arduinos are actually wildly popular because, well, they are Arduinos. And now we throw a Frankenstien Propeller-Arduino in there.
My argument still stands. The Franken-Propdiono is not an original Arduino nor a supported new member of the family. It's a freak side show.
Yes different PCs have different peripherals. But you cannot deny that the chain of backwards compatibility in the x86 architecture and the software from MS has carried most of the worlds computer users along for decades.
I don't really want the hand-holding of the Arduino IDE either. I was just thinking that supporting the ASC+ with the Arduino IDE but adding additional functions to support the Propeller might make a good way for Arduino users to transition to the Propeller.
I was just thinking that supporting the ASC+ with the Arduino IDE but adding additional functions to support the Propeller might make a good way for Arduino users to transition to the Propeller.
Yes. And I'm telling you as an Arduino user, I'd flip to the Prop-2 instantly and drop the Arduino Due.
Look, I'm not suggesting dropping the Parallax IDE for Spin and other languages. You need to make your current customers happy. But if you want to expand your market share, the Arduino IDE with Prop-2 functionality is an obvious way to attract Arduino users. Especially for those who wish to upgrade from the Uno or Due, but don't need the expensive Tre. How to attract R-Pi users? That's a different story. Prop-3.
I certainly hope Spin. It fits the propeller infinitely better and is much easier to use (not to mention get started with) than C.
Why did Parallax decide to put so much emphasis into C on the propeller? Is it to try to rescue arduino fans? That's the only real reason I can think of. It seems like they're mainly using it for education. Why would you teach someone a really hard language and then show them that it's better done with a much simpler language?
Spin is simpler than C? That's great. I learned to program on parallax microcontrollers and I see no reason for me to change.
The 32bit Arduino platforms have always been aimed at beginners and non-techies who need hand holding and extra processing power/memory. The gurus could always buy a el-cheapo and disposable RPI and be ready to rock. And why should anyone would go overkill with a RPI or BBB when specific apps may only require a bit more processing power or memory than a 8 bit AVR?A 28 pin PIC32 or ARM will do just fine.
Not every app needs a 700 Mhz ARM SOC running Linux.
As for winning part ot the Arduino market segment. Possible if Parallax backs the effort. But it should have been done years ago when there was only the 8 bitters to compete with. Now the ecosystem has grown tremendously. Hobbyists now have a wide choice of Arduino variants like the Pinguino(PIC32 and 8 bit Microchip), Energia(MSp430, TI ARM's and DSP); Mbed's C++ online compiler that supports about 14 very low cost ARM boards. Or something like Geoff's Micromite BASIC.
That's a tough market for the Prop to standout in. You won't do it in terms of cost. NXP has a whole line of $10 M4 and M0+ boards, The TI Launchpad line is equally dirt cheap, Freescale has their own low cost line, Cypress has $6 PSOC boards and so on. You're going to have come up with a reason why the Prop is so much better for hobbyists as opposed to the other options out there.
Well, it's about as unclear to me as it is to you, to be honest, so I must not be a marketing guru. To make it a success we'd need to put massive support behind it - Arduino IDE compatibility, hardware design (and sell it for nothing), etc. This means we'd abandon efforts around Propeller 1 C Learning System and other much-needed product upgrades we have planned. It's never appeared to be a very clear task to us, to be truthful.
We admit to having lost some market share to Arduino, but to pursue it at this point we'd really have to want to do it. Do I want to spend my next year's effort and at least a handful of our staff's time to make this come true, not to mention gathering support from the Arduino creators? It could be a fine business move, but perhaps not exactly what I envision as my dream job. If we're already productive and happy doing what we do, and making money in the ultra-competetive low-cost PCB effort with a Propeller Arduino is the only driving force I don't see why we'd do it. Everybody is already into Arduinos one way or another, so it's really very crowded.
Four years ago it would've been easier for us to do this.
Heck, I think I'm happy just being the company we are.
Four years ago it would've been easier for us to do this.
At the rate the microcontroller market is moving, one has to wonder what it will look like 4 years from now. On the other hand, I understand your resources are limited and only so much can be done.
Perhaps establishing a high level relationship with Massimo Banzi would be beneficial to everyone. A mere endorsement by you and Banzi might inspire passionate people to marry Prop-2 and Arduino.
That said, I fully respect your plan and nothing can be better than having a productive and happy company as a result of living a dream job. I can only aspire to such a feat.
[QUOTE= Heck, I think I'm happy just being the company we are. Ken Gracey[/QUOTE]
I'm perfectly happy with Parallax just the way it is. I'd be less happy if anything was done solely in the interest of money. To me Parallax is a ma and pa (OK brother and brother) company that is in tune with its customers and cares. FWIW. Thanks Ken and Chip
Comments
Twice is once too many.
Go
For some time, I've been thinking about C and these basic differences. New job has given me, or forced me into --depending on perspective, some drive time to mull things over.
IMHO, this comes down to how many things a person needs to know in order to do something, and how many states they need to be aware of while doing it, and what is familiar to them.
Seems to me, a killer C environment for people who prefer that lean, "single file" option SPIN + PASM provides them, might be something managed. The programmer gets presented with a place to write code. And they write it. In the background, the other stuff gets created as what they write is being parsed.
We see hints of this kind of thing in Visual Studio, which does all sorts of things to get the programming moving forward. Maybe it makes sense to push that boundary some.
An editor could be doing all sorts of stuff for you. To the experienced person, this may seem intrusive. Probably it is. But, not everybody has the body of familiarity needed to program from the command line, or work in an editor, then build with a script, whatever.
If it's all about "type it here, press F10 and go", that can happen with C, just as it can with SPIN + PASM. Just a thought I had a while back worth dropping here.
Basically, encode the common understanding into the tool. People write code, and that tool parses it, produces the meta-information needed for the compiler, etc... and it goes interactive when needed. "Did you mean this?" kind of thing.
So then, instead of a tool, you get a partner. Smart software that keeps you on task, potentially guiding you toward mastery, or best practices by making those paths as friction free as possible.
One thing I don't like about "exactly two places" is generally one of them is wrong. That is a gut level reaction, and it's due to my manufacturing background. Single sources of truth are extremely valuable. Where there are multiple ones, not associative in any way, where humans basically have to do the work, generally that work is wrong, until those humans get acclimated to the various disciplines, skills, methods, processes, means, culture needed to insure the work isn't wrong. And because of that, there is a lot of meta-activity, such as QA, check lists, and other things all employed to help get everybody where they want to be.
This is why data management exists, for example. We see it as document management, content management, PDM, PLM, Source Code management. We want to know there is a place where "the truth" is, and we want to know how we need to interact to get where ever it is we are going too.
Applying this concept to a person attempting to write a program might not be a bad idea. Instead of offering them more information and options, just manage that whole thing so they remain more focused on the task at hand, not so much meta-tasks at hand.
For a given problem, there is the work to be done, right? That might look something like this:
Identify the sensor, identify the embedded system, pins, and the hardware overall.
Identify the data provided by the sensor.
Identify how that data is used, what decisions and outcomes are needed to accomplish whatever it is.
From there, write a program!
Meta-tasks:
Build scripts.
Declarations of various kinds. (some of these are needed for the board and hardware, so there is grey area here, and we see "configs for boards" as one means of addressing this meta-task)
File names, locations.
Development environment.
And so on...
Really, if this were boiled down into some abstract, perfect world, the code itself isn't much! It's everything that is the context for the code that people struggle with.
Another way to put this:
I like inline assembly. I like it, because when inline is well implemented, the higher level language provides nearly all of the context. I can literally think up a few instructions, put them there, and know they will do what I want them to do.
Forget the non-portable nature for a moment. Different discussion.
I do this, because something in the HLL is lacking in some way. Maybe it's speed, or math. Whatever it is. Doesn't matter. I'm in a place where I need to either get something for my HLL, or work my problem in a way that is better suited to the HLL, or eliminate a requirement to favor the HLL, or get faster hardware to improve the HLL. Whatever.
Now, if I were to tackle the entire problem in assembly language, that's a mess! There is almost NO context for assembly, which means the programmer needs to specify everything. This is why we got higher level languages, and C in particular anyway! It's easier to have some context, so that we can focus on writing the code and getting there instead of all these meta tasks needed to establish context.
That in-line assembly gets the benefit of a memory map of some sorts (usually), it can use the labels and variables in my program, and it's right there, in-line, not some other file, so I can work with it in the context of the other things I'm doing.
We like COG objects for similar reasons. Once you've got one, you either include it, or paste it into your file, and the inputs and outputs of it are generally compartmentalized. Once it's there, it's there. Almost like adding hardware is.
Getting back to writing an assembly language program then. I've got to specify it all, then I've got to write lots of instructions, manage every bit, and potentially interact with other programs, or some HLL or other, and now I'm in the weeds. Too much detail.
I know, Chip uses assembly language, and I would argue he's built up a context with few dependencies, which makes it lean for his purposes, which are well defined. I also know some of us use HLL a lot for portability, and again, there are contexts built up over time, which make things lean. This is the benefit of experience.
The problem area is where people just don't have that experience. The reasons vary.
Maybe that helps to articulate what I'm getting at here. To some degree, the Arduino people understood this, and they hid a lot of things, leaving users to focus on their task more than meta-tasks. And I would argue they were successful in that they have a lot of users doing a lot of tasks too. And that's the goal, however one gets there.
So what if there was a tool that presented an interface to C that is highly managed? It provides a lot of context, doing more than hiding things from the user, but actually doing some of the work for the user? A lot of that work can be rote work.
I think that could end up looking a whole lot like SPIN does. And the beauty of it would be the user could just run with that, no worries. Maybe it's enough, and they are happy. If not, they can leave the managed space, and look at their program in it's entirety. From there, they use whatever tools they want to. So the product of this tool would be a C program anyone would understand, and it's standard. The user just didn't write all of it, unless they want to. Their partner, the tool, will have just done the right thing for them where it makes sense, and is possible to do.
There is a similar kind of thing in my CAD program I use. I go to manipulate some geometry, and it sees a variety of things, like I would. And rather than take me through all the drudgery of performing or confirming the task, it just does the right thing and I see that. If it's not the right thing, I'm offered a few choices, or can choose to dig deeper and go do it myself.
The net result is the number of things I have to keep in my head is significantly lower than it was with older, dumber CAD, where making changes required I parse the geometry, make the changes, add new things, and then verify the result makes sense geometrically, and that it's actually manifold in that it could be manufactured as a real world thing. The latter was a problem early on. People could, would, and did often make constructs that could not be mapped to the real world. Goofy things like not having each edge of a part shared by two and only two surfaces. That's manifold, and that's how the real world works and is.
Back then, people would construct things where several surfaces would all share an edge. The truth is a radius or multiple radii would be needed to describe something real, and there were checkers, wizards, assistants, and sometimes, limited workflows all aimed at preventing people from making nonsense models, or when they changed them, turning good models into nonsense.
The solution was to make the software a lot smarter. We got geometry kernels, and we got constraint managers, and those took much of the context out of the users hands, which meant taking a lot of things out of their head, which improved their ability to get the real task done. Even simple things like measuring something, then typing in a number meant errors. Software improved so that one could specify something by measuring something else entirely, reducing the numerical input provided by the user to those given numbers they are the source of, all else being computed or measured. Fat finger errors were reduced dramatically.
Today, engineers making models enjoy smart software that handles a ton of the context for them.
During this time, software engineers were also making models, and both are code like, in that there are parameters, relationships, decisions, and lots of files. Software people built up data management and we see the product of that today. SVN, Mercurial, etc... CAD focused on the context, and is now focusing on data management. A bit late, but still welcome. Today, we see smart CAD systems able to manage data for people, and it's kind of awesome.
Maybe it's time to go back and tackle some of the context problems in software. With CAD, we used to draw the object directly. A cube required a user create a bunch of lines, or planar surfaces, make them the right size, put them in the right place and trim them so that they all touched. Some time later, defining a cube meant describing how a cube is to be made and what it's function is. The CAD system would then create the cube. The little things, which caused a lot of pain and made the task hard for people unfamiliar with geometry, manifolds, surfaces, vertices, etc... just went away.
This smarter tool would parse what a user is writing and populate things, or fill in blanks, or offer choices so the user can just take them and go, or simply not have to worry about them, where possible. The trade-off would be less efficient code, or maybe working with a smaller set of functions, operators, etc... inherent in the language, but that would also bring better focus on the primary tasks too.
Again, in CAD, we lost a lot of technical CAD functions when we moved to a more structured style of create. Sometimes those things are still needed, and sometimes they still get used a lot, particularly when CAD is used in an abstract way, not for making real world manufacturable things, but inexperienced people don't worry about any of that stuff either.
Just a thought. Now it's out there. Carry on all.
I can also live with it and understand why they're necessary. Like I said earlier, it would be easy to have your makefile call a simple program that generates header files for you and I should probably be doing that instead of complaining about a 40 year old standard.
Having separate prototypes and function bodies isn't my only problem with C. I listed a few other things I don't like about the language in a previous post. However, my main problem isn't as much with C as a language in general as with C as a language for use with the propeller.
I should try out Catalina. I'll probably like it better than GCC (which was never designed to compile stuff for something with only 32KB of ram).
That would be a totally brain dead and wrong way to design a class hierarchy. You misunderstood me. I meant parents and children as in a tree or something, not class inheritance.
A book object has an array of pointers to page objects, each page object has a pointer back to its containing book.
That JS example was only made to work so people like you can brag how short their hello world programs are.
Aside: It's amazing to think that Arduino exists in large part because of Parllax and the BASIC Stamp. The way you describe it it sounds really annoying. Like Clippy. But there are times when I do like this. In C/C++ of course the editor can highlight/underline syntactic errors or warnings. Why wait till compile time for that to show up? In JavaScript my editor indicates constructs that while perfectly legal are common sources of bugs. Poorly chosen comparison operators, missing semicolons etc. It's a fundamental idea in software engineering that keeping only a single copy of anything is going to be far less buggy than keeping many copies in synch. However in the case of C function declarations the compiler cross checks them every time anyway. In practice it's not a problem. You can think of it as the stuff in the header file is the single gardian of the truth and all implementations and users of those definitions have to comply with that.
Just wanted to explore the idea of a smarter environment. @Heater, yes it would be potentially annoying to people used to and good at doing it how it's done now. However, it might get considerably less annoying once it got good enough.
GCC is what is used by the Arduino. The Uno only has 32K of FLASH and 5 of that is taken for the boot loader. And all of 2K RAM.
GCC is usable on AVRs with a lot less space.
GCC is used for all kind of small memory devices. Like the Motorola 6809.
propgcc can compile code to run entirely within the 496 LONGs of a COG, native PASM. I have written a version of FullDuplexSerial in C that does exactly that. How much smaller do you want GCC to compile code for?
Do you have any evidence that Catalina generates smaller code? OK, I'm with you now. Looks like a problem.
Perhaps your object model is wrong.
If a book can point to pages and pages can point to the book (or other books) then what we have is a graph. The nodes of the graph are the books and pages. The edges of the graph are those pointers linking everything up.
Clearly both books and pages are instances of nodes.
That tells me that both Book and Page classes should be derived from a Node class.
Of course Book and Page may well already be derived from some other class or classes so now we are the world of multiple inheritance and the complete nightmare that entails.
Alternatively this may not be an inheritance relation, perhaps it's a "has a" relation where nodes can have books or nodes can have pages or whatever else a node may carry around.
Or is it the other way around that Books and Pages both "have" Nodes.
Basically what you are missing in your simple "book and page" model is a concept of "node in a graph"
Or is that if you actually do have circular references in your data it perhaps a good idea to point that out by using a forward reference in your code?
All in all the crappy class based, object oriented paradigm is the problem here, which is of course a problem that Java has but worse. At least in C++ you don't have to use classes. You make it sound like that Hello World example is somehow a special case in JS that they "rigged" to make a short Hello World program possible.
Could not be further from the truth. The JS REPL evaluates whatever JS you type into it and spits out the result. Typing in "2 + 3" will print "5". Type the name of a function and it will print whatever that function returns. A string, like "Hello World" is a valid JS expression so that's what it prints.
There is no "only made to work" about it. It's not a special case it's just what JS does.
If P2 is released with bugs it will probably sink the company. Damage to Parallax's reputation could be insurmountable. The American car industry was unable to win back an entire generation of car buyers. It's doubtful they will ever enjoy market dominance again.
As far as I know the Arduino IDE and SimpleIDE and for sure GCC itself are Free and Open Source software.
Note the capitalization there and do google around to find out what those terms really mean today.
What that means is that anyone anywhere can take any parts of any of that software and mix it up as much as they like. Provided they offer their modified sources along with any binaries they distribute.
Do what you like, go crazy, nobody cares.
If it turns out to be useful and popular you may become famous and respected world wide like Linus Torvalds.
If you are just making a "pigs ear", well perhaps you learn something on the way. It's all good.
So, as your username is "tryit" I suggest you just try it and see how it goes.
As we say in these parts "Show me the code".
I just wish you could fix the American motorcycle industry. The whole world is enamoured by those prehistoric tractors made by Harley Davidson.
The point of the thought experiment was to understand if it's even worth going through the trouble of modifying the Arduino IDE to accept the Prop-2. From a business perspective, it should be in Parallax's best interest to win over Arduino users - Prop2 on the Arduino IDE seems obvious. As a microcontroller enthusiast, all the different open source IDEs make about as much sense as different computer languages. A common language, C, and a common IDE used by a majority is the logical approach, IMHO. Parallax started it all with the Basic Stamp. I'd like to see them on top again.
Let's assume a Propeller 1 or 2 can be used from the Arduino IDE.
Let's assume that this all works so well that an Arduino user cannot tell if he is using an ATMEL AVR on his board or a Propeller.
Great.
But what is the frikken point? That Arduino user already has a dumb Smile normal MCU with the AVR. Why would he pay more for a Propeller? Especially since any such imitation will not be perfect and things will not work the way he expects.
If you think it's a good idea you are very free to do it. "Show us the code" and all that. Maybe it gets traction, who knows?
OK. To be honest I don't know so much about the Arduino world. I have used AVRs and ARMs and never felt the need of the hand holding of the Arduino environment. My impression, and I could be way off, is that those ARM and PIC32 Arduinos are the new kids on the block. That they account for a very small fraction of current Arduino usage. In fact I don't know why anyone would "upgrade" themselves to those devices when things like Raspberry Pis and Beagles are around.
But let's assume I'm wrong. That those ARM and PIC32 Arduinos are actually wildly popular because, well, they are Arduinos. And now we throw a Frankenstien Propeller-Arduino in there.
My argument still stands. The Franken-Propdiono is not an original Arduino nor a supported new member of the family. It's a freak side show.
Yes different PCs have different peripherals. But you cannot deny that the chain of backwards compatibility in the x86 architecture and the software from MS has carried most of the worlds computer users along for decades.
Yes. And I'm telling you as an Arduino user, I'd flip to the Prop-2 instantly and drop the Arduino Due.
Look, I'm not suggesting dropping the Parallax IDE for Spin and other languages. You need to make your current customers happy. But if you want to expand your market share, the Arduino IDE with Prop-2 functionality is an obvious way to attract Arduino users. Especially for those who wish to upgrade from the Uno or Due, but don't need the expensive Tre. How to attract R-Pi users? That's a different story. Prop-3.
I respect your opinions, but that is just the wrong attitude. The real freak show is the loss of market share to Arduino.
Not every app needs a 700 Mhz ARM SOC running Linux.
As for winning part ot the Arduino market segment. Possible if Parallax backs the effort. But it should have been done years ago when there was only the 8 bitters to compete with. Now the ecosystem has grown tremendously. Hobbyists now have a wide choice of Arduino variants like the Pinguino(PIC32 and 8 bit Microchip), Energia(MSp430, TI ARM's and DSP); Mbed's C++ online compiler that supports about 14 very low cost ARM boards. Or something like Geoff's Micromite BASIC.
That's a tough market for the Prop to standout in. You won't do it in terms of cost. NXP has a whole line of $10 M4 and M0+ boards, The TI Launchpad line is equally dirt cheap, Freescale has their own low cost line, Cypress has $6 PSOC boards and so on. You're going to have come up with a reason why the Prop is so much better for hobbyists as opposed to the other options out there.
That's a job for the marketing gurus at Parallax.
Well, it's about as unclear to me as it is to you, to be honest, so I must not be a marketing guru. To make it a success we'd need to put massive support behind it - Arduino IDE compatibility, hardware design (and sell it for nothing), etc. This means we'd abandon efforts around Propeller 1 C Learning System and other much-needed product upgrades we have planned. It's never appeared to be a very clear task to us, to be truthful.
We admit to having lost some market share to Arduino, but to pursue it at this point we'd really have to want to do it. Do I want to spend my next year's effort and at least a handful of our staff's time to make this come true, not to mention gathering support from the Arduino creators? It could be a fine business move, but perhaps not exactly what I envision as my dream job. If we're already productive and happy doing what we do, and making money in the ultra-competetive low-cost PCB effort with a Propeller Arduino is the only driving force I don't see why we'd do it. Everybody is already into Arduinos one way or another, so it's really very crowded.
Four years ago it would've been easier for us to do this.
Heck, I think I'm happy just being the company we are.
Ken Gracey
At the rate the microcontroller market is moving, one has to wonder what it will look like 4 years from now. On the other hand, I understand your resources are limited and only so much can be done.
Perhaps establishing a high level relationship with Massimo Banzi would be beneficial to everyone. A mere endorsement by you and Banzi might inspire passionate people to marry Prop-2 and Arduino.
That said, I fully respect your plan and nothing can be better than having a productive and happy company as a result of living a dream job. I can only aspire to such a feat.
I'm perfectly happy with Parallax just the way it is. I'd be less happy if anything was done solely in the interest of money. To me Parallax is a ma and pa (OK brother and brother) company that is in tune with its customers and cares. FWIW. Thanks Ken and Chip
Aaron