Сталкивался со многим.

Почитайте Мак коннелла что ли ? там все просто легко , в описательной форме без пафоса.

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

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

M>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...

IT>Надеюсь ты в обморок от переизбытка чувств не упал как князь Мышкин? Ну вот и славно.

Я польщен что ты заюотишься о моей личности спасибо.

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

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

M>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."

M>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...

G>Один ошибочный вывод не делает бредом всю статью. В конце концов, непрерывно нести бред очень тяжело. Почти так же тяжело, как и все время говорить истину, и только истину . Если предмет статьи содержателен, конечно.

Конечно нет , но уровень статьи сразу понижает. Может все же Мак Коннелла почитать? без шуток ? Ну уже классика, пока не стареющая.

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

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

M>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."

M>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
B>Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.

Если точного нет , тогда и не стоит спекулировать ? Практично , прагматично , без пафоса.

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

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

B>>>> Цепочка текста сразу превращается в польскую форму, и никаких деревьев.
B>>Я только про выражения.

AVK>Выражения тоже отображаются в AST. Не строится дерево только в игрушечных интерпретаторах.

AVK>>>Ассоциативность определяет, каким образом строится дерево выражений. Левоассоциативные операторы на одноприоритетной цепочке формируют дерево вложенных выражений слева, правоассоциативные справа.
B>>Как уже написал, приоритеты понятно, а ассоциациативность..не въехал в необходимость. Растолкуй.

AVK>http://ru.wikipedia.org/wiki/%D0%90%D1%81%D1%81%D0%BE%D1%86%D0%B8%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D1%81%D1%82%D1%8C
Скажу прямо. Редко встретишь специалиста в этой области. Но и в других тоже. Каждый по своему силен, и уважаем. Но почему надо молится на Ахо, или Алана.. У вас же есть такие же мозги. Почему вы не видите что они предлагают только часть своего пути. Дорога впереди открыта, при всем уважении. Ну, я сделал по другому. Где-то проще. Где-то сложней. Но это продолжение пути. Потому что до сих пор не понимаю чем поможет ассоциативность. Для оптимизации? Соглашусь. Хотя не понял. Но моя фишка не в том. А в том, что грамматику можно и нужно определить (и постороить компилятор) для любых объектов, а не только для букв (которые сейчас и не объекты.. а что-то левое, заданное где-то и кем-то сверху). Мне кажется, что современные требования объектного программирования ставят задачи шире. Да. У меня не все красиво. Но работает. Я бы хотел здесь посоветоваться, а не получать ссылки на столпов. Конечно, читал. Да, у меня по другому. Вот это и давайте обсуждать. Или критиковать. Фух.. Извините. Тема совсем не та.. Прорвало..

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

M>Почитайте Мак коннелла что ли ? там все просто легко , в описательной форме без пафоса.
Надо наверное дочитать. Но тяжело он читается, я начинал и забросил не доходя до 100 cтр.
Слишком много воды. Вроде текст есть, а вроде как и нету ничего. Создается впечатление что у автора по делу страниц 20 а растянул их на 800. Что-то интересное наверняка должно быть, знать бы только где искать.
Чтобы найти что-то интересное надо в тысячный раз снова узнать что "Объекты могут поддерживать самые разные операции".

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

— действия, которые каждый объект может выполнять над другими объектами;
— части каждого объекта, видимые другим объектам, т. е. открытые и закрытые
части;
— открытый интерфейс каждого объекта.
Эти часто повторяющиеся действия не обязательно выполнять в указанном по-
рядке. Помните о важности итерации.
Определите объекты и их атрибуты В основе создания программ обычно
лежат сущности реального мира. Например, система расчета повременной опла-
ты может быть основана на таких сущностях, как сотрудники, клиенты, карты учета
времени и счета (рис. 5-6).

Определить атрибуты объектов не сложнее, чем сами объекты. Каждый объект имеет
характеристики, релевантные для компьютерной программы. Скажем, в системе
расчета повременной оплаты объект «сотрудник» обладал бы такими атрибутами,
как имя/фамилия, должность и уровень оплаты. С объектом «счет» были бы свя-
заны такие атрибуты, как сумма, имя/фамилия клиента, дата и т. д.
Объектами системы GUI были бы разнообразные окна, кнопки, шрифты и инст-
рументы рисования. При дальнейшем изучении проблемной области вы можете
прийти к выводу, что установление однозначного соответствия между объектами
программы и объектами реального мира — не самый лучший способ определе-
ния объектов, но для начала он тоже неплох.
Определите действия, которые могут быть выполнены над каждым
объектом. Объекты могут поддерживать самые разные операции. В нашей сис-
теме расчета оплаты объект «сотрудник» мог бы поддерживать изменение долж-
ности или уровня оплаты, объект «клиент» — изменение реквизитов счета и т. д.
Определите действия, которые каждый объект может выполнять над
другими объектами Суть этого этапа ясна из его названия. Двумя универсаль-
ными действиями, которые объекты могут выполнять друг над другом, являются
включение (containment) и наследование. Какие объекты могут включать другие
(какие?) объекты? Какие объекты могут быть унаследованными от других (каких?)
объектов? На рис. 5-6 объект «карта учета времени» может включать объект «со-
трудник» и объект «клиент», а объект «счет» может включать карты учета време-
ни. Кроме того, счет может сообщать, что клиент оплатил услуги, а клиент —
оплачивать указанную в счете сумму. Более сложная система включала бы допол-
нительные взаимодействия.

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

