Ви хочете сказати, що без DBA на проекті завжди ігнориться "використання SQL" чи я невірно зрозумів, Вас? Якщо, Ви дійсно так вважаєте, то цікаво, з чого у Вас такі висновки? 

Знову ж повторюся, або я Вас невірно зрозумів, або... Явно не джавісти (пхпшники чи ...) визначають доцільність наявності певних персон на проекті, а трішки інші люди. Тому мені якось важко зрозуміти дане висловлювання. 

Це щось схоже з тим, як люди ставлять клеймо на інших людях не знаючи їх особисто. Тобто, якщо єврей, то ..., якщо темношкірий, то ... і тд. Я вже колись, Вам відписував щодо Вашої згадки про "хороших" джавістів. Тобто, якщо людина, скажімо так, знає, що робить, то чи це джавіст, сішник, пхпшник, ... немає ніякого значення. Тому, якщо спеціаліст, який є на проекті дійсно спеціаліст, то він має розуміти плюси та мінуси використання певного фреймворка + розуміти, в якій ситуації, що та як саме, краще використати.

Я теж на проектах і тд. зустрічаю певних людей, які говорять "дивні речі". Але це ж не означає, що всі інші програмісти, які використовують ті самі технології, такої ж думки.

Ну я такий висновок зробив з Вашого ж попереднього повідомлення:

Я не кажу що DBА буде зайвим (особисто я завжди ЗА, хоч звісно все залежить від проекту), але відсутність DBА, не означає, що всі "автоматично забувають про native SQL"

Справжній конкурент сів це Zig. Ось чому можна послуговуватися цією мовою та забути про мову асемблера(окрім зовсім системних функцій - перемикання режимів процесора чи взаємодія з зовнішніми пристроями)
https://ziglang.org/documentation/maste … thOverflow

Perl убила вузька спеціалізація й зависокий поріг входження. Прихід php, набагато простішого на старті, забрав у perl його нішу в веб-бекенді, а ще десь особливої ваги він не мав (shell-скрипти хіба що, які знаходяться в харчовому ланцюжку досить далеко від кінцевого комерційного споживача).

JS навряд чи помре так легко — забагато всього поверх нього набудовано. Так, це теж вузька спеціалізація, але весь веб-фронтенд будується на ньому (тоді як серверні скрипти — річ менш постійна, і там можлива конкуренція) — ЈЅ почувається повним монополістом в одній з найзатребуваніших галузей. Щоб помер ЈЅ, має померти веб (чи, принаймні, дуже змінитись). Так, теоретично, його можна ще поховати під рівнями надбудов, як асемблер, але в асемблера нема такої простоти освоєння, і його закопування було закономірним.

Python — ризик зникнення через втрату єдиної вузької ніші невеликий, але от ніші, де Python не має конкурентів, нема — це мова широкої спеціалізації, як і Java. В одних нішах він провалюється, інші продовжує захоплювати. А низький поріг входження робить його ще й популярною навчальною мовою (а отже, маємо вхосталь програмістів, які можуть на цій мові щось робити без додаткових витрат на перепідготовку). Так, колись він помре, але не схоже, що це буде миттєво. Хіба що розробники самої мови вирішать навіщось її спаскудити.

Це не ви на APL пишете вже не перший рік?...

(Аби отримати щось, треба щось віддати.
"Design tradeoffs — A situation where one attribute of a system or product is made less suitable by giving priority to another feature...
.... tradeoff - a balancing of factors all of which are not attainable at the same time.
....Engineering choices typically involve optimizing certain parameters, often at the expense of others.)