[Digikam-users] Digikam and the KDE

[Benjamin GIRAULT]

2011/10/9 sleepless <sleeplessregulus at hetnet.nl>:
> Bugs should not be there! Imagine the airplane industry worked this way,
> sending the planes in the air and fix bugs after every crash and then with
> every fix introducing three new ones.

Think about what the software of an airplane is doing. Each of its
tasks alone is fairly simple (read a sensor, display its value or act
according to its value), and the difficulty does not come from that,
but from the scheduling of those tasks such that each is performed
within the required time. Thus their requirements are completely
different: no bugs. However, this is achieved at the cost of
efficiency: the cpus are often waiting for tasks to do, and the
hardware is kept to a minimum (there are in CPUs made for desktop PCs
a lot of non determinism, both hardware and software, that prevent one
from proving anything software related, thing for example of when a
thread is taking over within a single core CPU, or when an interrupt
can happen...) to have a good model of the hardware (which is required
to prove softwares).

The main tasks of programmers is then to do an efficient and correct
scheduling, and prove it (which involves not only engineers but also
researchers). People in the critical embedded programming have
dedicated tools (such as Scade) to do this. Proving Qt, KDE or Digikam
is something noone want, or even is able, to do, and using tools like
Scade does not make any sense. Thus, bugs are expected.

My guess is that if someone claims to write programs without bugs, it
can mean 2 things, either that this person is lying or is burying is
head in the sand, or that he never wrote a program of more than a
hundred lines.

Also, do not mix up programming language and library. The kde
libraries, and QT, are written in C++, which is a low level
programming language, are high level libraries. Programming languages
of higher level are Python, Java, OCaml, Haskell, Prolog, etc... What
you could think as limitations for those are rather possibilities. For
example, with functional programming languages (like OCaml and
Haskell) it is much easier to prove programs. For high level
libraries, it allows the programmer to both code faster, and not to
have to reinvent the wheel.

-- 
Benjamin.