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

Groups > alt.os.development > #8888 > unrolled thread

Re: Smaller C

Back to article view | Back to alt.os.development

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 1 of 2  [1] 2  Next page →

#8888 — Re: Smaller C

Alexei A. Frounze於 2012年11月22日星期四 UTC+8下午9時02分48秒寫道：
> I've been working on a simple C compiler lately and here's what I've got so far. It's a fun project, I must tell. :)
> 
> Steve and Rod may be interested to take a look.
> 
> Code (ugly in some places and ways, but apparently functional):
> https://github.com/alexfru/SmallerC
> 
> Alex

May I know the goals of the smallerC?

[toc] | [next] | [standalone]

#8889

On Wednesday, October 7, 2015 at 12:10:57 AM UTC-7, Peter Cheung wrote:
> Alexei A. Frounze於 2012年11月22日星期四 UTC+8下午9時02分48秒寫道：
> > I've been working on a simple C compiler lately and here's what I've got so far. It's a fun project, I must tell. :)
> > 
> > Steve and Rod may be interested to take a look.
> > 
> > Code (ugly in some places and ways, but apparently functional):
> > https://github.com/alexfru/SmallerC
> > 
> > Alex
> 
> May I know the goals of the smallerC?

It doesn't have goals of its own. So, you're asking about
my goals/plans for the compiler. There isn't much. The main
goals of making a usable compiler, which is better than
Cain's/Hendrix' Small C, and having fun with it have been
achieved. I'm adding small stuff here and there. There are
a couple of significant additions that I'd like to make
(a preprocessor and 32-bit floats). And that's about it
at the moment. Do you have any specific question/problem?

Alex

[toc] | [prev] | [next] | [standalone]

#8890

Alexei A. Frounze於 2015年10月7日星期三 UTC+8下午3時52分13秒寫道：
> On Wednesday, October 7, 2015 at 12:10:57 AM UTC-7, Peter Cheung wrote:
> > Alexei A. Frounze於 2012年11月22日星期四 UTC+8下午9時02分48秒寫道：
> > > I've been working on a simple C compiler lately and here's what I've got so far. It's a fun project, I must tell. :)
> > > 
> > > Steve and Rod may be interested to take a look.
> > > 
> > > Code (ugly in some places and ways, but apparently functional):
> > > https://github.com/alexfru/SmallerC
> > > 
> > > Alex
> > 
> > May I know the goals of the smallerC?
> 
> It doesn't have goals of its own. So, you're asking about
> my goals/plans for the compiler. There isn't much. The main
> goals of making a usable compiler, which is better than
> Cain's/Hendrix' Small C, and having fun with it have been
> achieved. I'm adding small stuff here and there. There are
> a couple of significant additions that I'd like to make
> (a preprocessor and 32-bit floats). And that's about it
> at the moment. Do you have any specific question/problem?
> 
> Alex

I am always think human is impossible to replace C, but we can enhance it. I am interested to start over it from the very basic beginning.

[toc] | [prev] | [next] | [standalone]

#8891

Peter Cheung said:

> I am always think human is impossible to replace C, but we can enhance
> it. I am interested to start over it from the very basic beginning.

C and C++ and simalar are made by man.
So there is much room to shorten/improve/addon
and remove all things which arent free of doubt.

So even I'm a machine code programmer I see some benefits in Alexeis 
attempts to put HLL closer to hardware and become less detoured as in
other HL-languages.

__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8893

On Wednesday, October 7, 2015 at 12:02:26 PM UTC-7, wolfgang kern wrote:
> Peter Cheung said:
> 
> > I am always think human is impossible to replace C, but we can enhance
> > it. I am interested to start over it from the very basic beginning.
> 
> C and C++ and simalar are made by man.
> So there is much room to shorten/improve/addon
> and remove all things which arent free of doubt.
> 
> So even I'm a machine code programmer I see some benefits in Alexeis 
> attempts to put HLL closer to hardware and become less detoured as in
> other HL-languages.

What do you mean by the last paragraph? What attempts? What kind
of closeness to hardware? I'm not the inventor of C. Aren't other
C compilers close to hardware? Sorry, I'm not following you here.

Alex

[toc] | [prev] | [next] | [standalone]

#8894

Alexei A. Frounze wrote:
>> Peter Cheung said:
>> 
>> > I am always think human is impossible to replace C, but we can enhance
>> > it. I am interested to start over it from the very basic beginning.
>> 
>> C and C++ and simalar are made by man.
>> So there is much room to shorten/improve/addon
>> and remove all things which arent free of doubt.
>> 
>> So even I'm a machine code programmer I see some benefits in Alexeis 
>> attempts to put HLL closer to hardware and become less detoured as in
>> other HL-languages.
 
> What do you mean by the last paragraph? What attempts? What kind
> of closeness to hardware? I'm not the inventor of C. Aren't other
> C compilers close to hardware? Sorry, I'm not following you here.

Perhaps I misunderstood, but what I read so far seems you have less 
restrictions and the produced code may become less bloated, which I 
see as more hardware near than usual HLL output.

__
wolfgang
 

[toc] | [prev] | [next] | [standalone]

#8895

On Thursday, October 8, 2015 at 1:52:37 AM UTC-7, wolfgang kern wrote:
> Alexei A. Frounze wrote:
> >> Peter Cheung said:
> >> 
> >> > I am always think human is impossible to replace C, but we can enhance
> >> > it. I am interested to start over it from the very basic beginning.
> >> 
> >> C and C++ and simalar are made by man.
> >> So there is much room to shorten/improve/addon
> >> and remove all things which arent free of doubt.
> >> 
> >> So even I'm a machine code programmer I see some benefits in Alexeis 
> >> attempts to put HLL closer to hardware and become less detoured as in
> >> other HL-languages.
>  
> > What do you mean by the last paragraph? What attempts? What kind
> > of closeness to hardware? I'm not the inventor of C. Aren't other
> > C compilers close to hardware? Sorry, I'm not following you here.
> 
> Perhaps I misunderstood, but what I read so far seems you have less 
> restrictions and the produced code may become less bloated, which I 
> see as more hardware near than usual HLL output.

