84-летний Лесли Лампорт-легенда.
На веб -странице Microsoft (где он когда -то работал научным исследователем) отмечает, что Лампорт начал «баловаться» на компьютерах в 1950 -х годах — в то время, когда это означало «он и друг привыкли кататься вокруг в поисках выброшенных вакуумных труб для создания цифровой схемы».
Через шестьдесят лет он получил награду Тьюринга за «фундаментальные взносы в теорию и практику распределенных и параллельных систем». После десятилетий исследований Лампорт даже выпустил свой собственный язык спецификации высокого уровня в 1999 году для моделирования программ и систем, предлагая свой собственный элегантный способ диаграммы параллелизма. (TLA в TLA+ означает «временную логику действий»).
Но, оставаясь верным своим академическим происхождениям, Лэмпорт однажды сказал, что язык был «Quixotic попытки преодолеть антипатию инженеров к математике».
Он серьезно относится к математике. После специальности по математике в Массачусетском технологическом институте Lamport получил степень магистра из Brandies в 1963 году и докторскую степень в 1972 году. Его карьера включала в себя должности в ведущих технологических компаниях, включая SRI, Digital Equipment Corporation и Microsoft Research, согласно личному веб -сайту, в котором также перечислены 194 опубликованных научных документов, некоторые из которых были приписаны закладываемым основаниям для распределенных вычислений.
Итак, что вы можете узнать о программировании из жизни, проведенного на его пересечении с математикой?
В прошлом месяце Лампорт вышел на сцену на 22 -й ежегодной выставке Linux в Южной Калифорнии, чтобы поделиться некоторыми пониманиями. Доставляя заключительную основную доклад, Лампорт размышлял о том, почему программисты должны научиться думать более абстрактно и о преимуществах, которые он может принести.
«Быть хорошим в этом, поэтому меня пригласили поговорить с вами», — пошутил он, прежде чем отметить, что его мастерство пришло «во многом, получив образование как математик…»
Почему кодирование не программирование
Лампорт назвал свою презентацию «Кодирование не программирование», объясняя своей аудитории различие между программой и алгоритмом-более высокой, более абстрактной версией пошаговых инструкций программы.
Лэмпорт помнит, что когда он был программистом, он иногда понимал, что кодирование программ, которые он предполагал, «будет большой работой. И мне так же лениво, как и следующий парень. И то, что я бы сделал, это выяснить, что мне действительно нужно для программы». Потребовалось время, но «это сэкономило гораздо больше времени, когда пришло время написать код».
Его заключение? «Не зацикливайтесь на языках. Программирование людей, компьютерных людей, слишком слишком зацикленных на языках. Вы должны думать об идеях, а не о языке, на котором они выражаются».
Снив проект до его обнаженных предметов первой необходимости — всего, что было необходимо — все еще было «дополнительной работой — это дополнительное мышление. Но в конце концов это экономит много времени, потому что он может создать что -то более простое». И вскоре он прибыл на свою главную точку зрения. «Немногие программисты или компьютерные ученые знают, что значит для программы для реализации абстрактной программы (или алгоритма)…»
Разговор Лэмпорта поделился с трудом завоеванными жемчужинами мудрости.
- «Код написания потока сознания не создает хорошую программу».
- «Мышление всегда лучше, чем не думать перед кодированием».
- «Вы пишете абстракцию, чтобы помочь вам подумать о проблеме, прежде чем подумать о коде».
Чтобы поехать домой в последний момент, один из слайдов был назван «Как думать». Вскоре Лэмпорт добавил пулевую точку одного слова-напишите! — За ним следует идеальная цитата от карикатуриста Дика Гиндона.
«Письмо — это способ природы, чтобы сообщить вам, насколько неаккуратно вы думаете».
А потом Лампорт добавил свой собственный афоризм.
«Если вы думаете без писательства, вы только думаете, что думаете…»
В реальном мире
Его главная точка зрения, казалось, было этим. Будь то полная система или просто сложный цикл, «для непрерывных программ абстрактное мышление (выше уровня кода) может избежать ошибок и привести к лучшему, легче записать код».
Лампорт гордится тем, что его язык спецификации TLA+ когда -то использовался для создания всей критической системы. В 2004 году ЕС запустил Rosetta, первую космическую космическую корабль, приземленную на комету. Но он контролировался совершенно новой версией виртуоза, операционной системы в реальном времени (или RTO), написанной с нуля. (Как описано в книге 2011 года.)
«Они сделали дизайн высокого уровня в TLA+»,-говорит Лэмпорт-прежде чем разместить электронное письмо, которое он получил от главы своей команды разработчиков-что абстракция TLA+ «очень помогла прийти к гораздо более чистой архитектуре».
И, в конце концов, они обнаружили, что их окончательная кодовая база была теперь в 10 раз меньше…
«Вы не производите в десять раз меньше кода по лучшему кодированию. Вы делаете это с более чистой архитектурой-также известной как лучший дизайн высокого уровня, лучшая абстракция. Это происходит от размышлений об абстракции, а не об коде.
«Это не из мышления на языке программирования».
Лампорт также сослался на статью 2015 года инженеров Amazon Web Services под названием «Как Amazon Web Services использует формальные методы», отметив, что «формальный метод, который они использовали, был языком TLA+ для написания своих абстракций».
Инженеры писали, что Amazon «регулярно» применяет формальные методы при разработке «сложного реального программного обеспечения, включая общественные услуги». И они пришли к выводу, что их абстрактный язык — найти ошибки в проектах системы, «которые не могут быть найдены с помощью любых других методов, о которых мы знаем».
Их вывод? Эти формальные методы как «удивительно осуществимые для разработки основного программного обеспечения», даже предлагая хорошую отдачу от инвестиций.
Лампорт подчеркивает его значение. «Это фундаментальные недостатки дизайна. Они не просто простые ошибки кодирования». (Это, конечно, означает, что они «очень дорого исправить после написания кода»), как объясняет Лампорт, обнаружил ошибку после того, как код был выпущен пользователям, «считается катастрофой, если вы Amazon».
«Эти ребята являются практическими бизнесменами, и пишут, что спецификация TLA+ требует времени. И они считают, что это стоит потратить в это время, в реальных долларах и смысле, потому что это избегает ошибок».
Вопросы и ответы
Оглядываясь назад, ему повезло, что люди, которые впервые заинтересовались в TLA+, были инженерами -аппаратными средствами, которых он описывает как «гораздо более восприимчивые к концепции правильности». (В то время как программисты живут своей жизнью в окружении кода, это «настолько податлен… что им не нужно беспокоиться о том, чтобы сделать это правильно с первого раза».)
Лампорт считает, что ваша перспектива отличается как аппаратный инженер, потому что «делать это в кремнии — это гораздо более стимул, чтобы сделать это правильно с первого раза».
На сессии вопросов и ответов после его выступления один член аудитории оценил его совет, что проблемы должны быть строго определены «Прежде чем попытаться решить его, написав код». Но они добавили, что «по моему опыту, это почти никогда не было сделано! Редко я когда -либо видел на кодифицированном языке, как ASN.1, определяя формат или протокол для кода».
Лэмпорт согласился, что есть какой-то вопрос о том, будут ли инженеры-программисты даже открыты для начала с высокого уровня Лампорта, абстрактных рассуждений. «То, за что я спорю, считается обманом. Потому что я говорю, не делайте проблемы, которую кто -то говорит вам, что они думают, что хотят. Узнайте, что им действительно нужно».
Затем Лэмпорт рассказал историю «очень яркого» стажера, которого он имел в течение года. «Он выучил TLA+, и он узнал, что вы знаете, думая и указав, что вы хотите сделать, прежде чем сделать это». Но на его следующей стажировке «человек, который нанял его, сказал:« Перестань писать всю эту глупую чепуху. Просто напишите код ».» »» »».
«Так что… мышление — это очень тяжелая продажа», — сказал Лэмпорт.
«Большинство людей предпочли бы сражаться, чем думать».
Один спрашивающий вспомнил профессора математики, который описал компьютеры и компьютерные науки как «механизация абстракции». Таким образом, в мире, где уже существуют модельные валидаторы — и с ИИ, который уже живет в совершенно абстрактном мире, «может быть, легче передать абстрактное мышление на машины?»
Лампорт говорит, что он не изучал ИИ, но не знает ни о каких валидаторах с поддержкой AI. И это приводит его к более общему наблюдению. В то время как абстракции могут принести вам сияющую ясность, необходимую для принятия хороших решений о ваших программах, работа с ИИ, кажется, делает наоборот.
«Все дело в ИИ заключается в том, что он решает проблемы, которые мы не знаем, как решить — написав программы, которые мы не понимаем!»
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Дэвид Кассель — гордый житель района залива Сан -Франциско, где он освещал технологические новости более двух десятилетий. За эти годы его статьи появлялись повсюду от CNN, MSNBC и The Wall Street Journal Interactive … Подробнее от Дэвида Касселя
