Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8897

Re: Smaller C

Show all headers | View raw

On Thu, 08 Oct 2015 03:22:56 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> I have a list (or two) of classical problems of C as a programming
> language. Some of them are easy to solve. Others are a question of
> balance.

A few examples would be nice, but every time someone
asked me for a list, it's not something I have readily
available.

I think James would want to redirect this part of the post
to comp.lang.c ...

> For example, is removing a specific language feature
> going to make more work for the programmer?

That's not been my experience with C.  A you may recall,
I've slowly moved from a much fuller set of C features to
fewer and fewer features over time.

> Or does it have to be replaced with something else/better?

When I read that, I think about the ?: conditional operator
in C.  Is it needed?  I rarely use it.  If I do, it's in a
printf() statement to select between two characters to emit.
I can always replace it with a proper if() or if()-else,
usually with minimal rearrangement.  Similarly, sometimes
I come across C code with goto's to exit a procedure.  These
can usually all be eliminated without extra overhead.

> Is adding a feature going to create a new problem
> for the programmer?

It could.  There are instances of that in C itself.
Implicit int's, typedef's, void and void pointers, ...

> How about the compiler? Will it become significantly
> /unnecessarily more complex as a result of adding that
> feature?

What more is needed in C?

The usual things mentioned in response to that seems to
be features from other languages that people are familiar
with, e.g., closures or lists from LISP, etc, or slightly
more advanced math concepts such as complex integers.
However, none of these are used to program a computer's
hardware.  They may be used to program applications.

> Or will the basic implementation of the compiler require
> more computer resources than the same for C?

Personally, I'm all for reducing C to a smaller subset,
and eliminating some of the problematic issues introduced
as well.  Think LOGO or BASIC.  Ease of use helps not
only novices, but skilled people too.

I never really got around to spend much time looking into
Walter Bright's D language.  He produced the Digital Mars
C compilers.  I recall not be impressed or liking C++ that
much from Bjarne Stroustrup's book.

I think James would want to redirect up to this part of
the post to comp.lang.misc ...

> And then there's another important question. How close
> to C or its "spirit" do we want the language to be?

How minimal should minimalism be? ...

That's an interesting question.  I might've expected it
 from James though with all his philosophical, programming
questions.  The Forth language definately takes certain
aspects of that much further than C and somewhat too
far IMO for various things.

> Specifically, how much work will be needed to convert
> existing C code to this language?

I don't see that as an issue for two reasons.

First, new code will be written for this variation,
if people enjoy using it or find it to be effective.

Second, a more powerful compiler can be modified to
produce or reduce code to the variation, if it's that
useful to do so, e.g., to bootstrap code.

> Do we want it to have access to the C standard library,

It should at least have <stdio.h> because it's very useful.
It could have <string.h> because it's convenient.  It could
have <ctype.h> because it's easy to implement.  As for the
rest, or even the entire library, an open-source version
could be used, if needed.  The remainder of the library
really isn't all that important, IMO.  Sometimes the extra
functionality is useful, but most of the time it's only
needed for specialized situations.  It's generally not
needed for generic code.

> should it be part of the language (like C is a part of C++)?

There are some things which are definately misplaced in C.
So, it would be nice if they were also available as part of
the C compiler too, e.g., malloc(), free(), exit(), etc.

> C++ acquired its audience because of being mostly compatible
> with C and offering some nice and useful extras on top of C.

Please, remind me what those are ...  My thoughts on this
are rather sarcastic or perhaps even somewhat dour.

> On one hand you could try keeping close ties with C to easily
> get first users, early adopters. But if you go the C++ route
> and just support most of C, you'll have the same problem as
> C++ now has. It tries to grow into something better and safer
> than C, but it can't because C is in its DNA, because it shares
> all the same UBs with C and then adds a few of its own. I don't
> think C++ can ever be a nice language because it's growing overly
> complex and because its hiding in itself the ugliness of C. I
> would not want that in a language. On the other hand, it should
> probably also offer something that C does not have (as a language
> proper or in its library), so there's a reason to switch or at
> least to try it out.

...


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?
Just how many food articles from neurotic millenials do we need?

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Smaller C Peter Cheung <mcheung63@gmail.com> - 2015-10-07 00:10 -0700
  Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-07 00:52 -0700
    Re: Smaller C Peter Cheung <mcheung63@gmail.com> - 2015-10-07 02:51 -0700
      Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-10-07 21:01 +0200
        Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 00:25 -0700
          Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-10-08 10:50 +0200
            Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 02:06 -0700
              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-08 19:39 -0400
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-09 01:00 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 20:28 -0400
      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 00:22 -0700
        Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-08 20:19 -0400
          Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-09 02:50 -0700
            Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 22:18 -0400
              Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-10 01:48 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-12 01:52 -0400
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-11 23:49 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-12 20:33 -0400
              Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:50 +0000
                Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:19 -0500
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-01-23 13:54 -0800

csiph-web