DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 14:50

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
СообщениеДобавлено: Вторник, 20 Январь, 2015 17:14 

Зарегистрирован: Вторник, 13 Декабрь, 2011 15:31
Сообщения: 113
Ссылка на статью: http://geektimes.ru/post/244472/
Я не имею профессионального образования программиста и для меня программирование это хобби. По собственному опыту могу сказать, что скрипты написанные мною в текстовом виде гораздо сложнее самому понимать спустя 2-3 месяца, чем скрипты написанные в DRAKON Editor. С использованием ДРАКОН-а мои скрипты кажутся мне более понятными.
Я думаю что ДРАКОН сможет внести улучшение в проблему описанную выше в статье.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2015 17:39 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 40
Откуда: г. Ярославль
Цитата:
56% учёных сказали, что разрабатывают собственное ПО
Каждый второй!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2015 19:09 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
По ссылке vasili111 http://geektimes.ru/post/244472/
Василий, спасибо. Великолепный материал!
Цитата:
Плохой софт портит научные исследования

Научные исследования невозможны без использования компьютеров и программного обеспечения. Такое мнение высказали 69% учёных, принявших участие в опросе Software Sustainability Institute (SSI). При этом в реальности софт используют 92% всех исследователей.

Результаты этого опроса показались бы совершенно банальными, если бы не одна деталь: 56% учёных сказали, что разрабатывают собственное ПО (интересно, что это делают 70% мужчин и 30% женщин, то есть наблюдается определённое гендерное неравенство).

Так вот, каждый пятый учёный из тех, кто создаёт собственное ПО, не имеет никакого образования в области разработки программного обеспечения.

«Это вызывает серьёзную озабоченность. Да, можно самостоятельно найти способ для создания программы, учёные — умные люди, они способны в этом разобраться, но при этом вы не сможете сделать программу, которая работает надёжно, — говорит Саймон Хеттрик (Simon Hettrick), заместитель директора SSI. Если вы производите научные результаты с помощью программы, а ваша программа не делает воспроизводимых результатов, но и научные результаты не будут воспроизводимыми».

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

Когда учёные разрабатывают программы, то это чревато проблемами. Единственная ошибка в коде приводит к получению результатов, которые на первый взгляд выглядят невинно, но в реальности оказываются неправильными.

Уже неоднократно возникали ситуации, когда научные журналы отказывали в публикации статей из-за ошибок в самодельном ПО. Ситуация усугубляется тем, что многие «глючные» программы передаются от одного научного коллектива другим, что умножает количество ошибок.

Представители Software Sustainability Institute считают, что необходимо проводить тренинги для учёных по написанию программного обеспечения, публиковать исходный код каждой программы и проверять его качество.

UPD. Перевод пресс-релиза от Software Sustainability Institute, таблица Excel с результатами опроса
воспроизводимость
, наука
, разработка ПО

          Похожие публикации

          Минкомсвязи отозвал у Ростелекома подряд на разработку мобильных приложений «Госуслуг» 19 декабря 2014 в 20:44

          Простая Наука — дайджест опытов #38 4 декабря 2014 в 19:09

          NASA инициирует начало разработки астероидов, предоставляя контракты частным компаниям 26 ноября 2014 в 13:04

          Господдержка российских разработчиков ПО: просят 40 млрд руб. в год 20 ноября 2014 в 14:33

          AppleInternal and some other stuff или разработка в Apple изнутри 6 ноября 2014 в 12:15

          Минкомсвязи лоббирует выделение 10 млрд рублей на поддержку российских разработчиков ПО 4 ноября 2014 в 17:21

          Три основных направления разработки ПО в будущем 2 июля 2010 в 21:35

          Разработка ПО и его продажа (Часть 2. Наличие Хорошего продукта — не гарантия успеха) 13 июля 2009 в 10:32

          Разработка ПО и его продажа (Часть 1. копирование — не воровство) 23 апреля 2009 в 11:28

          Microsoft инициировала образовательную программу по предпринимательству в сфере разработки ПО — «Start in Garage» 12 мая 2007 в 11:32

