Languages for the TROM

[Matt]

Okay, here we can have a knock down drag out debate over languages :D This should be fun to watch and I'll be the one standing waaaay over in the corner ontop of the dresser. :)

What language should the TROM be rewritten in?

Maybe we should list out what the defining factors are as well to help with the decision making process.

[Adrenalynn]

[Pardon the Crosspost]

I'm by no means "anti-windows" - but I am "pro-small-is-beautiful" - especially when embedding.

I would like to put forward a vote for C/C++ (I really don't like C++, but it sure wouldn't be that hard to make the port from C#). C/C++ are both "universal" (if you stay away from the weird libraries) and one would be hard-pressed to find an embedded system that didn't have a compiler/cross-compiler to support it.

Something that Dale mentioned: Java was originally (even as "Oak") intended to be used for these kinds of purposes. It's an embedded controller first-and-foremost originally.

Did I mention that I despise everything about Java? ;)

[LinuxGuy]

I would like to put forward a vote for C/C++ (I really don't like C++, but it sure wouldn't be that hard to make the port from C#). C/C++ are both "universal" (if you stay away from the weird libraries) and one would be hard-pressed to find an embedded system that didn't have a compiler/cross-compiler to support it.
I would have no problems going with C/C++. Like I said elsewhere, most (if not all) of the existing sources we are going to be dealing with is going to be C/C++. It's a no brainer for me.

Something that Dale mentioned: Java was originally (even as "Oak") intended to be used for these kinds of purposes. It's an embedded controller first-and-foremost originally.

Did I mention that I despise everything about Java? ;)
I've actually started to learn JAVA several times. I just never seem to get to coding anything of my own. I would vote for Python over JAVA if I had to make a choice between the two. I wouldn't be particularly interested in using JAVA.

8-Dale

[Adrenalynn]

I'm also somewhat concerned about "weight" of the code. I'm not sure that natively interpreted avenues are the best. I know I'm beating my own drum, but I think I'd like to see us remember the small embedded stuff. Moving our processing off to the 'bot will just continue to make them smarter in the future as the embedded hardware moves more into what the desktop market has today. I mean, I remember moving from the 8080 to the 6502 to the 680*0 to the 286 to the 386 to the 486, ... in the embedded space. It's always just two or three generations behind the desktop...

Java and Python, at a low-level (even compiled) will be very challenged to equal C/C++ in efficiency.

[Sienna]

I am good with C (I am a C hacker after all).

However, I am going to propose that we use C++. Because in this, I think we will need the pseudo object orientation that C++ provides.

However, I would like to direct everyone to the protocol thread, where I am discussing language abstraction.... :look

[Droid Works]

I suggest VB being that it is the only lang I use..lol and it is also the lang most of us bot junkies have in common.

[Adrenalynn]

Just a personal observation:

I'd rather have a dull rusty railroad spike driven through the side of my skull with a ballpean hammer. :P

[LinuxGuy]

I suggest VB being that it is the only lang I use..lol and it is also the lang most of us bot junkies have in common.
I've never used VB, or any MS language, for robotics. :tongue: I am occasionally tempted by MSRS, but then I come to my senses. :happy: I do have the latest (2008) C#, C/C++, and MSRS installed currently, just because I like to see what others are doing and using. I can gain inspiration even from Microsoft! :veryhappy::veryhappy: There will eventually come a time when I will want to develop for Windows, because I want to write some cross platform robotics tools (servo sequencer, etc) which I believe can be built on top of TROM.

8-Dale

[Alex]

I propose not to do it in Java. Even though Java is one of the only truely Object Oriented languages, Java is much too slow to be able to handle everything that users will be doing with the TRS (short term sure, but not long term).

I don't know C, but I've looked at C syntax and it seems fairly easy to pick up if I have to. However, is C Object Oriented? I didn't think it was...

I really don't have any interest nor desire to develop in non-object oriented languages. I know C is a very powerful language and all. But, it just seems like we're going backwards in time like using two sticks instead of lighters to make a fire:D

Plus, I have no idea what it will look like for users of the system if we develop it in C.

