![]() |
#29 |
Участник
|
Цитата:
Возможно, вам будет интересно прочесть этот ответ: Цитата:
1. Потому, что разработчики браузеров и скриптовых машин (Rhino, SpiderMonkey) так создали свои программные продукты.
2. Потому, что составители спецификации ECMAScript описали этот язык как однопоточный. 3. Потому, что задачи, для решения которых этот язык позиционировался (придание интерактивности и динамики HTML-страничкам, проверка правильности заполнения форм и простые визуальные эффекты), не сочли достаточно сложными для того, что бы усложнять этот язык многопоточными конструкциями. А в последствии, даже если кто-то и пересмотрел своё решение, эти конструкции не стали вводить по причине желания сохранить обратную совместимость уже написанных сценариев и сложностей эволюционного перехода к ним. 4а. Потому что этот язык изначально был придуман и введён компанией Netscape для браузера Netscape Navigator в эпоху "браузерных войн" в качестве конкурентного преимущества перед компанией Microsoft и на тот момент развитие языка HTML было таковым, что коммерческие интересы Netscape диктовали этой компании постановку именно таких задач перед этим языком. Более сложные задачи перед разработчивами сайтов при том уровне развития интернета просто не стояли и. если бы была введена многопоточность, это выглядело бы излишним утяжелением этого языка. 4б. Потому, что понадобилось бы обеспечивать thread-safe`овость DOM-дерева и большинства объектов объектной модели. Так же необходимо было бы предоставлять возможность синхронизовывать функции и/или блоки, критичные к многотредовому использованию, придумывать или брать из других более сложных языков механизмы разруливания конфликтов за ресурсы и прочее и прочее. Кроме того, введение этого механизма сильно ослабило бы надёжность JS-машин и на порядки усложнило бы их реализацию без какого-либо существенного выигрыша для тех задач, которые традиционно решаются на этом языке. 4в. Хотя бы потому, что многочисленные методы DOM-модели, которые активно использует колоссальное количество сценариев, стали бы работать по-другому, с задержками. Ряд методов наверняка пришлось бы убирать, другие - вводить. Не надо ещё забывать "особую точку зрения на стандарты" компании Microsoft, которая бы наверняка не упустила бы лишнего шанса устроить очередную гадость несчастным скрипт-кодерам, старающимся писать кросс-браузерные скрипты, сделав свою реализацию многопоточности в JScript частично или даже полностью неcовместимой с ECMA. Всё это привело бы к колоссальной путанице. |
|
|
За это сообщение автора поблагодарили: George Nordic (2), belugin (2). |
Теги |
f#, kotlin |
|
|