The generated code is quite "bloated". There are many unnecessary
instructions (moves, sing/zero-extensions, jumps, etc) and
registers are used rather inefficiently. Even without considering
language-specific optimizations and smart graph algorithms, you
have overhead immediately visible by the naked eye. You wouldn't
write in assembly like that. :)

Alex

[toc] | [prev] | [next] | [standalone]

#8896

On Thu, 08 Oct 2015 05:06:37 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> The generated code is quite "bloated". There are many unnecessary
> instructions (moves, sing/zero-extensions, jumps, etc) and
> registers are used rather inefficiently.

So, it's time to construct your own more efficient language.

RP


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

[toc] | [prev] | [next] | [standalone]

#8898

On Thursday, October 8, 2015 at 4:39:50 PM UTC-7, Rod Pemberton wrote:
> On Thu, 08 Oct 2015 05:06:37 -0400, Alexei A. Frounze <...@gmail.com> wrote:
> 
> > The generated code is quite "bloated". There are many unnecessary
> > instructions (moves, sing/zero-extensions, jumps, etc) and
> > registers are used rather inefficiently.
> 
> So, it's time to construct your own more efficient language.

Was that a joke or a failure to realize that the poor code is being
generated as a result of simplicity of the compiler (in both design
and implementation)?

Alex

[toc] | [prev] | [next] | [standalone]

#8900

On Fri, 09 Oct 2015 04:00:30 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> On Thursday, October 8, 2015 at 4:39:50 PM UTC-7, Rod Pemberton wrote:
>> On Thu, 08 Oct 2015 05:06:37 -0400, Alexei A. Frounze <...@gmail.com> wrote:
>>
>> > The generated code is quite "bloated". There are many unnecessary
>> > instructions (moves, sing/zero-extensions, jumps, etc) and
>> > registers are used rather inefficiently.
>>
>> So, it's time to construct your own more efficient language.
>
> Was that a joke or a failure to realize that the poor code is being
> generated as a result of simplicity of the compiler (in both design
> and implementation)?
>

Neither.  Suggestion, speculative.

RP

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

[toc] | [prev] | [next] | [standalone]

#8892

On Wednesday, October 7, 2015 at 2:51:41 AM UTC-7, Peter Cheung wrote:
> Alexei A. Frounze於 2015年10月7日星期三 UTC+8下午3時52分13秒寫道：
> > On Wednesday, October 7, 2015 at 12:10:57 AM UTC-7, Peter Cheung wrote:
> > > Alexei A. Frounze於 2012年11月22日星期四 UTC+8下午9時02分48秒寫道：
> > > > I've been working on a simple C compiler lately and here's what I've got so far. It's a fun project, I must tell. :)
> > > > 
> > > > Steve and Rod may be interested to take a look.
> > > > 
> > > > Code (ugly in some places and ways, but apparently functional):
> > > > https://github.com/alexfru/SmallerC
> > > > 
> > > > Alex
> > > 
> > > May I know the goals of the smallerC?
> > 
> > It doesn't have goals of its own. So, you're asking about
> > my goals/plans for the compiler. There isn't much. The main
> > goals of making a usable compiler, which is better than
> > Cain's/Hendrix' Small C, and having fun with it have been
> > achieved. I'm adding small stuff here and there. There are
> > a couple of significant additions that I'd like to make
> > (a preprocessor and 32-bit floats). And that's about it
> > at the moment. Do you have any specific question/problem?
> > 
> > Alex
> 
> I am always think human is impossible to replace C, but we can enhance it. I am interested to start over it from the very basic beginning.

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. For example, is removing a specific language feature going
to make more work for the programmer? Or does it have to be replaced
with something else/better? Is adding a feature going to create a
new problem for the programmer? How about the compiler? Will it
become significantly/unnecessarily more complex as a result of
adding that feature? Or will the basic implementation of the
compiler require more computer resources than the same for C?

And then there's another important question. How close to C or its
"spirit" do we want the language to be? Specifically, how much
work will be needed to convert existing C code to this language?
Do we want it to have access to the C standard library, should it
be part of the language (like C is a part of C++)? C++ acquired
its audience because of being mostly compatible with C and
offering some nice and useful extras on top of C. 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.

In any case, it will still have to provide interfacing/bindings
to other existing stuff (e.g. other languages, DLLs, etc) at the
ABI level or similar as it won't survive in vacuum.

But yes, C can be improved and/or simplified, no doubts there.

Alex

[toc] | [prev] | [next] | [standalone]

#8897

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?

[toc] | [prev] | [next] | [standalone]

#8899

On Thursday, October 8, 2015 at 5:19:22 PM UTC-7, Rod Pemberton wrote:
> On Thu, 08 Oct 2015 03:22:56 -0400, Alexei A. Frounze <...@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.

Unwrap/linearize complex type declarations. Win-win (for both
the programmer and the compiler).

Make declarations distinguishable from expressions, so the code
can be handled by simpler tools when searching/indexing,
analyzing and refactoring it. Win-win.

Carry out comparison of integers of different size and signedness
as you'd do with numbers in mathematics. Simple, small overhead
in the compiler, intuitively expected results to the programmer,
no need for casts or tricks, it just works.

Support integer overflow checks at the language level (I haven't
thought of syntax and exact behavior, but it's something very
important in low level unmanaged code (if we're still considering
the "spirit" of C and assembly) and why shouldn't the language/
compiler be able to help with it?).
Saturating arithmetic is an option to consider as well.

Define the order of subexpression evaluation.

Minimize side effects of expression/statement evaluation.
IOW, turn =, op=, ++, -- into non-expressions to get rid of
a = a++; type of bugs.

Do away with most of silly UB.

Automatically generate type specifiers for formatting, fewer
coding bugs.

But then there are things like the preprocessor. I don't use it
often for anything but #include. But when I do, I use it
to do the exact same sort of things I hate seeing in someone
else's code. :) I mean the ## operator. You can't find stuff
with simple search because of it. But with it you can cut down
on typing. If you remove it, you need something to replace it
with. Forcing the programmer to use external tools for it
isn't a great idea because then the scope of the code, the
language and the tools expands and you will see many different
workarounds, even within the same large project. Is there a
way to keep ## and make it searchable?

There are others. Many many small things that can be either
improved or made more reliable/dependable.

