"The long goodbye to C" by Eric Raymond

[Lynn McGuire]

"The long goodbye to C" by Eric Raymond
http://esr.ibiblio.org/?p=7711

"I was thinking a couple of days ago about the new wave of systems
languages now challenging C for its place at the top of the
systems-programming heap – Go and Rust, in particular. I reached a
startling realization – I have 35 years of experience in C. I write C
code pretty much every week, but I can no longer remember when I last
started a new project in C!"

I doubt it.

Lynn

[Rick C. Hodgin]

It's true. Unless C evolves, it will be slowly relegated to only
niche markets, and will die as a language for any real projects.

The whole purpose of CAlive is to inject new life into C by bringing
forward some of the features of other languages, and to introduce new
features, while maintaining backward compatibility.

It is obvious to anyone who is looking: C is dying quickly due to
the age of visual languages, and computers fast enough to run much
slower code written in other languages faster than the fastest C
could do on the CPUs available earlier this century.

The times, they are a changin'.

--
Rick C. Hodgin

[jacobnavia]

Raymond says:
...and so was obviously silly to do in C or any other language without
dynamic allocation and a real string type

With "dynamic allocation" he means a GC...

Lcc-win incorporated a GC since 2005 or earlier, I do not remember.
But all the discussions here about why a GC, etc, led to people (like is
always the case in this newsgroup) started complaining that "sombody
could write a pointer to a file and then read it, then the GC would
introduce a bug".

"Besides it is slow"

"Besides that, it is non-standard"

And they won, I never made any larger consensus, and here most people
(Raymond included) see C as a thing of the past. At the same time they
will fight anyone that tries to improve the language.

I wrote a string package with real strings using operator overloading.
But I never got any traction about it, with the C++ guys that feared the
competition of a simpler language, that joined with the guys that repeated:

"C is for embedded microcontrollers only"

A typical representative of this kind of thinking was Heathfield and his
friend Thompson.

They won, I lost.

C is leading nowhere, with the C committee convinced that C++ is the way
to go.

Luckily the server in Virginia is down, and lcc-win will disappear, a
stupid idea of somebody that refuses to go into the complexity wagon,
like everybody else.

It has been a long goodbye, yes.

[Keith Thompson]

jacobnavia <ja...@jacob.remcomp.fr> writes:
[...]

> Raymond says:
> ...and so was obviously silly to do in C or any other language without
> dynamic allocation and a real string type
>
> With "dynamic allocation" he means a GC...
>
> Lcc-win incorporated a GC since 2005 or earlier, I do not remember.
> But all the discussions here about why a GC, etc, led to people (like is
> always the case in this newsgroup) started complaining that "sombody
> could write a pointer to a file and then read it, then the GC would
> introduce a bug".

As I recall, I and others correctly pointed out that the ability
to write a pointer value to a file and then reread it made it
impossible to have full GC in a fully conforming C implementation.

That fact doesn't mean that GC is a bad idea, or that GC *in C*
is a bad idea. It's just a non-conforming language extension --
and the non-conformance is likely not to matter for most code.

> "Besides it is slow"

I don't know about that.

> "Besides that, it is non-standard"

Well, yes, it is. That's not necessarily an entirely bad thing.

> And they won, I never made any larger consensus, and here most people
> (Raymond included) see C as a thing of the past. At the same time they
> will fight anyone that tries to improve the language.
>
> I wrote a string package with real strings using operator overloading.
> But I never got any traction about it, with the C++ guys that feared the
> competition of a simpler language, that joined with the guys that repeated:
>
> "C is for embedded microcontrollers only"

Nobody said that.

> A typical representative of this kind of thinking was Heathfield and his
> friend Thompson.
>
> They won, I lost.

If that's what you believe, you've completely misunderstood what I was
saying. Can you cite an article in which I discouraged you from
implementing GC in your compiler? (Pointing out that it's
non-conforming in some cases doesn't count; nobody requires your
compiler to be fully conforming.)

[self-pity snipped]

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Spiros Bousbouras]

On Wed, 15 Nov 2017 02:33:56 +0100
jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Raymond says:
> ...and so was obviously silly to do in C or any other language without
> dynamic allocation and a real string type
>
> With "dynamic allocation" he means a GC...
>
> Lcc-win incorporated a GC since 2005 or earlier, I do not remember.

There is also the Boehm-Demers-Weiser garbage collector. Automatic
garbage collection is a solved problem in C.

[...]

> And they won, I never made any larger consensus, and here most people
> (Raymond included) see C as a thing of the past. At the same time they
> will fight anyone that tries to improve the language.

You're imagining things.

> I wrote a string package with real strings using operator overloading.
> But I never got any traction about it,

Yes I remember that and I don't see the point. When I want better strings
that what C has I start with something like

struct better_string {
char *s ;
size_t sz ;
} ;

and add more stuff depending on my needs.

> with the C++ guys that feared the
> competition of a simpler language, that joined with the guys that repeated:

Oh so it was C++ people "fighting" you as well ? You have made many times
the claim that people on comp.lang.c were fighting you but I don't remember
seeing before the claim about C++ people too.

> "C is for embedded microcontrollers only"
>
> A typical representative of this kind of thinking was Heathfield and his
> friend Thompson.

You're making stuff up.

> They won, I lost.

There was a period when a large percentage of your posts were around the
lines "if C doesn't get feature X then C will die" and that people were
fighting you , etc. That was very tedious to me partly because many of your
"essential" features were things I wasn't much interested in and on the other
hand you seemed completely oblivious to the fact that other people may have
other preferences about what additions to C they want. I hope you're not
going back to that kind of posting.

> C is leading nowhere, with the C committee convinced that C++ is the way
> to go.

You may have a point regarding the C committee leading the language nowhere ,
annex K for example seems to me much complexity for hardly any gain. But if
the C committee will not push things forward then it's up to other people to
do it. Now of course you have been trying to do this but personally I'm not
taken by your vision and the way you advertise it thoroughly sucks. I hardly
know anything about marketing but my impression is (and it makes intuitive
sense too) that to get people onboard (especially computer programmers) you
need a positive vision not negative admonishments. So for example instead of
saying "if C doesn't get a native string type with operator overloading , C
will die" it's better to say how much more wonderful and pleasant C
programming is with a native string type with operator overloading. So if you
were to switch to positive optimistic talk regarding your extensions to C and
also avoided picking up fights with imaginary enemies and making wild
unfounded accusations , you will get a much better response.

> Luckily the server in Virginia is down, and lcc-win will disappear, a
> stupid idea of somebody that refuses to go into the complexity wagon,
> like everybody else.

You seem to take a masochistic pleasure in doom and gloom. Once you get your
present doom and gloom fix , I expect you will find a new place to host your
compiler and it will be available again within a few weeks (or the Virginia
server situation will resolve as having been just a technical glitch). I
wouldn't be surprised if you interpret my saying this as me "fighting" you.


--
What is a Goedelian rhetorical question ? It's when someone asks "Is this a
rhetorical question ?" and they're only asking rhetorically.

[David Brown]

On 15/11/17 00:19, Rick C. Hodgin wrote:
> On Tuesday, November 14, 2017 at 5:13:13 PM UTC-5, Lynn McGuire wrote:
>> "The long goodbye to C" by Eric Raymond
>> http://esr.ibiblio.org/?p=7711
>>
>> "I was thinking a couple of days ago about the new wave of systems
>> languages now challenging C for its place at the top of the
>> systems-programming heap – Go and Rust, in particular. I reached a
>> startling realization – I have 35 years of experience in C. I write C
>> code pretty much every week, but I can no longer remember when I last
>> started a new project in C!"
>>
>> I doubt it.
>>
>> Lynn
>
> It's true. Unless C evolves, it will be slowly relegated to only
> niche markets, and will die as a language for any real projects.

So what? If a language is not suitable for new projects, then that is
because there are better choices - so use them. Lots of languages and
tools that were fantastic in their day are no longer particularly
relevant. How many new projects are written in Pascal? Fortran?
Basic? The answer is a few - they are still the best choice in niche cases.

C needs to evolve to allow us to work with existing C code, and to allow
us to write code in C in situations where C is still the best language
choice. It does not need to move into new areas, or make big changes -
that would reduce its usefulness in existing situations where simplicity
and stability are key. C will /never/ be a modern language, and no
amount of "evolution" will make it one - when you put enough into C to
get a modern language you end up with C++, Objective-C, Rust, etc. - all
fine languages for their use, and all tracing their roots back to C, but
none of them /are/ C.

>
> The whole purpose of CAlive is to inject new life into C by bringing
> forward some of the features of other languages, and to introduce new
> features, while maintaining backward compatibility.

CAlive is not C - it is a totally different language designed in a
different way for a different purpose. That is absolutely fine - we
don't need another C, because we already /have/ C. Make your language
the way you want, but stop trying to kid yourself that it is the "future
of C" or "evolved C". Adding some way to support C code does not make
it an enhanced C any more than a C compiler's "asm" statement means that
C is an enhanced assembly.

>
> It is obvious to anyone who is looking: C is dying quickly due to
> the age of visual languages, and computers fast enough to run much
> slower code written in other languages faster than the fastest C
> could do on the CPUs available earlier this century.
>

Again, so what? If it makes more sense to write a program in Python, or
Rust, or APL - then write the program in those languages. There can be
many good reasons for choosing C as the language for a new project -
"because it is C" is /not/ one of them.

> The times, they are a changin'.
>

True. So change with them, rather than clinging on to the past.

There are plenty of "niche areas" for C as yet. People who want to
program in C will find lots to do for a long time to come. It is only
the people that insist that they will use C regardless of the task, that
will have trouble.

[Malcolm McLean]

On Wednesday, November 15, 2017 at 4:04:58 AM UTC, Spiros Bousbouras wrote:
> On Wed, 15 Nov 2017 02:33:56 +0100
> jacobnavia <ja...@jacob.remcomp.fr> wrote:
> > ...and so was obviously silly to do in C or any other language without
> > dynamic allocation and a real string type
> >
> > With "dynamic allocation" he means a GC...
> >
> > Lcc-win incorporated a GC since 2005 or earlier, I do not remember.
>
> There is also the Boehm-Demers-Weiser garbage collector. Automatic
> garbage collection is a solved problem in C.
>

Garbage collection is a fundamental change. lcc has it, which moves it on
from ANSI C in a substantial way. Unfortunately it didn't attract a critical
mass of users to make it into effectively the new high-level C standard,
and other languages are starting to fill the niche that lcc-win would have
filled wth something still essentially C.

>
> > Luckily the server in Virginia is down, and lcc-win will disappear, a
> > stupid idea of somebody that refuses to go into the complexity wagon,
> > like everybody else.
>
> You seem to take a masochistic pleasure in doom and gloom. Once you get your
> present doom and gloom fix , I expect you will find a new place to host your
> compiler and it will be available again within a few weeks (or the Virginia
> server situation will resolve as having been just a technical glitch). I
> wouldn't be surprised if you interpret my saying this as me "fighting" you.
>

The frustrations of the internet, where you have "link rot" as old pages are taken
offline. Most of them are obsolete, but some are still useful. It happened
to my own website.

[Spiros Bousbouras]

On Wed, 15 Nov 2017 01:56:11 -0800 (PST)
Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> On Wednesday, November 15, 2017 at 4:04:58 AM UTC, Spiros Bousbouras wrote:
> > On Wed, 15 Nov 2017 02:33:56 +0100
> > jacobnavia <ja...@jacob.remcomp.fr> wrote:
> > > ...and so was obviously silly to do in C or any other language without
> > > dynamic allocation and a real string type
> > >
> > > With "dynamic allocation" he means a GC...
> > >
> > > Lcc-win incorporated a GC since 2005 or earlier, I do not remember.
> >
> > There is also the Boehm-Demers-Weiser garbage collector. Automatic
> > garbage collection is a solved problem in C.
> >
> Garbage collection is a fundamental change. lcc has it, which moves it on
> from ANSI C in a substantial way.

What does garbage collection in lcc have over Boehm-Demers-Weiser ?

> Unfortunately it didn't attract a critical
> mass of users to make it into effectively the new high-level C standard,
> and other languages are starting to fill the niche that lcc-win would have
> filled wth something still essentially C.

Why past tense ? As long as lcc is available (and I'm sure it will be again
soon) the effort to attract "a critical mass of users" is ongoing. The best
way to do it is to create a substantial open source project (or rewrite an
existing one) using the extensions of lcc and show how much more convenient
it is to program in this version of C.

--
Useds of Facebook: People may think they use Facebook, but really Facebook uses
them. So I call them "useds" of Facebook.
www.stallman.org/glossary.html

[David Brown]

On 15/11/17 10:56, Malcolm McLean wrote:
> On Wednesday, November 15, 2017 at 4:04:58 AM UTC, Spiros Bousbouras wrote:
>> On Wed, 15 Nov 2017 02:33:56 +0100
>> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> ...and so was obviously silly to do in C or any other language without
>>> dynamic allocation and a real string type
>>>
>>> With "dynamic allocation" he means a GC...
>>>
>>> Lcc-win incorporated a GC since 2005 or earlier, I do not remember.
>>
>> There is also the Boehm-Demers-Weiser garbage collector. Automatic
>> garbage collection is a solved problem in C.
>>
> Garbage collection is a fundamental change. lcc has it, which moves it on
> from ANSI C in a substantial way. Unfortunately it didn't attract a critical
> mass of users to make it into effectively the new high-level C standard,
> and other languages are starting to fill the niche that lcc-win would have
> filled wth something still essentially C.

The Boehm garbage collector has been around for decades, is free, and
portable. There is no need for compiler support (though of course
compiler extensions could reduce the manual coding). It does not
fundamentally change C - it is implemented in standard C.

You could certainly argue that it is a fundamental change to the way
dynamic memory works in C - but dynamic memory is just one part of C,
and is not used in all code. Many C programs either don't use dynamic
memory at all, or handle it specially in some way (such as memory pools)
- garbage collection is just one of many alternatives.

Garbage collection does not turn C into a higher level language. It
does not make C into the new style of languages like Rust and Go. It is
not new - Boehm's code has been around for a couple of decades or more,
and is far and away the most popular automatic garbage collection for C
(much more so than lcc-win). Lcc-win has some nice extensions to C that
I am sure many people could find useful, and Jacob also has his
container library that again could be useful for some. But it is not
revolutionary.

[Malcolm McLean]

On Wednesday, November 15, 2017 at 10:49:27 AM UTC, Spiros Bousbouras wrote:
> On Wed, 15 Nov 2017 01:56:11 -0800 (PST)
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > On Wednesday, November 15, 2017 at 4:04:58 AM UTC, Spiros Bousbouras wrote:
> > > On Wed, 15 Nov 2017 02:33:56 +0100
> > > jacobnavia <ja...@jacob.remcomp.fr> wrote:
> > > > ...and so was obviously silly to do in C or any other language without
> > > > dynamic allocation and a real string type
> > > >
> > > > With "dynamic allocation" he means a GC...
> > > >
> > > > Lcc-win incorporated a GC since 2005 or earlier, I do not remember.
> > >
> > > There is also the Boehm-Demers-Weiser garbage collector. Automatic
> > > garbage collection is a solved problem in C.
> > >
> > Garbage collection is a fundamental change. lcc has it, which moves it on
> > from ANSI C in a substantial way.
>
> What does garbage collection in lcc have over Boehm-Demers-Weiser ?
>

