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

[Richard Maher]

On 15/04/2022 7:12 am, Arne Vajhøj wrote:
> 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
> 
> 

COBOL and program-id IS COMMON and GLOBAL variables was just so far 
ahead of its time