Re[16]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 20.05.07 14:21
Оценка: -2 :))
Здравствуйте, konsoletyper, Вы писали:

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


K>Обратили-обратили. Даже минус поставили.


K>Всё потому, что ты даже не удосужился понять, что такое паттерн-матчинг.

Чувствую, я понял паттерн матчинг гораздо лучше многих приверженцев Nemerle, раз смог привести уже несколько более или менее соответствующих ему аналогов на C#.

K>Кстати, на неконструктивные замечания я отвечать не намерен.

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

Вот хотя бы в данном сообщении:

Мне сообщили — "не удосужился понять нечто". Явный неконструктив.
А что вообще значит понимание? Если человек только заучил определение, то это еще не понимание. Нужно рассказать другими словами, привести аналоги из иных систем.
Вот я и ответил, не просто, что "понял нечто", что было бы не более конструктивно, чем исходное замечание, хотя и в этом случае я имел бы моральное право привести неконструктив в ответ на конструктив (око за око), однако я также пояснил как убедиться, что действительно "понял нечто".
Re[17]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 20.05.07 14:34
Оценка:
Здравствуйте, Аноним, Вы писали:

А>привести неконструктив в ответ на конструктив

неконструктив в ответ на не конструктив
Re[15]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 20.05.07 14:50
Оценка: -2
Здравствуйте, konsoletyper, Вы писали:

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


K>Отличный пример софистики и демагогии. Нуль конструкрива.

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

По поводу демагогии:
Демагог прежде всего обращается к широким массам.
То есть речь в таком стиле —
Разработчики! Изучайте Nemerle будете производительнее в работе. А я скромный разработчик Nemerle на службе у разработчиков.
или
Участники форума, свободные люди! Вам на форуме нужна свобода выражать свое мнение. А я буду модератором защищающим свободу на форуме, голосуйте за меня.

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

По поводу конструктива:

А. Легко доведу код на C# до 300 строк переформатированием еще и читабельность увеличится.
B. Тогда я доведу код на Nemerle до 150.
A. Не сможешь.
B. Вот пожалуйста.
A. Код утратил читабельность.
B. Возможно, но мне не привели пример кода с улучшенной читабельностью на C#.

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

K>Ты вообще понимаешь слово "читабельный", или просто издеваешься над собеседниками?

Пригодный к чтению. Естественно, что это не универсальная категория — кто-то легко читает код определенного вида на Perl, кто-то с трудом.
Поэтому необходимы примеры и определенные договоренности.
Как связана краткость кода, с читабельностью кода?
Читабелен ли максимально краткий код?
Краток ли максимально читабельный?
Где границы краткости, при которой начинает падать читабельность?
Где границы читабельности, при которой начинает падать краткость?
И т.д. и т.п.
Я при этом не требовал математически строгого определения, мне достаточно было примера.
Re[15]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 20.05.07 15:12
Оценка: -1
Здравствуйте, konsoletyper, Вы писали:

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


K>В Nemerle, обрати внимание, такая практика существует только по отношению к вариантам.

