"Small C++" Anyone?

[JohnQ]

I note the use of the future tense "would be"
Ok, letsd try this. We'll start off with the same requirements.
Ill use C++, you can use Small C++.
We'll see who finishes first. I'll admit I have an advantage in that my
language and compiler.....exists.

I fail to see your point. The thread is rationale for a new language.

Interesting that you find no other language in which you have reasonable
confidence that, given the specification, that the programmer will prodce
the desired result.

That's not the only criteria.

And I said that since C++ derives from C, and C is the one language I know
that has a contest whose purpose is to write obfuscated code, it seems
logical that Small-C++ would also "have obfuscation built in".

That sounds completely illogical to me. B does not obviously follow directly
from A.

So with C, no possibility of programmers writing obfuscated code. Only
with
C++ does obfuscation come into the picture?

C++ has more potential for obfuscation because it has more mechanisms and
exploitation of them seems to be encouraged.

Well, in the survey results I posted, they emphasised the "managed"
environment in reducing application complexity.

Implementation complexity of the compiler is where the 'complexity' word
entered this thread.

Yes, since there are machine architectures with 9-bit bytes.
Having the language with the flexibility to handle such architectures is a
good thing, IMO.

Unless you know you will never need that portability. Then it just serves to
make the compiler more complex (well, so I assume, but surely it makes the
programmer have to think more than is necessary about extraneous detail). If
it's not needed, not specified, it's "gold plating".

Uhm...."(And newbies do) use every nook and cranny in C++"?


And therein lies a problem.
If you have a header file, which allows the definition of templates in
Small-C++, then a developer will be able to use the same syntax.
Or will these headers be "marked" in some way which lets them use
templates,
but nothing else?

TBD.

John

 

[JohnQ]

BTW try this one with printf:

class SomeClass {
//..some stuff
};

SomeClass someObject;
printf("what '%' code should be placed here? ", someObject);

C++ IO is object oriented. It HAVE TO be, because if you can
create new data types, you should also be able to use it with
IO the same way as built-in types. With printf you can't, because
it has '%' codes only for built-in types.
There's another reason behind using iostreams instead of printf:
iostream output operators are matched at compile time and in a
machine code there'll be only calls for the proper functions to
handle only proper data types, and nothing else. OTOH printf
have to parse format string at run-time every time it's called,
and choose the proper branch of execution for the particular type.
All that branches will be there in executable even if you print
only one type in a whole program. In a case of iostreams, there
could be only the ones used [code of the operator<<'s for the
used types only].

In this day of the GUI, how much do you need Std IO anyway.

John, there are these neat things called "files".
They're a sequence of bytes sitting out on persistent storage.
InputFule >> MyObject;
OutputFile << MyObject;

There's no need for C++ IO though to read/write data. Just wrap the (better)
platform APIs into a nicer "std library".

Ok, so you'll avoid using standard genertic containers in place of what
you
write yourself.
And you think it'll be easier for new hires to use the ones you create as
opposed to the STL?

Definitely! There will be "Small C++ Standard Containers and Algorithms"
that are an improvement over STL containers/algos both in usage and in
implementation.

for my masters thesis, I implemented a C compiler for microprogramming.
I developed a couple of extensions to better handle the specifics for
microcode.
Took me about 6 months, using flex and bison.

Those tools are freely available.
Go for it.

I may be backing my way into something like that, but I doubt it unless I
could do it in a big way with funding, resources etc. A preprocessor might
be a better place to start. Having full control of the toolchain is
definitely lucrative. That's why I started this thread afterall.

John

 

[JohnQ]

It pretty much is everywhere.
Not so Java or C#.



And such a langauge can restrict itself out of existence.
Think of how many laguages that defined pointers as 16-bit addresses would
still be in use in desktop apps since we've moved into 32-bit years ago,
and
are now embracing 64-bit.


Ok, so why do you use it?

Because it is the closest thing to what I want in a language. It's drifting
more and more away though. What was once even thought to be "all I ever
wanted in a language" now leaves me longing for something better based upon
lessons learned over the years. C++ can't evolve to be that replacement
because it is encumbered by backward compatibility and is now decidedly too
broad. (Or something like that).

Uhmm...about Small-C++?

You mean more specific than everything already said in this thread? (!).
LOL. If I was more specific, I'd be writing a specification already!

Ahh..so someone having difficulty with "int" and float" would find them
immediately accessible if they know that both are 32-bit?

I was talking about ints.

So you have int as 32-bit exclusively,

No, I didn't say that. I said you have guaranteed width integers and a byte
is 8 bits.

then it performs poorly on 16-bit
CPUs compared to ones that use the "native type".


Go for it.

I'm not sure that is plausible for me to do it. Needs more research. If I
pick up on more and more of the concepts as time goes on, before anyone else
makes the thing, I just might do it. It's probably harder than I care to get
into though. It would be a great job for someone already skilled in
compiler/tool development.

It's much easier for a bad coder. But [like Dennis mentioned
already]
for a bad coder it's possible in any language.

He was off topic at that passage in his post. Yes, a logic error.

Off-topic? You're complaining that C++ features lead to unmaintainable
code,
I point out that its possible to do this in any lanaguage, including C,
and
you think this is a logic error?

Yes, because he confused "the possibility of" with "the probability of". He
was pointing out the former while I was talking about the latter.

Ahh...so you think a given deveoper has a lower probability of writing
obfuscated code in C, vs C++?

Yes.

It does though. Just not in an evolved or complete form. EC++ could be said
to be a "Small C++" of sorts, for instance. A strict subset to start
from.
Then add a few ingredients, change some (8-bit bytes anyone?) and voila!

Ok, so there ya go.
Have fun

It could happen, maybe.

Yeah, probably so.


No, the states. You?
Same.


Well , best get started on it.

At least I'm thinking about it.

John

 

[Bo Persson]

JohnQ wrote:
:::
::: Well, programming itself is "hard".
::
:: Well it doesn't have to be. I mean, that would be a goal of "Small
:: C++": programming doesn't have to be so hard. From the get go, if
:: the new programmer could rely on an 8-bit byte and integer types of
:: specific widths exclusively, just that would help propel someone to
:: productivity with a language faster. type.h is probably where I'd
:: start if I was to start laying out "Small C++": a standard set of
:: integer types of guaranteed width and no nebulous integer types (no
:: "is 32 bits on a 32 bit machine, 64 bits on a 64 bit machine" etc.).

Why is having a certain number of bits in an integer so good?

If you use it as a counter for number of objects (like characters), isn't it
EXTREMELY good that it is 16 bits on 16-bit hardware, 32 bits on 32-bit
hardware, 36 bits on 36-bit hardware, and 64 bits on 64-bit hardware?

Not too big, not too small, but just right!


Just consider if we were to specify 9-bit bytes, 36-bit ints, and 72-bit
floating point for everyone, just because some machines look like that.




Bo Persson

 

[Bo Persson]

JohnQ wrote:
:::
::: Yes, since there are machine architectures with 9-bit bytes.
::: Having the language with the flexibility to handle such
::: architectures is a good thing, IMO.
::
:: Unless you know you will never need that portability. Then it just
:: serves to make the compiler more complex (well, so I assume, but
:: surely it makes the programmer have to think more than is necessary
:: about extraneous detail). If it's not needed, not specified, it's
:: "gold plating".

When you write a compiler for a machine with 8-bit bytes, you don't have to
care that someone else might be writing for 9-bit bytes, or 32 bit bytes.
There is no added complexity for you!

On the other hand, if you specify 8-bit bytes only in your language, the
9-bit guy will be in A LOT of trouble. What do you gain from that?


Here is another example, where a supposedly "very portable" language
specifying a particular floating point format, requires VERY expensive
hardware extensions on mainframes.

http://www-03.ibm.com/systems/z/zaap/



Bo Persson

 

[JohnQ]

JohnQ wrote:
:::
::: Yes, since there are machine architectures with 9-bit bytes.
::: Having the language with the flexibility to handle such
::: architectures is a good thing, IMO.
::
:: Unless you know you will never need that portability. Then it just
:: serves to make the compiler more complex (well, so I assume, but
:: surely it makes the programmer have to think more than is necessary
:: about extraneous detail). If it's not needed, not specified, it's
:: "gold plating".