> 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.

Sorry, I don't recall that. Could you remind me?

> > 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. 

?: allows for greater expressiveness, but it gets confusing
very quickly. I'd not have hard feelings about it go.

> Similarly, sometimes
> I come across C code with goto's to exit a procedure.  These
> can usually all be eliminated without extra overhead.

I think we've discussed this before and I disagreed with you.
At any rate, for this special use case one could probably
come up with something that's not goto, but still does its
job. Other than that I'd agree that goto isn't a great feature.
And it provides another way of bypassing initialization, which
is hardly desirable.

> > 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, ...

Other than the implicit int (and indistinguishability of
declarations from types (which is only a part of typedef)),
we had some disagreements here.

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

I've listed some extras above.

I'd like to have better strings and standard containers. And arrays
as true first-class types.

I'd like Unicode and regexp's in the language/library.

I'd like multi-precision arithmetic in the language/library.

I'd like to be able to define functions inside other
functions simply because their code would be in the right
context, surrounded by relevant/related code.

Richer ways to communicate with the outer world, not just
stdin/stdout/stderr, even if that's optional functionality
(e.g. for hosted environment).

Even if you think that something like Python isn't a
serious language (it has plenty of shortcomings) or isn't
going to stay, useful things get done in it and it's
much easier to write in it than in C because the language
is richer and there's quite a bit of stuff in its library,
which has no match in the standard C library. Of course,
not all richness is necessary or very useful, but some
is.

> 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.

Sure. And most programmers make applications, which operate
with higher abstractions than those chiseled in the silicon
of the CPU. So, why not provide some of those most common
abstractions?

> > 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 think some things just have to be renamed or split into
several distinct things to reduce confusion. static is one.
void is perhaps another one.

> 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? ...

Forth? Brainfuck? Discrete vacuum tubes? :)

> That's an interesting question. 

It is.

> 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.

There's usually a fair bit of disagreement because newbies
naturally want things very different from the pros. And not
just newbies vs pros. People with different background/
experience. I wonder if there ever was an attempt to come up
with a language that could be automatically "zoomed in and
out" without breaking any code written in it, but by just
providing different views/interpretations of it. E.g. some
obscure or non-trivial feature could be expressed as a series
of easy to grasp features and they could be collapsed back
into the obscure non-trivial one back, all by a press of
a key or a turn of a wheel.

> > 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.

If you were to get rid of C completely and just have
this one language instead, wouldn't you want to convert
the programs that you like to use into this language?

> > 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.

Compiler? Why? Aren't those OS-specific? Or do you envision
the OS and the compiler as one thing, much like Forth?

> > 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.

So as not to waste too much of our time, I won't. :)

Alex

[toc] | [prev] | [next] | [standalone]

#8901

On Fri, 09 Oct 2015 05:50:47 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> On Thursday, October 8, 2015 at 5:19:22 PM UTC-7, Rod Pemberton wrote:
>> On Thu, 08 Oct 2015 03:22:56 -0400, Alexei A. Frounze <...@gmail.com> wrote:

[...]

>> What more is needed in C?
>
> I've listed some extras above.
>
> I'd like to have better strings and standard containers.

Containers seem to be an object-oriented construct.

So, why would C need this if C has structures?

> And arrays as true first-class types.

What advantage would this offer? ...

E.g., you can always place an array within a struct
to get a first-class type.  You don't even need to
specify the size of the array, due to the C "struct
hack" feature, which was standardized for C99.

#28 C Struct Hack
http://web.archive.org/web/20070807074051/http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html

> I'd like Unicode and regexp's in the language/library.

I'm indifferent and/or mixed on these at this point ...

I see no point in using Unicode to program since ASCII
is sufficient, but Unicode is needed for emitting strings,
nowadays.

Regexp's are convenient, but I've only needed them in
a program a few times, e.g., commandline parameters.

> I'd like multi-precision arithmetic in the language/library.

I'm assuming you meant integer arithmetic here since
C has floats.

The ability to construct larger integers from smaller ones
like with assembly is definately missing in C.  I think most
people will agree upon that.

> I'd like to be able to define functions inside other
> functions simply because their code would be in the right
> context, surrounded by relevant/related code.

Ok.

Another reason that could be useful is for "inheriting"
variables from the outer function into the inner since
it's within outer scope.  This would be useful with
variables declared register.  Implementing this may
be an another issue.

> Richer ways to communicate with the outer world, not just
> stdin/stdout/stderr, even if that's optional functionality
> (e.g. for hosted environment).

I'm not sure of what you mean by this.

A binary stream works with text, binary, files, memory
mapped devices, graphics, etc.

What would you be communicating with, which couldn't be
communicated with via a binary stream? ...

Port I/O is the only thing which comes to my mind.

(Deja Vu...  Did James ask the same?)

> Even if you think that something like Python isn't a
> serious language (it has plenty of shortcomings) or isn't
> going to stay, useful things get done in it and it's
> much easier to write in it than in C because the language
> is richer and there's quite a bit of stuff in its library,
> which has no match in the standard C library. Of course,
> not all richness is necessary or very useful, but some
> is.

I've not used Python, AFAIR.  IIRC, it's converted to C.

For anything which is converted to C, one must ask why
not just use C in the first place?  That includes just
about every language in existence, since they've all
emitted C code or were written in it at some point.  If
someone doesn't have a good justification as to why to
not use C, which they usually don't when asked that,
then I see no point in them using another language.
"All roads lead to Rome."  So, you might as well start
there, IMO.  Of course, Rome fell, but it took a long
time.

>> 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.
>
> Sure. And most programmers make applications, which operate
> with higher abstractions than those chiseled in the silicon
> of the CPU. So, why not provide some of those most common
> abstractions?

That is why we have a large C library, and an even larger
POSIX C library, and why Linux has many, many more libraries,
none of which work together or with out-of-date versions of
each other, and now you want even more functionality above,
which is likely to be kept in even more libraries.  ;-)

So, issues with bloat (as indicated sarcasticly above),
or implementation, or portability would be reasons not
to do so.  Do the advantages outweigh the costs?  Are
diminishing returns in effect?  I would probably argue
that the more advanced the concept becomes, the less it
will be used and so it has less value.  At some point,
it doesn't make sense for someone to implement it.