It comes with the compiler, whilst if all you have is an ANSI C compiler you have
to use platform-specific code to implement Boehm-Demers-Weiser (at least I
guess, I don't know how it works). Jacob might use BDW under the hood, but
I think he has his own method.

>
> > Unfortunately it didn't attract a critical
> > mass of users to make it into effectively the new high-level C standard,
> > and other languages are starting to fill the niche that lcc-win would have
> > filled wth something still essentially C.
>
> Why past tense ? As long as lcc is available (and I'm sure it will be again
> soon) the effort to attract "a critical mass of users" is ongoing. The best
> way to do it is to create a substantial open source project (or rewrite an
> existing one) using the extensions of lcc and show how much more convenient
> it is to program in this version of C.
>

That's sound advice. Actually lcc-win has shipped with Matlab, which means that
it has found some use writing C functions for calling from Matlab. Support from
a major vendor is the way most programming languages reach the mainstream.
There's always a chicken and egg effect, if something doesn't have widespread
use, it's a high risk decision to use it.

[Ben Bacarisse]

Malcolm McLean <malcolm.ar...@gmail.com> writes:

> On Wednesday, November 15, 2017 at 4:04:58 AM UTC, Spiros Bousbouras wrote:
>> On Wed, 15 Nov 2017 02:33:56 +0100
>> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> > ...and so was obviously silly to do in C or any other language without
>> > dynamic allocation and a real string type
>> >
>> > With "dynamic allocation" he means a GC...
>> >
>> > Lcc-win incorporated a GC since 2005 or earlier, I do not remember.
>>
>> There is also the Boehm-Demers-Weiser garbage collector. Automatic
>> garbage collection is a solved problem in C.
>>
> Garbage collection is a fundamental change. lcc has it, which moves it on
> from ANSI C in a substantial way.

lccwin32 (lcc is as separate compiler, I think) uses the
Boehm-Demers-Wiser GC library, so I'm not sure what you mean by moving
on from ANSI C in a substantial way. lccwin32 *does* move on from
standard C in *other* ways, but I don't think GC is one of them.
However, as someone who doesn't use it, I may not have understood. I'm
going by the documentation.

<snip>
--
Ben.

[David Brown]

On 15/11/17 12:42, Malcolm McLean wrote:
> On Wednesday, November 15, 2017 at 10:49:27 AM UTC, Spiros Bousbouras wrote:
>> On Wed, 15 Nov 2017 01:56:11 -0800 (PST)
>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>> On Wednesday, November 15, 2017 at 4:04:58 AM UTC, Spiros Bousbouras wrote:
>>>> On Wed, 15 Nov 2017 02:33:56 +0100
>>>> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>>>> ...and so was obviously silly to do in C or any other language without
>>>>> dynamic allocation and a real string type
>>>>>
>>>>> With "dynamic allocation" he means a GC...
>>>>>
>>>>> Lcc-win incorporated a GC since 2005 or earlier, I do not remember.
>>>>
>>>> There is also the Boehm-Demers-Weiser garbage collector. Automatic
>>>> garbage collection is a solved problem in C.
>>>>
>>> Garbage collection is a fundamental change. lcc has it, which moves it on
>>> from ANSI C in a substantial way.
>>
>> What does garbage collection in lcc have over Boehm-Demers-Weiser ?
>>
> It comes with the compiler, whilst if all you have is an ANSI C compiler you have
> to use platform-specific code to implement Boehm-Demers-Weiser (at least I
> guess, I don't know how it works). Jacob might use BDW under the hood, but
> I think he has his own method.

You don't know how Boehm garbage collection works, you don't know how
the implementation works, you don't know its requirements beyond
standard C or its platform limitations. You don't know how lcc's
garbage collection works, how it is used, how it is implemented, or how
it relates to using the Boehm library or algorithms.

So what you /really/ meant to write was "I don't know. Hopefully
someone who /does/ know, such as Jacob, can answer". Wouldn't that make
more sense?

[Mr. Man-wai Chang]

On 15/11/2017 6:13 AM, Lynn McGuire wrote:
> "I was thinking a couple of days ago about the new wave of systems
> languages now challenging C for its place at the top of the
> systems-programming heap – Go and Rust, in particular. I reached a
> startling realization – I have 35 years of experience in C. I write C
> code pretty much every week, but I can no longer remember when I last
> started a new project in C!"

Because there is no new operating system effort? C is not suitable as a
rapid development tool for business applications. That's the real
reasons why there are few new C projects.

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[Pascal J. Bourguignon]

"Mr. Man-wai Chang" <toylet...@gmail.com> writes:

> On 15/11/2017 6:13 AM, Lynn McGuire wrote:
>> "I was thinking a couple of days ago about the new wave of systems
>> languages now challenging C for its place at the top of the
>> systems-programming heap – Go and Rust, in particular. I reached a
>> startling realization – I have 35 years of experience in C. I write C
>> code pretty much every week, but I can no longer remember when I last
>> started a new project in C!"
>
> Because there is no new operating system effort? C is not suitable as
> a rapid development tool for business applications. That's the real
> reasons why there are few new C projects.

There are new operating system efforts, but they definitely don't use C.

More like Common Lisp
https://github.com/froggey/Mezzano/releases/tag/demo3

or other languages, such as Go,
https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item

etc. You can write an OS in any programming language.

--
__Pascal J. Bourguignon
http://www.informatimago.com

[bartc]

On 15/11/2017 08:10, David Brown wrote:
> On 15/11/17 00:19, Rick C. Hodgin wrote:

> C will /never/ be a modern language, and no
> amount of "evolution" will make it one - when you put enough into C to
> get a modern language you end up with C++, Objective-C, Rust, etc.

Because people don't know how to design a new replacement language
without going over the top and making it higher level than the original.
And, therefore, something different.

In the case of C, you have to separate what the language allows you to
DO, all the various low level manipulations, data types and so on, which
gets you close to the machine, with HOW it does it, involving its
peculiar syntax, the crazy macro processor, the special semantics, the
tools with thousands of options, everything people think is what C is about.

But there are other approaches to designing a language that does what C
does. Most other such language have died out, but mine is still used
(and no doubt others that no one knows about).

So I at least am using a 'modern' language that can be used as a low
level implementation language like C. (I say modern but it was first
designed 35 years ago.)

> Adding some way to support C code does not make
> it an enhanced C any more than a C compiler's "asm" statement means that
> C is an enhanced assembly.

I disagree; most of my assembly code in last few decades has been
written as inline assembly within a HLL (the HLL takes care of most
non-executable code, and provides the HLL structure with functions,
scopes and so on).

So there are ways (I've listed over 100 in the past) of enhancing C to
make it better and to make it easier to write low level code.

But if the project demands a higher-level language, then you use that
instead. And of course you can use more than one language in a project.

(In my world there are two languages: one that is static, compiled, low
level, completely transparent, but fast; and one that is higher level,
dynamic, interpreted and slow - but much more productive and less of a
pain to code in.

Some languages are aimed at the rather large gap in between: having
static (or inferred) types, more features, more dynamism, a bit easier
to code, but that is still fast.

But if I give C++ as an example, many (not you) will agree that that one
hasn't really worked... There are also Java, Go and Rust, but those
won't be to everyone's taste either. And they are not small either.)

> There are plenty of "niche areas" for C as yet. People who want to
> program in C will find lots to do for a long time to come. It is only
> the people that insist that they will use C regardless of the task, that
> will have trouble.

Be nice if there was a real choice though when they do need a language
/like/ C.


--
Bartc

[Rick C. Hodgin]

On Wednesday, November 15, 2017 at 10:01:42 AM UTC-5, Bart wrote:
> Be nice if there was a real choice though when they do need a language
> /like/ C.

One of CAlive's greatest goals is to integrate languages into a common
framework, so that C code lives alongside assembly alongside Java
alongside Julia alongside CAlive, etc.

The ability to use the right tool for the right job, all in a single
integrated package through the RDC framework.

If I ever get it completed, it will be a game changer.

--
Rick C. Hodgin

[bartc]

It seems unlikely, using off-the-shelf implementations. Possibly with a
'modified' compiler like the one mentioned in the second link or
requiring a bit of hacking.

The chances are it will depend on some bits that are not in the standard
language. That's if it has to talk to actual hardware and doesn't rely
on some virtual interface to do the hard stuff.

--
bartc

[bartc]

You might be interested in this Link that Pascal posted:

https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item

Interesting choice of name.

(I was thinking Pascal might be stuck thinking up a suitable name if he
ever brought out own language, as the obvious choice has gone...)

--
bartc

[Melzzzzz]

Low level stuff is usually written in C ;)

--
press any key to continue or any other to quit...

[Scott Lurndal]

"Pascal J. Bourguignon" <p...@informatimago.com> writes:

>
>etc. You can write an OS in any programming language.

I once wrote one in a modula-like language called SPRITE.

I'd like to see you write one in COBOL[*].

As it happens, any language used to write an OS needs facilities
not generally required for standard applications (such as access
to the privileged instructions).

[*] Actually, it's not impossible if the extensions to the language
provide access to the hardware. I've seen a disk defragmenter
written in COBOL in production at hundreds of sites - the compiler
offered a facility similar to inline assembler.

[Pascal J. Bourguignon]

bartc <b...@freeuk.com> writes:

> On 15/11/2017 08:10, David Brown wrote:
>> On 15/11/17 00:19, Rick C. Hodgin wrote:
>
>> C will /never/ be a modern language, and no
>> amount of "evolution" will make it one - when you put enough into C to
>> get a modern language you end up with C++, Objective-C, Rust, etc.
>
> Because people don't know how to design a new replacement language
> without going over the top and making it higher level than the
> original. And, therefore, something different.

Well, first you would have to realize that C is not a low level
programming language. There are languages, like Common Lisp that are
lower level than C! (eg. Common Lisp has operators to deal with bit
fields, bit vectors, etc). A lot of other programming languages are
mode fit than C to deal with hardware memory, address computing, such as
Modula-2 or even the OOP language Modula-3!


The only advantage of C is that its (original) design lets you write a
compiler easily on a PDP-7 system with a teletype.

>> There are plenty of "niche areas" for C as yet. People who want to
>> program in C will find lots to do for a long time to come. It is only
>> the people that insist that they will use C regardless of the task, that
>> will have trouble.
>
> Be nice if there was a real choice though when they do need a language
> /like/ C.

Indeed.

[Jens Stuckelberger]

A lot of mental masturbation in the answers here. Relax, guys.
Live and let live - life's too short for such Byzantine disputes.

[bartc]

On 15/11/2017 15:16, Pascal J. Bourguignon wrote:
> bartc <b...@freeuk.com> writes:
>
>> On 15/11/2017 08:10, David Brown wrote:
>>> On 15/11/17 00:19, Rick C. Hodgin wrote:
>>
>>> C will /never/ be a modern language, and no
>>> amount of "evolution" will make it one - when you put enough into C to
>>> get a modern language you end up with C++, Objective-C, Rust, etc.
>>
>> Because people don't know how to design a new replacement language
>> without going over the top and making it higher level than the
>> original. And, therefore, something different.
>
> Well, first you would have to realize that C is not a low level
> programming language. There are languages, like Common Lisp that are
> lower level than C! (eg. Common Lisp has operators to deal with bit
> fields, bit vectors, etc). A lot of other programming languages are
> mode fit than C to deal with hardware memory, address computing, such as
> Modula-2 or even the OOP language Modula-3!

Yes, C could do with being a little more low-level (it only took 30
years until you could confidently define an int the same size as a
machine word, and you still can't officially write a binary constant).

Bit, bit-field, bit-array and bit pointer handling I find generally
useful anyway, and not necessarily a low-level feature, and I wouldn't
call Lisp low-level.

(I have them in my next language up, but not the lower level one because
it's not used enough to be worth the effort.)

All versions of my languages however came with /easy-to-use/ inline
assembly, so that anything is possible.

--
bartc

[Melzzzzz]

On 2017-11-15, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> bartc <b...@freeuk.com> writes:
>
>> On 15/11/2017 08:10, David Brown wrote:
>>> On 15/11/17 00:19, Rick C. Hodgin wrote:
>>
>>> C will /never/ be a modern language, and no
>>> amount of "evolution" will make it one - when you put enough into C to
>>> get a modern language you end up with C++, Objective-C, Rust, etc.
>>
>> Because people don't know how to design a new replacement language
>> without going over the top and making it higher level than the
>> original. And, therefore, something different.
>
> Well, first you would have to realize that C is not a low level
> programming language. There are languages, like Common Lisp that are
> lower level than C! (eg. Common Lisp has operators to deal with bit
> fields, bit vectors, etc). A lot of other programming languages are
> mode fit than C to deal with hardware memory, address computing, such as
> Modula-2 or even the OOP language Modula-3!

Hm. Common Lisp runs in VM... while standard C is useless, non standard
C is more practical for OS programming ;)

[bartc]

Even then, it might need something extra.

Suppose the first thing that needs to done is write zero to port 0x58
(not memory-mapped); how does C do that?

--
bartc

[Dan Cross]

In article <oufppg$aqa$1...@dont-email.me>,

Lynn McGuire <lynnmc...@gmail.com> wrote:
>"The long goodbye to C" by Eric Raymond
> http://esr.ibiblio.org/?p=7711

I started to read this, but then stopped. I find it ever
increasingly difficult to care what ESR says/thinks/does.

- Dan C.

[David Brown]

On 15/11/17 16:02, bartc wrote:
> On 15/11/2017 08:10, David Brown wrote:
>> On 15/11/17 00:19, Rick C. Hodgin wrote:
>
>> C will /never/ be a modern language, and no
>> amount of "evolution" will make it one - when you put enough into C to
>> get a modern language you end up with C++, Objective-C, Rust, etc.
>
> Because people don't know how to design a new replacement language
> without going over the top and making it higher level than the original.
> And, therefore, something different.

We don't need a replacement for C. We've got C - it does the job C
needs to do. If you want a new language to do some of the jobs that C
does today, and perhaps other jobs, then that's fine - but it is a new
language.

I have nothing against making new languages (high level or low level),
or using different languages instead of C. I simply don't understand
why anyone would want to consider it to be a "new C", "evolved C",
"replacement for C".

>
> In the case of C, you have to separate what the language allows you to
> DO, all the various low level manipulations, data types and so on, which
> gets you close to the machine, with HOW it does it, involving its
> peculiar syntax, the crazy macro processor, the special semantics, the
> tools with thousands of options, everything people think is what C is
> about.
>
> But there are other approaches to designing a language that does what C
> does. Most other such language have died out, but mine is still used
> (and no doubt others that no one knows about).

Neither your language, nor anyone else's, does what C does. I can't run
it on a Solaris workstation. I can't use it to target an AVR
microcontroller. I can't use it to compile the source for the libjpg
library. I can't hire a new programmer that understands the language.
I can't buy a book on it, or go on a course for it. It is /not/ a
replacement for C in any reasonable meaning of the term.

You may have created a useful (to you, at least) low-level language. It
may well be more efficient, more productive, more convenient or safer
than C for some programming tasks. But still, it is /not/ a replacement
for C.

>
> So I at least am using a 'modern' language that can be used as a low
> level implementation language like C. (I say modern but it was first
> designed 35 years ago.)
>
>> Adding some way to support C code does not make
>> it an enhanced C any more than a C compiler's "asm" statement means that
>> C is an enhanced assembly.
>
> I disagree; most of my assembly code in last few decades has been
> written as inline assembly within a HLL (the HLL takes care of most
> non-executable code, and provides the HLL structure with functions,
> scopes and so on).
>

Most of /my/ assembly for the last decade has also been inline assembly
within C. But my C compiler is not an assembler, my C code is not
assembly code, and the C language is not an enhanced or evolved assembly
language.

> So there are ways (I've listed over 100 in the past) of enhancing C to
> make it better and to make it easier to write low level code.

I've seen your list. Almost all of them are, IMHO, irrelevant, easily
avoided, or simply wrong. However, even if we assume for the sake of
argument that your list of "defects" in C was uncontroversial and we all
agreed that these were things that should be "fixed". A language that
applies all those fixes would not be C - it would not be an enhanced or
improved C, but a significantly different language.

>
> But if the project demands a higher-level language, then you use that
> instead. And of course you can use more than one language in a project.
>

Agreed.

> (In my world there are two languages: one that is static, compiled, low
> level, completely transparent, but fast; and one that is higher level,
> dynamic, interpreted and slow - but much more productive and less of a
> pain to code in.
>

Typically I use C and Python, but the principle is the same.

> Some languages are aimed at the rather large gap in between: having
> static (or inferred) types, more features, more dynamism, a bit easier
> to code, but that is still fast.

Yes.

>
> But if I give C++ as an example, many (not you) will agree that that one
> hasn't really worked... There are also Java, Go and Rust, but those
> won't be to everyone's taste either. And they are not small either.)

You can't have a language (and standard libraries) that covers a very
wide range of application areas, and is small. That is simply a
contradiction.

Some people like C++, Java, Go and Rust - others don't. You certainly
cannot suggest that any of these "hasn't really worked" - even the most
ardent C++ hater would have to accept that it is a massively popular
language that has been used successfully on everything from tiny AVR's
to massive supercomputers. (Just as even the most ardent C++ lover
would have to accept that it has also been used /unsuccessfully/ in many
cases.)

>
>> There are plenty of "niche areas" for C as yet. People who want to
>> program in C will find lots to do for a long time to come. It is only
>> the people that insist that they will use C regardless of the task, that
>> will have trouble.
>
> Be nice if there was a real choice though when they do need a language
> /like/ C.
>

There are a number of things I would like to change about C - small
things, not dramatic changes to the language. Many of these could be
handled simply as compiler extensions, and indeed some of them /are/
handled by compiler implementations. But for the most part, C does a
perfectly good job for me.

And when I want a different language for my low-level work, there /is/ a
real choice - C++. It is like C in some ways, and very different in
other ways - but I fail to see the need for a language that is /almost/
like C.

[David Brown]

*((volatile uint8_t*) 0x58) = 0x00;

The C standards don't say how such a write is to be performed - but all
implementations I know of handle it as you expect (and for code like
this, you don't need portability - it only has to work on the platform
with the port at 0x58).

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
> On 15/11/17 16:35, bartc wrote:

[...]

>> Suppose the first thing that needs to done is write zero to port 0x58
>> (not memory-mapped); how does C do that?
>
> *((volatile uint8_t*) 0x58) = 0x00;

"not memory-mapped".

I think what bartc is referring to would require executing a specific
CPU instruction that writes to a specified port.

The answer, of course, is that C provides no standard way to do that --
but an implementation for a system with such a feature is likely to
provide an appropriate extension.

[Rick C. Hodgin]

On Wednesday, November 15, 2017 at 10:15:24 AM UTC-5, Bart wrote:
> You might be interested in this Link that Pascal posted:
>
> https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item
>
> Interesting choice of name.
>
> (I was thinking Pascal might be stuck thinking up a suitable name if he
> ever brought out own language, as the obvious choice has gone...)

Clive, eh? I don't know. Sounds hokey. :-)

--
Rick C. Hodgin

[Scott Lurndal]

Keith Thompson <ks...@mib.org> writes:
>David Brown <david...@hesbynett.no> writes:
>> On 15/11/17 16:35, bartc wrote:
>[...]
>>> Suppose the first thing that needs to done is write zero to port 0x58
>>> (not memory-mapped); how does C do that?
>>
>> *((volatile uint8_t*) 0x58) = 0x00;
>
>"not memory-mapped".
>
>I think what bartc is referring to would require executing a specific
>CPU instruction that writes to a specified port.

Yep. Do this all the time from C (and C++). Sure, it's not standard,
but then gcc is widely available and I see no reason to not use it.


static inline uint8
inb(uint16 port)
{
uint8 value;

__asm__ __volatile__ ("inb %1, %0": "=a"(value): "Nd"(port));

return value;
}
static inline uint16
inw(uint16 port)
{
uint16 value;

__asm__ __volatile__ ("inw %1, %0": "=a"(value): "Nd"(port));

return value;
}

static uint32 inl(uint16) __attribute__((always_inline));

static inline uint32
inl(uint16 port)
{
uint32 value;

__asm__ __volatile__ ("inl %1, %0": "=a"(value): "Nd"(port));

return value;
}

[James R. Kuyper]

On 11/15/2017 09:54 AM, Pascal J. Bourguignon wrote:
...

> etc. You can write an OS in any programming language.

I'd like to see how you write an OS in any of the languages listed at
<https://en.wikipedia.org/wiki/Esoteric_programming_language>. As far as
I can tell from the descriptions, none of them seem to give enough
access to the actual hardware to write an OS.

[Scott Lurndal]

sc...@slp53.sl.home (Scott Lurndal) writes:
>Keith Thompson <ks...@mib.org> writes:
>>David Brown <david...@hesbynett.no> writes:
>>> On 15/11/17 16:35, bartc wrote:
>>[...]
>>>> Suppose the first thing that needs to done is write zero to port 0x58
>>>> (not memory-mapped); how does C do that?
>>>
>>> *((volatile uint8_t*) 0x58) = 0x00;
>>
>>"not memory-mapped".
>>
>>I think what bartc is referring to would require executing a specific
>>CPU instruction that writes to a specified port.
>
>Yep. Do this all the time from C (and C++). Sure, it's not standard,
>but then gcc is widely available and I see no reason to not use it.

I should mention that on systems that support ECAM for access to the
PCI configuration space, one can use the MMIO accesses that David
showed rather than using in/out instructions to ports CF8 and CFC. Non-intel
systems can map the IO Port space into the physical address space
allowing MMIO accesses as well (for the two or three PCI Express cards
that still support the PCI I/O address space).

[James R. Kuyper]

On 11/15/2017 10:17 AM, Jens Stuckelberger wrote:
...

> Live and let live - life's too short for such Byzantine disputes.

Life's too short to NOT spend at least some of your time doing what you
love to do - even if what you love to do is engage in Byzantine
disputes. This particular one doesn't interest me, but I've had a lot of
fun participating in some other discussions that you would probably
dismiss in the same fashion (I've also wasted a lot of time in other,
similar disputes that were no fun at all).

[bartc]

On 15/11/2017 17:10, Scott Lurndal wrote:
> Keith Thompson <ks...@mib.org> writes:
>> David Brown <david...@hesbynett.no> writes:
>>> On 15/11/17 16:35, bartc wrote:
>> [...]
>>>> Suppose the first thing that needs to done is write zero to port 0x58
>>>> (not memory-mapped); how does C do that?
>>>
>>> *((volatile uint8_t*) 0x58) = 0x00;
>>
>> "not memory-mapped".
>>
>> I think what bartc is referring to would require executing a specific
>> CPU instruction that writes to a specified port.
>
> Yep. Do this all the time from C (and C++). Sure, it's not standard,
> but then gcc is widely available and I see no reason to not use it.
>
>
> static inline uint8
> inb(uint16 port)
> {
> uint8 value;
>
> __asm__ __volatile__ ("inb %1, %0": "=a"(value): "Nd"(port));
>
> return value;
> }

"Even then, it might need something extra."

Here, you're not doing it in C, but roping in assembly. In which case
you really can use /ANY/ language to write on OS (although few can make
use of it inline, )

(FWIW, the first language I created, on Z80, had actual INP and OUTP
/statements/. But long since dropped as I no longer work directly with
ports.)


--
bartc

[supe...@casperkitty.com]

On Wednesday, November 15, 2017 at 9:16:54 AM UTC-6, Pascal J. Bourguignon wrote:
> Well, first you would have to realize that C is not a low level
> programming language. There are languages, like Common Lisp that are
> lower level than C! (eg. Common Lisp has operators to deal with bit
> fields, bit vectors, etc). A lot of other programming languages are
> mode fit than C to deal with hardware memory, address computing, such as
> Modula-2 or even the OOP language Modula-3!

C can be usefully employed as a recipe that will yield low-level programming
language for almost any common platform. All one need to is specify that in
places where the Standard would allow the "abstract machine" to behave in the
natural fashion of the real machine, it should do so.

The Standard does not specify that machines for any particular platform--
even those which use 32-bit linear addressing, would need to map integers
to pointers in any particularly logical fashion. On the other hand, there
are a lot of platforms upon which something like:

*(volatile uint32_t*)0x12345678 = 0xABCD4321;

would have one clear and logical meaning. The authors of C89 did
not think it necessary to specify that implementations that claim to be
suitable for systems programing should expose natural underlying platform
behaviors whenever practical, because that's what existing implementations
were doing and there was no reason to expect that they wouldn't continue
to do so.

If someone writing a compiler seeks to follow the Principle of Least
Astonishment, assuming users of the compiler will be familiar with the
target platform and common practices, it won't usually be clear what
exact range of behaviors would be "not astonishing", but there would
normally be at least one way an implementation could behave that would
be considered "not astonishing" by anyone familiar with the target.

For example, on a 16-bit two's-complement platform with silent-wraparound
semantics, given "int i=32767", it would not be astonishing for "long l=i+1;"
to set l to -32768. Programmers familiar with the platform might or might
not be astonished if l were set to +32768, but setting it to -32768 should
not be astonishing in any case.

I'm not sure why some people seem to think "behave in a manner that would be
non-astonishing to someone familiar with the underlying platform" is not a
workable specification, given that C was flourishing under such semantics
long before any "official" standard was written.

[supe...@casperkitty.com]

On Wednesday, November 15, 2017 at 10:39:16 AM UTC-6, Keith Thompson wrote:> "not memory-mapped".

>
> I think what bartc is referring to would require executing a specific
> CPU instruction that writes to a specified port.

If the target platform is known, and does not use memory protection, one
could achieve the necessary semantics without any compiler-specific features
by doing something like:

union exec {
unsigned char *code;
void (*function)(void);
};

void out_port(int addr, int data)
{
union exec ex;
unsigned char out_cmd[12];
out_cmd[0] = ..; /* PUSH AX */
out_cmd[1] = ..; /* PUSH DX */
out_cmd[2] = ..; /* MOV DX,NN */
out_cmd[3] = addr & 255;
out_cmd[4] = addr >> 8;
out_cmd[5] = ..; /* MOV AX,NN */
out_cmd[6] = data & 255;
out_cmd[7] = data >> 8;
out_cmd[8] = ..; /* OUT DX, AX */
out_cmd[9] = ..; /* POP DX */
out_cmd[10] = ..; /* POP AX */
out_cmd[11] = ..; /* RET */
ex.code = out_cmd;
ex.function();
}

If the platform's native format for code and data pointers are identical,
and it doesn't use any kind of memory protection, code like the above
should work on any compiler targeting that platform that uses that format
for its pointers and which processes the code in the obvious logical
fashion. If an instruction would need a cache-flush instruction before
using self-modifying code, that could be handled by putting the code in
a static variable which is used for no purpose other than the cache flush.

Having a function accept arguments for addr and data would generally be
better than having such things baked into the function code itself, but
the above approach would be a bit less compiler-dependent [most platforms
would define argument-passing conventions that should be usable within
the machine code, but not all platforms do].

[John Bode]

On Tuesday, November 14, 2017 at 4:13:13 PM UTC-6, Lynn McGuire wrote:
> "The long goodbye to C" by Eric Raymond
> http://esr.ibiblio.org/?p=7711
>

> "I was thinking a couple of days ago about the new wave of systems
> languages now challenging C for its place at the top of the
> systems-programming heap – Go and Rust, in particular. I reached a
> startling realization – I have 35 years of experience in C. I write C
> code pretty much every week, but I can no longer remember when I last
> started a new project in C!"
>

> I doubt it.
>
> Lynn

I haven't written a line of C as a professional since 2004 or so.

I can believe it.

[bartc]

On 15/11/2017 16:27, David Brown wrote:

> On 15/11/17 16:02, bartc wrote:

> I have nothing against making new languages (high level or low level),
> or using different languages instead of C. I simply don't understand
> why anyone would want to consider it to be a "new C", "evolved C",
> "replacement for C".

Because it was created in the early 70s and looks like something thrown
together as a student project, or as a joke. Think of the loss of
productivity of approaching half a century now of people grappling with
type declaration syntax, just one thing out of dozens that ought to have
been fixed nearly from the start.

>> But there are other approaches to designing a language that does what C
>> does. Most other such language have died out, but mine is still used
>> (and no doubt others that no one knows about).
>
> Neither your language, nor anyone else's, does what C does. I can't run
> it on a Solaris workstation. I can't use it to target an AVR
> microcontroller. I can't use it to compile the source for the libjpg
> library.

The C language can't do that. You're talking about implementations
created to work on those targets. Someone might be kind enough to
development an implementation of mine for Solaris too.

As for compiling libraries that are written in C, that's an example of
the lock-in effect when one language starts to dominate. (Jpeg is a good
example of a program that must surely be language-neutral.)

C also is harder to translate into usable code in another language (than
one of mine into C for example). It's harder because typical code is a
mass of conditional blocks, macro definitions and expansions, relies on
a mish-mash of C and POSIX headers, its 'module system' is a
free-for-all, it mixes up what are arrays and what are pointers (there
was a thread on this problem in the Fortran group), ....

Basically, it's a mess.

Your reaction is apparently to leave it well alone: either use that
mess, or switch to something higher level that doesn't do the same job
(and by all accounts is a bigger job to compile).

> You may have created a useful (to you, at least) low-level language. It
> may well be more efficient, more productive, more convenient or safer
> than C for some programming tasks. But still, it is /not/ a replacement
> for C.

It is for me. That majority of my low level coding I can do in that
language, even if it might rely on a C implementation to make programs
run on a 32-bit system for example (I only target x64 directly).

Ergo, anyone could create such a language. And since it would be way
simpler than ones such as Go and Rust (and can be made simpler than C)
it wouldn't be that hard.

However, some C implementations have grown their own massive eco-systems
that people have grown to rely on, replacing which would be a more
daunting task.

> And when I want a different language for my low-level work, there /is/ a
> real choice - C++. It is like C in some ways, and very different in
> other ways - but I fail to see the need for a language that is /almost/
> like C.

That's why I gave up my thin wrapper around C and made a proper language
instead. But you're right, you can't make those 100 changes to C and
still have C, or still be compatible. That was to highlight many
annoyances, some of which could be fixed, but many of which can't
without having a different language.

The fact remains that I can code at low level without any of those
annoyances.

--
bart

[Keith Thompson]

supe...@casperkitty.com writes:
[...]

> For example, on a 16-bit two's-complement platform with silent-wraparound
> semantics, given "int i=32767", it would not be astonishing for "long l=i+1;"
> to set l to -32768. Programmers familiar with the platform might or might
> not be astonished if l were set to +32768, but setting it to -32768 should
> not be astonishing in any case.

I agree, that would not be astonishing. The behavior is undefined, so
any behavior is permitted, but setting l to -32768 would be, I suppose,
particularly unsurprising. A compile-time warning would also be
unsurprising.

A conforming C compiler is free to implement that behavior, either by
default or in response to a compile-time option.

> I'm not sure why some people seem to think "behave in a manner that would be
> non-astonishing to someone familiar with the underlying platform" is not a
> workable specification, given that C was flourishing under such semantics
> long before any "official" standard was written.

Are you suggesting that the C standard should require implementations to

"behave in a manner that would be non-astonishing to someone familiar

with the underlying platform"?

It's not a workable specification because it's vague.

[James R. Kuyper]

So for you, it makes sense that you haven't started any new projects in C.

> I can believe it.

But he writes "C code pretty much every week", which is what makes his
claim so odd.

[supe...@casperkitty.com]

On Wednesday, November 15, 2017 at 1:13:27 PM UTC-6, Keith Thompson wrote:
> Are you suggesting that the C standard should require implementations to
> "behave in a manner that would be non-astonishing to someone familiar
> with the underlying platform"?

The easiest way to make an implementation that targets a typical platform
suitable for low-level programming use thereon is to make it behave in ways
characteristic of the environment when the Standard allows, without regard
for whether the Standard mandates such behavior.

The Standard makes no effort to mandate that conforming implementations be
suitable for low-level programming, in part because implementations that are
not suitable for that purpose may be useful for other purposes. The fact
that the Standard does not mandate some particular behavior does not imply
any judgment by the authors of the Standard as to whether a lack of support
for such features would make an implementation unsuitable for some purposes.

Nothing in the C Standard would distinguish a compiler that targets the
68000 and would process "*(unsigned long volatile*)0x12345678 = 0xABCD1234"
by writing a value of 0xABCD4321 to physical address 0x12345678, from one
which targets the same CPU but would map integers to addresses in some other
fashion. The failure of the Standard to recognize a category of compilers
that are suitable for low-level programming does not, however, imply that
someone who genuinely wants to make a compiler suitable for low-level
programming on that platform should have any difficulty recognizing how
such a compiler should behave.

[Keith Thompson]

So would that be a "no"?

[John Bode]

Legacy code is forever. There are C systems out there that have been in place for
decades and are still being actively maintained. C programmers have kind of reached
that same career point that COBOL programmers did in the '90s - there's plenty of
maintenance work, but not that much in the way of greenfield development.

Yeah, I'm sure plenty of guys in this newsgroup are spinning up new projects in C,
but industry in general is not.

[Pascal J. Bourguignon]

bartc <b...@freeuk.com> writes:

> On 15/11/2017 14:54, Pascal J. Bourguignon wrote:
>> "Mr. Man-wai Chang" <toylet...@gmail.com> writes:

>>
>>> On 15/11/2017 6:13 AM, Lynn McGuire wrote:
>>>> "I was thinking a couple of days ago about the new wave of systems
>>>> languages now challenging C for its place at the top of the
>>>> systems-programming heap – Go and Rust, in particular. I reached a
>>>> startling realization – I have 35 years of experience in C. I write C
>>>> code pretty much every week, but I can no longer remember when I last
>>>> started a new project in C!"
>>>

>>> Because there is no new operating system effort? C is not suitable as
>>> a rapid development tool for business applications. That's the real
>>> reasons why there are few new C projects.
>>
>> There are new operating system efforts, but they definitely don't use C.
>>
>> More like Common Lisp
>> https://github.com/froggey/Mezzano/releases/tag/demo3
>>
>> or other languages, such as Go,
>> https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item

>>
>> etc. You can write an OS in any programming language.
>

> It seems unlikely, using off-the-shelf implementations. Possibly with
> a 'modified' compiler like the one mentioned in the second link or
> requiring a bit of hacking.

>
> The chances are it will depend on some bits that are not in the
> standard language. That's if it has to talk to actual hardware and
> doesn't rely on some virtual interface to do the hard stuff.

Same as in C.

[Pascal J. Bourguignon]

Melzzzzz <Melz...@zzzzz.com> writes:

> Low level stuff is usually written in C ;)

Nope. You have to do it in assembler.

[Pascal J. Bourguignon]

C too, runs it its own VM! You don't realize it, but you're not running
on the bare hardware, or even in a unix process. You're running in the
imaginary world of the C standard, and it is different from the unix
process virtual environment provided by the OS.

[Pascal J. Bourguignon]

supe...@casperkitty.com writes:

> I'm not sure why some people seem to think "behave in a manner that would be
> non-astonishing to someone familiar with the underlying platform" is not a
> workable specification, given that C was flourishing under such semantics
> long before any "official" standard was written.

Well, you see that's the point: C wasn't flourishing at all, on the
machines that had a different model than the PDP-7 or PDP-11 where C had
been developed first.

For example, nobody here used Zeta-C, and Zeta-C left no legacy. Zeta-C
targetted the Lisp Machine.

(Zeta-Lisp left some legacy, which you can find in any current Lisp
implementation, including in GNU emacs).

[Pascal J. Bourguignon]

Neither does ANSI C!

Think about it!

[James R. Kuyper]

On 11/15/2017 03:50 PM, Pascal J. Bourguignon wrote:
> "James R. Kuyper" <james...@verizon.net> writes:
>
>> On 11/15/2017 09:54 AM, Pascal J. Bourguignon wrote:
>> ...
>>> etc. You can write an OS in any programming language.
>>
>> I'd like to see how you write an OS in any of the languages listed at
>> <https://en.wikipedia.org/wiki/Esoteric_programming_language>. As far
>> as I can tell from the descriptions, none of them seem to give enough
>> access to the actual hardware to write an OS.
>
> Neither does ANSI C!

I agree. The best you can do it write most of the OS in portable C, and
cover the tricky parts with non-portable C (including inline assembler),
or calls to functions written in assembler. So, what does that do to
your original claim, cited above?

[supe...@casperkitty.com]

On Wednesday, November 15, 2017 at 2:29:25 PM UTC-6, Keith Thompson wrote:
> supe...@casperkitty.com writes:
> > On Wednesday, November 15, 2017 at 1:13:27 PM UTC-6, Keith Thompson wrote:
> >> Are you suggesting that the C standard should require implementations to
> >> "behave in a manner that would be non-astonishing to someone familiar
> >> with the underlying platform"?
> >

> > Nothing in the C Standard would distinguish a compiler that targets the
> > 68000 and would process "*(unsigned long volatile*)0x12345678 = 0xABCD1234"
> > by writing a value of 0xABCD4321 to physical address 0x12345678, from one
> > which targets the same CPU but would map integers to addresses in some other
> > fashion. The failure of the Standard to recognize a category of compilers
> > that are suitable for low-level programming does not, however, imply that
> > someone who genuinely wants to make a compiler suitable for low-level
> > programming on that platform should have any difficulty recognizing how
> > such a compiler should behave.
>
> So would that be a "no"?

Some implementations are suitable for low-level programming. Others are
not. The language processed by implementations which expose low-level
behaviors whenever practical is a low-level language. The minimal language
defined by the Standard, without such behaviors, is not a low-level language.

The Standard should describe what features would be appropriate in a low-
level language, without mandating that implementations intended for other
purposes include such features.

[supe...@casperkitty.com]

On Wednesday, November 15, 2017 at 2:47:50 PM UTC-6, Pascal J. Bourguignon wrote:
> > I'm not sure why some people seem to think "behave in a manner that would be
> > non-astonishing to someone familiar with the underlying platform" is not a
> > workable specification, given that C was flourishing under such semantics
> > long before any "official" standard was written.
>
> Well, you see that's the point: C wasn't flourishing at all, on the
> machines that had a different model than the PDP-7 or PDP-11 where C had
> been developed first.

It was catching hold on the dominant microcomputer platforms at the time,
and was the most suitable language for writing code that would run on both
the PC and Macintosh.

C may not have been particularly flourishing on weird oddball platforms,
but that's in significant measure because weird oddball platforms in
general haven't flourished since the invention of the microprocessor.
Having a standard specify a minimal range that can be expected for "int"
and "long" on platforms where storage is addressed in e.g. 12-bit chunks
would make the language more useful than it would otherwise be on such
platforms, but a language's ability to support such platforms should not
come at the expense of code which has no need to run on them.

[Ian Collins]

Why constrain implementations by attempting to standardise such things?
If an implementation is targeting bare metal or a specialised platform,
it is free to offer the appropriate extensions. The set of possible
extensions is to large and varied to be part of any standard.

--
Ian.

[supe...@casperkitty.com]

The number of features required to support 80% of low-level code isn't
particularly great. It would be impractical to have the Standard try to
support all the features needed by 100% of low-level programs, including
those for arcane platforms, but the vast majority could be supported with
an annex smaller than the poorly-designed Annex L (which is intended to
address a real problem, but fails to actually specify anything useful).

[Pascal J. Bourguignon]

It does nothing. You can write an OS in any programming language.

[James R. Kuyper]

On 11/15/2017 05:36 PM, Pascal J. Bourguignon wrote:
> "James R. Kuyper" <james...@verizon.net> writes:
>
>> On 11/15/2017 03:50 PM, Pascal J. Bourguignon wrote:
>>> "James R. Kuyper" <james...@verizon.net> writes:
>>>
>>>> On 11/15/2017 09:54 AM, Pascal J. Bourguignon wrote:
>>>> ...
>>>>> etc. You can write an OS in any programming language.
>>>>
>>>> I'd like to see how you write an OS in any of the languages listed at
>>>> <https://en.wikipedia.org/wiki/Esoteric_programming_language>. As far
>>>> as I can tell from the descriptions, none of them seem to give enough
>>>> access to the actual hardware to write an OS.
>>>
>>> Neither does ANSI C!
>>
>> I agree. The best you can do it write most of the OS in portable C,
>> and cover the tricky parts with non-portable C (including inline
>> assembler), or calls to functions written in assembler. So, what does
>> that do to your original claim, cited above?
>
> It does nothing. You can write an OS in any programming language.

So, you see no contradiction between the claim that "You can write an OS
in any programming language" (which necessarily includes all of those
esoteric languages and C), despite the fact that you agree with me that
none of those languages "give enough access to the actual hardware to
write an OS"?

If you think that those two statements don't directly contradict other,
you should at least explain why you think that they fail to do so.

[Melzzzzz]

On 2017-11-15, Pascal J. Bourguignon <p...@informatimago.com> wrote:

> Melzzzzz <Melz...@zzzzz.com> writes:
>
>> Low level stuff is usually written in C ;)
>
> Nope. You have to do it in assembler.

Some things.
eg this is from magenta project, new google OS:
~/projects/magenta >>> find . -name '*.S' | wc -l ±[master]
114
~/projects/magenta >>> find . -name '*.c' | wc -l ±[master]
2151
~/projects/magenta >>> find . -name '*.cpp' | wc -l ±[master]
466

C still dominates ;)

