"Small C++" Anyone?

[Bo Persson]

JohnQ wrote:
:: ::: 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.

You get that by specifying the communications protocol, and the data storage
format.

Not by forcing everyone else to use you favorite format.

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

But that's at the network interface layer. The 9-bit machine will have to
convert to and from the proper protocol. Not a problem, as network transport
is much slower anyway.

But when I do some computations on my 36-bit machine, I want to be ALLOWED
to use 36-bit ints and 72-bit doubles. If the language says that it MUST
ALWAYS be 32-bit and 64-bit, I'm toast.

With Java, that is the case. With C++, it is not. I see that as a advantage!


Bo Persson

 

[Dennis \(Icarus\)]

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

But, as yet, since nothing as yet exists, you can't really say whether it
will or not.

Small C++.

I find it interesting that you think a hypothetical, non-existent language
gives you reasonable confidence that ,given their specification, the
programmer will produce what was envisioned, and NO other language.

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

Then by that logic, a Small-C++ programmer has a higher proability of
writing obfuscated (incomprehensible/unmaintainable/hard to understand) code
since it will have more mechanisms than C. Or will it?

Dennis

 

[Dennis \(Icarus\)]

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.

Well, the key thing is that these features aren't being added just for the
sake of change
They're being requested because they fill a need.

I find it interesting, also, that the one language you think gives
"reasonable confidence that, given their specfication, the programmer will
produce what was envisioned".....may not be worth your time?

Well an extraneous scenario then.

John, it was your scenario - I just picked the specific width.

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.

That wouldn't be a good thing.

<snip>

Dennis

 

[Dennis \(Icarus\)]

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

Given that object-oriented programming tries to hide object details.
They know how to create (initialize), copy, assign, clean up, it seems
logical that the i/o mechanism would be a "foundation" issue.
Given that you're not fond of C++'s stream mechanism and <<, >> (gained
through operator overloading), you'd need to have a means for doing so.
After all, if you want a clearer token to set as an i/o operator, that'd be
part of the language.
If you keep the idea of operator overloadig, then that's anothr item that
can lead to "obfuscated code".

Dennis

 

[JohnQ]

But, as yet, since nothing as yet exists, you can't really say whether it
will or not.

I can make some deductions from my own libraries.

I find it interesting that you think a hypothetical, non-existent language
gives you reasonable confidence that ,given their specification, the
programmer will produce what was envisioned, and NO other language.

I like C++ though overall. Why would I look at another language when I've
looked at them already and made the choice to go with C++ over them?

Then by that logic, a Small-C++ programmer has a higher proability of
writing obfuscated (incomprehensible/unmaintainable/hard to understand)
code
since it will have more mechanisms than C. Or will it?

The goal is to create mechanisms that aren't exploitable if possible.
Templates started out as simple text replacement and evolved into
incomprehensibility as sometimes applied.

John

 

[JohnQ]

Given that object-oriented programming tries to hide object details.
They know how to create (initialize), copy, assign, clean up, it seems
logical that the i/o mechanism would be a "foundation" issue.
???

Given that you're not fond of C++'s stream mechanism and <<, >>

I'm not fond of operator overloading or operators in general, such as >>/<<.

(gained
through operator overloading), you'd need to have a means for doing so.

I still see it (IO) as a library issue.

After all, if you want a clearer token to set as an i/o operator, that'd
be
part of the language.

Again, I doubt I would assign an operator(s) for IO.

If you keep the idea of operator overloadig, then that's anothr item that
can lead to "obfuscated code".

Like I said, I'm not fond of operator overloading or operators in general.
They make code (other than numeric code) hard to grok. Especially overloaded
operators.

John

 

[JohnQ]

Well, the key thing is that these features aren't being added just for the
sake of change
They're being requested because they fill a need.

C++: the "all things for all people" language. "One size fits all".

I find it interesting, also, that the one language you think gives
"reasonable confidence that, given their specfication, the programmer will
produce what was envisioned".....may not be worth your time?

Well, I can control my own code as I don't have teams of developers to
manage. In the future, that may change and I'll personally have the troubles
of any other manager faced with C++ development (although I can curb a lot
of the chaff by requiring use of in-house libraries, patterns, techniques
and such). There's already so many developers who have the required
knowledge to start prototyping "Small C++". Rather than getting directly
involved with the nitty gritty low level compiler design details, I'd rather
sanction it, as I have other things I'm involved with and want to continue
pursuing: I can't do everything.

John, it was your scenario - I just picked the specific width.

Your's was a different scenario. I'm not sure what your point was/is. I just
said that having guaranteed width integers exclusively sounds like a
lucrative simplification and that it could produce productive programmers
faster.

That wouldn't be a good thing.

Why not? One less choice to be faced with at every integer type selection.

John

 

[JohnQ]

JohnQ wrote:
:: ::: 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.

You get that by specifying the communications protocol, and the data
storage format.

Not by forcing everyone else to use you favorite format.

It's consistency, not force. Use C++ if you like "portable to 9-bit
processors"-type generality. If you don't give a care about that level of
portability, use Small C++ and have a simply elegant life.

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

But that's at the network interface layer. The 9-bit machine will have to
convert to and from the proper protocol. Not a problem, as network
transport is much slower anyway.

But I don't care about 9-bit machines: I'm creating an 8-bit byte language
and relegating C++ to the fringe cases. Why penalize the common case for all
the special cases?

But when I do some computations on my 36-bit machine, I want to be ALLOWED
to use 36-bit ints and 72-bit doubles. If the language says that it MUST
ALWAYS be 32-bit and 64-bit, I'm toast.

Then use C++, as it handles all the special cases, and not Small C++.
Simple. Being able to rely on 8-bit bytes, and unpadded structures, sounds
beautiful to me.

With Java, that is the case. With C++, it is not. I see that as a
advantage!

John

 

[JohnQ]

And, I suspect that, were Small-C++ created, standardized, it too would
grow, and expand, becoming the very thing you dislike.



Uhm....because a variable's value represetns something, and if that
something can never be negative, its better to use unsigned.

I default to using unsigned ints though too. It's pretty trivial. I'm OK
with it either way. It does show though how everything would be reevaluated
for selection or exclusion in Small C++.

John

 

[Dennis \(Icarus\)]

C++: the "all things for all people" language. "One size fits all".

And, I suspect that, were Small-C++ created, standardized, it too would
grow, and expand, becoming the very thing you dislike.

Why not? One less choice to be faced with at every integer type selection.

Uhm....because a variable's value represetns something, and if that
something can never be negative, its better to use unsigned.

Dennis