Порождающий 2008г.
Определения (http://www.generative.net/read/definitions): Generative art is a term given to work which stems from concentrating on the processes involved in producing an artwork, usually (although not strictly) automated by the use of a machine or computer, or by using mathematic or pragmatic instructions to define the rules by which such artworks are executed.
Adrian Ward
Generative art refers to any art practice where the artist creates a process, such as a set of natural language rules, a computer program, a machine, or other procedural invention, which is then set into motion with some degree of autonomy contributing to or resulting in a completed work of art.
Philip Galanter
Еще (http://www.program-transformation.org/Transform/GenerativeProgramming):
И я нашел-таки место, которым можно все объяснить это новомодие порождающего подхода -- обратным прочтением первых же двух страниц диссертации "Aspect-oriented domain-specific modeling: a generative approach using a metaweaver framework" (http://www.cis.uab.edu/gray/Pubs/Dissertation.pdf). В этой диссертации говорится: In any engineering endeavor, a key requirement is the ability to compose large structures from a set of primitive elements. This is true for children who are constructing toy models of bridges and buildings using Lego™ or Erector™ sets. This is true, on a
larger scale, for civil engineers who design and supervise the construction of skyscrapers. This is especially true for software engineers who compose increasingly complex systems from components, classes, and methods.
An important difference between the engineering of software, and the other undertakings enumerated above, is the recognition that the set of available core elements for software construction is often significantly larger. The composition of these elements can be specified at a much finer level of granularity. As a contrast, the “bricks” used to build Lego™ houses, or the steel beams used in the construction of a bridge, come in but a few different shapes and sizes, and are composed using a simple standard interface (e.g., the prong and receptacle parts of a Lego™ block have been unchanged since 1932
[Lego, 2002]; likewise, since around 1850, the standard dimensions for an “air cell” masonry brick in the United States has been 2.5 x 3.75 x 8 inches [Chrysler and Escobar, 2000]).
Furthermore, the compositional permutations and dynamic interactions that are possible with software elements are several orders of magnitude richer than those found in other engineering activities. For example, a generic function can be parameterized with a seemingly unlimited number of other elements (e.g., a template function that can sort
any data type using numerous functors). Parametric polymorphism is but one factor that contributes to the exponential state explosion problem that makes the composition of software so difficult. A reason for this complexity is that the essence of software elements is expressed as logical abstractions, as opposed to physical materials, which results in the generation of an enormous state-space that must be tested. In fact, the core of Brooks’ “No Silver Bullet” essay is a commentary that the molding of complex conceptual entities is the essence of software construction [Brooks, 1995].
Так вот: современные инженеры и архитекторы не хотят больше мириться с тем, что у них кирпичи все одного размера, стекла плоские, а трубы или прямые, или гнутые под прямым углом. Музыканты не согласны с тем, что партитура не отражает саунда и не позволяет показать изменения тембра в уже звучащей ноте. Инженеры, архитекторы и музыканты хотят того же, что и софтверщики -- бесконечной гибкости материала, и способов борьбы с неминуемо возрастающей сложностью проектирования. А еще инженеры, архитекторы и музыканты хотят тех же прелестей, что есть у софтверщиков -- отладки, режима интерпретации, диалога по уточнению параметров и т.д.
Отсюда тяга к средствам автоматизации проектирования и музицирования, переосмыслению инженерных, архитектурных, музыкальных и всяческих других "алфавитов" (недаром трансформационные грамматики Хомского так часто встречаются в работах порождающего подхода), глубокая параметризация этих "алфавитов", переход от компиляционных к интерпретационным (точнее -- "сверхпознего связывания", я много писал об этом раньше) режимам (т.е. уход от "партитурности" к "джазовости").
Тем самым я бы определил порождающий подход как попытку в любой деятельности найти такие паттерны ("алфавит") конструктов и их параметризацию, которые способны породить бесчисленное количество выходных систем.
Например (возьмем примеры из http://ailev.livejournal.com/537500.html):
1. Онтологическая парадигма против объект-ориентированной дает возможность выбирать разные объекты (в смысле ООП) над одним и тем же множеством предметов (в онтологическом смысле), что дает как минимум один добавочный уровень косвенности в описаниях. Онтологическое описание задает другой (более нижнего уровня, чем строящееся на его основе ОО-описание) тип конструктов, поэтому и результаты получаются качественно другие.
2. В Karma 2.0 был предложен 4D музыкальный алфавит на базе не только нот и их последовательностей, сколько более низкоуровневых (работающих и "внутри нот", и "между нотами") "миди-событий". Такие описания порождают другую музыку, нежели могла себе позволить "традиционная нотная запись" (музыку тембра в том числе -- другие конструкты, другая музыка, http://www.livejournal.com/users/ailev/34758.html). Многие неухватываемые "традиционной партитурой" аспекты музыки (джазовый "свинг", например) становятся вполне описываемыми.
3. В современном планировании для планов предлагаются все более и более детальные описания, нежели PERT-описания. Так, в деревьях стратегии и тактики предлагается новый тип конструкта для планов -- прежде всего пара "состояние мира -- работа по его достижению", что явно более подробно нежели "дерево целей" в стратегировании и WBS у "классических проектов". Кроме того, в constraint techniques for planning предлагается еще более мелкая нарезка элементов плана -- "переменные" и "ограничения" (http://www.cs.rochester.edu/u/kautz/papers/nareyek-05-ieee.pdf).
4. Порождающее проектирование в современном инжиниринге -- по факту речь идет о том, чтобы "конструирование" (в машиностроительном смысле, создание уникальных изделий) и "проектирование" (в машиностроительном смысле, сборка из заранее известных серийно выпускаемых деталей) слились в едином порыве -- для этих самых "деталей" вводятся много более детальные и параметризованные описания, чем это было принято раньше. В результате можно спроектировать "кривой дом" из похожих друг на друга, но уникальных деталей [тут краткое отступление -- я встретился с таким "порождающим подходом" много лет назад на Атоммаше. Атомный котел представлял собой много-много (порядка полутора тысяч) сварных деталек, которые имели очень похожую форму, но тем не менее различались. Был сделан софт, который на основе описания этих "похожих, но разных" деталек составлял описание процесса их сварки -- выбор материала электрода, расчет потребного времени, расчет времени остывания материала и т.д. Бизнес-процесс сварки "порождал" (генерировал) конкретный набор документов выхода сварщика на работу с конкретной деталью на основе как описания этого бизнес-процесса в целом, так и описания целевой детали. Это были 1986-1987 годы, ровно двадцать лет назад]. Сейчас использование "порождающего подхода" в архитектурном дизайне позволяет получать здания криволинейных форм, наподобие Башни Федерации в Moscow City.
5. Понимание процесса генерации плана и деталек, из которых эти планы устроены, позволяет "генерировать" план из его параметризованных кусочков -- причем эта генерация (порождение) может происходить в реальном времени. В agile-проектах нельзя говорить, что никаких планов нет. Есть хорошо параметризованные планы для "кусочков работы", и процедура потактового планирования просто генерирует куски того, что нужно сделать на следующем такте, уточняя параметры уже известных (чаще всего -- из опыта, из культуры) кусков плана. Если в agile нужно в какой-то момент будет рыть яму, это лишь означает, что "план рытья ямы вообще" существует, не существует только "план рытья конкретной ямы" -- и эти конкретные (уточненные, порожденные) планы получаются из "алфавита параметризованных планов" именно путем "порождения" (генерации), растянутой практически по всей длине agile-проекта.
Я думаю, что многие противоречия планирования и проектирования можно решить, если соображать, что планирование и проектирование -- это не разовая и уникальная операция по созданию плана-project и проекта-design, а процесс "порождения" и соответствующие разным стадиям этого процесса разные состояния design и соответствующего ему plan.
Сюда и думать.
Adrian Ward
Generative art refers to any art practice where the artist creates a process, such as a set of natural language rules, a computer program, a machine, or other procedural invention, which is then set into motion with some degree of autonomy contributing to or resulting in a completed work of art.
Philip Galanter
Еще (http://www.program-transformation.org/Transform/GenerativeProgramming):
- The goal of generative programming is to replace manual search, adaptation, and assembly of components with the automatic generation of needed components on demand [from the call for papers of GP2002 at ICSR7].
- The goal of generative and component-based software engineering is to increase the productivity, quality, and time-to-market in software development thanks to the deployment of both standard componentry and production automation. One important paradigm shift implied here is to build software systems from standard componentry rather than "reinventing the wheel" each time. This requires thinking in terms of system families rather than single systems. Another important paradigm shift is to replace manual search, adaptation, and assembly of components with the automatic generation of needed components on demand. Generative and component-based software engineering seeks to integrate domain engineering approaches, component-based approaches, and generative approaches. [from GCSE working group page]
- Generative programming is a software engineering paradigm based on modeling software families such that, given a particular requirements specification, a higly customized and optimized intermediate or end-product can be automatically manufactured on demand from elementary, reusable implementation components by means of configuration knowledge. [from the GenerativeProgrammingBook]
И я нашел-таки место, которым можно все объяснить это новомодие порождающего подхода -- обратным прочтением первых же двух страниц диссертации "Aspect-oriented domain-specific modeling: a generative approach using a metaweaver framework" (http://www.cis.uab.edu/gray/Pubs/Dissertation.pdf). В этой диссертации говорится: In any engineering endeavor, a key requirement is the ability to compose large structures from a set of primitive elements. This is true for children who are constructing toy models of bridges and buildings using Lego™ or Erector™ sets. This is true, on a
larger scale, for civil engineers who design and supervise the construction of skyscrapers. This is especially true for software engineers who compose increasingly complex systems from components, classes, and methods.
An important difference between the engineering of software, and the other undertakings enumerated above, is the recognition that the set of available core elements for software construction is often significantly larger. The composition of these elements can be specified at a much finer level of granularity. As a contrast, the “bricks” used to build Lego™ houses, or the steel beams used in the construction of a bridge, come in but a few different shapes and sizes, and are composed using a simple standard interface (e.g., the prong and receptacle parts of a Lego™ block have been unchanged since 1932
[Lego, 2002]; likewise, since around 1850, the standard dimensions for an “air cell” masonry brick in the United States has been 2.5 x 3.75 x 8 inches [Chrysler and Escobar, 2000]).
Furthermore, the compositional permutations and dynamic interactions that are possible with software elements are several orders of magnitude richer than those found in other engineering activities. For example, a generic function can be parameterized with a seemingly unlimited number of other elements (e.g., a template function that can sort
any data type using numerous functors). Parametric polymorphism is but one factor that contributes to the exponential state explosion problem that makes the composition of software so difficult. A reason for this complexity is that the essence of software elements is expressed as logical abstractions, as opposed to physical materials, which results in the generation of an enormous state-space that must be tested. In fact, the core of Brooks’ “No Silver Bullet” essay is a commentary that the molding of complex conceptual entities is the essence of software construction [Brooks, 1995].
Так вот: современные инженеры и архитекторы не хотят больше мириться с тем, что у них кирпичи все одного размера, стекла плоские, а трубы или прямые, или гнутые под прямым углом. Музыканты не согласны с тем, что партитура не отражает саунда и не позволяет показать изменения тембра в уже звучащей ноте. Инженеры, архитекторы и музыканты хотят того же, что и софтверщики -- бесконечной гибкости материала, и способов борьбы с неминуемо возрастающей сложностью проектирования. А еще инженеры, архитекторы и музыканты хотят тех же прелестей, что есть у софтверщиков -- отладки, режима интерпретации, диалога по уточнению параметров и т.д.
Отсюда тяга к средствам автоматизации проектирования и музицирования, переосмыслению инженерных, архитектурных, музыкальных и всяческих других "алфавитов" (недаром трансформационные грамматики Хомского так часто встречаются в работах порождающего подхода), глубокая параметризация этих "алфавитов", переход от компиляционных к интерпретационным (точнее -- "сверхпознего связывания", я много писал об этом раньше) режимам (т.е. уход от "партитурности" к "джазовости").
Тем самым я бы определил порождающий подход как попытку в любой деятельности найти такие паттерны ("алфавит") конструктов и их параметризацию, которые способны породить бесчисленное количество выходных систем.
Например (возьмем примеры из http://ailev.livejournal.com/537500.html):
1. Онтологическая парадигма против объект-ориентированной дает возможность выбирать разные объекты (в смысле ООП) над одним и тем же множеством предметов (в онтологическом смысле), что дает как минимум один добавочный уровень косвенности в описаниях. Онтологическое описание задает другой (более нижнего уровня, чем строящееся на его основе ОО-описание) тип конструктов, поэтому и результаты получаются качественно другие.
2. В Karma 2.0 был предложен 4D музыкальный алфавит на базе не только нот и их последовательностей, сколько более низкоуровневых (работающих и "внутри нот", и "между нотами") "миди-событий". Такие описания порождают другую музыку, нежели могла себе позволить "традиционная нотная запись" (музыку тембра в том числе -- другие конструкты, другая музыка, http://www.livejournal.com/users/ailev/34758.html). Многие неухватываемые "традиционной партитурой" аспекты музыки (джазовый "свинг", например) становятся вполне описываемыми.
3. В современном планировании для планов предлагаются все более и более детальные описания, нежели PERT-описания. Так, в деревьях стратегии и тактики предлагается новый тип конструкта для планов -- прежде всего пара "состояние мира -- работа по его достижению", что явно более подробно нежели "дерево целей" в стратегировании и WBS у "классических проектов". Кроме того, в constraint techniques for planning предлагается еще более мелкая нарезка элементов плана -- "переменные" и "ограничения" (http://www.cs.rochester.edu/u/kautz/papers/nareyek-05-ieee.pdf).
4. Порождающее проектирование в современном инжиниринге -- по факту речь идет о том, чтобы "конструирование" (в машиностроительном смысле, создание уникальных изделий) и "проектирование" (в машиностроительном смысле, сборка из заранее известных серийно выпускаемых деталей) слились в едином порыве -- для этих самых "деталей" вводятся много более детальные и параметризованные описания, чем это было принято раньше. В результате можно спроектировать "кривой дом" из похожих друг на друга, но уникальных деталей [тут краткое отступление -- я встретился с таким "порождающим подходом" много лет назад на Атоммаше. Атомный котел представлял собой много-много (порядка полутора тысяч) сварных деталек, которые имели очень похожую форму, но тем не менее различались. Был сделан софт, который на основе описания этих "похожих, но разных" деталек составлял описание процесса их сварки -- выбор материала электрода, расчет потребного времени, расчет времени остывания материала и т.д. Бизнес-процесс сварки "порождал" (генерировал) конкретный набор документов выхода сварщика на работу с конкретной деталью на основе как описания этого бизнес-процесса в целом, так и описания целевой детали. Это были 1986-1987 годы, ровно двадцать лет назад]. Сейчас использование "порождающего подхода" в архитектурном дизайне позволяет получать здания криволинейных форм, наподобие Башни Федерации в Moscow City.
5. Понимание процесса генерации плана и деталек, из которых эти планы устроены, позволяет "генерировать" план из его параметризованных кусочков -- причем эта генерация (порождение) может происходить в реальном времени. В agile-проектах нельзя говорить, что никаких планов нет. Есть хорошо параметризованные планы для "кусочков работы", и процедура потактового планирования просто генерирует куски того, что нужно сделать на следующем такте, уточняя параметры уже известных (чаще всего -- из опыта, из культуры) кусков плана. Если в agile нужно в какой-то момент будет рыть яму, это лишь означает, что "план рытья ямы вообще" существует, не существует только "план рытья конкретной ямы" -- и эти конкретные (уточненные, порожденные) планы получаются из "алфавита параметризованных планов" именно путем "порождения" (генерации), растянутой практически по всей длине agile-проекта.
Я думаю, что многие противоречия планирования и проектирования можно решить, если соображать, что планирование и проектирование -- это не разовая и уникальная операция по созданию плана-project и проекта-design, а процесс "порождения" и соответствующие разным стадиям этого процесса разные состояния design и соответствующего ему plan.
Сюда и думать.