Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 14:58

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу 1, 2, 3, 4, 5 ... 9  След.
Автор Сообщение
 Заголовок сообщения: Статья: Прототипирование программ как стихийный подход...
СообщениеДобавлено: Пт ноя 19, 2010 13:49 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Прототипирование программ как стихийный подход к программированию и анализ эволюционной модели быстрого прототипирования применительно к программированию на Форте

Введение
«Г-н Журден. Честное слово, я и не подозревал, что вот уже
более сорока лет говорю прозой» Жан-Батист Мольер. Мещанин во дворянстве


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

Преимущества структурной эволюционной модели быстрого прототипирования
    Конечный пользователь может «увидеть» системные требования в процессе их сбора командой разработчиков; таким образом, взаимодействие заказчика с системой начинается на раннем этапе разработки

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

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

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

    Модель представляет собой формальную спецификацию, воплощенную в рабочую модель

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

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

    Возможность возникновения разногласий при общении заказчиков с разработчиками минимизирована

    Ожидаемое качество продукта определяется при активном участии пользователя в процесс на ранних фазах разработки

    Возможность наблюдать ту или иную функцию в действии пробуждает очевидную необходимость в разработке функциональных дополнительных возможностей

    Благодаря меньшему объему доработок уменьшаются затраты на разработку

    Благодаря тому, что проблема выявляется до привлечения дополнительных ресурсов, сокращаются общие затраты

    Обеспечивается управление рисками

    Документация сконцентрирована на конечном продукте, а не на его разработке

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

Недостатки структурной эволюционной модели быстрого прототипирования

Субъективная оценка автором степени существенности недостатка помечена цветом. Ниже дан комментарий.
Модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о «разработанном на скорую руку» методе
Недостаток явно несущественен, поскольку в форт-сообществе не наблюдается консерваторов такого рода.

Разработанные «на скорую руку» прототипы, в отличие от эволюционных ускоренных прототипов, страдают от неадекватной или недостающей документации

Крайне актуальный недостаток, который устраняется в считанных вариантах форт-систем.

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

Достаточно актуальный недостаток в настоящее время. Более того, хакерский код регулярно приветствуется в Форте в противовес хорошо проработанным решениям с известными характеристиками. Существуют точки зрения, обосновывающие допустимость хакерских решений исключительными особенностями Форта и элитарностью языка.

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

Ни «качеству всего ПО», ни «эксплуатационной надежности» в стихийном прототипировании не уделяется вообще никакого внимания. Критерии качества не имеют сформулированных метрических показателей (исключение – «прохождение теста на ANSI»), эксплуатационная поддержка осуществляется нестабильно, на основе багрепортов. Характерна реакция вида «эта реализация Форта имеет открытые исходные тексты, значит, заметивший ошибку пользователь должен исправить ее и отправить авторам исправленную версию».

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

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

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

Недостаток проявляется ограниченно. Пользователи разрабатываемых форт-систем участвуют в их развитии ограниченно, не существует однозначного механизма реализации обратной связи – подходящие замечания могут включаться в список будущих исправлений, тогда как неподходящие игнорируются. Формулирование требований фортерами-пользователями также неоднозначно, смешиваются требования к эксплуатационным характеристикам форт-системы и к способам достижения этих характеристик, т.е. фрагментам кода и техническим решениям.

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

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

Несовпадение представлений заказчика и разработчиков об использовании прототипа может привести к созданию другого пользовательского интерфейса.

Существует как минимум три варианта использования Форта – консольное приложение, оконное приложение, системная служба/подключаемая библиотека. Вопросы адаптации интерфейса к целевой ОС слабо зависят от используемого языка, и в Форте проработаны неравномерно.

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

Недостаток не является существенным, поскольку в данном случае предпочтения заказчика могут основываться на его желании самостоятельно доработать продукт, осознавая его незавершенность.

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

Как правило, неактуально вследствие того, что разработка финальной версии ведется с помощью тех же инструментов, что и прототипа

Прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл «кодирование – устранение ошибок» (code-and-fix cycle), что приводит к дорогостоящим незапланированным итерациям прототипирования

