Re[19]: Не пора ли переименовать ООП в ООН - Архитектура программного обеспечения

Здравствуйте, Аноним, Вы писали:
А>Можно подробнее , каким образом решена ? Где четкая методология ( рецепт приготовления обеда ) и как оценивать стоимость/сроки каждого шага ?
это как вкратце матан рассказать
учиться этому надо

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

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

>меня так прикалывают эти желтушные посты.
Это не "желтушный пост", а вполне адекватное мнение о полемике на одной из конференций OOPSLA.

"Желтушными" кажутся ваши максималистические высказывания. Но пойдём по порядку:

>задача разработки качественного ПО в срок сейчас решена.
Нет. "Задача разработки качественного ПО в срок" --- это сложнейшая задача успех которой зависит от большого количества различных факторов.
Влияние ООП/ООД относительно этой задачи --- капля в море.
Я думаю это должно быть очевидно.

>это не проблема. это не гадание. это так же просто, как приготовить обед.
Ага. А "любая кухарка сможет управлять государством!"

>огромную долю успеха в решении этой задачи занимает ООП.
Я так не считаю. Расскажите об этой "огромной доле успеха" по пунктам и аргументированно.

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

>то ученые нашли, что чеснок лечит рак
Кстати, очень похоже на то, как "британские учёные-программисты" изобрели ООП для решение "всех проблем разработки качественного ПО в срок"

Здравствуйте, nullxdth, Вы писали:
>>задача разработки качественного ПО в срок сейчас решена.
N>Нет. "Задача разработки качественного ПО в срок" --- это сложнейшая задача успех которой зависит от большого количества различных факторов.
я еще раз говорю — задача разработки качественной архитектуры это как сходить посрать. реализация это архитектуры не сложнее поедания мороженого.
как это продается, управляется, как компания конкурирует сильно зависит от локальных особенностей. в обязанности программиста это не входит.

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

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

__>задача разработки качественного ПО в срок сейчас решена.

Задача разработки качественного ПО особо-то не решена.
Задача разработки в срок не решена вообще ни для чего хоть сколько-то интересного.

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

>это как вкратце матан рассказать
>учиться этому надо
Не надо уровень значимости и сложности математики/математического анализа с ООП/ООД сравнивать. Тут явно счёт будет не в пользу второго.

>каждой сущности выделяется их погонялец (контроллер)
Что из себя представляет и для каких целей нужен "погонялец"?

>если интерфейс получается большой его делят на подинтерфейсы.
Как определить "размер" интерфейса?

>чтобы больше примерно 10 методов не было ни у кого
Почему, кстати? И почему примерно 10? Откуда это число?

>у общих сущностей для избежания дублирования кода создается предок (полиморфизм)
Я понимаю что такое полиморфизм в ООП, но то что вы написали --- это какая-то ерунда.
Если "создается предок", то, видимо, под сущностью вы полагаете "класс"; и тогда этот механизм называется "наследованием", а не "полиморфизмом".

>там где общие методы применяются к разнородным сущностям используюся шаблоны, а не копипаста.
Опять я нифига не понял. Что вы подразумевается под "разнородными сущностями"? И что под "шаблонами"?
Осмелюсь предположить, что тут речь об обобщённом программировании. Обобщённое программирование никакого отношения к ООП/ООД не имеет.

>таким образом убирается все дублирование и избыточность кода
В обобщённом программировании и ООП нет механизмов для "убирания" всевозможного избыточного кода

>все дублирование информации еще на этапе дизайна нахрен убирается, чтобы не было ошибок рассинхронизации.
А как быть, например, с кэшем? Кэш не нужен?

>команда расформировывается и все участники провалившейся команды понижаются в должности и попадают в подчинение в другие команды.
Мде... Brilliant management!
С таким отношением вы ничего не напишите. Неужели вы полагаете, что "понижение в должности" работников благоприятно повлияет на успех компании?

>основные концепции можно так примерно назвать
Мде... Не густо с основными концепциями.

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

>я еще раз говорю
Ещё хоть тысячу раз. Без аргументов и доказательств --- просто шум. Самый невежественный и пустой шум.

>задача разработки качественной архитектуры это как сходить посрать. реализация это архитектуры не сложнее поедания мороженого.
Вы уж определитесь "срать" или "кушать"

>как жигули не переделывай, все равно жигули получатся. вот на этом поле и рождаются какие-то методологии, как из говна смастерить пулю.
Нет. Вы совершенно не понимаете семантику слова "методология".

Здравствуйте, nullxdth, Вы писали:
>>как жигули не переделывай, все равно жигули получатся. вот на этом поле и рождаются какие-то методологии, как из говна смастерить пулю.
N>Нет. Вы совершенно не понимаете семантику слова "методология".
как нам наш тренер говорил — "до черного пояса у вас вообще своего мнения не должно быть". вот как только ты просветлеешь насчет того, чем хорошо ООП, вот после этого можешь размышлять насчет чего-то другого.
а если ты не понимаешь, как ООП работает, не можешь задизайнить ничего нормально и сделать в срок, то тебе еще учиться и учиться, а размышления твои нииикому не интересны.

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

>как нам наш тренер говорил — "до черного пояса у вас вообще своего мнения не должно быть".
Совершенно верно ваш тренер говорил. Вот только ты его, судя по всему, совершенно не слушал.

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

Такой уровень просветления мне не нужен

"Спасибо. Не голоден".

>а размышления твои нииикому не интересны.
А я особо и не размышлял. "Размышлял", а точнее "фантазировал" тут только ты. Я же просто решил макнуть очередного ООП-фанатика на потеху окружающим

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

Здравствуйте, nullxdth, Вы писали:
>>вот как только ты просветлеешь насчет того, чем хорошо ООП, вот после этого можешь размышлять насчет чего-то другого.
N>Судя по твоему посту об "основных концепциях", ты не только не знаешь ООП/ООД, но ещё и мысли свои излагать не научился. То есть "достиг" максимального уровня просветления ООП фанбоя

N>Такой уровень просветления мне не нужен

"Спасибо. Не голоден".

>>а размышления твои нииикому не интересны.
N>А я особо и не размышлял. "Размышлял", а точнее "фантазировал" тут только ты. Я же просто решил макнуть очередного ООП-фанатика на потеху окружающим

N>Кстати говоря, я задал тебе много вопросов по делу. Ты будешь на них отвечать, или сразу слив засчитаем?

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

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

>тьфу ты госсподи, извини. я то думал, ты обычный школьник, а ты просто тролль.

Троллинг --- это провокация с целью социальной деструкции.
Я тут никого не провоцировал. Даже тебя.
Ты начал с апломбом заявлять про идеальность ООП/ООД для решения всех архитектурных и управленческих проблем. Я же просто призвал тебя к ответу.
Так что наезд не обоснован.

Отвечать на вопросы то будешь? Или продолжишь высказывать невежественную и бездоказательную чепуху?

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

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

>>основной принцип разработки сложной фигни это разделение на части
>>ООП помогает разделять
N>Каким образом?

путем реализации type-erasure через полиморфизм (наследование от абстрактных классов/интерфейсов, или статический полиморфизм)

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

 ___________          _________________________          _______________________            _____________________
[интерфейс A] <|---- [код с которым мы работаем] -----> [интерфейс зависимости B] <|------ [какая-то реализация B]
 -----------          -------------------------          -----------------------            ---------------------

стирание типов есть не только в ООП, однако в случае ООП оно удобно тем, что
во-первых в интерфейс можно впихнуть не 1, а много методов,
а во-вторых есть удобный синтаксис доступа к методам через точку: объект.метод()

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

>путем реализации type-erasure через полиморфизм (наследование от абстрактных классов/интерфейсов, или статический полиморфизм)
Обобщённое программирование совершенно не обязательно реализуется средствами type-erasure механизма. Более того, стирание типов препятствует рефлексии.
Также статический полиморфизм никого отношения к ООП не имеет.

>стирание типов есть не только в ООП, однако в случае ООП оно удобно тем, что
>во-первых в интерфейс можно впихнуть не 1, а много методов,
Чем это будет отличается от модуля в котором сконцентрированы функции для работы с обобщённым типом?

>а во-вторых есть удобный синтаксис доступа к методам через точку: объект.метод()
Не вижу никого удобства вызова метода через точку. obj.f(<args>) принципиально ничем не отличается от f(obj, <args>).
Более того, синтаксис через точку препятствует реализации в языке мультиметодов.

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

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

>>путем реализации type-erasure через полиморфизм (наследование от абстрактных классов/интерфейсов, или статический полиморфизм)
N>Обобщённое программирование совершенно не обязательно реализуется средствами type-erasure механизма.
я ничего не говорил про обобщенное программирование

я сказал что стирание типов позволяет отделить конкретные типы зависимостей, а ООП позволяет сделать стирание типов

N>Более того, стирание типов препятствует рефлексии.
почему это? при стирании типов остается некоторый интерфейс, и его можно разобрать рефлексией. а что там было до стирания знать не надо, это детали реализации

N>Также статический полиморфизм никого отношения к ООП не имеет.
почему это? в ООП ничего не говорится каким именно должен быть полиморфизм.

можно использовать динамический полиморфизм

class A
{
public: 
    void do_something()
    {
        B* b = create_B();
        ...
    }
private:
    virtual B* create_B() = 0;
};

class D : A
{
    virtual B* create_B() override { return new ConcreteB(); }
};

а можно статический полиморфизм

template<typename D>
class A
{
public: 
    void do_something()
    {
        B* b = static_cast<D&>(*this).create_B();
        ...
    }
};

class D : A<D>
{
    B* create_B() { return new ConcreteB(); }
};

и там и там ООП, и там и там полиморфизм, отличия минимальны

>>стирание типов есть не только в ООП, однако в случае ООП оно удобно тем, что
>>во-первых в интерфейс можно впихнуть не 1, а много методов,
N>Чем это будет отличается от модуля в котором сконцентрированы функции для работы с обобщённым типом?

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

interface InputStream
{
    char read_char();
};

char f(InputStream& stream)
{
    return stream.read_char();
}

TEST("f reads and returns one character")
{
    StringStream stream("x");
    REQUIRE(read_one_char(stream) == 'x');
    REQUIRE(stream.tell() == 1);
}

а как это будет выглядеть в случае "модулей"?

>>а во-вторых есть удобный синтаксис доступа к методам через точку: объект.метод()
N>Не вижу никого удобства вызова метода через точку. obj.f(<args>) принципиально ничем не отличается от f(obj, <args>).
N>Более того, синтаксис через точку препятствует реализации в языке мультиметодов.

по моему субъективному мнению, большинство программистов предпочитает obj.f(x).g(y), а не g(f(obj, x), y),
а мультиметоды слишком редко когда нужны.

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

N>>Также статический полиморфизм никого отношения к ООП не имеет.
A>почему это? в ООП ничего не говорится каким именно должен быть полиморфизм.
Вообще-то говорится — в ООП под полиморфизмом подразумевается Subtype polymorphism.

A>можно использовать динамический полиморфизм
A>

A>class A
A>{
A>public: 
A>    void do_something()
A>    {
A>        B* b = create_B();
A>        ...
A>    }
A>private:
A>    virtual B* create_B() = 0;
A>};

A>class D : A
A>{
A>    virtual B* create_B() override { return new ConcreteB(); }
A>};
A>

A>а можно статический полиморфизм

A>

A>template<typename D>
A>class A
A>{
A>public: 
A>    void do_something()
A>    {
A>        B* b = static_cast<D&>(*this).create_B();
A>        ...
A>    }
A>};

A>class D : A<D>
A>{
A>    B* create_B() { return new ConcreteB(); }
A>};
A>

A>и там и там ООП, и там и там полиморфизм, отличия минимальны

Только в первом случае мы можем написать:

class D2 : A
{
    virtual B* create_B() override { return new ConcreteB2(); }
};

void f(A* a)
{
  a->do_something();
  ...
}

A* a1 = new D();
A* a2 = new D2();

f(a1);
f(a2);

(т.е. использовать Subtype polymorphism), а во втором — нет.
Так что отличия нифига не минимальны.

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

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

A>>почему это? в ООП ничего не говорится каким именно должен быть полиморфизм.
A>Вообще-то говорится — в ООП под полиморфизмом подразумевается Subtype polymorphism.
Согласен.

A>>и там и там ООП, и там и там полиморфизм, отличия минимальны

A>Только в первом случае мы можем написать:
A>(т.е. использовать Subtype polymorphism), а во втором — нет.
A>Так что отличия нифига не минимальны.
class D : A<D> — это тоже формально subtype полиморфизм.
Отличия может и не так минимальны. Они в том, будет ли позднее связывание. Я считаю что для ООП позднее связывание характерно. Но не берусь утверждать что без позднего связывания ООП не бывает.

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

>>>основной принцип разработки сложной фигни это разделение на части
>>>ООП помогает разделять
N>>Каким образом?

A>путем реализации type-erasure через полиморфизм (наследование от абстрактных классов/интерфейсов, или статический полиморфизм)
type-erasure — не самоцель. Хочу сказать что отделять можно и без type-erasure, а type-erasure это фича компайл-тайма, и работает оно не как средство, помогающее разрабатывать, а как средство, позволяющее облегчить исполняемый код или решить какие-то проблемы рантайма.

A>мы работаем с каким-то небольшим куском кода, типы сущностей от которых он зависит стираются, и не мешают концентрироваться на этом самом небольшом куске кода.
A>получается такая вот конструкция
A>

A> ___________          _________________________          _______________________            _____________________
A>[интерфейс A] <|---- [код с которым мы работаем] -----> [интерфейс зависимости B] <|------ [какая-то реализация B]
A> -----------          -------------------------          -----------------------            ---------------------
A>

Да, и концентрироваться на небольшом куске кода можно и без type-erasure.

A>стирание типов есть не только в ООП, однако в случае ООП оно удобно тем, что
A>во-первых в интерфейс можно впихнуть не 1, а много методов,
1 метод не ограничение для не-ООП. Кортеж методов — суть тот же интерфейс, или точнее vtbl во плоти.
A>а во-вторых есть удобный синтаксис доступа к методам через точку: объект.метод()
В языках с возможностью создания инфиксных функций доступ к методам через точку является навесным с точностью до понятия самой точки. Например, в F# такой точкой является функция "|>".

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

A>Ну ты пойми, что 90% программистов умом не блещут. Массовая профессия, однако.

А ты себя к 90% или к оставшимся 10% относишь?

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

__>ну и лично я уже считаю, что код никогда не должен переписываться тем, кто его написал, то есть в случае неуспеха какой-то части меняется команда этой части, команда расформировывается и все участники провалившейся команды понижаются в должности и попадают в подчинение в другие команды.

Ужас, а не компания. Постоянное напряжение и страх, перетасовки коллектива... Интересно сколько в таком коллективе люди выдержали?

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

__>Здравствуйте, Аноним, Вы писали:
А>>Можно подробнее , каким образом решена ? Где четкая методология ( рецепт приготовления обеда ) и как оценивать стоимость/сроки каждого шага ?
__>это как вкратце матан рассказать
__>учиться этому надо

__>основные концепции можно так примерно назвать:
Правильно ли я понимаю, что если я принесу тебе спецификацию на крупную ИС enterprise уровня и спрошу "сколько?", ты её всю вот так распишешь до уровня "класса, в котором не больше 10 методов" и дашь мне точный ответ?

__>ну и лично я уже считаю, что код никогда не должен переписываться тем, кто его написал, то есть в случае неуспеха какой-то части меняется команда этой части, команда расформировывается и все участники провалившейся команды понижаются в должности и попадают в подчинение в другие команды.
Почему ты так считаешь?

Здравствуйте, Doc, Вы писали:
Doc>Ужас, а не компания. Постоянное напряжение и страх, перетасовки коллектива... Интересно сколько в таком коллективе люди выдержали?
чего бояться-то, если с головой все в порядке? а там где говнкодят там народ сам долго думаю не задержится. кроме случая образования группы отстойников. которая после первого же выхода в свет погонится ссаными тряпками

Здравствуйте, 0x7be, Вы писали:
__>>основные концепции можно так примерно назвать:
0>Правильно ли я понимаю, что если я принесу тебе спецификацию на крупную ИС enterprise уровня и спрошу "сколько?", ты её всю вот так распишешь до уровня "класса, в котором не больше 10 методов" и дашь мне точный ответ?
до такого уровня архитектура никогда не детализируется. один я конечно это делать не буду, я лучше всегда посоветуюсь еще со знакомыми и теми кто подобное делал.
но бесплатно я это делать конечно не буду.

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

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

A>>во-первых в интерфейс можно впихнуть не 1, а много методов,
S>1 метод не ограничение для не-ООП. Кортеж методов — суть тот же интерфейс, или точнее vtbl во плоти.

кортеж функций (замыканий?), т.е.? и его небось надо руками собирать, или как?
такое можно и в С++/С# сделать, только это не удобно и непонятно зачем вообще такое нужно

A>>а во-вторых есть удобный синтаксис доступа к методам через точку: объект.метод()
S>В языках с возможностью создания инфиксных функций доступ к методам через точку является навесным с точностью до понятия самой точки. Например, в F# такой точкой является функция "|>".

это круто, только как-то удобнее печатать "." (или "-" в С++), чем "|"

и мне как-то непонятно почему ты все время повторяешь "методы", "методы", если говоришь за не-ООП?

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

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

N>>>Также статический полиморфизм никого отношения к ООП не имеет.
A>>почему это? в ООП ничего не говорится каким именно должен быть полиморфизм.
A>Вообще-то говорится — в ООП под полиморфизмом подразумевается Subtype polymorphism.

не слышал.
однако в некоторых языках поддержки Subtype нет, а полиморфизм с ООП есть

A>Только в первом случае мы можем написать:
A>

A>void f(A* a)
A>{
  a->>do_something();
A>  ...
A>}
A>

A>(т.е. использовать Subtype polymorphism), а во втором — нет.

со статическим полиморфизмом это выглядит так же

template<typename T>
void f(A<T>* a)
{
    a->do_something();
}

только так обычно никто не делает, ибо незачем, проще использовать конкретные типы

template<typename T>
void f(T& a)
{
    a.do_something();
}

D d;
D2 d2;
f(d);
f(d2);

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

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

A>>>во-первых в интерфейс можно впихнуть не 1, а много методов,
S>>1 метод не ограничение для не-ООП. Кортеж методов — суть тот же интерфейс, или точнее vtbl во плоти.

A>кортеж функций (замыканий?), т.е.? и его небось надо руками собирать, или как?
Да, кортеж функций. Или record функций, не суть важно.
Не понимаю, что значит руками собирать? Можно написать функцию, которая будет собирать нужный кортеж. А вот с функцией, которая будет собирать нужный класс в некоторых языках гораздо сложнее. Например, C++/C#. И уж там-то либо руками, либо генерировать код.

A>такое можно и в С++/С# сделать, только это не удобно и непонятно зачем вообще такое нужно
Можно. И да, в языках где есть интерфейсы или абстрактные классы это не так удобно. Хотя, как посмотреть. Создать и инициализировать кортеж функций с нужными функциями можно одним выражением. А вот реализовать класс — обычно язык не позволяет.

S>>В языках с возможностью создания инфиксных функций доступ к методам через точку является навесным с точностью до понятия самой точки. Например, в F# такой точкой является функция "|>".

A>это круто, только как-то удобнее печатать "." (или "-" в С++), чем "|"
Это дело привычки, а не принципиальной невозможности обращения через ".". Кстати, через точку F# как раз к членам обращается.

A>и мне как-то непонятно почему ты все время повторяешь "методы", "методы", если говоришь за не-ООП?
Один раз я написал "функция"

Нет, я не говорю за не-ООП. Я говорю что точка или не точка — вопрос привычки. И когда речь идет об ООП или не ООП, то говорить что "выбираю ООП потому что там точка (или стрелочка)" — ну это не ахти какой аргумент.
Вот то что команда привыкла к ООП, или то что найти спеца в ООП проще — это аргумент.

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

__>чего бояться-то, если с головой все в порядке?

1) Адекватности оценивающего. Вот скажем, Win8 провалилаась (разогнать команду) или нет?
2) И при явном виде кнута, в чем пряник?

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

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

__>потому что я таких команд насмотрелся. такие команды как северная корея — вещь в себе, бесполезно торговаться с ними или пытаться менять их культуру
Не, я о другом: почему такое негативное отношение к переписыванию кода?

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

>я ничего не говорил про обобщенное программирование

>я сказал что стирание типов позволяет отделить конкретные типы зависимостей, а ООП позволяет сделать стирание типов
Ты есть вы полагаете что стирание типов --- технология ООП и без ООП не имеет смысла?

>Также статический полиморфизм никого отношения к ООП не имеет.
>почему это? в ООП ничего не говорится каким именно должен быть полиморфизм.
Говорится или не говорится это дело десятое. Суть в том, что статический полиморфизм самодостаточен и в ОО обобщении не нуждается.

>не во всех языках есть модули.
>в тех языках где есть что-то что называется "module", обычно нет возможности подменить реализацию интерфейса например для юнит-тестирования.
Обычно возможность есть. Подменить реализацию не проблема.
Обычно определение интерфейса модуля отделяется от реализации.
Часто даже требуется, что бы интерфейс физически (по разным файлам) отделялся от реализации, как в Ada.
Вот и OCaml относительно реализации выводит сигнатуру модуля. А если же явно задать сигнатуру, то можно скрыть функции модуля для внутренних нужд.

Да. Понятие "модуль" действительно не формализован никак. И в разных языках совершенно по разному определяется.
Ну так и ООП дикой формализацией не отличается

Тот же разброд и шатание.

>по моему субъективному мнению, большинство программистов предпочитает obj.f(x).g(y), а не g(f(obj, x), y).
Это синтаксические мелочи. Их даже рассматривать не стоит. К тому же есть композиция функций.

>а мультиметоды слишком редко когда нужны.
Нужны. Ещё как. Для сколь-нибудь сложного взаимодействия объектов.

На мой взгляд единственное, что ценного есть в реализациях ООП "мейнстримных языков" --- модуль (с наследованием), как первоклассная сущность.
Однажды Вирт сказал, что "ООП не более чем тривиальная надстройка над структурным программированием [...]". И это правда.
Совершенно ясно это прослеживается на примере развития языка Ада; для добавления поддержки ООП в Аду сделали 2 вещи: научили записи наследоваться и добавили точечку

Все остальные механизмы уже были в системе модулей Ады.

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

>это круто, только как-то удобнее печатать "." (или "-" в С++), чем "|"
Это не "круто". Это правильно. Зачем хардкодить подобный синтаксис на уровне реализации языка, если композицию можно добавить средствами самого языка.
К тому же "как-то удобнее печатать" --- вкусовщина.
Неужели вы серьёзно полагаете, что синтаксис записи вызовов методов через точечку --- серьёзный аргумент полезности ООП?

