Здравствуйте, Reset, Вы писали:

R>А есть такой язык, на котором можно писать сколько-нибудь сложный проект без опытных разработчиков?

Да, конечно есть: Go, Elixir, в какой-то степени Python.

R>ты уже давно не разработчик.

Да я сам не знаю кто я, но судя по названию позиции разработчик

Здравствуйте, vsb, Вы писали:

vsb>Подтверждается ли это практикой?

Подтверждается — новые проекты на Си начинают только в тех случаях, когда нет альтернатив, а старые и матерые Си проекты, к примеру GLib, городят свою правильную версию С++ — Vala.

vsb>Например код ядра Linux это C. Судя по тому, что Linux развивается уже 30 лет, в Linux контрибьютят самые разные люди, видимо на практике поддерживать этот код получается.

По моему не очень большому опыту с ядром, на плюсах там писать сильно более геморно чем на Си, при всех недостатках Си. Но вот тут

Автор: CreatorCray
Дата: 11.06.20

, со мной не согласны и я вполне допускаю что заблуждаюсь.

vsb>Предполагаю, что это можно квалифицировать, как С с классами?

Эту часть да, хотя в целом там код хороший.

Здравствуйте, kov_serg, Вы писали:
_>При переводе с одного языка на другой язык программа может перестать работать или потерять что-то или получить новые баги.
_>И кто сказал что преобрахование будет однозначным.
_><куча поскипанного>

Тогда это был бы не транспайлер, а плохая, негодная поделка-недоделка.
Имеющиеся в виду "первичные" языки заведомо сложнее и выразительнее "вторичных", а траспайлер должен преобразовывать код так же надежно и однозначно, как это делают обычные компиляторы.
Твои высказывания могут касаться только обратных транспайлеров из моего пункта 5, но они необязательны и вообще весь пункт сильно гипотетический.

_>Вообще есть haxe но он несколько для другого.

Действительно, для другого. haxe может транслироваться в кучу других языков, а для моего "первичного" вполне достаточно только одного "вторичного".

Ближе к моей схеме имеющиеся транспайлеры в C типа Nim -> C или тот же С++ -> C, или транспайлеры в JavaScript — много их.
Возможно, реально было бы сделать такие транспайлеры и для пар типа F# -> C#, Scala -> Java, но я сильно не уверен, что функциональщину удастся выразить в легко читаемом, понятном коде.
Вообще, задача получить на выходе именно простой, читаемый код — достаточно трудна, чтобы пришлось сам "первичный язык" для неё разрабатывать специально с учетом этой трудности.

Как вариант, "первичный" может быть не универсальным языком , а заточенным под задачу DSL-ом.
Возможно, это ближе к кодогенератору с набором темплейтов и конфигурацией, выраженной на DSL.

Здравствуйте, Shmj, Вы писали:

S>Сложность, конечно, понятие субъективное

Не субъективное, а относительное.

S>С одной стороны, если парадигм будет достаточно мало (в теории 1 команды достаточно для всего) — будет весьма сложно.

Каких таких парадигм и при чем тут одна команда?

S>С другой стороны, если парадигм достаточно много — то, как показывает практика, не все могут осилить

А все это кто?

S>Для примера возьмем Java и Scala.

При чем тут Java и Scala? И на том и на другом можно писать и простой и сложный код.

S> Scala проще или сложнее? Для большинства все-таки сложнее

Для какого большинства? Для тех кто пишет на Scala? Вряд ли? Для тех кто не пишет на Scala? А зачем нам вообще знать про то как им сложно воспринимать код на Scala?

S>Так вот. Постепенно функциональщина и пр. монады — протекают и в изначально простые языки.

А с чего ты взял что функциональщина это сложно? Это сложно только для тех, кто себе в мозгах накатал императивную колею, и не может из нее выползти.
Я вооще не очень понимаю эти разговоры про сложность современных языков для промышленной разработки в отношении тех, у кого базовые вещи вызывают сложность.

S>Просьба высказать мысли по этому вопросу.

У тебя в тексте очень много плохо связанных между собой вопросов. Попробуй начать с простоты понимания своих сообщений.