Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 28 мар 2024, 15:12

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 7 ] 
Автор Сообщение
СообщениеДобавлено: 23 дек 2013, 14:20 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Из дискусии на компютерном форуме, затеянной анонимным автором.
Цитата:
Небольшое автобиографическое отступление.

Когда-то давно, пришёл я в одну контору по поводу работы. Тамошний шеф спрашивает меня, знаю ли я их программу. Отвечаю, что относительно. Шеф кривится, как мол так, программист должен знать всё! Ну, я ему начал про структуру ПО на компьютере, его взаимосвязи и что вряд ли он найдет человека, знающего всё. Смотрю, шеф то ли не понимает, то ли не верит, а скорее всего всё вместе.

Ладно, говорит, нам тут надо кое-что в этой программе поменять, сможешь? Надо посмотреть, отвечаю, но, скорее всего, вряд ли, если она для этого не приспособлена. Он опять: как так — есть программист, есть программа, почему первый не может починить вторую? Я опять про технологию программирования, про исходные и исполняемые коды и т.д.

В общем, не договорились мы тогда (не больно-то и хотелось). Теперь все стали умнее — мы так глупо не отвечаем, они таких глупых вопросов не задают.

Но много позже я подумал: а почему собственно? Почему я не могу сделать всего этого, что хочет от меня пользователь? Может это как раз тот случай, когда устами младенца (то бишь пользователя) глаголет истина?

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

В чём состоит это кризис, каковы его причины?

Сложно достаточно чётко и полно ответить на этот вопрос. Но очертить контуры попытаюсь.

Если проанализировать различные признаки этого кризиса, то можно сделать следующие выводы:

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

Она уже подошла к пределу возможностей мозга среднестатистического разработчика.

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

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

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

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

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

    — это приводит ко всё возрастающей потребности в программистах. Где-то я читал, что это одна из самых быстрорастущих по численности профессий. Но еще Брукс указывал, что при увеличении числа разработчиков сверх определенного предела управляемость проектом, и, следовательно, качество продукта падает ("мифический человеко-месяц"). Хотя это говорилось о группе разработчиков, но, похоже, это действительно и для всего программистского сообщества. Лет 15 назад Дж. Мартин, если не ошибаюсь, в одной из своих статей уже касался этого вопроса. Тогда он сравнивал ситуацию с разработкой ПО с ситуацией роста телефонизации в начале 20 века. Тогда пресса писала: ещё немного, и половина населения сядет за коммутаторы. Но этого не случилось — изобрели АТС. Вот и в сфере разработки ПО что-нибудь изобретут, и не надо будет всем становится программистами — на такой оптимистической ноте он заканчивал статью. Однако "воз и ныне там".

    — следующая, то ли причина, то ли следствие предыдущих причин. Программирование стало индустрией. Индустрия поглотила весь программистский контингент, несмотря на весь его рост, и требует ещё. Заниматься исследовательской работой, перспективой, похоже, стало некому. Даже в научной и университетской среде. То ли перестали вкладывать деньги в это дело, то ли заработки на коммерческих разработках не идут ни в какое сравнение, то ли не престижно стало этим заниматься, то ли все, как правоверные пользователи, решили, что и так все что надо, великий и всемогущий Microsoft сделает и ниспошлет. Причём не только у нас — с нами то всё ясно — но, похоже, везде.

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

Сайт, впрочем, стоит изучить — много интересного и дружественный нам по проблематике:
http://compact-programming.narod.ru


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 янв 2014, 08:42 
Не в сети

Сообщения: 25
Да, спасибо, сайт интересный. И вызывает некоторые практические вопросы:

1. Вполне согласен с п. Каковы пути выхода из кризиса? в упомянутой статье Бурьяка (на странице http://compact-programming.narod.ru/CP0031.htm). И вот можно ли сделать среду поддержки таких моделей? В теории, полагаю можно основываться на том, что обсуждалось в этой статье (даю выдержку для тех, кому лень регаться для загрузки вложений с того движка).
Вложение:
А логику построения уже давали, например, в п. 1.7 этой книги (дал бы выдержку, но дежавюшки не поддерживаются). Общая идея приводит примерно к тому же, что у Бурьяка здесь... и в Pure Builder.

Возможные варианты реализации представляются такими (множество м.б. неполно):
    * приложение отдельной ОС, работающее по такому принципу: http://sem-tech.net/forum/russian.aspx? ... 91#post691 (думаю, Бурьяк примерно то же имеет в виду, так ведь?);
    * самостоятельная операционная среда, рационализированная (допустим, по типу Оберон-ОС, примерно как Бурьяк и предлагает), поддерживающая приложения, исполняемые прямо или предварительно компилируемые из исходных текстов.

Получается, что функции редактора - вести и исполнять описания технологий, где исполнителями одних техопераций являются пользователи (в т.ч. когда они управляют машинами по указаниям в описаниях), других - машины, принимающие команды из описаний напрямую (как программируемые, так и чисто "железные" - главное, чтоб каналы связи с машиной, исполняющей редактор, были). Разумеется, у всех техопераций есть предмет труда - какие-то массивы данных. Вместе с описаниями технологий они образуют контент, с которым работаем в среде.
Оболочка редактирования (фактически - операционная среда АРМ) может увязываться с СУБД контента по тому же принципу, как Прохоренко предлагает: https://sites.google.com/site/purebuilder/#TOC-PureBuilder1. При этом употребляются открытые обменные форматы документов для сохранения в файлы, как-то:
    * научного текста полиграфического качества (TeX, LaTeX);
    * открытого документного стандарта (например, составного документа OpenOffice, XML);
    * стандарта межмашинного переноса (например, PDF, HTML).
В конкретной реализации редактора выбирается подмножество вариантов обмена. И соответственно круг приложений, работающих с БД. Внешних - сам редактор не делает контент (ну если только он оригинальный), а лишь организует его в модели решаемых задач. И в основном готовых - т.е. по возможности подбираются существующие приложения для работы с различными видами контента, и только пишется код поддержки управления ими из редактора (и обмена их с БД, если надо).

Функции среды дополнительно - компиляция с ожидаемых языков исходного текста приложений, исполнение, операции взаимодействия (файлы/порты), а также языки технологической алгоритмизации процессов. Причём они же используются как "языки управления заданиями" ОС, т.е. нет разницы в средствах сценаризации исполнения приложений и работы пользователей. И разработка/сопровождение ОС ведётся в ней же (для чего она пишется на "ожидаемом языке", например, на КомПасе). Аналогично в случае редактора - ОС внешняя, а все процессы ЖЦ редактора по его готовности в приемлемой версии переводятся в его же инсталляцию.

2. Может ли какая-то из сред, служащих предметом этого форума (XDev, ББ...), как полагаете:
    * быть использована для разработки такого редактора/операционки (на начальном этапе, а впоследствии - только как подчинённое приложение для компиляции с реализуемого языка) И/ИЛИ;
    * быть развита в такой редактор/операционку (соответственно уже с интегрированной компиляцией)?

Уточню ещё вот что:
    * понятие алгоритма использую в таком значении, как обсуждал прежде всего здесь: http://forum.oberoncore.ru/viewtopic.php?p=83926#p83926. Т.е. разница с программой в модели исполнителя (говорили также здесь, например, и здесь);
    * языки техноалгоритмизации - это не обязательно на схемной основе, обсуждаемой в статье. Форма записи м.б. и чисто текстовой, и на базе таблиц. Главное - что она воспроизводит одну и ту же структуру модели деятельности (как технологии, составляемой из техопераций, в т.ч. и динамически в зависимости от распознавания текущего состояния среды исполнения как одного из предусмотренных при описании деятельности).
Вообще условия применимости разных записей - самостоятельная тема. Её тоже можно было бы обсудить отдельно, но не знаю, насколько будет интересно участникам (мне лично их конструктивные мнения знать однозначно интересно)...


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 фев 2014, 10:03 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
Как то всё сумбурно и слишком обобщили. Отсутствует конкретика.

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

1. Есть только сборщик мусора. + Для производительности пытаются навернуть костыли.
2. Есть сборщик муcора но он опционален. new - gc, alloc и free. Можно как отказаться от GC, так и совместно использовать.

При полной высокоуровневости есть выбор, пользоваться ей или нет.

Нужна конкретика и примеры.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 фев 2014, 14:49 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
Как раз для совместного существования gc и alloc free, есть такая штука как деструктор. Который автоматом освобождает память, и не трогает тормозной gc. Такой совместной техникой, можно найти золотую середину.

Да, всё это расширизмы и партизанщина. :)


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 фев 2014, 18:39 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Куда ж без них родимых. ;)

