> Что именно стоило бы добавить?
Ну, стоило бы начать с разъяснения проблемы. Привести примеры, когда проблема действительно появляется, а затем показать, как её можно решить при помощи вашего подхода. И показать, что я как пишущий в ОО-стиле выиграю от вашего подхода.
Вы все правильно говорите, совсем без программирования нельзя, ведь технологию нужно обсчитывать.
Но, насколько я понял авторское высказывание о том, что среда (в его понимании IDE) не в приоритете (читай — не особо нужна), ситуация другая. В SCADA-системе уже есть инфраструктура, все уже между собой увязано, осталось только потоки данных раскидать и обсчитать (знаю, что выглядят мои слова слишком уж оптимистично). А тут получается, что дали мне Qt и сиди сам собирай всю скаду от начала и до конца. Думаю, это совсем другой уровень сложности.
Про web — правда. Надо с самого начала думать, как передать все в web. Потом «прикрутить» будет очень сложно.
Сравнивать Qt и другие SCADA неправильно. Со SCADA-системами работают разные люди, порой они и понятия не имеют о программировании, а в Qt вынь да положь знание C++. SCADA, в общем-то, и нужна для того, чтобы уйти от программирования в сторону мышки. Технология производства выходит на первый план, думать о тонкостях C++ некогда, сдавать надо. А если еще и заказов много, то нанимать программистов под C++ будет очень дорого.
По приведенному описанию сложно понять, насколько удобный и функциональный продукт. Думаю, вам никто в комментариях ничего ценного по этому поводу не напишет.
Чтобы получить действительно качественный feedback нужно дать возможность попробовать поработать с продуктом сторонним пользователям. Опыт создателя программы не может быть до конца объективным в силу разных причин.
Есть у вас возможность дать продукт на тестирование неподготовленным пользователям? Мне, например, было бы интересно посмотреть. Я сам много лет писал SCADA-систему, не в одиночку, конечно.
Физики всем тем, что вы перечислили, не занимаются, у них другая работа и другие цели.
Если нужен не разовый инструмент для оценки/расчета, то и пишут такие вещи программисты, у которых консультантами в предметной области являются те самые физики. Конечно, бывают исключения, но они лишь подтверждают правило: физика — физикам, программирование — программистам.
да, это «замечательная» позиция: мы тут в прошлой версии накосорезили, но раз вы у нас это купили, то теперь это ваши проблемы, а нам гораздо интереснее новое писать. Ничего личного, конечно же, просто нам так удобнее
Подобные статьи всегда вызывают смешанные чувства. С одной стороны, делать большие функции — это чаще всего неправильно. С другой стороны, делать функции длиной в одну строчку (и вызываемые всего один раз) только ради того, что возможно в будущем это может пригодиться — это ли не та самая преждевременная оптимизация, про которую столько статей было?
Ситуация напоминает ситуацию с нормализации реляционных баз данных: вроде теоретически для каждого факта должна быть своя таблица с внешними ключами, но на практике это ужасно неудобно. Думаю, во всем должно быть чувство меры…
про какой геморрой вы говорите? NULL — это значение. У него логическая нагрузка другая, это да, но это значение. Третье состояние, если использовать терминологию схемотехники. Ведь никто не возражает против третьего состояния в отношении микросхем, никто не возражает, что у типа данных Variant есть состояние unassigned. Потому что это нормально — отсутствие известного значения. Это не бесплатно, да. Но это нормально
Судя по комментариям, многие готовы 24 часа в сутки сидеть в низком старте, ожидая новой задачи, лишь бы в резюме можно было написать что-то, что понравится будущему работодателю… Не имею права осуждать такой подход, но это какое-то рабство получается.
Работодателю очень удобно нанимать таких людей, удобно во всех отношениях, ведь если вдруг у разработчика что-то меняется во взглядах на жизнь, то «он сам виноват, что не может соответствовать нашим высочайшим стандартам». Нет личных проектов, значит разработчик не топовый? Божэмой, это типичное взятие «на слабо». И ведь кто-то ведется… И с удовольствием ведется… Ну да, возможно, это мое ворчание, но жизнь ведь не только из работы состоит, и требовать отказа от личной жизни в пользу работы — это, по меньшей мере, непорядочно. Но, повторюсь, кому-то нравится…
В статье нет ничего нового, но из-за настойчивого пиара отрешенного стремления к топовости, совершенно нормальное отношение к соотношению жизнь/работа вдруг вызывает такой резонанс и даже удивление…
Я имел в виду, кроме всего прочего, еще и рутину, возникающую в процессе доведения программы до «идеального» состояния. Лично мне всегда хочется написать программу так, чтобы она работала годами и никто бы не приходил в панике «Оно не работает!!!» или «Я ваще нипонел чотам!!!». Так вот, сам процесс доводки — занятие для очень терпеливых людей, занятие, состоящее на 98% из рутинных операций. Именно это и вызывает желание сменить работу, иногда кардинально, иногда — хотя бы перейти к другой задаче.
Формализация задачи, проектирование, прототипирование, даже реализация со всеми подробностями — это, по сравнению с описанным выше процессом, супер интересные вещи, за них и любят программирование. А вот довести дело до логического завершения — это скука, это «я вырос из ваших задач» и проч.
В мире программистов существует хорошо известный феномен, который заключается в том что вы можете найти решение сложной задачи, просто описывая ее вслух.
Вообще-то, это относится не только к программистам. Я слышал примерно такую формулировку: «Хочешь решить проблему, объясни суть проблемы другому человеку». Возможно, это как-то связано с особенностями человеческого мышления — облекая проблему в слова, человек в большей степени формализует ее или, другими словами, более строго формулирует.
Ну, стоило бы начать с разъяснения проблемы. Привести примеры, когда проблема действительно появляется, а затем показать, как её можно решить при помощи вашего подхода. И показать, что я как пишущий в ОО-стиле выиграю от вашего подхода.
Кстати, в Delphi _очень_ быстрая загрузка из DFM-файлов.
Терси-КБ
Описанный подход используется и без привязки конкретно к Go
Но, насколько я понял авторское высказывание о том, что среда (в его понимании IDE) не в приоритете (читай — не особо нужна), ситуация другая. В SCADA-системе уже есть инфраструктура, все уже между собой увязано, осталось только потоки данных раскидать и обсчитать (знаю, что выглядят мои слова слишком уж оптимистично). А тут получается, что дали мне Qt и сиди сам собирай всю скаду от начала и до конца. Думаю, это совсем другой уровень сложности.
Сравнивать Qt и другие SCADA неправильно. Со SCADA-системами работают разные люди, порой они и понятия не имеют о программировании, а в Qt вынь да положь знание C++. SCADA, в общем-то, и нужна для того, чтобы уйти от программирования в сторону мышки. Технология производства выходит на первый план, думать о тонкостях C++ некогда, сдавать надо. А если еще и заказов много, то нанимать программистов под C++ будет очень дорого.
Чтобы получить действительно качественный feedback нужно дать возможность попробовать поработать с продуктом сторонним пользователям. Опыт создателя программы не может быть до конца объективным в силу разных причин.
Есть у вас возможность дать продукт на тестирование неподготовленным пользователям? Мне, например, было бы интересно посмотреть. Я сам много лет писал SCADA-систему, не в одиночку, конечно.
Если нужен не разовый инструмент для оценки/расчета, то и пишут такие вещи программисты, у которых консультантами в предметной области являются те самые физики. Конечно, бывают исключения, но они лишь подтверждают правило: физика — физикам, программирование — программистам.
Но это вовсе не значит, что не стоило ее реализовывать еще раз
Ситуация напоминает ситуацию с нормализации реляционных баз данных: вроде теоретически для каждого факта должна быть своя таблица с внешними ключами, но на практике это ужасно неудобно. Думаю, во всем должно быть чувство меры…
а если смотреть шире (что и предлагает делать iqiaqqivik), то вполне себе можно
Судя по комментариям, многие готовы 24 часа в сутки сидеть в низком старте, ожидая новой задачи, лишь бы в резюме можно было написать что-то, что понравится будущему работодателю… Не имею права осуждать такой подход, но это какое-то рабство получается.
Работодателю очень удобно нанимать таких людей, удобно во всех отношениях, ведь если вдруг у разработчика что-то меняется во взглядах на жизнь, то «он сам виноват, что не может соответствовать нашим высочайшим стандартам». Нет личных проектов, значит разработчик не топовый? Божэмой, это типичное взятие «на слабо». И ведь кто-то ведется… И с удовольствием ведется… Ну да, возможно, это мое ворчание, но жизнь ведь не только из работы состоит, и требовать отказа от личной жизни в пользу работы — это, по меньшей мере, непорядочно. Но, повторюсь, кому-то нравится…
В статье нет ничего нового, но из-за настойчивого пиара отрешенного стремления к топовости, совершенно нормальное отношение к соотношению жизнь/работа вдруг вызывает такой резонанс и даже удивление…
Формализация задачи, проектирование, прототипирование, даже реализация со всеми подробностями — это, по сравнению с описанным выше процессом, супер интересные вещи, за них и любят программирование. А вот довести дело до логического завершения — это скука, это «я вырос из ваших задач» и проч.
И да, возраст совершенно не помеха для роста.
Вообще-то, это относится не только к программистам. Я слышал примерно такую формулировку: «Хочешь решить проблему, объясни суть проблемы другому человеку». Возможно, это как-то связано с особенностями человеческого мышления — облекая проблему в слова, человек в большей степени формализует ее или, другими словами, более строго формулирует.