When you write a compiler for a machine with 8-bit bytes, you don't have
to care that someone else might be writing for 9-bit bytes, or 32 bit
bytes. There is no added complexity for you!

Well I don't know that as I've never written a compiler.

On the other hand, if you specify 8-bit bytes only in your language, the
9-bit guy will be in A LOT of trouble. What do you gain from that?

Ease of writing internet protocols.

Here is another example, where a supposedly "very portable" language
specifying a particular floating point format, requires VERY expensive
hardware extensions on mainframes.

http://www-03.ibm.com/systems/z/zaap/

John

 

[JohnQ]

JohnQ wrote:
:::
::: Well, programming itself is "hard".
::
:: Well it doesn't have to be. I mean, that would be a goal of "Small
:: C++": programming doesn't have to be so hard. From the get go, if
:: the new programmer could rely on an 8-bit byte and integer types of
:: specific widths exclusively, just that would help propel someone to
:: productivity with a language faster. type.h is probably where I'd
:: start if I was to start laying out "Small C++": a standard set of
:: integer types of guaranteed width and no nebulous integer types (no
:: "is 32 bits on a 32 bit machine, 64 bits on a 64 bit machine" etc.).

Why is having a certain number of bits in an integer so good?

Inter-application communication. Portable data storage.

If you use it as a counter for number of objects (like characters), isn't
it EXTREMELY good that it is 16 bits on 16-bit hardware, 32 bits on 32-bit
hardware, 36 bits on 36-bit hardware, and 64 bits on 64-bit hardware?

No, not extremely. It's pretty trivial if you ask me.

Not too big, not too small, but just right!


Just consider if we were to specify 9-bit bytes, 36-bit ints, and 72-bit
floating point for everyone, just because some machines look like that.

I like 8-bit bytes and guaranteed-width integers. So does the internet.

John

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

cases. It's the more-is-more language. Small C++ is envisioned as the
less-is-more language.

In that case, you have already achieved your goal, because Small C++ is
nothing. Impossible to be less.

 

[Dennis \(Icarus\)]

I fail to see your point. The thread is rationale for a new language.

My point is that since C++ does not yet exist, not even as a specification
that can be evaluated, its difficult to evaluate its feature set and
difficult to have reasonable confidence that, given the specification, the
programmer will produce what was envisioned.

That's not the only criteria.

That is what I asked about though.

That sounds completely illogical to me. B does not obviously follow directly
from A

Perhaps this will help?
http://en.wikipedia.org/wiki/Obfuscated_code
Obfuscated code is source code that is (usually intentionally) very hard to
read and understand. Some languages are more prone to obfuscation than
others. C, C++ and Perl are most often cited as easily obfuscatable
languages.

Unless you know you will never need that portability. Then it just serves to
make the compiler more complex (well, so I assume, but surely it makes the
programmer have to think more than is necessary about extraneous detail). If
it's not needed, not specified, it's "gold plating".

Well....I have implemented a compiler and I tell ya, byte size was not a
concern at all.

<snip>
Dennis

 

[Dennis \(Icarus\)]

Because it is the closest thing to what I want in a language. It's drifting
more and more away though. What was once even thought to be "all I ever
wanted in a language" now leaves me longing for something better based upon
lessons learned over the years. C++ can't evolve to be that replacement
because it is encumbered by backward compatibility and is now decidedly too
broad. (Or something like that).

Backward compatibility is important, but there have been times that its been
ignored.
Make a strong enough case at the standards committee and.......

You mean more specific than everything already said in this thread? (!).
LOL. If I was more specific, I'd be writing a specification already!
Yes.


I was talking about ints.
Yes.


No, I didn't say that. I said you have guaranteed width integers and a byte
is 8 bits.

I realize that, I was using an example. Note the comma as opposed to a
period.

So what is the guaranteed width?
Some compilers already provide as an extenson __int16, __int32, __int64,
etc.

