Writing programs in another programming language, such as C?
Xemdo
Posts: 2
I don't like this Spin language. Some website with information about Spin said it's a mix of C, Python, and Delphi (which is Pascal), but there is no way it has C and Python it. I'm skilled in C, C#, Java, and C++ and I'm familiar with Python's syntax, but this language is so Delphi-like that I want to throw my microcontroller off a building.
I don't want to use assembly either. I've tried that before and I can't type things like
So is there anything more C-like?
I don't want to use assembly either. I've tried that before and I can't type things like
axl 24 86 wat 34 4124 stab 33 324 goto goodLuckFindingMe
So is there anything more C-like?
Comments
http://forums.parallax.com/forumdisplay.php?93-Propeller-GCC-Beta
https://sites.google.com/site/propellergcc/
This is also now available for PropGCC beta. CMM compresses the code to sizes comparable to SPIN...
But, SPIN is not so terribly different from C (although it has a definite Pascal smell to it).
(What I mean is that if you know C, you can figure SPIN out in just a few days...)
But, if you're really opposed to it, then Catalina and the new PropGCC will let you program in C...
http://forums.parallax.com/showthread.php?142627-Catalina-3.8
Spin is nothing like Python. Does Spin have dynamic typing, memory management, tuples, dictionaries, first class functions, closures etc? You can't do object oriented programming in Spin despite it's "objects". The similarities between Spin and Python are shallow. the use of white space delimiting blocks and other syntactic things.
Python on the Prop just won't fit, the run time is huge. If you contemplate the Prop architecture long enough you come to the conclustion that despite the fact that Spin is a pretty hopeless language it's an excellent fit to the job in hand.
Why would one not see C in the future of embedded systems?. C is a wondeful thing, it is what the Linux kernel and real-time embedded operating systems are written in. It won't go away in a hurry and in 40 years many have tried and failed to usurp it.
C++ is an a abomination I agree. Ada, it's OK, to verbose for my taste.
As for C not being the future of embedded systems, many who've given it much thought realize that C has many many weaknesses that later generation languages, especially, simply do not have. http://archive.adaic.com/docs/reports/lawlis/k.htm , http://archive.adaic.com/docs/reports/lawlis/j.htm
The language/environment doesn't make the programmer, but it can make his/her output better or worse. Also, some languages are better for certain tasks; C simply cannot be the best choice for *everything* and frankly, probably not even most things in the embedded space that it's now being used for.
A couple of other major differences off the top of my head:
What is the result of the following expressions in Spin and Python?
Actually Spin is a lot more like Pascal. It's out of the same block stuctured mould with a nod towards objects.
Is a cut down version of a language still the same language? How much normal Python code will work under pyMite?
Having been around embedded systems for a while I am aware of the weaknesses of C. I too would probably want to use Ada in seriously safety critical systems. A language I am quite fond of. However a few observations:
The report you linked to obviously has an agenda bias given that it is on a site promoting Ada.
As an example they go on about supprt for software engineering practices and give C a low rating. Reality is that if you want your code to work in any language applying good software engineering practices like, reviews, unit testing, coverage analysis, etc etc is essential anyway.
I have seen Ada projects grow into huge sprawling undecipherable messes that were impossible to maintain efficiently. And that was in safety critical aerospace applications.
Pretty much all modern traffic light controllers in Scandinavia are controlled by code written in C and running on Linux again written in C. They do not misbehave.
Traditionally C was selected for embedded microcontroller apps because it is a least possibel to fit the code in the small space and provide near assembler performance. I remember a time when Ada was just producing code that was too big and slow. There pretty much was no other choice.
Very different does not equal *entirely* different. Never mind, too, from what I understand it's generally been acknowledged that Python was one of the influences for Spin. To say they are *nothing* alike is the stretch (if there be one). Under normal circumstances, when one sees two languages with syntax this similar one can safely mention that there is a resemblance, a relatedness without it turning into a dustup.
I could do the very same thing with Ada and Pascal. Should we then assume those two have *nothing* in common?
Close enough it would seem, imo...
Supports integers, floats, tuples, lists, dicts, functions, modules, classes, generators, decorators and closures
- Supports 25 of 29 keywords and 89 of 112 bytecodes from Python 2.6
- Can run multiple stackless green threads (round-robin)
- Has a mark-sweep garbage collector
- Has a hosted interactive prompt for live coding
Again, talking about a full-blown Python implementation in this context is a needless distraction.I've been around a while too, 25+ years writing code in C and other languages. So yes, now we can agree - C has weaknesses, and I would not just limit those to "seriously" safety critical systems.
Yes, the report is hosted on an Ada-centric website (though it isn't clear that the operators of the site actually produced the report). Is that relevant? I'm more interested in what the report says, and what I know from first-hand experience to be true.
Correct. But that is not an argument for passing more potential problems off to the review stage, hoping they can be caught later. If the starting environment is neater, cleaner, less error prone, so much the better.
You might want to tell that to the agencies (esp. in Europe) that require Ada. jk Look, no one is saying that projects can't go awry in any particular language. So this is a red herring.
A good many things run on C and don't misbehave (much). Yet you yourself admit you wouldn't use C for "seriously" safety critical applications. Hence, there must be something to this.
Yes, C has been around a long time and is ubiquitous. That does not mean that, going forward, we should only be looking at C for new projects. C has been useful and will continue to be so in the future, but it was never the best solution in all situations and has grown somewhat long in the tooth now. So, in fine, my point is that it might be time to open up more to other options.
I'm sure Spin had many influences including Python, if only for the white space delimiting feature. Give the enormous differences between Spin and Python I don't saying they are nothing alike is a stretch. Yes their syntaxes and "look" have a resemblence but it's only skin deep. No dust up just a difference of opinion here.
pyMite sounds interesting, indeed impressive.
I'm not about to defend C to the death, as much as I love the old girl. And I'm not knocking Ada, which I quite like, or any other language. Just pointing out that many have tried to create new improved replacements for C with out much luck so far. Yes C++ and Java are hugely popular but they are a real pain in the neck as well. Ada is rigoros as it should be to fill its intended role but suffers from verboseness. I might ask why Linux, BSD, Windows, MacOS and pretty much every other OS are written in C? Where is the OS written in Ada or any other language?
I too am always checking out other options, that's why we are here on this forum and putting together Spin projects. Just now I'm looking into the new Go language which has the simplicity of C and almost as much of the type safety of Ada without being verbose. It has a super quick compile times putting some fun back into programming. Seems to be also small enough to get into small embedded systems, it runs on RTEMS for example.
STOP PRESS: Turns out OpenVMS contains Ada components. And C and pretty much every other language:)
http://h71000.www7.hp.com/faq/vmsfaq_002.html
Edit: As Xemdo said in the opening post "I'm familiar with Python's syntax, but this language is so Delphi-like that I want to throw my microcontroller off a building."
Just as you're not trying to defend C to the death, I'm not trying to kill it either. Obviously it's a very useful language and will be for a long long time to come. I do get annoyed, sometimes, at the C C C or else mentality, however, and that is what prompted my original post. I should also add that I'm not an Ada zealot either; but I think you'd agree that the language often doesn't get the attention it deserves. And who knows? Maybe it's getting long in the tooth now, and something else has (or is about to) come along that's better suited for safety critical stuff.
PyMite is indeed impressive, especially when you consider that it's not an "official" project or anything like one. As far as I know, there has been no support from Atmel (or any other chip mfr.). Just some guys who thought it'd be cool to run Python on a small micro. Obviously, I would not recommend it for a professional project, but what they've done is notable!
To my mind it is very much, conceptually, like C. Without C's structs and with the addition of a crude object approach. Yes I know the syntax is looking very different but in terms of capabilities its from the same mould as C, Pascal, PL/M and so on.
As I said, given the Props hardware architecture, Spin is a very good solution to the problem of how to program the thing. They could have gone for BASIC but that is old hat. C works offering a performance boost but eats memory. (The new CMM producing compilers have eased that issue a bit but at the cost of making C into an interpretted language on the Prop.)
Xemdo,
Do have a look at the Props assembly language, you may have been put off assembler on other micros but PASM is a very simple clean wondefull thing. Must be the easiest assembly language I have ever used.
Second the look at PASM. A great assembly language. Addictive.