[Info-vax] First ship poll: When will the first native x86-64 compilers ship ?

[Dave Froble]

On 4/14/2022 2:08 PM, Simon Clubley wrote:
> On 2022-04-14, Dave Froble <davef at tsoft-inc.com> wrote:
>> On 4/14/2022 1:17 AM, Richard Maher wrote:
>>> On 14/04/2022 12:23 pm, Dave Froble wrote:
>>>> On 4/13/2022 10:10 PM, Arne Vajhøj wrote:
>>>>> On 4/13/2022 8:43 PM, Dave Froble wrote:
>>>>>>
>>>>>> Can you better define nested functions?  Then I can decide if
>>>>>> Basic allows such.
>>>>>
>>>>> Functions declared inside functions (and therefore only available inside the
>>>>> declaring function).
>>>>>
>>>>
>>>> Ok, what is so neat about that?
>>>>
>>>> I cannot see the point, when if one wants to use a second function inside a
>>>> first function, another external function should be
>>>> callable. Haven't tried it recently.  Maybe I should.  Perhaps I
>>>> should know what I'm talking about at least once a year.
>>>>
>>>> But I can see no reason to have a function defined inside another
>>>> function.
>>>>
>>>
>>> Encapsulation/Isolation
>>
>> Isolation from what?  You're writing the code, you decide what to write, I still
>> don't see the point.
>>
>
> When you write an application that's say 20,000 lines long, do you
> write one great big monolithic function that's 20,000 lines long and
> with sections of common code copy and pasted around in the application,
> or do you split up the application into logical chunks and also include
> common functions with a defined interface that can be called from
> multiple points in your application ?

Sorry, hit the wrong button.

Simon, I am the world's greatest believer in modularity.

I have libraries of often used functionality.

I break tasks down into reasonable units.

I really try to keep things as simple and understandable as possible.

When one creates an "object" to perform a task, then one can invoke that same 
"object" many times, from all over the main task.  (Use of term "object" intended.)

This has caused one problem.  It is not the language, but the implementation of 
the return from a routine that can be so costly.  ("Yes John, I'm still upset 
about this.)  We've had "objects" that have been called hundreds of thousands, 
even millions of times, to perform a simple task, and the performance has 
suffered greatly.  We've had at times to go into the program and inline the code 
for performance reasons.  (We should not have to do this John.)

But the philosophy has been, keep it small, keep it simple, keep it reusable.

> If it's the latter, you are already performing encapsulation and
> isolation of functionality and nested procedures are just the
> next step in that process.

But why?  Why would anyone ever want to encapsulate some object inside another 
object?  Not saying there will never be a reason, but, I just don't see it.

Nor would I consider modularity and encapsulation to be the same concept, or, 
perhaps that is arguing symantics.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486