I'm not sure that is plausible for me to do it. Needs more research. If I
pick up on more and more of the concepts as time goes on, before anyone else
makes the thing, I just might do it. It's probably harder than I care to get
into though. It would be a great job for someone already skilled in
compiler/tool development.

Well, one of your goal was to make Small-c++ easy for anyone to implement.

It could happen, maybe.

Good luck.

At least I'm thinking about it.

Yep.

Dennis

 

[Dennis \(Icarus\)]

news:[email protected]...

There's no need for C++ IO though to read/write data. Just wrap the (better)
platform APIs into a nicer "std library".

There is a need for C++ IO. The current system allows classes to serialize
themselves.
What are your thoughts on implementing a replacement?

Definitely! There will be "Small C++ Standard Containers and Algorithms"
that are an improvement over STL containers/algos both in usage and in
implementation.

And how will they be improved in both usage and implementation?

I may be backing my way into something like that, but I doubt it unless I
could do it in a big way with funding, resources etc. A preprocessor might
be a better place to start. Having full control of the toolchain is
definitely lucrative. That's why I started this thread afterall.

Dennis

 

[JohnQ]

I fail to see your point. The thread is rationale for a new language.

My point is that since [Small] C++ does not yet exist, not even as a
specification
that can be evaluated, its difficult to evaluate its feature set and
difficult to have reasonable confidence that, given the specification, the
programmer will produce what was envisioned.

Well given that that is a goal of the new language, where it was not so with
C++, some bit of assumption can be made.

That is what I asked about though.

I see no question in there.

Perhaps this will help?
http://en.wikipedia.org/wiki/Obfuscated_code
Obfuscated code is source code that is (usually intentionally) very hard
to
read and understand. Some languages are more prone to obfuscation than
others. C, C++ and Perl are most often cited as easily obfuscatable
languages.

Trying to write obfuscated code and doing it inherently because of the
popular usage of the language constructs are entirely different animals.

Well....I have implemented a compiler and I tell ya, byte size was not a
concern at all.

Good then, maybe that can stay.

John

 

[JohnQ]

There is a need for C++ IO. The current system allows classes to serialize
themselves.

There's more than one way to skin a cat.

What are your thoughts on implementing a replacement?

I'm don't think it is a primary concern at the outset. IO tends to be
application-specific.

And how will they be improved in both usage and implementation?

You'll have to wait and see.

John

 

[JohnQ]

Backward compatibility is important, but there have been times that its
been
ignored.
Make a strong enough case at the standards committee and.......

It sounds easier just to create a new language for new development where a
codebase does not exist. Why deal with politics if you don't have to? Also,
C++ is obviously on an expansion-of-features path. I don't foresee any
feature being removed ever, so the compiler system development capability
(toolchain) for C++ will only be possible with millions of dollars of
development or equivalent resources. Perhaps it's idealistic to think that a
powerful-enough language could be developed that keeps toolchain development
accessible to the masses, but I for one think that it may be possible.
Whether it is worth my time or not is another story.

Yes.

Well you know what they say about million dollar answers: they cost a
million dollars!

I realize that, I was using an example. Note the comma as opposed to a
period.

Well an extraneous scenario then.

So what is the guaranteed width?
Some compilers already provide as an extenson __int16, __int32, __int64,
etc.

I'm suggesting that only guaranteed width integers should be available to
avoid confusion about what happens from platform to platform. (Though I
haven't completely decided that a platform-specific-width integer is a bad
idea). Perhaps another simplification would be to have only signed integer
types.

Well, one of your goal was to make Small-c++ easy for anyone to implement.

Being the first to pick from the existing patterns and techniques, etc.
would be the hard part and someone already on top of compiler/tool building,
assuming they had the right practicality for the job, could avoid most of
the startup research. Showing someone how and why after the fact would be
the easy part.

John

 

[JohnQ]

In that case, you have already achieved your goal, because Small C++ is
nothing. Impossible to be less.

It's a (fuzzy) vision. Time is making it clearer though. It's a concept (a
set of them) yet to be proven. It may become more lucrative as C++ expands
with features to fill the universe and the compilers become big plates of
spaghetti maintained by a very few multi-million dollar projects/companies.

John

 

[JohnQ]

<snip>

So in what language(s) do you think its easy to have reasonable
confidence
that, given their specification, the programmer will produce what
was
envisions (vs what was written in the spec?)

Small C++! Why? Because thought would be given to the feature set,
much
moreso than it was with C++, to ensure it was harder to "shoot your
whole
foot off" or even shoot yourself in the foot.

I note the use of the future tense "would be"
Ok, letsd try this. We'll start off with the same requirements.
Ill use C++, you can use Small C++.
We'll see who finishes first. I'll admit I have an advantage in that my
language and compiler.....exists.

I fail to see your point. The thread is rationale for a new language.

My point is that since [Small] C++ does not yet exist, not even as a
specification
that can be evaluated, its difficult to evaluate its feature set and
difficult to have reasonable confidence that, given the specification, the
programmer will produce what was envisioned.

Well given that that is a goal of the new language, where it was not so with
C++, some bit of assumption can be made.

I'm sure you remember what happens when you assume.

"assume" was a bad word then. Theorizing would be better. It's not like I'm
pulling all of this out of thin air. There are reasonable goals and
directions for further investigation and prototyping.

It was above.
So in what language(s) do you think its easy to have reasonable confidence
that, given their specification, the programmer will produce what was
envisions (vs what was written in the spec?)

Small C++.

And C allows one to write obfuscated code due to popular usage of the
language constructs.

There are more mechanisms in C++ hence more possibility for obfuscation.
Just the "template obfuscation machinery" should be enough proof of that.
(Of course I am using "obfuscation" to mean "incomprehsible/unmaintainable"
at worst, or "hard to understand" at best).

John

 

[JohnQ]

Oh, I think it'd be a pretty important consideration.

It's at the library level rather than the language proper level. Foundations
first. Higher level things afterwards. For the most part.

 

[Dennis \(Icarus\)]

<snip>

So in what language(s) do you think its easy to have reasonable
confidence
that, given their specification, the programmer will produce what
was
envisions (vs what was written in the spec?)

Small C++! Why? Because thought would be given to the feature set,
much
moreso than it was with C++, to ensure it was harder to "shoot your whole
foot off" or even shoot yourself in the foot.

I note the use of the future tense "would be"
Ok, letsd try this. We'll start off with the same requirements.
Ill use C++, you can use Small C++.
We'll see who finishes first. I'll admit I have an advantage in that my
language and compiler.....exists.

I fail to see your point. The thread is rationale for a new language.

My point is that since [Small] C++ does not yet exist, not even as a
specification
that can be evaluated, its difficult to evaluate its feature set and
difficult to have reasonable confidence that, given the specification, the
programmer will produce what was envisioned.

Well given that that is a goal of the new language, where it was not so with
C++, some bit of assumption can be made.

I'm sure you remember what happens when you assume.

Heck, I could say that I have a goal for NewC++ where it'd be impossible to
express an incorrect program.
Everything would be caught at compile time.
Doesn't mean it'd happen.

There's a difference between "goal" and what's achieved.

I see no question in there.

It was above.
So in what language(s) do you think its easy to have reasonable confidence
that, given their specification, the programmer will produce what was
envisions (vs what was written in the spec?)

Trying to write obfuscated code and doing it inherently because of the
popular usage of the language constructs are entirely different animals.

And C allows one to write obfuscated code due to popular usage of the
language constructs.

Dennis

 

[Dennis \(Icarus\)]

There's more than one way to skin a cat.
Indeed.

I'm don't think it is a primary concern at the outset. IO tends to be
application-specific.

Oh, I think it'd be a pretty important consideration.

You'll have to wait and see.

Uhmm....ok.

Dennis

 

[Bo Persson]

Dennis (Icarus) wrote:
:: :::
::: :: <snip>
:::
:::
::: There's no need for C++ IO though to read/write data. Just wrap the
::: (better) platform APIs into a nicer "std library".
::
:: There is a need for C++ IO. The current system allows classes to
:: serialize themselves.
:: What are your thoughts on implementing a replacement?

If you have binary compatibility across all implementations on all hardware,
the rest will be simple.

I think that's what John is looking for.


Bo Persson