Comments 190
IDE выглядит как привет из 90ых. А так это интересно, что язык все еще жив — для меня это откровение.
Язык жив и очень даже развивается. В последней версии 8.0 они изменили дизайн IDE. Я просто пока на неё не перешол. Да и вообще интерфейс меняется одним параметром в настройках. Вот например интерфейс в стиле Мас ОС
Можно полностью настроить как нравится. Но я и сам из 90-х, так что меня устраивает дефолтный
Можно полностью настроить как нравится. Но я и сам из 90-х, так что меня устраивает дефолтный
Как насчётт библиотек, так нужных в бизнес приложениях: парсинг и генерация Excel (2003/2007+), генерация PDF?
Насчет Exel сейчас в сообществе смолторкеров как разрабатывается парсер. Файлы десятого офиса разбираются на счет раз (это просто зип архивы). Мы их сами разбирали и собирали. К автокаду цеплялись по COM. Есть встроенная поддержка СОМ интерфейса (пакет ComAll).Так же сами писали пакеты для чтения dxf в объектную структуру, и выгрузку обратно в файл. Насчет PDF не знаю, надо смотреть в Sincom Public Repozinity. За бугром сообщество достаточно мощное, возможно кто то что то и написал.
А вообще есть поддержка WinApi так что возможно подключение любых библиотек и вызов их функций. Как в в линуксе это реализованно я не знаю, а под виндой не очень сложно. Например я использую для отрисовки библиотеку Cairo и она прекрасно работает.
А вообще есть поддержка WinApi так что возможно подключение любых библиотек и вызов их функций. Как в в линуксе это реализованно я не знаю, а под виндой не очень сложно. Например я использую для отрисовки библиотеку Cairo и она прекрасно работает.
Генерация PDF есть.
Есть некоторое количество разных интересных библиотек и инструментов.
Но надо понимать, что из-за небольшого размера коммьюнити, очень многие инструменты не реализованы или в находятся в зачаточном состоянии.
Есть некоторое количество разных интересных библиотек и инструментов.
Но надо понимать, что из-за небольшого размера коммьюнити, очень многие инструменты не реализованы или в находятся в зачаточном состоянии.
(Ох накликаю я беду!)
Автор, Ваше знание русского языка отбило охоту читать Вашу же статью на втором абзаце. А Ваши ответы и комментарии усугубили ситуацию. Ужас!
Автор, Ваше знание русского языка отбило охоту читать Вашу же статью на втором абзаце. А Ваши ответы и комментарии усугубили ситуацию. Ужас!
Комментатор, Вы после «ох» запятую пропустили. И это поборник русского языка. Ужас!
Да ладно, все мы люди, все мы человеки. У меня жена когда читает мои тексты — сначала долго мате...., потом выгоняет из за компьютера, и долго правит. На то что бы научить меня правилам уже махнула рукой, хотя и работала долго репетитором по русскому языку. Но и после этого редакторы (я пишу статьи для журналов и хелпы для проекта), все равно находят ошибки. Так что идеального правописания по моему не существует. Всегда присутствует человеческий фактор, да и идеальной программы проверки текстов пока не придумали.
Автор, это была ирония по отношению к комментатору, который ужасается вашему «знанию русского языка», но и сам после первого же слова допускает ошибку :)
К вашему правописанию я претензий не имею — видно, что писали вы от души и по делу, читать ваш текст интересно, ошибки чтению не мешают.
Об ошибках в орфографии и пунктуации принято сообщать в личку, а в комментариях же — писать по делу.
К вашему правописанию я претензий не имею — видно, что писали вы от души и по делу, читать ваш текст интересно, ошибки чтению не мешают.
Об ошибках в орфографии и пунктуации принято сообщать в личку, а в комментариях же — писать по делу.
Я понял что это была ирония. Спасибо за Ваш комментарий. Я поскольку действительно сам не отличаюсь грамотностью, очень терпимо отношусь к другим таким — же. Ну и привык уже к тому что меня постоянно ругают за это. Заслужил)))). Кстати многие написали мне в личку подсказки где исправить ошибки. Спасибо им за это. Благодаря им я смог привести пост в более менее удобочитаемый вид.
Да, неувязочка! А ведь должна была быть. Коммментарий писал со смартфона. (Не в качестве оправдания, а так… констатация факта).
Да с чистописанием у меня не все хорошо. Хотя статью вроде проверял Word — ом. Ну что поделать, не все мы филологами родились. Да и на вахте я сейчас, жена далеко. Обычно она меня проверяет. Глубоко извиняюсь если чем то обидел русский язык.
Нажимаем «рун»! :)
Наличие внешней проверки не отменяет наличие внутренней. Вы хоть почитайте, что написали (обычно на следующий день после написания большинство косяков видны) — уже просто читая, так и хочется вопросить: «запятые уже отменили?» Это, кстати, касается и цитат из википедии — там тоже тихий ужас. Как я понимаю, вы их даже не читали, понадеевшись на Ctrl+C, Ctrl+V. А ведь можно было сделать доброе дело и поправить. Остальное отправил личным сообщением.
Ну и опять же, вижу стандартную кашу в голове, когда в одну кучу свалены особенности языка и конкретной IDE, библиотек и всего того, чем автор пользуется, лишь бы набросать побольше плюсов своему любимому языку. Ну какая поддержка дебага и рефакторинга на уровне языка? Это чисто фишки IDE. То, что организация языка — все переменные приватные — упрощает рефакторинг, не означает, что язык его поддерживает. А если вам нужно поменять геттер/сеттер? Туда же работа с БД и GUI, репозиторий кода.
Это что ж получается — поменял переменную-счетчик цикла (утрированно, знаю, что есть методы обхода элементов) и все, кирдык?
Ну и опять же, вижу стандартную кашу в голове, когда в одну кучу свалены особенности языка и конкретной IDE, библиотек и всего того, чем автор пользуется, лишь бы набросать побольше плюсов своему любимому языку. Ну какая поддержка дебага и рефакторинга на уровне языка? Это чисто фишки IDE. То, что организация языка — все переменные приватные — упрощает рефакторинг, не означает, что язык его поддерживает. А если вам нужно поменять геттер/сеттер? Туда же работа с БД и GUI, репозиторий кода.
При любом изменении в объявлении сохраненных объектов (добавление, удалении переменных, изменении имени переменных и т.д) файл обратно не вычитается.
Это что ж получается — поменял переменную-счетчик цикла (утрированно, знаю, что есть методы обхода элементов) и все, кирдык?
За исключением около 10% статья как про Common Lisp.
На самом деле я, познав оба языка, даже пытался сделать Class Browser (это те самые 10%) для CL. Если есть желающие, могу поделиться наработками и списком нерешённых (но не неразрешимых) трудностей.
На самом деле я, познав оба языка, даже пытался сделать Class Browser (это те самые 10%) для CL. Если есть желающие, могу поделиться наработками и списком нерешённых (но не неразрешимых) трудностей.
Расскажите, как обстоят дела с кроссплатформенной разработкой:
1. Нужно писать отдельный GUI под каждую OS?
2. В GUI используются нативные контролы?
3. Нужно устанавливать виртуальную машину отдельно, как для Java, или приложение компилируется в исполняемый бинарник отдельно для каждой ОС?
1. Нужно писать отдельный GUI под каждую OS?
2. В GUI используются нативные контролы?
3. Нужно устанавливать виртуальную машину отдельно, как для Java, или приложение компилируется в исполняемый бинарник отдельно для каждой ОС?
С GUI все обстоит прекрасно. Практически все отрисовывается средствами SmallTalk. Кроме хедара окна (в каждой ОС он будет родной для неё).
В остальном отрисовка и работа ГУЯ от ОС не зависит. Так же надо проверить отображение шрифтов. В целевой ОС необходимых может не оказаться, Система подберёт подходящие. Может получиться некрасиво. У меня с переходом на другую ОС были проблемы с запросом домашней папки (Ну не линуксоид я — не знал как называется переменная окружения. Теперь знаю — помогли). Так же была проблема с работой с Com портом. Оказалось даже проще чем в винде. Работаеш как файлом (точнее с потоком — Stream). C маком и компортом пока не разобрался (не заработал пока на мак), поэтому версии под него пока нет.
Виртуальную машину устанавливать не надо. Надо положить в одну папку необходимую виртуалку и файл образа. Причем он один для всех ОС. Главное что бы имена виртуалки и образа совпадали. В винде просто двойной клик по виртуалке, она ищет у себя под боком одноимённый файл образа и работает с ним. С линуксой посложнее немного. Рядышком надо положить скрипт примерно такого содержания:
#!/bin/sh
./flp flp.im
и запускать его.
Как то так
В остальном отрисовка и работа ГУЯ от ОС не зависит. Так же надо проверить отображение шрифтов. В целевой ОС необходимых может не оказаться, Система подберёт подходящие. Может получиться некрасиво. У меня с переходом на другую ОС были проблемы с запросом домашней папки (Ну не линуксоид я — не знал как называется переменная окружения. Теперь знаю — помогли). Так же была проблема с работой с Com портом. Оказалось даже проще чем в винде. Работаеш как файлом (точнее с потоком — Stream). C маком и компортом пока не разобрался (не заработал пока на мак), поэтому версии под него пока нет.
Виртуальную машину устанавливать не надо. Надо положить в одну папку необходимую виртуалку и файл образа. Причем он один для всех ОС. Главное что бы имена виртуалки и образа совпадали. В винде просто двойной клик по виртуалке, она ищет у себя под боком одноимённый файл образа и работает с ним. С линуксой посложнее немного. Рядышком надо положить скрипт примерно такого содержания:
#!/bin/sh
./flp flp.im
и запускать его.
Как то так
Автор статьи немного лукавит. Система виджетов в смолтоке своя, построена по отличным от принятых принципам (морфик). Поддержка нативных виджетов системы часто условная. Тесная интеграция с системой часто болезненна. Сказалась многолетняя изоляция мира смолтока от остального мира IT.
Это действительно проблемы которые надо, как мне кажется, решать системно. Сейчас же это больше напоминает попытку нарисовать скин похожий на системный и успокоиться. Джава в свое время тоже придерживалась модели собственных элементов управления, но к счастью от этого отошли.
Ближе всего к системе находится Dolphin Smalltalk, но он нифига не кроссплатформенный, платный и нифига не развивается.
Это действительно проблемы которые надо, как мне кажется, решать системно. Сейчас же это больше напоминает попытку нарисовать скин похожий на системный и успокоиться. Джава в свое время тоже придерживалась модели собственных элементов управления, но к счастью от этого отошли.
Ближе всего к системе находится Dolphin Smalltalk, но он нифига не кроссплатформенный, платный и нифига не развивается.
Ну вообще то я об этом и написал:
Мне пока хватает встроенных виджетов. Если что то надо изменить, можно отнаследоваться от базового, и рисовать виджет как душа пожелает. Не знаю получится ли так с наитивными виджетами. А здесь мне в большинстве случаев достаточно научить объект отрисовыватся на вьюшке так как мне надо.
И да благодаря этому достигается кроссплатформеность. Dolphin Smalltalk действительно красивый но только под винду
Практически все отрисовывается средствами SmallTalk. Кроме хедара окна (в каждой ОС он будет родной для неё).
В остальном отрисовка и работа ГУЯ от ОС не зависит.
Мне пока хватает встроенных виджетов. Если что то надо изменить, можно отнаследоваться от базового, и рисовать виджет как душа пожелает. Не знаю получится ли так с наитивными виджетами. А здесь мне в большинстве случаев достаточно научить объект отрисовыватся на вьюшке так как мне надо.
И да благодаря этому достигается кроссплатформеность. Dolphin Smalltalk действительно красивый но только под винду
UFO just landed and posted this here
Морфик это в Squeak/Pharo.
Про dolphin smalltalk — забудьте, он умер и вряд ли восстанет из пепла.
Про dolphin smalltalk — забудьте, он умер и вряд ли восстанет из пепла.
Есть два ведущих диалекта:
Под каждую платформу есть своя виртуальная машина, здесь как для Java. Есть возможность скомпоновать исполняемую виртуальную машину и образ в единый бинарник. Только смысла в этом не много. Надо понимать, что если вы пишете тиражируемый софт для домохозяек, то Smalltalk не ваш выбор.
GUI кроссплатформенный и реализован весь на Smalltalk. Отличаются только вызовы к system API для создания окон, но это все инкапсулируется в виртуальной машине. Так что, файл образа абсолютно переносим с платформы на платформу
- VisualWorks Smalltalk (платный, есть бесплатная версия для себя без ограничения возможностей)
- Pharo (бесплатная)
Под каждую платформу есть своя виртуальная машина, здесь как для Java. Есть возможность скомпоновать исполняемую виртуальную машину и образ в единый бинарник. Только смысла в этом не много. Надо понимать, что если вы пишете тиражируемый софт для домохозяек, то Smalltalk не ваш выбор.
GUI кроссплатформенный и реализован весь на Smalltalk. Отличаются только вызовы к system API для создания окон, но это все инкапсулируется в виртуальной машине. Так что, файл образа абсолютно переносим с платформы на платформу
Приветствую единомышленника!
Статья неплохая, хоть и сумбурная.
К сожалению, введение в смолток писали уже все кому не лень (включая меня), но нормальных статей по прежнему нет. Все пишут что язык классный, все здорово, приводят пару стандартных примеров и на этом все заканчивается обычно.
Нужна нормальная статья с примером практической разработки. Хорошо бы продемонстрировать, что такое Smalltalk way с точки зрения проектирования. Показать, как концепция превращается в реализацию на примере конкретной задачи. Вы упомянули разработку FLProg. Вот и опишите, как происходила разработка и что позволило делать это быстро и эффективно. Это все равно что хаскель объяснять на примере десяти вариантов реализации факториала.
Во-вторых, говорить только о прекрасных сторонах языка — нечестно. Надо рассказать и об недостатках, включая проблемы с нативными виджетами и отсутствием нормальной свободной реализации (Pharo конечно есть, но это не тот уровень).
Статья неплохая, хоть и сумбурная.
К сожалению, введение в смолток писали уже все кому не лень (включая меня), но нормальных статей по прежнему нет. Все пишут что язык классный, все здорово, приводят пару стандартных примеров и на этом все заканчивается обычно.
Нужна нормальная статья с примером практической разработки. Хорошо бы продемонстрировать, что такое Smalltalk way с точки зрения проектирования. Показать, как концепция превращается в реализацию на примере конкретной задачи. Вы упомянули разработку FLProg. Вот и опишите, как происходила разработка и что позволило делать это быстро и эффективно. Это все равно что хаскель объяснять на примере десяти вариантов реализации факториала.
Во-вторых, говорить только о прекрасных сторонах языка — нечестно. Надо рассказать и об недостатках, включая проблемы с нативными виджетами и отсутствием нормальной свободной реализации (Pharo конечно есть, но это не тот уровень).
P.S.: Прошу прощения, предложение про хаскель семантически относится к прыдыдущему абзацу :)
Это вводная статья, так сказать поверхностный обзор. Мне было интересно посмотреть как сообщество отреагирует на этот язык. Если статья заинтересует читателя, я напишу продолжение. Со стилем у меня не очень, но что рассказать есть. Про ГУЙ — это вообще отдельный вопрос. Непривычно до ужаса, но если понять — то очень мощный платформонезависимый механизм. Для его описания потребуется не один пост. Вы кстати первый кто заинтересовался продолжением. Писать то надо для заинтересованной публики, а если никому неинтересно — то зачем писать? Посмотрим на реакцию.
Я тоже заинтересовался, что там за гуй необычный такой?
Я жду продолжение
Было бы интересно увидеть что-то типа getting started — hello world, GUI, общепринятая структура организации кода программы, деплой готового приложения под разные ОС.
А то скачал образ, открыл, потыкал в дерево классов, впечатлился и закрыл :)
А то скачал образ, открыл, потыкал в дерево классов, впечатлился и закрыл :)
Я постараюсь в ближайший месяц наваять что ни будь подобное. Как ни смешно, самое сложное придумать сценарий. То есть «а что конкретно собрать такое что бы и осмысленно и недолго». У меня в связи с моим проектом уже набрался достаточно большой опыт в написании видео уроков, но всегда это самая большая проблема. Первый видео урок по проекту получился полтора часа, и из шести с половиной тысяч просмотревших только 5% просмотрели до конца. Очень сложно сделать так что бы это было не громоздко, не долго и более менее законченно.
А каким местом Pharo не на том уровне?
Возможно я не так выразился. Как среда разработки именно под Smalltalk он хорош. Я имел в виду интеграцию с остальным рабочим окружением. Современные интерфейсы это не только и не столько «кнопочки и галочки», сколько сервисы.
Взять тот же Qt. Помимо собственно графической подсистемы, он предоставляет большие возможности по взаимодействию с окружающим миром. Особенно если это заметно на уровне KDE.
Взять тот же Qt. Помимо собственно графической подсистемы, он предоставляет большие возможности по взаимодействию с окружающим миром. Особенно если это заметно на уровне KDE.
Все равно не понимаю мысль…
У Smalltalk-а очень долго было и до сих пор остается много «детских» болезней. Pharo как раз — попытка все это решить и сделать, наконец, нормальный рабочий Smalltalk так сказать «на современном уровне». Пока, на мой взгляд, все идет неплохо… Я бы даже сказал, лучше, чем можно было ожидать.
У Smalltalk-а очень долго было и до сих пор остается много «детских» болезней. Pharo как раз — попытка все это решить и сделать, наконец, нормальный рабочий Smalltalk так сказать «на современном уровне». Пока, на мой взгляд, все идет неплохо… Я бы даже сказал, лучше, чем можно было ожидать.
Современный язык должен поддерживать многопоточность. Оставаться только на грин тредах это не дело. Во-вторых, нативные виджеты. В третьих JIT. Можно сколько угодно говорить, что смолток не для этого, но мне кажется это только провоцирует изоляцию.
Вы случайно не знаете подробностей по поводу поддержки многопоточности и JIT в CogVM? В образе есть нечто под названием AsmJIT, но непонятно, насколько оно функционально.
Вы случайно не знаете подробностей по поводу поддержки многопоточности и JIT в CogVM? В образе есть нечто под названием AsmJIT, но непонятно, насколько оно функционально.
Современный язык должен поддерживать многопоточность. Оставаться только на грин тредах это не дело.
Это — да. Точнее, есть нюансы и варианты, но в целом я, скорее, соглашусь. Однако это проблема не Pharо/Squeak, а всех Smalltalk-ов.
Во-вторых, нативные виджеты. В третьих JIT. Можно сколько угодно говорить, что смолток не для этого, но мне кажется это только провоцирует изоляцию.
Я думал, мы именно особенности Pharo обсуждаем… А так — да, все это слабые места современного Smalltalk-а. Опять же, есть всякие оговорки и отговорки, но это все пока разговоры в пользу бедных. Многим все это не позволяет серьезно использовать Smalltalk. Но некоторым и не мешает.
Вы случайно не знаете подробностей по поводу поддержки многопоточности и JIT в CogVM? В образе есть нечто под названием AsmJIT, но непонятно, насколько оно функционально.
Деталей не знаю, тема для меня слишком сложная :) За все не уследить… А так, вроде, какие-то неплохие подвижки в эту сторону идут, судя по перепискам в Smalltalk-овских листах и докладам на конференциях.
Однако это проблема не Pharо/Squeak, а всех Smalltalk-ов.Во-первых, пролетали новости о том что в BeeSmalltalk якобы делали поддержку реальной многопоточности чуть ли не в пару десятков строк.
Во-вторых, еще лет несколько назад где то видел препринты статьи о том что делали акторную систему на базе многопоточного смолтока и рапортовали об успешной работе в сильно многопроцессорной системе (64 процессора, если не ошибаюсь).
Наконец мы в llst.org планируем реализовать честную многопоточность, правда пока не ясно какого рода ограничения это наложит. Возможно придется делать отдельные кучи и обмен объектами между потоками будет ограничен.
Деталей не знаю, тема для меня слишком сложная :) За все не уследить… А так, вроде, какие-то неплохие подвижки в эту сторону идут, судя по перепискам в Smalltalk-овских листах и докладам на конференциях.Проблема в том, что судя по тому коду что я видел, это банальный и печальный велосипед — ручное генерирование x86 инструкций. Никакой абстракции над архитектурой нет в принципе, не говоря уже про оптимизации. А делать банальную трансляцию байткодов смолтока в x86 это не самая удачная мысль. Как показали наши тесты, оно будет не быстрее прямой интерпретации.
Про пчелку в курсе, но там ничего пока не ясно же? Похожих многообещающих в плане решения глобальных проблем проектов было много, но воз и ныне там… Проблема существует, люди над ней работают, но решающего ее полноценного промышленного Smalltalk-а пока никто не видел…
Кстати, есть альтернатива. Проблема же на самом деле не в том, чтобы внести в Smalltalk нативную многопоточность как таковую (не такая уж она и хорошая, умные люди говорят), а дать возможность распределять процессорную нагрузки по ядрам, верно ведь? А это можно сделать, запуская несколько образов, если дать им возможность между собой нормально общаться, разумеется. В Cincom-е уже несколько лет такое решение существует. Восторгов правда почему-то не слышно :)
По поводу JIT-а, к сожалению, ничего конкретного сказать не могу — не компетентен. Хотелось бы, конечно, «нормальный» Smalltalk — который мог бы менять любую свою часть «на лету», в том числе и этот аспект… Мечты :)
Кстати, есть альтернатива. Проблема же на самом деле не в том, чтобы внести в Smalltalk нативную многопоточность как таковую (не такая уж она и хорошая, умные люди говорят), а дать возможность распределять процессорную нагрузки по ядрам, верно ведь? А это можно сделать, запуская несколько образов, если дать им возможность между собой нормально общаться, разумеется. В Cincom-е уже несколько лет такое решение существует. Восторгов правда почему-то не слышно :)
По поводу JIT-а, к сожалению, ничего конкретного сказать не могу — не компетентен. Хотелось бы, конечно, «нормальный» Smalltalk — который мог бы менять любую свою часть «на лету», в том числе и этот аспект… Мечты :)
Не для каждой задачи подойдет вариант «просто запустить N образов». Тупо разбрасывать пользователькие запросы по инстансам — это да. А вот параллельно пройтись несколькими потоками по общему графу уже не получится.
Передача данных между ними будет возможна или посредством сериализации (прощай скорость), или очень ограниченным набором данных (например только замороженные объекты содержащие литеральные константы).
Честные потоки хороши тем, что отдельные параллельные треды находятся в общем адресном пространстве и могут разделять объемные данные без накладных расходов (кроме синхронизации).
Передача данных между ними будет возможна или посредством сериализации (прощай скорость), или очень ограниченным набором данных (например только замороженные объекты содержащие литеральные константы).
Честные потоки хороши тем, что отдельные параллельные треды находятся в общем адресном пространстве и могут разделять объемные данные без накладных расходов (кроме синхронизации).
Ясно, что есть разные модели организации параллельных вычислений, многое зависит от задачи, что разделяемая память имеет преимущества и недостатки, и да, потоки тоже бывают полезны, но есть еще и всякие кластеры, распределенные системы и т.д.… И что сейчас многое пересматривается, изменяется и изобретается заново :)
Но я не специалист (к моему огромному сожалению) в этой области, тем более в технических деталях — не в состоянии поддержать беседу, и сливаюсь :)
Да и мы уклонились от исходной темы, вроде… В общем: в Smalltalk-сообществе признают проблему и что-то делают по поводу ее решения. Сам с удовольствием бы почитал какой-нибудь обзор на эту тему.
Но я не специалист (к моему огромному сожалению) в этой области, тем более в технических деталях — не в состоянии поддержать беседу, и сливаюсь :)
Да и мы уклонились от исходной темы, вроде… В общем: в Smalltalk-сообществе признают проблему и что-то делают по поводу ее решения. Сам с удовольствием бы почитал какой-нибудь обзор на эту тему.
A JIT то чего? Вы про just-in-time compilation? Так это есть. Более того, это многие аспекты JIT пришли в большой мир из Smalltalk
Кстати, ваша статья очень хороша — все аккуратно расставляет по полочкам, побольше бы таких. Всем (ну как всем… тем, кто хочет узнать что-то новое, даже если это его никоим боком сейчас не касается, как Smalltalk меня) рекомендую. Жаль, на момент прочтения срок голосования уже истек.
Спасибо за обзор. Было бы интересно прочитать продолжение про web-приложение на SmallTalk.
Кстати, по поводу «Программирования через дебаг» вспомнил, что делаю так же в Chrome Dev Tools для JS :)
Заранее извиняюсь. После прочтения всего выше сказанного, чем Smalltalk приятнее Python (не говорю лучше)?
Прошу мнения автора, который хорошо знает Smalltalk ну и глянуть на синтаксис Python дело пары минут. :)
Прошу мнения автора, который хорошо знает Smalltalk ну и глянуть на синтаксис Python дело пары минут. :)
Навскидку и скорую руку:
Простотой базовых идей: Smalltalk — чистая объектность чусть подпорченная классами. Питон (если не ошибаюсь, ориентируясь на википедию) — еще один «мультипарадигматический» язык.
Простотой синтаксиса: Smalltalk — (почти) только посылка сообщений + чуть-чуть сахара. Наглядно видно на 'if'-ах, которые в Smalltalk-е — просто методы. Не все так идеально в Smalltalk, но гораздо лучше, чем где бы ты ни было (из известного мне).
«Образностью» :) Smalltalk-а — в том смысле, что все объекты живут в общей среде; все этом можно в любой момент сохранить, а потом продолжить с той точки, где сохранились. Такой бесплатный базовый персистенс. Жаль только пока (надеюсь) дальше не развивают. Но и сейчас в принципе можно разработать приложение не думая о БД совсем, а потом перенести его в среду с полноценной (лучшей до сих пор?) объектной СУБД (я про GemStone).
Изначальной ориентированностью Smalltalk на то, чтобы быть средой разработки (а не только компилятором) —> до сих пор непревзойденные возможности разработки. И это несмотря не только на «90-сть GUI», но и на то, что процентов 95% потенциала среды до сих пор не раскрыто.
Подозреваю, что мета-возможности Smalltalk более естественны и просты. Классический пример — добавление континуаций без каких-либо изменений в языке.
В целом, отличия Smalltalk-а от Python-а — примерно такие же, как отличия Smalltalk-а от любого современного мейн-стримового языка :) То есть, принципиальные.
Простотой базовых идей: Smalltalk — чистая объектность чусть подпорченная классами. Питон (если не ошибаюсь, ориентируясь на википедию) — еще один «мультипарадигматический» язык.
Простотой синтаксиса: Smalltalk — (почти) только посылка сообщений + чуть-чуть сахара. Наглядно видно на 'if'-ах, которые в Smalltalk-е — просто методы. Не все так идеально в Smalltalk, но гораздо лучше, чем где бы ты ни было (из известного мне).
«Образностью» :) Smalltalk-а — в том смысле, что все объекты живут в общей среде; все этом можно в любой момент сохранить, а потом продолжить с той точки, где сохранились. Такой бесплатный базовый персистенс. Жаль только пока (надеюсь) дальше не развивают. Но и сейчас в принципе можно разработать приложение не думая о БД совсем, а потом перенести его в среду с полноценной (лучшей до сих пор?) объектной СУБД (я про GemStone).
Изначальной ориентированностью Smalltalk на то, чтобы быть средой разработки (а не только компилятором) —> до сих пор непревзойденные возможности разработки. И это несмотря не только на «90-сть GUI», но и на то, что процентов 95% потенциала среды до сих пор не раскрыто.
Подозреваю, что мета-возможности Smalltalk более естественны и просты. Классический пример — добавление континуаций без каких-либо изменений в языке.
В целом, отличия Smalltalk-а от Python-а — примерно такие же, как отличия Smalltalk-а от любого современного мейн-стримового языка :) То есть, принципиальные.
Что с графикой и скоростью работы? То есть легко ли подрубить OpenGL или DirectX, и насколько быстро работают приложения?
(для сравнения Delphi — очень удобен, но игру всё-таки лучше писать на C++)
(для сравнения Delphi — очень удобен, но игру всё-таки лучше писать на C++)
Кесарю — кесарево, богу — богово.
Не надо писать игр на smalltalk. Он не для этого.
Давайте я расставлю точки над i
Плюсы:
Основное преимущество St — это офигительное, удобное конструирование. Вам будет легко выделить классы, построить взаимодействие между ними, увидеть как это работает. Представьте себе прозрачный двигатель внутреннего сгорания — вы увидете как взаимодействуют объекты внутри вашей программы. Вы сможете в лобой момент сказать двигателю «замри», подкрутить в нём что-то, изменить поведение объекта, и сказать «отомри» и он пойдет работать с всеми изменениями. Язык предоставляет исключительные возможности по конструированию.
Это преимущество вытекает из следующих предпосылок:
1. Синтаксис близкий к английскому языку. Сравните вызов метода в обобщенной сигнатуре для основных ЯП:
2. Основной инструмент IDE — class browser. Непревзойденный инструмент для работы с кодом. Позволяет абстрагироваться от бесконечных файлов и их содержимого. Вы видите только список пакетов, классов в них, методов в классе и реализацию выбранного метода. Очень удобно.
Мне этого не хватает в ruby/js
3. Отличная поддержка рефакторинга. В современных IDE это тоже есть, но скорее для галочки. Здесь это один из основных инструментов.
Минусы:
St — это не C++ и скорости ожидать не надо. По производительности он сравним с Java/C#.
Не надо писать сложные веб приложения на нем с rich client-side, поддержка JS бибилотек есть, но работать с ней неудобно. Возможно, это чисто мое имхо. Мне могут возразить, что вот у нас есть знаменитый Seaside web framework, только что с того? В общем для веба — не он.
Заключение: превосходен для прототипирования сложных объектных систем энтерпрайз уровня. Вырабатывает отличные скиллы по ООП.
Не надо писать игр на smalltalk. Он не для этого.
Давайте я расставлю точки над i
Плюсы:
Основное преимущество St — это офигительное, удобное конструирование. Вам будет легко выделить классы, построить взаимодействие между ними, увидеть как это работает. Представьте себе прозрачный двигатель внутреннего сгорания — вы увидете как взаимодействуют объекты внутри вашей программы. Вы сможете в лобой момент сказать двигателю «замри», подкрутить в нём что-то, изменить поведение объекта, и сказать «отомри» и он пойдет работать с всеми изменениями. Язык предоставляет исключительные возможности по конструированию.
Это преимущество вытекает из следующих предпосылок:
1. Синтаксис близкий к английскому языку. Сравните вызов метода в обобщенной сигнатуре для основных ЯП:
paintItemsInArea(array, canvas, rectangle)
paintItems: array on: canvas at: rectangle
2. Основной инструмент IDE — class browser. Непревзойденный инструмент для работы с кодом. Позволяет абстрагироваться от бесконечных файлов и их содержимого. Вы видите только список пакетов, классов в них, методов в классе и реализацию выбранного метода. Очень удобно.
Мне этого не хватает в ruby/js
3. Отличная поддержка рефакторинга. В современных IDE это тоже есть, но скорее для галочки. Здесь это один из основных инструментов.
Минусы:
St — это не C++ и скорости ожидать не надо. По производительности он сравним с Java/C#.
Не надо писать сложные веб приложения на нем с rich client-side, поддержка JS бибилотек есть, но работать с ней неудобно. Возможно, это чисто мое имхо. Мне могут возразить, что вот у нас есть знаменитый Seaside web framework, только что с того? В общем для веба — не он.
Заключение: превосходен для прототипирования сложных объектных систем энтерпрайз уровня. Вырабатывает отличные скиллы по ООП.
Не надо писать игр на smalltalk. Он не для этого.
Могу ошибаться, но по слухам в Транзасе довольно долго делали симуляторы и всякую виртуальную реальность на Smalltalk-е, пользуясь тем фактом, что «сверх-скорость» нужна не везде. Да и игры бывают разные… Не все так однозначно.
Не надо писать сложные веб приложения на нем с rich client-side, поддержка JS бибилотек есть, но работать с ней неудобно. Возможно, это чисто мое имхо. Мне могут возразить, что вот у нас есть знаменитый Seaside web framework, только что с того? В общем для веба — не он.
Видели Amber?
Могу ошибаться, но по слухам в Транзасе довольно долго делали симуляторы и всякую виртуальную реальность на Smalltalk-е, пользуясь тем фактом, что «сверх-скорость» нужна не везде. Да и игры бывают разные… Не все так однозначно.
Я работал в Транзасе в той самой виртуальной реальности (Trans-Force). Симулятор, это речь о вертолетном тренажере.
Работа с этими проектами на Smalltalk и сейчас ведется (два года назад точно велась).
В обоих проектах Smalltalk используется для написания управляющей программы. За вертолетный тренажер не скажу точно, но, вроде, они все моделирование физики поведения вертолета в Smalltalk перевели. Могу ошибиться. Управление комплексом Trans-Force все написано на St. А теперь жирное НО. Сама визуализация трехмерного пространства (полета) — это другая среда, вроде, называлась «Аврора». На чем написана не знаю, но это не smalltalk.
Amber видел. Пока как приложить к веб-проектам не знаю. Скажите, вот есть meteorjs, мне он нравится. Как его можно использовать вместе с Amber? Если никак, то пока он неинтересен.
Amber+Meteor? Надо подумать. Но не факт, что это даст упрощение процесса
Я работал в Транзасе в той самой виртуальной реальности (Trans-Force). Симулятор, это речь о вертолетном тренажере.
Я знал! Я знал! :)
А теперь жирное НО. Сама визуализация трехмерного пространства (полета) — это другая среда, вроде, называлась «Аврора». На чем написана не знаю, но это не smalltalk.
Я же об этом и говорю: Smalltalk-у есть место и в играх, не самое маловажное место.
Amber видел. Пока как приложить к веб-проектам не знаю. Скажите, вот есть meteorjs, мне он нравится. Как его можно использовать вместе с Amber? Если никак, то пока он неинтересен.
Не в курсе, что такое meteorjs. Но, скорее всего, как и с любой другой JS-библиотекой. Вопрос, нужно ли — вполне возможно, amber и meteorjs являются конкурентами? Предлагаю продолжить обсуждение в RSUG-е :)
Amber хоть красив и интересно сделан на современных механизмах, но пока это отдельная вещь в себе.
Спасибо за статью.
Давно присматриваюсь к этому языку, но есть вещи останавливающие меня. Прошу знатоков ответить на эти вопросы (сам я новичок, поэтому вопросы могут посчитаться кем-то глупыми):
1. Возможно ли на этапе выпуска приложения почистить автоматически образ от всего лишнего, оставив только действительно необходимое для работы программы? Там ведь хранится куча неиспользованного. Образы тяжеловесные. Я видел у того же Pharo минимальный образ в 2-3МБ, но это не совсем то, хотелось бы примерный аналог жёсткой компиляции когда выкидывается всё лишнее.
2. Возможно ли изменить синтаксис средствами языка? Скажем я хочу переназначить «:=» на другой знак. Если да, то как это сделать? Отталкивает синтаксис smalltalk, но само устройство интересно.
3. Возможно ли морду привести к системному виду? Чтобы автоматом бралась тема системы, может какие-то наработки уже есть? Биндинги в другие морды? (Tk, Qt и т. п.). Для Qt я нашёл только мёртвые ссылки под GNU Smalltalk.
4. В тексте упоминалась возможность работать с файлами вместо образа, как это сделать? Нашлась только интеграция с CVS/Git.
5. Насколько между собой совместимы разные ВМ/платформ? Их существует множество: GNU Smalltalk, Squeak, Pharo, VisualWorks, Dolphin… В чём в основном их различия? Сложно ли переносить код написанный под одной ВМ на другую?
С чего вообще стоит начать новичку? Где искать чужие наработки? Гугл-то находит далеко не всё.
Давно присматриваюсь к этому языку, но есть вещи останавливающие меня. Прошу знатоков ответить на эти вопросы (сам я новичок, поэтому вопросы могут посчитаться кем-то глупыми):
1. Возможно ли на этапе выпуска приложения почистить автоматически образ от всего лишнего, оставив только действительно необходимое для работы программы? Там ведь хранится куча неиспользованного. Образы тяжеловесные. Я видел у того же Pharo минимальный образ в 2-3МБ, но это не совсем то, хотелось бы примерный аналог жёсткой компиляции когда выкидывается всё лишнее.
2. Возможно ли изменить синтаксис средствами языка? Скажем я хочу переназначить «:=» на другой знак. Если да, то как это сделать? Отталкивает синтаксис smalltalk, но само устройство интересно.
3. Возможно ли морду привести к системному виду? Чтобы автоматом бралась тема системы, может какие-то наработки уже есть? Биндинги в другие морды? (Tk, Qt и т. п.). Для Qt я нашёл только мёртвые ссылки под GNU Smalltalk.
4. В тексте упоминалась возможность работать с файлами вместо образа, как это сделать? Нашлась только интеграция с CVS/Git.
5. Насколько между собой совместимы разные ВМ/платформ? Их существует множество: GNU Smalltalk, Squeak, Pharo, VisualWorks, Dolphin… В чём в основном их различия? Сложно ли переносить код написанный под одной ВМ на другую?
С чего вообще стоит начать новичку? Где искать чужие наработки? Гугл-то находит далеко не всё.
1. Да возможно очищение. Но жесткое вряд ли. Поскольку язык динамической типизации, то самостоятельно определить, что выкидывать, а что нет он не в состоянии.
2. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.
3. Можно. Иногда это не будет 1 в 1, но что-то похожее. Так как GUI все таки не native
4. Нет, нельзя. То что вы упоминаете, всего лишь возможность выгрузки пакетов в файлы для интеграции с GIT. Собственные репозитарии кода более удобны для просмотра изменений (версионность базируется на методе, не на файле); Плюшек типа pull request нету
5. Переносить не очень сложно, но различия существуют.
Начинать лучше с Pharo (pharo.org) — относительно большое и отзывчивое коммьюнити, наиболее прогрессивный диалект
2. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.
3. Можно. Иногда это не будет 1 в 1, но что-то похожее. Так как GUI все таки не native
4. Нет, нельзя. То что вы упоминаете, всего лишь возможность выгрузки пакетов в файлы для интеграции с GIT. Собственные репозитарии кода более удобны для просмотра изменений (версионность базируется на методе, не на файле); Плюшек типа pull request нету
5. Переносить не очень сложно, но различия существуют.
Начинать лучше с Pharo (pharo.org) — относительно большое и отзывчивое коммьюнити, наиболее прогрессивный диалект
2. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.Уточню, что если очень-очень хочется, то можно — для этого придётся изменить компилятор (он написан на самом Smalltalk, живёт в том же самом образе, и вызывается при сохранении метода). Но лучше этого не делать.
Любопытно. А где например его можно посмотреть? Точнее как он конкретно называется? Где-то можно прочитать про низкоуровневую архитектуру Smalltalk? Для меня открытие что там внутри компилятор сидит написанный на самом Smalltalk.
В некоторых случаях даже виртуалка написана на Smalltalk (его подмножестве).
Могу посоветовать мои статьи по архитектуре LittleSmalltalk. Надо только сразу оговориться, что LittleSmalltalk не поддерживает стандарт Smalltalk80, хотя для понимания базовых принципов это не нужно.
1. То что динамический понятно, но есть же профилировщики, как например тут на 5 шаге. Можно было бы использовать подобный подход чтобы определить что и как используется, после чего отбросить всё лишнее, транслировав исходные коды в байткоды для компактности (хотя я не ковырял образ, может там уже полный байткод).
4. Просто я увидел фразу в статье:
В целом ясно, спасибо за ответ.
4. Просто я увидел фразу в статье:
Образ системы является основным контейнером информации в Smalltalk — т.е. в Smalltalk не приняты текстовые файлы с исходным кодом. В принципе, их можно создавать, но работать с образом системы гораздо удобнее.Это ошибка?
В целом ясно, спасибо за ответ.
1. То что динамический понятно, но есть же профилировщики, как например тут на 5 шаге. Можно было бы использовать подобный подход чтобы определить что и как используется, после чего отбросить всё лишнее, транслировав исходные коды в байткоды для компактности (хотя я не ковырял образ, может там уже полный байткод).
Анализ в динамических языках тоже, разумеется, возможен. Есть всякие наработки на данную тему. Но именно про такой инструмент я не слышал. В VisualWorks, насколько помню, это делается частично автоматически, но без участия человека может получится не очень хорошо в сложных случаях.
Что Вы на нём пишете?
Ну прежде всего первый мой проект на смолтолке Cadel. Сейчас я уже в нем не участвую, но был одним из «родителей». Мой текущий проект FLProg. И сама программа и сайт написаны на смолтолке. Этот проект я разрабатываю один, и на другом языке боюсь бы у меня это не получилось. Ну еще много различных полезных программок как говорится «для вутреннего потребления» создано за эти годы.
жду, жду, а каммент тут :-)
Вы просто жмите «ответить» в теле каммента, чтобы получился ответ в нужном месте
Cadel — скачать можно только после регистрации, а скринов нет
FLProg, конечно, впечатляет.
Вы просто жмите «ответить» в теле каммента, чтобы получился ответ в нужном месте
Cadel — скачать можно только после регистрации, а скринов нет
FLProg, конечно, впечатляет.
Да простят меня мои бывшие работодатели:Cadel
Я тоже в своё время влюбился в этот язык программирования. Удивительно, что с 80-х годов синтаксис и основные принципы работы языка практически не изменились. То есть, изначально Алан Кей достал бритву Окама и сделал простой и одновременно мощный язык, который легко расширять (добавление Try-Catch конструкций можно сделать средствами самого языка, не вводя новых ключевых слов и не меняя виртуальную машину), и который объектно-ориентированный до мозга костей (в отличие от той же Java, где есть int, boolean и float, выпадающие из общей идеи «всё есть объект»). Плюс всё динамическое: можно добавлять/удалять классы и менять методы прямо в процессе работы приложения. Рекомендую пройти какой-нибудь туториал по этому языку. Он заставляет мозг работать немного по другому и прививает «чистый» ООП стиль программирования.
Конечно у Smalltalk есть недостатки. В частности меня смущает образ системы, внутри которого «живёт» виртуальная машина и управляет объектами.
totuin, подскажите, как происходит deployment приложения на сервер? Вы закачиваете готовый образ системы и запускаете VM с этим образом? Или рабочий сервер выкачивает исходный код из базы и компилирует его на лету?
Конечно у Smalltalk есть недостатки. В частности меня смущает образ системы, внутри которого «живёт» виртуальная машина и управляет объектами.
totuin, подскажите, как происходит deployment приложения на сервер? Вы закачиваете готовый образ системы и запускаете VM с этим образом? Или рабочий сервер выкачивает исходный код из базы и компилирует его на лету?
У меня на сервере работает открытый образ разработчика (сервер на Win Server 2008 r2, доступ по RDP). Это позволяет на лету дорабатывать сайт без остановки сервера. При создании новых страниц я сначала ссылку на них создаю только для администратора сервера (то есть для меня), а после готовности открываю для всех. А вот бэкапер сайта представляет собой независимое приложение, в виде Run Time образа и своим UI.
Как говорил Н. Вирт:
Smalltalk годится чтобы учить возить черепашку по экрану. В остальном бесполезен.
Информация из википедии:
Вирт, Никлаус
Судя по его разработкам для него тяжело было понятие объектно ориентированого программирования основанного на событиях и сообщениях. Наверно этим и вызвано его высказывание. В то время вообще к ООП относились настороженно, но в конце — концов можно сказать что оно победило.
В том же Паскале (нынче Delphi), ООП до сих пор прикручено где то сбоку.
Вирт, Никлаус
В 1970 году создал язык программирования Паскаль. В 1970-х годах разработал, вместе с Хоаром и Дейкстрой технологию структурного программирования. Вышедшая в 1971 году статья Вирта «Разработка программы методом пошагового уточнения» описала и обосновала ставшую впоследствии классической методологию разработки программного обеспечения «сверху вниз».
В 1975 году разработал язык Модула, в котором реализовал идеи разработки модульных программ с хорошо определёнными межмодульными интерфейсами и параллельного программирования. Кроме того, в Модуле был изменён синтаксис языка — Вирт избавился от унаследованной ещё от Алгола-60 необходимости применять составные операторы в конструкциях ветвления и циклах.
Судя по его разработкам для него тяжело было понятие объектно ориентированого программирования основанного на событиях и сообщениях. Наверно этим и вызвано его высказывание. В то время вообще к ООП относились настороженно, но в конце — концов можно сказать что оно победило.
В том же Паскале (нынче Delphi), ООП до сих пор прикручено где то сбоку.
Цитата 2005-го года, так что у всех было время оценить результаты.
Хотя, вот цитата из 1998-го:
Хотя, вот цитата из 1998-го:
Объектно-ориентированное программирование вышло из принципов и понятий традиционного процедурного программирования. Скажу больше: в ООП не добавлено ни одного действительно нового понятия; просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое — это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов «объект» и «метод». Средством для такой привязки является процедурная переменная (или поле записи — record field), доступная в языках программирования с середины 70-х гг. Второе понятие — это конструирование нового типа данных (названного «подкласс») путем расширения заданного типа («суперкласс»).Как мы можем увидеть, все не так грустно, как Вы предположили из статьи Википедии. На этом можно закрыть тему непонимания Н. Виртом ООП.
Стоит заметить, что вместе с ООП пришла совершенно новая терминология, имевшая целью затемнить происхождение его корней. Таким образом, если раньше вы могли инициировать активность процедуры путем ее вызова, то теперь должны посылать сообщение методу.
Скажите, вы, говоря про черепашку на экране, не спутали Smalltalk с Logo? Вроде черепахи это там.
1) Это цитата Н. Вирта
2) Черепашка это же языконезависимый исполнитель.
Если хотите моё мнение, то оно такое: любой язык с такими выдающимися качествами как:
2) Черепашка это же языконезависимый исполнитель.
Если хотите моё мнение, то оно такое: любой язык с такими выдающимися качествами как:
Все переменные в объектах являются указателями.
Во-вторых Smalltalk – динамически типизированный язык. То есть в любую переменную можно положить ссылку на инстанс объекта любого класса.вообще нет смысла рассматривать как нечто стоящее людских усилий. Но если завалить его деньгами, то вполне получится какой-нибудь веселый кадавр, типа javascript.
По-моему, ее действительно можно закрыть этой цитатой, поскольку Вирт явно расписался в своем непонимании объектного подхода.
Не, я не хочу сказать, что я вот такой умный и понимаю, а Вирт такой тупой и не понимает :) Просто он действительно «не просек фишку» по каким-то причинам.
Не, я не хочу сказать, что я вот такой умный и понимаю, а Вирт такой тупой и не понимает :) Просто он действительно «не просек фишку» по каким-то причинам.
А в чем фишка?
В сообщениях, если коротко.
Все же стоит разделять термины «передача сообщения объекту», который однозначно трактуется только внутри парадигмы ООП, и понятия процедурного программирования «вызов процедуры/функции каким-то образом привязанной к экземпляру структуры и передача ей набора параметров».
Поэтому и непонятно, в чем же тут фишка? Просто в новых словах?
Вот и Вирту, было не понятно :) А вы хотите, чтобы я здесь в комменте раскрыл вопрос во всех аспектах?
Сообщение от вызова отличается тем, что в первом случае мы не знаем, как получатель отреагирует на это сообщение. Звучит странно, но это ставит программирование, как ни удивительно, с головы на ноги. Впрочем, не удивительно — ведь в реальной жизни все примерно так и обстоит, да?
Сказывается это и на «философии» программирования, и на языке, и на методах построения дизайна системы (я не про GUI)… это приводит к чему-то вроде TDD… Как побочный эффект — существенные, если не сказать принципиальные, отличия Smalltalk-а от, казалось бы, аналогичных языков… В общем я могу курс лекций по этому поводу прочитать (собственно, и читал до недавнего времени) :)
Сообщение от вызова отличается тем, что в первом случае мы не знаем, как получатель отреагирует на это сообщение. Звучит странно, но это ставит программирование, как ни удивительно, с головы на ноги. Впрочем, не удивительно — ведь в реальной жизни все примерно так и обстоит, да?
Сказывается это и на «философии» программирования, и на языке, и на методах построения дизайна системы (я не про GUI)… это приводит к чему-то вроде TDD… Как побочный эффект — существенные, если не сказать принципиальные, отличия Smalltalk-а от, казалось бы, аналогичных языков… В общем я могу курс лекций по этому поводу прочитать (собственно, и читал до недавнего времени) :)
Вы знаете, вот я в Блэкбоксе (BlackBox Component Builder, рантайм-среда для оберона) даже не пытаюсь узнать, как отреагирует на моё сообщение виджет, вставленный в контейнер, обёрнутый несколькими врапперами. Мне и не нужно знать, это же гетерогенная структура, я просто туда посылаю сообщение.
Мы и во втором случае не знаем. И догадок не делаем.
Ну, я бы сказал, что явное знание о вызываемом методе даёт нам детерминированность поведения. А сообщение можно обработать, а можно и не обработать. Концептуальный смысл «сообщения» вполне очевиден, вопрос в том, надо ли вводить в формальный аппарат дополнительную сущность или можно обойтись уже имеющимися инвариантами.
Все же, и в том и в другом случае мы имеем дело с одним принципом: черный ящик сам решает, какая связанная процедура вызывается в результате нашей попытки ее вызвать. Путь прохождения вызова так же нам безразличен. Но как видно из обсуждения, это в языке Smalltalk выведено из набора внеязыковых приемов и введено в язык.
Ну а привычка все тащить в язык давно известна. Чего стоит хотя бы эта картинка
Ну а привычка все тащить в язык давно известна. Чего стоит хотя бы эта картинка
«Syntax volume (N of lexems)» — это количество предопределенных синтаксических конструкций в языке?
Если так, то, видимо, постеснялись туда St поставить.
Там их гораздо меньше — три конструкции и 6 зарезервированных слов.
Перечислю конструкции (остальное по ссылке):
1. := (присваивание)
2. ^ (возврат результата из метода)
3. собственно отправка сообщения объекту
Все остальное, вся стандартная библиотека (все это if then else, loop operators/iterators, collections and so on) реализовано на самом St и доступно для изменения, если такое взбредет в голову.
Если так, то, видимо, постеснялись туда St поставить.
Там их гораздо меньше — три конструкции и 6 зарезервированных слов.
Перечислю конструкции (остальное по ссылке):
1. := (присваивание)
2. ^ (возврат результата из метода)
3. собственно отправка сообщения объекту
Все остальное, вся стандартная библиотека (все это if then else, loop operators/iterators, collections and so on) реализовано на самом St и доступно для изменения, если такое взбредет в голову.
И это не говоря про эзотерику всякую. И что?
Наверное, не постеснялись. Потому что синтаксис оценивался по РБНФ, а есть ли таковая для Smaltalk?
Пожалуйста, гугл в помощь
chronos-st.blogspot.de/2007/12/smalltalk-in-one-page.html
Возможно, вам будет интересно вот это
chronos-st.blogspot.de/2007/12/smalltalk-in-one-page.html
Возможно, вам будет интересно вот это
Вы будете смеяться, но РБНФ синтаксиса Оберона меньше, чем Smalltalk :)
И о чем это говорит?
Это говорит о том, что ваши слова «Там их гораздо меньше — три конструкции и 6 зарезервированных слов.» сделаны несколько сгоряча.
Попробуйте разобраться и понять, а не просто спорить.
Вот интересная ссылочка: code.uko.tymchuk.me/2013/02/grammars-complexity-comparison.html. Покажите такую диаграмму для Oberon-а и все увидят, насколько прост этот язык.
Вот интересная ссылочка: code.uko.tymchuk.me/2013/02/grammars-complexity-comparison.html. Покажите такую диаграмму для Oberon-а и все увидят, насколько прост этот язык.
И, самое интересное, со временем их не становится больше. Вот чудеса! :)
Когда есть некая тенденция, то наличие исключений, не попадающих под тенденцию, не отрицает тенденцию.
Вас задело, что куча языков на одном графике? Типа, «нашли что сравнивать, вот в языке Му всего одно ключевое слово Му». Ну нарисуйте каждому языку по своему графику, и все равно там будет разрастание рбнф-описания.
Вас задело, что куча языков на одном графике? Типа, «нашли что сравнивать, вот в языке Му всего одно ключевое слово Му». Ну нарисуйте каждому языку по своему графику, и все равно там будет разрастание рбнф-описания.
Простите, а вы что доказать-то хотите?
Что ООП фигня? Что Оберон круче всех? Что именно?
Что ООП фигня? Что Оберон круче всех? Что именно?
Не ставил себе такой цели. Мы тут рассуждаем про соотношение терминологий внутри всевозможных методик и про отношение этих терминологий к базовым понятиям сферы нашей общей деятельности. Если вас это утомляет и вы хотите перейти к конфликту религиозного свойства, то пожалуйста. В отдельной ветке.
Тут утверждается, что 1) Вирт не понял ООП и 2) В смолтоке всего три необходимых конструкции. Оба этих тезиса, скажем так, ни к селу ни к городу.
Троллинг становится уже не толстым, а откровенно жирным :)
Вирт:
После этого читаем «History of Smalltalk», гуглим цитаты Алана Кэя про его(!) объектный подход, и, наконец, думаем!
Вирт:
ООП <…> просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое — это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов «объект» и «метод». Средством для такой привязки является процедурная переменная (или поле записи — record field), доступная в языках программирования с середины 70-х гг. Второе понятие — это конструирование нового типа данных (названного «подкласс») путем расширения заданного типа («суперкласс»).
После этого читаем «History of Smalltalk», гуглим цитаты Алана Кэя про его(!) объектный подход, и, наконец, думаем!
Алан Кей в своей «Ранней истории Smalltalk» выдвигает интересный концепт вычислительной системы, построенной из элементов, похожих на биологические клетки или монады Лейбница. Эти элементы коммуницируют между собой, формируя какое угодно поведение, и позволяют строить легко расширяемые системы.
Алан Кей вводит понятие класса, который заключает в себе поведение всех его экземпляров. Вот здесь понятие класса немного уточняется — естественно, не меняя сути.
Вирт говорит именно про это. Привязываем методы к структуре, позволяем наследоваться и получаем классы Алана Кея.
Довольно очевидные вещи.
Алан Кей вводит понятие класса, который заключает в себе поведение всех его экземпляров. Вот здесь понятие класса немного уточняется — естественно, не меняя сути.
Вирт говорит именно про это. Привязываем методы к структуре, позволяем наследоваться и получаем классы Алана Кея.
Довольно очевидные вещи.
Так, вам же и объясняют, что в Smalltalk-е все не так! :)
Там всего несколько действительно необходимых синтаксических конструкций, навскидку: посылка сообщения, присваивание (его тоже можно сделать сообщением, но это будет не совсем Smalltalk) и возврат (тоже можно сделать сообщением, кстати)… Может что-то забыл, но, по сути, все! Остальное — «сахар».
Любые конструкции и операторы типа ветвления, циклов, а также структуры навроде замыканий, континуаций, сопрограмм и т.д. — все добавляется не в язык, и никаких изменений/дополнений языка не требуется!
А тенденция — она есть, да. Может быть, Oberon, как и Smalltalk, ее преодолевает. Но только по первым страницам описания я этого не увидел — в отличие от Smalltalk-а, где идея вылезает сразу и уже больше не дает спокойно жить. Если это есть в Oberon-е, если это не еще один банальный наследник Algol-а — пишите статью, будет очень интересно об этом узнать
Там всего несколько действительно необходимых синтаксических конструкций, навскидку: посылка сообщения, присваивание (его тоже можно сделать сообщением, но это будет не совсем Smalltalk) и возврат (тоже можно сделать сообщением, кстати)… Может что-то забыл, но, по сути, все! Остальное — «сахар».
Любые конструкции и операторы типа ветвления, циклов, а также структуры навроде замыканий, континуаций, сопрограмм и т.д. — все добавляется не в язык, и никаких изменений/дополнений языка не требуется!
А тенденция — она есть, да. Может быть, Oberon, как и Smalltalk, ее преодолевает. Но только по первым страницам описания я этого не увидел — в отличие от Smalltalk-а, где идея вылезает сразу и уже больше не дает спокойно жить. Если это есть в Oberon-е, если это не еще один банальный наследник Algol-а — пишите статью, будет очень интересно об этом узнать
Ну вот сказали, для чего годится эта идея.
Ну, раз вы так настаиваете. Скажите пожалуйста, где и когда Вирт это сказал?
В 2005 году, на лекции в Москве.
Свидетельские показания будут? :) (Не обязательно, шучу)
Вообще, от Вирта можно было бы ожидать более широкого кругозора :) Если вы тоже реально не в курсе, посмотрите хотя бы раздел Influences в википедийной статье про Smalltalk и/или это почитайте.
Вообще, от Вирта можно было бы ожидать более широкого кругозора :) Если вы тоже реально не в курсе, посмотрите хотя бы раздел Influences в википедийной статье про Smalltalk и/или это почитайте.
Вирт — практик. Его разработки использовались и используются в авиации, управлении дорожным движением, электростанциях и пр.
Теоретические изыски «всё есть объект» так и остались теоретическими, не так ли?
Теоретические изыски «всё есть объект» так и остались теоретическими, не так ли?
Я иногда не понимаю, вы шутите так?
Про «технологический» след Smalltalk-а я ранее комментировал.
Вот примеры использования Smalltalk-а (в кучи и относительно старые, и новые):
www.esug.org/wiki/pier/Smaltalk/Companies
www.cincomsmalltalk.com/main/successes
gemtalksystems.com/about/customers
www.goodstart.com/who-uses-smalltalk.shtml
Ну, и знаменитое: «it is almost certain that the chip in your smart phone was built by fab machines whose control system (GUI and scheduler) is implemented in Smalltalk»
Про «технологический» след Smalltalk-а я ранее комментировал.
Вот примеры использования Smalltalk-а (в кучи и относительно старые, и новые):
www.esug.org/wiki/pier/Smaltalk/Companies
www.cincomsmalltalk.com/main/successes
gemtalksystems.com/about/customers
www.goodstart.com/who-uses-smalltalk.shtml
Ну, и знаменитое: «it is almost certain that the chip in your smart phone was built by fab machines whose control system (GUI and scheduler) is implemented in Smalltalk»
Да, хорошая подборка, нечего сказать. Единственно, что можно добавить — очень много ссылок 15-летней давности, видимо, как-то связано с интенсивным развитием инструментария типа Visual Smalltalk в те годы. Ну а с унаследованной системы довольно трудно спрыгнуть, вот и держатся.
В любом случае, приятно видеть, что концепция Алана Кея живёт и не погибает.
В любом случае, приятно видеть, что концепция Алана Кея живёт и не погибает.
Вы знаете, РБНФ смолтока ясно показывает устройство синтаксиса. Поэтому ваше высказывание про «всего несколько необходимых конструкций» остаётся слишком легковесным.
Вы посмотрите внимательнее на указанные формулы, а не только на количество строк в них.
В любом случае, РБНФ показывает, как один искуственный язык переводится на другой искуственный язык. Да, машине может быть тяжелее. Но меня это мало трогает — не знаю, как вы, а я не состою в лиге защиты прав трансляторов и лексических анализаторов. Меня больше волнует сложность использования языка человеком.
Впрочем, тему сравнения Smalltalk-а и Oberon-а я продолжать (по крайней мере, здесь) не намерен. Если этот вопрос интересует — излагайте внятно где-нибудь свои мысли на этот счет — там и обсудим.
В любом случае, РБНФ показывает, как один искуственный язык переводится на другой искуственный язык. Да, машине может быть тяжелее. Но меня это мало трогает — не знаю, как вы, а я не состою в лиге защиты прав трансляторов и лексических анализаторов. Меня больше волнует сложность использования языка человеком.
Впрочем, тему сравнения Smalltalk-а и Oberon-а я продолжать (по крайней мере, здесь) не намерен. Если этот вопрос интересует — излагайте внятно где-нибудь свои мысли на этот счет — там и обсудим.
Вызов — это вызов конкретного метода, известного на этапе компиляции.
Сообщение — переданная просьба объекту что-то сделать. Что именно сделает объект — мы не знаем до момента получения и обработки объектом этой просьбы (связывания сообщения с конкретным методом в случае Smalltalk-а). Более того, мы не знаем, как объект среагирует уже потому, что мы даже в общем случае не знаем какой именно объект получит это самое сообщение.
Следствий из такой концепции — масса, они и составляют ту самую «парадигму объектного программирования». Но вы упорно не хотите понять, что это не «дополнителная сущность» к «уже имеющимся инвариантам». Это самая что ни на есть базовая концепция. Все остальное через нее «выводится» (по-моему, я повторяюсь?). В этом та самая «фишка» и состоит: на базовом уровне не надо вводить массу понятий навроде «тип», «запись», «абстрактный тип», «процедура», «оператор ветвления»… Подобные вещи становятся лишь следующим шагом, деталями, которые можно убрать из языка и реализовать как «библиотеку». Smalltalk эту идею до конца не довел, но она, пусть и не в полной мере, была осуществлена, и на практике показана не только ее жизне-способность, но и, как минимум, конкурентно-способность (а некоторые считают, что и превосходство) относительно других подходов. Нигде больше (из известных мне языков, за исключением Self) в такой степени идея реализована не была. Наверное поэтому Smalltalk на самом деле сильно/принципиально отличается по множеству параметров от почти всех своих собратьев по «объектности».
Сообщение — переданная просьба объекту что-то сделать. Что именно сделает объект — мы не знаем до момента получения и обработки объектом этой просьбы (связывания сообщения с конкретным методом в случае Smalltalk-а). Более того, мы не знаем, как объект среагирует уже потому, что мы даже в общем случае не знаем какой именно объект получит это самое сообщение.
Следствий из такой концепции — масса, они и составляют ту самую «парадигму объектного программирования». Но вы упорно не хотите понять, что это не «дополнителная сущность» к «уже имеющимся инвариантам». Это самая что ни на есть базовая концепция. Все остальное через нее «выводится» (по-моему, я повторяюсь?). В этом та самая «фишка» и состоит: на базовом уровне не надо вводить массу понятий навроде «тип», «запись», «абстрактный тип», «процедура», «оператор ветвления»… Подобные вещи становятся лишь следующим шагом, деталями, которые можно убрать из языка и реализовать как «библиотеку». Smalltalk эту идею до конца не довел, но она, пусть и не в полной мере, была осуществлена, и на практике показана не только ее жизне-способность, но и, как минимум, конкурентно-способность (а некоторые считают, что и превосходство) относительно других подходов. Нигде больше (из известных мне языков, за исключением Self) в такой степени идея реализована не была. Наверное поэтому Smalltalk на самом деле сильно/принципиально отличается по множеству параметров от почти всех своих собратьев по «объектности».
Вы куда-то залезли в дебри, компиляция будет потом, не надо о ней думать, а то абстракции потекут.
Напомню, что речь изначально шла о том, как навыдумывали лишних сущностей, чтобы новыми понятиями выбить себе место на рынке, а потомки уже кроме объектов и сообщений и слов других не знают, самоуверенно вменяя тем, кто знает, некое недопонимание Очень Особенных Понятий.
Это как бины в джаве. Большинство уже даже не понимает, что такое эти бины на самом деле. Просто бины, существуют и все. Ну ок, люди сами решают, на каком уровне детализации мыслить. Может, им по работе больше не надо. Только при этом не стоит рассуждать с умным видом, что кто-то (в данном случае Н. Вирт) не шарит ничего в бинах и ООПе.
К самому ООП претензий нет, ну разве что концептуально, замыливание сознания. Представьте, что для победы в важной межгалактической войне важно знать и понимать обыкновенные дроби. Тогда хитрым пришельцы для победы нужно очень мало, всего лишь натянув костюм из человеческой кожи со школы учить Вас исключительно десятичным дробям.
Напомню, что речь изначально шла о том, как навыдумывали лишних сущностей, чтобы новыми понятиями выбить себе место на рынке, а потомки уже кроме объектов и сообщений и слов других не знают, самоуверенно вменяя тем, кто знает, некое недопонимание Очень Особенных Понятий.
Это как бины в джаве. Большинство уже даже не понимает, что такое эти бины на самом деле. Просто бины, существуют и все. Ну ок, люди сами решают, на каком уровне детализации мыслить. Может, им по работе больше не надо. Только при этом не стоит рассуждать с умным видом, что кто-то (в данном случае Н. Вирт) не шарит ничего в бинах и ООПе.
К самому ООП претензий нет, ну разве что концептуально, замыливание сознания. Представьте, что для победы в важной межгалактической войне важно знать и понимать обыкновенные дроби. Тогда хитрым пришельцы для победы нужно очень мало, всего лишь натянув костюм из человеческой кожи со школы учить Вас исключительно десятичным дробям.
«Сила пророков в их моральной уверенности» (С) О. Куваев, «Территория»
Я вам в очередной (и последний раз) поясняю :) Kay/Smalltalk-овский подход тем и прекрасен, что там близкий к минимум набор «лишних» сущностей и концепций. Эти самые лишние концепции к сути ООП относят те, кто эту самую суть не уловил: абстракция, инкапсуляция, наследование, полиморфизм… — «этого ничего не надо!»(с) Все это спокойно выводится из тех самых сообщений. Ну, а про сущности я где-то тоже уже писал — «чистый» объектный язык весьма минималистичен. Даже в случае Smalltalk-а, который не совсем чист и не совсем минималистичен, разница с другими языками впечатляющая.
Вы смешиваете техническое устройство с концепцией. Что такое метод, мы знаем. Что такое вызов метода, мы знаем. Это всё технический уровень.
А вот что такое «переданная просьба», мы не знаем — потому что это выход на концептуальный уровень. Как «передача просьбы» реализуется технически?
А вот что такое «переданная просьба», мы не знаем — потому что это выход на концептуальный уровень. Как «передача просьбы» реализуется технически?
Что такое инструкция процессора мы знаем. Что такое регистр мы знаем. А что такое вызов процедуры — мы не знаем. Отсюда вывод — процедурное программирование ничего не добавило к программированию в кодах.
Так как же всё-таки «передача просьбы» реализуется технически?
Pharo — открытая реализация Smalltalk. Можно посмотреть как Smalltalk-овские исходники системы (чтобы увидеть «внешнюю» часть механизма, включая класс Message), так и виртуалки (чтобы увидеть всю начинку).
Умеете же вы посылать далеко и надолго. А попроще нельзя объяснить?
Вопрос из разряда «что происходит, когда вы набрали адрес и нажали „ввод“ в адресной строке браузера?» Можно очень долго описывать этот процесс и где-нибудь все равно будет ошибка.
Но если вас это действительно интересует, то вкратце на «самом техническом» из доступных моему пониманию в данный момент уровне «по классике» все будет происходить примерно так:
В виртуальной машине есть байткод «Send». Когда интерпретатор встречает этот байт-код, он снимает со стека значения аргументов, получателя и имя сообщения, у получателя в словаре методов ищет откомпилированный метод, соответствующий сообщению с этим именем, сохраняет текущий контекст выполнения и создает новый, передавая управление в байт-код найденного метода. Когда он отработает, на стеке будет возвращенный результат.
Но если вас это действительно интересует, то вкратце на «самом техническом» из доступных моему пониманию в данный момент уровне «по классике» все будет происходить примерно так:
В виртуальной машине есть байткод «Send». Когда интерпретатор встречает этот байт-код, он снимает со стека значения аргументов, получателя и имя сообщения, у получателя в словаре методов ищет откомпилированный метод, соответствующий сообщению с этим именем, сохраняет текущий контекст выполнения и создает новый, передавая управление в байт-код найденного метода. Когда он отработает, на стеке будет возвращенный результат.
Значит, посылка сообщения технически реализована через вызов метода. Ничего нового. О чём и говорил Вирт.
Зато снаружи много магии и загадочных пассов руками — «сообщения», «вы ничего не понимаете в ООП».
Зато снаружи много магии и загадочных пассов руками — «сообщения», «вы ничего не понимаете в ООП».
UFO just landed and posted this here
Ну, дык:
Процедурное программирование — ничего нового по сравнению со структурным.
Структурное программирование — ничего нового по сравнению с Алголом.
Алгол — ничего нового по сравнению с ассемблером.
Ассемблер — ничего нового по сравнению с архитектурой фон Неймана.
Архитектура фон Неймана — ничего нового по сравнению с машиной Тьюринга…
… Дальше не рискну, но прикиньте: с 1936-го года сплошная магия и пассы руками!
Процедурное программирование — ничего нового по сравнению со структурным.
Структурное программирование — ничего нового по сравнению с Алголом.
Алгол — ничего нового по сравнению с ассемблером.
Ассемблер — ничего нового по сравнению с архитектурой фон Неймана.
Архитектура фон Неймана — ничего нового по сравнению с машиной Тьюринга…
… Дальше не рискну, но прикиньте: с 1936-го года сплошная магия и пассы руками!
Позвольте встряну в разговор. Когда вы вызываете метод задайте себе такие вопросы:
1) когда он отработает
2) в каком потоке он отработает
3) на каком сервере из ваших двух он отработает
4) что произойдет с необработанным исключением, которое упало внутри метода
5) может ли объект внезапно поменять свое поведение и перестать реагировать на некоторые вызовы методов?
И вот ответы: отработает он сейчас, в текущем потоке, на текущем сервере, исключение пробросится наружу где вы его сможете словить, нет, объект не может резко поменять поведение и игнорировать не может. Это традиционное процедурное программирование.
ООП в современных языках — это блин просто virtual table и проверка на уровне компилятора модификаторов доступа. И между ним и процедурным программированием нету особой разницы. Вот именно поэтому вы эту разницу и не видите. Вам просто добавили чуточку возможностей и улучшили разделение кода.
Теперь, что такое ООП в настоящем виде: все есть объект и единственный способ общения с объектом — послать сообщение. Нам не важно, как, где и когда обработается сообщение.
Например, есть модель акторов. Это по сути урезанная версия ООП, в которой объект не делает работу сразу и не может отвечать на сообщения (т.е. RPC нужно делать вручную). У каждого актора есть threadsafe mail box, он поочередно обрабатывает сообщения и в зависимости от них что-то делает или меняет себе атомарно свое состояние.
Такие ограничения сразу приводят к коду, которому нету разницы (ну я тут приврал, идеале не бывает, но все же), где исполняться: на локальной машине или Северном Полюсе.
И заметьте, мы остались в терминах everything is object & общения через посылку сообщений. Это настоящее бескомпромисное ООП.
Btw, многие интересные вещи в нынешнем «ООП»-мире решаются через «АОП».
1) когда он отработает
2) в каком потоке он отработает
3) на каком сервере из ваших двух он отработает
4) что произойдет с необработанным исключением, которое упало внутри метода
5) может ли объект внезапно поменять свое поведение и перестать реагировать на некоторые вызовы методов?
И вот ответы: отработает он сейчас, в текущем потоке, на текущем сервере, исключение пробросится наружу где вы его сможете словить, нет, объект не может резко поменять поведение и игнорировать не может. Это традиционное процедурное программирование.
ООП в современных языках — это блин просто virtual table и проверка на уровне компилятора модификаторов доступа. И между ним и процедурным программированием нету особой разницы. Вот именно поэтому вы эту разницу и не видите. Вам просто добавили чуточку возможностей и улучшили разделение кода.
Теперь, что такое ООП в настоящем виде: все есть объект и единственный способ общения с объектом — послать сообщение. Нам не важно, как, где и когда обработается сообщение.
Например, есть модель акторов. Это по сути урезанная версия ООП, в которой объект не делает работу сразу и не может отвечать на сообщения (т.е. RPC нужно делать вручную). У каждого актора есть threadsafe mail box, он поочередно обрабатывает сообщения и в зависимости от них что-то делает или меняет себе атомарно свое состояние.
Такие ограничения сразу приводят к коду, которому нету разницы (ну я тут приврал, идеале не бывает, но все же), где исполняться: на локальной машине или Северном Полюсе.
И заметьте, мы остались в терминах everything is object & общения через посылку сообщений. Это настоящее бескомпромисное ООП.
Btw, многие интересные вещи в нынешнем «ООП»-мире решаются через «АОП».
Вы тоже смешиваете техническую реализацию с концепцией.
Попробуйте в рамках концепции методов реализовать что-нибудь подобное методу doesNotUnderstand в Smalltalk (в Ruby аналогичная сущность — метод method_missing).
Объясню, как он действует. Как уже было сказано выше, вызов методов в Smalltalk реализован с помощью отправки сообщений. Пример: при выполнении кода «anObject doSomething» объекту anObject будет отправлено сообщение doSomething, при этом, если существует такой метод, то он выполняется. Но разница особенно заметна, когда метода с таким именем нет — в таком случае выполняется метод doesNotUnderstand, одним из параметров которому передаётся сообщение. Это позволяет делать такие вещи, как, например, построение DSL на лету в зависимости от данных. Пример: есть некий xml вида "<root><branch><leaf/></branch></root>", и вы можете с ним работать в стиле «xml branch leaf» — т.е. объекту xml посылается сообщение branch, а результату посылается сообщение leaf. При этом, разумеется, у объекта xml нет метода branch, но для работающего с этим объектом это неважно — он работает с объектом так, как будто такой метод есть.
И, заметьте, я говорю не о реализации (ваша любимая отмазка), а именно о концепции. Как именно будет реализована обработка сообщения — для концепции неважно, главное, что отправка сообщения не обязательно вызывает метод, а может быть обработана и по другому.
Объясню, как он действует. Как уже было сказано выше, вызов методов в Smalltalk реализован с помощью отправки сообщений. Пример: при выполнении кода «anObject doSomething» объекту anObject будет отправлено сообщение doSomething, при этом, если существует такой метод, то он выполняется. Но разница особенно заметна, когда метода с таким именем нет — в таком случае выполняется метод doesNotUnderstand, одним из параметров которому передаётся сообщение. Это позволяет делать такие вещи, как, например, построение DSL на лету в зависимости от данных. Пример: есть некий xml вида "<root><branch><leaf/></branch></root>", и вы можете с ним работать в стиле «xml branch leaf» — т.е. объекту xml посылается сообщение branch, а результату посылается сообщение leaf. При этом, разумеется, у объекта xml нет метода branch, но для работающего с этим объектом это неважно — он работает с объектом так, как будто такой метод есть.
И, заметьте, я говорю не о реализации (ваша любимая отмазка), а именно о концепции. Как именно будет реализована обработка сообщения — для концепции неважно, главное, что отправка сообщения не обязательно вызывает метод, а может быть обработана и по другому.
«Programming in Oberon», раздел 23.4, широковещательная рассылка сообщений. Объект-получатель интерпретирует сообщение (у Алана Кея точно такая же концепция), и если не понимает его, просто не реагирует. Такой подход позволяет работать с гетерогенными структурами, не имея представления об их внутреннем устройстве.
При этом, разумеется, у объекта xml нет метода branch, но для работающего с этим объектом это неважно — он работает с объектом так, как будто такой метод есть.
Постарайтесь понять, что в Обероне есть две разные концепции — вызов методов И отправка сообщений. В то время как в Smalltalk есть только отправка сообщений.
Нет, не смешиваю. Когда техническая реализация кастрирует концепцию, то нельзя переносить понимание кастрированной концепции на изначальную.
Когда техническая реализация сама становится концепией, то понимание её нельзя применять к оригинальной реализации.
Если вы добьетесь, что вы будете решать похожие задачи похожим образом, но при этом концепции, лежащие в основе разные — то вы не можете переносить свое понимание реализации на понимание концепции. Ибо в конечном счете, то как вы мыслите определяет направление разработки и возможные преграды.
Т.е. нужно рассматривать концепцию в виде «возможности + способ мышления».
Когда техническая реализация сама становится концепией, то понимание её нельзя применять к оригинальной реализации.
Если вы добьетесь, что вы будете решать похожие задачи похожим образом, но при этом концепции, лежащие в основе разные — то вы не можете переносить свое понимание реализации на понимание концепции. Ибо в конечном счете, то как вы мыслите определяет направление разработки и возможные преграды.
Т.е. нужно рассматривать концепцию в виде «возможности + способ мышления».
Вызов метода — это техническая реализация.
Посылка сообщения, это концепция, реализуемая вызовом метода.
Я предпочитаю видеть явную реализацию, чем туманную концепцию.
Посылка сообщения, это концепция, реализуемая вызовом метода.
Я предпочитаю видеть явную реализацию, чем туманную концепцию.
Вызов метода это не посылка сообщения.
Во-первых, вызов метода — позволяет делать всего-лишь подмножество из тех вещей, которые возможны при посылке сообщения. Посылка сообщения включает в себя как минимум отложенный вызов, удаленный вызов метода, любую вариацию декораторов и прокси без введения новых классов, вызов несуществующих методов, возможность в рантайме заменить набор методов на другой (с удалением предыдущих).
Во-вторых, вы видите сокрытие реализации, а я вижу сокрытие концепции. Концепция это тоже важно, именно поэтому сейчас все основные языки вместо ООП имеют структуры + virtual table и никто не понимает, чем это лучше структур.
Во-первых, вызов метода — позволяет делать всего-лишь подмножество из тех вещей, которые возможны при посылке сообщения. Посылка сообщения включает в себя как минимум отложенный вызов, удаленный вызов метода, любую вариацию декораторов и прокси без введения новых классов, вызов несуществующих методов, возможность в рантайме заменить набор методов на другой (с удалением предыдущих).
Во-вторых, вы видите сокрытие реализации, а я вижу сокрытие концепции. Концепция это тоже важно, именно поэтому сейчас все основные языки вместо ООП имеют структуры + virtual table и никто не понимает, чем это лучше структур.
Я ничего не имею против концепции сообщения. Сообщения прекрасны.
Правда, когда мы делали асинхронную обработку сообщений, то натолкнулись на нехорошие вещи, связанные с невозможностью контролировать поток управления. Вот сообщение, вот мы его получили — а кто послал и в каком контексте — неизвестно. Синхронное процедурное программирование более детерминировано в этом смысле.
Но в общем, мне сообщения нравятся. Не нравится только высказывание, что «настоящее ООП» только сообщениями и ограничивается. Фактически, это не так, ведь для обработки сообщений нужны методы. Концептуальный сахар получается, короче :)
Правда, когда мы делали асинхронную обработку сообщений, то натолкнулись на нехорошие вещи, связанные с невозможностью контролировать поток управления. Вот сообщение, вот мы его получили — а кто послал и в каком контексте — неизвестно. Синхронное процедурное программирование более детерминировано в этом смысле.
Но в общем, мне сообщения нравятся. Не нравится только высказывание, что «настоящее ООП» только сообщениями и ограничивается. Фактически, это не так, ведь для обработки сообщений нужны методы. Концептуальный сахар получается, короче :)
Правда, когда мы делали асинхронную обработку сообщений, то натолкнулись на нехорошие вещи, связанные с невозможностью контролировать поток управления.
Верно, эту фичу в обычных языках надо допиливать отдельно. Сейчас за вас это делает ваш язык программирования для синхронного кода — вызова методов. В том же C# есть отдельная поддержка асинхронного кода и во многих случаях стектрейсы получается адекватными (что не решает проблему отложенной обработки сообщений на другом приложении). Кроме того, не всегда нужно знать полный контекст.
Фактически, это не так, ведь для обработки сообщений нужны методы
Если вы понимаете под методами подпрограммы, то да, для того, чтобы что-то обработать нужны программы/подпрограммы/код. Но метод — это нечто большее, чем подпрограмма.
С моей точки зрения — ООП — это просто другой образ мысли. Отношение к программе — не как к набору (тексту) кода, а как к живому миру. Может быть к дому — большому и наполненным жильцами. Давайте попробую объяснить как я это вижу.
Запуская программы ту заходишь в этот дом. Перед тобой холст — MainUI вокруг которого кнопочки звонков в квартиры -ToolBar. Например открытие файла -> звонок в квартиру -> вызов жильца. Прибегает жилец -> Project (вместе со всей семьёй: жена Scehma, дети Network-и, внуки Block -и). Project просит Schem-у нарисовать себя на холсте и отдает его ей. Она делит его между детьми и отдаёт каждому из них свой кусочек и просит теперь их нарисовать себя каждого на своём месте. Каждый Network пишет сверху свое имя, а остаток отдает на растерзание внукам. Каждый Block (а они все разные) знает своё место относительно имени родителя, рисует себя так как он себя видит. И вот войдя в дом и вызвав конкретный проект я вижу на холсте семейный портрет. Моя задача как программиста научить всю эту толпу рисовать себя. Рядышком на соседнем холсте портрет семьи библиотеки (Block Library). Когда мне надо добавить в семью Project-а новый блок, я сообщаю об этом Block Library (startDrag -> endDrag). Она же является моделью для второго холста. Создатели (разработчики языка) уже научили её кому об этом надо сказать — Controller-у. А ему уже я подсказал кому передать это сообщение — Scheme. Она выбирает кому из детей отдать новый Block (зависит от места endDrag), и отдает его.
Всё это звучит наверное достаточно глупо, но таким образом легче понимать взаимодействие объектов в большой системе. В этом отношении ООП дает больше возможности абстрагироваться от кода, а SmallTalk с близостью его синтаксиса к нормальному языку, дает возможность легче объяснить объекту что от него хотят и как это нужно сделать.
Запуская программы ту заходишь в этот дом. Перед тобой холст — MainUI вокруг которого кнопочки звонков в квартиры -ToolBar. Например открытие файла -> звонок в квартиру -> вызов жильца. Прибегает жилец -> Project (вместе со всей семьёй: жена Scehma, дети Network-и, внуки Block -и). Project просит Schem-у нарисовать себя на холсте и отдает его ей. Она делит его между детьми и отдаёт каждому из них свой кусочек и просит теперь их нарисовать себя каждого на своём месте. Каждый Network пишет сверху свое имя, а остаток отдает на растерзание внукам. Каждый Block (а они все разные) знает своё место относительно имени родителя, рисует себя так как он себя видит. И вот войдя в дом и вызвав конкретный проект я вижу на холсте семейный портрет. Моя задача как программиста научить всю эту толпу рисовать себя. Рядышком на соседнем холсте портрет семьи библиотеки (Block Library). Когда мне надо добавить в семью Project-а новый блок, я сообщаю об этом Block Library (startDrag -> endDrag). Она же является моделью для второго холста. Создатели (разработчики языка) уже научили её кому об этом надо сказать — Controller-у. А ему уже я подсказал кому передать это сообщение — Scheme. Она выбирает кому из детей отдать новый Block (зависит от места endDrag), и отдает его.
Всё это звучит наверное достаточно глупо, но таким образом легче понимать взаимодействие объектов в большой системе. В этом отношении ООП дает больше возможности абстрагироваться от кода, а SmallTalk с близостью его синтаксиса к нормальному языку, дает возможность легче объяснить объекту что от него хотят и как это нужно сделать.
Давайте попробуем отыскать фишку?
Для начала, кратенький дайджест по оберону: www.osp.ru/pcworld/2005/10/317204
Вот тут обсуждение ООП в обероне: www.osp.ru/pcworld/2005/10/317204
А здесь совсем уж сухое техническое описание ООП в обероне: statlab.uni-heidelberg.de/projects/oberon/kurs/www/Oberon2.OOP.html
Я думаю, что если мы не будем поддаваться очарованию магических слов типа «сообщение», то перед нами откроется реальность как она есть.
Для начала, кратенький дайджест по оберону: www.osp.ru/pcworld/2005/10/317204
Вот тут обсуждение ООП в обероне: www.osp.ru/pcworld/2005/10/317204
А здесь совсем уж сухое техническое описание ООП в обероне: statlab.uni-heidelberg.de/projects/oberon/kurs/www/Oberon2.OOP.html
Я думаю, что если мы не будем поддаваться очарованию магических слов типа «сообщение», то перед нами откроется реальность как она есть.
UFO just landed and posted this here
М-м-м, я с вами согласен. Я когда-то пришел к выводу, что ООП это не столько методология программирование, сколько способ организации кодом. Я поясню свою мысль: с увеличением объема программ (в строках, оперируемых сущностях) возникает проблема управления большими объемами кода. И ООП предлагает такой подход: компоновка в одном пространстве данных и процедур, работающих с этими данными. Мы инкапсулируем в отдельном контейнере данные и процедуры.
Словом, как всегда, разделяй и властвуй.
Все остальное — полезные, удобные добавки вокруг.
А так, как ни крути, все равно все сведется к ассемблеру
Словом, как всегда, разделяй и властвуй.
Все остальное — полезные, удобные добавки вокруг.
А так, как ни крути, все равно все сведется к ассемблеру
Я поясню свою мысль: с увеличением объема программ (в строках, оперируемых сущностях) возникает проблема управления большими объемами кода. И ООП предлагает такой подход: компоновка в одном пространстве данных и процедур, работающих с этими данными. Мы инкапсулируем в отдельном контейнере данные и процедуры.
Ох, тогда Вирт прав и нам прямая дорога в какой-нибудь С++ :)
Да, статическую структуру соединяем с алгоритмами и получаем «объект». Множество объектов приходится обозначать словом «класс». Кроме этого, требуется ещё и взаимодействие объектов между собой, а это возможно только если они способны коммуницировать — вот и появляется «сообщение».
А в основе лежит та же статическая структура с ассоциированными с ней процедурами.
А в основе лежит та же статическая структура с ассоциированными с ней процедурами.
Возможно, вы ожидали увидеть революцию, там где есть эволюция?
Соединяя статическую структуру с алгоритмами, получаем «абстрактный тип»… или модуль в паскале :) Нет, назвать, конечно, можно и объектом. Но это не будет объектом Алана Кея. У последнего только одно обязательное свойство — отвечать на сообщение. Все остальное — детали реализации. От которых не только в принципе можно, но и на практике хотелось бы отказаться, когда речь заходит об основах и «языке».
Процитирую вам Гради Буча: «Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений».
Не знаю, может у Алана Кея какие-нибудь другие, особенные «объекты». Формальный аппарат Оберона позволяет совершенно спокойно реализовать процитированную концепцию.
Не знаю, может у Алана Кея какие-нибудь другие, особенные «объекты». Формальный аппарат Оберона позволяет совершенно спокойно реализовать процитированную концепцию.
Видите ли, это у Гради Буча свое какое-то понимание ООП.
А Алан Кей один из первых отцов основателей ООП
userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
Хотя это суть неважно. Мнится мне, что это битва за термины.
А Алан Кей один из первых отцов основателей ООП
userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
Хотя это суть неважно. Мнится мне, что это битва за термины.
Вы сами понимаете, что вы пытаетесь доказать? Если да — раскройте пожалуйста.
Есть термин: объектно(-ориентированное) программирование. Есть автор этого термина — Алан Кей. Есть набор концепций, который автор (со своей командой) вкладывал в этот термин. В History of Smalltalk он подробно объяснил свою концепцию, разделив принципы на две группы: основу и детали реализации. Если продолжать его мысль, окажется, что в основе лежит один принцип — обмен сообщениями. Все остальное по необходимости «выводится» из этого принципа. Smalltalk в этом отношении — не идеальный язык, так как в него введены некоторые необязательные концепции (например, классы… я бы добавил еще, но это надо обсуждать отдельно), Self в этом отношении получше, но все равно не идеален. Идеального языка я не знаю.
А есть еще набор интерпретаций того же термина другими лицами. Интерпретации эти обычно сложнее. Интерпретации приводят к другому пониманию, к другой организации разработки, к более сложным и «раздутым» языкам… В общем, ни к чему хорошему не приводят вплоть до идеи «ООП мертв» без понимания, что же такое ООП на самом деле.
Реализовать ООП — в любой интерпретации — можно очень разными способами наверное в любой из существующих «парадигм»: можно в процедурной, можно в функциональной (надеюсь, они подтянуться сюда и нам не придется вести дискуссуию на два фронта — каждой из трех сторон:). О чем это говорит? Да ни о чем! Объектами тоже можно реализовать и функциональную концепцию и процедурную…
Так что же вы хотите донести до нас?
Есть термин: объектно(-ориентированное) программирование. Есть автор этого термина — Алан Кей. Есть набор концепций, который автор (со своей командой) вкладывал в этот термин. В History of Smalltalk он подробно объяснил свою концепцию, разделив принципы на две группы: основу и детали реализации. Если продолжать его мысль, окажется, что в основе лежит один принцип — обмен сообщениями. Все остальное по необходимости «выводится» из этого принципа. Smalltalk в этом отношении — не идеальный язык, так как в него введены некоторые необязательные концепции (например, классы… я бы добавил еще, но это надо обсуждать отдельно), Self в этом отношении получше, но все равно не идеален. Идеального языка я не знаю.
А есть еще набор интерпретаций того же термина другими лицами. Интерпретации эти обычно сложнее. Интерпретации приводят к другому пониманию, к другой организации разработки, к более сложным и «раздутым» языкам… В общем, ни к чему хорошему не приводят вплоть до идеи «ООП мертв» без понимания, что же такое ООП на самом деле.
Реализовать ООП — в любой интерпретации — можно очень разными способами наверное в любой из существующих «парадигм»: можно в процедурной, можно в функциональной (надеюсь, они подтянуться сюда и нам не придется вести дискуссуию на два фронта — каждой из трех сторон:). О чем это говорит? Да ни о чем! Объектами тоже можно реализовать и функциональную концепцию и процедурную…
Так что же вы хотите донести до нас?
Если уж на то пошло, то Алан Кей не является автором понятий «класс» и «объект».
Речь идёт о том, что вы ставите тождество ООП = Smalltalk и упрекаете Вирта в том, что он не следовал дао смолтока.
Но если посмотреть на оберон-системы, то там есть сообщения. И даже, вы представляете, есть асинхронность. Есть классы объектов, есть экземпляры. Есть поведение. То есть, ООП реализовано нормально, суть проявлена.
А вот что такого магического ВЫ пытаетесь донести до нас, чего никто не знает и знаете только вы, вопрос.
Речь идёт о том, что вы ставите тождество ООП = Smalltalk и упрекаете Вирта в том, что он не следовал дао смолтока.
Но если посмотреть на оберон-системы, то там есть сообщения. И даже, вы представляете, есть асинхронность. Есть классы объектов, есть экземпляры. Есть поведение. То есть, ООП реализовано нормально, суть проявлена.
А вот что такого магического ВЫ пытаетесь донести до нас, чего никто не знает и знаете только вы, вопрос.
Я, к примеру, среди прочего, пытался донести, что понятие «класс» не является базовым понятием объектного программирования.
Впрочем, я уже больше ничего не пытаюсь донести до вас, извините :) Что мог — сделал.
Впрочем, я уже больше ничего не пытаюсь донести до вас, извините :) Что мог — сделал.
Да вы что?
Читаем: gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
Четвёртый из шести принципов Smalltalk:
4) Every object is an instance of a class (which must be an object)
Читаем: gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
Четвёртый из шести принципов Smalltalk:
4) Every object is an instance of a class (which must be an object)
А теперь еще неутомимо читаем следующий абзац…
И в следующем абзаце и в дальнейших абзацах плотно используется слово «class». Такое ощущение, что вы плохо ориентируетесь в вопросе. Это пока только ощущение.
Дочитал Алана Кея. Моё ощущение переросло в уверенность. Теперь понятно, почему вы так безапелляционно обвинили Вирта в непонимании сути ООП.
:D Что тут скажешь?
«Имещий глаза да увидит»
Вот вам цитата:
Перевод нужен?
Вот вам Self, который, по сути, является Smalltalk-ом без классов (и с некоторыми другими очень интересными доработками). Про JavaScript говорить не буду — очень уж «специфический» язык. Есть и другие примеры.
На момент написания «The Early History…» Self уже существовал. Думаю, Кэй был в курсе и неспростра внес эту оговорку.
«Имеющий мозг да поймет»
Если вы зададитесь трудом немного поразмыслить над вашим — безусловно богатейшим — опытом программирования «в объектной парадигме», то, уверен, в какой-то момент вы осознаете, что классы очень полезны при решении «стандартных» задач, но могут «не менее очень» мешать, когда приходится делать что-то на мета-уровне с отдельными объектами (когда нужно отдельному объекту задать специфическое поведение). И если после этого вы сделаете еще небольшое усилие, то прекрасно увидите, что на уровне языка классы совсем и не нужны — достаточно порождать объекты по образу и подобию уже существующих. А классы можно прекрасненько реализовать в библиотеке и пользоваться ими тогда, когда это действительно нужно.
«Имещий глаза да увидит»
Вот вам цитата:
The 1st three principles are what objects “are about”–how they are seen and used from “the outside.” These did not require any modification over the years. The last three –objects from the inside–were tinkered with in every version of Smalltalk (and in subsequent OOP designs).
Перевод нужен?
Вот вам Self, который, по сути, является Smalltalk-ом без классов (и с некоторыми другими очень интересными доработками). Про JavaScript говорить не буду — очень уж «специфический» язык. Есть и другие примеры.
На момент написания «The Early History…» Self уже существовал. Думаю, Кэй был в курсе и неспростра внес эту оговорку.
«Имеющий мозг да поймет»
Если вы зададитесь трудом немного поразмыслить над вашим — безусловно богатейшим — опытом программирования «в объектной парадигме», то, уверен, в какой-то момент вы осознаете, что классы очень полезны при решении «стандартных» задач, но могут «не менее очень» мешать, когда приходится делать что-то на мета-уровне с отдельными объектами (когда нужно отдельному объекту задать специфическое поведение). И если после этого вы сделаете еще небольшое усилие, то прекрасно увидите, что на уровне языка классы совсем и не нужны — достаточно порождать объекты по образу и подобию уже существующих. А классы можно прекрасненько реализовать в библиотеке и пользоваться ими тогда, когда это действительно нужно.
О, пожалуй да, перевод нужен! Я не буду вам накидывать тучу цитат из того же самого текста про классы, давайте сначала разберёмся с вашим переводом.
Хорошо, раз уж сам предложил, потрачу на этот балаган еще немного своего времени :)
Первые три принципа говорят о том, что такое объекты вообще (be about — be involved or to do with; have the intention of) — как они видятся и используются извне. Они не требовали каких-либо изменений годами. Последние три — объекты изнутри — подправлялись с каждой версией Smalltalk (и в последующих ООП-разработках).
Предвосхищая ваши цитаты из «Ранней истории…» (которую я первый раз прочитал лет уже 10 назад), попробую еще разик (в дополнение к моим предыдущим комментариям) разжевать для вас мысль, которую вы никак не желаете услышать: в Smalltalk-е классы ЕСТЬ! :) И, судя по некоторым широко известным высказываниям Кэя, некоторое время считалось, что без этого никак. Потом вдруг выяснилось, что очень даже как. Но дело даже не в этом. Если вы уж так уверились в том, что я не ориентируюсь в этих вопросах, вот вам цитата самого:
Переводить и понимать вам придется самостоятелно. Я завязываю с этой бессмысленной тратой моего времени.
Первые три принципа говорят о том, что такое объекты вообще (be about — be involved or to do with; have the intention of) — как они видятся и используются извне. Они не требовали каких-либо изменений годами. Последние три — объекты изнутри — подправлялись с каждой версией Smalltalk (и в последующих ООП-разработках).
Предвосхищая ваши цитаты из «Ранней истории…» (которую я первый раз прочитал лет уже 10 назад), попробую еще разик (в дополнение к моим предыдущим комментариям) разжевать для вас мысль, которую вы никак не желаете услышать: в Smalltalk-е классы ЕСТЬ! :) И, судя по некоторым широко известным высказываниям Кэя, некоторое время считалось, что без этого никак. Потом вдруг выяснилось, что очень даже как. Но дело даже не в этом. Если вы уж так уверились в том, что я не ориентируюсь в этих вопросах, вот вам цитата самого:
Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term «objects» for this topic because it gets many people to focus on the lesser idea.
Переводить и понимать вам придется самостоятелно. Я завязываю с этой бессмысленной тратой моего времени.
Отличная статья. Спасибо.
Возможно Вы знаете, но все таки расскажу, что Smalltalk изучают в Южном Федеральном Университете. Если интересно найти «единомышленников», то нужно поискать доцента кафедры математического анализа мехмата ЮФУ Кирютенко Юрия Александровича. Он автор нескольких работ по Smalltalk, и значительная часть студентов у него пишут проект на Smalltalk. Я, будучи «его студентом», писал несколько классов в один проект, связанный с государствеными образовательными стандартами (ГОС ВПО).
Возможно Вы знаете, но все таки расскажу, что Smalltalk изучают в Южном Федеральном Университете. Если интересно найти «единомышленников», то нужно поискать доцента кафедры математического анализа мехмата ЮФУ Кирютенко Юрия Александровича. Он автор нескольких работ по Smalltalk, и значительная часть студентов у него пишут проект на Smalltalk. Я, будучи «его студентом», писал несколько классов в один проект, связанный с государствеными образовательными стандартами (ГОС ВПО).
Спасибо за информацию. Не знал. Знал только что одно время SmallTalk преподавали в Таганрогском радиотехническом институте, и еще в каком то институте под Москвой. Но в Таганроге была своя — особенная версия языка полностью переведённая на русский язык. В принципе язык это позволяет, но смотреть на него было непривычно))))
Sign up to leave a comment.
Неизвестный Smalltalk