Re: Optimization techniques and runtime checks

On 08/05/2019 02:27, Hans-Peter Diettrich wrote:
> Am 07.05.2019 um 16:29 schrieb David Brown:
>> On 29/04/2019 22:36, Hans-Peter Diettrich wrote:
>>> Am 28.04.2019 um 23:49 schrieb David Brown:
>
>>>> This is exactly the same as mathematics.  The "square root" function,
>>>> for real numbers, is defined for non-negative numbers.  If someone asks
>>>> you for "sqrt(-4)", then the question is meaningless.  Any answer given
>>>> can be considered incorrect - equally, any answer given can be
>>>> considered correct.
>>>
>>> That's a cheap excuse for poor language design, aimed at sloppy compiler
>>> implementation.
>>>
>>
>> You are saying that mathematics is a poor language design?
>
> No, I criticize the lack of restricted (non-negative...) types for such
> purposes.


OK. Again, I'd note that different languages have different design
requirements and different uses. (Although I agree that such specific
ranged types are nice, and are a feature of Pascal that I miss in C.)


>
>
>> Different languages have different purposes and trade-offs.  This is
>> important to accept when discussing them.
>
> No doubt :-)
>
> So I wonder why the topic (optimization...) drifted into a discussion of
> almost only the C language.
>


C is a language that many people know, one for which optimisations are
very important, and where certain kinds of optimisations can be
controversial - and therefore lead to discussions. If everyone is happy
with a language's definitions, behaviours, and typical optimisations,
there'd be no arguments and few posts!


But by all means, add more about Pascal or any other language you like
to this thread - it could be interesting for many of us.


> I also wonder where runtime efficiency nowadays is really so important,
> that safety and security breaches are considered acceptable?
>


This depends on the use of the code.


I have many times noted that C is often a poor choice of language.
There was a time when it was the best, or only, language suitable for a
wide range of uses. This is no longer the case. I personally use it
for small-systems embedded programming, and the runtime efficiency /is/
important. But for PC programming, I use mostly Python (I used to use
Delphi more). Pick a language that makes sense for the job, and gives
the trade-offs that suit your needs.




And often there is no way to handle run-time errors sensibly anyway.
You don't want your car brakes to give you a message "Your braking
system has encountered an integer overflow. Please report this error to
your car dealer". You want the brake software developers to be
/absolutely/ sure that overflows can't happen - and then there is no
point in run-time checks.




C is not going away. But it would be good to see less C code used, but
more care used with the C code that is written. That includes testing
with tools that do run-time checks, but not having them included in the
final product. It is the run-time efficiency of the underlying C code
in libraries, VMs, etc., that makes the speed of most checked languages
acceptable.


>
>> Every language has its oddities, and there are always things that some
>> people thing are terrible design.  For example, it is truly weird that
>> "const x : int = 10;" is one of Delphi's way of making "x" a variable
>> with an initialised value.  (In older Delphi, it was the only way!)
>
> This makes the different evolution visible:
> Pascal started as a tutorial language, C as a production language.
> Evolution added features of great demand - in the case of Pascal many
> features had to be added to Wirth's academic language(s) before it
> became usable outside education.
>


Yes. I realise that this oddity is "for historical reasons". The same
applies to a great many oddities in C.


> I definitely prefer a safe language, which can be tuned later for
> efficieny. Lowering requirements and checks in specific parts of a
> program is doable and acceptable easier than introducing requirements
> that were not anticipated in the basic language design.
>
> DoDi
> [These days I write just about everything in python.  Occasionally
> I'll rewrite something in C if python can't do it but that's pretty
> rare.  The python implementation everyone uses is written in C but it
> does a pretty good job of managing storage and arithmetic. -John]


That's the way to do it.

Return to the comp.compilers page.
Search the comp.compilers archives again.