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


I>...две асинхронных нити, 1 и 2, захватывают 2 ресурса, А и Б, но в разной последовательности. Нить 1 захватывает А и пытается захватить Б, а нить 2 захватывает Б и пытается захватить А.
I>Опаньки — дедлок асинхронного кода.
В теории согласен, но я не могу вспомнить (или даже придумать) реального примера когда такое происходило бы (утечки ресурса, гонки -- это помню, дедлок вспомнить не могу). Если вам не трудно приведите его.
И все же оставил себе немного маневра
S>>

Однопоточность и колбеки убирают/уменьшают вероятность дедлоков.


I>Итого — асинхронщина это АДъ в отладке. Нужно устранять разделяемые ресурсы, даже если это обойдётся в 100гб адресного пространства
Простите немного не понял вывод. При чем тут отладка? И откуда появились 100Гб?

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

I>>Опаньки — дедлок асинхронного кода.
S>В теории согласен, но я не могу вспомнить (или даже придумать) реального примера когда такое происходило бы (утечки ресурса, гонки -- это помню, дедлок вспомнить не могу). Если вам не трудно приведите его.

В правильно написаном приложении я вообще не могу вспомнить где бы проиходили утечки, гонки, дедлоки, креши. Если не трудно — приведи пример.

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

S>И все же оставил себе немного маневра
S>>>

Однопоточность и колбеки убирают/уменьшают вероятность дедлоков.
S>

I>>Итого — асинхронщина это АДъ в отладке. Нужно устранять разделяемые ресурсы, даже если это обойдётся в 100гб адресного пространства
S>Простите немного не понял вывод. При чем тут отладка? И откуда появились 100Гб?

Если говорить про коня в вакууме, то отладка ни при чем. А если про конкретный результат, то надо чем то обеспечить " Однопоточность и колбеки убирают/уменьшают вероятность дедлоков". Пудозреваю, это легко если ты пишешь без багов

100гб это для интереса. Зарулить указаную проблему можно конским распылением памяти-адресного пространства.

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

vsb>>К ФП у меня претензии — нет нормального синтаксиса для анонимных однострочных функций, писать function (x, y) { return x + y; } это очень много в сравнение с другими языками. Нет нормальной библиотеки коллекций в функциональном стиле.

I>А что ты хочешь от этой нормальной библиотеки функций ?

1. Развитый и расширяемый набор классов для коллекций. Вообще мне Java-овский нравится, но в целом может быть можно и лучше. Iterable, Collection, Set, List, ArrayList, LinkedList, HashSet, TreeSet, Map, HashMap, TreeMap. Эти все классы я использую достаточно часто и не представляю, как без них можно жить. В принципе есть ещё некоторые структуры данных вроде AVL-Tree, Trie, Ropes, BTree, которые используются редко, но почему бы их не иметь в стандартной библиотеке коллекций. Ещё есть бесконечные списки-генераторы, тоже могут быть полезны.

2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.

vsb>>Про ООП странно слышать. Я в JS вообще ООП нормальный не вижу, вижу некую симуляцию, как в каком-нибудь перле. Вроде внешне всё как в ООП, но внутри костылях и хеш-таблицы. В Java с этим по-моему лучше.

I>Там прототипное ООП, в ём реализуемо всё что тебе надо.

На С тоже реализуемо всё, что надо. Но писать классы в Java-стиле как то проще и понятней, в том числе для новичков. А прототипно-ориентированное программирование некоторыми ставится как отдельная дисциплина. В целом мне оно нравится, но всё же я не считаю его эталоном ООП.

I>>>Есть несколько правил в JS — нужно, в порядке убывания важности
I>>>1 избегать лишних связей и обрезать оные по возможности.
I>>>2 держать код в виде пригодном для рефакторинга
I>>>3 избегать лишних сущностей и обрезать по возможности.
I>>>4 соблюдать соглашения, давать качественные имена
I>>>5 следить за локальностью

vsb>>Правила хорошего тона для любого языка на мой взгляд.

I>Приоритеты разные. Скажем, п2, п4 и п5 для C# или джавы вообще можно выкинуть

Не понимаю, почему. Если речь о том, что в Java можно выжить без читаемых имён, а в JS можно сразу застрелиться, то, возможно, соглашусь, но зачем так жить. Лучше писать нормально.

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

I>>А что ты хочешь от этой нормальной библиотеки функций ?

vsb>1. Развитый и расширяемый набор классов для коллекций.

Это самоцель такая ? Ты лучше задачи расскажи, которые тебе надо решать.

>Iterable, Collection, Set, List, ArrayList, LinkedList, HashSet, TreeSet, Map, HashMap, TreeMap. Эти все классы я использую достаточно часто и не представляю, как без них можно жить. В принципе есть ещё некоторые структуры данных вроде AVL-Tree, Trie, Ropes, BTree, которые используются редко, но почему бы их не иметь в стандартной библиотеке коллекций. Ещё есть бесконечные списки-генераторы, тоже могут быть полезны.

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

vsb>2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.

var y = x.map(function(item) { return item.run(); })

Тут у тебя волосы шевелятся ?

I>>Там прототипное ООП, в ём реализуемо всё что тебе надо.

vsb>На С тоже реализуемо всё, что надо. Но писать классы в Java-стиле как то проще и понятней, в том числе для новичков. А прототипно-ориентированное программирование некоторыми ставится как отдельная дисциплина. В целом мне оно нравится, но всё же я не считаю его эталоном ООП.

скажи сразу — дело привычки и все.

I>>>>Есть несколько правил в JS — нужно, в порядке убывания важности
I>>>>1 избегать лишних связей и обрезать оные по возможности.
I>>>>2 держать код в виде пригодном для рефакторинга
I>>>>3 избегать лишних сущностей и обрезать по возможности.
I>>>>4 соблюдать соглашения, давать качественные имена
I>>>>5 следить за локальностью

vsb>>>Правила хорошего тона для любого языка на мой взгляд.

I>>Приоритеты разные. Скажем, п2, п4 и п5 для C# или джавы вообще можно выкинуть

vsb>Не понимаю, почему. Если речь о том, что в Java можно выжить без читаемых имён, а в JS можно сразу застрелиться, то, возможно, соглашусь, но зачем так жить. Лучше писать нормально.

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

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

I>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.
А ты вообще пишешь что-нибудь сложнее Hello World?

Да, кстати, как там по хэш-карте в JS пройтись?

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

I>Вот простой пример — есть два файла, в которых надо чего то писать. Одна цепочка пишет в файл унутре асинхронного мутекса и там же пытается записать в другой файл, так же унутре асинхроного мутекса, но другого. Другая цепочка делает тоже самое, но наоборот.
Простите, но я не знаком с таким понятием как "асинхронный мьютекс" (может под другим названием), если вам не трудно дайте ссылку "на почитать".
Если брать пример когда 2 цепочки пишут 2 файла но в разном порядке, то не понятно как получается дедлок. Если "блокировка" происходит по средствам чего-то вроде Deferred Object (который непереиспользуемый -- один раз отпустив его вы уже не сможете его поднять, то есть на роль мьютекса не особо подходит), то полочить дедлок вы можете только намерено, при том оба "потока" должны знать друг о друге (поскольку "блокировка" принадлежит "потоку") в таком контексте более естественным решением будет сделать цепочку из них. То есть в теории можно написать "дедлок", но на практике я не вижу способа как это можно получить по ошибке (а не намеренно).
Если вас не затруднит, то приведите пример кода, возможно так мне будет легче понять.

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

S>Простите, но я не знаком с таким понятием как "асинхронный мьютекс" (может под другим названием), если вам не трудно дайте ссылку "на почитать".

Это легко гуглится. примитивы синхрнизации, гонки, дедлоки есть в любой многозадачности. Повторяю — в любой.

S>Если брать пример когда 2 цепочки пишут 2 файла но в разном порядке, то не понятно как получается дедлок. Если "блокировка" происходит по средствам чего-то вроде Deferred Object (который непереиспользуемый -- один раз отпустив его вы уже не сможете его поднять, то есть на роль мьютекса не особо подходит), то полочить дедлок вы можете только намерено, при том оба "потока" должны знать друг о друге (поскольку "блокировка" принадлежит "потоку") в таком контексте более естественным решением будет сделать цепочку из них.

