Comments 13
А можно ли тут задать пару вопросов Александру, или он на Хабр не заглядывает?
Я - типичный научный сотрудник, который сам пишет программы для решения разных задач, и сам же их применяет. В результате появился очень узконишевый пакет программ, который умеет решать много нестандартных задач по анализу геофизических временных рядов едва ли не лучше всех в мире (примеры таких задач и их решений в опубликованных научных статьях), но при этом страдает весьма старомодным интерфейсом в стиле Norton Commander и достаточно высоким порогом вхождения. Мы хотели бы присоединиться со своей разработкой к сообществу open source (исходные коды пакета открыты и доступны всем пользователям), но непонятно, как это проще сделать и, главное, будет ли от этого какая-то польза: не хочется тратить ресурсы и время на то, что никогда никому не понадобится. Ведь шансы, что кто-то подключится к разработке,
ничтожно малы
по целому ряду причин. Во-первых, сам пакет полностью русскоязычный. Это сразу резко ограничивает его возможную нишу. Нет никакого смысла бороться за увеличение своей доли на "рынке", если весь этот рынок - это десяток научных групп, треть из которых и так уже с нами сотрудничают ;-)
Во-вторых, основа пакета - это легаси с обильными русскоязычными комментариями, в котором никто, не владеющий языком, разобраться не сможет в принципе.
Ну и сам код: он преимущественно написан на древнем современном, но никому не известном фортране, да еще и страдает проприетарностью компилятора...
И еще про стиль разработки. Сначала авторов было трое, а сейчас их осталось полтора человека. Поэтому вся разработка (она идет до сих пор, и довольно активно) ведется локально. Учитывая размер коллектива, нам нет никакого смысла задействовать инструменты коллективной разработки.
Что посоветуете таким, как мы?
Я конечно не Александр, но понимаю вашу проблему. Советую её декомпозировать и решать по частям.
Перевести для начала все комментарии на английский язык, отформатировать код - это можно доверить и ИИ.
Спасибо за идеи, но...
Перевести для начала все комментарии на английский язык,
Это совершенно точно не первоочередная задача. Программа полностью русскоязычная. Поэтому привлекать иностранное комьюнити абсолютно бессмысленно, пока не реализована многоязычность. Тут если уж начинать, то с перевода интерфейса. В принципе, ничего сложного... но
объем работы ОЧЕНЬ приличный.
Я не знаю, как это сейчас обычно принято делать, но в фортран-программе для этого проще всего заменить все литералы в программе на ключи (для простоты, ключ может повторять текст сообщения на одном из языков), а сами сообщения (точнее, их переводы на разные языки) собрать в соответствующий файл словаря. В принципе, ничего сложного... только вот таких литералов в программе около 10 тыс. И автопереводом точно не обойдешься (задачи специфические, поэтому и сообщения несколько отличаются от стандартных, которые хорошо переводятся). А еще многие сообщения для эстетики выровнены "прямоугольником", и при переводе придется думать еще и об этом...
Но главная проблема в том, что переход на такую систему - это не единоразовое "вложение", а постоянная дополнительная нагрузка на всю оставшуюся жизнь. В частности, резко осложнится любой новый кодинг: если сейчас я просто вбиваю текст сообщения в код, то в мультиязычной версии любая такая операция будет стоит втрое дороже (и это если не задумываться о качестве перевода). Причем, "платить" придется уже сейчас, а возможные бонусы от многоязычности наступят лишь в отдаленном будущем (если вообще наступят).
А еще мне придется перевести справку, в которой более 500 топиков. Каждый в среднем на пару экранов текста. Не повредив при этом 10 тыс. ее внутренних гиперссылок. Причем, сейчас все это оформлено в виде документа старого Word (формат doc). Я это чудо не то что в автоперевод не умею засунуть (ни один из известных мне способов не сохраняет гиперссылки), я его даже сконвертировать в docx не умею. (Пробовал пару десятков методов такой конвертации с использованием разных программ и разных промежуточных форматов, но внутренние гиперссылки во всех вариантах теряются). А расставлять их вручную заново - это отдельная песня...)
Причем никаких бонусов мне за это
не светит
Зарплату мне платят за публикации и отчеты, а вовсе не за разработку ПО. Поэтому несмотря на то, что это самое ПО является моим основным и даже чуть ли не единственным инструментом (Тотал + офис не в счет), тратить на его развитие слишком большую часть рабочего времени я не могу...
А вот дальнейшее развитие и поддержка многоязычной программы в будет мне "стоить" гораздо дороже, чем моноязычной. Ведь при любом изменении (дополнении) в проге придется переводить и все новые сообщения, и, главное, все затронутые фрагменты справки. Если учесть, что английским я владею
очень-очень условно,
Например, я не могу оценить качество автоперевода на английский даже в нулевом приближении. Для этого я делаю обратный перевод в другом переводчике и сравниваю два русских текста. Если есть разница - то упрощаю свой русский текст и повторяю операцию до сходимости...
то это становится почти непосильной задачей.
.
отформатировать код - это можно доверить и ИИ.
А вот эта задача точно на повестке дня не стоит. Для иностранного комьюнити код будет абсолютно непонятен вне зависимости от форматирования (у меня размер шапки функции с ее описанием часто составляет половину размера функции. И без нее там хрен что поймешь). А для русскоязычного - наоборот, понятен вне зависимости от форматирования. Так как весь пакет написан микроскопическим коллективом, изначально придерживавшимся определенного
единого стиля
Да, этот стиль самопальный (когда это все начиналось, понятие "стиль" в широких массах было еще практически неизвестно ;-)
Но как мне неоднократно говорили коллеги, в плане читаемости стиль не самый плохой, несмотря на его самопальность и древность. А главное, автоформатирование вряд ли может что-то существенно в этом стиле улучшить... Вот для примера случайно выбранный фрагмент кода примерно 10-летней давности (функция предлагает юзеру еще раз подумать, если он собирается прерывать "опасную" операцию на полпути, рискуя при этом испортить редактируемую копию сигнала):
cccccccccccccccc L*4 DANGEROUS_USER_ABORT() ccccccccccccccccc
c Аналог USER_ABORT для команды сдвига фрагмента ряда. c
c Если последней была нажата клавиша F1, выводит справку (топик задан в MAIN).c
c Иначе выводит dos_line_wait() с предупреждением о том, что операция c
c не завершена, и датой Irec (cptr=1). с
c Если юзер все равно командует "аборт", то результат $True. c
c...............................................................................c
LOGICAL*4 FUNCTION DANGEROUS_USER_ABORT()
USE ABD_INC; USE HEADERS, Dummy_dangerous_user_abort => dangerous_user_abort
integer*4 i
if (scan_cod == $F1) then; call show_help(); return; end if
c
dos_line='Предупреждение: ряд был сдвинут только частично! Операция еще не закончена!|'//
+ 'Если сейчас прервать вычисления, то в сигнале появится дополнительный разрыв|'//
+ '(дополнительный скачок = сдвиг уровня) примерно в момент:'
c
c Выровняем сообщение для украшения текста:
select case(int_type)
case ($SType_sec); call subst2to1(dos_line,' =','=')
case ($SType_msec,$SType_mks); call subst_substr(dos_line,' = сдвиг уровня)',')')
end select
cptr=1; call set_discret_date(Irec) ! дата вычисляется для текущего ряда
i=set_date_string(abd_date,extr_date_len) ! Дата в строке date_string, i = длина даты
call append(date_string); call append('|')
call dos_line_wait()
call kbdclr(); call putkey($Space,0); call delay(0.3)
DANGEROUS_USER_ABORT=user_abort(); call kbdclr();
end
Конечно, не имея доступа к описанию использованных глобальных переменных, понять этот код будет проблематично... но некоторое представление о стиле он, надеюсь, дает
Ну давайте начнем со слона в комнате, ваш пакет написан на Fortran. Живых людей вне метеорологии, кто писал бы на Fortran уже осталось очень мало. Это означает, что без дополнительных усилий будет довольно сложно привлечь комьюнити. Какие дополнительные усилия можно предпринять? Сделать поставку ядра приложения таким образом, чтобы другие люди могли ей пользоваться. Например сделать обертку на Python. В Python экосистеме это довольно распространенная практика, весь ScipPy так сделан. Сразу предупреждаю, что это не просто если вы до этого никогда этим не занимались. Надо разобраться с тем, как работают более или менее стабильные сборщики, научиться более или менее автоматически делать релизы и сделать минимальные тесты. Не просто, но и не фантастически сложно. Мотивированный студент за полгода должен разобраться.
Дальше вопрос о том, зачем и имеет ли смысл. Тут надо понять, востребован ли ваш пакет за пределами вашей задачи. Для этого лучше всего поискать профессиональные сообщества в вашей теме и закинуть туда вашу идею. У нас есть свое сообщество, и мы иногда занимаемся геоданными, но боюсь не настолько углубленно, чтобы был нужен отдельный пакет для анализа. Если сообщества нет, то можно его создавать. Это тоже не так уж просто (и именно этому могут существенно помочь open source хабы в вузах), но как минимум надо начать с того, чтобы опубликовать код в удобном виде. Можно на Github, возможно у вашего института или вузов, с которыми вы работаете есть какие-то свои хранилища. При этом, как вам уже писали, надо позаботиться о том, чтобы ваш код было удобно и приятно читать.
Теперь о шансах. Шансы, что кто-то со стороны быстро придет и начнет что-то добавлять в ваш сложный код на мертвом по сути языке довольно низкие. При этом если возникнут пользователи, то так или иначе качество кода будет улучшаться. Хотя бы потому, что люди будут приходить и задавать вопросы, по которым будут видны недостатки существующего кода. Может быть и критика, но критика означает в том числе интерес. Даже если сторонних контрибьютеров не будет, будут ваши собственные студенты, для которых публичный вклад в проект будет хорошим опытом и хорошей добавкой в портфолио.
Кстати, куча свободных компиляторов фортрана. Кто мешает протестировать на любом из них?
Кстати, куча свободных компиляторов фортрана. Кто мешает протестировать на любом из них?
Тестировали. Все компилируется, если убрать некоторые мелкие расширения стандарта, допустимые в Интел фортране. Но это нарушит стиль и ухудшит (имхо) читаемость кода. Например, сейчас у нас все имена констант начинаются с $ - сразу понятно, где что. Можно заменить на S, но тогда появятся неблагозвучные сочетания в именах. А если на "s_", то это длиннее, ну и стиль портится (для других переменных такого префикса нету).
Во-вторых, код у интел-фортрана получается ощутимо быстрее (если сравнивать компиляторы одного возраста). У нас ряды длинные, это существенно.
В общем, когда припрет по-настоящему - перейдем. Но зачем бежать впереди паровоза?
Сделать поставку ядра приложения таким образом, чтобы другие люди могли ей пользоваться
Увы, это малореально. Основной интерес пакета - это не ядро, а алгоритмы обработки рядов. Без них все остальное бессмысленно. Но у нас почти все методы работают не с памятью, а с диском (предполагается, что в память ряды не влезают). В ОП читается только скользящее окно. Плюс к этому почти у каждого алгоритма свои специфические диалоги. Причем эти вопросы часто нельзя задать юзеру заблаговременно, и передать расчетному модулю готовое задание с исчерпывающим набором опций. В результате возникает куча взаимных зависимостей, и вычленить из пакета какие-то фрагменты, имеющие самостоятельную ценность (в отрыве от всего остального), очень проблематично.
Например сделать обертку на Python. В Python экосистеме это довольно распространенная практика
Знаю... Но тоже не выйдет, только уже по другой причине. У нас одна из базовых идей - это визуально-ориентированная среда обработки данных. При этом ряды часто имеют длину в гигабайты. Например, у меня прямо сейчас в рабочем пространстве висит 30 временных рядов, в каждом из которых около 200 млн. значений. Рабочий процесс - это первичная обработка рядов. Он состоит в просмотре графиков с разным временным разрешением (развертка экрана от нескольких минут до многих лет), выборе и применении разных преобразований к отдельным фрагментам сигнала или к рядам целиком (пока идет этот счет, я и сижу в соцсетях ;-). При этом на экране могут одновременно отображаться миллиарды значений данных (на моем не слишком современном компьютере это занимает секунды), а могут - небольшие фрагменты из пары миллионов значений, между которыми я хочу переходить по временной оси "на лету". Плюс мне постоянно нужна такая штука, как визуальное редактирование данных, причем границы фрагментов я задаю с точностью не до экранного пиксела, а до одного значения данных. Сейчас у нас это все работает методом "подсоса" нужных фрагментов сигнала из рабочего пространства (в теории это диск, но на практике часто кэш) в ОП, и т.д.
Чтобы все это реализовать с использованием стандартных библиотек Питона, потребуется очень глубокая интеграция с интерфейсом. А то и вовсе лезть внутрь (например, у нас полно Nan-ов, и они должны обрабатываться, как штатные значения данных, то есть по-своему в каждом конкретном случае в зависимости от текущей задачи). В общем, "тупой" подход, чтобы просто отдать-получить массив данных (ряд целиком) - работать явно не будет. Поэтому даже простое переписывание графических экранов (которых у нас всего лишь пара десятков) уже потребует несоразмерных усилий, чтобы только не потерять наиболее востребованную функциональность.
И это я еще даже не начал песню про генерализацию изображения. Обертка ведь должна включать графику, иначе какой в ней смысл? К примеру, у нас одна из наиболее востребованных команд - это переключение
режима генерализации
Когда ширина экрана по X всего две тысячи пикселов, но при этом надо показать миллион точек, то приходится выбирать из двух вариантов: либо в каждой точке рисуется среднее значение сигнала в пределах текущих 500 точек, либо размах его вариаций за тот же период. А если нам постоянно нужно и то, и другое? Я еще не видел программ, которые бы это делали удобно и быстро. Как максимум, можно передать графической подсистеме вместо одного ряда два длиной по 2000 точек с заранее предвычисленными значениями. И делать это снова и снова при каждом смещении окна просмотра. При этом сперва надо все эти сигналы предвычислить, потом их отдать, и только потом начнется отображение. У нас же все это реализовано динамически, с учетом точного размера отведенной под графики экранной области в пикселах. Причем если ряды большие, то первый сигнал отображается практически сразу же, - так что можно его порассматривать, пока отрисуются остальные.
Ну и куча других мелких трюков буквально на каждом углу, которые сильно
повышают удобство и скорость работы
Вот для примера еще одна фича: для статьи/презентации график должен быть красиво оформлен. Поэтому разметку осей принято делать снаружи бокса. На это уходит существенная доля экрана, но это общий стандарт. Но при работе гораздо важнее, чтобы график был нарисован максимально подробно. Чтобы использовать весь экран, у нас ось Y идет по самому краю окна, а цифры мы пишем внутри поля графика. Благодаря чему график начинается фактически от края экрана. Поскольку у нас вся графика векторная, это не слишком мешает при последующем дооформлении этих рисунков (ну или можно переключиться в "презентационный" режим, но лично я его практически никогда не использую).
и которые замучаешься переписывать под другую среду. Которая еще не факт, что вообще сможет с этими задачами справиться. Ну или даже в конце концов справится, а через два года безнадежно умрет, и начинай все сначала (вспомним переход с версии 2 на 3).
А самое главное, что даже после изготовления этой "обертки" основой все равно останется код на фортране и С++. Только теперь все причастные должны будут, помимо этих двух языков, владеть еще и Питоном, включая все прилагающиеся к нему атрибуты (среду и зависимости). Чем-то мне это напоминает анекдот про стандарты ;-)
В общем, Питон - это явно не вариант.
И продолжение ответа вторым сообщением (в первое не успел, время редактирования истекло).
Дальше вопрос о том, зачем и имеет ли смысл. Тут надо понять, востребован ли ваш пакет за пределами вашей задачи.
В этом-то и вопрос. Геодинамическим мониторингом в научных целях занимается считанное число людей на планете. Из них заметное, но еще более крохотное подмножество занимается этим в РФ. И это почти на 100% научники, а не программисты. Как максимум, они могут использовать готовый пакет (и используют), но не участвовать в чужой разработке. Самые продвинутые пишут что-то свое, строго под текущую решаемую ими задачу. Остальные пытаются комбинировать какие-то готовые среды, начиная от Матлаба и кончая файлами в Excell. Но все они и так про наш пакет знают. Тут поля для расширения нет.
Что же касается более широких задач, то я просто не знаю: интересен ли там кому-нибудь такой инструмент, или нет. Все-таки, у нас много специфики, и она совсем не бесплатная, особенно в плане порога вхождения. А они, соответственно, ничего о нашем пакете не знают и никогда не узнают. Попросту негде. Как известно, в Африке нет никакого смысла продавать обувь - там все босиком ходят :-)
как минимум надо начать с того, чтобы опубликовать код в удобном виде.
Мысль понятная, но она мне кажется спорной. Какой смысл читать код, если тебе не интересна задача, которую он решает? Польза могла бы быть от попадания в какие-то обзоры... только ведь систематизация все равно должна идти по задачам. А в нашем случае это кратно более узкая ниша, чем "временные ряды вообще". Я просто не знаю, как такие обзоры
устроены на практике
Если там ориентир - число звезд, то шансов нет никаких. Это как сравнивать цитируемость в разных областях науки: простенькая, но массовая утилита, заточенная на одно элементарное действие, заведомо обгонит любую узконишевую систему.
Конечно, кругозор расширять полезно, но в моем случае монолингва это сопряжено еще и с языковым барьером :-( Я никогда на гитхабы не лазил, и даже
не представляю, с чего начать
чтобы не утонуть в море бесполезных для меня знаний. В общем, пока кто-нибудь умный не ткнет меня носом "читай сюда", рак на горе не свистнет...
Теперь о шансах. Шансы, что кто-то со стороны быстро придет и начнет что-то добавлять в ваш сложный код на мертвом по сути языке довольно низкие. При этом если возникнут пользователи, то так или иначе качество кода будет улучшаться. Хотя бы потому, что люди будут приходить и задавать вопросы, по которым будут видны недостатки существующего кода. Может быть и критика, но критика означает в том числе интерес.
Да, именно так все и происходит сейчас. Примерно половину проблем/заявок я обнаруживаю в коде сам (как наиболее активный эксплуатант), еще столько же общими усилиями собирают все прочие пользователи. Из этих проблем я 2/3 решаю практически сразу, а треть откладываю на to_do, чтобы вернуться к ним, когда будет возможность. Но в прошлом году один из разработчиков пакета нас печально покинул, поэтому в 2024 папка to_do осталась наполовину несделанной... :-(
Даже если сторонних контрибьютеров не будет, будут ваши собственные студенты, для которых публичный вклад в проект будет хорошим опытом и хорошей добавкой в портфолио.
Мысль очень правильная. Спасибо, что напомнили. Проблема в том, что хотя формально я сотрудник московского института, но живу в 100км от Москвы и фактически уже много лет работаю удаленно. А со студентами надо общаться, причем регулярно. Поэтому я даже не думал о том, чтобы двинуться в эту сторону. Хотя мне уже намекали, что это неправильно. Похоже, пришло время задуматься...
То, что вы описываете - довольно типичная ситуация в ПО для науки. Ну и тут два пути, либо тянуть ту же историю, которая есть сейчас, при этом, разумеется, у вас есть "конкуренты" и если ваша область востребована, они будут вас очень быстро догонять (для поточной обработки в памяти существует уже довольно много инструментов, и главным блокером для появления новых является, как это ни удивительно пакет Pandas). Или вы понимаете, что вам нужно развитие, и тогда вам придется заняться поэтапной модернизацией проекта, которая требует довольно много усилий.
будет ли от этого какая-то польза: не хочется тратить ресурсы и время на то, что никогда никому не понадобится. Ведь шансы, что кто-то подключится к разработке,
Вот тут вам должно быть виднее, сколько будет пользователей у вашей программы, если допустим ее переписали с фортрана на С++, сделали современный удобный UI условно уровня Matlab с диалогами, графиками и пр, на мой взгляд нужно от этого отталкиваться.
сколько будет пользователей у вашей программы, если допустим...
Не думаю, что я смогу ответить на вопрос о числе пользователей хоть сколько-нибудь правдоподобно. Может, будет разлетаться. как горячие пирожки (при хорошем пиаре), а может - ни одного нового, сколько бы и чего б мы не сделали ;-)
ее переписали с фортрана на С++,
Вот именно эта опция на число юзеров не повлияет вообще никак ;-)
Юзеру вообще пофиг, на чем оно все написано - лишь бы работало быстро, и делало то, что нужно ;-)
Что же касается скорости, то тут С++ фортрану при прочих равных
скорее проигрывает, чем наоборот
Точнее, вычислительная эффективность у обоих языков имхо примерно сравнима... только вот чтобы написать высокоэффективную программу без багов на С++, квалификация программиста должна быть на две-три головы повыше ;-) В фортране же для этого достаточно знать массивные операторы, ну и изолировать разные подразделы кода в отдельных модулях (= классах). Все остальное сделает компилятор ;-)
Учитывая, что сейчас вычисления у нас написаны на фортране, и что для основного разработчика этот язык - родной, такое переписывание вообще никакой пользы не даст, кроме вреда (с). Что же касается потенциального круга комьюнити, то писать дополнения-расширения к нашей программе можно фактически на любом языке. Так как основное взаимодействие между модулями идет через файлы и системные сообщения - их даже не обязательно компилировать в единый exe-шник. Чтобы начать, достаточно
оформить С++ -интерфейсы к библиотекам ядра программы
обеспечивающим доступ к данным и пр. Кстати, один из юзеров это реально сделал какое-то время назад, и его приложения напрямую работают с нашей базой... Только сейчас он уже совсем не в науке :-((
Да, там довольно много всяких структур, но они переписываются на С++ один к одному. Ну и еще там примерно под сотню минималистичных функций типа
открытия-закрытия входных-выходных потоков
Для скорости и для аккуратного обслуживания NaN-значений мы работаем с файлами данных и скользящими по ним окнами через отдельный промежуточный уровень
Единственное, чего не сможет делать человек с другим стеком - это полноценно рефакторить вычислительные алгоритмы. Но тут уж ничего не поделаешь...
Что же касается GUI
он у нас, разумеется, есть,
так как основная идея программы - это визуально-ориентированная среда анализа данных. Где главную роль играет эксперт, а не алгоритмы. Поэтому 99% времени он видит перед собой не таблицы из списков методов и сигналов, а графики временных рядов в разных видах и представлениях. Которые занимают 99% экрана. А все элементы управления утрамбованы в самом минималистичном формате. Например, для настройки оси координат надо не лезть в меню (которое еще попробуй найди - изначально оно свернуто в один символ), а щелкнуть по этой оси. А для управления окном просмотра (если хочется получить расширенный доступ к настройкам) - щелкнуть по спрятанному в status line инфотексту с параметрами текущего окна. И так далее. Кстати, это тоже вызывает ступор у новичков, привыкших к современным стандартам. Особенно на начальном этапе, когда рука так и тянется к мышке (я сам при работе практически все делаю через хоткеи, но их же еще надо запомнить)
то GUI у нас и так написан на С++. Причем с определенным количеством разных трюков, без которых было бы невозможно обеспечить необходимую скорострельность при интерактивной визуализации совсем уж объемных данных.
сделали современный удобный UI условно уровня Matlab с диалогами, графиками и пр,
Ту есть ключевое слово "удобный". Лично для меня "современный удобный UI" (типа матлабовского) при работе с нашими данными гораздо менее удобен, чем уже сделанный у нас. Сейчас я практически любое действие могу выполнить через пару нажатий на клавиши. Ну изредка приходится что-нибудь выбрать мышкой прямо на графике, если, к примеру,
перемещать рамку выделения клавиатурно медленнее, чем мышкой
Хотя именно для того, чтобы уменьшить количество перехватов мышка-клавиатура, у нас одновременно работают три типа "горячих сочетаний" клавиш, которые двигают эту рамку с тремя разными скоростями. Причем эти скорости еще и немного подстраиваются динамически в зависимости от данных, показанных на экране
Проблема не в неудобстве нашего UI (на мой вкус, он, наоборот, максимально удобен), а в его нестандартности. Все заточено не просто под конкретные задачи, но фактически под конкретный стиль работы.
Или скажем диалоги. С одной стороны, они реализованы в виде всплывающих текстовых окон, что сильно ограничивает возможность донастроить оформление "под себя". С другой стороны, это оформление изначально настроено так, чтобы нескольким "приоритетным" пользователям было максимально удобно. Вплоть до побитовой подгонки цветовых масок. Для тех, кому это не нравится, есть единственный предустановленный альтернативный стиль - т.н. "светлая тема". Но донастроить ее под себя точно так же нельзя. И не потому, что это сложно реализовать (как раз прописать эти таблицы в конфиге и прикрутить к ним минимальный редактор - это вообще ерундовая фича). А потому, что работу с этими настройками придется описывать в справке, делать там защиту от дурака (чтобы какие-то важные вещи не стали невидимыми), и т.д., и т.п. У нас в пакете и так хватает всякой труднопонятной для нормального человека зауми. Усугублять ее еще и настройками интерфейса нам показалось излишним.
Или другой пример про удобство. У нас еще в 1980-х годах каждый диалог стал запоминать ввод юзера, и при следующем открытии диалога этот ввод автоматически подставляется
в качестве умолчания
Причем вне зависимости от того, открывался ли этот диалог в прошлый раз минуту назад или в прошлом году (т.к. ответы хранятся в специальном собственном файле, который легко можно перекинуть в другую папку или на другой комп вместе с программой простым копированием всей папки).
Если, конечно, данные не изменились настолько, что предыдущий ввод потерял всякий смысл (тогда умолчание корректируется "по мотивам" предыдущего ввода). Но строка ввода в любом случае точно не будет пустой - там с гарантией будет записан шаблон ответа, который точно прокатит при фактических характеристиках имеющегося набора сигналов. Для меня остается загадкой, почему такой стиль до сих пор не реализован во всех остальных программах, как общее правило. Ведь есть куча случаев, когда юзер решает похожие задачи неоднократно. А если вдруг нет, то никто не мешает начать ввод строки с нажатия символа, после чего шаблон исчезает, и все выглядит так, будто изначально поле ввода было пустым.
А уж как там в матлабе реализованы вектора timestamp-ов - это вообще за гранью добра и зла. Если бы мы использовали аналогичный подход, то потеряли бы в скорости (а также в требованиях к памяти) минимум втрое. Хорошо, что когда мы лишь начинали писать наш пакет (в 1985-м!), мы о матлабе просто
не знали ;-))
Я совершенно не говорю, что матлаб - это плохо! Но главные задачи у него откровенно другие, поэтому и оптимизация под нашу нишу попросту никакая. Одна только проблема с Nan-ами уже практически обнуляет шансы его сюда приспособить...
Единственное, чего мне сейчас реально не хватает в реализованном интерфейсе, это полноценного языка макросов. Де-факто наши макрокоманды запоминают нажатые клавиши, после чего записанный макрос можно применять многократно, или отредактировать-сохранить и т.д. Поскольку у нас очень часто приходится выполнять похожие процедуры с разными наборами рядов данных, без таких макросов была бы нудятина. Только вот чтобы превратить их во что-то более полноценное, нужно потратить серьезное время. Которое мне никак не удается найти... То есть, работать как-то работает, но нормальному юзеру непривычно. Ну и набор возможностей ограничен.
Вот именно эта опция на число юзеров не повлияет вообще никак ;-)Юзеру вообще пофиг, на чем оно все написано - лишь бы работало быстро, и делало то, что нужно ;-)Что же касается скорости, то тут С++ фортрану при прочих равных
Это опция не про юзеров, а про возможность привлечь сообщество, людей способных вести нужную вам разработку на С++ (или даже на C#) значительно больше в мире, чем на фортране.
Проблема не в неудобстве нашего UI (на мой вкус, он, наоборот, максимально удобен), а в его нестандартности. Все заточено не просто под конкретные задачи, но фактически под конкретный стиль работы.
UI это очень важная часть уже для пользователей, неудобный, не понятный, сложный UI может отпугнуть потенциальных пользователей и многие вместо использования вашей программы, будут писать свои скрипты как то обсчитывать. Тут точно нужно привлекать грамотного UI дизайнера или даже компанию (такие есть) которые разработают вам дизайн UI.
про возможность привлечь сообщество, людей способных вести нужную вам разработку на С++ (или даже на C#) значительно больше в мире, чем на фортране.
За всю историю проекта разрабы к нам присоединялись лишь пару раз. И так оказалось, что оба были плюсовиками. (Их действительно тупо больше). Но это вроде бы не мешало им понимать фортран, и даже писать на нем что-то. В любом случае "цена" переписывания на С++ всего кода (полмиллиона строк!) настолько запредельна, что это даже нет смысла обсуждать. Сделать это без багов будет дороже, чем написать аналогичный проект с нуля (имхо, это порядка 5 человеко-лет одним разработчиком сеньорского уровня или 10-15 человеко-лет впятером).
Да, эти примеры не снимают вопрос о понятности фортран-кода программеру с другим стеком. Но мне трудно его оценить самому, поэтому этот вопрос я задал в соседнем топике, с примерами кода. Там он вроде бы поуместнее. Но вообще, современный фортран - это имхо сильно недооцененный язык в массовом представлении. Так как подавляющее число программистов решает совсем другие задачи, где он не нужен и даже вреден, то и насчет языка возникает масса предубеждений. Хотя в своей собственной нише (в которую входим и мы) фортран вообще-то вне конкуренции в техническом плане. А столь же широкое использование (или даже преобладание) С++ внутри этой ниши объясняется вовсе не тем, что он чем-то лучше, а исключительно кратно большей доступностью разработчиков с этим стеком
В общем, идея с переписыванием фортран-вычислений на С++, имхо, очень неоднозначная. Так как скорость не увеличится, а простота и надежность очень сильно просядут. Если к этому все в итоге придет, то лишь в результате очень трудного компромисса (отказ от идеально подходящей к задачами, но узконишевой технологии в пользу более сложной и неудобной, но общеизвестной).
Тут точно нужно привлекать грамотного UI дизайнера или даже компанию (такие есть) которые разработают вам дизайн UI.
Если бы речь шла о массовом продукте, то да. Однако сейчас у проекта не так много пользователей. Но зато профессиональных, для которых это основной рабочий инструмент. Поэтому резкие изменения в UI неприемлемы - тут важно не навредить. А если говорить про "нерезкие", то я и сам знаю про несколько багов, которые ощутимо мешают. Одна из основных проблем - у нас все заточено под десктопную клаву, поэтому работать на ноуте весьма неудобно. Но как это исправить, неясно. Вопрос тут не столько в дизайне, сколько в том, что нам надо много хоткеев. Чем, например заменить Fn в комбинациях с Alt/Ctrl//Shift? Буквами не получится, так как свободных букв (включая их комбинации с Alt и Ctrl) тоже нету. Да, они не нужны все одновременно в одном экране. Но ведь хоткеи должны по возможности согласовываться между собой как в разных экранах одной программы, так и в разных программах, с которыми юзер имеет дело. Поэтому иногда нам просто необходимы синонимы, чтобы одно и тоже можно было сделать двумя разными способами. А еще очень хочется, чтобы команды, которые часто нужны подряд, особенно с общим модификатором, были прицеплены к близко расположенным буквам.
И аналогичная проблема с правой цифровой клавиатурой, и др.
В общем, привлечь дизайнера можно, но он первым делом задаст вопрос о цели оптимизации. Я, например, не думаю, что какой-нибудь банк не может нанять дизайнера. Однако унификация интерфейса к мобильной версии (которая чаще нужна) привела к такой деградации десктопного интерфейса, что такого дизайнера лучше не надо ;-) Во всяком случае лично мне, как десктопщику ;-)) "Стандартный стиль" далеко не всегда означает "удобный", особенно если ты уже привык к "нестандартному". Конечно, стандартизация может снизить порог вхождения... но что от этого толку, если у опытных юзеров их скорость работы (одно из важных достоинств программы) уменьшится вдвое?
Александр Нозик, директор Scientific Programming Centre, о научном программировании, open source в России и не только