Comments 24
Что, в соответствии с мыслями Алана Кэя, является самым главным в ООП? — … Динамическая привязка (т.е. Позднее связывание)…
Что в ООП несущественно? — … Полиморфизм…
Но, Полиморфизм — это не что иное как реализация позднего связывания!
Тезис Чёрча-Тьюринга показал, что лямбда-исчисление и машины Тьюринга функционально эквивалентны.
Тезис Чёрча-Тьюринга не об этом.
А лучше не медитировать, а пописать на Smalltalk в котором между написанием программы и ее рантаймом нет никакой разницы.
Вся любовь к типам и непонимание динамики (позднего связывания) происходят, потому что момент написания программы в текущих мейнстрим-языках статический. Перед запуском созданной системы нам сначала необходимо статически (в текстовом файле) описать ее и скомпилировать.
В современных "динамических" языках информация о "типах" доступна только в рантайме. Так как в этих языках динамичность осталась только в рантайме, но момент написания все еще статический (текстовые файлы), то создается mismatch.
Smalltalk — совсем другой фрукт. Он делает динамическим не только способ работы системы как таковой, но и принцип работы человека с системой. В Smalltalk нет файлов. Кент Бек по этому поводу сказал "I mean, source code in files; how quaint, how seventies!". Да, в Smalltalk исходный код — это текст, но он находится не в файлах.
Я вот склонен говорить о типах.
Очень забавный момент в этом плане — что Хаскель в статье упоминается, как пример свободы — в то время как у него жуть какая строгая система типов, C++ отдыхает. И то, что эта система позволяет описывать вещи, которые в C++ делаются через всякий ад вроде dynamic_cast — это не меньшая строгость, а бОльшая продуманность системы (правда, отчасти доступная только за счёт иммутабельности). С JavaScript сравнивать не приходится… (увы-увы, мне порой приходится писать на js, и никогда на хаскеле — и жёсткой типизации очень не хватает)
И хранят все (все програмные абстрации, все окружения со всеми данным во все моменты) и потому сильно текут по памяти.
«Течет по памяти» не лисп, а дизайн программы (развивая мысль далее — структура, алгоритм). На любом (garbage-collected и не только) языке запросто устроить бесконечную «утечку» памяти в виде списка или мапы в которую ежесекундно будут добавляться (и не освобождаться) терабайты.
Я бы сказал что напротив, у лиспа, не отличающего данные и код полнейший контроль программы. Правда, это приносит известные проблемы — так как лисповое состояние обладает персистентностью (т.е. можно сохранять/загружать) то со временем трудно сказать (и понять, и отлаживать) что представляет собой программа. Иными словами, у лиспа проблемы с масштабируемостью вверх на большие и сверхбольшие проекты.
Любопытный факт — понятие mudball идет с лиспа. https://en.wikipedia.org/wiki/Big_ball_of_mud#In_relation_to_Lisp поэтому уход лиспа в специфическую нишу определен конечно же не проблемами с памятью, а развитием ООП, которое позволило сделать разработку и работу больших проектов предсказуемой (т.к. она разделена на изолированные классы).
Есть распространённое заблуждение, в соответствии с которым машины Тьюринга могут вычислить всё, поддающееся вычислению. Существуют классы проблем (например — проблема остановки), которые могут быть вычислимыми с использованием машин Тьюринга лишь для некоторых случаев.
«Вычислимо» и «вычислимо на машине Тьюринга» — синонимы (сверхтьюринговых вычислений никто пока не смог придумать), и проблема останова никак этому не противоречит. Что вообще значил этот тезис? Ну и дальше идёт какая-то шизофазия про противопоставление лямбд императивному подходу (императивность — это антоним декларативности, а не лямбдам), и прочие сектантсткие «Правильные трактования слов Отца ООПа». Это не история ООП, это ассоциативный ряд запутавшегося в тьюринговой трясине джуниора.
Они реализуют стандартизированные интерфейсы, а это значит, что они могут взаимодействовать друг с другом.
Вот как эти стандартизированные интерфейсы выглядят, и как вместе с сообщениями передавать информацию о произошедших событиях — это большой вопрос, потому что это всё сильно попахивает WinAPI'шными, прости г-ди, lParam / wParam.
Конечно, мы не будем приводить в пример концепции ООП Кея Erlang, а будем со всех сил тянуть за уши JS.
Плюсую. Вообще по моему опыту люди рассуждающие о "будущем программирования" и "единственно верной парадигме", которая к нему приведёт, обычно знают мало языков и этих самых парадигм. Что приводит к попыткам переизобрести пролог: давайте опишем что мы хотим, а оно само как-то заработает.
Жаль, что Erlang довольно низкоуровневый в плане реализации ООП. Если в Smalltalk для обработки сообщения объектом достаточно создать метод с нужным селектором, то в Erlang принято сначала писать сервер, который умеет обрабатывать определенные сообщения, а потом клиент для этого сервера.
Но Erlang создавался для решения конкретных инженерных задач, и он справляется с этими задачами на ура. Очень приятный язык.
Забытая история ООП