Конец программной инженерии и последний методист

Original author: Bertrand Meyer
  • Translation
Это перевод статьи профессора Бертрана Мейера из блога Communications of the ACM.
Статья относительно недавняя (по сравнению с предыдущим переводом).

Кроме того, что Бертран Мейер известен большинству специалистов как создатель языка программирования Eiffel и идей контрактного программирования (design by contract), он является почетным доктором и заведующим кафедрой ИТМО, преподает в университете Иннополис. И прекрасно владеет русским языком. ;)

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

Но так было в давние времена. За некоторыми исключениями, одно из которых будет упомянуто ниже, если кто и продолжает изучать методологии программирования, занимается он этим уже в мире agile, там, где решающие доводы часто начинаются с фразы «Я всегда говорю…» (Пример со страницы консультанта: «я всегда говорю команде: ‘Мне хотелось бы, чтобы [пользовательские] истории были небольшими, умещались в одну итерацию, однако такой путь не всегда приемлем»). Дейкстра, бывало, апеллировал к интуиции, однако подтверждал ее строгими концептуальными доказательствами.

Область программной инженерии, где методология программирования в наши дни является лишь небольшой частью, невероятно расширилась и в глубину и вширь. Конференции типа ICSE и ESEC все еще привлекают большие толпы, журналы гудят, исследователи по-прежнему в восторге от своих работ, но… являюсь ли я единственным, кто ощущает все нарастающее вокруг разочарование? Непонятно интересно ли это все кому-либо за пределами сообщества. Мир, похоже, считает программную инженерию чем-то таким, что знакомо любому в ИТ, мы же все разрабатываем программы, ну или управляем людьми, которые разрабатывают программы. В обзоре найма факультетами компьютерных наук в США от 2017 года, показано, что в ста ведущих университетах, предоставляющих профессорские места, программная инженерия заняла лишь 3% от всех вакансий! (В ВУЗ-ах, которые ограничиваются уровнем магистра, эта цифра равна 6%, не сказать, чтобы незначительно, но и не впечатляет также, учитывая, что эти заведения в основном и ответственны за подготовку будущих инженеров-программистов.) С точки зрения академической карьеры, очевидное направление для выбора – «Искусственный интеллект, анализ данных и машинное обучение», которое набрало 23% от числа нанятых в этих 100 лучших университетах.

Ничего не имею против коллег из ИИ; я всегда считал, что «ИИ зима» была перебором [1] и у них есть право на весну. Означает ли это, что теперь программная инженерия должна отправиться в зиму? Это сумасшествие. Программная инженерия важна как никогда. Недавняя статья-«апокалипсис от ПО» (больше о проблеме, чем о решении) – один из последних обзоров, звучащих как сигнал тревоги. Или, как один из недавних примеров – почитайте об утере спутника в России [2] (сочная цитата, которую вы можете использовать в следующий раз, когда будете преподавать классу тему сложности тестирования программного обеспечения: «Это выявило скрытую проблему в алгоритме, которая не проявлялась десятилетиями успешных пусков связки “Союз” — “Фрегат”»).

Подобные случаи, кстати, иллюстрируют то, что я бы назвал дилеммой профессора программной инженерии, гораздо более интересной, на мой взгляд, чем причудливые этические головоломки (вы понимаете о чем я – проблема вагонетки и тому подобное) над которыми люди с философского факультета проводят свои дни: этично ли, для профессора программной инженерии, каждое утро, сразу после пробуждения, открывать сайт cnn.com в надежде на свершение какой-нибудь программно-инициированной катастрофы, которая окончательно узаконила бы его профессию? Ответ простой – нет, это не этично. Тем не менее, когда вы наблюдаете в каком состоянии находится обычная разработка программного обеспечения, подумать страшно (хотя и неправильно такого желать) обо всех поджидающих своего часа катастрофах, которые, как вы можете подозревать, там уже заложены и просто ждут правильного стечения обстоятельств.

Так что, да, программная инженерия важна как никогда, как и методология программирования. (Персональное разоблачение: о себе я думаю, как о том самом образце современного методиста [3], без бороды или голландского акцента, но пытающегося вынести на современную ИТ сцену факел плодотворных работ семидесятых и восьмидесятых.)

Ценится, однако, не то, что нужно миру, а то, что мир считает нужным. Не похоже, чтобы мир думал о большой необходимости программной инженерии. Даже когда программное обеспечение приводит к катастрофам, мы видим заголовки день-два и потом ничего. Радио тишина. Я до тошноты спорил, включая четыре раза в этом блоге (теперь пять), о необходимости простого правила, которое требовало бы публичной ревизии каждого такого события; цитируя самого себя: авиаперевозки становятся безопаснее не случайно, а из-за несчастных случаев. К этим предостережениям остаются глухи. В качестве другого признака спада интереса, многие, включая меня, получили большую часть своего понимания о программной инженерии из форума ACM о рисках, давнего и уникального источника технической информации о неприятностях в программном обеспечении. Форум все еще процветает и все еще, порой, информирует о проблемах программной инженерии, однако большая часть трафика – о приватности и безопасности (с особой нежностью к либертарианским тирадам против любых разумных правил приватности, которые утверждаются в ЕС). Важные темы, конечно, но куда нам идти за исчерпывающей информацией о том, что идет не так с программным обеспечением?

Еще одно обстоятельство, заслуживающее внимания – эволюция языков программирования. Создание языков снова громкая тема, со всякого вида модными вновь прибывшими. Я вижу один пример (TypeScript) в котором движущей силой является инженерная цель: сделать Web программы безопаснее, более масштабируемыми и более управляемыми за счет введения некоторой дисциплины в мир JavaScript. Но это исключение. Аргументы многих новых языков склоняются к тому, насколько они искусны и какие выразительные конструкции они вводят в употребление. Отлично. Нам нужны новые идеи. Они могли бы быть еще более убедительными, если бы были направлены на решение старых и скучных проблем программной инженерии: корректность, надежность, расширяемость и возможность многократного использования.

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

Примечания

[1] ИИ был моей первой любовью, спасибо за это Жан-Клоду Симону из Политехнического/Париж VI и Джону Маккарти в Стэнфорде.

[2] Благодарю Николая Шилова за обращение моего внимания на эту информацию. Текст на русском, но вы можете пропустить его через web-переводчик, что позволит понять самое важное.

[3] В этот раз позаимствую фразу у Джеймса Нобеля.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 141

    +8
    Что за поток сознания?
      –6

      Тяжело?

        +4
        Кому?
          0

          Читать?
          Статья ученого, переживал за перевод. Одобрил комментарий в надежде на более развернутое пояснение.
          Впрочем, на вопрос вы ответили.

            0

            Да, тяжело читать. Zanak достаточно адекватно ответил на широкий вопрос, который можно было интерпретировать тысячей способов:)

              +1

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

                +2

                Спасибо за переводы.
                Сложно писать так чтобы легко читалось:)

                  0

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

      +6
      Честно говоря ни о чём, что за супер магия древних забыта в веках?
      Как разрабатывать софт писяя больше документации чем кода? Так это помнят те кому нужно, но от аварий это не страхует, да, их меньше, но цена этого огромна, когда-то читал оценку что разработка софта для НАСА в 170 раз дороже обычной коммерческой разработки.
      Мало у кого есть такой бюджет на разработку софта, зачем готовить много таких специалистов?
      А если говорить о проблемах в отрасли, да они есть и очень остры, я думаю что нужна более сильная магия.
      Она может и ещё дороже, но хоть что-то делает надёжно.
        0

        Под магией Вы понимаете микроядро sel4L, я так понимаю? И формальную верификацию как панацею? Согласен, хороший пример правильного проектирования ПО.


        Думаю Вам, в таком случае, тем более будет интересно почитать о языке Eiffel, принципу дизайна по контракту и тому, какое влияние они оказали на современные языки и решения. Надеюсь Вам понравятся идеи и автора этой статьи.


        Не подумал, что надо подробнее представить автора в начале статьи, исправлю, спасибо.

          +3
          Ну слово панацея нужно применять с оговорками — формальная верификация это панацея только в части реализации, от ошибки в требованиях стопроцентных средств вроде и нет (формальная верификация наверное может помочь найти противоречия, но полноту и корректность требованиях никто кроме человека проверить не может).
          А языки я думаю нужно более математические и видимо чисто функциональные аля haskell
            0

            Вижу, что Ваша позиция во многом совпадает с авторской. Скажите, а у Вас есть примеры успешного промышленного применения Хаскеля?

              +1
              Лично не сталкивался, хотя вроде как это бывает, даже и на хабре было.
              Впрочем это ровно ничего не означает, во-первых, хаскел я привожу просто как пример языка который есть математика, а значит более подходящ как для верификации так и для безопасных оптимизаций компилятором, во-вторых, даже отсутствие внедрений ничего бы не доказывало, кроме низкой популярности или высокого порога входа.
              Ныне джаваскрипт самый популярный, но не думаю что кто-то будет утверждать что это лучший инструмент для создания надёжного софта.
                0

                Не заметил комментария. Тогда снова вопрос — если Хаскель просто как пример, тогда почему в этом же качестве не может быть Eiffel (это я все еще про Ваш первый комментарий и древнюю супермагию). Хотя, это я придираюсь.


                По поводу приведенной статьи о Haskell и JS как лучшем инструменте, кстати.
                Мы делали очень надежный и эффективный слой АПИ на NodeJS в 2014. Кроме инструментов (промисы, pm2, слава NPM и др.;) это, конечно, зависит от культуры программирования, которой язык может просто помогать или мешать в большей или меньшей степени. Так вот, прочитав ту статью (она от 2013), я бы и тогда и сейчас, сравиниваяя именно их, отдал бы предпочтение NodeJS (в данное время и в реальности я предпочтение, конечно, отдаю уже не ему)

                  0
                  Потому что хаскел это чисто функциональный язык программирования основанный, ка я понял, на теории категорий, на математике, а ООП языки это языки и изменяемым состоянием т.е. очень грязные и соответствующей математики вроде и нет.
                    +1
                    Любая программа на любом языке может быть представлена диаграммой состояний с переходами и, соответственно, можно доказать/опровергнуть требуемое поведение. Математическая чистота тут не при чём. В Хаскеле используется исчисление рекурсивных функций, а в С++ (например) — теория автоматов.
                      0
                      Да, видимо я неправильно сказал, конечно верифицируют программы не только на функциональных языках, но насколько мне известно функциональный подход облегчает формальную верификацию.
                      И это важно т.к. верификация процедура очень затратная.
                        +1
                        Честно говоря, не уверен. Скажем, в многопоточном программировании обычно используется какой-нибудь облегчённый язык моделирования (напр., Promela — вполне себе императивный), на котором пишется алгоритм, а потом уже всё это переписывается на обычном языке. В конце концов, и в Haskell есть «нечистые» функции вроде генератора случайных чисел или чтения ввода пользователя.

                        Я с этой темой знаком поверхностно, и мне показалось, что тут важнее не какой язык, а что мы ищем. Ну и, соответственно, сложность зависит от этого. Например, если вам надо доказать, что в системе есть deadlock, это ещё терпимо, т.к. достаточно найти один пример того, как это может случиться. А вот если требуется доказать, что всегда после события А рано или поздно наступает событие B, это уже куда сложнее.
                          0
                          нечистые функции в хаскел явные и их не так много, большая часть кода должна быть в чистых функциях и видимо это упрощает верификацию
                            +1
                            А откуда вообще эта идея? Мне и вправду интересно. Только не на уровне теорий, а конкретных продуктов, которыми можно воспользоваться.

                            Я немного рассказываю студентам про model checking, вот в своё время пытался подобрать наиболее простой инструмент, и в итоге выбрал банальный Spin. Если посмотреть список в Википедии, Хаскелл там вообще не упоминается, да и, по правде говоря, больше половины указанных проектов реально мертвы.
                              +1
                              Да честно говоря это старая мантра источник которой затрудняюсь найти.
                              Но тут пишут:
                              seL4, the first formally verified microkernel,[58] used Haskell as a prototyping language for the OS developer.[58]:p.2 At the same time, the Haskell code defined an executable specification with which to reason, for automatic translation by the theorem-proving tool.[58]:p.3 The Haskell code thus served as an intermediate prototype before final C refinement.
                                0
                                Тут написано, что Haskell оказался удобен для решения конкретной задачи верификации микроядра, но из этого не следует, что условная Promela была бы хуже.
                                0
                                Чистые функции гарантируют локальность. То есть свойства функции не будут зависеть от фаз Луны и состояния каких-то сторонних объектов.
                                Кроме того есть перспективное направление верификации — зависимые типы (в Haskell они пока почти не поддерживаются, только планируются, но есть ATS, IDRIS в которых они готовы к использованию). А зависимые типы без чистоты функций сделать непонятно как. Скажем у нас есть вектор v длинны l, а кто-то присваивает l новое значение, что после этого считать типом v?
                                  +1
                                  Погодите, это всё интересные мысли, но это всего лишь мысли. У меня есть конкретная задача: дать студентам пощупать model checking. Я иду в Википедию и смотрю список реальных инструментов. Их там десятки. Использовать Haskell на практике никому в голову не приходит. При этом очень часто разрабатывают какой-то собственный формализм, вовсе даже не в функциональном стиле.
                                  0
                                  Сию статью я понял как обоснование удобства чистых функциональных языков для формальной верификации.
                                +1
                                Нечистых функций в Haskell нет (кроме unsafePerformIO). Генерация совсем случайных чисел и ввод строки являются экземплярами монады IO и просто так вызваны быть не могут.
                              0
                              Ну да, если состояние автомата фактически является дампом всей используемой программой памяти. Хотел бы я посмотреть на доказательства свойств такого автомата.
                                0
                                Пожалуйста, качайте Spin и смотрите, там ровно это и делается.
                            +1
                            Составление контрактов для императивного языка — задача тяжелая и неустойчивая. Например, в контракте прописано, что поле объекта параметра больше единицы, и вдруг в середине метода это поле кем-то изменяется на ноль. Контракт это пропустит, но программа может работать неправильно.
                            К тому же полноценная проверка контрактов существенно более сложна, чем проверка типов, так что многие ошибки она позволит обнаружить раньше.
                            К тому же ООП без соблюдения принципа подстановки Лисков очень мешает надежному программированию, а описать этот принцип контрактом совсем не просто.

                            Сравнение с нодой несколько странное. Фьючи — более развитый механизм асинхронного программирования, чем промисы. Они являются монадами, а в работе с монадами с Haskell трудно тягаться (хотя сейчас появился Purescript, транслирующийся в джаваскрипт, где монады дополнены концепцией «эффектов», которые, потенциально, должны обеспечить дополнительную надежность). Управление пакетами в Haskell (cabal) ни чуть не отстает от npm.
                              0

                              По поводу первого — я так понимаю, что контракты, как раз, должны требовать исполнения этого принципа. Но, так как почти не в теме — было бы интересно узнать, чем они усложняют его соблюдение.


                              По поводу сравнения NodeJS и Haskell — я именно сравнивал с практической точки зрения, ни в коем случае не особенности языка как таковые (feature тогда в синтаксис еще не ввели, промисы были на библиотеке Bluebird.js). Про управление пакетами в Haskell не знал, спасибо!

                                +1
                                Они, бесспорно, упрощают его соблюдение. Даже сильно упрощают.
                                Но составить контракты так, что бы они гарантировали принцип подстановки очень сложно. А ошибки, вызванные его нарушением встречаются — это повод в ответственных приложениях отказаться от наследования (и языков, его поддерживающих).
                          +2

                          В 2018 году, когда регулярно слышны новости об успехах функционального программирования в промышленности и животноводстве, вопрос «а у Вас есть примеры успешного промышленного применения Хаскеля?» звучит примерно как «а у Вас в Америке негров линчуют».


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

                            0

                            Мне действительно интересен личный опыт.
                            Тем более, что на волне "serverless" движения (AWS Lambda), я, например, ожидал всплеска интереса к этому языку, теоретически идеально подходящему.
                            На деле же слышу все реже. У меня есть мнение, почему так получается, конечно. Как раз по "инженерским" причинам — сложность с образованием и нехватка практических инструментов для конкретного окружения. Часто приходится повторять, что выигрывают не языки, а платформы.
                            Это касается и остальных функциональных языков (OCaml, Scheme (бывшее секретное оружие Пол Грэхэма)) и нефункциональных (Eiffel, Smalltalk, Forth и т.п.) в большей или меньшей степени.
                            Вот даже Rust, который я бы с удовольствием использовал — инфраструктурно для серверной разработки пока еще не совсем дозрел.

                              +2
                              Вот мой личный опыт, например — ruhaskell.org/posts/talks/2016/08/18/ivory-high-performance-code-for-haskell.html

                              Кроме серверов и лямбды, есть очень много областей, где применяется программирование.
                                0

                                Отлично! Спасибо!
                                Про много областей — ну зачем же, ни разу не пытался Вас обидеть (и никого под своей публикацией вообще ;).
                                Замечательный доклад!

                                0

                                Может дело в простоте? Ни один из перечисленных языков вряд ли можно назвать простым. В отличие от js, python, php, c, java, которые и правят бал.

                                  0

                                  Да, императивные языки, кроме того, что чаще преподаются — действительно легче объяснить начинающему: "командуй компьютеру".


                                  Хотя Logo Сеймура Папперта функциональный, или SmallTalk, который Алан Кей и товарищи писали изначально, как язык для детской компьютерной грамотности. Дети прекрасно понимали парадигму, там такие же команды-сообщения, только все более компактно. Он простой, но инфраструктура так и не пошла в народ. Как платформа он проиграл и не уверен, что активно используется для обучения.


                                  Т.е. еще должно быть просто сделать большие и практичные вещи, чтобы внимание к нему было оправдано.

                                    0

                                    Так почему бы не давать в ВУЗе языки не исходя из странной концепции "будем давать то, что лучше иллюстрирует парадигму", а "надо дать опыт 4 и более востребованных на рынке языков, и на них показать различные парадигмы"?

                                      +1
                                      Университет не может переориентировать курсы каждые три-четыре года в соответствии с модой. Кроме того, конкретная парадигма в принципе может отсутствовать с списке модных языков по 10-20 лет. Поэтому брать приходится более-менее известные языки, у которых есть перспектива не помереть в ближайшем будущем.
                                        0

                                        Наши, к сожалению, именно таковы.
                                        Пару лет назад очень впечатлило с какой скоростью Стенфорд создал и ввел CS231* (deep learning).

                                          0

                                          Вот на предыдущий вопрос уже замечательно ответили (у преподавателей не хватит ресурсов гнаться за fancy skills, которые к моменту окончания с большой вероятностью утратят актульность).


                                          А по поводу курса — deep learning это, все-таки, больше самодостаточный научный метод в рамках дисциплины, чем навык. Вот использование TensorFlow (навык) преподавать отдельно не будут — максимум использовать как инструмент для лабораторных.


                                          "Зарубежный" от "нашего" подхода также отличается гораздо бОльшим акцентом на самостоятельных работах, в добавок к произвольному набору необязательных предметов. Самостоятельная работа — свобода в полировке навыков.

                                            0

                                            Дают обзор инструментов, после на лекции подробно разбирается как работает tensor flow (8я лекция), далее есть tutorial и после лабораторные уже идут с новым инструментом.
                                            В итоге студент знаком с ценным для рынка инструментом.
                                            А вот про то, что подобные навыки "которые к моменту окончания с большой вероятностью утратят актульность" я сомневаюсь. Есть примеры, показывающие истинность высказывания?

                                              0

                                              Ну с языками тоже не все так плохо — в основном дают Java, C и Python. С GoLang или Kotlin — будут, возможно, когда те устаканятся и удержатся в мейнстриме лет 10.


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

                                                0

                                                Вот зачем эти "в мейнстриме лет 10"? Снова учить тому, на чем папа программировал?

                                                  +1
                                                  Вы говорите об этом так, словно речь идёт о чём-то очевидно плохом.
                                            +1
                                            Deep learning — это концепция, которая есть и будет, но честное слово, никто не станет переписывать данный курс под самый популярный язык очередной пятилетки. Вот какой язык у них сейчас там используется, такой и будет использоваться очень долго, я так думаю.
                                              0
                                              Печально. Так и имеем стандарты на специальности по 20-30 лет.
                                              Мне видится, что скоро наше образование перестанет выдерживать конкуренцию.
                                        0
                                        Младшему школьнику может быть. Но студент уже должен иметь некоторые навыки абстрактного мышления, иначе непонятно как и зачем он оказался в ВУЗе.
                                        +1
                                        Во-первых, не путаете ли вы простоту и привычность? А если бы вы начинали программировать с хаскела, а не с паскаля?
                                        Во-вторых, «простота» их обманчива, она не соответствует уровню сложности задач, поэтому и получает убогий результат, см. теорему необходимого разнообразия.
                                          0

                                          Не очень понял сути вашего замечания. Про каждый python, go есть достаточно материалов с опытом преподавания их, как первых языков.
                                          Ну и да, go именно простой. В общем-то он дальний родственник pascal.

                                            0
                                            А я не понял сути вашего, вы писали что Python и др проще чем Scheme и другие, а я вам говорю что проблема в том с какого языка вы начинали изучение программирования, если с условного паскаля, то вам питон и товарищи будут казаться простыми т.к. они всего одной крови.
                                              0

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

                                        +1
                                        Про применение ФП, кроме Haskell, могу добавить ReasonML, используемый в Facebook, и ELM, применяемый во многих небольших проектах, в том числе и мной. Это все языки для фронтенда.
                                        Что касается serverless, то, по крайней мере у AWS, он сделан так себе. Поддерживается небольшое количество языков, и все из них плохо поддерживают ФП. Долгий холодный старт, особенно у больших программ для JVM. Для функциональных языков, транслирующихся в джаваскрипт (в частности Purescript) нет биндингов к AWS. Так что к функциональщине там имеет отношение только название, а для пробуждения интереса этого мало.
                                          0

                                          Да, я тоже все удивлялся, что Lambda — название от функционального подхода, но относится только к биллингу, похоже. Но на Wikipedia упоминается возможность запуска нативного кода для Linux и Haskell, как пример.

                                            +1
                                            Видел примеры, когда в архив к js или питону добавляли бинарную библиотеку или просто исполняемый файл, и его запускали.
                                      +1
                                      Я применял Haskell для моделирования системы на кристалле (правда до реализации не дошло, потому что поняли, что изделие получится не конкурентоспособным).
                                      В OS Касперского значительная часть кода генерируется из Haskell с помощью библиотеки Ivory.
                                      Есть успешный RSS-агрегатор, написанный на Haskell.
                                        0

                                        Спасибо! Что-то я многие комментарии поздно замечаю ))
                                        По поводу OS Касперского — тут рядом, как раз, писал разработчик и один из основателей сообщества ruhaskell.org, интересный опыт, DSL на Haskell для трансляции в C.

                                  +2
                                  Речь жеж как раз не о «коммерческом ПО» :-) Речь о том, что уровень инженерной культуры снижается в разработке ПО вообще. Это и пугает.
                                    0
                                    Во-первых, хорошо бы придумать метрики этого уровня инженерной культуры, иначе нельзя утверждать что что-то там снижается.
                                    Во-вторых, отрасль бурно росла и привлекала людей с непрофильным образованием, вполне вероятно что рост уже закончился или близок к этому, перекос зарплат исчезнет и ситуация начнёт выравниваться.
                                    В-третьих, есть проблема с образованием, даже те кто учился на айтишника мало чего понимают, но я надеюсь это проблема только отсталых, типа exUSSR, стран.
                                      +1
                                      Во-первых, хорошо бы придумать метрики этого уровня инженерной культуры, иначе нельзя утверждать что что-то там снижается.


                                      Серьезно?! Этому понятию — «сто лет в обед»… что конкретно вы предлагаете «придумать»?

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


                                      Не начнет… ибо причины этого совсем не в этом.

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


                                      Поскольку в «exUSSR» все это началось сильно позже, то, соответственно, на данный момент, в «exUSSR» с этим как раз лучше, чем «в среднем, по больнице» :-)
                                        0
                                        > Серьезно?! Этому понятию — «сто лет в обед»… что конкретно вы предлагаете «придумать»?

                                        или озвучить то что вы подразумеваете под этим понятием
                                          +1
                                          или озвучить то что вы подразумеваете под этим понятием


                                          ?! Я правильно понял, что вы предложили «придумать метрики» для того, что даже не понимаете?

                                          Ок… поясняю.

                                          Во-первых, речь идет о том, что называется инженерия (engineering). Или — если применительно к разработке ПО — программной инженерии (software engineering). Это даже из названия должно было бы быть ясно.

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

                                          Так вот, низкий уровень инженерной культуры в разработке ПО означает, что инженерные методы — в разработке ПО — если и используются осознано (это важно, чтоб *осознано*), то весьма ограничено. Что, в свою очередь, означает, что разработка ПО — чем дальше, тем все больше — перестает быть инженерной дисциплиной. Вот и все. И тех, кто «в теме», это немножко напрягает…
                                            0
                                            Не надо говорить банальностей, всё это очевидно, я говорю о конкретике — каких конкретно инженерных методов стали применять меньше и каким образом вы получили эту оценку?
                                              0
                                              :-) «Банальностей», значит… ну хорошо.

                                              каких конкретно инженерных методов стали применять меньше и каким образом вы получили эту оценку?

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

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

                                              А потом мы с вами обсудим, насколько широко она распространена в данный момент.
                                                0
                                                Вы постоянно уходите от вопроса, могу повторить: «каких конкретно инженерных методов стали применять меньше и каким образом вы получили эту оценку?»
                                                и не нужно на меня перекладывать бремя доказательства, вы сделали утверждение «уровень инженерной культуры снижается в разработке ПО вообще» вам его и обосновывать
                                                  0
                                                  :-) Даже так.

                                                  Вообще-то, я на ваш вопрос ответил. Повторюсь, лично мне, не известно ни одной современной методологии разработки ПО, которая бы была построена «вокруг» инженерных методов. Т.е. — насколько мне известно — все современные методологии не предполагают и использования инженерных методов вообще. Они все про что угодно, но не про инженерию. Что, впрочем, вполне логично :-)

                                                  Но, если вы не знакомы с термином «инженерный метод», то вы лучше так и скажите. Я тогда вам «на пальцах» попытаюсь объяснить :-)

                                                  Хотя… Возьмем, например, разбиение (сиречь, декомпозицию). Один из основных и простых инженерных методов. Можно даже сказать — базовый. Много вы знаете современных методологий «заточенных» на проведение грамотной декомпозиции? Да ни одной нет. Более того, не все из них даже предполагают, что есть хоть какая-то? :-) При этом, я сильно сомневаюсь, что хоть кто-то (вы, например) будет спорить с тем, что грамотная декомпозиция — это таки важно.
                                                    0
                                                    Строгих методологий тут не было и нет, есть идеи, и достаточно современная, и на мой взгляд наиболее здравая идея, это плясать при декомпозиции от предметной области — DDD, ну и всякие DRY и SOLID никуда не делись, они тоже влияют на то как делается декомпозиция, плюс критерии сложности аля цикломатическая сложность.
                                                    Вопрос скорее в другом — как оценить степень применения этих методов тогда и сейчас, то что умные дяди что-то изобретали не означает, что это применяли или правильно применяли.
                                                    ООП и сейчас в ВУЗах есть, да только есть ли кто-нибудь среди выпускников кто понимает как правильно применять ООП или это просто карго-культ и больше проблем от такого применения?
                                                      0
                                                      Строгих методологий тут не было и нет ...

                                                      Это вы просто, как обычно, не в курсе.

                                                      … есть идеи, и достаточно современная, и на мой взгляд наиболее здравая идея, это плясать при декомпозиции от предметной области — DDD, ну и всякие DRY и SOLID никуда не делись ...

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

                                                      Но, обращаю ваше внимание, что даже DDD — если и касается декомпозиции, то только в части отнологии. Что — вообще говоря — к инженерии имеет весьма опосредованное отношение.

                                                      ..., они тоже влияют на то как делается декомпозиция

                                                      Декомпозиция — как инженерный метод — «делается» всегда одинаково :-)

                                                      ..., плюс критерии сложности аля цикломатическая сложность.

                                                      Это-то тут каким боком?!

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

                                                      Очень просто… найти и вникнуть в соответствующие *методологии*

                                                      ООП и сейчас в ВУЗах есть, да только есть ли кто-нибудь среди выпускников кто понимает как правильно применять ООП или это просто карго-культ и больше проблем от такого применения?

                                                      Какое отношение это имеет к обсуждаемому вопросу?
                                                        0
                                                        Вы предпочитаете утверждать что я чего-то не знаю (это очевидно возможно), но при этом обходиться без конкретики, а предлагает поискать.
                                                        Знающий человек так не делает, тот кто знает давно уже бы перешел бы к конкретным методологиям, охарактеризовал бы их и дал ссылки.
                                                          0
                                                          Т.е. вам таки на «по гуглить»?! Ну, можете начать, например, с аббревиатур SADT и IDEF :-)
                                                            0
                                                            Смотрим SADT:
                                                            In 1981 the IDEF0 formalism was published, based on SADT.

                                                            Переходим к IDEF0:
                                                            On September 2, 2008, the associated NIST standard, FIPS 183, has been withdrawn

                                                            видимо что-то оказалось не так с этим супер-пупер методологиями древних
                                                              0
                                                              видимо что-то оказалось не так с этим супер-пупер методологиями древних


                                                              Теперь вам осталось выяснить, что же «не так» с этими методологиями :-)

                                                              Просто — на всякий случай — и SADT, и IDEF (а не IDEF0, которая лишь часть) — примеры «строгих методологий», которых — по вашему мнению — «не было».
                                                                0
                                                                Было бы интересно почитать какой там строгий алгоритм декомпозиции.
                                                                  0

                                                                  Не уследил, как дискуссия перешла от метрик к методологиям, но SADT (он же IDEF0) — очень помогал описывать системы за счет рекурсивных схем процессных потоков, в которых есть несколько ограничений — каждый процесс получает на вход результат другого (слева); каждый процесс имеет, соответственно, результат (справа); для каждого процесса есть стороны "надзорно-контрольная" (сверху) и "исполнительная" (снизу).


                                                                  Entity Relationship (ER) диаграмы (принято позже в IDEF1X) замечательно помогали при определении схемы баз данных. В таком продукте, как ERWin, например, отрисовывалась логическая схема, на ее основе — физическая, описывались макросы триггеров (для контроля целостности в основном) и потом все это экспортировалось в рабочий скрипт для конкретного вида РСУБД. Очень сильно помогало поддерживать порядок, реально.


                                                                  Я так понимаю, LogicWorks продалась (застал еще Platinum Technology), и продукты, в итоге, разошлись по кускам BPWin в IBM, а ERWin — в CA.

                                                                    +1
                                                                    Я может быть вас как-то не так понимаю… Но, нет какого-то отдельного «алгоритма» декомпозиции (хоть «строгого», хоть какого) для SD/SE и т.д. Он — один. Главное в нем — неизменность критерия декомпозиции.

                                                                    А «строгость» заключается именно в требовании таки провести декомпозицию (и не одну).
                                                                      0

                                                                      Полностью согласен.

                                          0

                                          По метрикам, действительно, очень много работ. Тот же Макконел и товарищи, например. Подозреваю, что в таких профессиях, как наша, где учиться нужно ежедневно и всю жизнь — профильность первичного образования уже давно не является главным фактором успеха.
                                          А по поводу exUSSR и сложности научного подхода — я, например, в какой-то степени, стал программистом благодаря усилиям академика Ершова (одного из учителей автора, кстати). Вот пример характерной презентации тех, кто нес факел "в древних веках" http://ershov.iis.nsk.su/ru/second_literacy/article

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

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


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

                                          +1
                                          что за супер магия древних забыта в веках?
                                          У древних тоже было не всё хорошо (человеческие жертвоприношенияы — Therac-25, например).

                                          когда-то читал оценку что разработка софта для НАСА в 170 раз дороже обычной коммерческой разработки.
                                          Так они даже модел-чекинг применяют, когда другие даже статическим анализом брезгуют.
                                          +4
                                          О, я как раз писал похожую вещь на русском в 2014, и улучшенную версию на английском в 2017.
                                            +1

                                            Прочел улучшенную версию — отличная статья!

                                            +4
                                            Это действительно какой-то поток сознания и алармизм (да, я в курсе замечательных достижений автора вне общих рассуждений). Людей, двигающих вперёд software engineering в процентах мало, как и выращивающих пшеницу, но человечеству, видимо, хватает. Лучшие идеи теории SE либо уже воплощены в существующих языках (они заставляют даже новичков писать лучше, чем 20 лет назад), либо объективно сложны для среднего специалиста. Продолжать работать в этом направлении надо, но принципиально поменять ситуацию вряд ли получится, слишком много здесь нетехнических факторов. Я не думаю, что спутник упал из-за недостаточного количества профессоров SE в университетах. Гораздо вероятнее, что конкретный сотрудник оказался недостаточно внимательным (допустил баг), а другой достаточно ленивым или недостаточно компетентным для работы по приёмке качества.
                                              0

                                              Спасибо! По поводу алармизма и стиля подачи — отчасти соглашусь, статья из научного блога, для определенной аудитории, возможно не стоило выносить сюда, но обещаю еще несколько раз попробовать ;) Замечу только, что улучшение существующих языков за последние 20 лет — прямое следствие именно такого алармизма и именно таких (действующих) людей:


                                              Лучшие идеи теории SE либо уже воплощены в существующих языках (они заставляют даже новичков писать лучше, чем 20 лет назад), либо объективно сложны для среднего специалиста

                                              Все ли? По поводу сложности — понимаю, мало кому интересен rocket science, средний программист, в отличие от других видов инженеров, в допуске не нуждается так как вряд-ли себя убъет. Как Вы думаете, учитывая, как много взломов с кражей личных данных, например, сейчас происходит (equifax — хороший пример) — будет ли расти давление на средних специалистов, или это как раз тот случай, где принципиально поменять ситуацию не получится?


                                              конкретный сотрудник оказался недостаточно внимательным (допустил баг), а другой достаточно ленивым или недостаточно компетентным для работы по приёмке качества

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

                                                +1
                                                улучшение существующих языков за последние 20 лет — прямое следствие именно такого алармизма и именно таких (действующих) людей

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

                                                будет ли расти давление на средних специалистов, или это как раз тот случай, где принципиально поменять ситуацию не получится

                                                Может, я сейчас слишком копну, ну да ладно. Вот есть «дискурс первого уровня». Броуди в «Thinking Forth» пишет, что паттерны проектирования нужны прежде всего для того, чтобы биться с проблемами, вызванными самими (плохими) языками программирования. Дейкстра очень прохладно отзывается о software engineering. Он-то считал, что если нормально доказывать корректность алгоритмов, то всё и будет работать (справедливости ради, он по факту критикует отдельные части SE, а не всё подряд).

                                                Сообщество Мейера делает переход на следующий уровень: да, нереалистично надеяться на то, что у нас будут идеальные языки и все будут математически доказывать корректность, но давайте хотя бы разработаем разумную методику процесса.

                                                Это справедливо (как и ремарки Дейкстры), но давайте перейдём к третьему уровню. Если совсем упростить, можно почти всё свести к экономической целесообразности. Хорошо обученный специалист затратил долгие годы на своё образование и стоит достаточно дорого. Проектирование и поддержка качественной системы тоже стоит денег (да, считается, что это окупается, но гарантий нет), при этом цена ошибки далеко не всегда измеряется миллионами. Вот мы и подсчитываем, стоит оно того или нет.

                                                Я думаю, что качество (в широких массах) двигается за счёт качественных компонентов, которые достаются дёшево. Например, вас беспокоит сохранность данных при передаче. Ну окей, переходим на HTTPS — благо есть готовые библиотеки, разбираться с протоколом не нужно. Или хотим мы создать качественный 3D мир. Прекрасно, берём Unity, там уже всё есть. То есть я в целом хочу сказать, что методика нужна, но надеяться на повсеместное применение лучших практик невозможно, потому что это отнюдь не даром достаётся.
                                                  0

                                                  Спасибо, подпишусь под каждым словом!


                                                  С экономикой — тоже абсолютно согласен. Грубо говоря — много слесарей, мало инженеров. Но у последних рычаг длиннее.


                                                  Есть, правда, одна особенность, не очень существенная для нашей дискуссии, но в какой-то мере к ней относящаяся. Буква Т в ИТ (пока) толкает третий уровень постоянно и с возрастающим, рывками, ускорением. Я несколько раз наблюдал, как выбрасывало целые поколения специалистов.


                                                  Как потерялись работники ВЦ (соотношение женщин и мужчин в профессии, кстати, в те инженерные времена четких ролей, было гораздо более ровное). Но это понятно, изменения были драматическими.


                                                  Как вынесло другую прослойку, ребят (моих ровесников) пишуших под DOS по отдельной программе для каждого конкретного заказчика. И, чего многие не понимают, виной тому был банальный Excel, а не только и не столько наивность или глупость начинающих программистов.


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


                                                  В общем, я уверен, что нынешних "ремесленников" тоже смахнет в вероятном ближайшем и вижу, что их вклад не так велик, если умножить на срок приложения сил и будет уменьшаться дальше, превращая, благодаря достижениям инженеров, в продвинутых пользователей. Как Вы думаете, мне это кажется напрасно, или асбтрактный рынок тоже это скоро заметит?

                                                    0

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

                                                      0

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


                                                      Но, в то же время, текущее положение — всегда точка встречи и влияния двух векторов — один подход, условно говоря, практический, а другой — научный. По обоим этим направлениям силы прикладываются не случайно, а в попытках эту "телегу" подтянуть куда "нужнее".


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


                                                      Один из преподавателей сокрушался, показывая на меня: "сейчас молодежь интересуют приложения, а не алгоритмы". С тех пор порог вхождения в "продуктовую" область все время продолжал уменьшаться, что замечательно.


                                                      Но, снова, единственное, что я хотел сказать — видимое расширение и "очеловечивание" отрасли не должно обманывать вновь прибывающих специалистов, процент ротации все еще высок. Рынок будет продолжать отсеивать. Вопрос — добавятся ли критерии, кроме очевидных требований "опыт разработки на Go от шести лет"

                                                        0

                                                        И сейчас часто бывают критерии о знании алгоритмов и на собеседовании их проверяют частенько. Даже мода на это есть.
                                                        Но по мне это самые ужасные команды в итоге, которым приходится отказывать, как правило. Во-первых, не знаю как, но наши ВУЗы часто взращивают надменность в людях и отношение свысока. Есть мы, наука, люди знающие, и прочий временный люд. И собеседования выглядят соответствующе.
                                                        Требования должны быть под задачи. Не более и не менее. Отсева спецов нигде не наблюдаю, есть только расслоение по рынкам.

                                                          0

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


                                                          Отсева спецов нигде не наблюдаю, есть только расслоение по рынкам.

                                                          Это замечательно. Говорит и о том, что, скорее всего, и Вы находитесь в правильной среде, и всякие ИИ и пр. не вытесняют, пока, среднего уровня специалистов.

                                                      +2
                                                      Я не готов судить, но вполне вероятно, что имеется таки, по крайней мере, один тектонический сдвиг, о котором говорит Сассман:
                                                      «Программирование сегодня больше напоминает науку: вы берете часть библиотеки и «тыкаете» в нее — смотрите на то, что она делает. Затем вы спрашиваете себя, «Могу ли я настроить это так, чтобы оно делало то, что мне нужно?». Подход «анализ через синтез», используемый в SICP, когда вы строите большую систему из простых, маленьких частей, стал неактуальным. Сегодня мы программируем «методом тыка».

                                                      То есть дело не только в том, что в 2000-м году резко потребовались верстальщики HTML, а в 2015-м — писатели на Angular, и рынку приходится иметь дело с существующими людьми, какими бы они ни были, но и в более серьёзных изменениях.

                                                      Скажем, что классические методики SE говорят о ситуациях такого вида:
                                                      — Мне нужно использовать библиотеку, в которой есть заведомый баг, но варианта не использовать её у меня нет?
                                                      — Мне нужно использовать библиотеку, чья структура плохо совместима с архитектурой моей системы?
                                                      — Две библиотеки предоставляют массу дублирующегося, плохо документированного или просто legacy в худшем смысле слова кода?

                                                      Я могу придумать массу таких вот вопросов, которыми в науке мало кто задаётся, потому что это скучно и на премию Тьюринга не потянет.
                                                        0

                                                        Спасибо за ссылку. Про замену SICP курсом Питона читал, но этот комментарий Сассмана не видел.


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


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


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


                                                        Вопросы к SE хорошие, но для ответа на них хватит и простого здравого смысла, без формальных доказательств.


                                                        Спасибо!

                                                          0
                                                          Насчёт короткой жизни продукта не соглашусь, как раз сейчас у кода есть шанс жить десятилетия (я вот не знаю, кому-нибудь за последние 20 лет приходилось самостоятельно писать, скажем, функцию распаковки GIF формата в BMP на C?)

                                                          В остальном — ну, да, какие времена, такие и вызовы.
                                                            0

                                                            Ну я говорил не коде, который код (библиотека) и актуальность которого зависит от времени жизни платформы, а о продукте, у которого время жизни зависит еще и от спроса и от конкурентов.

                                                      +1
                                                      но давайте перейдём к третьему уровню. Если совсем упростить, можно почти всё свести к экономической целесообразности.
                                                      В капиталистическом мире с этого уровня и не уходили никогда ("… при 100% он попирает все человеческие законы..."): те же автомобилестроители сравнивают стоимость исправления опасных ошибок в конструкции с предполагаемыми суммами выплат за погибших, если не исправлять.
                                                  +1
                                                  Даже когда программное обеспечение приводит к катастрофам, мы видим заголовки день-два и потом ничего. Радио тишина.

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

                                                    +3
                                                    В свою очередь терракты и хулиганство девочек в церквях получают широкую огласку и далеко идущие последствия.

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

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

                                                        0
                                                        По моим наблюдениям это касается любых тем — заголовки день-два, а потом даже опровержения неверной информации нет. Журналист задачу выполнил — заходы/продажи поднял, а даже соответствие действительности никого не волнует.
                                                        Немного пофорсить тему могут провластные структуры, но даже они сдуваются достаточно быстро.
                                                        africaunite — по заголовкам о внутренней кухне судить сложно, это ДСП-документы надо смотреть.
                                                          0

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


                                                          Я до тошноты спорил, включая четыре раза в этом блоге (теперь пять), о необходимости простого правила, которое требовало бы публичной ревизии каждого такого события; цитируя самого себя: авиаперевозки становятся безопаснее не случайно, а из-за несчастных случаев.
                                                            0
                                                            а потом даже опровержения неверной информации нет. Журналист задачу выполнил — заходы/продажи поднял, а даже соответствие действительности никого не волнует.

                                                            Опровержение обязательно будет, если оно кому-то выгодно и выполнит ту же задачу, а именно привлечёт интерес и поднимет заходы/продажи :)


                                                            А в целом, вы правы, конечно. Печально, что по факту нет никакой ответственности за враньё в СМИ или публичных заявлениях.

                                                          +2

                                                          Очень понятный текст. Заслуженный товарищ год из года видит беду и ее усугубление, но не видит решения. От того и кричит.
                                                          До дня, пока введение лучших методологий разработки ПО не перевесит у бизнеса "прибыль сейчас — возможная реализация рисков потом" ничего не будет изменено.
                                                          То же кричат специалисты по информационной безопасности: классические уязвимости давно известны, равно, как и способы их предотвращения, но он этого они не перестают занимать весь top10 уязвимостей.
                                                          Бизнес — это люди. И даже если случится беда или ЧП, то можно сделать крайним того, кто написал код. Так во всем мире. VP отмажут, а Варю/Карла/Смита наоборот.
                                                          Можно ли что-то поменять? Не думаю, да и зачем? SE росла тогда, когда на софт был заказ у очень больших ребят и правительств. Был заказ — был товар в виде спецов. Вполне может быть, что те 3-6% найма в SE, о которых сокрушается автор, в абсолютных значениях такие же, что были в 70-80е. Просто вырос больший рынок и доля уменьшилась тех дел, где SE полезно бизнесу. Довольно цинично, понимаю.
                                                          Ребята из ML создают новые продукты, которые можно продать. А что создаёт SE? Уменьшение рисков? Я обеими руками За! Но зачем это конкретным людям в бизнесе? Тот же VP отработает от 1 до 3 лет и свалит в лучшее место. Ему важнее больше плюшек с новых продуктов заиметь, чем предприятие и продукт обезопасить в будущем. У него и kpi(okr) про это.
                                                          Безопасность и надёжность — это теперь вотчина PR. Об этом надо говорить, но не делать.

                                                            +1

                                                            Хороший анализ. А как Вы считаете, можно ли рекламу ПИ формировать не только образами катастроф? Я понимаю, что для этого у бизнеса нет времени, интереса и средств, соответственно.
                                                            Но вот тот же Rust или TypeScript, как конкурентные преимущества их создателей?
                                                            Может ли получиться продвигать ПИ не вопреки авось (не перебьешь), а как заботу об эффективности труда?
                                                            Хотя понятно, что продаются навыки, а не знания, но есть ли вариант переместить те же понятия аспектного программирования, или BDD в ранг навыков и сделать их модными?

                                                              +1
                                                              Может ли получиться продвигать ПИ не вопреки авось (не перебьешь), а как заботу об эффективности труда?

                                                              Тут есть вопрос, а это истинное утверждение вообще?
                                                              Или имеет место быть, что SE дает эффективность труда в определенных предприятиях, определенных проектов?
                                                              У меня тут, быть может, несколько предвзятое мнение, поскольку много доводилось иметь дело с людьми из Oberon тусовки и проектов, которые всеми руками за доказательность верности программы и прочая и прочая. Однако же взлет языков программирования, которые дают большие гарантии программистам, был быстрым и недолгим. Это все еще тот старый-старый спор между европейский и американской школ: должен ли программист подстраиваться под бизнес, или он должен объяснять бизнесу, как правильно пользоваться поставляемыми им инструментами.
                                                              Для меня ответ очевиден: «no free lunch». На мой взгляд, это должно быть краеугольным камнем SE.
                                                              Мы не можем утвердать, что подходы «безопасные» подходы работают хорошо и, что нет или ничтожно мало количество случаев, когда эти подходы будут работать хуже некуда.
                                                              На мой взгляд, мало учить SE, надо учить и продуктовой разработке, надо учить и основам предпринимательства, чтобы можно было выбирать подходящие инструменты из подходящих подходов.
                                                              Зачем нужно увеличивать время на разработку более надежного софта в 2-3 раза, усложнять процесс найма сотрудников, обучения и будущей поддержки (плюс риски, что выбранный новый и «надежный» язык умрет, в отличие от какого-либо старого и «ненадежного»), если бизнес рискует небольшими убытками в случае ошибки?
                                                              На мой взгляд, поменять положение вещей можно принципеально, если наши (буду говорить о нашем образовании) ВУЗы начнут учить программировать. Сейчас студент или выпускник учится программировать не в ВУЗе, а там, где придется, или где приткнется. Как правило, это так себе опыт и навыки, которые во многом определят будущие навыки. Стоит учить делать и доводить проекты до финала в составе небольших рабочих групп прямо в ВУЗе. Народ и первые шишки набьет и можно будет показать, как избегать ошибок более умными подходами и проектированием. Будут выходить из ВУЗов способные к работе программисты, умеющие и любящие хорошие практики, будут эти ребята и девчонки со временем новым поколением CTO, CEO, VP. Тогда можно будет говорить о шансах, что что-то поменяется.
                                                                0
                                                                вы правы насчёт бизнеса, конечно не теоретикам учить их заниматься бизнесом, однако есть сферы в которых халатность бизнеса создаёт риски для жизни и здоровья людей и там бизнес нужно заставить делать нормально или делать это силами государства прямо или косвенно
                                                                  0
                                                                  Да, для этого, на мой взгляд, должно быть регулирование на уровне государства. Стандарты и контроль.
                                                                  0

                                                                  Сделаю два признания.
                                                                  Во-первых, это отличный комментарий. Настолько, что я даже решил не отвечать на ходу. И именно ради такого рода ответов, позволяющих подумать (а не спешить перекрикнуть анонимов своим Я, успев заметить во всей простыне только заголовок), перевод всей и каждой статьи и делается. Правда я сейчас тут сам издалека начну, так что может показаться, что к Вашему комментарию мой отношения не имеет ;)


                                                                  Второе — в оригинальном черновике перевода, зная, как тяжело на нашем читаются привычные для английского уха повторы слов и личных местоимений (а в популярных статьях еще любят писать как герой выглядит и что он ест), термин Software engineering выражался тремя или четырьмя вариантами фраз. Т.е. там были и "проектирование (engineering) программного обеспечения" и "инженерия ПО", а местами даже "разработка ПО". Профессор Мейер (невероятнейший человек) меня поправил и посоветовал везде придерживаться оригинала и использовать стандартный термин "программная инженерия". Текст от этого, само-собой, стал выглядеть менее русским и гладким, но за совет я был благодарен. И только к утру (спасибо комментаторам, в том числе) понял настоящую ценность такой правки. Я понял, что статья, действительно, именно об отрасли "программная инженерия".


                                                                  Честно говоря, я совсем забыл, как и что это было. Как сам же доказывал, лет 15 назад, что программирование — это инженерная (в сельскохозяйственном роде) профессия, а не чистое творчество (до сих пор так считаю, видимо из-за увлечений и образования). Забыл потому, что тогда, в конце 90-х, начале 2000-х, последний всплеск закончился почти полной и заслуженной победной песней "манифестов" (К. Бека, прагматиков и т.п.). Заслуженной потому, что вариант с "зарегулированием", за который зацепились гранды от методологии, был, кроме того, что очень скучным, так еще и несвоевременным — задачи росли, дисциплин и практик явно все еще не хватало и лишняя пачка бумаг, пусть и хорошо структурированных, типа SWEBoK, казалась издевательством. Так оно и вышло. Если всякие ITIL и PMBoK, все-таки, местами, прижились, а отраслевые гиганты смогли еще в 90-х закрепиться на сертификации (CСNA/CCNP/CNIE от Cisco, MCP/MCSE/* от Microsoft, от Novell, Oracle и т.п.), то SWEBoK, похоже, благополучно забыт.


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


                                                                  Ох. Стоп. Еще раз — согласен с каждым Вашим доводом.


                                                                  Но вот вопрос — не кажется ли Вам, что, как и говорится в статье, SE бородатых авторитетов с европейскими акцентами прошло? Я правильно понимаю, что пора пройти и эре "возврата в средневековье" и теперь, наоборот, самое время вернуться к правильному пониманию инженерии? Может быть статья об этом?

                                                                    0

                                                                    Как я понимаю, профессор Мейер из университета Цюриха, как и Никалаус Вирт по сей день.
                                                                    Мне кажется, что это сильно добавляет контекста для статьи. И, возможно, стоило бы осветить тот старый спор европейской и американской школ. Вы, как я понимаю, застали его. Я о нем знаю только потому, что интересовался.


                                                                    Вы говорите важные вещи, которые стоит знать программистам, вы говорите о изрядно забытой SE.


                                                                    Но мне трудно понять вас, когда вы говорите о качестве ПО. "Оно упало" — звучит так, словно качество есть нечто абсолютное, а не нечто понимаемое и измеряемое только в контексте задачи. Еще раз повторюсь, что есть "no free lunch theorem" и любой предложенный прекрасный подход к разработке ПО будет ужасен в определенном наборе случаев. Даже не "не очень подходящ", а плох, нерабочим.


                                                                    И я бы предложил остановиться тут подробнее. Если мы утверждаем, что SE, служит повышению качества софта (что может обсуждаться), то мы должны не идти в рассуждении далее, пока не определим понятия "качества", а затем "качества ПО". Иначе наши выводы по меньшей мере сомнительны.
                                                                    Это первый важный момент, на мой взгляд.
                                                                    Второй, о европейской школе. Для меня их время не прошло, а труды изрядно недооценены. Из-за этого часто разработчики как калеки: заставить код работать могут, но если возникнет отдельная задача о "качестве", то инструментов и понимания нам не хватает.


                                                                    И ремарка: я в дискуссии участвую, как "любитель", поскольку профильного образования не имею, хотя и все годы от совершеннолетия работую разработчиком или руководителем разработки. Так что я могу быть предвзят про наши ВУЗы :)

                                                                      0

                                                                      Нет, не застал и уверен, что Вы находитесь в теме гораздо глубже, чем я.
                                                                      В спор между CS и SE я, кстати, не верю (потому что сами термины недопонимаю, скорее всего), но верю в то, что научно-обоснованный (инженерный?) подход игнорировать и задвигать нельзя.


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


                                                                      Второй, о европейской школе. Для меня их время не прошло, а труды изрядно недооценены. Из-за этого часто разработчики как калеки: заставить код работать могут, но если возникнет отдельная задача о "качестве", то инструментов и понимания нам не хватает.

                                                                      Да, и вот эта цитата также подтверждение того, что мы говорим об одном и том же.

                                                                        0
                                                                        но верю в то, что научно-обоснованный (инженерный?) подход игнорировать и задвигать нельзя.


                                                                        Это верно только в отношении *производства*. «Проблема» в том, что software development — в своей массе — все сильнее дрейфует из категории *производство* (пусть и не материальное, пусть группы Б), в категорию *обслуживание*. Причем, имхо, дрейф этот отнюдь не спонтанный, а вполне осознанный (если не сказать, вынужденный).

                                                                        А *обслуживание* вполне возможно без инженерии как таковой… она там скорее «мешается под ногами» и «все портит».
                                                                          0

                                                                          Может быть я не совсем верно Вас понял, но Вы имеете в виду именно создание ПО, или всю область информационных технологий?


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


                                                                          Так уже было, сейчас произошел откат наверх, благодаря появлению новых платформ (а вернее — рынков), интернету, как средству доставки и, в какой-то степени — резкому удешевлению разработки (не только в денежном, но и в смысле усилий) благодаря открытому ПО. Очевидные сейчас следующие "сдвиги" — это уже не смартфоны, а IoT (которые будут завязаны на производителей и стандартные АПИ, иначе не выйдет эффекта синергии), AI (где, как раз, возможно и получится предлагать новые методологии для эффективной "настройки") и Quantum computing (который до массового специалиста дойдет не раньше, чем лет через 10-15, видимо. Причем не столько из-за доступности, но и в ожидании появления массового спроса на решения подходящих задач).


                                                                          С другой стороны — бОльшая часть отрасли — всегда было обслуживанием, но мне кажется, что Вы не об этом.


                                                                          С третьей — в налаживании обслуживания — методика нужна не меньше, так как само оно — деятельность процессная, и даже не проектная, а тем более — не творческая. Как пример — мой дед получил орден Ленина в начале тридцатых за создание МТС (машино-тракторных станций) в ТССР. Я к тому, что инженеры заточены на решение проблем и налаживание повторяемого процесса, в отличие от исследователей (ученых) или творцов (художников).

                                                                            +1
                                                                            Про SD, конечно… за все IT целиком говорить очень сложно… оно очень разное.

                                                                            Речь о том, что происходит замена *продукта* (производство), пусть и не материального — *услугой* (обслуживание).

                                                                            «Процесс» есть и там, и там — конечно. Но место его существенно разное.

                                                                            Дело не в том, что «налаживание обслуживания» может потребовать инженеров… Дело в том, что сам (уже «налаженный») процесс «оказания услуги» инженеров уже точно не подразумевает. Что мы и наблюдаем.
                                                                              0

                                                                              Да, мы снова об одном и том же.
                                                                              Я там опечатался: "и кастомным разработкам" осталось от старой фразы, ну или можно заменить на "доработкам"


                                                                              Расширение области требует инженеров. Фиксация требует, чтобы инженеры занялись расширением в других областях, и, в небольших количествах, контролировали процесс на уже "завоеванных" территориях.

                                                                    0

                                                                    По поводу обучения в ВУЗах продуктовой разработке и предпринимательству — абсолютно согласен.


                                                                    Более того, разбить профессию на еще большее число специализаций (в Болонской системе, впрочем, решается немного по другому), и добавить еще больше дисциплин: экономика/управление проектами/информационный дизайн/биоинформатика/ИИ/квантовые вычисления/функциональное/ООП/сети/базы данных/теория информации/алгоритмы/литературная грамотность/иностранный язык/ и т.д.


                                                                    Нас, первый набор специальности АСОИиУ, от растерянности, учили как настоящих инженеров — сопромат, электротехника, начертательная геометрия и т.п. Это были именно дисциплины, а не науки. И именно они вправляли в мозг инженерную закваску — умение применять знания (науки) для решения конкретных задач.


                                                                    Тут, кстати, кроется еще одна причина провала SE — неопределенность с CS. Там был конфликт, кто есть кто. Причина в том, что фундаментальных наук в Computer Science маловато, все больше прикладные отрасли знания, а они инженерные и есть.


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


                                                                    Еще — делать все, чтобы студентов принимали в интернатуры (на практику по старому) в настоящее производство. Потому что ни на каких занятиях невозможно научить инженера акутальным навыкам. Как не учат, например, ремонту конкретных марок двигателей инженера-механизатора.


                                                                    И снова — все это уже есть. Вопрос только в качестве реализации. И я думаю, что и у нас доберется. Вот сам, например, брал работника вслепую — только узнав, что он закончил тот же американский ВУЗ, что и предыдущий сотрудник. )))

                                                                      0

                                                                      Почему думаете, что не получилось бы учить популярным языкам? Любопытно действительно.
                                                                      Мне видится, что за время обучения вполне можно дать студентам боевое крещение в языках всех основных направлений: python, как удобный в разработке и с динамической типизацией да и для DS и ML на более старших курсах зайдет, golang, со строгой типизацией, но очень малым "словарем" языка и удобным набором инструментов для написания конкурентного и параллельного кода, elixir или erlang, как хорошие функциональные языки, которые на порядок проще в освоении, чем любимый многими и мной тоже haskell.

                                                                        0

                                                                        Нет-нет. Я имел в виду именно "модные" навыки (skills).
                                                                        И в силу инерции (ну вот представьте, сколько времени нужно на утверждение курса по тому же Go), и, что важнее — у института должна быть задача подготовки навыка самостоятельного получения навыков (и знаний). Метрика должна быть — как быстро ученик овладевает новыми умениями, а это не поднимешь простой, но бесконечной гонкой за убегающей (в модном) мишенью.


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


                                                                        Вот у rg_software, кстати, замечательные посты на эту тему. Ему действительно должно быть, что сказать по этому поводу.

                                                                          0

                                                                          Все же, для меня, наше невопоротливое в самой своей мути образование вызывает только тоску и желание взвыть. Со всеми этими утверждениями и прочим.
                                                                          Как мы можем говорить о том, чтобы что-то внятное дать через наши ВУЗы, хотя знаем, что изменения почти нереальны. Несколько радуют только курсы от ВШЭ, которые пробуют делать, что-то современное.

                                                                            0

                                                                            Когда заинтересованные стороны начнут голосовать рублем, тогда и будут соревнования. Местами такое есть (я могу вспомнить множество ВУЗов, кроме ВШЭ), но большинство институтов готово тихо жить на дотациях и почти поголовном желании иметь хотя бы корочку (важна стандартная книжечка, а не особые знания или имя заведения).

                                                                              0

                                                                              Думаю, уже начинается. Образование, видимо, идет к 100% платности и тут уже будет вопрос, образование какой страны выбрать. Я для своих детей, коль кто решит брать то же ремесло, не думаю выбирать наши вузы, даже просто сравнивая программы и ценники.

                                                                                0

                                                                                Ну не только платность образования (в Англии, кстати, красиво сделали, через льготный долгосрочный кредит, который, если ты не согласен, что образование окупилось, можно и не возвращать (конечно так никто не делает)). Есть еще и отраслевые спонсоры-рекрутеры, можно брать на себя роль бывших НИИ, которые теперь все превратились в ООО-лендлордов, и выполнять исследования, можно коммерциализировать те же прикладные и фундаментальные открытия. Все стимулирует качество.


                                                                                По поводу заграничного образования в нашем ремесле — вот один из опосредованных, но все же солидных рейтингов: https://icpc.baylor.edu/worldfinals/results

                                                                              +1
                                                                              Я работаю в зарубежном вузе, и вот просто ради полноты картины скажу, что счастья нет нигде. Вам, наверно, хочется, чтобы в вузах преподавали люди, реально работающие на переднем крае науки, а не прочитавшие что-то про нейросети во втором русском издании четвёртого пересказа оригинала? Но в этом случае придётся смириться с тем, что этим людям есть чем заняться в жизни помимо вдалбливания элементарных вещей студентам младших курсов.

                                                                              Реальность такова, что программирование/информатика не входит в обязательную школьную программу очень многих даже хороших стран. В Британии вводят вот прямо сейчас, в Японии введут с 2020го, если не ошибаюсь. Студентами становятся люди, которые не могут даже написать программу «Hello, world» на Бейсике. При этом им уже на первом-втором году обучения приходится читать достаточно нетривиальные курсы, которые требуют и соответствующего уровня от лектора. Интереса в такой работе не так много, большой процент профессуры именно преподавательскую часть откровенно не любит, и надеяться на постоянное совершенствование и шагание в ногу со временем не приходится.

                                                                              Да, конечно, если человек профессионально занимается NLP или там нейросетями, он сможет провести прекрасный спецкурс по этой узкой теме, но это лишь небольшая часть общего паззла.
                                                                                0

                                                                                Пример с cs231 я привел, как способность вузов к быстрой адаптации к новым условиям.
                                                                                Про то, чтобы этот или подобный курс преподавал "светило" и прочее, что вы написали, я не говорил.

                                                                                  +1
                                                                                  А других там не держат, вы не сможете стать преподавателем Стэнфорда, будучи просто вменяемым специалистом по теме и хорошим педагогом.
                                                                                    0

                                                                                    Судя по эволюции курса, его начинали "светилы", но через 2 года большую часть лекций дают толковые аспиранты.

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

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

                                                                                      В любом случае обновлять и улучшать курс всё равно будет профессор (когда найдёт на это время и желание...)
                                                                                        0

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


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


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

                                                                                          0

                                                                                          Курс про DL и конкретно для речи один курс и один для распознавания изображений. Если посмотреть содержание, то становится очевидно, что основывались на последних алгоритмах и книге Goodfellow 2017 года.
                                                                                          Тут лучше бы возражения фактами подкреплять.

                                                                                            0

                                                                                            Вообще не возражаю. Но мы говорили о конкретных навыках (языках программирования).


                                                                                            Proficiency in Python, high-level familiarity in C/C++
                                                                                            All class assignments will be in Python (and use numpy) (we provide a tutorial here for those who aren't as familiar with Python), but some of the deep learning libraries we may look at later in the class are written in C++. If you have a lot of programming experience but in a different language (e.g. C/C++/Matlab/Javascript) you will probably be fine.

                                                                                            предполагается, что для изучения научной дисциплины (наука моде подвержена меньше и знания как фундамент, а не временный слой) нужно пройти (самостоятельно) курс или знать языки

                                                                                              0

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

                                                                                                0

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


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

                                                                                            0

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

                                                                                              0

                                                                                              Учить другого (эмпатия) и самообучение (вполне себе навык) — две разные вещи.


                                                                                              Никто же не требует от тренера сборной быть (в прошлом или настоящем, не важно) — лучшим спортсменом страны.


                                                                                              Но, снова, я согласен образование не должно быть для галочки. Институты своей деятельностью не должны заниматься для галочки. Вариантов, кроме рыночных (кстати, рыночный запрос может создать и государство, а иногда даже обязано, если умное и переживает за место под солнцем) не вижу.

                                                                      +1
                                                                      Персональное разоблачение: о себе я думаю, как о том самом образце современного методиста [3], без бороды или голландского акцента, но пытающегося вынести на современную ИТ сцену факел плодотворных работ семидесятых и восьмидесятых.

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


                                                                      Мой взгляд на проблему старого и нового:

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

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

                                                                        По поводу первой Вашей цитаты — я публиковал пост именно как вопрос — что можно сделать, чтобы к проблемам, которые перечислил автор стали относиться серьезнее в более широком кругу специалистов. Я так понимаю, речь не о технических новшествах, а о новой попытке вернуть популярность подходам систематизации знаний/путей решения.


                                                                        По поводу второго — я и сам хожу с телефоном, который мне подарили в 2008 году. Но! Вносит ли эта культура деструктивный вклад в сознание людей, или она пользуется незрелостью личности, для которой телефон может стать неудобен не только по техническим параметрам, но и по социальным понятиям? Не могу сказать, возможно, что для экономики и развития человечества это хорошо. Брать деньги у таких людей, чтобы было на что развиваться (не только гнать по наклонной). В любом случае, это отдельная тема.

                                                                          +1
                                                                          я и сам хожу с телефоном, который мне подарили в 2008 году.
                                                                          Телефон — дело личное. А как быть с новым ( возможно, сырым) компилятором или с новой ОС? — Это проблемы серьезнее, чем смена телефона. Но, к сожалению, очень многие разницы не видят. Поэтому на вопрос:

                                                                          что можно сделать, чтобы к проблемам, которые перечислил автор стали относиться серьезнее в более широком кругу специалистов


                                                                          Я отвечаю: ИМХО прежде всего перестроить собственное мировосприятие, т.е. отрешиться от психологии потребления, хотя бы в проф.сфере. Почувствовать принципиальную разнницу между личным телефоном и инструментами/методами разработки ПО, Почувствовать ответственность за свой продукт. Сейчас многие крупные юр.лица предпочитают малоответственное отношение ради доп. прибыли и не только в сфере ПО, автомобили, нпр., периодически отзывают. Когда это станет невыгодно (не только по деньгам, но и в плане репутации), тогда возродится интерес к методам надежного проектирования софта.
                                                                            0

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


                                                                            Но. Да. Предупреждать тех, кто не осознает компромиссов и верит слепо нужно. Хотя и бессмысленно. Но, может быть, вспомнят о теме, когда обожгутся и "дозреют".

                                                                              +1
                                                                              В развитых странах бизнес очень гибок и очень прислушивается к общественному мнению — кто не гибок и не прислушивается, тот не выживает. Поэтому пропаганда идей надежного ПО даже на популярном уровне для массового потребителя может иметь большой смысл. С этой точки зрения недавние громкие скандалы, связанные с софтом и железом, могут иметь значительные последствия уже завтра. Будем оптимистами :)
                                                                                0

                                                                                Будем. Эффективно общественное мнение служит (культивируется) — когда бизнес (или кто там заинтересован) сам может им манипулировать как конкурентным преимуществом. Очень часто выгодополучателем и спонсируется. Надо такому субъекту дать метрики надежности (чтобы сравнивал), способы достижения (чтобы отстроился) и методы заработка (тут суть) и все будет ОК ;)

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

                                                                        Но это если в эту невозможную отрасль никто не влезет с регулированием.

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

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

                                                                        К сожалению сейчас данная технология бесконечно сложна из-за очень слабого технологического развития цивилизации, которые ещё и тормозится разными чуваками(которые по сути предали человечество) под разными предлогами(защита природы, снижение выбросов, перенаселение(эти вообще могут соперничать с Пол Потом), etc) так что шансов на реальный продукт в 21 веке где-то около 0%, скорее всего ровно 0%.

                                                                        Первая причина — малый размер мегаполисов. Если IT не может нормально жить в миллионниках и нормальную кашу можно сварить только в глобальных городах с 5-10млн+, то в создании продукта, обеспечивающего бессмертие скорее всего быть нужны города минимум 50+млн из-за того, что эта технология стоит выше по пирамиде технологий, иначе там тупо не будет достаточного числа спецов, с специфическими чертами и мозгами, концентрация которых в одном месте и даст продукт.

                                                                        Чем крупнее город, тем легче в нём делать сложный продукт вверху технологической цепочки, стоящий на спинах сотен других компаний(чем меньше город, тем меньше этих спин).

                                                                        Если бы на Земле жило 50млрд урбанизированных человек, данная проблема решалась куда быстрей. Однако подавляющее большинство людей не любит людей(людей в целом), и не любит когда человечество растёт, особенно когда быстро растёт. Ненависть людей к людям и их развитию как раз и приводит к тому, что технологический уровень недостаёт для того, чтобы взломать природный hi tech и подчинить его.

                                                                        Это проблема номер раз!

                                                                        Также вторым пунктом идёт самоощущение — большинство людей считает что люди — ничтожества и самые худшие существа на земле. Это тоже делает невозможным мысли, что именно я хочу заняться проблемой. Вместо этого появляется что-то типа —
                                                                        наверное они сделают эликсир вечной молодости уже скоро и ещё нужно выпустить закон, чтобы он был бесплатен, а то не справедливо. Но увеличивать могущество человечества путём строительства заводов, электростанций в 10-100 раз — ни ни ни, ни в коем случае. Но они таки изобретут эликсир, я верю, я ж мастер магического мышления


                                                                        Так что в совокупности национальные идеи большинства стран(но не Китая!), продавливают собственное мнение людей в вышеприведённом направлении и в итоге мы имеем кучу людей, которые хотят быть бессмертными, но не хотят при этом чтобы было построено в 2 раза больше заводов(это по очевидным причинам желание взаимоисключающих параграфов). И добиваются именно отказа от строительства заводов и прочих средств повышения могущества цивилизации
                                                                          0
                                                                          прикольно, это сообщение должно было попасть в другую вкладку.
                                                                          Считать данное сообщение ответом на пост https://habrahabr.ru/post/350376/

                                                                        Only users with full accounts can post comments. Log in, please.