Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Часто код для научных расчетов пишут довольно сумбурно, к тому же те кто его пишут обычно не являются программиста по призванию. Поэтому часто встречается: люди не то что бы не хотят, они просто не понимают зачем и не знают как нужно писать документацию, не слышали про системы контроля версий, а часто просто напросто называют переменные и функции типа a,b,c.
Конечно есть крутые аспиранты которые сегодня уже стараются писать понятно, выкладывать код и всячески упрощают работу себе и другим, но по моим наблюдениям, научные работники старше 35-40 лет в 90% случаев чуть ли не специально всячески препятствуют не только распространению их кода но и читабельности.
Наверное это плохо но научная среда довольно инертна и очень тяжело принимает нововведения, даже самые маленькие. Например мне не удалось «подсадить» знакомых на dropbox, им почему то проще и понятнее ходить в универ что бы сбросить материалы через флешку, причем часто другой цели подобные путешествия дом-универ не ставят. Уходит куча времени на такие банальные вещи как синхронизация и разбор материалов, постановка задач: почему то нужно говорить лично, с глазу на глаз, скайп или какая-нибудь трекинговая система — адское изобретение которое нельзя даже рассматривать как альтернативу.
Все это конечно мои субъективные наблюдения.
Конечно есть крутые аспиранты которые сегодня уже стараются писать понятно, выкладывать код и всячески упрощают работу себе и другим, но по моим наблюдениям, научные работники старше 35-40 лет в 90% случаев чуть ли не специально всячески препятствуют не только распространению их кода но и читабельности.
Наверное это плохо но научная среда довольно инертна и очень тяжело принимает нововведения, даже самые маленькие. Например мне не удалось «подсадить» знакомых на dropbox, им почему то проще и понятнее ходить в универ что бы сбросить материалы через флешку, причем часто другой цели подобные путешествия дом-универ не ставят. Уходит куча времени на такие банальные вещи как синхронизация и разбор материалов, постановка задач: почему то нужно говорить лично, с глазу на глаз, скайп или какая-нибудь трекинговая система — адское изобретение которое нельзя даже рассматривать как альтернативу.
Все это конечно мои субъективные наблюдения.
>>>научная среда довольно инертна и очень тяжело принимает нововведения
Да она делает нововведения!
Да она делает нововведения!
У каждого своя специализация. Если человек занимается исследованием каких-нибудь аэродинамических свойств разных тел, на кой черт ему думать про комментарии к коду или про другие «мудреные» программные системы? Цель — смоделировать процесс, остальное -второстепенно.
Хотя бы потому, что в его коде может быть ошибка, и результаты эксперимента / моделирования будут неверными. Почему-то физики, когда строили коллайдер, делали это не сами (ну мы же занимаемся исследованием аэродинамических свойств частиц, на кой черт думать как котлован копать и стенки из труб варить) а заказали изгтовление специалистам.
Откуда у бедных аспирантов и их руководителей деньги за специалистов-программистов? :)
Видимо мы думаем о разных вещах.
Я пишу в большей мере о рядовых исследователях которых тысячи, а так же больше с уклоном в СНГ.
О каком найме специалистов может идти речь, если иногда не хватает стола для рабочего места? Вы привели исключение из правил. Исследований таких масштабов довольно мало на фоне общего числа «обычных». Да, науку двигают мега-личности и супер-корпорации/исследовательские центы. Но их единицы. В остальном мире исследователь — обычный человек который работает либо вообще один, либо в команде с 3-4мя такими же, обычными людьми. И рабочее место у них — не «мостик» исследовательского центра в засекреченной лаборатории за миллиарды долларов под землей, а обычный маленький, пыльный кабинет с одним настольным ПК.
Идем дальше. Вы считаете что теории должен выдвигать профессор, а программисты (которые специализируются исключительно на какой-нибудь технологии разработки) должны реализовывать программу для моделирования. Спешу вас огорчить. Почти всегда исследователь сам пишет код, пусть и криво, не профессионально, но сам. По одной простой причине: программист вряд ли сможет на 100% разобраться в передовых научных теориях за приемлемый срок (конечно если у вас не миллиардный бюджет и команда из сотни человек), в то же время исследователь в случае некорректной работы программы не сможет нормально объяснить в чем проблема, ведь это не бухгалтерское приложения где обычно всего несколько действий «плюс», «минус», «поделить».
Я пишу в большей мере о рядовых исследователях которых тысячи, а так же больше с уклоном в СНГ.
О каком найме специалистов может идти речь, если иногда не хватает стола для рабочего места? Вы привели исключение из правил. Исследований таких масштабов довольно мало на фоне общего числа «обычных». Да, науку двигают мега-личности и супер-корпорации/исследовательские центы. Но их единицы. В остальном мире исследователь — обычный человек который работает либо вообще один, либо в команде с 3-4мя такими же, обычными людьми. И рабочее место у них — не «мостик» исследовательского центра в засекреченной лаборатории за миллиарды долларов под землей, а обычный маленький, пыльный кабинет с одним настольным ПК.
Идем дальше. Вы считаете что теории должен выдвигать профессор, а программисты (которые специализируются исключительно на какой-нибудь технологии разработки) должны реализовывать программу для моделирования. Спешу вас огорчить. Почти всегда исследователь сам пишет код, пусть и криво, не профессионально, но сам. По одной простой причине: программист вряд ли сможет на 100% разобраться в передовых научных теориях за приемлемый срок (конечно если у вас не миллиардный бюджет и команда из сотни человек), в то же время исследователь в случае некорректной работы программы не сможет нормально объяснить в чем проблема, ведь это не бухгалтерское приложения где обычно всего несколько действий «плюс», «минус», «поделить».
Я не говорю «как надо». Я показываю слабые места текущей практики. И мне кажется, что описанная в статье инициатива может несколько уменьшить эту проблему — если код будет публиковаться на том же github, то профессионалы смогут время от времени смотреть на код своих… хмм… коллег и давать ценные рекомендации в виде pull request'ов.
Честно говоря вы только что описали суть статьи :)
Об этом и идет речь: если бы публиковали код, его могли бы поддерживать больше людей, и ошибок было бы меньше.
П.С. Ошибки в коде программ моделирования чаще всего кроются в алгоритмах (в которых исследователь обычно хорошо разбирается или вообще сам их создает).
Об этом и идет речь: если бы публиковали код, его могли бы поддерживать больше людей, и ошибок было бы меньше.
П.С. Ошибки в коде программ моделирования чаще всего кроются в алгоритмах (в которых исследователь обычно хорошо разбирается или вообще сам их создает).
ну слабые места уже давно известны, вот например публикация 2006 года: www.americanscientist.org/issues/pub/wheres-the-real-bottleneck-in-scientific-computing
мне очень хотелось ее перевести и засунуть в какой-нибудь читаемый российский журнал, но руки не дошли.
мне очень хотелось ее перевести и засунуть в какой-нибудь читаемый российский журнал, но руки не дошли.
ой, как я с вами не согласен. я вот пишу много не очень серьезного кода, простые скрипты, но то ли мозг так устроен, то ли объем информации с которой работаю большой — вообщем, я предпочитаю откомментировать все свои действия, чтобы потом самому же было легко читать, а уж тем более передавать его другому человеку.
Я написал как рассуждает большинство знакомых мне исследователей. Сам я безусловно против такой манеры написания программ.
Все против. Но все пишут. Точнее подавляющее большинство.
В том то и проблема, что код для исследования резко отличается от кода 99% программ. UI часто не нужен, важными являются производительность и простота. Часто даже от ооп следует отказаться и писать в стиле 90-х да еще и с асмовскими кусками, дабы код был максимально быстрым.
В конце концов — проверить идею чаще всего можно софтом до тысячи строк. Для таких объемов кода детальные и четкие комментарии часто ни к чему. Достаточно мелких пометок «на память». Если это исследование, а не разработка, то код может меняться по 10 раз на дню, комментировать — значит отвлекаться от основной задачи. Код вторичен. Это средство а не цель. А значит неважно как он будет сделан — дело вкуса, о которых не спорят.
В том то и проблема, что код для исследования резко отличается от кода 99% программ. UI часто не нужен, важными являются производительность и простота. Часто даже от ооп следует отказаться и писать в стиле 90-х да еще и с асмовскими кусками, дабы код был максимально быстрым.
В конце концов — проверить идею чаще всего можно софтом до тысячи строк. Для таких объемов кода детальные и четкие комментарии часто ни к чему. Достаточно мелких пометок «на память». Если это исследование, а не разработка, то код может меняться по 10 раз на дню, комментировать — значит отвлекаться от основной задачи. Код вторичен. Это средство а не цель. А значит неважно как он будет сделан — дело вкуса, о которых не спорят.
>а часто просто напросто называют переменные и функции типа a,b,c.
Кстати зачастую это не проблема «быдловатости» исследователей, а объективная проблема.
Почти никто не будет писать код вида energy = mass*speed_of_light^2. Всегда будет e = m*c^2.
Во первых, это больше визуально похоже на реальную «формулу из книжки».
Во вторых какая нибудь трехэтажная фурмула с 10-15 переменными, записанная в «правильных говорящих переменных» будет выглядеть как совершенно нечитаемое говно.
Кстати зачастую это не проблема «быдловатости» исследователей, а объективная проблема.
Почти никто не будет писать код вида energy = mass*speed_of_light^2. Всегда будет e = m*c^2.
Во первых, это больше визуально похоже на реальную «формулу из книжки».
Во вторых какая нибудь трехэтажная фурмула с 10-15 переменными, записанная в «правильных говорящих переменных» будет выглядеть как совершенно нечитаемое говно.
К сожалению в программах моделирования довольно редко встречаются формулы в таком простом, линейном виде. Чаще всего они как то хитро параллелятся, что-то численно интегрируется, отнимается, какие-то массивы куда-то записываются, как то хитро переставляются, умножаются и прочее. И проблема возникает в конце, когда все это сводится к простой формуле: где какой массив, что он содержит и почему называется как-нибудь типа re_dt_y_plte понять очень сложно.
Вы провоцируете.
try:
math.longfloat.mul(mass, math.longfloat.pow(phy.const.light.speed(phy.obj.vacuum),math.longfloat(2))
except Exception.Exception:
pass
Это в очередной раз наводит меня на мысли об удобной системе ввода символов Unicode. В IDE DrRacket можно через пункт меню вставить символ λ и использовать его вместо «ключевого слова» lambda для создания анонимных функций:
Только такой способ ввода очень медленный и не годится для нескольких символов, и уж тем более, десятков и сотен.
(map (λ (x) (* x x))
'(1 2 3 4))Только такой способ ввода очень медленный и не годится для нескольких символов, и уж тем более, десятков и сотен.
То, о чём вы говорите — это качество кода. И оно не может не сказаться в итоге на качестве исследования.
Отлично подсадил на dropbox своего научного руководителя — членкор НАНУ по экономике
когда другие экспериментаторы воссоздавали программный код по описанию алгоритма, они получали результаты, несколько отличающиеся от оригинальных результатов. Разбирательство показало, что причиной были ошибки в оригинальной программе
А если бы они взяли готовый код — они бы получили те же самые результаты, да, но они бы были точно так же ошибочны, как и в первый раз. ИМХО здесь простое копирование может быть даже вредным. А вот подробное описание алгоритма позволит выявлять ошибки и получать в самом деле не просто копии результатов, а результаты других исследований.
Описание только должно быть достаточно подробным, чтобы последователи могли без труда им воспользоваться и реализовать алгоритм.
В научной среде довольно распространена реализация алгоритма, даже если код уже написан. Именно для проверки. Так что с этим проблем не будет.
Тогда можно считать, что проблем и вовсе нет. Если все равно будут переписывать для проверки — можно не напрягать ученых комментариями, рефакторингом, архитектурой и всем остальным. Как выше заметили — им надо чтобы работало. А как там и что — зачастую никто не думает.
Кстати, если перед глазами есть готовый код — велик соблазн использовать его если не полностью, то хотя-бы частично. А это опять же может вредно. А когда перед глазами только алгоритм — уже не подсмотришь. Хотя может это я и перегибаю чуток.
Во всяком случае я бы так не формулировал, мол, или закрытый код или воспроизводимая наука.
Кстати, если перед глазами есть готовый код — велик соблазн использовать его если не полностью, то хотя-бы частично. А это опять же может вредно. А когда перед глазами только алгоритм — уже не подсмотришь. Хотя может это я и перегибаю чуток.
Во всяком случае я бы так не формулировал, мол, или закрытый код или воспроизводимая наука.
Во-первых результаты почти всегда разные: ошибки округления и другие подводные камни никто не отменял.
Во-вторых, как вы думаете, зачем придумали ООП? Ведь если вы используете чужой класс, а не пишете свой, тогда вы получите «точно также ошибочные резултаты»?
Короче говоря проверку кода никто не отменял, а писать одну и ту же программу для измерения силы трения, а потом точно такую-же для измерения той же силы трения но в других условиях или для других тел — по мне так маразм.
Во-вторых, как вы думаете, зачем придумали ООП? Ведь если вы используете чужой класс, а не пишете свой, тогда вы получите «точно также ошибочные резултаты»?
Короче говоря проверку кода никто не отменял, а писать одну и ту же программу для измерения силы трения, а потом точно такую-же для измерения той же силы трения но в других условиях или для других тел — по мне так маразм.
Во-первых результаты почти всегда разные: ошибки округления и другие подводные камни никто не отменял.
Вы имеете ввиду, что если код с ошибкой, то ошибки округления и другие другие подводные камни сделают результаты верными? Не думаю.
как вы думаете, зачем придумали ООП?
У меня можете не спрашивать. Я программист, а не ученый и я его использую, в отличии от многих ученых.
Короче говоря проверку кода никто не отменял
Вот только что вы писали про именование переменных и про подход к программированию и тут же себе перечите. Какая может быть проверка, если там лапша задача которой была запуститься и отработать один раз?
Проверять подобное будет сложнее, чем написать заново. Корректировать — невозможно.
Вы поняли все наоборот.
Я писал про печальную ситуацию которая есть сейчас (с переменными а, б, ц и прочим). И привел доводы почему нужно наконец начинать писать нормальный код с ООП(хотя и не всегда) и комментариями (что бы как раз можно было нормально проверять, рефакторить и изменять код).
Теперь по пунктам:
>Вы имеете ввиду, что если код с ошибкой, то ошибки округления и другие другие подводные камни сделают результаты верными? Не думаю.
Я имею в виду что если код работает правильно то результаты будут отличаться в любом случае. Погрешность всегда будет, от нее не избавиться.
> У меня можете не спрашивать. Я программист, а не ученый и я его использую, в отличии от многих ученых.
Я написал про ООП для того что бы показать, насколько удобно использовать наследование, вместо того что бы писать заново одно и то же. Вы его используете, а вот ученым нельзя и даже вредно, потому что в коде может быть ошибка? Какая то дискриминация, я бы сказал :)
> Вот только что вы писали про именование переменных и про подход к программированию и тут же себе перечите.
Уже ответил.
Я писал про печальную ситуацию которая есть сейчас (с переменными а, б, ц и прочим). И привел доводы почему нужно наконец начинать писать нормальный код с ООП(хотя и не всегда) и комментариями (что бы как раз можно было нормально проверять, рефакторить и изменять код).
Теперь по пунктам:
>Вы имеете ввиду, что если код с ошибкой, то ошибки округления и другие другие подводные камни сделают результаты верными? Не думаю.
Я имею в виду что если код работает правильно то результаты будут отличаться в любом случае. Погрешность всегда будет, от нее не избавиться.
> У меня можете не спрашивать. Я программист, а не ученый и я его использую, в отличии от многих ученых.
Я написал про ООП для того что бы показать, насколько удобно использовать наследование, вместо того что бы писать заново одно и то же. Вы его используете, а вот ученым нельзя и даже вредно, потому что в коде может быть ошибка? Какая то дискриминация, я бы сказал :)
> Вот только что вы писали про именование переменных и про подход к программированию и тут же себе перечите.
Уже ответил.
И привел доводы почему нужно наконец начинать писать нормальный код с ООП
Ну мне ваши доводы не нужны, а матерого математика, который вчера отметил выход на пенсию ваши доводы не убедят. Не надо оно ему — пересаживаться с привычного паскаля на что-то круто-мощно-модное и правильное. И переучиваться он не будет. И комментарии писать тоже. Не его это, он не программист.
Можете, конечно, попытаться его убедить.
Я имею в виду что если код работает правильно то результаты будут отличаться в любом случае.
А я про пример из статьи, когда в коде была ошибка, которая повторится у вторых экспериментаторов. Они получат тот же ошибочный результат и ошибка не будет обнаружена.
> Ну мне ваши доводы не нужны, а матерого математика, который вчера отметил выход на пенсию ваши доводы не убедят. Не надо оно ему — пересаживаться с привычного паскаля на что-то круто-мощно-модное и правильное. И переучиваться он не будет. И комментарии писать тоже. Не его это, он не программист.
Можете, конечно, попытаться его убедить.
Если вам не нужны мои доводы, зачем продолжать диалог? Ваша воля.
Можете, конечно, попытаться его убедить.
Если вам не нужны мои доводы, зачем продолжать диалог? Ваша воля.
> Вы имеете ввиду, что если код с ошибкой, то ошибки округления и другие другие подводные камни сделают результаты верными? Не думаю.
во-первых, проверить «верность» результата расчета очень сложно, если вообще возможно. неверность доказать гораздо реалистичнее.
во-вторых, авторы приводят ссылки на публикации в рецензируемых журналах, этим заявлениям я склонен доверять больше, чем вашим.
во-первых, проверить «верность» результата расчета очень сложно, если вообще возможно. неверность доказать гораздо реалистичнее.
во-вторых, авторы приводят ссылки на публикации в рецензируемых журналах, этим заявлениям я склонен доверять больше, чем вашим.
Ученый, который пишет программу для вычисления силы трения для конкретных, известных ему условий, учтет массу факторов, о которых его коллега, написавший «точно такую же» библиотечную программу, не подумал или счел несущественными — что-нибудь вроде зависимости от влажности, спектра вибраций, распределения площади микронеровностей в зависимости от их размера, и т.п. Даже если автор будет клясться, что его программа универсальна, другие ученые ему не поверят, потому что знают, что универсального ничего не бывает. Так что придется брать справочник по поверхностным свойствам твердых тел (если он еще не загружен в голову), просмтривать извесные факторы, оценивать их влияние на конкретную задачу и садиться за написание кода :(
не согласен. редко кто будет повторять тот же самый численный эксперимент с теми же самыми входными данными, это уровень лабораторных работ для старших классов. ну разве что студенту поручат попрактиковаться, чтоб с кодом освоился. а взрослые дяди будут проверять выводы, т.е. будут применять код к подобным проблемам, с другими входными данными. при этом вероятность нахождения ошибки вырастает в разы.
С одной стороны это конечно здорово, что всякий аспирант из какой-то неизвестной лабы может вот так просто скачать матметоды из топовых публикаций физрева и Nature. С другой стороны эти самые аспиранты завалят эти же журналами статьями в духе «я тут подставил фигню в фигню и получилась другая фигня», тем самым отняв хлеб от авторов программ. Возможно это принесёт какое-то открытие и даже фотка выйдет аспера с пробиркой около лица выйдет на обложке глянцевого журнала с комментарием как он лихо обделал всех старпёров.
Собственно реализация численного алгоритма примерно как технология эксперимента, является нехилым таким порогом, отдать который так просто мало кто способен. В науке важен приоритет, а с открытием кодов он может достаться «случайным» людям.
Проблема сложная и коммунизма тут, наверное, не будет никогда. Лет 6 назад на 4 курсе я был бы четырьмя ногами за, сейчас как н.с. уже подумаю.
Хотя отдать код всё равно не могу по причине трудового договора.
Собственно реализация численного алгоритма примерно как технология эксперимента, является нехилым таким порогом, отдать который так просто мало кто способен. В науке важен приоритет, а с открытием кодов он может достаться «случайным» людям.
Проблема сложная и коммунизма тут, наверное, не будет никогда. Лет 6 назад на 4 курсе я был бы четырьмя ногами за, сейчас как н.с. уже подумаю.
Хотя отдать код всё равно не могу по причине трудового договора.
Журналы очень серьезно рецензируют статьи. Плагиат очень жестко отсекается.
Если следовать вашей логике, то получается нельзя вообще ничего публиковать — ведь скопируют, заменят синонимами и станут героями. Но ведь мы понимаем что это не так :)
Опять же, открытие кода может стать защитой вашей работы: если у вас, грубо говоря, сопрут код (который никто не видел), оформят статью и отправят в журнал без исходников, то никто и никогда не узнает, оригинальный там код, или «украденный». А так все будет прозрачно, кто чей код использовал.
Если следовать вашей логике, то получается нельзя вообще ничего публиковать — ведь скопируют, заменят синонимами и станут героями. Но ведь мы понимаем что это не так :)
Опять же, открытие кода может стать защитой вашей работы: если у вас, грубо говоря, сопрут код (который никто не видел), оформят статью и отправят в журнал без исходников, то никто и никогда не узнает, оригинальный там код, или «украденный». А так все будет прозрачно, кто чей код использовал.
К сожалению, ситуация, которую вы описали, бывает только в стране розовых пони. Существует масса примеров, когда просто копируются статьи 70-80 годов, меняются обозначения и проталкиваются как супер-пупер исследования. Существует и обратная ситуация, когда хорошие статьи отвергаются только потому что рецензенту было лениво разбираться. С рецензированием научных статей проблема гораздо более важная, чем с открытым кодом.
Кстати, если взять те же статьи 50-60 годов, то в них обычно расписаны все выкладки и разобраться в них не составляет труда. А вот современные, опять же обычно, содержат «из чего очевидно получить[десять_ссылок_в_неизвестность]:» и складывается ощущение, что народ соревнуется кто лучше скроет до такой степени, чтобы статья прошла, но чтобы разобраться там требовало максимального времени. А вы говорите код открыть :)
Справедливости ради надо отметить, что существует куча проектом, условием финансирования которых является открытие кода: nmag.soton.ac.uk/nmag/, math.nist.gov/oommf/, www.freefem.org/ff++/ (это только с чем общался по работе)
Кстати, если взять те же статьи 50-60 годов, то в них обычно расписаны все выкладки и разобраться в них не составляет труда. А вот современные, опять же обычно, содержат «из чего очевидно получить[десять_ссылок_в_неизвестность]:» и складывается ощущение, что народ соревнуется кто лучше скроет до такой степени, чтобы статья прошла, но чтобы разобраться там требовало максимального времени. А вы говорите код открыть :)
Справедливости ради надо отметить, что существует куча проектом, условием финансирования которых является открытие кода: nmag.soton.ac.uk/nmag/, math.nist.gov/oommf/, www.freefem.org/ff++/ (это только с чем общался по работе)
Мне кажется, что реализация кода сама по себе является не самым большим порогом для защиты науки от профанов, «случайных» людей. Даже при наличии инструментов, сделать научное открытие без знаний тех людей, кто такие инструменты разрабатывал, крайне маловероятно.
Защита научного исследования от копирования — совсем другая, часто спекулируемая (см., например, Мертона), тема.
Защита научного исследования от копирования — совсем другая, часто спекулируемая (см., например, Мертона), тема.
они не журналы завалят статьями, а форумы завалят вопросами. в качестве примера посмотрите на openfoam, по-моему их пример очень показателен.
Хех. У них проблема с открытым доступам к научным публикациям (новость на хабре пробегала). Что уж говорить об исходном коде программ? :(
детального описания, которое достаточно для того, чтобы другие могли написать аналогичный код и сделать такой же эксперимент
Помню, я как-то потратил три недели на воспроизведение результата по такому детальному описанию. В итоге выяснилось, что при описанных условиях вычисления подвержены таким бешеным погрешностям округления, что все результаты представляют собой просто мусор. А работа была такая серьезная, много умных букв и матана… Был бы опубликован код — занялся бы чем-нибудь более полезным.
… вычисления подвержены таким бешеным погрешностям округления…
Ничего не путаете?
Округление имеет всегда известную погрешность. А вот погрешность исходных данных не всегда известна и посчитана.
Ничего не путаете?
Округление имеет всегда известную погрешность. А вот погрешность исходных данных не всегда известна и посчитана.
Одно округление — да, но вычислений-то много, и округлений много и вместе они накапливаются. Там выполнялось LU-разложение матрицы, но были такие условия, что матрица гарантированно оказывалась вырожденной, т.е. не могла быть подвергнута LU-разложению, формально проведенное разложение дало бы деление на ноль. Из-за накопления погрешностей вместо деления на ноль происходило деление на очень малые значения, и формально оно проходило, но получался мусор.
Кроме кода программ на результат эксперимента вилияет так много всего… оборудование, качество электропитания, качество монтажа проводов. Если речь идет не о чисто вычислительном процессе, то открытие кода не сильно упростит воспроизведение эксперимента.
Тем более что важным усливием признания результатов открытия является их независимое воспроизведение. То есть, реализация усливий эксперимента или алгоритма независимо от первоначального автора.
Тем более что важным усливием признания результатов открытия является их независимое воспроизведение. То есть, реализация усливий эксперимента или алгоритма независимо от первоначального автора.
Вы всё перевернули с ног на голову: открытый код гарантирует точное соответствие как минимум одной грани эксперимента, тогда как написание независимого кода вносит ошибки и погрешности. Или, быть может, вы знаете человека, способного писать идеально правильный код? Предлагаете вместо гарантий получить ещё больше проблем? Только лишь теоретиком быть в программировании опасно, и подобная уверенность в идеальном коде до добра не доведёт, поверьте.
Если задача поставлена как «воспроизвести эксперимент 1 в 1», то код программы будет полезен. Однако, такой эксперимент всего лишь докажет, что эксперимент воспроизводим и в его рамках результаты получены.
Для подтверждения открытия эксперимент должен быть воспроизведен на базе теоретической модели. То есть, другая команда учетных использует формулы, выкладки, алгоритмы, но все экспериментальное окружение (включая ПО) готовит своими силами. Это позволяет говорить о том, что данная теоретическая модель соответствует (или не соответствует) реальности.
Для подтверждения открытия эксперимент должен быть воспроизведен на базе теоретической модели. То есть, другая команда учетных использует формулы, выкладки, алгоритмы, но все экспериментальное окружение (включая ПО) готовит своими силами. Это позволяет говорить о том, что данная теоретическая модель соответствует (или не соответствует) реальности.
Вообще раскрытие исходников достаточно спорный момент. С одной стороны для проверки и поиска возможных ошибок — это хорошо. Но с другой стороны помимо расчетов в программе содержатся запрограммированные результаты мышления ученого в виде неких алгоритмов. И это мне не очень нравится — вижу источник для вороства идей и присвоения чужих идей. Ведь процесс мышления украсть невозможно, а вот алгоритмы уже можно.
Подобные мысли ставят под угрозу открытость науки. Как можно украсть идею, которая по определению должна быть открыта? Ни дай бог копирасты доберуться и до науки — тогда научному прогрессу придёт конец. Закрытая научная монополия — каково, а? Сначала закрытые алгоритмы, а потом и закрытые результаты исследований. Так дойдёт до того, что новые лекарства и технологии будут доступны только в пределах корпораций, а простым смертным придётся перебиваться тем, что есть.
Нельзя быть таким эгоистом и подозревать любого в воровстве, ведь основа науки — это открытый обмен знаниями. Задумайтесь, какое будущее вы себе готовите, принимая идеи копирастов.
Нельзя быть таким эгоистом и подозревать любого в воровстве, ведь основа науки — это открытый обмен знаниями. Задумайтесь, какое будущее вы себе готовите, принимая идеи копирастов.
Я не совсем корректно выразился — я речь веду не о закрытости алгоритмов. А результатах работы.
Например никто не украдет вашего реального труда: время и ресурсы потраченные на создание научного результата.
Например: один ученый синтезировал новое вещество и описал методику синтеза.
Ведь никому не придет в голову взять украсть синтезированное вещество.
А новое вещество можно дальше исследовать и получать результаты.
Но другому ученому придется синтезировать его самостоятельно.
Т.е. в результате вашей работы помимо научного результата возникает результат ввиде нового вещества или программного обеспечения в нашем случае. Которое можно использовать для дальнейшей научной деятельности. Вот в чем проблема. Конечно идеально чтобы ученые обменивались не только своими идеями, но и оборудованием, материалами, лаборантами и прочими ресурсами.
Но и в науке хватает халявщиков, которых такое положение дел очень бы устроило бы
То с программным обеспечением сложнее. ПО можно украсть и присвоить.
Например никто не украдет вашего реального труда: время и ресурсы потраченные на создание научного результата.
Например: один ученый синтезировал новое вещество и описал методику синтеза.
Ведь никому не придет в голову взять украсть синтезированное вещество.
А новое вещество можно дальше исследовать и получать результаты.
Но другому ученому придется синтезировать его самостоятельно.
Т.е. в результате вашей работы помимо научного результата возникает результат ввиде нового вещества или программного обеспечения в нашем случае. Которое можно использовать для дальнейшей научной деятельности. Вот в чем проблема. Конечно идеально чтобы ученые обменивались не только своими идеями, но и оборудованием, материалами, лаборантами и прочими ресурсами.
Но и в науке хватает халявщиков, которых такое положение дел очень бы устроило бы
То с программным обеспечением сложнее. ПО можно украсть и присвоить.
Сложный вопрос. Не для всех исследований это сможет дать ожидаемый эффект. Но авторы точно правы насчёт социально значимых проектов (молекулярная биология, исследования болезней, опухолей и т.д.), где положительный эффект намного дороже возможных опасений за воровство.
Хых. В наших вузах это было бы полезно. Отсеяло бы хотя бы тех, чьи «программы» существуют только в виде «результатов работы» и «скриншотов». :)
В день, когда был написан этот хабрапост я вначале хотел его горячо поддержать, но мой рабочий день подходил к концу и пока я ехал домой я переосмыслил свои первоначальные мысли…
Я непосредственно связан с наукой и с задачами, требующими программной обработки в областях систем передачи данных и косвенно физики, по этому попробую сформулировать свою точку зрения сразу с нескольких позиций, с которыми мне приходилось сталкиваться.
С точки зрения меня, как человека который проводит исследования в области ИТ открывать программный код нужно обязательно. Не раз и не два я открывал публикацию, статью, монографию, диссертацию в которых заявлялось о блестящих достигнутых результатах в областях, которые были связаны с моими научными интересами, однако по которым было невозможно полностью восстановить разработанный авторами инструментарий. В каких-то случаях алгоритмы были недостаточно подробны, или были представлены только концептуальные мат.модели, или проекты были на столько объемными, что сложность воспроизведения результатов была едва ли не большая чем у первоначальных исследований. А ведь предложенный метод может и не подойти…
С другой стороны я косвенно связан с физикой. Тут по моему мнению ситуация двоякая. От реализующего мат.модель софта результат может зависеть даже больше чем от самой мат.модели! По этому в этой области я за максимально открытые модели, но софт может быть и закрытым. Так больше шансов, что сторонние исследователи реализуя имеющуюся мат.модель «допустят другие ошибки», что позволит либо подтвердить либо опровергнуть суть явления, а не умение/не умение исследователей писать код.
С третьей стороны физики нередко используют различные большие и сложные приборчики, которые управляются компьютерами. И иногда у физиков возникает желание, например, получать данные не только таким образом, как предусмотрел производитель приборчика, но и по другому. В этом случае открытый исходник управляющего софта — это скорее благо, граничащее с необходимостью, так как это позволит значительно упростить реализацию альтернативных вариантов использования приборчиков.
Выводы я делать не буду, так как по моему мнению ситуация слишком многогранна и сложна для возможности существования единственно верного решения.
Я непосредственно связан с наукой и с задачами, требующими программной обработки в областях систем передачи данных и косвенно физики, по этому попробую сформулировать свою точку зрения сразу с нескольких позиций, с которыми мне приходилось сталкиваться.
С точки зрения меня, как человека который проводит исследования в области ИТ открывать программный код нужно обязательно. Не раз и не два я открывал публикацию, статью, монографию, диссертацию в которых заявлялось о блестящих достигнутых результатах в областях, которые были связаны с моими научными интересами, однако по которым было невозможно полностью восстановить разработанный авторами инструментарий. В каких-то случаях алгоритмы были недостаточно подробны, или были представлены только концептуальные мат.модели, или проекты были на столько объемными, что сложность воспроизведения результатов была едва ли не большая чем у первоначальных исследований. А ведь предложенный метод может и не подойти…
С другой стороны я косвенно связан с физикой. Тут по моему мнению ситуация двоякая. От реализующего мат.модель софта результат может зависеть даже больше чем от самой мат.модели! По этому в этой области я за максимально открытые модели, но софт может быть и закрытым. Так больше шансов, что сторонние исследователи реализуя имеющуюся мат.модель «допустят другие ошибки», что позволит либо подтвердить либо опровергнуть суть явления, а не умение/не умение исследователей писать код.
С третьей стороны физики нередко используют различные большие и сложные приборчики, которые управляются компьютерами. И иногда у физиков возникает желание, например, получать данные не только таким образом, как предусмотрел производитель приборчика, но и по другому. В этом случае открытый исходник управляющего софта — это скорее благо, граничащее с необходимостью, так как это позволит значительно упростить реализацию альтернативных вариантов использования приборчиков.
Выводы я делать не буду, так как по моему мнению ситуация слишком многогранна и сложна для возможности существования единственно верного решения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Если мы хотим воспроизводимую науку, код программ должны быть открыт