OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 11 Декабрь, 2019 22:32

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




Начать новую тему Ответить на тему  [ Сообщений: 71 ]  На страницу 1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 02:46 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Было проведено интересное исследование:
http://lionet.livejournal.com/55643.html?thread=1431899
Цитата:
Экспериментальные результаты показывают, что код на Scala, написанный с использованием продвинутых, абстрактных конструкций, лучше чем код, написанный в стиле, схожем с Java. Разница во времени понимания испытуемыми материала статистически значима, несмотря на малый размер выборки. Касательно достигаемого степени понимания, неформальные замечания, сделанные испытуемыми, дают субъективное подтверждение этому — использование продвинутых конструкций упрощает задачу понимания кода. Интересно отметить, что преимущества использования Scala были видны даже в группе, состоящей из программистов с ограниченным пониманием общих концепций Scala.
[…]
Неожиданностью оказалось наблюдение, что время понимания смысла токена не отличалось, несмотря на разный когнитивное содержание токена.. Если это свойство может быть обобщено, это дало бы дизайнерам языков точную цель: чем короче код, тем лучше. Это также может объяснить, почему языки предметной области (DSL) так эффективны.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 07:25 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Я бы так безапеляционно не утверждал. Видимо, существует некоторый оптимумразмера кода и его понимания. В одной из книжек, которые я читал было написано, что однажды один из гуру-программистов 4 (четыре!) часа разбирал программу из 4 строчек. Прога была написана на АПЛ.
Поэтому помимо краткости нужно что-то еще для понимания.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 11:06 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Валерий Лаптев писал(а):
Я бы так безапеляционно не утверждал. Видимо, существует некоторый оптимумразмера кода и его понимания. В одной из книжек, которые я читал было написано, что однажды один из гуру-программистов 4 (четыре!) часа разбирал программу из 4 строчек. Прога была написана на АПЛ.
Поэтому помимо краткости нужно что-то еще для понимания.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 11:48 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Вообще же написано, что играет роль число токенов, а не число строк (число строк тоже думаю играет роль, но слабо, кроме того это моё субъективное мнение ничем не подтвержденное). Также роли не играет сколько символов в каждом токене.

Зато, на число токенов хорошо влияет более высокий уровень абстракции. В частности, наличие в языке HOF, наличие высокоуровневых библиотек (типа stl/boost, а лучше то что есть в стандартной библиотеке любого ФЯ -- всякие foldr'ы, map'ы, комбинаторы..).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 12:11 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1026
Валерий Лаптев писал(а):
Поэтому помимо краткости нужно что-то еще для понимания.
Алгоритм нужен.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 13:26 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Alexey Veselovsky писал(а):
Вообще же написано, что играет роль число токенов, а не число строк (число строк тоже думаю играет роль, но слабо, кроме того это моё субъективное мнение ничем не подтвержденное). Также роли не играет сколько символов в каждом токене.

Зато, на число токенов хорошо влияет более высокий уровень абстракции. В частности, наличие в языке HOF, наличие высокоуровневых библиотек (типа stl/boost, а лучше то что есть в стандартной библиотеке любого ФЯ -- всякие foldr'ы, map'ы, комбинаторы..).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 13:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9164
Откуда: Россия, Орёл
Влияет хорошая (плохая, в случае распространённого стиля на обычных языках) структурированность - вот и всё.

Краткость и обозримость каждого блока.

А не вообще сравнительная краткость записи системы.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 13:31 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Влияет хорошая (плохая, в случае распространённого стиля на обычных языках) структурированность - вот и всё.

Краткость и обозримость каждого блока.

А не вообще сравнительная краткость записи системы.

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

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


Полагаю в ислледовании структурированность всех трех исходников была примерно на одном уровне (ибо писалось одним и тем же человеком). И персональная составляющая тоже была одна и та же. Так что это предположение данным исследованием не подтверждается.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 15:24 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1026
Илья Ермаков писал(а):
Тот же КП, как показывает практика, очень быстро направляет всех на единообразие - персональной стилистике мало места остаётся
Сам предмет такой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 15:44 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8214
Откуда: Троицк, Москва
Еще важно, сколько и каких "топологических препятствий" разожено в компактном коде для evolvability.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 16:00 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Info21 писал(а):
Еще важно, сколько и каких "топологических препятствий" разожено в компактном коде для evolvability.

Я правильно понимаю, что evolvability это возможность последующей модификации, развития программы?
Если так, то это уже как бы друой вопрос.

Обычно подобные абстрактные вещи никак в плане интерфейсов не завязаны на тонкости реализации.
Т.е. делаем foldl хоть списку, хоть массиву, хоть чему-то ещё. С т.з. интерфейса будет в точности то же самое. При этом оно отработает максимально эффективно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 20:18 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8214
Откуда: Троицк, Москва
Alexey Veselovsky писал(а):
Info21 писал(а):
Еще важно, сколько и каких "топологических препятствий" разожено в компактном коде для evolvability.
Я правильно понимаю, что evolvability это возможность последующей модификации, развития программы?
Если так, то это уже как бы друой вопрос.
Может, и другой.
Но умные люди сформулировали (на мой взгляд, совершенно правильно), что evolvability -- при прочих равных в плане корректности -- главный показатель качества программы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 21:50 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Info21 писал(а):
Alexey Veselovsky писал(а):
Info21 писал(а):
Еще важно, сколько и каких "топологических препятствий" разожено в компактном коде для evolvability.
Я правильно понимаю, что evolvability это возможность последующей модификации, развития программы?
Если так, то это уже как бы друой вопрос.
Может, и другой.
Но умные люди сформулировали (на мой взгляд, совершенно правильно), что evolvability -- при прочих равных в плане корректности -- главный показатель качества программы.

Никто же ж не спорит, что это важно. Просто исследование было не про это. Собственно для того, чтобы добраться до того состояния когда важна evolvability, нужно вначале понять, а потом, поняв, сделать программу корректной (если она вдруг оказалась не корректной). Вот этот вот первый шаг тут и проверялся. Зависимость степени/скороти понимабельности программы от стиля в котором она написана. Первый шаг. Без него не будет и остальных.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Апрель, 2010 10:26 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Alexey Veselovsky писал(а):
Было проведено интересное исследование:
На примере скольких программ? И каких именно?
(Может быть, эти данные доступны по указанной ссылке, но у меня на работе нет доступа к ЖЖ. :roll: )
Вообще, что-то я сомневаюсь, чтобы краткость делала ребусы/шифровки понятными. Не зря тут АПЛ поминали.
P.S. Оберон делает ставку на простоту базового языка и возможность его расширения за счёт процедур, а не роста числа токенов и синтаксических правил (т.е. не за счёт усложнения языка).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Апрель, 2010 10:40 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
AVC писал(а):
Alexey Veselovsky писал(а):
Было проведено интересное исследование:
На примере скольких программ? И каких именно?
(Может быть, эти данные доступны по указанной ссылке, но у меня на работе нет доступа к ЖЖ. :roll: )
Вообще, что-то я сомневаюсь, чтобы краткость делала ребусы/шифровки понятными. Не зря тут АПЛ поминали.
P.S. Оберон делает ставку на простоту базового языка и возможность его расширения за счёт процедур, а не роста числа токенов и синтаксических правил (т.е. не за счёт усложнения языка).


А pdf можете скачать?
http://infoscience.epfl.ch/record/13858 ... 09coco.pdf

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

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

Разумеется, когда мы говорим о кратком коде, мы не имеем ввиду синтаксическую краткость — отсутствие лишних пробелов, переводов строк, упаковывание повторяющихся последовательностей операций в текстовые макросы, etc. Краткость, которую имеет смысл рассматривать, достигается использованием абстракций более высокого уровня. Например, использование свёрток списков или деревьев вместо ручного их обхода.

Аргумент от Java/C++ программистов — использование слегка более многословного кода позволяет быстрее и эффективнее донести суть алгоритма до читателя кода. Реакция Java программистов на Haskell-код — этот ваш хаскель сложно понимать, ибо в нём нездоровое количество функциональности на единицу текста.

Аргумент от программистов на языках, допускающих написание существенно более коротких программ — короткий код позволяет человеку выражать более высокоуровневые концепции, наверняка более приближенные к предметной области, и поэтому понимание кода происходит быстрее и эффективнее. Реакция Python программистов на Java код — за деревьями не видно леса: большое количество церемоний вокруг простейших вещей напускает ненужный туман на ту мысль, которую программист пытался этим кодом донести.

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

Gilles Dubochet в своей статье принимает точку зрения, что код является механизмом обмена информацией — моделями, пониманием предметной области — между людьми. Базируясь на этом, он конструирует две гипотезы, и организует эксперимент, чтобы проверить состоятельность каждой из них.

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

Гипотеза номер два. Намёки на модель предметной области, выраженные в типах, именах переменных, и т. п., позволяют привязаться к модели предметной области. Например, понятие объединения из реляционной алгебры может быть выражено через функцию по имени join, а может быть через функцию с похожим названием (enhance_with?), но не имеющую названия, взятого напрямую из предметной области.

Gilles дал некоторому количеству испытуемых код на Scala, по-разному реализующий некий набор алгоритмов из реляционной алгебры. Вот такие три варианта были разработанны:

S/G
Sparse/Grounded
Код на Scala, использующий только конструкции, доступные в Java.
Этот код имеет привязки к реляционной алгебре с помощью имён переменных, функций, типов, etc.

D/U
Dense/Ungrounded
Компактный код на Scala, использующий более высокоуровневые конструкции, доступные в Scala. Код не имеет явных привязок к реляционной алгебре.

D/G
Dense/Grounded
Компактный код на Scala, имеющий привязки к реляционной алгебре

Читателям кода давались на ознакомление концепции реляционной алгебры, а затем следовала просьба изучить предлагаемые варианты кода, реализующие некоторые алгоритмы из неё: natural join, left outer join, cartesian product. После вникания в код (обычно испытуемые справлялись с этим за 45-60 минут), испытуемые должны были написать "контракты", которым следует код: списки предусловий и постусловий, которым отвечает логика алгоритмов. Этим проверялась степень понимания кода. Параллельно использовался специальный девайс для слежения за глазами, чтобы понять, какие языковые конструкции привлекают максимум внимания на этапе изучения кода.

[Снимок экрана с кодом, как он был показан испытуемым во время эксперимента, с картой распределения концентрации внимания. Алгоритм слева — S/G, читаемый испытуемым 7, алгоритм справа — D/U, читаемый испытуемым 12. Обратите внимание на то, что фиксация внимания на именах идентификаторов, наблюдаемая для кода в стиле S/G, в коде стиля D/U отсутствует.]

Статья даёт развёрнутую интерпретацию полученных экспериментальных результатов. Попробую дать выжимку. По поводу состоятельности первой гипотезы Gilles замечает следующее:

Цитата:
Экспериментальные результаты показывают, что код на Scala, написанный с использованием продвинутых, абстрактных конструкций, лучше чем код, написанный в стиле, схожем с Java. Разница во времени понимания испытуемыми материала статистически значима, несмотря на малый размер выборки. Касательно достигаемого степени понимания, неформальные замечания, сделанные испытуемыми, дают субъективное подтверждение этому — использование продвинутых конструкций упрощает задачу понимания кода. Интересно отметить, что преимущества использования Scala были видны даже в группе, состоящей из программистов с ограниченным пониманием общих концепций Scala.
[…]
Неожиданностью оказалось наблюдение, что время понимания смысла токена не отличалось, несмотря на разный когнитивное содержание токена. (Шрифт мой — lionet). Если это свойство может быть обобщено, это дало бы дизайнерам языков точную цель: чем короче код, тем лучше. Это также может объяснить, почему языки предметной области (DSL) так эффективны.


По поводу второй гипотезы (привязка к доменной области упрощает восприятие кода) эксперименты не смогли ни подтвердить, ни опровергнуть этого. Испытуемые, которым требовалось создать концептуальную модель того, что происходит, тратили больше времени на чтение привязок к доменной области (имён переменных, etc), чем те, которые составляли более техническую модель кода. В целом можно сказать, что поставленный эксперимент не очень подходил для того, чтобы иметь возможность установить состоятельность второй гипотезы.


Последний раз редактировалось Alexey Veselovsky Понедельник, 05 Апрель, 2010 12:19, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Апрель, 2010 11:12 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8214
Откуда: Троицк, Москва
Разработка программы -- это уже ее эволюция.

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

Загадок более чем достаточно и без выдумок мирового IT-обезъянства.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Апрель, 2010 12:13 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Info21 писал(а):
Разработка программы -- это уже ее эволюция.

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

Загадок более чем достаточно и без выдумок мирового IT-обезъянства.

Именно. Поэтому я предпочту короткую нотацию длинной. Просто потому что она проще и обозримей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Апрель, 2010 12:49 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Мдда-а.. Обсуждал эту статью на irc канале #java, внезапно столкнулся с совершенно неожиданным мнением -- мнением что "читабельность программы" не нужна и не важна. Потому как программы пишут и продают, а не читают.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Апрель, 2010 13:00 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Alexey Veselovsky писал(а):
Спасибо, скачал.
Пробежал глазами (пока) "наискосок", поэтому об эксперименте судить не берусь.
Там, где приведен пример кода, код справа никак не ассоциируется у меня с большей понятностью. (Здесь, конечно, возможная причина -- моё незнакомство со Scala.)
Я (по прежнему) не понимаю, почему краткая запись с использованием процедур должна быть хуже, чем такая же краткая запись с использованием изощрённых языковых конструкций.
Вообще, хорошо ли изобилие синтаксиса? Я вон синтаксис Лиспа не могу запомнить, а уж Скалу освоить, наверное, не в состоянии. :cry:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Апрель, 2010 13:16 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4539
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Поэтому я предпочту короткую нотацию длинной. Просто потому что она проще и обозримей.
А что? Короткая и обозримая нотация - это хорошо. Юникод ББ поддерживает. Прилада для замены ключевых слов у инфо21 есть... Даёшь ключевые слова Ыероглифами - просто потому что оно проще!


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 71 ]  На страницу 1, 2, 3, 4  След.

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


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

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


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

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB