Comments 28
Довольно интересно было почитать автора ООП и моего любимого языка Smaltalk, спасибо автору. )
Вы используйте неправильный ООП и у него неправильный код.
Краткое содержание части этого интервью, посвященной ООП :-)
С другой стороны у всех э́тих мейнстримовых ООП языков действительно нет (наверное) и половины того что бы было заложено в Smalltalk, зато есть куча
Но если посмотреть еще и с 3-й стороны, то Smalltalk — это чисто учебный язык. Языки используемые в продакшене на протяжении всей своей истории существования, это: Fortran (охоспади, первый ЯП), Lisp, Cobol, Ada, С/С++, С#, Java, Pascal/Delphi, Matlab, Пухтон, SQL, Verilog, VHDL, Go и даже упомянутая в интервью Jullia используется в продакшене — её ещё нет в релизе, а она уже достаточно активно используется (на мой взгляд это самый перспективный ЯП из всех существующих, если, конечно, получится пересадить народ с С/С++, Fortran, Matlab и Пухтона на нее). А ещё всякий синтаксический мусор типа ПХП и Жаба-скрипта. Есть парочка убитых языков, типа Пролога и Алгола. Наверное Вы ещё с десяток сможете добавить. А вот Smalltalk в бою я нигде не видел, и сомневаюсь что его когда-либо использовали — он с самого начала не зашёл в продакшен (кстати по вполне объективным причинам).
Ну у меня есть проект, который работает на Smalltalk 24/7/365 уже 17 лет. Причем последние 6-7 лет без моего участия. Но проектов действительно мало просто потому, что Smalltalker'ов в России в пределах 10-15.
Думаю их всё-таки побольше. А проблема — действительно в условных «индусах». Вернее — в том, что люди разные, очень разные. Но им нужно как-то совместно делать проект. В результате 1000 человек совместно делают за год проект, который один Smalltalk'ер сделал бы за 10 лет (и результат был бы лучше!), но, увы, ждать столько нельзя…
Ну вот за бугром, как мне показалось чуть ли не каждый второй его знает — все его любят, но почти никто не пользуется. Так же как и Симула, потомком которого он и является, этот язык концептуально был слишком крут для своего времени… и для тогдашнего железа.
И вот прошло… эээ… почти 50 лет и Алан Кей в интервью говорит: вы используйте императивное программирование со структурами и сеттерами и называйте это ООП, не надо так.
И вот прошло… эээ… почти 50 лет и Алан Кей в интервью говорит: вы используйте императивное программирование со структурами и сеттерами и называйте это ООП, не надо так.
Он говорит не о языках программирования, а об антипаттернах типа Anemic Model. Ровно о том же, только другими словами, говорят Фаулер, Эванс итд.
1. Берём любой рэндомный Паттерн (если это общеизвестный антипаттерн, то сразу переходим к п.3)
2. Обнаруживаем что он антипаттерн
3. Находим ему альтернативу
4. Обнаруживаем, что альтернатива тоже антипаттерн
5. Повторять до тех пор пока не будет обнаружена серебряная пуля.
Ок, раз другими словами, ну тогда другими словами:
Употреблять в любой непонятной ситуации.
2. Обнаруживаем что он антипаттерн
3. Находим ему альтернативу
4. Обнаруживаем, что альтернатива тоже антипаттерн
5. Повторять до тех пор пока не будет обнаружена серебряная пуля.
Ок, раз другими словами, ну тогда другими словами:
Вы просто не умейте готовить ООП
Употреблять в любой непонятной ситуации.
Это вы уже в демагогию сваливаетесь. Сами выдвинули утверждение и сами опровергаете. Я вообще не о том.
Сформулирую свою мысль иначе: изначальная формулировка ООП, которую дал Алан Кей (про объекты и сообщения) вполне совместима с более современными паттернами и методологиями (SOLID, DDD, CQRS...), а отклонения от его изначальной формулировки вполне соответствуют известным антипаттернам.
У вас удивительная способность все смешать в кучу, навешать лейбаков, добавить ксенофобии по отношению к индусами. Логика при этом проигнорирована напрочь. Например, ваши же выводы должны записать Алгол в индусский язык. :D Что такое нафиг «продакшен» по отношению к языку!? Смоллток использовался во многих проектах в реальной жизни. В Японии на нем целые CAD'ы писали, когда Verilog даже не существовал в планах. Не говоря о том, что он многие идеи и конструкции из Смоллтока перекочевали в другие языки. ObjC тому пример.
В Японии на нем целые CAD'ы писали, когда Verilog даже не существовал в планах..
Писали, писали, да не выписали, вероятно точно также как и вычислительные системы 5 поколения :) Когда это когда? :-) Что за CAD? Что он делал? Как назывался? Что за японцы его писали?
«Вот был там какой-то проект, бабушка на лавочке сказала что его писали на языке Х задолго до языка Y» — плохой пример, даже не потому что это неверифицируемый треп, а потому что не смогли выдать хоть сколько-то значимого примера и не показали регулярность использования языка. Ну писали и что? Раз написали, два написали, потом отпуск кончился и пошли дальше на Жабе писать.
ксенофобии по отношению к индусами
Хм, с каких это пор констатация факта является ксенофобией? Индусы любят сахар (докажите что не любят), не вижу здесь ничего ксенофобского. Вы похоже что-то выдумали и давай развешивать ярлыки ;-)
Например, ваши же выводы должны записать Алгол в индусский язык. :D
Вы что-то путайте — это Ваши выводы, ещё и новый класс языков выдумали — индусский (говорят в Индии много языков, но официальные языки английский и хинди, но не исключаю что есть индусы которые на Алголе разговаривают). Я лишь написал, что Алгола был безвременно убитым языком, ничего более, также как был убит Пролог, кстати японцами, старожилы говорят, что это было очень увлекательное зрелище ;-) Возможно это даже были те же японцы что-то там писали на Smalltalk :-)
Не говоря о том, что он многие идеи и конструкции из Смоллтока перекочевали в другие языки. ObjC тому пример
Алан Кей в интервью уже все сказал про все эти Object языки в которые перекочевали идеи Smalltalk: «Это был не ООП». То что оказал некое влияние, никто и не отрицает, только разговор шел о:
Что такое нафиг «продакшен» по отношению к языку!?
Капитан очевидность подсказывает, что это значит, что на языке пишут что-то более серьезное нежели чем «Hello world» и учебных примеров. Пишут и выпускают продукт на этом языке, иногда даже коммерчески успешный. Например, на Фортране писали математику ещё до того как Алан Кей пришел в Xerox, пишут аш с 1957 года, и продолжают писать до сих пор т.к. другая альтернатива — это Си, и Вы не поверите, но на Си пишут самые настоящие ОС (просто офигеть!), а на VHDL вот уж 35 лет описывают интегральные схемы. А вот на Smalltalk написали VisualWorks — среду для того что бы писать на Smalltalk, вероятно некоторые попали в рекурсию и так до сих пор и не вышли…
Мне кажется, в начале статьи очень хорошо смотрелась бы небольшая справка на тему того, кто такой Алан Кей. Предвижу, что в меня полетят помидоры после такого заявления, но всё же это не общеизвестная информация.
Но существование Википедии — это то общеизвестная информация.
добавил
Что за Danila Kornev в 9 вопросе? А все, понял, начались вопросы от конкретных людей?
Интересно узнать его отношение к доказательствам корректности программ, в частности к ЯП с зависимыми типами.
Julia, который сейчас потихоньку выходит на роль ведущего языка scientific computing после фортрана-матлаба-питона
Очень смелое утверждение на мой взгляд.
Нормальное утверждение. Сейчас все серьезные приматы так или иначе на нем работают.
Вообще в мире всего на двух (трех) языках пишут программы с серьезными вычислениями — это C/C++ и Fortran, сейчас в этот клуб вступила Julia и стала третьим (четвертым, если разделять C и Fortran) языком для высокопроизводительных вычислений.
Никто на Пухтоне, Жабе или Матлабе не будет поднимать вычислений, где надо брать петафлопные рубежи. Математика в Матлабе самая быстрая из этих трех, а Julia быстрее Матлаба, гхм… в моих задачах примерно в 38 раз, а учитывая что синтаксис там такой же нативный для приматов как и Матлабе с Фортраном, то это становится слишком заманчиво что бы проигнорировать такой язык.
Единственная проблема, шо крайняя версия языка, гхм...0.6 и некоторые инструменты находятся еще просто в зачаточном состоянии. С другой стороны это не мешает его использовать, например, для система управления воздушным движениям.
Вообще в мире всего на двух (трех) языках пишут программы с серьезными вычислениями — это C/C++ и Fortran, сейчас в этот клуб вступила Julia и стала третьим (четвертым, если разделять C и Fortran) языком для высокопроизводительных вычислений.
Никто на Пухтоне, Жабе или Матлабе не будет поднимать вычислений, где надо брать петафлопные рубежи. Математика в Матлабе самая быстрая из этих трех, а Julia быстрее Матлаба, гхм… в моих задачах примерно в 38 раз, а учитывая что синтаксис там такой же нативный для приматов как и Матлабе с Фортраном, то это становится слишком заманчиво что бы проигнорировать такой язык.
Единственная проблема, шо крайняя версия языка, гхм...0.6 и некоторые инструменты находятся еще просто в зачаточном состоянии. С другой стороны это не мешает его использовать, например, для система управления воздушным движениям.
В контексте сравнения динамических и статических языков Алан как-то говорил, что все известные ему системы типов невообразимо отвратительны. Если я правильно помню, он не против самой концепции системы типов, но ему не нравятся имеющиеся реализации.
Интересно услышать его мнение относительно системы типов языка Rust. Именно в контексте проблем с «плохими» языками и многопоточными системами. С моей точки зрения, это единственный на данный момент язык, который пытается решать проблему параллельного программирования на фундаментальном уровне.
Интересно услышать его мнение относительно системы типов языка Rust. Именно в контексте проблем с «плохими» языками и многопоточными системами. С моей точки зрения, это единственный на данный момент язык, который пытается решать проблему параллельного программирования на фундаментальном уровне.
Прочитал документацию по Расту, не вижу абсолютно ничего особенного в его системе типов, можете раскрыть мысль? Насчёт «единственного языка, который решает проблему параллельного программирования» также непонятно.
На эти вопросы хорошо отвечает пост одного из идеологов языка: Fearless Concurrency.
За статью спасибо.
В целом не совсем понятно, почему не ограничиться lexical scope (со всеми традиционными батарейками в виде HOF и так далее) и агентами (как в Oz, например, ну или даже как в эрланге), или вообще пойти по пути хаскеля (раз уж и так что-то типа GADT и pattern matching уже есть). Видимо, крестовые корни не дают возможности делать просто (для программиста), а не сложно.
Ну да ладно, лень спорить. То, что раст не единственный, где думают про конкурентность, и то, что система типов у него хоть и не самая простая, но вполне себе обычная для 21 века (даже всяких agda не надо вспоминать, сравнения с простым хаскелем достаточно) — ну собственно я в этом убедился, ну а большего мне и не надо.
В целом не совсем понятно, почему не ограничиться lexical scope (со всеми традиционными батарейками в виде HOF и так далее) и агентами (как в Oz, например, ну или даже как в эрланге), или вообще пойти по пути хаскеля (раз уж и так что-то типа GADT и pattern matching уже есть). Видимо, крестовые корни не дают возможности делать просто (для программиста), а не сложно.
Ну да ладно, лень спорить. То, что раст не единственный, где думают про конкурентность, и то, что система типов у него хоть и не самая простая, но вполне себе обычная для 21 века (даже всяких agda не надо вспоминать, сравнения с простым хаскелем достаточно) — ну собственно я в этом убедился, ну а большего мне и не надо.
Видимо, крестовые корни не дают возможности делать просто (для программиста), а не сложно.Вопрос не в простоте или сложности для программиста, а в возможности «положить» это на CPU. Rust следует за C++ в принципе you don't pay for what you don't use — а все «традиционные батарейки» в этом ключе сложно реализовать, как я понимаю (с другой стороны исключения таки реализовали так, что при их не использовании за них «платить» не нужно, может быть и тут можно так сделать).
даже всяких agda не надо вспоминать, сравнения с простым хаскелем достаточноХаскель — ни разу не прост. Даже C++ и rust в 100 раз концептуально проще. Именно а разрезе отображения языка на железо. Как именно многие конструкции Хаскеля отображаются в машинные инструкции — сходу неочевидно, в то время как для C++ и rust — всё понятно. Совсем другой уровень абстракций…
Не забывайте, что язык позиционируется как системный. Соответственно, требования к контролю и управлению памятью совершенно другие, чем в эрланге или хаскеле.
У вас довольно своеобразное представление о том, что просто для программиста, а что сложно. Пойдя по пути хаскеля мы получим еще один хаскель. Раст же старается оставаться в рамках императивной парадигмы, понятной обывателю и удобной для системного программирования, в то же время вынося на бытовой уровень ФП-шные плюшки.
С точки зрения теории типов, система типов раста — это что-то вроде системы F, расширенной понятиями лайфтаймов. Операторы над типами, насколько я знаю, сейчас не поддерживаются (хотя сейчас идет активная работа над специализацией и полиморфизмом высших порядков).
Основное отличие по сравнению с хаскелем — это существование т.н. coherence rule, которое обеспечивает возможность изменения зависимостей без нарушения логики программы. То есть ситуация, когда после минорного обновления библиотеки в недрах дерева зависимостей код перестает компилироваться, практически исключена.
Это требование налагает определенные ограничения и на программиста и на реализацию языка.
Наконец, все это является довеском к основным задачам языка: memory safety и fearless concurrency. Вы утверждаете, что в этом ничего особенного. Назовите мне пожалуйста еще один императивный язык программирования, который статически на этапе компиляции контролирует отсутствие в программе состояния гонок и не допускает существования тухлых указателей. Притом, чтобы все это происходило без GC и VM.
В целом не совсем понятно, почему не ограничиться lexical scope (со всеми традиционными батарейками в виде HOF и так далее) и агентами (как в Oz, например, ну или даже как в эрланге), или вообще пойти по пути хаскеля (раз уж и так что-то типа GADT и pattern matching уже есть). Видимо, крестовые корни не дают возможности делать просто (для программиста), а не сложно.
У вас довольно своеобразное представление о том, что просто для программиста, а что сложно. Пойдя по пути хаскеля мы получим еще один хаскель. Раст же старается оставаться в рамках императивной парадигмы, понятной обывателю и удобной для системного программирования, в то же время вынося на бытовой уровень ФП-шные плюшки.
С точки зрения теории типов, система типов раста — это что-то вроде системы F, расширенной понятиями лайфтаймов. Операторы над типами, насколько я знаю, сейчас не поддерживаются (хотя сейчас идет активная работа над специализацией и полиморфизмом высших порядков).
Основное отличие по сравнению с хаскелем — это существование т.н. coherence rule, которое обеспечивает возможность изменения зависимостей без нарушения логики программы. То есть ситуация, когда после минорного обновления библиотеки в недрах дерева зависимостей код перестает компилироваться, практически исключена.
Это требование налагает определенные ограничения и на программиста и на реализацию языка.
Наконец, все это является довеском к основным задачам языка: memory safety и fearless concurrency. Вы утверждаете, что в этом ничего особенного. Назовите мне пожалуйста еще один императивный язык программирования, который статически на этапе компиляции контролирует отсутствие в программе состояния гонок и не допускает существования тухлых указателей. Притом, чтобы все это происходило без GC и VM.
Да, если есть желание разобраться подробнее именно с точки зрения системы типов, могу посоветовать научную работу по формальному доказательству корректности языка и его стандартной библиотеки: RustBelt: Securing the Foundations of the Rust Programming Language.
Прочитал документацию по Расту, не вижу абсолютно ничего особенного в его системе типов, можете раскрыть мысль?С вероятностью 90% вы просто «пропустили мимо» самое важное. Ну как программисты на Turbo Pascal'е когда говорили с C++'шниками: а что — так сложно деструктор вызвать? А когда появились исключения, то эта мелочь (в Turbo Pascal нужно явно вызвать XXX.Done, в С++ компилятор разрушает обьект автоматически) оказалась настолько важной, что в Delphi пришлось вводить совершенно другую, ортагональную, систему типов…
Sign up to leave a comment.
Специально для Хабра: интервью с Аланом Кеем