>и мне как-то непонятно почему ты все время повторяешь "методы", "методы", если говоришь за не-ООП?
Отвечу за себя. Я к ООП отношусь трезво.
Я просто против фанатиков-дегенератов, полагающих, что ООП реально решает чуть ли не все архитектурные проблемы.
Да и технически примитивные реализации ООП в "мейнстримных языках" обсуждать скучно. Уже тысячу раз всё разжевано.
Лучше обсуждать, как эти примитивные механизмы способны решать проблемы code reuse. Или как позволяют избавиться от boilerplate'а.
Если уж технические вещи обсуждать, то лучше обсуждать CLOS с его мультидиспетчеризацией и комбинаторами методов.
CLOS куда технологичнее и интереснее, чем весь этот примитивизм.

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

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

>>я сказал что стирание типов позволяет отделить конкретные типы зависимостей, а ООП позволяет сделать стирание типов
N>Ты есть вы полагаете что стирание типов --- технология ООП и без ООП не имеет смысла?
я написал "X позволяет делать Y; Z позволяет делать X".
где Вы тут увидели "X — технология Z; X не имеет смысла без Z"?

>>в тех языках где есть что-то что называется "module", обычно нет возможности подменить реализацию интерфейса например для юнит-тестирования.
N>Обычно возможность есть. Подменить реализацию не проблема.
код покажите.

вот 16 строчек кода для тестирования функции при ОО подходе, покажите код с модулями и без ОО

interface InputStream
{
    char read_char();
};

char f(InputStream& stream)
{
    return stream.read_char();
}

TEST("f reads and returns one character")
{
    StringStream stream("x");
    REQUIRE(read_one_char(stream) == 'x');
    REQUIRE(stream.tell() == 1);
}

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

N>Я просто против фанатиков-дегенератов, полагающих, что ООП реально решает чуть ли не все архитектурные проблемы.
да, решает.

N>Лучше обсуждать, как эти примитивные механизмы способны решать проблемы code reuse. Или как позволяют избавиться от boilerplate'а.
это архитектурные проблемы?
или эти проблемы как-то относятся к ООП?

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

>код покажите.
>вот 16 строчек кода для тестирования функции при ОО подходе, покажите код с модулями и без ОО
Где в этом псевдокоде подмена реализации?
Что мне конкретно написать и на каком языке?
Юнит-тесты к функциям модуля? Если так, то зачем? Это же очевидно: подключить интерфейсный файл к модулю с юнит-тестами и написать тесты.
Нужно подменить реализацию. Открою файл реализации модуля и подменю. В чём проблема-то? Нафиг тут вообще ООП?

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

>да, решает.
Нет. Не решает. Это миф.
Наоборот, навязывает спорный принцип проектирования "сверху вниз".

N>>Лучше обсуждать, как эти примитивные механизмы способны решать проблемы code reuse. Или как позволяют избавиться от boilerplate'а.
A>это архитектурные проблемы?
A>или эти проблемы как-то относятся к ООП?
И code reuse и boilerplate это в том числе и архитектурные проблемы.
Т.к. ООП/ООД позиционирует себя как методология решения архитектурных проблем, то расскажите, каким образом она решает эти проблемы?

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

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

>>код покажите.
>>вот 16 строчек кода для тестирования функции при ОО подходе, покажите код с модулями и без ОО
N>Где в этом псевдокоде подмена реализации?

какая еще подмена реализации?

N>Что мне конкретно написать и на каком языке?

1) функцию f, которая читает из какого-то InputStream один символ и возвращает его.
2) юнит-тест к этой функции.

на любом языке

N>Юнит-тесты к функциям модуля? Если так, то зачем? Это же очевидно: подключить интерфейсный файл к модулю с юнит-тестами и написать тесты.
N>Нужно подменить реализацию. Открою файл реализации модуля и подменю. В чём проблема-то? Нафиг тут вообще ООП?

нет, не очевидно. код покажи.

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

>>путем реализации type-erasure через полиморфизм (наследование от абстрактных классов/интерфейсов, или статический полиморфизм)
N>Более того, стирание типов препятствует рефлексии.

Рефлексия не является необходимым атрибутом ООП.

>>стирание типов есть не только в ООП, однако в случае ООП оно удобно тем, что
>>во-первых в интерфейс можно впихнуть не 1, а много методов,
N>Чем это будет отличается от модуля в котором сконцентрированы функции для работы с обобщённым типом?

У модуля один инстанс, а у класса много. В общем-то, вопрос в синтаксисе вызова — через точку или нет.

>>а во-вторых есть удобный синтаксис доступа к методам через точку: объект.метод()
N>Не вижу никого удобства вызова метода через точку.

Ваше дело.

N>obj.f(<args>) принципиально ничем не отличается от f(obj, <args>).

А ассемблер принципиально не отличается от C#.

К примеру, линк-запросы писать и читать через точку удобнее, чем через обычные вызовы.

N>Более того, синтаксис через точку препятствует реализации в языке мультиметодов.

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

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

N>Я просто против фанатиков-дегенератов, полагающих, что ООП реально решает чуть ли не все архитектурные проблемы.

ООП решает, а лисп — не решает.

[F:\temp]
> type f.hpp
#include <istream>
char f(std::istream& stream)
{
    char c;
    stream.get(c);
    return c;
}

[F:\temp]
> type f_test.cpp
#define CATCH_CONFIG_MAIN
#include <catch.hpp>
#include "f.hpp"
#include <sstream>
TEST_CASE("f reads one char", "")
{
    std::stringstream stream("x");
    REQUIRE(f(stream) == 'x');
    REQUIRE((int)stream.tellg() == 1);
}
[F:\temp]
> g++ f_test.cpp && a.exe

[Testing completed. All tests passed (2 assertions in 1 test case)]

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

N>>obj.f(<args>) принципиально ничем не отличается от f(obj, <args>).
ARK>А ассемблер принципиально не отличается от C#.

Неадекватная аналогия. Точечка это всего лишь синтаксическая "пудра", которая не скрывает никаких низкоуровневых подробностей. Семантика этих конструкций одинакова.
Хотя, если сравнивать Lisp, C# и Asm, то с точки зрения Lisp принципиальной разницы между C# и Asm действительно нет

ARK>Мультиметоды не нужны. Не существует их нормальной реализации со статическими проверками компилятора. В редких частных случаях можно обойтись костылями.
О какой статической проверке идёт речь при определении метода, который должен вызываться? И какая разница в сложности реализации этой "статической проверки" для диспетчеризации по одному аргументу и более чем по одному?
Вот с этим давайте сначала разберёмся. А потому уже начнём вещать про "нинужность". Okay?

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

>ООП решает, а лисп — не решает.
Эту глупость вы от незнания говорите.
Lisp --- это метапрограммрование. Т.е. на Lisp можно добиться любой степени выразительности решений.
ООП же --- тривиальнейшая "надстройка". Хотя CLOS действительно интересен.

Здравствуйте, Doc, Вы писали:
Doc>1) Адекватности оценивающего. Вот скажем, Win8 провалилаась (разогнать команду) или нет?
что говорит о том, что она провалилась?

Doc>2) И при явном виде кнута, в чем пряник?
да, согласен, пряник нужен. просто системы поощрения есть везде, а вот кнут обычно не практикуется. считается что сидение на одном месте без повышения уже наказание. а ведь такие люди гадят компании очень сильно.

Здравствуйте, 0x7be, Вы писали:
0>А если ты так точно не детализируешь, то как ты можешь точно оценить трудоёмкость?
0>Применяешь ли ты какие-то вычислительные методы оценки?
оценка трудоемкости и разработка архитектуры это все-таки немного разные вещи. и что самое главное разные люди напишут одно и то же за сильно разное время. тут нужно конкретно смотреть по задаче, по доступным людям.
я видел когда команда из ста человек за два года разработки с нуля выдавала цельный кусок окаменелого гавна
в то время как то же самое (но уже без гавна) с нуля могло бы быть написано пятеркой грамотных людей

__>>потому что я таких команд насмотрелся. такие команды как северная корея — вещь в себе, бесполезно торговаться с ними или пытаться менять их культуру
0>Не, я о другом: почему такое негативное отношение к переписыванию кода?
что такое работа программиста? чем занимается программист? он просто излагает свои мысли насчет устройства программы в виде кода.
откуда у него возникнут другие мысли для написания другово кода? это как в России — какую партию не делай, КПСС получается.

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

ARK>>Мультиметоды не нужны. Не существует их нормальной реализации со статическими проверками компилятора. В редких частных случаях можно обойтись костылями.
N>О какой статической проверке идёт речь при определении метода, который должен вызываться? И какая разница в сложности реализации этой "статической проверки" для диспетчеризации по одному аргументу и более чем по одному?
N>Вот с этим давайте сначала разберёмся. А потому уже начнём вещать про "нинужность". Okay?

Okay. Разница между одним и несколькими аргументами диспетчеризации принципиальная. Для мультиметодов возможны случаи, когда подходящий вариант из нескольких выбрать невозможно — все равноправны. Статически это проверить либо невозможно, либо накладывает ряд ограничений, либо неюзабельно. Остается кидать исключение.

С модульностью мультиметоды тоже плохо дружат. Подключив модуль, мы рискуем непреднамеренно изменить поведение уже написанного кода. Мультиметоды вообще плохо вписываются в ООП, т.к. по сути не принадлежат ни одному объекту.

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

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

>>ООП решает, а лисп — не решает.
N>Эту глупость вы от незнания говорите.

Ну, вам виднее.

N>Lisp --- это метапрограммрование. Т.е. на Lisp можно добиться любой степени выразительности решений.

И можно писать без скобок?

N>ООП же --- тривиальнейшая "надстройка". Хотя CLOS действительно интересен.

Где же, где они — выразительные программы на лиспе? Тривиальнейшая надстройка используется в чуть менее, чем 100% программ, а интересный лисп — в чуть более, чем 0%.
Чем вы объясняете этот феномен?

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

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

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

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

>С модульностью мультиметоды тоже плохо дружат. Подключив модуль, мы рискуем непреднамеренно изменить поведение уже написанного кода.
Не очень понимаю. Каким образом?

>Мультиметоды вообще плохо вписываются в ООП, т.к. по сути не принадлежат ни одному объекту.
Нет. Множественная диспетчеризация и комбинаторы методов — это и есть ООП, advanced ООП. Это единственно на что стоит заострить внимание в ООП. Всё остальное тривиально и "из пустого в порожнее".

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

>Ну, вам виднее.
Да. Мне виднее. Я знаю Lisp.

>И можно писать без скобок?
Можно. Но зачем? В скобках вся сила

Также скобочки не мешают ни читать (Lisp код читают по отступам), ни писать (IDE сам расставляет скобочки и отступы).
Да и синтаксисом заморачиваются только самые невежественные и необразованные кодеры.

>Где же, где они — выразительные программы на лиспе? Тривиальнейшая надстройка используется в чуть менее, чем 100% программ, а интересный лисп — в чуть более, чем 0%.
>Чем вы объясняете этот феномен?
Порог вхождения в Lisp выше чем у среднестатистического blab'а.
Также Lisp показал себя как отличный инструмент для программирования не типового комплексного ПО. Примеры всем известны.

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

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

>1) функцию f, которая читает из какого-то InputStream один символ и возвращает его.
>2) юнит-тест к этой функции.
>на любом языке
CL:

(defun f (s) (read-char s))

(defun test-f ()
  (with-input-from-string (s "x")
    (assert (char= (f s) #\x))))

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

__>что говорит о том, что она провалилась?

Ну публикацией на эту тему полно. Но Win8 я для примера. Рассмотрим когда один и тот же продукт может быть оценен по разному. Что является фактором "не проваленного проекта"? Сдан или нет в срок, число багов, уровень продаж, отзывы клинтов?

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

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

__>>что говорит о том, что она провалилась?

Doc>Ну публикацией на эту тему полно. Но Win8 я для примера. Рассмотрим когда один и тот же продукт может быть оценен по разному. Что является фактором "не проваленного проекта"? Сдан или нет в срок, число багов, уровень продаж, отзывы клинтов?

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

а оценка успешности проекта целиком это вообще отдельная тема и с качеством кода она слабо связана. 3д макс 6, флеш, win95, Miranda im да и многие другие продукты — корявое нагромождение говнокода. но все эти проекты были достаточно успешными, хотя бы временно. хотя, например, хром легко заткнул ie потому что там разница качества кода просто небо и земля. браузеры должны гибко развиваться, но код ie настолько макаронный, что реализовать вкладки там, поддержку нового стандарта или нормальное автообновление это героический поступок

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

__>>>потому что я таких команд насмотрелся. такие команды как северная корея — вещь в себе, бесполезно торговаться с ними или пытаться менять их культуру
0>>Не, я о другом: почему такое негативное отношение к переписыванию кода?
__>что такое работа программиста? чем занимается программист? он просто излагает свои мысли насчет устройства программы в виде кода.
__>откуда у него возникнут другие мысли для написания другово кода?
Вы настолько не правы, что даже спорить не хочется

СУВ, Aikin

ПС: Я настолько "плохой программист", что практически любой код годовой давности я хочу выкинуть и переписать заново.

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

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

>>Для мультиметодов возможны случаи, когда подходящий вариант из нескольких выбрать невозможно — все равноправны.
N>Нет. В реальности неоднозначности решаются соглашениями. Например, в CLOS при вызове, методы сортируются по специализаторам аргументов слева направо.

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

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

N>Статически проверить соответствие аргументов специализаторам параметров вполне возможно без каких-либо ограничений точно также, как и при частной диспетчеризации по одному аргументу. Не вижу никаких проблем.

Проблему я обозначил, нормально она не решается. Упорядочивание методов слева направо, по алфавиту или по дате создания — это не решение.

Кстати, есть еще одна проблема — невозможно создать абстрактный прототип мультиметода, так как всегда есть риск, что мы свалимся в него при неудачной комбинации параметров диспетчеризации (с одним аргументом это гарантировано невозможно).

>>С модульностью мультиметоды тоже плохо дружат. Подключив модуль, мы рискуем непреднамеренно изменить поведение уже написанного кода.
N>Не очень понимаю. Каким образом?

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

>>Мультиметоды вообще плохо вписываются в ООП, т.к. по сути не принадлежат ни одному объекту.
N>Нет. Множественная диспетчеризация и комбинаторы методов — это и есть ООП, advanced ООП. Это единственно на что стоит заострить внимание в ООП. Всё остальное тривиально и "из пустого в порожнее".

О даа, конечно.

Вам с лисповых высот виднее.

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

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

>>Ну, вам виднее.
N>Да. Мне виднее. Я знаю Lisp.

>>И можно писать без скобок?
N>Можно. Но зачем? В скобках вся сила

Да, вся сила ушла в скобки.

N>Также скобочки не мешают ни читать (Lisp код читают по отступам),

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

N>Да и синтаксисом заморачиваются только самые невежественные и необразованные кодеры.

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

N>Порог вхождения в Lisp выше чем у среднестатистического blab'а.

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

N>Также Lisp показал себя как отличный инструмент для программирования не типового комплексного ПО. Примеры всем известны.

Приведите пару таких примеров-то. Желательно более-менее современных.

N>Как же надоел этот бессмысленный аргумент популярности и "мейнстримности". Когда аргументов нет, blab-кодер начинает запевать про "популярность".

Лисп маргинальный язык, это факт. И не надо корчить из себя илитария и "запевать" про блабов и порог вхождения.

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

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

>>1) функцию f, которая читает из какого-то InputStream один символ и возвращает его.
>>2) юнит-тест к этой функции.
>>на любом языке
N>CL:
N>

N>(defun f (s) (read-char s))

N>(defun test-f ()
N>  (with-input-from-string (s "x")
N>    (assert (char= (f s) #\x))))
N>

так `s` это объект, не?

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

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

A>>Вообще-то говорится — в ООП под полиморфизмом подразумевается Subtype polymorphism.

A>не слышал.
A>однако в некоторых языках поддержки Subtype нет, а полиморфизм с ООП есть

Однако и на голом С можно писать в ООП-стиле. Только придется эмулировать ООП-фишки, в частности Subtyping.

A>со статическим полиморфизмом это выглядит так же
A>

...
D d;
D2 d2;

Не совсем.

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

S>class D : A<D> — это тоже формально subtype полиморфизм.
Не, само по себе это просто наследование, а не полиморфизм. Subtype полиморфизм возникает когда имеется ссылка на базовый тип и выбор реализации метода делается на основе фактического типа объекта, на который ссылается эта ссылка.
S>Отличия может и не так минимальны. Они в том, будет ли позднее связывание. Я считаю что для ООП позднее связывание характерно. Но не берусь утверждать что без позднего связывания ООП не бывает.
На сколько я понимаю, вопрос сводится к "возможно ли ООП при запрете приведения (без потери идентичности) объекта к типу базового класса/интерфейса?".

А>ООН = Объектно Ориентированные Нагромождения
Для настоящего Нагромождения ни один из существоваших, существующих и будущих подходов не является препятствием. Создав топик, ТС продемонстрировал свою некомпетентность в области Нагромождений.

Здравствуйте, Aikin, Вы писали:
A>Вы настолько не правы, что даже спорить не хочется

A>СУВ, Aikin
A>ПС: Я настолько "плохой программист", что практически любой код годовой давности я хочу выкинуть и переписать заново.
нет, ну разумеется начинающий программист после прочтения книжки или прохождения тренинга начинает писать по другому часто. он сразу старается сделать все, что было написано в этой книжке и пишет в другом стиле — делая те же самые ошибки типа оставляя обьекты в невалидном состоянии, но при этом еще лепит какие-нить параметризации шаблонов или паттерны мосты, фасады или прочую хрень там где это нафиг не нужно. да насмотрелся я на такие проекты. нафиг это все переписывание не нужно. ничего не меняет в коде. тот же кал, но в профиль. бывает много хороших годных реализаций, но гавенных реализаций просто бесконечно много и их можно можно долго перебирать, не понимая что такое хорошо, а что такое плохо.

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

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

S>>class D : A<D> — это тоже формально subtype полиморфизм.
A>Не, само по себе это просто наследование, а не полиморфизм. Subtype полиморфизм возникает когда имеется ссылка на базовый тип и выбор реализации метода делается на основе фактического типа объекта, на который ссылается эта ссылка.
Википедия против:

allows a function to be written to take an object of a certain type T, but also work correctly if passed an object that belongs to a type S that is a subtype of T

То есть речь всего лишь о заменяемости объекта на объект подтипа при передаче в функцию.
Вот из того примера у нас есть функция A<D>::do_something(), принимающая неявно первым параметром указатель (идентити) объекта типа A<D>. Точно так же туда можно передать D : A<D>.

S>>Отличия может и не так минимальны. Они в том, будет ли позднее связывание. Я считаю что для ООП позднее связывание характерно. Но не берусь утверждать что без позднего связывания ООП не бывает.
A>На сколько я понимаю, вопрос сводится к "возможно ли ООП при запрете приведения (без потери идентичности) объекта к типу базового класса/интерфейса?".
На сколько я понимаю, приведение (без потери идентичности) хоть и является широкоиспользуемым в ООП, но не является при этом необходимым атрибутом ООП.

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

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

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

S>>>class D : A<D> — это тоже формально subtype полиморфизм.
A>>Не, само по себе это просто наследование, а не полиморфизм. Subtype полиморфизм возникает когда имеется ссылка на базовый тип и выбор реализации метода делается на основе фактического типа объекта, на который ссылается эта ссылка.
S>Википедия против:
S>

S>allows a function to be written to take an object of a certain type T, but also work correctly if passed an object that belongs to a type S that is a subtype of T

S>То есть речь всего лишь о заменяемости объекта на объект подтипа при передаче в функцию.
Хмм.. т.е. про то, что можно сделать такую вот параметрически полиморфную 'function'?! Тогда причем тут виртуальные функции, про которые все рассказывают, когда заходит речь о полиморфизме в контексте обсуждения ООП? Что-то я не доверяю этой статье.

This article is missing information about function overriding, which is another form of polymorphism

Вот другая статья. Оттуда:

The primary usage of polymorphism in industry (object-oriented programming theory) is the ability of objects belonging to different types to respond to method, field, or property calls of the same name, each one according to an appropriate type-specific behavior.

Т.е. уже про ad-hoc полиморфизм.

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

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

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

S>>То есть речь всего лишь о заменяемости объекта на объект подтипа при передаче в функцию.
A>Хмм.. т.е. про то, что можно сделать такую вот параметрически полиморфную 'function'?!
Параметрически-полиморфная функция должна работать для любых типов безотносительно их родственных связей вроде подтипа. Здесь именно ограниченно-параметрический полиморфизм, т.е. как бы параметрический, но работает лишь для подтипов.
A>Тогда причем тут виртуальные функции, про которые все рассказывают, когда заходит речь о полиморфизме в контексте обсуждения ООП? Что-то я не доверяю этой статье.
A>

A>This article is missing information about function overriding, which is another form of polymorphism

Все правильно, но виртуальные функции — это уже замес subtype на ad-hoc полиморфизм. Вот если в случае параметрического используется один и тот же код с одним поведением для любых типов (либо любых подтипов для subtype полиморфизма), то в специальном полиморфизме используется разный код для разных типов.
Но и тут надо аккуратно, т.к. смешение специального и параметрического может происходить с помощью разных механизмов.
Один из механизмов — таблица виртуальных функций и аналоги. Другой — тот же самый пример с class D : A<D>.
В обоих случаях в наследнике пере(до)определяется специальный метод со специальным поведением для конкретного наследника. Разница в том что один способ позволяет скрыть информацию о типе во время компиляции и подменять объекты в рантайме динамически, а другой — нет.

A>Вот другая статья. Оттуда:
A>

A>The primary usage of polymorphism in industry (object-oriented programming theory) is the ability of objects belonging to different types to respond to method, field, or property calls of the same name, each one according to an appropriate type-specific behavior.

A>Т.е. уже про ad-hoc полиморфизм.
Да, точно. Но это тоже не чистый ad-hoc, т.к. виртуальные функции без subtype-а как-то не живут. Но порядок тут наводится легко. Subtype позволяет нам передать в функцию объект производного типа, а ad-hoc позволяет по типу объекта выбрать соответствующее тело функции.
Кстати, процитировано не определение подвида полиморфизма, а его типичное использование в ООП.

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

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

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

__>что такое работа программиста? чем занимается программист? он просто излагает свои мысли насчет устройства программы в виде кода.
__>откуда у него возникнут другие мысли для написания другово кода? это как в России — какую партию не делай, КПСС получается.
Дык, опыт своих же ошибок дает прекрасную пищу для улучшения.
На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
Собственно, это ключевая идея прототипирования

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

__>меня так прикалывают эти желтушные посты. то win 8 провалилось, что еще что-то, то, теперь, оказывается ООП. то ученые нашли, что чеснок лечит рак, то София Ротару собралась лететь на Марс. это никому не интересно.
ПМСМ, некоторый налет "желтизны" там — это вполне обоснованная реакция на попытку сделать ООП религией

Здравствуйте, Аноним, Вы писали:

А>ООН = Объектно Ориентированные Нагромождения

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

Возможно выскажу свое заблуждение.. но мне кажется что большие серверные энтерпрайз приложения "внутри" лучше реализовывать в стиле ООП.
Я не говорю об 3-ех уровневой архитектуры, с сервисами выставленными наружу, это к ООП не совсем относится.
Оговорка, что я понимаю под "большие серверные энтерпрайз приложения". Это некие монстры автоматизирующие некие бизнес процессы, которые
могут быстро меняться. Или же в процессе разработки бизнесс процессы на которые ориентируемся не известно какими будут, лишь приблизительно.
И код должен быть таким же гибким и подстраивающимся.
Вот мне не понятно каким образом эти монстры, где во главе угла стоит гибкость и масштабируемость, могут быть эффективно реализованы с помощью
скажем только функционального стиля, или только процедурного стиля.
Если кому то известны пеценденты написания крупных, долго живущих энтерпрайз приложений в функциональном стиле пожалуйста
приведите ссылки, и тогда я с радостью признаю свое мнение ошибочным. Допускаю что это возможно, все-таки когда долго кодишь в какой либо
методологии мышление закостенивает, и труднее представить как можно по другому.

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

S>Параметрически-полиморфная функция должна работать для любых типов безотносительно их родственных связей вроде подтипа. Здесь именно ограниченно-параметрический полиморфизм, т.е. как бы параметрический, но работает лишь для подтипов.
Bounded parametric polymorphism — частный случай параметрического полиморфизма. Т.е. не "как бы" параметрический, а именно параметрический, но с ограничением на типы (to be subtypes of a given type).

Здравствуйте, Аноним, Вы писали:

А>ООН = Объектно Ориентированные Нагромождения

Вот тебе поддержка из Википедии:

Alexander Stepanov suggested that OOP provides a mathematically limited viewpoint and called it "almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work....".

Paul Graham has suggested that the purpose of OOP is to act as a "herding mechanism" that keeps mediocre programmers in mediocre organizations from "doing too much damage". This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques.

Joe Armstrong, the principal inventor of Erlang, is quoted as saying "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

здесь

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

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

S>>Параметрически-полиморфная функция должна работать для любых типов безотносительно их родственных связей вроде подтипа. Здесь именно ограниченно-параметрический полиморфизм, т.е. как бы параметрический, но работает лишь для подтипов.
A>Bounded parametric polymorphism — частный случай параметрического полиморфизма. Т.е. не "как бы" параметрический, а именно параметрический, но с ограничением на типы (to be subtypes of a given type).
Когда я писал "именно ограниченно-параметрический полиморфизм" я не подразумевал ограничения дженериков (констрейнты). А bounded — то другой частный случай.
void Foo0<T>(T list) {} — чистый параметрический
void Foo1(IList list) {} — пролезет все что реализует IList. Это subtype полиморфизм
void Foo2<T>(IList<T> list) {} — добавили параметричности. Т.е. для любого типа T, все что реализует IList<T>
void Foo3<T>(T list) where T : IList {} — это уже bounded. Но не совсем чистый, т.к. при том что мы можем зафиксировать T как IList<int>, сможем просунуть все что реализует IList<int>
Foo3<IList<int>>(new List<int>);
Foo3<IList<int>>(new int[]{});
То есть это замес subtype и bounded.
а можно еще так:
void Foo4<T, TList>(TList list) where TList : IList<T> {}
здесь для любого типа T можем зафиксировать тип TList, такой что TList: IList<T> но при этом можем передать любой подтип типа TList.

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

S>Когда я писал "именно ограниченно-параметрический полиморфизм" я не подразумевал ограничения дженериков (констрейнты). А bounded — то другой частный случай.
S>void Foo0<T>(T list) {} — чистый параметрический
S>void Foo1(IList list) {} — пролезет все что реализует IList. Это subtype полиморфизм
S>void Foo2<T>(IList<T> list) {} — добавили параметричности. Т.е. для любого типа T, все что реализует IList<T>
S>void Foo3<T>(T list) where T : IList {} — это уже bounded. Но не совсем чистый, т.к. при том что мы можем зафиксировать T как IList<int>, сможем просунуть все что реализует IList<int>
S>Foo3<IList<int>>(new List<int>);
S>Foo3<IList<int>>(new int[]{});
S>То есть это замес subtype и bounded.
S>а можно еще так:
S>void Foo4<T, TList>(TList list) where TList : IList<T> {}
S>здесь для любого типа T можем зафиксировать тип TList, такой что TList: IList<T> но при этом можем передать любой подтип типа TList.

А по моему это все вариации Bounded parametric polymorphism-а, не?

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

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

S>>Когда я писал "именно ограниченно-параметрический полиморфизм" я не подразумевал ограничения дженериков (констрейнты). А bounded — то другой частный случай.

A>А по моему это все вариации Bounded parametric polymorphism-а, не?
Только там где where

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

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

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

S>>>Когда я писал "именно ограниченно-параметрический полиморфизм" я не подразумевал ограничения дженериков (констрейнты). А bounded — то другой частный случай.

A>>А по моему это все вариации Bounded parametric polymorphism-а, не?

void Foo1(IList list) {} — constraint на параметр: list должен наследоваться (реализовывать) от IList
void Foo3<T>(T list) where T : IList {} — constraint на параметр: list должен наследоваться (реализовывать) от IList

В чем концептуальное различие с точки зрения типизации?

S>Только там где where
Почему?

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

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

S>>>>Когда я писал "именно ограниченно-параметрический полиморфизм" я не подразумевал ограничения дженериков (констрейнты). А bounded — то другой частный случай.

A>>>А по моему это все вариации Bounded parametric polymorphism-а, не?

A>void Foo1(IList list) {} — constraint на параметр: list должен наследоваться (реализовывать) от IList
A>void Foo3<T>(T list) where T : IList {} — constraint на параметр: list должен наследоваться (реализовывать) от IList

A>В чем концептуальное различие с точки зрения типизации?
Bounded дает ограничение на тип generic аргумента (не только метода, но и типа). А subtype — на тип фактически передаваемого в метод значения. Причем, bounded — он не обязательно связан с subtype. Так, в C# можно ограничивать по наличию конструктора по-умолчанию (where T()), а в F# по наличию в классе методов с конкретной сигнатурой. Можно потребовать что бы у объекта было свойство Length и подсовывать строки, массивы, и все что имеет свойство int Length.

S>>Только там где where
A>Почему?
Ну вот такой вот он, работает только с generic-ами. Конкретно почему не могу сказать, т.к. не вижу достаточно формального определения.
http://en.wikipedia.org/wiki/Bounded_quantification
В С++ template-ах не проявляется. Но, будет в концептах.

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

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

>Кстати, есть еще одна проблема — невозможно создать абстрактный прототип мультиметода, так как всегда есть риск, что мы свалимся в него при неудачной комбинации параметров диспетчеризации (с одним аргументом это гарантировано невозможно).
Такая особенность есть в CLOS. Но это отнюдь не из-за мультиметодов. Такое поведение в CLOS и для дипетчеризации по одному аргументу.
Дело в том, что в CLOS необязательно писать реализацию для всех комбинаций спецификаторов обобщённого метода.
На мой взгяд, это разумно. В противном случае пришлось бы определять заглушки для набора спецификаторов в которых нет смысла; это лишний и совершенно бесполезный код. В роли таких заглушек как раз и выступает сигнал (runtime exception) говорящий о том, что реализации нету.

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

>Это часть более крупной проблемы — каким образом с одной стороны задать, а с другой ограничить область поиска реализаций мультиметода. Нормального решения этой проблемы также не существует
Спецификаторы и ограничивают поиск реализаций. В CLOS, в довесок, есть ещё и equal спецификатор для ограничений по значению.
Это не "крупная проблема". Этой проблемы воообще нет. Это ваши фантазии.

>[...] хотя не сомневаюсь, что в лиспе для этого есть очередной говнокостыль.
Если говрить конкретно о Common Lisp, то таким качественным дизайном стандартной библиотеки может похвастаться далеко не каждый язык.
Я знаю о чём говрю, ибо пишу, как минимум, на дюжине языках; в том числе и на CL.
Вы же не знаете CL, но почему-то полагаете, что имеете право столь категорично заявлять. Т.е. "не знаю, но осуждаю". Весьма показательно.

>О даа, конечно.

Вам с лисповых высот виднее.

Да. Мне виднее. По крайней мере я не берусь судить о том, чего не знаю.
Особенно показателен тот момент, что вы говорите о статических проверках типов в контексте ООП, тогда как классическая школа ООП — чистейшая динамика.

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

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

>Да, вся сила ушла в скобки.

Очень остро! Отличный удар интернет-боец!

>Нагромождения скобок в лиспе мешают читать код.
Нет никакого нагромождения.
Есть хорошее соглашение по расстановки скобок, которое позволяет почти всегда их игнорировать; на них просто не обращают никакого внимания.
Скобки мешают лишь lisp-аналитикам, которы никогда не писали и не читали lisp-код.

>Хм, не уверен. Особой сложности в лиспе не вижу.
Мне виднее. Но вы правы, какой-то особой сложности в lisp'е нету.

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

>Приведите пару таких примеров-то. Желательно более-менее современных.
Не вопрос. Но зачем? В противовес вы приведёте количественный показатель ПО на других ЯП. А в такой плоскости я не собираюсь вести дискуссию, ибо пользы от этого нет никакой.
Имею желание обсуждать лишь технологичность и практичность языков.

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

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

>так `s` это объект, не?
Да, вы правы. s — объект. Вы же меня просили написать подобное без использования ООП.
Мой код неадекватен требованию, согласен.
Позвольте исправиться, но чуть позже...

Здравствуйте, 0x7be, Вы писали:
__>>я видел когда команда из ста человек за два года разработки с нуля выдавала цельный кусок окаменелого гавна
__>>в то время как то же самое (но уже без гавна) с нуля могло бы быть написано пятеркой грамотных людей
0>Вот потому я и интересуюсь, как именно "задача разработки качественного ПО в срок сейчас решена" (с) ты.
при условиях достаточных ресурсов. ни одна задача не может быть решена когда ресурсов нет. если нет, сначала их нужно достать.

0>Дык, опыт своих же ошибок дает прекрасную пищу для улучшения.
0>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>Собственно, это ключевая идея прототипирования

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

int j = 0;
for (; j<10; j++)
....
int i = 0;
for (; i<10; j++) // тут опечатка — нужно было i++

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

Здравствуйте, __kot2, Вы писали:
__>совсем необязательно. это достаточно дурацкая идея. любое решение имеет побочные эффекты.
я имел в виду, что не надо все делать "как тут принято", а понимать плюсы и минусы любого, даже самого маленького решения. тогда улучшать будет просто нечего.

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

>Просто корявый синтаксис людей отпугивает, а реальных преимуществ нет.
Реальное преимущество s-expressions — простота анализа и генерации. Именно благодаря скобкам МП в lisp столь простое и удобное.
Была мысль у Маккарти сделать m-expressions и потом транслировать в s-expr's. Но он так и не сделал этого, ибо к тому времени, как он созрел, lisp-программисты по достоинству оценили скобочки и никакой особый синтаксис не требовался по вышеизложенной причине.
Вы же дальше примитивных рассуждений о "вкусовщине" синтаксиса: точечке и скобочках никуда не ускакали.

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

0>>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>>Собственно, это ключевая идея прототипирования

__>совсем необязательно. это достаточно дурацкая идея.
Обоснуй.

__>любое решение имеет побочные эффекты. например, решение применять сокращения в стиле Cnt или опечатки в названии усложняют полнотекстовый поиск по проекту. а отказ от принципа минимальной видимости ведет к проблемам в стиле:
__>int j = 0;
__>for (; j<10; j++)
__>....
__>int i = 0;
__>for (; i<10; j++) // тут опечатка — нужно было i++
__>если у вас вторая версия получается значительно лучше первой, значит, я скорее всего смогу предложить вам третью версию, которая разнесет две ваши предыдущие и которую вы уже улучшить не сможете.
Если честно, не понял, как эти примеры связаны с моим утверждением о том, что переписанный код обычно получается лучше оригинального.

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

>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
>Собственно, это ключевая идея прототипирования

>>совсем необязательно. это достаточно дурацкая идея.
>Обоснуй.
Чего тут обосновывать: "Мужики, давайте писать сразу правильно и без багов!"

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

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

N>Чего тут обосновывать: "Мужики, давайте писать сразу правильно и без багов!"

Фантазии... фантазии...
N>Прототипирование — важнейшая часть разработки комплексного ПО. И зачастую, самая интересная часть. В обосновании не нуждается. Самоочевидно.
Да даже и не комплексного.
За 20+ лет программирования (как хобби и профессионального) я пришел полному отказу от дизайна (не путать с архитектурой!) перед написанием кода.
Пишу код прямо в Program.Main и Button0_Click

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

Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, __kot2, Вы писали:
0>>>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>>>Собственно, это ключевая идея прототипирования

__>>совсем необязательно. это достаточно дурацкая идея.
0>Обоснуй.
переписывание это действие. зачем нужно это действие?
потому что так получается лучше? ну хорошо, да. но почему это ставится как какой-то принцип?

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

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

A>>ПС: Я настолько "плохой программист", что практически любой код годовой давности я хочу выкинуть и переписать заново.
__>нет, ну разумеется начинающий программист после прочтения книжки или прохождения тренинга начинает писать по другому часто.
Я говорю про себя (девелопера с почти 10ти летним стажем). И я этому рад, потому как я развиваюсь, а не стою на месте.

Могу привести пример рефакторинга, который мы (я) делали где-то пол года назад. Мы делали порядка 15 слабо похожих отчетов, код старались пере-использовать как можно больше, но это получалось плохо. На 10м где-то отчете пришло понимание, что отчеты-то, в принципе, похожи и можно выделить общий воркфлоу с отличиями во внутренней структуре. Понимание-то пришло, но вот рефакторить мы не стали так как менять нужно было много, а вот практической пользы (кроме "красоты" кода) не много. И не рефакторили. До того момента, как нам эти отчеты нужно было сравнивать между собой. Отрефакторили, что позволило написать универсальную сравнивалку, которую мы сделали буквально за неделю.

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

СУВ, Aikin

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

Погуглив еще, вынужден признать, что subtype polymorphism принято выделять в отдельный вид полиморфизма (т.е. не ad-hoc и не parametric).
Имхо, вопреки здравому смыслу...

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

__>Здравствуйте, 0x7be, Вы писали:
0>>>>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>>>>Собственно, это ключевая идея прототипирования

__>>>совсем необязательно. это достаточно дурацкая идея.
0>>Обоснуй.
__>переписывание это действие. зачем нужно это действие?
__>потому что так получается лучше? ну хорошо, да. но почему это ставится как какой-то принцип?
Вопросы, тем более, оставленные без ответов, обычно не являются обоснованием чего-либо.
Если вам самому нужны ответы — узнайте у конструкторов, нафига они бумагу пачкают, гоняют воздух в аэродинамических трубах. Или спросите в MS Research, нафига они дурью страдают, если можно сразу пилить продакшн.
А если ответы не нужны — можете сразу обосновать руководству тех или других что прототипировать — дурацкая идея.

__>обычно нет проблем распознать код целиком гавно или нет. даже не особо опытный программист скажет правдоподобно про чужой код — он удобный для работы и хорошо написанный или кусок гавна.
__>а вот для того, чтобы понять что делает код гавном, какие конкретно частички, чтобы уметь разглядеть гавно в каждом далеко неочевидном кусочке нужен опыт. ничего сложного в этом нет. то есть есть код, который сам по себе ни о чем не говорит, однако в совокупности он вызывает множество проблем в неожиданных местах. вот если код писать хотя бы просто без таких кусков, то и переписывать ничего не нужно потом, точно так же, как никто не переваривает заново прекрасно приготовленный борщ. для того, чтобы хорошо приготовить что-то необязательно испоганить кучу продуктов и переделывать его и переделывать. а когда человек учится готовить то перевода продуктов можно избежать если он будет сначала подмастерьем.
Борщ варят 500 лет. Если бы программисты 500 лет варили бы один и тот же продукт по одному рецепту, то вопросов о прототипировании тоже бы не стояло.

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

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

A>Погуглив еще, вынужден признать, что subtype polymorphism принято выделять в отдельный вид полиморфизма (т.е. не ad-hoc и не parametric).
A>Имхо, вопреки здравому смыслу...
Соглашусь что название не совсем удачное, учитывая то что его называют так же динамическим полиморфизмом (по википедии), который по моему скромному мнению является подвидом subtype, и именно который обеспечивает позднее связывание, одиночную диспетчеризацию и который наиболее характерен для ООП.
И это не одно и то же просто потому что имеем возможность наблюдать проявление subtype без динамического полиморфизма.

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

S>Я считаю что для ООП позднее связывание характерно. Но не берусь утверждать что без позднего связывания ООП не бывает.

Алан Кей с тобой согласен:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

Хотя кого в наши дни интересует мнение Алана Кея...

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

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

N>>Чего тут обосновывать: "Мужики, давайте писать сразу правильно и без багов!"

Фантазии... фантазии...
N>>Прототипирование — важнейшая часть разработки комплексного ПО. И зачастую, самая интересная часть. В обосновании не нуждается. Самоочевидно.
0>Да даже и не комплексного.
0>За 20+ лет программирования (как хобби и профессионального) я пришел полному отказу от дизайна (не путать с архитектурой!) перед написанием кода.
0>Пишу код прямо в Program.Main и Button0_Click

0>Сначала добиваюсь, что бы работало, потом яростно рефакторю.
0>Получается быстрее и лучше, чем сначала думать о классах и функциях.

Мне кажется что пишут, а потом яростно рефакторят люди которые не понимают как этот дизайн должен делаться и как развиваться. Всегда делаю дизайн на листке, на доске, в средствах автоматизации. Т.к. именно дизайн выражает идею отношений и обязанностей, выражаясь тезисно, "вот мы так задумывали". Дизайн начинается с ответственностей, с интерфейсов и типов. То что вы называете рефакторингом, это не рефакторинг, а переделка, которой скорее всего можно было избежать. Рефакторинг делается тогда, когда новая функциональность не укладывается в старый дизайн. И рефакторинг должен начинаться с дизайна.

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

_>Мне кажется что пишут, а потом яростно рефакторят люди которые не понимают как этот дизайн должен делаться и как развиваться. Всегда делаю дизайн на листке, на доске, в средствах автоматизации. Т.к. именно дизайн выражает идею отношений и обязанностей, выражаясь тезисно, "вот мы так задумывали". Дизайн начинается с ответственностей, с интерфейсов и типов. То что вы называете рефакторингом, это не рефакторинг, а переделка, которой скорее всего можно было избежать. Рефакторинг делается тогда, когда новая функциональность не укладывается в старый дизайн. И рефакторинг должен начинаться с дизайна.
Я понимаю, как дизайн делается и развивается, и я сам раньше дизайн делал исключительно заранее и на листочке

Здравствуйте, Aikin, Вы писали:
A>И вообще, у меня принцип работы такой: работай чтобы работало, рабочий код лучше красивого решения, отрефакторить потом всегда успеешь. И мне этот подход нравится.
я работал с индусами с 10+ годами опыта. они тоже всем довольны. у них точно такой же принцип разработки.

Здравствуйте, samius, Вы писали:
S>Если вам самому нужны ответы — узнайте у конструкторов, нафига они бумагу пачкают, гоняют воздух в аэродинамических трубах. Или спросите в MS Research, нафига они дурью страдают, если можно сразу пилить продакшн.
S>А если ответы не нужны — можете сразу обосновать руководству тех или других что прототипировать — дурацкая идея.
я работал в ресерче. очень понравилось. большая часть работы — написание прототипов. вот только мои прототипы не нужно было переделывать, если хочется пустить в продакшен, он сразу писался нормальным.

S>Борщ варят 500 лет. Если бы программисты 500 лет варили бы один и тот же продукт по одному рецепту, то вопросов о прототипировании тоже бы не стояло.
кто варит борщ 500 лет? у моей девушки он сразу получался хорошим с первого раза. ей точно 500 лет нет.

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

__>Здравствуйте, samius, Вы писали:
S>>А если ответы не нужны — можете сразу обосновать руководству тех или других что прототипировать — дурацкая идея.
__>я работал в ресерче. очень понравилось. большая часть работы — написание прототипов. вот только мои прототипы не нужно было переделывать, если хочется пустить в продакшен, он сразу писался нормальным.
Полагаю что ресерчу что-то не понравилось, раз в прошедшем времени.

S>>Борщ варят 500 лет. Если бы программисты 500 лет варили бы один и тот же продукт по одному рецепту, то вопросов о прототипировании тоже бы не стояло.
__>кто варит борщ 500 лет? у моей девушки он сразу получался хорошим с первого раза. ей точно 500 лет нет.
Вот если бы она его изобрела с первого раза и сварила хорошо — тогда да, аргумент. А программу ваша девушка не пробовала писать с первого раза?
Вот поставьте эксперимент. Вы ей рассказываете об ООП в объеме не превышающем рецепт борща. Она пишет программу с первого раза. Не сложную, в пределах сложности варки борща. Результат можно не пересказывать, особенно если она не программист.

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

__>Здравствуйте, Aikin, Вы писали:
A>>И вообще, у меня принцип работы такой: работай чтобы работало, рабочий код лучше красивого решения, отрефакторить потом всегда успеешь. И мне этот подход нравится.
__>я работал с индусами с 10+ годами опыта. они тоже всем довольны. у них точно такой же принцип разработки.
вы мне, наверно, скажете "вы так говорите будто это что-то плохое". да, это плохо когда чел фигачит говнокод, лишь бы тесты проходил и работал иногда, а потом с песнями и плясками сваливает в другой проект. "my work here is done.."

Здравствуйте, samius, Вы писали:
__>>Здравствуйте, samius, Вы писали:
S>>>А если ответы не нужны — можете сразу обосновать руководству тех или других что прототипировать — дурацкая идея.
__>>я работал в ресерче. очень понравилось. большая часть работы — написание прототипов. вот только мои прототипы не нужно было переделывать, если хочется пустить в продакшен, он сразу писался нормальным.
S>Полагаю что ресерчу что-то не понравилось, раз в прошедшем времени.
нет, я в MS ушел.

S>>>Борщ варят 500 лет. Если бы программисты 500 лет варили бы один и тот же продукт по одному рецепту, то вопросов о прототипировании тоже бы не стояло.
__>>кто варит борщ 500 лет? у моей девушки он сразу получался хорошим с первого раза. ей точно 500 лет нет.
S>Вот если бы она его изобрела с первого раза и сварила хорошо — тогда да, аргумент. А программу ваша девушка не пробовала писать с первого раза?
S>Вот поставьте эксперимент. Вы ей рассказываете об ООП в объеме не превышающем рецепт борща. Она пишет программу с первого раза. Не сложную, в пределах сложности варки борща. Результат можно не пересказывать, особенно если она не программист.
я говорю, что постоянное переделывание это признак отсталой технологии, а не какой-то то там один из основных принципов разработки. да, прототипирование и постоянный "рефакторинг" работает. лобание кода в столбик без ф-ий тоже работает. все работает. работает так, что все постоянно плюются и матерятся.

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

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

S>>Вот поставьте эксперимент. Вы ей рассказываете об ООП в объеме не превышающем рецепт борща. Она пишет программу с первого раза. Не сложную, в пределах сложности варки борща. Результат можно не пересказывать, особенно если она не программист.
__>я говорю, что постоянное переделывание это признак отсталой технологии, а не какой-то то там один из основных принципов разработки. да, прототипирование и постоянный "рефакторинг" работает. лобание кода в столбик без ф-ий тоже работает. все работает. работает так, что все постоянно плюются и матерятся.
Что ж вы мечетесь? Разговор был про "зачем нужно прототипирование". Но у вас то борщ, то постоянный рефакторинг, теперь лобание в столбик и без функций. С прототипированием вопрос закрыли?

Здравствуйте, samius, Вы писали:
S>Что ж вы мечетесь? Разговор был про "зачем нужно прототипирование". Но у вас то борщ, то постоянный рефакторинг, теперь лобание в столбик и без функций. С прототипированием вопрос закрыли?
я понимаю, что вам неприятно слышать, что ваш подход осталый. не стоит из-за этого злиться. я тут непричем. это не я научил вас так работать.

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

__>Здравствуйте, samius, Вы писали:
S>>Что ж вы мечетесь? Разговор был про "зачем нужно прототипирование". Но у вас то борщ, то постоянный рефакторинг, теперь лобание в столбик и без функций. С прототипированием вопрос закрыли?
__>я понимаю, что вам неприятно слышать, что ваш подход осталый. не стоит из-за этого злиться. я тут непричем. это не я научил вас так работать.
Мне удивительно слышать как резко вы меняете темы. Теперь переключились на мой подход, хотя я его нигде не обозначил. И на то что мне по-вашему неприятно. Может вы моих родственников обсудите, раз вам нечего о прототипировании сказать?

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

A>>>И вообще, у меня принцип работы такой: работай чтобы работало, рабочий код лучше красивого решения, отрефакторить потом всегда успеешь. И мне этот подход нравится.
__>>я работал с индусами с 10+ годами опыта. они тоже всем довольны. у них точно такой же принцип разработки.
__>вы мне, наверно, скажете "вы так говорите будто это что-то плохое".
Мимо. Я против "индусского" кода.
Дело в том, что этим принципом дело не кончатеся. Есть и другие. Например "простой код лучше сложного".
Только смысл нам с вами разговаривать? Как я уже говорил "Вы настолько не правы, что даже спорить не хочется"

__>да, это плохо когда чел фигачит говнокод, лишь бы тесты проходил и работал иногда, а потом с песнями и плясками сваливает в другой проект. "my work here is done.."
А никто про говнокод не говорит. Мне не стыдно его показывать.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:
__>>да, это плохо когда чел фигачит говнокод, лишь бы тесты проходил и работал иногда, а потом с песнями и плясками сваливает в другой проект. "my work here is done.."
A>А никто про говнокод не говорит. Мне не стыдно его показывать.
ну а зачем же тогда его "яростно рефакторить"? или это не ваши слова?

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

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

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

N>Нет. Никакой "кривизны" и "косости" тут нет. Это самое что ни на есть нормальное соглашение.

Для меня оно не выглядит нормальным.
Оно ни откуда не следует, как пятая аксиома Евклида.

N>Такое же как, например, соглашение о порядке вычисления аргументов функций во всех известых мне энергичных языках (слева направо).
N>Такое же как соглашение о приоритетах математических операций.

Скорее как соглашения о множественном наследовании в С++, которые тоже высосаны из пальца.

N>На мой взгяд, это разумно. В противном случае пришлось бы определять заглушки для набора спецификаторов в которых нет смысла; это лишний и совершенно бесполезный код. В роли таких заглушек как раз и выступает сигнал (runtime exception) говорящий о том, что реализации нету.

Лично я предпочитаю сигналы на этапе компиляции.

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

Может это не мы его определили. А из подключаемого модуля нам нужен другой функционал.

>>Это часть более крупной проблемы — каким образом с одной стороны задать, а с другой ограничить область поиска реализаций мультиметода. Нормального решения этой проблемы также не существует
N>Спецификаторы и ограничивают поиск реализаций. В CLOS, в довесок, есть ещё и equal спецификатор для ограничений по значению.

Ну я и говорю. Подключили модуль и получили "сигнал (runtime exception)" в том коде, который раньше работал.

N>Это не "крупная проблема". Этой проблемы воообще нет. Это ваши фантазии.

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

N>Я знаю о чём говрю, ибо пишу, как минимум, на дюжине языках; в том числе и на CL.

На каких же 12 языках вы пишете?

Причем наверняка одновременно. Просто интересно, с кем мне выпала честь беседовать.

N>Вы же не знаете CL, но почему-то полагаете, что имеете право столь категорично заявлять. Т.е. "не знаю, но осуждаю". Весьма показательно.

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

N>Да. Мне виднее. По крайней мере я не берусь судить о том, чего не знаю.

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

N>Особенно показателен тот момент, что вы говорите о статических проверках типов в контексте ООП, тогда как классическая школа ООП — чистейшая динамика.

Какая еще классическая школа, Симула-67? И причем тут вообще какая-то мифическая классическая школа?

N>Но раз уж вы так рьяно говорите о "костылях", то извольте определить, что подразумеваете под ними? А то может оказаться, что и нога тоже костыль (биологический)

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

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

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

>>Да, вся сила ушла в скобки.

N>Очень остро! Отличный удар интернет-боец!

>>Нагромождения скобок в лиспе мешают читать код.
N>Нет никакого нагромождения.

Да ладно.

(defun project (y x)
  (let* (
         (ip-xy (sum (* x y)))
         (ip-xx (sum (* x x)))
         (coef  (/ ip-xy ip-xx))
         )
    (* coef x)))

А что, если тут одна скобочка будет стоять не там, где надо?
А что, если это будет не такой примитивный кусок кода, а портянка в несколько тысяч строк?

N>Есть хорошее соглашение по расстановки скобок, которое позволяет почти всегда их игнорировать; на них просто не обращают никакого внимания.
N>Скобки мешают лишь lisp-аналитикам, которы никогда не писали и не читали lisp-код.

Да-да, конечно. И к громкой музыке организм тоже может привыкнуть. Но лучше засыпать в тишине.
Я бы сказал иначе. Скобки (абсолютно ненужные, синтаксический мусор) мешают многим программистам. Кроме двух с половиной илитариев.

>>Просто корявый синтаксис людей отпугивает, а реальных преимуществ нет.
N>Синтаксис lisp на столько лаконичен и гениален, что "корявостям" просто неоткуда взяться.

Попробуйте brainfuck, еще лаконичнее.

N>Он только обезьянок отпугивает, которые вместо того, чтобы разобраться какими преимуществами обладает столь интересная технология и как это можно применить на практике, смотрят лишь на внешний облик.

"Очень остро! Отличный удар интернет-боец!" (с)
Ну расскажите, как вы это применяете на практике. Сколько строк лисп-кода в вашем проекте, сколько человек в вашей команде и сколько времени и в каком объеме вы поддерживали чужой говнокод на лиспе? А, я забыл, что лисп илитарен настолько, что говнокода на нем не бывает.

>>Приведите пару таких примеров-то. Желательно более-менее современных.
N>Не вопрос. Но зачем? В противовес вы приведёте количественный показатель ПО на других ЯП. А в такой плоскости я не собираюсь вести дискуссию, ибо пользы от этого нет никакой.
N>Имею желание обсуждать лишь технологичность и практичность языков.

Ради интереса приведите же, ну. А то говорите всем известно, а потом в кусты.

Я не буду приводить количественных показателей.

>>Лисп маргинальный язык, это факт. И не надо корчить из себя илитария и "запевать" про блабов и порог вхождения.
N>Как вы классифицируете языки программиста совершенно не интересует. Программиста интересует прежде всего увелечение качества и производительности труда.

Это верно. И почему-то обычно для труда выбирают не лисп. Если за 50 лет популярности нет — значит язык нишевой во всех смыслах.

N>А "запевать" про "блабов" и про "илитарость" я продолжу до тех пор, пока имеет место быть "не знаю, но осуждаю".

Ну, дело ваше.

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

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

>>Просто корявый синтаксис людей отпугивает, а реальных преимуществ нет.
N>Реальное преимущество s-expressions — простота анализа и генерации. Именно благодаря скобкам МП в lisp столь простое и удобное.

Тут я согласен. Определенно однотипная структура языка в некоторых задачах может быть удобна.

N>Вы же дальше примитивных рассуждений о "вкусовщине" синтаксиса: точечке и скобочках никуда не ускакали.

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

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

>

Для меня оно не выглядит нормальным.
>Оно ни откуда не следует, как пятая аксиома Евклида.

Не понимаю в чём ненормальность определения приоритета слева направо

То есть вы полагаете что вычисление аргументов при вызове функций в энергичных языках тоже "костыль" и "высосан из пальца"?

И следуют подобные соглашения не "из ни откуда", а из такого соображения, что большинство населения планеты читает текст слева направо; соответственно, такие соглашения воспринимаются просто и естественно.
Не согласны? Или вы полагаете, что логично при вызове функций каждый раз явно указывать в каком порядке будут вычислены аргументы?

Я полагаю, что ваша претензия к данному соглашению как раз таки "высосана из пальца" и не имеет под собой никаких реальных обоснований.

N>>Такое же как, например, соглашение о порядке вычисления аргументов функций во всех известых мне энергичных языках (слева направо).
N>>Такое же как соглашение о приоритетах математических операций.
ARK>Скорее как соглашения о множественном наследовании в С++, которые тоже высосаны из пальца.
Нет. Это тоже абсолютно логичное соглашение по вышеуказанной причине.

>Лично я предпочитаю сигналы на этапе компиляции.
Логичное предпочтение; но это далеко не всегда возможное. Но в случае с мультиметодами вполне возможно.

>Может это не мы его определили. А из подключаемого модуля нам нужен другой функционал.
Начнём с того, что не "функционал", а "функциональность". Про то, что такое функционал вы можете прочитать на wiki.
Далее, если говорить о CLOS и CL, то модуль, а точнее "пакет" для определения метода должен знать о ваших классах, т.е. импортировать символы классов из вашего пакета. В этом случае, да: пакет может определить реализации методов для классов не принадлежащих данному пакету. И это хорошо!
Приведу пример реального use case. Нужны pre и post проверки при вызове определённых реализаций обобщённого метода. Создаём отдельный пакет, импортируем символы классов, определяем реализацию :before и :after (или :around) методов для нужного набора спецификаторов, пишем проверки. Используем этот пакет. После тестирования и выяснения того, что объекты наших классов работают как надо и assert'ы не срабатывают, то, для увеличения производительности, отключаем пакет.
Прошу заметить! pre и post условия реализуются отдельно, и не надо лезть в реализацию каждого метода писать assert'ы. Разве это не прекрасно?
На самом деле, тут мультиметоды так таковые ни при чём; вполне можно сделать ограничение такое: все классы и использующие их методы определяются в одном месте. Но к чему такое адово ограничение? Понятное дело, что Lisp идёт другим путём.

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

>Проблемы нет, это точно. Потому что мультиметодов нигде нет (и лисп почти не используется).
>Чтобы мультиметоды стали нормальным инструментом, эту несуществующую проблему (и другие) надо разрешить, желательно с полным контролем на этапе компиляции.
Зачем же решать-то несуществующие проблемы?

Вы ж их придумали — вы и решайте; у себя в голове.
А также, все якобы "проблемы" о которых вы говорили вообще никак к проверкам в compile time не относятся — никак не мешают.
Более того, ООП так таковой никакого отношения к compile time не имеет — прекрасно живёт и здравствует как в статически-, так и динамически-типизированных языках.

>На каких же 12 языках вы пишете?

Причем наверняка одновременно. Просто интересно, с кем мне выпала честь беседовать.
Судя по тому, что вы так много говорите про "статические проверки", вероятно у вас закралось подозрение, что с вами тут разговаривает человек не могущий в "божественную статику"

Но не обольщайтесь, я прекрасно понимаю преимущества и недостатки, как статически, так и динамики.
Не плохо знаю OCaml, да и "мейнстримные" вещи, навроде C++ не обходят меня стороной.
Также не плохо осведомлён и о динамике — Python, Ruby, Perl, Tcl, JS.
Common Lisp же не является чистой динамикой. Держу пари, что средств управления compile time в CL куда больше, чем в каком бы то ни было языке, который вы знаете/используете

Осмелюсь предположить, что вы пишите на C# или Java (ну или C++)? Всё так?

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

Меня ваша личность (или чья либо другая) мало интересует. Меня, в первую очередь, интересуют занятные мнения, а также факты/аргументы/доказательства.

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

Как вы можете знать про проблемы реализации (и их решения) мультиметодов, если вы не знаете ничего про самую технологичную реализацию ООП на сегодняшний день — CLOS?

>Да я тоже не берусь в общем-то.
>Просто озвучиваю два не связанных друг с другом факта: что лисп нигде не нужен и мультиметоды нормально пока не реализованы, хотя сама идея неплохая.
Нет. Вы именно судите. А к тому же совершенно невежественно объявляете фактами то, что ими не может никак являться.
Относительно Lisp, то-то же Рич Хикки Java-миру запилил Clojure. Видимо от хорошей Java и от нечего делать (ну и конечно от того, что Lisp "не нужен")

Так считаете?
Ну, а прежде, чем рассуждать о "нормальной реализации" мультеметодов не плохо бы осилить CLOS и рассказать о "ненормальности" CLOS и о том, что действительно такое "нормально"

>Какая еще классическая школа, Симула-67? И причем тут вообще какая-то мифическая классическая школа?
Именно так: Simula, Smalltalk — классическая школа. Никаких мифов тут нет.

>Слишком общий вопрос. Наверное можно сформулировать так. Под костылем я понимаю нечто, что в рамках обсуждаемого предмета удовлетворяет как можно большему числу претензий: ни откуда логически не следует; не является с любой точки зрения лучшим выбором по сравнению с другими вариантами; решает проблему корявым способом, провоцирующим ошибки программиста и/или ошибки времени исполнения. Возможно есть и другие факторы, сейчас в голову не приходит. При этом это нечто не является чем-то общепринятым.

>Под костылем я понимаю нечто, что в рамках обсуждаемого предмета удовлетворяет как можно большему числу претензий:
>ни откуда логически не следует
Соглашение вполне обосновано, аргументы см. выше.
>не является с любой точки зрения лучшим выбором по сравнению с другими вариантами;
Приведите вариант(ы) механизма выбора мультиметода, правильного/лучшего, чем соглашение "слева направо" или одинаково хорошего.
>решает проблему корявым способом, провоцирующим ошибки программиста и/или ошибки времени исполнения
Проблему решает логичным соглашением.
Это соглашение никак не провоцирует ошибки программиста и, тем более, runtime ошибки.

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

>>>Нагромождения скобок в лиспе мешают читать код.
N>>Нет никакого нагромождения.
ARK>Да ладно.
Никаких "да ладно". С написанием и чтением Lisp-кода всё чётко.

ARK>

ARK>(defun project (y x)
ARK>  (let* (
ARK>         (ip-xy (sum (* x y)))
ARK>         (ip-xx (sum (* x x)))
ARK>         (coef  (/ ip-xy ip-xx))
ARK>         )
ARK>    (* coef x)))
ARK>

Вы не верно оформили код. В Lisp сообществе принято так:

(defun project (y x)
  (let* ((ip-xy (sum (* x y)))
         (ip-xx (sum (* x x)))
         (coef  (/ ip-xy ip-xx)))
    (* coef x)))

ARK>А что, если тут одна скобочка будет стоять не там, где надо?
В такое случае IDE поставит вам не верный отступ по которому сразу понятно, что вы пропустили скобку.
К тому же многие лисперы используют режим редактирования соблюдающий баланс скобок (например, paredit-mode в Emacs).

ARK>А что, если это будет не такой примитивный кусок кода, а портянка в несколько тысяч строк?
Всё будет чётко и читаемо. Благодаря соглашению по оформлению.

N>>Есть хорошее соглашение по расстановки скобок, которое позволяет почти всегда их игнорировать; на них просто не обращают никакого внимания.
N>>Скобки мешают лишь lisp-аналитикам, которы никогда не писали и не читали lisp-код.
ARK>Да-да, конечно. И к громкой музыке организм тоже может привыкнуть. Но лучше засыпать в тишине.
ARK>Я бы сказал иначе. Скобки (абсолютно ненужные, синтаксический мусор) мешают многим программистам. Кроме двух с половиной илитариев.
Ещё раз повторюсь. Не "многим программистам", а "авторитетным lisp аналитикам"

У программистов же не возникает никаких проблем с чтением сколь угодно сложноструктурированного lisp-кода.

>>>Просто корявый синтаксис людей отпугивает, а реальных преимуществ нет.
N>>Синтаксис lisp на столько лаконичен и гениален, что "корявостям" просто неоткуда взяться.
ARK>

ARK>Попробуйте brainfuck, еще лаконичнее.
No comments. "Икспиртиза" высочайшего уровня!

>Ну расскажите, как вы это применяете на практике. Сколько строк лисп-кода в вашем проекте, сколько человек в вашей команде и сколько времени и в каком объеме вы поддерживали чужой говнокод на лиспе? А, я забыл, что лисп илитарен настолько, что говнокода на нем не бывает.

Говнокод бывает всегда. CL использую в бою. Lisp полностью оправдал мои ожидания и даже сверх того. Строки считают только идиоты. Чужой говногод на lisp'е сопровождать одинаково сложно как и любой другой говнокод на любом другом ЯП. Другое дело, что среди лисперов почти не встречаются "плохие" разработчики. Поэтому и говнокода меньше.

>Ради интереса приведите же, ну. А то говорите всем известно, а потом в кусты.

Я не буду приводить количественных показателей.

Нет. Если бы у вас было желание найти, вы бы уже давно нашли.

>Если за 50 лет популярности нет — значит язык нишевой во всех смыслах.
Популярность не коррелирует с увеличением производительности труда. Увы и ах.
Чаще всего популярен тот инструмент, у которого порог вхождения ниже плинтуса. Но мы то все знаем, что такая "простота", чаще всего "хуже воровства" (т.е. "простота", в смысле тривиальности/примитивизма).

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

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

>>

Для меня оно не выглядит нормальным.
>>Оно ни откуда не следует, как пятая аксиома Евклида.

N>Не понимаю в чём ненормальность определения приоритета слева направо

А почему не справа налево?

N>То есть вы полагаете что вычисление аргументов при вызове функций в энергичных языках тоже "костыль" и "высосан из пальца"?

В некотором смысле это тоже плохо.

N>И следуют подобные соглашения не "из ни откуда", а из такого соображения, что большинство населения планеты читает текст слева направо; соответственно, такие соглашения воспринимаются просто и естественно.
N>Не согласны? Или вы полагаете, что логично при вызове функций каждый раз явно указывать в каком порядке будут вычислены аргументы?

Я полагаю, что логично не использовать в качестве аргументов вызовы с побочными эффектами. После этого последовательность вычисления аргументов не будет играть роли. Примеры языков — Ada, Eiffel.

ARK>>Скорее как соглашения о множественном наследовании в С++, которые тоже высосаны из пальца.
N>Нет. Это тоже абсолютно логичное соглашение по вышеуказанной причине.

Ознакомьтесь с множественным наследованием в Eiffel. Вот там все логично и без всяких "соглашений".

>>Лично я предпочитаю сигналы на этапе компиляции.
N>Логичное предпочтение; но это далеко не всегда возможное. Но в случае с мультиметодами вполне возможно.

Не все возможно как раз.

>>Может это не мы его определили. А из подключаемого модуля нам нужен другой функционал.
N>Начнём с того, что не "функционал", а "функциональность". Про то, что такое функционал вы можете прочитать на wiki.

Мелкие придирки обычно означают приближающийся слив.

N>Далее, если говорить о CLOS и CL
N>Если же вы боитесь, что импортирование символов пакета приведёт к нежелательным последствиям, то импортируйте только те символы, которые вам необходимы для работы; благо что в механике пакетов CL для всевозможного импортирования и сокрытия символов всё есть.

Я говорю не о CLOS и CL. Но в принципе да, возможность частичного импорта — это и есть костылек, позволяющий обойти проблему. Костылек потому, что выписывать импорты вручную может быть, как мне кажется, весьма геморройно.

N>Зачем же решать-то несуществующие проблемы?

Вы ж их придумали — вы и решайте; у себя в голове.

А, ну сидите в своих розовых очках, я не против.

N>А также, все якобы "проблемы" о которых вы говорили вообще никак к проверкам в compile time не относятся — никак не мешают.

Ну дайте в compile-time гарантию, что при вызове мультиметода не будет исключения. Что, не получается?

N>Более того, ООП так таковой никакого отношения к compile time не имеет — прекрасно живёт и здравствует как в статически-, так и динамически-типизированных языках.

Мейнстрим ООП статический и почти 100% коробочного ПО написано на статически типизированных языках. Кроме веб-сайтов динамики нигде нет и она не нужна. Основное направление в ООП это все же статика.

>>На каких же 12 языках вы пишете?

Причем наверняка одновременно. Просто интересно, с кем мне выпала честь беседовать.
N>Судя по тому, что вы так много говорите про "статические проверки", вероятно у вас закралось подозрение, что с вами тут разговаривает человек не могущий в "божественную статику"

N>Но не обольщайтесь, я прекрасно понимаю преимущества и недостатки, как статически, так и динамики.
N>Не плохо знаю OCaml, да и "мейнстримные" вещи, навроде C++ не обходят меня стороной.
N>Также не плохо осведомлён и о динамике — Python, Ruby, Perl, Tcl, JS.
N>Common Lisp же не является чистой динамикой. Держу пари, что средств управления compile time в CL куда больше, чем в каком бы то ни было языке, который вы знаете/используете

N>Осмелюсь предположить, что вы пишите на C# или Java (ну или C++)? Всё так?

Что-то даже дюжины не набралось.

Я в настоящий момент пишу на C#, Objective-C и JavaScript.
Раньше использовал Delphi, C++, Python и Ruby (на двух последних писал довольно мало, пару утилит).

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

Меня ваша личность (или чья либо другая) мало интересует. Меня, в первую очередь, интересуют занятные мнения, а также факты/аргументы/доказательства.

Ваше суждение о моей квалификации — это переход на личности. А что вас интересует, это совершенно другой вопрос (который лично меня не интересует

).

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

N>Как вы можете знать про проблемы реализации (и их решения) мультиметодов, если вы не знаете ничего про самую технологичную реализацию ООП на сегодняшний день — CLOS?

Ну вот так. Интересуюсь аспектами языкостроения.

>>Да я тоже не берусь в общем-то.
>>Просто озвучиваю два не связанных друг с другом факта: что лисп нигде не нужен и мультиметоды нормально пока не реализованы, хотя сама идея неплохая.
N>Нет. Вы именно судите. А к тому же совершенно невежественно объявляете фактами то, что ими не может никак являться.

О как. Интересно, что же у нас написано на лиспе? Windows, Firefox или может Oracle? А может World of Warcraft? Ничего? Ууупс.
А где у нас мультиметоды? В лиспе, которого нигде нет?

N>Относительно Lisp, то-то же Рич Хикки Java-миру запилил Clojure. Видимо от хорошей Java и от нечего делать (ну и конечно от того, что Lisp "не нужен")

Так считаете?

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

N>Ну, а прежде, чем рассуждать о "нормальной реализации" мультеметодов не плохо бы осилить CLOS и рассказать о "ненормальности" CLOS и о том, что действительно такое "нормально"

Ога, а чтобы рассуждать о яичнице, надо снести яйцо.

>>не является с любой точки зрения лучшим выбором по сравнению с другими вариантами;
N>Приведите вариант(ы) механизма выбора мультиметода, правильного/лучшего, чем соглашение "слева направо" или одинаково хорошего.

Строго по аргументам диспетчеризации без всяких "соглашений".

N>Это соглашение никак не провоцирует ошибки программиста и, тем более, runtime ошибки.

А программист не может ошибиться, написав реализацию и не заметив, что она стоит в списке вызовов на втором месте?

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

N>Вы не верно оформили код. В Lisp сообществе принято так:

Все претензии к оформлению кода — к вашему лисп-сообществу, это оно "оформляло код", а не я.

ARK>>А что, если тут одна скобочка будет стоять не там, где надо?
N>В такое случае IDE поставит вам не верный отступ по которому сразу понятно, что вы пропустили скобку.
N>К тому же многие лисперы используют режим редактирования соблюдающий баланс скобок (например, paredit-mode в Emacs).

(defun project (y x)
  (let* (ip-xy (sum (* x y)))
        (ip-xx (sum (* x x)))
        (coef  (/ ip-xy ip-xx))))
    (* coef x)))

А тут "IDE поставит вам не верный отступ по которому сразу понятно, что вы пропустили скобку"?

ARK>>А что, если это будет не такой примитивный кусок кода, а портянка в несколько тысяч строк?
N>Всё будет чётко и читаемо. Благодаря соглашению по оформлению.

Ага, конечно. Только успевай скобки считать.

N>У программистов же не возникает никаких проблем с чтением сколь угодно сложноструктурированного lisp-кода.

Не у программистов, а у илитариев, которые не пишут и не поддерживают промышленного кода.

ARK>>Попробуйте brainfuck, еще лаконичнее.
N>No comments. "Икспиртиза" высочайшего уровня!

Вполне в вашем духе. Лаконичность это не самоцель.

N>Говнокод бывает всегда. CL использую в бою. Lisp полностью оправдал мои ожидания и даже сверх того. Строки считают только идиоты. Чужой говногод на lisp'е сопровождать одинаково сложно как и любой другой говнокод на любом другом ЯП.

Ну так сколько строк-то, а?

Пара тыщ хоть будет?

N>Другое дело, что среди лисперов почти не встречаются "плохие" разработчики. Поэтому и говнокода меньше.

Говнокода меньше скорее потому, что в целом кода на лиспе почти нет.

>>Ради интереса приведите же, ну. А то говорите всем известно, а потом в кусты.

Я не буду приводить количественных показателей.

N>Нет. Если бы у вас было желание найти, вы бы уже давно нашли.

Ну что, как говорится — слив засчитан.

>>Если за 50 лет популярности нет — значит язык нишевой во всех смыслах.
N>Популярность не коррелирует с увеличением производительности труда. Увы и ах.

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

N>Чаще всего популярен тот инструмент, у которого порог вхождения ниже плинтуса. Но мы то все знаем, что такая "простота", чаще всего "хуже воровства" (т.е. "простота", в смысле тривиальности/примитивизма).

Бред. С++ популярен, но сложен, и порог вхождения у него не особо низкий.

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

__>Здравствуйте, Aikin, Вы писали:
__>>>да, это плохо когда чел фигачит говнокод, лишь бы тесты проходил и работал иногда, а потом с песнями и плясками сваливает в другой проект. "my work here is done.."
A>>А никто про говнокод не говорит. Мне не стыдно его показывать.
__>ну а зачем же тогда его "яростно рефакторить"? или это не ваши слова?
Нет, не мои.

__>я так понял из ваших слов, что вы делаете, чтобы работало, а потом доводите до ума.
Не правильно поняли.

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

__>я так понимаю что все кто сейчас со мной спорят работают фрилансерами в одного колбасят что-то по быстрому. это вырожденный случай разработки.
Опять же нет. Гадалка из вас никакая.

А рефакторю я потому, что обстоятельства изменились. Например знания о системе (мои и команды), требования (или, может, у вас требования не меняются?).
Приходит новый таск, и ты понимаешь, что лучше изменить дизайн системы. Вот и получается рефакторинг. И это происходит очень часто (по мелочи постоянно, по крупняку раз в 1-2 месяца).
Я тоже могу включит гадалку и предположить, что вы...

СУВ, Aikin

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

ARK>

ARK>(defun project (y x)
ARK>  (let* (ip-xy (sum (* x y)))
ARK>        (ip-xx (sum (* x x)))
ARK>        (coef  (/ ip-xy ip-xx))))
ARK>    (* coef x)))
ARK>

ARK>А тут "IDE поставит вам не верный отступ по которому сразу понятно, что вы пропустили скобку"?
Чувак, хватит смеяться с того чего не знаешь. Твой смех только тебя выставляет смешным.

Я, который познакомился с Лиспом (ну Ракетом) за 2 недели в рамках онлайн курса, нахожу ошибку на раз без всяких IDE.
На самом деле тут нет ничего сложного. http://landoflisp.com/wizards_game.lisp код в разы сложнее и то, неприятия не вызывает.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:
A>А рефакторю я потому, что обстоятельства изменились. Например знания о системе (мои и команды), требования (или, может, у вас требования не меняются?).
A>Приходит новый таск, и ты понимаешь, что лучше изменить дизайн системы. Вот и получается рефакторинг. И это происходит очень часто (по мелочи постоянно, по крупняку раз в 1-2 месяца).
приведите просто конкретный пример такого изменения требований и рефакторинга.
вы не сможете это сделать.
я несколько раз проверял это на людях — вы можете быть сильно убеждены в своей правоте, но вы не сможете привести конкретный пример, что не сможете просто его придумать, потому что на самом деле неправы.

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

__>Здравствуйте, Aikin, Вы писали:
A>>А рефакторю я потому, что обстоятельства изменились. Например знания о системе (мои и команды), требования (или, может, у вас требования не меняются?).
A>>Приходит новый таск, и ты понимаешь, что лучше изменить дизайн системы. Вот и получается рефакторинг. И это происходит очень часто (по мелочи постоянно, по крупняку раз в 1-2 месяца).
__>приведите просто конкретный пример такого изменения требований и рефакторинга.
Ну во первых я уже привел конкретный пример. Да, он без деталей и их не будет. Тон беседы, извините, не способствует появлению деталей.
И таких примеров у меня много. Например буквально недавно менялась архитектура (рефакторинг) -- мобильное приложение, которое писало самостоятельно в базу, теперь оттуда только читает, а пишет через вэбсервис. Причины этого рефакторинга -- изменившиеся требования.

__>вы не сможете это сделать.
Опять гадаете и опять мимо?

__>я несколько раз проверял это на людях — вы можете быть сильно убеждены в своей правоте, но вы не сможете привести конкретный пример, что не сможете просто его придумать, потому что на самом деле неправы.
Чувак, твой тон беседы никак не способствует конструктивному разговору, а потом ты еще удивляешься, что люди "не хотят убедить ТЕБЯ в их правоте". Нахрена оно мне нужно? Я, если чессно, общаюсь тут (в этой теме) только потому, что это не напрягает и я получаю от этого удовольствие.

СУВ, Aikin

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

__>Здравствуйте, Aikin, Вы писали:
A>>Приходит новый таск, и ты понимаешь, что лучше изменить дизайн системы. Вот и получается рефакторинг. И это происходит очень часто (по мелочи постоянно, по крупняку раз в 1-2 месяца).
__>приведите просто конкретный пример такого изменения требований и рефакторинга.
__>вы не сможете это сделать.
джедайские штучки
Про итеративную разработку слышали, или настоящие джедаи отливают код сразу в продакшн одним коммитом, причем, набранный в "copy con"?

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

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

>Все претензии к оформлению кода — к вашему лисп-сообществу, это оно "оформляло код", а не я.
Откуда вы выкапали такой код?

ARK>

ARK>(defun project (y x)
ARK>  (let* (ip-xy (sum (* x y)))
ARK>        (ip-xx (sum (* x x)))
ARK>        (coef  (/ ip-xy ip-xx))))
ARK>    (* coef x)))
ARK>

