Я догадывался, что фотоны разной энергии могут проходить через разные пути биосинтеза, но не думал, что они таки обширны. Вы не подскажете, где можно об этом подробнее почитать?
Что-то мне подсказывает, что купить отдельно синие и красные светодиоды будет на порядок дешевле. Рынок фиолетовых светодиодов строго меньше рынка для ширпотребных красных и синих, конкуренции меньше. Вопрос только в том, отобьёт ли такое разделение стоимость изготовления (пайки, например). Я мог бы посчитать, только это будет сильно зависеть от доступных поставщиков (полагаю, в Москве и Перми их список будет существенно различаться), поэтому оставлю эту задачу заинтересованному читателю.
Рыбам тоже не должны быть вредны, потому что загрязнение водоёмов инсектицидами тоже является серьёзной проблемой. Вопрос только в том, есть ли в РФ государственное регулирование этого момента. Кроме того, убивать всех насекомых тоже никому не нужно, потому что хищные клещи и божьи коровки как раз поедают опасную для растений фауну. Поэтому лучше просто почитать о воздействии разных инсектицидов на окружающую среду и выбрать наиболее таргетированные.
И это не учитывая тот факт, что R&D входить в стоимость не всегда должен, поскольку приводит к неоправданному обогащению. Да, нужно отбить стоимость разработки. Что-то мне подсказывает, что эти конторы не торопятся исключать из цены продукции стоимость R&D после того, как они эту стоимость отбили, и получают сверхприбыль.
Особенно этим пользуются ребята вроде фармацевтических компаний, монополизируя новые полезные виды лекарств и продавая их по многократно завышенным относительно себестоимости ценам, оправдывая это тем, что R&D тоже денег стоит. Только почему-то в Forbes фигурируют фамилии владельцев.
Такой ерунде новоприбывшие коллеги обучаются максимум со второго тыканья носом.
Обычно таких правил целая пачка. Я уже видел проекты, где эти «тыканья носом» продолжаются месяцами. Всё из-за того, что используются ущербные технологии, в которых удобство для программиста не находится на первом месте, а эта ущербность восполняется не менее ущербными административными решениями.
Заодно можно найти тех, кому удобно читать текст длинными строками, а не колонками (у человеков с этим проблемы, им почему то удобен spritz).
А потом найти хотя бы одну книгу по матану поверх spritz. К сожалению, код это вам не худлит, он всегда читается с использованием мозгов, длина строк со сложностью прочтения коррелирует не так уж и сильно (если не говорить про вырожденные случаи вроде однострочных программ, которые никто в продакшен и так не напишет).
Впрочем, длинные строки говорят не о том, что «кто-то тут не умеет оформлять», а о том, что тут ORM с использованием method chaining вместо хорошего набора комбинаторов. ПО плохое, как всегда.
Замечание: класс объектов обычно не является множеством в смысле аксиоматической теории множеств. Категория, в которой объекты составляют множество, называется малой. Кроме того, возможно (с небольшим исправлением определения) рассмотрение категорий, в которых морфизмы между любыми двумя объектами также образуют класс, или даже большую структуру. В этом варианте определения категория, в которой морфизмы между двумя зафиксированными объектами образуют множество, называется локально малой.
Вы всё же определитесь, была ли это провокация или начало конструктивной дискуссии.
Программисты же обычно люди рациональные, и не выбирают языки программирования, пользуясь метриками вроде «круто». Если у вас есть более конкретный вопрос, я мог бы вам на него ответить.
Хорошо, что вы спросили, зачем нужно лямбда-исчисление. Это одна из самых удобных формализаций вычислительного контекста с точки зрения размера и формальности доказательств с её использованием. Правила редукции на основе какой-нибудь машины Тьюринга выглядят крайне синтетическими, и содержат больше бесполезных подробностей нежели смысла. Во многих ВУЗах и теорию множеств не рассказывают, но от этого никак не изменится тот факт, что она крайне удобна в качестве оснований математического анализа и других разделов математики.
Реляционная алгебра или реляционное исчисление? Реляционное исчисление кортежей или исчисление доменов? В каких именно приложениях вы их использовали, и когда они оказались вам полезны? Как вы можете утверждать, что «реляционный калькулус» полезнее лямбда-исчисления, если вы его не знаете?
Кстати, забавно, как наша аудитория расставляет минусы одному из известных популяризаторов функционального программирования в нашей стране, исключительно из того, что с ним не согласна.
А ещё лучше взять Седжвика. Это один из учеников Кнута, считающий, что изложение должно быть максимально доступным. Без десятеричных ассемблеров MIX и конкретной математики в качестве разгрузочных упражнений.
Думаю, можно сделать CreateFile напрямую на \\.\PhysicalDrive#. Если при этом ещё и драйвер написать на основе стандартного примера ramdisk, то можно пользоваться диском как будто он вообще нормальный.
Если говорить про более старые версии IE, то необходимость отлаживать исходный код сугубо из-под IE может быть связана только с тем, что не использованы fallback/shim библиотеки для работы с некоторым функционалом с плохой кросс-браузерностью. Разработчиков таких библиотек, конечно, уже ничего не спасёт, но я пока не слышал ни об одной библиотеке в духе jQuery или es5-shim, написанной на TypeScript.
Если source map не доступен, нужно сделать его доступным. У разработчика есть возможность, у остальных нет необходимости.
Если транслятор статически типизированного языка не даёт гарантий относительно качества target кода, то транслятору место на свалке истории. Даже в C/С++ с их чудесами при наличии undefined behaviour в коде никогда не нужно отлаживать ассемблер. Если такие ситуации возникают, то вместо отладки транслированного кода нужно создавать тикеты вот здесь.
Я бы даже сказал, что он в этом плане довольно плох, и я бы предпочёл куда более строго типизированный PureScript. Но это уже намного лучше, чем типизация JS с её сплошным WAT.
Не думаю, что сейчас есть хоть один транслятор, способный на это. У всех существующих есть ошибка в реализации разных моментов языка, от встроенных массивов размерности больше 1 до полного отсутствия атрибутов и рефлексии. Крупные проекты обычно хоть что-нибудь из этого используют, а поэтому не транслируются.
Трансляция LLVM в asm.js не предполагает читаемости, поскольку asm.js сделан не для людей. У таких модулей всегда есть исходный код (в данном случае C#), и есть чёрный ящик на JS с известным нам API.
Мне кажется, вам просто более привычен подход TypeScript «давайте сделаем выдачу читаемой». Я как раз никогда не мог понять, зачем это нужно. Вы не могли бы объяснить?
Если вас интересует серверный JS, то есть библиотека edge, которая позволяет делать интероп между кодом на C# и JS без всякой трансляции.
Если же говорить именно про Duocode, то тут всё странно. В официальном FAQ есть только про вызовы C# из JS, а для всего остального они вроде бы написали врапперы. Всегда можно, конечно, посмотреть, как они делают эти врапперы, но есть более прямолинейный подход. Вы можете в своём коде при инициализации получить объект со списком лямбда-функций. Когда JS вызывает ваш код на C#, он передаёт в него ссылки на все необходимые функции, и вы их потом вызываете.
Но я бы не стал использовать Duocode, пока не появится серьёзных портов чего-нибудь с C# в браузер. Все существующие трансляторы (Netjs, IL2JS) так и не были доведены до конца вследствие технических сложностей такой реализации.
Предлагаете найти программу, которая позволяет подобным образом делать merge?
Описанный в статье подход плох тем, что он unenforceable. Нельзя сделать формальную метрику «длина строки не более 40 символов», засунуть её в git hook и надеяться на то, что ни у кого не появится необходимости действительно сделать такую строку. Без формальных метрик этот подход особенно плох, потому что новоприбывшие коллеги всегда будут ошибаться.
Есть только одно хорошее решение. Нужно использовать хороший софт, и не подстраиваться под плохой.
Вот авторы использовали лямбда-функцию со своим ORM, и получили серьёзные проблемы с производительностью. Тем не менее, если бы ORM через рефлексию подобные лямбды переводил в SQL, или если бы он делал custom SQL functions, или хотя бы выдавал предупреждение «осторожно, таблица будет загружена целиком», таких проблем бы вообще не возникало.
Но авторы пошли путём Роскомнадзора, (почти) решили проблему административно, продолжив использовать низкокачественное ПО.
Особенно этим пользуются ребята вроде фармацевтических компаний, монополизируя новые полезные виды лекарств и продавая их по многократно завышенным относительно себестоимости ценам, оправдывая это тем, что R&D тоже денег стоит. Только почему-то в Forbes фигурируют фамилии владельцев.
Обычно таких правил целая пачка. Я уже видел проекты, где эти «тыканья носом» продолжаются месяцами. Всё из-за того, что используются ущербные технологии, в которых удобство для программиста не находится на первом месте, а эта ущербность восполняется не менее ущербными административными решениями.
А потом найти хотя бы одну книгу по матану поверх spritz. К сожалению, код это вам не худлит, он всегда читается с использованием мозгов, длина строк со сложностью прочтения коррелирует не так уж и сильно (если не говорить про вырожденные случаи вроде однострочных программ, которые никто в продакшен и так не напишет).
Впрочем, длинные строки говорят не о том, что «кто-то тут не умеет оформлять», а о том, что тут ORM с использованием method chaining вместо хорошего набора комбинаторов. ПО плохое, как всегда.
Неужели так сложно хотя бы прочесть определение?
Программисты же обычно люди рациональные, и не выбирают языки программирования, пользуясь метриками вроде «круто». Если у вас есть более конкретный вопрос, я мог бы вам на него ответить.
Реляционная алгебра или реляционное исчисление? Реляционное исчисление кортежей или исчисление доменов? В каких именно приложениях вы их использовали, и когда они оказались вам полезны? Как вы можете утверждать, что «реляционный калькулус» полезнее лямбда-исчисления, если вы его не знаете?
Кстати, забавно, как наша аудитория расставляет минусы одному из известных популяризаторов функционального программирования в нашей стране, исключительно из того, что с ним не согласна.
Если говорить про более старые версии IE, то необходимость отлаживать исходный код сугубо из-под IE может быть связана только с тем, что не использованы fallback/shim библиотеки для работы с некоторым функционалом с плохой кросс-браузерностью. Разработчиков таких библиотек, конечно, уже ничего не спасёт, но я пока не слышал ни об одной библиотеке в духе jQuery или es5-shim, написанной на TypeScript.
К сожалению, от разработчика всегда всё зависит.
Если source map не доступен, нужно сделать его доступным. У разработчика есть возможность, у остальных нет необходимости.
Если транслятор статически типизированного языка не даёт гарантий относительно качества target кода, то транслятору место на свалке истории. Даже в C/С++ с их чудесами при наличии undefined behaviour в коде никогда не нужно отлаживать ассемблер. Если такие ситуации возникают, то вместо отладки транслированного кода нужно создавать тикеты вот здесь.
Мне кажется, вам просто более привычен подход TypeScript «давайте сделаем выдачу читаемой». Я как раз никогда не мог понять, зачем это нужно. Вы не могли бы объяснить?
Если же говорить именно про Duocode, то тут всё странно. В официальном FAQ есть только про вызовы C# из JS, а для всего остального они вроде бы написали врапперы. Всегда можно, конечно, посмотреть, как они делают эти врапперы, но есть более прямолинейный подход. Вы можете в своём коде при инициализации получить объект со списком лямбда-функций. Когда JS вызывает ваш код на C#, он передаёт в него ссылки на все необходимые функции, и вы их потом вызываете.
Но я бы не стал использовать Duocode, пока не появится серьёзных портов чего-нибудь с C# в браузер. Все существующие трансляторы (Netjs, IL2JS) так и не были доведены до конца вследствие технических сложностей такой реализации.
Описанный в статье подход плох тем, что он unenforceable. Нельзя сделать формальную метрику «длина строки не более 40 символов», засунуть её в git hook и надеяться на то, что ни у кого не появится необходимости действительно сделать такую строку. Без формальных метрик этот подход особенно плох, потому что новоприбывшие коллеги всегда будут ошибаться.
Есть только одно хорошее решение. Нужно использовать хороший софт, и не подстраиваться под плохой.
Вот авторы использовали лямбда-функцию со своим ORM, и получили серьёзные проблемы с производительностью. Тем не менее, если бы ORM через рефлексию подобные лямбды переводил в SQL, или если бы он делал custom SQL functions, или хотя бы выдавал предупреждение «осторожно, таблица будет загружена целиком», таких проблем бы вообще не возникало.
Но авторы пошли путём Роскомнадзора, (почти) решили проблему административно, продолжив использовать низкокачественное ПО.