LINUX.ORG.RU

История изменений

Исправление torvn77, (текущая версия) :

Нет, там именно проблемы с эффективным распаралеливанием интерпретируемых языков, подробнее можно прочитать у них в мануальнике
https://docs.godotengine.org/en/3.2/getting_started/scripting/gdscript/gdscript_basics.html

 В этот момент стало очевидно, что пользовательский язык сценариев может более оптимально использовать особую архитектуру Годо:

* Годо встраивает скрипты в узлы. Большинство языков не предназначены для этого.   
Godot использует несколько встроенных типов данных для 2D и 3D математики. Языки сценариев не обеспечивают этого, и связывание их неэффективно.    
* Godot активно использует потоки для подъема и инициализации данных из сети или с диска. Переводчики сценариев для распространенных языков не дружат с этим.
* У Godot уже есть модель управления памятью для ресурсов, большинство языков сценариев предоставляют свои собственные, что приводит к дублированию усилий и ошибкам.
* Связывающий код всегда запутан и приводит к нескольким точкам отказа, неожиданным ошибкам и, как правило, снижению удобства обслуживания.

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

Исправление torvn77, :

Нет, там именно проблемы с эффективным распаралеливанием интерпретируемых языков, подробнее можно прочитать у них в мануальнике
https://docs.godotengine.org/en/3.2/getting_started/scripting/gdscript/gdscript_basics.html

 В этот момент стало очевидно, что пользовательский язык сценариев может более оптимально использовать особую архитектуру Годо:

* Годо встраивает скрипты в узлы. Большинство языков не предназначены для этого.   
Godot использует несколько встроенных типов данных для 2D и 3D математики. Языки сценариев не обеспечивают этого, и связывание их неэффективно.    
* Godot активно использует потоки для подъема и инициализации данных из сети или с диска. Переводчики сценариев для распространенных языков не дружат с этим.
* У Godot уже есть модель управления памятью для ресурсов, большинство языков сценариев предоставляют свои собственные, что приводит к дублированию усилий и ошибкам.
* Связывающий код всегда запутан и приводит к нескольким точкам отказа, неожиданным ошибкам и, как правило, снижению удобства обслуживания.

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

Исходная версия torvn77, :

Нет, там именно проблемы с эффективным распаралеливанием интерпретируемых языков, подробнее можно прочитать у них в мануальнике
https://docs.godotengine.org/en/3.2/getting_started/scripting/gdscript/gdscript_basics.html

 В этот момент стало очевидно, что пользовательский язык сценариев может более оптимально использовать особую архитектуру Годо:

Годо встраивает скрипты в узлы. Большинство языков не предназначены для этого.
Godot использует несколько встроенных типов данных для 2D и 3D математики. Языки сценариев не обеспечивают этого, и связывание их неэффективно.
Godot активно использует потоки для подъема и инициализации данных из сети или с диска. Переводчики сценариев для распространенных языков не дружат с этим.
У Godot уже есть модель управления памятью для ресурсов, большинство языков сценариев предоставляют свои собственные, что приводит к дублированию усилий и ошибкам.
Связывающий код всегда запутан и приводит к нескольким точкам отказа, неожиданным ошибкам и, как правило, снижению удобства обслуживания.
Результатом этих соображений является GDScript . Язык и интерпретатор для GDScript оказались меньше, чем сам код привязки для Lua и Squirrel, но при этом имели одинаковую функциональность. Со временем наличие встроенного языка оказалось огромным преимуществом.