Блокировки есть в любой многозадачности, отсюда ясно, что для дедлока нужно минимально
1 два примитива синхронизации, в данном слчае мутекса
2 две нитки(задачи)

Это понятно, или надо объяснять ?

Не ясно, к чему ты притянул Defered Object Мутекс он переиспользуемый, т.к. для синхронизации нужен, и это очевидно.

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

Например обычные мутексы принадлежат процессу или ОС, потоки их захватывают. В кооперативной навроде асинхронщины блокировки так же не принадлежат потоку.

И, что очевидно, ни одна из ниток не знает про другую — все что они знают, это про асинхронные блокировки.

Вот простейший асинхронный мутекс, точнее его вызов

        var promise = mutex.lock(function () {
            return operation(data, filePath); // возвращает промис
        });

        return promise;

Отсюда ясно, что промис(DeferredObject) и мутекс это две большие разницы.
lock если свободен, запускает функцию. Если занят — ставит функцию в очередь.
operation — стартует асинхронную цепочку, которая выполнится унутре мутекса.
Как только она завершится, мутекс освободится. Далее из очереди берется следующий клиент и с ним всё по кругу.


> То есть в теории можно написать "дедлок", но на практике я не вижу способа как это можно получить по ошибке (а не намеренно).
S>Если вас не затруднит, то приведите пример кода, возможно так мне будет легче понять.

Показываю страшное

цепочка 1
function fiber1(){
        return mutex1.lock(function () {
            return operation(data1, file1Path).then(function(){
                return mutex2.lock(function () {
                    return operation(data2, file2Path);
                });
           });
        });
}
цепочка 2
function fiber2(){
        return mutex2.lock(function () {
            return operation(data2, file2Path).then(function(){
                return mutex1.lock(function () {
                    return operation(data1, file1Path);
                });
           });
        });
}

Итого — дедлок налицо. Каждая из цепочек может войти в первую операцию и если обе войдут, то каждая потом зависнет во второй.
Поскольку код асинхронный, цепочки легко стартуют одна за другой

fiber1();
fiber2();

поскольку код асинхронный, то обе цепочки могут одновременно спать или ожидать скажем IO. Т.е. пока первая унутре mutex1 ожидает IO, вторая входит в мутекс2 и так же начинает ожидать IO. Потом одна из них пробуждается и пробует захватить второй мутекс и попадает в очередь. Далее вторая попадется точно так же.

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

I>>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.
C>А ты вообще пишешь что-нибудь сложнее Hello World?

Как говорил IT, правильно спроектированая программа состоит из большого количества Hello World

C>Да, кстати, как там по хэш-карте в JS пройтись?

Что ты называешь хеш-картой ?

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

S>>Простите, но я не знаком с таким понятием как "асинхронный мьютекс" (может под другим названием), если вам не трудно дайте ссылку "на почитать".

I>Это легко гуглится. примитивы синхрнизации, гонки, дедлоки есть в любой многозадачности. Повторяю — в любой.
Если бы оно легко гуглелось, я бы не третировал вас на форуме У меня в выдаче противопоставления мьютекса и промисов.

>> То есть в теории можно написать "дедлок", но на практике я не вижу способа как это можно получить по ошибке (а не намеренно).
S>>Если вас не затруднит, то приведите пример кода, возможно так мне будет легче понять.

I>Показываю страшное
Та ничего страшного. Код вполне валидный и при этом теоретический.
На практике джаваскрипт-программист не придумает использовать мьютексы при наличии более простых способов "синхронизации", что делается довольно просто в условиях именно однопоточной среды. Поэтому я и писал что "убирают/уменьшают вероятность дедлоков" (согласен что "убирают" таки довольно резкое утверждение). Поэтому и просил привести реальный пример (реальную ошибку которую кто-то уже допустил при решении реальной задачи).

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

S>Поэтому я и писал что "убирают/уменьшают вероятность дедлоков" (согласен что "убирают" таки довольно резкое утверждение).

Вполне нормальное утверждение, поскольку в каноническом js в принципе этих проблем быть не может. В здравом уме и памяти
никто переть мьютексы в js не будет, поскольку там нет такой пробелмы, которую они решают. (тыц,тыц). Другое дело webworker'ы, но это другая история...

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

I>>Это легко гуглится. примитивы синхрнизации, гонки, дедлоки есть в любой многозадачности. Повторяю — в любой.
S>Если бы оно легко гуглелось, я бы не третировал вас на форуме У меня в выдаче противопоставления мьютекса и промисов.

А оно действительно легко гуглится Я когда то нагуглил целую кучу асинхронных примитивов синхронизации.

>>Показываю страшное
S>Та ничего страшного. Код вполне валидный и при этом теоретический.

Дедлок ты увидел или считаешь, что там дедлока нет ?

S>На практике джаваскрипт-программист не придумает использовать мьютексы при наличии более простых способов "синхронизации", что делается довольно просто в условиях именно однопоточной среды.

А если я тебе скажу, что в апи может и не быть синхронных методов в файл, что ты ответишь ?
Я сильно пудозреваю, ты с таким и не сталкивался.
Сейчас почти любая задача которая работает с IO проводит 90% времени в ожидании. Это значит, что даже на мега-быстродейственном С++ ты используешь максимум 10% процессора.

Сейчас самое узкое место в компе это IO. И по этой причине синхронный АПИ это убыток, неоправданная роскошь. Скажем для С++ это можно амортизировать, заюзав треды, а в джаваскрипте у тебя один единственный поток, синхронные вызовы сделают из без того тормозной джаваскрипт(сравнвая с С++) в черепаху.

>Поэтому я и писал что "убирают/уменьшают вероятность дедлоков" (согласен что "убирают" таки довольно резкое утверждение). Поэтому и просил привести реальный пример (реальную ошибку которую кто-то уже допустил при решении реальной задачи).

Я привел тебе ральный пример, только имена не из продакшна, ибо незачем.

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

S>>Если бы оно легко гуглелось, я бы не третировал вас на форуме У меня в выдаче противопоставления мьютекса и промисов.
I>А оно действительно легко гуглится Я когда то нагуглил целую кучу асинхронных примитивов синхронизации.
Ну хоть название перечислите (выдача гугла персонализированная, может мне просто не везет)

I>Я привел тебе ральный пример, только имена не из продакшна, ибо незачем.
I>Дедлок ты увидел или считаешь, что там дедлока нет ?
Дедлок я увидел. Просто тот пример что вы привели мне показался чисто теоретическим/надуманным, но раз вы говорите что такое мог написать живой человек в реальном коде прийдется поверить.

S>>На практике джаваскрипт-программист не придумает использовать мьютексы при наличии более простых способов "синхронизации", что делается довольно просто в условиях именно однопоточной среды.

I>А если я тебе скажу, что в апи может и не быть синхронных методов в файл, что ты ответишь ?
Что это не новость. В той же ноде в реальных задачах не используют синхронное АПИ (для некоторых наоборот людей открытие что в ноде существуют синхронные АПИ ).
От только эта асинхронная природа как раз таки уменьшает вероятность появления дедлока, так как та операция ради которой вы хотели залочиться, как правило, "атомарна", то есть управление вам передастся после ее завершения и необходимости делать явный лок (и разгребать все связанные с этим проблемы) нет, в отличии от многопоточной среды.

var lock = createLock();
// цепочка 1
function fiber1(){
  return lock.then(_.partial(operation, data1, file1Path))
             .then(_.partial(operation, data2, file2Path)); // заменяет mutex1
}
// цепочка 2
function fiber2(){
  return lock.then(_.partial(operation, data2, file2Path))
             .then(_.partial(operation, data1, file1Path)); // заменяет mutex2
}
lock = filer1();
lock = fiber2();

Помимо того что этот код проще он еще и более правильный так как гарантирует атомарность пары операций над file1Path и file2Path,
что были призваны обеспечить внешние вызовы mutex1.lock и mutex2.lock.
Поскольку такой вариант проще, то увеличивается вероятность того что он будет выбран вместо разгребания с парой мьютексов.

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

S>>>Если бы оно легко гуглелось, я бы не третировал вас на форуме У меня в выдаче противопоставления мьютекса и промисов.
I>>А оно действительно легко гуглится Я когда то нагуглил целую кучу асинхронных примитивов синхронизации.
S>Ну хоть название перечислите (выдача гугла персонализированная, может мне просто не везет)

