experchange > ada

Olivier Henley (11-02-18, 11:11 PM)
Hey,

These days, at my job, I integrate the C++ work of a colleague into a bigger product.

Developing alone, for months, he chose convenient name for his classes. Because they are not mandatory in C++ and because he did not need it, he did not used namespaces. Fair.

What do you think happened when moving the code into a MUCH larger C++ code base? It clashed, and a lot. It took hours to stitch things together, even adding a 'hacky halfbaked' namespace to lift the ambiguity.

I just want to recall that in Ada being forced to choose a package name for our units is a frustration/time/clarity saver. Integrating would have taken nothing.

Anyone arguing that enforcing explicit separation of code units is a waste of time or tutoring for bad programmers is plain wrong.

This is one of the many reasons why Ada, in the long run, kills it.

ohenley
Maciej Sobczak (11-05-18, 12:39 PM)
> I just want to recall that in Ada being forced to choose a package name for our units is a frustration/time/clarity saver. Integrating would have taken nothing.

Except when the original and target package names need to differ or are in a different package hierarchies. Or perhaps somebody decides that what was originally sitting alone in a cosy Utils package needs to be integrated within an already existing (and crowded) Our_Very_Complex_System.Utilities.Helpers.
Which, considering your assertion that the target is a MUCH bigger codebase, would be the case almost certainly.

> Anyone arguing that enforcing explicit separation of code units is a waste of time or tutoring for bad programmers is plain wrong.


Yes.

> This is one of the many reasons why Ada, in the long run, kills it.


Unfortunately, no. Complex projects are complex in whatever language and code migration and integration are hard, for everybody.

Interestingly, the feature that allows C++ namespaces to exists in multiplefiles, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added to the project. In comparison (and in this context), Ada couples logic and physical designs, which is not always wanted.
Björn Lundin (11-05-18, 02:39 PM)
On 2018-11-05 11:39, Maciej Sobczak wrote:
> Interestingly, the feature that allows C++ namespaces to exists in multiple files, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added to the project. In comparison (and in this context), Ada couples logic and physical designs, which is not always wanted.


You can add procedures and function in separate files in Ada too
by using the 'separate' keyword.

And childpackages often help with hiearachies

--
Olivier Henley (11-05-18, 07:20 PM)
> Except when the original and target package names need to differ or are in a different package hierarchies.

I do not get this one?

> Or perhaps somebody decides that what was originally sitting alone in a cosy Utils package needs to be integrated within an already existing (and crowded) Our_Very_Complex_System.Utilities.Helpers.


I disagree.

1. 99% of the time, people have their own 'utils, math etc' that does exactly what 25 other 'projects' does and NOBODY tries or even care to merge into a cohesive 'utils, math etc' package.

2. Merging code under the same umbrella is tedious, cut, copy, paste, rename etc but not hard. At least it removes complexity. Keeping alive duplicate type naming through 'disfigure' mechanism is another story. C++ big projects are full of that.

> Which, considering your assertion that the target is a MUCH bigger codebase, would be the case almost certainly.


hundreds++ of visual studio projects.

> Unfortunately, no. Complex projects are complex in whatever language and code migration and integration are hard, for everybody.


The problem I had would have been easily solved in Ada. The guy would have named his code cathedral something like: eg. ConsultingCompanyCathedral.AnUsualTypeName and merging would have not clashed at all because since the beginning of times the official Matrix type would have been forcefully scopedeg. OurFlagshipProduct.Whatever.AnUsualTypeName

> Interestingly, the feature that allows C++ namespaces to exists in multiple files, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added to the project. In comparison (and in this context), Ada couples logicand physical designs, which is not always wanted.


You can argue/present it the way you want but stitching official, cast in stone, legacy types (not namespaced) that are visible everywhere + new public types declared inside classes + forward declare + anonymous namespace + partial implementation in .h files is a ****** nightmare. It is so convoluted that you end up fighting Visual Studio for the whole thing to compile under thousands of misleading errors so ... I fail to see where, practically, there is such thing as "C++ (...) makes the code migrations easier".

This I love: presenting the C++ capabilities conceptually 'sandboxed', forgetting that it exposes SO much potentially 'skewed capabilities' that facing the 'working, proper, clean context' for those capabilities to actually behave like expected is virtually impossible.

What you describe works fine with people sharing the same architectural conventions, with super good doc, with very tight knowledge of C++ exceptions to exceptions, with small code base, with same epoch code base. Once you toss some of those aspects out, to name a few, the whole thing becomes a madhouse.

Look. In real life, companies have to hire hundreds of C++ guys to push legacy or new stuff forward. We are either morons or there is an obvious problem with the tech, yours to choose.
Olivier Henley (11-05-18, 07:56 PM)
> Except when the original and target package names need to differ or are in a different package hierarchies.

I do not get this one?

> Or perhaps somebody decides that what was originally sitting alone in a cosy Utils package needs to be integrated within an already existing (and crowded) Our_Very_Complex_System.Utilities.Helpers.


I disagree.

1. 99% of the time, people have their own 'utils, math etc' that does exactly what 25 other 'projects' does and NOBODY tries or even care to merge into a cohesive 'utils, math etc' package.

2. Merging code under the same umbrella is tedious, cut, copy, paste, rename etc but not hard. At least it removes complexity. Keeping alive duplicate type naming through 'disfigure' mechanism is another story. C++ big projects are full of that.

> Which, considering your assertion that the target is a MUCH bigger codebase, would be the case almost certainly.


hundreds++ of visual studio projects.

> Unfortunately, no. Complex projects are complex in whatever language and code migration and integration are hard, for everybody.


The problem I had would have been easily solved in Ada. The guy would have named his code cathedral something like: eg. ConsultingCompanyCathedral.AnUsualTypeName and merging would have not clashed at all because since the beginning of times the official Matrix type would have been forcefully scopedeg. OurFlagshipProduct.Whatever.AnUsualTypeName

> Interestingly, the feature that allows C++ namespaces to exists in multiple files, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added to the project. In comparison (and in this context), Ada couples logicand physical designs, which is not always wanted.


Merging new clashing type names AND file names with cast in stone, legacy types (not namespaced) that are visible everywhere + some of those new typesdeclared inside classes + forward declare + heavy use of anonymous namespace + partial implementation in .h files happened to be a nightmare.

Sidenote: This I love. You are presenting the C++ capabilities conceptually'sandboxed', eluding the fact that it exposes SO much potentially interacting 'skewed capabilities' that facing the 'working, proper, clean context' for those capabilities to actually behave like expected is rarely, very rarely, the case.

What you describe works fine with people sharing the same architectural conventions, with super good doc, with very tight knowledge of C++ exceptions to exceptions, with small code base, with same epoch code base. Once you toss some of those aspects out, to name a few, the whole thing becomes ... IMO, a madhouse.

In real life, companies have to hire hundreds of C++ guys to push legacy and/or new stuff forward. I think we are either morons or there is an obviousproblem with the tech, yours to choose. I never worked with a huge Ada code base so I cannot pinpoint typical cases gone wrong, but the fact that things are "more square" and because I build and inspect relatively big open-source Ada project from time to time it appears to me that Ada is light years more truthful to help solving a practical goal at hand.
Simon Wright (11-05-18, 08:07 PM)
Olivier Henley <olivier.henley> writes:

> the official Matrix type would have been forcefully scoped
> eg. OurFlagshipProduct.Whatever.AnUsualTypeName


I'd have hoped it'd be called OurFlagshipProduct.Whatever.Matrix
Olivier Henley (11-05-18, 08:29 PM)
corrections:
.... the official AnUsualTypeName type would have been forcefully scoped eg. OurFlagshipProduct.Whatever.AnUsualTypeName.
Jeffrey R. Carter (11-05-18, 09:37 PM)
On 11/5/18 7:07 PM, Simon Wright wrote:
> I'd have hoped it'd be called OurFlagshipProduct.Whatever.Matrix


Ourflagshipproduct being unreadable, I'd have hoped for an Ada name:
Our_Flagship_Product.
Olivier Henley (11-05-18, 10:03 PM)
Follow up. A concrete example, one of many:

1. Atype exists in the core classes since the beginning of time.
2. Atype is redefined inside a local anonymous namespace.

This does not pass:

const Atype& var1 = _inst->getA(...);

Visual Studio gives 2 clues:

a. Atype --> is ambiguous.
b. getA signature --> <unnamed>::AType.

Ok a bit of SO to understand how to refer to that <unnamed>::Atype locally.

i. A guy propose to wrap the anonymous namespace with another named namespace.
ii. Another propose to use 'auto'.

I tried auto, it works.

Why do I find such solutions so dubious? Am I alone? Am I crazy?
Olivier Henley (11-05-18, 10:04 PM)
On Monday, November 5, 2018 at 2:41:14 PM UTC-5, Jeffrey R. Carter wrote:
> On 11/5/18 7:07 PM, Simon Wright wrote:
> Ourflagshipproduct being unreadable, I'd have hoped for an Ada name:
> Our_Flagship_Product.
> --
> Jeff Carter
> "You tiny-brained wipers of other people's bottoms!"
> Monty Python & the Holy Grail
> 18


Sorry. Will try better next time. :)
Olivier Henley (11-05-18, 10:12 PM)
On Monday, November 5, 2018 at 2:41:14 PM UTC-5, Jeffrey R. Carter wrote:
> On 11/5/18 7:07 PM, Simon Wright wrote:
> Ourflagshipproduct being unreadable, I'd have hoped for an Ada name:
> Our_Flagship_Product.
> --
> Jeff Carter
> "You tiny-brained wipers of other people's bottoms!"
> Monty Python & the Holy Grail
> 18


shipproduct is worst.
Olivier Henley (11-05-18, 10:40 PM)
Follow up. A concrete example, one of many:

1. Atype exists in the core classes since the beginning of time.
2. Atype is redefined inside a local anonymous namespace.

This does not pass:

const Atype& var1 = _inst->getA(...);

Visual Studio gives 2 clues:

a. Atype --> is ambiguous.
b. getA signature --> <unnamed>::AType.

Ok a bit of SO to understand how to refer to that <unnamed>::Atype locally.

i. A guy propose to wrap the anonymous namespace with another named namespace.
ii. Another propose to use 'auto'.

I tried auto, it works. I find all this dubious.
Maciej Sobczak (11-06-18, 10:52 AM)
> You can add procedures and function in separate files in Ada too
> by using the 'separate' keyword.


No. You need to edit the package spec to add subprogram declarations and then edit the body to introduce separate implementation and than, if you are not yet tired already, add new file to the project. Sounds like the worst option of all.

In C++ you can "reopen" the namespace by just introducing a new file, without editing existing files related to that namespace. This allows to decouple logical and physical aspects of namespace designs.

> And childpackages often help with hiearachies


Sometimes they force hierarchies when there is no design reason for them.
Olivier Henley (11-06-18, 03:02 PM)
> In C++ you can "reopen" the namespace by just introducing a new file, without editing existing files related to that namespace. This allows to decouple logical and physical aspects of namespace designs.

I agree that this is convenient. Is convenience in 'architectural elaboration' a good thing? I don't think so. The body of works exist to testify of the utter mess it can produce over the years.

But 'extension' through child package, present in the filename, is 'self documenting' in Ada. C++ namespace can be anywhere regardless of file naming.... often very confusing about what is tied to what. At directory level you cannot figure out the design layout. In Ada you can get pretty much the whole picture just from that inspection. This is huge for reasoning.

Maybe enforcing the explicit merging of designs in Ada is a very good thingin the long run. It forces the team members to take decisions early and dedicate to a real solution, one that they will live with. I know this could be very heavy at time and I can easily figure why some probably ditched Adajust because of such lack of convenience --> They just want to code.
Maciej Sobczak (11-07-18, 09:02 AM)
> But 'extension' through child package, present in the filename, is 'self documenting' in Ada. C++ namespace can be anywhere regardless of file naming... often very confusing about what is tied to what. At directory level you cannot figure out the design layout. In Ada you can get pretty much the whole picture just from that inspection. This is huge for reasoning.

Except that it is not enforced by the language. It is a (still not obligatory!) convention used with the GNAT compiler, which is the convention that Iappreciate, but it is not the achievement of Ada as the language. I have seen a relatively large Ada project (several thousand files), where for historical reasons file names have been forced to be 8 characters[*], which obviously did not have anything to do with package names that they specified or implemented. Reasoning in such a mess is just impossible.
[*] See the GNAT standard package files, too. Do you know the purpose of file that has name a-tiinau.ads? Or s-atacco.ads? Can you figure out the hierarchy from such names? There are almost 700 such files in my installation, all in a single directory.

The fact that you can *voluntarily* keep order in your Ada files is great, but remember that it is not Ada vs. C++ thing. There are enough good and bad examples in both.