[Info-vax] VSI: "Official 8.4-1H1 Launch"

[David Froble]

Stephen Hoffman wrote:
> On 2015-06-15 21:55:59 +0000, David Froble said:
> 
>> Well, coding is what we do, right?
> 
> Yes.  Preferably we're all making improvements that mean we're using 
> less code, too.

TANSTAAFL

In reality, it is not less code.  A task is a task, and to do it 
requires whatever it requires.  It may be code in a library, or it may 
be code written for the specific task.  But the code required for the 
task remains pretty much the same.

>> My only problems with item lists are first wrapping my mind around the 
>> concept, and that's not too hard.  The worst problem was the declining 
>> standards for documentation that accompanied VMS's adoption of C as a 
>> System Programming language.
>>
>> As for coding, I had little problem with item lists in Basic.  The 
>> RECORD construct is rather flexible and powerful.
> 
> That's true.  But you're not using assembler here, probably because 
> having fewer lines of code is easier to write and to troubleshoot and to 
> maintain than a solution with more lines of code.

I have used assembler when it was more efficient and / or was the bset 
tool for the task.

> Though the code itself is easy, the C and BASIC sequences for a system 
> service call are still much more code than is necessary.
> 
> For instance, the following returns a list (an array, technically) of 
> the various host names associated with your current computer:
> 
> NSArray *hostNames = [[NSHost currentHost] names];
> 
> or to get a string containing the primary host name with the following:
> 
> NSString *hostName = [[NSHost currentHost] name];
> 
> Technically, that stuff can get even shorter using what's called dot 
> notation.  The following is a full command-line program that prints out 
> all of the local host names, and exits.
> 
> #import <Foundation/Foundation.h>
> int main(int argc, const char * argv[]) {
>    @autoreleasepool {
>        NSLog(@"%@", NSHost.currentHost.names);
>    }
> }
> 
> This is a whole lot less code than what's available on OpenVMS to 
> retrieve that same data, as an example.  Sure, this means we programmers 
> then push this stuff down into a local subroutine or a local subroutine 
> library, and pretty soon we have an extensive library of features and 
> calls that we're maintaining.  (I've open-sourced some of that glue 
> code, as have some other folks.  But I digress.)  Much like moving from 
> Macro32 to BASIC, it'd be better if we were rid of our existing morass 
> of glue code, as that'd lower the cost for new users, and even for us 
> folks with existing libraries and tools.

I actually do see differences between code in a library someone else has 
provided, and code in a library that I've written.

 From your perspective, I don't have to re-write what someone else has 
provided.  That is one of the basic concepts in how software has advanced.

 From my perspective, sometimes I have difficulty in using someone 
else's code.  Much more rarely do I have difficulty using code I've 
written.  Now, if I've decently documented code I've written, why isn't 
it just as good as what others have provided?  I say it's better for me, 
and perhaps it's better than what others have provided, but that can get 
rather subjective.

I've known two basic types of programmers.  Those who understand what 
they are doing, and usually do a good job.  Then there are those who 
"cut-n-paste" code others have written, many times not really 
understanding what it is doing.  For them, things usually don't end well.

So, in today's IT world, we seem to have some of the former, and many of 
the latter.  Using all the available tools, and lack of understanding, 
some really bad stuff has been produced.  Look at the security mess.  I 
doubt some of these so called programmers understand the concepts.  If 
you give some who don't understand binary a bit mask they don't know 
what to do with it.

Back in the day we all learned the basics.  Today, many consider 
themselves "computer literate" and programmers without having a clue 
about the basics.  Some might claim that with the tools available they 
don't need to know the basics.  Some might claim that knowledge isn't 
important, getting the job done is all that matters.

Long ago I declared a rule.  "Before I can design an application to 
solve a problem, I first must be able to solve the problem without a 
computer."  I think that is a pretty good rule.

I think there is another rule that I never declared, but is still rather 
meaningful.  "Before you can use a software tool you need to understand 
what it does and how it does it."  I think this rule is violated quite 
often today.

Some may disagree with me.  Doesn't make them any more right than I am.