>


--
press any key to continue or any other to quit...

[Rick C. Hodgin]

On Wednesday, November 15, 2017 at 5:37:02 PM UTC-5, Pascal J. Bourguignon wrote:
> It does nothing. You can write an OS in any programming language.

You can rebuild an engine with box-end wrenches. Hardly seems desirable
or profitable to do so when better tools exist for some of those rasks,
and when I say rasks I mean tasks, of course, oh silly Pascal.

https://www.youtube.com/watch?v=H4YRPdRXKFs&t=1m38s

--
Rick C. Hodgin

[Pascal J. Bourguignon]

"James R. Kuyper" <james...@verizon.net> writes:

> On 11/15/2017 05:36 PM, Pascal J. Bourguignon wrote:
>> "James R. Kuyper" <james...@verizon.net> writes:
>>
>>> On 11/15/2017 03:50 PM, Pascal J. Bourguignon wrote:
>>>> "James R. Kuyper" <james...@verizon.net> writes:
>>>>
>>>>> On 11/15/2017 09:54 AM, Pascal J. Bourguignon wrote:
>>>>> ...
>>>>>> etc. You can write an OS in any programming language.
>>>>>
>>>>> I'd like to see how you write an OS in any of the languages listed at
>>>>> <https://en.wikipedia.org/wiki/Esoteric_programming_language>. As far
>>>>> as I can tell from the descriptions, none of them seem to give enough
>>>>> access to the actual hardware to write an OS.
>>>>
>>>> Neither does ANSI C!
>>>
>>> I agree. The best you can do it write most of the OS in portable C,
>>> and cover the tricky parts with non-portable C (including inline
>>> assembler), or calls to functions written in assembler. So, what does
>>> that do to your original claim, cited above?
>>
>> It does nothing. You can write an OS in any programming language.
>
> So, you see no contradiction between the claim that "You can write an
> OS in any programming language" (which necessarily includes all of
> those esoteric languages and C), despite the fact that you agree with
> me that none of those languages "give enough access to the actual
> hardware to write an OS"?

Of course. In all cases you will have to add some assembly, so they're
all equally good to write OSes. And OSes having been written in almost
all programming languages is proof of it!

[bartc]

Until you add in the GUI and other stuff the OS takes care of, then the
mix will change.

But people use C for a lot of this because /there is little other
choice/. And if not starting from scratch and disregarding every
existing library and driver, then it will be necessary to make use of
existing C sources or C interfaces, which is easiest from C.

And the more the decision is made to use C, the less choice there is,
but the more there are people who are skilled in using C for such projects.

--
bartc

[Melzzzzz]

You don't want GC in kernel, that's sure. That eliminates all languages
with GC.

[Melzzzzz]

On 2017-11-15, bartc <b...@freeuk.com> wrote:
> On 15/11/2017 22:52, Melzzzzz wrote:
>> On 2017-11-15, Pascal J. Bourguignon <p...@informatimago.com> wrote:
>>> Melzzzzz <Melz...@zzzzz.com> writes:
>>>
>>>> Low level stuff is usually written in C ;)
>>>
>>> Nope. You have to do it in assembler.
>>
>> Some things.
>> eg this is from magenta project, new google OS:
>> ~/projects/magenta >>> find . -name '*.S' | wc -l ±[master]
>> 114
>> ~/projects/magenta >>> find . -name '*.c' | wc -l ±[master]
>> 2151
>> ~/projects/magenta >>> find . -name '*.cpp' | wc -l ±[master]
>> 466
>>
>> C still dominates ;)
>
> Until you add in the GUI and other stuff the OS takes care of, then the
> mix will change.

Well look:
~/projects/magenta >>> find . -name '*.go' ±[master]
./third_party/ulib/uboringssl/scripts/check-boringssl.go

Single `go` program in google's OS ;)
That tells something!

>
> But people use C for a lot of this because /there is little other
> choice/. And if not starting from scratch and disregarding every
> existing library and driver, then it will be necessary to make use of
> existing C sources or C interfaces, which is easiest from C.
>
> And the more the decision is made to use C, the less choice there is,
> but the more there are people who are skilled in using C for such projects.
>

Anyone serious don't wont bloatware in kernel, that's sure ;)

[David Brown]

On 15/11/17 20:13, bartc wrote:
> On 15/11/2017 16:27, David Brown wrote:
>> On 15/11/17 16:02, bartc wrote:
>
>> I have nothing against making new languages (high level or low level),
>> or using different languages instead of C.  I simply don't understand
>> why anyone would want to consider it to be a "new C", "evolved C",
>> "replacement for C".
>
> Because it was created in the early 70s and looks like something thrown
> together as a student project, or as a joke.

I think you have an unusual sense of humour. I have learned, or at
least been familiar with, a large number of programming languages
throughout the years. I really can't see that C stands out as being
particularly difficult or having an awkward syntax. It has a few
oddities, certainly (default fall-through for switches, for example, is
IMHO a terrible idea). But I know of no languages that don't have some
oddities - variations in programmers' tastes and experiences makes that
inevitable.

> Think of the loss of
> productivity of approaching half a century now of people grappling with
> type declaration syntax, just one thing out of dozens that ought to have
> been fixed nearly from the start.

Why not just think about the huge majority of C programmers who /don't/
have a problem with C's type declaration syntax? Or those that
understand "typedef", precisely so that they don't need to write
anything too complicated? Or those that simply don't need particularly
complex types?

>
>>> But there are other approaches to designing a language that does what C
>>> does. Most other such language have died out, but mine is still used
>>> (and no doubt others that no one knows about).
>>
>> Neither your language, nor anyone else's, does what C does.  I can't run
>> it on a Solaris workstation.  I can't use it to target an AVR
>> microcontroller.  I can't use it to compile the source for the libjpg
>> library.
>
> The C language can't do that. You're talking about implementations
> created to work on those targets. Someone might be kind enough to
> development an implementation of mine for Solaris too.

There are C implementations for all those platforms. There is no other
language that comes close to the breadth of support (and you don't like
the runner-up, C++). There are no other languages that could be called
a replacement for C.

>
> As for compiling libraries that are written in C, that's an example of
> the lock-in effect when one language starts to dominate.

Absolutely true.

> (Jpeg is a good
> example of a program that must surely be language-neutral.)

How can a program be language neutral? The jpeg /algorithms/ are
language neutral, but a jpeg program, or library implementation, is by
definition written in a programming language and cannot be language-neutral.

>
> C also is harder to translate into usable code in another language (than
> one of mine into C for example).

First, so what? How often do people want to translate C code into other
languages?

Second, I disagree. I don't think C code is significantly more
difficult to translate to another procedural imperative programming
language (or another language that supports procedural imperative
programming) than any other such language - Pascal, Modula-2, Fortran,
etc. A simple and limited language, such as yours, may be easier to
translate. But that does not make C hard.

> It's harder because typical code is a
> mass of conditional blocks, macro definitions and expansions, relies on
> a mish-mash of C and POSIX headers, its 'module system' is a
> free-for-all, it mixes up what are arrays and what are pointers (there
> was a thread on this problem in the Fortran group), ....

That may be true of /your/ C code, but I can assure you it is not
typical of most C code. You can't blame the language for a few bad
programmers.

I think you have a weird concept of what is "typical" in C because of
the types of code you look at, and because you are viewing the code as a
compiler and not as a C programmer.


Consider this code in a header:

#ifdef __cplusplus
#if __cplusplus >= 201103L
// static_assert is part of C++11
#define _got_static_assert
#endif
#else
#ifdef __STDC_VERSION__
#if (__STDC_VERSION__ >= 20112L)
// _Static_assert is part of C11
#define static_assert _Static_assert
#define _got_static_assert
#endif
#endif
#endif
#ifndef _got_static_assert
/* Fall-back to ugly macro */
#define _sa_name(_counter) _sa_name2(_counter)
#define _sa_name2(_counter) static_assert_failed_##_counter
#ifdef __GNUC__
/* gcc has __COUNTER__, which is better than __LINE__ here */
#define static_assert(_claim, _warning) \
typedef struct { \
char _sa_name(__COUNTER__) [(_claim) ? 2 : -2]; \
} _sa_name(__COUNTER__)
#else
#define static_assert(_claim, _warning) \
typedef struct { \
char _sa_name(__LINE__) [(_claim) ? 2 : -2]; \
} _sa_name(__LINE__)
#endif
#endif


That is some messy code, with conditional blocks, macro definitions, etc.

But that code only needs to be written once, in a header that you re-use
in all your code. And then you can write static assertions in your code:

static_assert(sizeof(struct big_struct) == 48,
"Unexpected size of big_struct");

static_assert(MAXSIZE >= 100,
"This code assumes MAXSIZE is at least 100");

Static assertions cost nothing in code space, run-time, or data size,
and are very useful for checking things or stating assumptions in a way
that can be easily understood by the reader, and checked by the
compiler. C11 and C++11 have them as part of the language - for earlier
C, you can simulate them with a typedef like this that causes a
compile-time error if the claim is not true. But you want to use the
real static assertion if the compiler supports it, because the error
message is clearer.

From the viewpoint of the C programmer, this is marvellous - you get
one of the nicest features from C11 even if you have an older or more
limited compiler, and the use of the feature is clear and simple.

But as you are more interested in the compiler's viewpoint, and obsessed
with counting lines rather than understanding code, all you see is macro
expansions and conditional compilation that get you all in a fluster.
What you fail to understand is that these are /features/ that let people
write clearer, safer and more efficient code.

>
> Basically, it's a mess.
>
> Your reaction is apparently to leave it well alone: either use that
> mess, or switch to something higher level that doesn't do the same job
> (and by all accounts is a bigger job to compile).

I believe that is a far more practical solution than to whine about
things I don't like to people who don't agree and couldn't help you even
if they /did/ agree.

>
>> You may have created a useful (to you, at least) low-level language.  It
>> may well be more efficient, more productive, more convenient or safer
>> than C for some programming tasks.  But still, it is /not/ a replacement
>> for C.
>
> It is for me. That majority of my low level coding I can do in that
> language, even if it might rely on a C implementation to make programs
> run on a 32-bit system for example (I only target x64 directly).
>

But you are only one programmer writing a few bits of code for one or
two platforms. It is like someone who lives in California saying that
flip-flops are a suitable replacement for all types of shoes, simply
because /they/ don't need anything else.

> Ergo, anyone could create such a language. And since it would be way
> simpler than ones such as Go and Rust (and can be made simpler than C)
> it wouldn't be that hard.

So the answer is for everyone to write their own private languages that
suits their purposes. Seriously?

>
> However, some C implementations have grown their own massive eco-systems
> that people have grown to rely on, replacing which would be a more
> daunting task.
>
>> And when I want a different language for my low-level work, there /is/ a
>> real choice - C++.  It is like C in some ways, and very different in
>> other ways - but I fail to see the need for a language that is /almost/
>> like C.
>
> That's why I gave up my thin wrapper around C and made a proper language
> instead. But you're right, you can't make those 100 changes to C and
> still have C, or still be compatible. That was to highlight many
> annoyances, some of which could be fixed, but many of which can't
> without having a different language.
>
> The fact remains that I can code at low level without any of those
> annoyances.
>

The inability to code for the targets I want, to use existing code the
way I want, to use a wide selection of tools the way I want, and to work
together with other people - that would be /vastly/ more annoying to me
than any of the oddities of C, no matter how "perfect" your pet language
may be.

[David Brown]

On 15/11/17 19:26, bartc wrote:
> On 15/11/2017 17:10, Scott Lurndal wrote:
>> Keith Thompson <ks...@mib.org> writes:
>>> David Brown <david...@hesbynett.no> writes:
>>>> On 15/11/17 16:35, bartc wrote:
>>> [...]
>>>>> Suppose the first thing that needs to done is write zero to port 0x58
>>>>> (not memory-mapped); how does C do that?
>>>>
>>>> *((volatile uint8_t*) 0x58) = 0x00;
>>>
>>> "not memory-mapped".
>>>
>>> I think what bartc is referring to would require executing a specific
>>> CPU instruction that writes to a specified port.
>>
>> Yep.   Do this all the time from C (and C++).   Sure, it's not standard,
>> but then gcc is widely available and I see no reason to not use it.
>>
>>
>> static inline uint8
>> inb(uint16 port)
>> {
>>      uint8  value;
>>
>>      __asm__ __volatile__ ("inb %1, %0": "=a"(value): "Nd"(port));
>>
>>      return value;
>> }
>
>
> "Even then, it might need something extra."
>
> Here, you're not doing it in C, but roping in assembly. In which case
> you really can use /ANY/ language to write on OS (although few can make
> use of it inline, )

There is more to writing an OS than reading or writing a port or two.

You can be sure that writing an OS is going to involve a certain amount
of assembly - no programming language will give you the features you
need for things like context switches (unless you are dealing with
extremely convenient hardware).

>
> (FWIW, the first language I created, on Z80, had actual INP and OUTP
> /statements/. But long since dropped as I no longer work directly with
> ports.)
>

Many C compilers have extensions such as these as "intrinsic" or
"builtin" functions. Many others have them defined in headers. It does
not matter in the slightest to the user if "inp" is a language feature
or a function like Scott's declared in a header.

[supe...@casperkitty.com]

On Wednesday, November 15, 2017 at 5:44:50 PM UTC-6, Pascal J. Bourguignon wrote:
> Of course. In all cases you will have to add some assembly, so they're
> all equally good to write OSes. And OSes having been written in almost
> all programming languages is proof of it!

Assembly won't always be required. Machine code might be, but on many
platforms it's possible to write machine code in C by creating an array
holding the necessary code, converting its address to a function pointer,
and executing it.

If one wants to make N1 applications will work on N2 target platforms,
each of which is supported by compilers from N3 vendors, the total work
should not be O(N1 * N2 * N3). Writing in assembly for one vendor's tools
would often be nicer than writing machine code, but generating N2 pieces of
machine code by using one vendor's assembler and then converting the
output to a C array may be nicer than having to write a separate piece of
assembly-language code for every platform-vendor combination.

[Chris M. Thomasson]

On 11/15/2017 12:10 AM, David Brown wrote:
> On 15/11/17 00:19, Rick C. Hodgin wrote:

>> On Tuesday, November 14, 2017 at 5:13:13 PM UTC-5, Lynn McGuire wrote:
>>> "The long goodbye to C" by Eric Raymond
>>> http://esr.ibiblio.org/?p=7711
>>>

>>> "I was thinking a couple of days ago about the new wave of systems
>>> languages now challenging C for its place at the top of the
>>> systems-programming heap – Go and Rust, in particular. I reached a
>>> startling realization – I have 35 years of experience in C. I write C
>>> code pretty much every week, but I can no longer remember when I last
>>> started a new project in C!"
>>>

>>> I doubt it.
>>>
>>> Lynn
>>
>> It's true. Unless C evolves, it will be slowly relegated to only
>> niche markets, and will die as a language for any real projects.
>
> So what? If a language is not suitable for new projects, then that is
> because there are better choices - so use them. Lots of languages and
> tools that were fantastic in their day are no longer particularly
> relevant. How many new projects are written in Pascal? Fortran?
> Basic? The answer is a few - they are still the best choice in niche cases.
>
> C needs to evolve to allow us to work with existing C code, and to allow
> us to write code in C in situations where C is still the best language
> choice. It does not need to move into new areas, or make big changes -
> that would reduce its usefulness in existing situations where simplicity
> and stability are key. C will /never/ be a modern language, and no

> amount of "evolution" will make it one - when you put enough into C to

> get a modern language you end up with C++, Objective-C, Rust, etc. - all
> fine languages for their use, and all tracing their roots back to C, but
> none of them /are/ C.
>
>>
>> The whole purpose of CAlive is to inject new life into C by bringing
>> forward some of the features of other languages, and to introduce new
>> features, while maintaining backward compatibility.
>
>
> CAlive is not C - it is a totally different language designed in a
> different way for a different purpose. That is absolutely fine

Imvvho, Rick should try to make an online version of CAlive's current
state so that we can start creating some programs. It would be fun.



> - we
> don't need another C, because we already /have/ C. Make your language
> the way you want, but stop trying to kid yourself that it is the "future
> of C" or "evolved C". Adding some way to support C code does not make
> it an enhanced C any more than a C compiler's "asm" statement means that
> C is an enhanced assembly.
>
>>
>> It is obvious to anyone who is looking: C is dying quickly due to
>> the age of visual languages, and computers fast enough to run much
>> slower code written in other languages faster than the fastest C
>> could do on the CPUs available earlier this century.
>>
>
> Again, so what? If it makes more sense to write a program in Python, or
> Rust, or APL - then write the program in those languages. There can be
> many good reasons for choosing C as the language for a new project -
> "because it is C" is /not/ one of them.
>
>> The times, they are a changin'.
>>
>
> True. So change with them, rather than clinging on to the past.
>
> There are plenty of "niche areas" for C as yet. People who want to
> program in C will find lots to do for a long time to come. It is only
> the people that insist that they will use C regardless of the task, that
> will have trouble.
>

[Pascal J. Bourguignon]

So this eliminates C, which has BoehmGC and several other garbage
collectors.

Please stop writing bullshit!

[David Kleinecke]

On Wednesday, November 15, 2017 at 11:08:41 AM UTC-8, John Bode wrote:

> On Tuesday, November 14, 2017 at 4:13:13 PM UTC-6, Lynn McGuire wrote:
> > "The long goodbye to C" by Eric Raymond
> > http://esr.ibiblio.org/?p=7711
> >
> > "I was thinking a couple of days ago about the new wave of systems
> > languages now challenging C for its place at the top of the
> > systems-programming heap – Go and Rust, in particular. I reached a
> > startling realization – I have 35 years of experience in C. I write C
> > code pretty much every week, but I can no longer remember when I last
> > started a new project in C!"
> >
> > I doubt it.
> >
> > Lynn
>

> I haven't written a line of C as a professional since 2004 or so.
>

> I can believe it.

I haven't written a line of C as a professional since 1998 or so.

I'm retired.

[supe...@casperkitty.com]

On Wednesday, November 15, 2017 at 6:28:51 PM UTC-6, Pascal J. Bourguignon wrote:

> Melzzzzz <Melz...@zzzzz.com> writes:
> > You don't want GC in kernel, that's sure. That eliminates all languages
> > with GC.
>
> So this eliminates C, which has BoehmGC and several other garbage
> collectors.
>
> Please stop writing bullshit!

It severely curtails the use of languages which can't create aggregates
whose storage isn't managed by a garbage collector. Not all languages
that include GC features lack the ability to create unmanaged objects,
but languages like C# whose design is focused on the GC would at best
be very awkward for systems programming since most language features
would be unavailable.

[Melzzzzz]

C doesn't have GC. Boehms GC is third party and not part of langugae.
I am not writing bullshit, you are...

[Melzzzzz]

In medias res!!!

[James Kuyper]

On 11/15/2017 06:44 PM, Pascal J. Bourguignon wrote:
> "James R. Kuyper" <james...@verizon.net> writes:
>
>> On 11/15/2017 05:36 PM, Pascal J. Bourguignon wrote:
>>> "James R. Kuyper" <james...@verizon.net> writes:
>>>
>>>> On 11/15/2017 03:50 PM, Pascal J. Bourguignon wrote:
>>>>> "James R. Kuyper" <james...@verizon.net> writes:

...

>>>>>> I'd like to see how you write an OS in any of the languages listed at
>>>>>> <https://en.wikipedia.org/wiki/Esoteric_programming_language>. As far
>>>>>> as I can tell from the descriptions, none of them seem to give enough
>>>>>> access to the actual hardware to write an OS.
>>>>>
>>>>> Neither does ANSI C!
>>>>
>>>> I agree. The best you can do it write most of the OS in portable C,
>>>> and cover the tricky parts with non-portable C (including inline
>>>> assembler), or calls to functions written in assembler. So, what does
>>>> that do to your original claim, cited above?
>>>
>>> It does nothing. You can write an OS in any programming language.
>>
>> So, you see no contradiction between the claim that "You can write an
>> OS in any programming language" (which necessarily includes all of
>> those esoteric languages and C), despite the fact that you agree with
>> me that none of those languages "give enough access to the actual
>> hardware to write an OS"?
>
> Of course. In all cases you will have to add some assembly, so they're
> all equally good to write OSes. And OSes having been written in almost
> all programming languages is proof of it!

As I expected, you reconcile those contradictory statements by changing
the meaning when switching from one statement to the other. When you say
"You can write an OS in any programming language", what you mean is "any
programming language + assembler". When you agree with me that none of

those languages "give enough access to the actual hardware to write an

OS", you mean only the language itself, NOT supplemented by assembler.

Incidentally, did you look at any of those esoteric languages? I checked
out several of them, and as far as I could see, none of them provided
any way of calling a subroutine written in assembler, nor did they
provide any option for inline assembler, and I think that most of them
provide no way of defining a subroutine that could be called by a main
program written in some other language. Are you really sure that "You
can write an OS in any language", even those esoteric ones? Since what
you actually meant was "any programming language + assembler", I suppose
you could stretch that meaning to include an OS written almost entirely
in assembler, with the other language serving no particularly important
role in the OS. I will concede that this should be possible, but that's
really stretching the concept of "written in any programming language"
well past the breaking point (in my personal opinion, you've already
stretched it past the breaking point when you failed to say "any
language + assembler").

[BGB]

On 11/15/2017 2:10 AM, David Brown wrote:
> On 15/11/17 00:19, Rick C. Hodgin wrote:

>> On Tuesday, November 14, 2017 at 5:13:13 PM UTC-5, Lynn McGuire wrote:
>>> "The long goodbye to C" by Eric Raymond
>>> http://esr.ibiblio.org/?p=7711
>>>
>>> "I was thinking a couple of days ago about the new wave of systems
>>> languages now challenging C for its place at the top of the
>>> systems-programming heap – Go and Rust, in particular. I reached a
>>> startling realization – I have 35 years of experience in C. I write C
>>> code pretty much every week, but I can no longer remember when I last
>>> started a new project in C!"
>>>
>>> I doubt it.
>>>
>>> Lynn
>>

>> It's true. Unless C evolves, it will be slowly relegated to only
>> niche markets, and will die as a language for any real projects.
>
> So what? If a language is not suitable for new projects, then that is
> because there are better choices - so use them. Lots of languages and
> tools that were fantastic in their day are no longer particularly
> relevant. How many new projects are written in Pascal? Fortran?
> Basic? The answer is a few - they are still the best choice in niche cases.
>
> C needs to evolve to allow us to work with existing C code, and to allow
> us to write code in C in situations where C is still the best language
> choice. It does not need to move into new areas, or make big changes -
> that would reduce its usefulness in existing situations where simplicity
> and stability are key. C will /never/ be a modern language, and no
> amount of "evolution" will make it one - when you put enough into C to
> get a modern language you end up with C++, Objective-C, Rust, etc. - all
> fine languages for their use, and all tracing their roots back to C, but
> none of them /are/ C.
>

I tried before doing a variant of C with more aggressive tweaks (which I
had called "C-Aux"), but even if it worked with "90% of the code", that
last "10%" was enough to sort of ruin things, causing me to later
back-track and make it (semantically at least) a more proper C.

I generally needed something which "compiled C"; and some of the more
aggressive features ran into roadblocks, *1. it wasn't really sufficient
if it looked like C but still required fairly extensive editing to get
things to compile in it.

as well, had ended up implementing some features I hadn't originally
intended on, namely support for K&R decl's, missing prototypes, and
implicit int, as I was running into code which needed them.


though a few extensions remain:
__float16 / "short float"
__int128 and __float128
__variant (dynamically-typed tagged references)
...

a lot of these are implemented internally mostly using runtime calls;
and __variant exists mostly because I wanted to possibly target my BS2
language to the same backend, and by this point it is more of a "may as
well" feature (and at this point makes no claim of being particularly
fast nor all that useful).

the partial exception is float16, which in nearly every context is
equivalent to float; the main exceptions being arrays, pointers, and
structs.


there are various other extension, but most aren't too far off from
things which already exist in GCC and MSVC, and in most cases serve
basically the same purpose (though, for various reasons, the language
features and similar more closely align with those of MSVC than those of
GCC).


*1: I had originally planned to, in some cases, defer parts of the
preprocessor to a much later stage (such as load-time or AOT/JIT time);
and also to try to blur the line between 32 and 64-bit code enough that
the same IL code could be used with either width.

one problem that became a bit problematic was that different typedef's
for various types would exist depending on architecture-related
#define's, struct fields (or sometimes entire structs) may exist or not
exist depending on these defines, ... and the relevant machinery for
dealing with this never got implemented (and, without this, the code is
basically already target-specific once it comes out of the preprocessor).

my BS2 language has this mechanism, but differs in that it is actually
built into the language (and its capabilities are much more narrowly
defined than the C preprocessor).


this has become less relevant though, as now I am mostly using it to
spit out native-code PE/COFF binaries (albeit not for x86 or similar).

albeit, the internal compiler pipeline is very different from more
traditional compilers (eg: translation units are all compiled together;
there is no separate assembler or linker stage; ...).

the closest it has to object files is basically a stack-machine bytecode
it can spit out, basically as a IL for dealing with statically-linked
libraries (given it would be kind of silly to pull in and compile the
source for the C runtime library and similar every time the program is
being recompiled).

>>
>> The whole purpose of CAlive is to inject new life into C by bringing
>> forward some of the features of other languages, and to introduce new
>> features, while maintaining backward compatibility.
>
>
> CAlive is not C - it is a totally different language designed in a

> different way for a different purpose. That is absolutely fine - we

> don't need another C, because we already /have/ C. Make your language
> the way you want, but stop trying to kid yourself that it is the "future
> of C" or "evolved C". Adding some way to support C code does not make
> it an enhanced C any more than a C compiler's "asm" statement means that
> C is an enhanced assembly.
>

I had thought a few times of basically trying to go the other direction
with my BS2 language, and basically try to make it work "bare-metal".

haven't done so though as there is basically "too much other stuff going
on":
doing a C compiler for both a 32-bit and 64-bit versions of an ISA;
and the CPU emulator for both ISA variants;
and trying to do CPU Core implementations in Verilog;
...

is basically enough to eat a mountain of time as-is, so, "make BS2
usable as a systems" language has sort of fallen by the wayside.


could describe the ISA's, but this would basically be somewhat OT here,
but will say that they are basically tweaked/extended variants of the SH
ISA (the 32-bit ISA deriving fairly directly from the Hitachi SH4).

though, if I had infinite time/energy, I might also consider targeting
ARM/Thumb and RISC-V.

>>
>> It is obvious to anyone who is looking: C is dying quickly due to
>> the age of visual languages, and computers fast enough to run much
>> slower code written in other languages faster than the fastest C
>> could do on the CPUs available earlier this century.
>>
>
> Again, so what? If it makes more sense to write a program in Python, or
> Rust, or APL - then write the program in those languages. There can be
> many good reasons for choosing C as the language for a new project -
> "because it is C" is /not/ one of them.
>

I suspect it is more a case of "C has the properties which make it C"
rather than "C because it is named C".

many of the languages which have aimed to replace C fail in one or more
ways to make them an attractive alternative for much of what I am doing.


admittedly, one of the closest of the "mainstream" languages to seem
like a viable alternative (at least for tools and application software)
is probably C#; if for no other reason that it is slightly less stupidly
painful to write code in than Java.

there is "C++", which while not a terrible language per-se, it has the
big drawback of the whole "Modern C++" community (where it is a
discouragement to use the language in the face of crowds of people being
like "You are doing it wrong!"; and me being like "but I want build
times and memory usage that aren't sh**..."; and want code that is not
some cryptic mess of template gobbledygook).


I sort of like my own language, but this is probably a given, and it
still isn't really a great language for writing "serious" software in
(doesn't produce standalone native binaries and its approach to
"library" has thus far basically been more of "lol, yeah, just use the
FFI to call into C land"; had sort of intended at one point to make it
import/export COM interfaces, but never really got around to it, ...).

>> The times, they are a changin'.
>>
>
> True. So change with them, rather than clinging on to the past.
>
> There are plenty of "niche areas" for C as yet. People who want to
> program in C will find lots to do for a long time to come. It is only
> the people that insist that they will use C regardless of the task, that
> will have trouble.
>

personally, most of the time I still end up using C though (and
sometimes C++, but I prefer to keep quiet about this...).

haven't encountered too many scenarios where these don't work
adequately, or where there is an obvious "more clearly better"
alternative. (well, nevermind special-purpose languages, like G-Code and
Verilog and similar).

[Malcolm McLean]

I don't know exactly how it works, but I'd guess that it scans the stack on
each call. So it has access to the stack pointer, which makes it a language
feature.

[bartc]

On 16/11/2017 00:09, David Brown wrote:

> On 15/11/17 20:13, bartc wrote:

>> Think of the loss of productivity of approaching half a century now of
>> people grappling with type declaration syntax, just one thing out of
>> dozens that ought to have been fixed nearly from the start.
>
> Why not just think about the huge majority of C programmers who /don't/
> have a problem with C's type declaration syntax?

I don't believe you. Look at the chapter in K&R2 on complex declarations
and special program to help untangle them, or the existence of CDECL.

>  Or those that
> understand "typedef", precisely so that they don't need to write
> anything too complicated?

A workaround and an extra layer that would not be needed with a simpler
type declaration.

> Or those that simply don't need particularly
> complex types?

Just the difference between pointer to array and array of pointers is
enough!

> There are C implementations for all those platforms.  There is no other
> language that comes close to the breadth of support

Yes, that is a huge advantage. But that doesn't say anything about the
quality of the language. Quite likely there are also assemblers for
every single one of those targets, but also quite likely few use them;
only as a convenient target for a compiler or for the odd bit of code
not otherwise possible.

>> (Jpeg is a good example of a program that must surely be
>> language-neutral.)
>
> How can a program be language neutral?  The jpeg /algorithms/ are
> language neutral, but a jpeg program, or library implementation, is by
> definition written in a programming language and cannot be
> language-neutral.

You're being pedantic. Think of such a program as being written in
pseudo-code then.

>> C also is harder to translate into usable code in another language
>> (than one of mine into C for example).
>
> First, so what?  How often do people want to translate C code into other
> languages?

So a Go language system should rely on a library written in C rather
than having it in Go, complete with C's naff ways of passing array data?
I understand the Go people are keen to be independent of C.

> But you are only one programmer writing a few bits of code for one or
> two platforms.

I currently write for x64, C32 and C64, if you count the last two as
'platforms'. Then you just pass them through any C compiler for a real
platform (not a C16 one). So C is being used, but you don't have to
bother yourself with its problems or deal with its type system etc.

In the past I've targetted pdp10, z80, and 16- and 32-bit x86, so it's
not a bit deal, just extra effort that is not worth doing.

>> Ergo, anyone could create such a language. And since it would be way
>> simpler than ones such as Go and Rust (and can be made simpler than C)
>> it wouldn't be that hard.
>
> So the answer is for everyone to write their own private languages that
> suits their purposes.  Seriously?

Anyone not everyone. By that I mean more than one language at this level
ought to be exist, but not a million.

>> The fact remains that I can code at low level without any of those
>> annoyances.
>>
>
> The inability to code for the targets I want, to use existing code the
> way I want, to use a wide selection of tools the way I want, and to work
> together with other people - that would be /vastly/ more annoying to me
> than any of the oddities of C, no matter how "perfect" your pet language
> may be.

