Научный код

[Programer]

Pphantom в сообщении #1545879 писал(а):

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

Если ПО с открытым кодом будет написано научным институтом и код будет заверен цифровой подписью директора института, причём ЦП получена в государственном центре сертификации, то оно будет вызывать какое-то доверие.

[Dan B-Yallay]

Programer в сообщении #1545884 писал(а):

Если ПО с открытым кодом будет написано научным институтом и код будет заверен цифровой подписью директора института, причём ЦП получена в государственном центре сертификации, то оно будет вызывать какое-то доверие.

https://youtu.be/aARqAfpKNjc

[Progger]

worm2 в сообщении #1545880 писал(а):

Я не могу понять одну вещь касательно JS-опенсорса. Зачем вообще ССЫЛАТЬСЯ на чужой репозиторий, непонятно кем разработанный, и который непонятно в какой (т.е. в любой) момент может непонятно кто сломать??? Какая такая религия запрещает просто СКОПИРОВАТЬ код себе?

Есть проблема с зависимостями - один пакет может зависеть от нескольких других. Соответственно придётся скопировать к себе и их. В JS при импорте одного пакета спокойно может подтянуться десятки зависимостей. И потом в ручную это всё обновлять просто замучаешься. Естественно такая ситуация многих не устраивает и с этим пытаются как-то бороться.

[Pphantom]

Programer в сообщении #1545884 писал(а):

Если ПО с открытым кодом будет написано научным институтом и код будет заверен цифровой подписью директора института, причём ЦП получена в государственном центре сертификации, то оно будет вызывать какое-то доверие.

Мда... ясно. Как говорил один персонаж, "больше вопросов не имею".

[Progger]

Programer в сообщении #1545872 писал(а):

Если в коммерческом ПО после обновления вылез баг, то по письму от законного пользователя его оперативно исправляют.

Оперативно

Цитата:

В техподдержке Acura рассказали, что проблема затронула много машин с 2008 по 2013 годы выпуска. Производитель в курсе инцидента, но выпустит обновление для устранения бага в лучшем случае лишь в августе.

[mustitz]

Programer в сообщении #1545572 писал(а):

Тоже около 15 лет в IT-индустрии. И скажу, что таких ошибок как в двух приведённых примерах в коммерческом коде опытным разработчикам не прощают.

У меня 25+ дет в IT-индустрии, и мой опыт говорит о том, что любой программист может совершить любую глупую ошибку. Хотя бы потому, что код не пишется линейно и сразу. Допустим была старая версия функции. Потом пришла идея что-то улучшить, добавить новые возможности, для чего надо сделать, скажем пять изменений. А программист внёс четыре, а пятое забыл. И да, может выглядеть очень глупо, то даже пройти какие-то тесты :) И это не говоря о том, что во многих местах (&= вместо tt]&&=[/tt]) это может быть банальной опечаткой. Не да, такие уж языки C/C++, что случайное удаление/замена/вставка одного символа может привести к неверной программе без каких-либо предупреждений. Уже в Pascal/Ada этого добиться сложнее, но это немного другой разговор. И это всё выглядит как скрытая реклама какого-то статистического чекера, ибо на другом форуме он же использовался для того, чтобы ругать OpenSource с аналогичными аргументами: люди ошибаются. Да, ошибаются.

-- 12.01.2022, 09:56 --

Programer в сообщении #1545629 писал(а):

Хороший код определить сложнее. Есть книга «Совершенный код». То что соответствует всем требованиям из неё можно считать хорошим кодом.

Ну.... Я рассматриваю эту книгу больше как рекомендации одного человека с экспертизой в достаточно узкой области (заимоствованное из Симулы ООП с небольшими методами, для решения бизнес задач), где-то выражающей личные вкусы автора. В каком-нить embedded на Си многие рекомендации будут выглядеть откровенно говоря вредными. Или для алгоритмических расчётов. Например, не использовать сокращения в мире, где как-то точно назвать сущность может быть весьма проблематичным. Нет, я видел, конечно, небольшие рассказы я именах методов (более 50-ти символов) в коммерческом, кстати, коде, но не считаю это хорошей практикой. Ну а так я даже встречал развитие этой идеи и даже требование переписать все учебники по математики и по физике с внятными именами идентификаторов :)

-- 12.01.2022, 10:06 --

ozheredov в сообщении #1545677 писал(а):

Хороший код - это такой код, при прочтении которого в общем и среднем некая референсная группа "нормальных программиздов" сможет наиболее быстро ответить на три вопроса:

Интересно, как набирать референсную группу? Если мне показать какой-нить код из мира Java с равиоли из классов, я буду ругать его на чём свет стоит, и взяд ли смогу ответить на большую часть вопросов за вменяеое время. Зато если мне дать код какого-нить модуля ядра Linux, где будут методы 500+ строчек, я в нём буду ориентироваться намного лучше и комфортнее. С другой стороны, для какого-нить разработчика .NET ситуация может быть ровно наоборот. Само определение «нормальности» оно субъективно, и часто это «я и все кто разделяет мою точку зрения, нормальны» :)

