В работе делается упор на использование воды как топлива.
Но энергии от соединения водорода и кислорода обратно в воду при сгорании мы получим не больше, чем потратим на гидролиз, пусть даже суперэффективный.
Разве нет?
Вы правы, оказывается они успели сменить технологию, хотя Bespin был основан именно на canvas:
«Bespin started as part of Mozilla Labs and was based on the canvas tag, while Ace is the Editor component of the Cloud9 IDE and is using the DOM for rendering.»
Первыми идею отрисовки редактора на canvas использовали в проекте Mozilla Skywriter (Bespin), который сейчас превратился в Ace и активно используется в Cloud9 IDE. Так что вы не совсем первые )
Но там редактор исходников, а у вас — документов, что прилично сложнее. По части редактора документов с таким подходом, пожалуй, действительно первые )
Рекомендую "Третью волну" Элвина Тоффлера. Там о том же более развернуто и всесторонне.
Интересно, что книга написана в начале 80х. Прочесть можно здесь.
Язык программирования — это способ воплощать идеи в реальность. Чем этот способ проще, прямее и удобнее, тем лучше.
Необходимость четкого знания диковинных правил работы парсера с переводами строк и точками с запятой — недостаток дизайна языка.
Таких недостатков в JS очень много. Вообще, JS легко позволяет писать ужасный, плохо читаемый и практически неподдерживаемый код. Но есть способ с этим справляться. Достаточно придерживаться простых соглашений. Эти соглашения, кроме прочего, позволяют не держать в голове сложные правила, о которых неприятно помнить и в которых легко ошибиться.
Нельзя недооценивать необходимость и силу соглашений. JS, как и Python, построены по принципу «соглашения важнее ограничений». Эти языки содержат очень мало запретов, в надежде, что вы достаточно ответственны, чтобы не делать зла. Это обеспечивает невероятную свободу и гибкость. Это же делает соглашения неотъемлемой частью таких языков.
Касательно топика.
Ставить точки с запятой проще, чем держать в голове правила, когда их можно опустить. Это делает жизнь приятнее. В том числе в плане прочтения кода — не ломаешь голову, здесь возможная ошибка или так и задумано.
Знать те два с половиной случая, когда переводы строк в JS опасны — придется. Это недостаток языка. Не слишком приятный, но терпимый.
Знать все особенности парсинга, к счастью, необязательно. Но хотя бы раз в жизни поинтересоваться ими полезно.
Стиль написания, требующий глубокого знания предмета без особых плюсов на выходе — не повод для гордости. Гораздо ценнее мастерство, делающее вещи проще. Автора извиняет то, что npm прекрасен. Но будь он ближе к общепринятым соглашениям, было бы еще лучше.
В то же время, отлично понимаю раздражение автора. Люди, учащиеся на шаманских ресурсах, которых развелось сверх меры, никогда не заглядывающие ни в спеку, ни в действительно хорошие примеры кода, влегкую выбешивают своими суевериями )
«Система неустойчива к сплитам» как раз и означает, что как только сплит — мы ничего не гарантируем. Все в силе только «пока сплита нет».
Представьте, вам предлагают построить дом, в котором ничего не сделано для защиты от ураганов. Пока урагана нет — все хорошо. Как только ураган — вам ничего не гарантируют.
Купите вы такой дом? — Почему бы и нет, если вы живете не в Канзасе и про ураганы разве что читали в «Волшебнике Изумрудного города».
Или вы станете «оценивать по худшей ситуации» и жить в бункере с защитой от цунами, взрывов водородной бомбы и пятью линиями вооруженной охраны, испытывая все связанные с таким непростым местом жительства неудобства?
Цитирую статью по вашей ссылке: «Nevertheless, no quorum algorithm can provide an absolute guarantee of this property in the presence of arbitrary failures. Different quorum implementations provide different degrees of certainty for any given configuration and set of expected failures.»
Именно про простейший вариант кворума написано в «лирическом отступлении». Читайте внимательнее.
Теперь я знаю, что люди, которые фиксируют расходы, предпочитают мыть посуду горчицей и хозяйственным мылом )
Похоже, выборка получилась несколько однобокая, во многом из сегмента «для тех, кто (жестко) экономит»
Огромное количество очень суровых ограничений, именно в них его сила.
Отсутствие деструктивного присваивания, немутируемые в принципе данные, общение между потоками только посылкой сообщений, на каждом шагу возникает необходимость создания компонентов в виде мини-серверов, ужасающая рудиментарная поддержка объектности… Список можно продолжить.
Эти ограничения заставляют решать задачи определенным способом, который как правило и является правильным, если только вы не пытаетесь сделать что-то, для чего язык совершенно не предназначен. Но это ограничивает область его применения.
Да что тут рассуждать, напишите на эрланге пару-тройку проектов, хотя бы и учебных — это даст вам понимания на два порядка больше чем самая заумная статья.
Erlang — в первую очередь телеком и все виды стэйт машин. Вот GUI на нем не попишешь — полное безобразие получается, взгляните хотя бы на его обертки к wxWidgets. Вообще, любые задачи с состоянием в виде развесистого сильно мутабельного по своей природе дерева делать на эрланге — мучение.
Про ноду говорить не совсем верно, правильнее про JS. А он зарекомендовал себя как вполне универсальный — чего только на нем не пишется и все вполне удобно и успешно. И серверные решения, и GUI, и злая математика. Основная проблема была в скорости, но V8 хорошо подсобил.
Проблемы нет, потому что есть подходы, наработки и традиции, которые позволяют строить архитектуру правильно. Что такое «правильно» — сильно зависит от проекта, поэтому тут лучше говорить предметно.
Вы говорите, вам понравился подход Erlang'а — замечательно, используйте его. Erlang обеспечивает полную изоляцию переменных, запрещая даже простейшее деструктивное присваивание — изолировано все от всего, не важно внутреннее оно или принадлежит обработчику. Для нормальной скорости работы это требует суровых оптимизаций, copy-on-write — наверное самая примитивная из них.
На C++ такое реализовать будет непросто. Но запрещать принципиальную возможность «сделать не так» не обязательно, часто достаточно соглашений. Или используйте языки со встроенным нужным подходом — Erlang далеко не единственный предоставляет изоляцию, почти любой язык из семейства функциональных поступает подобным образом. Почитайте доклад Валкина, может под ваши задачи хорошо ляжет тот же OCaml. На C++ свет клином не сошелся.
Проблема в том, что исполняющий движок что JS, что питона, что многих других языков, в текущей реализации будет ждать возврата из библиотечной функции, заблокировав исполнение в том числе других нитей — в каждый момент времени только одна нить может что-то делать и она «как-бы делает». Неблокирующие вызовы должны позволить продолжать исполнение других нитей во время ожидания ввода-вывода и прочего подобного, когда на самом ничего могущего помешать другим нитям не происходит.
Анонимные колбэки — очень большое добро при правильном использовании. У меня куча кода под рукой, который без них выглядел бы куда более страшно и убого.
Сигнал-слот — хорошая абстракция, но тяжеловесная, не всегда удобная.
Но энергии от соединения водорода и кислорода обратно в воду при сгорании мы получим не больше, чем потратим на гидролиз, пусть даже суперэффективный.
Разве нет?
«Bespin started as part of Mozilla Labs and was based on the canvas tag, while Ace is the Editor component of the Cloud9 IDE and is using the DOM for rendering.»
Видимо, что-то не пошло у них с канвасом.
Но там редактор исходников, а у вас — документов, что прилично сложнее. По части редактора документов с таким подходом, пожалуй, действительно первые )
Интересно, что книга написана в начале 80х. Прочесть можно здесь.
Необходимость четкого знания диковинных правил работы парсера с переводами строк и точками с запятой — недостаток дизайна языка.
Таких недостатков в JS очень много. Вообще, JS легко позволяет писать ужасный, плохо читаемый и практически неподдерживаемый код. Но есть способ с этим справляться. Достаточно придерживаться простых соглашений. Эти соглашения, кроме прочего, позволяют не держать в голове сложные правила, о которых неприятно помнить и в которых легко ошибиться.
Нельзя недооценивать необходимость и силу соглашений. JS, как и Python, построены по принципу «соглашения важнее ограничений». Эти языки содержат очень мало запретов, в надежде, что вы достаточно ответственны, чтобы не делать зла. Это обеспечивает невероятную свободу и гибкость. Это же делает соглашения неотъемлемой частью таких языков.
Касательно топика.
Ставить точки с запятой проще, чем держать в голове правила, когда их можно опустить. Это делает жизнь приятнее. В том числе в плане прочтения кода — не ломаешь голову, здесь возможная ошибка или так и задумано.
Знать те два с половиной случая, когда переводы строк в JS опасны — придется. Это недостаток языка. Не слишком приятный, но терпимый.
Знать все особенности парсинга, к счастью, необязательно. Но хотя бы раз в жизни поинтересоваться ими полезно.
Стиль написания, требующий глубокого знания предмета без особых плюсов на выходе — не повод для гордости. Гораздо ценнее мастерство, делающее вещи проще. Автора извиняет то, что npm прекрасен. Но будь он ближе к общепринятым соглашениям, было бы еще лучше.
В то же время, отлично понимаю раздражение автора. Люди, учащиеся на шаманских ресурсах, которых развелось сверх меры, никогда не заглядывающие ни в спеку, ни в действительно хорошие примеры кода, влегкую выбешивают своими суевериями )
Мои знания по теме поверхностны.
«Система неустойчива к сплитам» как раз и означает, что как только сплит — мы ничего не гарантируем. Все в силе только «пока сплита нет».
Представьте, вам предлагают построить дом, в котором ничего не сделано для защиты от ураганов. Пока урагана нет — все хорошо. Как только ураган — вам ничего не гарантируют.
Купите вы такой дом? — Почему бы и нет, если вы живете не в Канзасе и про ураганы разве что читали в «Волшебнике Изумрудного города».
Или вы станете «оценивать по худшей ситуации» и жить в бункере с защитой от цунами, взрывов водородной бомбы и пятью линиями вооруженной охраны, испытывая все связанные с таким непростым местом жительства неудобства?
Цитирую статью по вашей ссылке: «Nevertheless, no quorum algorithm can provide an absolute guarantee of this property in the presence of arbitrary failures. Different quorum implementations provide different degrees of certainty for any given configuration and set of expected failures.»
Именно про простейший вариант кворума написано в «лирическом отступлении». Читайте внимательнее.
Похоже, выборка получилась несколько однобокая, во многом из сегмента «для тех, кто (жестко) экономит»
Отсутствие деструктивного присваивания, немутируемые в принципе данные, общение между потоками только посылкой сообщений, на каждом шагу возникает необходимость создания компонентов в виде мини-серверов, ужасающая рудиментарная поддержка объектности… Список можно продолжить.
Эти ограничения заставляют решать задачи определенным способом, который как правило и является правильным, если только вы не пытаетесь сделать что-то, для чего язык совершенно не предназначен. Но это ограничивает область его применения.
Да что тут рассуждать, напишите на эрланге пару-тройку проектов, хотя бы и учебных — это даст вам понимания на два порядка больше чем самая заумная статья.
Про ноду говорить не совсем верно, правильнее про JS. А он зарекомендовал себя как вполне универсальный — чего только на нем не пишется и все вполне удобно и успешно. И серверные решения, и GUI, и злая математика. Основная проблема была в скорости, но V8 хорошо подсобил.
Вы говорите, вам понравился подход Erlang'а — замечательно, используйте его. Erlang обеспечивает полную изоляцию переменных, запрещая даже простейшее деструктивное присваивание — изолировано все от всего, не важно внутреннее оно или принадлежит обработчику. Для нормальной скорости работы это требует суровых оптимизаций, copy-on-write — наверное самая примитивная из них.
На C++ такое реализовать будет непросто. Но запрещать принципиальную возможность «сделать не так» не обязательно, часто достаточно соглашений. Или используйте языки со встроенным нужным подходом — Erlang далеко не единственный предоставляет изоляцию, почти любой язык из семейства функциональных поступает подобным образом. Почитайте доклад Валкина, может под ваши задачи хорошо ляжет тот же OCaml. На C++ свет клином не сошелся.
Есть конструктивные предложения?
Сигнал-слот — хорошая абстракция, но тяжеловесная, не всегда удобная.
Всему свое место.
Вот слово function — действительно длинновато :-)