Обращаю внимание, что при паттерн матчинге декларация тоже на одной строке в Nemerle.
Ведь код типа
match 
{
   | Call(expr1, expr2)


это и есть декларация двух, возможно разнотипных, переменных expr1 и expr2 на одной строке

K>Так что судить могу по абстрактному понятию "читабельность".

Ого, уже абстрактное.

K>Потому что варианты унаследованы Nemerle от ML, где такое практикуется почти 30 лет. И это вполне обоснованная практика. Я не сильно разбираюсь в тонкостях computer science.

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

Понимаю, Nemerle — хороший язый, ML — хороший язык (30 лет!) им можно декларации на одной строке размещать.
А вот C# плохой язык ему нельзя.
Re[15]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.07 19:50
Оценка: 3 (1)
Здравствуйте, <Аноним>, Вы писали:

А>Я правильно понимаю, что вы решили не замечать реализацию паттерн матчинга в C# и быстренько свернуть разговор.


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

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

А>Я, конечно, конкретный код реализации матчинга не привел


Конечно. Потому и обсуждать нечего.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 20.05.07 21:09
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Скорее я отныне решил не замечать тебя, потому как имею обширный и печательный опыт общения с упертыми спорщиками, которым познание истины не интересно как класс, а интересен сам процесс спора.

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

VD>Конечно. Потому и обсуждать нечего.

А пример использования? По нему вполне можно восстановить примерный код реализации.
Мне тоже небезынтересно проверить знание C# для спорящих со мной.

Также, хочу заметить, что вместе с сопоставлением по образцу код уложился в те самые 250 строк кода на C#, о котором количестве шла речь в исходной статье.
Re[16]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.07 22:53
Оценка: +1
Здравствуйте, <Аноним>, Вы писали:

K>>Отличный пример софистики и демагогии. Нуль конструкрива.

А>Чувствую, не знаете значения ни демагогии, ни конструктива.
А>Если под софистикий понимается умение мудро вести спор, то с благодарностью принимаю в свой адрес.

Вот это она и есть софистика или иными словами демогогия.
Прекрасно понимаю, что ты и сам это знешь. Но тем кто не так подкован в данном вопросе советую сходить и почитать определение терминов Софизм и Софисты. Конкретно:

Вырождение софистики началось уже в IV в. до н. э. (Евтидем и др.). Софисты постепенно превращались в фокусников, берущихся с помощью софизмов и др. способов (подробно описанных Аристотелем в «Софистических опровержениях») защищать или опровергать любые мнения.


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

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

А>По поводу демагогии:

А>Демагог прежде всего обращается к широким массам.

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

А>Конечно, любое выступление на форуме, можно посчитать демагогическим ибо в потенциале, его могут прочитать очень много людей.

А>Но нужно ли считать его демагогическим если идет обращение к одному человеку?

Не стоти рассчитывать, что такой наивный подлог прокатит в данном месте. Ты не на тех нарвался. Толи и демагиги не редкость на больших форумах. И лечим мы их очнь просто — баним к чертям. А тех кто еще и ник не удосуживается завести банем по IP-пишникам.

А>По поводу конструктива:


А>А. Легко доведу код на C# до 300 строк переформатированием еще и читабельность увеличится.

А>B. Тогда я доведу код на Nemerle до 150.
А>A. Не сможешь.
А>B. Вот пожалуйста.
А>A. Код утратил читабельность.
А>B. Возможно, но мне не привели пример кода с улучшенной читабельностью на C#.

А то ты сам не знаешь что такое читабельный код. Код вылетающий за пределы экрана (превышающий 100 символов в ширину) и попытки впихнуть в одну строку много определений ухудшают читабельность.

В том что ты можешь разести код содержащий 150 токенов на 150 строк ни у кого сомнений не вызвает, в прочем точно так же как ни у кого не вызвает сомнений то что ты жулик, так как сравнивашь код хорошо отформатированный и отлично читающийся с форменной кашей.
Если пойти по твоему пути, то можно провести обратный эксперемент и превратить в такую же кашу и код на Немерле. Например, так:
using System;
using System.Console;
using Nemerle.Utility;
using Expr;

public variant Expr
{
 | Literal { value : double; } | Call { name : string; parms : list[Expr]; } | Plus { expr1 : Expr; expr2 : Expr; } 
 | Minus { expr1 : Expr; expr2 : Expr; } | Mul { expr1 : Expr; expr2 : Expr; }| Div { expr1 : Expr; expr2 : Expr;
}
 
 public override ToString() : string
 {
   match (this) { | Literal(value) => value.ToString() | Call(name, parms) => $"$name(..$parms)" | Plus(e1, e2) with op = "+" 
   | Minus(e1, e2) with op = "-" | Mul (e1, e2) with op = "*" | Div (e1, e2) with op = "/" => $"$e1 $op $e2" }
 }

 public Eval() : double
 {
   match (this) { | Literal(value) => value | Plus (e1, e2) => e1.Eval() + e2.Eval() | Minus(e1, e2) => e1.Eval() - e2.Eval() 
   | Mul (e1, e2) => e1.Eval() * e2.Eval() | Div (e1, e2) => e1.Eval() / e2.Eval() | Call("max", [arg1, arg2]) => Math.Max(arg1.Eval(), arg2.Eval())
   | Call("min", [arg1, arg2]) => Math.Min(arg1.Eval(), arg2.Eval()) | Call("foo", [arg1]) => arg1.Eval() | Call(_, _) => throw InvalidOperationException(this.ToString());
   }
 }

 public Convert(transform : Expr -> Expr) : Expr // добавили поддержку трансформации выражений
 {
   transform(match (this) { | Literal => this | Plus (e1, e2) => Plus (e1.Convert(transform), e2.Convert(transform))
   | Minus(e1, e2) => Minus(e1.Convert(transform), e2.Convert(transform)) | Mul (e1, e2) => Mul (e1.Convert(transform), e2.Convert(transform))
   | Div (e1, e2) => Div (e1.Convert(transform), e2.Convert(transform)) | Call(name, parms) => Call(name, parms.Map(_.Convert(transform)))
   })
 }
}

module Program
{
 Main() : void
 {
   def expr = Mul(Mul(Plus(Literal(1.23), Call("max", [Literal(1), Literal(2)])), Literal(1)), Literal(1));
   WriteLine($"До трансформации\nExpression '$expr' = $(expr.Eval())");

   def expr = expr.Convert(_ => { | Mul(x, Literal(1.0)) => x | Call("max", [Literal(x), Literal(y)]) => Literal(Math.Max(x, y))
   | Call("mix", [Literal(x), Literal(y)]) => Literal(Math.Min(x, y)) | e => e });
   WriteLine($"После трансформации\nExpression '$expr' = $(expr.Eval())");
 }
}

Итого 46 строк. Выглядит конечно хреново, но не хуже чем твои:
    public override string ToString() { return name + "(" + String.Join(", ", Array.ConvertAll<Expr, string>(arguments, System.Convert.ToString)) + ")"; }


K>>Ты вообще понимаешь слово "читабельный", или просто издеваешься над собеседниками?

А>Пригодный к чтению.

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

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

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

А>Как связана краткость кода, с читабельностью кода?


Прямой связи тут нет. Но если не страдает выразительность и два варианта код решают одну и ту же задачу, то более кратикий будет по совместительству и более читабельным.
Но точно известно, что если код содержит несколько определений переменных на додной строке, если он содержит черезчур длинные строки (а 150 символов — это совсем черезчур), то код назвать читабельным нельзя. Так же ухудщают читабельность и содержащиется по всему код незначимые куски вроде "public override Expr Convert(Converter converter) { return " заграмождющие код. Они просто дань традициям ОО-языков.

А>Читабелен ли максимально краткий код?

А>Краток ли максимально читабельный?

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

Короче, по-русски читабельность называется удобочитаемостью. К сожалению определиние общее, расчитанное на разговорный зяык. Программистское описание есть на английском — readability. Обрати там внимание на послединй пункт (Naming conventions). Вот здесь ты можешь почитать соглашения по кодированию на C# нашей командны.

А>Где границы краткости, при которой начинает падать читабельность?


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

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

А>Где границы читабельности, при которой начинает падать краткость?


Это вообще перл. Читабельность падает когда код превращают в кашу. Не важно увеличивается он при этом в общеме или уменьшается.

А>И т.д. и т.п.

А>Я при этом не требовал математически строгого определения, мне достаточно было примера.

ОК. Записывать вот такие функции:
    public override Expr Convert(Converter converter) { return converter(new Plus(first.Convert(converter), second.Convert(converter))); }

в одну строку — это путь к нчитаемости. Такуая функция должна быть записана хотя бы так:
        public override Expr Convert(Converter converter)
        {
            return converter(new Plus(first.Convert(converter), second.Convert(converter)));
        }

При этом ее следует отбить от других фукнций хотя бы одной пустой строкой, чтобы ее можно было легко разглядеть в коде.
Далее вот это:
    static Expr RemoveMaxOfLiterals(Expr expr)
    {
        Max max = expr as Max; if (max != null) 
        {            
            Lit first = max.First as Lit, second = max.Second as Lit; if (first != null && second != null)
            {
                return new Lit(Math.Max(first.Eval(), second.Eval()));
            }
        }
        return expr;
    }

тоже плохочитаемая запись. Писать новый statment на стоке где начинаетс определение переменной — это верный путь к запутыванию кода. Должно быть так:
    static Expr RemoveMaxOfLiterals(Expr expr)
    {
        Max max = expr as Max;
        if (max != null) 
        {            
            Lit first = max.First as Lit;
            Lit second = max.Second as Lit;
            if (first != null && second != null)
            {
                return new Lit(Math.Max(first.Eval(), second.Eval()));
            }
        }
        return expr;
    }

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

Кстати, о твоих словах, что мол ты используешь полные имена, а кто-то там двух-буквенные согращения. Что-то в последних вариантах у тебя все идентификаторы резо подусохли. Даже Literal укоротился до LIt, что уже на грани читаемости, в то время как все мои были очевидны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.07 22:53
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Да, я правильно понял, что мне тоже можно в C# размещать декларации для нескольких разнотипных переменных на одной строке или это прерогатива кода на Nemerle?


А где ты увидил несколько переменных на одной строке? Речь идет о связывамых перменных в паттернах? Или о полях?

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

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

Кстати, учти, что эти поля еще к тому же доступны только для чтения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.07 22:53
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>В Nemerle, обрати внимание, такая практика существует только по отношению к вариантам. Потому что варианты унаследованы Nemerle от ML, где такое практикуется почти 30 лет. И это вполне обоснованная практика. Я не сильно разбираюсь в тонкостях computer science. Так что судить могу по абстрактному понятию "читабельность". Так вот, в вариантах размещение нескольких "деклараций" на одной строке читабельность повышает. В классах же — понижает. Думаю, всё это связано с тем, что классы поддерживают ООП-парадигму, так что должны походить на чёрный ящик, потому для них требуется пространное описание структуры. Варианты же — вещь ортогональная ООП, они, наоборот, максимально открыты, чтобы по ним было проще сопостовлять по образцу.


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

Естественно, что если определения не лезут в одру строку, то нужно их переносить и как следует форматировать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.07 22:53
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Обращаю внимание, что при паттерн матчинге декларация тоже на одной строке в Nemerle.

А>Ведь код типа
А>
А>match 
А>{
А>   | Call(expr1, expr2)
А>


А>это и есть декларация двух, возможно разнотипных, переменных expr1 и expr2 на одной строке


Ага. В этом и есть суть паттернов. Понимаш ли тут проблема с мозгами, а не с форматированием. Паттерн не надо рассматривать как что-то содержащее переменные. Паттерн — это образец со знаками/переменными заменителями. Их нельзя именить, им нельзя задать тип. Они определяются паттерном иявляются его чатьсю. Это как регулярные выражения с группами:
Начало образца ([A-za-z][A-za-z0-9]+) конец образца

Мы не объявляем переменную типа строка. Мы создаем образец часть которого является переменной величиной (в данном случае "([A-za-z][A-za-z0-9]+)"). Глупо заставлять людей записывать две группы в одном регэкспе на разных строках, да еще и аргументировать это тем, что в C# это плохо. В C# нет ни регекспов, ни паттерн-матчинга и добавить их студа средствами языка нельзя. Так что применять правила порматирования переменных C# к сущностям из другого языка ошибочно. Это называется применение выводов по анлогии. Грубейшая логическая ошибка.

А>Понимаю, Nemerle — хороший язый, ML — хороший язык (30 лет!) им можно декларации на одной строке размещать.

А>А вот C# плохой язык ему нельзя.

Плохой не плохой, а паттерн-матчинга в нем нерт и вывода типа пока тоже. Это однозначные минусы. Вывод типов (плохоньких, но хоть что-то) появится в 3.0, а вот паттерн-матчинг мы будем ждать очень длого. Рано или поздно он все равно появится во всех мэйнстрим-языках, но хотелось бы чтобы раньше. В прочем, Nemerle ка язык уже превосходит тот же C# практически по всем показателям. Так что можно ничего не ждать. Яык уже есть. Интеграция к Студии тоже.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.07 22:53
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Так же легко повернуть, что и код на Nemerle не делает, того что от него требовалось, и другого полезного ничего не делает.


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

А>Что несуразного в Min с одним параметром?


То что это функция вычисляющая минимальное значение. Глупо вычислять минимальное значение когда вариантов ровно один.

А> Не больше чем в умножении на 1.


Умножение на 1 может получиться в следствии применения другой оптимизации. Если ты заметил, то их там можно добавлять хоть тысячу.

А> К тому же добавить контроль количества параметров очень легко, что я и показал в следующем коде.


Речь шало о исходном варинте.

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


Не выкладывал. Но этого никто не просил.

VD>>Это проблемы твоей реализации и выбронного тбой подхода. Сделай по другому. Главное, чтобы по фунциональности было тоже самое.

А>Серьезно не понимаю, зачем добиваться той же функциональности с точностью до миллиметра.

Сравнивать можно только программы решающие одни и те же задачи. А то я тебе напишу программу "x()" и отмажусь тем, что "не понимаю, зачем добиваться той же функциональности".

А> Разговор с моей стороны идет, что по объему кода никакого пятикратного преимущества у Nemerle нет,


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

А> а есть максимум двухкратное, как по количеству строк, так и по объему файла за вычетом ведущих проблелов.


Поправлю. Минимум двукратное. То есть 2+ получается после ужатия C#-ного кода до безоразия (объявления и выражения на одной строке, 150-символьные строки). Любому кто в теме очевидно, что увеличение объема кода связано с тем, что C#-ный вариант содержит море не важной для программы информации. В каждом классе приходится писать море баластного кода. К тому же какой-нибудь override можно пропустить и компилятор уже не подскажет, что ты забыл реализовать то или ное дейтсвие. А классов то уеже не мало и контролировать их в разрезе операций очень сложно.

При нормальном же форматировании разница составляет 3х. А при применении, напрашивющегося здесь, паттерна проектирования Посетитель код становится больше в 5 раз (при стандартном для C# форматировании). Собственно это и было продемонстрировано в статье. Граматные программисты занкомые с упомянутым паттерном и с разработкой парсеров, думаю, согласятся со мной, что его использование тут очень к месту. И что увелчение объема кода все же не так критично по сравнению с тем, что операции сложены вместе и их не надо искть по туче классов.

А> А уж если сравнивать по количеству нажатий на кнопки в среде оснащенной Intellisense'ом.


И что будет? Будет такое же 2-5 кратное упрощение работы. Более того, ad-hoc-полиморфизм в паттерн матчинге позволяет еще больше согратить запись.

VD>>У тебя код не делал то что нужно.

А>Это на Nemerle не делал то что нужно

Ты вменяемый?

VD>>Заметь, люди которые знают оба зыка откровенно посмеялись над твоим кодом.

А>Пускай, я пока не смеюсь.

А тебе над чем смеяться то? Они смеются над тем как ты краткий и очевидны код (который даже ты вроде как понял) ты патшся сравнивать со своей кашей.

VD>>К тому же если все так хорошо, что же ты переписал код как только увидел мой вариант?

А>А откуда такая уверенность.

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

А> Я переписал, код как только получил доступ к форуму и смог посмотреть на исходные условия.


В условиях задачи не сказно как надо делать. Там сказано, что нужно делать.

А>Да и что в твоем примере такого существенного?


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

VD>>Да уж это неверотное приемущество, вот только этого не требовалось по условию задачи и не ясно что оно дает.

А>Инкапсуляция всегда небесполезна.

В конкретном случае бесполезно все, что не приносит пользы для этого случая. Все данные AST-классов должны быть доступны публично. Их тлько желательно сделать неизменяемыми. Это и делается автоматически в вариантах Немерле и вызывает нагромождения кода на C#. В общем, это банально более удобное решения конкретной задачи.

VD>>То-то я гляжу, все так легко, что дня не хвает на реализацию.

А>Пишу, в основном, после работы. Кстати, стараюсь никогда не оправдыватся, но, ха-ха, вчера у меня прорвало счетчик воды в квартире и половину ее залило, к счастью без особых последствий, но пять 15 литровых ведер воды, я с пола собрал.

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

А>Я подумал, подумал и написал сопоставление с образцом на C#.




VD>>Кстати, использовать Eval() для доступа к значениям литералов плохой подход. В будущем поведение может измениться и этот код превратится в ошибочный, а компилятор снова не сможет ничего подсказать.

А>С этим не согласен.

С чем? Это как раз тот случай когда ты губо попираешь принципы инкапсуляции. Eval() должен вычислять, а не возвращать значение. Испоьзование частнрых знаний, о том, что для некоторого типа Eval() реализован так, что может заменить эксессор свойства как раз и является нарушением инкапсуляции, так как ты опирашся на знания о реализации абстрактного метода.

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

Согласен, но это дело не меняет и ничего не оправдывает. Нарушение инкапсуляции (грубое) на лицо.

VD>>Да? А как понимать, то что ты полностью переписал свой код и отказался от так защищаемого тбой RemoveOneParameterMin()?

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

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

VD>>Ты уже начиташь сам себе противоречить и своими же действиями опровергать свои же слова .

А>Отнюдь, я просто показал широту своих взглядов и легкость к изменениям.


Где ты изменил взгляд? Умора. Сам написать ничего приличного не смог, а потом оправдался тупое сдирание по контексту тем широтой вглядов и легкостью их изменения.

VD>>Отнюдь. Как раз посетители отлично выявляют необработанные классы иерархии, если конечно, правильно их готовить.

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

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

VD>>Серьезно? Ну, я почти на верняка пишу на C# дольше тебя (начал еще в 2000-ном когда первые превью появились), но вот почему-то никак не могу привыкнуть к тому, что вместо:

А>Я тоже начал в 2000 с бета версий, правда, тогда в основном упирал на VB.NET, ну да в контексте .NET это не так важно.
А>И оценка на brainbench у нас примерно одинаковая по C#.

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

Вот это о чем было:
VD>>Расскажи, как ты к такому привыкаешь?

А кто-то тупо обошел этот вопрос и начал развивать пенесометрийную тему. Демагогия однако.

А>>>Вот код:...


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

А>Да ничего там не пришлось подглядывать.

Ну, это все видил.

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


В прочем, это заявление будет правдой.

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


А, да, да. Это очень правильно, использовать не осмысленные имена, "полные". Кстати, не сильно смущают функции Min и Max? Может быть сделать обертки MinimalValue и MaximumValue?
А вот этот код
Автор:
Дата: 17.05.07
не твой ли? Смотри как от полных имен не осталось и следа! Даже Literal был в совершенно не очевидный Lit переименован. Это тоже, так сказать, проявление широты взглядов?

VD>>

Читаемость кода

VD>>Вряд ли ты станешь спорить, что теперь наш код иделогически близок. Но вот что лучше читается? На мой взгляд действия собранные вместе и без лишних заголовков функций читается намного лучше. Его и поддерживать проще.
А>C# неплохо читается,

А>можно по отдельности классы разбирать.


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

VD>>Развитие кода

VD>>Если нам понадобиться добавить новую операцию обработки кода мне будет достаточно создать новый метод, а тебе придется лазить по всем классам и добавлять в каждый из них по фукнции.
А>Во все не по всем. За счет наследования метод надо будет добавить буквально в нескольких классах.

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

Ведь в любом случае одна строка:
  | Minus   { expr1 : Expr;   expr2 : Expr; }

соотвествует как минимум:
class Minus: Oper
{
    public Minus(Expr first, Expr second): base(first, second) {}
    public override string ToString() { return first.ToString() + "-" + second.ToString(); }
    public override double Eval() { return first.Eval() - second.Eval(); }
    public override Expr Convert(Converter converter) { return converter(new Minus(first.Convert(converter), second.Convert(converter))); }
}

7 строкам на шарпе. А еще нужно учеть пустые строки которыми классы отбивают. да и код отбить по человечески:
class Minus: Oper
{
  public Minus(Expr first, Expr second): base(first, second) {}
  public override string ToString() { return first.ToString() + "-" + second.ToString(); }
  public override double Eval() { return first.Eval() - second.Eval(); }
    
  public override Expr Convert(Converter converter)
  {
    return converter(new Minus(first.Convert(converter), second.Convert(converter)));
  }
}

а то и:
class Minus: Oper
{
  public Minus(Expr first, Expr second): base(first, second) {}
    
  public override string ToString()
  {
    return first.ToString() + "-" + second.ToString();
  }
    
  public override double Eval() { return first.Eval() - second.Eval(); }
    
  public override Expr Convert(Converter converter)
  {
    return converter(
          new Minus(first.Convert(converter), second.Convert(converter)));
  }
}


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

А>Так и мне подскажет. Набираешь override (даже несколько букв) вот и готово тело метода.
Согласен. Подскажет пока ты за override-ами внимательно следишь. Тут паритет. Жаль в остальных местах его нет.

А>А вот код сопоставления по образцу:

А>
А>  static Expr RemoveMulToOne(Expr expr)
А>  {
А>    Mul mul = null; Expr first = null; Lit lit = null;
А>    if (new Pattern<Mul, Expr, Lit>().Match<Expr>(expr, ref mul, ref first, ref lit))
А>    {
А>      if (lit.Eval() == 1) return first;
А>    }
А>    return expr;
А>  }

А>  static Expr RemoveMaxOfLiterals(Expr expr)
А>  {
А>    Max max = null; Lit lit1 = null; Lit lit2 = null;
А>    if (new Pattern<Max, Lit, Lit>().Match<Expr>(expr, ref max, ref lit1, ref lit2))
А>    {
А>      return new Lit(Math.Max(lit1.Eval(), lit2.Eval()));
А>    }
А>    return expr;
А>  }
А>


Это извини меня чушь какая-то, а не сопоставление с образцом. Ты бы хоть реализацию этого чуда привел бы, а то даже разговаривать не о чем. Ну, и надо заметить, что "это чудо" один фиг не сопоставимо с образцами паттерн-матчинга, ни по объему, ни по удобочитаемости. Это очередное награмождение кода попирающее принципы форматирования в C#.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.05.07 01:31
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>А пример использования?


- Иссаак! Зачем ты покупашь яйца по рублю за десяток, варишь их и продаешь по 10 копеек за штуку?
— Как же? А наваррръ?!


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

Пример использования один фиг награмождение кода по сравнению с исходным обрацом.

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

А> По нему вполне можно восстановить примерный код реализации.


А зачем мне знаиматься реверс-инжинирингом какого-то бредового куса кода? Темболее, что он у тебя есть.

А>Мне тоже небезынтересно проверить знание C# для спорящих со мной.


Это не интересно мне. Ведь не я пришел сюда спорить кажется? И не я рассказываю, что на коленке паттен-матчинг сварганил?

А>Также, хочу заметить, что вместе с сопоставлением по образцу код уложился в те самые 250 строк кода на C#, о котором количестве шла речь в исходной статье.


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

Понимаш ли даже 30% разницы в коде — это весомый результат. Это значит, что программа может быть написана на 30% быстрее, или что она может стать на 30% фуниональнее. А 2 раза — это уже огромный результат. Так что если бы даже тебе удалось хоть кого-то кроеме себя убедить в том, что твой код содержащий строки по 150 символов и нагромождение конструкций на одной строке — это нормально оформленный код, все равно он минимум в 2 раза хуже. И с каждым образцом он становится худе на 5-10 строк. А так как реальная цифра выигрыша составляет 3-5 раз, то он уже получается каким-то угражающим. Писать подобные задачи на C# в то время как есть возможность использовать более мощьный язык просто является приступлением.

Это все равно как подойти в качалку и заявить, что скажем жим 100 килограм с груди мало чем отличается от жима 50. Тебе сразу заметят, что 50 это результат для новичка. А вот до 100 уже не все добираются. Ну, а 150 это уже гигантская разница...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.05.07 01:31
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Блин, ребят, что же вы не написали, а! Надо же было орать на весь форум!!! А я мучаюсь без интеграции....


Видишь, поарали и теперь многие дуются. Теперь вот тихо потребляем плоды прогресса.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 21.05.07 16:11
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Вот это она и есть софистика или иными словами демогогия.

А почему определения разные в википедии для софиситики и демагогии?

VD>Прекрасно понимаю, что ты и сам это знешь. Но тем кто не так подкован в данном вопросе советую сходить и почитать определение терминов Софизм и Софисты. Конкретно:

Гм, а мне казалось, софизм, софисты и софистика — разные слова, пусть и однокоренные.
Что интересно, слово софистика есть в википедии, однако две приведенные ссылки, ссылаются на другие слова.

Софи́стика (греч. σοφιστική — умение хитро вести прения)


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

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

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


Демаго́г (др.-греч. δημαγωγός, «предводитель народа»)

Как ни крути, предводитель народа, без самого народа — это вряд ли демагог. Даже если понятие народа трактовать широко.

VD>А то ты сам не знаешь что такое читабельный код. Код вылетающий за пределы экрана (превышающий 100 символов в ширину) и попытки впихнуть в одну строку много определений ухудшают читабельность.

Осторожно напоминаю, что речь шла о том, что я убил читабельность в коде на Nemerle.

VD>Если пойти по твоему пути, то можно провести обратный эксперемент и превратить в такую же кашу и код на Немерле. Например, так:

Осторожно напоминаю, что я сделал с кодом на Nemerle нечто обратное приведенному коду. В ответ мне заявили, что я убил читабельность.

VD>Еще одна лож. Пригодным к чтению можно счесть почти любой текст. А "читабельный" означает "который удобно и легко читать".

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

VD>Конечно и это категория не универсальная, но уж строки в 150 символов точно нельзя счесть читабельными.

Осторожно напоминаю, что речь шла о "моем" коде на Nemerle где точно не было никаких 150 символов в строке.

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

Напомните, сравнивал ли я своих оппонентов с демонстрирующими упертость животными? Или использовал, что-то еще более грязное?

VD>Но точно известно, что если код содержит несколько определений переменных на додной строке, если он содержит черезчур длинные строки (а 150 символов — это совсем черезчур), то код назвать читабельным нельзя. Так же ухудщают читабельность и содержащиется по всему код незначимые куски вроде "public override Expr Convert(Converter converter) { return " заграмождющие код. Они просто дань традициям ОО-языков.

Осторожно напоминаю, про что уже напоминал. (Пример рекурсии, если что, или вызова подпрограммы)

VD>Изумительные примеры демагогии. Повторюсь — прямой свзи между краткостью и читбельностью нет. Краткость это отельное достоинство и оно не достикается запихиванием в одну стоку 150 симовол.

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

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

Краткий код, это краткие конструкции, это я понял

VD>Это вообще перл. Читабельность падает когда код превращают в кашу. Не важно увеличивается он при этом в общеме или уменьшается.

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

VD>в одну строку — это путь к нчитаемости. Такуая функция должна быть записана хотя бы так:

А вот так?
public override Expr Convert(Converter c) { return c(new Plus(first.Convert(c), second.Convert(c))); }

Или так?
public override Expr Convert(Converter converter) { 
    return c(new Plus(first.Convert(converter), second.Convert(converter))); 
}

А если посчитать не по строкам, а по объему кода без ведущих пробелов?
А если учесть, что при наборе в Visual Studio не надо набирать "public override Expr Convert(Converter converter) {", а только набрать over и выбрать вариант для переопределения?

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

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

VD>Далее вот это:

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

VD>В прочем, зачем нужны ничего не делающие фигурные скбоки у тела if-а тоже не ясно. Лучше бы на них сэкомномил.

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

VD>Кстати, о твоих словах, что мол ты используешь полные имена, а кто-то там двух-буквенные согращения. Что-то в последних вариантах у тебя все идентификаторы резо подусохли. Даже Literal укоротился до LIt, что уже на грани читаемости, в то время как все мои были очевидны.

Как ни крути Lit трехбуквенное. Уж молчу про Operation и AtLeastTwoArgumentsCall
Re[17]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 21.05.07 16:24
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Ага. В этом и есть суть паттернов. Понимаш ли тут проблема с мозгами, а не с форматированием. Паттерн не надо рассматривать как что-то содержащее переменные. Паттерн — это образец со знаками/переменными заменителями. Их нельзя именить, им нельзя задать тип. Они определяются паттерном иявляются его чатьсю. Это как регулярные выражения с группами:

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

VD>
VD>Начало образца ([A-za-z][A-za-z0-9]+) конец образца
VD>

VD>Мы не объявляем переменную типа строка. Мы создаем образец часть которого является переменной величиной (в данном случае "([A-za-z][A-za-z0-9]+)"). Глупо заставлять людей записывать две группы в одном регэкспе на разных строках, да еще и аргументировать это тем, что в C# это плохо.
Образец — да, не совсем строка (хотя и задается в строке), а результат удачного сопоставления — строка например А0.

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

Кажется, regexp есть. Кажется они везде есть. Для всех случаев может и не сделать (хотя сильно над этим я еще не думал особенно в контексте C# 3.0), а для определенной иерархии классов вполне себе.
Re[16]: Функциональное программирование в Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 21.05.07 16:42
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Конечно, любое выступление на форуме, можно посчитать демагогическим ибо в потенциале, его могут прочитать очень много людей.

А>Но нужно ли считать его демагогическим если идет обращение к одному человеку?

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

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


P.S. Кстати, вы случайно не преднамеренно путаете этимологию слова (его происхождение) с толкованием (значением) слова?
(это я по поводу этого
Автор:
Дата: 21.05.07
вашего сообщения, я так понимаю, это тоже вы)
Re[11]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 21.05.07 17:14
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Он делает, то что было описано в условиях задачи. Это легко проверить запустив его.

Так и мой делает, что было в моих условиях задачи.

А>>Что несуразного в Min с одним параметром?

VD>То что это функция вычисляющая минимальное значение. Глупо вычислять минимальное значение когда вариантов ровно один.
А>> Не больше чем в умножении на 1.
VD>Умножение на 1 может получиться в следствии применения другой оптимизации. Если ты заметил, то их там можно добавлять хоть тысячу.
И такой Min может получиться в следствии применения другой оптимизации, которая уберет остальные аргументы.
Напоминаю, у меня был Min со смногим количеством параметров и я его выкладывал.

VD>Не выкладывал. Но этого никто не просил.

Я тут давно прошу признать, что сравнение Nemerle и C# по объему кода было нечестным в статье, хоть бы кто послушал.

VD>Сравнивать можно только программы решающие одни и те же задачи. А то я тебе напишу программу "x()" и отмажусь тем, что "не понимаю, зачем добиваться той же функциональности".

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

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

Ага, если он abstract в базовом, еще как подскажет. Даже скомпилировать не даст.

VD>и их не надо искть по туче классов.

Считаю, что код надо хранить поближе к данным, которые он обрабатывает.

VD>Граматные программисты

Стараюсь не цеплятся к правописанию, ибо сам грешен, но тут не могу не отметить. Считайте троллингом.

VD>И что будет? Будет такое же 2-5 кратное упрощение работы.

Гм, ну как "protected override Expr Convert(Converter converter)" сократится до пары нажатий, я вижу, а где intellisense также сократит код на Nemerle не вижу.
Что тут среда подсказать может? "| Plus (e1, e2) => Plus (e1.Convert(transform), e2.Convert(transform))" Ну параметры, так она и для C# подскажет.

VD>Ты вменяемый?

Надеюсь.

VD>А тебе над чем смеяться то? Они смеются над тем как ты краткий и очевидны код (который даже ты вроде как понял) ты патшся сравнивать со своей кашей.

Хорошо смеется тот кто смеется последним. Народная мудрость.

VD>В условиях задачи не сказно как надо делать. Там сказано, что нужно делать.

Там было сказано, что код изменений будет "внешним".

VD>Он верно работал с самого начала.

А поправка Wolfhaund? Код, работал не правильно.

VD>В конкретном случае бесполезно все, что не приносит пользы для этого случая. Все данные AST-классов должны быть доступны публично. Их тлько желательно сделать неизменяемыми. Это и делается автоматически в вариантах Немерле и вызывает нагромождения кода на C#. В общем, это банально более удобное решения конкретной задачи.


VD>Кстати, не всегда получается.

Рад, что заметил мою шутку, там даже ха-ха было вставлено

VD>С чем? Это как раз тот случай когда ты губо попираешь принципы инкапсуляции. Eval() должен вычислять, а не возвращать значение. Испоьзование частнрых знаний, о том, что для некоторого типа Eval() реализован так, что может заменить эксессор свойства как раз и является нарушением инкапсуляции, так как ты опирашся на знания о реализации абстрактного метода.

Продолжаю оставаться несогласным. <<< Это пример неконструктива.

VD>А кто с тобой спорил по поводу RemoveOneParameterMin? Консолетайпер выразил тебе свое мнение, что это кривое решение, но никто тебя не заставлял его убирать.

Кажется, я принял это решение не после слов konsoletyper. А после прочтения условий, впрочем не важно.

VD>Где ты изменил взгляд?

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

VD>Пример есть в статье. Полный. Если забыть в посетителе реализовать дин из методов, то сразу получишь от компилятора сообщение.

А я не про методы, я про классы. В иерархию добавляется новый класс, в нем реализуется метод для посетителя. Но в самом посетителе, например для представления в виде строки, не добавляется проверка на новый класс. Ошибка вылетает только во время выполнения. Как, кстати, и в Nemerle в некоторых случаях.

VD>А кто-то тупо обошел этот вопрос и начал развивать пенесометрийную тему. Демагогия однако.

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

VD>А вот этот код
Автор:
Дата: 17.05.07
не твой ли? Смотри как от полных имен не осталось и следа! Даже Literal был в совершенно не очевидный Lit переименован. Это тоже, так сказать, проявление широты взглядов?

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

VD> Ой, умаор! Да ничего другого и не приходится. Еще приходится скролировтаь код чтобы разглядеть, что там у тебя за горизонтом тварится. И при это всевремы ломать глаза, так как выцепить значемый код из 150-символьных строк ой как не просто. Уж лучше бы фукнция 3 строки занимала.

Гм, не я понимаю, встречаются длинные строки, но чтобы все были 150 символьные? Против трех строк не против, но как уже говорил предлагаю тогда считать размер кода без ведущих пробелов или количество нажатий в Visual Studio (это впрочем тяжело подсчитать)

VD>Наследование конечно здорово, но что-то оно тебе так и не помогло до конца. Да несколько строк выиграл, но в итоге все равно код не читаемый и значительно больший.

Ну так ООП для больших проектов и задумывался.

VD>Ведь в любом случае одна строка:

VD>
VD>  | Minus   { expr1 : Expr;   expr2 : Expr; }
VD>

VD>соотвествует как минимум:
VD>
VD>class Minus: Oper
VD>{
VD>    public Minus(Expr first, Expr second): base(first, second) {}
VD>    public override string ToString() { return first.ToString() + "-" + second.ToString(); }
VD>    public override double Eval() { return first.Eval() - second.Eval(); }
VD>    public override Expr Convert(Converter converter) { return converter(new Minus(first.Convert(converter), second.Convert(converter))); }
VD>}
VD>

VD>7 строкам на шарпе. А еще нужно учеть пустые строки которыми классы отбивают. да и код отбить по человечески:
Гм, гм.
А у меня есть мнение, что не одна строка на Nemerle, а четыре, только они размазаны по коду. Вот глаза-то придется поломать
| Minus { expr1 : Expr;   expr2 : Expr; }
| Minus(e1, e2) with op = "-" 
| Minus(e1, e2) => e1.Eval() - e2.Eval()
| Minus(e1, e2) => transform(Minus(e1.Convert(transform), e2.Convert(transform)))

2 * 4 > 7

VD> Это извини меня чушь какая-то, а не сопоставление с образцом. Ты бы хоть реализацию этого чуда привел бы, а то даже разговаривать не о чем. Ну, и надо заметить, что "это чудо" один фиг не сопоставимо с образцами паттерн-матчинга, ни по объему, ни по удобочитаемости. Это очередное награмождение кода попирающее принципы форматирования в C#.

Попирает, только в декларации на одной строке. Впрочем, кажется, мне разрешили это делать.
Также сопоставление претендует на универсальность и немного громоздко. А можно упростить до:
Max max = null; Lit lit1 = null; Lit lit2 = null;
if (expr.Match<Max, Lit, Lit>(ref max, ref lit1, ref lit2))
    return new Lit(Math.Max(lit1.Eval(), lit2.Eval()))

В чем сильные отличия от:
| Call("max", [Lit(lit1), Lit(lit2)]) 
    => Literal(Math.Max(lit1.Eval(), lit2.Eval()))

?
Три строки вместо двух, да и то за счет декларации.

К тому же возможно в C# 3.0 будет некоторая поддержка кортежей, что позволит и этот пример упростить далее.
Re[18]: Функциональное программирование в Nemerle
От: Аноним  
Дата: 21.05.07 17:31
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Пример чего? У тебя что есть универсально решение которое обладает фунционльностью пттерн-тачинга? Ты меня извини, но этот алгоритм тебе просто не написать

Я добрее к людям. Если, у программиста больше 4 по C# на brainbench, то он может написать этот алгоритм. В потенциале.

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

Зачем? Она помогает мне ощущать интеллектуальное превосходство. In my dreams, чтобы не злить волков.

VD>Понимаш ли даже 30% разницы в коде — это весомый результат.

По мне так даже отрицательный, если на одной чаше microsoft, а на другой пять человек.
Как видишь, заставить меня программировать на Nemerle не так сложно.
Достаточно чтобы ms купила его и вложила бы большие средства в его развитие.

VD>Это значит, что программа может быть написана на 30% быстрее, или что она может стать на 30% фуниональнее.

Это значит, что возможность получить справку по сложным моментам, в тысячи раз меньше.

VD>Это все равно как подойти в качалку и заявить, что скажем жим 100 килограм с груди мало чем отличается от жима 50. Тебе сразу заметят, что 50 это результат для новичка. А вот до 100 уже не все добираются. Ну, а 150 это уже гигантская разница...

В качалку чаще ходят, не для того чтобы один раз по 100, а для того чтобы два раза по 50. Повторяют, короче, упражения.
Где в качалке, intellisence, спрашивать опасаюсь.
Re[12]: Функциональное программирование в Nemerle
От: WolfHound  
Дата: 21.05.07 19:16
Оценка: +3
Здравствуйте, <Аноним>, Вы писали:

VD>>и их не надо искть по туче классов.

А>Считаю, что код надо хранить поближе к данным, которые он обрабатывает.
Это догма. Догмы до добра не доводят.
Иногда это так. Иногда иначе.
В случае с АСТ однозначно иначе.

VD>>И что будет? Будет такое же 2-5 кратное упрощение работы.

А>Гм, ну как "protected override Expr Convert(Converter converter)" сократится до пары нажатий, я вижу, а где intellisense также сократит код на Nemerle не вижу.
А>Что тут среда подсказать может? "| Plus (e1, e2) => Plus (e1.Convert(transform), e2.Convert(transform))" Ну параметры, так она и для C# подскажет.
Ну про то что тебе еще надо написать
return converter(new Plus(first.Convert(converter), second.Convert(converter)));
ты как обыно забыл...
Вот только тут собрались флеймеры со стажем и так просто нас не провести...

А>Хорошо смеется тот кто смеется последним. Народная мудрость.

Нет. Хорошо смеется тот кто смется как сферическая лошадь в вакууме.

VD>>Он верно работал с самого начала.

А>А поправка Wolfhaund? Код, работал не правильно.
Мелкая бага. Заметь поправка не изменила колличество строк.

VD>>С чем? Это как раз тот случай когда ты губо попираешь принципы инкапсуляции. Eval() должен вычислять, а не возвращать значение. Испоьзование частнрых знаний, о том, что для некоторого типа Eval() реализован так, что может заменить эксессор свойства как раз и является нарушением инкапсуляции, так как ты опирашся на знания о реализации абстрактного метода.

А>Продолжаю оставаться несогласным. <<< Это пример неконструктива.
Типа тут гдето от тебя есть конструктив? Извини не вижу.

А>Легкость к изменениям программы, а не взглядов. Они впрочем у меня, тоже широкие.

Легкость это полное переписывание? Ну да когда 200-300 строк то переписать действительно легко, а когда больше...

А>А я не про методы, я про классы. В иерархию добавляется новый класс, в нем реализуется метод для посетителя. Но в самом посетителе, например для представления в виде строки, не добавляется проверка на новый класс. Ошибка вылетает только во время выполнения. Как, кстати, и в Nemerle в некоторых случаях.

Ясно. С тем как реализуются посетители не знаком.
Объясняю для тех кто не знает как реализуют посетитель:
interface IVisiter
{
    void accept(A a);
    void accept(B b);
}
interface IVisitable
{
    void visit(IVisiter visiter);
}
class A : IVisitable
{
    public void visit(IVisiter visiter)
    {
        visiter.accept(this);
    }
}
class B : IVisitable
{
    public void visit(IVisiter visiter)
    {
        visiter.accept(this);
    }
}
class ToStringVisiter : IVisiter
{
    void accept(A a)
    {
    ...
    }
    
    void accept(B b)
    {
    ...
    }
}
class EvalVisiter : IVisiter
{
    void accept(A a)
    {
    ...
    }

    void accept(B b)
    {
    ...
    }
}
class SomeElseVisiter : IVisiter
{
    void accept(A a)
    {
    ...
    }

    void accept(B b)
    {
    ...
    }
}

А теперь внимание вопрос:
Скомпилируется ли программа если добавить класс:
class C : IVisitable
{
    public void visit(IVisiter visiter)
    {
        visiter.accept(this);
    }
}


VD>>А вот этот код
Автор:
Дата: 17.05.07
не твой ли? Смотри как от полных имен не осталось и следа! Даже Literal был в совершенно не очевидный Lit переименован. Это тоже, так сказать, проявление широты взглядов?

А>Немерлисты, научили меня плохому.
И где в коде Влада неуместные сокращения?

А>Гм, не я понимаю, встречаются длинные строки, но чтобы все были 150 символьные? Против трех строк не против, но как уже говорил предлагаю тогда считать размер кода без ведущих пробелов или количество нажатий в Visual Studio (это впрочем тяжело подсчитать)

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

А>А у меня есть мнение, что не одна строка на Nemerle, а четыре,

А у меня есть мнение что при правильном форматирование не 7 строк на C#, а 22
class Minus : Oper
{
    public Minus(Expr first, Expr second)
        : base(first, second)
    {}
    
    public override string ToString()
    {
        return first.ToString() + "-" + second.ToString();
    }
    
    public override double Eval()
    {
        return first.Eval() - second.Eval();
    }
    
    public override Expr Convert(Converter converter)
    {
        return converter(new Minus(first.Convert(converter), second.Convert(converter)));
    }
}


А>только они размазаны по коду. Вот глаза-то придется поломать

Не размазаны, а сгрупированны по действию. Но не по объекту.
Просто другой принцип группировки. Иногда (например в данном случае) болие предпочтительный.

А>
А>| Minus { expr1 : Expr;   expr2 : Expr; }
А>| Minus(e1, e2) with op = "-" 
А>| Minus(e1, e2) => e1.Eval() - e2.Eval()
А>| Minus(e1, e2) => transform(Minus(e1.Convert(transform), e2.Convert(transform)))
А>

А>2 * 4 > 7
Почему 4 понятно, а вот почему 2 * 4 уже нет.

А>Также сопоставление претендует на универсальность и немного громоздко. А можно упростить до:

1)У Влада было так
| Call("max", [Literal(x), Literal(y)]) => Literal(Math.Max(x, y))


2)Попробуй написать аналог этого
| Call("max", [Mul(Literal(x), Literal(m)), Div(Literal(y), Literal(d))]) => Literal(Math.Max(x * m, y / d))
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Функциональное программирование в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.05.07 20:50
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Я добрее к людям. Если, у программиста больше 4 по C# на brainbench, то он может написать этот алгоритм. В потенциале.


Это алогоритм — это дисер на Ph.D. Его с нуля не написать ни мне, ни тебе не многим другим. Ты его можешь только содрать. Но как раз для этого тебе прийдется понять всю силу того самого паттерн-матчинга. А это уже парадокс.

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

А>Зачем? Она помогает мне ощущать интеллектуальное превосходство. In my dreams, чтобы не злить волков.

А, ну, успехов в этом нелегком труде.

VD>>Понимаш ли даже 30% разницы в коде — это весомый результат.

А>По мне так даже отрицательный, если на одной чаше microsoft, а на другой пять человек.
А>Как видишь, заставить меня программировать на Nemerle не так сложно.
А>Достаточно чтобы ms купила его и вложила бы большие средства в его развитие.

Вот! Что и требовалось доказать. А весь этот лживый демогогический бред можно было просто не раводить.

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

VD>>Это значит, что программа может быть написана на 30% быстрее, или что она может стать на 30% фуниональнее.

А>Это значит, что возможность получить справку по сложным моментам, в тысячи раз меньше.

Это зависит не от размера комьюнити, а от его подготовленности. Пока, что на этом форуме на все вопросы отвечают практически молниеносно. На английских форумах тоже. Так что тут ты просто мимо кассы.

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

А>В качалку чаще ходят, не для того чтобы один раз по 100, а для того чтобы два раза по 50. Повторяют, короче, упражения.

А>Где в качалке, intellisence, спрашивать опасаюсь.

Ага. Вот одни всю жизнь 2 раза по 50, а другие 10 по 110. А некторые 10 по 200. Причем, как и в программировании все определяют гены.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.