10 мая 2015 в 21:58

Неизвестный Smalltalk tutorial



Уважаемые читатели хабра. Прежде всего я хочу объяснить, что обзор языка 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

Постараюсь ответить на все ваши вопросы к комментариях
Автор: @totuin
FLProg
рейтинг 33,46
Графическая среда программирования Arduino

Комментарии (190)

  • +9
    IDE выглядит как привет из 90ых. А так это интересно, что язык все еще жив — для меня это откровение.
    • +2
      IDE выглядит как привет из 90ых

      А что в этом плохого?
      • +1
        Да просто все это выглядит как поделка десятиклассника в делфи. Может ничего плохого и нет, но работать с красивыми вещами всегда приятнее.
    • +5
      IDE выглядит как привет из 90ых.
      … но на самом деле это привет из 80-х
      • 0
        Такая долгая история заслуживает уважения. При том-что язык остается живым. Пускай не в России, но за рубежом, насколько я слышал он достаточно популярен.
  • +5
    Язык жив и очень даже развивается. В последней версии 8.0 они изменили дизайн IDE. Я просто пока на неё не перешол. Да и вообще интерфейс меняется одним параметром в настройках. Вот например интерфейс в стиле Мас ОС



    Можно полностью настроить как нравится. Но я и сам из 90-х, так что меня устраивает дефолтный
    • +2
      Кстати стиль окна (заголовок и форма) берётся из ОС. И у меня Win10. У неё все окна квадратные
    • +10
      Очень непривычно видеть код набранный не моноширинным шрифтом.
      • +1
        Среда настраиваема, выставьте любой шрифт.
        Посмотрите pharo.org, там среда более sexy look
    • +6
      > стиле Мас ОС 10-ти летней давности

      Лично мне было бы неприятно на такое смотреть каждый день.
  • 0
    Как насчётт библиотек, так нужных в бизнес приложениях: парсинг и генерация Excel (2003/2007+), генерация PDF?
    • 0
      Насчет Exel сейчас в сообществе смолторкеров как разрабатывается парсер. Файлы десятого офиса разбираются на счет раз (это просто зип архивы). Мы их сами разбирали и собирали. К автокаду цеплялись по COM. Есть встроенная поддержка СОМ интерфейса (пакет ComAll).Так же сами писали пакеты для чтения dxf в объектную структуру, и выгрузку обратно в файл. Насчет PDF не знаю, надо смотреть в Sincom Public Repozinity. За бугром сообщество достаточно мощное, возможно кто то что то и написал.
      А вообще есть поддержка WinApi так что возможно подключение любых библиотек и вызов их функций. Как в в линуксе это реализованно я не знаю, а под виндой не очень сложно. Например я использую для отрисовки библиотеку Cairo и она прекрасно работает.
    • 0
      Генерация PDF есть.
      Есть некоторое количество разных интересных библиотек и инструментов.
      Но надо понимать, что из-за небольшого размера коммьюнити, очень многие инструменты не реализованы или в находятся в зачаточном состоянии.
  • +9
    (Ох накликаю я беду!)
    Автор, Ваше знание русского языка отбило охоту читать Вашу же статью на втором абзаце. А Ваши ответы и комментарии усугубили ситуацию. Ужас!
    • +1
      Комментатор, Вы после «ох» запятую пропустили. И это поборник русского языка. Ужас!
      • 0
        Да ладно, все мы люди, все мы человеки. У меня жена когда читает мои тексты — сначала долго мате...., потом выгоняет из за компьютера, и долго правит. На то что бы научить меня правилам уже махнула рукой, хотя и работала долго репетитором по русскому языку. Но и после этого редакторы (я пишу статьи для журналов и хелпы для проекта), все равно находят ошибки. Так что идеального правописания по моему не существует. Всегда присутствует человеческий фактор, да и идеальной программы проверки текстов пока не придумали.
        • +1
          Автор, это была ирония по отношению к комментатору, который ужасается вашему «знанию русского языка», но и сам после первого же слова допускает ошибку :)

          К вашему правописанию я претензий не имею — видно, что писали вы от души и по делу, читать ваш текст интересно, ошибки чтению не мешают.

          Об ошибках в орфографии и пунктуации принято сообщать в личку, а в комментариях же — писать по делу.
          • 0
            Я понял что это была ирония. Спасибо за Ваш комментарий. Я поскольку действительно сам не отличаюсь грамотностью, очень терпимо отношусь к другим таким — же. Ну и привык уже к тому что меня постоянно ругают за это. Заслужил)))). Кстати многие написали мне в личку подсказки где исправить ошибки. Спасибо им за это. Благодаря им я смог привести пост в более менее удобочитаемый вид.
      • 0
        Да, неувязочка! А ведь должна была быть. Коммментарий писал со смартфона. (Не в качестве оправдания, а так… констатация факта).
  • +6
    Да с чистописанием у меня не все хорошо. Хотя статью вроде проверял Word — ом. Ну что поделать, не все мы филологами родились. Да и на вахте я сейчас, жена далеко. Обычно она меня проверяет. Глубоко извиняюсь если чем то обидел русский язык.
    • +2
      Нажимаем «рун»! :)
      • 0
        Ну да я не писатель. Ну уж какой есть. И образования высшего у меня нет. Извините меня безграмотного.
        • 0
          Я вспомнил откуда это -Run. Первая моя программа связанная с прффесиональной деятельностью написана была на бейсике для компьютера Агат. Как говорится привычки рождаются в молодости и остаются на всю жизнь.
      • +1
        В универе на первом курсе, препод, обучавшая нас вижуалвасику, не знала английского, зато знала немецкий. Рун, зуб, буттон и дебуг.
    • 0
      Наличие внешней проверки не отменяет наличие внутренней. Вы хоть почитайте, что написали (обычно на следующий день после написания большинство косяков видны) — уже просто читая, так и хочется вопросить: «запятые уже отменили?» Это, кстати, касается и цитат из википедии — там тоже тихий ужас. Как я понимаю, вы их даже не читали, понадеевшись на Ctrl+C, Ctrl+V. А ведь можно было сделать доброе дело и поправить. Остальное отправил личным сообщением.

      Ну и опять же, вижу стандартную кашу в голове, когда в одну кучу свалены особенности языка и конкретной IDE, библиотек и всего того, чем автор пользуется, лишь бы набросать побольше плюсов своему любимому языку. Ну какая поддержка дебага и рефакторинга на уровне языка? Это чисто фишки IDE. То, что организация языка — все переменные приватные — упрощает рефакторинг, не означает, что язык его поддерживает. А если вам нужно поменять геттер/сеттер? Туда же работа с БД и GUI, репозиторий кода.

      При любом изменении в объявлении сохраненных объектов (добавление, удалении переменных, изменении имени переменных и т.д) файл обратно не вычитается.

      Это что ж получается — поменял переменную-счетчик цикла (утрированно, знаю, что есть методы обхода элементов) и все, кирдык?
      • +2
        Справедливости ради замечу, что в Smalltalk-е разделить «философию», язык, библиотеки, IDE — довольно сложно. Не видел, где автор написал про «поддержку дебага и рефакторинга на уровне языка», но это, в какой-то степени, ближе к истине, чем фраза «Это чисто фишки IDE».
  • +3
    За исключением около 10% статья как про Common Lisp.

    На самом деле я, познав оба языка, даже пытался сделать Class Browser (это те самые 10%) для CL. Если есть желающие, могу поделиться наработками и списком нерешённых (но не неразрешимых) трудностей.
    • –8
      Нарыл, выложи пожалуйста на гитхаб свои поделки, пацаны просят :)
  • 0
    Расскажите, как обстоят дела с кроссплатформенной разработкой:
    1. Нужно писать отдельный GUI под каждую OS?
    2. В GUI используются нативные контролы?
    3. Нужно устанавливать виртуальную машину отдельно, как для Java, или приложение компилируется в исполняемый бинарник отдельно для каждой ОС?
    • 0
      С GUI все обстоит прекрасно. Практически все отрисовывается средствами SmallTalk. Кроме хедара окна (в каждой ОС он будет родной для неё).
      В остальном отрисовка и работа ГУЯ от ОС не зависит. Так же надо проверить отображение шрифтов. В целевой ОС необходимых может не оказаться, Система подберёт подходящие. Может получиться некрасиво. У меня с переходом на другую ОС были проблемы с запросом домашней папки (Ну не линуксоид я — не знал как называется переменная окружения. Теперь знаю — помогли). Так же была проблема с работой с Com портом. Оказалось даже проще чем в винде. Работаеш как файлом (точнее с потоком — Stream). C маком и компортом пока не разобрался (не заработал пока на мак), поэтому версии под него пока нет.
      Виртуальную машину устанавливать не надо. Надо положить в одну папку необходимую виртуалку и файл образа. Причем он один для всех ОС. Главное что бы имена виртуалки и образа совпадали. В винде просто двойной клик по виртуалке, она ищет у себя под боком одноимённый файл образа и работает с ним. С линуксой посложнее немного. Рядышком надо положить скрипт примерно такого содержания:

      #!/bin/sh
      ./flp flp.im

      и запускать его.
      Как то так
    • +3
      Автор статьи немного лукавит. Система виджетов в смолтоке своя, построена по отличным от принятых принципам (морфик). Поддержка нативных виджетов системы часто условная. Тесная интеграция с системой часто болезненна. Сказалась многолетняя изоляция мира смолтока от остального мира IT.

      Это действительно проблемы которые надо, как мне кажется, решать системно. Сейчас же это больше напоминает попытку нарисовать скин похожий на системный и успокоиться. Джава в свое время тоже придерживалась модели собственных элементов управления, но к счастью от этого отошли.

      Ближе всего к системе находится Dolphin Smalltalk, но он нифига не кроссплатформенный, платный и нифига не развивается.
      • 0
        Ну вообще то я об этом и написал:
        Практически все отрисовывается средствами SmallTalk. Кроме хедара окна (в каждой ОС он будет родной для неё).
        В остальном отрисовка и работа ГУЯ от ОС не зависит.

        Мне пока хватает встроенных виджетов. Если что то надо изменить, можно отнаследоваться от базового, и рисовать виджет как душа пожелает. Не знаю получится ли так с наитивными виджетами. А здесь мне в большинстве случаев достаточно научить объект отрисовыватся на вьюшке так как мне надо.
        И да благодаря этому достигается кроссплатформеность. Dolphin Smalltalk действительно красивый но только под винду
      • +1
        Скажем, система виджетов вообще в каждом смоллтоке своя ) Morphic — это Squeak/Pharo, а автор рассказывает про VisualWorks.

        Чтобы коммент был не совсем пустой, оставлю ссылку на amber-lang.net, выглядит мило.
      • 0
        Морфик это в Squeak/Pharo.
        Про dolphin smalltalk — забудьте, он умер и вряд ли восстанет из пепла.
        • +1
          Вот что меня в них поражает, так это какое-то непонятное жлобство. Ну ладно, поняли, что проект не взлетит. Но зачем все было прятать в сундук? Открыли бы исходники или просто сделали бы свободную community версию — пускай бы развивался сообществом.
          • +1
            Видите ли, эта их культура и их право. Вот так они решили.
    • 0
      Есть два ведущих диалекта:
      • VisualWorks Smalltalk (платный, есть бесплатная версия для себя без ограничения возможностей)
      • Pharo (бесплатная)


      Под каждую платформу есть своя виртуальная машина, здесь как для Java. Есть возможность скомпоновать исполняемую виртуальную машину и образ в единый бинарник. Только смысла в этом не много. Надо понимать, что если вы пишете тиражируемый софт для домохозяек, то Smalltalk не ваш выбор.

      GUI кроссплатформенный и реализован весь на Smalltalk. Отличаются только вызовы к system API для создания окон, но это все инкапсулируется в виртуальной машине. Так что, файл образа абсолютно переносим с платформы на платформу
  • +7
    Приветствую единомышленника!

    Статья неплохая, хоть и сумбурная.

    К сожалению, введение в смолток писали уже все кому не лень (включая меня), но нормальных статей по прежнему нет. Все пишут что язык классный, все здорово, приводят пару стандартных примеров и на этом все заканчивается обычно.

    Нужна нормальная статья с примером практической разработки. Хорошо бы продемонстрировать, что такое Smalltalk way с точки зрения проектирования. Показать, как концепция превращается в реализацию на примере конкретной задачи. Вы упомянули разработку FLProg. Вот и опишите, как происходила разработка и что позволило делать это быстро и эффективно. Это все равно что хаскель объяснять на примере десяти вариантов реализации факториала.

    Во-вторых, говорить только о прекрасных сторонах языка — нечестно. Надо рассказать и об недостатках, включая проблемы с нативными виджетами и отсутствием нормальной свободной реализации (Pharo конечно есть, но это не тот уровень).
    • 0
      P.S.: Прошу прощения, предложение про хаскель семантически относится к прыдыдущему абзацу :)
    • +3
      Это вводная статья, так сказать поверхностный обзор. Мне было интересно посмотреть как сообщество отреагирует на этот язык. Если статья заинтересует читателя, я напишу продолжение. Со стилем у меня не очень, но что рассказать есть. Про ГУЙ — это вообще отдельный вопрос. Непривычно до ужаса, но если понять — то очень мощный платформонезависимый механизм. Для его описания потребуется не один пост. Вы кстати первый кто заинтересовался продолжением. Писать то надо для заинтересованной публики, а если никому неинтересно — то зачем писать? Посмотрим на реакцию.
      • +2
        Я тоже заинтересовался, что там за гуй необычный такой?
      • +1
        Я жду продолжение
      • 0
        Было бы интересно увидеть что-то типа getting started — hello world, GUI, общепринятая структура организации кода программы, деплой готового приложения под разные ОС.
        А то скачал образ, открыл, потыкал в дерево классов, впечатлился и закрыл :)
        • +1
          Я постараюсь в ближайший месяц наваять что ни будь подобное. Как ни смешно, самое сложное придумать сценарий. То есть «а что конкретно собрать такое что бы и осмысленно и недолго». У меня в связи с моим проектом уже набрался достаточно большой опыт в написании видео уроков, но всегда это самая большая проблема. Первый видео урок по проекту получился полтора часа, и из шести с половиной тысяч просмотревших только 5% просмотрели до конца. Очень сложно сделать так что бы это было не громоздко, не долго и более менее законченно.
    • 0
      А каким местом Pharo не на том уровне?
      • +2
        Возможно я не так выразился. Как среда разработки именно под Smalltalk он хорош. Я имел в виду интеграцию с остальным рабочим окружением. Современные интерфейсы это не только и не столько «кнопочки и галочки», сколько сервисы.

        Взять тот же Qt. Помимо собственно графической подсистемы, он предоставляет большие возможности по взаимодействию с окружающим миром. Особенно если это заметно на уровне KDE.
        • 0
          Все равно не понимаю мысль…

          У Smalltalk-а очень долго было и до сих пор остается много «детских» болезней. Pharo как раз — попытка все это решить и сделать, наконец, нормальный рабочий Smalltalk так сказать «на современном уровне». Пока, на мой взгляд, все идет неплохо… Я бы даже сказал, лучше, чем можно было ожидать.
          • 0
            Современный язык должен поддерживать многопоточность. Оставаться только на грин тредах это не дело. Во-вторых, нативные виджеты. В третьих JIT. Можно сколько угодно говорить, что смолток не для этого, но мне кажется это только провоцирует изоляцию.

            Вы случайно не знаете подробностей по поводу поддержки многопоточности и JIT в CogVM? В образе есть нечто под названием AsmJIT, но непонятно, насколько оно функционально.
            • 0
              Современный язык должен поддерживать многопоточность. Оставаться только на грин тредах это не дело.

              Это — да. Точнее, есть нюансы и варианты, но в целом я, скорее, соглашусь. Однако это проблема не Pharо/Squeak, а всех Smalltalk-ов.

              Во-вторых, нативные виджеты. В третьих JIT. Можно сколько угодно говорить, что смолток не для этого, но мне кажется это только провоцирует изоляцию.

              Я думал, мы именно особенности Pharo обсуждаем… А так — да, все это слабые места современного Smalltalk-а. Опять же, есть всякие оговорки и отговорки, но это все пока разговоры в пользу бедных. Многим все это не позволяет серьезно использовать Smalltalk. Но некоторым и не мешает.

              Вы случайно не знаете подробностей по поводу поддержки многопоточности и JIT в CogVM? В образе есть нечто под названием AsmJIT, но непонятно, насколько оно функционально.

              Деталей не знаю, тема для меня слишком сложная :) За все не уследить… А так, вроде, какие-то неплохие подвижки в эту сторону идут, судя по перепискам в Smalltalk-овских листах и докладам на конференциях.
              • 0
                Однако это проблема не Pharо/Squeak, а всех Smalltalk-ов.
                Во-первых, пролетали новости о том что в BeeSmalltalk якобы делали поддержку реальной многопоточности чуть ли не в пару десятков строк.

                Во-вторых, еще лет несколько назад где то видел препринты статьи о том что делали акторную систему на базе многопоточного смолтока и рапортовали об успешной работе в сильно многопроцессорной системе (64 процессора, если не ошибаюсь).

                Наконец мы в llst.org планируем реализовать честную многопоточность, правда пока не ясно какого рода ограничения это наложит. Возможно придется делать отдельные кучи и обмен объектами между потоками будет ограничен.

                Деталей не знаю, тема для меня слишком сложная :) За все не уследить… А так, вроде, какие-то неплохие подвижки в эту сторону идут, судя по перепискам в Smalltalk-овских листах и докладам на конференциях.
                Проблема в том, что судя по тому коду что я видел, это банальный и печальный велосипед — ручное генерирование x86 инструкций. Никакой абстракции над архитектурой нет в принципе, не говоря уже про оптимизации. А делать банальную трансляцию байткодов смолтока в x86 это не самая удачная мысль. Как показали наши тесты, оно будет не быстрее прямой интерпретации.
                • 0
                  Про пчелку в курсе, но там ничего пока не ясно же? Похожих многообещающих в плане решения глобальных проблем проектов было много, но воз и ныне там… Проблема существует, люди над ней работают, но решающего ее полноценного промышленного Smalltalk-а пока никто не видел…

                  Кстати, есть альтернатива. Проблема же на самом деле не в том, чтобы внести в Smalltalk нативную многопоточность как таковую (не такая уж она и хорошая, умные люди говорят), а дать возможность распределять процессорную нагрузки по ядрам, верно ведь? А это можно сделать, запуская несколько образов, если дать им возможность между собой нормально общаться, разумеется. В Cincom-е уже несколько лет такое решение существует. Восторгов правда почему-то не слышно :)

                  По поводу JIT-а, к сожалению, ничего конкретного сказать не могу — не компетентен. Хотелось бы, конечно, «нормальный» Smalltalk — который мог бы менять любую свою часть «на лету», в том числе и этот аспект… Мечты :)
                  • 0
                    Не для каждой задачи подойдет вариант «просто запустить N образов». Тупо разбрасывать пользователькие запросы по инстансам — это да. А вот параллельно пройтись несколькими потоками по общему графу уже не получится.

                    Передача данных между ними будет возможна или посредством сериализации (прощай скорость), или очень ограниченным набором данных (например только замороженные объекты содержащие литеральные константы).

                    Честные потоки хороши тем, что отдельные параллельные треды находятся в общем адресном пространстве и могут разделять объемные данные без накладных расходов (кроме синхронизации).
                    • 0
                      Ясно, что есть разные модели организации параллельных вычислений, многое зависит от задачи, что разделяемая память имеет преимущества и недостатки, и да, потоки тоже бывают полезны, но есть еще и всякие кластеры, распределенные системы и т.д.… И что сейчас многое пересматривается, изменяется и изобретается заново :)

                      Но я не специалист (к моему огромному сожалению) в этой области, тем более в технических деталях — не в состоянии поддержать беседу, и сливаюсь :)

                      Да и мы уклонились от исходной темы, вроде… В общем: в Smalltalk-сообществе признают проблему и что-то делают по поводу ее решения. Сам с удовольствием бы почитал какой-нибудь обзор на эту тему.
            • +1
              A JIT то чего? Вы про just-in-time compilation? Так это есть. Более того, это  многие аспекты JIT пришли в большой мир из Smalltalk
    • +1
      Кстати, ваша статья очень хороша — все аккуратно расставляет по полочкам, побольше бы таких. Всем (ну как всем… тем, кто хочет узнать что-то новое, даже если это его никоим боком сейчас не касается, как Smalltalk меня) рекомендую. Жаль, на момент прочтения срок голосования уже истек.
  • +2
    Спасибо за обзор. Было бы интересно прочитать продолжение про web-приложение на SmallTalk.
    • +2
      www.seaside.st

      В свое время это было дико инновационно и круто. Но, по-моему, там уже ничего не развивается. Компанию автора купил Твиттер.
      • 0
        Сейчас есть надежды по поводу Amber-а, которого ты уже упоминал. Если получится нормально связать с «полноценным» Smalltalk-ом, может получится реально интересная вещь… Только вот не особо пытаются пока :)
  • 0
    Кстати, по поводу «Программирования через дебаг» вспомнил, что делаю так же в Chrome Dev Tools для JS :)
  • +2
    Заранее извиняюсь. После прочтения всего выше сказанного, чем Smalltalk приятнее Python (не говорю лучше)?
    Прошу мнения автора, который хорошо знает Smalltalk ну и глянуть на синтаксис Python дело пары минут. :)
    • 0
      Навскидку и скорую руку:

      Простотой базовых идей: Smalltalk — чистая объектность чусть подпорченная классами. Питон (если не ошибаюсь, ориентируясь на википедию) — еще один «мультипарадигматический» язык.

      Простотой синтаксиса: Smalltalk — (почти) только посылка сообщений + чуть-чуть сахара. Наглядно видно на 'if'-ах, которые в Smalltalk-е — просто методы. Не все так идеально в Smalltalk, но гораздо лучше, чем где бы ты ни было (из известного мне).

      «Образностью» :) Smalltalk-а — в том смысле, что все объекты живут в общей среде; все этом можно в любой момент сохранить, а потом продолжить с той точки, где сохранились. Такой бесплатный базовый персистенс. Жаль только пока (надеюсь) дальше не развивают. Но и сейчас в принципе можно разработать приложение не думая о БД совсем, а потом перенести его в среду с полноценной (лучшей до сих пор?) объектной СУБД (я про GemStone).

      Изначальной ориентированностью Smalltalk на то, чтобы быть средой разработки (а не только компилятором) —> до сих пор непревзойденные возможности разработки. И это несмотря не только на «90-сть GUI», но и на то, что процентов 95% потенциала среды до сих пор не раскрыто.

      Подозреваю, что мета-возможности Smalltalk более естественны и просты. Классический пример — добавление континуаций без каких-либо изменений в языке.

      В целом, отличия Smalltalk-а от Python-а — примерно такие же, как отличия Smalltalk-а от любого современного мейн-стримового языка :) То есть, принципиальные.
  • 0
    Что с графикой и скоростью работы? То есть легко ли подрубить OpenGL или DirectX, и насколько быстро работают приложения?
    (для сравнения Delphi — очень удобен, но игру всё-таки лучше писать на C++)
    • +2
      Кесарю — кесарево, богу — богово.
      Не надо писать игр на smalltalk. Он не для этого.

      Давайте я расставлю точки над i
      Плюсы:
      Основное преимущество St — это офигительное, удобное конструирование. Вам будет легко выделить классы, построить взаимодействие между ними, увидеть как это работает. Представьте себе прозрачный двигатель внутреннего сгорания — вы увидете как взаимодействуют объекты внутри вашей программы. Вы сможете в лобой момент сказать двигателю «замри», подкрутить в нём что-то, изменить поведение объекта, и сказать «отомри» и он пойдет работать с всеми изменениями. Язык предоставляет исключительные возможности по конструированию.
      Это преимущество вытекает из следующих предпосылок:
      1. Синтаксис близкий к английскому языку. Сравните вызов метода в обобщенной сигнатуре для основных ЯП:
      paintItemsInArea(array, canvas, rectangle)
      
      и для St
      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, только что с того? В общем для веба — не он.

      Заключение: превосходен для прототипирования сложных объектных систем энтерпрайз уровня. Вырабатывает отличные скиллы по ООП.
      • +1
        Не надо писать игр на smalltalk. Он не для этого.

        Могу ошибаться, но по слухам в Транзасе довольно долго делали симуляторы и всякую виртуальную реальность на Smalltalk-е, пользуясь тем фактом, что «сверх-скорость» нужна не везде. Да и игры бывают разные… Не все так однозначно.

        Не надо писать сложные веб приложения на нем с rich client-side, поддержка JS бибилотек есть, но работать с ней неудобно. Возможно, это чисто мое имхо. Мне могут возразить, что вот у нас есть знаменитый Seaside web framework, только что с того? В общем для веба — не он.

        Видели Amber?
        • 0
          Могу ошибаться, но по слухам в Транзасе довольно долго делали симуляторы и всякую виртуальную реальность на Smalltalk-е, пользуясь тем фактом, что «сверх-скорость» нужна не везде. Да и игры бывают разные… Не все так однозначно.


          Я работал в Транзасе в той самой виртуальной реальности (Trans-Force). Симулятор, это речь о вертолетном тренажере.
          Работа с этими проектами на Smalltalk и сейчас ведется (два года назад точно велась).

          В обоих проектах Smalltalk используется для написания управляющей программы. За вертолетный тренажер не скажу точно, но, вроде, они все моделирование физики поведения вертолета в Smalltalk перевели. Могу ошибиться. Управление комплексом Trans-Force все написано на St. А теперь жирное НО. Сама визуализация трехмерного пространства (полета) — это другая среда, вроде, называлась «Аврора». На чем написана не знаю, но это не smalltalk.

          Amber видел. Пока как приложить к веб-проектам не знаю. Скажите, вот есть meteorjs, мне он нравится. Как его можно использовать вместе с Amber? Если никак, то пока он неинтересен.
          • 0
            Amber+Meteor? Надо подумать. Но не факт, что это даст упрощение процесса
          • 0
            Я работал в Транзасе в той самой виртуальной реальности (Trans-Force). Симулятор, это речь о вертолетном тренажере.

            Я знал! Я знал! :)

            А теперь жирное НО. Сама визуализация трехмерного пространства (полета) — это другая среда, вроде, называлась «Аврора». На чем написана не знаю, но это не smalltalk.

            Я же об этом и говорю: Smalltalk-у есть место и в играх, не самое маловажное место.
          • 0
            Amber видел. Пока как приложить к веб-проектам не знаю. Скажите, вот есть meteorjs, мне он нравится. Как его можно использовать вместе с Amber? Если никак, то пока он неинтересен.

            Не в курсе, что такое meteorjs. Но, скорее всего, как и с любой другой JS-библиотекой. Вопрос, нужно ли — вполне возможно, amber и meteorjs являются конкурентами? Предлагаю продолжить обсуждение в RSUG-е :)
        • 0
          Amber хоть красив и интересно сделан на современных механизмах, но пока это отдельная вещь в себе.
          • 0
            Поддержка WebSocket и в Amber-е и в Pharo делает это утверждение не совсем верным. Есть и конкретные решения (с JSON-ом, вроде) для организации общения… Но в целом соглашусь — пока это дело не докачано до нужного уровня.
  • +1
    Спасибо за статью.
    Давно присматриваюсь к этому языку, но есть вещи останавливающие меня. Прошу знатоков ответить на эти вопросы (сам я новичок, поэтому вопросы могут посчитаться кем-то глупыми):
    1. Возможно ли на этапе выпуска приложения почистить автоматически образ от всего лишнего, оставив только действительно необходимое для работы программы? Там ведь хранится куча неиспользованного. Образы тяжеловесные. Я видел у того же Pharo минимальный образ в 2-3МБ, но это не совсем то, хотелось бы примерный аналог жёсткой компиляции когда выкидывается всё лишнее.
    2. Возможно ли изменить синтаксис средствами языка? Скажем я хочу переназначить «:=» на другой знак. Если да, то как это сделать? Отталкивает синтаксис smalltalk, но само устройство интересно.
    3. Возможно ли морду привести к системному виду? Чтобы автоматом бралась тема системы, может какие-то наработки уже есть? Биндинги в другие морды? (Tk, Qt и т. п.). Для Qt я нашёл только мёртвые ссылки под GNU Smalltalk.
    4. В тексте упоминалась возможность работать с файлами вместо образа, как это сделать? Нашлась только интеграция с CVS/Git.
    5. Насколько между собой совместимы разные ВМ/платформ? Их существует множество: GNU Smalltalk, Squeak, Pharo, VisualWorks, Dolphin… В чём в основном их различия? Сложно ли переносить код написанный под одной ВМ на другую?
    С чего вообще стоит начать новичку? Где искать чужие наработки? Гугл-то находит далеко не всё.
    • +2
      1. Да возможно очищение. Но жесткое вряд ли. Поскольку язык динамической типизации, то самостоятельно определить, что выкидывать, а что нет он не в состоянии.
      2. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.
      3. Можно. Иногда это не будет 1 в 1, но что-то похожее. Так как GUI все таки не native
      4. Нет, нельзя. То что вы упоминаете, всего лишь возможность выгрузки пакетов в файлы для интеграции с GIT. Собственные репозитарии кода более удобны для просмотра изменений (версионность базируется на методе, не на файле); Плюшек типа pull request нету
      5. Переносить не очень сложно, но различия существуют.

      Начинать лучше с Pharo (pharo.org) — относительно большое и отзывчивое коммьюнити, наиболее прогрессивный диалект
      • 0
        2. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.
        Уточню, что если очень-очень хочется, то можно — для этого придётся изменить компилятор (он написан на самом Smalltalk, живёт в том же самом образе, и вызывается при сохранении метода). Но лучше этого не делать.
        • 0
          Любопытно. А где например его можно посмотреть? Точнее как он конкретно называется? Где-то можно прочитать про низкоуровневую архитектуру Smalltalk? Для меня открытие что там внутри компилятор сидит написанный на самом Smalltalk.
          • 0
            В некоторых случаях даже виртуалка написана на Smalltalk (его подмножестве).
          • 0
            Могу посоветовать мои статьи по архитектуре LittleSmalltalk. Надо только сразу оговориться, что LittleSmalltalk не поддерживает стандарт Smalltalk80, хотя для понимания базовых принципов это не нужно.
      • 0
        1. То что динамический понятно, но есть же профилировщики, как например тут на 5 шаге. Можно было бы использовать подобный подход чтобы определить что и как используется, после чего отбросить всё лишнее, транслировав исходные коды в байткоды для компактности (хотя я не ковырял образ, может там уже полный байткод).
        4. Просто я увидел фразу в статье:
        Образ системы является основным контейнером информации в Smalltalk — т.е. в Smalltalk не приняты текстовые файлы с исходным кодом. В принципе, их можно создавать, но работать с образом системы гораздо удобнее.
        Это ошибка?

        В целом ясно, спасибо за ответ.
        • +1
          1. То что динамический понятно, но есть же профилировщики, как например тут на 5 шаге. Можно было бы использовать подобный подход чтобы определить что и как используется, после чего отбросить всё лишнее, транслировав исходные коды в байткоды для компактности (хотя я не ковырял образ, может там уже полный байткод).

          Анализ в динамических языках тоже, разумеется, возможен. Есть всякие наработки на данную тему. Но именно про такой инструмент я не слышал. В VisualWorks, насколько помню, это делается частично автоматически, но без участия человека может получится не очень хорошо в сложных случаях.
  • +2
    Что Вы на нём пишете?
  • 0
    Ну прежде всего первый мой проект на смолтолке Cadel. Сейчас я уже в нем не участвую, но был одним из «родителей». Мой текущий проект FLProg. И сама программа и сайт написаны на смолтолке. Этот проект я разрабатываю один, и на другом языке боюсь бы у меня это не получилось. Ну еще много различных полезных программок как говорится «для вутреннего потребления» создано за эти годы.
    • 0
      жду, жду, а каммент тут :-)
      Вы просто жмите «ответить» в теле каммента, чтобы получился ответ в нужном месте

      Cadel — скачать можно только после регистрации, а скринов нет

      FLProg, конечно, впечатляет.
      • 0
        Да простят меня мои бывшие работодатели:Cadel
        • 0
          Спасибо, потыкал. Итересно видеть Smalltalk в живых проектах.
        • 0
          Зря.
          И из коробки это не запустится. Мне пришлось вырезать кучу проверок
          • 0
            Это версия с сайта, «заказчика». И они отказались от лицензионного ключа. Так что пускается на ура. Только скачка доступна после регистрации.
            • 0
              Славу богу, не прошло и три года.
              • 0
                Появился мастер проекта (волшебная палочка), ШОТ собрали вместе с НКУ. Семимильные шаги. Сам смотрел и плакал от ностальгии)))
  • +1
    Я тоже в своё время влюбился в этот язык программирования. Удивительно, что с 80-х годов синтаксис и основные принципы работы языка практически не изменились. То есть, изначально Алан Кей достал бритву Окама и сделал простой и одновременно мощный язык, который легко расширять (добавление Try-Catch конструкций можно сделать средствами самого языка, не вводя новых ключевых слов и не меняя виртуальную машину), и который объектно-ориентированный до мозга костей (в отличие от той же Java, где есть int, boolean и float, выпадающие из общей идеи «всё есть объект»). Плюс всё динамическое: можно добавлять/удалять классы и менять методы прямо в процессе работы приложения. Рекомендую пройти какой-нибудь туториал по этому языку. Он заставляет мозг работать немного по другому и прививает «чистый» ООП стиль программирования.
    Конечно у Smalltalk есть недостатки. В частности меня смущает образ системы, внутри которого «живёт» виртуальная машина и управляет объектами.
    totuin, подскажите, как происходит deployment приложения на сервер? Вы закачиваете готовый образ системы и запускаете VM с этим образом? Или рабочий сервер выкачивает исходный код из базы и компилирует его на лету?
    • 0
      У меня на сервере работает открытый образ разработчика (сервер на Win Server 2008 r2, доступ по RDP). Это позволяет на лету дорабатывать сайт без остановки сервера. При создании новых страниц я сначала ссылку на них создаю только для администратора сервера (то есть для меня), а после готовности открываю для всех. А вот бэкапер сайта представляет собой независимое приложение, в виде Run Time образа и своим UI.
  • –6
    Как говорил Н. Вирт:
    Smalltalk годится чтобы учить возить черепашку по экрану. В остальном бесполезен.
    • +3
      Информация из википедии:

      Вирт, Никлаус

      В 1970 году создал язык программирования Паскаль. В 1970-х годах разработал, вместе с Хоаром и Дейкстрой технологию структурного программирования. Вышедшая в 1971 году статья Вирта «Разработка программы методом пошагового уточнения» описала и обосновала ставшую впоследствии классической методологию разработки программного обеспечения «сверху вниз».

      В 1975 году разработал язык Модула, в котором реализовал идеи разработки модульных программ с хорошо определёнными межмодульными интерфейсами и параллельного программирования. Кроме того, в Модуле был изменён синтаксис языка — Вирт избавился от унаследованной ещё от Алгола-60 необходимости применять составные операторы в конструкциях ветвления и циклах.


      Судя по его разработкам для него тяжело было понятие объектно ориентированого программирования основанного на событиях и сообщениях. Наверно этим и вызвано его высказывание. В то время вообще к ООП относились настороженно, но в конце — концов можно сказать что оно победило.
      В том же Паскале (нынче Delphi), ООП до сих пор прикручено где то сбоку.

      • 0
        Цитата 2005-го года, так что у всех было время оценить результаты.
        Хотя, вот цитата из 1998-го:
        Объектно-ориентированное программирование вышло из принципов и понятий традиционного процедурного программирования. Скажу больше: в ООП не добавлено ни одного действительно нового понятия; просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое — это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов «объект» и «метод». Средством для такой привязки является процедурная переменная (или поле записи — record field), доступная в языках программирования с середины 70-х гг. Второе понятие — это конструирование нового типа данных (названного «подкласс») путем расширения заданного типа («суперкласс»).
        Стоит заметить, что вместе с ООП пришла совершенно новая терминология, имевшая целью затемнить происхождение его корней. Таким образом, если раньше вы могли инициировать активность процедуры путем ее вызова, то теперь должны посылать сообщение методу.
        Как мы можем увидеть, все не так грустно, как Вы предположили из статьи Википедии. На этом можно закрыть тему непонимания Н. Виртом ООП.
        • +1
          Скажите, вы, говоря про черепашку на экране, не спутали Smalltalk с Logo? Вроде черепахи это там.
          • +1
            1) Это цитата Н. Вирта
            2) Черепашка это же языконезависимый исполнитель.

            Если хотите моё мнение, то оно такое: любой язык с такими выдающимися качествами как:
            Все переменные в объектах являются указателями.
            Во-вторых Smalltalk – динамически типизированный язык. То есть в любую переменную можно положить ссылку на инстанс объекта любого класса.
            вообще нет смысла рассматривать как нечто стоящее людских усилий. Но если завалить его деньгами, то вполне получится какой-нибудь веселый кадавр, типа javascript.
            • +1
              А, не вопрос. Одному нравится арбуз, другому свиной хрящик. (с) Островский
        • 0
          По-моему, ее действительно можно закрыть этой цитатой, поскольку Вирт явно расписался в своем непонимании объектного подхода.

          Не, я не хочу сказать, что я вот такой умный и понимаю, а Вирт такой тупой и не понимает :) Просто он действительно «не просек фишку» по каким-то причинам.
          • 0
            А в чем фишка?
            • 0
              В сообщениях, если коротко.
              • 0
                Все же стоит разделять термины «передача сообщения объекту», который однозначно трактуется только внутри парадигмы ООП, и понятия процедурного программирования «вызов процедуры/функции каким-то образом привязанной к экземпляру структуры и передача ей набора параметров».
                • 0
                  Поэтому и непонятно, в чем же тут фишка? Просто в новых словах?
                  • 0
                    Вот и Вирту, было не понятно :) А вы хотите, чтобы я здесь в комменте раскрыл вопрос во всех аспектах?

                    Сообщение от вызова отличается тем, что в первом случае мы не знаем, как получатель отреагирует на это сообщение. Звучит странно, но это ставит программирование, как ни удивительно, с головы на ноги. Впрочем, не удивительно — ведь в реальной жизни все примерно так и обстоит, да?

                    Сказывается это и на «философии» программирования, и на языке, и на методах построения дизайна системы (я не про GUI)… это приводит к чему-то вроде TDD… Как побочный эффект — существенные, если не сказать принципиальные, отличия Smalltalk-а от, казалось бы, аналогичных языков… В общем я могу курс лекций по этому поводу прочитать (собственно, и читал до недавнего времени) :)
                    • 0
                      Вы знаете, вот я в Блэкбоксе (BlackBox Component Builder, рантайм-среда для оберона) даже не пытаюсь узнать, как отреагирует на моё сообщение виджет, вставленный в контейнер, обёрнутый несколькими врапперами. Мне и не нужно знать, это же гетерогенная структура, я просто туда посылаю сообщение.
                    • –1
                      Мы и во втором случае не знаем. И догадок не делаем.
                      • +1
                        Ну, я бы сказал, что явное знание о вызываемом методе даёт нам детерминированность поведения. А сообщение можно обработать, а можно и не обработать. Концептуальный смысл «сообщения» вполне очевиден, вопрос в том, надо ли вводить в формальный аппарат дополнительную сущность или можно обойтись уже имеющимися инвариантами.
                        • 0
                          Все же, и в том и в другом случае мы имеем дело с одним принципом: черный ящик сам решает, какая связанная процедура вызывается в результате нашей попытки ее вызвать. Путь прохождения вызова так же нам безразличен. Но как видно из обсуждения, это в языке Smalltalk выведено из набора внеязыковых приемов и введено в язык.
                          Ну а привычка все тащить в язык давно известна. Чего стоит хотя бы эта картинка image
                          • +3
                            «Syntax volume (N of lexems)» — это количество предопределенных синтаксических конструкций в языке?
                            Если так, то, видимо, постеснялись туда St поставить.
                            Там их гораздо меньше — три конструкции и 6 зарезервированных слов.
                            Перечислю конструкции (остальное по ссылке):
                            1. := (присваивание)
                            2. ^ (возврат результата из метода)
                            3. собственно отправка сообщения объекту

                            Все остальное, вся стандартная библиотека (все это if then else, loop operators/iterators, collections and so on) реализовано на самом St и доступно для изменения, если такое взбредет в голову.

                            • 0
                              И это не говоря про эзотерику всякую. И что?
                              • +1
                                Вы что имеете в виду про эзотерику?

                                >И что?

                                Гм, да, в общем-то, ничего. А вы картинку-то к чему тогда привели? Вы хотели показать «как мало предопределенных конструкций в Обероне»?

                                Дискуссия явно начала вырождаться.
                            • 0
                              Наверное, не постеснялись. Потому что синтаксис оценивался по РБНФ, а есть ли таковая для Smaltalk?
                              • 0
                                Пожалуйста, гугл в помощь

                                chronos-st.blogspot.de/2007/12/smalltalk-in-one-page.html

                                Возможно, вам будет интересно вот это
                                • 0
                                  Вы будете смеяться, но РБНФ синтаксиса Оберона меньше, чем Smalltalk :)
                                  • 0
                                    И о чем это говорит?
                                    • 0
                                      Это говорит о том, что ваши слова «Там их гораздо меньше — три конструкции и 6 зарезервированных слов.» сделаны несколько сгоряча.
                                      • 0
                                        Попробуйте разобраться и понять, а не просто спорить.

                                        Вот интересная ссылочка: code.uko.tymchuk.me/2013/02/grammars-complexity-comparison.html. Покажите такую диаграмму для Oberon-а и все увидят, насколько прост этот язык.
                                        • 0
                                          Интересные рисунки. Два вопроса:

                                          1) Как туда загрузить синтаксис Оберона? (не вручную же рисовать)
                                          2) Как сравнивать результаты — по высоте, по ширине или по глубине?
                            • 0
                              И, самое интересное, со временем их не становится больше. Вот чудеса! :)
                              • 0
                                Когда есть некая тенденция, то наличие исключений, не попадающих под тенденцию, не отрицает тенденцию.
                                Вас задело, что куча языков на одном графике? Типа, «нашли что сравнивать, вот в языке Му всего одно ключевое слово Му». Ну нарисуйте каждому языку по своему графику, и все равно там будет разрастание рбнф-описания.
                                • 0
                                  Простите, а вы что доказать-то хотите?
                                  Что ООП фигня? Что Оберон круче всех? Что именно?
                                  • 0
                                    Не ставил себе такой цели. Мы тут рассуждаем про соотношение терминологий внутри всевозможных методик и про отношение этих терминологий к базовым понятиям сферы нашей общей деятельности. Если вас это утомляет и вы хотите перейти к конфликту религиозного свойства, то пожалуйста. В отдельной ветке.
                                    • 0
                                      «Если б Остап узнал, что он играет такие мудреные партии и сталкивается с такой испытанной защитой, он крайне бы удивился.» (с) 12 стульев ;)
                                  • 0
                                    Тут утверждается, что 1) Вирт не понял ООП и 2) В смолтоке всего три необходимых конструкции. Оба этих тезиса, скажем так, ни к селу ни к городу.
                                    • 0
                                      Троллинг становится уже не толстым, а откровенно жирным :)

                                      Вирт:
                                      ООП <…> просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое — это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов «объект» и «метод». Средством для такой привязки является процедурная переменная (или поле записи — record field), доступная в языках программирования с середины 70-х гг. Второе понятие — это конструирование нового типа данных (названного «подкласс») путем расширения заданного типа («суперкласс»).


                                      После этого читаем «History of Smalltalk», гуглим цитаты Алана Кэя про его(!) объектный подход, и, наконец, думаем!
                                      • 0
                                        Алан Кей в своей «Ранней истории Smalltalk» выдвигает интересный концепт вычислительной системы, построенной из элементов, похожих на биологические клетки или монады Лейбница. Эти элементы коммуницируют между собой, формируя какое угодно поведение, и позволяют строить легко расширяемые системы.

                                        Алан Кей вводит понятие класса, который заключает в себе поведение всех его экземпляров. Вот здесь понятие класса немного уточняется — естественно, не меняя сути.

                                        Вирт говорит именно про это. Привязываем методы к структуре, позволяем наследоваться и получаем классы Алана Кея.

                                        Довольно очевидные вещи.
                                • 0
                                  Так, вам же и объясняют, что в Smalltalk-е все не так! :)

                                  Там всего несколько действительно необходимых синтаксических конструкций, навскидку: посылка сообщения, присваивание (его тоже можно сделать сообщением, но это будет не совсем Smalltalk) и возврат (тоже можно сделать сообщением, кстати)… Может что-то забыл, но, по сути, все! Остальное — «сахар».
                                  Любые конструкции и операторы типа ветвления, циклов, а также структуры навроде замыканий, континуаций, сопрограмм и т.д. — все добавляется не в язык, и никаких изменений/дополнений языка не требуется!

                                  А тенденция — она есть, да. Может быть, Oberon, как и Smalltalk, ее преодолевает. Но только по первым страницам описания я этого не увидел — в отличие от Smalltalk-а, где идея вылезает сразу и уже больше не дает спокойно жить. Если это есть в Oberon-е, если это не еще один банальный наследник Algol-а — пишите статью, будет очень интересно об этом узнать
                                  • 0
                                    Ну вот сказали, для чего годится эта идея.
                                    • 0
                                      Ну, раз вы так настаиваете. Скажите пожалуйста, где и когда Вирт это сказал?
                                      • 0
                                        В 2005 году, на лекции в Москве.
                                        • 0
                                          Свидетельские показания будут? :) (Не обязательно, шучу)

                                          Вообще, от Вирта можно было бы ожидать более широкого кругозора :) Если вы тоже реально не в курсе, посмотрите хотя бы раздел Influences в википедийной статье про Smalltalk и/или это почитайте.
                                          • 0
                                            Вирт — практик. Его разработки использовались и используются в авиации, управлении дорожным движением, электростанциях и пр.

                                            Теоретические изыски «всё есть объект» так и остались теоретическими, не так ли?
                                            • 0
                                              Я иногда не понимаю, вы шутите так?

                                              Про «технологический» след 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»
                                              • 0
                                                Да, хорошая подборка, нечего сказать. Единственно, что можно добавить — очень много ссылок 15-летней давности, видимо, как-то связано с интенсивным развитием инструментария типа Visual Smalltalk в те годы. Ну а с унаследованной системы довольно трудно спрыгнуть, вот и держатся.

                                                В любом случае, приятно видеть, что концепция Алана Кея живёт и не погибает.
                                  • 0
                                    Вы знаете, РБНФ смолтока ясно показывает устройство синтаксиса. Поэтому ваше высказывание про «всего несколько необходимых конструкций» остаётся слишком легковесным.
                                    • 0
                                      Вы посмотрите внимательнее на указанные формулы, а не только на количество строк в них.

                                      В любом случае, РБНФ показывает, как один искуственный язык переводится на другой искуственный язык. Да, машине может быть тяжелее. Но меня это мало трогает — не знаю, как вы, а я не состою в лиге защиты прав трансляторов и лексических анализаторов. Меня больше волнует сложность использования языка человеком.

                                      Впрочем, тему сравнения Smalltalk-а и Oberon-а я продолжать (по крайней мере, здесь) не намерен. Если этот вопрос интересует — излагайте внятно где-нибудь свои мысли на этот счет — там и обсудим.
                        • +1
                          Вызов — это вызов конкретного метода, известного на этапе компиляции.
                          Сообщение — переданная просьба объекту что-то сделать. Что именно сделает объект — мы не знаем до момента получения и обработки объектом этой просьбы (связывания сообщения с конкретным методом в случае Smalltalk-а). Более того, мы не знаем, как объект среагирует уже потому, что мы даже в общем случае не знаем какой именно объект получит это самое сообщение.

                          Следствий из такой концепции — масса, они и составляют ту самую «парадигму объектного программирования». Но вы упорно не хотите понять, что это не «дополнителная сущность» к «уже имеющимся инвариантам». Это самая что ни на есть базовая концепция. Все остальное через нее «выводится» (по-моему, я повторяюсь?). В этом та самая «фишка» и состоит: на базовом уровне не надо вводить массу понятий навроде «тип», «запись», «абстрактный тип», «процедура», «оператор ветвления»… Подобные вещи становятся лишь следующим шагом, деталями, которые можно убрать из языка и реализовать как «библиотеку». Smalltalk эту идею до конца не довел, но она, пусть и не в полной мере, была осуществлена, и на практике показана не только ее жизне-способность, но и, как минимум, конкурентно-способность (а некоторые считают, что и превосходство) относительно других подходов. Нигде больше (из известных мне языков, за исключением Self) в такой степени идея реализована не была. Наверное поэтому Smalltalk на самом деле сильно/принципиально отличается по множеству параметров от почти всех своих собратьев по «объектности».
                          • 0
                            Вы куда-то залезли в дебри, компиляция будет потом, не надо о ней думать, а то абстракции потекут.
                            Напомню, что речь изначально шла о том, как навыдумывали лишних сущностей, чтобы новыми понятиями выбить себе место на рынке, а потомки уже кроме объектов и сообщений и слов других не знают, самоуверенно вменяя тем, кто знает, некое недопонимание Очень Особенных Понятий.

                            Это как бины в джаве. Большинство уже даже не понимает, что такое эти бины на самом деле. Просто бины, существуют и все. Ну ок, люди сами решают, на каком уровне детализации мыслить. Может, им по работе больше не надо. Только при этом не стоит рассуждать с умным видом, что кто-то (в данном случае Н. Вирт) не шарит ничего в бинах и ООПе.

                            К самому ООП претензий нет, ну разве что концептуально, замыливание сознания. Представьте, что для победы в важной межгалактической войне важно знать и понимать обыкновенные дроби. Тогда хитрым пришельцы для победы нужно очень мало, всего лишь натянув костюм из человеческой кожи со школы учить Вас исключительно десятичным дробям.
                            • 0
                              «Сила пророков в их моральной уверенности» (С) О. Куваев, «Территория»

                            • 0
                              Я вам в очередной (и последний раз) поясняю :) Kay/Smalltalk-овский подход тем и прекрасен, что там близкий к минимум набор «лишних» сущностей и концепций. Эти самые лишние концепции к сути ООП относят те, кто эту самую суть не уловил: абстракция, инкапсуляция, наследование, полиморфизм… — «этого ничего не надо!»(с) Все это спокойно выводится из тех самых сообщений. Ну, а про сущности я где-то тоже уже писал — «чистый» объектный язык весьма минималистичен. Даже в случае Smalltalk-а, который не совсем чист и не совсем минималистичен, разница с другими языками впечатляющая.

                          • 0
                            Вы смешиваете техническое устройство с концепцией. Что такое метод, мы знаем. Что такое вызов метода, мы знаем. Это всё технический уровень.

                            А вот что такое «переданная просьба», мы не знаем — потому что это выход на концептуальный уровень. Как «передача просьбы» реализуется технически?
                            • –1
                              Что такое инструкция процессора мы знаем. Что такое регистр мы знаем. А что такое вызов процедуры — мы не знаем. Отсюда вывод — процедурное программирование ничего не добавило к программированию в кодах.
                              • 0
                                Так как же всё-таки «передача просьбы» реализуется технически?
                                • 0
                                  Pharo — открытая реализация Smalltalk. Можно посмотреть как Smalltalk-овские исходники системы (чтобы увидеть «внешнюю» часть механизма, включая класс Message), так и виртуалки (чтобы увидеть всю начинку).
                                  • 0
                                    Умеете же вы посылать далеко и надолго. А попроще нельзя объяснить?
                                    • 0
                                      Вопрос из разряда «что происходит, когда вы набрали адрес и нажали „ввод“ в адресной строке браузера?» Можно очень долго описывать этот процесс и где-нибудь все равно будет ошибка.
                                      Но если вас это действительно интересует, то вкратце на «самом техническом» из доступных моему пониманию в данный момент уровне «по классике» все будет происходить примерно так:

                                      В виртуальной машине есть байткод «Send». Когда интерпретатор встречает этот байт-код, он снимает со стека значения аргументов, получателя и имя сообщения, у получателя в словаре методов ищет откомпилированный метод, соответствующий сообщению с этим именем, сохраняет текущий контекст выполнения и создает новый, передавая управление в байт-код найденного метода. Когда он отработает, на стеке будет возвращенный результат.
                                      • 0
                                        Значит, посылка сообщения технически реализована через вызов метода. Ничего нового. О чём и говорил Вирт.

                                        Зато снаружи много магии и загадочных пассов руками — «сообщения», «вы ничего не понимаете в ООП».
                                        • +1
                                          Haskell-исходник можно скомпилировать в бинарный выполняемый файл, напрямую выполняемый на процессоре.

                                          Значит, вся эта функциональщина технически реализована через императивщину. Ничего нового. О чём и говорил Вирт.

                                          Зато снаружи много магии и загадочных пассов руками — «чистота», «ленивость», «монады», «зависимые типы».
                                          • 0
                                            Ну, дык:

                                            Процедурное программирование — ничего нового по сравнению со структурным.
                                            Структурное программирование — ничего нового по сравнению с Алголом.
                                            Алгол — ничего нового по сравнению с ассемблером.
                                            Ассемблер — ничего нового по сравнению с архитектурой фон Неймана.
                                            Архитектура фон Неймана — ничего нового по сравнению с машиной Тьюринга…

                                            … Дальше не рискну, но прикиньте: с 1936-го года сплошная магия и пассы руками!
                  • +2
                    Позвольте встряну в разговор. Когда вы вызываете метод задайте себе такие вопросы:
                    1) когда он отработает
                    2) в каком потоке он отработает
                    3) на каком сервере из ваших двух он отработает
                    4) что произойдет с необработанным исключением, которое упало внутри метода
                    5) может ли объект внезапно поменять свое поведение и перестать реагировать на некоторые вызовы методов?

                    И вот ответы: отработает он сейчас, в текущем потоке, на текущем сервере, исключение пробросится наружу где вы его сможете словить, нет, объект не может резко поменять поведение и игнорировать не может. Это традиционное процедурное программирование.

                    ООП в современных языках — это блин просто virtual table и проверка на уровне компилятора модификаторов доступа. И между ним и процедурным программированием нету особой разницы. Вот именно поэтому вы эту разницу и не видите. Вам просто добавили чуточку возможностей и улучшили разделение кода.

                    Теперь, что такое ООП в настоящем виде: все есть объект и единственный способ общения с объектом — послать сообщение. Нам не важно, как, где и когда обработается сообщение.

                    Например, есть модель акторов. Это по сути урезанная версия ООП, в которой объект не делает работу сразу и не может отвечать на сообщения (т.е. RPC нужно делать вручную). У каждого актора есть threadsafe mail box, он поочередно обрабатывает сообщения и в зависимости от них что-то делает или меняет себе атомарно свое состояние.
                    Такие ограничения сразу приводят к коду, которому нету разницы (ну я тут приврал, идеале не бывает, но все же), где исполняться: на локальной машине или Северном Полюсе.

                    И заметьте, мы остались в терминах everything is object & общения через посылку сообщений. Это настоящее бескомпромисное ООП.

                    Btw, многие интересные вещи в нынешнем «ООП»-мире решаются через «АОП».
                    • 0
                      Вы тоже смешиваете техническую реализацию с концепцией.
                      • 0
                        Попробуйте в рамках концепции методов реализовать что-нибудь подобное методу 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, но для работающего с этим объектом это неважно — он работает с объектом так, как будто такой метод есть.

                        И, заметьте, я говорю не о реализации (ваша любимая отмазка), а именно о концепции. Как именно будет реализована обработка сообщения — для концепции неважно, главное, что отправка сообщения не обязательно вызывает метод, а может быть обработана и по другому.
                        • 0
                          «Programming in Oberon», раздел 23.4, широковещательная рассылка сообщений. Объект-получатель интерпретирует сообщение (у Алана Кея точно такая же концепция), и если не понимает его, просто не реагирует. Такой подход позволяет работать с гетерогенными структурами, не имея представления об их внутреннем устройстве.
                          • 0
                            При этом, разумеется, у объекта xml нет метода branch, но для работающего с этим объектом это неважно — он работает с объектом так, как будто такой метод есть.
                          • 0
                            Постарайтесь понять, что в Обероне есть две разные концепции — вызов методов И отправка сообщений. В то время как в Smalltalk есть только отправка сообщений.
                            • 0
                              В Обероне НЕТ концепции сообщений. И нет концепции МЕТОДОВ. Есть структуры и процедуры.
                      • 0
                        Нет, не смешиваю. Когда техническая реализация кастрирует концепцию, то нельзя переносить понимание кастрированной концепции на изначальную.
                        Когда техническая реализация сама становится концепией, то понимание её нельзя применять к оригинальной реализации.
                        Если вы добьетесь, что вы будете решать похожие задачи похожим образом, но при этом концепции, лежащие в основе разные — то вы не можете переносить свое понимание реализации на понимание концепции. Ибо в конечном счете, то как вы мыслите определяет направление разработки и возможные преграды.
                        Т.е. нужно рассматривать концепцию в виде «возможности + способ мышления».
                        • 0
                          Вызов метода — это техническая реализация.

                          Посылка сообщения, это концепция, реализуемая вызовом метода.

                          Я предпочитаю видеть явную реализацию, чем туманную концепцию.
                          • 0
                            Вызов метода это не посылка сообщения.

                            Во-первых, вызов метода — позволяет делать всего-лишь подмножество из тех вещей, которые возможны при посылке сообщения. Посылка сообщения включает в себя как минимум отложенный вызов, удаленный вызов метода, любую вариацию декораторов и прокси без введения новых классов, вызов несуществующих методов, возможность в рантайме заменить набор методов на другой (с удалением предыдущих).

                            Во-вторых, вы видите сокрытие реализации, а я вижу сокрытие концепции. Концепция это тоже важно, именно поэтому сейчас все основные языки вместо ООП имеют структуры + virtual table и никто не понимает, чем это лучше структур.
                            • 0
                              Я ничего не имею против концепции сообщения. Сообщения прекрасны.

                              Правда, когда мы делали асинхронную обработку сообщений, то натолкнулись на нехорошие вещи, связанные с невозможностью контролировать поток управления. Вот сообщение, вот мы его получили — а кто послал и в каком контексте — неизвестно. Синхронное процедурное программирование более детерминировано в этом смысле.

                              Но в общем, мне сообщения нравятся. Не нравится только высказывание, что «настоящее ООП» только сообщениями и ограничивается. Фактически, это не так, ведь для обработки сообщений нужны методы. Концептуальный сахар получается, короче :)
                              • 0
                                Правда, когда мы делали асинхронную обработку сообщений, то натолкнулись на нехорошие вещи, связанные с невозможностью контролировать поток управления.

                                Верно, эту фичу в обычных языках надо допиливать отдельно. Сейчас за вас это делает ваш язык программирования для синхронного кода — вызова методов. В том же C# есть отдельная поддержка асинхронного кода и во многих случаях стектрейсы получается адекватными (что не решает проблему отложенной обработки сообщений на другом приложении). Кроме того, не всегда нужно знать полный контекст.

                                Фактически, это не так, ведь для обработки сообщений нужны методы

                                Если вы понимаете под методами подпрограммы, то да, для того, чтобы что-то обработать нужны программы/подпрограммы/код. Но метод — это нечто большее, чем подпрограмма.
            • 0
              С моей точки зрения — ООП — это просто другой образ мысли. Отношение к программе — не как к набору (тексту) кода, а как к живому миру. Может быть к дому — большому и наполненным жильцами. Давайте попробую объяснить как я это вижу.

              Запуская программы ту заходишь в этот дом. Перед тобой холст — MainUI вокруг которого кнопочки звонков в квартиры -ToolBar. Например открытие файла -> звонок в квартиру -> вызов жильца. Прибегает жилец -> Project (вместе со всей семьёй: жена Scehma, дети Network-и, внуки Block -и). Project просит Schem-у нарисовать себя на холсте и отдает его ей. Она делит его между детьми и отдаёт каждому из них свой кусочек и просит теперь их нарисовать себя каждого на своём месте. Каждый Network пишет сверху свое имя, а остаток отдает на растерзание внукам. Каждый Block (а они все разные) знает своё место относительно имени родителя, рисует себя так как он себя видит. И вот войдя в дом и вызвав конкретный проект я вижу на холсте семейный портрет. Моя задача как программиста научить всю эту толпу рисовать себя. Рядышком на соседнем холсте портрет семьи библиотеки (Block Library). Когда мне надо добавить в семью Project-а новый блок, я сообщаю об этом Block Library (startDrag -> endDrag). Она же является моделью для второго холста. Создатели (разработчики языка) уже научили её кому об этом надо сказать — Controller-у. А ему уже я подсказал кому передать это сообщение — Scheme. Она выбирает кому из детей отдать новый Block (зависит от места endDrag), и отдает его.

              Всё это звучит наверное достаточно глупо, но таким образом легче понимать взаимодействие объектов в большой системе. В этом отношении ООП дает больше возможности абстрагироваться от кода, а SmallTalk с близостью его синтаксиса к нормальному языку, дает возможность легче объяснить объекту что от него хотят и как это нужно сделать.
              • 0
                Модель акторов языконезависима, емнип.
          • +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

            Я думаю, что если мы не будем поддаваться очарованию магических слов типа «сообщение», то перед нами откроется реальность как она есть.
            • 0
              «Сообщение» — не совсем магическое слово. Например, я могу задать метод, в который будут попадать неизвестные сообщения (с аргументами и т.д.). Таким образом легко сделать объект-прокси.
              • +1
                В обероне это реализуется с помощью Generic Message Bus. Без введения дополнительных понятий.
                • +1
                  А Generic Message Bus — это не дополнительное понятие? :)
                  • +1
                    Это внеязыковый паттерн, построенный, всё же, на некоторых инвариантах языка.
            • +2
              М-м-м, я с вами согласен. Я когда-то пришел к выводу, что ООП это не столько методология программирование, сколько способ организации кодом. Я поясню свою мысль: с увеличением объема программ (в строках, оперируемых сущностях) возникает проблема управления большими объемами кода. И ООП предлагает такой подход: компоновка в одном пространстве данных и процедур, работающих с этими данными. Мы инкапсулируем в отдельном контейнере данные и процедуры.

              Словом, как всегда, разделяй и властвуй.
              Все остальное — полезные, удобные добавки вокруг.

              А так, как ни крути, все равно все сведется к ассемблеру
              • +1
                Я поясню свою мысль: с увеличением объема программ (в строках, оперируемых сущностях) возникает проблема управления большими объемами кода. И ООП предлагает такой подход: компоновка в одном пространстве данных и процедур, работающих с этими данными. Мы инкапсулируем в отдельном контейнере данные и процедуры.


                Ох, тогда Вирт прав и нам прямая дорога в какой-нибудь С++ :)
              • +1
                Да, статическую структуру соединяем с алгоритмами и получаем «объект». Множество объектов приходится обозначать словом «класс». Кроме этого, требуется ещё и взаимодействие объектов между собой, а это возможно только если они способны коммуницировать — вот и появляется «сообщение».

                А в основе лежит та же статическая структура с ассоциированными с ней процедурами.
                • 0
                  Возможно, вы ожидали увидеть революцию, там где есть эволюция?
                  • 0
                    Речь идёт не о революции и не об эволюции, а о некоторых ошибочных представлениях об ошибочных представлениях.
                • 0
                  Соединяя статическую структуру с алгоритмами, получаем «абстрактный тип»… или модуль в паскале :) Нет, назвать, конечно, можно и объектом. Но это не будет объектом Алана Кея. У последнего только одно обязательное свойство — отвечать на сообщение. Все остальное — детали реализации. От которых не только в принципе можно, но и на практике хотелось бы отказаться, когда речь заходит об основах и «языке».
                  • +1
                    Процитирую вам Гради Буча: «Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений».

                    Не знаю, может у Алана Кея какие-нибудь другие, особенные «объекты». Формальный аппарат Оберона позволяет совершенно спокойно реализовать процитированную концепцию.
                    • +1
                      Видите ли, это у Гради Буча свое какое-то понимание ООП.
                      А Алан Кей один из первых отцов основателей ООП
                      userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

                      Хотя это суть неважно. Мнится мне, что это битва за термины.
                      • 0
                        Всякий термин что-нибудь обозначает. Вот Вирт говорит, что суть одна, а терминов, её обозначающих, много.
                        • 0
                          А его за такое в непонимании ООП обвиняют.
                    • +1
                      Вы сами понимаете, что вы пытаетесь доказать? Если да — раскройте пожалуйста.

                      Есть термин: объектно(-ориентированное) программирование. Есть автор этого термина — Алан Кей. Есть набор концепций, который автор (со своей командой) вкладывал в этот термин. В History of Smalltalk он подробно объяснил свою концепцию, разделив принципы на две группы: основу и детали реализации. Если продолжать его мысль, окажется, что в основе лежит один принцип — обмен сообщениями. Все остальное по необходимости «выводится» из этого принципа. Smalltalk в этом отношении — не идеальный язык, так как в него введены некоторые необязательные концепции (например, классы… я бы добавил еще, но это надо обсуждать отдельно), Self в этом отношении получше, но все равно не идеален. Идеального языка я не знаю.

                      А есть еще набор интерпретаций того же термина другими лицами. Интерпретации эти обычно сложнее. Интерпретации приводят к другому пониманию, к другой организации разработки, к более сложным и «раздутым» языкам… В общем, ни к чему хорошему не приводят вплоть до идеи «ООП мертв» без понимания, что же такое ООП на самом деле.

                      Реализовать ООП — в любой интерпретации — можно очень разными способами наверное в любой из существующих «парадигм»: можно в процедурной, можно в функциональной (надеюсь, они подтянуться сюда и нам не придется вести дискуссуию на два фронта — каждой из трех сторон:). О чем это говорит? Да ни о чем! Объектами тоже можно реализовать и функциональную концепцию и процедурную…

                      Так что же вы хотите донести до нас?
                      • 0
                        Если уж на то пошло, то Алан Кей не является автором понятий «класс» и «объект».

                        Речь идёт о том, что вы ставите тождество ООП = Smalltalk и упрекаете Вирта в том, что он не следовал дао смолтока.

                        Но если посмотреть на оберон-системы, то там есть сообщения. И даже, вы представляете, есть асинхронность. Есть классы объектов, есть экземпляры. Есть поведение. То есть, ООП реализовано нормально, суть проявлена.

                        А вот что такого магического ВЫ пытаетесь донести до нас, чего никто не знает и знаете только вы, вопрос.
                        • 0
                          Я, к примеру, среди прочего, пытался донести, что понятие «класс» не является базовым понятием объектного программирования.

                          Впрочем, я уже больше ничего не пытаюсь донести до вас, извините :) Что мог — сделал.
                          • 0
                            Да вы что?

                            Читаем: gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

                            Четвёртый из шести принципов Smalltalk:

                            4) Every object is an instance of a class (which must be an object)
                            • 0
                              А теперь еще неутомимо читаем следующий абзац…
                              • 0
                                И в следующем абзаце и в дальнейших абзацах плотно используется слово «class». Такое ощущение, что вы плохо ориентируетесь в вопросе. Это пока только ощущение.
                                • 0
                                  Дочитал Алана Кея. Моё ощущение переросло в уверенность. Теперь понятно, почему вы так безапелляционно обвинили Вирта в непонимании сути ООП.
                                  • +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 уже существовал. Думаю, Кэй был в курсе и неспростра внес эту оговорку.

                                    «Имеющий мозг да поймет»

                                    Если вы зададитесь трудом немного поразмыслить над вашим — безусловно богатейшим — опытом программирования «в объектной парадигме», то, уверен, в какой-то момент вы осознаете, что классы очень полезны при решении «стандартных» задач, но могут «не менее очень» мешать, когда приходится делать что-то на мета-уровне с отдельными объектами (когда нужно отдельному объекту задать специфическое поведение). И если после этого вы сделаете еще небольшое усилие, то прекрасно увидите, что на уровне языка классы совсем и не нужны — достаточно порождать объекты по образу и подобию уже существующих. А классы можно прекрасненько реализовать в библиотеке и пользоваться ими тогда, когда это действительно нужно.
                                    • 0
                                      О, пожалуй да, перевод нужен! Я не буду вам накидывать тучу цитат из того же самого текста про классы, давайте сначала разберёмся с вашим переводом.
                                      • 0
                                        Хорошо, раз уж сам предложил, потрачу на этот балаган еще немного своего времени :)

                                        Первые три принципа говорят о том, что такое объекты вообще (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.


                                        Переводить и понимать вам придется самостоятелно. Я завязываю с этой бессмысленной тратой моего времени.
                                        • 0
                                          Секта свидетелей Алана Кея, что я могу ещё сказать. Вы не видите разницы между экземпляром множества и самим множеством. Тут я бессилен.
  • 0
    Отличная статья. Спасибо.

    Возможно Вы знаете, но все таки расскажу, что Smalltalk изучают в Южном Федеральном Университете. Если интересно найти «единомышленников», то нужно поискать доцента кафедры математического анализа мехмата ЮФУ Кирютенко Юрия Александровича. Он автор нескольких работ по Smalltalk, и значительная часть студентов у него пишут проект на Smalltalk. Я, будучи «его студентом», писал несколько классов в один проект, связанный с государствеными образовательными стандартами (ГОС ВПО).
    • 0
      Спасибо за информацию. Не знал. Знал только что одно время SmallTalk преподавали в Таганрогском радиотехническом институте, и еще в каком то институте под Москвой. Но в Таганроге была своя — особенная версия языка полностью переведённая на русский язык. В принципе язык это позволяет, но смотреть на него было непривычно))))
      • 0
        Не SmallTalk, а Smalltalk.
        • 0
          Ну извини, исправлюсь )))

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка