Re: Why use C++?

["Jed" <jehdiah@orbitway.net>]

Dmitry A. Kazakov wrote:
> On Sat, 13 Aug 2011 02:53:32 -0500, Jed wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1gu6ni1yb54k3$.4nbvfqqndl8m$.dlg@40tude.net...
>>> On Fri, 12 Aug 2011 14:06:55 -0500, Jed wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>> news:fwnlcp4mgj03$.1tjeqjtos00o8$.dlg@40tude.net...
>>>
>>>>> I want the type semantics specified. C/C++ int is neither lower
>>>>> level nor closer to the machine it is just ill-defined. The
>>>>> concern is this, not its relation to the machine, of which I (as
>>>>> a programmer) just do not
>>>>> care.
>>>>
>>>> What more definition do you want?
>>>
>>> More than what? I see nothing.
>>
>> The semantics of C++ types are specified.
>
> By the word "int"?

By "specified", I mean "you know what to expect" (being, you have not a 
guarantee).

>
>>>> Size guarantee?
>>>> Other than that, what
>>>> is ambiguous (platform-specific) about C++ int?
>>>
>>> That is one of the meanings of ill-defined.
>>
>> Don't use it.
>
> Which was the point.

Consider it ancillary, for there are other integer types. Singling out 
int is a strawman, for while it is a failure, it is not the only avenue 
in the language.

>
>>> BTW, if you aim at this application domain, note endianness and
>>> encoding stuff. You have very little chance that int is the type
>>> the protocol or hardware uses.
>>
>> Picking on int?
>
> int, long, unsinged represent an example of wrong language design.

I agree (did you mean in C++, or in general?). I have a feeling you meant 
in general. In that case, again, I'm not sure that having some of those 
monikers isn't the best compromise.  You know, the 80% rule.

>  The
> point was that the semantics of an [integer] must be derived from the
> application domain.

Maybe it's good enough in a lot of instances. Say, a memory address. 
32-bit unsigned address works nicely (on a 32-bit machine). Ah, but you 
are going to say that that is just convenient coincidence. You could be 
right. I'm not sure at this point. Again, purest approach vs. practical 
compromise is the issue.

>
>>> In each such case I will have to use a type different from the
>>> machine type. This is just another argument why types need to be
>>> precisely specified. I addressed this issue above.
>>
>> But they are precisely specified on any given platform.
>
> 1. They are not. In order to see the specification of int, you have
> to read the compiler documentation.

"platform" = hardware + OS (if there is one) + compiler.

> My point was that the program
> code does not specify the properties of int.

And I'm saying, maybe ("maybe" is a key word here) that is just a purist 
approach and not better than practical compromise.

> The answer that it is
> defined somewhere somehow is not an argument at all, anything works
> in this or that way.

Who's arguing? First of all, I wouldn't use int, but if I did, I would 
know what "int" was. Everything does not require cross-platform 
portability.

>
> 2. I don't care about the platform, I care about what the program is
> supposed to do.

Another way to skin the cat: write to a virtual machine. Java. .Net. Your 
own.

> The type's properties shall be defined by the application domain.

If you say so, but that is maybe too much effort for too little gain. 
TBD.

>
>>> Just another layer of
>>> abstraction above states of the p-n junctions of some transistors.
>>> Do you care?
>>
>> At some level, I care, yes. At that level, no. I'm not against your
>> proposal, I just don't know the scope of it. I have a feeling that
>> going to the level you are calling for is what would say is "an
>> exercise" instead of practical engineering. Just a feeling though,
>> mind you. Tell me this, how close is Ada (and which one) to your
>> ideal? All I know about Ada is what I've read about it. Maybe I
>> should write some programs in it.
>
> Ada is close, but not close enough. It is light years ahead of C++
> concerning numeric types, so the problems with Ada might be difficult
> to understand for a C programmer. Ada puts too much magic into
> numeric types. I would prefer less. Ada lacks numeric interfaces
> abstracted away. Ada lacks mapping of classes of numeric types onto
> proper types. [There are classes, but no objects] Exceptions are not
> contracted. Too many things required static. Other things are dynamic
> while should have been static, etc.

I guess I'll just have to wait and try this other language when you are 
done implementing it. ;)?

>
>>>>>>> (The way compiler would implement that type is uninteresting,
>>>>>>
>>>>>> Ha! To me that is KEY.
>>>>>
>>>>> This is not a language design question. It is a matter of compiler
>>>>> design targeting given machine.
>>>>
>>>> Oh? I've been having a language design discussion (primarily).
>>>
>>> Then that cannot by any means be a key issue.
>>
>> That's opinion, not fact.
>
> It is a conclusion from the fact that we were discussing language
> design issues rather than code generation problems.

Language design includes foresight into the implementation. Else it's 
just pondering some theoretical ideal. Academic research vs. practical 
engineering.

>
>>>>> Why should you? Again, considering design by contract, and
>>>>> attempt to reveal the implementation behind the contract is a
>>>>> design error. You shall not rely on anything except the contract,
>>>>> that is a fundamental principle.
>>>>
>>>> While that paradigm does have a place, that place is not
>>>> "everywhere".
>>>
>>> Where?
>>
>> The formality of "design by contract" as used in developing
>> functions/methods.
>
> That is a procedural view on software developing [a very outdated one,
> IMO].

No it is not. Classes have methods. (I'm surprised you even said that).

>
> But design by contract is a mere engineering principle,

And a bit more. I always took it as a paradigm associated with a specific 
product (Eiffel). As a matter of fact, I felt kind of "irked" when it was 
presented as "something new" for before that, it was engineering 
technique. I mean, "it's like.. the function/method specification is a 
"contract"... blah, blah", well, duh! But, I digress.

> it applies
> absolutely everywhere in engineering. If you disagree, please, show
> examples.

That's what I meant by saying you can choose to use the terminology in a 
general way, to which I "retort", "well, duh!". Statements of the 
obvious, so what?

>
> [I don't mean here Meyer's notion of DbC, which is largely wrong, IMO]

When I see "Design by Contract", my mind automagically puts a "tm" after 
it. Not that I'm knocking anything.

>
>>>> Well then, if wrapping is OK, what else is needed and why?
>>>
>>> Wrapping is an implementation, the question is WHAT does this
>>> implementation actually implement?
>>
>> I was just asking why you find that inadequate such that something
>> (largely more complex?) is needed.
>
> Hmm, then I didn't understand your question.

The whole time, I've been trying to get a handle on this "nebulous" (to 
me) ideal language of yours and how it differs from "the low hanging 
fruit" of traditional language design and implementation. I furthered 
saying that I have a feeling you are seeking some "purist" ideal or 
something for comp sci labs in academia. That's about it.

>
>> Oh, you were thinking something else when I wrote: "Can that be
>> achieved? At what degree of complexity?". I asked if creating your
>> ideal language (this "definitively specified higher level" language)
>> is feasible and if so, what does that do to the complexity of the
>> implemenation (compiler)?
>
> I think it should make the compiler simpler.

Do explain please. I can appreciate that in the abstract things look 
rosey, but the devil is always in the details. One can design the perfect 
bridge, but the problem is that landscapes are never perfect.

> Implementation of the RTL is a different issue.

>
>> Is a comparison of Ada and C++ pretty much that answer?
>
> As a matter of fact, since I partially did both, to compile Ada is way
> simpler than to compile C++.

That's not saying much of anything. Compare it to C.

>
>>> Contract specifications. "int" is not a contract.
>>
>> Does Ada meet your desired requirements?
>
> Ada is the closest existing approximation.

I wonder if there is more to discover in using it than just reading about 
it. I think it has this "module as class-like thing" that seems so 
archaic, so I would fight it at every step of coding, so maybe I'll stick 
to just reading more about it.