E.g., if you're not plotting Mandelbrot sets or taking
an Algebra class, when would you ever use complex numbers?
Should you construct an entire financial transaction
framework?  Everybody must buy things and take care of
banking.  What about a physics engine?  Everyone is going
to use 3D virtual reality.  When do you stop?  It that
point once we can no longer model anything more in reality?

>> > 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? ...
>
> Forth? Brainfuck? Discrete vacuum tubes? :)

I don't know much about tubes, other than they do much the
same as transistors, have a vacuum, plate, grid etc, emit
electrons, can become very hot, use higher voltages, have
"getter" to absorb oxygen, don't perform IRL as good as in
theory, can be defective despite everyones belief they are
nearly perfect devices, perfectly manufactured, and they
can provide a modified sound which some musicians love.

Getter
https://en.wikipedia.org/wiki/Getter

I've learned much about the first two over the past few years.

Forth, especially ITC Forth, has a number of useful techniques
and features, which could be used for interpreters for other
languages, e.g., 0-operand stacks, threaded code (DTC, ITC),
simplified AST as a dictionary (library), but it seems that
early Forth deviated from it's original designs at some point.
I'm not found of some of what came after the deviation.  It
was more algebraic, like C, than word based, like it is now.

Brainfuck is not really as simple as it seems ...  It uses
many boundary effects.  There are a couple handfuls of commonly
used sequences which are used to implement slightly higher
level operations.  A language designed with these slightly
higher level operations would still be too low-level, but
actually more useful, e.g., perhaps if used inconjunction
with an ITC interpreter and a stack like ITC Forths.  Of
course, ITC Forth dictionaries (library) are usually built
up from a small set of about 35 to 65 "primitives" (low-level
functions).

I'm not sure about the entirety of the ANSI/ICO C libraries,
but I suspect that much of it can also be built up from some
base functions, and odds and ends.  Most minimal C libraries
interface to the host OS with less than 20 functions, mostly
file I/O related.  I'd probably attempt to start with the
memory functions in <string.h> and most of <stiod.h> and
work from there.  I'd be doubtful about building up the POSIX
C libraries that way, simply due to their rather large
size, but it may be possible.

>> 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.
>
> There's usually a fair bit of disagreement because newbies
> naturally want things very different from the pros. And not
> just newbies vs pros. People with different background/
> experience. I wonder if there ever was an attempt to come up
> with a language that could be automatically "zoomed in and
> out" without breaking any code written in it, but by just
> providing different views/interpretations of it. E.g. some
> obscure or non-trivial feature could be expressed as a series
> of easy to grasp features and they could be collapsed back
> into the obscure non-trivial one back, all by a press of
> a key or a turn of a wheel.
>

Every object in C maps onto an array of C bytes.  Is something
like that what you meant?  Or, did you mean something more
along the lines of expanding and collapsing items in a list
in a browser, and dragging and dropping a link into a folder?
So, James was recently discussing modules, and you seem to be
thinking about containers, I'd say in a similar manner.  You
both seem to want some way to organize, build up, and group
smaller pieces into large pieces like Minecraft or Forth or
MacDraw or Visio a does.  Point, click, drag, drop, organize,
link, connect, group, *BOOM* working code ...  Wasn't that
the point of Visual Basic, Visual C/C++, and Visual Studio, etc?

>> > 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.
>
> If you were to get rid of C completely and just have
> this one language instead, wouldn't you want to convert
> the programs that you like to use into this language?

Most likely, but that takes time.  There is a large amount
of in-use code which must be converted, tweaked and tested,
or rewritten from scratch.  Think of converting all C or
Python code etc to a new language 'X'.  Immense.

>> > 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.
>
> Compiler? Why? Aren't those OS-specific? Or do you envision
> the OS and the compiler as one thing, much like Forth?

I'd desire them to be optionally available in the compiler so
that only <stdio.h> would be absolutely required for the
minimalist compiler situation.  Once a compiler has a library,
this isn't needed, but may still be useful to someone reducing
library dependence to only <stdio.h>.


Rod Pemberton

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

[toc] | [prev] | [next] | [standalone]

#8902

On Friday, October 9, 2015 at 7:18:41 PM UTC-7, Rod Pemberton wrote:
> On Fri, 09 Oct 2015 05:50:47 -0400, Alexei A. Frounze <...@gmail.com> wrote:
> 
> > On Thursday, October 8, 2015 at 5:19:22 PM UTC-7, Rod Pemberton wrote:
> >> On Thu, 08 Oct 2015 03:22:56 -0400, Alexei A. Frounze <...@gmail.com> wrote:
> 
> [...]
> 
> >> What more is needed in C?
> >
> > I've listed some extras above.
> >
> > I'd like to have better strings and standard containers.
> 
> Containers seem to be an object-oriented construct.
> 
> So, why would C need this if C has structures?

Sorry if I wasn't clear enough. I meant lists, trees, hash tables
and such. C++, Python and a bunch of other languages have them.
It's great to not have them in C when you want your students to
implement them from scratch. It's not so great to have to either
implement them when you're not interested in the exercise or to
carry around a special library for something that could've existed
in the standard library. Every decent OS kernel written in C has
its implementation of these, Linux, Windows, BSD, etc. Every
decent C compiler has them. And yet, the library does not.
Long gone are the times when computers had little storage, were
slow and awkward to use. If 30-40 years ago you could argue that
having those things in the library wasn't very rational (you had
little data to operate on and you had little memory for the code
to handle it and it was harder to implement and test said code),
today it's not a problem anymore. Today we have better code
editors, more books on algorithms (and lots of existing
implementations easily obtainable online), more storage and power
to test certain things using brute force, and our problems are
larger. Everything is favorable for inclusion of those things in
the library nowadays.

> > And arrays as true first-class types.
> 
> What advantage would this offer? ...

I think it would be proper to reduce the confusion in the
arrays and pointers area and be able to pass an array as
an array and not as a pointer or as an array inside of a
structure.

...
> > I'd like Unicode and regexp's in the language/library.
> 
> I'm indifferent and/or mixed on these at this point ...
> 
> I see no point in using Unicode to program since ASCII
> is sufficient, but Unicode is needed for emitting strings,
> nowadays.

