Почему Форт
Ответить на этот вопрос меня заставил знакомый, которому я рассказывадл о своем увлечении. Итак, зачем прикладному программист Форт? Язык, который малоизвестен, можно сказать даже больше – неизвестен, с интерсным, непривычном синтаксисом?.
Фактор извстности очень значительный – он определяет такие вещи, как востребованость ваших знаний языка; наличия уже готовых решений; выбор языка кодирвоания для проекта ну и т.д.
Так вот фактор известности, фактор поддержки языка для прикладного программиста, не настолько важен. Дабы внести ясность, определю что имеется ввиду под прикладным программистов. Это человек, который прекрасно знает предместную область, видит проблему, может ее формализовать, поставить задачу и найти ее решение. Но которому в силу причин объективной ограниченности ресурсов, не до детального кодирования. Это для них создают макроязыки и прочий васокоуровневый мусор. Да, я так могу говорить, потому что с этим сталкиваюсь. Потому что каждый язык реализует те или иные абстрактные конструкции. Хорошо или плохо – это другйо вопрос. Основной в том, что задачу нужно укладывать именно в эти конструкции. Даже больше, в особенности реализации этих конструкций. В итоге, получаем упрощение кодирования только для определенного класса задач. А, вообще, получаем нагромождение кода. Доказательств приводить не буду – и так об этом говорят на каждом углу.
Еще одно замечание, может показаться, что я здесь смешиваю постановщика задач (или аналитика, если хотите) с кодировщиками. На самом деле нет – когда решение указано, его реализация это механическая задача. Реализация которой это вопрос механизации. Яркий пример – организация работ в конструкторских бюро. Пока были кульмана, ватман, карандаш и бумага было и разделение на собственно конструкторов и чертежников. Первые решали поставленные задачи, вторые оформляли решение. Как только появилась возможность полностью автоматизирвоать процесс оформления (специализированные пакеты черчения на персоналках), потребность в чертежниках отпала. Точно так же и в программировании – как только постановщик задач найдет подходящий интсрумент, он откажется от услуг кодировщика.
Теперь понятно, что в итоге пользователями будет востребована не ОС, не язык программмирования, а реализация решения их проблем. А реализацию делает прикладной программист.
А прикладному программисту нужен инструмент. У каждого из нас есть представление об идеальном инструменте, который бы мы бы хотели видеть, найти. И распространненость его занимает в списке поеланий далеко не самую верхнюю строчку.
Дальше, чтобы не лить много воды, опишу что я хочу видеть в своем идеальном инструменте, с некими комментариями.
- предельно простой синтаксис. Понятно? Я не хочу тратить время при отладке на выяснение где я ошибся в синтаксисе. Я не хочу изучать синтаксис. Это время. Это усилия. Я не хочу тратить время на конструирование синтаксических конструкций языка. Я ленивый :) Я эгоистичный, я хочу думать о своей задаче.
- естественная расширяемость. Тоже просто, вытекает из предыдущего пункта, нет желания отслеживать зависимости, прописывать что подключать, пути вызовы ну и т.д.
- лаконичность. Это очень важно. Я хочу найти лаконичные конструкции, некие кубики, компонуя которые я получаю требуемые мне объекты. Нет, я не хочу обилия объектов. Нет! Я просто хочу компактность, стройность идеологии системы. Время подбора компонента, время на его изучения и ... и все равно в часто используемом арсенале останется не большоен количество конструкций, возможностей языка. Мне не хочется чтобы продуманность средства подменялось свалкой всего на свете на некие случаи жизни....
- компактность системы. Это уже следствие предыдущего пункта. Ну не может продуманная, стройная, лаконичная система быть огромной. У нее и документация компактна, читается быстро. И система изучается быстро – понял принципы на которых она построена, принял их и система понятна. Еще свойство компактной системы, при необходимости можно самостоятельно решить проблему по ее развитию и поддержки (Это не только то, о чем вы подумали. Есть разные способы. Когда сталкнетесь – найдете или подскажут).
- Самодостаточность системы. Т.е. если мне нужно что-то сделать чего еще не реализовано в системе то я должен иметь возможность сделать это в самой системе, без особых ухищрений! Ни один скриптовый язык такими возможностями не обладает, они все написаны на языках более низкого уровня, чаще всего С. И если мне что-то нужно, то или приходиться извращаться на самом языке, или стряпать на С или ... Вообщем, возникает очередная проблему, на решение которой тратится время. Ой, про компонентный подход тоже не надо. Сыт.
- Условия лицензирования. Ага! Так как я делаю ставку на эту систему, я не хочу становиться заложником решений правообладателя. Я вкладываю определенные свои интелектуальные ресурсы и я хочу быть уверенным в том, что я смогу и дальше их использовать. Нет, я не говорю о тех поддержке, я говорю о лицензирвоании! Да, я хочу быть собствнником той инструментальной системы с которой я работаю, без временных и пространственных ограничений. Именно поэтому меня привлекают продукты под лицензией LGPL и BSD – я могу создавть продукты как с открытым кодом так и не открывать его. И я согласен с требованиями этих лицензий указывать авторство применяемых компонентов в сторонних разработках.
- Переконфигурирование. Мне хочется иметь возможность компоновать систему, оптимизируя ее под конечное решение. Это должно допускать как сама система так и политика лицензирования. Мне хочетяс иметь возможность получать готовый продукт как в бинарный, полностью скопмлированный и собранный объект, так и в форме открытых исходных кодов.
- желательна интерпретируемость, особенно на этапах разработки, макетирования и отладки. И в тоже время иметь возможность компилировать и оптимизирвоать в целях повышения быстродействия конечной версии.
- Кроссплатформенность. Понятно, что это некоторая абстракция. Но сознание того факта, что система перенесена или может быть перенесена с незначительными усилиями на другую ОС, все же приятно...
Вот такой краткий список пожеланий. Того чего мне хочется. На самом деле пожеланий еще больше. Но это основные. И я считаю что Форт может стать претендентом на эту должность. Он овтечает практически всем требованиям. Он компактный, простой синтаксис, быстрый, интерактивный, существует множество реализаций трансляторов, стандартизован. В нем заложены красивые и мощные идеи. Его ядро обозримо, и оценосчная его трудоемкость создания не более 1 человеко-месяц.
Вот примерно, такие причины меня и побудили начать его изучать. Мир, конечно, не идеальный, не все в выбранном мной траснслятора меня устраивает, да и к языку привыкнуть нужно. Но уже сейчас замечаю, что он оказывает положительное влияние на мою профессиональную деятельность.
Copyright © Alex Furashev 2004
При цитировании, ссылка на оригинальный текст обязательна.
Допускается копирование материалов только целиком, без внесения каких-либо изменений
в оригинальный текст, меняющих смысл, структуру материала и проч.
|