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

[Arne Vajhøj]

On 4/14/2022 6:39 PM, Dave Froble wrote:
> 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 ?

That is the argument for functions - not the arguments for nested
functions.

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

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

If you have a large applications, then having 1000 global visible
functions expose a lot of internals. If you instead have
50 global visible functions that use 200 local visible functions
that use 750 next level visible functions, then have reduced
what get exposed to only what need to be exposed and you keep
the internals internal.

Arne