Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Sun, 8 Sep 2024 12:05:12 +0100
Organization: A noiseless patient Spider
Lines: 136
Message-ID: <vbk0d9$1tajm$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <87o75bwlp8.fsf@bsb.me.uk>
 <vaps06$3vg8l$1@dont-email.me> <871q27weeh.fsf@bsb.me.uk>
 <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk>
 <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk>
 <vaq9tu$1te8$1@dont-email.me> <vbci8r$1c9e8$1@paganini.bofh.team>
 <vbcs65$eabn$1@dont-email.me> <vbekut$1kd24$1@paganini.bofh.team>
 <vbepcb$q6p2$1@dont-email.me> <vbgb5q$1ruv8$1@paganini.bofh.team>
 <vbhbbb$1blt4$1@dont-email.me> <vbipp5$24kl5$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 08 Sep 2024 13:05:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ad79b9a69b5377684053ea6685c7dbff";
	logging-data="2009718"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/J00XpAPACruvaFp+/EiFn"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:oYLRmJdeQJ1abWsvMA/G/dj0tjM=
Content-Language: en-GB
In-Reply-To: <vbipp5$24kl5$1@paganini.bofh.team>
Bytes: 7227

On 08/09/2024 01:05, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:

>> Then you no longer have a language which can be implemented in a few KB.
>> You might as well use a real with with proper data types, and not have
>> the stack exposed in the language. Forth code can be very cryptic
>> because of that.
> 
> First, it is not my goal to advocate for Forth use.

You're doing a fine job of it!

For me it's one of those languages, like Brainf*ck, which is trivial to 
implement (I've done both), but next to impossible to code in.

With Forth, I had to look for sample programs to try out, and discovered 
that Forth was really a myriad different dialects. It's more of a DIY 
language that you make up as you go along.


> : 2*3 =>
> ** 6
> : 2, 3, *() =>
> ** 6
> the first line is infix form, '=>' oprator prints what is on
> the stack (but you cat treat it as "print current result").
> In the second line two numbers are pushed on the stack and
> then there is call to multiplication routine.  Parser knows
> that '*' is an operator, but since there are no argument
> '*' is treated as ordinary identifer and as result you
> get multiplication routine.  Like in other languages parentheses
> mean function call.  Up to now this may look just as some
> weirdness with no purpose.  But there are advantages.  One
> is that Pop11 functions can return multiple values, they just
> put as many values as needed on the stack.  Second, one can
> write functions which take variable number of arguments.
> And one can use say a loop to put varible number of arguments
> on the stack and then call a routine expecting variable
> number of arguments.  In fact, there is common Pop11 idiom
> to handle aggregas: 'explode' puts all members of the aggregate
> on the stack.  There are also constructor function which build
> aggregates from values on the stack.

This sounds like one of my bytecode languages.

So, in the same way that Lisp looks like the output of an AST dump, 
these stack languages look like intermediate code:


   HLL ->    AST     ->  Stack IL  ->  Interpret or -> ASM
   (eg. C)   (Lisp)      (Forth)
                         (Pop-11)

Most people prefer to code in a HLL. But this at least shows Lisp as 
being higher level than Forth, and it's a language that can also be 
bootstrapped from a tiny implementation.

> Coming back to Forth, you can easily add infix syntax to Forth
> but Forth users somewhat dislike idea of using infix for most
> of programming.  My personal opinion is that Fort was good
> around 1980.  At that time there was quite simple implementation,
> language offered interactive developement and some powerful
> feature and there were interesting compromise between speed
> and size.

Around that time I was working on several languages that were low level 
and with small implementations, which included running directly on 8-bit 
hardware. They all looked like proper HLLS, if crude and simple.

There was no need to go 'weird'. For lower level, I used assembly, where 
you weren't constrained to a stack.

>> What started the subthread was the question of which HLL goes between
>> ASM and C (since someone suggested that C was mid-level).
> 
> Well, for me important question is how much work is due to tools
> (basically overhead) and how much deals with problem domain.
> Since computers are now much heaper compared to human work
> there is desire to reduce tool overhead as much as possible.
> This favours higher level languages, so probably most recently
> created languages is at higher level than C.  However, in
> sixties and seventies there were pack of so called algorithmic
> languages or somewhat more specifically Algol family.  I would
> say that C is close to the middle of this pack.

My exposure before I first looked at C was to Algol, Pascal, Fortran 
(and COBOL).

C struck me as crude, and I would have placed it lower than FORTRAN IV, 
even though the latter had no structured statements. But that was 
because it exposed less in the language - you couldn't play around with 
variable addresses for example. So FORTRAN was no good for systems 
programming.

I'd also looked at Algol68, which was higher level than any of those. So 
my own first language used syntax from that, but with simplified 
semantics and with explicit pointer/address ops. It was a fine systems 
language.



>  As a devils
> advocate let me compare typical implementation of early Pascal
....
> of early languages were at lower level than Pascal.

You're taking all those, to me, chaotic features of C as being superior 
to Pascal.

Like being able define anonymous structs always anywhere, or allowing 
multiple declarations of the same module-level variables and functions.

Pascal was a teaching language and some thought went into its structure 
(unlike C). In my hands I would have given it some tweaks to make it a 
viable systems language. For a better evolution of Pascal, forget Wirth, 
look at Ada, even thought that is not my thing because it is too strict 
for my style.


>> People suggested ones like BLISS and Forth.
>>
>> I remarked that a proper HLL would let you write just A to either read
>> the value of variable A, or write to it. Eg. A = A, without special
>> operators to dereference A's address.
> 
> You are looking at superficial things.

Syntax IS superficial! But it's pretty important otherwise we'd be 
programming in binary machine code, or lambda calculus.

> I am not going to write substantial programs in Bliss or Forth
> but I have no double they are HLL-s.

So, what would a non-HLL look like to you that is not actual assembly?