Здравствуйте, VladD2, Вы писали:
VD>Ну, так что? Попробуем залудить более-менее полноценное и честное сравениние?
Да ну, сам же говоришь, это терминологический спор.
Ну смотри — в таблице парадигм можно каждому языку понаставлять плюс на каждую парадигму, нет проблем.
Теперь про Хаскель.
В таблице типизации стоит "Явная типизация" — что под этим понимается? Возможность указывать типы явно? Тогда почему нет плюсика? Или наоборот, почему на "неявном приведении типов без потери данных" нет минуса? В Хаскеле в принципе нет приведения. Мы можем уточнить тип переменной, но привести целое к длинному целому не можем. Тем более неявно. Самая интересная таблица "Возможности языка". В Хаскеле нет шаблонов, но с другой стороны — нахрена козе баян? Это никак не говорит о достоинствах или недостатках языка. Мне кажется, интереснее было бы сравнивать не конкретные решения сами по себе, а то, как проблемы решаются на том или ином языке, В С++ это шаблоны, в Хаскеле для этого просто не надо уточнять тип функции Ну и дальше всё в том же духе, как то мне это представляется может быть и интересным, но не сильно полезным, ну разве что для расширения кругозора — теперь буду тыкать тебя в то, что Немерле отстой, потому что у него нет параметрического полиморфизма высших порядков
Здравствуйте, lomeo, Вы писали:
L>Да ну, сам же говоришь, это терминологический спор.
Ну, так если мы все будум пытаться прийти к конструктиву, то должно же что-то путное получиться?
L>Ну смотри — в таблице парадигм можно каждому языку понаставлять плюс на каждую парадигму, нет проблем.
Ага. Это если ставить их от любви к искуству. А можно сделать так. Ввести оценки:
1. Идеологически не совместим.
2. Не поддерживает.
3. Пытается эмулировать библиотеками без особого успеха.
4. С успехом эмулирует библиотеками.
5. Сносно поддерживает средствами самого языка.
6. Отлично поддерживает средствами самого языка.
То каждому языку можно будет поставить заслуженную оценку. Ну, какая к чертовой матери в С++ поддержка ФП? Ему я бы поставил 3. Конечно можно поспорить 3 или 4, но уж точно не 5 или 6. А вот Хаскелю и Немерле я бы опставил бы 6. C#-у 3.0, к слову, я бы поставил 5.
L>Теперь про Хаскель. L>В таблице типизации стоит "Явная типизация" — что под этим понимается?
Да в лес эту таблицу. Ежу понятно, что по уму нужно продумывать более гибкую оценку для данного параметра.
L> Возможность указывать типы явно? Тогда почему нет плюсика?
Потому как я уже сказал — "демакратическим" путем такие сопоставления не делются. Это профанация!
L> Или наоборот, почему на "неявном приведении типов без потери данных" нет минуса? В Хаскеле в принципе нет приведения. Мы можем уточнить тип переменной, но привести целое к длинному целому не можем. Тем более неявно.
Кстати, подобные вопросы сами по себе интересны. Ведь если нет фунций преобрзования, то писать на таком языке становится, мягко говоря, не просто. Тут как миниум нжно сноску. А то и подумать как лучше описать то или иное свойство.
Оптимально, чтобы каждый пункт сопровождался примером.
L> Самая интересная таблица "Возможности языка".
Ага. Ее вообще в лес. Надо сравнивать языки только в рамках поддерживаемых парадигм. А то и стилей. Для C# и С++ некоторые фичи могут быть разумными. А для Хаскеля — нет, так как он ФЯ.
L>В Хаскеле нет шаблонов, но с другой стороны — нахрена козе баян?
Полностью согласен. Шаблоны — это бред! Это отражение С++-нутого мышления — "если в С++ есть, то везед должно быть так же, а если нет, то они уроды". Надо сравнивать возможности обобщенного программирования (ОП). То что Шаблоны кроме ОП, на шаблонах ко всему прочему наворачивается метапрограммирование (МП) и реалзиуются фичи вроде миксинов нужно отражать в отдельных таблицах где описываются эти фичи. Другими словами должно быть наоборот. В графее "Поддержка ОП времени компиляции" доллжно стоять "Шаблоны". А в графе "Поддержка ОП времени выполнения" должен стоять прочерк. А у C# в перовой и второй гафе должно стоять "Generics", так как они доступны и в компайлатайм и в рантайм, а вот в графах "МП" и "Миксины" должн стоять "банан" (возможность не реализуется средствами языка).
L> Это никак не говорит о достоинствах или недостатках языка.
+1
L> Мне кажется, интереснее было бы сравнивать не конкретные решения сами по себе, а то, как проблемы решаются на том или ином языке, В С++ это шаблоны, в Хаскеле для этого просто не надо уточнять тип функции Ну и дальше всё в том же духе, как то мне это представляется может быть и интересным, но не сильно полезным, ну разве что для расширения кругозора — теперь буду тыкать тебя в то, что Немерле отстой, потому что у него нет параметрического полиморфизма высших порядков
Ну, Хаскель тоже можно потыкать много куда. Тут еще большой вопрос что такое "полиморфизма высших порядков" и зачем он нужен. Но это вопрос мне будет интересен если вдруг мы соберемся делать разумное сравнение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>эмуляция многотредности рунтаймом самого языка. в пределах одного (или нескольких) тредов ОС выполняется куча потоков исходного кода
А если эмулция производится библиотекой (файберы/зеленые потоки), то это как называть?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
VD>>Ну, так что? Попробуем залудить более-менее полноценное и честное сравениние?
FR>И какие предложения насчет этой процедуры?
В смысле? Сначала обдумываем что сравниваем и как по крупняку. Потом берем отдельные блоки и согласовываем их.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Мне кажется, интереснее было бы сравнивать не конкретные решения сами по себе, а то, как проблемы решаются на том или ином языке, В С++ это шаблоны, в Хаскеле для этого просто не надо уточнять тип функции Ну и дальше всё в том же духе, как то мне это представляется может быть и интересным, но не сильно полезным, ну разве что для расширения кругозора — теперь буду тыкать тебя в то, что Немерле отстой, потому что у него нет параметрического полиморфизма высших порядков
Ощущение, что характеристики, по которым будет идти сравнение, станут на порядок выше в абстракции, нежели существующие: не что умеет язык, а для чего язык умеет так, зачем ему нужно это, какие задачи это решает. Кстати, по такому сравнению сразу будет видно, какие языки самые удобные, а какие самые извратные для решения конкретных задач — здесь с процитированным не согласен, это очень и очень полезная информация. Вот только кто составит такой перечень? Себя настолько компетентным не ощущаю...
Здравствуйте, VladD2, Вы писали:
VD>Ну, так если мы все будум пытаться прийти к конструктиву, то должно же что-то путное получиться?
Честно говоря, не знаю. В смысле, да конечно, конструктив подразумевает рождение чего то полезного, сомневаюсь только, что у нас получится — очень уж тема скользкая. Хотя, возможно, это от того, что я пока не вижу, к чему это всё вообще.
Попытаюсь прокомментировать.
VD>Ага. Это если ставить их от любви к искуству. А можно сделать так. Ввести оценки: VD>1. Идеологически не совместим. VD>2. Не поддерживает. VD>3. Пытается эмулировать библиотеками без особого успеха. VD>4. С успехом эмулирует библиотеками. VD>5. Сносно поддерживает средствами самого языка. VD>6. Отлично поддерживает средствами самого языка.
Вот как тут оценивать? Понятия "успех" и "сносно/отлично" уж очень субъективны.
Голосованием? Мы ведь даже по шкале не сможем выставить — мол, этот язык поддерживает то-то лучше, чем этот — 100% будет флейм. А уж оценки ставить...
Не знаю я
VD>То каждому языку можно будет поставить заслуженную оценку. Ну, какая к чертовой матери в С++ поддержка ФП? Ему я бы поставил 3. Конечно можно поспорить 3 или 4, но уж точно не 5 или 6. А вот Хаскелю и Немерле я бы опставил бы 6. C#-у 3.0, к слову, я бы поставил 5.
Или вот здесь. Начнём спорить, что такое ФП, да что лучше — карринг в Хаскеле или не-знаю-как-называется — 5+_ в Немерле, ударимся в частности, короче.
VD>Кстати, подобные вопросы сами по себе интересны. Ведь если нет фунций преобрзования, то писать на таком языке становится, мягко говоря, не просто.
Не, функции есть, приведения нет, ну это оффтопик немного.
VD>Оптимально, чтобы каждый пункт сопровождался примером.
+1
VD>Но это вопрос мне будет интересен если вдруг мы соберемся делать разумное сравнение.
Попробовать можно, в любом случае. Я попробую, не смотря на свой скептицизм. У тебя есть конкретные предложения по тому, что оценивать? Огласите весь список, пжалста
Здравствуйте, lomeo, Вы писали:
VD>>Ага. Это если ставить их от любви к искуству. А можно сделать так. Ввести оценки: VD>>1. Идеологически не совместим. VD>>2. Не поддерживает. VD>>3. Пытается эмулировать библиотеками без особого успеха. VD>>4. С успехом эмулирует библиотеками. VD>>5. Сносно поддерживает средствами самого языка. VD>>6. Отлично поддерживает средствами самого языка.
L>Вот как тут оценивать? Понятия "успех" и "сносно/отлично" уж очень субъективны.
Субеъективны... Ну, что поделаешь?
Давай на примере. Берем функциональный стиль программирования и языки: С, С++, C#, Java, Nemerle, Haskell.
С я бы поставил 2, С++ — 3, C# 3.0 — 5, Java — 1, Nemerle и Haskell — 6. Причем к Haskell я бы сделал примечание, что это оснвоной и по сути единственный ситиль... к нему сделано множество оптимизаций...
L>Голосованием? Мы ведь даже по шкале не сможем выставить — мол, этот язык поддерживает то-то лучше, чем этот — 100% будет флейм. А уж оценки ставить...
Голосования тут бесполезны. А вот обсуждения полезны.
L>Или вот здесь. Начнём спорить, что такое ФП, да что лучше — карринг в Хаскеле или не-знаю-как-называется — 5+_ в Немерле, ударимся в частности, короче.
Если цель поспорить (как у нашего любимого еао197), то несомненно к консенсусу мы не прийдем. Но если мы будем стремиться к конструктиву, то договоримся.
Совершенно ведь не важно какие фичи позволяют писать на языке в фукнциональном стиле. Главное, что на нем можно писать в этом стиле и что это делать удобно. Не так ли? Немерле и Хаскель поддерживают ФП по полной программе. На обоих языках (как в прочем и на Лиспе) можно писать в этом стиле, и писать удобно. А вот скажем на С++ писать конечно можно, но только с подпорками вроде буста и все равно результат получается довольно отвратительным. Друими словами 1 или 2 ему поставить нельзя, но выше тройки тоже ничего не поставишь.
Опять же можно пообсуждать каждый выбор, но в пределах разумного. В конце концов можно для сопрных пунктов привести "коментарии экспертов".
VD>>Кстати, подобные вопросы сами по себе интересны. Ведь если нет фунций преобрзования, то писать на таком языке становится, мягко говоря, не просто.
L>Не, функции есть, приведения нет,
Есть фунции — есть приведение. Просто нет неявного приведения.
L>ну это оффтопик немного.
+1
VD>>Но это вопрос мне будет интересен если вдруг мы соберемся делать разумное сравнение.
L>Попробовать можно, в любом случае. Я попробую, не смотря на свой скептицизм. У тебя есть конкретные предложения по тому, что оценивать? Огласите весь список, пжалста
Я предпочитаю решать пролемы по мере поступления. Сначала нужно классифицировать языки по парадигмам, типам типизации и т.п.
Далее сравнивать их уже в разрезе поддерживаемой парадигмы. Так для ИП будут интересны поддерживаемые операторы, а для ФП возможности манипуляций с функциями и т.п.
Нужно заводить оп одному обсуждению на каждый вопрос. Само сравнение оформить отдельной страницей (или несколькими).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Давай на примере. Берем функциональный стиль программирования и языки: С, С++, C#, Java, Nemerle, Haskell.
VD>С я бы поставил 2, С++ — 3, C# 3.0 — 5, Java — 1, Nemerle и Haskell — 6. Причем к Haskell я бы сделал примечание, что это оснвоной и по сути единственный ситиль... к нему сделано множество оптимизаций...
ОК. Хотя я и не очень понял почему именно такие оценки, расскажи за что даётся каждая оценка.
Я видел твоё описание, но оно во-первых очень-очень субъективное ("пытается", "сносно" и т.д.), во-вторых, именно по этой причине — это всего лишь описание оценок, т.к. что 6, что "отлично поддерживает" — ни о чём не говорит. Можешь немного более формализовать выдачу баллов?
VD>Я предпочитаю решать пролемы по мере поступления. Сначала нужно классифицировать языки по парадигмам, типам типизации и т.п. VD>Далее сравнивать их уже в разрезе поддерживаемой парадигмы. Так для ИП будут интересны поддерживаемые операторы, а для ФП возможности манипуляций с функциями и т.п.
Да. Просто я плохо себе это представляю. Вот вернёмся к моему примеру. Есть проблема — в Scheme (без наворотов), для задания в map функции-преобразователя необходимо выписывать всю лямбду.
(map (lambda (x) (x + 5)) lyst)
В шарпе наверняка тоже что-то вроде:
lyst.Map(x => x + 5)
А вот в Haskell это решается каррингом
map (+5) lyst
В Nemerle не знаю как называется, partial function application?
lyst.Map(_ + 5)
И два последних варианта жутко удобны своей краткостью. Некоторые выводы, сравнение подходов к решению этой задачи и т.д. — в приниципе, понятно. Но вот как обозвать эту проблему? Как она вписывается в общую систему сравнений? Не хотелось бы получить винегрет. Как будут представлены эти данные — ведь матрично получается плохо, повествовательно — не очень наглядно? Раздавать ли для подобных решений оценки и как? И т.д. и т.п. Не ясно мне многое в том, как это должно быть. Что скажешь?
VD>Нужно заводить оп одному обсуждению на каждый вопрос. Само сравнение оформить отдельной страницей (или несколькими).
А если вопрос содержит подвопросы, насколько глубока кроличья нора?
Про сравнение на отдельной странице не очень понял.
Здравствуйте, lomeo, Вы писали:
VD>>С я бы поставил 2, С++ — 3, C# 3.0 — 5, Java — 1, Nemerle и Haskell — 6. Причем к Haskell я бы сделал примечание, что это оснвоной и по сути единственный ситиль... к нему сделано множество оптимизаций...
L>ОК. Хотя я и не очень понял почему именно такие оценки, расскажи за что даётся каждая оценка.
С — по сути был рассчитан на структурное программирование. Попытка писать в нем на любом из стилей приводит к закату сонца вручную. С++ не подерживает ФП сам по себе. Вместо этого имеются разные Локи и Бусты которые пытаются за счет гибкости шаблонов что-то подрихтовать. Однако программы написанные в ФП с использованием этих библиотек получаются громоздким, неуклюжими и требуют много усилий. C# 3.0 поддерживает главное — лябды с замыканиями, что позволяет использоват ФП во многих местах. Итераторы (те, что yeild) и LINQ так же облегчают использование ФП. Однако полной поддержки нет. Так, нет даже оптимизации концевой рекурсии. Нет паттерн-матчинга и т.п. Есть вывод типов, но он ограничивается выводом из инициализации. С Хаскелем и Немерлом все вроде ясно. Языки специально проектировались под ФП. Хаскль вообще только на него и рассчитан. Немерле — гибрид, но поддержка полноценная, на уровне языка и без компромисов.
L>Я видел твоё описание, но оно во-первых очень-очень субъективное ("пытается", "сносно" и т.д.), во-вторых, именно по этой причине — это всего лишь описание оценок, т.к. что 6, что "отлично поддерживает" — ни о чём не говорит.
Любая оценка субъективна, если она не рассчитывается на базе формальных показателей. Оценка языков по жизни будет субъективной, или прйдется оценивать количество байт в коде компилятора и другую никому не нужную фигню.
L>Можешь немного более формализовать выдачу баллов?
Меня в общем-то устраивает и такая. Если есть предолжения, то можно их рассмореть. Собственно суть моего предложения и заключается в том, чтобы вместе отшлифовать хероховатости с тем, чтобы у адекватных людей было меньше претензий.
L>Да. Просто я плохо себе это представляю. Вот вернёмся к моему примеру. Есть проблема — в Scheme (без наворотов), для задания в map функции-преобразователя необходимо выписывать всю лямбду.
L>
L>(map (lambda (x) (x + 5)) lyst)
L>
L>В шарпе наверняка тоже что-то вроде:
L>
L>lyst.Map(x => x + 5)
L>
L>А вот в Haskell это решается каррингом
L>
L>map (+5) lyst
L>
L>В Nemerle не знаю как называется, partial function application?
Да.
L>
L>lyst.Map(_ + 5)
L>
L>И два последних варианта жутко удобны своей краткостью.
+1
L> Некоторые выводы, сравнение подходов к решению этой задачи и т.д. — в приниципе, понятно. Но вот как обозвать эту проблему?
Мне кажется, что тут все очевидно. Сначала определяем поддерживает ли язык данную фичу. Далее смотрим как он ее поддериживает. Вот мой набор оценок для данного теста:
1 — не поддерживается.
2 — эмулируется библиотеками/МП (обязательно требуется пояснить суть эмуляции, данный пункт може быть полезен для С++, где ничерта нет, но все с горем пополам эмулируется).
3 — поддерживается за счет наличия лябд и замыканий.
4 — п. 3 + шорткат (сокращеный синтаксис) для урощения применения (опять же приводим пример).
В общем, если проблема сложная, то просто не надо описывать ее в терминах булевой логики . По сути мы даем объяснения, а уж оценки нужны исключительно для того чтобы можно было вывести некий общий вывод. Скажем С++ поддерживает ФП на 36, а Хаскель на 256. При этом мы поясним, что это синтетика и по ней можно судить только об общих тенденциях.
L>Как она вписывается в общую систему сравнений? Не хотелось бы получить винегрет. Как будут представлены эти данные — ведь матрично получается плохо, повествовательно — не очень наглядно? Раздавать ли для подобных решений оценки и как? И т.д. и т.п. Не ясно мне многое в том, как это должно быть. Что скажешь?
Мне кажется нужно совмещать табличную форуму, расширенный набор оценок, и пояснения на разговорном языке и конечно же снабжать все массой примеров. Глядишь у такого сравнения появятся и другие полезные фунции. Например, по ней можно будет выучить "похожий" язык. Ведь зная различия не трудно начать использовать новый язык.
Сложности скорее появятся в других местах. Вот скажем в Хаскеле есть лист-компрехеншон. Но в C# 3.0 есть квари-компрехеншон. Тоже штука мощьная, особенно если учитывать, что она прозрачно мапится на БД (про Хаскель ДиБи я знаю). Вот тут прийдется поломать голову, как преподнести подобное сравнение. Тут таблички уже почти наверняка не подойду и прйдется давать не мало текста и примеров, а однозначные выводы вообще вряд ли можно будет сделать, так как тут уже специфика аудитории и задач прет во все дыры.
VD>>Нужно заводить оп одному обсуждению на каждый вопрос. Само сравнение оформить отдельной страницей (или несколькими).
L>А если вопрос содержит подвопросы, насколько глубока кроличья нора?
Дык, на то и нужно обсуждение. Может разобъем, может оптом зачтем.
L>Про сравнение на отдельной странице не очень понял.
Ну, результат (сравнение) должен быть всегда перед глазами. Хранить множество версий срвенений в обсуждениях не очень разумно. Их ведь после нескольких итераций вообще не найти будет. Так что обсудили некую маленькую часть... создали страничку... еще раз осбудили... если претенций нет, то оставляем и приступаем к следующей части. Если потом оказывается, что надо внести изменения в существующую часть, то снова обсуждаем и меняем ее. Но результат у нас всегда доступен по ссылке из корневого сообщения (или в закладках).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, geniepro, Вы писали:
VD>>>Оптимально, чтобы каждый пункт сопровождался примером.
L>>+1
G>Это уже получится не просто сравнение, а миниэнциклопедия...
От этого кто-то пострадает?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
G>>Это уже получится не просто сравнение, а миниэнциклопедия...
VD>От этого кто-то пострадает?
У них цели немного разные.
Сравнение обычно бывает быстрое, поискал в гугле — нашёл матрицу сравнения, сравнил. А если нужны детали ищешь уже конкретно по ним.
Здравствуйте, lomeo, Вы писали:
L>У них цели немного разные. L>Сравнение обычно бывает быстрое, поискал в гугле — нашёл матрицу сравнения, сравнил. А если нужны детали ищешь уже конкретно по ним.
Ну, про матрицу я уже все сказал. Это по любому получится обманом.
Собственно Веб предоставляет возможность вынести дополнительное описание во всплывающие окна или куда-то вниз. Так что данные представимые в табличной форме можно будет смотреть точно так же, но при этом будет возможность разобраться в сути срвнения.
Все равно мы не сможет дать некую общуюю оценку по которой можно будет выбрать "лубщий язык" для всех и на все времена. Кому-то важно одно. Кому-то другое. Кому-то важны ограничения...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>С — по сути был рассчитан на структурное программирование. Попытка писать в нем на любом из стилей приводит к закату сонца вручную. С++ не подерживает ФП сам по себе. Вместо этого имеются разные Локи и Бусты которые пытаются за счет гибкости шаблонов что-то подрихтовать. Однако программы написанные в ФП с использованием этих библиотек получаются громоздким, неуклюжими и требуют много усилий. C# 3.0 поддерживает главное — лябды с замыканиями, что позволяет использоват ФП во многих местах. Итераторы (те, что yeild) и LINQ так же облегчают использование ФП. Однако полной поддержки нет. Так, нет даже оптимизации концевой рекурсии. Нет паттерн-матчинга и т.п. Есть вывод типов, но он ограничивается выводом из инициализации. С Хаскелем и Немерлом все вроде ясно. Языки специально проектировались под ФП. Хаскль вообще только на него и рассчитан. Немерле — гибрид, но поддержка полноценная, на уровне языка и без компромисов.
Два момента. Один по теме, один не очень.
Во-первых, из этого описания можно понять различия в поддержке ФП языков. Однако его надо читать. Значит это будет вроде пояснения к тем оценкам, что ты выставил этим языкам, верно я понял?
Во-вторых, (частности) подход к ФП может быть разным, а из этого описания можно сделать вывод, что Хаскель является подмножеством Немерле. Однако, это не так, даже если оставить такие глобальные вещи как multiparameter type classes, type families, GADT (тут, правда, не уверен) и т.д. как не относящиеся к ФП, то ещё остаётся масса различий — разница в выводе типов, разница в системе типов (пример с гарантией на уровне типов в отсутствии side effect-ов внутри atomically у STM), pattern guards, view patterns, использование карринга в качестве порождения комбинаторов (eDSL) и т.д. Стоит ли дописывать об этой разнице?
Последнее замечание, раузмеется, относится не к самому подходу, а только к примеру текста.
L>>Можешь немного более формализовать выдачу баллов?
VD>Меня в общем-то устраивает и такая. Если есть предолжения, то можно их рассмореть. Собственно суть моего предложения и заключается в том, чтобы вместе отшлифовать хероховатости с тем, чтобы у адекватных людей было меньше претензий.
Мне это представляется в целом так. Есть стандартная проблема — такая то. На языке таком то она решается так-то, на этом так-то, на этом даже проблемы такой не стоит, а на этом мы никак её не обойдём. У этого решения такие то преимущества в таких то условиях, а у этого такие то недостатки. До сих пор всё понятно.
Но вот дальше слишком много субъективного, это уровень генерации флейма. Хотя у этого решения такие то недостатки, но для одного они более важны, так как он чаще работает вот в таких то условиях, а для другого менее. Оценки могут не просто отличаться, они могут существенно различаться.
Давай что ли начнём что нибудь обсуждать, а там поглядим, насколько страшно то, чего я опасаюсь?
VD>Мне кажется, что тут все очевидно. Сначала определяем поддерживает ли язык данную фичу. Далее смотрим как он ее поддериживает. Вот мой набор оценок для данного теста: VD>1 — не поддерживается. VD>2 — эмулируется библиотеками/МП (обязательно требуется пояснить суть эмуляции, данный пункт може быть полезен для С++, где ничерта нет, но все с горем пополам эмулируется). VD>3 — поддерживается за счет наличия лябд и замыканий. VD>4 — п. 3 + шорткат (сокращеный синтаксис) для урощения применения (опять же приводим пример).
VD>В общем, если проблема сложная, то просто не надо описывать ее в терминах булевой логики .
ОК, т.е. всё таки получается миниэнциклопедия?
VD>Мне кажется нужно совмещать табличную форуму, расширенный набор оценок, и пояснения на разговорном языке и конечно же снабжать все массой примеров.
Я — за.
VD>Глядишь у такого сравнения появятся и другие полезные фунции. Например, по ней можно будет выучить "похожий" язык. Ведь зная различия не трудно начать использовать новый язык.
Э.. Не хотелось бы размазывать цели.
VD>Сложности скорее появятся в других местах. Вот скажем в Хаскеле есть лист-компрехеншон. Но в C# 3.0 есть квари-компрехеншон. Тоже штука мощьная, особенно если учитывать, что она прозрачно мапится на БД (про Хаскель ДиБи я знаю). Вот тут прийдется поломать голову, как преподнести подобное сравнение. Тут таблички уже почти наверняка не подойду и прйдется давать не мало текста и примеров, а однозначные выводы вообще вряд ли можно будет сделать, так как тут уже специфика аудитории и задач прет во все дыры.
Осмелюсь заявить, что наличие LH в Haskell не сильно то и полезно, местами удобно, но do-синтаксис порождает форму почти один в один (разве что появятся явно "guard" — буквально это слово, в одном месте return — тоже одно слово, да вместо запятых будут точки с запятой).
[ f z | x <- xs, y <- ys, x < y, let z = g x y]
do { x <- xs; y <- ys; guard(x < y); let z = g x y; return (f z)}
А вот в шарпе это вещь существенно облегчает кодирование/чтение. И как их оценивать?
Кстати, query comprehension в C# — это скорее do-syntax, т.к. query работает для разных IEnumerable, а do для разных монад. Может быть стоит сравнивать именно их?
VD>Дык, на то и нужно обсуждение. Может разобъем, может оптом зачтем.
ОК.
L>>Про сравнение на отдельной странице не очень понял.
VD>Ну, результат (сравнение) должен быть всегда перед глазами. Хранить множество версий срвенений в обсуждениях не очень разумно. Их ведь после нескольких итераций вообще не найти будет. Так что обсудили некую маленькую часть... создали страничку... еще раз осбудили... если претенций нет, то оставляем и приступаем к следующей части. Если потом оказывается, что надо внести изменения в существующую часть, то снова обсуждаем и меняем ее. Но результат у нас всегда доступен по ссылке из корневого сообщения (или в закладках).
Осталось начать?
Уже есть масса информации в таблицах. Может стоит поменять представление, добавить к таблицам описания, а то они в сносках.
Чтобы не начинать всё с самого начала.
Ну и дальше всё в том же духе, как то мне это представляется может быть и интересным, но не сильно полезным, ну разве что для расширения кругозора — теперь буду тыкать тебя в то, что Немерле отстой, потому что у него нет параметрического полиморфизма высших порядков 