Крайне существенный негативный фактор, тормозящий развитие способностей программиста к самоорганизации. Фортеры имеют тенденцию к пренебрежению организационными мероприятиями, противопоставляя им «открытость» и «гибкость» языка. Это приводит к насыщению восприятия разработчика и торможению проекта на уровне, когда он еще может быть удержан в «операционном поле» одного человека.

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

Важный недостаток, подтверждаемый крайне недостаточной документированностью многих реализаций Форта. Необходимость документирования часто противопоставляется «гибкости» и «расширяемости», а также наличию исходных текстов. Распространение исходных текстов может способствовать фиксации текущего решения, и разработчики попадают в цикл бесконечной модификации распространяемых текстов.

Когда заказчики, удовлетворенные прототипом, требуют его немедленной поставки, перед менеджером программного проекта возникает соблазн пойти им навстречу.

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

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

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

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

Если заказчики программ на Форте являются пользователями Форта, они, как правило, существенно вовлечены в процесс разработки.

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

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

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

Недостаток является существенным. В определенной степени, Форт сам по себе является языком, демонстрирующим способности программиста. Поэтому он провоцирует использование неуместных приемов программирования, которые демонстрировали бы исключительность Форта, вне зависимости от того, помогают ли эти приемы достижению эффективных результатов.

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

Данный недостаток лежит в основном в организационной области и мало соотносится со свойствами языка программирования.

Итоговый анализ недостатков дает следующую статистику:
Несущественных – 6
Неопределенной степени важности - 3
Существенных – 9

В конечном итоге можно сделать вывод, что стихийный подход к программированию на Форте, выражающийся в использовании (по факту) модели эволюционного прототипирования, имеет более 50% существенных недостатков, что и затрудняет разработку качественных программных продуктов. Для повышения качества разработки (имея в виду не код, а процесс выпуска программного обеспечения в целом) следует либо обратить особое внимание на устранение рассмотренных недостатков, либо использовать другие модели жизненного цикла, смягчающие остроту проблем.

Литература:
1. Фатрелл Р.Т., Шафер Д.Ф., Шафер Л.И. — Управление программными проектами



За это сообщение автора Hishnik поблагодарили - 2: dynamic-wind, mOleg
Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Пт ноя 19, 2010 18:48 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
Я считаю, что на современном этапе развития индустрии ПО, Форт утратил актуальность как язык программирования. Скорее всего его можно рассматривать, как классический алгоритм, на одном уровне с двоичными деревьями, списками и т.д., подлежащими изучению.

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Пт ноя 19, 2010 19:33 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июн 25, 2009 11:12
Сообщения: 412
Благодарил (а): 41 раз.
Поблагодарили: 8 раз.
Цитата:
Простота Форта необоснованно принимается за простоту разработки программ на нем как таковых, независимо от степени сложности решаемой задачи. Компактность реализации и возможность расширения синтаксиса также необоснованно принимаются за способ кардинально уменьшить трудоемкость любой разработки, независимо от возможного наличия в ней объективно высокой алгоритмической сложности, не зависящей от используемого языка.
...........
Поэтому он провоцирует использование неуместных приемов программирования, которые демонстрировали бы исключительность Форта, вне зависимости от того, помогают ли эти приемы достижению эффективных результатов.

Всем фанатам форта распечатать, и на стенку перед собой. :<


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Пт ноя 19, 2010 20:50 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
Цитата:
Простота Форта необоснованно принимается за простоту разработки программ

Если кто-то считает форт простым, то этот кто-то пока еще не фортер.
В качестве инструмента для массового программирования форт не годится - это
правда. Во-первых сложен, во-вторых не имеет развитой инфраструктуры в силу опять таки достаточно узкого круга фортеров, не заинтересованных реально в широком распространении форт-подхода к программированию.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Пт ноя 19, 2010 21:11 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июн 25, 2009 11:12
Сообщения: 412
Благодарил (а): 41 раз.
Поблагодарили: 8 раз.
chess писал(а):
Если кто-то считает форт простым, то этот кто-то пока еще не фортер.
В качестве инструмента для массового программирования форт не годится - это
правда. Во-первых сложен, во-вторых не имеет развитой инфраструктуры в силу опять таки достаточно узкого круга фортеров, не заинтересованных реально в широком распространении форт-подхода к программированию.

