[fpc-devel] was: type discussion
sebaska at melkor.mimuw.edu.pl
Fri Jun 3 19:50:36 CEST 2005
I think we're mostly offtopic now, maybe we should EOT or move to private
Vinzent Hoefler wrote:
>>Of course C is much worse than contemporary C++ (C++ + std::).
> Only in theory. Look at typical projects in the industry.
I have close look at the projects in my company. And the difference is
>>Count separate apps not separate instalations.
> Doesn't change the count much, I think. Every f*cking microwave oven has
> its own control program these days.
I suspecct that owens from the same manufacturer have the same program or
their programs differ only minmally. Then how complex those programs are?
Now look how many different general computing apps are out there? The count
goes in millions, i think.
> I'm just asking because somebody from a car company claimed that one bug
> per 1000 SLOC would be "the normal expected amount" and I got a study
> here that claims a bug rate of less then a tenth (0.096 defects/KSLOC
> [and even for their C-Code, they had 0.676 defects/KSLOC]) for "just a
> compiler and related tools", not for potentially life-critical systems
> as you'd expect in the 70 or more microprocessors a modern car has
> built in.
> Which seems quite surprising considering that the bug rate should be
> practically independent of the language (ok, this statement is not
> valid for C99, of course, it's the only exception there). Sarcasm
Depends how the bugs were counted. In the study I talk, AFAIR there was
quite a variation between solutins, but no correlation of defects/kLoC to
programming language was found.
>>Smaller programs are easier to maitain.
> Yes, but small programs are not the typical project. Even small projects
> break through the 100 KSLOC barrier very quick.
Smaller <> small. But it's generally easier to mainatin 100 kSLoC vs 200
>>You can do most of apps withing time & bugget even in pure machine
>>code if you'll assume huge enough budget and long enough time.
> Considering that it wasn't government money they had to waste, instead
> they took the risk of the whole development theirselves, this certainly
> wasn't the case here.
Lokheed-Martin not wasting goverment money!?! That's something new ;)
>>>Yes, true. Funny thing is, that those companies are now almost able
>>>to deliver software cheaper than the mainstream. If they would cut
>>>the testing completely, they definitely could and the software
>>>wouldn't even be as worse. (BTW, that's my own observation, not
>>The same functionality?
> Yes. MULTOS/CA had 0.04 defects per KSLOC with an average "productivity"
> of 28 lines of code per developer per day, if I remember the figures
But kSLoC <> kSLoC. What amount of functionality was there is also important.
>>No. Simply preventing some failure is economically viable if
>>cost_of_failure * probality_of_filure > const_of_prevention.
> Yes. But Cost_Of_Failure sometimes seems to be a negative amount while
> Cost_Of_Prevention never is.
That's true only in some special cases, and mostly if you're monopoly. But
even MicroSoft had to improve their soft. Sales lost due to customet
dissatisfaction are also cost of failure.
>>Nope. There was enough time to develop the app in all but some
>>ackward joke languages. Problem was simple & well understood.
> Yeah. The latter may be the problem. Most real world problems are
> neither simple nor they are well understood just until after you solved
> them. :-)
Well, I'd say that most of the software is doing the well understood stuff
only slightly differing from things already done.
>>That's the reality. Just look at properly designed languages, not
> I'm looking at the stuff that gets used most often, because it must be
> superior then, otherwise nobody would use it.
You're joking, right?
> But i.e. Python's
> automatic memory system didn't convince me any bit more, although it
> seems more effective to me.
Pyhton is not very concerned with performance. Besides there are dynamically
typed languages much faster than it (Dylan for example).
>>See comparison with C. They're more or less equal performance wise.
> doesn't look much *equal* to me. Maybe, my feeling for numbers is
> screwed up.
The difference is not big. It's allmost the same as with C++ vs C.
>>>|function Foo (const I : Integer) : Integer;
>>>in Ada looks
>>>|function Foo (I : in Integer) return Integer is
>>But what is that '...' is what matters.
> Yes, of course. But we were talking about verbosity in general and not
> on the amount of standard libraries.
Hmmm... Verbosity is not important. Expresiveness is. You can have language
with verbose or not verbose constructs, but wether those constructs are
expressive or not is an orthogonal matter.
C constructs are typilcally non-expressive and not verbose. Standard Pascal
construct are verbose but not too expressive. Object Pascal (i.e. FPC) is
more expressive. Ada, C++ with std:: or OCaml are even more expressive.
> To be honest: I wouldn't expect much difference between Ada and
> (Free)Pascal programs in terms of lines of code there. But I'd expect a
> difference in terms of declaration lines and in FreePascal a much
> lesser amount of needed code because of the relatively large amount of
> libraries you can use (which usually don't account for SLOC).
Well, quite a lot of SLoc is consumed by simple stuff not requiring large
standard library. Personally I don't like languages with bloated standard
library (case example: Java). At some point you'll lose more time looking
for library feature to solve your problem that actually solving it yourself.
Not to mention that such large bloated libraries are quite often full of
bugs. Your app will be no better than library it uses.
So often relatively simple things are what make or break expreiveness. C vs
Pascal example: set -- try acheiving the same in C.
But there is more of that stuff like maps/dictionaries, dynamic arrays,
autmatic destructoe calling at the end of scope, etc. Or even automatic
In one lang you'd have to write:
for i:=1 to len(arr) do begin
if arr[i] = 0 then
And in anther:
i := find(arr, 0);
And in yet another:
i := arr.Find(0);
Verbosity of the particular constructs is the same (all are Pascal
variants), but 2 later have better expresiveness of their basic datastructures.
More information about the fpc-devel