[SystemSafety] C for OSs

Mon Sep 16 18:53:07 CEST 2019

Chris Hills wrote:

“There is no One Book.”

And

“the principals of Software Engineering are reasonably stable.”

Yes, I agree. Two comments to add on to that. First, I think that version 3 of the Guide to the Software Engineering Body of Knowledge (SWEBOK Guide V3) is a reasonable survey of the discipline of software engineering. It’s not perfect the way it stands, some things could be improved, IMHO. But there is a lot more right with it than wrong with it. You can get a free copy of SWEBOK Guide by going to www.swebok.org. Keep in mind that it is “a guide to …” and not “the body of knowledge”. It’s a survey of the skills and knowledge, it doesn’t contain all of that knowledge within itself. It’s also worth mentioning that it was quite a struggle but the SWEBOK Guide editorial committee reduced the survey of Software Engineering skills and knowledge down to a core set of 36 references. You can see them at:

https://www.computer.org/education/bodies-of-knowledge/software-engineering/swebok-reference-list

My point here is that it cannot be one book, it was quite a struggle to narrow it down to 36 representative books and papers.

Second, ACM and IEEE Computer Society jointly worked out the “Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering” (aka SE 2014). The structure of the knowledge areas in S 2014 is different than in SWEBOK Guide, but the breadth is essentially identical. You can find SE 2014 at:

https://www.acm.org/binaries/content/assets/education/se2014.pdf

Again, this shows that the scope of Software Engineering is far broader than what can be imparted in one single book. I hope it also makes it obvious that the so-called Coding Camps (“Learn programming in only 6 weeks!”) are hopeless.

— steve

From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of Chris Hills <safetyyork at phaedsys.com<mailto:safetyyork at phaedsys.com>>
Organization: Phaedrus Systems
Reply-To: "safetyyork at phaedsys.com<mailto:safetyyork at phaedsys.com>" <safetyyork at phaedsys.com<mailto:safetyyork at phaedsys.com>>
Date: Monday, September 16, 2019 at 3:03 AM
To: 'The System Safety List' <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] C for OSs

There is no One Book.
To do that starts another religion.

What amuses me is that people will recommend the K&R  book to learn C from.  The second edition is nearly 30 years old.  Since the second edition the C standard has grown in size many times over and the book covers a fraction of the language,  some of which has changed.

Even in 2019 I have found people using C11 and C18 who have the K&R 1st edition from the 1970’s and recommend it to new programmers to learn from as it is “The bible” of C.

However the principals of Software Engineering are reasonably stable.

From: Gergely Buday [mailto:gbuday at gmail.com]
Sent: Monday, September 16, 2019 8:05 AM
To: safetyyork at phaedsys.com<mailto:safetyyork at phaedsys.com>
Cc: The System Safety List; Olwen Morgan
Subject: Re: [SystemSafety] C for OSs

"The problem is the industry was flooded with a huge number of self-taught programmers."

What book should we base the teaching of software engineers? Where is the holy grail of true software engineering?

- Gergely

Chris Hills <safetyyork at phaedsys.com<mailto:safetyyork at phaedsys.com>> ezt írta (időpont: 2019. szept. 15., V 19:40):
Hi,

(catching up which is what Sunday afternoons are for)

I have often said at conferences, much to Rod’s horror, that C can be made as good as SPARK.  I then start going through some of the things you are going to have to do to subset and sort out on the way  when I usually get interrupted by someone (other than Rod) to say “wouldn’t it be easier to use SPARK in the first place?”  To which the answer is “yes”

The problem is not technical in the way most think.

As Derek Jones said early on in this “Another way of looking at this is as a statistical sampling problem. If the most heavily used OSs are written in X, then X will experience the most faults.” So we should be careful what, and how we are measuring these things.

And as David MENTRÉ said:-  As usual, the problem is more social than technical: people don't want to change their habits, because they cannot due to external constraints, or think they cannot due to external constraints.

So simply changing the language used is not going to stop the problem, merely change it.  Going back to my first point about C and SPARK.  If programmers were Software Engineers and properly engineered software (which is a social problem)   things would be very different and all software would be written as though it was for a critical system.

As an aside I now say “critical software” and explain that safety, security, mission or commercially critical are all the same. Unless your brief is to write buggy and incomplete code…

You can write bad software in most languages.  Simply relying on the language implementation tools as a primary (and often only method)   to stop the developers doing something silly is not really a good idea.

I once had to work in Modula 2  “because Mod2 had an ISO standard” and was “good” this was the year before the ISO C standard. However the 3 compilers we had for Modula 2 has some major differences and some serious faults.  So whist the theoretical language was “good” the implementation was dangerous.

What is needed is a complete change in the way software is developed at a social level.

I blame Clive Sinclair.

When he flooded the UK with home computers anyone who could copy type a program from “your ZX80”  magazine into their Sinclair ZX80 and get it to run was A Programmer.  If you could modify it and it still ran you were A GURU.   The problem is the industry was flooded with a huge number of self-taught programmers.  Where in the land of the blind a one eyed man is king.  Many of the bad habits and attitudes in software can be traced back to the 1980’s  and 90’s.  Many can still be seen alive and well 40+ years on.

If we solved that problem software would be far more reliable and the differences between C programs and SPARK  programs would be an order of magnitude (or two) less.   They would still be there but you have to ask would C 90 have been allowed to run off in to  C99 and C11 without first fixing the problems in C90
Regards
   Chris

Phaedrus Systems Ltd
FREEphone 0808 1800 358    International +44 1827 259 546
Vat GB860621831  Co Reg #04120771
Http://www.phaedsys.com<http://www.phaedsys.com/>  chills at phaedsys.com<mailto:chills at phaedsys.com>

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>] On Behalf Of Olwen Morgan
Sent: Monday, September 9, 2019 11:14 AM
To: systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] C for OSs

For the avoidance of doubt, IMO you cannot equal SPARK Ada code quality in C. I've only ever said that you can approach it (albeit, I'm confident, fairly closely) by using different best-of-breed tools and exercising a severe coding discipline that takes a long time - and perhaps a peculiar mindset - to acquire.

And all that hassle really shouldn't be necessary in the first place.

Olwen

This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com<http://www.bullguard.com/tracking.aspx?affiliate=bullguard&buyaffiliate=smtp&url=/>
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com<http://www.bullguard.com/tracking.aspx?affiliate=bullguard&buyaffiliate=smtp&url=/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190916/60e7cdec/attachment-0001.html>