F# (F sharp) as the language to get the masses to use Prop2
tonyp12
Posts: 1,951
F# though preferable to be used with .Net framework,
I could still see it being used as a MCU programming language.
And telling potential Prop2 customers that F# is available,
though they may have never used it you could hint to them that it's a new popular language by Microsoft.
Forced indent (like Spin)
Use := to set a ref value (like Spin)
Never set variable type, the pre compiler handles that.
Never use curly brackets or semi colons.
Video introduction:
http://youtu.be/z49Wew284PE
system.console should be a 640x480 VGA screen by default.
printnf should be Uart by default.
Would it be hard to get basic F# functions on a Prop2?
Should it be compiled in to bytecode as Spin is?
https://en.wikipedia.org/wiki/F_Sharp_(programming_language)
http://fsharpforfunandprofit.com/learning-fsharp/
I could still see it being used as a MCU programming language.
And telling potential Prop2 customers that F# is available,
though they may have never used it you could hint to them that it's a new popular language by Microsoft.
Forced indent (like Spin)
Use := to set a ref value (like Spin)
Never set variable type, the pre compiler handles that.
Never use curly brackets or semi colons.
Video introduction:
http://youtu.be/z49Wew284PE
system.console should be a 640x480 VGA screen by default.
printnf should be Uart by default.
Would it be hard to get basic F# functions on a Prop2?
Should it be compiled in to bytecode as Spin is?
https://en.wikipedia.org/wiki/F_Sharp_(programming_language)
http://fsharpforfunandprofit.com/learning-fsharp/
Comments
So, apart from F# being yet another shiny new thing what does it offer the MCU programmer over the million or so languages we have already?
It's old and soon obsolete (I hope) and if a new MCU language was the same as F#
would be great as I did not have to learn different syntax when I make programs for the PC and then my MCU.
Maybe Prop2 will be the forerunner for MCU F# ?
I'm halfway to master C# but maybe I will skip it and master F# as it seems to be so much better.
For example (cdr '(a b c)) returns a list (b c), but list (a b c) still exists as well, at some point list (b c) is going to become garbage. Static or stack based allocation tends to be better suited to real time programming because you avoid garbage creation in the first place.
it may be just me, but I feel compelled to ask why it is that programmers chase after new fangled languages like a dog chasing his tail? Sure it looks like we are all very happy and busy -- but we never really get anywhere different.
[mode pop]
Languages like C# and F# are not just language's but include shiploads of Microsoft runtime - so they are not really embedded controller languages.
Sure C is annoying in many areas, but a good editor can ease some of that.
What C does have, is critical mass on micro controllers.
Whilst the fashion is to rush out 'more fluff' in languages, in the embedded space I think there is good scope for a High level assembler.
That may be a combination of subset/superset of an existing language, and on the Prop 2, the solution looks to be using C with switches to create PASM code - workable in small pieces.
PASM itself could also do with a clean-up pass, to being it closer to the next language up.
Another language that would fit a Prop 2 nicely is the PLC language IEC 61131 ST (and maybe IL )
Instruction List is more similar to the byte-codes of .net, or reverse polish.
Given the advances in Editors and Simulators, the obvious combination is a Language+Editor+Simulator merge.
If you can see the direct opcode is a dis-asm window, and step the virtual CPU, almost any language becomes easy to learn.
Don't worry, some folks do understand and care for their tools. One of the oldest languages was designed for systems with limited resources. It pre-dates C (and pre-dates COBOL if you count the start of development). The version for the Prop 2 will implement a cool method of multitasking, and the view the Prop2 threads as 32 execution opportunities which can be divided into pools (for time critical vs non critical execution). And its still free.
C.W.
For example, functional languages seek to eliminate function side effects, so each can be unit tested without concern about the state of other functions. This is in contrast to a language like C++ or Spin where member functions are influenced by the object state which in turn influences object state.
So I have no problem with functional programming, and I've used that style of programming in the past. Where this gets frustrating is the creation of multiple similar languages (e.g Clojure, Erlang, F#, Haskell, and Scala). I suppose competition improves the breed, but I already know Lisp (and Clojure because it's a dialect), so I'm not interested in the others.
I also get annoyed by multiple incompatible dialects of a language as it reduces code portability. Some languages I like (e.g. BASIC, FORTH) have this problem, and I've heard a rumor of four dialects of one of them on the Propeller chip.
I felt like an old dude. I'd use VB6 if it was free. Better than C#/vb.net where the language seems to change every 3 years. Actually, I had a little retro moment resurrecting QB45 which was free and still is, and is really nifty if you want a quick console line program. C is also great for quick console line programs.
I do most of my serious programming in VB.net and it seems that every new release brings C# and VB.net closer to the same language.
There are some retro programmers here who see everything on the propeller in terms of a historical perspective. Simulate '60s computers. Then '70s computers. Then '80s computers. I think were are roughly at about 1990. Enhanced DOS is just within reach. Win95 may be a bit beyond us (and the equivalent linux/unix program). I'm not letting that stop me though *grin*, I an coding a graphical enhancement to CP/M for the propeller/Z80 hybrid.
I dunno about F#. Talk to me. It sounds interesting
I'd love to see a 'simple' version of C# or VB.Net, even if it couldn't do classes, the syntax editor and IDE would be extremely helpful. C# might be easier as one could think of a simplified version of C# that was more ansii 89 C but used the microsoft IDE.
F# may be closer to Spin. Any link to a simple tutorial?
That "old" guy wanting to rewrite C# to VB can't be all that old. I still think of VB is a toy language for the young'ns
A nice example of how out of touch modern languages and programmers are with the reality of the machines they run on is in this video where a guy speeds up a Python program by a factor of thousands. Mostly by reorganizing the code (and data) into a machine friendly form and then rewriting key parts of it in C. If you have an hour to waste it's a great vid if only for the "old guy" perspective on modern programming and his cranky jokes. http://www.youtube.com/watch?v=e08kOj2kISU
Up until recently I would have said all these functional programming enthusiasts were horribly wasteful of machine resources for no good reason. But I couple of things happened:
1) I started to understand what "functional programming" is about.
2) JavaScript
Turns out that programming styles provided by these higher level languages, like functional programming, are pretty cool if you can get your brain out of the Algol/C/Pascal etc mind set. That is actually quite hard for this old guy.
Turns out that JavaScript can be much more efficient than I would eve imagined. For example it is now possible to "compile" C and C++ code to JavaScript and have it run up to half the speed of compiling it to native code. Amazing. My own little JavaScript programs on the server side have come out only slightly slower than the old C++ versions I based them on whilst being hundreds of times easier to write. Much easier to maintain moving on as well.
If you feel the need for functional programming in a Lisp like language we now have Clojure http://clojure.org/rationale that compiles down to Java or .Net byte codes or, surprise surprise, JavaScript.
Still, we have to face the fact that an MCU with only 32K or 128K of RAM is not really big enough to support all this. Plus most of these new "programmer friendly" languages rely on garbage collection which is a no-no for real-time deterministic performance.
But, hey, if you want to play with this new world we already have JavaScript running on the Propeller:)
Most of the code I've written for Prop1 is PASM with a small amount of spin to launch and feed the PASM. I've now started supplementing that with C++ via SimpleIDE/propgcc. I think from now on I'll be mostly using C++ on the Prop1 and Prop2, with PASM where needed.
I've been using C++ since around 1984. I've been using it professionally in the video/computer game business for 20+ years now. When it comes to consoles and PC games, most of it is C++. There is a bit of C# in there for things like Xbox live arcade and a few random oddballs on PCs. When you start talking mobile stuff, that's dominated by Java(android) and Objective-C(iOS).
Anyway, anyone thinking C or C++ is going away, is delusional. It's pretty much here to stay, just like machine/assembly language. I'm quite happy about that.
Heater,
I think of the P2 as having 32MB ram, 126KB L2 cache (HUB), and 3KB x 8 L1 cache (each COGs memory).
I detect a little contradiction in your post. On the one hand "we are unlikely to see managed languages on the Prop" on the other "I think of the P2 as having 32MB ram,"Given the speed of the P2 and that huge memory possibility there is no reason we should not have a CLR or JVM for it. Both of those have been running on small embedded systems for a long while. See mbed for example.
Not sure what you mean by "managed" exactly but we also have JavaScript running on the Prop 1 with external memory today. JS is running on machines with a lot less memory: http://www.espruino.com/
In fact these things might make more sense on the Propeller than many other devices as one has the luxury of using a COG to run the slow, cumbersome, managed, garbage collected code whilst still having COGs free for the hard real-time deterministic stuff. Best of both worlds:)
the languages tend to increase in -complexity- as folks add more of the kitchen sink, until the language is awkward to learn or use. Which is a subjective evaluation.
Sometimes dialects is the -goal- of the tool.
Some environments/languages are design to DISTANCE developers from to nuances of the hardware (C, etc); other FOCUS on the nuances of the hardware (Forth, etc), C allows any programmer to write general programs for general hardware, and forth allows programmer to write programs to take advantage of the unique abilities of a given hardware, to tailor for the application at hand. Portability is only needed for arbitrary examples; a complex application tailored to specialized hardware would tend to not be portable to generic hardware in any case.
Every forth is different. This is by design. No forth programmer expects a forth comply 100% with the standard, and still be useful for applications on micro controller or other system with limited or specialized resources. On a PC one -could- be 100% compliant, but in that case one would like just use an existing PC tool.
What would be the draw for say, C programmers to turn to F#? What make this particularly suited for a micro controller, what need is F# designed to fill?
The way C handles this is by either allowing in line assembly via a directive, or assembly modules linked with the program. That way the C program stays portable, but code tuned to the machine is available.
Which is entirely cool and suitable for many situations. So what F# features would entice someone choose that instead of C, or any other option, particularly on a micro controller?
I notice that github has it down as about the 50th used language in their repositories.
Being Microsoft centric I don't see much future for it.
Sadly also is the fact that "the masses" of Arduino users don't even know they are using C/C++ because it is hidden from them by the Arduino documentation.
if you tell them that this new language is also used on other systems and its future as language looks bright.
If I could type in this in a F#/Spin hybrid on a Prop2 I would be happy
let myvalue = PortA.input(mask) if myvalue.Equals(7) then PortB.output.value := 1 else PortB.output.value := 0In post 5 I said I didn't think F# was suitable for a microcontroller. As a functional language it would probably be useful for the same sort of symbolic processing problems that Lisp is useful for (e.g graph traversal, forward or backward chaining, theorem proving). Lisp syntax really puts some people off, so maybe they would like it better.
But as I also said earlier, I know Lisp and wouldn't bother using F#.
Only hidden from those who don't look.
http://www.arduino.cc/en/Hacking/Libraries
http://arduino.cc/en/Hacking/HomePage
I was doing that parallax forum thing... where you say it won't happen and someone proves you wrong. Also, "managed" is the term Microsoft uses (maybe it's gone out of favor?) for all the .NET languages (C#, J#, F#, VB.NET, C++/CLI). The ones that run on the CLR and use the .NET framework. Maybe the term is only used in Visual Studio? Where you have Managed vs Native debugging, and so on...
Also, I fully expect to see some form of Linux running on the P2 before the end of next year. Maybe once that's going someone could port over a subset of Mono?
"Libraries are files written in C or C++ (.c, .cpp) which provide your sketches with extra functionality"
Exactly. That could be a description of extending Python or whatever. What is all this nonsense about "sketches"? Why don't they talk about extending your C++ program?
I mean ".equals" instead of good old "==". And so on.
You don't get anymore expressive power from rearranging syntax like that.
By the way what is " PortB.output.value := 1"? does that clobber all PortBwith zeros apart from bit zero or what? Seems you need a mask there like you implied for the PortA input.
F# may have a lot of useful features for high level programming, as does Lisp and everything derived from it, but it's not clear how that helps in MCUprogramming.
Yes, good. In Parallaxia just say it's impossible and there it is:)
I have no idea where the term "managed" came from. Seems to hark back to thedays of running Java applets in your browser in a virtual machine "sand box".Well, that idea went nowhere fast.
No, no. Linux on a Propeller is impossible I tell you:)
I just want it to be the same syntax as some other major language, I like that F# is half the lines of code compared to C/C#
I like that it's good for math and science, I like that they asked themselves what is the problems we had for the last 30years and trying to fix them.
My example PortB example is probably no good, I have not looked in to how F# do it's syntax with non-muted values and Tuples and Records etc
I think it would be possible to write a program that translate basic F# |>Spin |>bytecode (transparent to user) like a pre-compiler.
Good point. I too am not a fan of the C/C++ header files and all that redundant text you have to create.
Spin has done a good job of getting rid of that.
These new languages do have good intentions in fixing up old problems.
For example in C/Pascal/Spin etc if you add enough to an integer it will silently overflow and give you a wrong result. How crazy is that?
Modern languages fix that by using arbitrarily large integers. But that suddenly demands a huge lot more code and memory to handle. And creates a situation where you can no longer tell how long it takes to add 1 to anything. Not good.
When you start talking about immutable data and such, as required for functional programming, you are in big trouble fitting it in the limited memory of MCU's.
There are reasons why those 30 year old problems are still with us.
Preach it, brother. Something clicked in the past 5-7 years for a lot of people who had to use Javascript. A confluence of influential books and toolkits all combined to show just how expressive and powerful that language really was, so long as you avoided the ugly bits. It still leaves a lot to be desired, but I've seen some sublime Javascript in the past few years. 15 years ago I can't imagine that anyone on Earth could ever say such a thing. Even better, I've written some pretty concise yet expressive JS. Once it clicks, it clicks. It's like LISP in C clothing.
Woah. I missed that. Is that in OBEX?
I have heard of F#, but I don't know a single developer or shop here in the bay area that's using it. Closure, Scala, Erlang... those are getting some traction from the more academic-minded teams. In fact, an Erlang-like system for Prop2 might not be a bad idea. It's a language built for soft real time, high availability, super lightweight threads, etc.
But as for the language war originally proposed at top of this thread
Recently I had to get something working that streamed live data from multiple remote sensors up to a server and then onto the clients browser(s)where it would be shown in a nice animation. I was horrified at the idea that I would have to get into all that web stack stuff again.
Luckily I found I could bypass most of it. I created the server end in JavaScript in Node.js. The stream to browser is websockets and JSON. The animation is webgl. I could pretty much do the whole thing without touching HTML or CSS or PHP/Python/whatever. Let the other guys do that. Yay.
Well, point is, because I needed a real-time streams I needed websockets. Knowing nothing about anything the easiest way to do that for me was node.js.And that led to discovering that JS is quite brilliant and with modern JS engines is pretty damn quick. No. It's was just a quick experiment using a tiny JS engine from Pur3 Ltd.Those guys have nice JS system for small ARM processors, like with 128K RAM
The Pur3 JS is a fully working JS for embedded systemshttp://www.espruino.com/ but it is not open source (yet, if ever).But the authors did put up the guts of their JS engine somewhere. I forked it to here if you want to play with it. https://github.com/ZiCog/tiny-js-propellerYou will need a Prop board withe external RAM though.I think this is another improved but bigger version:https://github.com/gabonator/G42-tiny-js