Комментарии 141
Тяжело?
Читать?
Статья ученого, переживал за перевод. Одобрил комментарий в надежде на более развернутое пояснение.
Впрочем, на вопрос вы ответили.
Да, тяжело читать. Zanak достаточно адекватно ответил на широкий вопрос, который можно было интерпретировать тысячей способов:)
Как разрабатывать софт писяя больше документации чем кода? Так это помнят те кому нужно, но от аварий это не страхует, да, их меньше, но цена этого огромна, когда-то читал оценку что разработка софта для НАСА в 170 раз дороже обычной коммерческой разработки.
Мало у кого есть такой бюджет на разработку софта, зачем готовить много таких специалистов?
А если говорить о проблемах в отрасли, да они есть и очень остры, я думаю что нужна более сильная магия.
Она может и ещё дороже, но хоть что-то делает надёжно.
Под магией Вы понимаете микроядро sel4L, я так понимаю? И формальную верификацию как панацею? Согласен, хороший пример правильного проектирования ПО.
Думаю Вам, в таком случае, тем более будет интересно почитать о языке Eiffel, принципу дизайна по контракту и тому, какое влияние они оказали на современные языки и решения. Надеюсь Вам понравятся идеи и автора этой статьи.
Не подумал, что надо подробнее представить автора в начале статьи, исправлю, спасибо.
А языки я думаю нужно более математические и видимо чисто функциональные аля haskell
Вижу, что Ваша позиция во многом совпадает с авторской. Скажите, а у Вас есть примеры успешного промышленного применения Хаскеля?
Впрочем это ровно ничего не означает, во-первых, хаскел я привожу просто как пример языка который есть математика, а значит более подходящ как для верификации так и для безопасных оптимизаций компилятором, во-вторых, даже отсутствие внедрений ничего бы не доказывало, кроме низкой популярности или высокого порога входа.
Ныне джаваскрипт самый популярный, но не думаю что кто-то будет утверждать что это лучший инструмент для создания надёжного софта.
Не заметил комментария. Тогда снова вопрос — если Хаскель просто как пример, тогда почему в этом же качестве не может быть Eiffel (это я все еще про Ваш первый комментарий и древнюю супермагию). Хотя, это я придираюсь.
По поводу приведенной статьи о Haskell и JS как лучшем инструменте, кстати.
Мы делали очень надежный и эффективный слой АПИ на NodeJS в 2014. Кроме инструментов (промисы, pm2, слава NPM и др.;) это, конечно, зависит от культуры программирования, которой язык может просто помогать или мешать в большей или меньшей степени. Так вот, прочитав ту статью (она от 2013), я бы и тогда и сейчас, сравиниваяя именно их, отдал бы предпочтение NodeJS (в данное время и в реальности я предпочтение, конечно, отдаю уже не ему)
И это важно т.к. верификация процедура очень затратная.
Я с этой темой знаком поверхностно, и мне показалось, что тут важнее не какой язык, а что мы ищем. Ну и, соответственно, сложность зависит от этого. Например, если вам надо доказать, что в системе есть deadlock, это ещё терпимо, т.к. достаточно найти один пример того, как это может случиться. А вот если требуется доказать, что всегда после события А рано или поздно наступает событие B, это уже куда сложнее.
Я немного рассказываю студентам про model checking, вот в своё время пытался подобрать наиболее простой инструмент, и в итоге выбрал банальный Spin. Если посмотреть список в Википедии, Хаскелл там вообще не упоминается, да и, по правде говоря, больше половины указанных проектов реально мертвы.
Но тут пишут:
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.
Кроме того есть перспективное направление верификации — зависимые типы (в Haskell они пока почти не поддерживаются, только планируются, но есть ATS, IDRIS в которых они готовы к использованию). А зависимые типы без чистоты функций сделать непонятно как. Скажем у нас есть вектор v длинны l, а кто-то присваивает l новое значение, что после этого считать типом v?
К тому же полноценная проверка контрактов существенно более сложна, чем проверка типов, так что многие ошибки она позволит обнаружить раньше.
К тому же ООП без соблюдения принципа подстановки Лисков очень мешает надежному программированию, а описать этот принцип контрактом совсем не просто.
Сравнение с нодой несколько странное. Фьючи — более развитый механизм асинхронного программирования, чем промисы. Они являются монадами, а в работе с монадами с Haskell трудно тягаться (хотя сейчас появился Purescript, транслирующийся в джаваскрипт, где монады дополнены концепцией «эффектов», которые, потенциально, должны обеспечить дополнительную надежность). Управление пакетами в Haskell (cabal) ни чуть не отстает от npm.
По поводу первого — я так понимаю, что контракты, как раз, должны требовать исполнения этого принципа. Но, так как почти не в теме — было бы интересно узнать, чем они усложняют его соблюдение.
По поводу сравнения NodeJS и Haskell — я именно сравнивал с практической точки зрения, ни в коем случае не особенности языка как таковые (feature тогда в синтаксис еще не ввели, промисы были на библиотеке Bluebird.js). Про управление пакетами в Haskell не знал, спасибо!
В 2018 году, когда регулярно слышны новости об успехах функционального программирования в промышленности и животноводстве, вопрос «а у Вас есть примеры успешного промышленного применения Хаскеля?» звучит примерно как «а у Вас в Америке негров линчуют».
Ни в коем случае не хочу упрекнуть вас в троллинге, просто занятное наблюдение.
Мне действительно интересен личный опыт.
Тем более, что на волне "serverless" движения (AWS Lambda), я, например, ожидал всплеска интереса к этому языку, теоретически идеально подходящему.
На деле же слышу все реже. У меня есть мнение, почему так получается, конечно. Как раз по "инженерским" причинам — сложность с образованием и нехватка практических инструментов для конкретного окружения. Часто приходится повторять, что выигрывают не языки, а платформы.
Это касается и остальных функциональных языков (OCaml, Scheme (бывшее секретное оружие Пол Грэхэма)) и нефункциональных (Eiffel, Smalltalk, Forth и т.п.) в большей или меньшей степени.
Вот даже Rust, который я бы с удовольствием использовал — инфраструктурно для серверной разработки пока еще не совсем дозрел.
Кроме серверов и лямбды, есть очень много областей, где применяется программирование.
Может дело в простоте? Ни один из перечисленных языков вряд ли можно назвать простым. В отличие от js, python, php, c, java, которые и правят бал.
Да, императивные языки, кроме того, что чаще преподаются — действительно легче объяснить начинающему: "командуй компьютеру".
Хотя Logo Сеймура Папперта функциональный, или SmallTalk, который Алан Кей и товарищи писали изначально, как язык для детской компьютерной грамотности. Дети прекрасно понимали парадигму, там такие же команды-сообщения, только все более компактно. Он простой, но инфраструктура так и не пошла в народ. Как платформа он проиграл и не уверен, что активно используется для обучения.
Т.е. еще должно быть просто сделать большие и практичные вещи, чтобы внимание к нему было оправдано.
Так почему бы не давать в ВУЗе языки не исходя из странной концепции "будем давать то, что лучше иллюстрирует парадигму", а "надо дать опыт 4 и более востребованных на рынке языков, и на них показать различные парадигмы"?
Наши, к сожалению, именно таковы.
Пару лет назад очень впечатлило с какой скоростью Стенфорд создал и ввел CS231* (deep learning).
Вот на предыдущий вопрос уже замечательно ответили (у преподавателей не хватит ресурсов гнаться за fancy skills, которые к моменту окончания с большой вероятностью утратят актульность).
А по поводу курса — deep learning это, все-таки, больше самодостаточный научный метод в рамках дисциплины, чем навык. Вот использование TensorFlow (навык) преподавать отдельно не будут — максимум использовать как инструмент для лабораторных.
"Зарубежный" от "нашего" подхода также отличается гораздо бОльшим акцентом на самостоятельных работах, в добавок к произвольному набору необязательных предметов. Самостоятельная работа — свобода в полировке навыков.
Дают обзор инструментов, после на лекции подробно разбирается как работает tensor flow (8я лекция), далее есть tutorial и после лабораторные уже идут с новым инструментом.
В итоге студент знаком с ценным для рынка инструментом.
А вот про то, что подобные навыки "которые к моменту окончания с большой вероятностью утратят актульность" я сомневаюсь. Есть примеры, показывающие истинность высказывания?
Ну с языками тоже не все так плохо — в основном дают Java, C и Python. С GoLang или Kotlin — будут, возможно, когда те устаканятся и удержатся в мейнстриме лет 10.
Я все время говорю про навыки. Пример — NodeJS уже не так интересен, как был 4 года назад (вижу по вакансиям, снова). Даже для лабораторных. Проект восьмимесячной давности, который попытался поднять на днях, ругнулся. Bower сообщил, что он больше не работает и предложил освоить новые навыки (не совсем, конечно, но по сути).
Во-вторых, «простота» их обманчива, она не соответствует уровню сложности задач, поэтому и получает убогий результат, см. теорему необходимого разнообразия.
Не очень понял сути вашего замечания. Про каждый python, go есть достаточно материалов с опытом преподавания их, как первых языков.
Ну и да, go именно простой. В общем-то он дальний родственник pascal.
Что касается serverless, то, по крайней мере у AWS, он сделан так себе. Поддерживается небольшое количество языков, и все из них плохо поддерживают ФП. Долгий холодный старт, особенно у больших программ для JVM. Для функциональных языков, транслирующихся в джаваскрипт (в частности Purescript) нет биндингов к AWS. Так что к функциональщине там имеет отношение только название, а для пробуждения интереса этого мало.
В OS Касперского значительная часть кода генерируется из Haskell с помощью библиотеки Ivory.
Есть успешный RSS-агрегатор, написанный на Haskell.
Спасибо! Что-то я многие комментарии поздно замечаю ))
По поводу OS Касперского — тут рядом, как раз, писал разработчик и один из основателей сообщества ruhaskell.org, интересный опыт, DSL на Haskell для трансляции в C.
Во-вторых, отрасль бурно росла и привлекала людей с непрофильным образованием, вполне вероятно что рост уже закончился или близок к этому, перекос зарплат исчезнет и ситуация начнёт выравниваться.
В-третьих, есть проблема с образованием, даже те кто учился на айтишника мало чего понимают, но я надеюсь это проблема только отсталых, типа exUSSR, стран.
Во-первых, хорошо бы придумать метрики этого уровня инженерной культуры, иначе нельзя утверждать что что-то там снижается.
Серьезно?! Этому понятию — «сто лет в обед»… что конкретно вы предлагаете «придумать»?
Во-вторых, отрасль бурно росла и привлекала людей с непрофильным образованием, вполне вероятно что рост уже закончился или близок к этому, перекос зарплат исчезнет и ситуация начнёт выравниваться.
Не начнет… ибо причины этого совсем не в этом.
В-третьих, есть проблема с образованием, даже те кто учился на айтишника мало чего понимают, но я надеюсь это проблема только отсталых, типа exUSSR, стран.
Поскольку в «exUSSR» все это началось сильно позже, то, соответственно, на данный момент, в «exUSSR» с этим как раз лучше, чем «в среднем, по больнице» :-)
или озвучить то что вы подразумеваете под этим понятием
или озвучить то что вы подразумеваете под этим понятием
?! Я правильно понял, что вы предложили «придумать метрики» для того, что даже не понимаете?
Ок… поясняю.
Во-первых, речь идет о том, что называется инженерия (engineering). Или — если применительно к разработке ПО — программной инженерии (software engineering). Это даже из названия должно было бы быть ясно.
Во-вторых, инженерная культура — это культура не в, скажем так, филосовско-обобщенном смысле, а в конкретно-практическом — как уровень владения чем-либо. Т.е. инженерная культура — это уровень владения инженерией… в частности, например, насколько широко используются инженерные методы при решении тех, или иных задач.
Так вот, низкий уровень инженерной культуры в разработке ПО означает, что инженерные методы — в разработке ПО — если и используются осознано (это важно, чтоб *осознано*), то весьма ограничено. Что, в свою очередь, означает, что разработка ПО — чем дальше, тем все больше — перестает быть инженерной дисциплиной. Вот и все. И тех, кто «в теме», это немножко напрягает…
каких конкретно инженерных методов стали применять меньше и каким образом вы получили эту оценку?
Я, наверное, как-то не так объясняю… Но, проблема не в том, что их стали применять меньше. Проблема в том, что их перестали применять вообще. Т.е. реальность такова, что, на данный момент, широко используемые методологии разработки ПО не подразумевают *осознанного* использования инженерных методов. Вообще никаких.
Если вы считаете иначе, то тогда вас не должно затруднить назвать хотя бы одну методологию разработки ПО, в которая постулирует обратный подход.
А потом мы с вами обсудим, насколько широко она распространена в данный момент.
и не нужно на меня перекладывать бремя доказательства, вы сделали утверждение «уровень инженерной культуры снижается в разработке ПО вообще» вам его и обосновывать
Вообще-то, я на ваш вопрос ответил. Повторюсь, лично мне, не известно ни одной современной методологии разработки ПО, которая бы была построена «вокруг» инженерных методов. Т.е. — насколько мне известно — все современные методологии не предполагают и использования инженерных методов вообще. Они все про что угодно, но не про инженерию. Что, впрочем, вполне логично :-)
Но, если вы не знакомы с термином «инженерный метод», то вы лучше так и скажите. Я тогда вам «на пальцах» попытаюсь объяснить :-)
Хотя… Возьмем, например, разбиение (сиречь, декомпозицию). Один из основных и простых инженерных методов. Можно даже сказать — базовый. Много вы знаете современных методологий «заточенных» на проведение грамотной декомпозиции? Да ни одной нет. Более того, не все из них даже предполагают, что есть хоть какая-то? :-) При этом, я сильно сомневаюсь, что хоть кто-то (вы, например) будет спорить с тем, что грамотная декомпозиция — это таки важно.
Вопрос скорее в другом — как оценить степень применения этих методов тогда и сейчас, то что умные дяди что-то изобретали не означает, что это применяли или правильно применяли.
ООП и сейчас в ВУЗах есть, да только есть ли кто-нибудь среди выпускников кто понимает как правильно применять ООП или это просто карго-культ и больше проблем от такого применения?
Строгих методологий тут не было и нет ...
Это вы просто, как обычно, не в курсе.
… есть идеи, и достаточно современная, и на мой взгляд наиболее здравая идея, это плясать при декомпозиции от предметной области — DDD, ну и всякие DRY и SOLID никуда не делись ...
То, что эти «идеи» — это не методология, обсуждать не вижу смысла. Если вы «топите» за то, что методология — это лишнее, то дальнейшее обсуждение предлагаю прекратить.
Но, обращаю ваше внимание, что даже DDD — если и касается декомпозиции, то только в части отнологии. Что — вообще говоря — к инженерии имеет весьма опосредованное отношение.
..., они тоже влияют на то как делается декомпозиция
Декомпозиция — как инженерный метод — «делается» всегда одинаково :-)
..., плюс критерии сложности аля цикломатическая сложность.
Это-то тут каким боком?!
Вопрос скорее в другом — как оценить степень применения этих методов тогда и сейчас, то что умные дяди что-то изобретали не означает, что это применяли или правильно применяли.
Очень просто… найти и вникнуть в соответствующие *методологии*
ООП и сейчас в ВУЗах есть, да только есть ли кто-нибудь среди выпускников кто понимает как правильно применять ООП или это просто карго-культ и больше проблем от такого применения?
Какое отношение это имеет к обсуждаемому вопросу?
Знающий человек так не делает, тот кто знает давно уже бы перешел бы к конкретным методологиям, охарактеризовал бы их и дал ссылки.
видимо что-то оказалось не так с этим супер-пупер методологиями древних
Теперь вам осталось выяснить, что же «не так» с этими методологиями :-)
Просто — на всякий случай — и SADT, и IDEF (а не IDEF0, которая лишь часть) — примеры «строгих методологий», которых — по вашему мнению — «не было».
Не уследил, как дискуссия перешла от метрик к методологиям, но SADT (он же IDEF0) — очень помогал описывать системы за счет рекурсивных схем процессных потоков, в которых есть несколько ограничений — каждый процесс получает на вход результат другого (слева); каждый процесс имеет, соответственно, результат (справа); для каждого процесса есть стороны "надзорно-контрольная" (сверху) и "исполнительная" (снизу).
Entity Relationship (ER) диаграмы (принято позже в IDEF1X) замечательно помогали при определении схемы баз данных. В таком продукте, как ERWin, например, отрисовывалась логическая схема, на ее основе — физическая, описывались макросы триггеров (для контроля целостности в основном) и потом все это экспортировалось в рабочий скрипт для конкретного вида РСУБД. Очень сильно помогало поддерживать порядок, реально.
Я так понимаю, LogicWorks продалась (застал еще Platinum Technology), и продукты, в итоге, разошлись по кускам BPWin в IBM, а ERWin — в CA.
А «строгость» заключается именно в требовании таки провести декомпозицию (и не одну).
По метрикам, действительно, очень много работ. Тот же Макконел и товарищи, например. Подозреваю, что в таких профессиях, как наша, где учиться нужно ежедневно и всю жизнь — профильность первичного образования уже давно не является главным фактором успеха.
А по поводу exUSSR и сложности научного подхода — я, например, в какой-то степени, стал программистом благодаря усилиям академика Ершова (одного из учителей автора, кстати). Вот пример характерной презентации тех, кто нес факел "в древних веках" http://ershov.iis.nsk.su/ru/second_literacy/article
Если вы понимаете, что такое цикломатическая сложность софта и можете ее измерить — это признак Вашей высокой инженерной культуры, конечно же. И таких метрик много. Измерить культуру вообще — не знаю. Но если есть феномен — то как-то его влияние, наверняка измеряется, но, скорее всего — только эмпирически. По удельному проценту или абсолютным масштабам аварий, к примеру. ;)
Вот, кстати, рядом пример информации из исследований, которая может пригодиться инженеру.
По поводу же системной инженерии и почему она проигрывает как дисциплина (если есть такая дисциплина, вообще) — я там ниже вижу замечательный и дельный комментарий, попробую ответить позже.
что за супер магия древних забыта в веках?У древних тоже было не всё хорошо (человеческие жертв
когда-то читал оценку что разработка софта для НАСА в 170 раз дороже обычной коммерческой разработки.Так они даже модел-чекинг применяют, когда другие даже статическим анализом брезгуют.
Спасибо! По поводу алармизма и стиля подачи — отчасти соглашусь, статья из научного блога, для определенной аудитории, возможно не стоило выносить сюда, но обещаю еще несколько раз попробовать ;) Замечу только, что улучшение существующих языков за последние 20 лет — прямое следствие именно такого алармизма и именно таких (действующих) людей:
Лучшие идеи теории SE либо уже воплощены в существующих языках (они заставляют даже новичков писать лучше, чем 20 лет назад), либо объективно сложны для среднего специалиста
Все ли? По поводу сложности — понимаю, мало кому интересен rocket science, средний программист, в отличие от других видов инженеров, в допуске не нуждается так как вряд-ли себя убъет. Как Вы думаете, учитывая, как много взломов с кражей личных данных, например, сейчас происходит (equifax — хороший пример) — будет ли расти давление на средних специалистов, или это как раз тот случай, где принципиально поменять ситуацию не получится?
конкретный сотрудник оказался недостаточно внимательным (допустил баг), а другой достаточно ленивым или недостаточно компетентным для работы по приёмке качества
Мне кажется, что статья именно об этом трюизме. Продолжая ход Вашей мысли — за все эти годы компетентного приемщика качества возле ракеты так и не появилось, что, конечно, не правда с самого начала (уверен, что даже самый первый из них был компетентнее нас двоих вместе взятых). Автор имеет отношение к нашей науке, кстати, за ракету, уверен, тоже переживает, и понимает, что в сложных системах от ошибок не уйти. Но показательно то, что эта связка проверялась не только специалистами, но и огромным количеством запусков. После десятилетий эксплуатации — можно ли считать ракету доказуемо надежной?
улучшение существующих языков за последние 20 лет — прямое следствие именно такого алармизма и именно таких (действующих) людей
Думаю, что причины не только в этом, но и не без того. Впрочем, мы тут обсуждаем конкретный текст, а не то, как взгляды автора помогли ему в его работе :)
будет ли расти давление на средних специалистов, или это как раз тот случай, где принципиально поменять ситуацию не получится
Может, я сейчас слишком копну, ну да ладно. Вот есть «дискурс первого уровня». Броуди в «Thinking Forth» пишет, что паттерны проектирования нужны прежде всего для того, чтобы биться с проблемами, вызванными самими (плохими) языками программирования. Дейкстра очень прохладно отзывается о software engineering. Он-то считал, что если нормально доказывать корректность алгоритмов, то всё и будет работать (справедливости ради, он по факту критикует отдельные части SE, а не всё подряд).
Сообщество Мейера делает переход на следующий уровень: да, нереалистично надеяться на то, что у нас будут идеальные языки и все будут математически доказывать корректность, но давайте хотя бы разработаем разумную методику процесса.
Это справедливо (как и ремарки Дейкстры), но давайте перейдём к третьему уровню. Если совсем упростить, можно почти всё свести к экономической целесообразности. Хорошо обученный специалист затратил долгие годы на своё образование и стоит достаточно дорого. Проектирование и поддержка качественной системы тоже стоит денег (да, считается, что это окупается, но гарантий нет), при этом цена ошибки далеко не всегда измеряется миллионами. Вот мы и подсчитываем, стоит оно того или нет.
Я думаю, что качество (в широких массах) двигается за счёт качественных компонентов, которые достаются дёшево. Например, вас беспокоит сохранность данных при передаче. Ну окей, переходим на HTTPS — благо есть готовые библиотеки, разбираться с протоколом не нужно. Или хотим мы создать качественный 3D мир. Прекрасно, берём Unity, там уже всё есть. То есть я в целом хочу сказать, что методика нужна, но надеяться на повсеместное применение лучших практик невозможно, потому что это отнюдь не даром достаётся.
Спасибо, подпишусь под каждым словом!
С экономикой — тоже абсолютно согласен. Грубо говоря — много слесарей, мало инженеров. Но у последних рычаг длиннее.
Есть, правда, одна особенность, не очень существенная для нашей дискуссии, но в какой-то мере к ней относящаяся. Буква Т в ИТ (пока) толкает третий уровень постоянно и с возрастающим, рывками, ускорением. Я несколько раз наблюдал, как выбрасывало целые поколения специалистов.
Как потерялись работники ВЦ (соотношение женщин и мужчин в профессии, кстати, в те инженерные времена четких ролей, было гораздо более ровное). Но это понятно, изменения были драматическими.
Как вынесло другую прослойку, ребят (моих ровесников) пишуших под DOS по отдельной программе для каждого конкретного заказчика. И, чего многие не понимают, виной тому был банальный Excel, а не только и не столько наивность или глупость начинающих программистов.
Я вижу, как все это смягчается, на поднимающемся тренде. Забудем про крах доткома и жуткие истории потерянных спецов на рынке, который за год до этого требовал невероятной по тем временам цифры в несколько десятков (или сотен, не помню) тысяч новых специалистов в год — тогда сдуло, как раз, по экономическим причинам, хотя большинство так и не вернулось. Но вот вакансий "верстальщик HTML", например, буквально за несколько последних лет тоже практически не стало.
В общем, я уверен, что нынешних "ремесленников" тоже смахнет в вероятном ближайшем и вижу, что их вклад не так велик, если умножить на срок приложения сил и будет уменьшаться дальше, превращая, благодаря достижениям инженеров, в продвинутых пользователей. Как Вы думаете, мне это кажется напрасно, или асбтрактный рынок тоже это скоро заметит?
Мне кажется, я это много раз слышал в сообществе вокруг Oberon. При всем уважении, но пока наблюдаются противоположные процессы и скорее важен не абсолютный вклад в абстрактное нечто, но способность найти подходящий набор инструментов к задаче и шустро, в несколько итераций его освоить.
Да, асболютно согласен и уверен, что рынок и дальше будет отдавать предпочтение эволюции снизу (преемственность, основанная на опыте).
Я не утверждаю, что ремесленники не будут нужны, скорее наоборот — пока отрасль расширяется, число специалистов будет расти.
Но, в то же время, текущее положение — всегда точка встречи и влияния двух векторов — один подход, условно говоря, практический, а другой — научный. По обоим этим направлениям силы прикладываются не случайно, а в попытках эту "телегу" подтянуть куда "нужнее".
И если кто-то хочет удержаться на такой платформе — то должен обращать внимание на ускорения, придаваемые с обеих сторон (потому пляшут и величина и направления вектора). Чтобы удерживать в руках быстро меняющиеся актуальные навыки — нужна не только сила и реакция, но и умение различать законы, по которым они развиваются.
Один из преподавателей сокрушался, показывая на меня: "сейчас молодежь интересуют приложения, а не алгоритмы". С тех пор порог вхождения в "продуктовую" область все время продолжал уменьшаться, что замечательно.
Но, снова, единственное, что я хотел сказать — видимое расширение и "очеловечивание" отрасли не должно обманывать вновь прибывающих специалистов, процент ротации все еще высок. Рынок будет продолжать отсеивать. Вопрос — добавятся ли критерии, кроме очевидных требований "опыт разработки на Go от шести лет"
И сейчас часто бывают критерии о знании алгоритмов и на собеседовании их проверяют частенько. Даже мода на это есть.
Но по мне это самые ужасные команды в итоге, которым приходится отказывать, как правило. Во-первых, не знаю как, но наши ВУЗы часто взращивают надменность в людях и отношение свысока. Есть мы, наука, люди знающие, и прочий временный люд. И собеседования выглядят соответствующе.
Требования должны быть под задачи. Не более и не менее. Отсева спецов нигде не наблюдаю, есть только расслоение по рынкам.
Я много общаюсь с представителями очень разных стран. Боюсь, что высокомерие (и нетерпимость) взращивают не только институты, надеюсь, что это временный культурный феномен, но в больших многонациональных группах (не программистов) он, к сожалению, бывает заметен.
Отсева спецов нигде не наблюдаю, есть только расслоение по рынкам.
Это замечательно. Говорит и о том, что, скорее всего, и Вы находитесь в правильной среде, и всякие ИИ и пр. не вытесняют, пока, среднего уровня специалистов.
«Программирование сегодня больше напоминает науку: вы берете часть библиотеки и «тыкаете» в нее — смотрите на то, что она делает. Затем вы спрашиваете себя, «Могу ли я настроить это так, чтобы оно делало то, что мне нужно?». Подход «анализ через синтез», используемый в SICP, когда вы строите большую систему из простых, маленьких частей, стал неактуальным. Сегодня мы программируем «методом тыка».
То есть дело не только в том, что в 2000-м году резко потребовались верстальщики HTML, а в 2015-м — писатели на Angular, и рынку приходится иметь дело с существующими людьми, какими бы они ни были, но и в более серьёзных изменениях.
Скажем, что классические методики SE говорят о ситуациях такого вида:
— Мне нужно использовать библиотеку, в которой есть заведомый баг, но варианта не использовать её у меня нет?
— Мне нужно использовать библиотеку, чья структура плохо совместима с архитектурой моей системы?
— Две библиотеки предоставляют массу дублирующегося, плохо документированного или просто legacy в худшем смысле слова кода?
Я могу придумать массу таких вот вопросов, которыми в науке мало кто задаётся, потому что это скучно и на премию Тьюринга не потянет.
Спасибо за ссылку. Про замену SICP курсом Питона читал, но этот комментарий Сассмана не видел.
Как я понял смысл — бывший лабораторный эксперимент вышел из под контроля и начал жить и развиваться по собственным эволюционным законам, требуя для изучения каждого отдельного феномена научно-экспериментального исследовательского подхода.
Т.е. роль утеряна и будет сведена, в лучшем случае, к общим инструкциям по проведению безопасных экспериментов? Хотя и тут вполне хватает тех же методик от итеративного подхода, а в качестве экономической стратегии — MVP, быстрая смерть, быстрый рост и быстрое перерождение.
Такие понятия, как рефаторинг кода (кстати, это относилось к SE?), в виду короткой жизни продуктов, больше не нужны. Борьба с болезнями и метастазами будет решаться эволюцией, которая не нуждается в контролировании, так?
Вопросы к SE хорошие, но для ответа на них хватит и простого здравого смысла, без формальных доказательств.
Спасибо!
но давайте перейдём к третьему уровню. Если совсем упростить, можно почти всё свести к экономической целесообразности.В капиталистическом мире с этого уровня и не уходили никогда ("… при 100% он попирает все человеческие законы..."): те же автомобилестроители сравнивают стоимость исправления опасных ошибок в конструкции с предполагаемыми суммами выплат за погибших, если не исправлять.
Даже когда программное обеспечение приводит к катастрофам, мы видим заголовки день-два и потом ничего. Радио тишина.
По моим наблюдениям, это справедливо практически для любых катастроф, а не только вызванных программным обеспечением. Уж не знаю, к счастью или к сожалению, но люди по своей природе не хотят зацикливаться на негативных новостях, и подсознательно пытаются абстрагироваться от них, если события не связаны с ними или их близкими.
Просто когда низкоквалифицированный программист сливает персоональные данные полмиллиона человек, правящие структуры не знают, какой закон можно обосновать этим инцидентом.
Добавлю, что тут речь именно и, скорее всего, о профессиональном сообществе. Т.е. тишина не в разговорах на улице (кстати, я помню день, когда впервые услышал новость, касающуюся ИТ по местному телевидению, т.е. когда заметили нас, компьютерщиков. Она была о деньгах, конечно) и речь не об обычных людях, а о тех, кто может и должен решать.
Немного пофорсить тему могут провластные структуры, но даже они сдуваются достаточно быстро.
africaunite — по заголовкам о внутренней кухне судить сложно, это ДСП-документы надо смотреть.
Да, о внутренней сложно, но думаю, все-таки, что под публичной ревизией (см. продолжение цитаты), автор понимает как-минимум обсуждение сообществом. Тут вот даже простой эксперимент — вынести обсуждение из узкого круга читателей CACM на все еще профессиональный хабр — показывает, что пора надевать пальто и каску, а не просто шляпу.
Я до тошноты спорил, включая четыре раза в этом блоге (теперь пять), о необходимости простого правила, которое требовало бы публичной ревизии каждого такого события; цитируя самого себя: авиаперевозки становятся безопаснее не случайно, а из-за несчастных случаев.
а потом даже опровержения неверной информации нет. Журналист задачу выполнил — заходы/продажи поднял, а даже соответствие действительности никого не волнует.
Опровержение обязательно будет, если оно кому-то выгодно и выполнит ту же задачу, а именно привлечёт интерес и поднимет заходы/продажи :)
А в целом, вы правы, конечно. Печально, что по факту нет никакой ответственности за враньё в СМИ или публичных заявлениях.
Очень понятный текст. Заслуженный товарищ год из года видит беду и ее усугубление, но не видит решения. От того и кричит.
До дня, пока введение лучших методологий разработки ПО не перевесит у бизнеса "прибыль сейчас — возможная реализация рисков потом" ничего не будет изменено.
То же кричат специалисты по информационной безопасности: классические уязвимости давно известны, равно, как и способы их предотвращения, но он этого они не перестают занимать весь top10 уязвимостей.
Бизнес — это люди. И даже если случится беда или ЧП, то можно сделать крайним того, кто написал код. Так во всем мире. VP отмажут, а Варю/Карла/Смита наоборот.
Можно ли что-то поменять? Не думаю, да и зачем? SE росла тогда, когда на софт был заказ у очень больших ребят и правительств. Был заказ — был товар в виде спецов. Вполне может быть, что те 3-6% найма в SE, о которых сокрушается автор, в абсолютных значениях такие же, что были в 70-80е. Просто вырос больший рынок и доля уменьшилась тех дел, где SE полезно бизнесу. Довольно цинично, понимаю.
Ребята из ML создают новые продукты, которые можно продать. А что создаёт SE? Уменьшение рисков? Я обеими руками За! Но зачем это конкретным людям в бизнесе? Тот же VP отработает от 1 до 3 лет и свалит в лучшее место. Ему важнее больше плюшек с новых продуктов заиметь, чем предприятие и продукт обезопасить в будущем. У него и kpi(okr) про это.
Безопасность и надёжность — это теперь вотчина PR. Об этом надо говорить, но не делать.
Хороший анализ. А как Вы считаете, можно ли рекламу ПИ формировать не только образами катастроф? Я понимаю, что для этого у бизнеса нет времени, интереса и средств, соответственно.
Но вот тот же Rust или TypeScript, как конкурентные преимущества их создателей?
Может ли получиться продвигать ПИ не вопреки авось (не перебьешь), а как заботу об эффективности труда?
Хотя понятно, что продаются навыки, а не знания, но есть ли вариант переместить те же понятия аспектного программирования, или BDD в ранг навыков и сделать их модными?
Может ли получиться продвигать ПИ не вопреки авось (не перебьешь), а как заботу об эффективности труда?
Тут есть вопрос, а это истинное утверждение вообще?
Или имеет место быть, что SE дает эффективность труда в определенных предприятиях, определенных проектов?
У меня тут, быть может, несколько предвзятое мнение, поскольку много доводилось иметь дело с людьми из Oberon тусовки и проектов, которые всеми руками за доказательность верности программы и прочая и прочая. Однако же взлет языков программирования, которые дают большие гарантии программистам, был быстрым и недолгим. Это все еще тот старый-старый спор между европейский и американской школ: должен ли программист подстраиваться под бизнес, или он должен объяснять бизнесу, как правильно пользоваться поставляемыми им инструментами.
Для меня ответ очевиден: «no free lunch». На мой взгляд, это должно быть краеугольным камнем SE.
Мы не можем утвердать, что подходы «безопасные» подходы работают хорошо и, что нет или ничтожно мало количество случаев, когда эти подходы будут работать хуже некуда.
На мой взгляд, мало учить SE, надо учить и продуктовой разработке, надо учить и основам предпринимательства, чтобы можно было выбирать подходящие инструменты из подходящих подходов.
Зачем нужно увеличивать время на разработку более надежного софта в 2-3 раза, усложнять процесс найма сотрудников, обучения и будущей поддержки (плюс риски, что выбранный новый и «надежный» язык умрет, в отличие от какого-либо старого и «ненадежного»), если бизнес рискует небольшими убытками в случае ошибки?
На мой взгляд, поменять положение вещей можно принципеально, если наши (буду говорить о нашем образовании) ВУЗы начнут учить программировать. Сейчас студент или выпускник учится программировать не в ВУЗе, а там, где придется, или где приткнется. Как правило, это так себе опыт и навыки, которые во многом определят будущие навыки. Стоит учить делать и доводить проекты до финала в составе небольших рабочих групп прямо в ВУЗе. Народ и первые шишки набьет и можно будет показать, как избегать ошибок более умными подходами и проектированием. Будут выходить из ВУЗов способные к работе программисты, умеющие и любящие хорошие практики, будут эти ребята и девчонки со временем новым поколением CTO, CEO, VP. Тогда можно будет говорить о шансах, что что-то поменяется.
Сделаю два признания.
Во-первых, это отличный комментарий. Настолько, что я даже решил не отвечать на ходу. И именно ради такого рода ответов, позволяющих подумать (а не спешить перекрикнуть анонимов своим Я, успев заметить во всей простыне только заголовок), перевод всей и каждой статьи и делается. Правда я сейчас тут сам издалека начну, так что может показаться, что к Вашему комментарию мой отношения не имеет ;)
Второе — в оригинальном черновике перевода, зная, как тяжело на нашем читаются привычные для английского уха повторы слов и личных местоимений (а в популярных статьях еще любят писать как герой выглядит и что он ест), термин Software engineering выражался тремя или четырьмя вариантами фраз. Т.е. там были и "проектирование (engineering) программного обеспечения" и "инженерия ПО", а местами даже "разработка ПО". Профессор Мейер (невероятнейший человек) меня поправил и посоветовал везде придерживаться оригинала и использовать стандартный термин "программная инженерия". Текст от этого, само-собой, стал выглядеть менее русским и гладким, но за совет я был благодарен. И только к утру (спасибо комментаторам, в том числе) понял настоящую ценность такой правки. Я понял, что статья, действительно, именно об отрасли "программная инженерия".
Честно говоря, я совсем забыл, как и что это было. Как сам же доказывал, лет 15 назад, что программирование — это инженерная (в сельскохозяйственном роде) профессия, а не чистое творчество (до сих пор так считаю, видимо из-за увлечений и образования). Забыл потому, что тогда, в конце 90-х, начале 2000-х, последний всплеск закончился почти полной и заслуженной победной песней "манифестов" (К. Бека, прагматиков и т.п.). Заслуженной потому, что вариант с "зарегулированием", за который зацепились гранды от методологии, был, кроме того, что очень скучным, так еще и несвоевременным — задачи росли, дисциплин и практик явно все еще не хватало и лишняя пачка бумаг, пусть и хорошо структурированных, типа SWEBoK, казалась издевательством. Так оно и вышло. Если всякие ITIL и PMBoK, все-таки, местами, прижились, а отраслевые гиганты смогли еще в 90-х закрепиться на сертификации (CСNA/CCNP/CNIE от Cisco, MCP/MCSE/* от Microsoft, от Novell, Oracle и т.п.), то SWEBoK, похоже, благополучно забыт.
Парадокс в том, что рынок не убить, его надо заполнять и методологи ринулись раздувать книжные сценарии теперь уже на основе победившего craftsmansip подхода. И тут я совершенно согласен с автором — качество упало. Хотя, еще раз, я уверен, что как бы это не подавалось — программист-прагматик = программист-инженер.
Ох. Стоп. Еще раз — согласен с каждым Вашим доводом.
Но вот вопрос — не кажется ли Вам, что, как и говорится в статье, SE бородатых авторитетов с европейскими акцентами прошло? Я правильно понимаю, что пора пройти и эре "возврата в средневековье" и теперь, наоборот, самое время вернуться к правильному пониманию инженерии? Может быть статья об этом?
Как я понимаю, профессор Мейер из университета Цюриха, как и Никалаус Вирт по сей день.
Мне кажется, что это сильно добавляет контекста для статьи. И, возможно, стоило бы осветить тот старый спор европейской и американской школ. Вы, как я понимаю, застали его. Я о нем знаю только потому, что интересовался.
Вы говорите важные вещи, которые стоит знать программистам, вы говорите о изрядно забытой SE.
Но мне трудно понять вас, когда вы говорите о качестве ПО. "Оно упало" — звучит так, словно качество есть нечто абсолютное, а не нечто понимаемое и измеряемое только в контексте задачи. Еще раз повторюсь, что есть "no free lunch theorem" и любой предложенный прекрасный подход к разработке ПО будет ужасен в определенном наборе случаев. Даже не "не очень подходящ", а плох, нерабочим.
И я бы предложил остановиться тут подробнее. Если мы утверждаем, что SE, служит повышению качества софта (что может обсуждаться), то мы должны не идти в рассуждении далее, пока не определим понятия "качества", а затем "качества ПО". Иначе наши выводы по меньшей мере сомнительны.
Это первый важный момент, на мой взгляд.
Второй, о европейской школе. Для меня их время не прошло, а труды изрядно недооценены. Из-за этого часто разработчики как калеки: заставить код работать могут, но если возникнет отдельная задача о "качестве", то инструментов и понимания нам не хватает.
И ремарка: я в дискуссии участвую, как "любитель", поскольку профильного образования не имею, хотя и все годы от совершеннолетия работую разработчиком или руководителем разработки. Так что я могу быть предвзят про наши ВУЗы :)
Нет, не застал и уверен, что Вы находитесь в теме гораздо глубже, чем я.
В спор между CS и SE я, кстати, не верю (потому что сами термины недопонимаю, скорее всего), но верю в то, что научно-обоснованный (инженерный?) подход игнорировать и задвигать нельзя.
Я не говорил, что упало качество ПО. И размер и качество (первое без второго невозможно) растут. Я говорил, что упало качество аргументации. Что с переходом популярности от инженеров к евангелистам, теряется информация о том, как пришли к конкретной методике с инженерной точки зрения. А она изначально была, все вновь открытые волшебные пилюли — хорошо забытое старое, которое, к тому же, разрабатывалось и научно анализировалось.
Второй, о европейской школе. Для меня их время не прошло, а труды изрядно недооценены. Из-за этого часто разработчики как калеки: заставить код работать могут, но если возникнет отдельная задача о "качестве", то инструментов и понимания нам не хватает.
Да, и вот эта цитата также подтверждение того, что мы говорим об одном и том же.
но верю в то, что научно-обоснованный (инженерный?) подход игнорировать и задвигать нельзя.
Это верно только в отношении *производства*. «Проблема» в том, что software development — в своей массе — все сильнее дрейфует из категории *производство* (пусть и не материальное, пусть группы Б), в категорию *обслуживание*. Причем, имхо, дрейф этот отнюдь не спонтанный, а вполне осознанный (если не сказать, вынужденный).
А *обслуживание* вполне возможно без инженерии как таковой… она там скорее «мешается под ногами» и «все портит».
Может быть я не совсем верно Вас понял, но Вы имеете в виду именно создание ПО, или всю область информационных технологий?
Потому что я тоже считаю, на примере тех же электронных таблиц, что сегментирование продуктов снова будет уступать место мега-решениям и "кастомным" разработкам. Снова будет все сложнее находодить себе клиентов в рамках стандартных технологий.
Так уже было, сейчас произошел откат наверх, благодаря появлению новых платформ (а вернее — рынков), интернету, как средству доставки и, в какой-то степени — резкому удешевлению разработки (не только в денежном, но и в смысле усилий) благодаря открытому ПО. Очевидные сейчас следующие "сдвиги" — это уже не смартфоны, а IoT (которые будут завязаны на производителей и стандартные АПИ, иначе не выйдет эффекта синергии), AI (где, как раз, возможно и получится предлагать новые методологии для эффективной "настройки") и Quantum computing (который до массового специалиста дойдет не раньше, чем лет через 10-15, видимо. Причем не столько из-за доступности, но и в ожидании появления массового спроса на решения подходящих задач).
С другой стороны — бОльшая часть отрасли — всегда было обслуживанием, но мне кажется, что Вы не об этом.
С третьей — в налаживании обслуживания — методика нужна не меньше, так как само оно — деятельность процессная, и даже не проектная, а тем более — не творческая. Как пример — мой дед получил орден Ленина в начале тридцатых за создание МТС (машино-тракторных станций) в ТССР. Я к тому, что инженеры заточены на решение проблем и налаживание повторяемого процесса, в отличие от исследователей (ученых) или творцов (художников).
Речь о том, что происходит замена *продукта* (производство), пусть и не материального — *услугой* (обслуживание).
«Процесс» есть и там, и там — конечно. Но место его существенно разное.
Дело не в том, что «налаживание обслуживания» может потребовать инженеров… Дело в том, что сам (уже «налаженный») процесс «оказания услуги» инженеров уже точно не подразумевает. Что мы и наблюдаем.
Да, мы снова об одном и том же.
Я там опечатался: "и кастомным разработкам" осталось от старой фразы, ну или можно заменить на "доработкам"
Расширение области требует инженеров. Фиксация требует, чтобы инженеры занялись расширением в других областях, и, в небольших количествах, контролировали процесс на уже "завоеванных" территориях.
По поводу обучения в ВУЗах продуктовой разработке и предпринимательству — абсолютно согласен.
Более того, разбить профессию на еще большее число специализаций (в Болонской системе, впрочем, решается немного по другому), и добавить еще больше дисциплин: экономика/управление проектами/информационный дизайн/биоинформатика/ИИ/квантовые вычисления/функциональное/ООП/сети/базы данных/теория информации/алгоритмы/литературная грамотность/иностранный язык/ и т.д.
Нас, первый набор специальности АСОИиУ, от растерянности, учили как настоящих инженеров — сопромат, электротехника, начертательная геометрия и т.п. Это были именно дисциплины, а не науки. И именно они вправляли в мозг инженерную закваску — умение применять знания (науки) для решения конкретных задач.
Тут, кстати, кроется еще одна причина провала SE — неопределенность с CS. Там был конфликт, кто есть кто. Причина в том, что фундаментальных наук в Computer Science маловато, все больше прикладные отрасли знания, а они инженерные и есть.
По поводу программирования — тоже согласен. Учить трендовым языкам, кстати, может и не получится. На лабораторных и на типичных для конкретной дисциплины, если только. Но зачеты, курсовые и дипломные не по формальным задачкам, а как законченное решение конкретных задач (и научных и прикладных), защиту именно продукта, что тоже, вроде, бывает.
Еще — делать все, чтобы студентов принимали в интернатуры (на практику по старому) в настоящее производство. Потому что ни на каких занятиях невозможно научить инженера акутальным навыкам. Как не учат, например, ремонту конкретных марок двигателей инженера-механизатора.
И снова — все это уже есть. Вопрос только в качестве реализации. И я думаю, что и у нас доберется. Вот сам, например, брал работника вслепую — только узнав, что он закончил тот же американский ВУЗ, что и предыдущий сотрудник. )))
Почему думаете, что не получилось бы учить популярным языкам? Любопытно действительно.
Мне видится, что за время обучения вполне можно дать студентам боевое крещение в языках всех основных направлений: python, как удобный в разработке и с динамической типизацией да и для DS и ML на более старших курсах зайдет, golang, со строгой типизацией, но очень малым "словарем" языка и удобным набором инструментов для написания конкурентного и параллельного кода, elixir или erlang, как хорошие функциональные языки, которые на порядок проще в освоении, чем любимый многими и мной тоже haskell.
Нет-нет. Я имел в виду именно "модные" навыки (skills).
И в силу инерции (ну вот представьте, сколько времени нужно на утверждение курса по тому же Go), и, что важнее — у института должна быть задача подготовки навыка самостоятельного получения навыков (и знаний). Метрика должна быть — как быстро ученик овладевает новыми умениями, а это не поднимешь простой, но бесконечной гонкой за убегающей (в модном) мишенью.
Может быть по одному языку (в лаборатории, не на лекциях) на парадигму, самостоятельные с изучением соседей и практика на реальном производстве помогут ему окрепнуть? Но это тоже было всегда. Возможно просто нужно где-то явно указать, что, лабораторные, например, министерством не регулируются, не знаю, есть ли там на самом деле проблема.
Вот у rg_software, кстати, замечательные посты на эту тему. Ему действительно должно быть, что сказать по этому поводу.
Все же, для меня, наше невопоротливое в самой своей мути образование вызывает только тоску и желание взвыть. Со всеми этими утверждениями и прочим.
Как мы можем говорить о том, чтобы что-то внятное дать через наши ВУЗы, хотя знаем, что изменения почти нереальны. Несколько радуют только курсы от ВШЭ, которые пробуют делать, что-то современное.
Когда заинтересованные стороны начнут голосовать рублем, тогда и будут соревнования. Местами такое есть (я могу вспомнить множество ВУЗов, кроме ВШЭ), но большинство институтов готово тихо жить на дотациях и почти поголовном желании иметь хотя бы корочку (важна стандартная книжечка, а не особые знания или имя заведения).
Думаю, уже начинается. Образование, видимо, идет к 100% платности и тут уже будет вопрос, образование какой страны выбрать. Я для своих детей, коль кто решит брать то же ремесло, не думаю выбирать наши вузы, даже просто сравнивая программы и ценники.
Ну не только платность образования (в Англии, кстати, красиво сделали, через льготный долгосрочный кредит, который, если ты не согласен, что образование окупилось, можно и не возвращать (конечно так никто не делает)). Есть еще и отраслевые спонсоры-рекрутеры, можно брать на себя роль бывших НИИ, которые теперь все превратились в ООО-лендлордов, и выполнять исследования, можно коммерциализировать те же прикладные и фундаментальные открытия. Все стимулирует качество.
По поводу заграничного образования в нашем ремесле — вот один из опосредованных, но все же солидных рейтингов: https://icpc.baylor.edu/worldfinals/results
Реальность такова, что программирование/информатика не входит в обязательную школьную программу очень многих даже хороших стран. В Британии вводят вот прямо сейчас, в Японии введут с 2020го, если не ошибаюсь. Студентами становятся люди, которые не могут даже написать программу «Hello, world» на Бейсике. При этом им уже на первом-втором году обучения приходится читать достаточно нетривиальные курсы, которые требуют и соответствующего уровня от лектора. Интереса в такой работе не так много, большой процент профессуры именно преподавательскую часть откровенно не любит, и надеяться на постоянное совершенствование и шагание в ногу со временем не приходится.
Да, конечно, если человек профессионально занимается NLP или там нейросетями, он сможет провести прекрасный спецкурс по этой узкой теме, но это лишь небольшая часть общего паззла.
Пример с cs231 я привел, как способность вузов к быстрой адаптации к новым условиям.
Про то, чтобы этот или подобный курс преподавал "светило" и прочее, что вы написали, я не говорил.
Судя по эволюции курса, его начинали "светилы", но через 2 года большую часть лекций дают толковые аспиранты.
В этом смысле, если всё равно всё делают аспиранты, то разницы между Стэнфордом и Урюпинском нет, т.к. в онлайне всё равно есть лекции светил, а в реале общаться будешь в лучшем случае с аспирантами.
В любом случае обновлять и улучшать курс всё равно будет профессор (когда найдёт на это время и желание...)
Так же было и раньше, с учебниками. Поменялся просто формат подачи.
Я так понимаю, что Вы переживаете о сроках актуализации знаний. Тут согласен, но, как и говорилось с самого начала — или лектор узкий специалист, которого может позволить себе пригласить только серьезный университет, или преподаватель, который в отрыве от производства — просто не в состоянии поддерживать актуальность по всем фронтам.
Плюс, ощущение сверхоперативности появления курса ML может быть сильно обманчиво. Теме много десятков лет, первая волна возврата началась в начале 2000-х, реально горячей она стала через 10 лет — волшебное число, похоже для любого нового человеческому обществу нужно около 10 лет.
В общем, свободные лекции — это хороший вариант, в любом случае. Но я продолжаю считать, что цель образовательного института — научить учиться.
Курс про DL и конкретно для речи один курс и один для распознавания изображений. Если посмотреть содержание, то становится очевидно, что основывались на последних алгоритмах и книге Goodfellow 2017 года.
Тут лучше бы возражения фактами подкреплять.
Вообще не возражаю. Но мы говорили о конкретных навыках (языках программирования).
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.
предполагается, что для изучения научной дисциплины (наука моде подвержена меньше и знания как фундамент, а не временный слой) нужно пройти (самостоятельно) курс или знать языки
Храни нам бог от этого научиться учиться. По такой логике, сами преподаватели должны быть Мастерами в умении учиться. Но почему-то редко демонстрируют способность взять очередной актуальный навык и переводят разговор на "базис и фундамент".
Учить другого (эмпатия) и самообучение (вполне себе навык) — две разные вещи.
Никто же не требует от тренера сборной быть (в прошлом или настоящем, не важно) — лучшим спортсменом страны.
Но, снова, я согласен образование не должно быть для галочки. Институты своей деятельностью не должны заниматься для галочки. Вариантов, кроме рыночных (кстати, рыночный запрос может создать и государство, а иногда даже обязано, если умное и переживает за место под солнцем) не вижу.
Персональное разоблачение: о себе я думаю, как о том самом образце современного методиста [3], без бороды или голландского акцента, но пытающегося вынести на современную ИТ сцену факел плодотворных работ семидесятых и восьмидесятых.
Нам нужны новые идеи. Они могли бы быть еще более убедительными, если бы были направлены на решение старых и скучных проблем программной инженерии: корректность, надежность, расширяемость и возможность многократного использования.
Мой взгляд на проблему старого и нового:
не всякое новшество сразу оказывается удобным и полезным. Крупной и успешной коммерческой компании, конечно, всеми силами нужно поспевать за прогрессом, и разумные затраты на пусть пока еще не удачные, но потенциально прогрессивные решения, для такой компании жизненно необходимы.
так называемая культура общества потребления вносит заметный деструктивный вклад в сознание людей. Например, многие готовы тратить немалые деньги, меняя гаджеты хоть каждый месяц, не потому что гаджет сломался или стал неудобен, а только потому, что появилась очередная новая модель. При этом под «гаджетом» понимается всё: от автомобиля до мобильного телефона, кухонной сковородки и ПО.
По поводу первой Вашей цитаты — я публиковал пост именно как вопрос — что можно сделать, чтобы к проблемам, которые перечислил автор стали относиться серьезнее в более широком кругу специалистов. Я так понимаю, речь не о технических новшествах, а о новой попытке вернуть популярность подходам систематизации знаний/путей решения.
По поводу второго — я и сам хожу с телефоном, который мне подарили в 2008 году. Но! Вносит ли эта культура деструктивный вклад в сознание людей, или она пользуется незрелостью личности, для которой телефон может стать неудобен не только по техническим параметрам, но и по социальным понятиям? Не могу сказать, возможно, что для экономики и развития человечества это хорошо. Брать деньги у таких людей, чтобы было на что развиваться (не только гнать по наклонной). В любом случае, это отдельная тема.
я и сам хожу с телефоном, который мне подарили в 2008 году.Телефон — дело личное. А как быть с новым ( возможно, сырым) компилятором или с новой ОС? — Это проблемы серьезнее, чем смена телефона. Но, к сожалению, очень многие разницы не видят. Поэтому на вопрос:
что можно сделать, чтобы к проблемам, которые перечислил автор стали относиться серьезнее в более широком кругу специалистов
Я отвечаю: ИМХО прежде всего перестроить собственное мировосприятие, т.е. отрешиться от психологии потребления, хотя бы в проф.сфере. Почувствовать принципиальную разнницу между личным телефоном и инструментами/методами разработки ПО, Почувствовать ответственность за свой продукт. Сейчас многие крупные юр.лица предпочитают малоответственное отношение ради доп. прибыли и не только в сфере ПО, автомобили, нпр., периодически отзывают. Когда это станет невыгодно (не только по деньгам, но и в плане репутации), тогда возродится интерес к методам надежного проектирования софта.
Понял, но тут, по моему мнению, нет смысла призывать к добровольной перестройке мировосприятия. Как ни крути, но правят этим миром и кнут и пряник (пряник популярнее). Вы и сами ответили — когда это станет невыгодно. На то и надежда, хотя и тут все относительно — как пример — использовал в предыдущем проекте сырую (в промышленном смысле) графовую БД. Выбор был оправдан, так как давал реальный качественный скачок (не качественности, а именно другой уровень характеристик), но для следующей версии — пришлось бы выбирать уже более тщательно.
Но. Да. Предупреждать тех, кто не осознает компромиссов и верит слепо нужно. Хотя и бессмысленно. Но, может быть, вспомнят о теме, когда обожгутся и "дозреют".
Будем. Эффективно общественное мнение служит (культивируется) — когда бизнес (или кто там заинтересован) сам может им манипулировать как конкурентным преимуществом. Очень часто выгодополучателем и спонсируется. Надо такому субъекту дать метрики надежности (чтобы сравнивал), способы достижения (чтобы отстроился) и методы заработка (тут суть) и все будет ОК ;)
Конец программной инженерии и последний методист