Я учился в 3 школах, по советской, американской, и новой украинской системе. Также смотрю на младшего брата и иногда вижу других лицейских деток. Могу сказать так, что, во-первых — это нам ещё надо кое чему поучиться у американской системы. Во-вторых, уж что-что, а программирование и математика в советской школе, можно считать, вообще отсутствовали, по сравнению с тем, что творится сейчас. Детям в младшей школе на картинках алгоритмы объясняют, и задания такого же плана дают. В итоге ребёнок учится мыслить математически. А в советское же время компьютер был чудо машиной. По собственному опыту могу сказать, что советские учебники рассказывают удивительные вещи, как, к примеру, про число Скьюза, но вот советская система образования совершенно не заботилась о том, чтобы у детей появилось понимание. Т.е. из предмета математики они бы вынесли факт, что есть такое число, и совковые учителя заставили бы его вызубрить эти, и другие факты. Но понимание всего этого, и математическое мышление пришлось бы вырабатывать самостоятельно, не в школе. В современной системе ровно наоборот. Фактаж уменьшен, зато больший упор на то, чтобы добиться от всех детей глубокого понимания основ. Я считаю такой подход правильнее. Из америки же приходят методики ещё более высокого уровня — дивергентные задачи, с множественными ответами. Может показаться что это не случай математики, но на самом деле в прикладной математике такого навалом.
+ меня просто покоряют научные ярмарки в американской системе. Это как два разных мира — в одном мы заставляем умных ребят крутиться самим, и в итоге если есть талантливые дети, которые ещё этого не открыли в себе, система их пропускает, и они идут работать грузчиками. В другом — каждого заставляют прикоснуться к науке и почувствовать, что он может. В таком варианте никого не оставляют, все проходят через процесс. Так мне больше нравится. В сср найчных ярмарок тоже не было.
Спасибо, понял. Но случай вопиющий (система с ограничениями на память — скорее всего контроллер, и на них я бы ожидал задокументированную длину пакетов со всех сторон...).
Более реальный случай под ту же математическую логику — нужно делать наложенное изображение из нескольких слайдов-слоёв. Слайды загружаются поочерёдно, и неисвестно, сколько их будет всего. Как обеспечить равномерное наложение слоёв?
Объясните плиз, про генератор случайных. То ли лыжи не едут, то ли я не понимаю в чём сложность.
буфер?
Есть реальный поток данных. Если он бесконечен, то вероятность выбрать любое из чисел должна быть нулевой. Если он конечен, то у него есть длина n. Если она меньше нашего объёма буфера, то возвращаем из генератора число от 1 до n с равной вероятностью. Если больше — то возвращаем случайный момент времени из диапазона когда велась трансляция, и ровно в этот момент хватаем последнее попавшее в буфер число. Если скорость передачи не фиксирована, то просто знаем сколько раз наполнится буфер, и считаем два числа random%N и N%databuffer. Так как каждое из них независимое, то и вероятность равна для всех.
Растворить ещё одну А и выпить полстакана, тщательно перемешав. Вторую половину на завтра.
Зарплата
Сначала я подумал что каждому надо добавить случайное число, затем сложиться, и вычесть все три числа. Но тогда получается что сумму можно вычислить постфактум. Значит, им надо ещё и обменяться теми случайными числами по кругу. Пусть a, b, c — зарплаты; A, B, C — их личные случайные числа. aa<< — информация, которую получил aa.
bb<< (a+A)
cc<< (a+A+b+B)
aa<< (a+A+b+B+c+C)
bb<< (a+b+B+c+C)
cc<< (a+b+c+C)
Теперь сс вычитает своё число и делит на три.
1
Можно написать слегка оптимизированный перебор — перебрать упорядоченные наборы, умножая каждый новый на количество перестановок.
2
def not3(x):
if x < 3:
return x
b = 1
a = -1
while b < x:
b *= 10
a += 1
b //= 10
res = x//b
if res > 3: res -= 1
res2 = 0
for i in range(a):
res2 *= 9
res2 += 10**i
res = res * b - res * res2 + not3(x % b)
return res
Более непонятного чем 3 задание ещё ничего не было) Что значит дополнение? В оригинале более интересный термин, дополнить до укомплектовки. Что есть укомплектованное число?
А… Я подумал что их заменяют не в коробке, а в руке. Мол, взяли два, а потом положили назад в коробку и взяли оттуда чёрный или белый, в зависимости от комбинации.
Вовсе нет. Шары всегда извлекаются по одному. Вот взяли два чёрных — заменили на белый (т.е. оба чёрных остались в коробке, вместо них ушёл белый), взяли чёрный и белый — ушёл чёрный (один, белый остался в коробке).
Белый шар останется. Есть комбинации где извлекая пары чёрных можно потратить все белые, но тогда не может остаться одного шара (всегда минимум 2 чёрных останется, а надо ответить про цвет последнего шара). Вывод — чёрные необходимо исчерпать раньше белых, чтобы была возможность оставить только один шар. Соответственно, шар будет белым.
Да, если юпитер под боком, то пайтоном можно сделать всё вышеперечисленное, и даже красиво оформить прямо на листе, где он выполняется.
Вот интересная вещь) В линуксе действительно проще компилировать библиотеки. А в виндоусе проще использовать уже скомпилированые, и никогда не иметь проблем с несовпадением версии компилятора, или с нехваткой библиотек, которые лично человеку в задаче не нужны, но их требует для компиляции нужная библиотека.
Если говорить про куду, то у меня с ней был ад именно на линуксе (ведь санчала нужно поставить правильную версию драйверов, что не всегда возможно нормальными способами). А на винде как-то на раз два — всё автоматизировано (в линуксе тоже есть автоматизирующие скрипты, но они постоянно пытаются то скачивать что-то с давно не существующих репозиториев, то загружают версии несовместимые с чем-то что уже стоит в системе, то ещё что-то неожиданное происходит). Вообще столько головняка с версиями всего-на-свете я на винде никогда не имел. Устанавливал по три версии проги, каждая из которых пыталась апгрейдить уже существующую, и решал проблемы банальным перемещением папок. В линуксе ради такого приходится почему-то возиться с системными путями, и при чём эти пути отчего-то гораздо менее удобно организованы чем на винде (хотя редактировать их нужно чаще).
Насчёт научного софта далеко ходить не надо. Простейшая программа для символьных вычислений — маткад — на линуксах не работает, даже из эмулятора не очень чтобы. А оказавшись без ориджина я уже ощущаю себя как без рук (на 3 ноута и комп поставил, не только на рабочий — просто чтобы был, если внезапно понадобится). Попробуйте, может и вы в зависимость впадёте.
Я уже описал проблему, думаю понятно. Искать примеры использования этих вещей мне лень, т.к. сам я их не использую, но поверьте, бывают проблемы. Мне кидали файлики, которые парсились неправильно, или только с какой-то левой кодировкой, или с лишними токенами из-за ,/;.
А если это модуль программы, как процедура в делфи, то вы и из консоли её не запустите отдельно.
Это реальный случай?
Да. Режим подключения определяется тем, кто и как настраивал сервер. А программок которые роняют что-то в линуксе море (даже драйвер на графику не поставить, когда есть графика — парадокс). Вообще отдельная от ОС графическая оболочка было для меня новостью тогда. Типа вот есть программа, только окна и кнопки ты рисуешь для неё в отдельной программе-оболочке опять-таки, очень сильно противоречит интуиции.
в графическом интерфейсе тем более могут возникнуть проблемы.
В графическом не возникало, пока что-то не сломалось, и такой способ оказался недоступным.
Статьи (практически без вариантов) — latex.
Латех придумали верстальщики, чтобы переложить на учёных часть своей работы. Форматированием обязаны заниматься издатели. это всегда так для журналистов и писателей. Но на учёных решили сэкономить, и теперь многие журналы требуют это безумие — чтобы им отправляли статьи на языке разметки. Латех удобен только если набирать формулы, при чём для человека, который не в курсе что их можно набирать в визивиг-редакторе, или на форумах, где этих редакторов нет, а есть только разметки.
Вообще говоря я диссертацию пишу в ворде, и ни за что не открою опенсорсным аналогом, потому что есть большой шанс крашнуть документ. В powerpoint при желании можно сделать motion graphics и примитивненький скрайбинг, не говоря уже о том, что под виндоус существуют более продвинутые программі для презентации. impress начиная с некоторого размера будет не открываться, крашиться, система будет зависать на видеовставках. Инструменты для анимации там почти такие же, только их чуть меньше, и тайминг в них спонтанно сбивается — нет гарантии что одна анимация отработает одинаково каждый раз. С графиками я работаю в 5 программах, 3 из которых принципиально не поддерживаются на линуксах, а две — вебприложения, так что наверное, заработают… Для блоксхем я использую лио визио, либо пару yed + графический редактор (когда завезут фри-фотошоп на линуксе?). Inkscape, конечно, ничего, я им и с виндоуса пользуюсь. Шрифт даже можно свой сделать. Удобная вещь. Но всё таки количество вещей которые можно делать программами на линуксе не только меньше того многообразия на винде, но и меньше того, что необходимо.
Подумал пару дней, но так и не придумал как это сделать. Поменять местами циклы переборов можно, но производительность тогда только упадёт, поскольку неизвестное (но большое) число раз отрабатывает подбор начальной производной для стрельбы, и размещая дифференциальный прирост функции внутри него мы будем расчитывать её заведомо большее число раз. А если вынести обратно только функцию пересчёта дифференциала на шаге, чтобы этого избежать, то мы приходим к моему методу, где по сути отдельно идёт решение обычным РК, и на каждом его шаге отрабатывает стрельба.
Инструкции к лазеру: не лезть к внутренним контактам руками без антистатического браслета, не отключать стабилизатор напряжения, не светить в глаза. Одно предложение, три пункта. С этими правилами сломать установку или навредить людям уже очень сложно. Сбить настройки можно, но потом значит придётся калибровать, только и всего. Перекачать прибор, который всё время работает в инверсной населённости? Бред, даже если светить двумя лазерами друг в друга. Спалить высоким напряжением? С поставляемым с лазером стабилизатором и защитой от статики почти нереально. Разве что гвозди им забивать, тогда конечно, сломается.
Инструкции к С, С++, общие правила работы с памятью, описание стандартной библиотеки и буста — текст будет в очень много раз длиннее. И любое правило при несоблюдении может заставить программу работать неправильно из-за ub или вылета памяти. Воспринимать это как полноценный инструмент сложно, по скольку нет протых инструкций, с которыми можно быстро ознакомить человека, и оставить его работать, твёрдо зная, что он ничего не испортит.
Ну пусть 10-разовый (если учитывать копии с искажениями). Это не меняет подхода. Не должен будет этот код работать на сервере, чтобы его через апи 10000 пользователей в секунду дёргали. Я указал этот пункт в статье чтобы показать отличие от веб-программирования, где более существена скорость отработки, и заставлять пользователя ждать несколько часов неприемлимо. И от программирования встроенных систем, где необходима реакция в реальном времени, и обращения идут от одного компьютера 9600 раз в секунду. Там тоже так нельзя. А в научных — пфф, есть ещё время пока решаешь уравнения, проводишь эксперименты, читаешь статьи, дописываешь свои тексты, обсуждаешь с коллегами, посещаешь семинары, читаешь лекции, кушаешь и спишь. Исследования за один день не делаются (большая их часть).
Именно. Память нужна не лично программисту, а переменным в алгоритме, который он сочинил. Если он может использовать абстракцию массива не вдаваясь в детали, как внутри она устроена, и как выделяет-освобождает память, то и не нужно вдаваться.
Касательно же прямой работы с памятью, поле того как я более плотно познакомился с rust я начал удивляться, как это можно было придумать такую странную контринтуитивную штуку как С. Если считается необходимой работа с памятью для быстрых вычислений, то почему же её не делают обязательной при объявлении, и не вводят счётчики ссылок? В научных вычислениях, впрочем, я пока rust не применял, жду пока полезные библиотеки перепишут, тогда попробую поднять скорость своих программ с экспериментами. Но на С++ я это делать не рискну — больше нервов потрачу на всякие вылазящие ub, чем пользы нанесу.
Вот я не подумал… Действительно, просто для организации протокола связи много ресурсов не надо, можно было в коробке запустить. Хотя поставить виртуалку и развернуть на ней ОС — это тоже некоторое время занимает. Так что решение с двумя компьютерами сэкономило рабочее время над проблемой.
Но на будущее я запомню. Как же так-то, не догадался виртуалбокс поставить.
Ну он отработает один раз. Подвергнется некоторым переделкам, чтобы немого другое посмотреть. Затем запустится существенно другой код, тоже один раз. Всего, кусок кода с уравнением, может быть, запускался 8-10 раз. Но это, во-первых, всё равно счётное число раз. Во-вторых, каждая версия кода сильно отличается от предыдущей, хотя может содержать тот же метод и то же уравнение. Именно в этом и преимущество программирования — в готовом пакете можно как-то оформить в правильном виде функцию. Потом хочеться сделать один из её параметров варьируемым, или зависимым, и, скорее всего, придётся менять весь вид задания условий, и переписать с нуля весь блок символьных вычислений.
В программировании можно сделать проще, и использовать разрешающую часть кода снова, просто вмонтировав куда-нибудь во внутрений цикл строчку-две, или добавив ещё один. Нет никаких ограничений, как в матпакетах (матпакет бы ругнулся что в первой строке нужно указывать уравнение без у в правой части, после переписывания под этот каприз он бы сказал что больше трёх уравнений не принимает, потом становится понятно что переписать в более компактную систему с развязаными правыми частями не получается, и всё — надо помещать решение в цикл, и вручную дописывать логику выбора из двух-трёх систем… В итоге такой код в матпакете раздувается на несколько листов, и в нём гораздо проще запутаться).
Ну и если делать как принято у программистов — создавать программу и модифицировать её с помощью программы для контроля версий, тогда это был бы всё равно запуск одной программы. Но я так не делаю, поскольку было бы странно под одним названием но разными версиями хранить программы, которые считают разное. Проще хранить отдельно 10 файликов с частично повторяющимся кодом, но зато каждый из них будет иметь своё предназначение. Так что даже в конце работы над проблемой это будет 10 разных программ, абсолютно независимых, и без общих модулей. Так правильнее.
Все описаные минусы не относятся к ситуации. Когда есть приблизительные представления о том что будешь делать в будущем, когда/если данный код заработает. И когда функции всё равное тестируются и не документируются.
Как может быть более удобный способ вывести, например, таблицу, в файл, чем что-то вроде питоновских dictwriter или pandas?
Как насчёт убегающих разделителей? Насколько я понимаю, надо в параметр ридера потом вручную передавать информацию о символах разделителя и цитации, т.е. надо быть внимательным, и желательно не писать разнородные данные в один файл. Тогда как в стандартных объектах вывода на гуи прописана какая-то дефолтная токенизация, и пользователю уже даже не обязательно знать как храниться файл — уже всё сделано за него. Безопаснее же.
Эм, а как вы задаёте параметры симуляции например — не все же они зашиты в коде? Да и последовательность нажатия кнопок, если функций много, тоже быстро может забыться — а если бы это было в командной строке, то всё сохранится в быстрой доступности.
Ни зашивка параметров в код, ни забывание последовательности — не проблема для одноразового кода.
Как-то на глаз мало что можно улучшить в поиске по истории.
Если только не добавить интерфейс. Например, сделать как поиск текста на вебстраницах в браузерах, для начала. А вообще-то, если уж писать действия пользователя, то для этого есть специальные инструменты. Слухачи кнопок, рекордеры (иногда даже просто подключаемые как плагин) и всякое такое.
пишешь буквально ту же самую последовательность команд, что выполнял бы вручную, в нужном порядке в файл
Ну, то есть пишется скрипт. Который можно написать и в скриптовом языке программирования. И добавить в проект, чтобы пользователь не шёл в консоль.
Вообще-то вся работа с удалённым компьютером по ssh происходит в отдельном окне терминала, и ничего не мешает держать открытым браузер/другие приложения.
Теперь допустим, что сервер на компьютере-1 настроен таким образом, что подключится можно только программой А. Доступа к компьютеру-1 у вас нет, чтобы просто по другому настроить сервер, пускай он вообще стоит в другой стране, и возятся с ним 3 индуса и сторож, которым объяснить ничего нельзя; но зато есть компьютер-2, вы скачиваете программу А, и оказывается, что каждый её запуск нечаянно все ваши драйвера на видеокарту (особенность конфигурации к-2, не более). Приходится переключатся в режим терминала на компьютере-2, чтобы подсоединиться к компьютеру-1 через А (которая просто реализует протокол ssh с какой-то дополнительной защитой). Примерно так происходил мой первый опыт работы с этой штукой, и он мне не понравился. Мало того, что надо терминалом управлять удалённым компом, так ещё и на своём тоже в терминал переключаться. Проще всего тогда было найти ещё один компьютер, но решение не претендует на универсалность.
И да, default OS как-то так вышло, что у 80+% linux, и много софта нормально работает только под ним.
Учёный должен ещё (кроме работы с данными) работать со статьями, и писать тексты, и делать презентации, и визуализации, и много всякого разного. А о превосходстве офиса майкрософт над опенсорсными аналогами я могу слагать целые легенды и балады. Из этих двух фактов можно заключить, что windows учёному необходима. Кроме того, мне абсолютно неясны механизмы смещения статистики ОС среди учёных относительно мировой в пользу линукса (не вижу причин, почему среди учёных могло бы быть больше чем стандартные 1-2% по миру).
А моё личное отвращение (не имеющее отношения к вопросу об отношении среднестатистического учёного) легко объясняется сильной 23-летней привычкой к внутреннему обустройству Windows, ассоциацией текстового линукса с досом, который я ещё немного помню, и собственным опытом работы с линуксом, где мне пришлось буквально вывернуть своё мышление наизнанку ради дела. С линуксом мне в то времяпришлось больше заниматься настройкой, линковкой, версиями, версиями, компиляторами… И это было 80% времени. Тогда как с виндой я 80% времени выдумывал алгоритмы и архитектуру, и потом реализовывал и оттачивал дебагом свои идеи. Это гораздо интереснее, тем более с блэкджеком и графикой.
Если говорить о вашей статистике, то меня она шокирует. Вот я посмотрел у меня в группе пользователей проги 58 человек, двое используют линукс.
Если в таком духе писать, то и преимуществ относительно командного интерфейса не будет. А вот недостатки есть, значительные. Самый важный на мой взгляд — нетривильно сохранять полную историю, какие команды с какими параметрами и когда запускались. В командной строке это идёт из коробки, причём с удобным поиском, фильтрацией и автодополнением, а в gui нормально реализовать не так просто.
-Если в таком стиле писать, то у стандартных объектов вывода есть методы по типу «сохранить всю инфу в файл», который проще настроить чем ручной вывод данных в правильном формате.
-Зачем нужна история использования программы, если задачей является получение итоговых данных? Команд с параметрами же в гуи-приложении нет, есть подписаные кнопки, которые нажимает пользователь.
-Я бы не стал употреблять слово «удобно» в одном предложении с символьными интерфейсами без частицы «не». Даже поиск в линуксе не то чтобы очень удобен, и из коробки действительно приходится листать history. Но prompt ещё более мозговыносящий чем их терминал (default OS = Windows, потому что даже по консольно-запускаемым программам-симмуляциям туториалы ориентированы в первую очередь на винду).
Ну и про простейшую автоматизацию выполнения нескольких программ подряд с передачей данных от одной к другой тоже не стоит забывать — в gui это сложновато, а используется часто.
В своём личном опыте я сталкивался только с таким методом: консоль запускает программу и оставляет данные в файле в папке с определённым именем. Следующая команда берёт данные из папки с этим именем. И так далее. То есть всё равно передача данных идёт с использованием файловой системы ОС, так что никакой особой проблемы с тем чтобы сразу так написать в коде — вместо возложения ответственности на то что пользователь заполнит параметры командной строки при запуске — нет.
Ещё как бонус — к командной оболочке я могу подключиться отовсюду, был бы мобильный интернет.
Можно управлять домашним компьютером с мобильника, и видеть на экране привычную графическую оболочку. Точно могу сказать, что интернет пятилетней давности позволял это делать, скорости хватало.
Под рукой нужен ровно один — с которого подключаетесь и за которым собственно сидите.
Да. Один настроенный. Второй, с которого подключаешься. И третий, в котором можно быстро загуглить проблему, если что-то пойдёт не так (во втором гуи может оказаться недоступным из-за особенностей настройки первого).
для gui нужно писать слишком много никак не относящегося к делу коду
В Делфи, к примеру, на форму бросается объект. Затем дабл клик по нему генерирует весь необходимый код (объект появляется в списке на инициализацию, создаётся процедура клика, и даже курсор ставится на то место, куда писать код). А вывод в листбокс там такой же однострочный, как и вывод в консоль. Так что никаких дополнительных затрат по написанию кода нет. Вот в С++ как раз придётся написать код импортирующий ио и скорее всего строки. И стандартную библиотеку, весьма вероятно. И бог ещё знает что.
Чем же вам ssh так не понравился
Тем, что самый простой способ работать по нему — это иметь под рукой ещё третий компьютер с гуи и открытым браузером. Плюс безальтернативная работа с текстом нагоняет ощущения, как от давно позабытого доса, что в современном мире причиняет некоторый дискомфорт. Всегда гадал, какая такая профессиональная деформация заставляет некоторых линуксоидов сносить вообще графическую оболочку и с упоением ковыряться в символьном «интерфейсе».
По желанию можно брать курсы по всяким питонам, функциональным языкам и т.п.
Ну, среди курсов по желанию у нас, к примеру, работа с С++ была, там даже всяким тонким хитростям с битовыми операциями учили. У нас система в университете такая была, что любые опциональные курсы может взять себе любой студент с любого факультета. Так что таким образом программирование мог бы учить не только физик, но и, скажем, филолог. Но в качестве базы С++ шёл только у прикладных математиков, системных аналитиков, системных администраторов и у всех программистов.
+ меня просто покоряют научные ярмарки в американской системе. Это как два разных мира — в одном мы заставляем умных ребят крутиться самим, и в итоге если есть талантливые дети, которые ещё этого не открыли в себе, система их пропускает, и они идут работать грузчиками. В другом — каждого заставляют прикоснуться к науке и почувствовать, что он может. В таком варианте никого не оставляют, все проходят через процесс. Так мне больше нравится. В сср найчных ярмарок тоже не было.
Более реальный случай под ту же математическую логику — нужно делать наложенное изображение из нескольких слайдов-слоёв. Слайды загружаются поочерёдно, и неисвестно, сколько их будет всего. Как обеспечить равномерное наложение слоёв?
bb<< (a+A)
cc<< (a+A+b+B)
aa<< (a+A+b+B+c+C)
bb<< (a+b+B+c+C)
cc<< (a+b+c+C)
Теперь сс вычитает своё число и делит на три.
Более непонятного чем 3 задание ещё ничего не было) Что значит дополнение? В оригинале более интересный термин, дополнить до укомплектовки. Что есть укомплектованное число?
Вот интересная вещь) В линуксе действительно проще компилировать библиотеки. А в виндоусе проще использовать уже скомпилированые, и никогда не иметь проблем с несовпадением версии компилятора, или с нехваткой библиотек, которые лично человеку в задаче не нужны, но их требует для компиляции нужная библиотека.
Если говорить про куду, то у меня с ней был ад именно на линуксе (ведь санчала нужно поставить правильную версию драйверов, что не всегда возможно нормальными способами). А на винде как-то на раз два — всё автоматизировано (в линуксе тоже есть автоматизирующие скрипты, но они постоянно пытаются то скачивать что-то с давно не существующих репозиториев, то загружают версии несовместимые с чем-то что уже стоит в системе, то ещё что-то неожиданное происходит). Вообще столько головняка с версиями всего-на-свете я на винде никогда не имел. Устанавливал по три версии проги, каждая из которых пыталась апгрейдить уже существующую, и решал проблемы банальным перемещением папок. В линуксе ради такого приходится почему-то возиться с системными путями, и при чём эти пути отчего-то гораздо менее удобно организованы чем на винде (хотя редактировать их нужно чаще).
Насчёт научного софта далеко ходить не надо. Простейшая программа для символьных вычислений — маткад — на линуксах не работает, даже из эмулятора не очень чтобы. А оказавшись без ориджина я уже ощущаю себя как без рук (на 3 ноута и комп поставил, не только на рабочий — просто чтобы был, если внезапно понадобится). Попробуйте, может и вы в зависимость впадёте.
А если это модуль программы, как процедура в делфи, то вы и из консоли её не запустите отдельно.
Да. Режим подключения определяется тем, кто и как настраивал сервер. А программок которые роняют что-то в линуксе море (даже драйвер на графику не поставить, когда есть графика — парадокс). Вообще отдельная от ОС графическая оболочка было для меня новостью тогда. Типа вот есть программа, только окна и кнопки ты рисуешь для неё в отдельной программе-оболочке опять-таки, очень сильно противоречит интуиции.
В графическом не возникало, пока что-то не сломалось, и такой способ оказался недоступным.
Латех придумали верстальщики, чтобы переложить на учёных часть своей работы. Форматированием обязаны заниматься издатели. это всегда так для журналистов и писателей. Но на учёных решили сэкономить, и теперь многие журналы требуют это безумие — чтобы им отправляли статьи на языке разметки. Латех удобен только если набирать формулы, при чём для человека, который не в курсе что их можно набирать в визивиг-редакторе, или на форумах, где этих редакторов нет, а есть только разметки.
Вообще говоря я диссертацию пишу в ворде, и ни за что не открою опенсорсным аналогом, потому что есть большой шанс крашнуть документ. В powerpoint при желании можно сделать motion graphics и примитивненький скрайбинг, не говоря уже о том, что под виндоус существуют более продвинутые программі для презентации. impress начиная с некоторого размера будет не открываться, крашиться, система будет зависать на видеовставках. Инструменты для анимации там почти такие же, только их чуть меньше, и тайминг в них спонтанно сбивается — нет гарантии что одна анимация отработает одинаково каждый раз. С графиками я работаю в 5 программах, 3 из которых принципиально не поддерживаются на линуксах, а две — вебприложения, так что наверное, заработают… Для блоксхем я использую лио визио, либо пару yed + графический редактор (когда завезут фри-фотошоп на линуксе?). Inkscape, конечно, ничего, я им и с виндоуса пользуюсь. Шрифт даже можно свой сделать. Удобная вещь. Но всё таки количество вещей которые можно делать программами на линуксе не только меньше того многообразия на винде, но и меньше того, что необходимо.
Инструкции к С, С++, общие правила работы с памятью, описание стандартной библиотеки и буста — текст будет в очень много раз длиннее. И любое правило при несоблюдении может заставить программу работать неправильно из-за ub или вылета памяти. Воспринимать это как полноценный инструмент сложно, по скольку нет протых инструкций, с которыми можно быстро ознакомить человека, и оставить его работать, твёрдо зная, что он ничего не испортит.
Касательно же прямой работы с памятью, поле того как я более плотно познакомился с rust я начал удивляться, как это можно было придумать такую странную контринтуитивную штуку как С. Если считается необходимой работа с памятью для быстрых вычислений, то почему же её не делают обязательной при объявлении, и не вводят счётчики ссылок? В научных вычислениях, впрочем, я пока rust не применял, жду пока полезные библиотеки перепишут, тогда попробую поднять скорость своих программ с экспериментами. Но на С++ я это делать не рискну — больше нервов потрачу на всякие вылазящие ub, чем пользы нанесу.
Но на будущее я запомню. Как же так-то, не догадался виртуалбокс поставить.
В программировании можно сделать проще, и использовать разрешающую часть кода снова, просто вмонтировав куда-нибудь во внутрений цикл строчку-две, или добавив ещё один. Нет никаких ограничений, как в матпакетах (матпакет бы ругнулся что в первой строке нужно указывать уравнение без у в правой части, после переписывания под этот каприз он бы сказал что больше трёх уравнений не принимает, потом становится понятно что переписать в более компактную систему с развязаными правыми частями не получается, и всё — надо помещать решение в цикл, и вручную дописывать логику выбора из двух-трёх систем… В итоге такой код в матпакете раздувается на несколько листов, и в нём гораздо проще запутаться).
Ну и если делать как принято у программистов — создавать программу и модифицировать её с помощью программы для контроля версий, тогда это был бы всё равно запуск одной программы. Но я так не делаю, поскольку было бы странно под одним названием но разными версиями хранить программы, которые считают разное. Проще хранить отдельно 10 файликов с частично повторяющимся кодом, но зато каждый из них будет иметь своё предназначение. Так что даже в конце работы над проблемой это будет 10 разных программ, абсолютно независимых, и без общих модулей. Так правильнее.
Как насчёт убегающих разделителей? Насколько я понимаю, надо в параметр ридера потом вручную передавать информацию о символах разделителя и цитации, т.е. надо быть внимательным, и желательно не писать разнородные данные в один файл. Тогда как в стандартных объектах вывода на гуи прописана какая-то дефолтная токенизация, и пользователю уже даже не обязательно знать как храниться файл — уже всё сделано за него. Безопаснее же.
Ни зашивка параметров в код, ни забывание последовательности — не проблема для одноразового кода.
Если только не добавить интерфейс. Например, сделать как поиск текста на вебстраницах в браузерах, для начала. А вообще-то, если уж писать действия пользователя, то для этого есть специальные инструменты. Слухачи кнопок, рекордеры (иногда даже просто подключаемые как плагин) и всякое такое.
Ну, то есть пишется скрипт. Который можно написать и в скриптовом языке программирования. И добавить в проект, чтобы пользователь не шёл в консоль.
Теперь допустим, что сервер на компьютере-1 настроен таким образом, что подключится можно только программой А. Доступа к компьютеру-1 у вас нет, чтобы просто по другому настроить сервер, пускай он вообще стоит в другой стране, и возятся с ним 3 индуса и сторож, которым объяснить ничего нельзя; но зато есть компьютер-2, вы скачиваете программу А, и оказывается, что каждый её запуск нечаянно все ваши драйвера на видеокарту (особенность конфигурации к-2, не более). Приходится переключатся в режим терминала на компьютере-2, чтобы подсоединиться к компьютеру-1 через А (которая просто реализует протокол ssh с какой-то дополнительной защитой). Примерно так происходил мой первый опыт работы с этой штукой, и он мне не понравился. Мало того, что надо терминалом управлять удалённым компом, так ещё и на своём тоже в терминал переключаться. Проще всего тогда было найти ещё один компьютер, но решение не претендует на универсалность.
Учёный должен ещё (кроме работы с данными) работать со статьями, и писать тексты, и делать презентации, и визуализации, и много всякого разного. А о превосходстве офиса майкрософт над опенсорсными аналогами я могу слагать целые легенды и балады. Из этих двух фактов можно заключить, что windows учёному необходима. Кроме того, мне абсолютно неясны механизмы смещения статистики ОС среди учёных относительно мировой в пользу линукса (не вижу причин, почему среди учёных могло бы быть больше чем стандартные 1-2% по миру).
А моё личное отвращение (не имеющее отношения к вопросу об отношении среднестатистического учёного) легко объясняется сильной 23-летней привычкой к внутреннему обустройству Windows, ассоциацией текстового линукса с досом, который я ещё немного помню, и собственным опытом работы с линуксом, где мне пришлось буквально вывернуть своё мышление наизнанку ради дела. С линуксом мне в то времяпришлось больше заниматься настройкой, линковкой, версиями, версиями, компиляторами… И это было 80% времени. Тогда как с виндой я 80% времени выдумывал алгоритмы и архитектуру, и потом реализовывал и оттачивал дебагом свои идеи. Это гораздо интереснее, тем более с блэкджеком и графикой.
Если говорить о вашей статистике, то меня она шокирует. Вот я посмотрел у меня в группе пользователей проги 58 человек, двое используют линукс.
-Если в таком стиле писать, то у стандартных объектов вывода есть методы по типу «сохранить всю инфу в файл», который проще настроить чем ручной вывод данных в правильном формате.
-Зачем нужна история использования программы, если задачей является получение итоговых данных? Команд с параметрами же в гуи-приложении нет, есть подписаные кнопки, которые нажимает пользователь.
-Я бы не стал употреблять слово «удобно» в одном предложении с символьными интерфейсами без частицы «не». Даже поиск в линуксе не то чтобы очень удобен, и из коробки действительно приходится листать history. Но prompt ещё более мозговыносящий чем их терминал (default OS = Windows, потому что даже по консольно-запускаемым программам-симмуляциям туториалы ориентированы в первую очередь на винду).
В своём личном опыте я сталкивался только с таким методом: консоль запускает программу и оставляет данные в файле в папке с определённым именем. Следующая команда берёт данные из папки с этим именем. И так далее. То есть всё равно передача данных идёт с использованием файловой системы ОС, так что никакой особой проблемы с тем чтобы сразу так написать в коде — вместо возложения ответственности на то что пользователь заполнит параметры командной строки при запуске — нет.
Можно управлять домашним компьютером с мобильника, и видеть на экране привычную графическую оболочку. Точно могу сказать, что интернет пятилетней давности позволял это делать, скорости хватало.
Да. Один настроенный. Второй, с которого подключаешься. И третий, в котором можно быстро загуглить проблему, если что-то пойдёт не так (во втором гуи может оказаться недоступным из-за особенностей настройки первого).
В Делфи, к примеру, на форму бросается объект. Затем дабл клик по нему генерирует весь необходимый код (объект появляется в списке на инициализацию, создаётся процедура клика, и даже курсор ставится на то место, куда писать код). А вывод в листбокс там такой же однострочный, как и вывод в консоль. Так что никаких дополнительных затрат по написанию кода нет. Вот в С++ как раз придётся написать код импортирующий ио и скорее всего строки. И стандартную библиотеку, весьма вероятно. И бог ещё знает что.
Тем, что самый простой способ работать по нему — это иметь под рукой ещё третий компьютер с гуи и открытым браузером. Плюс безальтернативная работа с текстом нагоняет ощущения, как от давно позабытого доса, что в современном мире причиняет некоторый дискомфорт. Всегда гадал, какая такая профессиональная деформация заставляет некоторых линуксоидов сносить вообще графическую оболочку и с упоением ковыряться в символьном «интерфейсе».
Ну, среди курсов по желанию у нас, к примеру, работа с С++ была, там даже всяким тонким хитростям с битовыми операциями учили. У нас система в университете такая была, что любые опциональные курсы может взять себе любой студент с любого факультета. Так что таким образом программирование мог бы учить не только физик, но и, скажем, филолог. Но в качестве базы С++ шёл только у прикладных математиков, системных аналитиков, системных администраторов и у всех программистов.