-- 12.01.2022, 10:20 --

worm2 в сообщении #1545880 писал(а):

Я не могу понять одну вещь касательно JS-опенсорса. Зачем вообще ССЫЛАТЬСЯ на чужой репозиторий, непонятно кем разработанный, и который непонятно в какой (т.е. в любой) момент может непонятно кто сломать??? Какая такая религия запрещает просто СКОПИРОВАТЬ код себе? (при необходимости — периодически копировать изменения из апстрима, разумеется, если они успешно пройдут тестирование).

Потому что это делает менеджер пакетов, и в том числе управляет зависимостями. Очень может быть, что этот пакет используешь не напрямую, а какой-то другой пакет, который тоже использует не напрямую. Можно, конечно, следить за всеми версиями пакетов и зависимостями руками, но тогда увеличивается шансы отстать и привязаться до конкретной версии (аврал какой-нить). И если в зависимостях сотни пакетов, то тестирование каждого тоже куча труда. Ну а так мейнтейнеры менеджера пакетов следят за тестами сами, чтобы пакеты были минимально совместимы. Ну а проблема была в том, что спамилось куча сообщений в логи, на тесты она врядли сильно повлияла.

[photon]

Не в тему сравнения научный vs коммерческий, поднятую ТС, но по заголовку темы "Научный код" у меня возник такой вопрос.

В научных статьях, посвященных тем или иным алгоритмам, часто проводят сравнение с другими алгоритмами, известными до этого. Сравнивают по разным метрикам, в том числе по времени вычислений. Мне дважды доводилось оптимизировать код, выложенный в открытом доступе, реализующий алгоритмы из определенных статей. Результат был подходящим, а время работы - нет. В обоих случаях выложенный код в ходе оптимизации переписался чуть более, чем почти полностью, на что было потрачено по 1-2 месяца работы. Не акцентируя внимание на стиль, на присутствовавшие ошибки, которые могли приводить к утечкам памяти и т.п., скажу только о времени.

Для первого алгоритма не могу сравнить "было" и "стало" на одинаковых данных, но, что помню: в исходном варианте на моем PC для картинки 5Mpx (количество операций этого алгоритма пропорционально размеру изображения) было более 20с, после оптимизации на моем телефоне (тогда он был примерно в полтора раза медленнее PC) картинка 16Mpx обрабатывалась порядка 200мс.

Для второго алгоритма на одном и том же устройстве и на одних и тех же входных данных время вычисления уменьшено с 20+мин до ~3с.

В обоих случаях все вычисления оставались на CPU (правда, для первой задачи часть вычислений распараллелилась между ядрами).

То есть в обоих случаях при одном и том же алгоритме, но реализованном разными людьми, перед которыми стояли разные цели, разница во времени обработки в сотни раз. При этом я не могу сказать, что исходных код был совсем ужасен, - доводилось видеть и похуже. После этого, что я могу думать о табличках, как например Table 5 тут: https://web.cse.ohio-state.edu/~wenger.4/publications/isomesh.pdf?

Собственно, вопрос: насколько вообще правомерно приводить такие сравнения и доверять им, какие метрики могут быть информативны в этом плане? По-моему мнению, можно говорить об алгоритмической сложности, о каком-то минимальном числе операций, о минимальном объеме памяти, ниже которых для заданного алгоритма нельзя опуститься и т.п., в крайнем случае, можно сравнивать конкретные реализации (то есть при сравнении ссылаться не на статью, по которой написан код, а на сам код), но говорить о конкретных временах работы, просто ссылаясь на статью, по которой написан код, пусть и с одинаковыми входными даннами на одном и том же железе - какая-то профанация.

[ozheredov]

Mental в сообщении #1545588 писал(а):

В коммерческих компаниях качественным кодом, считается код который Team lead смержит в master

+++++

[Programer]

ozheredov
Team lead далеко не самостоятельное лицо. Коммерческий код проходит автоматическое и ручное тестирование, код-ревью, только потом тимлид его просматривает и фиксирует в СКВ. Подавляющее число коммерческих компаний работают по методологии SCRUM спринтами по 2 недели. Это позволяет в кратчайшие сроки выявить любой баг и ликвидировать его без существенной переделки коммерческого кода.

[EUgeneUS]

Programer в сообщении #1546422 писал(а):

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

SCRUM "позволяет" много чего, но только не то, что написано выше.

[Osmiy]

Programer в сообщении #1546422 писал(а):

Подавляющее число коммерческих компаний работают по методологии SCRUM спринтами по 2 недели.

Точно троль с Исходников. Выгнали, что ли, оттуда?

[Pphantom]

Да, кажется, пора закругляться. Programer - бан за систематический бред в различных темах.

[rockclimber]

wrest в сообщении #1545868 писал(а):

Но тем не менее - так тоже может быть.

Это еще ерунда. Я далек от фронт-энд разработки, но знающие люди говорят, что вот так - тоже может быть. А это уже немного другой уровень.