I can do C++ if necessary (I'll have to pick up my old textbooks though from school, haha) too.

Really, what it boils down to for me is:



is the language Object Oriented
can it support the protocol we all decide to use
Will it be fast enough to be able to handle future robotic applications


One of the reasons why I am such a huge fan of .NET languages (before anyone misunderstands me, NO I'm not proposing we develop in .NET:p) is because it is sooo easy to develop purely object oriented API's so that users of your library files can actually understand it fairly quickly.

[Droid Works]

Just a personal observation:

I'd rather have a dull rusty railroad spike driven through the side of my skull with a ballpean hammer. :P

Just out of curiosity why? VB is not only the easiest lang to use with win applications it a natural match for windows and robotics. Just my opinion.

[LinuxGuy]

I propose not to do it in Java. Even though Java is one of the only truely Object Oriented languages, Java is much too slow to be able to handle everything that users will be doing with the TRS (short term sure, but not long term).
I agree totally! Nix JAVA!

I don't know C, but I've looked at C syntax and it seems fairly easy to pick up if I have to. However, is C Object Oriented? I didn't think it was..
I actually did do a bit of development in C++ (which is OO grafted on top of C in many cases). The fit is not always good, but most basic OO stuff can be done without getting too far into the C++ end. I started with a game from a C++ book and modified it as I learned more from the book.

I really don't have any interest nor desire to develop in non-object oriented languages. I know C is a very powerful language and all. But, it just seems like we're going backwards in time like using two sticks instead of lighters to make a fire:D
You just need to look at some good tutorials for C++. I'm not proposing straight C either by any means. I really like the OO way of doing things and am very much looking forward to doing more with it. I am just one of those who needs a purpose before I care about learning something. I now have a purpose for more OO. :veryhappy: Some have even accused me of thinking in OO.

Really, what it boils down to for me is:


is the language Object Oriented
can it support the protocol we all decide to use
Will it be fast enough to be able to handle future robotic applications.


No problem with C/C++.

One of the reasons why I am such a huge fan of .NET languages (before anyone misunderstands me, NO I'm not proposing we develop in .NET:p) is because it is sooo easy to develop purely object oriented API's so that users of your library files can actually understand it fairly quickly.
This is all about documentation - internal within code and external. Document every procedure and function at the start of the routine and within it for every major section or difficult to understand section, with references to external documentation as needed.

8-Dale

[Alex]

Just out of curiosity why? VB is not only the easiest lang to use with win applications it a natural match for windows and robotics. Just my opinion.

VB (and I'm assuming you mean vb6, not .NET) is an easy language to use, but doesn't have even 1/100th of the tools necessary to build the TRS. VB isn't anywhere close to an Object Oriented language either. Plus, we've decided to not use any languages that are tied to any OS.

[Wingzero01w]

I say we should have: BASIC, C++, C#, C, Java, and Python... o wait isnt this basically all of them? Though i think we should have primarily BASIC or VB for the newbies, and the C family for the everyday hacker, and python for people who like it :D. Well thats just my suggestion but all i really care about is BASIC and the C language... i have no experience with Python.

[LinuxGuy]

Just out of curiosity why? VB is not only the easiest lang to use with win applications it a natural match for windows and robotics. Just my opinion.
Visual Basic is not cross platform. It's only available for Windows and from Microsoft.

8-Dale

[Alex]

Honestly Droid, if you are talking about VB6 and not vb.net, I would rather burn my eyes out with soldering irons, pour salt in the holes and chop off my whoha than use vb6:D

[LinuxGuy]

I say we should have: BASIC, C++, C#, C, Java, and Python... o wait isnt this basically all of them? Though i think we should have primarily BASIC or VB for the newbies, and the C family for the everyday hacker, and python for people who like it :D. Well thats just my suggestion but all i really care about is BASIC and the C language... i have no experience with Python.
I agree that we should eventually have interfaces for each of these languages on appropriate platforms where it is possible. We are choosing a language to develop the TROM in, not one that will necessarily have to be used by end users to interface with the TROM.

8-Dale

[Droid Works]

VB (and I'm assuming you mean vb6, not .NET) is an easy language to use, but doesn't have even 1/100th of the tools necessary to build the TRS. VB isn't anywhere close to an Object Oriented language either. Plus, we've decided to not use any languages that are tied to any OS.

I only have a basic understanding of C and I didn't know it had that many tools. So I guess that answers my question. That is a very good reason for using C. Thanks for the info, I guess I am going to start cracking open the C+, # and ++ books...lol

[Wingzero01w]

Well if its a development case than it should be one of the C languages since they are more faster and efficient... not to mention most majority of people have at least a little basic experience with the C family.

[metaform3d]

In terms of writing the core of the system you'll definitely want to go C/C++, most likely C++. This is big-league stuff -- you'll want to get out of the sandlot and onto the real field. Like Adrenalynn I actually prefer C to C++, but for this type of task I think C++ is more appropriate. There are a lot of potential pitfalls, but those can mostly be managed with strongly enforced coding standards.

Outside the core, however, I think that robot-builders should be able to write in any language they want. This simply requires that you provide the right hooks so experts in the various languages can write wrappers or interfaces. Python, which I believe was mentioned, is a great example. It's very easy to write C code that creates new data types and services in a Python script. Alternately a Python interpreter can be embedded into another system just as easily.

After two long evenings with C# I can state with some confidence that it bears almost no relation to C++. Except for the syntatic sugar that makes it look kind of like C, it's essentially the same as Visual Basic. I'm sorry to say that a grounding in C# will not substitute for a good C++ book or class.

[LinuxGuy]

In terms of writing the core of the system you'll definitely want to go C/C++, most likely C++. This is big-league stuff -- you'll want to get out of the sandlot and onto the real field. Like Adrenalynn I actually prefer C to C++, but for this type of task I think C++ is more appropriate. There are a lot of potential pitfalls, but those can mostly be managed with strongly enforced coding standards.
I agree completely. Not only is most of the Open Source code we'd want to use done in C/C++, but it opens so many more doors and is inviting to so many more developers. Matt and Alex may be underestimating the importance of what they are spear heading here. However, we have to go one step at a time, and add one brick at a time until we get where we want to be.

Outside the core, however, I think that robot-builders should be able to write in any language they want. This simply requires that you provide the right hooks so experts in the various languages can write wrappers or interfaces. Python, which I believe was mentioned, is a great example. It's very easy to write C code that creates new data types and services in a Python script. Alternately a Python interpreter can be embedded into another system just as easily.
Absolutely! We need to make it as easy as possible to use the TROM and associated software from as many different languages as possible, and we need to keep sight of that goal as we move forward and start coding. I'll add to this any platform the developer wishes to use, even if it means I have go do some development for Windows. This is important enough that I'll do development for Windows if required. Did I really write that??

After two long evenings with C# I can state with some confidence that it bears almost no relation to C++. Except for the syntatic sugar that makes it look kind of like C, it's essentially the same as Visual Basic. I'm sorry to say that a grounding in C# will not substitute for a good C++ book or class.
I've never been thrilled with C# right from the get go, but we still need to allow for C# users to interface with the TROM and associated libraries.

8-Dale

[Adrenalynn]

Just out of curiosity why? VB is not only the easiest lang to use with win applications it a natural match for windows and robotics. Just my opinion.

I'm using an old 68030 to control my robotic arm at the moment, because it's what I had laying around. How well does it run on the 68030 microprocessor? How about the latest craze - the Arduino? Can I run VB on the Arduino?

The world of Robotics is much larger than having to hang a quad-core and 650wt power supply on your ant-weight. ;)

[Adrenalynn]

In terms of writing the core of the system you'll definitely want to go C/C++, most likely C++. This is big-league stuff -- you'll want to get out of the sandlot and onto the real field. Like Adrenalynn I actually prefer C to C++, but for this type of task I think C++ is more appropriate. There are a lot of potential pitfalls, but those can mostly be managed with strongly enforced coding standards.

"I've seen C++ so beautiful, it'd make you weep with joy. But the vast majority will just make you cry"... It's awesome for the first generation or two of engineers that touch it. ;) But [sigh] yes, I agree, the C++ inheritance is a must.


After two long evenings with C# I can state with some confidence that it bears almost no relation to C++. Except for the syntatic sugar that makes it look kind of like C, it's essentially the same as Visual Basic. I'm sorry to say that a grounding in C# will not substitute for a good C++ book or class.

Yup, agreed. But my point is that a skilled C++ programmer can read C# without their heads exploding, so the port isn't the proverbial "end of the world"...

[LinuxGuy]

I'm using an old 68030 to control my robotic arm at the moment, because it's what I had laying around. How well does it run on the 68030 microprocessor? How about the latest craze - the Arduino? Can I run VB on the Arduino?
I'm looking at using the Arduino with a ZigBee module for wireless sensor and robot nodes. This is what distributed network processing is all about. :happy: This sort of thing could just as easily be applied to internet swarming of robots. We're getting into SkyNet types stuff with this sort of thing. :veryhappy:

I'll reply to the rest in the Robot thread. :happy:

8-Dale

[Adrenalynn]

I still like 3G/3.5G/4G digital cellular for my Skynet. ;)

[LinuxGuy]

I still like 3G/3.5G/4G digital cellular for my Skynet. ;)
Spark Fun has some cool GPS modules with integrated GSM. :happy: I haven't seen any 3G modules yet, but I bet they are coming at some point not too far away. I have AT&T for my cell, so a lot could be possible if shared (family) plans didn't cost so much. But then, with GSM I could have my robot call yours, interface, and exchange data. :happy::veryhappy:

8-Dale

[Adrenalynn]

My robot would want dinner first. :P

The company I work for has a GPS/WCDMA/CDMA integrated tracking device. It also does 1x/EV-DO. I can literally plug into it over serial and get a megabit down and 384kbit up. We're still in network certifications, but it will end-up in the US on at least Sprint and Verizon. The other LBS systems are a little sketchy.

[metaform3d]

Yup, agreed. But my point is that a skilled C++ programmer can read C# without their heads exploding, so the port isn't the proverbial "end of the world"...True, but not so much the other way around. There are enough serious disconnects between C# and C++, especially around constructors/destructors and strong typing (at least that I've found so far), that even an experienced C# programmer had better put their head on ice from time to time.

[Adrenalynn]

Agreed. C# is the BASIC of this millenium, imho. A good institution to graduate from. ;)

[Alex]

"I've seen C++ so beautiful, it'd make you weep with joy. But the vast majority will just make you cry"... It's awesome for the first generation or two of engineers that touch it. ;) But [sigh] yes, I agree, the C++ inheritance is a must.


Are you saying that in C, you can't even do a simple thing like inherit from different classes? Wait... are there even such a thing as classes in C? If not, then that is our answer: we CAN'T use C and must use C++ or some other OO language.

[Adrenalynn]

You can trick it, but under straight K&R, it's function-based.

>> we CAN'T use C

I read that and cringe. Next you're going to tell me why I can't do it in assembler, and then explain why I can't do it in microcode. :mad:

I think the more accurate observation would be "we won't do it in C, even though an adequately skilled engineer can do anything in straight K&R C, from the bare metal up, because we prefer the OO paradigm..." :tongue:

Did I mention I have a first edition K&R C, autographed by both of them? :happy:

[LinuxGuy]

Are you saying that in C, you can't even do a simple thing like inherit from different classes? Wait... are there even such a thing as classes in C? If not, then that is our answer: we CAN'T use C and must use C++ or some other OO language.
C++ can do all of this, so there should not be any problems. I think we've been talking C++ all along, but I may have missed something.

8-Dale

[Alex]

True, but not so much the other way around. There are enough serious disconnects between C# and C++, especially around constructors/destructors and strong typing (at least that I've found so far), that even an experienced C# programmer had better put their head on ice from time to time.

Very true!

I had two semesters of C++ back in college but haven't really used it since. I've tried to develop some applications in C++ since I've become proficient in C# (during last two years) and it's a headache! I can't seem to wrap my head around what are the differences between header and source files. I haven't really been able to wrap my head around WTF a header is for and why it's needed. Then again, I haven't really looked that deeply into it because I haven't had the need to. Like I said in another thread though, if I need to re-learn it, I don't have a problem with it.

I don't want to hijack thread though because it's already on the verge, so PM me if you want to reply to anything I said;)

[Alex]

I think the more accurate observation would be "we won't do it in C, even though an adequately skilled engineer can do anything in straight K&R C, from the bare metal up, because we prefer the OO paradigm..."Sorry, I could have been a little less "emotional" in that last reply:p

It's not that I "prefer" the OO paradigm, it's that if we really want to take the TRS out of our basements and garages and see it get some serious recognition and use then it must be purely OO based. Lower level, non-OO programming is one of the things that have been crippling the advancement of robotics for many years now. The only people who get that sort of programming is (no offense) but engineers, who make up a very small percentage of programmers.

If we really want to put the field of robotics on the map (seriously have you noticed that "Robotics" is never a field in dropdown boxes in things like LinkedIn;)), we need to present it in the way that will allow the millions of high-level developers to understand it.

