Здравствуйте, DarkGray, Вы писали:
DG>достаточно сказать — да, я, undying — индус и мне пофигу как там ваши языки устроены, на каких принципах построены, и какая часть общества их будет делать.
Цивилизация базируются на том, что для успешного использования инструмента нет необходимости знать процесс разработки этого инструмента. Без этого было бы невозможно разделение труда, а, значит, и решение мало-мальски масштабных задач. Соответственно знание прикладным разработчиком деталей разработки языков вовсе не увеличивает его эффективность при решении прикладных задач. Поэтому пока я занимаюсь прикладным программированием разработка языков меня интересует лишь в том плане, что я заинтересован в том, чтобы языки создавались для прикладных программистов, а не для академических мечтателей и не для попильщиков грантов.
зы
Полагать, что все прикладные разработчики это индусы, а все разработчики языков это белая кость, это расистская глупость.
U>Полагать, что все прикладные разработчики это индусы, а все разработчики языков это белая кость, это расистская глупость.
и опять ты вдарился в крайности и навязывание этических оценок.
речь идет лишь о самоидентификации на отрезке по понимании теории программирования:
"математик категорий"(haskell) <----------------------------------------------------------------------------------> "индус"(excel)
Здравствуйте, gandjustas, Вы писали:
V>>Да ну, может это ты зациклился на том, что существующие инструменты решают все проблемы программиста? G>А я говорил что инструменты решают все проблемы? Я говорил проблемы решаются определенным подходом к проектированию, инструменты лишь помогают иногда.
Ну и как измерить эти "иногда"? И как измерить преимущества одного подхода относительно другого? Пока это только субъективны оценки. на них нельзя делать предположения о новых технологиях, просто потому что нет никакого опыта в этих новых технологиях.
V>>Люди поумнее нас с тобой вместе взятых очень осторожно относятся к этим вопросам. Вот описание с примерами. V>>Хороший дизайн должен быть SOLID: TOP-5 архитектурных принципов V>>http://igor.quatrocode.com/2008/09/solid-top-5.html G> Ты считаешь эту банальщину чем-то важным?
G>Только один формальный принцип есть в этом списке — LSP. Он кстати очень хорошо относится к теме обсуждения. G>В более общей форме он выглядит так:
G>
G>Если тип Q является подтипом T, то предусловия Q должны быть не сильнее предусловий T, а постусловия и инварианты Q должны быть не слабее постусловий T.
G>Пред- и пост- условия — части контрактов.
Согласен. G>Наследование создает отношение тип-подтип.
Согласен.
Не давай подумает про самый тяжелый случай. Меняется функциональность программы. По ссылке рассмотрены именно изменения связанные с функциональностью и примеры к ним. Нововведение состоит в том, что каждое изменение в любой момент можно вернуть обратно. При этом каждое функциональное изменение можно выполнить с применением паттерна или без него. Вот как теперь ты будешь оценивать положительный эффект от новой технологии, дающей возможность в любой момент времени вернуться к предыдущей версии.
С одной стороны, тянуть за собой несколько вариантов реализации одной и той же функциональности явная переработка. Это тяжело, никому не нужно и выполняется либо при обнаружении ошибки. либо при изменении требований, когда Старые версии программы не нужны пользователю.
С другой стороны применение паттернов всегда затуманивает смысл программы и мешает немного применению других паттернов в других местах программы. Паттерны имеют как положительные так и отрицательные стороны и если каждый паттерн применять как если бы он был самым первым и единственным в программе, то это означало бы некоторую экономию работы и упрощение проектирования. Технология позволяет вернуться в версию программы, где задан только дин рассматриваемый паттерн. а остальная часть программы написана кое как.
И как ты тут будешь оценивать если никогда таким не занимался и даже мысленно не можешь представить себе что значит проектирование в таких условиях? Опять навесишь ярлык банальщины?
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Да ну, может это ты зациклился на том, что существующие инструменты решают все проблемы программиста? G>>А я говорил что инструменты решают все проблемы? Я говорил проблемы решаются определенным подходом к проектированию, инструменты лишь помогают иногда.
V>Ну и как измерить эти "иногда"?
Постфактум очень легко померить в SLOC, человекочасах работы, плотности багов итп
Метрик немеряно.
V>И как измерить преимущества одного подхода относительно другого?
Особенно это тяжело когда один подход уже работает, а другой только в голове одного человека существует.
V>Пока это только субъективны оценки. на них нельзя делать предположения о новых технологиях, просто потому что нет никакого опыта в этих новых технологиях.
Тогда нужно на конкретных примерах показать преимущества.
У людей тут достаточно опыта чтобы оценить подход и найти слабые стороны.
Но у тебя проблема в другом. Ты еще не можешь даже показать что твой подход возможен: разложение произвольных изменений на ортогональные.
V>Нововведение состоит в том, что каждое изменение в любой момент можно вернуть обратно.
Это как раз еще не доказано, о дальнейшем говорить бессмысленно.
V>Вот как теперь ты будешь оценивать положительный эффект от новой технологии, дающей возможность в любой момент времени вернуться к предыдущей версии.
Вообще-то такая технология уже есть и называется Source Control, с ветками позволяет делать примерно что ты хочешь.
Чтобы понять что вообще померить тебе надо:
1)Придумать какие проблемы решает твой подход, которые не решаются или плохо решаются другими средствами (с трассировкой требований и контрактами ты уже не угадал)
2)Придумать как люди будут пользоваться подобными инструментами (тут у тебя вообще пусто)
3)Оценить какие недостатки принесет решение
V>применение паттернов всегда затуманивает смысл программы и мешает немного применению других паттернов в других местах программы. Паттерны имеют как положительные так и отрицательные стороны и если каждый паттерн применять как если бы он был самым первым и единственным в программе, то это означало бы некоторую экономию работы и упрощение проектирования. Технология позволяет вернуться в версию программы, где задан только дин рассматриваемый паттерн. а остальная часть программы написана кое как.
Паттерн это тоже код, который тоже надо писать. Ты предложишь писать несколько версий программы для возможности отката?
Тебя пошлют сразу же.
Опять-таки не вижу какую проблему это решает.
V>И как ты тут будешь оценивать если никогда таким не занимался и даже мысленно не можешь представить себе что значит проектирование в таких условиях?
У тебя получается два варианта:
1)Писать заранее разные версии программы. Отметаем сразу же, как повышение трудозатрат без эффекта.
2)Каким-то образом научиться изменения раскладывать на ортогональные. Есть сомнение что это вообще возможно. Надо чтобы инструменты понимали семантику, а такого нет и непонятно когда будет.
То есть оба варианта — потенциально нерабочие. Придумай рабочий пример по схеме выше
Здравствуйте, gandjustas, Вы писали:
V>>>>Да ну, может это ты зациклился на том, что существующие инструменты решают все проблемы программиста? G>>>А я говорил что инструменты решают все проблемы? Я говорил проблемы решаются определенным подходом к проектированию, инструменты лишь помогают иногда.
V>>Ну и как измерить эти "иногда"? G>Постфактум очень легко померить в SLOC, человекочасах работы, плотности багов итп G>Метрик немеряно.
Метрик немеряно, и они все дают различные результаты. Не стоит тупо доверять метрикам. Тем более оценить еще нереализованную технологию ими невозможно.
V>>И как измерить преимущества одного подхода относительно другого? G>Особенно это тяжело когда один подход уже работает, а другой только в голове одного человека существует.
На то этот форум возник.
V>>Пока это только субъективны оценки. на них нельзя делать предположения о новых технологиях, просто потому что нет никакого опыта в этих новых технологиях. G>Тогда нужно на конкретных примерах показать преимущества. G>У людей тут достаточно опыта чтобы оценить подход и найти слабые стороны.
Ага, как Менделееву бросить свои глупости и отсортировать элементы по алфавиту. Ну или Лобачевскому пойти почитать учебник для начинающих. Или пионерам воздухоплавания — делать самолеты с машущими крыльями. Люди очень объективно оценивают все новое.
G>Но у тебя проблема в другом. Ты еще не можешь даже показать что твой подход возможен: разложение произвольных изменений на ортогональные.
Не понял вопроса, зачем что либо раскладывать?
V>>Нововведение состоит в том, что каждое изменение в любой момент можно вернуть обратно. G>Это как раз еще не доказано, о дальнейшем говорить бессмысленно.
?
V>>Вот как теперь ты будешь оценивать положительный эффект от новой технологии, дающей возможность в любой момент времени вернуться к предыдущей версии. G>Вообще-то такая технология уже есть и называется Source Control, с ветками позволяет делать примерно что ты хочешь.
Неверно я сформулировал, не вернуться к предыдущей версии, а отменить любое преобразование. Хранение множество версий тут ничем не поможет. Этого не достаточно.
G>Чтобы понять что вообще померить тебе надо: G>1)Придумать какие проблемы решает твой подход, которые не решаются или плохо решаются другими средствами (с трассировкой требований и контрактами ты уже не угадал)
Трассировка требований в твоем понимании это не та проблема о которой я говорил, я говорил о моем понимании проблемы. Контракты тут вообще не при чем.
G>2)Придумать как люди будут пользоваться подобными инструментами (тут у тебя вообще пусто) G>3)Оценить какие недостатки принесет решение
V>>применение паттернов всегда затуманивает смысл программы и мешает немного применению других паттернов в других местах программы. Паттерны имеют как положительные так и отрицательные стороны и если каждый паттерн применять как если бы он был самым первым и единственным в программе, то это означало бы некоторую экономию работы и упрощение проектирования. Технология позволяет вернуться в версию программы, где задан только дин рассматриваемый паттерн. а остальная часть программы написана кое как. G>Паттерн это тоже код, который тоже надо писать. Ты предложишь писать несколько версий программы для возможности отката? G>Тебя пошлют сразу же. G>Опять-таки не вижу какую проблему это решает.
Вот именно — не видишь, почему же тогда все оценки отрицательны? Если нет понимания зачем, то нельзя делать вывод об отсутствии положительного эффекта. Если оценка явно отрицательна, значит человек должен знать о чем говорит. Нельзя одновременно делать и то и другое.
V>>И как ты тут будешь оценивать если никогда таким не занимался и даже мысленно не можешь представить себе что значит проектирование в таких условиях? G>У тебя получается два варианта: G>1)Писать заранее разные версии программы. Отметаем сразу же, как повышение трудозатрат без эффекта.
Неверно, возможны эффективные приемы сокращения трудозатрат. Кроме того, полностью версию нет резона создавать.
G>2)Каким-то образом научиться изменения раскладывать на ортогональные. Есть сомнение что это вообще возможно. Надо чтобы инструменты понимали семантику, а такого нет и непонятно когда будет.
Это вообще не нужно. Сам программист решает что есть версии, т.е. в какой момент времени остановиться и результат назвать новой версией.
G>То есть оба варианта — потенциально нерабочие. Придумай рабочий пример по схеме выше.
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>>>Да ну, может это ты зациклился на том, что существующие инструменты решают все проблемы программиста? G>>>>А я говорил что инструменты решают все проблемы? Я говорил проблемы решаются определенным подходом к проектированию, инструменты лишь помогают иногда.
V>>>Ну и как измерить эти "иногда"? G>>Постфактум очень легко померить в SLOC, человекочасах работы, плотности багов итп G>>Метрик немеряно. V>Метрик немеряно, и они все дают различные результаты. Не стоит тупо доверять метрикам. Тем более оценить еще нереализованную технологию ими невозможно.
Именно.
V>>>И как измерить преимущества одного подхода относительно другого? G>>Особенно это тяжело когда один подход уже работает, а другой только в голове одного человека существует. V>На то этот форум возник.
Тем не менее не стоит заниматься болтологией.
V>>>Пока это только субъективны оценки. на них нельзя делать предположения о новых технологиях, просто потому что нет никакого опыта в этих новых технологиях. G>>Тогда нужно на конкретных примерах показать преимущества. G>>У людей тут достаточно опыта чтобы оценить подход и найти слабые стороны. V>Ага, как Менделееву бросить свои глупости и отсортировать элементы по алфавиту. Ну или Лобачевскому пойти почитать учебник для начинающих. Или пионерам воздухоплавания — делать самолеты с машущими крыльями. Люди очень объективно оценивают все новое.
Ты не путай себя с менделеевым. Ты не изобретаешь что-то кардинально новое. Ты придумываешь подход для решения проблем, которые уже решаются другими средствами.
G>>Но у тебя проблема в другом. Ты еще не можешь даже показать что твой подход возможен: разложение произвольных изменений на ортогональные. V>Не понял вопроса, зачем что либо раскладывать?
Чтобы обратно возвращать.
V>>>Нововведение состоит в том, что каждое изменение в любой момент можно вернуть обратно. G>>Это как раз еще не доказано, о дальнейшем говорить бессмысленно. V>?
Ты представишь способ автоматически выделить в коде "отдельное изменение" и откатить его?
V>>>Вот как теперь ты будешь оценивать положительный эффект от новой технологии, дающей возможность в любой момент времени вернуться к предыдущей версии. G>>Вообще-то такая технология уже есть и называется Source Control, с ветками позволяет делать примерно что ты хочешь. V>Неверно я сформулировал, не вернуться к предыдущей версии, а отменить любое преобразование.
В этом и суть. Чтобы отменить произвольное изменение надо уметь раскладывать последовательность изменений на независимые (ортогональные).
V>Хранение множество версий тут ничем не поможет. Этого не достаточно.
Почему недостаточно? С ветками — вполне достаточно.
G>>Чтобы понять что вообще померить тебе надо: G>>1)Придумать какие проблемы решает твой подход, которые не решаются или плохо решаются другими средствами (с трассировкой требований и контрактами ты уже не угадал) V>Трассировка требований в твоем понимании это не та проблема о которой я говорил, я говорил о моем понимании проблемы. Контракты тут вообще не при чем.
Так опиши свое понимание проблемы "трассировка требований" без больших цитат из непонятно кого.
G>>2)Придумать как люди будут пользоваться подобными инструментами (тут у тебя вообще пусто) G>>3)Оценить какие недостатки принесет решение
V>>>применение паттернов всегда затуманивает смысл программы и мешает немного применению других паттернов в других местах программы. Паттерны имеют как положительные так и отрицательные стороны и если каждый паттерн применять как если бы он был самым первым и единственным в программе, то это означало бы некоторую экономию работы и упрощение проектирования. Технология позволяет вернуться в версию программы, где задан только дин рассматриваемый паттерн. а остальная часть программы написана кое как. G>>Паттерн это тоже код, который тоже надо писать. Ты предложишь писать несколько версий программы для возможности отката? G>>Тебя пошлют сразу же. G>>Опять-таки не вижу какую проблему это решает.
V>Вот именно — не видишь
Так ты опиши чтобы видели люди. Пока проблема существует только у тебя в голове и решение её тоже. Покажи сначала проблему, а потом придумывай решения.
V>почему же тогда все оценки отрицательны?
Потому что ты увеличиваешь трудозатраты без решения проблем.
V>Если нет понимания зачем, то нельзя делать вывод об отсутствии положительного эффекта.
Любые действия, которые не решают определенных проблем — ненужная работа. Поэтому пока ты не докажешь что существуют проблемы и их надо решать, то действительно не будет никакого положительно эффекта от любого подхода.
V>>>И как ты тут будешь оценивать если никогда таким не занимался и даже мысленно не можешь представить себе что значит проектирование в таких условиях? G>>У тебя получается два варианта: G>>1)Писать заранее разные версии программы. Отметаем сразу же, как повышение трудозатрат без эффекта. V>Неверно
Очень даже верно.
V>возможны эффективные приемы сокращения трудозатрат.
Какие например? В любом случае ты уже повышаешь трудозатраты без решения проблем.
V>Кроме того, полностью версию нет резона создавать.
Какие еще варианты?
Покажи пример как это сделать.
G>>2)Каким-то образом научиться изменения раскладывать на ортогональные. Есть сомнение что это вообще возможно. Надо чтобы инструменты понимали семантику, а такого нет и непонятно когда будет. V>Это вообще не нужно. Сам программист решает что есть версии, т.е. в какой момент времени остановиться и результат назвать новой версией.
Ок, этот отбрасываем.
Здравствуйте, gandjustas, Вы писали:
V>>>>И как измерить преимущества одного подхода относительно другого? G>>>Особенно это тяжело когда один подход уже работает, а другой только в голове одного человека существует. V>>На то этот форум возник. G>Тем не менее не стоит заниматься болтологией.
А что сам посоветуешь в качестве средства повышения абстрактности ЯВУ?
V>>>>Пока это только субъективны оценки. на них нельзя делать предположения о новых технологиях, просто потому что нет никакого опыта в этих новых технологиях. G>>>Тогда нужно на конкретных примерах показать преимущества. G>>>У людей тут достаточно опыта чтобы оценить подход и найти слабые стороны. V>>Ага, как Менделееву бросить свои глупости и отсортировать элементы по алфавиту. Ну или Лобачевскому пойти почитать учебник для начинающих. Или пионерам воздухоплавания — делать самолеты с машущими крыльями. Люди очень объективно оценивают все новое. G>Ты не путай себя с менделеевым. Ты не изобретаешь что-то кардинально новое. Ты придумываешь подход для решения проблем, которые уже решаются другими средствами.
ЧЕм визуализируются несколько декомпозиций программы на части? И чтоб показывало при каких декомпозициях какие части нужно изменить и как?
G>>>Но у тебя проблема в другом. Ты еще не можешь даже показать что твой подход возможен: разложение произвольных изменений на ортогональные. V>>Не понял вопроса, зачем что либо раскладывать? G>Чтобы обратно возвращать.
Не обязательно, в случае неалгоритмизируемых процедур есть только вход и выход, середины нет.
V>>>>Нововведение состоит в том, что каждое изменение в любой момент можно вернуть обратно. G>>>Это как раз еще не доказано, о дальнейшем говорить бессмысленно. V>>? G>Ты представишь способ автоматически выделить в коде "отдельное изменение" и откатить его?
Автоматической выделялки — нет, откатить — да (автоматически).
V>>>>Вот как теперь ты будешь оценивать положительный эффект от новой технологии, дающей возможность в любой момент времени вернуться к предыдущей версии. G>>>Вообще-то такая технология уже есть и называется Source Control, с ветками позволяет делать примерно что ты хочешь. V>>Неверно я сформулировал, не вернуться к предыдущей версии, а отменить любое преобразование. G>В этом и суть. Чтобы отменить произвольное изменение надо уметь раскладывать последовательность изменений на независимые (ортогональные).
Аналитической записи преобразований не существует (исключая простейшие случаи), потому нельзя разложить то чего нет. Наоборот есть куча конкретных преобразований, путь обобщения их всех в одном преобразовании использует К-системы основанные на пропо(каких-то)зационных правилах. Для любой входной версии есть версия преобразованная. Только таким отношением функция и задается и только так и может создаться. Потому не общая аналитическая формулировка раскладывается на множество конкретных преобразований, а наоборот — множество конкретных преобразований объединяются создавая обобщенное преобразование.
V>>Хранение множество версий тут ничем не поможет. Этого не достаточно. G>Почему недостаточно? С ветками — вполне достаточно.
Да хоть с рогами и копытами — не достаточно.
G>>>Чтобы понять что вообще померить тебе надо: G>>>1)Придумать какие проблемы решает твой подход, которые не решаются или плохо решаются другими средствами (с трассировкой требований и контрактами ты уже не угадал) V>>Трассировка требований в твоем понимании это не та проблема о которой я говорил, я говорил о моем понимании проблемы. Контракты тут вообще не при чем. G>Так опиши свое понимание проблемы "трассировка требований" без больших цитат из непонятно кого.
Зачем?
V>>Вот именно — не видишь G>Так ты опиши чтобы видели люди. Пока проблема существует только у тебя в голове и решение её тоже. Покажи сначала проблему, а потом придумывай решения.
Не получиться так просто.
V>>>>И как ты тут будешь оценивать если никогда таким не занимался и даже мысленно не можешь представить себе что значит проектирование в таких условиях? G>>>У тебя получается два варианта: G>>>1)Писать заранее разные версии программы. Отметаем сразу же, как повышение трудозатрат без эффекта. V>>Неверно G>Очень даже верно.
Неверно.
G>Покажи пример как это сделать.
Неа. Сам говорил, пока непонятна проблема и непонятно ее решение, то пример демонстрировать это уже совсем извращенцем нужно быть.
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>>>И как измерить преимущества одного подхода относительно другого? G>>>>Особенно это тяжело когда один подход уже работает, а другой только в голове одного человека существует. V>>>На то этот форум возник. G>>Тем не менее не стоит заниматься болтологией. V>А что сам посоветуешь в качестве средства повышения абстрактности ЯВУ?
ИМХО чем более высокоуровнева абстракция, тем она более проблемно-ориентирована.
Самые высокоуровневые языки — DSL. При этом они наиболее бесполезны в общем программировании.
Хороший язык должен иметь возможность создавать DSL, при этом должен иметь широкий инструментарий компиляции этих DSL, от pre-compile time до runtime с единым API.
V>>>>>Пока это только субъективны оценки. на них нельзя делать предположения о новых технологиях, просто потому что нет никакого опыта в этих новых технологиях. G>>>>Тогда нужно на конкретных примерах показать преимущества. G>>>>У людей тут достаточно опыта чтобы оценить подход и найти слабые стороны. V>>>Ага, как Менделееву бросить свои глупости и отсортировать элементы по алфавиту. Ну или Лобачевскому пойти почитать учебник для начинающих. Или пионерам воздухоплавания — делать самолеты с машущими крыльями. Люди очень объективно оценивают все новое. G>>Ты не путай себя с менделеевым. Ты не изобретаешь что-то кардинально новое. Ты придумываешь подход для решения проблем, которые уже решаются другими средствами. V>ЧЕм визуализируются несколько декомпозиций программы на части? И чтоб показывало при каких декомпозициях какие части нужно изменить и как?
А это тут при чем? Ты же говорил про трассировку требований и контракты. А "визуализация декомпозиции" это твоя идея, которая еще понятно зачем нужна и как будет делаться. Скорее всего никак.
V>>>>>Нововведение состоит в том, что каждое изменение в любой момент можно вернуть обратно. G>>>>Это как раз еще не доказано, о дальнейшем говорить бессмысленно. V>>>? G>>Ты представишь способ автоматически выделить в коде "отдельное изменение" и откатить его? V>Автоматической выделялки — нет, откатить — да (автоматически).
Значит придется ортогонализировать изменения руками.
Вот у меня есть репозитарий на тысячу коммитов.
Как мне сделать так чтобы я мог откатить коммит номер один и не откатывать коммит номер 1000? При этом каждый следующий коммит потенциально зависит от предыдущего.
V>>>>>Вот как теперь ты будешь оценивать положительный эффект от новой технологии, дающей возможность в любой момент времени вернуться к предыдущей версии. G>>>>Вообще-то такая технология уже есть и называется Source Control, с ветками позволяет делать примерно что ты хочешь. V>>>Неверно я сформулировал, не вернуться к предыдущей версии, а отменить любое преобразование. G>>В этом и суть. Чтобы отменить произвольное изменение надо уметь раскладывать последовательность изменений на независимые (ортогональные). V>Аналитической записи преобразований не существует (исключая простейшие случаи), потому нельзя разложить то чего нет. Наоборот есть куча конкретных преобразований, путь обобщения их всех в одном преобразовании использует К-системы основанные на пропо(каких-то)зационных правилах. Для любой входной версии есть версия преобразованная. Только таким отношением функция и задается и только так и может создаться. Потому не общая аналитическая формулировка раскладывается на множество конкретных преобразований, а наоборот — множество конкретных преобразований объединяются создавая обобщенное преобразование.
Ну так у тебя почти всегда будет "обобщенное преобразование" {пусто} => {программа}, что оно тебе даст?
V>>>Хранение множество версий тут ничем не поможет. Этого не достаточно. G>>Почему недостаточно? С ветками — вполне достаточно. V>Да хоть с рогами и копытами — не достаточно.
Докажи.
Ты все еще не привел ту проблему, которую ты пытаешься решить.
G>>>>Чтобы понять что вообще померить тебе надо: G>>>>1)Придумать какие проблемы решает твой подход, которые не решаются или плохо решаются другими средствами (с трассировкой требований и контрактами ты уже не угадал) V>>>Трассировка требований в твоем понимании это не та проблема о которой я говорил, я говорил о моем понимании проблемы. Контракты тут вообще не при чем. G>>Так опиши свое понимание проблемы "трассировка требований" без больших цитат из непонятно кого. V>Зачем?
Без решаемых проблем любые действия никто не будет делать. Тупо менеджеры не позволят.
V>>>Вот именно — не видишь G>>Так ты опиши чтобы видели люди. Пока проблема существует только у тебя в голове и решение её тоже. Покажи сначала проблему, а потом придумывай решения. V>Не получиться так просто.
Значит ты зря это все пишешь.
Здравствуйте, DarkGray, Вы писали:
DG>речь идет лишь о самоидентификации на отрезке по понимании теории программирования: DG>"математик категорий"(haskell) <----------------------------------------------------------------------------------> "индус"(excel)
DG>вот ты undying где себя позиционируешь?
Нигде не позиционирую, потому что эта шкала выдает сложность инструмента за добродетель.
Высококлассный инженер это тот, кто способен решить поставленную задачу максимально простым образом. А для того, чтобы при решении задач использовать заумный инструмент много ума не надо.
Здравствуйте, DarkGray, Вы писали:
V>>Аналитической записи преобразований не существует (исключая простейшие случаи) DG>почему?
Хотел бы я чтобы было четкое определение неалгоритмических процедур. Вот тогда бы можно было сказать почему. А ток только можно констатировать факт — не получается.
Видимо потому, что разные преобразования применяют разные проектные решения, потому их обобщать не совсем корректно. НАпример, есть программа S00 мы ее изменили удалив некоторую функциональность F1 получив S01, затем далее изменили добавив другую функциональность F2 до версии S11.
S00(F1) -a0-> S01() -b0-> S11(F2)
Попытавшись обобщить преобразования мы можем столкнуться с серьезной проблемой в версии S10:
S00(F1) -b1-> S10(F1,F2) -a1-> S11(F2)
Возможно функции F1 и F2 взаимоисключающие или конфликтуют друг с другом. Потому для получения версии S10 потребуется в 10 раз больше времени и сил потратить чем для любой другой версии. При этом обобщение преобразований представляет собой множество конкретных преобразований a=[a0,a1] b=[b0,b1], которые даже назвать одним определением затруднительно, не говоря уже про существования единого алгоритма для всех частных преобразований.
Здравствуйте, gandjustas, Вы писали:
V>>А что сам посоветуешь в качестве средства повышения абстрактности ЯВУ? G>ИМХО чем более высокоуровнева абстракция, тем она более проблемно-ориентирована. G>Самые высокоуровневые языки — DSL. При этом они наиболее бесполезны в общем программировании. G>Хороший язык должен иметь возможность создавать DSL, при этом должен иметь широкий инструментарий компиляции этих DSL, от pre-compile time до runtime с единым API.
Слышал о технологии 4+1, там для программной системы было одновременно 4 разных представления. В первом — диаграммы наследования объектов, во второй диаграммы взаимодействия, в третей какой объект в каком файле и модуле хранится, в четвертой еще что-то чего нет в предыдущих. Такой подход давал гораздо более удобное представление. чем одно единственное описание. То есть было как минимум 4 разных способа декомпозиции исходной программной системы на части, каждый из которых ориентирован на наглядное представление проблем и связанных с ними проектных решений. При этом все уровни частично перекрывались и нужно было корректировать и отслеживать зависимости между этими разными представлениями одной и той же системы. При этом в рамках каждого из них редактирование и внесение изменений предполагалось независимым. Какие абстракции выносить на верхний уровень, а какие оставлять на нижнем зависит от решаемой задачи. Сейчас языки поддерживают один единственный способ распределения абстракций по уровням абстракции, потому поддержка одновременно нескольких способов распределения абстракций по абстрактным уровням серьезно помогает в проектировании. Но это трудно реализовать.
V>>ЧЕм визуализируются несколько декомпозиций программы на части? И чтоб показывало при каких декомпозициях какие части нужно изменить и как? G>А это тут при чем? Ты же говорил про трассировку требований и контракты. А "визуализация декомпозиции" это твоя идея, которая еще понятно зачем нужна и как будет делаться. Скорее всего никак.
Проблема не в том "как", а в том что сейчас вообще "никак".
G>>>Ты представишь способ автоматически выделить в коде "отдельное изменение" и откатить его? V>>Автоматической выделялки — нет, откатить — да (автоматически). G>Значит придется ортогонализировать изменения руками. G>Вот у меня есть репозитарий на тысячу коммитов. G>Как мне сделать так чтобы я мог откатить коммит номер один и не откатывать коммит номер 1000? При этом каждый следующий коммит потенциально зависит от предыдущего.
Вот об этом и речь, каждый коммит может быть и не сложным и откатывается чуть ли не автоматом. Но вот после 2, 3 и 1000 откатить 1 коммит назад — это учесь кучу нюансов, как минимум просмотреть 999 коммитов и выяснить не возникнет ли конфликта. Это задача порядка 2^1000 сложности, с реализаций функций то же самое, если мы подряд изменили тела 10 функций, то вернуть назад реализацию первой из них не тривиальная задача. Потому поддержка суперпозиции любых изменений в программной системе отпугивает всех теоретиков заранее и навсегда :). Но тут есть нюансы, существуют инварианты структурных преобразований, хотя это противоречит схемам Янова, но согласуется с Диакоптикой Габриэля Крона.
V>>>>Неверно я сформулировал, не вернуться к предыдущей версии, а отменить любое преобразование. G>>>В этом и суть. Чтобы отменить произвольное изменение надо уметь раскладывать последовательность изменений на независимые (ортогональные). V>>Аналитической записи преобразований не существует (исключая простейшие случаи), потому нельзя разложить то чего нет. Наоборот есть куча конкретных преобразований, путь обобщения их всех в одном преобразовании использует К-системы основанные на пропо(каких-то)зационных правилах. Для любой входной версии есть версия преобразованная. Только таким отношением функция и задается и только так и может создаться. Потому не общая аналитическая формулировка раскладывается на множество конкретных преобразований, а наоборот — множество конкретных преобразований объединяются создавая обобщенное преобразование. G>Ну так у тебя почти всегда будет "обобщенное преобразование" {пусто} => {программа}, что оно тебе даст?
Примитивную систему координат :)
1) Любая функциональность, объект или проектное решение могут быть определены через преобразование(изменение в тексте программы):
Программа(без них) --> Программа(с ними)
2) Любые ... могут рассматриваться в примитивной системе координат:
Программа(с ними) <--> Минимальная программа (с ними) <-- Почти ничего (с ними)
3) Знаком с концепцией "Генетическое описание"? В теоретической физике можно считать общепризнанным преимущество генетического описания проблемы перед любыми другими способами описания. А это и есть определение в терминах изменений и через изменения.
Проблема только в том, что для всего вышеперечисленного нужны обобщенные преобразования, т.е. для которых ортогональность гарантирована.
V>>>>Хранение множество версий тут ничем не поможет. Этого не достаточно. G>>>Почему недостаточно? С ветками — вполне достаточно. V>>Да хоть с рогами и копытами — не достаточно. G>Докажи. G>Ты все еще не привел ту проблему, которую ты пытаешься решить.
Как только научное сообщество придумает название для нее я первым делом сообщу всему RSDN-у об этом. Щас попробую, было у одного философа прикольная формулировочка — проблема искусственной абстрактной акселерации или как то похоже :):):):):):)
V>>>>Трассировка требований в твоем понимании это не та проблема о которой я говорил, я говорил о моем понимании проблемы. Контракты тут вообще не при чем. G>>>Так опиши свое понимание проблемы "трассировка требований" без больших цитат из непонятно кого. V>>Зачем? G>Без решаемых проблем любые действия никто не будет делать. Тупо менеджеры не позволят.
Ну мы же о новых технологиях говорим, а не проверенных и гарантированных?
V>>>>Вот именно — не видишь G>>>Так ты опиши чтобы видели люди. Пока проблема существует только у тебя в голове и решение её тоже. Покажи сначала проблему, а потом придумывай решения. V>>Не получиться так просто. G>Значит ты зря это все пишешь.
Здравствуйте, DarkGray, Вы писали:
V>>Аналитической записи преобразований не существует (исключая простейшие случаи)
DG>почему?
Хаос, хоть и детерминированный, но хаос. Малые изменения порождают серьезные последствия. Можно даже не учитывать ошибки программистов и случайность принимаемых ими решений.
В открытых нелинейных средах, которые являются наиболее типичными для существующего мира, случайное действие (флуктуация), может привести к значительным последствиям. Малые флуктуации могут усиливаться, и система будет эволюционировать в направлении «спонтанной организации», то есть незначительная флуктуация может служить началом эволюции в принципиально новом направлении, резко меняет все поведение макроскопической системы. Случайные флуктуации непредвиденным образом изменяют траекторию системы, хотя сами траектории имеют тяготение к аттракторам, в результате чего переводят систему, нестабильную относительно начальных условий, в новое стабильное состояние.
Нелинейность вносимых в программу изменений одним словом.
V>>Хотел бы я чтобы было четкое определение неалгоритмических процедур.
DG>из наличия нечеткости не следует — невозможность аналитической записи и невозможность алгоритмизации.
Не следует, но и не следует возможность в случае уточнения формулировок. Как там у Куна? В период научных революций взаимопонимание путем уточнения терминологии не срабатывает. По аналогии с этим, попытка программиста понять что у него твориться в мозгах напоминает непрекращающуюся революцию :) Нечеткость ведь относиться к действиям программиста, а не к алгоритмам программы.
Здравствуйте, Vaako, Вы писали:
V>Слышал о технологии 4+1, там для программной системы было одновременно 4 разных представления. В первом — диаграммы наследования объектов, во второй диаграммы взаимодействия, в третей какой объект в каком файле и модуле хранится, в четвертой еще что-то чего нет в предыдущих. Такой подход давал гораздо более удобное представление. чем одно единственное описание.
Оно и сейчас отлично в VS работает.
V>То есть было как минимум 4 разных способа декомпозиции исходной программной системы на части, каждый из которых ориентирован на наглядное представление проблем и связанных с ними проектных решений. При этом все уровни частично перекрывались и нужно было корректировать и отслеживать зависимости между этими разными представлениями одной и той же системы. При этом в рамках каждого из них редактирование и внесение изменений предполагалось независимым. Какие абстракции выносить на верхний уровень, а какие оставлять на нижнем зависит от решаемой задачи.
Никаких разных способов там нету. Способ ровно один — модули(проекты) — файлы — классы. Разные диаграммы — представления одного способа с разной степенью детализации. Значимое изменение одного из представлений повлечет изменения в остальных.
Изначальная цель, насколько я помню, была в том чтобы получить именно разные способы декомпозиции, чтобы их можно было менять независимо друг от друга.
V>Сейчас языки поддерживают один единственный способ распределения абстракций по уровням абстракции, потому поддержка одновременно нескольких способов распределения абстракций по абстрактным уровням серьезно помогает в проектировании. Но это трудно реализовать.
Разделение на слои — неформальное. Сможешь формализовать, то вполне можно будет обвешать классы атрибутами и анализировать их, строить диаграммы итп.
V>>>ЧЕм визуализируются несколько декомпозиций программы на части? И чтоб показывало при каких декомпозициях какие части нужно изменить и как? G>>А это тут при чем? Ты же говорил про трассировку требований и контракты. А "визуализация декомпозиции" это твоя идея, которая еще понятно зачем нужна и как будет делаться. Скорее всего никак. V>Проблема не в том "как", а в том что сейчас вообще "никак".
Поставь VS2010 team system, запусти architecture explorer. Очень даже "как" все делается. Вот только неформально это все, а формализовать у тебя не получается.
Еще раз: проблема не техническая, а концептуальная.
G>>Ну так у тебя почти всегда будет "обобщенное преобразование" {пусто} => {программа}, что оно тебе даст?
V>Примитивную систему координат V>1) Любая функциональность, объект или проектное решение могут быть определены через преобразование(изменение в тексте программы): V>Программа(без них) --> Программа(с ними) V>2) Любые ... могут рассматриваться в примитивной системе координат: V>Программа(с ними) <--> Минимальная программа (с ними) <-- Почти ничего (с ними) V>3) Знаком с концепцией "Генетическое описание"? В теоретической физике можно считать общепризнанным преимущество генетического описания проблемы перед любыми другими способами описания. А это и есть определение в терминах изменений и через изменения.
V>Проблема только в том, что для всего вышеперечисленного нужны обобщенные преобразования, т.е. для которых ортогональность гарантирована.
Только их нет, и как их достигнуть ты сказать не можешь, поэтому все что ты пишешь не имеет никакого смысла.
G>>Ты все еще не привел ту проблему, которую ты пытаешься решить. V>Как только научное сообщество придумает название для нее я первым делом сообщу всему RSDN-у об этом. Щас попробую, было у одного философа прикольная формулировочка — проблема искусственной абстрактной акселерации или как то похоже
Нужно не название, а описание.
V>>>>>Трассировка требований в твоем понимании это не та проблема о которой я говорил, я говорил о моем понимании проблемы. Контракты тут вообще не при чем. G>>>>Так опиши свое понимание проблемы "трассировка требований" без больших цитат из непонятно кого. V>>>Зачем? G>>Без решаемых проблем любые действия никто не будет делать. Тупо менеджеры не позволят. V>Ну мы же о новых технологиях говорим, а не проверенных и гарантированных?
Любые новые технологии должны хотябы обещать профит, ты это не можешь сделать. Все что ты говоришь приведет к повышению трудозатрат без видимого выхлопа.
V>Не следует, но и не следует возможность в случае уточнения формулировок. Как там у Куна? В период научных революций взаимопонимание путем уточнения терминологии не срабатывает. По аналогии с этим, попытка программиста понять что у него твориться в мозгах напоминает непрекращающуюся революцию Нечеткость ведь относиться к действиям программиста, а не к алгоритмам программы.
здесь ты во всю используешь постулаты: что не бывает нечеткой логики, и что на нечетких рассуждениях нельзя построить стабильный фундамент.
откуда эти постулаты следуют?
Здравствуйте, DarkGray, Вы писали:
V>>Слышал о технологии 4+1, там для программной системы было одновременно 4 разных представления. DG>uml — разве не оно
В каком смысле? Основная проблема — нарисовать диаграмму что ли?
Ты считаешь эту банальщину чем-то важным?