B>Скажу прямо. Редко встретишь специалиста в этой области. Но и в других тоже. Каждый по своему силен, и уважаем. Но почему надо молится на Ахо, или Алана..

Молиться не надо. Но и велосипеды кривоколесные изобретать тоже не стоит.

B>Потому что до сих пор не понимаю чем поможет ассоциативность.

Что значит поможет? Язык, в котором нет ассоциативности операторов, не нужен никому. А вот если ассоцитативность есть, то сформировать без дерева, сразу из лексем стековую нотацию будет весьма непросто, да и не нужно никому.

B>А в том, что грамматику можно и нужно определить (и постороить компилятор) для любых объектов, а не только для букв

Каких букв? Ну почитай хоть что нибудь про теорию формальных грамматик, что ты с таким упорством какую то пургу сюда пишешь?

B> (которые сейчас и не объекты.. а что-то левое, заданное где-то и кем-то сверху). Мне кажется, что современные требования объектного программирования ставят задачи шире. Да. У меня не все красиво. Но работает. Я бы хотел здесь посоветоваться, а не получать ссылки на столпов. Конечно, читал.

Не заметно. Ну или читал, не понимая что написано.

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

G>Из этого следует три возможных вывода — либо ты ничего в IBM не писал, либо — тщательно проектировал и тестировал свой код, либо твоим кодом никто не пользовался и багов не репортил. Проверяется, что именно из тех — элементарно.

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

G>Не понял — и зачем мне на что-то умножать свою трудоемкость?

Ну подели. Тоже интересный результат получится

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

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

G>>Простейший пример — так называемый EV-Plan.

G>>Составил план работ. Нарисовал кривую — общее количество (нарастающим итогом) закрытых задач понедельно, на основании плана. И каждую неделю наносишь на этот же график новую точку фактической кривой — с общим количеством фактически закрытых задач.
S_>...
G>>Я тебе простейший вариант планирования с учетом метрик дал. Есть другие.

S_>Планирования чего? Архитекутры приложения, или уровня загруженности конвеера(массива разработчиков), с целью уменьшения простоев и слабых мест.
S_>А если надо определиться в том что использовать WPF или WinForms. Или боле того, надо писать подобную библиотеку. Какую архитектуру выбрать как у WinForms или как WPF. Планирование уровня загруженности разработчиков уже будет недостаточно?
Ты откуда планирование загруженности взял?

Давай так. Лично ты на основании чего будешь делать выбор WinForms или WPF?

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

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

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

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

IT>>А принимая решение повернуть налево или направо ты каким прибором пользуешься, спидометром или тахометром?
G>Выбирая маршрут — наручными часами, показывающими текущее время, и данными по средней скорости потока на карте, которые выдает навигатор в виде цветных линий.

Не верю... Хотя почему не верю. Вполне очень даже может быть. Хотя я так не делаю.

Ручными (да вообще никакими) часами для выбора маршрута я не пользуюсь. В точном времени, например, если поеду направо, то приеду в 17:00, а если налево, то в 17:10, для меня ценной информации только то, что если поеду направо, то приеду быстрее. И даже не важно на сколько. С другой стороны даже в этом случае я могу поехать налево, просто потому, что самый быстрый путь не самый удобный, комфортный и дешовый. Направо можно доехать быстрее, но по светофорам, а налево медленнее, но по шоссе. Ещё и бензин можно сэкономить. К тому же налево я буду проезжать через чудесные места и наслаждаться прекрасным видом. А ещё по пути можно заскочить в цветочный магазин и купить жене цветы и 10 минут как-бы потерянного времени, сэкономят мне пол часа взаимных упрёков, которые удасться избежать при наличии букета. Надеюсь, понимаешь к чему вся эта лирика.

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

IT>>Судя по всему мы с тобой говорим о разных вещах. Ну правда, мне не интересна тема управления проектами в рамках данной статьи.
G>Я обсуждаю именно сложность, а не "управление проектами". И говорить о сложности вне связи со временем и объемом, т.е. наблюдаемыми характеристиками работы и ее результата — не интересно уже мне. Ибо сие есть метафизика.

Это не матафизика, это объективная реальность. Кроме сроков и человеко часов есть ещё много разных бенефитов. Некоторые из них можно даже свести ко времени, но только это будет другое время. Ну, например, как оторванная неделя от текущего проекта и потраченная на разработку универсального компонента сегодня может помочь сэкономить тебе месяцы работы в будущем. Как можно сравнивать эти времена?

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

IT>>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.
G>Анализ предыдущего опыта (не только своего) помогает принимать решения.