[LinuxGuy]

It's not that I "prefer" the OO paradigm, it's that if we really want to take the TRS out of our basements and garages and see it get some serious recognition and use then it must be purely OO based. Lower level, non-OO programming is one of the things that have been crippling the advancement of robotics for many years now.
I love the whole idea of OO, but until now haven't had any reason to do anything with it. That has changed, so here I go into the land of OO!

If we really want to put the field of robotics on the map (seriously have you noticed that "Robotics" is never a field in dropdown boxes in things like LinkedIn;)), we need to present it in the way that will allow the millions of high-level developers to understand it.
I want to see TROM go as far as it can go. I've known for a long time that TROM, or something like it, is needed for robotics and process control. I just never thought I would be part of such a development project.

8-Dale

[HumanoidFan]

What about using Mono ? Mono is cross platform and Open-sourced. Now people could pick any .Net language they want to use and have the ability to plug in C/C++ compiled libraries. Yes it is fast.

if the TROM is coded in C# already, why reinvent the wheel ?
Also if it can be compiled in Mono and executed in Mono then it can be run on Windows (native .Net), OSX and linux. Plus people don't have to maintain different ports of the TROM for different CPUs and platforms.

[Adrenalynn]

Because Mono is heavy, and there's absolutely no guarantee that Microsoft add features faster than the Mono team can reverse engineer them. Last I checked, Mono didn't universally support everything dotNet can throw out there even now - I think it's likely it never will - kinda like WINE.