ARK>А тут "IDE поставит вам не верный отступ по которому сразу понятно, что вы пропустили скобку"?
А вы каким IDE пользуетесь, не notepad случаем?

Emacs мне подобный код отформатировал следующим образом:

(defun project (y x)
  (let* (ip-xy (sum (* x y)))
    (ip-xx (sum (* x x)))
    (coef  (/ ip-xy ip-xx))))
(* coef x)))

Более того, подсветил 2 последние скобки. Косяк очевиден.

ARK>>>А что, если это будет не такой примитивный кусок кода, а портянка в несколько тысяч строк?
N>>Всё будет чётко и читаемо. Благодаря соглашению по оформлению.
ARK>Ага, конечно. Только успевай скобки считать.

Никто скобки не считает. Ни когда пишут код (IDE считает и рисует скобки автоматически), ни, тем более, когда читают. Сколько ещё раз повторить? Я даже про paredit-mode вам рассказал.

ARK>Вполне в вашем духе. Лаконичность это не самоцель.
Лаконичность и выразительность кода в lisp достигается за счёт МП (макросов), за счёт абстрагирования от не тривиального boilerplate. Это куда важнее, чем, например, примитивная лаконичность "точечки".

N>>Говнокод бывает всегда. CL использую в бою. Lisp полностью оправдал мои ожидания и даже сверх того. Строки считают только идиоты. Чужой говногод на lisp'е сопровождать одинаково сложно как и любой другой говнокод на любом другом ЯП.