So, do you tell the Chinese to learn English in order to be
able to process text data that's not ASCII? I mean, you could
get away with Morse code just as well, but come on. And then
today many products exist in many languages and it's often
expected that software be able to output and take input in
different languages, including simultaneously.

> Regexp's are convenient, but I've only needed them in
> a program a few times, e.g., commandline parameters.

I've written some of my text processing tools in Perl simply
because it was a language, where I had Unicode, regexps and
containers (lists, hash tables). I didn't do it in C or C++
because a lot of the stuff I needed wasn't in them.

> > I'd like multi-precision arithmetic in the language/library.
> 
> I'm assuming you meant integer arithmetic here since
> C has floats.

Yes, integer.

> The ability to construct larger integers from smaller ones
> like with assembly is definately missing in C.  I think most
> people will agree upon that.

It's not a big deal to implement basic support for it. Actually,
even a simpler implementation with compile-time-defined length
would be extremely helpful (if you could construct have not only
uint64_t, but also uintANY_t).

> > I'd like to be able to define functions inside other
> > functions simply because their code would be in the right
> > context, surrounded by relevant/related code.
> 
> Ok.
> 
> Another reason that could be useful is for "inheriting"
> variables from the outer function into the inner since
> it's within outer scope.  This would be useful with
> variables declared register.  Implementing this may
> be an another issue.

It may be useful, but a light context/scope-unaware version
is already an improvement, IMO.

> > Richer ways to communicate with the outer world, not just
> > stdin/stdout/stderr, even if that's optional functionality
> > (e.g. for hosted environment).
> 
> I'm not sure of what you mean by this.
> 
> A binary stream works with text, binary, files, memory
> mapped devices, graphics, etc.
> 
> What would you be communicating with, which couldn't be
> communicated with via a binary stream? ...
> 
> Port I/O is the only thing which comes to my mind.
> 
> (Deja Vu...  Did James ask the same?)

I mean displays, speakers, internets. We've had most of
this stuff in our computers for several decades now. But
the language haven't caught up with the reality. I hear
C++ seems to be moving in the right direction with this
(rumors) and there are some plans to support graphics
and network.

> > Even if you think that something like Python isn't a
> > serious language (it has plenty of shortcomings) or isn't
> > going to stay, useful things get done in it and it's
> > much easier to write in it than in C because the language
> > is richer and there's quite a bit of stuff in its library,
> > which has no match in the standard C library. Of course,
> > not all richness is necessary or very useful, but some
> > is.
> 
> I've not used Python, AFAIR.  IIRC, it's converted to C.
> 
> For anything which is converted to C, one must ask why
> not just use C in the first place?  That includes just
> about every language in existence, since they've all
> emitted C code or were written in it at some point.  If
> someone doesn't have a good justification as to why to
> not use C, which they usually don't when asked that,
> then I see no point in them using another language.
> "All roads lead to Rome."  So, you might as well start
> there, IMO.  Of course, Rome fell, but it took a long
> time.

Speaking of Rome... I wonder why you don't speak Latin.
A sizable portion of English comes directly or indirectly
from it. And it was a fine language at the time and
technically it could still be used today, you just need to
update its vocabulary. :)

> >> 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.
> >
> > Sure. And most programmers make applications, which operate
> > with higher abstractions than those chiseled in the silicon
> > of the CPU. So, why not provide some of those most common
> > abstractions?
> 
> That is why we have a large C library, and an even larger
> POSIX C library, and why Linux has many, many more libraries,
> none of which work together or with out-of-date versions of
> each other, and now you want even more functionality above,
> which is likely to be kept in even more libraries.  ;-)

There's plenty of generic stuff that isn't hardware/OS-specific
and can be part of the standard library. Versioning is another
issue altogether. I'm not talking about that now.

> So, issues with bloat (as indicated sarcasticly above),
> or implementation, or portability would be reasons not
> to do so.  Do the advantages outweigh the costs?  Are
> diminishing returns in effect?  I would probably argue
> that the more advanced the concept becomes, the less it
> will be used and so it has less value.  At some point,
> it doesn't make sense for someone to implement it.

So, English has around 1M words (800K, maybe?), right?
You only know some 50-100K and actually use many many
fewer, especially on the daily basis. Some you use extremely
rarely or not at all because they do not naturally occur in
your work, studies, hobbies and everyday life. They do occur
in lives of others, though. Same with things. You don't have
and don't use some, because you don't need to, don't want to
or maybe can't for monetary, cultural or other reasons. There
are people who do have and use those things, because they
find them useful or better than more primitive alternatives
(if any) of the past. Right? Same here. What you don't need
in a programming language or don't like always finds support
in other people, no matter your views or values.

> E.g., if you're not plotting Mandelbrot sets or taking
> an Algebra class, when would you ever use complex numbers?
> Should you construct an entire financial transaction
> framework?  Everybody must buy things and take care of
> banking.  What about a physics engine?  Everyone is going
> to use 3D virtual reality.  When do you stop?  It that
> point once we can no longer model anything more in reality?

You're taking it too far. Like I said, there's a bunch of
(more) common algorithms behind many different tasks and they
deserve to be part of the standard library. PCs have a number
of common ways to interact with people and other PCs ("3D
virtual reality" is not something common yet). That should be
in the library too.

> >> > 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? ...
> >
> > Forth? Brainfuck? Discrete vacuum tubes? :)
> 
> I don't know much about tubes, other than they do much the
> same as transistors, have a vacuum, plate, grid etc, emit
> electrons, can become very hot, use higher voltages, have
> "getter" to absorb oxygen, don't perform IRL as good as in
> theory, can be defective despite everyones belief they are
> nearly perfect devices, perfectly manufactured, and they
> can provide a modified sound which some musicians love.
> 
> Getter
> https://en.wikipedia.org/wiki/Getter
> 
> I've learned much about the first two over the past few years.
> 
> Forth, especially ITC Forth, has a number of useful techniques
> and features, which could be used for interpreters for other
> languages, e.g., 0-operand stacks, threaded code (DTC, ITC),
> simplified AST as a dictionary (library), but it seems that
> early Forth deviated from it's original designs at some point.
> I'm not found of some of what came after the deviation.  It
> was more algebraic, like C, than word based, like it is now.
> 
> Brainfuck is not really as simple as it seems ...  It uses
> many boundary effects.  There are a couple handfuls of commonly
> used sequences which are used to implement slightly higher
> level operations.  A language designed with these slightly
> higher level operations would still be too low-level, but
> actually more useful, e.g., perhaps if used inconjunction
> with an ITC interpreter and a stack like ITC Forths.  Of
> course, ITC Forth dictionaries (library) are usually built
> up from a small set of about 35 to 65 "primitives" (low-level
> functions).
> 
> I'm not sure about the entirety of the ANSI/ICO C libraries,
> but I suspect that much of it can also be built up from some
> base functions, and odds and ends.  Most minimal C libraries
> interface to the host OS with less than 20 functions, mostly
> file I/O related.  I'd probably attempt to start with the
> memory functions in <string.h> and most of <stiod.h> and
> work from there.  I'd be doubtful about building up the POSIX
> C libraries that way, simply due to their rather large
> size, but it may be possible.
> 
> >> 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.
> >
> > There's usually a fair bit of disagreement because newbies
> > naturally want things very different from the pros. And not
> > just newbies vs pros. People with different background/
> > experience. I wonder if there ever was an attempt to come up
> > with a language that could be automatically "zoomed in and
> > out" without breaking any code written in it, but by just
> > providing different views/interpretations of it. E.g. some
> > obscure or non-trivial feature could be expressed as a series
> > of easy to grasp features and they could be collapsed back
> > into the obscure non-trivial one back, all by a press of
> > a key or a turn of a wheel.
> >
> 
> Every object in C maps onto an array of C bytes.  Is something
> like that what you meant?  Or, did you mean something more
> along the lines of expanding and collapsing items in a list
> in a browser, and dragging and dropping a link into a folder?

Yes and no.

> So, James was recently discussing modules, and you seem to be
> thinking about containers, I'd say in a similar manner.  You
> both seem to want some way to organize, build up, and group
> smaller pieces into large pieces like Minecraft or Forth or
> MacDraw or Visio a does.  Point, click, drag, drop, organize,
> link, connect, group, *BOOM* working code ...  Wasn't that
> the point of Visual Basic, Visual C/C++, and Visual Studio, etc?

I'm frustrated with large C++ projects and I bet I'm not alone
here. I can't see what's behind a line of seemingly innocuous
code without finding types and reading lots of declarations
and definitions and that can go on recursively, in depth and
in breadth. That's not C++'s fault entirely. You can write
large and complex software in other languages as well. But with
C++ it's very easy to lose an important detail, which you don't
see, because it's thousands of lines away from where you're
now and because there's something happening implicitly per
the rules of the language. What I (and, I guess, many others)
would really like to see is where instances (including
short-lived temporary ones) are created, what the assignment
operator (and others) unfolds into and things like that. I have
no hopes ever knowing C++ nearly as well as I do C or assembly.
Several times in my career I have had to resort to reading
disassembly of compiled C++ code in order to understand the
grand plan of the author, who generously used classes and
templates. But that's not how it should be. Either you don't
complicate the language (code complexity is more than enough
already) or you provide tools to deal with this complexity.
In C++ there doesn't seem to be enough good tools for the
language complexity. So, if you let your compiler figure out
which type/function to substitute, which constructor to
call and so on, the IDE must be able to show you on demand
the decisions that the compiler makes when it compiles the
code. Our C++ IDEs are still piss poor with things like that.
I'm not sure the language is properly designed if you
have such problems with source code written in it.

> >> > 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.
> >
> > If you were to get rid of C completely and just have
> > this one language instead, wouldn't you want to convert
> > the programs that you like to use into this language?
> 
> Most likely, but that takes time.  There is a large amount
> of in-use code which must be converted, tweaked and tested,
> or rewritten from scratch.  Think of converting all C or
> Python code etc to a new language 'X'.  Immense.
> 
> >> > 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.
> >
> > Compiler? Why? Aren't those OS-specific? Or do you envision
> > the OS and the compiler as one thing, much like Forth?
> 
> I'd desire them to be optionally available in the compiler so
> that only <stdio.h> would be absolutely required for the
> minimalist compiler situation.  Once a compiler has a library,
> this isn't needed, but may still be useful to someone reducing
> library dependence to only <stdio.h>.

Then, to make malloc() and the company optional, you need to
redesign stdio. There's implicit buffering with memory allocated
during fopen() or first fgetc()/fputc(). Smaller C has a single
character buffer in FILE. So, when the I/O is unbuffered or
when malloc() fails, it uses it. You'd need something like that
in the library and a way to use stdio without linking malloc()'s.

Alex

[toc] | [prev] | [next] | [standalone]

#8903

On Sat, 10 Oct 2015 04:48:19 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> On Friday, October 9, 2015 at 7:18:41 PM UTC-7, Rod Pemberton wrote:
>> On Fri, 09 Oct 2015 05:50:47 -0400, Alexei A. Frounze <...@gmail.com> wrote:

>> > I wonder if there ever was an attempt to come up
>> > with a language that could be automatically "zoomed in and
>> > out" without breaking any code written in it, but by just
>> > providing different views/interpretations of it. E.g. some
>> > obscure or non-trivial feature could be expressed as a series
>> > of easy to grasp features and they could be collapsed back
>> > into the obscure non-trivial one back, all by a press of
>> > a key or a turn of a wheel.
>> >
>>
>> Every object in C maps onto an array of C bytes.  Is something
>> like that what you meant?  Or, did you mean something more
>> along the lines of expanding and collapsing items in a list
>> in a browser, and dragging and dropping a link into a folder?
>
> Yes and no.
>
>> So, James was recently discussing modules, and you seem to be
>> thinking about containers, I'd say in a similar manner.  You
>> both seem to want some way to organize, build up, and group
>> smaller pieces into large pieces like Minecraft or Forth or
>> MacDraw or Visio a does.  Point, click, drag, drop, organize,
>> link, connect, group, *BOOM* working code ...  Wasn't that
>> the point of Visual Basic, Visual C/C++, and Visual Studio, etc?
>
> I'm frustrated with large C++ projects and I bet I'm not alone
> here. I can't see what's behind a line of seemingly innocuous
> code without finding types and reading lots of declarations
> and definitions and that can go on recursively, in depth and
> in breadth. That's not C++'s fault entirely. You can write
> large and complex software in other languages as well. But with
> C++ it's very easy to lose an important detail, which you don't
> see, because it's thousands of lines away from where you're
> now and because there's something happening implicitly per
> the rules of the language. What I (and, I guess, many others)
> would really like to see is where instances (including
> short-lived temporary ones) are created, what the assignment
> operator (and others) unfolds into and things like that. I have
> no hopes ever knowing C++ nearly as well as I do C or assembly.
> Several times in my career I have had to resort to reading
> disassembly of compiled C++ code in order to understand the
> grand plan of the author, who generously used classes and
> templates. But that's not how it should be. Either you don't
> complicate the language (code complexity is more than enough
> already) or you provide tools to deal with this complexity.
> In C++ there doesn't seem to be enough good tools for the
> language complexity. So, if you let your compiler figure out
> which type/function to substitute, which constructor to
> call and so on, the IDE must be able to show you on demand
> the decisions that the compiler makes when it compiles the
> code. Our C++ IDEs are still piss poor with things like that.
> I'm not sure the language is properly designed if you
> have such problems with source code written in it.

I have two thoughts on that.

1) Well, if C++ clearly isn't the solution, then I would
strongly guess that C is since C++ is a language which once
compiled to C, just like all the other languages.  I did
say all roads lead to Rome.

2) You just argued for more complexity to be introduced into
the libraries due to their necessity, but also stated above
that "code complexity is more than enough already."  So,
which is it?

(You can't see me grinning for either reply.)

> Either you don't complicate the language [...] or you provide
> tools to deal with this complexity.  In C++ there doesn't seem
> to be enough good tools for the language complexity.

Well, obviously, I would argue for simplicity.

I recall a problem posted to comp.lang.c some years ago
where a student wanted a solution using a linked-list.
It was probably a requirement from their teacher.  So,
I posted a solution that didn't use a linked-list, and
stated that the solution was too simple to use a
linked-list, which it was.  I used counters.  I'm sure
the student submitted the solution thinking the novel
solution would impress their teacher.  Perhaps, they
had no other choice, i.e., they couldn't solve it.  It
was likely that their teacher was bombarded with 3 or 15
or maybe even 30 copies of my solution.  It's possible
they received even more, perhaps even 10,000, since this
was for someone from China where they test large groups.
"All them couldn't possibly have arrived with the exact
same solution."  Fail for cheating.  Fail for not
following the directions, i.e., didn't use a linked-list.

The point is that most Computer Science professors place
way too much emphasis on using linked-lists, structs,
local variables, etc.  So, their students use linked-lists,
even for trivial solutions where a LIFO stack or a counter
or an array would work.  So, I'd have to argue that having
fewer libraries available actually contributes to better
solutions and code.  I.e., the path of least resistance
is likely to be a mistake.


Rod Pemberton


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

[toc] | [prev] | [next] | [standalone]

#8904

On Sunday, October 11, 2015 at 10:52:24 PM UTC-7, Rod Pemberton wrote:
...
> 2) You just argued for more complexity to be introduced into
> the libraries due to their necessity, but also stated above
> that "code complexity is more than enough already."  So,
> which is it?

Consider two pieces of code, one using the implementation of
algorithm/container X from the standard library and the other
implementing its own, most likely poorly documented. Which
one would be easier to understand? Imagine now you routinely
have to look at custom implementations, not just once, but
many times, because there're many projects and subprojects.
Wouldn't you save time and effort by dealing more with known
and less with unknown?

> (You can't see me grinning for either reply.)
> 
> > Either you don't complicate the language [...] or you provide
> > tools to deal with this complexity.  In C++ there doesn't seem
> > to be enough good tools for the language complexity.
> 
> Well, obviously, I would argue for simplicity.
> 
> I recall a problem posted to comp.lang.c some years ago
> where a student wanted a solution using a linked-list.
> It was probably a requirement from their teacher.  So,
> I posted a solution that didn't use a linked-list, and
> stated that the solution was too simple to use a
> linked-list, which it was.  I used counters.  I'm sure
> the student submitted the solution thinking the novel
> solution would impress their teacher.  Perhaps, they
> had no other choice, i.e., they couldn't solve it.  It
> was likely that their teacher was bombarded with 3 or 15
> or maybe even 30 copies of my solution.  It's possible
> they received even more, perhaps even 10,000, since this
> was for someone from China where they test large groups.
> "All them couldn't possibly have arrived with the exact
> same solution."  Fail for cheating.  Fail for not
> following the directions, i.e., didn't use a linked-list.
> 
> The point is that most Computer Science professors place
> way too much emphasis on using linked-lists, structs,
> local variables, etc.  So, their students use linked-lists,
> even for trivial solutions where a LIFO stack or a counter
> or an array would work.  So, I'd have to argue that having
> fewer libraries available actually contributes to better
> solutions and code.  I.e., the path of least resistance
> is likely to be a mistake.

If it's the teacher's intent to make their students do X
and not Y, they should communicate that clearly and set the
rules to follow (N points given/taken for BLAH). Sometimes
you do X and not Y because it's an exercise. But we digress.

Alex

[toc] | [prev] | [next] | [standalone]

#8905

On Mon, 12 Oct 2015 02:49:47 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> On Sunday, October 11, 2015 at 10:52:24 PM UTC-7, Rod Pemberton wrote:

>> 2) You just argued for more complexity to be introduced into
>> the libraries due to their necessity, but also stated above
>> that "code complexity is more than enough already."  So,
>> which is it?
>
> Consider two pieces of code, one using the implementation of
> algorithm/container X from the standard library and the other
> implementing its own, most likely poorly documented. Which
> one would be easier to understand?

You're probably not going to like or accept my answer to that.

It's the poorly documented custom solution, at least 85% of
the time.  Why?  The custom solution is likely to have reduced
functionality, be short, and simple to understand.  The code
for the custom solution also is included with the program.  This
means it doesn't have to be searched for and found.  The code
for the C libraries aren't present with the program and can take
a while to search.  The code for the C libraries were coded by
someone skilled in C to work for the specific host.  So, they
have many qualifiers, typdefs, recursive declarations (which
you just complained about), #ifdef's, #undef's, and other,
sometimes complicated, stuff happening.

> Imagine now

At this point, I'm assuming you meant the poorly documented
code would be more difficult to understand.

> Imagine now you routinely have to look at custom implementations,
> not just once, but many times, because there're many projects
> and subprojects.  Wouldn't you save time and effort by dealing
> more with known and less with unknown?

It's very likely the custom implementation uses the same parameters
as the library implementation, e.g., when standard C libraries aren't
present.  So, if it functions correctly for the code in question,
I don't see where the problem arises.  AIUI, the problem is when
someone assumes the custom implementation is more complete, or has
capability which it doesn't.

there're ... ?

I'm a bit unsure about the validity of that contraction.

> If it's the teacher's intent to make their students do X
> and not Y, they should communicate that clearly and set the
> rules to follow (N points given/taken for BLAH). Sometimes
> you do X and not Y because it's an exercise. But we digress.
>

The English teachers I had from second grade through the end
of high school wanted their students to compose sentences for
a word which used that word correctly.  I.e., the sentence
was to express the word's definition accurately.  They simply
stated: "Write down a sentence." or "Write down a sentence
for each word." without any further instruction.  There was
never any directive that the student must compose their own
sentence and write that down.  There was no constraint on
where the sentence came from or who wrote it.  So, from second
grade through eleventh, I wrote down the sentence which was
in our dictionary at home.  It was only in eleventh grade when
I copied down the sentence from a dictionary available to our
class when I found out that doing so wasn't accepted.  The
teacher still attempted to claim that "Write down a sentence."
meant that I must compose a sentence of my own and write that
down, despite the given command saying no such thing.  This
wasn't revealed sooner because we had a rather rare dictionary.
There were roughly twenty different teachers, not one of whom
clarified the situation with sufficient information to any
class which they taught.

So, while I agree with you that teacher's should be more
precise and clarify, it's clear to me that people simply
can't communicate clearly, even if it's their job to do so.


Rod Pemberton

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

[toc] | [prev] | [next] | [standalone]

#9097

On 10/10/2015 03:18, Rod Pemberton wrote:
> On Fri, 09 Oct 2015 05:50:47 -0400, Alexei A. Frounze
> <alexfrunews@gmail.com> wrote:

...

>> Even if you think that something like Python isn't a
>> serious language (it has plenty of shortcomings) or isn't
>> going to stay, useful things get done in it and it's
>> much easier to write in it than in C because the language
>> is richer and there's quite a bit of stuff in its library,
>> which has no match in the standard C library. Of course,
>> not all richness is necessary or very useful, but some
>> is.
>
> I've not used Python, AFAIR.  IIRC, it's converted to C.

Python is normally converted to bytecode. You can compile text to 
bytecode and disassemble that bytecode to see what it does. For example, 
the following python code compiles a simple assignment and disassembles 
the resulting bytecode.

   import dis
   x = compile('a = 1', '', 'single')
   dis.dis(x)

The result is this disassembly:

   0 LOAD_CONST               0 (1)
   3 STORE_NAME               0 (a)
   6 LOAD_CONST               1 (None)
   9 RETURN_VALUE

> For anything which is converted to C, one must ask why
> not just use C in the first place?  That includes just
> about every language in existence, since they've all
> emitted C code or were written in it at some point.  If
> someone doesn't have a good justification as to why to
> not use C, which they usually don't when asked that,
> then I see no point in them using another language.

Python does make some things very easy to write (as above) but it is not 
suitable for everything. As you can see from the bytecode it would be 
much slower than C, for example.

James

[toc] | [prev] | [next] | [standalone]

#9128

On Sat, 16 Jan 2016 16:50:12 +0000
James Harris <james.harris.1@gmail.com> wrote:

> On 10/10/2015 03:18, Rod Pemberton wrote:
> > On Fri, 09 Oct 2015 05:50:47 -0400, Alexei A. Frounze
> > <alexfrunews@gmail.com> wrote:  
 
...

> >> Even if you think that something like Python isn't a
> >> serious language (it has plenty of shortcomings) or isn't
> >> going to stay, useful things get done in it and it's
> >> much easier to write in it than in C because the language
> >> is richer and there's quite a bit of stuff in its library,
> >> which has no match in the standard C library. Of course,
> >> not all richness is necessary or very useful, but some
> >> is.  
> >
> > I've not used Python, AFAIR.  IIRC, it's converted to C.  
> 
> Python is normally converted to bytecode. You can compile text to 
> bytecode and disassemble that bytecode to see what it does. For
> example, the following python code compiles a simple assignment and
> disassembles the resulting bytecode.
> 
>    import dis
>    x = compile('a = 1', '', 'single')
>    dis.dis(x)
> 
> The result is this disassembly:
> 
>    0 LOAD_CONST               0 (1)
>    3 STORE_NAME               0 (a)
>    6 LOAD_CONST               1 (None)
>    9 RETURN_VALUE
> 
> > For anything which is converted to C, one must ask why
> > not just use C in the first place?  That includes just
> > about every language in existence, since they've all
> > emitted C code or were written in it at some point.  If
> > someone doesn't have a good justification as to why to
> > not use C, which they usually don't when asked that,
> > then I see no point in them using another language.  
> 
> Python does make some things very easy to write (as above) but it is
> not suitable for everything. As you can see from the bytecode it
> would be much slower than C, for example.

That depends.  If the bytecode is interpreted, then, yes, it'll
be slow.

If it's compiled at some point, then it can be fast.  I.e.,
I have programs to convert indirect-threaded code (ITC) Forth
and TLTJHTNO(*) to C, some slightly optimized, which compiles
fine and executes quickly, but perhaps not as quickly as if
written natively in C.  ITC and DTC are similar to bytecode
(a.k.a. TTC or token-threaded code) in the sense that they
group the language into a bunch of procedures or routines.

(*)The Language That James Hates the Name Of
Close your eyes James, the rest is for Alexei, if he ever
responds ...

[TLTJHTNO is BrainFuck.]


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.os.development

csiph-web