OberonCore

Критика оберона опирается на утверждения, что:
1. Поскольку язык лаконичный (примитивный), то выражение программных конструкций в исходных текстах получается более многословным.
2. Поскольку язык непопулярный, то приходится многажды "изобретать велосипеды", что опять же якобы приводит к распуханию исходников.

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

Для оценки можно использовать следующие статистические параметры:

1. Общее время использования среды программирования. Среда программирования тут рассматривается как приспособление для создания программных текстов. Под использованием среды программирования подразумевается любая активность в среде - перетаскивание окон, кликанье мышкой, сохранение-открытие документов и т.п.

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

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

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

Я думаю, что набирание статистики возможно организовать как из среды BlackBox, так и из других сред программирования. Можно вывести даже некий индекс как отношение объёма текста к общему времени работы в среде. Если майнстрим настолько хорош, как его малюют, то преимущество популярных инструментов будет очевидно - времени потрачено мало, а набрано много. Или же набрано не очень много, зато нажатий почти нет. Ну и так далее.

Как вам идея? Покритикуем?

Нужно обмерить Оберон и конкурентов метриками. Например, метриками Холстеда. Свердлов хорошую методу предложил по измерению сложность: мерить объем грамматики в самых разных разрезах.
Можно обмерить типовые структуры данных в реализации на Обероне и, например, на С++.
При этом еще как-то надежность надо обмерять. Кроме статистики тут ничего не пойдет?

Про метрики Холстеда я уже думал. Ещё бы, конечно, вести подобные статистики с разбивкой по проектам, тогда можно получить усреднённое время реализации проекта. На достаточно больших периодах, можно даже приблизиться к каким-то нормам, независимым от среды и языка. Волонтёры статистику могут вести вообще в фоновом режиме, в BlackBox это сделать несложно. Результаты отсылать куда-нибудь в Центр.

P.S. Вообще, мне думается, что такой "мониторинг программиста" поможет избавиться от сугубо субъективных оценок и смотреть именно на то, как просто\сложно реализовывать задачи. Для этого нужны параметры, независимые от языка\среды, но фиксирующие как раз труд программиста.

Эти параметры изложены в стандартах по качеству ПО.
Лично я этим делом собрался заняться очень плотно после докторской. То есть примерно через год. К тому времени и статистика подоспела бы...

Мне кажется, что оценка качества ПО исходит все же из другой модели, нежели оценка инструмента разработки.

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

Критика происходит из отрицания того, что основное назначение кода - для Человека, а не для Компьютера.
Говорят все, что угодно - а в голове именно это.
И все следует именно из этого. Пока нет согласия по этой основной позиции - сто лет спорить с пеной у рта можно.
Вспомните Педсовет

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

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

Пора переходить от философии к цифрам Объём грамматики по Свердлову хорош, но не хватает фактора времени.

А время можно оценить только на практике. Посадить две команды с ОДИНАКОВЫМ опытом на одну задачу. кто быстрее и напишет. И где меньше ошибок. И где текст короче. У нас есть две такие команды? Или хотя бы два человека?
Хотя можно Ермакова попросить, мож двух студентов подбросит. Только их нужно обоих одинаково научить и ББ+КП и С++ + дотнет.

Тогда уж команды должны не только писать код, но и читать его после этого. И важным условием должно быть то, что читающий человек не участвовал в написании кода (эмулируется ситуация, когда к коду возвращаешься спустя долгое время и он настолько забыт, что воспринимается как чужой). И на основе чтения можно будет судить - для Человека писался код или для Машины.

Вот цена этого "одинаково" и есть искомая мера.

Надо, конечно, сильно думать, чтобы правильно проинтерпретировать такие цифры. Но вообще интересно.

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

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

Без реального мониторинга любую меру можно оспорить. Дело же не в метриках, а в их интерпретации. Метрики можно посчитать какие угодно. Но важно сопоставить числовые характеристики с субъективным человеческим восприятием. Например, посчитали мы метрики Чидамбера-Камерера или Лоренца и Кидда. Ну и что? Должен быть вывод: при таких значениях метрик получается хорошая модифицируемость проекта, а при таких - нет. А такой вывод можно сделать только на основе конкретного реального опыта. То есть опыта эксперта. Тут в полный рост приходится оперировать неточной-неполной информацией.
Мой аспирант в диссере предложил подход к оценке такого рода информации: нечеткие нейронные сети Ванга-Менделя. Но! Сначала ему пришлось ограничиться классом задач и инструментария. Он, естественно, рассмотрел дотнетовские ООП-системы, написанные на додиезе, так как сам был начальником отдела АСУ и сам это все писал.
Далее ему пришлось анализировать массу проектов и на основании своего ЛИЧНОГО опыта сопоставлять: проекты с такими-ито значениями метрик лучше поддаются модификации, чем вон те. А дальше уже обучать сеть и обрабатывать новые проекты.
Так что с метриками ПО - все достаточно сложно.
Холстед мне нравится потому, что он использует только статистику ТЕКСТА. И это дает кое-какую ОБЪЕКТИВНУЮ информацию. Мож в лингвистику залезть глубже надо и там поискать?
Но опять же - нужног усреднять по большому массиву текстов в обоих вариантах.

Показатель модифицируемости здесь только в качестве примера.

А вот не "и ладно", а самое главное
Никакая "линейка" не поможет, если для человека главное то, что он "Hello Word" может написать за 6 секунд (в смысле быстрее)
А если главное "понимание", то и "линейка" как-то уже и не актуальна...
Тем более, что "читаемость" - не понять что такое... Что более "читаемо" - код на (предположим) КП, или схема на ДРАКОНе ???
Вот если я отвечу на этот вопрос - "HiAsm", то где та "линейка", которая нас рассудит
Чего-то мне кажется, что нет такой линейки.... В смысле, фиг ее сделаешь.

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

Интересно направление Model checking - я в литературе книжку переводную приводил. Шалыто в книжке Автоматное программирование упоминал, что основное наблюдение в этом направлении: невозможно доказать правильность проги, если она с самого начала не строится под доказательство. Это как с другимихарактеристиками. Например, если изначально не строить программу с целью облегчения модифицируемости, то потом это уже невозможно сделать. Переписать заново проще.

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

Вот что я нашёл у Фасмера про "читать":



То есть, этимология недвусмысленно указывает на суть: чтение есть процесс, направленный на понимание текста.

У лингвистов можно найти такое определение текста: "последовательность осмысленных высказываний, передающих информацию". Видно главное - текст есть элемент общения.

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

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

И дракон-схемы, и программы на обероне - всё читаемое. Нельзя говорить, что одно более читаемое, чем другое. Хотя, думается, что под "читаемостью" подразумевается несколько другое, а именно - скорость расшифровки знаков. Если знаков много, то скорость падает. Если знаки богато нагружены смыслами, то скорость опять же падает (эти смыслы надо ещё уметь развернуть). То есть, речь идёт о "соревновании": кто быстрее поймёт текст, восстановит у себя в голове его структуру.

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

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

Я думаю, что с читабельностью вы правы. Но читаемость (понимаемость) текста влияет на другие характеристики программы. Например, на количество ошибок. Здесь можно говорить, например, о плотности ошибок на единицу программного текста: процедуру или модуль. А это уже сравниваемые вещи.
Но опять же: ошибки делают люди, поэтому сравнивать требуется работу людей с примерно одинаковым опытом.
То есть, куда ни кинь программа - это результат трудовой деятельности человека.
Кстати, в ИТ напрочь отсутствуют объективные нормативы мастерства программистов (и других деятелей... ). В отличие от других видов деятельности ...

Что-то здесь говорится только о "читабельности" текста.
А можно говорить и о других свойствах языка.
Открываю недавно изданную книгу М.Плаксина "Тестирование и отладка программ", главу 9 ("Ошибкоопасные ситуации").
Вот некоторые из перечисленных (с моими пометками):
- выход индекса за границу массива (Паскаль/Оберон vs Си)
- "висячая ссылка" (Оберон vs Си/Паскаль)
- использование записи с вариантами (Оберон vs Си/Паскаль)
- статические переменные (Оберон vs Алгол/Си)
- вложенные условные операторы: сочетание if-then-if-then-else (Оберон vs Си/Паскаль)
- ошибки в числе и типах параметров процедур (раздельная компиляция vs независимая компиляция).
Вопрос: число вероятных "ошибкоопасных ситуаций" будет учитываться в метрике?


Вот это "напрочь" вызывает сомнения.
Занимаются же "охотники за головами" набором программистов. Чем то они при этом руководствуются?
И так ли велика разница по сравнению с другими профессиями?

Ошибкоопасные свойства приводят к перерасходу времени использования среды (увеличивается период отладки, но объём текста меняется незначительно).

Так что, можно сказать, что учитываются