INT>Насколько интересно (перспективно) исследование в сторону технологий и языков для такого рода проектов (частично или полностьб opensource)?

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

Но Open Source в первую очередь написан на C++/C, в которых метаданные отсутствуют напрочь.

Также у скриптов в open source очень узкая ниша, и сильная конкуренция с нормальными языками.
Если деплоятся бинарники, то для того, чтобы пользователь мог сделать небольшие программные вставки, приходится делать поддержку скриптов.
Если деплоятся исходники, то для таких мелких ставок, проще напрямую редактировать исходники.

ps
Людям нужны дырки диаметром 5 мм, а не сверла диаметром 5 мм.

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

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

INT>Но теперь надо общаться не с человеком, а с другими программами. А они на ЕЯ не понимают...
Есть хорошие слова, сказанные в другое время и по другому поводу, но если их перевести на компьютерную тематику, то получится примерно так: Есть большая разница между программами, которые работают для тебя, и которые работают при тебе, обращая на тебя внимания не больше чем на устаревшую перефирию.

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

Когда-то одну программу писал как правило один человек. Потом программы стали больше и стали писаться командами — появились правила программирования, ориентированные на командную работу. Сейчас по идеологии XP кроме программистов в создании программы учавствует заказчик.

Следующая стадия (которая фактически началась уже давно): в написании программы (в том числе и кода) учавствует вообще кто угодно. Причем далеко не обязательно программисты. Во все серьезные продукты встраивается механизм скриптования для того, чтобы пользователь мог "дописать" его под свои нужды.

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

Насколько интересно (перспективно) исследование в сторону технологий и языков для такого рода проектов (частично или полностьб opensource)?

Идея предоставить пользователю возможность написания скриптов не нова. Она возникла, развилась, была реализована и умерла. Пример 1С — тому подтверждение. Изначально предполагалось, что бухгалтер что-то сможет подправить сам. Однако практика расставила всё по местам.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Идея предоставить пользователю возможность написания скриптов не нова. Она возникла, развилась, была реализована и умерла. Пример 1С — тому подтверждение. Изначально предполагалось, что бухгалтер что-то сможет подправить сам. Однако практика расставила всё по местам.

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

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

INT>>Насколько интересно (перспективно) исследование в сторону технологий и языков для такого рода проектов (частично или полностьб opensource)?

DG>Есть конфликт между потребностями и технологиями.
DG>Для легкого и быстрого подключения скриптов к программе — нужны развитые метаданные.
...
DG>Людям нужны дырки диаметром 5 мм, а не сверла диаметром 5 мм.

Т.е. есть конфликт и есть проблема для исследования? Так это то мне (дя кандидатской) и нужно

INT>Т.е. есть конфликт и есть проблема для исследования? Так это то мне (дя кандидатской) и нужно

Смотря, что тебя интересует — процесс или результат?

Если процесс — то да, все прекрасно — есть большое поле для исследования.
Если результат — то увы, есть очень высокая вероятность, что хорошего результата не будет.

INT>>Т.е. есть конфликт и есть проблема для исследования? Так это то мне (дя кандидатской) и нужно

DG>Смотря, что тебя интересует — процесс или результат?

DG>Если процесс — то да, все прекрасно — есть большое поле для исследования.
DG>Если результат — то увы, есть очень высокая вероятность, что хорошего результата не будет.

По крайней мере, есть шанс получить что-то новое и полезное

Народ, скажите что нибудь, мне завтра надо научруку объяснить так, чтобы он проперся

INT>В процессе курения моего предыдущего топика возникла мысль, что для изучения стоит взять технологию написания opensource проектов.

Open Source и скриптование? Честно говоря, связи кажутся притянутыми за уши.


По поводу Open Source можно что-то исследовать, но тогда, пожалуй, придётся переквалифицироваться в историки. Потому что большинство перипетий и краеугольных камней тут скорее в области человеческих взаимоотношений и исторических коллизий. Кто кого в документации забыл упомянуть, кто в доме главный, как называть переменные. По большому счёту не очень это ценное исследование.

Тенденция, которая якобы привела к скриптам тоже какая-то неубедительная. Да по моему они сами возникли, скрипты-то. А то, что они встроены в большую систему — это круто, это правильная идея. Но тенденции той, которую ты продвигаешь я лично здесь не вижу. Что, к примеру, по этой идеологии может происходить дальше? Непонятно.

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

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

Чудные слова говорите товарисч, с 95 года занимаюсь саппортом, ни одного такого юзверя не нашел. Ни один бухгалтер или клерк никогда не полезет в VBA надолго, хотябы потому, что объем стартовой информации достаточно велик, для их слабого восприятия. Самых продвинутых из них с трудом удается научить ваять примитивные макросы, но не более.

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

INT>Следующая стадия (которая фактически началась уже давно): в написании программы (в том числе и кода) учавствует вообще кто угодно.
Кто угодно запросто порождает что угодно, в том числе и лажу. Даже у opensource проектов есть своя команда программистов. Задача этих людей фильтровать все исправления и дополнения, для обеспечения целостности проекта. Правда никто не мешает взять за основу релиз чужого проекта и начать перелопачивать его по своему, но это уже другая история.
INT>Причем далеко не обязательно программисты. Во все серьезные продукты встраивается механизм скриптования для того, чтобы пользователь мог "дописать" его под свои нужды.
Не всегда хорошее решение. Это может дать повод, для долгой и счастливой жизни такого проекта, так и обеспечить хронический геморрой программистам сопровождения.
Пожалуй интересно былобы разобраться вот в чем: С какой стороны подходить к анализу предметной области, чтобы скриптовой язык не был перегружен, при этом обеспечивал решение всех задач, которые могут возникнуть в процессе сопровождения такой системы.

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

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

А>Чудные слова говорите товарисч, с 95 года занимаюсь саппортом, ни одного такого юзверя не нашел. Ни один бухгалтер или клерк никогда не полезет в VBA надолго, хотябы потому, что объем стартовой информации достаточно велик, для их слабого восприятия. Самых продвинутых из них с трудом удается научить ваять примитивные макросы, но не более.

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

Господа, вам не кажется, что мы до сих пор программируем только на ассемблере с макросами и в том же текстовом редакторе с прибамбасами? Разные языки отличаются только набором макросов. А процесс точно тот же — описываем не то, что, а то, как.

Сейчас мы дрейфуем от общения человек-программа к общению программа-программа. Все эти API, COM, CORBA, .NET, TCP/IP, ODBC и т.д., словом, все, что мы пишем в резюмах — это технологии общения программы с программой. Технологии общения программ на ассемблере.

Мы называем себя программистами потому, что умеем писать на разных диалектах макроассемблера — бейсиках, сях, смолтоках. Мы занимаемся созданием работы друг для друга. Это все имело смысл, пока мы писали stand-alone программы, которые с грехом пополам и с помощью ЕЯ могли объяснить человеку, как с ними обращаться. Но теперь надо общаться не с человеком, а с другими программами. А они на ЕЯ не понимают...

ИМХО решением является совмещение искусственно разделенных частей. Например, документация должна совпадать с программой. Т.е. процесс написания программы и документации к ней сведется к созданию одного документа, который может быть 1. Сконвертированным в ЕЯ. 2. Запущенным как программа. 3. Прочитанным другой программой.