Riesco a vedere da dove provengono, ma come regole direi che sono troppo specifiche per una restrizione del 100% in una progettazione linguistica.
Gli schemi di eredità contorti giganteschi di livello 18+ sono piuttosto consolidati come un anti-pattern, ad esempio, ma l'ereditarietà di 1-3 livelli può essere perfettamente ragionevole per risolvere determinati problemi a seconda di ciò che consente un linguaggio diverso.
Allo stesso modo, è abbastanza facile vedere come l'overloading dei metodi potrebbe essere fatto in eccesso, rendendo così un'API eccessiva che dovresti controllare i documenti ogni volta solo per capire come usare un metodo per uno dei 16 modi hai davvero bisogno che funzioni. Mentre, usato responsabilmente, è abbastanza facile vedere come il sovraccarico per tipi simili nello stesso schema potrebbe essere del tutto ragionevole e per nulla difficile da ricordare. Questo, ancor più che la questione dell'ereditarietà, mi sembra una strana caratteristica di restringere il mercato all'ingrosso. Ma, piena rivelazione: mi sento a mio agio con un paradigma in cui tutto è mutabile, non devi dichiarare un metodo due volte per sovraccaricare i suoi argomenti, e le funzioni di prima classe piovono da ogni parte come caramelle da un ladro- open pinata.
Detto questo, solo perché non mi piace, non significa che le lingue non siano valide per essere altamente restrittive. Java per esempio (come ho capito) è essenzialmente una risposta progettuale al problema del codice C / C ++ tendente a consentire un controllo così granulare che può essere molto difficile per due sviluppatori capire il codice dell'altro. Il conservatorismo / protezionismo intrinseco di Java consente a molti più sviluppatori di lavorare insieme sullo stesso progetto pur avendo meno problemi a capire su cosa sono gli altri sviluppatori, perché, per esempio, tutto deve assolutamente essere in una classe. E non ottieni cose come dei puntatori che sono certamente potenti, ma possono anche facilmente trasformare un codice in un incubo risveglio in mani mediocri. Potrei obiettare che la maggior parte delle volte avere un sacco di sviluppatori in primo luogo è un suo problema, ma non direi che questo non è mai una necessità o che starebbero sempre meglio con la flessibilità dinamica di JavaScript o il controllo granulare close-to-chrome di C ++.
Direi comunque che un linguaggio generico dovrebbe probabilmente essere più flessibile di Java, ma non è detto che il 75% di Stack probabilmente sia d'accordo con me su necessariamente.
Le lingue sono intrinsecamente legate ai compromessi di design. Ciò a cui tutto ciò si riduce veramente è come ti sei venduto alla filosofia in termini di risoluzione dei problemi che tipicamente devi risolvere. In questo caso, penso che siano stupidi per la stragrande maggioranza dei problemi che ho dovuto risolvere personalmente, ma la maggior parte di questi sono elementi dell'interfaccia utente web.