OberonCore :: - Есть идея, как измерить оберон.

Слово:честь

Ближайшая этимология: ж., род. п. -и, чеґстный, честноґй крест, чтить (см.)., поґтчевать (см.), укр. честь, блр. чесць, др.-русск. чьсть, ст.-слав. чьсть tim» (Клоц., Супр. и др.), болг. чест, сербохорв. ча?ст, словен. ‰a?st, чеш. ‰еst ж., слвц. ‰еst', польск. czesґcґ, род. п. сzсi, в.-луж. ‰escґ, н.-луж. сеscґ.

Дальнейшая этимология: Праслав. *‰ьstь, связанное со ст.-слав. чьт†, чисти (см. чту), родственно др.-инд. ciґttis· ж. "мышление, понимание, намерение", авест. ‰isti- "мышление, познание, понимание"; др. ступень чередования гласных: др.-инд. сЊґtаti "соблюдает, замечает, думает", лтш. «k§ist, «k§i°etu "думать, соблюдать"; см. Бернекер I, 173 и сл.; Траутман, ВSW 135; Мейе, МSL 14, 349; М. -- Э. 4, 47; Либерт 100. Ср. чту, читаґть.

Слово:чту

Ближайшая этимология: II, честь: почтуґ, почеґсть, прочтуґ, прочеґсть, чтеґние, почтеґние, почеЁт, почтиґ, нареч., буквально "считай, можно считать", также чеЁтки мн. (см.), чеЁткий, ст.-слав. чьт†, чисти ўnagignиskein, sebe‹n (Еuсh. Sin., Супр.), болг. четаґ "читаю", сербохорв. стар. чтем, чисти "читать, почитать", совр. ча°ти?м, ча°тити, ча°та?м, ча°тати "читать", по?штити "почтить", словен. ‰te·?jem, ‰te·ґti, «te·^jem, «te·ґti "считать", чеш. ‰tu, ‰iґsti "читать, считать", польск. стар. czte§, czysґcґ, полаб. caІte "считает".

Дальнейшая этимология: Связано чередованием гласных с читаґть (см.), сюда же честь (*‰ьt-tь). Родственно др.-инд. сЊґtаti "соблюдает, мыслит, познает, понимает", kЊґtas м. "мысль, умысел, желание", cikitvѓґn "понимающий, знающий", авест. ‰iki±wѓІ "мудрый", далее -- лит. skaityґti, skaitau~ "читать, считать", лтш. ska°iti^t "считать", «k§i°etu§, «k§ist "думать"; см. Бернекер I, 175; Траутман, ВSW 135; Зубатый, AfslPh 16, 388; М.--Э. 4, 47; Мейе, МSL 14, 349.

Автор:	Иван Кузьмицкий [ Понедельник, 01 Март, 2010 21:20 ]
Заголовок сообщения:	Есть идея, как измерить оберон.
Критика оберона опирается на утверждения, что: 1. Поскольку язык лаконичный (примитивный), то выражение программных конструкций в исходных текстах получается более многословным. 2. Поскольку язык непопулярный, то приходится многажды "изобретать велосипеды", что опять же якобы приводит к распуханию исходников. Исходные тексты программ - это всё же тексты, поэтому измеряя работу с текстами, можно получить некую универсальную методику оценки языка и даже среды программирования как рабочих инструментов программиста. Для оценки можно использовать следующие статистические параметры: 1. Общее время использования среды программирования. Среда программирования тут рассматривается как приспособление для создания программных текстов. Под использованием среды программирования подразумевается любая активность в среде - перетаскивание окон, кликанье мышкой, сохранение-открытие документов и т.п. 2. Общий объём текста. Те самые пресловутые 100-200 строк в день, в промежутках между набором которых программист думает, изучает документацию, пишет комментарии и т.п. 3. Общий объём использования клавиатуры как приспособления для набора текстов. Тут считаем все нажатия всех клавиш, включая стирание символов, пролистывание, горячие клавиши и т.п. То есть, можно будет видеть, сколько времени своей жизни программист потратил на сидение в среде, как сильно мучал клавиатуру и сколько в результате у него получилось текста. Я думаю, что набирание статистики возможно организовать как из среды BlackBox, так и из других сред программирования. Можно вывести даже некий индекс как отношение объёма текста к общему времени работы в среде. Если майнстрим настолько хорош, как его малюют, то преимущество популярных инструментов будет очевидно - времени потрачено мало, а набрано много. Или же набрано не очень много, зато нажатий почти нет. Ну и так далее. Как вам идея? Покритикуем?

Автор:	Валерий Лаптев [ Понедельник, 01 Март, 2010 21:39 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Нужно обмерить Оберон и конкурентов метриками. Например, метриками Холстеда. Свердлов хорошую методу предложил по измерению сложность: мерить объем грамматики в самых разных разрезах. Можно обмерить типовые структуры данных в реализации на Обероне и, например, на С++. При этом еще как-то надежность надо обмерять. Кроме статистики тут ничего не пойдет?

Автор:	Иван Кузьмицкий [ Понедельник, 01 Март, 2010 21:46 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Про метрики Холстеда я уже думал. Ещё бы, конечно, вести подобные статистики с разбивкой по проектам, тогда можно получить усреднённое время реализации проекта. На достаточно больших периодах, можно даже приблизиться к каким-то нормам, независимым от среды и языка. Волонтёры статистику могут вести вообще в фоновом режиме, в BlackBox это сделать несложно. Результаты отсылать куда-нибудь в Центр. P.S. Вообще, мне думается, что такой "мониторинг программиста" поможет избавиться от сугубо субъективных оценок и смотреть именно на то, как просто\сложно реализовывать задачи. Для этого нужны параметры, независимые от языка\среды, но фиксирующие как раз труд программиста.

Автор:	Валерий Лаптев [ Понедельник, 01 Март, 2010 21:58 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Эти параметры изложены в стандартах по качеству ПО. Лично я этим делом собрался заняться очень плотно после докторской. То есть примерно через год. К тому времени и статистика подоспела бы...

Автор:	Иван Кузьмицкий [ Понедельник, 01 Март, 2010 22:19 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Мне кажется, что оценка качества ПО исходит все же из другой модели, нежели оценка инструмента разработки.

OberonCore https://forum.oberoncore.ru/

Есть идея, как измерить оберон. https://forum.oberoncore.ru/viewtopic.php?f=1&t=2408	Страница 1 из 2

Автор:	Galkov [ Понедельник, 01 Март, 2010 23:41 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Иван Кузьмицкий писал(а): Критика оберона опирается на утверждения, что: Критика происходит из отрицания того, что основное назначение кода - для Человека, а не для Компьютера. Говорят все, что угодно - а в голове именно это. И все следует именно из этого. Пока нет согласия по этой основной позиции - сто лет спорить с пеной у рта можно. Вспомните Педсовет И что занимательно, глаза "нападающим" открыл (на странице, где-то - двадцатой...) не участник данного форума, а Руслан. И показалось мне, что как-то сникли "нападающие" немного... После этого. Не было уже той страсти, за мелочи взялись...

Автор:	Иван Кузьмицкий [ Вторник, 02 Март, 2010 00:58 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Ну, для человека, и ладно. Теперь к этому человеку надо линейку приложить и заценить - на что он тратит время своей жизни, на километры кода или на решение задачи. А то может оказаться так, что задачи в обероне решаются примерно такие же, как в майнстриме, а времени на это решение уходит меньше. Хотя бы из-за стремящегося к нулю периода отладки... Пора переходить от философии к цифрам Объём грамматики по Свердлову хорош, но не хватает фактора времени.

Автор:	Валерий Лаптев [ Вторник, 02 Март, 2010 01:04 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
А время можно оценить только на практике. Посадить две команды с ОДИНАКОВЫМ опытом на одну задачу. кто быстрее и напишет. И где меньше ошибок. И где текст короче. У нас есть две такие команды? Или хотя бы два человека? Хотя можно Ермакова попросить, мож двух студентов подбросит. Только их нужно обоих одинаково научить и ББ+КП и С++ + дотнет.

Автор:	Valery Solovey [ Вторник, 02 Март, 2010 01:10 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Тогда уж команды должны не только писать код, но и читать его после этого. И важным условием должно быть то, что читающий человек не участвовал в написании кода (эмулируется ситуация, когда к коду возвращаешься спустя долгое время и он настолько забыт, что воспринимается как чужой). И на основе чтения можно будет судить - для Человека писался код или для Машины.

Автор:	AVC [ Вторник, 02 Март, 2010 01:10 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Валерий Лаптев писал(а): Только их нужно обоих одинаково научить и ББ+КП и С++ + дотнет. Вот цена этого "одинаково" и есть искомая мера.

Автор:	Info21 [ Вторник, 02 Март, 2010 06:07 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Иван Кузьмицкий писал(а): Для оценки можно использовать следующие статистические параметры: Надо, конечно, сильно думать, чтобы правильно проинтерпретировать такие цифры. Но вообще интересно.

Автор:	Galkov [ Вторник, 02 Март, 2010 13:53 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Иван Кузьмицкий писал(а): Ну, для человека, и ладно А вот не "и ладно", а самое главное Никакая "линейка" не поможет, если для человека главное то, что он "Hello Word" может написать за 6 секунд (в смысле быстрее) А если главное "понимание", то и "линейка" как-то уже и не актуальна... Тем более, что "читаемость" - не понять что такое... Что более "читаемо" - код на (предположим) КП, или схема на ДРАКОНе ??? Вот если я отвечу на этот вопрос - "HiAsm", то где та "линейка", которая нас рассудит Чего-то мне кажется, что нет такой линейки.... В смысле, фиг ее сделаешь.

Автор:	AVC [ Вторник, 02 Март, 2010 23:46 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Валерий Лаптев писал(а): Я думаю, что с читабельностью вы правы. Но читаемость (понимаемость) текста влияет на другие характеристики программы. Например, на количество ошибок. Здесь можно говорить, например, о плотности ошибок на единицу программного текста: процедуру или модуль. А это уже сравниваемые вещи. Что-то здесь говорится только о "читабельности" текста. А можно говорить и о других свойствах языка. Открываю недавно изданную книгу М.Плаксина "Тестирование и отладка программ", главу 9 ("Ошибкоопасные ситуации"). Вот некоторые из перечисленных (с моими пометками): - выход индекса за границу массива (Паскаль/Оберон vs Си) - "висячая ссылка" (Оберон vs Си/Паскаль) - использование записи с вариантами (Оберон vs Си/Паскаль) - статические переменные (Оберон vs Алгол/Си) - вложенные условные операторы: сочетание if-then-if-then-else (Оберон vs Си/Паскаль) - ошибки в числе и типах параметров процедур (раздельная компиляция vs независимая компиляция). Вопрос: число вероятных "ошибкоопасных ситуаций" будет учитываться в метрике? Валерий Лаптев писал(а): Кстати, в ИТ напрочь отсутствуют объективные нормативы мастерства программистов (и других деятелей... ). В отличие от других видов деятельности ... Вот это "напрочь" вызывает сомнения. Занимаются же "охотники за головами" набором программистов. Чем то они при этом руководствуются? И так ли велика разница по сравнению с другими профессиями?

Автор:	Иван Кузьмицкий [ Среда, 03 Март, 2010 00:23 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Ошибкоопасные свойства приводят к перерасходу времени использования среды (увеличивается период отладки, но объём текста меняется незначительно). Так что, можно сказать, что учитываются

Автор:	Валерий Лаптев [ Понедельник, 01 Март, 2010 22:24 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Инструмент - это ПО. И мы собираемся оценить его качество. По некоторым параметрам. В стандартах изложены критерии в достаточной мере обобщенные. Например, мобильность, модифицируемость, читабельность. Кстати, никто еще не придумал способ объективного измерения читабельности. Мы же хотим обмерить более частные критерии. Но суть та же - мы хотим измерить некое конкретное качество конкретного ПО.

Автор:	Иван Кузьмицкий [ Вторник, 02 Март, 2010 07:14 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
Думаю, что "спортивный" подход на сравнение работы двух команд по решению одной задачи слишком узкий, что ли... В жизни встречаются разные задачи и разные уровни подготовки людей. Если же мониторить в течение длительного времени реальных разработчиков, то влияние всяких специфичных факторов нивелируется. Получится "чистая" картина: человек с помощью вот этой вот лопаты напахал столько-то гектар за такое-то время (решая самые разные задачи).

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

Автор:	Валерий Лаптев [ Вторник, 02 Март, 2010 14:35 ]
Заголовок сообщения:	Re: Есть идея, как измерить оберон.
То, что сейчас не понятно, не значит, что не нужно вообще ничего делать. Вот, например, наличие цикла Дейкстры и вообще структурных конструкций делает прогу более модифицируемой, чем при наличии конструкций с выходом из середины. И видимо, более надежной. И, кстати, возможно, что более читабельной. Осталось придумать метрику, которая показывает эту разницу, и во сколько раз. Метрика, естественно, эвристическая. Потом ее уточнять в реале. Меры сложности - они в первую очередь, количественные. На основе количества разнообразных элементов в программе. И, кроме того, на основе статического и динамического графа программы. Далее - опять эмпирический закон требуется наблюдать: насколько влияет сложность на другие характеристики. Это и есть первые шаги науки в ИТ - первоначальные наблюдения, измерение и классификация. Интересно направление Model checking - я в литературе книжку переводную приводил. Шалыто в книжке Автоматное программирование упоминал, что основное наблюдение в этом направлении: невозможно доказать правильность проги, если она с самого начала не строится под доказательство. Это как с другимихарактеристиками. Например, если изначально не строить программу с целью облегчения модифицируемости, то потом это уже невозможно сделать. Переписать заново проще.

Страница 1 из 2	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/