[HumanoidFan]

True,

But C# and IL are ISO standards, so if you code using mono runtime, then it will run in .NET.

Mono is not that heavy, it has very good performance. Enough performance that it is used for commercial video game development and in Second Life.

[Matt]

Thanks for ringing in Shawn. Everyone, I asked Shawn to bring up the Mono possibility so we could give it a fair look. It looks like C++ is winning the day and I think Mono is the last language we haven't really kicked the tires on so I'd like to do that and then we are close to making a decision.

cheers :)

[Adrenalynn]

I appreciate the discussion, Shawn, and don't think I'm downplaying your points.

A quick aside to Matt - I don't think I'd call Mono a "language". I'd call it a "framework" that certain languages reference for support.

Shawn - as long as your code is using nothing from anything later than dotNet 1.1, Mono should do fairly well. I've looked pretty hard at Second Life when I was developing a 3D project. I make money on Second Life, There, and IMVU - so I've also poked at Cal3D pretty hard too.

Mono suffers, imho, from being faaar behind the curve. I just don't know of a kinder/gentler way to put it.

One concern is that Mono has no intention of supporting Web Services - where I thought this project was looking for that.

System.Messaging doesn't and won't exist.

Unless the Trossen team wrote to dotNet 1.1, or got incredibly lucky, trying to code around Mono's limitations could be a bit of a challenge.

