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

M>Увы, повышение уровня абстракции практически всегда приводит к ухудшению производительности программ. Это ухудшение невелико, когда эти уровни абстрации были созданы в рамках одного проекта для решения одной задачи. Но если их брать со стороны, брать некие готовые решения — то потеря производительности будет очень заметна — в разы на каждом уровне абстракции.
Это неправда. Никакой связи между "готовностью" решений и abstraction penalty нет. Есть связь между качеством "клея", который собирает из абстракций конкретную реализацию, и abstraction penalty. Готовые решения из STL очень высокоабстрактны, и никаким образом не созданы в рамках "одного проекта" с прикладной задачей. Тем не менее, никакого "ухудшения производительности" по сравнению с C RTL нет — скорее наоборот.

M>Эта деградация производительности хороша заметна в ретроспективе развития производительности компьютеров и программного обеспечения — мы все видели, как скорость компьютеров увеличилась на несколько порядков, а вот функциональность софта — намного меньше.
Это тоже неправда. То, о чём ты говоришь, это "воспринимаемая функциональность" и "воспринимаемая производительность", perceived functionality vs perceived performance. Обе имеют большее отношение к психологии, чем к технике. Например, показ progress indicator во время долгой операции снижает объективную производительность и увеличивает воспринимаемую.
Список "фич" того же офиса за десять лет вырос на порядок, а его воспринимаемая функциональность практически не изменилась.

M>Так бы и продолжалось дальше, но увы, экспоненциальное развитие скорости компьютеров практически закончилось. И просто увеличение количества уровней абстракции (вроде применения более высокоуровневых языков программирования) уже не поможет — железо не потянет.
И это тоже неправда. Простой пример: запись вида int a = b + c / d — e; находится на совсем другом уровне абстракции, чем набор из mov EAX, .... Тем не менее, производительность программы будет ничуть не хуже.

M>И выход тут я вижу только один — использовать компьютер. Он не имеет такого встроенного ограничения на уровень сложности программы, которую должен анализировать.
Какого ограничения?
M>Но увы, он не имеет и интеллекта, чтоб писать и анализировать программы. Вот когда этот интеллект у него появится — тогда и появится реальная альтернатива увеличению количества уровней абстракции в программе. Чтоб программы становились более сложными и функциональными, без экспоненциального увеличения требований к ресурсам.
Угу. Прекрасный пост — из набора неверных утверждений делается совершенно бессмысленный вывод.

VD>Твое суждение было "любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот...". Если уж строить аналогии, которые в прочем не уместны, то про автомобили нужно было писать "автомобиль может быть использован как по делу, так и не эффективно, например в соседний ларёк ездить за пивом на авто не эффективно".

Аналогия относилась к окончаннию фразы, а именно —

упорядочивание и абстрагирование всегда в 100% случаях автоматически ведёт к усложнению

что, на мой взгляд, как раз и является ложным выводом.

Здравствуйте, IO, Вы писали:
IO>Ну да, я же отвечал на вопрос "Теперь нужно научиться всё это теплое и мягкое между собой сравнивать."...
IO>А что не так?
Что-то мне подсказывает, что тут одни под сложностью понимают запутанность, другие — трудность.
Тем временем третьи с четвёртыми пытаются подставить обе в одно уравнение и определить, можно это делать или нет.

IO>>Из "закона сохранения сложности" следует, что сложность при рефакторинге переходит из одного вида в другой.

IT>Ну то есть тёплое с мягким.

Ну так весь фокус в том, что ты первый начал.
Как тогда понимать твой "закон сохранения"?
Идея вроде: "оно никуда не делось, оно всё где-то тут"?
Ну так аргументируй количественно, раз начал количественные оценки. "Сохранение", "переход" и есть такие количественные оценки.

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

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

S_>КОНТЕ'КСТ, а, м. [латин. contextus — сплетение, соединение] (филол.).
T>>Связное словесное целое по отношению к входящему в него определенному слову или фразе. Надо взять фразу в контексте, и тогда она станет понятной.


