Жестоко, но на самом деле было бы очень хорошо, если бы тех программистов признали виновными (желательно вместе с начальниками конечно). В следующий раз задумавшим пакость будет гораздо труднее найти исполнителей.
Отмазка «я просто выполнял приказ» не действует даже в отношении военных, почему другие профессии должны быть исключением?
Посмотрите внимательно, Вы просто повторили мою фразу другими словами.
И этот чиновник предлагает не вкладываться в военную сферу, он предлагает применять военную силу для насильного сбыта заведомо худшей продукции. Что я и выразил меньшим количеством слов.
А чем OpenSource тут поможет? Почему-то представляется такая картина:
«Тэ-э-экс, что это тут у вас установлено? Дебьян какой-то? Ничего не знаю, в реестре патриотичного софта не значится, выписываем штраф. Кстати, есть прекрасная отечественная система БолгенОС, не желаете приобрести за нескромную цену? Впрочем, выбора у вас всё равно нет.»
Все эти ревнители отечественного почему-то говорят, что после запрета импортных товаров российский Левша засучит рукава и сделает нечто сногсшибательное. А на практике получается, что в отсутствии конкуренции Левши начинают халтурить ещё больше, продавая брак по монопольным ценам.
Да, наверное Вы правы, но только «водораздел» видимо проходит не по высокоуровневым языкам.
Значение имеет на какие машины ориентируется программист при написании кода. Скажем, если мы ориентируемся на массовую параллельность, то даже если на одной машине код работает в 10 раз медленнее, но отлично масштабируется с увеличением числа станций — то такое решение даже может быть предпочтительнее.
Но в то, что программист может обитать в прекрасном мире абстрактных парадигм а компилятор за него думает об оптимизации я не верю.
Спасибо за ответ, интересно. Что касается примера, то я привёл его специально чтобы показать, что абстрактная и «красивая» концепция ООП, так сказать, в реальном мире имеет свою стоимость и ограничения. И об этом приходится думать при программировании и временами отказываться от «красивого» с точки зрения концепции кода.
Можно ещё вспомнить о «красивых» рекурсивных решениях (вроде стандартного вычисления чисел Фибоначчи), которые в реальном мире и на реальном железе работают не очень.
Соответственно о стоимости ФП тоже очевидно придётся думать при программировании. Только поскольку я не знаком с ФП, я совершенно не знаю как принимаются подобные решения.
Хорошо, давайте. Например, при написании программы на языке с ООП мы знаем, что есть затраты на вызов виртуальных методов. Поэтому не очень хорошая идея засовывать тысячи объекты в контейнер и проходить по ним циклом с вызовом виртуальных методов, а ля
for ( baseObj: array )
{
baseObj->foo();
}
В данном случае лучше переписать эту часть, выделив функцию foo из класса, чтобы она работала сразу с коллекцией объектов.
foo( array );
Таким образом мы избегаем ненужных трат на поддержку ООП, хотя в общем-то и в первом случае код выглядит логичным и «правильным» (просто будет более медленным).
Существуют ли подобные правила для написания эффективного кода на функциональных языках?
Извиняюсь за настойчивость, но я так и не получил ответа на вопрос, как именно программист на функциональном языке выбирает как ему написать эффективную программу? Неужели ответ — швырять любой, логически правильный код в очень умный компилятор и ждать что он сгенерирует оптимальный машинный код?
Вы сейчас описываете использование готовых алгоритмов из библиотек, я прав? В таком случае конечно не имеет значения на чём там код написан.
Проблему вижу в накладных расходах на всю эту магию. Скажем, ООП тоже совсем не бесплатное.
И в целом есть плохие способы писать код на императивном языке (в плане быстродействия), есть хорошие, и можно объяснить чем одни отличаются от других, на что тратятся циклы процессора. В случае ФП я не понимаю как отличить быстрый код от медленного и возможно ли это в принципе, чем руководствуются программисты на ФП при выборе способа написания программы и.т.д. Просто у меня из статьи сложилось впечатление (возможно обманчивое), что предлагается откинуться на спинку стула и не думать о быстродействии, потому что современные компьютеры такие быстрые-пребыстрые.
Может кто-то из гуру ФП рассказать, как прогнозировать время работы программы на функциональном языке? То есть можно ли в общем случае глядя на код двух разных программ понять, какая из них будет работать быстрее?
Потому что в импертивном языке, даже щедро присыпанном ООП можно прикинуть быстродействие программы (в случае многопоточности всё конечно усложняется).
А в случае ФП у меня сложилось впечатление, что да, программа это волшебный свиток написанный красивыми рунами, и как оно там выполнится и во что развернётся на железе — не знает даже автор.
Зато вы не тратите столько времени и сил на стирку, приготовление пищи, и уборку как, например, в начале ХХ века. Ну и живётё вы, скорее всего, в отдельной квартире. И мясо, наверное, каждый день кушаете. И можете путешествовать в любую точку Земли, а не смотреть всю жизнь до могилы на местность рядом с работой.
Самое смешное, что конечно никак «сомнений» и «протестов» он высказывать не мог бы, потому что подписывал кучу бумажек о гостайне. Весь этот бред от ГосДепа означает «Делай свою работу молча или уходи. Если ты расскажешь о наших грязных делах — мы тебя достанем.».
Хотелось бы узнать о тех случаях, когда компилятор «не справляется» с автоматической генерацией выровненных инструкций. Помимо случаев, когда размер определяется динамически в рантайме, конечно.
Отмазка «я просто выполнял приказ» не действует даже в отношении военных, почему другие профессии должны быть исключением?
И этот чиновник предлагает не вкладываться в военную сферу, он предлагает применять военную силу для насильного сбыта заведомо худшей продукции. Что я и выразил меньшим количеством слов.
1. Россия обречена производить дерьмо по сравнению с США.
2. Силой оружия окунём в это дерьмо весь мир!
3. ???
4. ВЫГОДА!
«Тэ-э-экс, что это тут у вас установлено? Дебьян какой-то? Ничего не знаю, в реестре патриотичного софта не значится, выписываем штраф. Кстати, есть прекрасная отечественная система БолгенОС, не желаете приобрести за нескромную цену? Впрочем, выбора у вас всё равно нет.»
Все эти ревнители отечественного почему-то говорят, что после запрета импортных товаров российский Левша засучит рукава и сделает нечто сногсшибательное. А на практике получается, что в отсутствии конкуренции Левши начинают халтурить ещё больше, продавая брак по монопольным ценам.
Значение имеет на какие машины ориентируется программист при написании кода. Скажем, если мы ориентируемся на массовую параллельность, то даже если на одной машине код работает в 10 раз медленнее, но отлично масштабируется с увеличением числа станций — то такое решение даже может быть предпочтительнее.
Но в то, что программист может обитать в прекрасном мире абстрактных парадигм а компилятор за него думает об оптимизации я не верю.
Можно ещё вспомнить о «красивых» рекурсивных решениях (вроде стандартного вычисления чисел Фибоначчи), которые в реальном мире и на реальном железе работают не очень.
Соответственно о стоимости ФП тоже очевидно придётся думать при программировании. Только поскольку я не знаком с ФП, я совершенно не знаю как принимаются подобные решения.
for ( baseObj: array )
{
baseObj->foo();
}
В данном случае лучше переписать эту часть, выделив функцию foo из класса, чтобы она работала сразу с коллекцией объектов.
foo( array );
Таким образом мы избегаем ненужных трат на поддержку ООП, хотя в общем-то и в первом случае код выглядит логичным и «правильным» (просто будет более медленным).
Существуют ли подобные правила для написания эффективного кода на функциональных языках?
Проблему вижу в накладных расходах на всю эту магию. Скажем, ООП тоже совсем не бесплатное.
И в целом есть плохие способы писать код на императивном языке (в плане быстродействия), есть хорошие, и можно объяснить чем одни отличаются от других, на что тратятся циклы процессора. В случае ФП я не понимаю как отличить быстрый код от медленного и возможно ли это в принципе, чем руководствуются программисты на ФП при выборе способа написания программы и.т.д. Просто у меня из статьи сложилось впечатление (возможно обманчивое), что предлагается откинуться на спинку стула и не думать о быстродействии, потому что современные компьютеры такие быстрые-пребыстрые.
Потому что в импертивном языке, даже щедро присыпанном ООП можно прикинуть быстродействие программы (в случае многопоточности всё конечно усложняется).
А в случае ФП у меня сложилось впечатление, что да, программа это волшебный свиток написанный красивыми рунами, и как оно там выполнится и во что развернётся на железе — не знает даже автор.
Москва?