Showing posts with label Michael Barr. Show all posts
Showing posts with label Michael Barr. Show all posts

Sunday, November 7, 2010

Microsoft Open Sources F#. Will Functional Languages save us?

Michael Barr recently [September, 2010] wrote a column on The Sad State of Embedded Software Process, which tells us that the first embedded system was done about forty years ago, and we still are doing a collectively poor job at building them.

The VDC Research Report What languages do you use to develop software?, tells us that after those forty years 81.9% of our Embedded Systems are still using the language 'C'.

Perhaps there is a connection to using a forty year old language,with not having any great improvements in reliability after forty years?

Why can't any modern language gain significant traction in the Embedded Space? Whom has the clout to develop and promote a new, safe, language for limited resource hard real time (dead line can not be missed without catastrophic consequences) Embedded Systems that will actually gain traction?

I do not have those answers. I'm sure I could come up with a language, as I'm sure you could too, but how to get it used is the question?

Some of the 'safest' languages don't even make VDC's list, unless they are perhaps grouped into the 'Other' category of 11.5%, languages like Esterel and Erlang for example.

To me Esterel seems to be the most obscure language that is used in the most safety critical applications such as flight controls and railroad safety. Esterel has the company Esterel Technologies behind it, as well as an Open Source implementation of an Esterel Compiler. To get a feel of what it is like at the top end of the Safety Critical scale check out some of the Webinars such as Software and Hardware Foundations for Safety Critical.

Next in my obscure list of safe languages would be Erlang. Erlang runs a large percentage of the worlds telephone network, and is considered a 'soft' real time system (dead line can be missed without catastrophic consequences). There has been no larger and longer running networked system than the telephone company. I'm always amused to see such things as 'new' networking technologies rediscovering and reinventing problems and solutions that Erlang solved over a decade ago.


Because Erlang almost has what I'm looking for such as being small (in the sense of running on small micros), and meeting hard real time deadlines, Erlang is the one Functional Language that I play with the most, but does not meet those two criteria.

Functional Languages, in contrast to Procedural Languages like C, take a different approach and mind set to creating safe code.

WikiPedia details the concepts behind Functional programming, the two most important concepts being:

  • Functions have no side effects; a function can not change a global variable for exmple.
  • Data is immutable. Variables are single assignment; Variables don't change value after being set the first time.

Eliminating side effects can make it much easier to understand and predict the behavior of a program, because you are never asking yourself questions like "What is the value of X right now?", X can only be assigned once, so you always know its value.

Professor Stephen A. Edwards whom is a tenured associate professor in the Computer Science Department of Columbia University, once told me that freshman students to his class that had no programming experience picked up Functional Languages, and languages like Esterel quickly, while people that had experience with programming languages such as 'C', struggled to make the transition. Variables that never vary their value can be tough to get your mind around at first, if you programmed in 'C'.

Professor Edwards has put fourth his paper High-level Synthesis from Functional Languages proposing that Functional Languages can be directly compiled to FPGA hardware.

Functional Languages where destined to live in obscurity until this week [Nov. 5th, 2010] when Don Syme of Microsoft announced that the F# Compiler plus Library Source Code is now available as a free download.

While F#,which has its roots in Objective CAML, has little hope of running on a microprocessor based Embedded System, Functional Languages just got a big push in to being more main stream with potential integration to things like Visual Studio. It is my hope that soon there will be a micro friendly Functional Language, that gains widespread adoption.

Will Functional Languages save us? We can only hope.

In closing it is worth mentioning that UML comes in at 5.8% on the VDC report, so I thought I'd mention Miro Samek's new graphical modeling tool QM, that I'm just starting to learn myself. The QM tool is available now for a free download and free, unrestricted use.

Saturday, September 11, 2010

MISRA tutorial and seminar announcement. Standards or Guidelines?

If you are a world traveler, The Motor Industry Software Reliability Association (MISRA) just announced a tutorial and seminar:

"A tutorial and seminar in collaboration with the Safety-Critical Systems Club (SCSC) will be held on 24 and 25 November 2010 in London, UK. On the first day there will be two half-day tutorials, on the MISRA C and MISRA C++ guidelines for the use of these languages in critical systems. The second day will be a seminar that will consider how the MISRA guidelines support safety-related systems development in various industry sectors, and we are particularly keen to feature presentations of case studies. If you would like to speak at this seminar, please discuss your idea with me in the first instance.

Further details of the programme will be available in due course.

There will also be a small exhibition on the second day. Details of the exhibition are available from Joan Atkinson at the SCSC

____________________
Dr David Ward
MISRA Project Manager
Article:

http://www.misra.org.uk/forum/viewtopic.php?f=210&t=1058&p=2032#p2032"

For those not familiar with MISRA, MISRA publishes a set of 'Guidelines' on 'Best Practices' for the languages C and C++. For example what languages constructs are bug prone and should be avoided in embedded systems used in vehicles. Many companies outside of the automotive industry have adopted the use of these guidelines, to help keep bugs out of their products.

Netrino also has a similar set of guidelines, with some links to some real world tips: Embedded C Coding Standard.

A technical semantic nit I want to pick is that these are guidelines. Standards are set by recognized bodies like IEEE and IEC - International Electrotechnical Commission. I frequently see things like "MISRA Standard". The distinction is a subtle one, but could be important to a product liability suite. Which is not to say that a company can not set 'internal standards' for coding practices. English is such a wonderful language... :-(

IEEE P730 Standards Software Quality Assurance, IEEE/EIA 12207.0 Standard for Information Technology - Software Life Cycle Processes, and IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems, are all example of standards used in Embedded Systems. There are more examples at my Software Safety site.