[Info-vax] Building for Customers, Revenue

[Shark8]

On 9/16/2014 8:23 AM, bill at server3.cs.scranton.edu (Bill Gunshannon) wrote:
> In article <gbYRv.159900$p7.152940 at fx26.iad>,
> 	Shark8 <OneWingedShark at gmail.com> writes:
>> On 9/16/2014 5:55 AM, bill at server3.cs.scranton.edu (Bill Gunshannon) wrote:
>>>
>>> And are we supposed to somehow understand that it was the use of C++
>>> that caused this?
>>>
>>> bill
>>
>> I think that the point is that C++ was chosen because it was
>> popular/modern -- yet the programmers still fell into the Y2K trap.
>
> I can't think of any language that cold have prevented that.  :-)

As in designed in a way that will fail, sure.
Though you can have languages that make it a bit obvious that things 
will fail -- Ada, for example, has an excellent date-handling package:

> package Ada.Calendar is
>
>    type Time is private;
>    --  Declarations representing limits of allowed local time values. Note that
>    --  these do NOT constrain the possible stored values of time which may well
>
>    --  permit a larger range of times (this is explicitly allowed in Ada 95).
>    subtype Year_Number  is Integer range 1901 .. 2099;
>    subtype Month_Number is Integer range 1 .. 12;
>
>    subtype Day_Number   is Integer range 1 .. 31;
>
>    subtype Day_Duration is Duration range 0.0 .. 86_400.0;

The point of failure here is obvious: for this implementation no years 
greater than 2099 will be valid.

> I have long been an advocate of the idea that one of the first steps
> in Software Engineering is choosing the right tool for the job.  I
> have never gotten any traction with that and the preference remains
> picking the language du jour no matter how badly suited it is to the
> job.

You and I are in agreement there -- I think one reason it doesn't catch 
on is because the best tool is usually unfamiliar; another is that "good 
enough"/"X *can* [technically] do it"; yet a third is that many 
[general-purpose] languages give little-to-no consideration to 
interfacing with other languages.

That last point is something that VMS minimizes with the Common Language 
Environment... but VMS is not popular/wide-use at the moment; it's this 
CLE along with several other OS-handled notions [integrated/transparent 
DB, indexed files, versioning, etc] which makes it very, very attractive 
to build a integrated programming support environment [IPSE]. While the 
idea of such has been around since the `80s it was dropped in favor of a 
more simplistic view of programming (encouraged, I believe, by the 
prevalence of Unix and C). -- In short, I believe VMS could be made into 
something that developers on other systems would envy.