Уныло... нас мало, но мы в тельняшках.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Пт ноя 19, 2010 21:41 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
dynamic-wind писал(а):
Уныло... нас мало, но мы в тельняшках.

Это нормально. Многие-ли работают на К или даже на J и т.д. и т.п. - примеров много можно найти. А тельняшки давно уже тут лишние.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Сб ноя 20, 2010 01:06 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
mgw писал(а):
Я считаю, что на современном этапе развития индустрии ПО, Форт утратил актуальность как язык программирования. Скорее всего его можно рассматривать, как классический алгоритм, на одном уровне с двоичными деревьями, списками и т.д., подлежащими изучению.

А ведь это очень важно. Много ли языков могут считаться алгоритмами? Если Форт рассматривать в таком ракурсе, вопросы распространенности трансляторов отходят на второй план.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Сб ноя 20, 2010 01:19 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
chess писал(а):
Если кто-то считает форт простым, то этот кто-то пока еще не фортер.

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

А зачем его распространять-то? Чтобы окупить вложения в разработку? Так это банальный коммерческий проект. И уже очень-очень долгое время этот барьер пытаются штурмовать, с неизменно отрицательным результатом. Потому что mgw очень своевременно отметил, что Форт - это явление, подобное алгоритмам. Его надо применять для решения других задач, имея к этому склонность, а не пытаться вбросить в массы. Там нечего вбрасывать, сам Форт прост, но его простота влечет за собой богатейшие возможности, которые надо осваивать. Вот процесс освоения, а также развитие культуры программирования и организации работ - это и есть то, чего не хватает для повышения эффективности труда фортеров.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Сб ноя 20, 2010 10:44 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
Хищник писал(а):
Вот процесс освоения, а также развитие культуры программирования и организации работ - это и есть то, чего не хватает для повышения эффективности труда фортеров.

Этого не хватает наверное не только фортерам, но для массовых языков по крайней мере есть обширная литература, преподаватели и прочая инфраструктура.
В форте этого нет и не будет. Форт принимает своих пользователей по принципу наема
гастарбайтеров: белорусов, украинцев на работу посложней, а остальных- на попроще. :)

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Сб ноя 20, 2010 10:52 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Цитата:
В форте этого нет и не будет.
Я же говорил, депрессивные выводы


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Сб ноя 20, 2010 13:25 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
chess писал(а):
Хищник писал(а):
Вот процесс освоения, а также развитие культуры программирования и организации работ - это и есть то, чего не хватает для повышения эффективности труда фортеров.

Этого не хватает наверное не только фортерам, но для массовых языков по крайней мере есть обширная литература, преподаватели и прочая инфраструктура.

Литература существует не для языков, а для программистов. Хватит уже прятаться за элитарностью - это прекрасная иллюстрация к написанному мной. Дескать, мы бы и поучились, но Форт такой необычный, для него, наверное, и методы организации работы другие. Нет, не другие!
chess писал(а):
В форте этого нет и не будет. Форт принимает своих пользователей по принципу наема
гастарбайтеров: белорусов, украинцев на работу посложней, а остальных- на попроще.

Это откуда такая чушь?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Вс ноя 21, 2010 18:20 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Другие модели будем рассматривать? :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Вс ноя 21, 2010 19:36 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Хищник писал(а):
Другие модели будем рассматривать? :)

даже странно, что не рассмотрены


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Вс ноя 21, 2010 19:47 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
вопрос писал(а):
даже странно, что не рассмотрены

Вообще говоря, рассмотрение моделей - не совсем тривиальная нагрузка. Их еще пять, я просто физически не могу дать развернутый анализ за день-два.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Прототипирование программ как стихийный подход..
СообщениеДобавлено: Пн ноя 22, 2010 17:54 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
chess писал(а):
Если кто-то считает форт простым, то этот кто-то пока еще не фортер.


Простым кажется то что хорошо известно. Фортер должен хорошо знать устройство
форт-системы. Иначе, это не фортер, а пользователь форт-системы.

chess писал(а):
В качестве инструмента для массового программирования форт не годится


Чем обусловлено?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу 1, 2, 3, 4, 5 ... 9  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB