Eh, any sufficiently large or complex codebases will get ridiculously long names at some point. Here are some from a famous C API (Windows):

    CoMarshalInterThreadInterfaceInStream

    D3D12_GPU_BASED_VALIDATION_SHADER_PATCH_MODE_UNGUARDED_VALIDATION 

    RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext

Or how about:

    GtkColorSelectionChangePaletteWithScreenFunc

The alternative is things having names that aren't actually descriptive at all, which is not clearly better.

Or have a good package system... If you use a language with import with aliases, you don't need all that noise.

Java has such a system but people write long class names anyway, because people don't like to have too many types with identical names distinguished only by namespace. You can do it but it's a bit questionable to what extent you should.

But how else will your app automatically detect and inject its enterprise LangDetectLanguageIdentifierConfligurator at startup?

I just got some flashback reading that long string, and my heartbeat raised. The namespacing system is also a nightmare

Com.prout.shit.lol...

Namespacing in reverse dns order is something Java got right. It naturally segments things and you can immediately see the relative provenance of classes.

It’s just impossible to use without editor support. Nobody who cares for their sanity can type out those package names manually. I think even Gosling said as much.

Just trying to find files relevant to some functionality is incredibly difficult without full-text searching all the files. Namespacing is fine but why must the entire path be reflected in directory structures?

To prevent half assed refactoring in the first place where only namespaces and classes get refactored while folders and filenames remain as they were. It would just further confuse new devs on the project.