Комментарии (30)

Anton_Menshov

19 января 2015 в 14:24 (комментарий был изменён)

Мораль: «Плохой софт – это плохо. И в науке тоже. И для Сережи тоже.»

Coob

19 января 2015 в 14:42

Мораль: научный софт ужасного качества. Под ужасным качеством я подразумеваю, что его не так уж часто удается даже просто собрать/запустить без плясок с бубном, про надежность и вовсе молчу. Во всяком случае, об этом говорит беглый экскурс в биоинформатику.

lany

19 января 2015 в 15:48 (комментарий был изменён)

О, подскажите какой-нибудь ужасный научный софт на Java. Мне для тестирования FindBugs постоянно нужен низкокачественный глючный софт. Бывает, найдёшь что-нибудь новенькое, думаешь, о, научный софт, ща потестируем. А там, как назло, качество хорошее, юнит-тесты, код-ревью, ещё и в мавен выкладывают сами, как настоящие программисты.

Upd: JMol не предлагать, про него я уже знаю. Действительно изумительная коллекция багов.

DancingOnWater

19 января 2015 в 16:00
В предыдущей мажорной версии scilab был прилично забагован

lany

20 января 2015 в 08:19
Потестировал scilab, действительно прикольные баги нашлись. Спасибо.

dunmaksim

20 января 2015 в 08:36
Один знакомый программист в дискуссии по OpenSSL заметил: «Да чего ты от неё хочешь? Её не программисты, а математики писали». Что, в общем-то, объясняет почти всё.


DancingOnWater

19 января 2015 в 14:44
Судя по коду, что я видел в научных либах и прогах. Я б сказал так: 90% не думают о качестве кода и не думают о том, как они его будут тестировать, 9% задумались, но у них плохо получилось и они забросили, 1% пишут хоть как-то вменяемый код.

Причем сплошь и рядом ошибки переполнения, ошибки дискретизации, не учет ошибок вычислений с плавающей точкой. И т.д и т.п.

Nik_sav

19 января 2015 в 15:27 (комментарий был изменён)
Зачастую, выходит гораздо проще состряпать программку обработки данных самому, чем объяснить программисту, что программа должна выполнять. Дело, как минимум, в том, что на данном этапе человек еще не знает всех нюансов, которые стоит ожидать от эксперимента — возможно, потребуется сильная фильтрация полученных данных, или наоборот, излишне агрессивный фильтр смажет вожделенный пик на кривой. И все это выясняется только в процессе обработки измерений. Когда вся обработка написана самостоятельно, имеется полный контроль над ситуацией и всегда есть возможность оперативно подправить код с учетом открывшихся обстоятельств. Вряд ли профессиональный программист сможет быстро освоить проблематику, над которой ученый бьется всю сознательную жизнь, и предложить лучшее решение. А критиковать уже созданное весьма просто…

DancingOnWater

19 января 2015 в 15:42
Знаете, я не чистый программист, более того в универе у меня было два языка — Си и Matlab. я астроном по образованию. А сейчас пишу баллистику для спутников, а до этого сидел и обрабатывал данные с телескопов. И знаете что я вижу, когда заглядываю в код старых аксакалов: 20 вариантов одной и той же проги, которые то там, то здесь исправлены чуть-чуть и где что именно никто вот так сразу не скажет. О повторном использовании кода и речи быть не может.

А насчет контроля я скажу так, если это же самое не может контролировать другой человек, значит его не контролируете его и вы. И не идеализируйте свою память.

qbertych

19 января 2015 в 15:47
Маленькие научные группы обычно заинтересованы в приоритете публикаций, нежели в стабильности/надежности софта. Не говоря о том, что время жизни многих программ — это время работы конкретного человека (мнс, аспиранта) над данным проектом.

DancingOnWater