async mutex — это что, так сложно ?

http://alookonthecode.blogspot.com/2012/08/async-mutex-control-flow-in.html

asymc lock

https://www.google.by/search?q=async+mutex&rlz=1C1CHMO_enBY526BY526&oq=async+mutex&aqs=chrome..69i57j0l5.5758j0j7&sourceid=chrome&espv=210&es_sm=93&ie=UTF-8#es_sm=93&espv=210&q=async%20lock

S>От только эта асинхронная природа как раз таки уменьшает вероятность появления дедлока, так как та операция ради которой вы хотели залочиться, как правило, "атомарна", то есть управление вам передастся после ее завершения и необходимости делать явный лок (и разгребать все связанные с этим проблемы) нет, в отличии от многопоточной среды.

Обычно атомарна, но это не всегда так.

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

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

Скажем, такую свертку как у тебя, типа _.partial, почему то мало где видел
Вообще в js почему то принятно злоупотреблять анонимными функциями, наверное потому что так проще брейкпоинты расставлять при отладки.

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

C>Да, кстати, как там по хэш-карте в JS пройтись?

это как раз легко.

for( var k in map )
{
  var v = map[k];
  ...
}

map — Array.map(f)
foldl — Array.reduce(f)
foldr — Array.reduceRight(f)

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

C>>Да, кстати, как там по хэш-карте в JS пройтись?
CS>то как раз легко.
Авотфиг.

Правильно:

for( var k in map )
{
  if (!map.hasOwnProperty(k)) continue;
  var v = map[k];
}

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

C>Здравствуйте, c-smile, Вы писали:

C>>>Да, кстати, как там по хэш-карте в JS пройтись?
CS>>то как раз легко.
C>Авотфиг.

Извиняюсь, так вот надо

for( var k of map.keys() )
{
  var v = map[k];
  ...
}

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

CS>Извиняюсь, так вот надо
CS>

CS>for( var k of map.keys() )
CS>{
CS>  var v = map[k];
CS>  ...
CS>}
CS>

И опять не работает:

cyberax@cybmac:~$ cat test.js 
mp = {'aa':11, 'bb':12}
for(var k of mp.keys())
    console.log(mp[k]);

cyberax@cybmac:~$ node test.js

/Users/cyberax/test.js:2
for(var k of mp.keys())
         ^^
SyntaxError: Unexpected identifier

Замена на 'in' — "TypeError: Object #<Object> has no method 'keys'"

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

Отвечаю поздно, писал ответ давно, но рсдн его съел и сказал error

vsb>>1. Развитый и расширяемый набор классов для коллекций.

I>Это самоцель такая ? Ты лучше задачи расскажи, которые тебе надо решать.

1. Переопределение функции хеширования для своего объекта, чтобы использовать его в виде ключа. Сейчас всё конвертируется в строку, в итоге если мы хотим делать своё хеширование, нам надо переопределять метод toString. Бред.

2. Класс-множество. Нужен очень часто. Сейчас приходится использовать map[item] = true, но нормальный интерфейс куда удобней.

3. Двоичное дерево. Очень удобно, когда у нас есть сравнение ключей и мы хотим, чтобы ключи автоматом сортировались.

4. Связный список. Нужен не часто, но когда нужен, аналогов нет.

5. Нормальный Array, который не будет превращаться в HashMap незаметно от пользователя.


>>Iterable, Collection, Set, List, ArrayList, LinkedList, HashSet, TreeSet, Map, HashMap, TreeMap. Эти все классы я использую достаточно часто и не представляю, как без них можно жить. В принципе есть ещё некоторые структуры данных вроде AVL-Tree, Trie, Ropes, BTree, которые используются редко, но почему бы их не иметь в стандартной библиотеке коллекций. Ещё есть бесконечные списки-генераторы, тоже могут быть полезны.

I>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.

Это кирпичики для интерфейса между библиотеками. Если у тебя есть lib1, в которой list1, lib2 в которой list2, то придётся писать глупый и лишний код по преобразованию между этими списками. Если у нас есть чёткие кирпичики в виде интерфейсов, значит никаких проблем с использованием и сопряжением библиотек не будет. Ну а если у нас есть интерфейсы, как то глупо не включить реализацию.

vsb>>2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.

I>

I>var y = x.map(function(item) { return item.run(); })

I>

I>Тут у тебя волосы шевелятся ?

> ['1', '2', '3'].map(parseInt)
< [1, NaN, NaN]

Вот тут. Ещё можно почитать примеры тут и тут

I>>>>>Есть несколько правил в JS — нужно, в порядке убывания важности
I>>>>>1 избегать лишних связей и обрезать оные по возможности.
I>>>>>2 держать код в виде пригодном для рефакторинга
I>>>>>3 избегать лишних сущностей и обрезать по возможности.
I>>>>>4 соблюдать соглашения, давать качественные имена
I>>>>>5 следить за локальностью

vsb>>>>Правила хорошего тона для любого языка на мой взгляд.

I>>>Приоритеты разные. Скажем, п2, п4 и п5 для C# или джавы вообще можно выкинуть

vsb>>Не понимаю, почему. Если речь о том, что в Java можно выжить без читаемых имён, а в JS можно сразу застрелиться, то, возможно, соглашусь, но зачем так жить. Лучше писать нормально.

I>потому что там искаропки есть отличный рефакторинг, подсказки компилятора и интелисенс и это само по себе решает вагон проблем, потому п2 и п4 отпадают. п5 отпадает, потому что дизайн джавы и шарпа такой.

Это кажется. На деле лапшу нерефакторизуемую на джаве соорудить легко. И никакие инструменты не помогут. Кстати в Java качественные имена я наблюдаю почему то гораздо чаще, чем в JS.

Про локальность тоже не понял, что там с дизайном не так. Глобальных переменных нафигачить — как раз плюнуть можно. И потом не то, что тестировать, баг отлавливать замучаешься.

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

I>>Это самоцель такая ? Ты лучше задачи расскажи, которые тебе надо решать.

vsb>1. Переопределение функции хеширования для своего объекта, чтобы использовать его в виде ключа. Сейчас всё конвертируется в строку, в итоге если мы хотим делать своё хеширование, нам надо переопределять метод toString. Бред.

В итоге надо писать своё хеширование. toString или нет, это дело десятое.

vsb>2. Класс-множество. Нужен очень часто. Сейчас приходится использовать map[item] = true, но нормальный интерфейс куда удобней.
vsb>3. Двоичное дерево. Очень удобно, когда у нас есть сравнение ключей и мы хотим, чтобы ключи автоматом сортировались.
vsb>4. Связный список. Нужен не часто, но когда нужен, аналогов нет.
vsb>5. Нормальный Array, который не будет превращаться в HashMap незаметно от пользователя.

Задачи какие решаешь ?

I>>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.

vsb>Это кирпичики для интерфейса между библиотеками. Если у тебя есть lib1, в которой list1, lib2 в которой list2, то придётся писать глупый и лишний код по преобразованию между этими списками. Если у нас есть чёткие кирпичики в виде интерфейсов, значит никаких проблем с использованием и сопряжением библиотек не будет. Ну а если у нас есть интерфейсы, как то глупо не включить реализацию.

Ты лучше про задачу расскажи, а то ты выдаёшь клочки какого то своего решения. А вот я скажу, что в C#, Java, C++ отстой ибо нельзя сделать вот так

obj.toString = function() {}

И что ?


vsb>>>2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.

I>>

I>>var y = x.map(function(item) { return item.run(); })

I>>

I>>Тут у тебя волосы шевелятся ?

vsb>

>> ['1', '2', '3'].map(parseInt)
vsb>< [1, NaN, NaN]
vsb>

vsb>Вот тут. Ещё можно почитать примеры

Это отстой. Ты задачу какую решаешь ? У меня в проекте около 7 мб джаваскрипта и я не наблюдаю тех ужасов, о которых ты говоришь Надо полагать я чтото не так делаю ?

I>>потому что там искаропки есть отличный рефакторинг, подсказки компилятора и интелисенс и это само по себе решает вагон проблем, потому п2 и п4 отпадают. п5 отпадает, потому что дизайн джавы и шарпа такой.

vsb>Это кажется. На деле лапшу нерефакторизуемую на джаве соорудить легко.

Это только кажется. На самом деле количество шагов рефакторинга увеличится.

vsb>И никакие инструменты не помогут. Кстати в Java качественные имена я наблюдаю почему то гораздо чаще, чем в JS.

Потому и наблюдаешь чаще, что там рефакторинг есть. Самый частый рефакторинг это переименование.

vsb>Про локальность тоже не понял, что там с дизайном не так. Глобальных переменных нафигачить — как раз плюнуть можно. И потом не то, что тестировать, баг отлавливать замучаешься.

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

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

I>>>Это самоцель такая ? Ты лучше задачи расскажи, которые тебе надо решать.

vsb>>1. Переопределение функции хеширования для своего объекта, чтобы использовать его в виде ключа. Сейчас всё конвертируется в строку, в итоге если мы хотим делать своё хеширование, нам надо переопределять метод toString. Бред.

I>В итоге надо писать своё хеширование. toString или нет, это дело десятое.

toString это конвертация объекта в строку, а не хеширование. В том и беда JS, он постоянно всё подпирает костылями. Если я пишу своё хеширование, я его могу протестировать на данных, улучшить. Я чётко понимаю, как работает это хеширование. Как работает хеширование на toString-е? Это загадка, покрытая мраком. Очевидно только, что в каждом браузере по-разному. Ну и вообще я хочу иметь нормальный toString для отладки. Какое он отношение имеет к хешированию?

vsb>>2. Класс-множество. Нужен очень часто. Сейчас приходится использовать map[item] = true, но нормальный интерфейс куда удобней.
vsb>>3. Двоичное дерево. Очень удобно, когда у нас есть сравнение ключей и мы хотим, чтобы ключи автоматом сортировались.
vsb>>4. Связный список. Нужен не часто, но когда нужен, аналогов нет.
vsb>>5. Нормальный Array, который не будет превращаться в HashMap незаметно от пользователя.

I>Задачи какие решаешь ?

Разные задачи. Не понимаю вопроса. Ну банально — приходят данные, их надо вставлять в упорядоченный список (например по имени). Если у меня есть дерево, я просто строю дерево по имени и вставляю, операция вставки занимает O(1), всё моментально обновляется. Если у меня нет дерева, мне приходится использовать массив, двоичным поиском искать место для вставки (кстати какая стандартная функция в JS для двоичного поиска?) и впихивать туда элемент, получая O(N) и тормоза.

I>>>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.

vsb>>Это кирпичики для интерфейса между библиотеками. Если у тебя есть lib1, в которой list1, lib2 в которой list2, то придётся писать глупый и лишний код по преобразованию между этими списками. Если у нас есть чёткие кирпичики в виде интерфейсов, значит никаких проблем с использованием и сопряжением библиотек не будет. Ну а если у нас есть интерфейсы, как то глупо не включить реализацию.

I>Ты лучше про задачу расскажи, а то ты выдаёшь клочки какого то своего решения.

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

vsb>>>>2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.

I>>>

I>>>var y = x.map(function(item) { return item.run(); })

I>>>

I>>>Тут у тебя волосы шевелятся ?

vsb>>

>>> ['1', '2', '3'].map(parseInt)
vsb>>< [1, NaN, NaN]
vsb>>

vsb>>Вот тут. Ещё можно почитать примеры

I>Это отстой. Ты задачу какую решаешь ? У меня в проекте около 7 мб джаваскрипта и я не наблюдаю тех ужасов, о которых ты говоришь Надо полагать я чтото не так делаю ?

Не знаю, что ты не так делаешь. Писать можно и на бейсике, если аккуратно. Это не отменяет минусов языка. Как минимум нужно знать про все расставленные грабли. Нужно помнить, что map передаёт в функцию-маппер не просто объект а ещё и его индекс и исходную коллекцию с какого то фига. Нужно помнить про все особенности parseInt, про то, что в старых браузерах он 010 пропарсит как 8, а в новых как 10, нужно помнить, что parseInt возвращает NaN для ошибок, но не всегда, а только если не смог пропарсить даже первый символ. И куча подобных мелочей. Огромная куча нелогичного контекста.