Re: candidate of add. language in src (not rust)

On Tue, 23 Sep 2025 12:23:28 +0300
Anthony Pankov <anthony.pankov@yahoo.com> wrote:

> Monday, September 22, 2025, 1:50:48 AM, you wrote:
> 
> > On Tue, 16 Sep 2025 13:59:53 +0300
> > Anthony Pankov <anthony.pankov@yahoo.com> wrote:
> 
> > What's wanted (for me) to judge it is "is it standardized by ISO /
> > IEC?".
> > Means, adding something is OK (but not assured to be standardized on
> > next updates of the standard), but deletion and / or backwaed
> > incompatible modifications are clearly "prohibited", at worst, strongly
> > discouraged, not to force rewriting good enough codes in the future.
> 
> > This (hopefully) would mean it's safe to code something important with
> > the language using only standardized (and marked as mandatory) features
> > only.
> 
> That is the question. 
> 
> When I talk to students about IPv4 TCP/IP stack I say, "These are simple, clear subsystems. And if you've forgotten something, you can figure it out yourself using logic." But I don't know what to tell them about IPv6. When I read IPv6 related RFC I see that somebody want to solve specific thing somehow and put a solution as a standard. I remember Python 2.7->3.0 tragedy cutting many projects that lack manpower to rewrite code.

Internet RFCs are "running (de-facto) standards". I think they're not
always good enough to consider "stable de-jure standards".

And don't forget that the name "RFC" comes from "Request For Comments".
Not "fixed up" standards.

ISO standards has several phases.
  NWIP (New Work In Progress),
  WD(Working Draft),
  CD (Committee Draft),
  DIS (Draft International Standard for voting),
  FDIS (Final DIS) and
  IS (International Standard)
and co-called ISO standards are in IS phase.
If things are unchanged, anything after CD (at worst, DIS) are sold to
be available for anyone (any organizations) interested.

I consider Internet RFC as CD through DIS, depending on its quality.
Not IS. Some could be near FDIS.


And my point is that once becoming initial IS, tragedies like Python
2.x to 3 SHALL not be allwed and another brand-new standard SHOULD be
created as a different individual programming langurage.

  *The term "SHALL" here is used WRT ISO standards. Nothing more,
   nothing less. Same for "SHOULD", "COULD", "MAY", ...

And for standards (including pre-IS phases and RFC) having options,
the safest is to use MANDATORY parts only.

Just my opinion, but defining some complexed things as standards,
options are not at all good, and everything SHOULD be MANDATORY,
to make / keep things clear enough.

OTOH, simple enough things COULD have OPTIONAL things.
There would be far less confusions.

C would be the exception for Unix-derived OS'es, as, IIUC, C was
developed for writing Unix itself instead of CPU-dependent assembly
languages. So could be yacc, lex and m4 and so on used for developing C.


> I see something like OAuth so bloating and complex that I feel it there only to raise a barrier of required man-hours for realization. I do not recognize C++ which was clearly understandable when I learn it via Gradi Booch and Straustrup book's. There is a Linux also that makes de facto and formal standards by itself...

Agreed with you.

Making fundamental part forming the protocol itself to be one standard,
and "moving goals" parts like cryptographic functions to be used (yes,
this would change on improvements of technologies) to be separated
simple (what cryptographic functions can be used and how each functions
are called is defined, and also what NOT to be used, what arguments and
return value are typed and named, keeping implementation details for
each functions to be separate standards) would be wanted.

Regards.

> So, that is the question.
> 
> 
> -- 
> Best regards,
> Anthony


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>