29 Apr
2016
29 Apr
'16
6:09 a.m.
From: Swift Griggs
even though there is *more* overall documentation on
the Internet, the
docs you get with hardware and tools are nowhere near as good as they
were in the 80s AFAIK.
I think that's partially because the speed of product cycles has sped up;
there just isn't time to get good docs done and out. Also, there's more
competitiveness/'efficiency', and good documentation costs money/overhead.
Wonderful as e.g. DEC Technical Manuals were, I suspect producing their ilk
nowadays is simply beyond the industry's capabilities (in the organizational
sense, not the technical skill sense).
From: Liam Proven
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).
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.
As to whether those two are harmful - they can be. You have to have a 'clean'
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.)
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.
(E.g. build a 'system' of routines to manage a certain kind of objects -
like OO languages enforce in the language itself - and the average user
only calls foo_allocate(), etc.)
I actually hugely admire 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.
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
_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.
Noel
29 Apr
29 Apr
6:51 a.m.
On 29 April 2016 at 15:09, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
True, at least up to a point.
I am indeed interested.
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.
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.
Linux is boring to me now. It's an enterprise tool. I want to see the
effort, the development, the fiery new ideas being spent on something
new and different... and I'm not seeing much of it.
--
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)
From: Swift
Griggs
even though there is *more* overall documentation
on the Internet, the
docs you get with hardware and tools are nowhere near as good as they
were in the 80s AFAIK.
I think that's partially because the speed of product cycles has sped up;
there just isn't time to get good docs done and out. Also, there's more
competitiveness/'efficiency', and good documentation costs money/overhead.
Wonderful as e.g. DEC Technical Manuals were, I suspect producing their ilk
nowadays is simply beyond the industry's capabilities (in the organizational
sense, not the technical skill sense). From: Liam
Proven
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).
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. As to whether those two are harmful - they can be. You
have to have a 'clean'
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.
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.
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.
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.
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
...
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.
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
_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. 
9:59 a.m.
On Fri, Apr 29, 2016 at 03:51:12PM +0200, Liam Proven wrote:
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.
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.
There are many warts in C I would remove if I had the power to. ;)
C is an absolutely terrible language.
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).
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.
> 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.
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
7:12 p.m.
On 04/29/2016 11:59 AM, Diane Bruce wrote:
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.
DEC Pascal and Borland's Turbo Pascal had
separate
compilation that worked pretty well. The one place I see
Pascal being a bit out of the league of other systems was
standard text and numeric I/O being substantially slower
than the I/O library routines for some other languages. Not
a problem if just reading or writing a page of text, but if
handling hundreds of K you definitely notice. Binary I/O
seemed to be OK.
Jon
7:33 a.m.
On 29 April 2016 at 15:09, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
Unix was designed in a way which demanded that nearly every function
(except for a few built-in ones in the shell) was implemented as a
program. So to build a Unix system you built the kernel, that one's
written in C, but that's not the important part - you also built the
hundreds, and soon thousands of applications, all written in C. To be
able to compile those "Unix tools" (usr/src/*) every C compiler had to
confirm to a defacto standard in a way other language compilers didn't
have to. Usually somebody defines a standard, and then everybody else
will decide that it's not *that* important to follow the standard -
let's improve it a bit here and there. That wouldn't work for C. To
this day C is more standard than nearly everything else. Including
C++, which doesn't have the same must-compile-all-old-source pressure.
So, the way I see it is that C became incredibly popular not just
because it's usable for a wide range of purposes, but even more
because "C is C is C".
-Tor
From: Liam
Proven
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). 
8:43 a.m.
On Apr 29, 2016, at 9:09 AM, Noel Chiappa <jnc at
mercury.lcs.mit.edu> wrote:
...
I think the answer is simpler: Unix was adopted by a number of academic groups because it
was available on easy terms, and it was adopted by a very successful company (Sun).
If Burroughs had been successful, its Algol might well have won; it certainly is every bit
as capable as C and far safer. (For those who don't want safety, there's ESPOL.)
paul
From: Liam Proven
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).
2940
days inactive
2941
days old
5 comments
6 participants
participants (6)
-
db＠db.net -
elson＠pico-systems.com -
jnc＠mercury.lcs.mit.edu -
kspt.tor＠gmail.com -
lproven＠gmail.com -
paulkoning＠comcast.net