ArtistSpb писал(а):
Семантика важна, но и исполнение тоже важно - как это скрипты будут работать в ядре. Зависит от языка на котором реализуется.
Как пример. Сейчас же скрипты Dgscripts в мадах могут же порушить сервак - да могут.
Яб рекомендовал на них не ссылаться.
Это решение 15-летней давности. И не самое удачное.
ArtistSpb писал(а):
KadVar писал(а):
В любых других вариантах боюсь будут такие "несвязухи" на стыках "зон", что мало не покажется.
Такие проблемы давно решаются с помощью баз данных, например.
Какие "такие" ?
Не очень понятно зачем нужна многопоточность при необходимости частой синхронизации.
Т.е. кое-где многопоточность можно и даже нужно использовать, если нужна производительность.
К слову сказать, надо понимать еще и какая нужна производительность...
Сдается мне, что всё это - лишь пустая трата времени будет, в том смысле, что любой производительности
хватит с запасом. Вряд ли вы тысячный онлайн обеспечите.
ArtistSpb писал(а):
KadVar писал(а):
ArtistSpb писал(а):
Из всего этого, у меня пока только такие варианты вырисовываются :
- Lua как основной язык разработки + модули на C++.
Строго наоборот
.
Луа - это интерпретатор... какой из него "основной язык"...
Вот тут вы ошибаетесь. Lua - транслируется в байт код. И выполняется на виртуальной машине.
С таким же успехом можно Java или C# назвать неосновным языком. Еще у Lua есть сторонний
JIT компилятор, его скорость работы сравнима с кодом на С.
Честно - не хочется в это всё даже вникать.
Смысла не вижу.
Когда "все вокруг" пересядут с С# и Java на луа, тогда можно будет об этом говорить.
Т.е. об этом стоит почитать... в плане того подходит ли теперь lua хоть для чего-нибудь.
Потому как "с этими наворотами" может оказаться, что как скрипт-язык он более
негоден.
KadVar писал(а):
Lua вполне может выступать как основной язык разработки, только к ней эту кучу функционала
надо прицепить.
Если хочется как можно больше проблем - да.
Если хочется результата - яб рекомендовал проверенные решения...
Там вон некто на php+apache собрался мад фигачить... точно такое-же "безумие".
Можно и на VBA конечно сделать, весь вопрос в количестве спущенного в унитаз времени и сил
из-за выбора инструмента предназначенного для решения иных задач.