Какой язык выбрать для внутренних игровых скриптов?

А что значит «заслужил»? Моя характеристика вовсе ведет в 404. Непорядок. Себя кстати тоже запиши: верит СМИ, боится выходить на улицу. И сходи полечись в дурке.

Заслужил, значит что внесён по совокупности большого количества толстых вбросов. Твоя характеристика ведёт куда надо, просто у тебя звёзд мало, чтобы видеть удалённые модератором темы и комментарии, в том числе твои. Другие пятизвёздочные без проблем могут почитать твои перлы. Там твой срачик с Reset.

фанатик динамической типизации, который не писал больших и сложных проектов, когда падение во время работы критичнее

а откуда идёт миф о том, что динамические ЯП не подходят для больших проектов?
мой опыт использования статического ЯП (>10 лет на дельфи, в т.ч. большие проекты) и динамического (10 лет на Луа) никак не подтверждает этот миф
наоборот, разработка на динамических ЯП проще, а поэтому безошибочнее и быстрее
и субъективно воспринимается как «свободнее»

просто некоторые макаки думают, что после того, как компилятор найдёт ошибки несоответствия типов, в их программах больше не останется ошибок ))))

Размер не имеет значения. Только количество пограмистов. Если он один, то всё прекрасно с динамикой. Если вас двое, то уже начинаются трения. Если команда индусов, то можно сразу вешаться. Я давным давно работал с такой командой и питоном. С тех пор ненавижу змей и Индию.

и при чём тут динамичность языка?
ты бы в любом случае ненавидел индию, на чём бы ни писал

Нет, строгий компилятор им хоть бьёт по рукам. А вообще я сам люблю динамику, но вижу границы применимости. И допускать к динамике можно только того, кто понимает, что типы никуда не делись, просто они выводятся в рантайме. И соответственно имеет опыт работы со статической типизацией. А не как обычно верстальщиков каких-то набирают за доширак.

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

От языка зависит. Я свой древнющий код на тикле прекрасно читаю и правлю (тестов там конечно нет). С перлом вот похуже. А «большой» это понятие условное. Там же не одна мегапортянка, а какие-то модули. И сам себе не станешь же гадить сильной связностью. Да и миллионы строк в одно рыло всяко не напишешь.

И сам себе не станешь же гадить сильной связностью.

Зависит от сложности (уже в другом смысле) проекта. Иногда и станешь, потому как для обеспечения слабой связанности вместо 10 000 строк кода может потребоваться писать 100 000.

Размер это про количество людей

да, есть такая проблема - понять что предыдущие чуваки натворили в старом коде
но компилятор не сможет тебе в этом помочь ничем )))

эту проблему можно частично решить ведением документации
ещё важно, чтобы программистов не торопили
и набирать лучше перфекционитов, а не тех, для кого работа - это место для болтовни с коллегами, куда в 9 приходят и в 6 уходят

но компилятор не сможет тебе в этом помочь ничем )))

Хоть по типам данных будет понятно, а в динамике (как и в перемазанном шаблонами ООП) можно очень сильно удивляться как в результате вызова ряда функций неявно float превращается в class или строку.

можно очень сильно удивляться как в результате вызова ряда функций неявно float превращается в class или строку.

то есть, ты не разобрался как работает старый код, но начал его дорабатывать «не глядя»
и если компилятор не нашёл ошибок, то значит всё норм, можно «в продакшн»? )))
вот же говнокодер, блин…

типичная работа с чужим кодом в большом проекте: несколько часов изучаешь старый код и только потом добавляешь в него одну строку своего кода.
главное - не чтобы оно запустилось (и компилятор не нашёл ошибок), а чтобы оно работало гарантированно правильно после твоих изменений.
компилятор тебе не поможет понять логику старого кода.

Можно и несколько часов читать код, а потом где-то непоянтную фигню не заметить и всё

что значит «не заметить»?
цель - изучить код, а не построить правдоподобную догадку, прочитав его «по диагонали»

Как хочешь читай код, у тебя будут только догадки разной степени подобности. Это философская проблема, относится к проблеме познаваем ли мир и насколько. Вопрос в том, что ошибки были, есть и будут (это то с чем мы объективно регулярно сталкиваемся). Идеальный несуществующий язык программирования не избавляет от ошибок (это нереально, так как проблема в том, что нет идеального программиста), но он должен минимизировать риск совершения ошибки при сохранении скорости разработки, выразительности и скорости работы программ. Динамика способствует скорости разработки и иногда выразительности, но 2 других критерия ухудшает.

Вот вы всё луа да луа, а у схемы простой стандарт, guile впиливается в сишку на ура, никаких 1-индексов, отличное ООП и макросы есть в двух вариантах. Ещё можно легко в программу впилить сбоку, в отдельном треде, REPL и легко менять функции, если не весь код, прямо на ходу работы программы. Красота.

2 других критерия ухудшает.

он должен минимизировать риск совершения ошибки

опять вернулись к нашим макакам, которые думают, что проверка соответствия типов обнаружит 99% всех их ошибок )))
ошибки бывают от невнимательности и от лени (т.е., от нежелания тщательно разобраться)
да и в луа несоответствие типов чаще всего (где-нибудь в последующих строках кода) вылезет ошибкой, чем не вылезет
пример: индексация/вызов/конкатенация/арифметика с nil или сложение нечисловых строк - это типичные ошибки рантайма, вызванные несовпадением типов

скорости работы программ.

про то, что LuaJIT чуть быстрее сишечки на некоторых тестах, слышал?
но мы сейчас говорим про язык, а не про реализацию компиляторов

короче, доводов про «не подходит для больших проектов» я так и не увидел