ARK>Ну так сколько строк-то, а?

Пара тыщ хоть будет?

N>>Другое дело, что среди лисперов почти не встречаются "плохие" разработчики. Поэтому и говнокода меньше.
ARK>Говнокода меньше скорее потому, что в целом кода на лиспе почти нет.

>>>Ради интереса приведите же, ну. А то говорите всем известно, а потом в кусты.

Я не буду приводить количественных показателей.

N>>Нет. Если бы у вас было желание найти, вы бы уже давно нашли.

ARK>

ARK>Ну что, как говорится — слив засчитан.
Детский сад... право дело. Но да, действительно: "слив" ваших надуманных проблем и крестьянских рассуждений о ситаксисе близок как никогда

>>>Если за 50 лет популярности нет — значит язык нишевой во всех смыслах.
N>>Популярность не коррелирует с увеличением производительности труда. Увы и ах.

ARK>Люди не дураки, не надо считать себя умнее других. Если инструмент даст реальные преимущества, он будет использоваться. В целом более популярный инструмент увеличивает производительность труда, т.к. выше шанс найти компетентного человека (взамен заболевшего или уволившегося, например).
Ваш критерий выбора инструмента — популярность, примитивен и глуп. Но он единственный, я понимаю. Ведь по существу вам возратить нечего.

N>>Чаще всего популярен тот инструмент, у которого порог вхождения ниже плинтуса. Но мы то все знаем, что такая "простота", чаще всего "хуже воровства" (т.е. "простота", в смысле тривиальности/примитивизма).

ARK>Бред. С++ популярен, но сложен, и порог вхождения у него не особо низкий.
С++ стал популярен, ввиду популярости Си и Си-образного синтаксиса. Именно поэтому, помимо всего прочего, популярны такие языки как Java и C#.

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

ARK>>А тут "IDE поставит вам не верный отступ по которому сразу понятно, что вы пропустили скобку"?
A>Чувак, хватит смеяться с того чего не знаешь. Твой смех только тебя выставляет смешным.

Чувак, я не смеюсь, а спрашиваю.

A>Я, который познакомился с Лиспом (ну Ракетом) за 2 недели в рамках онлайн курса, нахожу ошибку на раз без всяких IDE.

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

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

>А почему не справа налево?
А я уже писал почему. Удосуждесь прочесть.

N>>Логичное предпочтение; но это далеко не всегда возможное. Но в случае с мультиметодами вполне возможно.
ARK>Не все возможно как раз.
Не вижу никаких проблем, кроме "высосаной из пальца" проблемы неоднозначности.
Может быть вы расскажите?

ARK>Мелкие придирки обычно означают приближающийся слив.

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

ARK>Я говорю не о CLOS и CL. Но в принципе да, возможность частичного импорта — это и есть костылек, позволяющий обойти проблему. Костылек потому, что выписывать импорты вручную может быть, как мне кажется, весьма геморройно.
Гемморойно, если в языке нет нормальных средств управления импортом, экспортом. CL к таковым языкам не относится. Вам совершенно не обязательно перечислять всё, что нужно импортировать. Можно пойти другим путём — импортировать всё и скрыть те символы, которые не желательны или конфликтуют.

N>>Зачем же решать-то несуществующие проблемы?

Вы ж их придумали — вы и решайте; у себя в голове.
ARK>А, ну сидите в своих розовых очках, я не против.

Розовые очки? Вы это серьёзно? Я тут рассказываю совершенно про конкретную реализацию ООП с мультиметодами. Вы же говорите про какие-то "сферические" мультиметоды. Про розовые очки, это явно вопрос ко мне

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

>Кроме веб-сайтов динамики нигде нет и она не нужна.
Очередная полная чушь. Тот же Python использую куда в более шириком смысле.

ARK>Что-то даже дюжины не набралось.

Если ещё и перечислить все "трансляторы" и DSL'и, которые я использую, будет куда больше, чем 12.

ARK>Ну вот так. Интересуюсь аспектами языкостроения.
Не верю. Человек, который интересуется "аспектами языкостроения" и не знакомый с Lisp — это сказки.

N>>Относительно Lisp, то-то же Рич Хикки Java-миру запилил Clojure. Видимо от хорошей Java и от нечего делать (ну и конечно от того, что Lisp "не нужен")

Так считаете?
ARK>То, что кто-то что-то "запилил", не говорит ни о чем вообще. Языки появляются тысячами и исчезают. Вот когда на кложуре будет вестись промышленная разработка, тогда и поговорим. А пока это пшик.
Т.е. вы снова не удосужились проверить где и как используется Clojure, но уже заявляете?

N>>Ну, а прежде, чем рассуждать о "нормальной реализации" мультеметодов не плохо бы осилить CLOS и рассказать о "ненормальности" CLOS и о том, что действительно такое "нормально"

ARK>Ога, а чтобы рассуждать о яичнице, надо снести яйцо.
Мде... No comments, снова.

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

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

>>Все претензии к оформлению кода — к вашему лисп-сообществу, это оно "оформляло код", а не я.
N>Откуда вы выкапали такой код?

В гугле набрал "lisp examples" и тыркнул в первую ссылку.

N>Emacs мне подобный код отформатировал следующим образом:
N>Более того, подсветил 2 последние скобки. Косяк очевиден.

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

ARK>>Вполне в вашем духе. Лаконичность это не самоцель.
N>Лаконичность и выразительность кода в lisp достигается за счёт МП (макросов), за счёт абстрагирования от не тривиального boilerplate. Это куда важнее, чем, например, примитивная лаконичность "точечки".

Все это хорошо, но должно быть убедительно подтверждено киллер-приложением. Пока что я таких не видел.

ARK>>Ну что, как говорится — слив засчитан.
N>Детский сад... право дело. Но да, действительно: "слив" ваших надуманных проблем и крестьянских рассуждений о ситаксисе близок как никогда

Реальность пока что подтверждает мои крестьянские рассуждения.

Удобные фичи идут в мейнстрим (элементы ФП, notnull ссылки по умолчанию и т.д.), а маргинальные — нет.

ARK>>Люди не дураки, не надо считать себя умнее других. Если инструмент даст реальные преимущества, он будет использоваться. В целом более популярный инструмент увеличивает производительность труда, т.к. выше шанс найти компетентного человека (взамен заболевшего или уволившегося, например).
N>Ваш критерий выбора инструмента — популярность, примитивен и глуп. Но он единственный, я понимаю. Ведь по существу вам возратить нечего.

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

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

>>А почему не справа налево?
N>А я уже писал почему. Удосуждесь прочесть.

Потому что люди читают слева направо?

Это прекрасно.

N>Не вижу никаких проблем, кроме "высосаной из пальца" проблемы неоднозначности.
N>Может быть вы расскажите?

Я уже три раза называл ряд проблем: нужна гарантия на этапе компиляции, что при вызове мультиметода не будет исключения; желательна возможность определения "абстрактного" мультиметода; нужна возможность задания области поиска реализаций мультиметода, желательно, чтобы это можно было делать просто. Да, еще есть проблема распухания таблицы виртуальных вызовов (сильно падает скорость поиска метода, что критично в ряде приложений).

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

Это неплохо, но все равно, как я понимаю, импортируемые "символы" могут быть весьма длинными.

>>Мейнстрим ООП статический и почти 100% коробочного ПО написано на статически типизированных языках. Кроме веб-сайтов динамики нигде нет и она не нужна. Основное направление в ООП это все же статика.
N>Полная чушь. ООП в суте своей динамика — отложенное определение конкретной реализации метода.

Это у вас полная чушь. У ООП много сутей. По Алану Кею ООП это просто объекты, обменивающиеся сообщениями и ничего больше. Без наследования и классов.

>>Кроме веб-сайтов динамики нигде нет и она не нужна.
N>Очередная полная чушь. Тот же Python использую куда в более шириком смысле.

Это была гипербола.
Но в любом случае использование Python/Ruby по сравнению с C/C++/C#/Java и в микроскоп не видно.

ARK>>Что-то даже дюжины не набралось.

N>Если ещё и перечислить все "трансляторы" и DSL'и, которые я использую, будет куда больше, чем 12.

А, вон оно что.

(Я тоже не все перечислил, если что.

)

ARK>>Ну вот так. Интересуюсь аспектами языкостроения.
N>Не верю. Человек, который интересуется "аспектами языкостроения" и не знакомый с Lisp — это сказки.

Я в целом знаком с lisp и он мне не нравится.

N>Т.е. вы снова не удосужились проверить где и как используется Clojure, но уже заявляете?

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

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

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

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

>>>Все претензии к оформлению кода — к вашему лисп-сообществу, это оно "оформляло код", а не я.
N>>Откуда вы выкапали такой код?
ARK>В гугле набрал "lisp examples" и тыркнул в первую ссылку.

Молодец

ARK>А, ну ок. Но это частный случай, вполне возможно, что баланс скобок нарушен не будет, а смысл программы изменится.
Смысл изменится и отступы изменятся.

ARK>Да и IDE не всегда есть, например когда смотрим коммиты в системе контроля версий.
И хорошо. Смотрим и читаем. В чём проблема-то? Ведь код будет уже с правильной расстановкой отступов.

ARK>>>Вполне в вашем духе. Лаконичность это не самоцель.
N>>Лаконичность и выразительность кода в lisp достигается за счёт МП (макросов), за счёт абстрагирования от не тривиального boilerplate. Это куда важнее, чем, например, примитивная лаконичность "точечки".
ARK>Все это хорошо, но должно быть убедительно подтверждено киллер-приложением. Пока что я таких не видел.
Для того, что бы в этом убедиться совершенно не обязательно смотреть на киллер-приложения

Достаточно одного из могих любымых примеров про декларативное определение словаря.
Вот, например, в Ruby есть синтакисис для этого:

dict = {a: 1, b: 2, c: 3}

В CL подобного синтаксиса для hash-table нет. Т.е. с коробки можно только так:

(defparameter *ht* (make-hash-table))
(setf (gethash 'a *ht*) 1)
(setf (gethash 'b *ht*) 2)
(setf (gethash 'c *ht*) 3)

Беда. Ведь это типичный шаблонный код. Набросаем простейший макрос:

(defmacro dict (&rest kvs)
  (let ((ht (gensym "ht-")))
    `(let ((,ht (make-hash-table)))
       (loop
          :for tail on (list ,@kvs) by #'cddr
          :for (key val) = (list (car tail) (cadr tail))
          :do (setf (gethash key ,ht) val))
       ,ht)))

и вот оно, декларативное определение содержимого hash-таблицы:

(dict 'a 1
      'b 2
      'c 3)

В C# для словарей тоже нет такого синтаксиса, как и в Objective C. Расскажите почтенной публике, как избавиться в C# от подобного bilerplate'а?

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

N>Достаточно одного из могих любымых примеров про декларативное определение словаря.
N>Вот, например, в Ruby есть синтакисис для этого:
N>

N>dict = {a: 1, b: 2, c: 3}
N>

N>и вот оно, декларативное определение содержимого hash-таблицы:
N>

N>(dict 'a 1
N>      'b 2
N>      'c 3)
N>

N>В C# для словарей тоже нет такого синтаксиса, как и в Objective C. Расскажите почтенной публике, как избавиться в C# от подобного bilerplate'а?

  dict = new Hashtable() { { "a", 1 }, { "b", 2 }, { "c", 3 } }

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

ARK>

ARK>  dict = new Hashtable() { { "a", 1 }, { "b", 2 }, { "c", 3 } }
ARK>

Okay. Хотя и синтаксис избыточен и оставляет желать лучшего

, но пойдём дальше — деструктуризация словаря (удобнейшая фича):

(defmacro dict-bind (list expr &body body)
  (let ((ht (gensym "ht-")))
    `(let ((,ht ,expr))
       (let ,(mapcar (lambda (s) `(,s (gethash ',s ,ht))) list)
         ,@body))))

(dict-bind (a b c) (dict 'a 1
                         'b 2
                         'c 3)
  (list a b c))

;; * (1 2 3)

Как сделаем?

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

ARK>Это у вас полная чушь. У ООП много сутей. По Алану Кею ООП это просто объекты, обменивающиеся сообщениями и ничего больше. Без наследования и классов.
Вот и именно что много сутей. Любая шпана вводит любую суть и называет это ООП'ом

ARK>>>Ну вот так. Интересуюсь аспектами языкостроения.
N>>Не верю. Человек, который интересуется "аспектами языкостроения" и не знакомый с Lisp — это сказки.
ARK>Я в целом знаком с lisp и он мне не нравится.
Обманываете ведь, что знаете?

N>>Т.е. вы снова не удосужились проверить где и как используется Clojure, но уже заявляете?
ARK>Гуглить использование каждого маргинального языка — слишком много чести. Ну найдется полтора проекта, дальше что?
Человеку интересующемуся дизайном ЯП? Не верю...

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

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

N>Okay. Хотя и синтаксис избыточен и оставляет желать лучшего

, но пойдём дальше — деструктуризация словаря (удобнейшая фича):
N>Как сделаем?

Ну, это только костылями.

        class ValueWrap
        {
            public object Value { get; set; }
        }

        void Match(Hashtable map, params ValueWrap[] vars)
        {
            int i = 0;

            foreach (var key in map)
            {
                vars[i].Value = map[key];
                i++;
            }
        }

        ...

        var a = new ValueWrap();
        var b = new ValueWrap();
        var c = new ValueWrap();

        Match(dict, a, b, c);

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

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

ARK>Ну, это только костылями.

ARK>

ARK>        Match(dict, a, b, c);
ARK>

В a надо положить значение под ключем "a", в b — под ключем "b" и т.п.

ARK>Понятно, что у всех языков есть своя сфера применимости, но у кого-то она больше, у кого-то меньше.
Прям сдача позиций. Лучше заявить что такая фича нужна только маргиналам и только в новолуние!

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

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

ARK>>Ну, это только костылями.

ARK>>

ARK>>        Match(dict, a, b, c);
ARK>>

S>В a надо положить значение под ключем "a", в b — под ключем "b" и т.п.

Ну блин. Нормально этого сделать сейчас нельзя, может только если сделают compiler as service.

ARK>>Понятно, что у всех языков есть своя сфера применимости, но у кого-то она больше, у кого-то меньше.
S>Прям сдача позиций. Лучше заявить что такая фича нужна только маргиналам и только в новолуние!

Ну почему, в C# есть еще много чего для улучшения.

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

ARK>Ну блин. Нормально этого сделать сейчас нельзя, может только если сделают compiler as service.
Вообще никак нельзя без внешних препроцессоров.
Идея же compile-time кодогенерации развита в lisp. Любая необходимая фича произвольной сложности реализуется в lisp почти интуитивно.
Подобное МП является обычной практикой в lisp и используется повсеместно даже для решения совершенно обыденных задач.
Я полагаю, что подобный механизм куда более фундаментален, чем любой частный синтаксис частных фич и позволяет запрограммировать язык под любую проблемную область. И никакой ООП в этом не поможет.

Здравствуйте, Aikin, Вы писали:
A>Чувак, твой тон беседы никак не способствует конструктивному разговору, а потом ты еще удивляешься, что люди "не хотят убедить ТЕБЯ в их правоте". Нахрена оно мне нужно? Я, если чессно, общаюсь тут (в этой теме) только потому, что это не напрягает и я получаю от этого удовольствие.
когда "требования меняются" то вместо ложки берут вилку. "рефакторинг" в классическом понимании это попытка сделать из ложки вилку пропилами, а потом заделка пропилов обратно, потому что опять решели вернуться к ложке. вы не сможете привести не одного примера такой переделки, так как вам будет стыдно за это. дело не втом, что там "тон не настраивает" — вы приводите какие-то доводы, спорите со мной, отвечаете на мои посты, а пример привести не можете. я то знаю причину этого — потому что примера такого нет. это повод вам лично задуматься над собственным говнокодерским подходом, раз вы примера ни одного привести не можете, за который не стыдно.

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

__>Здравствуйте, Aikin, Вы писали:
A>>Чувак, твой тон беседы никак не способствует конструктивному разговору, а потом ты еще удивляешься, что люди "не хотят убедить ТЕБЯ в их правоте". Нахрена оно мне нужно? Я, если чессно, общаюсь тут (в этой теме) только потому, что это не напрягает и я получаю от этого удовольствие.
__>когда "требования меняются" то вместо ложки берут вилку.
Перед тем как вместо ложки взять вилку, "едока", тарелку и стол нужно подготовить к использованию ложки. Это и называется рефакторинг, а не то что вы там себе напридумывали.

__>"рефакторинг" в классическом понимании это попытка сделать из ложки вилку пропилами, а потом заделка пропилов обратно, потому что опять решели вернуться к ложке.
В отличии от физического мира, софт он мягкий и пропиленая, а потом заделанная вилка от обычной вилки отличаться не будет.
__>вы не сможете привести не одного примера такой переделки, так как вам будет стыдно за это.
Легко. Есть сущность заказ, работу над заказом можно начать и закончить, на каждую пару старт-стоп в базе создается объект, который содержит данные о времени начала и конца и кучу других вещей. В базе эта сущность есть, а в приложении ее нет. И я отстаивал эту позицию (ибо просто лучше чем сложно, еще один принцип). Сейчас ситуация поменялась и нам все же придется ввести эту сущность в приложение.
Это как раз пример, когда мы подпиливали ложку (ибо необходимость в этой сущности возникла где-то полгода назад), а сейчас меняем ложку на вилку. Ничего стыдного. Рабочий момент.

__>дело не втом, что там "тон не настраивает" — вы приводите какие-то доводы, спорите со мной, отвечаете на мои посты, а пример привести не можете. я то знаю причину этого — потому что примера такого нет.
Нет, все дело в тоне. И пример я привел. Уже три. Только вы их проигнорировали. Почему?

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

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:
A>Перед тем как вместо ложки взять вилку, "едока", тарелку и стол нужно подготовить к использованию ложки. Это и называется рефакторинг, а не то что вы там себе напридумывали.
рефакторинг это переделывние. что-то сделали, потом переделали. получили по сути то же самое. рефактринг это не добавление новых классов, а переписывание кривых старых на такие же кривые. я просил привести пример переписывания кода за который вам не будет стыдно. вы такой пример привести не можете — у вас все время какие-то абстрактные размышления и задачи. я прошу конкретный код, если это непонятно.

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

A>>Перед тем как вместо ложки взять вилку, "едока", тарелку и стол нужно подготовить к использованию ложки. Это и называется рефакторинг, а не то что вы там себе напридумывали.
__>рефакторинг это переделывние. что-то сделали, потом переделали. получили по сути то же самое. рефактринг это не добавление новых классов, а переписывание кривых старых на такие же кривые.
При таком определении, согласен, рефакторингом занимаются только идиоты. Вы сходит, например, на википедию, посмотрите что другипе понимают под этим термином. Может понятние станет почему с вами не согласны.

__> я просил привести пример переписывания кода за который вам не будет стыдно. вы такой пример привести не можете — у вас все время какие-то абстрактные размышления и задачи.
Мало ли что вы просили. "Ключи от квартиры..." вы тоже попросите? Я привел конкретный пример, умному человеку должно быть этого достаточно.

Хотя. Хотите еще конкретнее? Пожалуйста:
История изменений: https://bitbucket.org/akava/saveendo/commits/all/
Пройден селфтест: https://bitbucket.org/akava/saveendo/commits/5eef34fe921b98e142345a7f07021c67b444afeb
Все остальные комиты были связаны с увеличением производительности и качества кода.

Т.е. как я и говорил: делаем хоть как-то, чтобы работало, а затем меняем код (рефакторим), чтобы добиться других целей (в данном случае скорости работы).

__>я прошу конкретный код, если это непонятно.
Мы в архитектуре, код здесь не обязателен.

СУВ, Aikin

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

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

A>>Ну ты пойми, что 90% программистов умом не блещут. Массовая профессия, однако.

Doc>А ты себя к 90% или к оставшимся 10% относишь?

А какая разница? Закон-то соблюдается.

Здравствуйте, Aikin, Вы писали:
A>Хотя. Хотите еще конкретнее? Пожалуйста:
A>История изменений: https://bitbucket.org/akava/saveendo/commits/all/
A>Пройден селфтест: https://bitbucket.org/akava/saveendo/commits/5eef34fe921b98e142345a7f07021c67b444afeb
A>Все остальные комиты были связаны с увеличением производительности и качества кода.
вот и отличненько. какие конкретно коммиты вы относите к рефакторингу? если скажете "все", то давайте сразу договоримся — добавления функционала, дописывание-изменение тестов, багфиксы, изменение настроек рефакторинггом не являются.

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

__>Здравствуйте, Aikin, Вы писали:
A>>Хотя. Хотите еще конкретнее? Пожалуйста:
A>>История изменений: https://bitbucket.org/akava/saveendo/commits/all/
A>>Пройден селфтест: https://bitbucket.org/akava/saveendo/commits/5eef34fe921b98e142345a7f07021c67b444afeb
A>>Все остальные комиты были связаны с увеличением производительности и качества кода.
__>вот и отличненько. какие конкретно коммиты вы относите к рефакторингу?
Например вся ветка StringArray является рефакторингом (5 комитов). Функционал не поменялся, внутренняя структура поменялась.
Комит Preformance improvments: nat(), "string prepend" and "hint chunk" тоже рефакторинг.
Комит Painter speed HUGE increase тоже.

__>если скажете "все", то давайте сразу договоримся — добавления функционала, дописывание-изменение тестов, багфиксы, изменение настроек рефакторинггом не являются.
Конечно не является. Никто с этим не спорит.

Тут вот какой поинт был:
Этап 1: делаем чтобы работало (пройден сэлфтэст).
Этап 2: рефакторим код с целью увеличения производительности и каества кода

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

СУВ, Aikin

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

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

A>Например вся ветка StringArray является рефакторингом (5 комитов). Функционал не поменялся, внутренняя структура поменялась.
это оптимизация в чистом виде

A>Комит Painter speed HUGE increase тоже.
тоже похоже на оптимизацию

A>Комит Preformance improvments: nat(), "string prepend" and "hint chunk" тоже рефакторинг.
а вот это больше на рефакторинг в моем понимании похоже. код невнятный что до, что после. совершенно непонятен мотив изменений, что делает код непонятно, невнятные имена, куча констант забита, еще и отладочное логгирование даже незакомменченным зачекинено. это плохой код. что до, что после.

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

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

__>Здравствуйте, Aikin, Вы писали:
__>спасибо за код.
__>вообще, мне даже и в голову раньше не приходило, что кто-то оптимизацию может называть рефакторингом.
__>я занимался рефакторингом и книжки по нему читал. рефакторинг в классическом его понимании это когда код становится слишком невнятным, сложным к дальнейшему расширению, сложным к отладке, фиксам и его куски переписываются на "грамотный код". оптимизация тут это вообще не то. бывает, что код настолько запутанный, что никто не понимает, почему он тормозит, в этом случае да, можно назвать что рефакторинг делается с целью оптимизации.
__>но оптимизация вообще это совсем другое.
__>оптимизация это хорошо.
На самом деле это был лишь пример. У меня проектов в открытом доступе ровно полтора)), а без кода вы не хотели общаться.
Пример не очень хорош, так как задача, с большего, понятна изначально и изменений в требованих никаких не предвидится. Но особой разницы нет, и не важно почему мы рефакторим (то ли изменились требования, то ли нам нужно чтобы код работал быстрее).
Принцип остается тот же самый: пишем хорошо, насколько можем; при изменении условий (требование или понимание или еще что), останавливаемся и готовим систему к будущим изменениям (рефакторинг).

Примеры, которые я приводил выше, как раз примеры, когда причиной рефакторинга явлются изменение в понимании задачи (пример про отчеты) и изменения в требованиях (пример про мобильное приложение и вэбсервис).
Вот только кода к этим примерам нет. Но я могу прояснить любой заинтересовавший вас момент в них. Код в обоих случаях не плох (не идеал, но куда нам до идеала). Я могу объяснить причины, почему мы изначально не сделали "как надо" и нам пришлось менять код.

A>>Например вся ветка StringArray является рефакторингом (5 комитов). Функционал не поменялся, внутренняя структура поменялась.
__>это оптимизация в чистом виде

A>>Комит Painter speed HUGE increase тоже.
__>тоже похоже на оптимизацию

A>>Комит Preformance improvments: nat(), "string prepend" and "hint chunk" тоже рефакторинг.
__>а вот это больше на рефакторинг в моем понимании похоже. код невнятный что до, что после. совершенно непонятен мотив изменений, что делает код непонятно, невнятные имена, куча констант забита, еще и отладочное логгирование даже незакомменченным зачекинено. это плохой код. что до, что после.
__>вообще, код у вас хорош. я обращаю внимание только на этот кусок. и он является рефакторингом в чисто виде — гавнянный код меняется на другой гавнянный, причем сложно даже понять мотивы изменений.
Задача такая. Посмотрите на спецификацию (страница 6 метод pattern, например). Причем этот код очень критичен к скорости выполнения (1,6 млн. итераций). Не до красоты, ес честно. Но я старался. На самом деле, если знать что именно делает метод, то код ничего.
А мотивы были чистая оптимизация по скорости.
Если взять, например, метод nat(), то я развернул рекурсию в цикл и полностью поменял алгоритм.

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

A>Можно было бы сразу заметить эту закономерность? Возможно. У нас команда новичков и тугодумов? Точно нет.
A>И вообще, у меня принцип работы такой: работай чтобы работало, рабочий код лучше красивого решения, отрефакторить потом всегда успеешь. И мне этот подход нравится.

"всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом на 5 лет вперёд.

On 28.05.2013 13:33, Ikemefula wrote:

> "всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом
> на 5 лет вперёд.
А если то, что вы упорно и красиво делаете, через никому нужно не будет?
Вот и определяют, что важнее рабочее сейчас с плохим кодом, или с
хорошим, но позже.

Posted via RSDN NNTP Server 2.1 beta

On 28.05.2013 13:47, Vzhyk wrote:

> А если то, что вы упорно и красиво делаете, через никому нужно не будет?
> Вот и определяют, что важнее рабочее сейчас с плохим кодом, или с
> хорошим, но позже.
Через год не нужно будет, например.

Posted via RSDN NNTP Server 2.1 beta

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

A>>Можно было бы сразу заметить эту закономерность? Возможно. У нас команда новичков и тугодумов? Точно нет.
A>>И вообще, у меня принцип работы такой: работай чтобы работало, рабочий код лучше красивого решения, отрефакторить потом всегда успеешь. И мне этот подход нравится.

I>"всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом на 5 лет вперёд.
Сочувствую.

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

I>"всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом на 5 лет вперёд.
"Давайте сделаем правильную архитектуру сразу. Начнём с UML диаграммок..." — так рождается (читать: не рождается) ПО которому не суждено выйти в свет, ввиду срывов всех сроков.

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

V>Вот и определяют, что важнее рабочее сейчас с плохим кодом, или с
V>хорошим, но позже.
Всегда лучше тысячу раз бажный, но рабочий продукт, чем продукт которого нет.

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

I>>"всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом на 5 лет вперёд.
N>"Давайте сделаем правильную архитектуру сразу. Начнём с UML диаграммок..." — так рождается (читать: не рождается) ПО которому не суждено выйти в свет, ввиду срывов всех сроков.

А что, кто-то предлагает делать правильную архитектуру сразу или начинать с UML ? Я это видел последний раз наверное в 2004м.

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

I>А что, кто-то предлагает делать правильную архитектуру сразу или начинать с UML ? Я это видел последний раз наверное в 2004м.
Часто апологеты ООП/ООД считают, что стоит начинать с архитектуры (даже тогда, когда ТЗ ещё не до конца осмыслено и разработано). То есть полагают, что проектирование "сверху вниз" является наболее грамотным видом проектирования в большинстве ситуаций. Практика же показывает совершенно обратное. Что, собственно, и пытаются объяснить некторые господа в этом треде.
Я, также как и эти господа, считаю, что стоит начинать с прототипа. В таком подходе есть несколько преимуещств: во-первых, при разработки прототипа выявляются действительные и, на первый взгляд, совершенно не очевидные проблемы; а, во-вторых, если будут поджимать сроки, то в свет можно выпустить какой-никакой продукт (довести до нужной кондиции прототип) и таким образом выпустить продукт быстрее чем конкуренты.

Если говорить короче, то вместо занятий "астронавтикой", в, подавляющем большинстве случаев, лучше начать писать.

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

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

Ты придумал какую то ахинею и сам её опроверг, малатца !

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

Первый способ убить продукт — переточить прототип в продакшн.

N>Если говорить короче, то вместо занятий "астронавтикой", в, подавляющем большинстве случаев, лучше начать писать.

Ага, "что тут думать, трясти надо !"

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

>> "всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом
>> на 5 лет вперёд.
V>А если то, что вы упорно и красиво делаете, через никому нужно не будет?

Да как то у меня такого никогда не было

V>Вот и определяют, что важнее рабочее сейчас с плохим кодом, или с
V>хорошим, но позже.

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

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

A>>>Можно было бы сразу заметить эту закономерность? Возможно. У нас команда новичков и тугодумов? Точно нет.
A>>>И вообще, у меня принцип работы такой: работай чтобы работало, рабочий код лучше красивого решения, отрефакторить потом всегда успеешь. И мне этот подход нравится.

I>>"всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом на 5 лет вперёд.
A>Сочувствую.

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

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

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

A>>>>Можно было бы сразу заметить эту закономерность? Возможно. У нас команда новичков и тугодумов? Точно нет.
A>>>>И вообще, у меня принцип работы такой: работай чтобы работало, рабочий код лучше красивого решения, отрефакторить потом всегда успеешь. И мне этот подход нравится.

I>>>"всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом на 5 лет вперёд.
A>>Сочувствую.

I>Ты не мне сочувствуй, а конторе у которой из за дорого майнтенанса, долгого введения фич, проблем с перформансом, памятью и кучей багов ушли практически все кастомеры.
И им тоже сочувствую. Мне не жалко

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

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

I>>>"всегда успеешь" — так и рождается трудноподдерживаемое г-но с баклогом на 5 лет вперёд.
N>>"Давайте сделаем правильную архитектуру сразу. Начнём с UML диаграммок..." — так рождается (читать: не рождается) ПО которому не суждено выйти в свет, ввиду срывов всех сроков.

I>А что, кто-то предлагает делать правильную архитектуру сразу или начинать с UML ? Я это видел последний раз наверное в 2004м.
Я, как ни странно, тоже не предлагал писать г-но, но ты этот призыв у меня увидел

Этакий взгляд со стороны. Спасибо nullxdth!

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

ARK>>Понятно, что у всех языков есть своя сфера применимости, но у кого-то она больше, у кого-то меньше.
S>Прям сдача позиций. Лучше заявить что такая фича нужна только маргиналам и только в новолуние!

За 10 минут:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;

namespace AdvancedDictUnpack
{
    class Program
    {
        static void Main(string[] args)
        {
            var dict = new Dictionary<string, int>() { { "a", 1 }, { "b", 2 }, { "c", 3 } };
            int a = 0;
            int b = 0;
            int c = 0;

            UnpackDict(dict, () => new { a, b, c });

            Console.WriteLine("{0}, {1}, {2}", a, b, c);
        }
        
        private static void UnpackDict(IDictionary d, Expression<Func<object>> target)
        {
            var nt = target.Body as NewExpression;
            if (nt == null)
                throw new ArgumentException("Target does not refer to an object initializer", "target");

            foreach (var a in nt.Arguments)
            {
                var am = a as MemberExpression;
                if (am == null)
                    throw new ArgumentException(string.Format("{0} does not refer to a member access expression", a.ToString()), "target");
 
                var to = (am.Expression as ConstantExpression).Value;
                object value = d[am.Member.Name];
                switch (am.Member.MemberType)
                {
                    case MemberTypes.Field:
                        (am.Member as FieldInfo).SetValue(to, value);
                        break;
                    case MemberTypes.Property:
                        (am.Member as PropertyInfo).SetValue(to, value);
                        break;
                    default: throw new ArgumentException(string.Format("Member {0} does not refer to an lvalue"), am.Member.Name);
                }
            }

        }
    }
}

Перед продакшном, конечно, надо точить дальше.

On 28.05.2013 17:57, nullxdth wrote:

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

Posted via RSDN NNTP Server 2.1 beta

On 29.05.2013 10:39, Ikemefula wrote:

> Да как то у меня такого никогда не было
Будет. Как там в известном фильме про несчастные случаи.

Posted via RSDN NNTP Server 2.1 beta

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

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

ARK>>>Понятно, что у всех языков есть своя сфера применимости, но у кого-то она больше, у кого-то меньше.
S>>Прям сдача позиций. Лучше заявить что такая фича нужна только маргиналам и только в новолуние!
S>

S>За 10 минут:
Признаться, мне пришла такая мысль, но не вдохновило то что объявлять и инициировать переменные все равно надо отдельно и массив надо объявить. И 10 минут пожалел.
S>

S>            int a = 0;
S>            int b = 0;
S>            int c = 0;

S>            UnpackDict(dict, () => new { a, b, c });
S>

S>Перед продакшном, конечно, надо точить дальше.
Я бы 7 раз подумал, прежде чем такую штуку в доточенном виде вставлять продакшн. Даже если пришлось бы доставать пару сотен переменных. Преимуществ перед записью

int a = dict["a"];
int b = dict["a"]; // ошибка при редактировании после копипасты,
int c = dict["c"];

почти никаких нет, ошибиться можно столько же раз и компилятор не заметит

UnpackDict(dict, () => new { a, a, c }); // аналогичная ошибка

А в лиспе — действительно удобно.

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

I>Ты придумал какую то ахинею и сам её опроверг, малатца!
Давайте вы попробуете ещё. Только на сей раз с явным указанием противоречий и с аргументами. А я, в свою очередь, приведу вам аргументы с цитатами и ссылками в поддержку подхода "снизу вверх". На первый раз я прощаю вас, но если пустой и не аргументированный батхёрт повторится, мне придётся занести вас в список "малограмотных, но отважных ООП макак"; и из этого списка я никого никогда не вычёркиваю

I>Первый способ убить продукт — переточить прототип в продакшн.
Нет. Первый способ убить продукт — не выпустить его или выпустить не своевременно.

I>Ага, "что тут думать, трясти надо !"
Написание прототипа — это и есть "думать", причём думать основательно и о конкретных проблемах.
Также, по опыту, я знаю, что прототип написанный профессиональным программистом-исследователем более пригоден к выходу в свет и более реюзабелен, чем груда противоречивых интерфейсов (нафантазированных "астронавтами") и куча кода, который только тем и занимается, что пытается обойти различными хаками эту, так сказать, "архитектуру".

Здравствуйте, samius, Вы писали:
S>Признаться, мне пришла такая мысль, но не вдохновило то что объявлять и инициировать переменные все равно надо отдельно и массив надо объявить. И 10 минут пожалел.
S>>

S>>            int a = 0;
S>>            int b = 0;
S>>            int c = 0;

S>>            UnpackDict(dict, () => new { a, b, c });
S>>

Увы, по-другому в языке никак. Ну, то есть не определив переменные, мы ничего не можем сделать — это плата за строгую статическую типизацию. Не инициализировав — нарвёмся на требование definite assignment. Все эти решения были приняты в языке вполне осознанно.

S>Я бы 7 раз подумал, прежде чем такую штуку в доточенном виде вставлять продакшн. Даже если пришлось бы доставать пару сотен переменных. Преимуществ перед записью
S>

S>int a = dict["a"];
S>int b = dict["a"]; // ошибка при редактировании после копипасты,
S>int c = dict["c"]; 
S>

S>почти никаких нет, ошибиться можно столько же раз и компилятор не заметит
S>

S>UnpackDict(dict, () => new { a, a, c }); // аналогичная ошибка
S>

Это отлавливается (правда, в рантайме).

S>А в лиспе — действительно удобно.
Перед тем, как решать, удобно это или нет, неплохо бы посмотреть на реальные сценарии использования. Эти микрофрагменты не говорят вообще ни о чём.
Потому, что задача "собрать корзинку именованных разнотипных значений" встроена в язык безо всяких макросов:

var dict = new {a=1, b=2, c=3};

Можно очень удобно эти значения оттуда доставать при помощи (статически валидируемого!) синтаксиса dict.a, dict.b и так далее.
А раз мы отказались от идеи заворачивать наши данные в нетипизированный словарь, то нет и задачи разворачивать обратно — данные уже здесь.

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

S>Здравствуйте, samius, Вы писали:
S>>Признаться, мне пришла такая мысль, но не вдохновило то что объявлять и инициировать переменные все равно надо отдельно и массив надо объявить. И 10 минут пожалел.

S>Увы, по-другому в языке никак. Ну, то есть не определив переменные, мы ничего не можем сделать — это плата за строгую статическую типизацию. Не инициализировав — нарвёмся на требование definite assignment. Все эти решения были приняты в языке вполне осознанно.
Я понимаю и не предлагаю что-то менять.

S>Это отлавливается (правда, в рантайме).
да

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

S>var dict = new {a=1, b=2, c=3};
S>

Конечно, если рассматривать в качестве задачи не доступ к словарю, а "собрать корзинку разноименованных значений", то решить в C# ее нынче можно в одну строку. Только это другая задача. Я думаю что другая задача и в CL решается.
S>Можно очень удобно эти значения оттуда доставать при помощи (статически валидируемого!) синтаксиса dict.a, dict.b и так далее.
S>А раз мы отказались от идеи заворачивать наши данные в нетипизированный словарь, то нет и задачи разворачивать обратно — данные уже здесь.
Задача красивого размещения данных в словаре только лишь для красивого извлечения из словаря большого смысла не имеет, только красоту и кучу лишнего кода. Но, полагаю, пример был не об этом ))

Здравствуйте, samius, Вы писали:
S>Задача красивого размещения данных в словаре только лишь для красивого извлечения из словаря большого смысла не имеет, только красоту и кучу лишнего кода. Но, полагаю, пример был не об этом ))
Это понятно. Тем не менее, непонятно, каким образом лисп может гарантировать (в отличие, скажем, от C#) отсутствие ошибок того же типа:
(dict-bind (a a c) (dict 'a 1
'b 2
'c 3)
(list a b c))

S>Перед тем, как решать, удобно это или нет, неплохо бы посмотреть на реальные сценарии использования. Эти микрофрагменты не говорят вообще ни о чём.
S>Потому, что задача "собрать корзинку именованных разнотипных значений" встроена в язык безо всяких макросов
Цель деструктуризации словаря — это не "собрать корзинку именованных разнотипных значений", а декларативно извлечь значения по ключам и определить лексическую область видимости со связанными идентификаторами за этими значениями. Конструкция деструктуризации совершенно ортогональна модели типизации. Деструктуризацию можно считать частным случаем pattern matching'а в ФП.
Например, подобную конструкцию можно запрограммировать в OCaml (статически и строготипизированном языке) при помощи Camlp4. В Lisp и OCaml это можно, а в C# нельзя, ибо C# не умеет МП; и статическая типизация тут совершенно ни при чём.

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

S>Здравствуйте, samius, Вы писали:
S>>Задача красивого размещения данных в словаре только лишь для красивого извлечения из словаря большого смысла не имеет, только красоту и кучу лишнего кода. Но, полагаю, пример был не об этом ))
S>Это понятно. Тем не менее, непонятно, каким образом лисп может гарантировать (в отличие, скажем, от C#) отсутствие ошибок того же типа:
S>(dict-bind (a a c) (dict 'a 1
S> 'b 2
S> 'c 3)
S> (list a b c))
Мне тоже.
Но я когда говорил об ошибках такого типа я сравнивал две записи на C# — одну в лоб через объявление с инициализацией (1) — другую через создание Expression с уже объявленными переменными (2). Точнее об отсутствии явных преимуществ второго способа перед первым. Это относилось к тому, почему бы я в продакшне не стал так делать.
Зато оценил саму реализацию как способ разминки серого вещества оценкой "спасибо".

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

I>>Ты придумал какую то ахинею и сам её опроверг, малатца!
N>Давайте вы попробуете ещё. Только на сей раз с явным указанием противоречий и с аргументами. А я, в свою очередь, приведу вам аргументы с цитатами и ссылками в поддержку подхода "снизу вверх". На первый раз я прощаю вас, но если пустой и не аргументированный батхёрт повторится, мне придётся занести вас в список "малограмотных, но отважных ООП макак"; и из этого списка я никого никогда не вычёркиваю

http://rsdn.ru/forum/design/5183606.1
Ахинея : "стоит начинать с архитектуры (даже тогда, когда ТЗ ещё не до конца осмыслено и разработано)"
Это утверждение ниоткуда не следует, ты сам его вбросил, приписав идею мифическим "апологеты ООП/ООД считают"
Все остальное по ссылке это аргументы против этой ахинеи. Ты мог бы сэкономить целый пост

Вобщем в список "малограмотных, не умеющих читать макак" можешь занести nullxdth.

I>>Первый способ убить продукт — переточить прототип в продакшн.
N>Нет. Первый способ убить продукт — не выпустить его или выпустить не своевременно.

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

I>>Ага, "что тут думать, трясти надо !"
N>Написание прототипа — это и есть "думать", причём думать основательно и о конкретных проблемах.
N>Также, по опыту, я знаю, что прототип написанный профессиональным программистом-исследователем более пригоден к выходу в свет и более реюзабелен, чем груда противоречивых интерфейсов (нафантазированных "астронавтами") и куча кода, который только тем и занимается, что пытается обойти различными хаками эту, так сказать, "архитектуру".

И надо полагать, ты где то в треде увидел предложение сделать "груда противоречивых интерфейсов (нафантазированных "астронавтами") и куча кода, который только тем и занимается, что пытается обойти различными хаками эту, так сказать, "архитектуру""

Ссылкой не поделишься ?

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

>> Я, также как и эти господа, считаю, что стоит начинать с прототипа. В
>> таком подходе есть несколько преимуещств: во-первых, при разработки
>> прототипа выявляются действительные и, на первый взгляд, совершенно не
>> очевидные проблемы; а, во-вторых, если будут поджимать сроки, то в свет
>> можно выпустить какой-никакой продукт (довести до нужной кондиции
>> прототип) и таким образом выпустить продукт быстрее чем конкуренты.
V>Но на этом пути есть тоже подводный, не не камень, а подводная скала, о
V>которую разбиваются кучи проектов. Очень часто появляется соблазн этот
V>прототип дорабатывать бесконечно, пока он не зацепится за ту подводную
V>скалу и не потонет. Лучше всего, на прототипе основное обкатать, а потом
V>переписать его уже не как прототип.

Я ж об чем и говорю.

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

S>Здравствуйте, samius, Вы писали:
S>>Задача красивого размещения данных в словаре только лишь для красивого извлечения из словаря большого смысла не имеет, только красоту и кучу лишнего кода. Но, полагаю, пример был не об этом ))
S>Это понятно. Тем не менее, непонятно, каким образом лисп может гарантировать (в отличие, скажем, от C#) отсутствие ошибок того же типа:
S>(dict-bind (a a c) (dict 'a 1
S> 'b 2
S> 'c 3)
S> (list a b c))
Подобного рода ошибки элементарно определяются в compile time путём анализа списка идентификаторов в коде макроса.
Прошу заметить и понять, что код приведенный мною не является кодом промышленного качества. Имел желание лишь показать некоторые возможности МП в Lisp.

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

S>>Перед тем, как решать, удобно это или нет, неплохо бы посмотреть на реальные сценарии использования. Эти микрофрагменты не говорят вообще ни о чём.
S>>Потому, что задача "собрать корзинку именованных разнотипных значений" встроена в язык безо всяких макросов
N>Цель деструктуризации словаря — это не "собрать корзинку именованных разнотипных значений", а декларативно извлечь значения по ключам и определить лексическую область видимости со связанными идентификаторами за этими значениями.
Это как раз понятно. Непонятно, зачем было сначала складывать значения по ключам, чтобы потом их декларативно извлекать.

N> Конструкция деструктуризации совершенно ортогональна модели типизации. Деструктуризацию можно считать частным случаем pattern matching'а в ФП.
Пока мы не начнём смотреть на более высокоуровневую задачу, приведённую деструктуризацию можно считать чем угодно.

N>Например, подобную конструкцию можно запрограммировать в OCaml (статически и строготипизированном языке) при помощи Camlp4. В Lisp и OCaml это можно, а в C# нельзя, ибо C# не умеет МП; и статическая типизация тут совершенно ни при чём.
Я привёл код на С#, который якобы "нельзя".
Полезность его более чем сомнительна — как и во всех случаях, когда мы пытаемся подобрать прямой аналог низкоуровневой конструкции на другом языке. Это как требовать русского перевода для артикля the.
Чтобы сравнивать языки, надо брать более конкретную задачу — и уже смотреть, как она решается. Может внезапно оказаться, что ничего никуда упаковывать не надо, и всё работает и так. Или что любое решение на C# заметно хуже, чем решение на Ocaml.

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

N>>Цель деструктуризации словаря — это не "собрать корзинку именованных разнотипных значений", а декларативно извлечь значения по ключам и определить лексическую область видимости со связанными идентификаторами за этими значениями.
S>Это как раз понятно. Непонятно, зачем было сначала складывать значения по ключам, чтобы потом их декларативно извлекать.
Неужели сложно себе представить такую ситуацию? Например, приходит извне какая-нибудь не слишком тривиальная json структура; десериализуем её и наглядно и декларативно извлекаем нужные поля. Т.е. вместо того, что бы писать портянки boilerplate'а, навроде:

a = dict['foobar']['long_long_field']['a']
b = dict['barbaz']['another_long_long_field']['b']
c = dict['barbaz']['another_long_long_field']['c']

Мы говорим:

{foobar: {long_long_field:         {a},
          another_long_long_field: {b, c}} = dict

Какой подход более сомнителен? Первый или второй?

S>Пока мы не начнём смотреть на более высокоуровневую задачу, приведённую деструктуризацию можно считать чем угодно.
Деструктуризация списков и словарей старейшая у удобнейшая фича и в той или иной мере она присутствует во многия ЯП и её не считают чем угодно, а имеют ввиду совершенно конкретную вещь. Если говорить о деструктуризации словарей, то: "декларативное извлечения значений по ключам и определение лексической области видимости (или внесение в текущую) со связанными идентификаторами с излвечённым значениями."
Если в C# такой конструкции нет, это совершенно не означает, что она сомнительна, ибо полезность доказана временем.

S>Я привёл код на С#, который якобы "нельзя".
Нет. Ваш код не решает поставленной задачи.

S>Полезность его более чем сомнительна — как и во всех случаях, когда мы пытаемся подобрать прямой аналог низкоуровневой конструкции на другом языке. Это как требовать русского перевода для артикля the.
Деструктуризация словарей не является низкоуровевой конструкцией языка Common Lisp. При этом, я показал как можно элементарно добавить, пусть даже весьма ограниченную деструктуризацию, всего в несколько строк кода.
Вы же написали портянку C# кода и при этом так и не решили поставленной задачи. Ведь C# не может МП и вовсе не из-за статической типизации. Что, собственно, и требовалось доказать.

S>Чтобы сравнивать языки, надо брать более конкретную задачу — и уже смотреть, как она решается. Может внезапно оказаться, что ничего никуда упаковывать не надо, и всё работает и так. Или что любое решение на C# заметно хуже, чем решение на OСaml.
Пример привёл выше.
И да. Любое решение в котором, для ясности, требуется внести не тривиальные абстракции скрывающие низкоуровневые подробности, на C# будет заметно проигрывать, например, Lisp'у, ввиду отстутствия МП в C# и наличии развитого МП в Lisp.
Задача с деструктуризацией это прекрасно показывает. Если хотите более сложные примеры, то советую прочесть, например, Art of Metaobject Protocol.

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

N>

N>{foobar: {long_long_field:         {a},
N>          another_long_long_field: {b, c}} = dict
N>

Прошу прощения, допустил ошибку.
Вот так:

{foobar: {long_long_field:         {a}},
 barbaz: {another_long_long_field: {b, c}}} = dict

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

S>Я привёл код на С#, который якобы "нельзя".
Хотя, вообще, да. Решение близко к правде.

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

N>Неужели сложно себе представить такую ситуацию? Например, приходит извне какая-нибудь не слишком тривиальная json структура; десериализуем её и наглядно и декларативно извлекаем нужные поля.
Такую ситуацию — не, несложно.

Т.е. вместо того, что бы писать портянки boilerplate'а, навроде:
N>

N>a = dict['foobar']['long_long_field']['a']
N>b = dict['barbaz']['another_long_long_field']['b']
N>c = dict['barbaz']['another_long_long_field']['c']
N>

N>Мы говорим:
N>

N>{foobar: {long_long_field:         {a},
N>          another_long_long_field: {b, c}} = dict
N>

N>Какой подход более сомнителен? Первый или второй?
Оба совершенно одинаково сомнительны. Разница — исключительно синтаксическая. Мы всё равно прошиваем пути внутри Json, и всё равно получаем контроль ошибок только в рантайме.
В C# мы бы писали

dynamic foobar = jsonString.ParseJson().foobar;
int a = foobar.long_long_field.a;
var bc = foobar.another_long_long_field;

Или бы сразу создали экземпляр безымянного типа с мемберами a, b, c — вместо локальных переменных — и проинициализровали его из Json (или XML, или Name=Value коллекции).

N>Деструктуризация списков и словарей старейшая у удобнейшая фича и в той или иной мере она присутствует во многия ЯП и её не считают чем угодно, а имеют ввиду совершенно конкретную вещь. Если говорить о деструктуризации словарей, то: "декларативное извлечения значений по ключам и определение лексической области видимости (или внесение в текущую) со связанными идентификаторами с излвечённым значениями."
Ещё раз: это очень низкоуровневая конструкция. В управляемых языках вместо неё обычно выполняют разбор, основанный на рефлексии, и в структуру, а не в набор однобуквенных переменных.

N>Нет. Ваш код не решает поставленной задачи.
Какой именно? Словарь деструктуризирован; присваивание в переменные (которое пока непонятно зачем) выполнено.

N>Вы же написали портянку C# кода и при этом так и не решили поставленной задачи. Ведь C# не может МП и вовсе не из-за статической типизации. Что, собственно, и требовалось доказать.
Значит, такая была постановка задачи. Вашему примеру мой код полностью удовлетворяет.

N>Пример привёл выше.
N>И да. Любое решение в котором, для ясности, требуется внести не тривиальные абстракции скрывающие низкоуровневые подробности, на C# будет заметно проигрывать, например, Lisp'у, ввиду отстутствия МП в C# и наличии развитого МП в Lisp.
Естественно, в шарпе есть ограничения выразительности. Иначе бы никто не изобретал Nemerle

Но нужны более убедительные примеры, чем рефлексия по месту.
N>Задача с деструктуризацией это прекрасно показывает. Если хотите более сложные примеры, то советую прочесть, например, Art of Metaobject Protocol.
Ок, почитаю.

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

S>Естественно, в шарпе есть ограничения выразительности. Иначе бы никто не изобретал Nemerle

S>Но нужны более убедительные примеры, чем рефлексия по месту.
Если вы говорите про рефлексию, относительно приведенного Lisp кода, то там нет и в помине никакой рефлексии. Только кодогенерация в compile time (точнее до непосредственной компиляции — во время раскрытия макросов).
Покажу на примере.
samius и вы интересовались относительно определения в compile time ошибок, навроде:

(dict-bind (a a c) (dict 'a 1
                         'b 2
                         'c 3)
  (list a b c))

Доработаем немного макрос:

(defun duplicates (xs)
  (let ((table (make-hash-table)))
    (mapc #'(lambda (x)
              (if (gethash x table)
                  (incf (gethash x table))
                  (setf (gethash x table) 1)))
          xs)
    (loop
       :for key :being :the :hash-keys :in table :using (:hash-value val)
       :if (> val 1) :collect key)))

(defmacro dict-bind (keys-list expr &body body)
  (when-let (dups (duplicates keys-list))
    (error (format nil "duplicate keys: ~A" dups)))
  (let ((ht (gensym "ht-")))
    `(let ((,ht ,expr))
       (let ,(mapcar (lambda (s) `(,s (gethash ',s ,ht))) keys-list)
         ,@body))))

И получаем ошибку во время раскрытия макроса со списком дублирующихся идентификаторов.

N>>Задача с деструктуризацией это прекрасно показывает. Если хотите более сложные примеры, то советую прочесть, например, Art of Metaobject Protocol.
S>Ок, почитаю.
Это правильный подход

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

I>>А что, кто-то предлагает делать правильную архитектуру сразу или начинать с UML ? Я это видел последний раз наверное в 2004м.
A>Я, как ни странно, тоже не предлагал писать г-но, но ты этот призыв у меня увидел

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

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

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

N>>Какой подход более сомнителен? Первый или второй?
S>Оба совершенно одинаково сомнительны. Разница — исключительно синтаксическая. Мы всё равно прошиваем пути внутри Json, и всё равно получаем контроль ошибок только в рантайме.
Нет, не одинаково сомнительны. В первом случае имеет место быть шаблонный код — копипаста. В лучшем случае, для избавления от boilerplate'а мы можем завести промежуточные переменные, но это лишние переменные — т.е. лишние подробности извлечения фрагментов. Во-втором же случае нет ни копипасты, ни лишних переменных.
Также мы говором о словаре, структура которого нам заведомо неизвестна. О каком статическом контроле может идти речь?

S>В C# мы бы писали
S>

S>dynamic foobar = jsonString.ParseJson().foobar;
S>int a = foobar.long_long_field.a;
S>var bc = foobar.another_long_long_field;
S>

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

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

N>>Нет. Ваш код не решает поставленной задачи.
S>Какой именно? Словарь деструктуризирован; присваивание в переменные (которое пока непонятно зачем) выполнено.
Да, в целом согласен. Не внимательно прочитал код. Решает, да. Кое-как.

Зачем нужен Nemerle, когда пол века уже есть Lisp?

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

N>Нет, не одинаково сомнительны. В первом случае имеет место быть шаблонный код — копипаста. В лучшем случае, для избавления от boilerplate'а мы можем завести промежуточные переменные, но это лишние переменные — т.е. лишние подробности извлечения фрагментов.
Совершенно непонятно, лишние они или нет. Всё потому, что вы описываете сферическую задачу, где ни семантика, ни дальнейшая судьба этих a и b совершенно неясны. Неясно, насколько часто меняется структура JSON. Неясно, к каким изменениям надо быть готовым, а каких можно не ждать. Неясно, сколько деталей важно прикладному программисту для понимания ситуации.

N>Также мы говором о словаре, структура которого нам заведомо неизвестна. О каком статическом контроле может идти речь?
Вот именно.
S>>В C# мы бы писали
S>>

S>>dynamic foobar = jsonString.ParseJson().foobar;
S>>int a = foobar.long_long_field.a;
S>>var bc = foobar.another_long_long_field;
S>>

N>И тем самым не избавились бы от копипасты.
Не понял, что вы называете копипастой. Покажите, какие именно фрагменты кода вы считаете копипастой, и куда они деваются в вашем коде.

N> В сущности же, в данном случае, нет никакой разницы обращаемся мы через точечку к полям или нет. Разница как раз таки лишь синтаксическая. Ни о какой высокоуровневости говорить не приходится.
Непонятно, что вы называете высокоуровневостью. Задача сводится к тому, чтобы вытащить в плоский кортеж, зачем-то составленный из локальных переменных, данные, расположенные внутри слаботипизированной структуры по некоторым путям.
Простой и очевидный способ записать решение этой задачи вам кажется бойлерплейтом (json["foobar"]["long_long_field"]["a"]).
Зато способ, где пути пишутся слева от переменных, вам кажется "высокоуровневым" и "небойлерплейтом", хотя отличается только порядком аргументов, типом скобочек, и символами цитирования.

N>Ещё раз: разбор на рефлексии нам ничего особенного в этом случае не даст. А деструктуризация какая-никакая абстракция. Мы просто говорим с какими фрагментами мы хотим работать и всё. И набор переменных можеть быть, естесственно, не только "однобуквенный".
Ну и в рефлексии то же самое. Делаем какую-никакую абстракцию, и наши соглашения о том, как енкодятся пути доступа к значениям, запихиваем в библиотечный код. Основная разница — рантайм vs компайл-тайм. Но, как мы только что выяснили, в компайл-тайм мы можем проверить только банальщину типа "нет ли случайно многократных включений одной и той же переменной". А реальные проблемы (типа несоответствия структуры JSON ожиданиям) мы проверить не можем.

N>Да, в целом согласен. Не внимательно прочитал код. Решает, да. Кое-как.

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

I>>>А что, кто-то предлагает делать правильную архитектуру сразу или начинать с UML ? Я это видел последний раз наверное в 2004м.
A>>Я, как ни странно, тоже не предлагал писать г-но, но ты этот призыв у меня увидел

I>Надо полагать ты с первого раза идеально да без ошибок пишешь
Не надо полагать. Я не супермэн.

I>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
Меняются обстоятельства. Я в той ветке об этом говорил.

I>Непонятно.
А теперь?

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

I>>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
A>Меняются обстоятельства. Я в той ветке об этом говорил.

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

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

I>Ахинея : "стоит начинать с архитектуры (даже тогда, когда ТЗ ещё не до конца осмыслено и разработано)"
I>Это утверждение ниоткуда не следует, ты сам его вбросил, приписав идею мифическим "апологеты ООП/ООД считают"
Хорошо. Допустим я сам придумал ООП/ООД апологетов и то, что разработка "сверху вниз" является доминирующим подходом в среде этих апологетов. Хотя, в подтверждении своей "ахинеи", я ещё в начале треда привёл ссылку на мнение о дискусии OOPSLA, где подобной "ахинеей" страдали такие господа, как Пол Грэм и Александр Степанов. Но всё же предположим, что ты просто не внимательно прочёл тред и влетел в обсуждение с термоядерным батхёртом (неизвестного происхождения). Это можно как-то простить.
Но как быть с этим:
I>Ты придумал какую то ахинею и сам её опроверг, малатца!
Где опровержение и противоречие в моих словах?

I>"не выпустить его или выпустить не своевременно" это уже следствие. Не бывает просто так, от балды, "не выпустить" или "выпустить не своевременно". Если говорить про код, то первая из причин это перетачивание прототипа в продакшн.
Нет, бывает. И ещё как бывает. Например, ввиду того, что нужно выпустить продукт раньше намеченного строка. Скажем, разведка доложила, что конкуренты вот-вот на днях зарелизятся.

I>Ссылкой не поделишься?
Нет, не поделюсь. Для начала мне нужно убедиться, что я разговариваю с разумным человеком, а не с воинствующей макакой. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.

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

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

N>>Нет, не одинаково сомнительны. В первом случае имеет место быть шаблонный код — копипаста. В лучшем случае, для избавления от boilerplate'а мы можем завести промежуточные переменные, но это лишние переменные — т.е. лишние подробности извлечения фрагментов.
S>Совершенно непонятно, лишние они или нет. Всё потому, что вы описываете сферическую задачу, где ни семантика, ни дальнейшая судьба этих a и b совершенно неясны. Неясно, насколько часто меняется структура JSON. Неясно, к каким изменениям надо быть готовым, а каких можно не ждать. Неясно, сколько деталей важно прикладному программисту для понимания ситуации.
Хорошо. Попробуем ещё раз. Коли не очевидно.
Допустим у нас есть следующая структура:

{"person": {"first_name": "...",
            "last_name":  "...",
            
            "tel":   {"home":   "...",
                      "office": "...",
                      "extra":  "..."}
            
            "email": {"home":   "...",
                      "office": "...",
                      "extra":  "..."}}}

и есть функция get_person, которая возвращает эту структуру.
Теперь, предположим, нужны только: имя, офисный и дополнительный телефоны, домашний и дополнительный адреса почты.
Мы не знаем что такое деструктуризация и наш язык об этом не знает. Можем поступить так:

result = get_person("Vasya") # result - лишняя сущность (полная информация не нужна)

# Далее идёт очевидная копипаста:
first_name  = result['person']['first_name']
extra       = result['person']['tel']['extra']
office      = result['person']['tel']['office']
home        = result['person']['email']['home']
email_extra = result['person']['email']['extra']

Или так:

person = get_person()['person']    # person - лишнаяя сущность (полная информация не нужна)

first_name = person['first_name']

tel = person['tel']                # tel - лишняя сущность (полная информация о телефонах не нужна)

extra  = tel['extra']              # tel, tel - копипаста
office = tel['office']             #

email = person['email']            # email - лишняя сущность (полная информация о ящиках не нужна)

home        = email['home']        # email, email - копипаста
email_extra = email['extra']       #

А теперь, допустим, мы программируем на CoffeeScript и знаем, что такое Destructuring Assignment.
Говорим так:

{person:
 {first_name,
  tel:   {extra, office},
  email: {home, extra: email_extra}}} = get_person('Vasya')

И получаем в скоупе: first_name, extra, office, home, email_extra и больше ничего. Тут нет ни копипасты, ни лишних сущностей — мы абстрагировались от лишних деталий извлечения информации.
Ещё есть какие-нибудь вопросы? Или это тоже сферическая задача?

S>Не понял, что вы называете копипастой. Покажите, какие именно фрагменты кода вы считаете копипастой, и куда они деваются в вашем коде.
Выше.

S>Простой и очевидный способ записать решение этой задачи вам кажется бойлерплейтом (json["foobar"]["long_long_field"]["a"]).
А вам не кажется? Ведь это и есть boilerplate, когда по foobar или foobar->long_long_field нам нужно извлечь более чем один ключ.

S>Зато способ, где пути пишутся слева от переменных, вам кажется "высокоуровневым" и "небойлерплейтом", хотя отличается только порядком аргументов, типом скобочек, и символами цитирования.
Не кажется. Это действительно более высокоуровневое решение. И отличается оно не только синтаксисом, как было показано выше.

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

I>>>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
A>>Меняются обстоятельства. Я в той ветке об этом говорил.
I>Обстоятельства всегда меняются. Собтсвенно рефакторинг нужен именно по этой причине — слишком часто приходится влазить и читать/править уже написаный работающий код.
Ну я, эта, согласен. Вот только не понял к чему ты это сказал.

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

N>Но как быть с этим:
I>>Ты придумал какую то ахинею и сам её опроверг, малатца!
N>Где опровержение и противоречие в моих словах?

Цтирую некоторую воинствующую макаку, не умеющую читать:

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

I>>"не выпустить его или выпустить не своевременно" это уже следствие. Не бывает просто так, от балды, "не выпустить" или "выпустить не своевременно". Если говорить про код, то первая из причин это перетачивание прототипа в продакшн.
N>Нет, бывает. И ещё как бывает. Например, ввиду того, что нужно выпустить продукт раньше намеченного строка. Скажем, разведка доложила, что конкуренты вот-вот на днях зарелизятся.

То есть, конкретная причина "разведка доложила" есть "от балды" ? Браво !

I>>Ссылкой не поделишься?
N>Нет, не поделюсь. Для начала мне нужно убедиться, что я разговариваю с разумным человеком, а не с воинствующей макакой. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.

Ты похоже о чем то своём, наболевшем. Не буду тебя беспокоить.

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

N>>Но как быть с этим:
I>>>Ты придумал какую то ахинею и сам её опроверг, малатца!
N>>Где опровержение и противоречие в моих словах?

I>Цтирую некоторую воинствующую макаку, не умеющую читать:
I>

I>"Практика же показывает совершенно обратное. Что, собственно, и пытаются объяснить некторые господа в этом треде.
I>Я, также как и эти господа, считаю, что стоит начинать с прототипа. В таком подходе есть несколько преимуещств: во-первых, при разработки прототипа выявляются действительные и, на первый взгляд, совершенно не очевидные проблемы; а, во-вторых, если будут поджимать сроки, то в свет можно выпустить какой-никакой продукт (довести до нужной кондиции прототип) и таким образом выпустить продукт быстрее чем конкуренты.
I>Если говорить короче, то вместо занятий "астронавтикой", в, подавляющем большинстве случаев, лучше начать писать."

И где тут опровержение/противоречие?

I>>>"не выпустить его или выпустить не своевременно" это уже следствие. Не бывает просто так, от балды, "не выпустить" или "выпустить не своевременно". Если говорить про код, то первая из причин это перетачивание прототипа в продакшн.
N>>Нет, бывает. И ещё как бывает. Например, ввиду того, что нужно выпустить продукт раньше намеченного строка. Скажем, разведка доложила, что конкуренты вот-вот на днях зарелизятся.
I>То есть, конкретная причина "разведка доложила" есть "от балды" ? Браво !
Да, действительно. "Разведка доложила" — это вовсе не "от балды". Это одна из обоснованных и весомых причин выпуска доработанного прототипа. Не придирайся к словам, ведь из контекста ясно, что имелось ввиду.

I>>>Ссылкой не поделишься?
N>>Нет, не поделюсь. Для начала мне нужно убедиться, что я разговариваю с разумным человеком, а не с воинствующей макакой. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.
I>Ты похоже о чем то своём, наболевшем. Не буду тебя беспокоить.
Нет. Я спросил тебя в очередной раз за противоречия в моих словах. Ты же продалжаешь своё бессмысленный батхёрт.

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

__>>что такое работа программиста? чем занимается программист? он просто излагает свои мысли насчет устройства программы в виде кода.
__>>откуда у него возникнут другие мысли для написания другово кода? это как в России — какую партию не делай, КПСС получается.
0>Дык, опыт своих же ошибок дает прекрасную пищу для улучшения.
0>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>Собственно, это ключевая идея прототипирования

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

А вот на счет классного кода, то лучший код это код после 5-6 фаз глубокого рефакторинга. При чем рефакторинга не от балды "шоб красивее було", а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд. За рефакторинг без четко поставленых целей надо убивать на месте.

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

I>Ключевая идея прототипирования это не получение классного кода, а сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте.
I>То есть, другими словами, разведка боем.
I>А вот на счет классного кода, то лучший код это код после 5-6 фаз глубокого рефакторинга. При чем рефакторинга не от балды "шоб красивее було", а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд. За рефакторинг без четко поставленых целей надо убивать на месте.

Это верно. Собственно, 0x7be (а также я, Aikin и другие господа) это и имеют ввиду, говоря про лучший код. И с кем ты тут боришься совершенно не ясно.

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

_>Мне кажется что пишут, а потом яростно рефакторят люди которые не понимают как этот дизайн должен делаться и как развиваться. Всегда делаю дизайн на листке, на доске, в средствах автоматизации. Т.к. именно дизайн выражает идею отношений и обязанностей, выражаясь тезисно, "вот мы так задумывали". Дизайн начинается с ответственностей, с интерфейсов и типов. То что вы называете рефакторингом, это не рефакторинг, а переделка, которой скорее всего можно было избежать. Рефакторинг делается тогда, когда новая функциональность не укладывается в старый дизайн. И рефакторинг должен начинаться с дизайна.

Рефакторинг начинается с цели. Если цель — уложить новый функционал, то следующий шаг — дизайн.

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

I>>А вот на счет классного кода, то лучший код это код после 5-6 фаз глубокого рефакторинга. При чем рефакторинга не от балды "шоб красивее було", а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд. За рефакторинг без четко поставленых целей надо убивать на месте.

N>Это верно. Собственно, 0x7be (а также я, Aikin и другие господа) это и имеют ввиду, говоря про лучший код. И с кем ты тут боришься совершенно не ясно.

Мне тоже не ясно где ты борьбу видишь, т.к. я всего то излагаю собственно мнение

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

I>>Цтирую некоторую воинствующую макаку, не умеющую читать:
I>>

I>>"Практика же показывает совершенно обратное. Что, собственно, и пытаются объяснить некторые господа в этом треде.
I>>Я, также как и эти господа, считаю, что стоит начинать с прототипа. В таком подходе есть несколько преимуещств: во-первых, при разработки прототипа выявляются действительные и, на первый взгляд, совершенно не очевидные проблемы; а, во-вторых, если будут поджимать сроки, то в свет можно выпустить какой-никакой продукт (довести до нужной кондиции прототип) и таким образом выпустить продукт быстрее чем конкуренты.
I>>Если говорить короче, то вместо занятий "астронавтикой", в, подавляющем большинстве случаев, лучше начать писать."

N>И где тут опровержение/противоречие?

Все, целиком.

I>>>>"не выпустить его или выпустить не своевременно" это уже следствие. Не бывает просто так, от балды, "не выпустить" или "выпустить не своевременно". Если говорить про код, то первая из причин это перетачивание прототипа в продакшн.
N>>>Нет, бывает. И ещё как бывает. Например, ввиду того, что нужно выпустить продукт раньше намеченного строка. Скажем, разведка доложила, что конкуренты вот-вот на днях зарелизятся.
I>>То есть, конкретная причина "разведка доложила" есть "от балды" ? Браво !
N>Да, действительно. "Разведка доложила" — это вовсе не "от балды". Это одна из обоснованных и весомых причин выпуска доработанного прототипа. Не придирайся к словам, ведь из контекста ясно, что имелось ввиду.

По моему "от балды" и "разведка доложила" это разные вещи и это предельно ясно любому.

N>>>Нет, не поделюсь. Для начала мне нужно убедиться, что я разговариваю с разумным человеком, а не с воинствующей макакой. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.
I>>Ты похоже о чем то своём, наболевшем. Не буду тебя беспокоить.
N>Нет. Я спросил тебя в очередной раз за противоречия в моих словах. Ты же продалжаешь своё бессмысленный батхёрт.

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

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

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

I>>>>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
A>>>Меняются обстоятельства. Я в той ветке об этом говорил.
I>>Обстоятельства всегда меняются. Собтсвенно рефакторинг нужен именно по этой причине — слишком часто приходится влазить и читать/править уже написаный работающий код.
A>Ну я, эта, согласен. Вот только не понял к чему ты это сказал.

Ты лучше свои сообщения перечитай

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

I>>>>>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
A>>>>Меняются обстоятельства. Я в той ветке об этом говорил.
I>>>Обстоятельства всегда меняются. Собтсвенно рефакторинг нужен именно по этой причине — слишком часто приходится влазить и читать/править уже написаный работающий код.
A>>Ну я, эта, согласен. Вот только не понял к чему ты это сказал.

I>Ты лучше свои сообщения перечитай

Давай на этом и закончим, ок?

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

I>>Ты лучше свои сообщения перечитай

A>Давай на этом и закончим, ок?

Можно и закончить, я не против.

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

I>Мне тоже не ясно где ты борьбу видишь, т.к. я всего то излагаю собственно мнение

Например:
0x7be, говорит:
0>Дык, опыт своих же ошибок дает прекрасную пищу для улучшения.
0>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>Собственно, это ключевая идея прототипирования
Ты же отвечаешь так, будто 0x7be не прав относительно идеи прототипирования:
I>Ключевая идея прототипирования это не получение классного кода, а сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте.
I>То есть, другими словами, разведка боем.
Будто 0x7be, говоря про лучший код имел ввиду нечто другое, отличное от
I>[...] а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд.
Фактически ты, на правах капитана, сказал тоже самое, что говорил 0x7be и Aikin, но сказал так, будто это нечто иное, отличное от того что говорят господа.
И почему я тут вижу некую борьбу непонятного происхождения? Чёрт его знает...

(у меня есть подозрения, что не только я эту борьбу вижу)

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

I>>Ключевая идея прототипирования это не получение классного кода, а сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте.
I>>То есть, другими словами, разведка боем.
0>Зачем ты ограничиваешь цели прототипирования только требованиями?

Правильно понимаю, в строчке ниже ты видишь только два первых слова ?
"сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте"

0>ПМСМ, прототипирование — это экспериментальная проверка своих гипотез, в том числе и технического характера.

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

Проверка гипотез это слишком мало.

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

N>Например:
N>0x7be, говорит:
0>>Дык, опыт своих же ошибок дает прекрасную пищу для улучшения.
0>>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>>Собственно, это ключевая идея прототипирования
N>Ты же отвечаешь так, будто 0x7be не прав относительно идеи прототипирования:
I>>Ключевая идея прототипирования это не получение классного кода, а сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте.
I>>То есть, другими словами, разведка боем.
N>Будто 0x7be, говоря про лучший код имел ввиду нечто другое, отличное от
I>>[...] а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд.
N>Фактически ты, на правах капитана, сказал тоже самое, что говорил 0x7be и Aikin, но сказал так, будто это нечто иное, отличное от того что говорят господа.

Опыт, лучший код, понятный, тестируемый — это все второстепенные вещи и именно об этих второстепенных вещах говорит 0x7be.

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

Пример из жизни — в новой версии приложения было решено слепить прототип для посмотреть новый функционал. Прототип показал, что задача не решаема в заданном контексте. Именно — не решаема.

Менеджмент посмотрел прототип, подумал и свернул все приложение.

Для аутсорсной говноконторы это фейл, они перестали получать бабло за проект.

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

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

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

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

I>>Ахинея : "стоит начинать с архитектуры (даже тогда, когда ТЗ ещё не до конца осмыслено и разработано)"
I>>Это утверждение ниоткуда не следует, ты сам его вбросил, приписав идею мифическим "апологеты ООП/ООД считают"
N>Хорошо. Допустим я сам придумал ООП/ООД апологетов и то, что разработка "сверху вниз" является доминирующим подходом в среде этих апологетов. Хотя, в подтверждении своей "ахинеи", я ещё в начале треда привёл ссылку на мнение о дискусии OOPSLA, где подобной "ахинеей" страдали такие господа, как Пол Грэм и Александр Степанов. Но всё же предположим, что ты просто не внимательно прочёл тред и влетел в обсуждение с термоядерным батхёртом (неизвестного происхождения). й. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.

На счет сверху вниз и снизу вверх. Здесь очень просто. Если ты решаешьш новую задачу и в ней мног неизвестных, нужно выбирать решение снизу вверх. то есть, решаешь маленькие задачи, потом побольше, побольше и тд.
Когда же ты решил множество задач в одном классе, то как правило неизвестных совсем мало и здесь можно и нужно использовать решение сверху вниз.

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

I>Здравствуйте, Аноним, Вы писали:

А>>ООН = Объектно Ориентированные Нагромождения

I>Вот тебе поддержка из Википедии:

I>Alexander Stepanov suggested that OOP provides a mathematically limited viewpoint and called it "almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work....".

Что-то в таком духе я всегда про него и думал, глядя на STL. "an interesting piece of code", панимаешшшшь. Я вот насмотрелся на интересный код, и теперь научился ценить самый неинтересный код.

I>Paul Graham has suggested that the purpose of OOP is to act as a "herding mechanism" that keeps mediocre programmers in mediocre organizations from "doing too much damage". This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques.

Золотые слова. Люто, бешенно плюсую.

К сожалению, какой же дурак не считает себя "productive programmer who knows how to use more powerful and more compact techniques", откуда и вся эта современная любовь к глобальным функциям в неймспейсах.

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

К счастью, многие фреймворки пишут действительно не-mediocre programmers, и получается очень няшно. FCL, например. Спасибо и на том, что дурацкий код с вызовами FCL становится почитабельнее, чем с вызовами STL/CRT.

I>Joe Armstrong, the principal inventor of Erlang, is quoted as saying "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

Ага, только вот из всего софта, что я видел, именно ejabberd, знаковый продукт Эрланга на тот момент, я НЕ смог завести вообще. Что-то там у него с environment было

. Не находил чего-то.

Здравствуйте, Аноним, Вы писали:

А>

I>>Joe Armstrong, the principal inventor of Erlang, is quoted as saying "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

А>Ага, только вот из всего софта, что я видел, именно ejabberd, знаковый продукт Эрланга на тот момент, я НЕ смог завести вообще. Что-то там у него с environment было

. Не находил чего-то.

Количественный показатель ПО никак не умаляет вполне справедливого, на мой взгяд, высказывания Армистронга относительно ООП.
Также на Erlang написан ряд качественного и широкоиспользуемого ПО; например, RabbitMQ, CouchDB.

Здравствуйте, Аноним, Вы писали:

А>

I>>Paul Graham has suggested that the purpose of OOP is to act as a "herding mechanism" that keeps mediocre programmers in mediocre organizations from "doing too much damage". This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques.

А>Золотые слова. Люто, бешенно плюсую.
А>К сожалению, какой же дурак не считает себя "productive programmer who knows how to use more powerful and more compact techniques", откуда и вся эта современная любовь к глобальным функциям в неймспейсах.
Функция определённая в пространстве имён — не глобальная функция.
Также, когда Грэм говорит про "more compact techniques" он вовсе не имеет ввиду функции в namespace'ах

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

I>На счет сверху вниз и снизу вверх. Здесь очень просто. Если ты решаешьш новую задачу и в ней мног неизвестных, нужно выбирать решение снизу вверх. то есть, решаешь маленькие задачи, потом побольше, побольше и тд.
I>Когда же ты решил множество задач в одном классе, то как правило неизвестных совсем мало и здесь можно и нужно использовать решение сверху вниз.

Убогие и практически не определённые критерии выбора подхода к проектированию/разработке — вода, короче говоря.

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

I>>На счет сверху вниз и снизу вверх. Здесь очень просто. Если ты решаешьш новую задачу и в ней мног неизвестных, нужно выбирать решение снизу вверх. то есть, решаешь маленькие задачи, потом побольше, побольше и тд.
I>>Когда же ты решил множество задач в одном классе, то как правило неизвестных совсем мало и здесь можно и нужно использовать решение сверху вниз.

N>Убогие и практически не определённые критерии выбора подхода к проектированию/разработке — вода, короче говоря.

Наоборот, все предельно ясно и понятно, тк есть осязаемая граница — наличие квалификация+опыт.

Для начала нужно выяснить, что такое снизу вверх и что такое сверху вниз. Внезапно оказывается, что никакого низа и верха нет.
Сверху вниз, это от общего к частному. У тебя есть информацияя
1 что нужно в итоге — общее видение
2 как дробить подзадачи — как получить все детали

Снизу вверх, это частного, к общему
1 у тебя четко ясно, что нужно делать прямо сейчас — простые вещи
2 четко ясно, как строить следующий уровень — комбинировать из простых

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

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

Если не знаешь четко всей глубины проблемы, то не ясно, как тыбудешь дробить непотяное на подзадачи. Но даже если цель тебе сообщить, должен все равно не ясно, как лучше дробить задачи. И здесь будет фейл — бесконечный анализ.

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

В первом случае первый результат появляется позже, но основной — раньше. Во втором- первый результат появляется раньше, но основной — позже.

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

В XP есть такое комбинирование — одни части пишешь сверху вниз, другие — снизу вверх. Простой пример — TDD. Написание теста до написания кода есть акт проектирования, то есть, разработка сверху вниз. Зато написание минимального кода и рефакторинг есть разработка снизу вверх.

	От:	Аноним
	Дата:	09.05.13 08:55
	Оценка:	9 (1) +4 -2

	От:	0x7be
	Дата:	09.05.13 08:58
	Оценка:	42 (6) +3

	От:	alpha21264
	Дата:	09.05.13 09:20
	Оценка:	+4

От:	samius	http://sams-tricks.blogspot.com
Дата:	09.05.13 10:03
Оценка:	+2

	От:	robin_of_the_wood
	Дата:	09.05.13 10:36
	Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	09.05.13 11:20
Оценка:

От:	Философ	http://vk.com/id10256428
Дата:	10.05.13 22:54
Оценка:

От:	Doc	http://andrey.moveax.ru
Дата:	12.05.13 03:38
Оценка:

От:	Aikin	kavaleu.ru
Дата:	13.05.13 06:29
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	28.05.13 10:33
Оценка:

	От:	nullxdth
	Дата:	28.05.13 14:29
	Оценка:	4 (1) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	29.05.13 07:50
Оценка:	16 (1) +1

	От:	Abyx
	Дата:	11.05.13 13:52
	Оценка:

	От:	artelk
	Дата:	11.05.13 20:35
	Оценка:	-1