> Oj ale to chyba nieco naiwne - że niby przetestowanie wynikowego kodu
> zagwarantuje brak bugów.

Nie zagwarantuje, tylko potwierdzi. Bo niby jak inaczej?

> Nie zagwarantuje, bo nie ma opcji by dało się
> przetestować wynikowy program w 100%

Witamy w branży systemów krytycznych. To nie jest opcja, tylko poziom oczekiwany.
I dlaczego miałoby się nie dać?

> (wliczając w to np. ładowanie
> relokowalnego kodu

Nie ma relokowalnego kodu. Właśnie dlatego.

> To nie znaczy oczywiście, że nie należy do tego dążyć,
> jeśli ekonomia projektu na to pozwala.

Ekonomia jest taka, że ma być 100%.

> > To kolejny mit. Wszyscy programiści kosztują z grubsza tyle samo, bo ich
> > koszt i tak już dawno nie zależy od ich kompetencji.
>
> Ja tam jednak obserwuję duże różnice w zależności od języka. Im więcej
> towaru na rynku, tym bardziej jego wartość spada.

Ale to nie zależy od niszowości języka, tylko od podaży i popytu. Jeżeli język X jest
niszowy, to i tak jedyny programista w Polsce będzie tanim hobbystą, jeśli będzie dla
niego 0 projektów. Niszowość mu nie pomoże.
Problemem na rynku pracy jest brak programistów w ogóle a nie to, czy coś jest
niszowe, czy nie.

> > Nie używa się bibliotek. Szkoda na to nerwów, znacznie szybciej jest
> > napisać i zweryfikować coś od zera samemu.
>
> Wliczając w to libc?

Tak. W sumie i tak nie ma tam nic ciekawego z punktu widzenia jakiegokolwiek systemu
krytycznego.

> "nie używa się"
> uważam za nieco zbyt kategoryczny obraz...

Nie używa się, bo obcy (!) kod jest bardziej kosztowny w weryfikacji, niż własny.
Obowiązek zapewnienia 100% pokrycia istnieje dla *całego* kodu a nie tylko dla
jakiegoś drobnego kawałka, który napisałeś sam, a pokrywanie kodu jakiejś obcej
biblioteki albo wykazywanie jej zgodności z wymaganiami projektu to jest coś, czego
nikt nie chciałby robić.

--
Maciej Sobczak * http://www.inspirel.com