On Fri, Apr 29, 2016 at 03:51:12PM +0200, Liam Proven wrote: > On 29 April 2016 at 15:09, Noel Chiappa <j...@mercury.lcs.mit.edu> wrote: > > > From: Swift Griggs > > ... > > > C is popular because C is popular. > > > > Yes, but that had to start somewhere. > > > > I think it _became_ popular for two reasons: i) it was 'the' language of > > Unix, and Unix was so much better than 99% of the alternatives _at the time_ > > that it grew like crazy, and ii) C was a lot better than many of the > > alternatives _at the time it first appeared_ (for a number of reasons, which > > I won't expand on unless there is interest). > > > > I am indeed interested.
XPL wasn't bad. (http://www.cs.toronto.edu/XPL/) PL/M wasn't bad either. For low level that is. Pascal and the Bell Northern Research, BNR (prior to Nortel amalgamation) derivative were pretty awful. Fortunately I never had to use the BNR version. They both suffered from not having separate compilation units, at least until near the end of BNR. > > > > direct memory allocation, pointer manipulation and so on -- are > > > widespread /because/ of the C family influence. And I have a deep > > > suspicion that these are harmful things. > > > > Pointers, yes. Allocation, not really - a lot of languages have heaps. Did > > you mean manual freeing when you mention 'memory allocation', because > > technically even something like CONS allocates memory? And one could > > consider > > 'auto' variables as 'allocated' - but the 'freeing' is automatic, when the > > routine returns. > > Well, malloc() and free(), anyway. > > I can't find the citation but I have seen references to GC > environments actually being _faster_ on well-structured systems. > Notably, LispMs. Yes they can be. Scavenger collector GC. Telephone companies preferred deterministic behaviour from their code and operating systems. GC is not and non-blocking send message passing kernels are not deterministic. > > > As to whether those two are harmful - they can be. You have to have a > > 'clean' Remember kids, Pascal is for children, C is for consenting adults. > > programming style to use them extensively without running into problems. (I > > personally have only rarely run into problems with them - and then mostly in > > very early C, before casts existed, because of C's wierd pointer math > > rules.) > > Well exactly. Some people can use Lisp macros to do brilliant things; > most can't. Some people can write clean, safe C; most can't. There are many warts in C I would remove if I had the power to. ;) C is an absolutely terrible language. > > Not everyone's a genius. > > And those who aren't, often don't know. See Dunning-Kruger. Klutzes > think they're gods; gods think they're klutzes. I could tell you stories sometime.... > > As Yeats put it: > > "The best lack all conviction, while the worst / Are full of > passionate intensity." > > So we *need* safe languages for the non-geniuses who think they're > brilliant. You tempt 'em in with productivity and tools and keep them > in a safe space where they can be productive. Delphi was superb for > this. Sure. I'd also suggest 'C' is overused and misused for too many reasons. But *everyone* thinks they are a C programmer these days, which is silly. OTH we still need a language where you can do the bad bad undefined things, just don't expect it to be super portable when you do. C is a high level PDP-11 assembler to this day. (auto increment and decrement) > > > I would need to think about this for a while to really come up with a good > > position, but my initial sense is that these two are perhaps things that > > should be hidden in the depths of large systems, for use by very good > > programmers, that 'average' programmers should only be using higher-level > > constructs. Totally. > > The thing is, the very good and the average often don't know it, and > non-technical managers can't tell. So, keep everyone in the safe > space, but offer power tools -- like Lisp macros -- so the brilliant > are not held back. > > > > I actually hugely admire Linux I prefer FreeBSD these days after a longish period of using Linux. ;) > > > ... > > > We are continuing to refine and tweak a 1970s-style OS -- a > > > technologically conservative monolithic Unix. FOSS Unix hasn't even > > > caught up with 1990s style Unix design yet, the early microkernel ones > > > .. It's roughly 2 decades behind the times. Agreed. Dragonfly is more interesting and some of the work Tannebaum is doing is exciting too. http://www.slideshare.net/eurobsdcon/andy-tanenbaum-euro-bsdcon2014v2 > > > > I'm a bit puzzled by your first thought, given your follow-on (which I agree > > with). > > > > I'd go further in criticizing Linux (and basically all other Unix > > descendants), though - your latter comment above is just about the Technically Linux is not a Unix descendant so much as a reimplementation. ;) But ok. ;) > > _implementation_. I have a problem with the _basic semantics_ - i.e. the > > computational environment provided to user code. It was fantastic on a > > PDP-11 > > - near-'mainframe' levels of capability on a tiny 16-bit machine. > > On modern machines... not so much. macros suck. They totally made sense on a VAX when one needed inline code because VAX calls were expensive and the compiler couldn't handle inline code generation otherwise. Nowadays? Except for manifest declarations (Constants) I'd remove macros. ;) Please don't waste tomatoes, I love eating them. ;) > > Well, yes, definitely, that too. I cut my teeth on VMS and preferred > it. I'd love to see some more totally non-Unix-like OSes, but I'd also > like to see Unix moving forward, not just sitting there getting better > and better at what it already is. Hey I did some VMS work too. You must remember BLISS. ;) ... > -- > Liam Proven • Profile: http://lproven.livejournal.com/profile > Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven > MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven > Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR) > -- - d...@freebsd.org d...@db.net http://www.db.net/~db