Валерий Крылов (justy_tylor) wrote,
Валерий Крылов
justy_tylor

Category:

Микротеории и срезы

Продолжая http://justy-tylor.livejournal.com/170049.html

Атрибуты имеют смысл лишь для чего-то имеющего identity. Рассмотрим структуру (класс) Vector3f с тремя полями (x, y, z) типа float, в каком-либо языке со статической типизацией. Vector3f (x=1, y=2, z=3) абсолютно то же самое, что и любой другой Vector3f (x=1, y=2, z=3). Это уже некий абстрактный срез информации о чём-то в трёхмерном пространстве (позиции, размерах, ...), оптимизированный под определённую микротеорию и определённое железо. Другая микротеория может потребовать точности double, другое железо - наличия дополнительного (зануляемого) четвёртого поля. Vector3f можно использовать как тип для атрибута, но добавление атрибутов непосредственно к (x=1, y=2, z=3) невозможно.

Однако, на низком уровне, для "двенадцати байт по адресу 0x87654321, представляющих экземпляр Vector3f" адрес в памяти можно применять как identity, например, для оптимизации доступа к какому-нибудь box123.position в графе вычислений.

Теперь от значений типа Vector3f перейдём к самому типу. Данные оптимизированы под одну микротеорию (вычисления), а код как реализует эту микротеорию, так и обеспечивает связь с другими микротеориями и срезами. В монолитном описании типа жёстко прописаны свойства и методы. Если в классе не прописан соответствующий метод toString (т.к. не был нужен автору кода в реализации его микротеории), то вы не сможете дописать его извне. Тогда в точке связи вычислительных и текстовых (отчётных) микротеорий придётся разбирать эту проблему вручную, через цепочку if. Однако, в более продвинутых языках для этого есть свои аналоги атрибутов. Вы можете написать темплейтную функцию to_string в C++ или использовать тайпкласс Show в Haskell. Или напрямую указать какие-то значения через трейты.

Атрибуты обеспечивают реюз модели данных для разного кода, template metaprogramming и type classes обеспечивают реюз кода для разных данных. Кода меньше, качество выше, казалось бы счастье.

Однако, посмотрим теперь на мэйнстримовые динамические языки. Классы как объекты, duck typing, monkey patching... Реюз там проще, синтаксического оверхеда меньше. Даже встроить REPL консоль в работающее приложение можно почти нахаляву. Счастье?...

Ещё нет. Статическая типизация лучше работает в пределах чётко заданных микротеорий. По всем параметрам: оптимизация, верификация, читаемость/самодокументируемость кода.

С другой стороны, в динамике проще exploratory programming и склейка микротеорий.

Объединить эти положительные качества - задача следующих поколений языков. Но уже сейчас можно правильно идентифицировать кейсы и применять соответствующие возможности существующих языков для их реализации.
Tags: архитектура
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 9 comments