Сассман назвал две причины; впрочем, сразу замечу, что в первой из них нет ничего особенного. К 1997 году Абельсон и Сассман уже устали рассказывать практически одно и то же с 80-ых, поэтому решили оставить преподавание и предложили главе кафедры самостоятельно решить, как поступить с самим курсом. Здесь удивляться действительно нечему — что угодно может осточертерть, если заниматься им достаточно долго.
Впрочем, вторая причина гораздо серьезнее. По мнению Сассмана, они с Абельсоном осознали, что учебный план SICP больше не в силах подготовить инженеров к тому, что представляет собой «инжиниринг» сегодня. В 80-ых и 90-ых инженеры строили сложные системы, комбинируя простые и хорошо изученные «части». Целью SICP было предоставить язык абстракций для рассуждений о таких системах.
Сегодня дела обстоят не так. Сейчас инженеры обычно пишут код для сложного аппаратного обеспечения, которое они не до конца понимают (причем часто это происходит по причине коммерческой тайны, а не в силу лени или недостатка времени — взять ту же Apple и ее технологии). Это же утверждение справедливо и для программного обеспечения, поскольку программные окружения состоят из гигантских библиотек с широчайшей функциональностью. Согласно Сассману, сегодня его студенты большую часть своего времени тратят на чтение мануалов к этим библиотекам, чтобы разобраться в том, как связать их вместе с простой целью — чтобы всё заработало и сделало то, что им нужно.
Со слов Сассмана, «Программирование сегодня больше напоминает науку: вы берете часть библиотеки и «тыкаете» в нее — смотрите на то, что она делает. Затем вы спрашиваете себя, «Могу ли я настроить это так, чтобы оно делало то, что мне нужно?». Подход «анализ через синтез», используемый в SICP, когда вы строите большую систему из простых, маленьких частей, стал неактуальным. Сегодня мы программируем «методом тыка».
В конце концов, в качестве альтернативы для Lisp в MIT был выбран Python. В пользу языка преподавателей склонил тот факт, что для Python доступно значительное количество библиотек, которые позволяют использовать его для решения упражнений в самых разнообразных типах проектов (например, для написания ПО для управлениям роботами).
Впрочем, сам Сассман пошутил, что использование Python было решением в духе «позднего связывания» (“late binding”) — поскольку план обучения SICP был более «последовательным» по сравнению с тем, что заняло его место. Он признался, что вместе с коллегами по прежнему не представляет себе, каким должен быть оптимальный план обучения.
Мнения насчет современного образования в целом и того, чему же все-таки должны обучаться будущие software engineer, расходятся радикально — поэтому предложить однозначный вывод из нововведения невозможно. Согласно одному из них, фундаментальной целью обучения CS является понимание того, как работают компьютеры, а не изучение конкретных языков программирования, и уж подавно — библиотек. С мнением соавтора курса Абельсона насчет конца эры SICP в MIT можно познакомиться по ссылке.
Современная экономика остро нуждается в присутствии на рынке большого количества прикладных программистов, и университеты выполняют свою обязанность в подготовке студентов к будущему. Естественно, выучить всё, особенно на старте карьеры, представляется невозможным; и в то же время, серьезное изучение CS позволяет уменьшить количество плохого кода и страданий коллег-разработчиков.
Одна из баек про MIT всегда говорила о том, что «изучение SICP и Lisp — это тот момент, когда первокурсники начинают оставлять большую часть мира позади себя по части возможности решения проблем (имеется в виду problem solving) и умению делать свою работу»; более того — многие выпускники MIT в дальнейшем как раз и занимаются тем, что пишут библиотеки сами, а не используют чьи-то еще. Думается, что невзирая на жестокие реалии бизнеса, среди нас найдутся те, кому (втайне) гораздо больше удовольствия приносит процесс обучения программированию «с нуля», эффективное использование ресурсов и построение своих велосипедов, чем ежедневные разборки с чужими API и связывание уже готовых open source компонентов в стремлении сделать то, что требуется — то самое «get work done», о котором вел речь Сассман (хотя новый подход в этом отношении действительно ближе к производственным задачам). Однако, времена, когда студентам в ходе обучения приходилось заниматься созданием компиляторов/интерпретаторов, могут отойти в прошлое быстрее, чем нам кажется.
Разумеется, все это — не повод отказываться от знакомства с SICP. По сложившейся традиции, ссылки на саму книгу и лекции прилагаются.
Комментарии (36)
mcgreedy
05.05.2016 15:14На мой, сугубо личный взгляд, следует очень сильно различать инженеров — программистов и «кодеров». Если первым поручить задачу «сделай чтоб это считало так» мы на выходе получим уйму потраченого времени, и уникальное решение которое будет решать эту задачу. Если мы попросим сделать ту же задачу «кодера» то мы получим решение этой же проблемы на основе другого решения, с меньшими затратами труда. НО если мы поручим «кодеру» написать что-то серьезное, мы получим решение быстрее, но сложнее в поддержке и, скорее всего, более уязвимое, ввиду использования большого количества разношерстных библиотек. По итогу, как сказал оратор выше. «Все профессии важны, все профессии нужны.»
sentyaev
05.05.2016 19:29+3Простите, но как вы отличаете «настоящего программиста» от кодера?
mcgreedy
06.05.2016 10:13Не стоит говорить и «инжинер» — настоящий программист а «кодер» — не программист, по тому что каждый из этих типов может является настоящим программистом, просто один склонен «изобретать велосипеды», другой «приделывать к велосипедам костыли». отличать путем общения и понимания личных предпочтений каждого в отдельности. Опять же скажу что нельзя сказать кто более важен, для процесса разработки нужны оба типа.
YChebotaev
06.05.2016 00:58Сложное в поддержке решение всегда можно отрефакторить, если это становится причиной ошибок, и получить менее сложное, а вот архитектуру, которая гнется не в тех местах и устарела морально в процессе реализации заменять придется сразу целиком.
mcgreedy
06.05.2016 10:22Вот только «отрефакторить», в некоторых случаях, означает тоже — заменять сразу целиком. Фатальные ошибки возможны при любых раскладах. Я в своей жизни видел проекты которые до сих пор отлично выполняют поставленные задачи и на fox.pro требующие минимум поддержки и никуда не годящиеся решения которые пришлось полностью менять на yii. Видел и обратное. Но это больше относится не столько к разработчикам, сколько к заказчикам и изменчивости требований к системам.
YChebotaev
07.05.2016 22:02Все равно лучше за неделю собрать из библиотек рабочее решение, а потом заменить его целиком, чем пол года разрабатывать что-то универсальное, а потом все равно его заменять целиком, потому что требования опять поменялись.
mcgreedy
08.05.2016 06:13Вот пример из жизни. Нужно было создать потенциально интересный людям сервис обработки и хранения данных, заказчик выбрал компанию которая сказала что сделает быстро и не дорого. В итоге сделала, не очень быстро, но сделала, и через 2 (два) месяца эксплуатации системы её пришлось ПОЛНОСТЬЮ переписывать, по тому что ввиду использования различных левых библиотек — оптимизация проекта была ниже плинтуса, и сервис падал от слова совсем уже при 1000 униках. Да, по итогу мы потратили не 3 месяца на разработку, а больше, зато проект не падает и стабильно развивается, доработки в рамках логики проекта не отнимают огромное количество времени на тестирование «а вдруг что отвалилось, где не ждали».
Понятно что для того чтоб написать визитку — нет смысла делать множество абстракций и каждый раз разрабатывать свою цмс, но для сложных и потенциально высоко нагруженных проектах бездумно использовать кучу чужих библиотек… это далеко не самое правильное решение.YChebotaev
08.05.2016 07:46+1Ну а чего вы вообще ожидали? В этой ситуации заказчик сделал ровно все, чтобы проект провалился. Я удивлен, что его вообще смогли закончить.
1) Никогда ничего не заказывайте на стороне. Ну просто потому что аутсорсеру вообще плевать что там будет после сдачи. Исключения можно делать только когда проект типовой, или у компании уже есть конкретные наработки.
2) Сроки, качество, цена — выбери любые два. Хотели быстро и дешево, получили соответствующее качество.
3) Технического задания, как я понимаю, тоже не было. А стоит оно также, как весь проект, и времени на его разработку нужно столько же.
4) Библиотеки помогают только если у команды есть необходимые компетенции. А если их не было, то чего вы ожидали?mcgreedy
08.05.2016 08:10Ну так, чисто для справки, проблемы решали тоже аутсорсеры :)
1) вы будете удивлены, но очень многие проекты в том числе и весьма сложные делаются или на аутсорсе, или с привлечением аутсорсеров, по тому что это правильнее, эффективнее и проще.
2) Заказчик исходил из вашего постулата, быстро собрать, а потом посмотрим.
3) Было, единственное что не было учтено — это нагрузки которые могут возниктнуть, это был стартап и было не понятно взлетит или нет.
4) Нужно понимать что, когда и как использовать. Я не говорю о том, что нужно постоянно изобретать велосипед, но и бездумно пользоваться готовыми решениями тоже не правильно.
Вообще не понимаю, почему вы считаете что заказчик сделал все чтоб проект провалился. ИМХО Заказчик сделал все вполне правильно с точки зрения бизнеса. Потратил часть ресурсов чтоб проверить насколько проект будет востребованным, когда убедился что проект будет востребован — потратил еще ресурсы чтоб сделать его эффективным. Это называется управление рисками :) Ведь проект мог и «не выстрелить»YChebotaev
08.05.2016 09:37+1Ну прямо большую тему вы подняли. Если совсем грубо, то на каждом из этапов заказчик не управлял рисками, а понадеялся на авось, мол, раз уж потеряю деньги, то хоть не очень много. И библиотеки тут вообще ни причем.
3) Вы меняете показания -) То пишете, что было настолько плохо, что пришлось ПОЛНОСТЬЮ переписать, то пишете, что все было учтено, кроме нагрузок. Ну так проблемы с нагрузкой легко лечатся — воткнул побольше памяти, еще парочку серверов, и все ок. Раз уж клиентов так много оказалось, то наверняка ручеек прибыли это должен окупить. А если нет, то тут тогда вообще не в разработке дело.
3б) А если ваша работа окупилась как раз с этой прибыли, тогда вообще не понимаю в чем проблема с библиотеками: их использование позволило вообще запустить проект в таких сложных условиях и нанять более компетентных специалистов которые перепишут все это г*но; Если все так и было, то вы только что привели просто хрестоматийный кейс, как библиотеки помогают бизнесу и почему даже их бездумное использование лучше, чем свои костыли.mcgreedy
08.05.2016 19:53Ну так тема то действительно большая и объемная.
Отнюдь, реализация не позволяла ни вменяемо масштабироваться ни держать нагрузку, но задачу свою с небольшим потоком пользователей — решала. На счет ручейка не берусь судить. Ну так я же с самого начала говорил, что прикладное программирование это НЕ ПЛОХО, просто не для всех задач подходит, как и инженерная разработка. Важно понять когда хорошо одно и когда хорошо другое. Причем, зачастую одно не исключает другого.YChebotaev
08.05.2016 23:16А библиотеки то тут причем? Да, допустили ошибки в архитектуре, не заложили масштабирование, но это претензия исключительно к квалификации конкретного исполнителя.
Инженерная разработка как раз и состоит из использования библиотек. Собственно, весь SICP как раз об этом: как правильно создавать библиотеки, чтобы их можно была переиспользовать. Просто в те времена все думали, что ничего сложного в том, чтобы разработать всю обвязку для бизнес-логики с нуля нет, и этим может заниматься тот же инженер, что и бизнес-логикой (а еще казалось, что такие библиотеки можно наследовать из проекта в проект). Практика показала, что это выходит слишком дорого и сложно, и все равно люди допускают ошибки на других уровнях, и стало понятно что использовать готовые чужие библиотеки гораздо выгоднее. Вот, собственно, и вся история.
Например, во фронтенде, в котором я работаю, доминирующая концепция — убер-модульность, когда даже для простейшего действия нужно скачать и подключить библиотеку из 10 строк кода. И ничего плохого в этом подходе нет, потому что экономит время, и позволяет избежать ошибок.
7pxl
05.05.2016 17:13-3Вот поэтому многие бегают от фреймворка к фреймворку, все свое детище хвалят и не любят другие решения. Сами же никто не пишет с нуля и не понимает базовых вещей. Поэтому мало кто пишет свои библиотеки в фреймворках, если текущая не устраивает. Просто пересаживаются на другой и переписывают код. Неосознанная некомпетентность.
YChebotaev
06.05.2016 01:03+4Вся прелесть библиотек и фреймворков в том, что их поддерживают и развивают другие люди.
ApeCoder
06.05.2016 09:02Возможно, чтобы хорошо выбрать Фреймворк надо уметь делать свой — так глубже понимаешь компромиссы и проблемы с которыми столкнутся авторы в будущем
foxmuldercp
06.05.2016 13:41Добавлю 5 копеек — пройдя путь от инженера техподдержки крупнейших украинских хостеров до хостмастера совсем небольших хостингов, перепробовав почти все современные и популярные панели управления хостингом я понял, почему каждый крупный хостер пишет свое решение.
Да, я тоже пишу свою панель управления хостингом, понимая, чем меня не устраивают те решения что тестировал, использовал или запустил в продакшен
kvasvik
06.05.2016 15:23Понять не поможет — разбираться в мегабайтах чужого кода чтобы выяснить, что они там наворотили — сомнительное удовольствие. А вот пересаживаться на чужой велосипед, после того как собрал свой, где сиденье, руль и педали идеально подогнаны под тебя, уже не захочется.
ApeCoder
06.05.2016 15:26Один из способов разобраться это представить «А как бы делал я на их месте» и проверить предположения
YChebotaev
07.05.2016 22:14Разумеется, чтобы стать хорошим специалистом просто необходимо много практиковаться и набивать шишки реализуя свои версии известных штук. Но делать это надо в свободное время в личном проекте, потому что внедрение подобного велосипеда на работе обернется издержками для компании, и выльется в сотни человеко-часов допиливаний, фиксов и поддержки. Фреймворки на то и нужны, что весь этот путь уже пройден другими людьми, а на большинство вопросов найдется ответ на стековерфлоу.
ApeCoder
07.05.2016 22:36Может не в свободное и не в личном, а например, в университете в учебном (см тему поста)
YChebotaev
08.05.2016 01:50Да, это было бы совсем классно, если бы в универе что-то подобное изучали. К сожалению, в наших вузах этого и близко не проходят.
7pxl
06.05.2016 10:38Всегда будут люди которые используют чужое и пишут свое, обе стороны правы, если интересно знать как все работает, когда любопытство спать не дает и охото понять как работает модуль в языке, то что человеку мешает sicp изучить, тем более вроде htdp дают курс еще
x2bool
05.05.2016 18:55+1Тенденция ясна. Но MIT? Неужели выпускники этого вуза не в состоянии самим научиться прикладному программированию?
recontemplator
05.05.2016 19:50+2По тексту статьи может показаться, что 6.001 (со schema) закончили преподавать совсем недавно. Однако, последний раз 6.001 читали MIT в 2007/2008м году. Уже 7 лет как вместо него читают 6.01 (c python).
Shamov
06.05.2016 15:24+1Всё-таки Гегель был прав в том, что история развивается по спирали. Старая идея Дейкстры о том, что программное обеспечение получается таким дорогим потому, что его пытаются получить при помощи дешёвого труда, сегодня актуальна как никогда. Происходит, как бы, новый виток в стремлении разрабатывать офигительно сложные системы при помощи труда вчерашних студентов. И поэтому очень хочется, чтобы студентов заранее научили не каким-то там абстракциям, а практическим навыкам использования готовых библиотек. И такой запрос со стороны работодателей рано или поздно будет удовлетворён. Теперь вот и MIT перешёл на сторону зла. К сожалению, идею Дейкстры никто всерьёз не воспринял и выводов не сделал. Поэтому в итоге то программное обеспечение, которое всё-таки удастся заставить работать приемлемо, окажется ещё более дорогим, чем когда-либо раньше.
EvRiaL
06.05.2016 23:55Конечно надо знать и уметь как можно больше, но за ограниченное время. Прогресс движется по пути усложнения, 15 лет назад не было тех веб сервисов и проблем которые есть сейчас, был веб-мастер всё в одном флаконе, теперь же full-stack девелопера найти как единорога, и есть тысячи библиотек которых раньше не было и в них надо разбираться за то же ограниченное время, потому что так работает индустрия.
Shamov
07.05.2016 10:00-1Индустрия работает не так. Так работает плесень на её поверхности, которая занимается производством никому не нужных веб-сайтов. Только у этой плесени есть проблема острой взаимной конкуренции за скромный ручеек доходов от рекламы. У тех же, кто финансируется не за счёт рекламы (т.е. производит продукт действительно нужный конечному потребителю, что тот готов подтвердить фактом оплаты), нет никаких проблем с постоянным ускорением прогресса. Этот прогресс проходит мимо них. Они делают продукт, который решает проблемы реально существующие у потребителя. И последний не закапризничает из-за того, что в продукте используются устаревшие технологии. И никуда не денется в том случае, если разработка займёт на год больше, чем планировалось… например, три года вместо двух. Когда разработка финансируется не за счёт крошек со стола онлайн-рекламы, а за счёт денег, которые потребитель платит осознанно и щедро, можно позволить себе с самого начала иметь какую-то тактику и придерживаться её в течение всего срока разработки. И даже если окажется, что решаемая задача требует использования elasticsearch, использование которого очень существенно отличается от использования традиционных баз данных, у разработчиков будет достаточно времени на то, чтобы спокойно и не спеша разобраться с этой технологической новинкой.
YChebotaev
07.05.2016 22:21+1Интернет-магазины зарабатывают не с рекламы, и у них есть крайне острая необходимость быстро и качественно внедрять новые фичи, чтобы увеличить конверсию и LTV покупателя. То же самое относится и к агрегаторам, тематическим поисковикам и SaaS-ам. Единственные ребята из веб-области, которым не нужно гнаться за скоростью и качеством внедрения новых фич — это как раз контентные сайты, которые получают доход с рекламы.
Shamov
07.05.2016 22:44-3При чём тут вообще интернет-магазины или контентные сайты? Это не часть IT-индустрии. Эти виды бизнеса зарабатывают деньги не за счёт разработки софта. Интернет-магазины — это банальная торговля. Хотя и с приёмом заказов через интернет. Сайты, производящие контент, — это часть медиаиндустрии.
Вы бы ещё РЖД или Сбербанк в IT-индустрию зачислили. Между прочим, у РЖД есть «небольшой» вычислительный центр (в Москве, на Красных воротах). Конечно, в нём работают не так много людей, как в Гугле, но я уверен, что счёт идёт на тысячи. В Сбербанке тоже есть IT-департамент, который по числу сотрудников скорее всего превышает 99% российских IT-компаний.YChebotaev
08.05.2016 11:27А что с SaaS-ами? Я волнуюсь. И еще агрегаторы забыли.
Shamov
08.05.2016 11:42Это я никак не могу прокомментировать. Ни разу не видел людей, которые бы платили за SaaS или за агрегатор. И если они финансируют свою разработку не за счёт рекламы, то скорее всего они вообще ничего не зарабатывают, а просто проедают инвестиции.
WEStor
Все профессии важны, все профессии нужны. И пока еще нужны, и те, кто пишет велосипеды сам, и те, кто на них катается. Так что каждый решает сам, писать ли ему мобильное приложение под iOS или идти придумывать Swift в Apple. И в итоге выбирает материал для изучения в зависимости от интересов и способностей.