Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 26 Aug 2024 17:55:21 -0700
Organization: A noiseless patient Spider
Lines: 112
Message-ID: <867cc24wee.fsf@linuxsc.com>
References: <vab101$3er$1@reader1.panix.com> <vad7ns$1g27b$1@raubtier-asyl.eternal-september.org> <vad8lr$1fv5u$1@dont-email.me> <vafmiv$202ef$1@dont-email.me> <20240825201124.000017a3@yahoo.com> <86msl05ctt.fsf@linuxsc.com> <20240826105456.0000150a@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 27 Aug 2024 02:55:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2126a4cc73d47322f0204dd590f16dc6";
	logging-data="2816341"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+kpZ9GpBjsEX0m1sWuB1ATThrczHf26W0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:OHFeNPhV+wIKuwiIaMAEz8yQjQc=
	sha1:c5U7KqO4eAhg8DXFXaHRPqjO4tM=
Bytes: 5938

Michael S <already5chosen@yahoo.com> writes:

> On Sun, 25 Aug 2024 17:48:14 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Sun, 25 Aug 2024 18:36:46 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
[...]

>>>> It's true that C++ decided to inherit unsafe C designs as C being
>>>> sort of its base.  But a sophisticated programmer would knowingly
>>>> avoid the unsafe parts and use the existing safer C++ constructs.
>>>> Only that a language allows that you *can* write bad code doesn't
>>>> mean you cannot avoid the problems.  Of course it would have been
>>>> (IMO) better if the unsafe parts were replaced or left out, but
>>>> there were portability consideration in C++'s design.
>>>>
>>>>
>>>>> [...]
>>>
>>> Safe HLLs without mandatory automatic memory management
>>
>> I'm not sure what you mean by this description.  Do you mean
>> languages that are otherwise unsafe but have a safe subset?
>> If not that then please elaborate.
>
> That is nearly always a case in practice, but it does not have to
> be.  I can't give a counterexample, but I can imagine language
> similar to Pascal that has no records with variants and no
> procedure Dispose and also hardens few other corners that I
> currently forgot about.

Does this description mean anything different than saying "Pascal
with all the unsafe parts taken out", without saying what all the
unsafe parts are?

>> What are some examples of
>> "safe HLLs without mandatory automatic memory management"?
>
> The most prominent examples are Ada and Rust.

I don't think of either Ada or Rust as safe languages.  I expect
there are some barriers in both languages to using unsafe features,
but also that it's easy to get around the barriers if one chooses
to do so.  (I should add that I have little to no "real world"
experience in either Ada or Rust.)

>>> tend to fall
>>> into two categories:
>>> 1.  Those that already failed to become popular
>>> 2.  Those for which it will happen soon
>>
>> It's been amusing reading a discussion of which languages are or are
>> not high level, without anyone offering a definition of what the
>> term means.  Wikipedia says, roughly, that a high-level language is
>> one that doesn't provide machine-level access (and IMO that is a
>> reasonable characterization).
>
> I don't like this definition.  IMHO, what language does have is at
> least as important as what it does not have for the purpose of
> estimating its level.

I think Wikipedia means to give a definition in the dictionary
sense of the word, namely, presenting the most commonly held view,
or sometimes the most commonly held views plural, of how the word
or term is used.  It is in this dictionary sense that I say the
definition is a reasonable characterization.  In particular I don't
mean to say that this meaning is "good", only that it is common
(and also has reasonably high historical fidelity).

>> Of course no distinction along these
>> lines is black and white - almost all languages have a loophole or
>> two - but I expect there is general agreement about which languages
>> clearly fail that test.  In particular, any language that offers
>> easy access to raw memory addresses (and both C and C++ certainly
>> do), is not a high-level language in the Wikipedia sense.
>>
>> Second amusement:  using the term popular without giving any
>> kind of a metric that measures popularity.
>
> Precise definitions of everything are hard.  [...]

Sure.  But that shouldn't stop someone from giving an imprecise
or informal definition.  Any attempt to give a useful definition
is infinitely better than no definition.

>> Third amusement:  any language that has not yet become popular
>> has already failed to become popular.
>
> There is also "heir apparent' type - languages that are recognized
> as not particularly popular now, but believed by many, including
> press, to become popular in the future.

Ahhh, so now we have a new metric to consider, whether a language
is _expected to become_ popular in the future (and an indeterminate
future at that).

Please forgive me if that comment comes across as snarky.  Mostly I
just find the whole concept amusing... I don't mean to do that at
your expense.

>>> That despite at least one language in the 1st category being
>>> pretty well designed, if more than a little over-engineered.
>>
>> Please, don't keep us in suspense.  To what language do you refer?
>
> I thought, that every reader understood that I meant Ada.

I expect many readers did.  If I had had to guess I would have
guessed Rust.