На днях широкое внимание привлекло состоявшееся в начале года на митапе NYC Lisp выступление Джеральда Джей Сассмана, — одного из авторов великого и могучего SICP, а также крестного отца Scheme. Всему виной — ответ на вопрос, почему в MIT прекратили преподавать ставший легендарным курс 6.001, построенный на основе книги Сассмана и Абельсона «Структура и интерпретация компьютерных программ» (вопрос задан на 59 минуте).

1. Абельсон Структура И Интерпретация Компьютерных Программ
2. Абельсон И Сассман Структуры И Интерпретация Компьютерных Программ Скачать

«Структу́ра и интерпрета́ция компью́терных програ́мм» (англ. Structure and Interpretation of. Автор, Харольд Абельсон, Джеральд Сассман. Структура и интерпретация компьютерных программ. Перейти к навигации Перейти к поиску. Структура и интерпретация компьютерных программ: Structure and Interpretation of Computer Programs: Автор: Харольд Абельсон, Джеральд Сассман: Язык.

Сассман назвал две причины; впрочем, сразу замечу, что в первой из них нет ничего особенного. К 1997 году Абельсон и Сассман уже устали рассказывать практически одно и то же с 80-ых, поэтому решили оставить преподавание и предложили главе кафедры самостоятельно решить, как поступить с самим курсом. Здесь удивляться действительно нечему — что угодно может осточертерть, если заниматься им достаточно долго. Впрочем, вторая причина гораздо серьезнее. По мнению Сассмана, они с Абельсоном осознали, что учебный план SICP больше не в силах подготовить инженеров к тому, что представляет собой «инжиниринг» сегодня.

1. Купить книгу «Структура и Интерпретация Компьютерных Программ» автора Харольд Абельсон, Джеральд Джей Сассман и другие произведения в разделе Книги в интернет-магазине OZON.ru.
2. Харольд Абельсон Джеральд Джей Сассман при участии Джули Сассман Структура и интерпретация компьютерных программ Добросвет, 2006. Эта книга посвящается, с уважением и любовью, духу.

В 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.

По сложившейся традиции, ссылки на саму и прилагаются. Метки:.

Добавить метки Пометьте публикацию своими метками Метки необходимо разделять запятой. Например: php, javascript, адронный коллайдер, задача трех тел. На мой, сугубо личный взгляд, следует очень сильно различать инженеров — программистов и «кодеров».

Абельсон Структура И Интерпретация Компьютерных Программ

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

По итогу, как сказал оратор выше. «Все профессии важны, все профессии нужны.». Вот пример из жизни.

Нужно было создать потенциально интересный людям сервис обработки и хранения данных, заказчик выбрал компанию которая сказала что сделает быстро и не дорого. В итоге сделала, не очень быстро, но сделала, и через 2 (два) месяца эксплуатации системы её пришлось ПОЛНОСТЬЮ переписывать, по тому что ввиду использования различных левых библиотек — оптимизация проекта была ниже плинтуса, и сервис падал от слова совсем уже при 1000 униках.

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

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

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

Хотели быстро и дешево, получили соответствующее качество. 3) Технического задания, как я понимаю, тоже не было. А стоит оно также, как весь проект, и времени на его разработку нужно столько же.

4) Библиотеки помогают только если у команды есть необходимые компетенции. А если их не было, то чего вы ожидали?

Ну так, чисто для справки, проблемы решали тоже аутсорсеры:) 1) вы будете удивлены, но очень многие проекты в том числе и весьма сложные делаются или на аутсорсе, или с привлечением аутсорсеров, по тому что это правильнее, эффективнее и проще. 2) Заказчик исходил из вашего постулата, быстро собрать, а потом посмотрим. 3) Было, единственное что не было учтено — это нагрузки которые могут возниктнуть, это был стартап и было не понятно взлетит или нет. 4) Нужно понимать что, когда и как использовать. Я не говорю о том, что нужно постоянно изобретать велосипед, но и бездумно пользоваться готовыми решениями тоже не правильно. Вообще не понимаю, почему вы считаете что заказчик сделал все чтоб проект провалился.

ИМХО Заказчик сделал все вполне правильно с точки зрения бизнеса. Потратил часть ресурсов чтоб проверить насколько проект будет востребованным, когда убедился что проект будет востребован — потратил еще ресурсы чтоб сделать его эффективным. Это называется управление рисками:) Ведь проект мог и «не выстрелить». Ну прямо большую тему вы подняли.

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

3) Вы меняете показания -) То пишете, что было настолько плохо, что пришлось ПОЛНОСТЬЮ переписать, то пишете, что все было учтено, кроме нагрузок. Ну так проблемы с нагрузкой легко лечатся — воткнул побольше памяти, еще парочку серверов, и все ок. Раз уж клиентов так много оказалось, то наверняка ручеек прибыли это должен окупить. А если нет, то тут тогда вообще не в разработке дело. 3б) А если ваша работа окупилась как раз с этой прибыли, тогда вообще не понимаю в чем проблема с библиотеками: их использование позволило вообще запустить проект в таких сложных условиях и нанять более компетентных специалистов которые перепишут все это г.но; Если все так и было, то вы только что привели просто хрестоматийный кейс, как библиотеки помогают бизнесу и почему даже их бездумное использование лучше, чем свои костыли. А библиотеки то тут причем? Да, допустили ошибки в архитектуре, не заложили масштабирование, но это претензия исключительно к квалификации конкретного исполнителя.

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

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

Старая идея Дейкстры о том, что программное обеспечение получается таким дорогим потому, что его пытаются получить при помощи дешёвого труда, сегодня актуальна как никогда. Происходит, как бы, новый виток в стремлении разрабатывать офигительно сложные системы при помощи труда вчерашних студентов. И поэтому очень хочется, чтобы студентов заранее научили не каким-то там абстракциям, а практическим навыкам использования готовых библиотек. И такой запрос со стороны работодателей рано или поздно будет удовлетворён. Теперь вот и MIT перешёл на сторону зла. К сожалению, идею Дейкстры никто всерьёз не воспринял и выводов не сделал. Поэтому в итоге то программное обеспечение, которое всё-таки удастся заставить работать приемлемо, окажется ещё более дорогим, чем когда-либо раньше.

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

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

Абельсон И Сассман Структуры И Интерпретация Компьютерных Программ Скачать

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

При чём тут вообще интернет-магазины или контентные сайты? Это не часть IT-индустрии. Эти виды бизнеса зарабатывают деньги не за счёт разработки софта. Интернет-магазины — это банальная торговля. Хотя и с приёмом заказов через интернет.

Сайты, производящие контент, — это часть медиаиндустрии. Вы бы ещё РЖД или Сбербанк в IT-индустрию зачислили. Между прочим, у РЖД есть «небольшой» вычислительный центр (в Москве, на Красных воротах). Конечно, в нём работают не так много людей, как в Гугле, но я уверен, что счёт идёт на тысячи. В Сбербанке тоже есть IT-департамент, который по числу сотрудников скорее всего превышает 99% российских IT-компаний.