T>>Все контексты поддаются описанию.

S_>Когда сложные и общие термины(по словарю) часто применяют в конкретной области они немного другой смысл могут приобретать.

S_>А теперь не о контекстах, а снова IDictionary<TKey,TValue> поскольку он широко известен. Да и вобще об интерфейсах.
S_>Что есть этот IDictionary ? Он имеет конкретное в ЯП значение, список членов. И плюс соглашения что каждый член означает и какое поведение ожидается. Почти все подробно закомментировано в MSDN. Но не все. Например не сказано что если объект добавлен в IDictionary, то он не может изчезнуть, пока не будет удален (через один из базовых интерфесов), или сам перепрыгнуть на другой key.
S_>Все описать невозможно, часть соглашений "переходит по наследству" от всего .NET, часть просто от здравого смысла программистов, и вобще от здравого смысла.

S_>Это соглашение IDictionary появилось в .Net потому что это велосипед. Его легко изучить и запомнить, можно часто использовать для разных целей, и не очень просто реализовать. И реализовать можно по разному просто но не эффективно, сложно но эффективнее, оптимизированно под конкретный сценарий или под общийслучай.
S_>Все эти соглашения это тоже контекст.

S_>Контекст который образуется в конкретной задаче. Это уже локальный контекст в коде. "На уме" у программиста он может быть и не быть. Если есть, то может быть краткосрочным и долгосрочным (раз естейственная память такая). Краткосрочный он недолгий зато может быть на порядок больше по объему. ... и пошло и поехало...

Ещё раз: все контексты поддаются описанию. Вне зависимости от их природы.

А поскольку у тебя кратковременная память на порядок больше по объёму памяти долговременной, судя по контексту, я совсем прекращу общение.

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

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


S_>>Контекст который образуется в конкретной задаче. Это уже локальный контекст в коде. "На уме" у программиста он может быть и не быть. Если есть, то может быть краткосрочным и долгосрочным (раз естейственная память такая). Краткосрочный он недолгий зато может быть на порядок больше по объему. ... и пошло и поехало...

T>А поскольку у тебя кратковременная память на порядок больше по объёму памяти долговременной, судя по контексту.

Да и твои слова легко передернуть. "Краткосрочный" слово мужского рода и не может относиться к памяти.
Как можно делать вывод что краткосрочная память больше по объему если в ней все быстро забывается? То что слово контекст это синоним слова память это чушь.

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

А что ты хотел чтобы я написал вместо одного предложения, вот это:
Краткорсрочная память отличается от долгосрочной тем что, за фиксированный промежуток времени через нее проходит и в ней обрабатывается на порядок больший объем информации, чем попадает в долгосрочную память. Кроме того краткосрочная память обладает меньшей избирательностью, и запоминает любую, даже несущественную информацию. В долгосрочную память попадают только наиболее существенная обобщаемая, и хорошо связанная(с тем что уже есть) информация. Программный код не является, тем что хорошо запоминается в долговременной памяти.
Поэтому невозможно большой по объему код за короткое время запомнить долговременно без потери детализации. А при работе с кодом детали имеют важное значение.
Большой по объему контекст обработать с высокой степенью детализации возможно только в краткосрочной памяти. Периодически бегая по тексту программы. Либо потратить десяток лет на точное долгосрочное заучивание исходников.
Да и в таком тексте я прекрасно вижу к чему можно придраться.

Так что этот вопрос с контекстами закрываем.

Здравствуйте, Игорь Ткачёв, Вы писали:

Надеюсь, я не слишком поздно ? Но раньше не мог — именно с 20 июля находился в условиях нулевой сложности на берегу моря

Нет такого закона. Исходное положение неверно. Задача проектирования — уменьшение сложности до минимума. И только так.

