(no subject)

[singalen]

В прошлый раз это было волшебно. Лёша в первый раз появился в компании, и сразу устроил рассказ о системе на Smalltalk. Как сказал upstartn, давно уже не чувствовал себя таким глупым - когда понимаешь менее 10% того, что тебе объясняют.
Система ни на что не похожа. Удивительно видеть, как юнит тест по мере прохождения с минимальными усилиями отрисовывается в виде графа в соседнем окне.

Лёша рассказывал об объектной СУБД, которая сама по себе тоже Smalltalk runtime environment. Что можно просто пометить метод как выполняемый на сервере и выполнить его там, а результат вернуть на клиента. Что все объекты в RTE сервера уже персистентны. Как такая СУБД принципиально отличается от реляционных, и что SQL - ужасный костыль для тех, кто не может полноценно обращаться с объектами.

Система, поправьте меня если что, автоматизирует управление машиностроительным предприятием. Выглядит очень мощно, чтобы написать такое на Delphi, пришлось бы потратить в десятки раз больше времени (я не преувеличиваю). А на Джаве - в сотни ;)

Как Алексей выбрал Smalltalk? Читал Гамму и прочих, они упоминали Smalltalk как истинный ОО язык. В отличие от всяких C++ :)
Изучил, понравилось. Сделал в ней систему.
Дальше цитирую vbayda: Сегодня первый раз в жизни увидел "счастливого программиста" То есть, не просто какого-то счатливого в данный момент человека. А именно программиста, который уже года полтора развивает проект и... полностью доволен тем, что у него получилось [...], не встречал проблем, которые было сложно реализовать средствами языка, кривых библиотек, не делал хаков.
Еще одно Чудо. Этот человек пользуется сторонней библиотекой для удаленной работы с обьектами, и ему никогда не приходилось ковырять, как она реализованна на низком уровне, не нужно было делать хаки и обходить предлагаемые языком либо библиотеками решения - вот это я понимаю, инкапсуляция :)

Мы его постоянно расспрашивали, так что даже не дали доесть первую порцию пиццы. Сами слопали по три.
Расспрашивали о проблемах, вызванных Smalltalk-ом. Никаких серьёзных Лёша не назвал, надо же 8)

Дальше мои разрознённые заметки.

Рассказал, как Smalltalk разрешает read-read и read-write конфликты. "Можно работать методом страуса".

И ещё много всего, что я не запомнил или не понял. Но буду пытаться :)

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

"- Этим бы всем овладеть лет в двадцать с небольшим...
- А если с большим? Овладеть..."

(Лёша рассказывает о каких-то паттернах)
- Там их два, но я расскажу о трёх.

Comments

[nponeccop.livejournal.com]

Но GUI - это же не часть языка. Это часть runtime environment, часть универсального фреймворка, поставляемого с языком. Соответственно мне бы интересно было узнать не то, красивые виджеты там или нет, и на каких платформах работают. А то, насколько сам UI фреймворк удобен в работе по сравнению с другими и то, какие возможности создателям UI-фреймворка дала гибкость языка.

Мои системы состоят сплошь из уникальной бизнес-логики которую никто раньше не реализовывал, и поэтому мне интересны прежде всего свойства самого языка, а не платформы в целом.

[(Anonymous)]

Наверное выше я немного резко выражался, приношу извенения.

GUI фрэймворк в работе удобен, как по мне даже очень удобен. Если говорить про VisualWorks - там гуй строится на основе адаптеров. Адаптер это как бы посредник между виджетом(контролером) и domain-м. Фактически адаптер возвращает тот объект который показывается в виджете. Адаптер получает от виджета запрос на модификацию и выполняет модификацию в domain. Когда виджету необходимо получить данные из модели(первое получение либо рефреш) он просит адаптер вернуть объект.

Если мы говорим о таблицах то, как правило, все происходит примерно так:
Есть коллекция - ее необходимо отобразить/редактировать в одномерном либо двумерном виде. Каждому столбцу назначается адаптер.

Адаптер:запросНаМодификацию и Адаптер:дайОбъект - это точки расширения. Есть адаптеры которым достаточно указать путь к объекту #(company name) и он сам выполнит модификацию объекта и его возврат по требованию. Есть адаптеры которые параметризуются блоками(неименованными функциями) - один блок на получение данных, один на изменение. В более сложных случаях можно написать свой адаптер(это не сложно) чаще всего как подкласс существующего. Виджету можно подставить любой адаптер.

Адаптер возвращает объект. Виджеты могут работать не только со строками но и с объектами(например в ComboBox-е отображаются объекты). Стандартно виджет может сам преобразовывать объект в строку(у объекта спрашивается displayString). Если надо преобразовать строку в объект, то задается метод который вызывается у ApplicationModel(можно провести некоторую паралель с окном). Этот метод можно считать чем-то вроде callback function. Метод пишем по своему усмотрению. На самом деле виджет при преобразовании строки в объект и обратно использует PrintConverter который мы можем параметризировать своими блоками(2 болка - чтение, запись) либо написать свой PrintConverter который должен отвечать на чтение, запись: (что-то вроде интерфейса).

Кроме того у виджетов есть возможность указать метод который будет вызываться при валидации введенного значения. Наример в этом месте удобно проверять инварианты.

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

Адаптер это вообщем-то не только точка расширения. Это воззможность вынесение общего за скобки. Что вообщем-то зачастую одно и то-же, ведь мы тоже хотим с помощью точки расширения вынести общее за скобки.

Вообщем-то это лиш часть фрэймворка.

[(Anonymous)]

Кроме описанной выше схему работы с адаптерами существует возможность делать интерфейс по типу нарисовали накладную соеденили ее стрелочками с отправителем, получателем. Так например удобно делать производственные схемы или в более общем случае графы. Для этого можно использовать HotDraw либо GF/ST. Так как такой интерфейс зачастую очень нестадертен то фреймворки сильно параметризируются и даже ихменяются. Изменения опять же идут в отдельном пакете и всегда можно просмотреть "истинный" метод, либо откатиться полностью. Тестировать такие вещи тоже достаточно удобно.

[nponeccop.livejournal.com]

Но это ж по сути всего лишь наличие дополнительного нестандартного виджета в стандартной библиотеке?

[(Anonymous)]

Бизнес логику на Smalltalk-е очень удобно реализовывать. Например есть такие методы для фильтраций колекций(параметризуются блоками), группировки, отображений (типа map), и еще куча всего. Колекции и работа с ними это тоже конек Smalltalk-а. Сильно помогают блоки, а также возможность изменять методы во всей системе. Например можно добавить методы Object-у, Number-у, Date, ...
Кроме того Smalltalk, как и многие другие другие не мейнстримовые языки, может может выполнять вычисления без потери точности (данные могут храниться как дроби при вычислении дроби могут сокращаться), а также числа могут быть большими, например можно вычислить 1000 factorial. Если необходима быстрая работа с числами то есть обычные короткие целые числа, а также числа с плавающей запятой. В целом работа с разными видами чисел остается для приложения прозрачной.

Параметризация блоками

[nponeccop.livejournal.com]

Блоки - это как я понимаю анонимные функции-closures? Рад слышать, что эти элементы функционального подхода таки сильно помогают в работе.

А вычисления - это не очень важно. С++ разрабатывался (судя по зеленой книжке второго издания Страуструпа) как раз с целью возможности добавления длинных, рациональных и вообще каких угодно чисел. И что из этого? Разве в С++ это проблема с его перегрузкой операций? Я не думаю, что наличие подобной арифметической библиотеки в стандартной поставке можно считать значительным преимуществом платформы.