strangest systems I've sent email from

[Diane Bruce]

On Fri, Apr 29, 2016 at 03:51:12PM +0200, Liam Proven wrote:
> On 29 April 2016 at 15:09, Noel Chiappa <jnc at 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: lproven at cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
> MSN: lproven at hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
> Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
> 

-- 
- db at FreeBSD.org db at db.net http://www.db.net/~db