19 января 2015 в 15:50
Ага, код которого потом будет использован методом копипастом через цать лет, спасибо — видел. Приоритет это хорошо, но вот как вы гарантируете, что вы верно считаете?

qbertych

19 января 2015 в 16:18
Ваш вопрос похож на «а как вы гарантируете что графики в вашей статье не взяты с потолка?»

Вообще для этого есть рецензирование статей. А еще такая вещь как повторяемость результата в разных группах.

В конце концов, если вы нашли сверхсветовые нейтрино — публикуйтесь на здоровье, всем пойдет на пользу. Особенно если вы потом найдете отошедший кабель в своем эксперименте.

DancingOnWater

19 января 2015 в 16:27
Ну да, знаем мы как рецензируются статьи. Особенно чисто расчетные. Никто ничего не понимает, формулы проверят, ну м.б. графики и то не всегда, и все.
Потом придут другие товарищи, которые также не в курсе ( а таких подавляющее большинство), что 0.01*100.0 != 0.01 + 0.01 +0.01… и так 100 раз. и у них результаты совпадут.

Nik_sav

19 января 2015 в 16:44
Я не отрицаю наличие проблем в самописном научном ПО, описанные вами случаи встречаются повсеместно. Мой посыл был в частой невозможности сформулировать четкое ТЗ для стороннего программиста на данном этапе исследований (умолчим про необходимое финансирование).
На счет старых наработок, я бы тоже не был столь категоричным, к примеру, библиотеки ФОРТРАНа до сих пор используются учеными во всем мире. Или специализированное ПО для физического (химического, биологического и т.д.) моделирования, где наработки ученых систематизируются в библиотеки и приобретают удобоваримую форму.
Так же, несколько улучшает ситуацию развитие языков высокого уровня (тот же Матлаб), вероятность описанных вами ошибок на которых в разы меньше, а скорость написания кода и его читаемость выше.

Но я двумя руками за то, что бы выделенных на науку денег хватало и на штат программистов.

VIK52

19 января 2015 в 23:34
Да. Вот насчет ТЗ согласен полностью. Лучше уж самому хоть как-нибудь…

DancingOnWater

20 января 2015 в 09:47 (комментарий был изменён)
Нельзя сделать за дорого — сделай за дешево, но также. На самом деле у ученых естественных наук и программистов один оочень мощный фундамент — математика. Она синхронизирует способ и направление мысли.
В чем отличие программиста от ученого? — Программист перелопатил тонны кода, как своего, так и чужого. Поэтому для него ЯП — это еще один язык общения. Он качался в этой сфере очень долго, у него за спиной целый стек технологий. Он знает как связать один узел с другим и заставить это работать. Он знает гораздо больше нюансов работы всех этих технологий.

По сравнению с ним, вы школьник 11-го класса, а он литератор. Но это не значит, что школьник не сумеет связано и грамотно изложить на бумаге свои мысли.

Рецепт построения вменяемой программы, да и вообще любого продукта прост — при реализации вы должны смотреть на него со стороны.
Сначала напишите в коде некую структуру программы.не обязательно чтоб она что-то считала, более того сейчас она не должна работать.
Напишите тесты и оцените удобство использования кода.
Напишите хоть пару строк комментариев ЧТО делает каждая функция. Оцените насколько проста каждая задача, насколько она покрывается тестами. А в качестве бонуса, пока вы думаете над комментарием, всплывет какой-то нюанс.
Устраните недочеты в структуре и теперь можно написать код.
Гарантирую, хороший программист, если вы ему понесете такой код очень быстро въедет в задачу. Ну а если нет, то проделанная процедура — это ваша база для спокойного сна. явные косяки вы должны были устранить.

AraneusAdoro

19 января 2015 в 18:48
А нельзя состряпать программку самому, а потом отдать программисту на вычитку и вычистку?

Nik_sav

19 января 2015 в 19:56
Часто все упирается в то, что программисту нужно заплатить, да и задачи, поначалу, выглядят просто. Не стоит так же отбрасывать ЧСВ — не каждый признается шефу, что не способен накидать несколько строчек программы самостоятельно. Выше я уже говорил, что в идеале, на ряду с инженерами и техниками, действительно было бы неплохо иметь в научной команде и программистов. Возможно, со временем и к этому придем.

dyadyaSerezha

19 января 2015 в 15:36
Ответ простой: дайте денег на нормальные зарплаты программистам в науке и они напишут хороший код.
Реальность: этого не будет никогда. Следовательно, в науке ситуация всегда будет такой.

stetzen

19 января 2015 в 17:54
Если изначально есть понимание, что нужна большая софтина — зачастую нормального програмиста найти таки можно. Но очень много самописного софта развивается чисто эволюционным путем из поделки на две сотни строк — сначала нужно автоматизировать какую-то простую операцию, потом дописать еще полсотни строк фильтра, потом еще, а потом внезапно оказывается, что есть уже приличый такой комбайн, и ну не выбрасывать же его.

idiv

19 января 2015 в 18:16
Не такой уж и простой. Программист должен разбираться в теме не хуже того, кто дает задание. Где-то это проблему решит, а где-то — не поможет.

dom1n1k

19 января 2015 в 18:41
Сейчас процентов 70-80 программистов даже банальный матан не знают. А зачем он, говорят? Кстати, припоминаю статьи об этом на Хабре. Ну действительно, зачем, если в реальной жизни он будет кодить какой-нибудь онлайн-магазин, цмс или игрушку? Фреймворки с паттернами ему полезнее. И большая доля истины в этом есть — мало кому матан пригождается на практике. Мне вот пригодился, но весьма частично.

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

Выходит, что з/п должна быть не просто высокой, а высокой на протяжении минимум нескольких лет. Никакому «обычному» программисту это не нужно. И наоборот, он такой не нужен науке. Остается только надеяться на редких людей «на стыке», которые интересуются и умеют то и другое.

Bas1l

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

qbertych
19 января 2015 в 15:42
Меня больше волнует софт для науки. Как софт для управления шаговиком через USB может инициализироваться полминуты — мне неведомо. И это еще большая компания, с ценами выше рыночных и огромным штатом.

speakingfish

19 января 2015 в 16:15
На различных стыках с железом часто с таким сталкивался. Ленивые люди делают синхронные методы доступа в которых жёстко задают задержку (с запасом!) между передачей и приёмом. Если обмен длительный — мелкие задержки накапливаются и вырастают в описываемое вами. Лечится заменой на асинхронный обмен. Но без исходников это затруднительно.

degs

19 января 2015 в 21:28
когда-то компьютеров не было, то есть вообще не было…
потом комьютеры появились и любопытные ученые сразу начали тыкать в них пальцами…
у кого-то получалось плохо, а у кого-то и хорошо…
те, у кого получалось плохо, до сих пор тыкают, но над ними за это смеются и бьют по рукам…
а у тех, у кого получалось хорошо, получалось все лучше и они тоже до сих пор тыкают, только учеными их больше не называют…
много нас таких, здесь кстати тоже

gonzazoid

19 января 2015 в 21:58
обязать к публикациям прикладывать либо исходники либо алгоритм расчетов. Имхо, это прямо вытекает из требования воспроизводимости результата.

MichaelBorisov

20 января 2015 в 01:41
Много лет работал программистом в научном коллективе и подтверждаю все сказанное в статье.

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

В научных учреждениях (даже небедных на Западе) никогда не хватает денег на наем профессиональных программистов. Даже если программистов нанимают, объем работы для программистов обычно существенно больше, чем они могут потянуть.

Подтвержаю сказанное Nik_sav:

на данном этапе человек еще не знает всех нюансов, которые стоит ожидать от эксперимента — возможно, потребуется сильная фильтрация полученных данных, или наоборот, излишне агрессивный фильтр смажет вожделенный пик на кривой. И все это выясняется только в процессе обработки измерений

Совершенно верно. Бывало, мне давали задание, я много времени тратил на тщательную проработку программы, приданию ей красивого вида, тестирование, оптимизацию, закладывание возможностей на расширение. А потом выяснялось, что эксперимент не удался, и программа не понадобится, или ее надо существенно переделывать. Выкрасить и выбросить. За это же время аспирант сам на коленке бы состряпал для себя некрасивую и неэффективную программу, которая позволила бы получить тот же результат (что она не нужна, и тратить усилия на дальнейшее совершенствования программы бессмысленно).

Также от «программиста для науки» требуется квалификация в предметной области, сравнимая с квалификацией аспиранта, а где-то даже и доктора. Знание математики, статистики, цифровой обработки сигналов и того, как все это эффективно реализуется на компьютере. Иногда — знание электроники (для понимания, как настраивать и использовать научную аппаратуру и приборы). Но люди с такой квалификацией обычно сами становятся аспирантами, а затем и докторами. Это единственный путь сделать карьеру в науке. Просто программист в научном коллективе лишен возможности карьерного роста. Он никогда не станет руководителем группы (это удел докторов и профессоров). Платят им меньше, чем в коммерческих предприятиях.

Поэтому я вижу единственный выход. Современные ученые должны повышать свою квалификацию в области программирования. Так же, как математика традиционно была необходима при исследованиях в области естественных наук, сегодня становится необходимым программирование.

Nik_sav

20 января 2015 в 13:04
Повышать квалификацию нужно несомненно, но тягаться с человеком, занимающимся исключительно программированием все равно не получится, нужно ведь, в первую очередь, в своей предметной области расти.

Как я уже писал выше, сильно помогают специализированные инструменты: Matlab — отличная числодробилка, пускай код (в неумелых руках) будет медленным, но свою задачу выполнит, LabView — для автоматизации эксперимента, прост до невозможности, при этом имеет огромный потенциал — доводилось и просто данные собирать и драйвера для устаревшего оборудования писать. Важно так же, что порог вхождения здесь крайне низок — любой студент освоит.

В свою очередь, уже эти программные пакеты разрабатывают команды профессионалов, и на их плечи ложится понятный интерфейс, «защита от дурака», написание мануала, тех. поддержка и т.д.

Такое решение требует дополнительных затрат, пакеты не из дешевых, даже для образовательных и научных учреждений. На западе проще заложить в бюджет покупку софта, на постсоветском пространстве можно столкнуться с закостенелым менталитетом руководства, мол, лучше купим еще одну супер нужную железяку, а программу студенты как-нибудь напишут на бейсике.

MichaelBorisov

20 января 2015 в 16:16 (комментарий был изменён)
тягаться с человеком, занимающимся исключительно программированием все равно не получится

Я в жизни видел успешный пример. Человек поработал несколько лет программистом в антивирусной компании, а после этого — пошел в аспирантуру. Профессиональные знания и навыки в области программирования позволили ему стать поистине «монстром» по сравнению с «обычными» аспирантами (физиками и т.д.). Он быстро и легко создавал для себя и других членов коллектива мощные и красивые программы. Когда пишешь программу для себя — то это всегда более эффективно, чем если по поручению других. Сам всегда знаешь, где можно сэкономить время и силы на вылизывание программы, а где — постараться и сделать качественно. Какие функции в программе реально нужны и до какой степени они должны быть развиты. В коллективе, где есть такой аспирант, нанимать отдельных программистов не нужно.

Цитата:
Зачастую, выходит гораздо проще состряпать программку обработки данных самому, чем объяснить программисту, что программа должна выполнять.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2015 19:39 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 71
Откуда: Россия, Орёл
Ну да, а когда программисты начинают писать программы для учёных (или учёных начинают учить писать так, как "профессионалы" пишут), то настаёт полный финиш.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Январь, 2015 19:41 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 71
Откуда: Россия, Орёл
http://www.inr.ac.ru/~info21/nonprofessionals.htm


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 10


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB