Roborio and Swift?

[Fauge7]

the only other language that i can actually see being programmed besides the one avalible is the .net languages mostly vb and c#

[virtuald]

Originally Posted by Fauge7

the only other language that i can actually see being programmed besides the one avalible is the .net languages mostly vb and c#

Not true. Any language that can run on linux, could potentially be run on the RoboRIO. The "hard" part (really, it's typically just a lot of tedious work, as opposed to being truly hard) is creating appropriate bindings for WPILib/HAL.

Possibilities include (but are not limited to) Python (done), Ruby, Perl, Go, Javascript, Haskell, Lisp, C#/Mono, D, Brainf*k, LOLCode... whatever someone is willing to put the work into, is possible.

I'd be interested in seeing someone create WPILib bindings for Go or Javascript.

[Bryan Herbst]

Originally Posted by virtuald

Not true. Any language that can run on linux, could potentially be run on the RoboRIO. The "hard" part (really, it's typically just a lot of tedious work, as opposed to being truly hard) is creating appropriate bindings for WPILib/HAL.

Possibilities include (but are not limited to) Python (done), Ruby, Perl, Go, Javascript, Haskell, Lisp, C#/Mono, D, Brainf*k, LOLCode... whatever someone is willing to put the work into, is possible.

I'd be interested in seeing someone create WPILib bindings for Go or Javascript.

I don't think the comment was about which languages are possible, but rather which languages are probable.

While all the languages you listed can run on the roboRIO, there isn't a great reason to bring most of them to FRC.

I could see arguments in favor of Python and C#, not so much the others. However, because they need to maintain a balance between offering a variety of languages and providing first class support for the available languages, I'm not holding my breath for more officially supported languages.

[virtuald]

Originally Posted by Tanis

I don't think the comment was about which languages are possible, but rather which languages are probable.

While all the languages you listed can run on the roboRIO, there isn't a great reason to bring most of them to FRC.

I could see arguments in favor of Python and C#, not so much the others. However, because they need to maintain a balance between offering a variety of languages and providing first class support for the available languages, I'm not holding my breath for more officially supported languages.

My expectation is that for the forseeable future, FRC will only officially support Java, C++, and LabVIEW.

[Thad House]

Originally Posted by Tanis

I don't think the comment was about which languages are possible, but rather which languages are probable.

While all the languages you listed can run on the roboRIO, there isn't a great reason to bring most of them to FRC.

I could see arguments in favor of Python and C#, not so much the others. However, because they need to maintain a balance between offering a variety of languages and providing first class support for the available languages, I'm not holding my breath for more officially supported languages.

I started working on C# earlier this season. I could access parts of the HAL and DS reporting was working, so it could switch between auto, teleop and disabled, but whenever I tried to open any input or output I would get a segfault. I have a feeling this was because it was using an old version of Mono, which wasnt working correctly with IntPtrs. I think I'm going to need to compile the newest version of Mono to get it working, but I really dont know how to do that, so that will be something to figure out over the summer.

This was good news for most languages though, because if you can interop with C++ libraries, getting basic communication working was really easy, and was done in about a day.

[Arhowk]

Originally Posted by virtuald

Not true. Any language that can run on linux, could potentially be run on the RoboRIO. The "hard" part (really, it's typically just a lot of tedious work, as opposed to being truly hard) is creating appropriate bindings for WPILib/HAL.

Possibilities include (but are not limited to) Python (done), Ruby, Perl, Go, Javascript, Haskell, Lisp, C#/Mono, D, Brainf*k, LOLCode... whatever someone is willing to put the work into, is possible.

I'd be interested in seeing someone create WPILib bindings for Go or Javascript.

No idea what "Go" is but 1684 will be doing JavaScript next year (if I'm still on the team) (or a custom language still being developed if time allows). The only reason that we didn't do it this year was that plans for a backup roboRIO fell through.

// just looked up "Go"

no type inheritance
no method or operator overloading
no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

[Aero]

Originally Posted by Arhowk

No idea what "Go" is but 1684 will be doing JavaScript next year (if I'm still on the team) (or a custom language still being developed if time allows). The only reason that we didn't do it this year was that plans for a backup roboRIO fell through.

// just looked up "Go"

no type inheritance
no method or operator overloading
no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

// just looked up "Javascript"

no type inheritance
no method or operator overloading
no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

[virtuald]

Go actually has *better* generic programming, sorta. It would be cool to use in FIRST.

[Fauge7]

I just dont get why you would do mono/c#, java has the same syntax as the library is more mature

[Arhowk]

Originally Posted by Aero

// just looked up "Javascript"

no type inheritance
no method or operator overloading
no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

Javascript indeed has type inheritance, assertions (console.assert(expression, object)), generic programming, and some operator overloading through "valueOf" hacks.

Javascript does not need method inheritance due to it's loose type definition, is built to avoid circular dependencies, and has no concept of pointers so pointer arithmetic is pointless.

Please attempt to be less aggressive next time.

Go actually has *better* generic programming, sorta. It would be cool to use in FIRST.

Meh. It has something. Whether or not it can be considered conventional "generic" programming is debatable.

I just dont get why you would do mono/c#, java has the same syntax as the library is more mature

It's just preference. Plus, alot of the Java library is inaccessible on the roboRIO since it's primarily graphical. (though the same and more can be said for C#)

[connor.worley]

Originally Posted by Aero

// just looked up "Javascript"

no circular dependencies among packages
no pointer arithmetic
no assertions
no generic programming

eh.

Why would you need any of these features for an FRC robot? Proper inheritance and overloading is a comfort thing, but the rest are mostly useless in an FRC context.

[Monochron]

Originally Posted by connor.worley

Why would you need any of these features for an FRC robot? Proper inheritance and overloading is a comfort thing, but the rest are mostly useless in an FRC context.

Educational probably. Especially pointer arithmetic, that is a nearly daily part of my job.

[byteit101]

Originally Posted by virtuald

Not true. Any language that can run on linux, could potentially be run on the RoboRIO. The "hard" part (really, it's typically just a lot of tedious work, as opposed to being truly hard) is creating appropriate bindings for WPILib/HAL.

Possibilities include (but are not limited to) Python (done), Ruby, Perl, Go, Javascript, Haskell, Lisp, C#/Mono, D, Brainf*k, LOLCode... whatever someone is willing to put the work into, is possible.

I'd be interested in seeing someone create WPILib bindings for Go or Javascript.

Go is actually used for some of our tests here at WPI. Rather easy to compile for arm. Javascript and Ruby (and Python) in theory should be able to work *RIGHT NOW* via the JVM with Nashorn or Rhino, JRuby, and Jython respectively. Hmm... now I have to go try this out...

EDIT: It would require a bit more work than running the jars. Most of them seem to require classes that aren't in the profile on the RoboRIO