Re: Машина состояний
От: Qbit86 Кипр
Дата: 16.01.13 12:29
Оценка: 59 (3) +2 -1
Здравствуйте, Аноним, Вы писали:

А>Как такое запрограммировать с применением конечного автомата?


По ссылке статья от студента некоего Шалыто (или иначе причастного). Судя по доступным в интернете статьям этой секты из ИТМО, ребята живут в каком-то своём, оторванном от нашей реальности мире, занимаются имитацией бурной деятельности, называют себя адептами «автоматного программирования» и на полном серьёзе считают, что двигают науку вперёд. Т.е. делают из вполне заурядного (в ремесле программиста) инструмента какой-то rocket science. Причём собственно science уже был сделан в середине прошлого века Хопкрофтом, Ульманом и прочими Ахо.

А так — да, конечные автоматы при разработке логики UI часто используются. Без нагнетания пафоса и приукрашивания заявлениями о революционности подхода. Причём фактически используются инструменты принципиально более сильные, чем теоретическая конструкция «конечный автомат», так что их часто называют «машина состояний». В C++ можно использовать Boost.Statechart или Boost.Msm, в .NET — библиотеку Stateless или Forkflow Foundation, в WPF/Metro — (несколько ограниченный) VisualStateManager.

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


Обычное дело, в UML это называется guard condition.
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: Вода в решете
От: Privalov  
Дата: 20.01.13 09:08
Оценка: 18 (2) :)
Здравствуйте, Tanker, Вы писали:

T>Статья, абзац, цитата ?


Ну, вот эта статья, например. А еще есть монография.
Re[5]: Вода в решете
От: Qbit86 Кипр
Дата: 17.01.13 11:48
Оценка: +3
Здравствуйте, Tanker, Вы писали:

Q>>Не был бы так категоричен насчёт «обязательно». В мире есть и много других отличных книг, и даже курсы на Coursera, причём от первоисточников.

T>А на русском слабо показать, что бы не переводная была?

Зачем непременно непереводная? Какие-то комплексы (как у Шалыто) по поводу не отечественных разработок в computer science? В топку Ульмана — только Ершов, только хардкор?

T>А на русском слабо показать, что бы не переводная была?


Что подразумевает «слабо»? Это типа я должен кидаться доказывать, что не слабо, да?

Q>>По-моему, люди зарабатывают деньги профанацией. Они пишут горы пустых статей о ношении воды в решете, только называют это «инновационный метод транспортировки дигидрогена монооксида в ёмкости с перфорированным дном».

T>Покажи профанацию в виде ссылки, абзаца и тд.

Q>>Я припоминаю исходную статью про SWITCH-технологию. Там в качестве образца их новейшей методики приводилась таки действительно switch-простыня на Си (для разбора какой-то строки, что ли), за которую в приличных конторах как минимум лишают премии, а в неприличных — коллеги устраивают «тёмную».

T>Статья, абзац, цитата?

Tanker, ты случайно не из ИТМО?

Я не коллекционирую творчество г-на Шалыто, рассказал по памяти. Резона и необходимости повторно копаться в шлаке в поисках цитат у меня нет, не тот случай. Можешь просто принять к сведению оценочное суждение некоего форумчанина, можешь проверить сам, можешь отбросить как неудобное. Я же со своей стороны на юридическую строгость не претендую, если ты мне не поверишь — я совершенно не расстроюсь.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Машина состояний
От: Qbit86 Кипр
Дата: 16.01.13 13:52
Оценка: 12 (2)
Здравствуйте, Qbit86, Вы писали:

Q>«Теоретический» конечный автомат — довольно слабоватая махина...


Обратите внимание, в указанную ссылку из Википедии тоже просочились адепты культа Шалыто со ссылками на своё «автоматное программирование» aka «SWITCH-технология», или как там их фрико-ересь называлась.
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: Вода в решете
От: Qbit86 Кипр
Дата: 16.01.13 17:35
Оценка: 10 (2)
Здравствуйте, Tanker, Вы писали:

T>По моему из этого можно сделать вывод или о том, что тебе попадался только научпоп или что люди зарабатывают деньги научпопом.


По-моему, люди зарабатывают деньги профанацией. Они пишут горы пустых статей о ношении воды в решете, только называют это «инновационный метод транспортировки дигидрогена монооксида в ёмкости с перфорированным дном».

T>Я вот немного логики не понял, на основе наличия среди статей научпопа на тему автоматов ты сделал вывод про секту?


Не только я, увы.

T>Книга про автоматы у них просто отличная, студентам 2-3го курса просто обязательная к освоению.


Не был бы так категоричен насчёт «обязательно». В мире есть и много других отличных книг, и даже курсы на Coursera, причём от первоисточников.

Я припоминаю исходную статью про SWITCH-технологию. Там в качестве образца их новейшей методики приводилась таки действительно switch-простыня на Си (для разбора какой-то строки, что ли), за которую в приличных конторах как минимум лишают премии, а в неприличных — коллеги устраивают «тёмную». Ну и всё перемежалось тоннами самолюбования господина Шалыто о том, как к нему приходят все советоваться, как писать ПО для самолётов, и он всем всё понятно разъясняет (не написав в жизни ни строчки).
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: Машина состояний
От: Qbit86 Кипр
Дата: 16.01.13 13:46
Оценка: 8 (1) +1
Здравствуйте, Sharov, Вы писали:

Q>>Причём фактически используются инструменты принципиально более сильные, чем теоретическая конструкция «конечный автомат», так что их часто называют «машина состояний».


S>А Вы не могли по подробнее раскрыть тему...


«Теоретический» конечный автомат — довольно слабоватая махина, пригодная для разбора максимум регулярного языка. Число состояний в них конечно, в то время как в «программистских» конечных автоматах их может быть фактически бесконечное число (т.е., например, можно использовать для разборка контекстно свободных грамматик). С точки зрения программиста, состояния MyState(42.0, "Hello") и MyState(3.14, "World") — это два состояния одного стостояния (тавтология, да), в то время как с точки зрения теории их нужно признавать разными состояниями. Второй момент, что переходы могут зависеть не только от пары <текущее состояние, пришедшее событие>, но и от состояния этого события (Event(1928, "Jackie Brown") или Event(1956, "John Doe")) или вообще от фазы луны. Далее, в машинах состояний в описании перехода указывается не только целевое состояние, как в классических конечных автоматах, но и action, то есть произвольное действие, которое может при необходимости читать/писать состояние машины/мира.

S>...желательно с сылками?


Да собственно, по той же ссылке на Википедию:
UML state machine, also known as UML statechart, is a significantly enhanced realization of the mathematical concept of a finite automaton in computer science applications as expressed in the Unified Modeling Language (UML) notation.

(Кстати, automata — это лат. множественное число от «автомат», почему автор обсуждаемой статьи его использует в примерах?)
Ещё неплохо раскрывается тема (в частности, иерархически вложенные состояния/машины) в документации к Boost.Statechart.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Применимость конечных автоматов в GUI
От: maxkar  
Дата: 18.01.13 14:39
Оценка: 2 (1) +1
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, Аноним, Вы писали:


А>>Как такое запрограммировать с применением конечного автомата?

LVV>Это два разных состояния автомата.
LVV>Если введенные данные корректны — переходим в новое состояние, где кнопка открыта.
LVV>Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?)

На практике — сложнее. Мы ведь хотим все правильно сделать? Значит для "статус введенных данных" появлюятся как минимум три состояния:
* Данные корректны
* Данные некорректны
* Данные проверяются (выполняется асинхронный запрос).
Может быть, еще и четвертое состояние (ошибка асинхронного запроса). Из третьего состояния может быть спонтанный переход по "внешнему" (не пользовательскому) событию в остальные. Из любого из этих четырех на одно событие (пользовательский ввод) может быть переход в третье состояние (т.е. начало асинхронной загрузки). Если чуть усложнять, будет еще и переход в любое из трех состояний (например, мы кэшируем балансы счетов на клиенте). И еще подобная груда стрелочек будет для каждого события "ввод суммы платежа".

Теперь нужно учесть, что есть какие-то другие состояния, т.е. на самом деле будет произведение <some states> * <payment state>, в общем, душераздирающее зрелище. Хотя в UML стоит попробовать нарисовать, чтобы убедиться, что конечные автоматы туда плохо подходят. Или нужна хорошая библиотечка комбинаторов.

А еще у КА есть идеологические проблемы. Например, заносить ли "вычислимое состояние" в еще одну размерность автомата. Ладно у ТС пример с async'ом. А ведь может быть ветвление и полностью синхронное (форма подтверждения пароля). Вот будет ли автомат в виде (<password1> * <password2>) (минимальный набор) или в виде (<password1> * <password2> * <confirmed successfully>) (удобное для действий). Чисто математически, это вообще одно и то же множество. Но ведь на практике <password1> очень захочется записать "одним" состоянием, а не их бесконечным множеством. Там мы получим все те проблемы, которые возникли у ТС.

На практике иметь понятие "Состояние" очень удобно. И привязываться к нему для выполнения набора действий — тоже. А формализовывать состояние до универсального КА — не стоит. Т.е. на практике работает композиция. Например, базовые состояния a, b, c, и d. Какое-то вычислимое состояние e = f1(a, c), другое вычислимое состояние g = f2(e, a, d) и т.д. В нужных проверках используются только отдельные состояния, UI биндится только к нужным состояниям, события меняют только нужные базовые состояния и т.п. Математически это, конечно, переводится в КА, только вот на практике результат получается печальный. А само выделение явных состояний таки полезно — оно позволяет все "нетривиальные сценарии" пользователя заставить более-менее продумывать (если все параметры UI вычисляются только от моделей, придется хотя бы задуматься о некорректных состояниях).
Применимость конечных автоматов в GUI
От: Аноним  
Дата: 16.01.13 12:05
Оценка:
Доброго дня!
Натолкнулся случайно на здесь
Автор(ы): Александр Бабаев
Дата: 12.05.2006
Метод, представленный в статье, кардинально отличается от тех методов, которые применяются сейчас для создания логики пользовательского интерфейса. Он позволяет, в конечном счете, улучшить качество конечного интерфейса и его исходного кода, ускорить разработку и упростить поддержку. Метод основывается на подходе, активно пропагандируемом Анатолием Абрамовичем Шалыто и использует большую часть достоинств автоматного метода программирования.
статью, оценил оригинальность идеи, а потом попытался притянуть ее к реальной ситуации и кое-чего не понял.
Как быть если следующее состояние автомата не может быть однозначно определено парой: (<текущее_состоянием>, <выполняемое_действие>), а завит также от других факторов? В этом случае вариант с автоматной организацией интерфейса не применим или надо как-то иначе организовать автомат?

Например.
Есть диалог, в котором надо выбрать из плана счетов счет плательщика, ввести сумму платежа и разные другие параметры, а затем нажать кнопку "Сохранить".
По одному из требований бизнес-логики введенные параметры считаются корректными, если на выбранном счете плательщика есть остаток не ниже заданной суммы платежа.
Допустим, решено делать кнопку "Сохранить" доступной для нажатия (Enabled = true) только если вышеозначенное требование удовлетворено. Вопрос юзабилити (на сколько такое "молчаливое" поведение будет понятно пользователю) мы пока не рассматриваем, просто так решено и так надо сделать.
Получается, что после выбора/изменения номера счета плательщика надо проверить остаток на выбранном счете и сравнить его с суммой платежа; тоже самое надо сделать после ввода/изменения суммы платежа. И, в зависимости от соотношения (больше/меньше) остатка на выбранном счете и введенной суммы платежа, надо сделать кнопку "Сохранить" доступной или не доступной.

Как такое запрограммировать с применением конечного автомата?
Re[2]: Машина состояний
От: Sharov Россия  
Дата: 16.01.13 13:29
Оценка:
Здравствуйте, Qbit86, Вы писали:



Q>Причём фактически используются инструменты принципиально более сильные, чем теоретическая конструкция «конечный автомат», так что их часто называют «машина состояний».


А Вы не могли по подробнее раскрыть тему, желательно с сылками?
Кодом людям нужно помогать!
Re: Применимость конечных автоматов в GUI
От: LaptevVV Россия  
Дата: 16.01.13 14:43
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Есть диалог, в котором надо выбрать из плана счетов счет плательщика, ввести сумму платежа и разные другие параметры, а затем нажать кнопку "Сохранить".

А>По одному из требований бизнес-логики введенные параметры считаются корректными, если на выбранном счете плательщика есть остаток не ниже заданной суммы платежа.
А>Допустим, решено делать кнопку "Сохранить" доступной для нажатия (Enabled = true) только если вышеозначенное требование удовлетворено. Вопрос юзабилити (на сколько такое "молчаливое" поведение будет понятно пользователю) мы пока не рассматриваем, просто так решено и так надо сделать.
А>Получается, что после выбора/изменения номера счета плательщика надо проверить остаток на выбранном счете и сравнить его с суммой платежа; тоже самое надо сделать после ввода/изменения суммы платежа. И, в зависимости от соотношения (больше/меньше) остатка на выбранном счете и введенной суммы платежа, надо сделать кнопку "Сохранить" доступной или не доступной.

А>Как такое запрограммировать с применением конечного автомата?

Это два разных состояния автомата.
Если введенные данные корректны — переходим в новое состояние, где кнопка открыта.
Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?)
На диаграмме — это петля в вершине графа автомата (она же — диаграмма состояний в UML).
А вообще построение автомата надо начинать с рисования графа состояний...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Машина состояний
От: Tanker  
Дата: 16.01.13 15:28
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>По ссылке статья от студента некоего Шалыто (или иначе причастного). Судя по доступным в интернете статьям этой секты из ИТМО, ребята живут в каком-то своём, оторванном от нашей реальности мире, занимаются имитацией бурной деятельности, называют себя адептами «автоматного программирования» и на полном серьёзе считают, что двигают науку вперёд. Т.е. делают из вполне заурядного (в ремесле программиста) инструмента какой-то rocket science. Причём собственно science уже был сделан в середине прошлого века Хопкрофтом, Ульманом и прочими Ахо.


Я вот немного логики не понял, на основе наличия среди статей научпопа на тему автоматов ты сделал вывод про секту ? По моему из этого можно сделать вывод или о том, что тебе попадался только научпоп или что люди зарабатывают деньги научпопом.
Книга про автоматы у них просто отличная, студентам 2-3го курса просто обязательная к освоению.
The animals went in two by two, hurrah, hurrah...
Re[2]: Применимость конечных автоматов в GUI
От: Аноним  
Дата: 17.01.13 09:00
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Если введенные данные корректны — переходим в новое состояние, где кнопка открыта.

LVV>Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?)
Так в том-то и дело, что не понятно как в классическом конечном автомате (автомате Мура например) реализовать ветвление...

LVV>А вообще построение автомата надо начинать с рисования графа состояний...

Это само собой, просто я пытаюсь остаться в пределах классической модели конечного автомата, не вводя всякие узлы-разветвители.
И такое складывается впечатление, что пытаюсь натянуть противогаз на глобус... Причем глобус какой-то квадратный получается.
Просто я с универа (уже 10 лет прошло) как-то обходился без КА. "Традиционных" способов хватало.
А тут вдруг оригинальную идею встретил, решил попробовать, а гибкость мышления в направлении КА уже атрофировалась как-то.
Расширить модель всякими "отсебятинами" можно конечно, но это я на крайний случай оставляю.
Re[3]: Применимость конечных автоматов в GUI
От: LaptevVV Россия  
Дата: 17.01.13 09:38
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, LaptevVV, Вы писали:


LVV>>Если введенные данные корректны — переходим в новое состояние, где кнопка открыта.

LVV>>Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?)
А>Так в том-то и дело, что не понятно как в классическом конечном автомате (автомате Мура например) реализовать ветвление...
D автомате переход зависит от сигнала на ребре.
Вершина автомата — там вычисляется некая функция, которая выдает, например, true или false
Соответственно, либо переход, либо — нет
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Вода в решете
От: Tanker  
Дата: 17.01.13 11:32
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>По-моему, люди зарабатывают деньги профанацией. Они пишут горы пустых статей о ношении воды в решете, только называют это «инновационный метод транспортировки дигидрогена монооксида в ёмкости с перфорированным дном».


Покажи профанацию в виде ссылки, абзаца и тд.

Q>Не был бы так категоричен насчёт «обязательно». В мире есть и много других отличных книг, и даже курсы на Coursera, причём от первоисточников.


А на русском слабо показать, что бы не переводная была ?

Q>Я припоминаю исходную статью про SWITCH-технологию. Там в качестве образца их новейшей методики приводилась таки действительно switch-простыня на Си (для разбора какой-то строки, что ли), за которую в приличных конторах как минимум лишают премии, а в неприличных — коллеги устраивают «тёмную».


Статья, абзац, цитата ?
The animals went in two by two, hurrah, hurrah...
Re[6]: Вода в решете
От: Tanker  
Дата: 17.01.13 12:36
Оценка:
Здравствуйте, Qbit86, Вы писали:

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


Вобщем, все ясно, "мотороллер не его, он просто дал объяву" @ Выглядит так, как будто эти ребята тебе чего то прищемили
The animals went in two by two, hurrah, hurrah...
Re[3]: Применимость конечных автоматов в GUI
От: maxkar  
Дата: 18.01.13 14:42
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, LaptevVV, Вы писали:


LVV>>Если введенные данные корректны — переходим в новое состояние, где кнопка открыта.

LVV>>Если введенные данные не корректны — остаемся в том же состоянии (ведь изначально кнопка закрыта?)
А>Так в том-то и дело, что не понятно как в классическом конечном автомате (автомате Мура например) реализовать ветвление...

А насколько у вас классический автомат? Совсем простейший автомат не имеет никакой памяти. Т.е. "В поле Х введено А" и "В поле Х введено Б" — это разные состояния автомата (потому что иначе он их не отличит). Введение памяти (а вот у нас состояние St с контекстом <X=A>) заставляет усложнять механику автомата. Появляются guards на стрелках перехода, например, которые такой "автомат" разделяют обратно в "классический" автомат без памяти (точнее, в другую группу "склеенных" состояний).
Re: Применимость конечных автоматов в GUI
От: landerhigh Пират  
Дата: 18.01.13 17:56
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Доброго дня!

А>Натолкнулся случайно на здесь
Автор(ы): Александр Бабаев
Дата: 12.05.2006
Метод, представленный в статье, кардинально отличается от тех методов, которые применяются сейчас для создания логики пользовательского интерфейса. Он позволяет, в конечном счете, улучшить качество конечного интерфейса и его исходного кода, ускорить разработку и упростить поддержку. Метод основывается на подходе, активно пропагандируемом Анатолием Абрамовичем Шалыто и использует большую часть достоинств автоматного метода программирования.
статью, оценил оригинальность идеи, а потом попытался притянуть ее к реальной ситуации и кое-чего не понял.


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

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


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

А>Допустим, решено делать кнопку "Сохранить" доступной для нажатия (Enabled = true) только если вышеозначенное требование удовлетворено. Вопрос юзабилити (на сколько такое "молчаливое" поведение будет понятно пользователю) мы пока не рассматриваем, просто так решено и так надо сделать.

А>Получается, что после выбора/изменения номера счета плательщика надо проверить остаток на выбранном счете и сравнить его с суммой платежа; тоже самое надо сделать после ввода/изменения суммы платежа. И, в зависимости от соотношения (больше/меньше) остатка на выбранном счете и введенной суммы платежа, надо сделать кнопку "Сохранить" доступной или не доступной.

А>Как такое запрограммировать с применением конечного автомата?


Конечный автомат в данном случае представляет собой состояние формы, даже не всей формы, а кнопки "Сохранить". Выглядит такой КА примерно вот так


И, что самое смешное, реализуется этот автомат посредством установки SaveButton.enabled в true или false.
А вот уже сама проверка условий не входит в сферу ответственности КА и запихивать ее туда не надо, облом выйдет.
www.blinnov.com
Re[6]: Вода в решете
От: Qbit86 Кипр
Дата: 20.01.13 09:29
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Ну, вот эта статья, например.


Блин, я как раз завтракал, когда открыл так называемый исходный, прости господи, код в ПРИЛОЖЕНИЕ 1 и ПРИЛОЖЕНИЕ 2. Да там вся статья феерична, включая список литературы.
Глаза у меня добрые, но рубашка — смирительная!
Re[7]: Вода в решете
От: Privalov  
Дата: 20.01.13 09:53
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Блин, я как раз завтракал, когда открыл так называемый исходный, прости господи, код в ПРИЛОЖЕНИЕ 1 и ПРИЛОЖЕНИЕ 2. Да там вся статья феерична, включая список литературы.


Ну извини, я совсем не намеревался испортить тебе аппетит. Просто я когда-то пытался читать монографию "SWITCH-технология", ну и вспомнил, где искать примеры примерения этой технологии. А о книжке я как-то упоминал
Автор: Privalov
Дата: 27.07.11
. Приводимые в ней примеры кода не менее фееричны.
Re[6]: Вода в решете
От: landerhigh Пират  
Дата: 20.01.13 11:53
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Здравствуйте, Tanker, Вы писали:


T>>Статья, абзац, цитата ?


P>Ну, вот эта статья, например.


О, дайте мне это развидеть.

Разработка унитаза с улучшенной смываемостью по сравнению с ЭТИМ должна тянуть на пять Нобелевских премий по всем номинациям сразу.

Немного конструктивной критики — эта т.н. switch технология широко используется в автоматизации производственных процессов с 70-х годов во всевозможных PLC.
www.blinnov.com
Re[6]: Вода в решете
От: Tanker  
Дата: 20.01.13 20:12
Оценка:
Здравствуйте, Privalov, Вы писали:

T>>Статья, абзац, цитата ?


P>Ну, вот эта статья, например. А еще есть монография.


Нормальная статья для журнала по прграммированию, ничем не хуже тех что в рсдн магазин. Или профессор должен выдавать только нетленку ?
The animals went in two by two, hurrah, hurrah...
Re[6]: Вода в решете
От: Tanker  
Дата: 20.01.13 20:16
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Ну, вот эта статья, например. А еще есть монография.


Монография для 98 года нормальная. Идея свич-технологии не в автоматах, а в возможности программирования без программистов. Что там странного ?
The animals went in two by two, hurrah, hurrah...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.