[fpc-devel] was: type discussion

[Sebastian Kaliszewski]

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 
snignificant.


>>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 
> included.

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 
kSLoC system.


>>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
>>>some study.)
>>
>>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 
> correctly.

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
>>Java.
> 
> 
> 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.
> 
> What?
> 
> http://shootout.alioth.debian.org/
> benchmark.php?test=all&lang=icc&lang2=ocaml&sort=fullcpu
> 
> 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;
>>>|begin
>>>|   ...
>>>|end;
>>>
>>>in Ada looks
>>>
>>>|function Foo (I : in Integer) return Integer is
>>>|begin
>>>|  ...
>>>|end Foo;
>>
>>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 
memory management.


In one lang you'd have to write:

for i:=1 to len(arr) do begin
   if arr[i] = 0 then
     break
end;

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.

rgds
-- 
Sebastian Kaliszewski