Я придумал для XDev такой механизм. Память выделяется как обычно с помощью NEW. Но есть явная процедура для её освобождения, которая может выглядеть, например, так:
Код: "OBERON"
  1. PROCEDURE DISPOSE* (VAR mem: SYSTEM.PTR); (* Системный тип Ofront'а - любой указатель *)
  2. BEGIN
  3. (* Здесь может быть free(mem) если сборка мусора не используется: *)
  4. IF ~RTS.GCused THEN RTS.free(mem) END;
  5. mem := NIL;
  6. END DISPOSE;
А дальше можно выбирать в опциях проекта: используется сборка мусора или нет. Но вспомните зачем вообще всё это было нужно. Сборка мусора для многих (не исключая меня) — тёмная шаманская штука, и в ней ещё не сказано последнее слово, нужно исследовать вопрос. Я где-то читал, что она замедляет работу не более чем на 1-2%. А если ещё алгоритмы усовершенствовать?

Сборка также может применяться и для задач реального времени. Соответствующие Оберон-технологии есть. Так что, мне кажется, сборка мусора — вещь хорошая в умелых руках. А злоупотреблять можно чем угодно и без неё. Той же динамической типизацией, например. Очень знатно хоронит производительность, как я слышал.

Проблемы производительности динамических языков типа Java проявляются не только в сборке мусора. Как насчёт чисто динамических данных и только виртуальных методов вместо статических данных и процедур? Я уже не говорю о виртуальной машине, которая способна замедлить исполнение по сравнению с нативом в десятки и сотни раз. Особенно это заметно на таких платформах как Java ME и Android. Но если проблема маскируется под норму и на более мощных платформах, то зачем нам с этим мириться и делать вид что всё в порядке?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 фев 2014, 19:26 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
Zorko писал(а):
А дальше можно выбирать в опциях проекта: используется сборка мусора или нет. Но вспомните зачем вообще всё это было нужно. Сборка мусора для многих (не исключая меня) — тёмная шаманская штука, и в ней ещё не сказано последнее слово, нужно исследовать вопрос. Я где-то читал, что она замедляет работу не более чем на 1-2%. А если ещё алгоритмы усовершенствовать?


Как и у любой шаманской штуки есть описание.

Производительность режется по разному.

Примеры GC в системах реального времени.

В любом случае, требуется некоторое количество соглашений и ограничений. GC далеко не бесплатен. Всё в меру, всё к месту.

Zorko писал(а):
Проблемы производительности динамических языков типа Java проявляются не только в сборке мусора. Как насчёт чисто динамических данных и только виртуальных методов вместо статических данных и процедур? Я уже не говорю о виртуальной машине, которая способна замедлить исполнение по сравнению с нативом в десятки и сотни раз. Особенно это заметно на таких платформах как Java ME и Android. Но если проблема маскируется под норму и на более мощных платформах, то зачем нам с этим мириться и делать вид что всё в порядке?


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

Ещё очень важный момент. Компиляция Java в памяти. Код компилируется и выполняется. Тот же натив.

Я загружал игру freecol, ремэйк игры colonization, той старой под dos. Графика новая, выглядит цивильнее. Написана на Java, соответственно тормозит. Но ещё нужно попробывать, настроить саму java, возможно можно ускорить.

С Java не так просто, это не чисто интерпритируемый язык. PHP, JS можно поливать говном. Но даже зная их недостатки, на них проще делать сайты, ничего не попишешь. Ещё раз напомню, об онлайн компиляторе на сайте оберспэйс. Всё тот же оберон, но транслируется в js.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 фев 2014, 20:44 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
В большинстве случаев НЕ использование GC(если он есть), преждевременная оптимизация. Обычно с GC борятся, когда тормозит, и нужно ускорить это и в C# есть. По сети можно найти, 102 способа, как ускорить GC.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 7 ] 

Часовой пояс: UTC + 2 часа


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

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


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club