Уважаемые читатели хабра. Прежде всего я хочу объяснить, что обзор языка Smalltalk делает в корпоративном блоге FLProg. Дело в том, что и сама программа FLProg и сайт программы написаны на этом замечательном языке. Его возможности и огромная скорость разработки на нём позволяют мне одному поддерживать и постоянно увеличивать функциональность как сайта, так и программы. Если интересно, как мне это удается – прошу под кат.
Сначала немного предыстории. Девять лет назад я работал в одной промышленной фирме инженером схемотехником. Рисовал схемы, а на досуге писал небольшие программки на дельфях для облегчения суровой инженерной жизни. Программки постепенно начали расходиться по коллективу, руководство это заметило и был создан отдел прикладного программирования. В помощь мне был принят на работу профессиональный программист, у которого недавно закончился проект. Вот он то и познакомил меня с языком Smalltalk, на котором реализовывался его предыдущий проект. Честно скажу, первая реакция от этого языка у меня была отрицательная. Он ломал все мои представления о программировании. Ломка продолжалась месяца три, после чего я влюбился в Smalltalk и до сих пор предпочитаю работать только на нем, хотя за это время пришлось изучить еще несколько других.
Поскольку повествователь из меня не очень, я буду широко использовать материалы из русской википедии , посвящённой этому языку и оформлять эти материалы как цитаты.
История возникновения языка:
Smalltalk был создан группой исследователей возглавляемой Аланом Кэйем в исследовательском центре XEROX Palo Alto. Первая реализация, известная как Smalltalk-71, была создана за несколько месяцев как результат спора о том, что язык программирования, основанный на идее посылки сообщений, подсказанной Симулой, должен реализовываться на «странице кода». Более поздняя версия, действительно использованная для исследовательской работы, известна сейчас как Smalltalk-72. Его синтаксис и модель исполнения сильно отличались от современного Smalltalk’а, настолько, что его надо рассматривать как другой язык.
После существенных переработок которые зафиксировали несколько сторон семантики выполнения для увеличения эффективности, была создана версия известная как Smalltalk-76. В этой версии добавились наследование, синтаксис более близкий к Smalltalk-80, и среда разработки включающую большинство инструментов знакомых сейчас Smalltalk-ерам.
Первые годы жизни языка описаны в замечательном эссе Кэя The Early History of Smalltalk (HTML).
В Smalltalk-80 были добавлены метаклассы, что делало фразу «всё объекты» истинной путём связывания с индивидуальными классами свойств и поведения (например, поддержки различных способов создания экземпляров). Smalltalk-80 был первой версией доступной за пределами PARC, сначала как Smalltalk-80 Version 1, розданной небольшому количеству компаний и университетов для «экспертной оценки». Позже (в 1983) общедоступная реализация, известная как Smalltalk-80 Version 2, стала доступна как образ (независимый от платформы файл содержащий объекты) и спецификации виртуальной машины.
Сейчас существует две реализации Smalltalk, являющихся прямыми потомками Smalltalk-80. Это Squeak и VisualWorks. Как выглядел Smalltalk-80 можно увидеть на скриншоте. Образ Smalltalk-80 version 2 запущен на Hobbes, виртуальной машине ST-80 реализованной на VisualWorks.
Smalltalk оказал большое влияние на развитие многих других языков, таких как: Objective-C, Actor, Java и Ruby. Многие идеи 1980-х и 1990-х по написанию программ (Class-Responsibility-Collaboration card) и появились в сообществе Smalltalk, такие как шаблоны проектирования (применительно к ПО), экстремальное программирование и рефакторинг. Основатель концепции WikiWiki, Вард Каннингем, входит в сообщество Smalltalk.
На сегодняшний день последняя версия языка – 8.0, выпущенная в сентябре 2014 года. Конкретно я работаю на реализации VisualWorks и рассказ будет посвящен ему.
Smalltalk является объектным языком, поэтому уместно будет вспомнить базовые принципы ООП (в том виде, в каком они были сформулированы Аланом Кеем):
Объект — базовая единица объектно-ориентированной системы.
Объекты могут обладать состоянием.
Посылка сообщения — единственный способ обмена информацией между объектами.
Кроме того, объектная модель Smalltalk построена на классах, а значит:
Каждый объект относится к какому-то классу.
Функциональность объекта определяется его классом (набором его методов).
Классы организованы в иерархию.
Классы наследуют функциональность от предка (или предков).
Вот, по сути, и всё. Хотя можно дополнительно акцентировать некоторые принципы и уточнить другие:
Всё в Smalltalk является объектами. Т.е. вообще всё. Абсолютно всё. Нет ничего, что не являлось бы объектом.
В Smalltalk существует четыре типа действий — посылка сообщения, присваивание, возвращение значения из метода, вызов примитива виртуальной машины.
Немного от себя. Все переменные в объектах являются указателями. Не существует понятия разыменовывания указателя, переменные всегда ссылки на объект. Во-вторых Smalltalk – динамически типизированный язык. То есть в любую переменную можно положить ссылку на инстанс объекта любого класса. Соответственно нет понятия приведения типа. В — третьих, в языке очень продвинутый сборщик мусора, поэтому практически никогда не приходится пользоваться методами уничтожения объекта. В случае, когда на инстанс объекта не остается ни одной ссылки – он быстро уничтожается сборщиком, и память освобождается. Конечно, это очень упрощенное описание сборщика мусора, но утечки памяти добиться в Smalltalk-е очень тяжело (мне ни разу не удалось).
Архитектура Smalltalk
Любая система Smalltalk (среда разработки, отдельная исполняемая программа и т.д.) состоит из двух частей — виртуальной машины и образа системы.
Виртуальная машина
Виртуальная машина содержит базовую функциональность: обработчик байт-кодов (в виде JIT-компилятора либо интерпретатора), систему управления памятью (со сборщиком мусора) и примитивы. (Примитивы — это функциональность, которую по каким-либо причинам оказалось удобнее или выгоднее реализовать не на Smalltalk, а в виртуальной машине. Обычно это функциональность самого нижнего уровня, типа сложения чисел или отрисовки точки на экране.)
Образ системы
Образ системы (image) — это файл, хранящий все объекты системы Smalltalk между сеансами работы. К этим объектам относятся исполняющиеся программы, созданные объекты, классы и т.д.
Когда система Smalltalk запущена — все действия, разумеется, выполняются в памяти компьютера. Когда же вы выходите из среды — у вас есть выбор, либо сохранять текущее состояние образа системы, либо нет. Если сохраните образ системы, то при следующем запуске вся среда будет восстановлена предельно точно — вплоть до положения окошек и позиций курсоров. Это происходит потому, что сохраняются (а потом восстанавливаются) состояния всех объектов.
Образ системы является основным контейнером информации в Smalltalk — т.е. в Smalltalk не приняты текстовые файлы с исходным кодом. В принципе, их можно создавать, но работать с образом системы гораздо удобнее.
В настоящее время существуют виртуальные машины под Windows x86 (прекрасно работает под Windows x64), Windows x64, Linux 32, Linux 64, Solaris, Mac Oc. Для перехода на другую платформу достаточно к образу системы подложить необходимую виртуальную машину. В коде бывает иногда необходимо предусмотреть разное поведение при специфических вызовах API, но большинство этих вопросов уже решено в базовых классах. Например работа с файловой системой не требует вообще никаких изменений при переходе на любую платформу. У меня возникала необходимость в доработке кода при портировании на Linux только в области работы с Com портом, и то это заняло не больше пары часов.
Это все была теория, а теперь к практике.
Большое преимущество Smalltalk в том, что нет необходимости устанавливать среду на машину. Вполне можно создать папку на флешке, положить туда три файлика и рабочее место всегда с собой. Работать можно на любой машине, даже на чужой, даже без прав администратора, при этом после извлечения флешки никаких следов работы не остается.
Основное рабочее окружение Smalltalk:
Class Browser
Workspace
В Class Browser-е хранится весь код программы представляющий набор классов проекта и базовых классов языка. В нем происходит основная работа. При этом следует учесть, что все классы «живые» то есть в любой момент можно вызвать любой класс, создать его инстанс, провести необходимые изменения. Для всего этого служит Workspace. В его рабочем поле можно написать и выполнить любой код.
Существует много способов программирования, но для себя я выбрал способ «Программирование через дебаг». Я его не придумал, а подсмотрел на слёте программистов на Smalltalk-е, который проходил в Питере лет восемь назад. К сожалению, не помню докладчика. Насколько я знаю другие языки, больше ни в каком другом этот способ не будет возможен. Дело в том, что Smalltalk позволяет остановить выполнение программы в любой момент, внести исправление в код и продолжить выполнение с точки останова. Объяснить это сложно, проще показать.
Для хранения истории проекта желательно иметь базу данных для системы управления версиями. У Smalltalk-ка она реализована на основе базы данных, и может работать практически на всех известных движках базы. У меня на сервере установлена PostgreSQL, и я могу к ней подключиться из любой точки при наличии интернета. Система хранения версий поддерживает хранение историй кода от самого начала, создание веток кода, мержа разных веток, возможность откатится до любой версии. Кроме того есть возможность просмотра истории изменения любого метода в системе, и загрузки необходимой версии конкретного метода.
Но наличие такой базы не является обязательным. Кроме системы хранения кода в репозитории существует еще ChangeList. В нем автоматически сохраняются все изменения кода с момента начала работы в образе. С его помощью можно восстановить все изменения, например в случае падения системы (такое иногда бывает при уж слишком грубых экспериментах), отключения компьютера, например при выключении питания. При этом есть возможность восстановить только необходимые методы, исключая например ошибочные. Так же как и в случае с системой хранения версий, можно посмотреть все изменения конкретного метода, и при необходимости восстановить любую версию.
Ну и наконец, самые вкусные возможности Smalltalk — ДЕБАГ и РЕФАКТОРИНГ. И я не просто так написал их большими буквами.
Начнем по порядку.
Дебагер встроенный в Smalltalk при ошибке в коде останавливает выполнение программы точке ошибки, позволяет просмотреть стек методов с просмотром содержимого всех переменных, внести изменение в любом из предыдущих методов, изменить содержимое переменных, и запустить выполнение программы с любого из них дальше. Но это тоже легче показать чем объяснить.
Как я уже сказал в ролике, это лишь малая часть возможностей для решения ошибок, реализованная в языке. Полное описание этих возможностей, пожалуй потянет на небольшую книжицу.
Рефакторинг. Основные возможности:
Изменение имени любого класса, метода с автоматическим отслеживанием всех вызовов и упоминаний. При этом дается возможность выбора изменяемых методов.
Изменение имени переменной, с автоматическим отслеживанием применения этой переменной в пределах класса. Тут надо пояснить. Все переменные в Smalltalk – приватные. То есть доступны только в пределах класса, в котором они созданы. Внешний доступ только через акцессоры (геттеры и сеттеры). Соответственно методы, которые могут использовать переменную, присутствуют только в пределах одного класса.
Добавление или удаление параметров метода с автоматическим изменением всех вызовов данного метода.
Возможность просмотра всех вызовов метода, а так же просмотр всех упоминаний класса.
Ну и еще много других функций, которые заслуживают отдельного рассмотрения. Так же хочется показать это в работе.
Вот несколько особенностей языка, которые рвут шаблоны программирования на первых этапах знакомства с языком.
Приоритеты математических операций. Их просто нет. Поскольку числа – это такие же объекты, как и всё остальное, то и операции – это обычные методы. И выполняются в обычной последовательности. Например.
а:=1+2*3/4.
Как это выполнится в обычном языке? Насколько я помню (если не прав — поправьте) 2 помножится на 3, потом результат поделится на 4 и прибавится 1.
На смолтолке к 1 добавится 2, результат умножится на 3 и разделится на 4. Это надо просто запомнить и не забывать применять скобки. Что бы выполнить действия в соответствии с результатом на обычном языке необходимо записать так:
a:= 1+(2*3/4).
Коллекции. Коллекции – это аналог массивам в других языках. Их много и разных (Set, OrderedCollection, ByteArray, и т.д). Кстати строка – это то же коллекция, и большинство методов, относящиеся к коллекции применимы и к ней. Первая особенность, в коллекции могут лежать объекты абсолютно разных классов. Вторая, самая непривычная для любого программиста особенность коллекции – индексы начинаются с 1 а не с 0. Соответственно в строке первый символ имеет индекс 1. И в любой коллекции так же. К этому то же надо привыкнуть.
Ну и третье – основное. Нет примитивов. Все – объекты. Даже Class – это инстанс класса Metaclass.
Metaclass, это инстанс класса Metaclass. Вот такое колечко на самом верху.
Ну и еще немного о вкусностях.
Расчеты без потери точности. Основная проблема во многих языках – потеря точности при делении. Например: 1/3 – это 0.3333 и 3 в периоде. Соответственно в других языках оговаривается количество знаков после запятой, и точность теряется. В Smalltalk эту проблему решили очень красиво. В результате этого деления мы получим число класса Fraction. Оно содержит в себе числитель (1) и знаменатель (3). То есть, как такового деления не будет, а будет дробь. Ничего не теряем. И все последующие операции подчиняются правилам работы с дробями. Когда необходимо получить десятичное число, просто говорим этому объекту asFixedPoint: с нужным числом знаков после запятой и получаем результат. При этом само число остается неизменным, и мы можем продолжать вести расчеты без потери точности. В других языках я такого не встречал.
Сериализация объектной структуры. Мне известны два пакета: BOSS и SIXX.
BOSS – сохраняет в файл любую объектную структуру с сохранением уникальности объектов. Сохраняет очень быстро, в бинарный файл. Сохраняет очень компактно. Есть минусы. При любом изменении в объявлении сохраненных объектов (добавлении, удаление переменных, изменение имени переменных и т.д) файл обратно не вычитается. Для моих задач не подошёл.
SIXX — сохраняет в файл любую объектную структуру с сохранением уникальности объектов. Сохраняет медленнее, чем BOSS, и файл получается больше. Файл текстовый, чем-то похож на XML. Большой плюс. В сохранённых классах можно смело удалять, добавлять переменные, нежелательно только менять их имена. Если добавится переменная, то при вычитывании из файла она инициализируется nil-ом. Такое поведение позволило мне в программе открывать проекты, сохраненные еще в первых версиях, Хотя с тех пор в проекте очень многое изменилось.
Работа с базами данных. Я пользуюсь пакетом GLORP входящим в базовую поставку. Пакет служит для сохранения базу и восстановления в базу объектов любой сложности. Для сохраняемых в базу объектов необходимо один раз описать способ их сохранения, и потом вся работа с базой будет заключаться в следующем:
1. Получить сессию работы с базой:
session := FLProgRuDescriptorSystem sessionForLogin: FLProgRuDescriptorSystem login.
2.Сохранить или обновить объект в базе
session save:object.
2. Вычитать все объекты из базы определённого класса
collection:=session readManyOff:Foo.
3. Вычитать с условием:
все где значение переменной равно id=100
collection:= session readManyOff:Foo where:[:each| each id=100].
первое где значение переменной равно id=100 и значение isCorrect = true
object:= session readOneOff:Foo where:[:each| (each id=100) &( each isCorrect=true)].
4. Удаление объекта из базы
session delete:object
Я еще не затронул вопросы создания GUI для приложения, вопросы тестирования (встроен пакет SUnit, наверное самое мощное средство тестирования из известных мне языков), деплой приложения и WEB возможности. Но пост и так получился огромный, и если рассматривать ещё и их, то до конца точно никто не дочитает. Если пост Вам понравится, то я постараюсь выбрать время и рассказать об остальном в продолжении.
Если же Вас заинтересовал этот язык то больще о нем вы можете почитать здесь:
Русская википедия посвященная языку ресурсам которой я пользовался
Группа русскоязычных пользователей Smalltalk
Постараюсь ответить на все ваши вопросы к комментариях
Комментарии (190)
totuin Автор
10.05.2015 22:26+5Язык жив и очень даже развивается. В последней версии 8.0 они изменили дизайн IDE. Я просто пока на неё не перешол. Да и вообще интерфейс меняется одним параметром в настройках. Вот например интерфейс в стиле Мас ОС
Можно полностью настроить как нравится. Но я и сам из 90-х, так что меня устраивает дефолтныйtotuin Автор
10.05.2015 22:40+2Кстати стиль окна (заголовок и форма) берётся из ОС. И у меня Win10. У неё все окна квадратные
Shoonoise
11.05.2015 14:42+6> стиле Мас ОС 10-ти летней давности
Лично мне было бы неприятно на такое смотреть каждый день.
PQR
10.05.2015 23:27Как насчётт библиотек, так нужных в бизнес приложениях: парсинг и генерация Excel (2003/2007+), генерация PDF?
totuin Автор
10.05.2015 23:39Насчет Exel сейчас в сообществе смолторкеров как разрабатывается парсер. Файлы десятого офиса разбираются на счет раз (это просто зип архивы). Мы их сами разбирали и собирали. К автокаду цеплялись по COM. Есть встроенная поддержка СОМ интерфейса (пакет ComAll).Так же сами писали пакеты для чтения dxf в объектную структуру, и выгрузку обратно в файл. Насчет PDF не знаю, надо смотреть в Sincom Public Repozinity. За бугром сообщество достаточно мощное, возможно кто то что то и написал.
А вообще есть поддержка WinApi так что возможно подключение любых библиотек и вызов их функций. Как в в линуксе это реализованно я не знаю, а под виндой не очень сложно. Например я использую для отрисовки библиотеку Cairo и она прекрасно работает.
mvaspb
11.05.2015 11:16Генерация PDF есть.
Есть некоторое количество разных интересных библиотек и инструментов.
Но надо понимать, что из-за небольшого размера коммьюнити, очень многие инструменты не реализованы или в находятся в зачаточном состоянии.
onix74
11.05.2015 00:19+9(Ох накликаю я беду!)
Автор, Ваше знание русского языка отбило охоту читать Вашу же статью на втором абзаце. А Ваши ответы и комментарии усугубили ситуацию. Ужас!
Goodkat
13.05.2015 23:05+1Комментатор, Вы после «ох» запятую пропустили. И это поборник русского языка. Ужас!
totuin Автор
13.05.2015 23:11Да ладно, все мы люди, все мы человеки. У меня жена когда читает мои тексты — сначала долго мате...., потом выгоняет из за компьютера, и долго правит. На то что бы научить меня правилам уже махнула рукой, хотя и работала долго репетитором по русскому языку. Но и после этого редакторы (я пишу статьи для журналов и хелпы для проекта), все равно находят ошибки. Так что идеального правописания по моему не существует. Всегда присутствует человеческий фактор, да и идеальной программы проверки текстов пока не придумали.
Goodkat
13.05.2015 23:30+1Автор, это была ирония по отношению к комментатору, который ужасается вашему «знанию русского языка», но и сам после первого же слова допускает ошибку :)
К вашему правописанию я претензий не имею — видно, что писали вы от души и по делу, читать ваш текст интересно, ошибки чтению не мешают.
Об ошибках в орфографии и пунктуации принято сообщать в личку, а в комментариях же — писать по делу.totuin Автор
13.05.2015 23:35Я понял что это была ирония. Спасибо за Ваш комментарий. Я поскольку действительно сам не отличаюсь грамотностью, очень терпимо отношусь к другим таким — же. Ну и привык уже к тому что меня постоянно ругают за это. Заслужил)))). Кстати многие написали мне в личку подсказки где исправить ошибки. Спасибо им за это. Благодаря им я смог привести пост в более менее удобочитаемый вид.
onix74
14.05.2015 06:49Да, неувязочка! А ведь должна была быть. Коммментарий писал со смартфона. (Не в качестве оправдания, а так… констатация факта).
totuin Автор
11.05.2015 00:28+6Да с чистописанием у меня не все хорошо. Хотя статью вроде проверял Word — ом. Ну что поделать, не все мы филологами родились. Да и на вахте я сейчас, жена далеко. Обычно она меня проверяет. Глубоко извиняюсь если чем то обидел русский язык.
DmitryKoterov
11.05.2015 05:50+2Нажимаем «рун»! :)
totuin Автор
11.05.2015 05:59Ну да я не писатель. Ну уж какой есть. И образования высшего у меня нет. Извините меня безграмотного.
totuin Автор
11.05.2015 06:23Я вспомнил откуда это -Run. Первая моя программа связанная с прффесиональной деятельностью написана была на бейсике для компьютера Агат. Как говорится привычки рождаются в молодости и остаются на всю жизнь.
Int_13h
11.05.2015 12:51+1В универе на первом курсе, препод, обучавшая нас вижуалвасику, не знала английского, зато знала немецкий. Рун, зуб, буттон и дебуг.
Mingun
11.05.2015 12:18Наличие внешней проверки не отменяет наличие внутренней. Вы хоть почитайте, что написали (обычно на следующий день после написания большинство косяков видны) — уже просто читая, так и хочется вопросить: «запятые уже отменили?» Это, кстати, касается и цитат из википедии — там тоже тихий ужас. Как я понимаю, вы их даже не читали, понадеевшись на Ctrl+C, Ctrl+V. А ведь можно было сделать доброе дело и поправить. Остальное отправил личным сообщением.
Ну и опять же, вижу стандартную кашу в голове, когда в одну кучу свалены особенности языка и конкретной IDE, библиотек и всего того, чем автор пользуется, лишь бы набросать побольше плюсов своему любимому языку. Ну какая поддержка дебага и рефакторинга на уровне языка? Это чисто фишки IDE. То, что организация языка — все переменные приватные — упрощает рефакторинг, не означает, что язык его поддерживает. А если вам нужно поменять геттер/сеттер? Туда же работа с БД и GUI, репозиторий кода.
При любом изменении в объявлении сохраненных объектов (добавление, удалении переменных, изменении имени переменных и т.д) файл обратно не вычитается.
Это что ж получается — поменял переменную-счетчик цикла (утрированно, знаю, что есть методы обхода элементов) и все, кирдык?
chaetal
12.05.2015 08:14+2Справедливости ради замечу, что в Smalltalk-е разделить «философию», язык, библиотеки, IDE — довольно сложно. Не видел, где автор написал про «поддержку дебага и рефакторинга на уровне языка», но это, в какой-то степени, ближе к истине, чем фраза «Это чисто фишки IDE».
naryl
11.05.2015 00:44+3За исключением около 10% статья как про Common Lisp.
На самом деле я, познав оба языка, даже пытался сделать Class Browser (это те самые 10%) для CL. Если есть желающие, могу поделиться наработками и списком нерешённых (но не неразрешимых) трудностей.
Goodkat
11.05.2015 02:01Расскажите, как обстоят дела с кроссплатформенной разработкой:
1. Нужно писать отдельный GUI под каждую OS?
2. В GUI используются нативные контролы?
3. Нужно устанавливать виртуальную машину отдельно, как для Java, или приложение компилируется в исполняемый бинарник отдельно для каждой ОС?totuin Автор
11.05.2015 02:20С GUI все обстоит прекрасно. Практически все отрисовывается средствами SmallTalk. Кроме хедара окна (в каждой ОС он будет родной для неё).
В остальном отрисовка и работа ГУЯ от ОС не зависит. Так же надо проверить отображение шрифтов. В целевой ОС необходимых может не оказаться, Система подберёт подходящие. Может получиться некрасиво. У меня с переходом на другую ОС были проблемы с запросом домашней папки (Ну не линуксоид я — не знал как называется переменная окружения. Теперь знаю — помогли). Так же была проблема с работой с Com портом. Оказалось даже проще чем в винде. Работаеш как файлом (точнее с потоком — Stream). C маком и компортом пока не разобрался (не заработал пока на мак), поэтому версии под него пока нет.
Виртуальную машину устанавливать не надо. Надо положить в одну папку необходимую виртуалку и файл образа. Причем он один для всех ОС. Главное что бы имена виртуалки и образа совпадали. В винде просто двойной клик по виртуалке, она ищет у себя под боком одноимённый файл образа и работает с ним. С линуксой посложнее немного. Рядышком надо положить скрипт примерно такого содержания:
#!/bin/sh
./flp flp.im
и запускать его.
Как то так
Halt
11.05.2015 04:26+3Автор статьи немного лукавит. Система виджетов в смолтоке своя, построена по отличным от принятых принципам (морфик). Поддержка нативных виджетов системы часто условная. Тесная интеграция с системой часто болезненна. Сказалась многолетняя изоляция мира смолтока от остального мира IT.
Это действительно проблемы которые надо, как мне кажется, решать системно. Сейчас же это больше напоминает попытку нарисовать скин похожий на системный и успокоиться. Джава в свое время тоже придерживалась модели собственных элементов управления, но к счастью от этого отошли.
Ближе всего к системе находится Dolphin Smalltalk, но он нифига не кроссплатформенный, платный и нифига не развивается.totuin Автор
11.05.2015 04:37Ну вообще то я об этом и написал:
Практически все отрисовывается средствами SmallTalk. Кроме хедара окна (в каждой ОС он будет родной для неё).
В остальном отрисовка и работа ГУЯ от ОС не зависит.
Мне пока хватает встроенных виджетов. Если что то надо изменить, можно отнаследоваться от базового, и рисовать виджет как душа пожелает. Не знаю получится ли так с наитивными виджетами. А здесь мне в большинстве случаев достаточно научить объект отрисовыватся на вьюшке так как мне надо.
И да благодаря этому достигается кроссплатформеность. Dolphin Smalltalk действительно красивый но только под винду
vk2
11.05.2015 08:22+1Скажем, система виджетов вообще в каждом смоллтоке своя ) Morphic — это Squeak/Pharo, а автор рассказывает про VisualWorks.
Чтобы коммент был не совсем пустой, оставлю ссылку на amber-lang.net, выглядит мило.
mvaspb
11.05.2015 11:27Морфик это в Squeak/Pharo.
Про dolphin smalltalk — забудьте, он умер и вряд ли восстанет из пепла.Halt
11.05.2015 17:48+1Вот что меня в них поражает, так это какое-то непонятное жлобство. Ну ладно, поняли, что проект не взлетит. Но зачем все было прятать в сундук? Открыли бы исходники или просто сделали бы свободную community версию — пускай бы развивался сообществом.
mvaspb
11.05.2015 11:22Есть два ведущих диалекта:
- VisualWorks Smalltalk (платный, есть бесплатная версия для себя без ограничения возможностей)
- Pharo (бесплатная)
Под каждую платформу есть своя виртуальная машина, здесь как для Java. Есть возможность скомпоновать исполняемую виртуальную машину и образ в единый бинарник. Только смысла в этом не много. Надо понимать, что если вы пишете тиражируемый софт для домохозяек, то Smalltalk не ваш выбор.
GUI кроссплатформенный и реализован весь на Smalltalk. Отличаются только вызовы к system API для создания окон, но это все инкапсулируется в виртуальной машине. Так что, файл образа абсолютно переносим с платформы на платформу
Halt
11.05.2015 04:14+7Приветствую единомышленника!
Статья неплохая, хоть и сумбурная.
К сожалению, введение в смолток писали уже все кому не лень (включая меня), но нормальных статей по прежнему нет. Все пишут что язык классный, все здорово, приводят пару стандартных примеров и на этом все заканчивается обычно.
Нужна нормальная статья с примером практической разработки. Хорошо бы продемонстрировать, что такое Smalltalk way с точки зрения проектирования. Показать, как концепция превращается в реализацию на примере конкретной задачи. Вы упомянули разработку FLProg. Вот и опишите, как происходила разработка и что позволило делать это быстро и эффективно. Это все равно что хаскель объяснять на примере десяти вариантов реализации факториала.
Во-вторых, говорить только о прекрасных сторонах языка — нечестно. Надо рассказать и об недостатках, включая проблемы с нативными виджетами и отсутствием нормальной свободной реализации (Pharo конечно есть, но это не тот уровень).Halt
11.05.2015 04:19P.S.: Прошу прощения, предложение про хаскель семантически относится к прыдыдущему абзацу :)
totuin Автор
11.05.2015 04:22+3Это вводная статья, так сказать поверхностный обзор. Мне было интересно посмотреть как сообщество отреагирует на этот язык. Если статья заинтересует читателя, я напишу продолжение. Со стилем у меня не очень, но что рассказать есть. Про ГУЙ — это вообще отдельный вопрос. Непривычно до ужаса, но если понять — то очень мощный платформонезависимый механизм. Для его описания потребуется не один пост. Вы кстати первый кто заинтересовался продолжением. Писать то надо для заинтересованной публики, а если никому неинтересно — то зачем писать? Посмотрим на реакцию.
Goodkat
13.05.2015 23:35Было бы интересно увидеть что-то типа getting started — hello world, GUI, общепринятая структура организации кода программы, деплой готового приложения под разные ОС.
А то скачал образ, открыл, потыкал в дерево классов, впечатлился и закрыл :)totuin Автор
13.05.2015 23:43+1Я постараюсь в ближайший месяц наваять что ни будь подобное. Как ни смешно, самое сложное придумать сценарий. То есть «а что конкретно собрать такое что бы и осмысленно и недолго». У меня в связи с моим проектом уже набрался достаточно большой опыт в написании видео уроков, но всегда это самая большая проблема. Первый видео урок по проекту получился полтора часа, и из шести с половиной тысяч просмотревших только 5% просмотрели до конца. Очень сложно сделать так что бы это было не громоздко, не долго и более менее законченно.
chaetal
11.05.2015 11:28А каким местом Pharo не на том уровне?
Halt
11.05.2015 13:55+2Возможно я не так выразился. Как среда разработки именно под Smalltalk он хорош. Я имел в виду интеграцию с остальным рабочим окружением. Современные интерфейсы это не только и не столько «кнопочки и галочки», сколько сервисы.
Взять тот же Qt. Помимо собственно графической подсистемы, он предоставляет большие возможности по взаимодействию с окружающим миром. Особенно если это заметно на уровне KDE.chaetal
12.05.2015 07:55Все равно не понимаю мысль…
У Smalltalk-а очень долго было и до сих пор остается много «детских» болезней. Pharo как раз — попытка все это решить и сделать, наконец, нормальный рабочий Smalltalk так сказать «на современном уровне». Пока, на мой взгляд, все идет неплохо… Я бы даже сказал, лучше, чем можно было ожидать.Halt
12.05.2015 11:06Современный язык должен поддерживать многопоточность. Оставаться только на грин тредах это не дело. Во-вторых, нативные виджеты. В третьих JIT. Можно сколько угодно говорить, что смолток не для этого, но мне кажется это только провоцирует изоляцию.
Вы случайно не знаете подробностей по поводу поддержки многопоточности и JIT в CogVM? В образе есть нечто под названием AsmJIT, но непонятно, насколько оно функционально.chaetal
12.05.2015 12:07Современный язык должен поддерживать многопоточность. Оставаться только на грин тредах это не дело.
Это — да. Точнее, есть нюансы и варианты, но в целом я, скорее, соглашусь. Однако это проблема не Pharо/Squeak, а всех Smalltalk-ов.
Во-вторых, нативные виджеты. В третьих JIT. Можно сколько угодно говорить, что смолток не для этого, но мне кажется это только провоцирует изоляцию.
Я думал, мы именно особенности Pharo обсуждаем… А так — да, все это слабые места современного Smalltalk-а. Опять же, есть всякие оговорки и отговорки, но это все пока разговоры в пользу бедных. Многим все это не позволяет серьезно использовать Smalltalk. Но некоторым и не мешает.
Вы случайно не знаете подробностей по поводу поддержки многопоточности и JIT в CogVM? В образе есть нечто под названием AsmJIT, но непонятно, насколько оно функционально.
Деталей не знаю, тема для меня слишком сложная :) За все не уследить… А так, вроде, какие-то неплохие подвижки в эту сторону идут, судя по перепискам в Smalltalk-овских листах и докладам на конференциях.Halt
12.05.2015 12:20Однако это проблема не Pharо/Squeak, а всех Smalltalk-ов.
Во-первых, пролетали новости о том что в BeeSmalltalk якобы делали поддержку реальной многопоточности чуть ли не в пару десятков строк.
Во-вторых, еще лет несколько назад где то видел препринты статьи о том что делали акторную систему на базе многопоточного смолтока и рапортовали об успешной работе в сильно многопроцессорной системе (64 процессора, если не ошибаюсь).
Наконец мы в llst.org планируем реализовать честную многопоточность, правда пока не ясно какого рода ограничения это наложит. Возможно придется делать отдельные кучи и обмен объектами между потоками будет ограничен.
Деталей не знаю, тема для меня слишком сложная :) За все не уследить… А так, вроде, какие-то неплохие подвижки в эту сторону идут, судя по перепискам в Smalltalk-овских листах и докладам на конференциях.
Проблема в том, что судя по тому коду что я видел, это банальный и печальный велосипед — ручное генерирование x86 инструкций. Никакой абстракции над архитектурой нет в принципе, не говоря уже про оптимизации. А делать банальную трансляцию байткодов смолтока в x86 это не самая удачная мысль. Как показали наши тесты, оно будет не быстрее прямой интерпретации.chaetal
12.05.2015 13:04Про пчелку в курсе, но там ничего пока не ясно же? Похожих многообещающих в плане решения глобальных проблем проектов было много, но воз и ныне там… Проблема существует, люди над ней работают, но решающего ее полноценного промышленного Smalltalk-а пока никто не видел…
Кстати, есть альтернатива. Проблема же на самом деле не в том, чтобы внести в Smalltalk нативную многопоточность как таковую (не такая уж она и хорошая, умные люди говорят), а дать возможность распределять процессорную нагрузки по ядрам, верно ведь? А это можно сделать, запуская несколько образов, если дать им возможность между собой нормально общаться, разумеется. В Cincom-е уже несколько лет такое решение существует. Восторгов правда почему-то не слышно :)
По поводу JIT-а, к сожалению, ничего конкретного сказать не могу — не компетентен. Хотелось бы, конечно, «нормальный» Smalltalk — который мог бы менять любую свою часть «на лету», в том числе и этот аспект… Мечты :)Halt
12.05.2015 13:28Не для каждой задачи подойдет вариант «просто запустить N образов». Тупо разбрасывать пользователькие запросы по инстансам — это да. А вот параллельно пройтись несколькими потоками по общему графу уже не получится.
Передача данных между ними будет возможна или посредством сериализации (прощай скорость), или очень ограниченным набором данных (например только замороженные объекты содержащие литеральные константы).
Честные потоки хороши тем, что отдельные параллельные треды находятся в общем адресном пространстве и могут разделять объемные данные без накладных расходов (кроме синхронизации).chaetal
12.05.2015 14:06Ясно, что есть разные модели организации параллельных вычислений, многое зависит от задачи, что разделяемая память имеет преимущества и недостатки, и да, потоки тоже бывают полезны, но есть еще и всякие кластеры, распределенные системы и т.д.… И что сейчас многое пересматривается, изменяется и изобретается заново :)
Но я не специалист (к моему огромному сожалению) в этой области, тем более в технических деталях — не в состоянии поддержать беседу, и сливаюсь :)
Да и мы уклонились от исходной темы, вроде… В общем: в Smalltalk-сообществе признают проблему и что-то делают по поводу ее решения. Сам с удовольствием бы почитал какой-нибудь обзор на эту тему.
Mingun
11.05.2015 12:29+1Кстати, ваша статья очень хороша — все аккуратно расставляет по полочкам, побольше бы таких. Всем (ну как всем… тем, кто хочет узнать что-то новое, даже если это его никоим боком сейчас не касается, как Smalltalk меня) рекомендую. Жаль, на момент прочтения срок голосования уже истек.
davidovsv
11.05.2015 07:34+2Спасибо за обзор. Было бы интересно прочитать продолжение про web-приложение на SmallTalk.
vk2
11.05.2015 11:51+2www.seaside.st
В свое время это было дико инновационно и круто. Но, по-моему, там уже ничего не развивается. Компанию автора купил Твиттер.chaetal
12.05.2015 07:43Сейчас есть надежды по поводу Amber-а, которого ты уже упоминал. Если получится нормально связать с «полноценным» Smalltalk-ом, может получится реально интересная вещь… Только вот не особо пытаются пока :)
alexstz
11.05.2015 09:18Кстати, по поводу «Программирования через дебаг» вспомнил, что делаю так же в Chrome Dev Tools для JS :)
stalkerg
11.05.2015 10:24+2Заранее извиняюсь. После прочтения всего выше сказанного, чем Smalltalk приятнее Python (не говорю лучше)?
Прошу мнения автора, который хорошо знает Smalltalk ну и глянуть на синтаксис Python дело пары минут. :)chaetal
11.05.2015 11:50Навскидку и скорую руку:
Простотой базовых идей: Smalltalk — чистая объектность чусть подпорченная классами. Питон (если не ошибаюсь, ориентируясь на википедию) — еще один «мультипарадигматический» язык.
Простотой синтаксиса: Smalltalk — (почти) только посылка сообщений + чуть-чуть сахара. Наглядно видно на 'if'-ах, которые в Smalltalk-е — просто методы. Не все так идеально в Smalltalk, но гораздо лучше, чем где бы ты ни было (из известного мне).
«Образностью» :) Smalltalk-а — в том смысле, что все объекты живут в общей среде; все этом можно в любой момент сохранить, а потом продолжить с той точки, где сохранились. Такой бесплатный базовый персистенс. Жаль только пока (надеюсь) дальше не развивают. Но и сейчас в принципе можно разработать приложение не думая о БД совсем, а потом перенести его в среду с полноценной (лучшей до сих пор?) объектной СУБД (я про GemStone).
Изначальной ориентированностью Smalltalk на то, чтобы быть средой разработки (а не только компилятором) —> до сих пор непревзойденные возможности разработки. И это несмотря не только на «90-сть GUI», но и на то, что процентов 95% потенциала среды до сих пор не раскрыто.
Подозреваю, что мета-возможности Smalltalk более естественны и просты. Классический пример — добавление континуаций без каких-либо изменений в языке.
В целом, отличия Smalltalk-а от Python-а — примерно такие же, как отличия Smalltalk-а от любого современного мейн-стримового языка :) То есть, принципиальные.
Idot
11.05.2015 11:26Что с графикой и скоростью работы? То есть легко ли подрубить OpenGL или DirectX, и насколько быстро работают приложения?
(для сравнения Delphi — очень удобен, но игру всё-таки лучше писать на C++)mvaspb
11.05.2015 11:54+2Кесарю — кесарево, богу — богово.
Не надо писать игр на smalltalk. Он не для этого.
Давайте я расставлю точки над i
Плюсы:
Основное преимущество St — это офигительное, удобное конструирование. Вам будет легко выделить классы, построить взаимодействие между ними, увидеть как это работает. Представьте себе прозрачный двигатель внутреннего сгорания — вы увидете как взаимодействуют объекты внутри вашей программы. Вы сможете в лобой момент сказать двигателю «замри», подкрутить в нём что-то, изменить поведение объекта, и сказать «отомри» и он пойдет работать с всеми изменениями. Язык предоставляет исключительные возможности по конструированию.
Это преимущество вытекает из следующих предпосылок:
1. Синтаксис близкий к английскому языку. Сравните вызов метода в обобщенной сигнатуре для основных ЯП:
и для StpaintItemsInArea(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, только что с того? В общем для веба — не он.
Заключение: превосходен для прототипирования сложных объектных систем энтерпрайз уровня. Вырабатывает отличные скиллы по ООП.chaetal
12.05.2015 08:02+1Не надо писать игр на smalltalk. Он не для этого.
Могу ошибаться, но по слухам в Транзасе довольно долго делали симуляторы и всякую виртуальную реальность на Smalltalk-е, пользуясь тем фактом, что «сверх-скорость» нужна не везде. Да и игры бывают разные… Не все так однозначно.
Не надо писать сложные веб приложения на нем с rich client-side, поддержка JS бибилотек есть, но работать с ней неудобно. Возможно, это чисто мое имхо. Мне могут возразить, что вот у нас есть знаменитый Seaside web framework, только что с того? В общем для веба — не он.
Видели Amber?mvaspb
12.05.2015 09:24Могу ошибаться, но по слухам в Транзасе довольно долго делали симуляторы и всякую виртуальную реальность на Smalltalk-е, пользуясь тем фактом, что «сверх-скорость» нужна не везде. Да и игры бывают разные… Не все так однозначно.
Я работал в Транзасе в той самой виртуальной реальности (Trans-Force). Симулятор, это речь о вертолетном тренажере.
Работа с этими проектами на Smalltalk и сейчас ведется (два года назад точно велась).
В обоих проектах Smalltalk используется для написания управляющей программы. За вертолетный тренажер не скажу точно, но, вроде, они все моделирование физики поведения вертолета в Smalltalk перевели. Могу ошибиться. Управление комплексом Trans-Force все написано на St. А теперь жирное НО. Сама визуализация трехмерного пространства (полета) — это другая среда, вроде, называлась «Аврора». На чем написана не знаю, но это не smalltalk.
Amber видел. Пока как приложить к веб-проектам не знаю. Скажите, вот есть meteorjs, мне он нравится. Как его можно использовать вместе с Amber? Если никак, то пока он неинтересен.chaetal
12.05.2015 11:48Я работал в Транзасе в той самой виртуальной реальности (Trans-Force). Симулятор, это речь о вертолетном тренажере.
Я знал! Я знал! :)
А теперь жирное НО. Сама визуализация трехмерного пространства (полета) — это другая среда, вроде, называлась «Аврора». На чем написана не знаю, но это не smalltalk.
Я же об этом и говорю: Smalltalk-у есть место и в играх, не самое маловажное место.
chaetal
12.05.2015 11:56Amber видел. Пока как приложить к веб-проектам не знаю. Скажите, вот есть meteorjs, мне он нравится. Как его можно использовать вместе с Amber? Если никак, то пока он неинтересен.
Не в курсе, что такое meteorjs. Но, скорее всего, как и с любой другой JS-библиотекой. Вопрос, нужно ли — вполне возможно, amber и meteorjs являются конкурентами? Предлагаю продолжить обсуждение в RSUG-е :)
dipspb
12.05.2015 09:24Amber хоть красив и интересно сделан на современных механизмах, но пока это отдельная вещь в себе.
chaetal
12.05.2015 11:58Поддержка WebSocket и в Amber-е и в Pharo делает это утверждение не совсем верным. Есть и конкретные решения (с JSON-ом, вроде) для организации общения… Но в целом соглашусь — пока это дело не докачано до нужного уровня.
EvilFox
11.05.2015 15:18+1Спасибо за статью.
Давно присматриваюсь к этому языку, но есть вещи останавливающие меня. Прошу знатоков ответить на эти вопросы (сам я новичок, поэтому вопросы могут посчитаться кем-то глупыми):
1. Возможно ли на этапе выпуска приложения почистить автоматически образ от всего лишнего, оставив только действительно необходимое для работы программы? Там ведь хранится куча неиспользованного. Образы тяжеловесные. Я видел у того же Pharo минимальный образ в 2-3МБ, но это не совсем то, хотелось бы примерный аналог жёсткой компиляции когда выкидывается всё лишнее.
2. Возможно ли изменить синтаксис средствами языка? Скажем я хочу переназначить «:=» на другой знак. Если да, то как это сделать? Отталкивает синтаксис smalltalk, но само устройство интересно.
3. Возможно ли морду привести к системному виду? Чтобы автоматом бралась тема системы, может какие-то наработки уже есть? Биндинги в другие морды? (Tk, Qt и т. п.). Для Qt я нашёл только мёртвые ссылки под GNU Smalltalk.
4. В тексте упоминалась возможность работать с файлами вместо образа, как это сделать? Нашлась только интеграция с CVS/Git.
5. Насколько между собой совместимы разные ВМ/платформ? Их существует множество: GNU Smalltalk, Squeak, Pharo, VisualWorks, Dolphin… В чём в основном их различия? Сложно ли переносить код написанный под одной ВМ на другую?
С чего вообще стоит начать новичку? Где искать чужие наработки? Гугл-то находит далеко не всё.mvaspb
11.05.2015 16:04+21. Да возможно очищение. Но жесткое вряд ли. Поскольку язык динамической типизации, то самостоятельно определить, что выкидывать, а что нет он не в состоянии.
2. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.
3. Можно. Иногда это не будет 1 в 1, но что-то похожее. Так как GUI все таки не native
4. Нет, нельзя. То что вы упоминаете, всего лишь возможность выгрузки пакетов в файлы для интеграции с GIT. Собственные репозитарии кода более удобны для просмотра изменений (версионность базируется на методе, не на файле); Плюшек типа pull request нету
5. Переносить не очень сложно, но различия существуют.
Начинать лучше с Pharo (pharo.org) — относительно большое и отзывчивое коммьюнити, наиболее прогрессивный диалект
eugenius_nsk
11.05.2015 19:092. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.
Уточню, что если очень-очень хочется, то можно — для этого придётся изменить компилятор (он написан на самом Smalltalk, живёт в том же самом образе, и вызывается при сохранении метода). Но лучше этого не делать.EvilFox
11.05.2015 20:39Любопытно. А где например его можно посмотреть? Точнее как он конкретно называется? Где-то можно прочитать про низкоуровневую архитектуру Smalltalk? Для меня открытие что там внутри компилятор сидит написанный на самом Smalltalk.
Halt
12.05.2015 11:12Могу посоветовать мои статьи по архитектуре LittleSmalltalk. Надо только сразу оговориться, что LittleSmalltalk не поддерживает стандарт Smalltalk80, хотя для понимания базовых принципов это не нужно.
EvilFox
11.05.2015 20:341. То что динамический понятно, но есть же профилировщики, как например тут на 5 шаге. Можно было бы использовать подобный подход чтобы определить что и как используется, после чего отбросить всё лишнее, транслировав исходные коды в байткоды для компактности (хотя я не ковырял образ, может там уже полный байткод).
4. Просто я увидел фразу в статье:Образ системы является основным контейнером информации в Smalltalk — т.е. в Smalltalk не приняты текстовые файлы с исходным кодом. В принципе, их можно создавать, но работать с образом системы гораздо удобнее.
Это ошибка?
В целом ясно, спасибо за ответ.chaetal
12.05.2015 08:07+11. То что динамический понятно, но есть же профилировщики, как например тут на 5 шаге. Можно было бы использовать подобный подход чтобы определить что и как используется, после чего отбросить всё лишнее, транслировав исходные коды в байткоды для компактности (хотя я не ковырял образ, может там уже полный байткод).
Анализ в динамических языках тоже, разумеется, возможен. Есть всякие наработки на данную тему. Но именно про такой инструмент я не слышал. В VisualWorks, насколько помню, это делается частично автоматически, но без участия человека может получится не очень хорошо в сложных случаях.
totuin Автор
11.05.2015 17:48Ну прежде всего первый мой проект на смолтолке Cadel. Сейчас я уже в нем не участвую, но был одним из «родителей». Мой текущий проект FLProg. И сама программа и сайт написаны на смолтолке. Этот проект я разрабатываю один, и на другом языке боюсь бы у меня это не получилось. Ну еще много различных полезных программок как говорится «для вутреннего потребления» создано за эти годы.
sheknitrtch
11.05.2015 18:31+1Я тоже в своё время влюбился в этот язык программирования. Удивительно, что с 80-х годов синтаксис и основные принципы работы языка практически не изменились. То есть, изначально Алан Кей достал бритву Окама и сделал простой и одновременно мощный язык, который легко расширять (добавление Try-Catch конструкций можно сделать средствами самого языка, не вводя новых ключевых слов и не меняя виртуальную машину), и который объектно-ориентированный до мозга костей (в отличие от той же Java, где есть int, boolean и float, выпадающие из общей идеи «всё есть объект»). Плюс всё динамическое: можно добавлять/удалять классы и менять методы прямо в процессе работы приложения. Рекомендую пройти какой-нибудь туториал по этому языку. Он заставляет мозг работать немного по другому и прививает «чистый» ООП стиль программирования.
Конечно у Smalltalk есть недостатки. В частности меня смущает образ системы, внутри которого «живёт» виртуальная машина и управляет объектами.
totuin, подскажите, как происходит deployment приложения на сервер? Вы закачиваете готовый образ системы и запускаете VM с этим образом? Или рабочий сервер выкачивает исходный код из базы и компилирует его на лету?totuin Автор
11.05.2015 18:41У меня на сервере работает открытый образ разработчика (сервер на Win Server 2008 r2, доступ по RDP). Это позволяет на лету дорабатывать сайт без остановки сервера. При создании новых страниц я сначала ссылку на них создаю только для администратора сервера (то есть для меня), а после готовности открываю для всех. А вот бэкапер сайта представляет собой независимое приложение, в виде Run Time образа и своим UI.
oberon87
11.05.2015 20:17-6Как говорил Н. Вирт:
Smalltalk годится чтобы учить возить черепашку по экрану. В остальном бесполезен.
totuin Автор
11.05.2015 20:33+3Информация из википедии:
Вирт, Никлаус
В 1970 году создал язык программирования Паскаль. В 1970-х годах разработал, вместе с Хоаром и Дейкстрой технологию структурного программирования. Вышедшая в 1971 году статья Вирта «Разработка программы методом пошагового уточнения» описала и обосновала ставшую впоследствии классической методологию разработки программного обеспечения «сверху вниз».
В 1975 году разработал язык Модула, в котором реализовал идеи разработки модульных программ с хорошо определёнными межмодульными интерфейсами и параллельного программирования. Кроме того, в Модуле был изменён синтаксис языка — Вирт избавился от унаследованной ещё от Алгола-60 необходимости применять составные операторы в конструкциях ветвления и циклах.
Судя по его разработкам для него тяжело было понятие объектно ориентированого программирования основанного на событиях и сообщениях. Наверно этим и вызвано его высказывание. В то время вообще к ООП относились настороженно, но в конце — концов можно сказать что оно победило.
В том же Паскале (нынче Delphi), ООП до сих пор прикручено где то сбоку.
oberon87
12.05.2015 10:07Цитата 2005-го года, так что у всех было время оценить результаты.
Хотя, вот цитата из 1998-го:Объектно-ориентированное программирование вышло из принципов и понятий традиционного процедурного программирования. Скажу больше: в ООП не добавлено ни одного действительно нового понятия; просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое — это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов «объект» и «метод». Средством для такой привязки является процедурная переменная (или поле записи — record field), доступная в языках программирования с середины 70-х гг. Второе понятие — это конструирование нового типа данных (названного «подкласс») путем расширения заданного типа («суперкласс»).
Как мы можем увидеть, все не так грустно, как Вы предположили из статьи Википедии. На этом можно закрыть тему непонимания Н. Виртом ООП.
Стоит заметить, что вместе с ООП пришла совершенно новая терминология, имевшая целью затемнить происхождение его корней. Таким образом, если раньше вы могли инициировать активность процедуры путем ее вызова, то теперь должны посылать сообщение методу.mvaspb
12.05.2015 10:17+1Скажите, вы, говоря про черепашку на экране, не спутали Smalltalk с Logo? Вроде черепахи это там.
oberon87
12.05.2015 10:50+11) Это цитата Н. Вирта
2) Черепашка это же языконезависимый исполнитель.
Если хотите моё мнение, то оно такое: любой язык с такими выдающимися качествами как:Все переменные в объектах являются указателями.
Во-вторых Smalltalk – динамически типизированный язык. То есть в любую переменную можно положить ссылку на инстанс объекта любого класса.
вообще нет смысла рассматривать как нечто стоящее людских усилий. Но если завалить его деньгами, то вполне получится какой-нибудь веселый кадавр, типа javascript.
chaetal
12.05.2015 12:14По-моему, ее действительно можно закрыть этой цитатой, поскольку Вирт явно расписался в своем непонимании объектного подхода.
Не, я не хочу сказать, что я вот такой умный и понимаю, а Вирт такой тупой и не понимает :) Просто он действительно «не просек фишку» по каким-то причинам.oberon87
12.05.2015 15:42А в чем фишка?
chaetal
12.05.2015 16:04В сообщениях, если коротко.
oberon87
12.05.2015 16:43Все же стоит разделять термины «передача сообщения объекту», который однозначно трактуется только внутри парадигмы ООП, и понятия процедурного программирования «вызов процедуры/функции каким-то образом привязанной к экземпляру структуры и передача ей набора параметров».
oberon87
12.05.2015 16:47Поэтому и непонятно, в чем же тут фишка? Просто в новых словах?
chaetal
12.05.2015 17:10Вот и Вирту, было не понятно :) А вы хотите, чтобы я здесь в комменте раскрыл вопрос во всех аспектах?
Сообщение от вызова отличается тем, что в первом случае мы не знаем, как получатель отреагирует на это сообщение. Звучит странно, но это ставит программирование, как ни удивительно, с головы на ноги. Впрочем, не удивительно — ведь в реальной жизни все примерно так и обстоит, да?
Сказывается это и на «философии» программирования, и на языке, и на методах построения дизайна системы (я не про GUI)… это приводит к чему-то вроде TDD… Как побочный эффект — существенные, если не сказать принципиальные, отличия Smalltalk-а от, казалось бы, аналогичных языков… В общем я могу курс лекций по этому поводу прочитать (собственно, и читал до недавнего времени) :)akastargazer
12.05.2015 17:23Вы знаете, вот я в Блэкбоксе (BlackBox Component Builder, рантайм-среда для оберона) даже не пытаюсь узнать, как отреагирует на моё сообщение виджет, вставленный в контейнер, обёрнутый несколькими врапперами. Мне и не нужно знать, это же гетерогенная структура, я просто туда посылаю сообщение.
oberon87
12.05.2015 17:34-1Мы и во втором случае не знаем. И догадок не делаем.
akastargazer
12.05.2015 17:38+1Ну, я бы сказал, что явное знание о вызываемом методе даёт нам детерминированность поведения. А сообщение можно обработать, а можно и не обработать. Концептуальный смысл «сообщения» вполне очевиден, вопрос в том, надо ли вводить в формальный аппарат дополнительную сущность или можно обойтись уже имеющимися инвариантами.
oberon87
12.05.2015 17:55Все же, и в том и в другом случае мы имеем дело с одним принципом: черный ящик сам решает, какая связанная процедура вызывается в результате нашей попытки ее вызвать. Путь прохождения вызова так же нам безразличен. Но как видно из обсуждения, это в языке Smalltalk выведено из набора внеязыковых приемов и введено в язык.
Ну а привычка все тащить в язык давно известна. Чего стоит хотя бы эта картинка
mvaspb
12.05.2015 18:29+3«Syntax volume (N of lexems)» — это количество предопределенных синтаксических конструкций в языке?
Если так, то, видимо, постеснялись туда St поставить.
Там их гораздо меньше — три конструкции и 6 зарезервированных слов.
Перечислю конструкции (остальное по ссылке):
1. := (присваивание)
2. ^ (возврат результата из метода)
3. собственно отправка сообщения объекту
Все остальное, вся стандартная библиотека (все это if then else, loop operators/iterators, collections and so on) реализовано на самом St и доступно для изменения, если такое взбредет в голову.
oberon87
12.05.2015 19:20И это не говоря про эзотерику всякую. И что?
mvaspb
12.05.2015 19:43+1Вы что имеете в виду про эзотерику?
>И что?
Гм, да, в общем-то, ничего. А вы картинку-то к чему тогда привели? Вы хотели показать «как мало предопределенных конструкций в Обероне»?
Дискуссия явно начала вырождаться.
akastargazer
12.05.2015 20:03Наверное, не постеснялись. Потому что синтаксис оценивался по РБНФ, а есть ли таковая для Smaltalk?
mvaspb
12.05.2015 20:14Пожалуйста, гугл в помощь
chronos-st.blogspot.de/2007/12/smalltalk-in-one-page.html
Возможно, вам будет интересно вот этоakastargazer
12.05.2015 21:19Вы будете смеяться, но РБНФ синтаксиса Оберона меньше, чем Smalltalk :)
chaetal
13.05.2015 05:42И о чем это говорит?
akastargazer
13.05.2015 11:20Это говорит о том, что ваши слова «Там их гораздо меньше — три конструкции и 6 зарезервированных слов.» сделаны несколько сгоряча.
chaetal
13.05.2015 11:24Попробуйте разобраться и понять, а не просто спорить.
Вот интересная ссылочка: code.uko.tymchuk.me/2013/02/grammars-complexity-comparison.html. Покажите такую диаграмму для Oberon-а и все увидят, насколько прост этот язык.akastargazer
13.05.2015 11:40Интересные рисунки. Два вопроса:
1) Как туда загрузить синтаксис Оберона? (не вручную же рисовать)
2) Как сравнивать результаты — по высоте, по ширине или по глубине?
chaetal
13.05.2015 05:44И, самое интересное, со временем их не становится больше. Вот чудеса! :)
oberon87
13.05.2015 10:33Когда есть некая тенденция, то наличие исключений, не попадающих под тенденцию, не отрицает тенденцию.
Вас задело, что куча языков на одном графике? Типа, «нашли что сравнивать, вот в языке Му всего одно ключевое слово Му». Ну нарисуйте каждому языку по своему графику, и все равно там будет разрастание рбнф-описания.mvaspb
13.05.2015 10:53Простите, а вы что доказать-то хотите?
Что ООП фигня? Что Оберон круче всех? Что именно?oberon87
13.05.2015 11:00Не ставил себе такой цели. Мы тут рассуждаем про соотношение терминологий внутри всевозможных методик и про отношение этих терминологий к базовым понятиям сферы нашей общей деятельности. Если вас это утомляет и вы хотите перейти к конфликту религиозного свойства, то пожалуйста. В отдельной ветке.
chaetal
13.05.2015 11:26«Если б Остап узнал, что он играет такие мудреные партии и сталкивается с такой испытанной защитой, он крайне бы удивился.» (с) 12 стульев ;)
akastargazer
13.05.2015 11:24Тут утверждается, что 1) Вирт не понял ООП и 2) В смолтоке всего три необходимых конструкции. Оба этих тезиса, скажем так, ни к селу ни к городу.
chaetal
13.05.2015 11:33Троллинг становится уже не толстым, а откровенно жирным :)
Вирт:ООП <…> просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое — это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов «объект» и «метод». Средством для такой привязки является процедурная переменная (или поле записи — record field), доступная в языках программирования с середины 70-х гг. Второе понятие — это конструирование нового типа данных (названного «подкласс») путем расширения заданного типа («суперкласс»).
После этого читаем «History of Smalltalk», гуглим цитаты Алана Кэя про его(!) объектный подход, и, наконец, думаем!akastargazer
13.05.2015 13:28Алан Кей в своей «Ранней истории Smalltalk» выдвигает интересный концепт вычислительной системы, построенной из элементов, похожих на биологические клетки или монады Лейбница. Эти элементы коммуницируют между собой, формируя какое угодно поведение, и позволяют строить легко расширяемые системы.
Алан Кей вводит понятие класса, который заключает в себе поведение всех его экземпляров. Вот здесь понятие класса немного уточняется — естественно, не меняя сути.
Вирт говорит именно про это. Привязываем методы к структуре, позволяем наследоваться и получаем классы Алана Кея.
Довольно очевидные вещи.
chaetal
13.05.2015 10:59Так, вам же и объясняют, что в Smalltalk-е все не так! :)
Там всего несколько действительно необходимых синтаксических конструкций, навскидку: посылка сообщения, присваивание (его тоже можно сделать сообщением, но это будет не совсем Smalltalk) и возврат (тоже можно сделать сообщением, кстати)… Может что-то забыл, но, по сути, все! Остальное — «сахар».
Любые конструкции и операторы типа ветвления, циклов, а также структуры навроде замыканий, континуаций, сопрограмм и т.д. — все добавляется не в язык, и никаких изменений/дополнений языка не требуется!
А тенденция — она есть, да. Может быть, Oberon, как и Smalltalk, ее преодолевает. Но только по первым страницам описания я этого не увидел — в отличие от Smalltalk-а, где идея вылезает сразу и уже больше не дает спокойно жить. Если это есть в Oberon-е, если это не еще один банальный наследник Algol-а — пишите статью, будет очень интересно об этом узнатьoberon87
13.05.2015 11:02Ну вот сказали, для чего годится эта идея.
chaetal
13.05.2015 12:01Ну, раз вы так настаиваете. Скажите пожалуйста, где и когда Вирт это сказал?
akastargazer
13.05.2015 12:11В 2005 году, на лекции в Москве.
chaetal
13.05.2015 12:17Свидетельские показания будут? :) (Не обязательно, шучу)
Вообще, от Вирта можно было бы ожидать более широкого кругозора :) Если вы тоже реально не в курсе, посмотрите хотя бы раздел Influences в википедийной статье про Smalltalk и/или это почитайте.akastargazer
13.05.2015 12:21Вирт — практик. Его разработки использовались и используются в авиации, управлении дорожным движением, электростанциях и пр.
Теоретические изыски «всё есть объект» так и остались теоретическими, не так ли?chaetal
13.05.2015 13:51Я иногда не понимаю, вы шутите так?
Про «технологический» след 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»akastargazer
13.05.2015 14:20Да, хорошая подборка, нечего сказать. Единственно, что можно добавить — очень много ссылок 15-летней давности, видимо, как-то связано с интенсивным развитием инструментария типа Visual Smalltalk в те годы. Ну а с унаследованной системы довольно трудно спрыгнуть, вот и держатся.
В любом случае, приятно видеть, что концепция Алана Кея живёт и не погибает.
akastargazer
13.05.2015 11:22Вы знаете, РБНФ смолтока ясно показывает устройство синтаксиса. Поэтому ваше высказывание про «всего несколько необходимых конструкций» остаётся слишком легковесным.
chaetal
13.05.2015 11:38Вы посмотрите внимательнее на указанные формулы, а не только на количество строк в них.
В любом случае, РБНФ показывает, как один искуственный язык переводится на другой искуственный язык. Да, машине может быть тяжелее. Но меня это мало трогает — не знаю, как вы, а я не состою в лиге защиты прав трансляторов и лексических анализаторов. Меня больше волнует сложность использования языка человеком.
Впрочем, тему сравнения Smalltalk-а и Oberon-а я продолжать (по крайней мере, здесь) не намерен. Если этот вопрос интересует — излагайте внятно где-нибудь свои мысли на этот счет — там и обсудим.
chaetal
13.05.2015 08:57+1Вызов — это вызов конкретного метода, известного на этапе компиляции.
Сообщение — переданная просьба объекту что-то сделать. Что именно сделает объект — мы не знаем до момента получения и обработки объектом этой просьбы (связывания сообщения с конкретным методом в случае Smalltalk-а). Более того, мы не знаем, как объект среагирует уже потому, что мы даже в общем случае не знаем какой именно объект получит это самое сообщение.
Следствий из такой концепции — масса, они и составляют ту самую «парадигму объектного программирования». Но вы упорно не хотите понять, что это не «дополнителная сущность» к «уже имеющимся инвариантам». Это самая что ни на есть базовая концепция. Все остальное через нее «выводится» (по-моему, я повторяюсь?). В этом та самая «фишка» и состоит: на базовом уровне не надо вводить массу понятий навроде «тип», «запись», «абстрактный тип», «процедура», «оператор ветвления»… Подобные вещи становятся лишь следующим шагом, деталями, которые можно убрать из языка и реализовать как «библиотеку». Smalltalk эту идею до конца не довел, но она, пусть и не в полной мере, была осуществлена, и на практике показана не только ее жизне-способность, но и, как минимум, конкурентно-способность (а некоторые считают, что и превосходство) относительно других подходов. Нигде больше (из известных мне языков, за исключением Self) в такой степени идея реализована не была. Наверное поэтому Smalltalk на самом деле сильно/принципиально отличается по множеству параметров от почти всех своих собратьев по «объектности».oberon87
13.05.2015 10:21Вы куда-то залезли в дебри, компиляция будет потом, не надо о ней думать, а то абстракции потекут.
Напомню, что речь изначально шла о том, как навыдумывали лишних сущностей, чтобы новыми понятиями выбить себе место на рынке, а потомки уже кроме объектов и сообщений и слов других не знают, самоуверенно вменяя тем, кто знает, некое недопонимание Очень Особенных Понятий.
Это как бины в джаве. Большинство уже даже не понимает, что такое эти бины на самом деле. Просто бины, существуют и все. Ну ок, люди сами решают, на каком уровне детализации мыслить. Может, им по работе больше не надо. Только при этом не стоит рассуждать с умным видом, что кто-то (в данном случае Н. Вирт) не шарит ничего в бинах и ООПе.
К самому ООП претензий нет, ну разве что концептуально, замыливание сознания. Представьте, что для победы в важной межгалактической войне важно знать и понимать обыкновенные дроби. Тогда хитрым пришельцы для победы нужно очень мало, всего лишь натянув костюм из человеческой кожи со школы учить Вас исключительно десятичным дробям.chaetal
13.05.2015 11:21Я вам в очередной (и последний раз) поясняю :) Kay/Smalltalk-овский подход тем и прекрасен, что там близкий к минимум набор «лишних» сущностей и концепций. Эти самые лишние концепции к сути ООП относят те, кто эту самую суть не уловил: абстракция, инкапсуляция, наследование, полиморфизм… — «этого ничего не надо!»(с) Все это спокойно выводится из тех самых сообщений. Ну, а про сущности я где-то тоже уже писал — «чистый» объектный язык весьма минималистичен. Даже в случае Smalltalk-а, который не совсем чист и не совсем минималистичен, разница с другими языками впечатляющая.
akastargazer
13.05.2015 11:26Вы смешиваете техническое устройство с концепцией. Что такое метод, мы знаем. Что такое вызов метода, мы знаем. Это всё технический уровень.
А вот что такое «переданная просьба», мы не знаем — потому что это выход на концептуальный уровень. Как «передача просьбы» реализуется технически?chaetal
13.05.2015 11:40-1Что такое инструкция процессора мы знаем. Что такое регистр мы знаем. А что такое вызов процедуры — мы не знаем. Отсюда вывод — процедурное программирование ничего не добавило к программированию в кодах.
akastargazer
13.05.2015 12:05Так как же всё-таки «передача просьбы» реализуется технически?
chaetal
13.05.2015 12:10Pharo — открытая реализация Smalltalk. Можно посмотреть как Smalltalk-овские исходники системы (чтобы увидеть «внешнюю» часть механизма, включая класс Message), так и виртуалки (чтобы увидеть всю начинку).
akastargazer
13.05.2015 12:22Умеете же вы посылать далеко и надолго. А попроще нельзя объяснить?
chaetal
13.05.2015 14:14Вопрос из разряда «что происходит, когда вы набрали адрес и нажали „ввод“ в адресной строке браузера?» Можно очень долго описывать этот процесс и где-нибудь все равно будет ошибка.
Но если вас это действительно интересует, то вкратце на «самом техническом» из доступных моему пониманию в данный момент уровне «по классике» все будет происходить примерно так:
В виртуальной машине есть байткод «Send». Когда интерпретатор встречает этот байт-код, он снимает со стека значения аргументов, получателя и имя сообщения, у получателя в словаре методов ищет откомпилированный метод, соответствующий сообщению с этим именем, сохраняет текущий контекст выполнения и создает новый, передавая управление в байт-код найденного метода. Когда он отработает, на стеке будет возвращенный результат.akastargazer
13.05.2015 16:23Значит, посылка сообщения технически реализована через вызов метода. Ничего нового. О чём и говорил Вирт.
Зато снаружи много магии и загадочных пассов руками — «сообщения», «вы ничего не понимаете в ООП».
nsinreal
12.05.2015 22:43+2Позвольте встряну в разговор. Когда вы вызываете метод задайте себе такие вопросы:
1) когда он отработает
2) в каком потоке он отработает
3) на каком сервере из ваших двух он отработает
4) что произойдет с необработанным исключением, которое упало внутри метода
5) может ли объект внезапно поменять свое поведение и перестать реагировать на некоторые вызовы методов?
И вот ответы: отработает он сейчас, в текущем потоке, на текущем сервере, исключение пробросится наружу где вы его сможете словить, нет, объект не может резко поменять поведение и игнорировать не может. Это традиционное процедурное программирование.
ООП в современных языках — это блин просто virtual table и проверка на уровне компилятора модификаторов доступа. И между ним и процедурным программированием нету особой разницы. Вот именно поэтому вы эту разницу и не видите. Вам просто добавили чуточку возможностей и улучшили разделение кода.
Теперь, что такое ООП в настоящем виде: все есть объект и единственный способ общения с объектом — послать сообщение. Нам не важно, как, где и когда обработается сообщение.
Например, есть модель акторов. Это по сути урезанная версия ООП, в которой объект не делает работу сразу и не может отвечать на сообщения (т.е. RPC нужно делать вручную). У каждого актора есть threadsafe mail box, он поочередно обрабатывает сообщения и в зависимости от них что-то делает или меняет себе атомарно свое состояние.
Такие ограничения сразу приводят к коду, которому нету разницы (ну я тут приврал, идеале не бывает, но все же), где исполняться: на локальной машине или Северном Полюсе.
И заметьте, мы остались в терминах everything is object & общения через посылку сообщений. Это настоящее бескомпромисное ООП.
Btw, многие интересные вещи в нынешнем «ООП»-мире решаются через «АОП».akastargazer
13.05.2015 16:24Вы тоже смешиваете техническую реализацию с концепцией.
eugenius_nsk
15.05.2015 14:39Попробуйте в рамках концепции методов реализовать что-нибудь подобное методу 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, но для работающего с этим объектом это неважно — он работает с объектом так, как будто такой метод есть.
И, заметьте, я говорю не о реализации (ваша любимая отмазка), а именно о концепции. Как именно будет реализована обработка сообщения — для концепции неважно, главное, что отправка сообщения не обязательно вызывает метод, а может быть обработана и по другому.akastargazer
15.05.2015 14:47«Programming in Oberon», раздел 23.4, широковещательная рассылка сообщений. Объект-получатель интерпретирует сообщение (у Алана Кея точно такая же концепция), и если не понимает его, просто не реагирует. Такой подход позволяет работать с гетерогенными структурами, не имея представления об их внутреннем устройстве.
eugenius_nsk
15.05.2015 14:50При этом, разумеется, у объекта xml нет метода branch, но для работающего с этим объектом это неважно — он работает с объектом так, как будто такой метод есть.
eugenius_nsk
15.05.2015 14:51Постарайтесь понять, что в Обероне есть две разные концепции — вызов методов И отправка сообщений. В то время как в Smalltalk есть только отправка сообщений.
akastargazer
15.05.2015 15:12В Обероне НЕТ концепции сообщений. И нет концепции МЕТОДОВ. Есть структуры и процедуры.
nsinreal
15.05.2015 16:14Нет, не смешиваю. Когда техническая реализация кастрирует концепцию, то нельзя переносить понимание кастрированной концепции на изначальную.
Когда техническая реализация сама становится концепией, то понимание её нельзя применять к оригинальной реализации.
Если вы добьетесь, что вы будете решать похожие задачи похожим образом, но при этом концепции, лежащие в основе разные — то вы не можете переносить свое понимание реализации на понимание концепции. Ибо в конечном счете, то как вы мыслите определяет направление разработки и возможные преграды.
Т.е. нужно рассматривать концепцию в виде «возможности + способ мышления».akastargazer
15.05.2015 17:06Вызов метода — это техническая реализация.
Посылка сообщения, это концепция, реализуемая вызовом метода.
Я предпочитаю видеть явную реализацию, чем туманную концепцию.nsinreal
15.05.2015 17:45Вызов метода это не посылка сообщения.
Во-первых, вызов метода — позволяет делать всего-лишь подмножество из тех вещей, которые возможны при посылке сообщения. Посылка сообщения включает в себя как минимум отложенный вызов, удаленный вызов метода, любую вариацию декораторов и прокси без введения новых классов, вызов несуществующих методов, возможность в рантайме заменить набор методов на другой (с удалением предыдущих).
Во-вторых, вы видите сокрытие реализации, а я вижу сокрытие концепции. Концепция это тоже важно, именно поэтому сейчас все основные языки вместо ООП имеют структуры + virtual table и никто не понимает, чем это лучше структур.akastargazer
15.05.2015 17:57Я ничего не имею против концепции сообщения. Сообщения прекрасны.
Правда, когда мы делали асинхронную обработку сообщений, то натолкнулись на нехорошие вещи, связанные с невозможностью контролировать поток управления. Вот сообщение, вот мы его получили — а кто послал и в каком контексте — неизвестно. Синхронное процедурное программирование более детерминировано в этом смысле.
Но в общем, мне сообщения нравятся. Не нравится только высказывание, что «настоящее ООП» только сообщениями и ограничивается. Фактически, это не так, ведь для обработки сообщений нужны методы. Концептуальный сахар получается, короче :)nsinreal
15.05.2015 18:28Правда, когда мы делали асинхронную обработку сообщений, то натолкнулись на нехорошие вещи, связанные с невозможностью контролировать поток управления.
Верно, эту фичу в обычных языках надо допиливать отдельно. Сейчас за вас это делает ваш язык программирования для синхронного кода — вызова методов. В том же C# есть отдельная поддержка асинхронного кода и во многих случаях стектрейсы получается адекватными (что не решает проблему отложенной обработки сообщений на другом приложении). Кроме того, не всегда нужно знать полный контекст.
Фактически, это не так, ведь для обработки сообщений нужны методы
Если вы понимаете под методами подпрограммы, то да, для того, чтобы что-то обработать нужны программы/подпрограммы/код. Но метод — это нечто большее, чем подпрограмма.
totuin Автор
12.05.2015 18:49С моей точки зрения — ООП — это просто другой образ мысли. Отношение к программе — не как к набору (тексту) кода, а как к живому миру. Может быть к дому — большому и наполненным жильцами. Давайте попробую объяснить как я это вижу.
Запуская программы ту заходишь в этот дом. Перед тобой холст — MainUI вокруг которого кнопочки звонков в квартиры -ToolBar. Например открытие файла -> звонок в квартиру -> вызов жильца. Прибегает жилец -> Project (вместе со всей семьёй: жена Scehma, дети Network-и, внуки Block -и). Project просит Schem-у нарисовать себя на холсте и отдает его ей. Она делит его между детьми и отдаёт каждому из них свой кусочек и просит теперь их нарисовать себя каждого на своём месте. Каждый Network пишет сверху свое имя, а остаток отдает на растерзание внукам. Каждый Block (а они все разные) знает своё место относительно имени родителя, рисует себя так как он себя видит. И вот войдя в дом и вызвав конкретный проект я вижу на холсте семейный портрет. Моя задача как программиста научить всю эту толпу рисовать себя. Рядышком на соседнем холсте портрет семьи библиотеки (Block Library). Когда мне надо добавить в семью Project-а новый блок, я сообщаю об этом Block Library (startDrag -> endDrag). Она же является моделью для второго холста. Создатели (разработчики языка) уже научили её кому об этом надо сказать — Controller-у. А ему уже я подсказал кому передать это сообщение — Scheme. Она выбирает кому из детей отдать новый Block (зависит от места endDrag), и отдает его.
Всё это звучит наверное достаточно глупо, но таким образом легче понимать взаимодействие объектов в большой системе. В этом отношении ООП дает больше возможности абстрагироваться от кода, а SmallTalk с близостью его синтаксиса к нормальному языку, дает возможность легче объяснить объекту что от него хотят и как это нужно сделать.
akastargazer
12.05.2015 16:56+1Давайте попробуем отыскать фишку?
Для начала, кратенький дайджест по оберону: 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
Я думаю, что если мы не будем поддаваться очарованию магических слов типа «сообщение», то перед нами откроется реальность как она есть.vk2
12.05.2015 17:04«Сообщение» — не совсем магическое слово. Например, я могу задать метод, в который будут попадать неизвестные сообщения (с аргументами и т.д.). Таким образом легко сделать объект-прокси.
akastargazer
12.05.2015 17:12+1В обероне это реализуется с помощью Generic Message Bus. Без введения дополнительных понятий.
chaetal
12.05.2015 17:22+1А Generic Message Bus — это не дополнительное понятие? :)
akastargazer
12.05.2015 17:24+1Это внеязыковый паттерн, построенный, всё же, на некоторых инвариантах языка.
mvaspb
12.05.2015 17:09+2М-м-м, я с вами согласен. Я когда-то пришел к выводу, что ООП это не столько методология программирование, сколько способ организации кодом. Я поясню свою мысль: с увеличением объема программ (в строках, оперируемых сущностях) возникает проблема управления большими объемами кода. И ООП предлагает такой подход: компоновка в одном пространстве данных и процедур, работающих с этими данными. Мы инкапсулируем в отдельном контейнере данные и процедуры.
Словом, как всегда, разделяй и властвуй.
Все остальное — полезные, удобные добавки вокруг.
А так, как ни крути, все равно все сведется к ассемблеруchaetal
12.05.2015 17:15+1Я поясню свою мысль: с увеличением объема программ (в строках, оперируемых сущностях) возникает проблема управления большими объемами кода. И ООП предлагает такой подход: компоновка в одном пространстве данных и процедур, работающих с этими данными. Мы инкапсулируем в отдельном контейнере данные и процедуры.
Ох, тогда Вирт прав и нам прямая дорога в какой-нибудь С++ :)
akastargazer
12.05.2015 17:19+1Да, статическую структуру соединяем с алгоритмами и получаем «объект». Множество объектов приходится обозначать словом «класс». Кроме этого, требуется ещё и взаимодействие объектов между собой, а это возможно только если они способны коммуницировать — вот и появляется «сообщение».
А в основе лежит та же статическая структура с ассоциированными с ней процедурами.mvaspb
12.05.2015 17:22Возможно, вы ожидали увидеть революцию, там где есть эволюция?
akastargazer
12.05.2015 17:26Речь идёт не о революции и не об эволюции, а о некоторых ошибочных представлениях об ошибочных представлениях.
chaetal
12.05.2015 17:31Соединяя статическую структуру с алгоритмами, получаем «абстрактный тип»… или модуль в паскале :) Нет, назвать, конечно, можно и объектом. Но это не будет объектом Алана Кея. У последнего только одно обязательное свойство — отвечать на сообщение. Все остальное — детали реализации. От которых не только в принципе можно, но и на практике хотелось бы отказаться, когда речь заходит об основах и «языке».
akastargazer
12.05.2015 17:45+1Процитирую вам Гради Буча: «Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений».
Не знаю, может у Алана Кея какие-нибудь другие, особенные «объекты». Формальный аппарат Оберона позволяет совершенно спокойно реализовать процитированную концепцию.mvaspb
12.05.2015 17:51+1Видите ли, это у Гради Буча свое какое-то понимание ООП.
А Алан Кей один из первых отцов основателей ООП
userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
Хотя это суть неважно. Мнится мне, что это битва за термины.akastargazer
12.05.2015 19:57Всякий термин что-нибудь обозначает. Вот Вирт говорит, что суть одна, а терминов, её обозначающих, много.
chaetal
13.05.2015 06:05+1Вы сами понимаете, что вы пытаетесь доказать? Если да — раскройте пожалуйста.
Есть термин: объектно(-ориентированное) программирование. Есть автор этого термина — Алан Кей. Есть набор концепций, который автор (со своей командой) вкладывал в этот термин. В History of Smalltalk он подробно объяснил свою концепцию, разделив принципы на две группы: основу и детали реализации. Если продолжать его мысль, окажется, что в основе лежит один принцип — обмен сообщениями. Все остальное по необходимости «выводится» из этого принципа. Smalltalk в этом отношении — не идеальный язык, так как в него введены некоторые необязательные концепции (например, классы… я бы добавил еще, но это надо обсуждать отдельно), Self в этом отношении получше, но все равно не идеален. Идеального языка я не знаю.
А есть еще набор интерпретаций того же термина другими лицами. Интерпретации эти обычно сложнее. Интерпретации приводят к другому пониманию, к другой организации разработки, к более сложным и «раздутым» языкам… В общем, ни к чему хорошему не приводят вплоть до идеи «ООП мертв» без понимания, что же такое ООП на самом деле.
Реализовать ООП — в любой интерпретации — можно очень разными способами наверное в любой из существующих «парадигм»: можно в процедурной, можно в функциональной (надеюсь, они подтянуться сюда и нам не придется вести дискуссуию на два фронта — каждой из трех сторон:). О чем это говорит? Да ни о чем! Объектами тоже можно реализовать и функциональную концепцию и процедурную…
Так что же вы хотите донести до нас?akastargazer
13.05.2015 11:33Если уж на то пошло, то Алан Кей не является автором понятий «класс» и «объект».
Речь идёт о том, что вы ставите тождество ООП = Smalltalk и упрекаете Вирта в том, что он не следовал дао смолтока.
Но если посмотреть на оберон-системы, то там есть сообщения. И даже, вы представляете, есть асинхронность. Есть классы объектов, есть экземпляры. Есть поведение. То есть, ООП реализовано нормально, суть проявлена.
А вот что такого магического ВЫ пытаетесь донести до нас, чего никто не знает и знаете только вы, вопрос.chaetal
13.05.2015 11:44Я, к примеру, среди прочего, пытался донести, что понятие «класс» не является базовым понятием объектного программирования.
Впрочем, я уже больше ничего не пытаюсь донести до вас, извините :) Что мог — сделал.akastargazer
13.05.2015 12:08Да вы что?
Читаем: gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
Четвёртый из шести принципов Smalltalk:
4) Every object is an instance of a class (which must be an object)chaetal
13.05.2015 12:12А теперь еще неутомимо читаем следующий абзац…
akastargazer
13.05.2015 12:23И в следующем абзаце и в дальнейших абзацах плотно используется слово «class». Такое ощущение, что вы плохо ориентируетесь в вопросе. Это пока только ощущение.
akastargazer
13.05.2015 13:30Дочитал Алана Кея. Моё ощущение переросло в уверенность. Теперь понятно, почему вы так безапелляционно обвинили Вирта в непонимании сути ООП.
chaetal
13.05.2015 14:34+1:D Что тут скажешь?
«Имещий глаза да увидит»
Вот вам цитата:
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 уже существовал. Думаю, Кэй был в курсе и неспростра внес эту оговорку.
«Имеющий мозг да поймет»
Если вы зададитесь трудом немного поразмыслить над вашим — безусловно богатейшим — опытом программирования «в объектной парадигме», то, уверен, в какой-то момент вы осознаете, что классы очень полезны при решении «стандартных» задач, но могут «не менее очень» мешать, когда приходится делать что-то на мета-уровне с отдельными объектами (когда нужно отдельному объекту задать специфическое поведение). И если после этого вы сделаете еще небольшое усилие, то прекрасно увидите, что на уровне языка классы совсем и не нужны — достаточно порождать объекты по образу и подобию уже существующих. А классы можно прекрасненько реализовать в библиотеке и пользоваться ими тогда, когда это действительно нужно.akastargazer
13.05.2015 14:38О, пожалуй да, перевод нужен! Я не буду вам накидывать тучу цитат из того же самого текста про классы, давайте сначала разберёмся с вашим переводом.
chaetal
13.05.2015 15:11Хорошо, раз уж сам предложил, потрачу на этот балаган еще немного своего времени :)
Первые три принципа говорят о том, что такое объекты вообще (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.
Переводить и понимать вам придется самостоятелно. Я завязываю с этой бессмысленной тратой моего времени.akastargazer
13.05.2015 16:00Секта свидетелей Алана Кея, что я могу ещё сказать. Вы не видите разницы между экземпляром множества и самим множеством. Тут я бессилен.
Viktor-Flash
11.05.2015 22:59Отличная статья. Спасибо.
Возможно Вы знаете, но все таки расскажу, что Smalltalk изучают в Южном Федеральном Университете. Если интересно найти «единомышленников», то нужно поискать доцента кафедры математического анализа мехмата ЮФУ Кирютенко Юрия Александровича. Он автор нескольких работ по Smalltalk, и значительная часть студентов у него пишут проект на Smalltalk. Я, будучи «его студентом», писал несколько классов в один проект, связанный с государствеными образовательными стандартами (ГОС ВПО).totuin Автор
11.05.2015 23:03Спасибо за информацию. Не знал. Знал только что одно время SmallTalk преподавали в Таганрогском радиотехническом институте, и еще в каком то институте под Москвой. Но в Таганроге была своя — особенная версия языка полностью переведённая на русский язык. В принципе язык это позволяет, но смотреть на него было непривычно))))
Divers
IDE выглядит как привет из 90ых. А так это интересно, что язык все еще жив — для меня это откровение.
NeoCode
А что в этом плохого?
Divers
Да просто все это выглядит как поделка десятиклассника в делфи. Может ничего плохого и нет, но работать с красивыми вещами всегда приятнее.
eugenius_nsk
totuin Автор
Такая долгая история заслуживает уважения. При том-что язык остается живым. Пускай не в России, но за рубежом, насколько я слышал он достаточно популярен.