If a more convenient language generates C that works on those targets,
then it solves both problems: works around the annoyances (at least you
don't have to deal with them), and still works on the same targets.
However that solution won't work for you because you rely on so much
more than just the bare language, and use tools not adapted to that
other language.

--
bartc

[David Brown]

On 16/11/17 12:42, bartc wrote:
> On 16/11/2017 00:09, David Brown wrote:
>> On 15/11/17 20:13, bartc wrote:
>
>>> Think of the loss of productivity of approaching half a century now
>>> of people grappling with type declaration syntax, just one thing out
>>> of dozens that ought to have been fixed nearly from the start.
>>
>> Why not just think about the huge majority of C programmers who
>> /don't/ have a problem with C's type declaration syntax?
>
> I don't believe you. Look at the chapter in K&R2 on complex declarations
> and special program to help untangle them, or the existence of CDECL.

I don't have a copy of K&R handy. Also remember that while it was the
first decent C book, it is very far from being the only C book or the
only way to teach C, and the way coding is done in K&R (or K&R2) does
not necessarily represent the best, easiest or clearest way to code.

It is easy to find examples of complex type declarations in C. But it
is far harder to find real-life useful and sensible examples that are so
complex. No sane person works with types that are arrays of pointers to
functions taking function pointers and returning pointers to arrays of
pointers to pointers. So it does not matter how easily you can read or
write that in one big lump in C - it merely matters that the syntax is
general enough to support arbitrary combinations, and that there are
methods for doing such hard stuff if you really need it.

>
>> Or those that understand "typedef", precisely so that they don't
>> need to write anything too complicated?
>
> A workaround and an extra layer that would not be needed with a simpler
> type declaration.

It is not a workaround - it is a simplification and a clarification.

>
>> Or those that simply don't need particularly complex types?
>
> Just the difference between pointer to array and array of pointers is
> enough!

It always seems to cause /you/ trouble. The rules about arrays and
pointers can be confusing for new C programmers, but I think most figure
it out within a few weeks of their courses or book study. Sometimes I
think you jumped from "I've bought a book on C" to "I need to write my
own compiler because nothing else is good enough" without ever actually
trying to learn the language, or learn existing tools.

>
>> There are C implementations for all those platforms. There is no
>> other language that comes close to the breadth of support
>
> Yes, that is a huge advantage. But that doesn't say anything about the
> quality of the language.

I did not claim it did. All I said was that it means there is nothing
that can replace C.

C is a good language, and well-designed for its purpose. It is
certainly not perfect, and it is a poor choice for many of the uses to
which it is put. But it is good enough to still be around while many
other languages have come and gone. It is fair to say that part of the
reason it is popular is because it is popular (that's a key reason we
have things like Windows and the x86 architecture) - but it would have
died out long ago if it were not good enough.

> Quite likely there are also assemblers for
> every single one of those targets, but also quite likely few use them;
> only as a convenient target for a compiler or for the odd bit of code
> not otherwise possible.

>
>>> (Jpeg is a good example of a program that must surely be
>>> language-neutral.)
>>
>> How can a program be language neutral? The jpeg /algorithms/ are
>> language neutral, but a jpeg program, or library implementation, is by
>> definition written in a programming language and cannot be
>> language-neutral.
>
> You're being pedantic. Think of such a program as being written in
> pseudo-code then.

It is not being pedantic! (I am often pedantic - but not here.) A
program is something written in a programming language - that's simply
what the words mean. A language-neutral program is like a
language-neutral poem or a language-neutral dictionary. And note that
the point of my example is that I can compile libjpg (or whatever) with
a C compiler, and not with a Bart-language compiler, because the
/program/ is written in C. I am sure that you could write a new
implementation of the jpeg /algorithm/ in Bart-language - but that means
writing a new implementation, a new /program/.

>
>>> C also is harder to translate into usable code in another language
>>> (than one of mine into C for example).
>>
>> First, so what? How often do people want to translate C code into
>> other languages?
>
> So a Go language system should rely on a library written in C rather
> than having it in Go, complete with C's naff ways of passing array data?
> I understand the Go people are keen to be independent of C.
>

Dogfooding is a fine tradition for programming languages. When you
develop a new programming language, it is normal (unavoidable, even) to
write the compiler, interpreter, libraries, etc., using existing
languages. This is called "bootstrapping". Then if your language is
one that is suitable for the task, you can re-write parts of it in your
new language. Often these different parts will be handled in different
languages - there are not many programming languages that are
appropriate for both a language support library, and for a compiler or
interpreter.

But the Go folk are not translating a C library into Go - they are
writing a /new/ library in Go. There is a big difference - even if the
end result for Go /users/ is much the same.

>
>> But you are only one programmer writing a few bits of code for one or
>> two platforms.
>
> I currently write for x64, C32 and C64, if you count the last two as
> 'platforms'. Then you just pass them through any C compiler for a real
> platform (not a C16 one). So C is being used, but you don't have to
> bother yourself with its problems or deal with its type system etc.

As I say, I am happy with C's type system and have learned to live with
the things I see as problems in C (being far fewer than the things /you/
see as problems). Certainly I would rather continue with C than learn
all the new problems and idiosyncrasies of your personal language and
tools. You treat your own preferences and opinions as though they were
universal facts, and that does not bode well for making a language that
anyone else would choose to use.

>
> In the past I've targetted pdp10, z80, and 16- and 32-bit x86, so it's
> not a bit deal, just extra effort that is not worth doing.
>
>>> Ergo, anyone could create such a language. And since it would be way
>>> simpler than ones such as Go and Rust (and can be made simpler than
>>> C) it wouldn't be that hard.
>>
>> So the answer is for everyone to write their own private languages
>> that suits their purposes. Seriously?
>
> Anyone not everyone. By that I mean more than one language at this level
> ought to be exist, but not a million.

But such a challenger to C's position does /not/ exist. And there are
millions of programmers out there - at least some of whom are a great
deal smarter than you (no offence meant - it's just statistics). If it
made sense to replace C, it would have been replaced. There are many
other languages that have been created that can be used for at least
some of C's uses - and they have replaced or been useful alternatives in
some cases. But nothing has covered everything that C does. All
languages have their advantages and disadvantages (any language that has
enough features for one purpose, is going to be too complex in a
different situation).

>
>>> The fact remains that I can code at low level without any of those
>>> annoyances.
>>>
>>
>> The inability to code for the targets I want, to use existing code the
>> way I want, to use a wide selection of tools the way I want, and to
>> work together with other people - that would be /vastly/ more annoying
>> to me than any of the oddities of C, no matter how "perfect" your pet
>> language may be.
>
> If a more convenient language generates C that works on those targets,
> then it solves both problems: works around the annoyances (at least you
> don't have to deal with them), and still works on the same targets.

You never get something for nothing. Your language might have a nicer
syntax for /you/ (I have seen little of it, so I cannot judge), but you
will lose some of the flexibility or features of C in the process. That
/always/ happens. Despite C being a low-level languages, there are
things that can be done in assembly that simply cannot be expressed in
C. That is why C is /not/ a "portable assembly", nor does it replace
assembly - it replaces the /need/ for assembly in many situations. If
your language and tools are good enough, then they may replace the
/need/ for C in some cases - they do not replace C.

> However that solution won't work for you because you rely on so much
> more than just the bare language, and use tools not adapted to that
> other language.
>

Yes. Real-world, practical C is different from the theoretical world
some people live in. Some useful C code is written using nothing but
the standards - but most uses things that are specific to the target,
the toolchains, additional code and libraries, or at least some
assumptions about the target.

However, I don't see your language and tools appealing much to the
"nothing but pure standard C" developers either.

[Thiago Adams]

On Tuesday, November 14, 2017 at 11:34:15 PM UTC-2, jacobnavia wrote:

> Le 14/11/2017 à 23:13, Lynn McGuire a écrit :
> > "The long goodbye to C" by Eric Raymond
> >    http://esr.ibiblio.org/?p=7711
> >
> > "I was thinking a couple of days ago about the new wave of systems
> > languages now challenging C for its place at the top of the
> > systems-programming heap – Go and Rust, in particular. I reached a
> > startling realization – I have 35 years of experience in C. I write C
> > code pretty much every week, but I can no longer remember when I last
> > started a new project in C!"

GC is a bad idea. I am surprised to have to say this here.
Maybe 80% will agree with me. I was expecting 95% at least.
Why?
Any problem that can be resolved or optimized in some way statically,
(during compilation) is better then a runtime-solution.

(Obs: Numbers of my head)
Many usages of 89% GC is for simple cases. Solved like RAII in C++.
Few cases 10% can be solved by refcounting to especific objects.
And maybe 1% of cases would have some benefit over refcountintg using GC.

[Thiago Adams]

On Thursday, November 16, 2017 at 10:52:44 AM UTC-2, David Brown wrote:
...

> I did not claim it did. All I said was that it means there is nothing
> that can replace C.

I think it is easy for a big company replace C, creating a compatible
language. For instance, something like C++.
Microsoft, apple, linux community, could do this if they want.
At this point we need two justifications. Not only a reason to replace C
but a reason to replace or not use C++ as well.

[Mr. Man-wai Chang]

On 15/11/2017 10:54 PM, Pascal J. Bourguignon wrote:
>
> There are new operating system efforts, but they definitely don't use C.
>
> More like Common Lisp
> https://github.com/froggey/Mezzano/releases/tag/demo3
>
> or other languages, such as Go,
> https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item

Academic or research projects only?

> etc. You can write an OS in any programming language.

Why bother if there are good ones working? Just to prove it's feasible?

Disclaim: I don't know anyone in the operating system world. ;)

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[Thiago Adams]

On Thursday, November 16, 2017 at 10:52:44 AM UTC-2, David Brown wrote:

> On 16/11/17 12:42, bartc wrote:
> > On 16/11/2017 00:09, David Brown wrote:
> >> On 15/11/17 20:13, bartc wrote:
> >
> >>> Think of the loss of productivity of approaching half a century now
> >>> of people grappling with type declaration syntax, just one thing out
> >>> of dozens that ought to have been fixed nearly from the start.
> >>
> >> Why not just think about the huge majority of C programmers who
> >> /don't/ have a problem with C's type declaration syntax?
> >
> > I don't believe you. Look at the chapter in K&R2 on complex declarations
> > and special program to help untangle them, or the existence of CDECL.
>
> I don't have a copy of K&R handy. Also remember that while it was the
> first decent C book, it is very far from being the only C book or the
> only way to teach C, and the way coding is done in K&R (or K&R2) does
> not necessarily represent the best, easiest or clearest way to code.
>
> It is easy to find examples of complex type declarations in C. But it
> is far harder to find real-life useful and sensible examples that are so
> complex. No sane person works with types that are arrays of pointers to
> functions taking function pointers and returning pointers to arrays of
> pointers to pointers. So it does not matter how easily you can read or
> write that in one big lump in C - it merely matters that the syntax is
> general enough to support arbitrary combinations, and that there are
> methods for doing such hard stuff if you really need it.

I think everyone should agree that the C type system could be improved.
We don't need a new language to improve it.

C declaration are ambiguous.
(Does anyone thinks that an ambiguous declaration is good?)

For instance:
struct X
{
struct Y *pY;
};

Is pY a pointer to one struct Y or many?

Someone could say.. I don't care this is not a problem for me.

Can we agree that static analysis is good for everyone?

Then, even if you don't care, and this is not a problem for you
we need to consider that removing ambiguity is good for static
analysis tools and we could create safer programs.

If we don't agree on that then we have big differences in ideology.

[Scott Lurndal]

"Pascal J. Bourguignon" <p...@informatimago.com> writes:
>Melzzzzz <Melz...@zzzzz.com> writes:
>
>> Low level stuff is usually written in C ;)
>
>Nope. You have to do it in assembler.
>

>--
>__Pascal J. Bourguignon
>http://www.informatimago.com

Linux is written is C. Isn't that low-level enough for you?

I've written an operating system and two hypervisors in C++
over the last 30 years. Software that runs at the lowest level
in the system.

Many BIOS and all UEFI implementations (tianocore) are written in C.

[Rick C. Hodgin]

On Thursday, November 16, 2017 at 8:29:54 AM UTC-5, Scott Lurndal wrote:
> "Pascal J. Bourguignon" <p...@informatimago.com> writes:
> >Melzzzzz <Melz...@zzzzz.com> writes:
> >
> >> Low level stuff is usually written in C ;)
> >
> >Nope. You have to do it in assembler.
>

> Linux is written is C. Isn't that low-level enough for you?
>
> I've written an operating system and two hypervisors in C++
> over the last 30 years. Software that runs at the lowest level
> in the system.
>
> Many BIOS and all UEFI implementations (tianocore) are written in C.

C's a good language, but if you look closely you'll find that there
are still some parts of the Linux kernel written in assembly. It is
the interface between specific hardware features and manageable data
on the C-side.

But, on the whole it's C.

To all:

I don't think C needs to go away. But, C needs to evolve and extend
itself to be a more capable language from its own base, rather than
relying on 3rd-party add-ons to extend it.

CAlive seeks to be that step-up from C. Not so complex as C++, but
more than adequate to do nearly all common day-to-day programming
tasks in the single tool, using CAlive-code where appropriate, C-code
where appropriate, assembly-code where appropriate, and even higher
level languages-code where appropriate, all coming together in the
internal framework.

It's how things should be done. It's why I'm working on CAlive in
this way. I could use some help on this project. Please consider
coming aboard and adding your unique abilities and talents. It
would make a difference in people's lives.

--
Rick C. Hodgin

[David Brown]

On 16/11/17 14:12, Thiago Adams wrote:
> On Thursday, November 16, 2017 at 10:52:44 AM UTC-2, David Brown wrote:
> ...
>> I did not claim it did. All I said was that it means there is nothing
>> that can replace C.
>
> I think it is easy for a big company replace C, creating a compatible
> language. For instance, something like C++.

C++ did not (does not) replace C. It is an alternative to C in many
situations, but certainly not all.

And no one company is big enough to have produced C++ - it is a
collaboration amongst a range of companies and other organisations.

> Microsoft, apple, linux community, could do this if they want.

Even if they could, why would they? None of them would have anything to
gain. Both Microsoft and Apple, and the open source community, have
produced languages that are useful in particular cases that are
important to them - "replacing C" is not important to anyone.

> At this point we need two justifications. Not only a reason to replace C
> but a reason to replace or not use C++ as well.
>

Certainly if you wanted to replace C, you would need to have something
that is a better choice than C++ as well as being a better choice than C
for all the current uses of C.

But no "justifications" are needed - because no replacement for C is needed.

Different languages that work better in particular cases are certainly a
good thing - whether it be C++, Go, Rust, Ada, or something new. That's
fine - but they are not replacements for C.

[David Brown]

Exactly. Such things are only a problem if you write code that makes it
a problem.

/Every/ language is full of ambiguities like that. Some languages have
stronger typing systems that are stricter about pointers like this - and
people will complain that in some cases, the type system won't let them
do what they want. Some languages have weaker type systems than C, and
people will complain that the compiler can't spot errors in their code.

/Every/ language lets you write the equivalent of "daysInAWeek = 12".
/Every/ language lets you write a program called "hello" that will print
out "goodbye". /Every/ language will give you some sort of number type,
but have restrictions on what numbers it can hold.

The details of what your language and compiler will and will not allow
can vary, but /no/ language or tool will give you the ideal "it
compiles, therefore it is correct".

>
> Can we agree that static analysis is good for everyone?

I would like to agree on that (/I/ am a big fan), but I know some people
like to write code that would throw up clouds of warnings with any
serious static analysis. And I also know that static analysis comes at
a cost - you get more out of it when you put more information into your
code.

>
> Then, even if you don't care, and this is not a problem for you
> we need to consider that removing ambiguity is good for static
> analysis tools and we could create safer programs.

Give the compiler the information you can, use typedefs, wrap your
arrays in structs, have naming conventions, write clear comments and
pick sensible identifier names. Improve compile-time static analysis,
or use additional static analysers. Use run-time sanitizers. There is
lots you can do to make issues like this a negligible concern.

But there is /nothing/ you can do to change the way pointers work in C,
without changing the way C works.

[bartc]

On 16/11/2017 12:52, David Brown wrote:
> On 16/11/17 12:42, bartc wrote:

> It is easy to find examples of complex type declarations in C. But it
> is far harder to find real-life useful and sensible examples that are so
> complex. No sane person works with types that are arrays of pointers to
> functions taking function pointers and returning pointers to arrays of
> pointers to pointers. So it does not matter how easily you can read or
> write that in one big lump in C - it merely matters that the syntax is
> general enough to support arbitrary combinations, and that there are
> methods for doing such hard stuff if you really need it.

"C is sometimes castigated for the syntax of its declarations,
particularly ones that involve pointers to functions. The syntax is an
attempt to make the declaration and use agree [why?]; it works well for
simple cases, but it can be confusing for the harder ones, because
declarations cannot be read left to right, and because parentheses are
overused."

From K&R2 p122. So it is not just own own opinion and ineptitude as you
constantly seem to think. It goes on to give these two examples:

int *f(); // function returning pointer to int
int (*pf)(); // pointer to function returning int

It says declaration and use agree, which they do, sort of:

f(); // call f
(*pf)(); // call function pointed to by pf

Except that C also allows this:

(*f)(); // call f
pf(); // call function pointed to by pf

WTF? This is where it starts to get crazy. But it gets worse:

f(10,20,30);
f("the quick brown fox");

This compiles, given the above declarations. I'm not going to rerun
everything else I've previously written along this lines, this is just a
reminder of how the famous and extraordinarily successful [how?] C
language works.

FWIW it's worth, my own language declares those two - assuming they take
no arguments - as:

function f => int # this is not a variable
pointer to function => int pf # this is a variable

Although that 'pointer to' is just for show, normally I write 'ref'.
Note that function declarations and variable declarations have different
syntax.

They are called as follows:

f()
pf^()

Attempting to do any of these is an error:

pf()
f(10,20,30)
f("the quick brown fox")

(f^() works, I think because f not immediately followed by ( yields a
pointer to the function. But f^^() doesn't, although (**f)() does in C.)

> It always seems to cause /you/ trouble. The rules about arrays and
> pointers can be confusing for new C programmers, but I think most figure
> it out within a few weeks of their courses or book study. Sometimes I
> think you jumped from "I've bought a book on C" to "I need to write my
> own compiler because nothing else is good enough" without ever actually
> trying to learn the language, or learn existing tools.

My language and compiler came first, as far as I was concerned. Because
that did things sensibly, it was much harder to adjust to a language as
screwed up as C is.

> As I say, I am happy with C's type system and have learned to live with
> the things I see as problems in C (being far fewer than the things /you/
> see as problems). Certainly I would rather continue with C than learn
> all the new problems and idiosyncrasies of your personal language and
> tools.

My own language is just an example, and proof that alternatives can
exist. I'm just waiting for someone else to come out with quality
versions of those, because I'm not interested in the task, and I don't
particularly want people to use my own /implementation/ as it's not good
enough and it's too much work to support. The design though is reasonable.

> You treat your own preferences and opinions as though they were
> universal facts, and that does not bode well for making a language that
> anyone else would choose to use.

I think some things just are generally agreed.

A language that allows = and == in the same expression is going to have
problems. A language that lets you declare a pointer to array, then
allows you to index the pointer and dereference the array, is going to
have problems. One where you have to write (void(**)(void))(0) to cast 0
as a null pointer to pointer to a function taking no arguments and
returning no result is just horrible confusing syntax. [Dozens more
examples left out]

> But such a challenger to C's position does /not/ exist. And there are
> millions of programmers out there - at least some of whom are a great
> deal smarter than you (no offence meant - it's just statistics).

I fully agree. There are many brilliant people working in the fields of
space research, particle physics, bio-genetics, mathematics, or
designing and fabricating new processors, ... everything can think of a
long list of such things. Real science and real technology.

I haven't got a clue about most of those. Yet when it comes to
programming languages, where are all those clever people? Too busy
designing very high level, very complicated languages that can only be
used by equally clever people?

When I first starting toying with creating languages (and on 8-bit toy
computers), it was just a laugh. A temporary workaround until the
professional stuff appeared. Which it never did, or not it a form that
could be used productively.

> If
> your language and tools are good enough, then they may replace the
> /need/ for C in some cases - they do not replace C.

Apart from the lack of a macro processor, AFAIK it can do everything C
can do (even thought the current 2017 version only really still exists
for a small number of specific applications so is not general purpose).

However its implementations are very limited.



--
bartc

[David Brown]

On 16/11/17 13:58, Thiago Adams wrote:
> On Tuesday, November 14, 2017 at 11:34:15 PM UTC-2, jacobnavia wrote:
>> Le 14/11/2017 à 23:13, Lynn McGuire a écrit :
>>> "The long goodbye to C" by Eric Raymond
>>> http://esr.ibiblio.org/?p=7711
>>>
>>> "I was thinking a couple of days ago about the new wave of systems
>>> languages now challenging C for its place at the top of the
>>> systems-programming heap – Go and Rust, in particular. I reached a
>>> startling realization – I have 35 years of experience in C. I write C
>>> code pretty much every week, but I can no longer remember when I last
>>> started a new project in C!"
>
>
> GC is a bad idea. I am surprised to have to say this here.
> Maybe 80% will agree with me. I was expecting 95% at least.
> Why?

Perhaps because you are taking numbers out of thin air?

> Any problem that can be resolved or optimized in some way statically,
> (during compilation) is better then a runtime-solution.

I fully agree that compile-time analysis is better than run-time
solutions. Where you can, put your data in file or function static
data, or on the stack, and use fixed sizes.

Garbage collection is for what you have left - the malloc'ed data. The
run-time allocations.

So the question is, is it better for the programmer to manually
deallocate memory when he/she determines it is the correct point in the
code - or is it better for the garbage collector to handle it
automatically? That depends on how confident you are in the programmer
getting things right, and how keen you are on having control of when
deallocation is done. There is no single correct answer. C++'s RAII
and smart pointers - when used correctly - make it /much/ easier to get
correct deallocation than when you code in C. But even then, there is
no clear case against garbage collection.

[bartc]

On 16/11/2017 05:00, BGB wrote:

> I tried before doing a variant of C with more aggressive tweaks (which I
> had called "C-Aux"), but even if it worked with "90% of the code", that
> last "10%" was enough to sort of ruin things, causing me to later
> back-track and make it (semantically at least) a more proper C.
>
> I generally needed something which "compiled C"; and some of the more
> aggressive features ran into roadblocks, *1. it wasn't really sufficient
> if it looked like C but still required fairly extensive editing to get
> things to compile in it.
>
> as well, had ended up implementing some features I hadn't originally
> intended on, namely support for K&R decl's, missing prototypes, and
> implicit int, as I was running into code which needed them.

I think this is what happens: try deprecate or prohibit ancient features
of C that are now considered poor practice, and it won't work if you
want to be able to compile existing code.

So they are also still allowed in new code thus perpetuating the
practice. A lot of compilers also won't even warn about them unless you
hold a gun to its head, and then you still have to know beforehand about
all of those features.

--
bartc

[Malcolm McLean]

On Thursday, November 16, 2017 at 1:58:43 PM UTC, David Brown wrote:
>
> C++ did not (does not) replace C. It is an alternative to C in many
> situations, but certainly not all.
>

That's not what Bjarne Stroustrup says. He believes that C and C++ should
be one language, and that C is obsolete.

[Rick C. Hodgin]

I agree with Bjarne, except I think C++ should be completely removed
from our space-time continuum, and subsequently replaced with something
not quite so complex, yet wholly useful, like what I intend CAlive to
be.

C is not enough. C++ is ++overkill. My goal is to make CAlive just
right.

--
Rick C. Hodgin

[Spiros Bousbouras]

On Thu, 16 Nov 2017 04:58:40 -0800 (PST)
Thiago Adams <thiago...@gmail.com> wrote:
> GC is a bad idea. I am surprised to have to say this here.

I think it is an excellent idea myself. It's not appropriate for all
circumstances but hardly any programming construct or concept is
appropriate for all circumstances. Automatic garbage collection is
very convenient for some circumstances and on that basis I say it a
great thing.

> Maybe 80% will agree with me. I was expecting 95% at least.
> Why?
> Any problem that can be resolved or optimized in some way statically,
> (during compilation) is better then a runtime-solution.

That depends on how much time and effort is required to resolve it
statically and whether the time and effort has to be expended by a
human or a computer.

> (Obs: Numbers of my head)
> Many usages of 89% GC is for simple cases. Solved like RAII in C++.
> Few cases 10% can be solved by refcounting to especific objects.

Reference counting *is* a garbage collection algorithm. So if the
system automatically implements reference counting then you have a
form of garbage collection.

> And maybe 1% of cases would have some benefit over refcountintg using GC.

So then even taking your made up numbers at face falue , garbage collection
is useful for 1% of programmes. That's a huge number of programmes hence
garbage collection is a good idea not a bad one.

--
vlaho.ninja/prog

[Pascal J. Bourguignon]

The bullshit is believing that garbage collector is specified or an
essential part of programming languages. Common Lisp doesn't specify a
garbage collector. Movitz, an implementation of Common Lisp designed to
write kernels doesn't have a garbage collector. You would IMPLEMENT a
garbage collector writing Common Lisp code!


And similarly, C doesn't specify and C implementations don't usually
provide a garbage collector. BoehmGC is implemented in C, and you can
use it in actual programs compiled from C or other languages sources!

If you cannot make the difference between a language and an
implementation (compiler, interpreter or otherwise), you cannot
understand half of what goes in those comp.lang.* newsgroups!

[Malcolm McLean]

On Thursday, November 16, 2017 at 11:42:10 AM UTC, Bart wrote:
> On 16/11/2017 00:09, David Brown wrote:
> > On 15/11/17 20:13, bartc wrote:
>
> >> Think of the loss of productivity of approaching half a century now of
> >> people grappling with type declaration syntax, just one thing out of
> >> dozens that ought to have been fixed nearly from the start.
> >
> > Why not just think about the huge majority of C programmers who /don't/
> > have a problem with C's type declaration syntax?
>
> I don't believe you. Look at the chapter in K&R2 on complex declarations
> and special program to help untangle them, or the existence of CDECL.
>

Even passing a 2D array to a subroutine is too complicated in C89, and
the C11 method isn't widely enough supported. There's also a subtle problem
with the typedef system which I keep understanding then forgetting,
something to do with the type of grammar that describes C.

However in my view the real problem isn't convoluted type, but type aliasing
(a Malcolm term). Use of more than one type to describe the same thing.

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On Thursday, November 16, 2017 at 8:29:54 AM UTC-5, Scott Lurndal wrote:
>> "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>> >Melzzzzz <Melz...@zzzzz.com> writes:
>> >
>> >> Low level stuff is usually written in C ;)
>> >
>> >Nope. You have to do it in assembler.
>>
>> Linux is written is C. Isn't that low-level enough for you?
>>
>> I've written an operating system and two hypervisors in C++
>> over the last 30 years. Software that runs at the lowest level
>> in the system.
>>
>> Many BIOS and all UEFI implementations (tianocore) are written in C.
>
>C's a good language, but if you look closely you'll find that there
>are still some parts of the Linux kernel written in assembly.

I've been working with the linux kernel tree since 1997 and
contributed kdb to the kernel in 1998.

The only part of linux that's assembled rather than compiled is
a the part that gets control from the boot loader and enables
protected mode, turns on paging and switches to longmode before
transfering the the C code. (header.S, pmjump.S).

$ wc -l arch/x86/boot/*.S
82 arch/x86/boot/bioscall.S
87 arch/x86/boot/copy.S
528 arch/x86/boot/header.S
77 arch/x86/boot/pmjump.S
774 total

GCC's inline assembly is used in a few places as well.

[Rick C. Hodgin]

Yup. Assembly has its place. It's not for the everyday average Joe,
but it definitely has its place because there are some things that
are machine specific, and they require an assembler expression to
translate human thought into the appropriate machine instructions.

--
Rick C. Hodgin

[Pascal J. Bourguignon]

Nope. You don't understand. I don't mention "+ assembler" in the first
place, you do. I don't mention it, because implementing an OS doesn't
mean that you're targetting the hardware where assembly is needed.

Programming languages provide processors. Virtual machines if you will.
Even a native compiler of C provides you with a virtual machine, quite
different from the hardware you can access using assembler, and quite
different even from "process" VM provided by unix systems.

Now if you add the requirement for assembler, then again all languages
are equal (but assembler itself (and even, often assembler aren't able
to generate all the documented instructions of a given variant of a
processor, let alone all the instructions actually implemented by a
given chip!)).

See for example the numerous OSes implemented in JavaScript running in
browser (no hardware, no assembly required, pun on purpose).

> Incidentally, did you look at any of those esoteric languages? I checked
> out several of them, and as far as I could see, none of them provided
> any way of calling a subroutine written in assembler, nor did they
> provide any option for inline assembler, and I think that most of them
> provide no way of defining a subroutine that could be called by a main
> program written in some other language. Are you really sure that "You
> can write an OS in any language", even those esoteric ones?

Sure. As long as they're Turing Complete, you can implement any program
you want on them including an operating system.

> Since what
> you actually meant was "any programming language + assembler",

No, this is you who meant that, because perhaps you don't want AN
operating system, but a SPECIFIC operating system running on a SPECIFIC
machine. And again, the C language doesn't contain anything specific
to your specfic machine, so it will need the same extension as those
more "esoteric" languages, so you're able to target this specific machine.

[Pascal J. Bourguignon]

sc...@slp53.sl.home (Scott Lurndal) writes:

> "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>>Melzzzzz <Melz...@zzzzz.com> writes:
>>
>>> Low level stuff is usually written in C ;)
>>
>>Nope. You have to do it in assembler.
>>
>>--
>>__Pascal J. Bourguignon
>>http://www.informatimago.com
>
>
> Linux is written is C. Isn't that low-level enough for you?

Wrong. There's a whole bunch of assembler in Linux.

And for C, there are a lot of parts that are actually writtenin gcc,
and not in C. Have fun, try to compile it with clang!
https://lwn.net/Articles/734071/

> I've written an operating system and two hypervisors in C++
> over the last 30 years. Software that runs at the lowest level
> in the system.
>
> Many BIOS and all UEFI implementations (tianocore) are written in C.

[David Brown]

On 16/11/17 15:18, bartc wrote:
> On 16/11/2017 12:52, David Brown wrote:
>> On 16/11/17 12:42, bartc wrote:
>
>> It is easy to find examples of complex type declarations in C. But it
>> is far harder to find real-life useful and sensible examples that are so
>> complex. No sane person works with types that are arrays of pointers to
>> functions taking function pointers and returning pointers to arrays of
>> pointers to pointers. So it does not matter how easily you can read or
>> write that in one big lump in C - it merely matters that the syntax is
>> general enough to support arbitrary combinations, and that there are
>> methods for doing such hard stuff if you really need it.
>
> "C is sometimes castigated for the syntax of its declarations,
> particularly ones that involve pointers to functions. The syntax is an
> attempt to make the declaration and use agree [why?]; it works well for
> simple cases, but it can be confusing for the harder ones, because
> declarations cannot be read left to right, and because parentheses are
> overused."
>
> From K&R2 p122. So it is not just own own opinion and ineptitude as you
> constantly seem to think. It goes on to give these two examples:
>
> int *f(); // function returning pointer to int
> int (*pf)(); // pointer to function returning int

Both these forms are obsolete.

int* f(void);
int (*pf)(void);

are slightly clearer.

Function pointers are not used extensively in most programs. In
particular, code rarely needs to store function pointers or write
functions that accept function pointers - it is a little more common to
/use/ functions that accept function pointers (such as registering a
callback, or an atexit() function). You don't need to understand how to
declare function types in order to use them.

It is okay for a feature that is rarely needed, to be a little awkward
to use. Looking up the details when you need them is the work of a
couple of minutes with a web browser - this is /not/ hard.

>
> It says declaration and use agree, which they do, sort of:
>
> f(); // call f
> (*pf)(); // call function pointed to by pf
>
> Except that C also allows this:
>
> (*f)(); // call f

I agree that one is a bit weird. So don't write it - just as it is
legal but (almost always) silly to write 1[a] instead of a[1].

> pf(); // call function pointed to by pf

That is a convenient shortcut syntax, IMHO.

>
> WTF? This is where it starts to get crazy. But it gets worse:
>
> f(10,20,30);
> f("the quick brown fox");
>
> This compiles, given the above declarations. I'm not going to rerun
> everything else I've previously written along this lines, this is just a
> reminder of how the famous and extraordinarily successful [how?] C
> language works.

That is why these sorts of declarations were obsoleted long ago (in C89,
aka ANSI C). And that is why K&R is a poor choice of book for learning
C - it is long outdated (even K&R2).

It is, IMHO, unfortunate that such non-prototype declarations have not
been banned outright in later C standards. And it is, IMHO, ridiculous
that warnings catching them are not enabled by default in major
compilers (like gcc, which does not even include "-Wstrict-prototypes"
in -Wall or -Wextra). Alternatively, it could be treated like in C++,
where "int f()" means "int f(void)". Then mixups like your example
would be a normal parameter mismatch error.


I agree that declaring functions (the use of pointers and function types
here is irrelevant) without a prototype is a bad thing for the language
to have. Fortunately, C has moved on since then - modern C is a better
language than K&R C, though compilers could do a better job of enforcing
this improvement.

That's a little like saying "because I learned to speak English as a
kid, I find it hard to use such a screwed up language as French".

>
>> As I say, I am happy with C's type system and have learned to live with
>> the things I see as problems in C (being far fewer than the things /you/
>> see as problems). Certainly I would rather continue with C than learn
>> all the new problems and idiosyncrasies of your personal language and
>> tools.
>
> My own language is just an example, and proof that alternatives can
> exist. I'm just waiting for someone else to come out with quality
> versions of those, because I'm not interested in the task, and I don't
> particularly want people to use my own /implementation/ as it's not good
> enough and it's too much work to support. The design though is reasonable.
>
>> You treat your own preferences and opinions as though they were
>> universal facts, and that does not bode well for making a language that
>> anyone else would choose to use.
>
> I think some things just are generally agreed.

That is perhaps so - but you are very quick to think that your
particular opinions are "generally agreed". To be fair here, I have
justly been reprimanded for exactly the same thing on more than one
occasion. However, I believe I am better at accepting that others have
different opinions (even if those opinions are wrong... :-) ), while you
cling stubbornly to your ideas of what "everyone" thinks is hard or
confusing about C.

>
> A language that allows = and == in the same expression is going to have
> problems.

Those are problems that are fixed almost entirely by having a good
compiler and/or other good development tools, as well as by having good
programming habits.

> A language that lets you declare a pointer to array, then
> allows you to index the pointer and dereference the array, is going to
> have problems.

I can honestly say this has never been a problem for me.

> One where you have to write (void(**)(void))(0) to cast 0
> as a null pointer to pointer to a function taking no arguments and
> returning no result is just horrible confusing syntax. [Dozens more
> examples left out]

In C, 0 is a null pointer. You don't need to cast it. (But if you
think you need to write a pointer to a pointer to a function, your code
is probably badly structured in the first place.)

[Melzzzzz]

Nope. It uses OS hacks to work. Completely unreliable. Any integer on
stack/heap/data segment that happens to coincide with heap pointer will lead to mem
leak. There is no single language feature that helps GC to work.

--
press any key to continue or any other to quit...

[Thiago Adams]

I think is too radical to say "no replacement for C is needed".
If we think like that C++ was not needed as well.
Was C99 , C11 needed?

Maybe you are trying to say that no other low language is needed,
and we just need to update C. In this case, I agree that is a good
path to go.
C++ has more competitors than C.

[Melzzzzz]

On 2017-11-16, Pascal J. Bourguignon <p...@informatimago.com> wrote:

> supe...@casperkitty.com writes:
>
>> On Wednesday, November 15, 2017 at 6:28:51 PM UTC-6, Pascal J. Bourguignon wrote:
>>> Melzzzzz <Melz...@zzzzz.com> writes:
>>> > You don't want GC in kernel, that's sure. That eliminates all languages
>>> > with GC.
>>>
>>> So this eliminates C, which has BoehmGC and several other garbage
>>> collectors.
>>>
>>> Please stop writing bullshit!
>>
>> It severely curtails the use of languages which can't create aggregates
>> whose storage isn't managed by a garbage collector. Not all languages
>> that include GC features lack the ability to create unmanaged objects,
>> but languages like C# whose design is focused on the GC would at best
>> be very awkward for systems programming since most language features
>> would be unavailable.
>
> The bullshit is believing that garbage collector is specified or an
> essential part of programming languages.

Ahahahahha, greater bullshit I haven't read last month ;)

Common Lisp doesn't specify a
> garbage collector.

Lisp cannot work without GC, you got that?

Movitz, an implementation of Common Lisp designed to
> write kernels doesn't have a garbage collector. You would IMPLEMENT a
> garbage collector writing Common Lisp code!

Problem is that writting Lisp without GC is such nightmare that assembly
would feal easy in comparision to that ;)