Опыт вообще-то как раз из области метафизика, как говорит уважаемый Гапертон. Да и помогает он только не делать ошибок, которые уже были сделаны ранее, т.е. осечь заведомо плохие варианты. Найти наиболее оптимальное решение в совершенно новой ситуации он не помогает.

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

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

G>А вот "весовую функцию" которая выполняет оценку в твоей голове, формализовать на все случаи жизни не просто невозможно, но просто бессмысленно и не нужно. Это есть тот самый уникальный "творческий" компонент. И это основной момент в работе с метриками, который ты почему-то отказываешься понимать. Пойми.

Видишь ли в чём дело. Время для меня хотя и ценный ресурс, но вовсе не дефицитный. Конечно, у нас бывают авралы и бывают проекты, которые внедряются и интенсивно начинают использоваться будучи в готовности лишь на 70% (прямо как здесь), но в целом времени у меня предостаточно. Соответственно это время я могу конвертировать во что-то другое, не менее ценное, а иногда и гораздо более. Например, в качество кода, в поиск более универсальных решений, в гибкость, в быстродействие, в надёжность, в более грамотный дизайн и т.п. Где-то здесь по ветке ты спросил буду ли я переписывать код, если он не очень, но работает как надо и его не планируется никогда менять. Ответ — возможно, если мне приходится в него часто заглядывать, а его сложность восприятия для меня становится геморроем. В данном случае я обменяю своё время на отсутвие не нужного мне геморроя.

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

G>Вот у тебя кусок кода. У него "высокая сложность", что означает крайне дорогие правки в этот код, даже если правки сами по себе незначительные. Но! Код отлажен, изолирован за годными интерфейсами, отлично работает, и никаких правок туда в ближайшие 5 лет не ожидается.
G>Тебя волнует его сложность? Ты будешь тратить время на то, чтобы его "рефакторить", понижая "сложность"?

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

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

G>Разница в том, что ты отказываешься привязывать свою теорию сложности к объективно измеримым вещам.

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

Ты же как коммерсанты сводят всё в мире к одной мере — деньгам, сводишь всё к срокам и трудоёмкости. С практической точки зрения это совсем не плохо. Но в мире не всё сводится к деньгам, а в программировании не всё сводится к срокам и трудоёмкости.

Кстати, в программировании практически всё сводится к сложности, но не всё к трудоёмкости. Это я к тому, что это не совсем одно и тоже.

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

G>Вопрос некорректен. В любом _проекте_ сроки имеют значение, ибо проект всегда ограничен временем по определению. Не ограничены временем _программа_ и разгильзяйство. Но программа состоит из проектов. А из чего состоит разгильзяйство — мне не интересно.

Думаю, что вот этот никак не ограничен временем.

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

IT>>Здорово. Только я всё не возьму в толк, как мне это поможет выбрать правильный дизайн базы данных? Вот, например, у меня есть форма с гридом, в котором 24 колонки для 24-х месяцев, по 12 на 2 года. Как мне лучше их уложить в базу, как 24 месяца в одну запись или как две записи по 12 месяцев? Какую метрику посоветуешь?

G>Посоветую не морочить людям голову, и перестать выдумывать и писать ерунду.
G>Надоело.

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

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

M>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
B>Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.

Можно даже как к эзотерическому учению Главное, что есть модель, которая работает. Может быть не для всех, может быть не всегда, но в большинстве случаев вполне сносно объясняет суть происходящего. Когда учоные создадут более адекватную модель и опишут сложность универсальными формулами и метриками, то на эту теорию можно будет смело забить. Я сделаю это первый, если доживу

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

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

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

M>>>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."

M>>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
B>>Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.

M>Если точного нет , тогда и не стоит спекулировать ? Практично , прагматично , без пафоса.
Если практично и прагматично, то да. А так нет

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

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

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

G>Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого.
Да. Это так. Может я не могу сформулировать. Но ход мысли такой. Я хочу оперировать более высоким уровнем.Что б в анализе участвовали объекты. Что бы пользователю было легче ориентироваться и создавать свои грамматики. Это никак не противоречит теории, если назначить каждому свойству или значению свойства объекта отдельный символ в классической формулировке. Понятия терминальные и нетерминальные символы убрать. Оставить правила (предикаты), имена которых непосредственно определяют лексему и продукцию. Эти имена тогда будут формулироваться в терминах создаваемого языка, что опять таки будет семантически ближе пользователю. Напрямую в общем случае это не получается. Иногда возникает необходимость в промежуточных (вспомогательных) правилах не создающих ни лексему ни продукцию. Ну, и у меня получилось так сделать. Т.е. построение грамматики стало возможно в общей концепции языка. Не надо никаких регекспов и вводить новые понятия. Вот туда я и веду. И с теорией противоречия нет. Фактически те же алгоритмы восходящий для лексики и нисходящий для синтаксиса. Просто другое представление. Я бы сравнил с машиной Тьюринга. Вещь хорошая для доказательств, но для реального создания программ мало подходящая. Так и теорию грамматик. Вещь хорошая, но для широкого использования надо бы формулировать в терминах ООП. Что я и пытаюсь сделать.