Я немного о другом. Вложенность зависимостей — дурацкая идея. Проблема в том, что " в плоский список, если это возможно". Почему-то, очень часто оно не работает. Может дело в зависимостях зависимостей? Я не знаю. Так вот — очень часто их глубина становится слишком большой. Проблема не с количеством файлов, а с тем, что путь к самым глубоким зависимостям такой длинный, что винда не может с ним работать.
Как на меня все модули должны всегда лежать на одной вложености (не важно какой, это может быть как iit предлагает), плюс я бы еще версию добавил, как раз, чтобы любой модуль мог подключить необходимую версию.
Ведь если человек некомпетентен в какой-либо сфере деятельности, это станет заметно через пару месяцев
Вот в том то и проблема. Если нужно будет кого-то выгнать (скажем, закрылся проект, а альтернативное место есть только одно), то выгонят более компетентного мужчину, потому что за женщинами есть квота. Это и есть сексизм и дискриминация мужчин.
Как ни странно я понимаю почему туда никто не смотрит
Вообще да, структура node_modules просто отвратительная, а вложенность зависимостей — крайне дурацкая идея. Я уж молчу, что иногда вложенность такая, что винда не может работать с этой директорией (например удалить ее). Конечно, это больше кривизна винды, чем ноды, но все-равно.
Общее:
— Макконнелл
— Фаулер
— Керниган
— Ритчи
— Тьюринг (раз уж Аду к программистам записываем)
— Р. Гэбриел (даже не знаю, почему именно его имя тоже вспомнил, ведь Маккарти, автора Лиспа смог только нагуглить)
— Игорь Сысоев (автор nginx)
Из мира JS:
— Эйк
— Флэнаган
— Крокфорд
— Резиг
— Сошников
Соцсети:
— Цукерберг
— Дуров
Из мира игр:
— Кармак (Doom)
— Ромеро (Doom)
— Перссон/Нотч (Minecraft)
— Гейб (Half Life)
Вот сходу (в гугле только написание двух фамилий проверил — Макконнелл меня всегда пугал количеством удвоений согласных, а Нотча помнил как Парсона) два десятка известных разными областями — кто-то книги писал, кого-то игры прославили, кто-то фреймворк или язык свой сделал. Большинство из них еще живы.
Тут у вас еще у формулировки вашего вопроса есть недостаток — я могу назвать десятки мужских фамилий разработчиков и даже две женских (всех, с кем я работал, большинство фамилий помню). Но они вам, к сожалению, ничего не скажут.
Уверен, что у 90% мейнтейнеров ключ лежит в обычном файле в ~/.gpg и украсть его не сложней, чем украсть пароль
С другой стороны, тогда нужен и ключ и пароль к нему, а без ключа — только пароль. То есть ключ уже дает два фактора защиты (доступ к файлу и знание пароля) вместо одного
Конечно, если владелец не хранит пароль рядом с ключом, а держит его в голове.
Практически ВСЕ противники идеи бессмертия вечно скандируют две вещи:
Я сторонник идеи бессмертия, но вижу еще одну проблему, которую не могу удачно сформулировать.
Сейчас власть и деньги хоть слегка перетрясываются в силу смертей тех, кто их имеет, в то время как дети, обычно, не так сильны, чтобы это все удержать. Если же смерть будет побеждена, то сильные богатые люди, имея больше возможностей будут иметь еще больше возможностей, простите за тафтологию.
Более локально это будет проявляться, к примеру, во всяких офисах. Вот сейчас есть продвижение по карьерной лестнице. Старший уходит на покой, а многие кто под ним продвигаются на ступеньку вниз. Если люди будут жить 1000 лет, то будут прозябать на одной должности сотни лет в ожидании повышения (как сейчас ждут 10 лет), что, в итоге крайне негативно скажется на эффективности труда в среднем.
Хотя, если мы будем жить тысячи лет, то вообще все станет иначе. Возможно, жизнь будет размереннее и 100 лет будет казаться уже совершенно не устрашающим сроком.
А еще вот интересно. Как наш мозг удержит всю эту информацию? На сколько он сейчас «забивается» за жизнь? Если мозг не будет деградировать, то буду ли я помнить то, что было со мной 500 лет назад?
Ну OR как «addUnique» подходит, а какой побитовый оператор тогда подходит под «removeIfExists»? NOT — с натяжечкой, это ведь инверсия и применяется к одному оператору, а не к двум, XOR и AND логично вообще не подходят.
Я сходу не скажу, ваш пример добавляет слушателя или убирает его. С плюсом и минусом контекст, если честно, понятнее.
Но вот запрещать перезагрузку операторов, как на меня — зло. У программиста должны быть удобные механизмы, а как ими пользоваться уже должны регламентировать соглашения, а не авторитарное и не всегда удачное мнение создателя языка ограниченного языка.
Я говорю лишь о том, что это вполне логично с точки зрения внутреннего устройства языка.
О том, что это крайне неудобно — я совершенно не спорю. В том же C# лично мне этот момент нравится значительно больше — оно более интуитивно-понятно и значительно приятнее используется.
Функция, которая умеет обрабатывать любой объект данного класса, это метод класса, а не объекта. В него объект должен передаться явно, через аргумент, а не через магический контекст.
Увы, нету в JS классов в таком виде. Есть функция первого класса, которая создает объект и которому присваивает прототип. И даже нету методов. Есть функции, которые лежат в прототипе.
У нас даже нету «это объект класса А». Нет. Скорее так: «у этого объекта сейчас прототип ссылается на инстанс А». А может потом вдруг начать ссылаться на что-то другое
Не мыслите о this в JS с точки зрения C#, это не имеет никакого смысла
То у вас перевозки, то у вас одноразовые мелкие проекты.
Это у человека просто прелестная демагогия:
— Дайте мне аргументы, что технологию А можно использовать для мелких проектов!
— Вот аргументы!
— Видите, сами утверждаете, что технология А подходит только для мелких проектов, а мне необходимо для крупных.
Проблема с this не в том, что он сложен, а в том, что он нелогичен.
Проблема с this не в том, что он нелогичен, а в том, что его логика отличается от других языков.
как часто вы реально использовали великолепную фичу «потеря контекста в колбеке»
Вы не понимаете. Это не фича «а давайте терять контекст, вдруг кому-то удобно будет». Это следствие его реализации. this — просто переменная, которая указывает, в каком контексте вызвана функция. То есть контекст не теряется, его никогда и не было, он просто подставляется в момент вызова. И такое следствие вы используете значительно чаще, чем вы думаете (все прототипное наследование на этом построено).
Вот смотрите.
var a = {
foo: function () { console.log(this) }
}
a.foo()
Тут вроде логично.
var a = {
foo: function () { console.log(this) }
}
var b = {
foo: a.foo
}
b.foo()
Вот тут могут быть сторонники каждого решения.
var Proto = {
foo: function () { console.log(this) }
}
var B = function () {}
B.prototype = new Proto();
var b = new B();
b.foo();
А вот тут контекст должен указывать на Proto, по вашему, потому что там объявлена функция?
Другое дело, что в 95% случаев работа с this в JS крайне неудобна и новички об нее постоянно спотыкаются. Это да. Но она по-своему логична.
Почему ненормально? Я вот много лет писал на ЖС и сейчас пишу, мне нравится множество вещей на нем, но вот люблю C#, потому что мне нравятся эмоции, которые я испытываю, когда программирую на нем. Может вы ремесленник и относитесь к программированию исключительно как к монотонной скучной работе, но не все такие.
Я вот сейчас еще на Go много пишу, но совсем его не люблю, потому что очень неудобный язык. Так что да, под решение задачи подходит и даже больше C#, но люблю я все-равно C#, к JS я нейтрален, а Go не люблю. Что тут не так?
шампанское не шампанское, если сделано в местах отличных от провинции Шампань
Нет, шампанское — не шампанское, если это виноградная Фанта, на которой написано, что это шампанское. То, что она из винограда и с пузырьками ведь не делает еще ее шампанским?
Вот и я не требую, чтобы Roguelike-игры были от автора Rogue. Я просто хочу, чтобы Roguelike называли игры, которые похожи на Rogue хотя бы основопологающими чертами.
и в режиме псевдографики в том числе.
Я не про псевдографику и графические паки. Я про геймплей. Там есть два режима игры — стратегический и приключение. Вот приключение — классический Roguelike. И, вы не поверите, ДФ соответствует всем этим пунктам.
пять с половиной из восьми — не так уж плохо, имхо.
Видите ли, большинство этих пунктов более характерны для наджанра «симулятора выживания», к которому относятся и Rougelike игры. Потому что те же 5.5 пунктов можно найти и в какой-либо "Survive — Wilderness survival", «Dying light» в режиме «Nightmare» или «X-Com 2016» в режиме «Iron Man» (даже 6 пунктов!)
— Random generated levels
— Permadeath
— Turn-based combat
— предпочтение «рубилову» а не мирному решению проблем
— player must use resource management to survive
— single-player
То есть даже x-com 2016-ого года по этому списку более Rougelike, чем FTL — у него крепких 6 пунктов. Да и остальные два можно с натяжечкой (такой же, как и FTL) приплести (в дом можно войти через дверь, через окно, через люк в крыше, взорвав гранатой стену), а «identity of magical items… varies across games» частично работает за счет множества мелких улучшений оружия вроде прицелов, автоперезарядок, обойм и десятков прочего, что дает тысячи комбинаций. Только это не делает из нее Rougelike, потому что она вообще не как Rouge.
Я немного о другом. Вложенность зависимостей — дурацкая идея. Проблема в том, что " в плоский список, если это возможно". Почему-то, очень часто оно не работает. Может дело в зависимостях зависимостей? Я не знаю. Так вот — очень часто их глубина становится слишком большой. Проблема не с количеством файлов, а с тем, что путь к самым глубоким зависимостям такой длинный, что винда не может с ним работать.
Как на меня все модули должны всегда лежать на одной вложености (не важно какой, это может быть как iit предлагает), плюс я бы еще версию добавил, как раз, чтобы любой модуль мог подключить необходимую версию.
Вот в том то и проблема. Если нужно будет кого-то выгнать (скажем, закрылся проект, а альтернативное место есть только одно), то выгонят более компетентного мужчину, потому что за женщинами есть квота. Это и есть сексизм и дискриминация мужчин.
Вообще да, структура node_modules просто отвратительная, а вложенность зависимостей — крайне дурацкая идея. Я уж молчу, что иногда вложенность такая, что винда не может работать с этой директорией (например удалить ее). Конечно, это больше кривизна винды, чем ноды, но все-равно.
— Макконнелл
— Фаулер
— Керниган
— Ритчи
— Тьюринг (раз уж Аду к программистам записываем)
— Р. Гэбриел (даже не знаю, почему именно его имя тоже вспомнил, ведь Маккарти, автора Лиспа смог только нагуглить)
— Игорь Сысоев (автор nginx)
ОС
— Билл Гейтс (сомнительно)
— Стив Возняк
— Линус Торвальдс
Из мира JS:
— Эйк
— Флэнаган
— Крокфорд
— Резиг
— Сошников
Соцсети:
— Цукерберг
— Дуров
Из мира игр:
— Кармак (Doom)
— Ромеро (Doom)
— Перссон/Нотч (Minecraft)
— Гейб (Half Life)
Вот сходу (в гугле только написание двух фамилий проверил — Макконнелл меня всегда пугал количеством удвоений согласных, а Нотча помнил как Парсона) два десятка известных разными областями — кто-то книги писал, кого-то игры прославили, кто-то фреймворк или язык свой сделал. Большинство из них еще живы.
Тут у вас еще у формулировки вашего вопроса есть недостаток — я могу назвать десятки мужских фамилий разработчиков и даже две женских (всех, с кем я работал, большинство фамилий помню). Но они вам, к сожалению, ничего не скажут.
С другой стороны, тогда нужен и ключ и пароль к нему, а без ключа — только пароль. То есть ключ уже дает два фактора защиты (доступ к файлу и знание пароля) вместо одного
Конечно, если владелец не хранит пароль рядом с ключом, а держит его в голове.
Я сторонник идеи бессмертия, но вижу еще одну проблему, которую не могу удачно сформулировать.
Сейчас власть и деньги хоть слегка перетрясываются в силу смертей тех, кто их имеет, в то время как дети, обычно, не так сильны, чтобы это все удержать. Если же смерть будет побеждена, то сильные богатые люди, имея больше возможностей будут иметь еще больше возможностей, простите за тафтологию.
Более локально это будет проявляться, к примеру, во всяких офисах. Вот сейчас есть продвижение по карьерной лестнице. Старший уходит на покой, а многие кто под ним продвигаются на ступеньку вниз. Если люди будут жить 1000 лет, то будут прозябать на одной должности сотни лет в ожидании повышения (как сейчас ждут 10 лет), что, в итоге крайне негативно скажется на эффективности труда в среднем.
Хотя, если мы будем жить тысячи лет, то вообще все станет иначе. Возможно, жизнь будет размереннее и 100 лет будет казаться уже совершенно не устрашающим сроком.
А еще вот интересно. Как наш мозг удержит всю эту информацию? На сколько он сейчас «забивается» за жизнь? Если мозг не будет деградировать, то буду ли я помнить то, что было со мной 500 лет назад?
Лол, тогда непонятно чего вы так агитируете за Go? Вот уж где инфрастуктура пока очень слабая.
Я сходу не скажу, ваш пример добавляет слушателя или убирает его. С плюсом и минусом контекст, если честно, понятнее.
Но вот запрещать перезагрузку операторов, как на меня — зло. У программиста должны быть удобные механизмы, а как ими пользоваться уже должны регламентировать соглашения, а не авторитарное и не всегда удачное мнение создателя языка ограниченного языка.
О том, что это крайне неудобно — я совершенно не спорю. В том же C# лично мне этот момент нравится значительно больше — оно более интуитивно-понятно и значительно приятнее используется.
Увы, нету в JS классов в таком виде. Есть функция первого класса, которая создает объект и которому присваивает прототип. И даже нету методов. Есть функции, которые лежат в прототипе.
У нас даже нету «это объект класса А». Нет. Скорее так: «у этого объекта сейчас прототип ссылается на инстанс А». А может потом вдруг начать ссылаться на что-то другое
Не мыслите о this в JS с точки зрения C#, это не имеет никакого смысла
Это у человека просто прелестная демагогия:
— Дайте мне аргументы, что технологию А можно использовать для мелких проектов!
— Вот аргументы!
— Видите, сами утверждаете, что технология А подходит только для мелких проектов, а мне необходимо для крупных.
Проблема с this не в том, что он нелогичен, а в том, что его логика отличается от других языков.
Вы не понимаете. Это не фича «а давайте терять контекст, вдруг кому-то удобно будет». Это следствие его реализации. this — просто переменная, которая указывает, в каком контексте вызвана функция. То есть контекст не теряется, его никогда и не было, он просто подставляется в момент вызова. И такое следствие вы используете значительно чаще, чем вы думаете (все прототипное наследование на этом построено).
Вот смотрите.
Тут вроде логично.
Вот тут могут быть сторонники каждого решения.
А вот тут контекст должен указывать на Proto, по вашему, потому что там объявлена функция?
Другое дело, что в 95% случаев работа с this в JS крайне неудобна и новички об нее постоянно спотыкаются. Это да. Но она по-своему логична.
В очень многих. Например в C#, но это другие языки.
Я вот сейчас еще на Go много пишу, но совсем его не люблю, потому что очень неудобный язык. Так что да, под решение задачи подходит и даже больше C#, но люблю я все-равно C#, к JS я нейтрален, а Go не люблю. Что тут не так?
Нет, шампанское — не шампанское, если это виноградная Фанта, на которой написано, что это шампанское. То, что она из винограда и с пузырьками ведь не делает еще ее шампанским?
Вот и я не требую, чтобы Roguelike-игры были от автора Rogue. Я просто хочу, чтобы Roguelike называли игры, которые похожи на Rogue хотя бы основопологающими чертами.
Я не про псевдографику и графические паки. Я про геймплей. Там есть два режима игры — стратегический и приключение. Вот приключение — классический Roguelike. И, вы не поверите, ДФ соответствует всем этим пунктам.
Видите ли, большинство этих пунктов более характерны для наджанра «симулятора выживания», к которому относятся и Rougelike игры. Потому что те же 5.5 пунктов можно найти и в какой-либо "Survive — Wilderness survival", «Dying light» в режиме «Nightmare» или «X-Com 2016» в режиме «Iron Man» (даже 6 пунктов!)
— Random generated levels
— Permadeath
— Turn-based combat
— предпочтение «рубилову» а не мирному решению проблем
— player must use resource management to survive
— single-player
То есть даже x-com 2016-ого года по этому списку более Rougelike, чем FTL — у него крепких 6 пунктов. Да и остальные два можно с натяжечкой (такой же, как и FTL) приплести (в дом можно войти через дверь, через окно, через люк в крыше, взорвав гранатой стену), а «identity of magical items… varies across games» частично работает за счет множества мелких улучшений оружия вроде прицелов, автоперезарядок, обойм и десятков прочего, что дает тысячи комбинаций. Только это не делает из нее Rougelike, потому что она вообще не как Rouge.
Чем ts лучше c#? =) Как по мне, ts хоть и улучшает js значительно, но до c# очень не дотягивает