At that point, why not port to something that is inherently and natively cross-platform?

I welcome your thoughts.



** Some opinion formed or quoted from: http://www.mono-project.com/Roadmap

[Sienna]

I am confused.... Mono isn't a language I thought? I understood Mono was a runtime environment for .NET applications under Linux?

.NET itself isn't a language as I understood it, but a runtime environment for VB, C#, etc?

[Adrenalynn]

Observed in my post, that's correct. Mono is a framework to reproduce dotNet components under more True POSIX operating systems.

[Alex]

One concern is that Mono has no intention of supporting Web Services - where I thought this project was looking for that.

System.Messaging doesn't and won't exist.


That does constrain us quite a bit then because I am leaning even more heavily towards Web Services for the TROM.

Unless the Trossen team wrote to dotNet 1.1, or got incredibly lucky, trying to code around Mono's limitations could be a bit of a challenge.


.NET 1.1 didn't have the features we needed. We used a lot of Generics (http://msdn2.microsoft.com/en-us/library/512aeb7t%28VS.80%29.aspx) all throughout the TROM, along with KeyedCollections (http://msdn2.microsoft.com/en-us/library/ms132438.aspx) (Man! I really love those KeyedCollections, so freakin powerful:D)

I am confused.... Mono isn't a language I thought? I understood Mono was a runtime environment for .NET applications under Linux?

.NET itself isn't a language as I understood it, but a runtime environment for VB, C#, etc?

Correct and Correct:) They're both runtime environments, not languages.

[Alex]

Wait a sec though Adrenalynn... I could've sworn I read something over a year ago saying that there was a Mono 2.0? I can't seem to find it right now though:(

If mono only supports .NET 1.1, then it really isn't all that useful because then we loose a HUGE chunk of what we have already architected and built in the TROM...

[Adrenalynn]

2.0 support is "partially complete". [From the Roadmap page I linked to before]

Mono 2.0 is an upcoming release.

It's also worth noting that Mono doesn't really make things truly cross-platform, as it's not supported yet on a lot of common platforms. That porting work is also ongoing.

My point is: Do we really want to get married to fledgling projects?

Here's that page I linked again. It's the official roadmap from the official site:

http://www.mono-project.com/Roadmap

[jrowe47]

I think that some foresight would serve us well, here.
C# is very widely used. You're not going to have to worry about massive changes or obscurity, and the mono implementation just keeps getting better.

Specifically, however, for those "small is beautiful" concerns, there's a gem out there called the Cosmos operating system. Cosmos is written entirely in c#, and they're finishing the sockets implementation.

What this means is that with a little patience, whatever code is produced here should be compatible with cosmos when its a little more fleshed out. As it is open source, the greater the interest, the faster things will get done.

Cosmos means a minimal operating system which can be modularly customized using an easy language at a very low level. Cosmos means more power for your applications and less for the overhead.

I think it would be wise to stick with C# and plan for very tight integration with many of the myriad open source projects out there that will lend themselves so well to robotics.

I think if you borrowed Cosmos and started adding in the things necessary for robotics, and designated a system level library for manipulating sensors and servos, then a script level API could be designed for easy behavior creation. That would free up the developers of the system itself to focus on implementation specifics, and allow robot builders to avoid dealing with messy frameworks and immediately start creating code for their robots.

I think independence from major operating systems is a plus, but the crux of the issue is really portability and size. If there were a Robotics version of Cosmos floating around, it would be freely and easily available, independent of any of the usual operating system overhead, and open source with great documentation and an active community.

Food for thought :)

[LinuxGuy]

I think it would be wise to stick with C# and plan for very tight integration with many of the myriad open source projects out there that will lend themselves so well to robotics.
The problem with this is C# is not cross platform. There should be APIs for C# to use TROM, but that is all. We must develop TROM in a cross platform language, not something tied to a single OS or company.

8-Dale

[Alex]

Personally jrow47, I would absolutely LOVE to develop this entire system in C#. However, I have to look at the reality, which is that C# is not cross platform (as robotguy stated) and that it is dependent on the .NET framework to run. What we're trying to accomplish here is developing a system that is not dependent on anything: frameworks, platforms, languages, etc.

[HumanoidFan]

In my opinion C# is cross platform.

Will web services allow the transfer of data in real time ?

a pure C implementation is the best way to go then. This is also not 100% cross platform..


I still think, develop the system with what you have (C#), turn it into a standard and then worry about other ports. How many resources are available for this project ?

For us, it does not matter if the lower level is C /C++, we can link our system to this layer.

[LinuxGuy]

In my opinion C# is cross platform.

Will web services allow the transfer of data in real time ?
How is C# cross platform. Mono is not sufficient for what we need.

8-Dale