Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart 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: References: <87o75bwlp8.fsf@bsb.me.uk> <871q27weeh.fsf@bsb.me.uk> <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk> <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk> 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: Bytes: 7227 On 08/09/2024 01:05, Waldek Hebisch wrote: > Bart 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?