singalen | (no subject)

Current Music: Тимур Шаов - Мечтательный пастух, изгой нечерноземья

Entry tags:

(no subject)

В прошлый раз это было волшебно. Лёша в первый раз появился в компании, и сразу устроил рассказ о системе на Smalltalk. Как сказал

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

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

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

Как Алексей выбрал Smalltalk? Читал Гамму и прочих, они упоминали Smalltalk как истинный ОО язык. В отличие от всяких C++ :)
Изучил, понравилось. Сделал в ней систему.
Дальше цитирую

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

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

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

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

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

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

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

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

Flat | Top-Level Comments Only

Витя, спасибо за такой романтический отзыв ;)

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

Есть две схемы обнаружения конфликтов между сессиями - read-write и write-write. Read-write надежный (мне не удалось придумать ни одного примера когда такую проверку можно было бы обойти). Но при read-write конфликты происходят часто. При возникновении конфликта происходит откат (клиентская часть СУБД автоматом производит также откат на клиенте). Из-за чего могут применятся схемы повторного наката изменений(повторный накат опять же надежен). Повторный накат изменений надо делать самому, что вобщем-то в Smalltalk системах как правило несложно. Например у меня в системе есть всего три операции модификации - изменения атрибута(instance variable) и добавление/удаление в адаптер коллекций. И то и другое инкапсулированно - то есть существует 3 метода (модификация, добавление, удаление) в которых можно выполнять заполнение глобального журнала модификаций. Правда такая система наката у меня еще не реализована (заказчики ставят другие приоритеты).
Из-за того что read-write конфликты происходят часто на практике чаще применяют схему с write-write конфликтами. Она менее надежна (в случае необходимости можно пользоваться локами) но конфликтов меньше.
В СУБД существует возможность создавать колекции, одновременное добавление в которые разных сессий не вызывает конфликтов. Вообщем выбор есть. Из-за большого выбора бывает трудно решиться на что-то. Благо в Smalltalk-е все можно просто переделать (рефакторинг, рефлекшн, тесты(тесты в Smalltalk часть культуры)).

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

"Что все объекты в RTE сервера уже персистентны"
Скорее все объекты к ктороым можно прийти из некоторой общей точки входа. Остальные объекты(временные, либо старые версии измененных объектов) убираются в базе сборщиком мусора.

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

Alex Baran

Как я понял, в моей терминологии система явояется вполне мейнстримовой - простой, но объемной "базкой". То есть, основной объем работ - это UI к СУБД.

Именно поэтому столько внимания уделяется использованию smalltalk в качестве DBMS. Соответственно сразу возникает вопрос - как там с UI?

Вообще, UI (Desktop и Web UI) и DBMS - это два кита, на которых держится мейнстрим. Более того, это две самые лапшевидные области программирования - то есть, хороших фреймворков и способов инкапсуляции как бы нет, и всё делается copy-paste.

Моим другом высказывалась идея, что разработка мейнстрима на продвинутых немейнстримовых языках и фреймворках даст колоссальный экономический эффект. Рад, что это удалось хоть кому-то подтвердить на практике и эффект не 10-15%.

Это не только UI к БД. Я помню в ней элементы АСУП: графики использования запчастей, диаграммы расположения по цехам и т.п. При этом запчасти можно перетаскивать/редактировать мышой, и это сразу отразится на данных. Всё это делается малым количеством кода.
UI вполне на уровне дельфийского - таблички, кнопочки и всё такое.

Я помню в ней элементы АСУП: графики использования запчастей, диаграммы расположения по цехам и т.п. При этом запчасти можно перетаскивать/редактировать мышой, и это сразу отразится на данных.

А это что, если не User Interface и связь с БД?

Так можно назвать вообще любую end-user программу.
В типичном дельфийском приложении GUI + DB выглядят как гриды-гриды-гриды-формы-ввода-формы-ввода-пачка-отчётов.
В этой системе GUI пошёл существенно дальше.

Хотя да, АСУП - это тоже в некотором смысле интерфейс к БД. Плюс немалое количество бизнес-логики.

Ну АСУП - это бизнес-логика. Вы же говорили как раз про интерфейс и ни слова о логике.

Идея была неправа, когда высказывалась. VCL - отличный фреймворк для GUI к БД, и "не пошёл" он скорее по маркетинговым причинам.
Только вот, как и учит нас Фаулер, начиная с некоторого количества бизнес-логики, этот паттерн не справляется с логикой системы.

Какой паттерн?

Если мне память неизменяет, то помему как раз на том собрании он говорил, что одна из "проблем" в SmallTalk - UI.

Когда я шел на встречу мне меньше всего хотелось разговаривать о том где используется Smalltalk, к какому классу систем он более пригоден, к какому менее пригоден. Хотелось же поговорить о том что внутри конкретной системы о гайках-и-болтах о решениях и их последствиях. Вот и сейчас встает вопрос про гуй. Могу точно сказать что гуй в смолтолке есть :) Есть всякие таблички, HotDraw, возможность создавать свои собственные компоненты, GUI-builder-ы, разные варианты MVC. GUI бывает эмулированный (VisualWorks, Squeak) либо нативный (Dolphin). Эмуллированные виджеты используются в кросплатформенных Smalltalk-х (поправьте меня на счет VisualAge) и везде отрисовываются одинаково. Dolphin работает только под виндой. ИМХО нестандартный гуй проще реализовать в системах с эмулированными виджетами, зато если гуй стандартный то нативные системы быстрее и отрисовываются аккуратнее. Тестить проще когда гуй с эмулированными виджетами.
ИМХО Smalltalk хорош когда задача имеет элемент нестандартности либо поимеет этот элемент со временем. Либо когда заказчик видит только общее направление но не видит точной реализации(мне например этот вариант интереснее чем сделай так и так). Рефакторинг, эволюционность, быстрый эксперимент, нестандартный гуй, сложная богика - это конек Smalltalk-а.
Стандартный быстрый гуй, схема четко подходящая под таблицы, малое количество бизнес логики - это скорее ближе к Delphi и подобным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://vbayda.livejournal.com/3045.html
"Вообще, то, что он делал этот проект дома, наводит на подозрения, что он делал его в одиночку и что smalltalk плохо подходит для collaborative development."

На Smalltalk-е совместно пишут большие системы:
http://groups.google.com.ua/group/soft_rd_dp_ua/browse_thread/thread/5d79fbe5542520cd/e0457e3bef780adf?hl=ru#e0457e3bef780adf

Smalltalk реализации как правило имеют хорошие системы версионного контроля (например Envy, Store). Версионность ведется для каждого метода, класса, пакета(в отличие от систем в которых ведется версионность файлов). Тестирование, как я уже говорил это часть культуры. Частые билды, короткие итерации тоже. Smalltalk системы хорошо делятся на части - например GUI логика от domain хорошо отделяется.

Спасибо. Комментарий был мой а не Байды.

Извеняюсь, заметил когда уже запостил :)

Создал страничку со своими хоби-проектами на Smalltalk-е:
http://aleksijb.googlepages.com/index.htm

Есть описания с картинками и возможность скачать.

Читал сегодня старые посты. Был пост про пересечение окружностей http://singalen.livejournal.com/89883.html#cutid2

Несдержался написал историю о том как делал на Smalltalk-е. Описан сам процесс:

http://aleksijb.googlepages.com/circlesIntersections.htm

Flat | Top-Level Comments Only

(no subject)

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

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

no subject

no subject

no subject

no subject

no subject