Здравствуйте, IT, Вы писали:
IT>>>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов. G>>И при принятии решения ты учитываешь собственный прогноз трудоемкости. Сознательно, или безсознательно.
IT>Я не только трудоёмкость учитываю, а ещё много чего другого.
Ты ошибаешься. Не так уж и много.
G>>Да нивапрос. Используй Трудоемкость, юный падаван . Единственный эффективный способ сделать работу быстрее — не делать лишней работы.
IT>Складывается впечатление, что у тебя ввобще кроме "быстрее" нет больше никаких критериев сложности.
"Быстрее" не является критерием сложности.
IT> Тебе никогда не приходилось работать над проектами или хотя бы слышать о таких, в которых сроки вообще не имели никакого определяющего значения?
Вопрос некорректен. В любом _проекте_ сроки имеют значение, ибо проект всегда ограничен временем по определению. Не ограничены временем _программа_ и разгильзяйство. Но программа состоит из проектов. А из чего состоит разгильзяйство — мне не интересно.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
IT>>>С тех пор веру в объём кода как в объективную характеристику я окончательно потерял. G>>У тебя появились сомнения, что объем кода объективно и точно считается? Однако . IT>>>Да и в дальнейшем не раз приходилось в этом убеждаться. G>>Появились сомнения — а теперь "убеждаться"? У тебя что, тулза измерения SLOC разные результаты выдавала от запуска к запуску на одном файле? Выкинь эту тулзу.
IT>О, да! Допустим, у меня в команде объём одного из проектов 50k строк. Как ты думаешь — это сложный проект или не очень?
Никак не думаю. Информации для раздумий ноль. Не задан ни достаточный набор метрик, ни контекст, в котором их надо интерпретировать. Задан только один дурацкий вопрос.
IT> А объём второго — 100k. Какой из них сложнее? А сложнее в чём? А какой быстрее написали? А на сколько быстрее?
Метрика "время". Она элементарна, и поддается прямому измерению. Не понимаю, с какого дуба я должен догадываться о том, что полагается измерять.
IT>>>Под ресурсами здесь, кстати, понимается в основном грубая физическая сила имеющихся в наличии индивидуумов. Мы же здесь толкуем о работе мозгами. Если бы мы тогда работали мозгами, то разница была бы не в разы, а на порядки. G>>Корреляции элементарных метрик наблюдаемы объективно, в том числе и при работе мозгами.
IT>Здорово. Только я всё не возьму в толк, как мне это поможет выбрать правильный дизайн базы данных? Вот, например, у меня есть форма с гридом, в котором 24 колонки для 24-х месяцев, по 12 на 2 года. Как мне лучше их уложить в базу, как 24 месяца в одну запись или как две записи по 12 месяцев? Какую метрику посоветуешь?
Посоветую не морочить людям голову, и перестать выдумывать и писать ерунду.
Здравствуйте, Gaperton, Вы писали:
G>Какая милая фантазия о содержимом монографий, которых не читал .
Как раз по менеджменту я монографии читал.
G>На почитай, что Уотс Хамфри о метриках пишет. Тот самый, который CMMI. Что характерно — более-менее адекватное представление об этом имеет каждый _студент_ Carnegie-Mellon SEI — у них в программу обучения включено. G>http://www.amazon.com/Introduction-Personal-Software-Process-sm/dp/0201548097
Я рад за Хамфри. Тем не менее, всякими software process теория менеджмента не исчерпывается.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Sinclair, Вы писали:
Странное ощущение, что пишущие и чиатющие разговаривают на разных языках.
M>>>Так бы и продолжалось дальше, но увы, экспоненциальное развитие скорости компьютеров практически закончилось.
Практически можно согласиться.
И просто увеличение количества уровней абстракции (вроде применения более высокоуровневых языков программирования) уже не поможет — железо не потянет.
Во первых, конечно, потянет, а во-вторых другого пути просто нет. За исключением распараллеливания.
S>>И это тоже неправда. Простой пример: запись вида int a = b + c / d — e; находится на совсем другом уровне абстракции, чем набор из mov EAX, .... Тем не менее, производительность программы будет ничуть не хуже.
Действительно на другом. И что?
G>Более того. На современных суперскалярно-конвейерных процах производительность будет на практике не то что не хуже, а лучше.
Для того и уровни абстракции, что б иметь возможность эффективней использовать возможности более низкого уровня.
G>Пример про то, как тупенький gcc компилирует два подряд идущих умножения для тупенького MIPS я уже раньше приводил. Одно делается как умножение, второе — на сдвигах-сложениях. Выполняется такое _быстрее_.
И, наконец, какое отношение увеличение/уменьшение производительности имеет к сложности?
S_>-------------- S_>Лучше бы студия отдельно все считала, отдельно циклы, отдельно функции,отдельно if'ы, ... S_>А потом показывала бы красивые картинки, диаграммы. Какие-то диаграммы распределения функций по числу вызовов, по размеру функции, классов по числу членов, по соотношению числа приватных и публичных членов... Эти картинки хоть можно принять к сведению будет, какая то инфа о характере кода. S_>И желательна возможность написания своих скриптов для получения суммарных показателей.
S_> А для связей между классами какие-то картинки где бы была видна кластеризация, и чтобы сотни классов на одной картинке было видно, но это уже сложно.
S_>Еще можно было бы подсчитывать показатель объема повторной используемости функций. Т.е. взять число IL инструкций программы, затем все функции условно подставить(распаковать) в точку вызова, и вычислить на сколько процентов вырастет число инструкций. Когда функция вызывается из одного места, то повторной используемости нет, ее могли выделить только для уменьшения сложности. А когда большая функция вызывается из разных 10 мест, то это уже совсем другое...
S_> При изучении незнакомого кода, например откуда-то скачанного. Полезно сначала посмотреть на метрики, но хотелось бы чего то посерьезнее чем сейчас в студии.
Совершенно согласен. If-ы и циклы имеют разную природу сложности. Их необходимо считать отдельно. И, есть замечание по общей статистике. Есть объективная природа задачи. И выбор концепции решения. От этого объективно будет зависеть результат собраной статистики. Например разбор выражения If-ми или рекурсивно используя грамматику покажут разный уровень сложности. Даже любопытно как их сравнивать по сложности...
Здравствуйте, minorlogic, Вы писали:
M>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.
Здравствуйте, Sinclair, Вы писали:
G>>Какая милая фантазия о содержимом монографий, которых не читал . S>Как раз по менеджменту я монографии читал.
Где вот такая херня написана, как ты привел? Ты их не просто читал, ты их, видимо, тщательно отбирал .
G>>На почитай, что Уотс Хамфри о метриках пишет. Тот самый, который CMMI. Что характерно — более-менее адекватное представление об этом имеет каждый _студент_ Carnegie-Mellon SEI — у них в программу обучения включено. G>>http://www.amazon.com/Introduction-Personal-Software-Process-sm/dp/0201548097 S>Я рад за Хамфри. Тем не менее, всякими software process теория менеджмента не исчерпывается.
Правда? Ну расскажи же мне, что же там еще такого есть, в теории менеджмента, чтоб про софтверные метрики (характеризующие software process по своей природе), но при этом ни в коем случае не про этот самый software process.
Здравствуйте, batu, Вы писали:
B>Самое большое влияние на алгоритм и его сложность оказывает выбор концепции.
Концепции чего?
B> При не правильно выбраной концепции сложность может оказаться и бесконечной. Классическая ситуация разбор текста вручную (я называю такое написание программ "в длинну") If-ами или парсером. Пусть даже самодельным.
И? Что в этой ситуации страшного и почему она классическая?
B> И качество и сложность программы даже трудно сравнивать.
Сравнивать с чем?
B> В длину вроде проще писать,
Проще чем что?
B> но результат очень "тупой"
Что значит "тупой"?
B> и не гибкий.
По сравнению с чем?
B> С другой стороны написать парсер.. Не то, что бы проще..Но в опытных руках окажется быстрее.
Парсер напичать быстрее чем парсер? Что то у тебя с логикой.
B> Ну, вообщем понятно.
Нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Gaperton, Вы писали:
G>Где вот такая херня написана, как ты привел? Ты их не просто читал, ты их, видимо, тщательно отбирал .
Да через раз. Отбирал их не я — отбирали авторы учебного курса на MBA.
G>Правда? Ну расскажи же мне, что же там еще такого есть, в теории менеджмента, чтоб про софтверные метрики (характеризующие software process по своей природе), но при этом ни в коем случае не про этот самый software process.
Открою тайну: метрики бывают вовсе не софтверные. Теоретики менеджмента применяют что-нибудь типа контрольного списка Армстронга или шкалы справедливости Мурмана. В общем курсе менеджмента про софтверные процессы нет вообще ничего. Управление проектами занимает маахонький уголок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
B>>Самое большое влияние на алгоритм и его сложность оказывает выбор концепции.
AVK>Концепции чего?
Концепции решения задачи. Как правило есть выбор метода. И структура данных может здорово повлиять на алгоритм.
B>> При не правильно выбраной концепции сложность может оказаться и бесконечной. Классическая ситуация разбор текста вручную (я называю такое написание программ "в длинну") If-ами или парсером. Пусть даже самодельным.
AVK>И? Что в этой ситуации страшного и почему она классическая?
Например, разбор выражений со скобками. Попробуйте сделать в лоб и с помощью польской записи.
Одна задача, две концепции, один уровень програмиста. Самое то, что нужно для сравнения сложности.
B>> В длину вроде проще писать,
AVK>Проще чем что?
Проще чем подумать, вычленить общности и в новых категориях написать.
B>> но результат очень "тупой"
AVK>Что значит "тупой"?
B>> и не гибкий.
AVK>По сравнению с чем?
B>> С другой стороны написать парсер.. Не то, что бы проще..Но в опытных руках окажется быстрее.
AVK>Парсер написать быстрее чем парсер? Что то у тебя с логикой.
Для приведеной задачи разбора выражений проще самому написать парсер, чем разбирать с помощью if-ов. Хотя я не уверен что проще. Смотря в каком смысле и кому. Собственно в этом и вопрос состоял.
B>> Ну, вообщем понятно.
AVK>Нет.
А сейчас?
Здравствуйте, batu, Вы писали:
AVK>>Концепции чего? B>Концепции решения задачи.
Непонятно.
B> Как правило есть выбор метода. И структура данных может здорово повлиять на алгоритм.
Ну может конечно. Вывод то какой?
AVK>>И? Что в этой ситуации страшного и почему она классическая? B>Например, разбор выражений со скобками. Попробуйте сделать в лоб и с помощью польской записи.
Что "значит" в лоб? Без польской записи пробовал много раз, ужаса не заметил. Более того, с появлением ассоциативности и приоритета операторов польская запись как раз таки обрастает гемороем.
B>Одна задача, две концепции, один уровень програмиста. Самое то, что нужно для сравнения сложности.
Ну так сравни.
B>>> В длину вроде проще писать,
AVK>>Проще чем что?
B>Проще чем подумать, вычленить общности и в новых категориях написать.
В каких таких новых категориях? О каком таком вундеваффе в написании парсера вообще речь?
AVK>>Парсер написать быстрее чем парсер? Что то у тебя с логикой. B>Для приведеной задачи разбора выражений проще самому написать парсер, чем разбирать с помощью if-ов.
Опять непонятно. Большинство практически используемых алгоритмов парсинга это и есть "разбирать с помощью if-ов".
B> Хотя я не уверен что проще.
Прелестно.
AVK>>Нет. B>А сейчас?
Стало еще более непонятным.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
AVK>>>Концепции чего? B>>Концепции решения задачи.
AVK>Непонятно.
Так ниже предложил два варианта. Неужели не понятно что алгоритм будет другой.
B>> Как правило есть выбор метода. И структура данных может здорово повлиять на алгоритм.
AVK>Ну может конечно. Вывод то какой?
Никакого. Ну, кроме того, что алгоритмы будут разными, что должно как-то отразиться на сложности.
AVK>>>И? Что в этой ситуации страшного и почему она классическая? B>>Например, разбор выражений со скобками. Попробуйте сделать в лоб и с помощью польской записи.
AVK>Что "значит" в лоб? Без польской записи пробовал много раз, ужаса не заметил. Более того, с появлением ассоциативности и приоритета операторов польская запись как раз таки обрастает гемороем.
Ассоциативность то как влияет на разбор написанного? А приоритет просто проверяешь и меняешь местами операции. Какой гемор?
B>>Проще чем подумать, вычленить общности и в новых категориях написать.
AVK>В каких таких новых категориях? О каком таком вундеваффе в написании парсера вообще речь?
слово "вундеваффе" не знакомое. Извини.
AVK>>>Парсер написать быстрее чем парсер? Что то у тебя с логикой. B>>Для приведеной задачи разбора выражений проще самому написать парсер, чем разбирать с помощью if-ов.
AVK>Опять непонятно. Большинство практически используемых алгоритмов парсинга это и есть "разбирать с помощью if-ов".
B>> Хотя я не уверен что проще.
AVK>Прелестно.
AVK>>>Нет. B>>А сейчас?
AVK>Стало еще более непонятным.
Ну, и хрен с ним
Если у тебя в руках молоток, все вокруг кажется гвоздями.
Ты упорно говоришь про что то свое, не про то что в статье. Она вообще не о сроках и трудоемкости.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, batu, Вы писали:
AVK>>Непонятно. B>Так ниже предложил два варианта.
Только один, плохой. Причем непонятно какой. Про хороший опять ни слова.
B> Неужели не понятно что алгоритм будет другой.
Какой?
AVK>>Ну может конечно. Вывод то какой? B>Никакого.
Ясно, пустопорожний треп. Я так и подумал.
AVK>>Что "значит" в лоб? Без польской записи пробовал много раз, ужаса не заметил. Более того, с появлением ассоциативности и приоритета операторов польская запись как раз таки обрастает гемороем. B>Ассоциативность то как влияет на разбор написанного?
Напрямую.
B> А приоритет просто проверяешь и меняешь местами операции.
Вообще то в парсерах, которые не рассчитаны на динамическое управление ассоциативностью и приоритетом (а таких большинство), никто местами операторы не меняет, дерево выражения сразу строится с учетом ассоциативности и приоритета.
B> Какой гемор?
Обходные маневры вроде твоей перестановки операторов местами. В хорошем парсере первичное дерево часто вообще иммутабельное.
AVK>>В каких таких новых категориях? О каком таком вундеваффе в написании парсера вообще речь? B>слово "вундеваффе" не знакомое. Извини.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
AVK>>>Непонятно. B>>Так ниже предложил два варианта.
AVK>Только один, плохой. Причем непонятно какой. Про хороший опять ни слова.
B>> Неужели не понятно что алгоритм будет другой.
AVK>Какой?
Другой. Там таки два подхода было предложено.
AVK>>>Ну может конечно. Вывод то какой? B>>Никакого.
AVK>Ясно, пустопорожний треп. Я так и подумал.
Ага. Тема для обсуждения. Я не знал что тут без выводов нельзя высказываться.
AVK>>>Что "значит" в лоб? Без польской записи пробовал много раз, ужаса не заметил. Более того, с появлением ассоциативности и приоритета операторов польская запись как раз таки обрастает гемороем. B>>Ассоциативность то как влияет на разбор написанного?
AVK>Напрямую.
B>> А приоритет просто проверяешь и меняешь местами операции.
AVK> Вообще то в парсерах, которые не рассчитаны на динамическое управление ассоциативностью и приоритетом (а таких большинство), никто местами операторы не меняет, дерево выражения сразу строится с учетом ассоциативности и приоритета.
B>> Какой гемор?
AVK>Обходные маневры вроде твоей перестановки операторов местами. В хорошем парсере первичное дерево часто вообще иммутабельное.
Какое дерево? Оно только в теории рисуется. Цепочка текста сразу превращается в польскую форму, и никаких деревьев. Так в польской записи и подается на вычисление. Причем тут ассоциативность? Как выражение написано так и выполняется. Оптимизация? Так какие проблемы? И каким боком тут иммутабельность несуществующего дерева?
AVK>>>В каких таких новых категориях? О каком таком вундеваффе в написании парсера вообще речь? B>>слово "вундеваффе" не знакомое. Извини.
AVK>http://lurkmore.ru/%D0%92%D1%83%D0%BD%D0%B4%D0%B5%D1%80%D0%B2%D0%B0%D1%84%D0%BB%D1%8F
Здравствуйте, batu, Вы писали:
AVK>>Какой? B>Другой.
B> Там таки два подхода было предложено.
Не заметил.
AVK>>Обходные маневры вроде твоей перестановки операторов местами. В хорошем парсере первичное дерево часто вообще иммутабельное. B>Какое дерево?
AST
B> Оно только в теории рисуется.
Силен, ничего не скажешь. Обратная польская запись, а точнее стековая машина, используется для итерпретации/кодогенерации и некоторх видов анализа. А боевые парсеры на выходе выдают AST, в котором никакой польской записи нет.
B> Цепочка текста сразу превращается в польскую форму, и никаких деревьев.
И этот человек еще пытается свой язык реализовать. Бегом читать книжки хотя бы.
B> Так в польской записи и подается на вычисление. Причем тут ассоциативность?
Ассоциативность определяет, каким образом строится дерево выражений. Левоассоциативные операторы на одноприоритетной цепочке формируют дерево вложенных выражений слева, правоассоциативные справа.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, batu, Вы писали:
AVK>>>Какой? B>>Другой.
AVK>
B>> Там таки два подхода было предложено.
AVK>Не заметил.
Бывает.
AVK>>>Обходные маневры вроде твоей перестановки операторов местами. В хорошем парсере первичное дерево часто вообще иммутабельное. B>>Какое дерево?
AVK>AST
B>> Оно только в теории рисуется.
AVK>Силен, ничего не скажешь. Обратная польская запись, а точнее стековая машина, используется для итерпретации/кодогенерации и некоторх видов анализа. А боевые парсеры на выходе выдают AST, в котором никакой польской записи нет.
B>> Цепочка текста сразу превращается в польскую форму, и никаких деревьев.
Я только про выражения.
AVK>И этот человек еще пытается свой язык реализовать. Бегом читать книжки хотя бы.
У меня дерево строится но, малость по другому. В узлах создается объект класса Production с именем понятия определенного грамматикой. Потому на выражения выхожу при разборе сразу, и дальше уже так как написал. А остальное так деревом и идет на выполнение еще одного этапа компиляции на создание объектов- результата трансляции. В частности объектов-инструкций. Процесс создания объектов — результата трансляции задается операторами при описании грамматики. Таким образом, значение свойств создаваемого объекта идет под управлением грамматики, а класс, имя и реализация создается на основе общего синтаксиса. Так и получается конвертируем из объектов в объекты. Лексический разбор идет перед синтаксичекским отдельно. Там разбор линейный и деревья ни к чему потому как LL(R) грамматика.
B>> Так в польской записи и подается на вычисление. Причем тут ассоциативность?
AVK>Ассоциативность определяет, каким образом строится дерево выражений. Левоассоциативные операторы на одноприоритетной цепочке формируют дерево вложенных выражений слева, правоассоциативные справа.
Как уже написал, приоритеты понятно, а ассоциациативность..не въехал в необходимость. Растолкуй.
Здравствуйте, batu, Вы писали:
B>>> Цепочка текста сразу превращается в польскую форму, и никаких деревьев. B>Я только про выражения.
Выражения тоже отображаются в AST. Не строится дерево только в игрушечных интерпретаторах.
AVK>>Ассоциативность определяет, каким образом строится дерево выражений. Левоассоциативные операторы на одноприоритетной цепочке формируют дерево вложенных выражений слева, правоассоциативные справа. B>Как уже написал, приоритеты понятно, а ассоциациативность..не въехал в необходимость. Растолкуй.
Здравствуйте, Gaperton, Вы писали:
G>Простейший пример — так называемый EV-Plan.
G>Составил план работ. Нарисовал кривую — общее количество (нарастающим итогом) закрытых задач понедельно, на основании плана. И каждую неделю наносишь на этот же график новую точку фактической кривой — с общим количеством фактически закрытых задач.
... G>Я тебе простейший вариант планирования с учетом метрик дал. Есть другие.
Планирования чего? Архитекутры приложения, или уровня загруженности конвеера(массива разработчиков), с целью уменьшения простоев и слабых мест.
А если надо определиться в том что использовать WPF или WinForms. Или боле того, надо писать подобную библиотеку. Какую архитектуру выбрать как у WinForms или как WPF. Планирование уровня загруженности разработчиков уже будет недостаточно?
Здравствуйте, minorlogic, Вы писали:
>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
Что именно бред? Ты не сталкивался с "перетягиванием одеяла" в софтостроении? Когда улучшить какой то показатель можно только ухудшив что-то другое.
Так вот, даже в математике есть закон сохранения сложности (ну пусть будет "закон сохранения одеяла"). Хотя не в той математике где теоремы доказывают, а где конкретные прикладные проблемы решают. И перетягивание одеяла там совсем по другому поводу.
Сам факт что существуют методы: аналитические,асимптотические,численные,экспериментальные. Говорит что каждый плох и хорош по своему. Выбрав один что-то выиграешь и что-то проиграешь.
И даже в асимптотических методах присутствует перетягивание одеяла:
(Р.Баранцев)
Асимптотология — искусство обращения с прикладными математическими системами в предельных случаях; наука о синтезе простоты и точности за счёт локализации.
В качестве первого приближения проще всего назвать асимптотическими методами те, что приспособлены для исследования асимптотических явлений. Однако их содержание таким путем еще не раскрывается. Цель асимптотического подхода заключается в упрощении предмета исследования. Это упрощение достигается за счет уменьшения окрестности рассматриваемой особенности. Причем характерно, что вместе с такой локализацией возрастает и точность асимптотических представлений.
Точность и простота обычно встречаются как понятия противоположные, дополнительные. Стремясь к простоте, мы жертвуем точностью; добиваясь точности, не ждем простоты. Однако при локализации эти антиподы сходятся, противоречие разрешается, снимается в синтезе, имя которому — асимптотика [Баранцев].
Итак, суть асимптотических методов состоит в том, что они осуществляют синтез простоты и точности за счет локализации: в окрестности некоторого предельного состояния находится упрощенное решение задачи, которое тем точнее, чем меньше эта окрестность. Как отмечал еще Лаплас, асимптотические методы тем точнее, чем нужнее. Действительно, потребность в них появляется там, где глобальные методы не срабатывают, но именно там, в окрестности особенностей, они и наиболее эффективны.
Согласованное взаимодействие этих трех компонент образует очевидную целостность. Следовательно, триаду точность—локальность—простота можно рассматривать как определение асимптотической методологии .
. Единственный эффективный способ сделать работу быстрее — не делать лишней работы.
Вообще то в парсерах, которые не рассчитаны на динамическое управление ассоциативностью и приоритетом (а таких большинство), никто местами операторы не меняет, дерево выражения сразу строится с учетом ассоциативности и приоритета.