Вот простой пример. Вспомним старые добрые ДОС-времена, когда некий сетевой код пытался изобразить собой и протокол , и клиент, и драйвер одновременно. Монолит. С появлением новых плат сложность такого кода росла. Пришли времена Windows, эти понятия разделили. Если бы сейчас кто-то попытался бы написать для Windows универсальный сетевой протокол-клиент-драйвер (я оставляю в стороне вопрос, можно ли такое вообще сделать для Windows), то сложность его была бы таковой, что он, скореее всего, никогда бы не был написан.

То же самое для видеокарт.

Целью проектирования является уменьшение сложности, для чего, собственно, и вводится понятие компонента (в широком смысле этого слова). Внутрення сложность компонента может быть сколь угодно высока, но его внешняя сложность должна быть небольшой. При работе с компонентом нас его внутрення сложность не интересует, он для нас (в идеале) black box. А внутри него — те же правила для его подкомпонентов.

И это не только к программированию относится.

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

G>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.

Ну допустим мы получили три числа: 25, 42 и 18. Что с ними дальше делать?

IT>>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
G>Связность.

Связность может быть сильная, а может быть слабая. Я вовсе не против этого, но это не количественная метрика.

IT>>Гибкость — сложность модификации кода. Как будем квантовать?
G>Обратная величина к линейной функции от связности и цикломатической сложности при фиксированном объеме кода.

Формулу не напишешь? Я тебе подскажу два аргумента, например, связность — много, цикломатическая сложность — 25.

IT>>Разная у всех не только сложность понимания, но ещё и обучаемость и предел алгоритмической сложности. Это всё тоже нужно как-то включать в формальное определение.
G>Субъективные факторы, типа сложности обучения, лучше не учитывать в формальных выкладках.

Ну да. А может лучше сразу не заниматься такой бесполезной фигнёй как формальные выкладки?

T>>>Это исследование надо проводить, на это я пойтить не могу.
IT>>А зря.
G>Не очень получится, в зависимости от задачи одни метрики могут быть более приоритетные, чем другие.

Включи в свои формулы приоритетность, в чём проблема?

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

T>Вот и размен: для Пеано проще доказывать теоремы, работать же лучше с позиционной системой счисления. Обычные программисты предпочитают второе, HOT программисты — первое. "Integers are for sissies!" (C) ироничный J. Shapiro, создатель BitC.

Зашибись! И что?

IT>>Опять же критерий полезности.
T>Чуть выше.



IT>>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
T>Самое простое — подход а-ля IQ. Создаём большой список вопросов по теме, от простых до сложных, проводим тесты. Метрика понимания — количество отвеченных вопросов за определённое время. Можно ввести вес вопросов.

Во-первых, допустим получишь ты в результате теста число 36 и как ты его дальше будешь сравнивать со строками кода?
Во-вторых, придут индусы и вызубрят все ответы, получат лучшие балы, а знать как не знали так и не будут знать ничего.

IT>>Гибкость — сложность модификации кода. Как будем квантовать?
T>Соответственно, гибкость будет обратно пропорциональна количеству ошибок на решение задачи.

Допустим. Теперь надо сравнить число 36, отличное знание ООП индусами и количество ошибок (кстати, о каких ошибках речь? наша задача вроде как писать рабочий код, а не ошибочный).

T>>>А можешь выбросить из рассмотрения, пока не найдёшь.
IT>>Не-не-не. Не надо ничего выбрасывать, надо наоборот добавлять.
T>Это не мой подход.

Т.е. если функциональное требование не вписывается в твою модель, то выбросить нужно функциональное требование, а не модель?

T>То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.

Скорость понимания больше всего зависит от знания предметной области. Как будем это связывать?

IT>>>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций.
T>>>Это исследование надо проводить, на это я пойтить не могу.
IT>>А зря.
T>Я разработчик, не когнитивный исследователь.

Пока ты больше похож на отбрасывальщика неустраивающих тебя требований.

T>>>Но в результате всё сведётся к прогнозу времени.
IT>>Время — это хорошо, но надо подумать. Есть моменты.
T>Это единственный невосполнимый ресурс.

Это не важно. Важнее уменее сравнивать 5 лет обучения в университете против 3 года в ПТУ и как результат 100 строк кода за час против 2000 за месяц на одной задаче.

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

IT>>Ну то есть тёплое с мягким.

VGn>Ну так весь фокус в том, что ты первый начал.
VGn>Как тогда понимать твой "закон сохранения"?
VGn>Идея вроде: "оно никуда не делось, оно всё где-то тут"?
VGn>Ну так аргументируй количественно, раз начал количественные оценки. "Сохранение", "переход" и есть такие количественные оценки.

Количественно не получается, потому что нельзя. Я уже устал это повторять.

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

PD>Нет такого закона. Исходное положение неверно. Задача проектирования — уменьшение сложности до минимума. И только так.

Ну допустим. Пока у нас 4 никак не связанных друг с другом предложения.

PD>Вот простой пример.

Пример тоже как-то никак не связан с предыдущим выступлением.

PD>То же самое для видеокарт.

Ну да.

PD>И это не только к программированию относится.

Не спорю.

Можно ворос? Спасибо! А поделу что-нибудь есть сказать?

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

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

Ты статью читал?

Привожу ещё раз цитату специально для тех, кто дальше названия не заглядывал:

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

VGn>>Ну так весь фокус в том, что ты первый начал.
VGn>>Как тогда понимать твой "закон сохранения"?
VGn>>Идея вроде: "оно никуда не делось, оно всё где-то тут"?
VGn>>Ну так аргументируй количественно, раз начал количественные оценки. "Сохранение", "переход" и есть такие количественные оценки.

IT>Количественно не получается, потому что нельзя. Я уже устал это повторять.

Тогда и нечего было эту муть начинать.

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

IT>>Количественно не получается, потому что нельзя. Я уже устал это повторять.

VGn>Тогда и нечего было эту муть начинать.

Зачем ты тогда влез в эту муть? Видимо всё таки стоило начинать и не такая уж это муть

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

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

T>>Вот и размен: для Пеано проще доказывать теоремы, работать же лучше с позиционной системой счисления. Обычные программисты предпочитают второе, HOT программисты — первое. "Integers are for sissies!" (C) ироничный J. Shapiro, создатель BitC.
IT>Зашибись! И что?

Пример "сохранения сложности". Неужто ты не рад?

IT>>>Опять же критерий полезности.
T>>Чуть выше.
IT>

Ничем не могу помочь.

IT>>>Чего — например, ООП. Можно квантануть до наследования, инкапсуляция, полиморфизм. Какова будет метрика?
T>>Самое простое — подход а-ля IQ. Создаём большой список вопросов по теме, от простых до сложных, проводим тесты. Метрика понимания — количество отвеченных вопросов за определённое время. Можно ввести вес вопросов.
IT>Во-первых, допустим получишь ты в результате теста число 36 и как ты его дальше будешь сравнивать со строками кода?

Взвешено.

IT>Во-вторых, придут индусы и вызубрят все ответы, получат лучшие балы, а знать как не знали так и не будут знать ничего.

Всё не вызубрят.

IT>>>Гибкость — сложность модификации кода. Как будем квантовать?
T>>Соответственно, гибкость будет обратно пропорциональна количеству ошибок на решение задачи.
IT>Допустим. Теперь надо сравнить число 36, отличное знание ООП индусами и количество ошибок (кстати, о каких ошибках речь? наша задача вроде как писать рабочий код, а не ошибочный).

В рабочем коде обязательно содержатся ошибки.

Насчёт сравнения — выводи веса.

T>>>>А можешь выбросить из рассмотрения, пока не найдёшь.
IT>>>Не-не-не. Не надо ничего выбрасывать, надо наоборот добавлять.
T>>Это не мой подход.
IT>Т.е. если функциональное требование не вписывается в твою модель, то выбросить нужно функциональное требование, а не модель?

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

Так делают все разумные люди.

Сперва надо разобраться без функциональных требований, потом ввести функциональные.

T>>То есть, скорость понимания снижается от уровня сложности задачи. Это можно связать.
IT>Скорость понимания больше всего зависит от знания предметной области. Как будем это связывать?

Тестами на знание предметной области а-ля IQ получив численное представление о знании предметной области?

Тем более, что так все и делают: тестируют на собеседовании и отвергают, если не подходит.

IT>>>>>Интересны количесвенные характеристики каждого вида и функции, с помощью которых их можно было бы привести к единой мере для дальнейших манипуляций.
T>>>>Это исследование надо проводить, на это я пойтить не могу.
IT>>>А зря.
T>>Я разработчик, не когнитивный исследователь.
IT>Пока ты больше похож на отбрасывальщика неустраивающих тебя требований.

Да. На любом этапе существования любой модели есть вещи, которые она объяснить не может. См. историю науки.

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

По-моему, это разумно.

T>>>>Но в результате всё сведётся к прогнозу времени.
IT>>>Время — это хорошо, но надо подумать. Есть моменты.
T>>Это единственный невосполнимый ресурс.
IT>Это не важно. Важнее уменее сравнивать 5 лет обучения в университете против 3 года в ПТУ и как результат 100 строк кода за час против 2000 за месяц на одной задаче.

Проводи исследования и вводи веса.

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

IO>Сложность кода не может быть ниже сложности обьекта, который код моделирует

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

Здравствуйте, Игорь Ткачёв, Вы писали:

Маленькое дополнение. То, что ты называешь IQ-сложностью стоит разделить на два вида:
1) Алгоритмическая сложность. Т.е. сложность логики, алгоритмов. Она, собственно, напрямую определяется той логикой, которая в итоге реализуется программой.
2) Структурная сложность. Т.е. сложность архитектуры программы, структуры обрабатываемых данных, сложности, количества и противоречивости требований.

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

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

AVK>Маленькое дополнение. То, что ты называешь IQ-сложностью стоит разделить на два вида:
AVK>1) Алгоритмическая сложность. Т.е. сложность логики, алгоритмов. Она, собственно, напрямую определяется той логикой, которая в итоге реализуется программой.
AVK>2) Структурная сложность. Т.е. сложность архитектуры программы, структуры обрабатываемых данных, сложности, количества и противоречивости требований.

Пожалуй это будет тем самым недостающим кирпичиком

IT>>>Количественно не получается, потому что нельзя. Я уже устал это повторять.

VGn>>Тогда и нечего было эту муть начинать.

IT>Зачем ты тогда влез в эту муть? Видимо всё таки стоило начинать и не такая уж это муть

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

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

IT>>Зачем ты тогда влез в эту муть? Видимо всё таки стоило начинать и не такая уж это муть

VGn>А как назвать утверждения, подтвердить которые автор не может в принципе? Причём ещё и сам об этом заявляет. Или тебе о верности твоих гипотез напели звёзды?

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

Если завтра будет холодно, скажем 5-10 С, ты просто оденешься потеплее или будешь до посинения требовать более точного числа для принятия решения, скажем до сотой градуса? А если ещё и дождик будет моросить, тебя будет интересовать сколько точно накапает в пробирки метеорологов или может просто взять зонтик и одним махом решить проблему?

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Но это не имеет отношения к пониманию. Но, например, к языку программирования имеет — поскольку он является средством выражения описания объекта(в оригинале — двоичных строк). Для разных описаний сложность отличается не более чем на константу, под которой можно понимать "длину" транслятора(т.е. размер кода) с одного языка на другой.

Почему же не имеет отношения к пониманию ? У человека мозг устроет определенным образом, описание состоящее более чем 7-9 эл-тов просто отказывается воспринимать. Соотвественно нужно наращивать абстракции что бы удержать описание в этих пределах.