Вроде бы достаточно прозначно, если следовать интрукции

Обе function members являются applicable. Выбор между ними идет с помощью п. 14.4.2.2:

14.4.2.2 Better function member
Given an argument list A with a sequence of argument types {A1, A2, …, AN} and two applicable function
members MP and MQ with parameter types {P1, P2, …, PN} and {Q1, Q2, …, QN, MP},

Здесь, видимо, опечатка? Должно быть {Q1, Q2, ..., QN}?
Впрочем, не важно. У нас function members are applicable in expanded form, обе последовательности типов пустые, поскольку нет аргументов.

after expansion and type argument substitution,is defined to be a better function member than MQ if
• for each argument, the implicit conversion from AX to PX is not worse than the implicit conversion from
AX to QX, and
• for at least one argument, the conversion from AX to PX is better than the conversion from AX to QX.

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

When performing this evaluation, if MP or MQ is applicable only in its expanded form, then PX or QX refers to a
parameter in the expanded form of the parameter list.

Полезный комментарий, но это не наш случай -- аргументов-то нет.

In case the expanded parameter types {P1, P2, …, PN} and {Q1, Q2, …, QN}, are identical,

Вот, это про нас. Одинаковые пустые последовательности.

the following tiebreaking rules are applied to determine the better function member by comparing the given uninstantiated
and unexpanded parameter types {R1, R2, …, RK} and {S1, S2, …, SL} of the function members MP and MQ

Ключевое слово -- uninstantiated and unexpanded. Для нас K = L = 1, R1 = T[], S1 = T[][]

respectively. In this case, the better function member is determined by the following rules:
• If one of MP and MQ is non-generic, but the other is generic, then the non-generic is better.

Не про нас.

• Otherwise, if one of MP and MQ is applicable in its non-expanded form (or has no params array) and the
other is applicable only in its expanded form (and has a params array), then the non-expanded method is
better.

Не про нас.

• Otherwise, if the numbers of parameters K in MP and L in MQ are different, then the method with more
parameters is better.Note that this can only occur if both methods have params arrays and are only
applicable in their expanded forms.

Не про нас.

• Otherwise, the number of parameters K in MP and L in MQ are the same, and if one method has more
specific parameter types, then that method is better.

А это про нас. T[] is more specific than T[][], что видно далее индукцией по построению типа.

The given parameter types {R1, R2, …, RK} are
defined to be more specific than the given parameter types {S1, S2, …, SL} if each given parameter RX is
not less specific than SX, and at least one given parameter, RX is more specific than SX. A type parameter
is less specific than a non-type parameter. Recursively, a constructed type is more specific than another
constructed type (with the same number of type arguments) if at least one type argument is more
specific and no type argument is less specific than the corresponding type argument in the other. An
array type is more specific than another array type (with the same number of dimensions) if the element
type of the first is more specific than the element type of the second.

Итак, T isless specific than T[], откуда T[] is less specific than T[][]. Дальше уже не важно.

• Otherwise, if one member is a lifted operator and the other member is an unlifted operator, then the
unlifted operator is better.
• Otherwise, neither method is better.

Спасибо за этюд

using System;

class B<T>
{
  public static void Foo(params T[] x) { Console.WriteLine(1); }
  public static void Foo(params T[][] x) { Console.WriteLine(2); }
}

class C
{
  static void Main()
  {
    B<int>.Foo();
  }
}

Скомпилируется ли программа? Если да, то что будет напечатано?

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

N>Скомпилируется ли программа? Если да, то что будет напечатано?

Традиционная (в таких случая) реклама движка вывода типов Nemerle .

В нем код:

using System;

module B[T]
{
  public Foo(params _x : array[T]) : void { WriteLine(1); }
  public Foo(params _x : array[array[T]]) : void { WriteLine(2); }
}

module Program
{
  Main() : void
  {
    B.[int].Foo(); // E: typing fails on ambiguity between overloads
  }
}

Выдаст сообщение об ошибке:

Main.n(13,5):Error: typing fails on ambiguity between overloads:
Main.n(13,5):Warning: hint:   Posible overload: method B.Foo(params _x : array[array[T]]) : void #VarArg
Main.n(6,3):Warning: hint: overload defination
Main.n(13,5):Warning: hint:   Posible overload: method B.Foo(params _x : array[T]) : void #VarArg
Main.n(5,3):Warning: hint: overload defination

Что, на мой взгляд, является оптимальным поведением.

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

VD>Что, на мой взгляд, является оптимальным поведением.

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

Здравствуйте, Пельмешко, Вы писали:

П>p.s. Ура, nikov вернулся!

Есть место, где я появляюсь более регулярно, там тоже можно найти много интересного: http://youtrack.jetbrains.net/issues/RSRP?q=by:nikov

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

N>Здравствуйте, Пельмешко, Вы писали:

П>>p.s. Ура, nikov вернулся!

N>Есть место, где я появляюсь более регулярно, там тоже можно найти много интересного: http://youtrack.jetbrains.net/issues/RSRP?q=by:nikov

Божетымой, 3645 issues
Бедные JetBrains....

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

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

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

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

V>А как же популярность Явы?
Вот-вот, Ява намного удобнее C++, однако как только в C# появились генерики и парочка других вкусностей, все с этой явы моментально свалили, и сейчас практически любой писавший и на яве и на шарпе, кроме самых упертых явистов, согласится с тем, что шарп более удобный язык, что лишний раз подтверждает мой тезис.

V>Именно, только в конце приписать надо "для каждой конкретной задачи".
Угу. Вернемся к тому, что есть у меня конкретная задача и часть задачи удобно решать на ООП, а часть ФП, какой язык тут удобен? Ну вот например, есть у меня отличное дерево объектов в C#, но засада — для правильного и красивого вызова нужного метода у нужного экземпляра отлично подошел бы ПМ.
Твои действия:
— Городить визитор ?
— Писать на F# функцию ресолвинга ?
— Ручное выпиливание по тайпкастам ифам и свичам ?

V>Чем более специализирован язык, тем он проще и тем сложнее ошибиться программисту.
Я не вижу практической пользы от заточки языка исключительно на ООП или ФП. И практика показывает, что ни один чистый ООП или ФП язык не оказался пригодным для решения большинства типичных задачь.
Вернемся к предыдущему примеру — мне очевидно, надеюсь и тебе тоже, что при наличии ПМ в C#, данная задача решалась бы существенно проще, и с меньшей вероятностью совершить ошибку, чем любая из доступных сейчас альтернатив.
Так какая польза от того, что язык является чисто ООП или ФП?

Здравствуйте, Димчанский, Вы писали:

Д>А где можно скачать самую распоследнюю версию стандарта?
Д>Пришла пора заменить занимательную физику Перельмана в туалете на стандарт C#.

C# 3.0:
http://download.microsoft.com/download/3/8/8/388e7205-bc10-4226-b2a8-75351c669b09/csharp%20language%20specification.doc

C# 4.0 (черновик, написан в виде дополнения к спецификации C# 3.0, некоторые вещи будут существенно переписаны к релизу):
http://download.microsoft.com/download/7/E/6/7E6A548C-9C20-4C80-B3B8-860FAF20887A/CSharp%204.0%20Specification.doc

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

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

Это круто, если никто не подумал
Все же мне кажется, что никто им не мешал посмотреть, во что они превратили оверлоад и побольше ошибок генерировать при компиляции.
Мне в большей половине этих этюдов хочется увидеть ошибку, а не результат в стиле "никогда не догадаешься, какой метод вызовется". По-моему это не красит язык. А что будет еще через 10 лет?

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

ВВ>> На мой взгляд такие заявления равносильны тому, чтобы расписаться в том, что у языка никакой цельной концепции нет.
IB>Лично мне не нужен язык с концепцией. Мне нужнен язык, чтобы решать прикладную задачу. И если задача такова, что часть вещей отлично ложится на ООП, а часть на функциональщину, то мне нужно, чтобы я мог сделать все это в одном языке.

Зачем все это делать в одном языке? Что это за цель такая?
Старые времена прошли, про КОМ можно забыть, какие проблемы использовать для решения твоей "прикладной задачи" несколько языков?

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

V>>Именно, только в конце приписать надо "для каждой конкретной задачи".
IB>Угу. Вернемся к тому, что есть у меня конкретная задача и часть задачи удобно решать на ООП, а часть ФП, какой язык тут удобен? Ну вот например, есть у меня отличное дерево объектов в C#, но засада — для правильного и красивого вызова нужного метода у нужного экземпляра отлично подошел бы ПМ.
IB>Твои действия:
IB>- Городить визитор ?
IB>- Писать на F# функцию ресолвинга ?
IB>- Ручное выпиливание по тайпкастам ифам и свичам ?

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

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

ВВ>А ты читать научись.
<...>
ВВ>Подумай, может сам поймешь.
Блестящая аргументация, коллега, по делу есть что сказать? )

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

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

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

Так я правильно понял твою мысль или нет? )

ВВ>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо.
Чем слабо? Тем что там нет ПМ? =) Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП. И что делать?

ВВ>Если AST в рамках конкретной задачи — это цель, и проектировать ее надо, исходя из этой конкретной задачи, а не рассуждать о сферических конях в вакууме.
Вот ты и не рассуждай, а спроектируй.

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

ВВ>Записывай что хочешь. Мне тему "генерики и ООП дизайн" конкретно с тобой обсуждать неинтересно.
Слив засчитан.

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

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

AVK>Я про другое — ПМ + discriminated unions, если отбросить исторические корни, можно с равным правом отнести кака к ООП, так и к ФП, и совершенно непонятно, почему в ФП языках он уместен, а в ООП уже лишний.

Из-за принципа подстановки Лисков. Т.е., если ввести в язык алгебраические типы ака размеченные объединения, и они будут стоять где-то сбоку от ООП-возможностей языка — то можно, если же начнется наследование по ним наследование, напр. размеченные объединения будут представлять из себя иерархию классов (как в Nemerle), то получаем потенциальное нарушение инвариантов базового класса. Крайне неприятная мина в коде.

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

V>Вот простой код, что выведет?
V>

V>    class Base
V>    {
V>        public void Method(short value)
V>    }
V>    class Derived : Base
V>    {
V>        public void Method(int value)
V>    }
V>            short value = 0;
V>            new Derived().Method(value);
V>}

V>Раньше выводил short, теперь int.

Хм. А когда он выводил short? В C# 2.0 правило о самой производной реализации уже точно было. Неужели в 1.0 было по-другому? Мне сейчас уже не вспомнить.

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

N>>Хм. А когда он выводил short? В C# 2.0 правило о самой производной реализации уже точно было. Неужели в 1.0 было по-другому? Мне сейчас уже не вспомнить.

V>Проверь на VS2005.

Специально поставил VS2005 и VS2003. И там, и там выводится int.

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

ВВ>> На мой взгляд такие заявления равносильны тому, чтобы расписаться в том, что у языка никакой цельной концепции нет.
IB>Лично мне не нужен язык с концепцией. Мне нужнен язык, чтобы решать прикладную задачу. И если задача такова, что часть вещей отлично ложится на ООП, а часть на функциональщину, то мне нужно, чтобы я мог сделать все это в одном языке.

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

ВВ>>Мне вообще нравился C# 1.0. Довольно чистый был язык.
IB>Только мало пригодный к серьезному практическому применению.

А как же популярность Явы?
Мы когда смотрели ее спецификации в 95-м, тоже ухахатывались, за животы держались.. а оно вон как вышло, кто бы мог подумать.

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

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

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

VD>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>А какое отношение дженерики имеют к ООП?

VD>Они имеют отношение к понятию "удобный, современный язык" в моем представлении. Раз тебе достаточно C# 1.0, то значит тебе они не нужны. Так?

Ну скажем так, в 3.5 на уровне публичных контрактов мне генерики не нужны даром. В 4.0, может, что и изменится.
В качестве implementation detail могут быть и генерики, но это уже другой вопрос.

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

Э, ни разу не видел, чтобы компания предлагала кому-нибудь решение на *языке*. Языки всем пофиг. Предлагают, скажем, решение на MOSS 2007/WWF 3.5. Это платформа.
А какие инструменты мы достанет из загашника — вопрос десятый.

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

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

ВВ>>>>Я вот в упор не понимаю, откуда эти убеждения в том, что ФП это типа супер-современная тенденция.
VD>>>Раз не понимаешь, то не стоит это миф так усиленно навязывать окружающим.
ВВ>>Какой еще миф?
VD>Тот что ты озвучил. Читай свою цитату.

ФП как супер-современная тенденция это миф? Ну так я об этом и говорю.

ВВ>>Сейчас, может, и неудобно. А в дотнете, где один бинарник в принципе можно собираться из исходников на разных языках, такую интеграцию при желании можно было бы сделать легко и просто. Выставил в свойствах файлика F# — и вперед с песней.
VD>Можно было бы, и есть — это две большие разница, как любят говорить в Одессе.

Ну ты вот тут ниже рассуждаешь о том, как МС "душит" хорошие идеи тем, что продает плохие. Вот тебе пример хорошей идеи с моей колокольни, которую МС не стала развивать.
А что, был бы вот некий SQL.NET вместо Линка, написал, он тебе в компил-тайме сгенерировался в специфичный SQL, все интеллисенсы и прочие блага доступны, интеграция с остальным кодом прозрачная. Файлик в том же проекте лежит, в отдельной папочке. Красота, нет?

VD>Как я понимаю твои рассуждения имеют теоретический характер. F#, похоже, ты тоже знаешь чисто теоретически. Попробуй на нем поисать реальный код. Уверен, что ты будешь удивлен тем, что во-первых это не так то просто (научиться на нем писать), а во-вторых, когда ты поймешь этот язык и научишся на нем писать, то поймешь, что тебе уже не нужен C#, так как в общем F# мощьнее C#-а. Ну, и за одно, поймешь, что твоя концепция многоязычия развалилась.

А в чем проблема-то? Ты пробовал писать на F# и тебе синтаксис не понравился? F# в одном никогда не заменит C# — в ООП. Возможности отказаться от ООП я не вижу. Возможность использовать другие языки для описания отдельных алгоритмов — вполне.
Гибче надо быть, а не "перестраивать сознание" с каждым новом языком. Язык — это средство выражения твоих идей, а не средство, чтобы эти идеи формировать.

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

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

Ты пробовал? Или это твои детский страхи?

ВВ>>Ну вот, видишь, как все хорошо получается. C# + F# == отличный ООП и ФП. Так в чем же проблема? Зачем плакать и жрать кактус?
VD>Проблема в том, что это два приблизительно равных языка, что не вписывается в твою концепцию множества языков.

Они не "приблизительно" равные и не равные вообще. То, что удобно делать в шарпе, неудобно в F# — и наоборот.

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

VD>Другое дело в С++. Там эвристик куда меньше, а проблем куда больше. Вот это плохой дизайн. И дальше будет только хуже. А с шарпом все более менее нормально.

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

VD>У шарпа другие проблемы. Например, его синтаксис слизан с С где основной идеологией является идеология — содержимое кода функций — это statment-ы.

Мне вообще нравился C# 1.0. Довольно чистый был язык. Убрать из него тех же делегатов — получается ООП в стиле С++ с более прямым дизайном. И я не вижу ничего плохого в том, что содержимое кода функций — это statement-ы. Для императивного подхода это нормально. А нынешняя мода на ФП, которому уж сто лет в обед... Ну так мода и есть мода, а людям работать надо.
Языки, где statement == expression, и любой "блок кода" возвращает значение есть. Когда нужно, можно писать на них. Мне вот базовая грамматика С не кажется устаревшей. Для ФП она неудобна, но для ФП есть ФЯ.
А то, о чем ты говоришь, еще старше С на самом-то деле.

VD>Шарп начал миграцию к функциональному программированию, но от порочной (в плане поддержки ФП) С-ишной идеологии он не избвился. В результате писать функциональный код на шарпе в не так удобно как на том же немерле.

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

VD>Другая проблема — это откровенное старение и, как следствие, консерватизм его авторов. Например, они на отрез не хотят принимать идеи паттерн-матчинга или макросов (ака средств расширений языка).

Мне кажется, проблема не в консерватизме авторов. 99% пользователей языка не нужно МП. Большая часть пользователей не использует и половины из его текущих фич. Все же это мейнстрим язык. И вводить при таком подходе МП действительно не кажется столь уж необходимым.

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

VD>Традиционная (в таких случая) реклама движка вывода типов Nemerle .

F#:

open System

type B<'A>() = 
    member this.Foo (?x : 'A[]) = Console.WriteLine(1)
    member this.Foo (?x : 'A[][]) = Console.WriteLine(2)

let b = new B<int>()
b.Foo()

A unique overload for method 'Foo' could not be determined based on type information prior to this program point. The available overloads are shown below (or in the Error List window). A type annotation may be needed.
Possible overload: 'member B.Foo : ?x:'A [] [] -> unit'.
Possible overload: 'member B.Foo : ?x:'A [] -> unit'.

— лаконичнее и короче

2All: Сорри оффтоп

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

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

ВВ>Мне вообще нравился C# 1.0. Довольно чистый был язык.
Только мало пригодный к серьезному практическому применению.
Жизнь такова, что реальный код пишут не на чистых языках, а на удобных.

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

N>А расскажи-ка, в чём у F# хуже интеграция с дотнетом, чем у немерле?

А расскажи мне как передать ординарную фукнцию F# в другую программу?
Как мне сделать частичное применение к функции доннета?
Как его использовать, скажем, в T4?
Где разнообразные дизайнеры, визарды?

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

ЗЫ

Ну, и это уже к основному смыслу сказанного не имеет особого отношения, так как главная идея в том, что F# такой же универсальный язык как и C#. Может даже чуть более универсальный.

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

VD>О, как? А что же в этот список не вошел F#?
VD>Ты ведь только что его предлагал использовать?

Вместо C#, чтобы писать функциональный код. Потихоньку и он внедрится.

VD>К тому же ты говорил о дотнете. Не подскажешь какие из этих языков имеют к нему прямое отношение?

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

VD>SQL ты предлагаешь по старинке в виде строк в C#-е держать?

Ты, видимо, примыкаешь к лагерю, который считает linq2 большим прогрессом? У меня вот последние несколько лет основная СУБД Оракл — Linq2 неприменим. DW, Data Mining, реал-тайм отчеты да и просто области, где данных много, а производительность критична — linq2 неприменим.
Хотя я не против linq2. Непонятно только зачем это вводить в C# по самые помидоры.

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

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

ВВ> Что это за цель такая?
Удобство.

ВВ>Старые времена прошли, про КОМ можно забыть, какие проблемы использовать для решения твоей "прикладной задачи" несколько языков?
Это неудобно, понимаешь? Вместо того, чтобы написать пару строк кода одним способом, понять, что не получается и переписать подругому, нужно эту пару строк таскать по разным сборкам и напрягать мозг как эти сборки будут друг с другом взаимодействовать.
Я хочу решать прикладную задачу, а не думать как проще интегрировать C# в F# и наоборот, мне и SQL-я хватает.

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

Mab>А это про нас. T[] is more specific than T[][], что видно далее индукцией по построению типа.

Хотел сказать — наоборот?

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

ВВ>>Горы непроизводительного кода — это к linq2 и к тому что генерят его замечательные провайдеры.
V>Для простых запросов вполне там нормально все генерится, а сложные все-равно должны быть как процедуры прямо в твоем Оракле, а не в коде C#.
V>Или ты имеешь ввиду, что сама технология генерации строки-запроса не столь быстра как конкатенация строк? Ну это смешно совершенно, ибо затраты на обработку запроса, и затем парсинг сообщения-ответа DB-провайдером на клиентской стороне куда как более затратны, чем генерация SQL по LINQ expression.

Причем тут конкатенация строк? Для "простых запросов" и маленьких проектов вообще говоря пофиг как там базу писать. Для чего-то посложнее оказывается, что решение на Линке не масштабируется совершенно. И зачем он нужен, когда есть специально обученный человек, который пишет базу? Заставлять его на си-шарпе писать?
Вот и оказывается, что область применения linq2 весьма ограниченна.

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

IB>Это неудобно, понимаешь? Вместо того, чтобы написать пару строк кода одним способом, понять, что не получается и переписать подругому, нужно эту пару строк таскать по разным сборкам и напрягать мозг как эти сборки будут друг с другом взаимодействовать.
IB>Я хочу решать прикладную задачу, а не думать как проще интегрировать C# в F# и наоборот, мне и SQL-я хватает.

Это тебе напрямую в REP loop с таким подходом, т.е. не от языка зависит, а от возможности среды разработки. Никто не мешает делать REP на разных языках, ИМХО, это даже полезно.

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

ВВ>Давай так. Есть "параметрический полиморфизм",
То есть генерики все таки нужны? Ты уж определись.

ВВ> есть реализация генериков в 3.5. Второе на уровне контрактов только мешает.
Чем?

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

ВВ> Берем язык-всемогутер (один штука) и гуру-девелопер (один штука). Гуру-девелопер, размахивая языком-всемогутером, начинает работать и спустя всего-то шесть лет — вуаля! — проект готов причем сделан с охрененным качеством. Клиент плачет от радости.
Ты с темы не съезжай, не нужно переводить стрелки с одного языка на одного девелопера.

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

Это на каком языке было?

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

ВВ>Что-то мне кажется в этом-то как раз основная проблема. Может быть она и решаемая, но этот матч придется прошивать в систему типов по самые помидоры. Так что тут речь не о новой конструкции, а о внедрении принципиально новой концепции. Неудивительно, что они не торопятся делать такие изменения.

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

У тебя кроме "кажется" какие-то предпосылки есть? Вопрос риторический... можешь не отвечать.

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

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

V>Вот именно, из детерминированного и элегантного языка превращается в непонятно что.

Во как? Где это тут что-то куда-то превращается?

Это исходный дизайн языка. Никто не виноват, что пока не пришел Ников ни не прочел стандарт языка с пристрастием и не выявил такие вот неочевидности, никто из нас не их не замечал.

Скажем, проблемы перегрузки и переопределения методов — это проблемы принятых еще в C# 1.0 решений.

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

VD> В лиспе, например, такого средтва в языке нет.

Ну, с Лиспом отдельный разговор.

VD>Ну, и то что ПМ не является неотъемлемой частью ФП никак не умаляет полезности этой фичи в конкретном языке.

Конечно нет. Я про другое — ПМ + discriminated unions, если отбросить исторические корни, можно с равным правом отнести кака к ООП, так и к ФП, и совершенно непонятно, почему в ФП языках он уместен, а в ООП уже лишний.

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

ВВ>Причем тут конкатенация строк? Для "простых запросов" и маленьких проектов вообще говоря пофиг как там базу писать. Для чего-то посложнее оказывается, что решение на Линке не масштабируется совершенно. И зачем он нужен, когда есть специально обученный человек, который пишет базу? Заставлять его на си-шарпе писать?

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

И насчет масштабируемости, можно подробнее? Это раньше, в эпоху медленных компьютеров, пытались сэкономить на парсинге/предобработке запроса SQL, поэтому пихали все подряд в процедуры, а сейчас-то зачем? ИМХО, сейчас имеет смысл пихать только те задачи, которые не представимы в SQL-запросе (вопрос "представимости", кстати, от умений разработчика зависит), но для результата требуют обработать большую кучу данных, не нужных клиенту. Даже в этом случае, удобнее будет все эти алгоритмы поотлаживать на дотнете, и перенести в базу уже готовые решения.

ВВ>Вот и оказывается, что область применения linq2 весьма ограниченна.

Извини, но звучит как очередное задвигание про "черное и белое", серьезную/несерьезную разработку и прочие лозунги. Даже в "серьезной" разработке до 90% задач и более обычно примитивны и подходящи для исполнения подручными ср-вами, типа линка.

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

V>IDL непригоден? JavaScript, ShellScript, XSLT, ASN.1? Свой domain-specific конфиг на JSON непригоден? Будем считать — погорячился.

В твоем мозгу полнейшая каша относительно понятия DSL и ЯПОН. В твоем списке JavaScript — это ЯПОН, а остальное DSL-ли (опять же каша между внешними и внутренними).

Пока эта каша есть спорить с тобой о чем-то просто бесполезно.

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

Есть ЯПОН-ы и есть ДСЛ-и. Их нельзя сравнивать и тем более подменять в рассуждениях друг-другом.

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

Однако чем больше ЯПОН-ов используется в проекте тем сложнее этот проект в поддержке и развитии.

Использование нескольких ЯПОН конечно может быть оправдано, например, тем требованиями к производительности или наличием обширной кодовой базы на устаревшем языке, или тем, что на клиенте доступен другой язык (как это бывает в случае с JavaScript). Но использование нескольких языков ради чистоты концепций этих самых языков — это полнейший идиотизм. Ему нет никакого разумного оправдания. Вать машу! Haskell или F# — это вам не DSL-и!

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

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

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

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

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

V>Ты хоть представляешь, что сделал бы с Хейлсбергом научный мир IT за такие фокусы? Да разорвал бы как тузик грелку, опустил бы ниже плинтуса.
Хэйсбергу покласть на научный мир. Он делает языки не для научного мира, а для прикладных разработчиков — массовые языки, понимаешь?

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

V> Или же, (а почему бы и нет?) настало время для выработки новых практик для этой сборной солянки... В любом случае должно пройти достаточное время, больше чем кажется, ибо даже пока научных работ на эту тему не видно.
Вот Nemerle, как раз и был такой научной работой.

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

V>Тем не менее, если DSL не декларативный, а алгоритмический, обычно его делают на основе урезанной версии некоего ЯПОН, и сие факт. И я не столько спорю, сколько информацию тебе сообщаю.

Не позорься. Прочти определение ДСЛ-я.

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

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

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

Т.е. когда у тебя код спроектирован так:

void Process(AstNode node) { node.CallMyProcessPlz(this); } // паттерн-костыль, где гарантия, что не обманет? :)
void Process(AstNode1 node);
void Process(AstNode2 mode);

Вместо так:

void Process(AstNode node, Context context) { node.Process(context); } // или просто node.Process(this); если сам себе контекст.

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

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


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

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

V>>Значит, учитываем практики ООП, вот что делать.
IB>Какие практики? Предметная область такова, что структура модели очень напоминает AST. А работать с ним надо в ООП языке — какие практики ООП мне здесь помогут? Чем мне здесь может повредить ПМ или хотя бы банальный Type switch или какой нибудь другой аналог множественной диспетчеризации встроенный в язык?

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

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

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

Вот, и я про то, что здесь как минимум два пути: построение универсальной дрели, либо удобного слесарского пояса для инструментов. ИМХО, подходы вполне конкурентноспособны. Более того, те же WindowsForms дизайнеры в студии — это именно демонстрация второго подхода, когда ты не выходя из зала, переключаешься на другое кино. Точно так же я прикручивал всякие DSL в проект, по которым генерился код. Влад опять может сказать, что я сливаю, упоминая DSL, но он не дает себе времени сообразить, что возможно с применением DSL задача ПМ по AST в основном коде отпадет сама собой. Да и не ПМ загвоздка, а в отделении декларативного от подробностей реализации, что просто спасает при большом кол-ве кода.


IB>Мне нужны в языке типа C# возможности имеющиеся у традиционных ФП языков. Мне пофиг как их получить в одном языке или в платформе. Однако как получить их в одном языке и как это могло бы работать — я знаю. А вот все что я могу представить в рамках одной платформы не затрагивая язык — к практическому применению мало пригодно.

Учитывая сегодняшнюю степень интеграции языков, возможно ты и прав, думая что знаешь. Отличная интероперабельность получилась сегодня только м/у VB.Net и C#, языками-близнецами. К сожалению, DSL tools и прочее аналогичное практически в зачаточном состоянии сегодня, что не дает нам почувствовать бенефитов. И вот тебе хочется если не DSL, то хотя бы "ну вот как в том другом языке", чтобы хоть как-то уменьшить себе трудоемкость.

А чем Немерле не подошел?

Ну и опять же, у всех разные ситуации. Я с тех пор, как начал пользоваться дотнетом в 2002-м, еще ни разу не сталкивался с приличным проектом на дотнете, чтобы без нативной части, так что минимум 2 языка обычно использую. Да, "стык" требует дополнительного обслуживания, непрозрачен для рефакторинга... Т.е. требует повышенного внимания, угу. Зато получается красивее всего остального, сам любуюсь.


IB>Повторяю вопрос — у тебя есть идеи как добиться этого результата оставляя язык чистым в рамках одной конкретной парадигмы?

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

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


V>>Открыли нечто новое? ИМХО, удачно собрали в одном месте старое. Но открытых новых принципов пока не вижу.
IB>Лично мне не нужны новые принципы, мне нужны старые, но собранные в одном месте. Я не ищу революционных прорывов — мне работать надо.

Ну так почему не Немерле?
Сам бы давно на него прыгнул, если бы язык получил признание у потенциальных заказчиков, но не столько из-за ПМ, сколько из-за возможностей управления синтаксисом для генерации своих DSL (Владу опять передаю пламенный...)

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



N>Скомпилируется ли программа? Если да, то что будет напечатано?
Я думаю, что не скомпилируется.

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

1>Я думаю, что не скомпилируется.

К сожалению компилируется и выводит 2.
Осталось обратиться к стандарту за разъяснениями о выборе метода.

Здравствуйте, Димчанский, Вы писали:

Д>К сожалению компилируется и выводит 2.
Д>Осталось обратиться к стандарту за разъяснениями о выборе метода.

Да, в стандарте есть этому объяснение.
Можно даже вот так сделать

using System;

class B<T>
{
  public static void Foo(params T[] x) { Console.WriteLine(1); }
  public static void Foo(params T[][] x) { Console.WriteLine(2); }
  public static void Foo(params T[][][] x) { Console.WriteLine(3); }
}

class C
{
  static void Main()
  {
    B<int>.Foo();
  }
}

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

N>

N>  public static void Foo(params T[] x) { Console.WriteLine(1); }
N>  public static void Foo(params T[][] x) { Console.WriteLine(2); }
N>

N>Скомпилируется ли программа? Если да, то что будет напечатано?

Согласно 7.4.3.1, оба метода applicable in expanded form и какого-то лешего второй является better...

Ума не приложу почему между int[] и int[][] в таком же случае компилятор выбрать не сможет, а между T[] и T[][], где T — bounded generic type of enclosing generic class, выбирает второй... И ведь не важно чем будет являться T...



p.s. Ура, nikov вернулся!

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

Mab>

Mab>14.4.2.2 Better function member
Mab>Given an argument list A with a sequence of argument types {A1, A2, …, AN} and two applicable function
Mab>members MP and MQ with parameter types {P1, P2, …, PN} and {Q1, Q2, …, QN, MP},

Mab>Здесь, видимо, опечатка? Должно быть {Q1, Q2, ..., QN}?

В моем тексте все правильно:


А анализ совершенно верный!

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

Mab>А это про нас. T is more specific than T[], что видно далее индукцией по построению типа.

Я до этого дошёл, но завис на этих правилах , всё равно не понимаю почему T less specific than T[]:

o A type parameter is less specific than a non-type parameter.

o Recursively, a constructed type is more specific than another constructed type (with the same number of type arguments) if at least one type argument is more specific and no type argument is less specific than the corresponding type argument in the other.

o An array type is more specific than another array type (with the same number of dimensions) if the element type of the first is more specific than the element type of the second.

Поясните пожалуйста, какое из правил здесь действует.

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

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

Mab>>

Mab>>14.4.2.2 Better function member
Mab>>Given an argument list A with a sequence of argument types {A1, A2, …, AN} and two applicable function
Mab>>members MP and MQ with parameter types {P1, P2, …, PN} and {Q1, Q2, …, QN, MP},

Mab>>Здесь, видимо, опечатка? Должно быть {Q1, Q2, ..., QN}?

N>В моем тексте все правильно:
N>
Ага, понятно. Я на сайте ECMA подсмотрел, видимо они не обновляют стандарт:
www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf

N>А анализ совершенно верный!

Здравствуйте, Пельмешко, Вы писали:

П>Я до этого дошёл, но завис на этих правилах , всё равно не понимаю почему T less specific than T[]:
Вроде бы самое первое из списка. T -- это type parameter, T[] таковым не является.

П>

П>o A type parameter is less specific than a non-type parameter.

П>o Recursively, a constructed type is more specific than another constructed type (with the same number of type arguments) if at least one type argument is more specific and no type argument is less specific than the corresponding type argument in the other.

П>o An array type is more specific than another array type (with the same number of dimensions) if the element type of the first is more specific than the element type of the second.

П>Поясните пожалуйста, какое из правил здесь действует.

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

Mab>Здравствуйте, Пельмешко, Вы писали:
П>>Я до этого дошёл, но завис на этих правилах , всё равно не понимаю почему T less specific than T[]:
Mab>Вроде бы самое первое из списка. T -- это type parameter, T[] таковым не является.

Хм, интересно, то есть T остаётся для компилятора как type parameter, даже в constructed type...
Я первое правило сразу же пропустил, думая что оно действует только для generic-методов...

ИМХО это плохое поведение...
Я бы ограничил это правило type parameter'ами от generic-методов, так как там правило имеет смысл и интуитивно...
Но наверное это повлекло бы какие-нить проблемы

Здравствуйте, Пельмешко, Вы писали:

П>Хм, интересно, то есть T остаётся для компилятора как type parameter, даже в constructed type...

Обрати внимание на слово uninstantiated. Сравниваются типы из исходных деклараций, игнорируя любые подстановки типов-аргументов.

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

Mab>Ага, понятно. Я на сайте ECMA подсмотрел, видимо они не обновляют стандарт:
Mab>www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf

Насколько я знаю, версии C# 3.0, 4.0 и не проходили международную стандартизацию.

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

N>Можно даже вот так сделать

А можно еще и так:

void Main()
{
    var c1 = new C<object>();
    c1.A(1);
    c1.A();    
    
    var c2 = new C<int>();
    c2.A(1);
    c2.A();        
}

class C<T>
{
    public void A(object a)
    {
        Console.WriteLine("A(object a)");
    }

    public void A(T a)
    {
        Console.WriteLine("A<>("+typeof(T).Name+" a)");
    }
    
    public void A(params T[] a)
    {
        Console.WriteLine("A<>(params "+typeof(T).Name+"[] a)");
    }

    public void A(params T[][] a)
    {
        Console.WriteLine("A<>(params "+typeof(T).Name+"[][] a)");
    }
}

А вот почему с шаблонными класами все компилится, а так:

void Main()
{
    var b= new B();
    b.A();
}

class B
{
    public void A(params int[] a)
    {
        Console.WriteLine("A(params int[] a)");
    }

    public void A(params int[][] a)
    {
        Console.WriteLine("A(params int[][] a)");
    }
}

и так:

void Main()
{
    var b= new B();
    b.A();
}

class B
{
    public void A<T>(params T[] a)
    {
        Console.WriteLine("A(params int[] a)");
    }

    public void A<T>(params T[][] a)
    {
        Console.WriteLine("A(params int[][] a)");
    }
}

нет?

Здравствуйте, Димчанский, Вы писали:

Д>А вот почему с шаблонными класами все компилится, а так:

Д>

Д>void Main()
Д>{
Д>    var b= new B();
Д>    b.A();
Д>}

Д>class B
Д>{
Д>    public void A(params int[] a)
Д>    {
Д>        Console.WriteLine("A(params int[] a)");
Д>    }

Д>    public void A(params int[][] a)
Д>    {
Д>        Console.WriteLine("A(params int[][] a)");
Д>    }
Д>}
Д>

Здесь int[][] не является more specific по сравнению с int[]. Посмотри внимательно правила определения "more specific".

Д>и так:

Д>

Д>void Main()
Д>{
Д>    var b= new B();
Д>    b.A();
Д>}

Д>class B
Д>{
Д>    public void A<T>(params T[] a)
Д>    {
Д>        Console.WriteLine("A(params int[] a)");
Д>    }

Д>    public void A<T>(params T[][] a)
Д>    {
Д>        Console.WriteLine("A(params int[][] a)");
Д>    }
Д>}
Д>

Д>нет?
А здесь вообще другая проблема: компилятор не может вывести тип T. Стоит написать b.A<int>(), и все получится.

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

Mab>Здесь int[][] не является more specific по сравнению с int[]. Посмотри внимательно правила определения "more specific".

А где можно скачать самую распоследнюю версию стандарта?
Пришла пора заменить занимательную физику Перельмана в туалете на стандарт C#.

Mab>А здесь вообще другая проблема: компилятор не может вывести тип T. Стоит написать b.A<int>(), и все получится.

Да, во втором случае поторопился с примером.

Здравствуйте, Димчанский, Вы писали:

Д>А где можно скачать самую распоследнюю версию стандарта?
Д>Пришла пора заменить занимательную физику Перельмана в туалете на стандарт C#.
Не скажу насчет последней, это nikov лучше знает. На сайте ECMA лежит какая-то ревизия.

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

Mab>Не скажу насчет последней, это nikov лучше знает. На сайте ECMA лежит какая-то ревизия.

Тут вроде вылезло несоответствие того, что на ECMA и того, что у nikov.
Будем ждать ответ nikov'а, где взять последнюю версию.

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

ВВ>Кстати, да. Мне вообще непонятно, зачем в шарпе компилировать такие вещи. Никакой практической пользы от этого нет. А самым ожидаемым поведением здесь была бы ошибка.

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

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

ВВ>Это круто, если никто не подумал
ВВ>Все же мне кажется, что никто им не мешал посмотреть, во что они превратили оверлоад и побольше ошибок генерировать при компиляции.

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

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

ВВ>Мне в большей половине этих этюдов хочется увидеть ошибку, а не результат в стиле "никогда не догадаешься, какой метод вызовется". По-моему это не красит язык. А что будет еще через 10 лет?

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

Другое дело в С++. Там эвристик куда меньше, а проблем куда больше. Вот это плохой дизайн. И дальше будет только хуже. А с шарпом все более менее нормально.

У шарпа другие проблемы. Например, его синтаксис слизан с С где основной идеологией является идеология — содержимое кода функций — это statment-ы. Шарп начал миграцию к функциональному программированию, но от порочной (в плане поддержки ФП) С-ишной идеологии он не избвился. В результате писать функциональный код на шарпе в не так удобно как на том же немерле.

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

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

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

Ну, а что тут поделать? Хейльсберг благополучно проспал последние 20 лет и заметил появление ФП только в 2005-ом, когда C# был концептуально закончен.

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

К сожалению, MS вряд ли вложит деньги в Nemerle, так как это будет равносильно отправки Шарпа (а следовательно и Хейльсберга на пенсию).

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

Ну, 10 лет с одной стороны срок большой, а сдругой не очень. Вон с С++ за последние 10 лен ровным счетом не произошло.

Лично я был бы рад, чтобы за следующие 10 лет основным языком мэйнстрима стал бы аналог Nemerle (или Scala).

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

ВВ>Мне вообще нравился C# 1.0. Довольно чистый был язык.

А мне не очень. Слишком он был ограниченным.

ВВ>Убрать из него тех же делегатов — получается ООП в стиле С++ с более прямым дизайном. И я не вижу ничего плохого в том, что содержимое кода функций — это statement-ы. Для императивного подхода это нормально.

Для императивного подхода достаточно C# 2.0. Ну, так он есть. Пользуйся им. Кто тебе не дает?

ВВ>А нынешняя мода на ФП, которому уж сто лет в обед... Ну так мода и есть мода, а людям работать надо.

Странный ты. Мода на ООП дала ООП и ты что-то не очень убиваешься от этого факта. Мода на ФП дала ФП, но тут ты что-то не доволен.

В конце концов есть C# 2 и даже 1, а то и просто С. Кто тебе мешает их использовать? Будешь пользоваться вечными ценностями и не гнаться за модой .

ВВ>Языки, где statement == expression, и любой "блок кода" возвращает значение есть. Когда нужно, можно писать на них. Мне вот базовая грамматика С не кажется устаревшей. Для ФП она неудобна, но для ФП есть ФЯ.

Ну, а мне не нужны ФЯ, ФП и даже ООП и ООЯ. Мне нужен удобный для работы инструмент. И в современном инструменте хочется видеть достижения современной науки которые способны упростить реализацию конечных программ.

VD>>Шарп начал миграцию к функциональному программированию, но от порочной (в плане поддержки ФП) С-ишной идеологии он не избвился. В результате писать функциональный код на шарпе в не так удобно как на том же немерле.

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

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

ВВ>А зачем писать функциональный код на шарпе я не понимаю

Искренне тебя жаль, если это так. Я вот не понимаю зачем писать гору бессмысленного кода там где можно обойтись парой строк вполне понятного кода. Применение ФП периодически дает возможность существенно сократить и упростить код. Так почему бы этим не воспользоваться?

VD>>Другая проблема — это откровенное старение и, как следствие, консерватизм его авторов. Например, они на отрез не хотят принимать идеи паттерн-матчинга или макросов (ака средств расширений языка).

ВВ>Мне кажется, проблема не в консерватизме авторов. 99% пользователей языка не нужно МП.

Ну, да. Если за 99% держать быдлокодеров индусятников, то конечно. Но сдается мне, что кто-то сильно ошибается в цифрах. Их далеко не 99%. Процент людей с мозгами в среде программистов довольно велик. Возможно они не гении и даже не ученые, но и не тупые дебилы. Так что им нужен более мощный и более уодбный интсрумент.

Личном мне такой инструмент нужен. И я не вижу такого инструмента "из коробки" посему занимаюсь созданием такового самостоятельно.

Ну, а тем кто примыкает к этим "99%" желаю счастливого кодинга.

ВВ>Большая часть пользователей не использует и половины из его текущих фич. Все же это мейнстрим язык. И вводить при таком подходе МП действительно не кажется столь уж необходимым.

Да, да. Именно так и думают разные Хейльсберги. Но это их личные проблемы.

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

VD>Ну, 10 лет с одной стороны срок большой, а сдругой не очень. Вон с С++ за последние 10 лен ровным счетом не произошло.

С С++ ситуация другая. Все же его не МС изобрела. МС вот за это время успела придумать и задушить два диалекта С++.
А C# — детище МС. Ни с кем можно не считаться.

ВВ>>Мне вообще нравился C# 1.0. Довольно чистый был язык.
VD>А мне не очень. Слишком он был ограниченным.

Для высокоуровнего ООП кода вполне достаточный. Для остального есть другие языки.

ВВ>>Убрать из него тех же делегатов — получается ООП в стиле С++ с более прямым дизайном. И я не вижу ничего плохого в том, что содержимое кода функций — это statement-ы. Для императивного подхода это нормально.
VD>Для императивного подхода достаточно C# 2.0. Ну, так он есть. Пользуйся им. Кто тебе не дает?
ВВ>>А нынешняя мода на ФП, которому уж сто лет в обед... Ну так мода и есть мода, а людям работать надо.
VD>Странный ты. Мода на ООП дала ООП и ты что-то не очень убиваешься от этого факта. Мода на ФП дала ФП, но тут ты что-то не доволен.

Мода на ФП, которая "дала ФП", прошла 30 лет назад. Я вот в упор не понимаю, откуда эти убеждения в том, что ФП это типа супер-современная тенденция. Да, для некоторых задач ФП более удобно. Почему бы для таких задач не использовать специализированные языки?

ВВ>>Языки, где statement == expression, и любой "блок кода" возвращает значение есть. Когда нужно, можно писать на них. Мне вот базовая грамматика С не кажется устаревшей. Для ФП она неудобна, но для ФП есть ФЯ.
VD>Ну, а мне не нужны ФЯ, ФП и даже ООП и ООЯ. Мне нужен удобный для работы инструмент. И в современном инструменте хочется видеть достижения современной науки которые способны упростить реализацию конечных программ.

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

ВВ>>А зачем писать функциональный код на шарпе я не понимаю
VD>Искренне тебя жаль, если это так. Я вот не понимаю зачем писать гору бессмысленного кода там где можно обойтись парой строк вполне понятного кода. Применение ФП периодически дает возможность существенно сократить и упростить код. Так почему бы этим не воспользоваться?

А чего меня жалеть-то? Пожалей лучше тех, кто функциональный код на шарпе пишет. Я для этого уж лучше F# возьму — именно для того, чтобы "не писать гору бессмысленного кода там где можно обойтись парой строк вполне понятного кода".

ВВ>>Большая часть пользователей не использует и половины из его текущих фич. Все же это мейнстрим язык. И вводить при таком подходе МП действительно не кажется столь уж необходимым.
VD>Да, да. Именно так и думают разные Хейльсберги. Но это их личные проблемы.

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

Если же ты хочешь, чтобы МС *формировала" мейнстрим, а не подстраивалась под него, то это, видимо, к совсем другой компании надо обращаться. МС так не делала никогда. И уже ИМХО не будет.

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

VD>К сожалению, MS вряд ли вложит деньги в Nemerle, так как это будет равносильно отправки Шарпа (а следовательно и Хейльсберга на пенсию).
F#, осталось в версии 3.0 добавить макросы и на NET платформу снизайдет счастье.

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

ВВ>>>Мне вообще нравился C# 1.0. Довольно чистый был язык.
VD>>А мне не очень. Слишком он был ограниченным.

ВВ>Для высокоуровнего ООП кода вполне достаточный.

Без дженериков то?

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

Для чего другого то? Ты язык используешь чтобы программы писать или для чего-то другого?

ВВ>Мода на ФП, которая "дала ФП", прошла 30 лет назад.

Слушай, я гляжу тебе просто поспорить охота. Зачем нести такую чушь?
Мне тяжело говорить вообще о моде на ФП, но если она и есть, то только в последние лет 5, когда ФП стали популяризировать как следует. Сам ФП существует уже 50 лет (т.е. почти столько же как и ИП), но серьезной его популяризации за первые 45 лет не было.

Лично я 15 назад даже не слышал про ФП. И это на фоне того, что ООП-мо мне всю плешь в те годы проели.

ВВ>Я вот в упор не понимаю, откуда эти убеждения в том, что ФП это типа супер-современная тенденция.

Раз не понимаешь, то не стоит это миф так усиленно навязывать окружающим.

ВВ> Да, для некоторых задач ФП более удобно. Почему бы для таких задач не использовать специализированные языки?

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

ВВ>А почему "удобный для работы инструмент" == один-единственный язык-всемогутер?

Все по тому же. Мы не плотники чтобы использовать 22 инструмента.

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

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

ВВ>А чего меня жалеть-то? Пожалей лучше тех, кто функциональный код на шарпе пишет. Я для этого уж лучше F# возьму — именно для того, чтобы "не писать гору бессмысленного кода там где можно обойтись парой строк вполне понятного кода".

Это не F# ли является узкоспециализированным? Я тебя расстрою. Это мультипарадигмный язык отличающийся от C# только тем, что в нем хреновый ООП и плохая интеграция с дотнетом, но хороший ФП, в то время как у отличный ООП и интеграция с дотнетом, но хреновый ФП.

Так вот лично вместо двух хреновых в отдельных аспектах языков хочется использовать один язык которые достаточно хорош во всех аспектах. Вот Nemerle как раз и есть такой язык. Он так же хорош в ФП как F#, и так же хорошо в ООП и интеграции с дотнетом как C#. Плюс ко всему прочему он расширяемый, что означает, что я могу встроить в него те самые узко-специализированные языки которые так хороши при решении прикладных задач, по твоим словам же.

ВВ>Т.е. ты полагаешь, что ситуация в действительности кардинально иная, люди страдают от ограниченности шарпа, а "разные Хейльсберги" слепо это игнорируют?

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

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

Какая в задницу статистика? МС давно формирует рынок, а не подчиняется ему.

ВВ>Если же ты хочешь, чтобы МС *формировала" мейнстрим, а не подстраивалась под него, то это, видимо, к совсем другой компании надо обращаться. МС так не делала никогда. И уже ИМХО не будет.

Ладно. Мне тебя переубеждать просто в лом. Оставайся при своем мнении.

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

ВВ>Зачем все это делать в одном языке? Что это за цель такая?
ВВ>Старые времена прошли, про КОМ можно забыть, какие проблемы использовать для решения твоей "прикладной задачи" несколько языков?

А как хорошо ты знаешь другие языки? И где ты применяешь их на практике?

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

VD>Это не F# ли является узкоспециализированным? Я тебя расстрою. Это мультипарадигмный язык отличающийся от C# только тем, что в нем хреновый ООП и плохая интеграция с дотнетом, но хороший ФП, в то время как у отличный ООП и интеграция с дотнетом, но хреновый ФП.

А расскажи-ка, в чём у F# хуже интеграция с дотнетом, чем у немерле?

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

ВВ>>Зачем все это делать в одном языке? Что это за цель такая?
ВВ>>Старые времена прошли, про КОМ можно забыть, какие проблемы использовать для решения твоей "прикладной задачи" несколько языков?
VD>А как хорошо ты знаешь другие языки? И где ты применяешь их на практике?

О, в больших количествах.

Трансформация данных — XSLT.
Описание данных — XSD
Описание грамматик — EBNF.
Операции с данными — SQL.
Обработка, скрипты — JScript, Python.
Собственные DSL-и

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

ВВ>>Для высокоуровнего ООП кода вполне достаточный.
VD>Без дженериков то?

А какое отношение дженерики имеют к ООП?

ВВ>>Для остального есть другие языки.
VD>Для чего другого то? Ты язык используешь чтобы программы писать или для чего-то другого?

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

ВВ>>Мода на ФП, которая "дала ФП", прошла 30 лет назад.
VD>Слушай, я гляжу тебе просто поспорить охота. Зачем нести такую чушь?

Чушь — это про то, что ФП есть нечто новое и модное. Оно такое же модное как комод моей бабушки.

ВВ>>Я вот в упор не понимаю, откуда эти убеждения в том, что ФП это типа супер-современная тенденция.
VD>Раз не понимаешь, то не стоит это миф так усиленно навязывать окружающим.

Какой еще миф?

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

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

ВВ>>А почему "удобный для работы инструмент" == один-единственный язык-всемогутер?
VD>Все по тому же. Мы не плотники чтобы использовать 22 инструмента.

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

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

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

ВВ>>А чего меня жалеть-то? Пожалей лучше тех, кто функциональный код на шарпе пишет. Я для этого уж лучше F# возьму — именно для того, чтобы "не писать гору бессмысленного кода там где можно обойтись парой строк вполне понятного кода".
VD>Это не F# ли является узкоспециализированным? Я тебя расстрою. Это мультипарадигмный язык отличающийся от C# только тем, что в нем хреновый ООП и плохая интеграция с дотнетом, но хороший ФП, в то время как у отличный ООП и интеграция с дотнетом, но хреновый ФП.

Ну вот, видишь, как все хорошо получается. C# + F# == отличный ООП и ФП. Так в чем же проблема? Зачем плакать и жрать кактус?

VD>У меня даже нет сомнения. Скажу больше. "разные Хейльсбери", пользуясь ресурсами своих компаний, удерживают людей в каменном веке (в некоторых аспектах). Но Хельсберг как раз плохой пример. А вот Сан действительно совсем застрял в каменном веке и держит там своих приверженцев.
ВВ>>МС вообще очень осторожная контора и всегда любила сначала гору статистики собрать, а потом уже принимать решения. Ты считаешь, что у тебя более верное представление о мейнстриме?
VD>Какая в задницу статистика? МС давно формирует рынок, а не подчиняется ему.

Назови пример новой технологии, которую изобрела МС. Все, что они делали, повторение чужих находок. Ожидать, что они ломанутся в массы с такой штукой как МП, пока кто-нибудь до них не наступит на все грабли ИМХО не стоит.
VD>Ладно. Мне тебя переубеждать просто в лом. Оставайся при своем мнении.

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

ВВ>Трансформация данных — XSLT.
ВВ>Описание данных — XSD
ВВ>Описание грамматик — EBNF.
ВВ>Операции с данными — SQL.
ВВ>Обработка, скрипты — JScript, Python.
ВВ>Собственные DSL-и

О, как? А что же в этот список не вошел F#?
Ты ведь только что его предлагал использовать?

К тому же ты говорил о дотнете. Не подскажешь какие из этих языков имеют к нему прямое отношение? Ну, АйронПитон конечно есть. А с остальными то что? SQL ты предлагаешь по старинке в виде строк в C#-е держать?

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

ВВ>А какое отношение дженерики имеют к ООП?

Они имеют отношение к понятию "удобный, современный язык" в моем представлении. Раз тебе достаточно C# 1.0, то значит тебе они не нужны. Так?

ВВ>>>Для остального есть другие языки.
VD>>Для чего другого то? Ты язык используешь чтобы программы писать или для чего-то другого?

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

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

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

ВВ>>>Я вот в упор не понимаю, откуда эти убеждения в том, что ФП это типа супер-современная тенденция.
VD>>Раз не понимаешь, то не стоит это миф так усиленно навязывать окружающим.

ВВ>Какой еще миф?

Тот что ты озвучил. Читай свою цитату.

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

Можно было бы, и есть — это две большие разница, как любят говорить в Одессе.

Как я понимаю твои рассуждения имеют теоретический характер. F#, похоже, ты тоже знаешь чисто теоретически. Попробуй на нем поисать реальный код. Уверен, что ты будешь удивлен тем, что во-первых это не так то просто (научиться на нем писать), а во-вторых, когда ты поймешь этот язык и научишся на нем писать, то поймешь, что тебе уже не нужен C#, так как в общем F# мощьнее C#-а. Ну, и за одно, поймешь, что твоя концепция многоязычия развалилась.

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

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

ВВ>Ну вот, видишь, как все хорошо получается. C# + F# == отличный ООП и ФП. Так в чем же проблема? Зачем плакать и жрать кактус?

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

ВВ>Назови пример новой технологии, которую изобрела МС.

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

ВВ> Все, что они делали, повторение чужих находок.

А это не важно. Важно, то что все что они не заметили может легко кануть в лету просто потому, что умы тех кто мог бы воспользоваться этими технологиями забиты тем, что впихивают им сильные игроки рынка (вроде МС). К тому же мало иметь хорошую технологию или гениальную идею. Еще нужно завернуть эту технологию или идею в коробку и "продать". Вот это в МС умеют делать на 5 балов. Вот только, как я уже говорил, толкают и заворачивают они далеко не всегда самые перспективные идеи.

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

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

VD>>О, как? А что же в этот список не вошел F#?
VD>>Ты ведь только что его предлагал использовать?

ВВ>Вместо C#, чтобы писать функциональный код. Потихоньку и он внедрится.

ОК. Остается только одни вопрос. А зачем тогда нужен C#?

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

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

ВВ>Очень простая мысль, если задуматься, а не заводить по автоматизму песню про Немерле.

Ага. Только бессмысленная в контексте обсуждаемого вопроса.

VD>>SQL ты предлагаешь по старинке в виде строк в C#-е держать?

ВВ>Ты, видимо, примыкаешь к лагерю, который считает linq2 большим прогрессом?

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

ВВ>У меня вот последние несколько лет основная СУБД Оракл — Linq2 неприменим.

У тебя и ФП не применим. И что? Это твои особенности.

ВВ>Хотя я не против linq2. Непонятно только зачем это вводить в C# по самые помидоры.

Ну, так разберись и поймешь.

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

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

Я тебе уже раз пять говорил. Слово из трех букв.

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

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

И что? наличие ХМЛ-я заставляет тебя писать горы циклов? В чем проблема-то?

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

Горы непроизводительного кода — это к linq2 и к тому что генерят его замечательные провайдеры.

ВВ>>У меня вот последние несколько лет основная СУБД Оракл — Linq2 неприменим.
VD>У тебя и ФП не применим. И что? Это твои особенности.

Откуда ты такой вывод сделал? Может быть, не будешь за меня додумывать?

ВВ>>Хотя я не против linq2. Непонятно только зачем это вводить в C# по самые помидоры.
VD>Ну, так разберись и поймешь.

Непонятно, зачем *вообще* это вводить в шарп. Деревья выражений — одно. Но SQL — пример вполне конкретной прикладной задачи, которая прошита на уровне синтаксиса. Хотя можно было бы обойтись и лямбдами.
Когда решат еще что-нибудь к Шарпу прикрутить — снова синтаксис расширять?

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

ВВ>А какое отношение дженерики имеют к ООП?
Это параметрический полиморфизм. Или он тоже не имеет отношения к ООП?

ВВ>Я использую не языки, а платформу, для того, чтобы создавать продукты, за которые платят деньги. А ты?
И как ты используешь платформу без языков? =)

ВВ>Сейчас, может, и неудобно. А в дотнете, где один бинарник в принципе можно собираться из исходников на разных языках, такую интеграцию при желании можно было бы сделать легко и просто. Выставил в свойствах файлика F# — и вперед с песней.
<...>
ВВ>Ну вот, видишь, как все хорошо получается. C# + F# == отличный ООП и ФП. Так в чем же проблема? Зачем плакать и жрать кактус?
Плакать и жрать кактус — это пытаться решить задачу на нескольких языках, изнурительно интегрируя одно с другим, когда можно обойтись одним. Я не знаю какой степенью просветленности мозга на чистоту языка, или отдаленностью от реальных проблем нужно обладать, чтобы это не было очевидно.

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

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

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

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

VD>Если посмотреть на данный пример, то легко заметить, что психически здоровый человек просто не создаст такую перегрузку в своих классах.

Заведомо нет, а как случайный результат рефакторинга, в котором переименовали какие-нить базовые интерфейсы и включили галочку [переименовать так же все реализации] — запросто.

VD>Другая проблема — это откровенное старение и, как следствие, консерватизм его авторов. Например, они на отрез не хотят принимать идеи паттерн-матчинга или макросов (ака средств расширений языка).

Для паттерн матчинга недостаточно завести одну новую конструкцию языка, для удобного его использования нужны еще конструкции, типа placeholder '_', а это не так просто в плане совместимости с имеющимся кодом. Опять же, паттерн-матчинг должен быть в C# имеративным, или функциональным? Если императивным (ИМХО в ЭТОМ языке — только императивный), то синтаксис утяжеляется обязательным оператором break, как в switch.

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

ВВ>>Старые времена прошли, про КОМ можно забыть, какие проблемы использовать для решения твоей "прикладной задачи" несколько языков?
IB>Это неудобно, понимаешь? Вместо того, чтобы написать пару строк кода одним способом, понять, что не получается и переписать подругому, нужно эту пару строк таскать по разным сборкам и напрягать мозг как эти сборки будут друг с другом взаимодействовать.

Ты и сейчас наверняка пишешь на нескольких языках в рамках одного проекта. Сюда относятся разные языки разметки, DSL-и и прочее. Что, неужели возникает желание *все* это писать на шарпе? Я вот вижу противоположную тенденцию.
А то, что неудобно — так это результат того, что подобный подход не развивается. Все компиляторы под дотнет на выход дают одно и то же. Были же, дай бог памяти, слинкованные .net module или .net assembly. Никто не мешал бы в рамках одного проекта на разных языках писать.

IB>Я хочу решать прикладную задачу, а не думать как проще интегрировать C# в F# и наоборот, мне и SQL-я хватает.

Ты эту задачу всегда один решаешь или еще кто в команде есть?

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

IB>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>А какое отношение дженерики имеют к ООП?
IB>Это параметрический полиморфизм. Или он тоже не имеет отношения к ООП?

Давай так. Есть "параметрический полиморфизм", есть реализация генериков в 3.5. Второе на уровне контрактов только мешает.

ВВ>>Я использую не языки, а платформу, для того, чтобы создавать продукты, за которые платят деньги. А ты?
IB>И как ты используешь платформу без языков? =)

Это откуда ты такой вывод вывод сделал?

ВВ>>Ну вот, видишь, как все хорошо получается. C# + F# == отличный ООП и ФП. Так в чем же проблема? Зачем плакать и жрать кактус?
IB>Плакать и жрать кактус — это пытаться решить задачу на нескольких языках, изнурительно интегрируя одно с другим, когда можно обойтись одним. Я не знаю какой степенью просветленности мозга на чистоту языка, или отдаленностью от реальных проблем нужно обладать, чтобы это не было очевидно.

Реальная проблема — это какая? Можешь описать? Вот есть проект, не очень большой, на пару тысяч человекочасов. Над ним как работать надо? Берем язык-всемогутер (один штука) и гуру-девелопер (один штука). Гуру-девелопер, размахивая языком-всемогутером, начинает работать и спустя всего-то шесть лет — вуаля! — проект готов причем сделан с охрененным качеством. Клиент плачет от радости.

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

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

VD>>А как хорошо ты знаешь другие языки? И где ты применяешь их на практике?

Ну, минимальный джентельменский набор сегодня: XML/HTML/JavaScript/SQL/VBA/[ASP.Net/php/JSP и пр. на выбор]/C++/C#/Java/IDL
Это то, что у многих на практике регулярно.

Для внутренних утилит обычно используются "любимчики", у каждого свои, напр Forth/Lisp-Scheme/SmallTalk/ML-family/SH-family/Make-family/Phyton-Ruby-family и т.д.

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

ВВ>Горы непроизводительного кода — это к linq2 и к тому что генерят его замечательные провайдеры.

Для простых запросов вполне там нормально все генерится, а сложные все-равно должны быть как процедуры прямо в твоем Оракле, а не в коде C#.
Или ты имеешь ввиду, что сама технология генерации строки-запроса не столь быстра как конкатенация строк? Ну это смешно совершенно, ибо затраты на обработку запроса, и затем парсинг сообщения-ответа DB-провайдером на клиентской стороне куда как более затратны, чем генерация SQL по LINQ expression.


ВВ>Когда решат еще что-нибудь к Шарпу прикрутить — снова синтаксис расширять?

Конечно.

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

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

ВВ> Что, неужели возникает желание *все* это писать на шарпе?
Да. Не обязательно на шарпе, но желательно на одном языке.

ВВ> Я вот вижу противоположную тенденцию.
Где?

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

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

ВВ>Ты эту задачу всегда один решаешь или еще кто в команде есть?
В команде дофига народу, но к делу это не относится.

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

V> Никто не мешает делать REP на разных языках, ИМХО, это даже полезно.
Чем?

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

ВВ>>Давай так. Есть "параметрический полиморфизм",
IB>То есть генерики все таки нужны? Ты уж определись.

А ты читать научись.

ВВ>> есть реализация генериков в 3.5. Второе на уровне контрактов только мешает.
IB>Чем?

Подумай, может сам поймешь.

ВВ>>Это откуда ты такой вывод вывод сделал?
IB>Из твоего заявления, что ты пользуешься не языками, а платформой.
ВВ>> Берем язык-всемогутер (один штука) и гуру-девелопер (один штука). Гуру-девелопер, размахивая языком-всемогутером, начинает работать и спустя всего-то шесть лет — вуаля! — проект готов причем сделан с охрененным качеством. Клиент плачет от радости.
IB>Ты с темы не съезжай, не нужно переводить стрелки с одного языка на одного девелопера.

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

ВВ>>Реальная проблема — это согнать на такой проект человек десять. Разделить задачи. Сделать так, чтобы эти люди работали параллельно и не мешали друг другу. И каждый будет заниматься своей, отдельной задачей, а от языка всемогутера пользы будет мало.
IB>И как ты собрался разделять задачи, если языки разные? И как у тебя разработчики общаться будут и соседский код смотреть, если там язык другой? Ты прям в какой-то другой реальности живешь.

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

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

V>Заведомо нет, а как случайный результат рефакторинга, в котором переименовали какие-нить базовые интерфейсы и включили галочку [переименовать так же все реализации] — запросто.

Рефактринг в принципе штука опасная и для того чтобы быть уверенным в том, что он прошел корректно все равно нужно иметь много юнит-тестов. Они то и должны выявить подобную и другие проблемы.

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

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

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

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

V>Опять же, паттерн-матчинг должен быть в C# имеративным, или функциональным?

А switch в C# императивный или функциональный? Так вот паттерн-матчинг — это тоже всего лишь оператор. Конечно, очень желательно, чтобы он был выражением (мок использоваться внутри выражений), но и statment пошел бы на худой конец.

V>Если императивным (ИМХО в ЭТОМ языке — только императивный), то синтаксис утяжеляется обязательным оператором break, как в switch.

Да синтаксис вообще можно оставить switch-ый просто расширв его. Хотя конечно было бы намного удобнее и проще для понимания просто ввести новый оператор аналогичный match в Nemerle. Тем более, что все аспекты его реализации уже отлично проработаны.

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

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

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

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

ВВ>Что делать? Очень просто. Для начала в "консерватории" надо что-то поправить, а не создавать модель с ОО системой типов, которую удобнее всего обрабатывать через ПМ.
Хорошо, давай посмотрим, что у тебя с консерваторией.
Я правильно понимаю, что твой поинт состоит в том, что модель для работы с которой лучше всего подошел бы ПМ — не является true ООП конструкцией и ее надо переделывать по другому? =)
Давай конкретизируем — какую модель ты предложишь, например, для AST, и как будешь с ней работать?

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

ВВ>>А ты читать научись.
IB><...>
ВВ>>Подумай, может сам поймешь.
IB>Блестящая аргументация, коллега, по делу есть что сказать? )

Я очевидные вещи не разжевываю. Как и не повторяю то, что было написано раньше.

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

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

ВВ>> И какому-нибудь веб-девелоперу не фиг вообще нос совать в код БД. А ты, видимо, в какой-то другой другой реальности живешь.
IB>Я живу в той реальности, в которой веб-разработчик (не путать с верстальщиком), обязан знать что делать с БД, так как сайты без БД, в наше время, вряд ли имеют практическую ценность. И даже в том редком случае, когда этому разработчику нет нужды самому писать запросы, он должен иметь представление и практические навыки в том как это все работает, чтобы адекватно выполнять свою часть работы.

Выделенное говорит об отсутствии мало-мальской специализации и полноценного разделения труда на твоих проектах. На практике это означает, что "универсальные специалисты" не является по-настоящему хорошими специалистами ни в одной из областей, где они работают. Итоговое качество получается соответствующим. И гордиться тут совершенно нечем.
Веб-разработчик должен знать свое ТЗ и тот слой, с которым он напрямую работает. И у нормальных людей — это не СУБД.

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

IB>Давай конкретизируем — какую модель ты предложишь, например, для AST, и как будешь с ней работать?

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

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

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

ВВ>Мне вообще удобно не писать.
Это я заметил )

ВВ> А разные части проекта *по факту* пишутся на разных языках разными людьми.
У тебя есть идеи, как они договариваются о том, что должно получиться в итоге? )

ВВ>Выделенное говорит об отсутствии мало-мальской специализации и полноценного разделения труда на твоих проектах. На практике это означает, что "универсальные специалисты" не является по-настоящему хорошими специалистами ни в одной из областей, где они работают. Итоговое качество получается соответствующим. И гордиться тут совершенно нечем.
ВВ>Веб-разработчик должен знать свое ТЗ и тот слой, с которым он напрямую работает. И у нормальных людей — это не СУБД.

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

ВВ>>Я очевидные вещи не разжевываю. Как и не повторяю то, что было написано раньше.
IB>Так и запишем — на прямо поставленный вопрос не знает что ответить и по этому начинает хамить. )

Записывай что хочешь. Мне тему "генерики и ООП дизайн" конкретно с тобой обсуждать неинтересно.

ВВ>> А разные части проекта *по факту* пишутся на разных языках разными людьми.
IB>У тебя есть идеи, как они договариваются о том, что должно получиться в итоге? )

А у тебя есть вообще представление о том, как люди в проекте работают? Или ты проект на 2 тыс. человекочасов шесть лет делать собираешься? Или все десять человек у тебя будут и в базе ковыряться, в вебе, и в бизнесе? Есть идеи о том, как такой проект не превратить в помойку?
Судя по тому, что ты пишешь и по истерической реакции (см. ниже) — нет.

ВВ>>Выделенное говорит об отсутствии мало-мальской специализации и полноценного разделения труда на твоих проектах. На практике это означает, что "универсальные специалисты" не является по-настоящему хорошими специалистами ни в одной из областей, где они работают. Итоговое качество получается соответствующим. И гордиться тут совершенно нечем.
ВВ>>Веб-разработчик должен знать свое ТЗ и тот слой, с которым он напрямую работает. И у нормальных людей — это не СУБД.
IB>

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

ВВ>>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо.
IB>Чем слабо? Тем что там нет ПМ? =)

Вообще-то как раз наоборот.

IB>Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП. И что делать?

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

ВВ>>Если AST в рамках конкретной задачи — это цель, и проектировать ее надо, исходя из этой конкретной задачи, а не рассуждать о сферических конях в вакууме.
IB>Вот ты и не рассуждай, а спроектируй.

Универсальное АСТ для неизвестной задачи?

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

В>Это на каком языке было?

F#:

open System
.
.
.

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

Неудобные вопросы ты по прежнему игнорируешь? )

ВВ>Вообще-то как раз наоборот.
Что наоборот?

ВВ> То, как ты лично собираешься использовать АСТ, ты не сказал, а догадываться мне не хочется.
То есть, ты не сталкивался с задачами, где нужны модели типа AST?

ВВ>Универсальное АСТ для неизвестной задачи?
Ну, например, для задачи рефакторинга и подсветки в редакторе.

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

ВВ>Ты и сейчас наверняка пишешь на нескольких языках в рамках одного проекта. Сюда относятся разные языки разметки, DSL-и и прочее.

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

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

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

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

ВВ>Что, неужели возникает желание *все* это писать на шарпе?

Почему обязательно на шарпе? Те кто боится брать языки вышедшие не из под пера МС, конечно предпочитают Шарп. Возможно через некоторое время будут предпочитать F#, как более мощный язык. Ну, а остальные вольны выбирать то что хотят. Лично я выбираю Nemerle, как объективно более мощный по сравнению с C# или F# язык. Но это все равно один язык. Потому как два неудобно.

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

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

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

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

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

V>А как же популярность Явы?

А что в Яве нет дженириков или она вообще не изменялась за время существования?
Ява 1.0 действительно мало для чего серьезного пригодна.

V>Мы когда смотрели ее спецификации в 95-м, тоже ухахатывались, за животы держались.. а оно вон как вышло, кто бы мог подумать.

А ты сравни эту спецификацию со спецификацией современной. К тому же в лагере явы тоже не стоят на месте. Там уже есть такие языки как Clojur, Groovy и конечно же Scala!

V>Именно, только в конце приписать надо "для каждой конкретной задачи". Чем более специализирован язык, тем он проще и тем сложнее ошибиться программисту.

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

По твоему, скажем, F# более специализированный нежели C#? Или как понять твои слова?

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

ВВ>>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо.
IB>Чем слабо? Тем что там нет ПМ? =) Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП. И что делать?

Отличный пример, кстати!

С одной стороны ты не прав. Таки да, АСТ удобнее описывать с помощью Алгебраических Типов Данных.
Но вот сам код лексера, парсера, типизатора и генератора кода удобнее оформить в виде тех самых классов. И было бы крайне глупо из-за этого писать компилятор на двух ЯПОН.

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

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

В>Это на каком языке было?

Лучше не так...

- Папа! Что это было?!

Ладно, я как провокатор офтопика предлагаю закрыть эту подтему.

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

V>Для паттерн матчинга недостаточно завести одну новую конструкцию языка, для удобного его использования нужны еще конструкции, типа placeholder '_', а это не так просто в плане совместимости с имеющимся кодом

Это как раз ерунда. Куда сложнее с тем, что для полноценного PM нужны discriminated unions. А это уже сильное нелокальное изменение языка. Для чего нужна глобальная маркетологическая идея. Так что, ИМХО, не в этой жизни.

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

VD>С одной стороны ты не прав. Таки да, АСТ удобнее описывать с помощью Алгебраических Типов Данных.

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

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

AVK> Так что, ИМХО, не в этой жизни.
Ну, мы примерно знаем когда..

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

VD>>С одной стороны ты не прав. Таки да, АСТ удобнее описывать с помощью Алгебраических Типов Данных.

AVK>Алгебраический тип данных и ПМ сами по себе ортогональны ФП. Другое дело что в ФП без них вилы, а вот в ООП как то жить можно.

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

Ну, и то что ПМ не является неотъемлемой частью ФП никак не умаляет полезности этой фичи в конкретном языке. Так что, если язык не поддерживает ПМ, то делать на нем компиляторы существенно сложнее нежели на языке поддерживающем эту фичу.

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

AVK>> Так что, ИМХО, не в этой жизни.
IB>Ну, мы примерно знаем когда..

Только оценку снизу

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

AVK>Это как раз ерунда. Куда сложнее с тем, что для полноценного PM нужны discriminated unions.

"discriminated unions" — это локальный для ML-я псевдоним для алгебраический типов данных.

AVK>А это уже сильное нелокальное изменение языка. Для чего нужна глобальная маркетологическая идея. Так что, ИМХО, не в этой жизни.

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

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

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

AVK>Ну, с Лиспом отдельный разговор.

Это с какой это стати? Лисп — прародитель всех ФЯ. Функциональный по духу и по букве. Если честно, то лисп

VD>>Ну, и то что ПМ не является неотъемлемой частью ФП никак не умаляет полезности этой фичи в конкретном языке.

AVK>Конечно нет. Я про другое — ПМ + discriminated unions, если отбросить исторические корни, можно с равным правом отнести кака к ООП, так и к ФП, и совершенно непонятно, почему в ФП языках он уместен, а в ООП уже лишний.

Это миф который сложился исторически. Разработан ПМ был в ФЯ и пол влиянием мат. моделей вытекающих из ФЯ, вот многие и считают ПМ чисто функциональной фичей.

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

VD>"discriminated unions" — это локальный для ML-я псевдоним для алгебраический типов данных.

Я в курсе

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

VD>Не стоит строить логику на подмене понятий. Использование разных ДСЛ-ей и использование разных языков программирования общего назначения (ЯПОН) — это очень разные вещи.

Почему? Может, от того и проблема?

VD>Кроме того, ДСЛ-и удобны, в основном, когда они встроены в какой-то базовый ЯПОН.

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

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


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

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

Нууу... с позиции активного пользователя языка с развитой макросистемой, ты конечно можешь себе позволить поострить. Но в ситуации, когда никто разрешение на использование Nemerle не даст, даже для разработки внутреннего инструментария, приходится пользовать DSL. Спросишь, кого интересует, на чем пишутся внутренние тулзы? Интересует заказчика, если он заказывает разработку, с условием передачи всех относящихся к ней исходников (очень популярный сценарий в заказной разработке). Он примет C/C++/Java/C#/JavaScript/XML и остальные распространенные вещи, а про существование N он даже не в курсе.

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

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

Могу лишь предположить, что у тебя узкоспециализированные задачи, раз не было подобного опыта. Мне приходилось завязывать C++/CLI — для нормальной интеграции C++ных библиотек, C# для основного кода, VB.Net — идеален для задач автоматизации офиса (кто делает это в C#, у того или задачи по офису микроскопические, или нуб, без обид ). Если еще вспомнить, что в .Net интероперабельность с COM тоже "как родная", то иногда обхожусь без C++/CLI, ибо последний требует включать в click-once MS VC рантайм, что можно избежать в случае COM.

V>>Универсальный язык не может быть хорошим для всех задач, он будет одинаково посредственнен.
IB>Проблема в том, что неуниверсальный язык — непригоден вообще.

IDL непригоден? JavaScript, ShellScript, XSLT, ASN.1? Свой domain-specific конфиг на JSON непригоден? Будем считать — погорячился.

IB>Вот-вот, Ява намного удобнее C++,

Ява удобнее только наличием GC, во всем остальном она достигла уровня не далее Objective C, тут даже смешно c C++ сравнивать.

IB>однако как только в C# появились генерики и парочка других вкусностей,

Да, генерики, делегаты и yield — это мегафичи, но это мы что-то пошли в сторону... в которой бывали уже раз сто.

IB>Угу. Вернемся к тому, что есть у меня конкретная задача и часть задачи удобно решать на ООП, а часть ФП, какой язык тут удобен? Ну вот например, есть у меня отличное дерево объектов в C#, но засада — для правильного и красивого вызова нужного метода у нужного экземпляра отлично подошел бы ПМ.
IB>Твои действия:
IB>- Городить визитор ?
IB>- Писать на F# функцию ресолвинга ?
IB>- Ручное выпиливание по тайпкастам ифам и свичам ?

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


V>>Чем более специализирован язык, тем он проще и тем сложнее ошибиться программисту.
IB>Я не вижу практической пользы от заточки языка исключительно на ООП или ФП. И практика показывает, что ни один чистый ООП или ФП язык не оказался пригодным для решения большинства типичных задачь.

Да ладно, до Явы и дотнета были Дельфи и VB/VBA, которые по количеству приложений на них затыкали всех за пояс (VB у них, Дельфи у нас). Это же были основные инструменты для бизнес-приложений. Эти и несколько других, долгое время тоже весьма популярных, типа FoxPro, 1С и т.д. тоже не особо ФП похвастать могут. Так что и тут ты погорячился.

Да, среда .Net избавила от опасности неверной реинтерпретации памятию, от ее утечки и т.д. И эти бенефиты конечно крутые, но только в сравнении с нативными "универсалами", типа С/С++. И это все равно не повысило надежность программ на C# до уровня программам на VB, FoxPro, 1C автоматически. Программы на C# до сих пор сыпятся как семечки, достаточно пройтись по тому же codeproject. Видел ли ты хоть раз, чтобы так же сыпались программы на вышеупомянутой тройке? То-то...

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


IB>Вернемся к предыдущему примеру — мне очевидно, надеюсь и тебе тоже, что при наличии ПМ в C#, данная задача решалась бы существенно проще, и с меньшей вероятностью совершить ошибку, чем любая из доступных сейчас альтернатив.

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

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

ВВ>>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо.
IB>Чем слабо? Тем что там нет ПМ? =) Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП.

Какие глупости пишешь...
AST — это идеальная задача для алгебраических типов данных, которые ты эмулируешь иерархией наследования в ООП (точно так же, как реализованы алгебраические типы в Nemerle, только тут ты "ручками"). Понимаешь, случай с AST как раз тот самый, когда соверешенно не получается породить гомоморфную иерархию, и мадам Лисков идет таким лесом, что дальше просто не куда... а значит о чистом ООП можно даже не заикаться. Не, постараться конечно можно.. но мозги закипят, и будет результат негибок и не особо расширяем. Здесь такой ООП-инструмент как наследование ты используешь именно как отдельный инструмент, за неимением другого, в отрыве от ООП-"парадигмы".

Сам по себе матчинг по типам (!!!) противен духу ООП (а только по значениям это будет недоматчинг). На уроках по ООП за это ставят двойки, поэтому не все так просто и поэтому не так просто внести в чистую ООП-среду ФП заморочки. Первоначально сделали ОГРОМНУЮ ошибку, повторив ее за Java, впечатав ООП в саму платформу, а не отдав на откуп языкам. Мы тут обсуждали несколько лет назад, если помнишь, почему бы в C# не сделать конструкцию, типа switch, но не по значениям, а по типам. Ты хоть представляешь, что сделал бы с Хейлсбергом научный мир IT за такие фокусы? Да разорвал бы как тузик грелку, опустил бы ниже плинтуса.

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

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

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

ВВ>>>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо.
IB>>Чем слабо? Тем что там нет ПМ? =) Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП. И что делать?

VD>Отличный пример, кстати!

VD>С одной стороны ты не прав. Таки да, АСТ удобнее описывать с помощью Алгебраических Типов Данных.
VD>Но вот сам код лексера, парсера, типизатора и генератора кода удобнее оформить в виде тех самых классов.

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

А в виде классов, или глобальный ф-ий или последовательности слов — вообще непринципиально.


VD>И было бы крайне глупо из-за этого писать компилятор на двух ЯПОН.

Я пять насчитал. На двух действительно глупо.

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

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

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

VD>>Не стоит строить логику на подмене понятий. Использование разных ДСЛ-ей и использование разных языков программирования общего назначения (ЯПОН) — это очень разные вещи.

V>Почему? Может, от того и проблема?

Разберись, напиши статью.

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

В тебя какое-то свое определение ДСЛ-ей. ДСЛ — это язык прикладной области, а не ограниченый ЯПОН. Может от того ты и споры эти разводишь...

V>
V>Как раз-таки в своей специализированной задаче DSL вовсе не "маломощный", собсно, затем он и нужен, чтобы предоставить "мощные" ср-ва для решения конкретной задачи.

Про ДСЛи я уже говорил. Иди прочти определение этого термина и сравни его с определением ЯПОН.

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

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

Вообще-то с вами не согласны AVK и IB. Они, мягко говоря, Немерл не используют.

V>Но в ситуации, когда никто разрешение на использование Nemerle не даст, даже для разработки внутреннего инструментария, приходится пользовать DSL.

Некорректное противопоставление. Немерле не заменяет DSL-и. Он, наоборот, упрощает их разработку и поощряет их использование.

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

V> Спросишь, кого интересует, на чем пишутся внутренние тулзы?

Мне по фигу. Лично я пишу их (вот уже 2 года) на Немерле. Следующая версия шаблона для верстки статей для РСДН-а та же на Немерле пишется. И я не одинок. Так что процесс потихонечку пошел.

V>Интересует заказчика, если он заказывает разработку, с условием передачи всех относящихся к ней исходников (очень популярный сценарий в заказной разработке). Он примет C/C++/Java/C#/JavaScript/XML и остальные распространенные вещи, а про существование N он даже не в курсе.

Ну, не все же так действуют? Кое кто и ПО продает, а не его исходники.

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

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

V>>Для паттерн матчинга недостаточно завести одну новую конструкцию языка, для удобного его использования нужны еще конструкции, типа placeholder '_', а это не так просто в плане совместимости с имеющимся кодом

AVK>Это как раз ерунда.

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

AVK>Куда сложнее с тем, что для полноценного PM нужны discriminated unions. А это уже сильное нелокальное изменение языка. Для чего нужна глобальная маркетологическая идея. Так что, ИМХО, не в этой жизни.

Мне показалось, что предполагается сделать как в Scala — матчить по типам и св-вам, и вот относительно первого повысказывался негативно тут рядом.

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

AVK>>Это как раз ерунда. Куда сложнее с тем, что для полноценного PM нужны discriminated unions.

VD>"discriminated unions" — это локальный для ML-я псевдоним для алгебраический типов данных.

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

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

V>В каждой методологии есть свои практики, которые позволяют писать достаточно надежные программы. Смешение практик приведет только к ухудшению надежности, в этом плане thesz категорически прав. Или же, (а почему бы и нет?) настало время для выработки новых практик для этой сборной солянки... В любом случае должно пройти достаточное время, больше чем кажется, ибо даже пока научных работ на эту тему не видно.

Настало. И есть не только научные работы, но и аж 3 современных полнофункцональных реализации гибридных языков (Nemerle, Scala и F#) и это если не считать, что даже C# стал почти функциональным.

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

V>>Вот именно, из детерминированного и элегантного языка превращается в непонятно что.

VD>Во как? Где это тут что-то куда-то превращается?

Элегантность была в однозначности конструкций. Это ушло.


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

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

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

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

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

V>Вот и нет:
V>- лексер удобнее всего табличный на голом С, полученный из регулярной грамматики (не та, что перловая, а та, что класс грамматик);

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

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

V>- парсер комбинаторный на любом ФП с обобщенными типами и явными их инстанциированиями;

Опять же все не совсем так. От парсеров может требоваться парсить код отдельных конструкций и работать в ленивом режиме. Любой ФЯ (ФП — это описка ведь?) тут не прокатит. Хаскель наверно справитя, но что-то решения на хаскеле мне кажутся далекими от прсотых.
К тому же комбинаторый парсер — это тормоз. Но это уже дело десятое.

V>- типизатор — однозначно логический, на прологе или чем-то похожем, ибо задача из области баз знаний и поиска решений (взаимно-рекурсивные альфа/бета редукции);

Да ну? О как? А пролог мы будем из комндной строки вызвать? Вот в Немерле Пролог, точнее подсистема унификации выделена в отдельный объект (класс). Получается очень удобно.

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

Вот незадача. Но код то нужно генерировать средствами SRE. А он имеет объектный интерфейс. Облом, да?

Можно узнать сколько компиляторов ты создал описанным тобой образом?

V>А в виде классов, или глобальный ф-ий или последовательности слов — вообще непринципиально.

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

Так что свои сказки про ФП-ДСЛ-и оставьте при себе.

VD>>И было бы крайне глупо из-за этого писать компилятор на двух ЯПОН.

V>Я пять насчитал. На двух действительно глупо.

Это что же за язык написан на пяти языках?

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

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

Меня умиляют эти доморощенные теоретики путающие ДСЛ и ЯПОН, но с высоко задранной головой советующие окружающим чем им заняться и чему научиться.

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

Ну, и за одно продолжайте нести эту чушь оправдывая применение в одном проекте 25 языков общего назначения вроде C# и F# тем, что ДСЛ-и для некоторых задач рулят. Это конечно глупо, но если глупость повторять много раз с умным выражением лица, то многие могут в нее поверят.

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

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

AVK>>Я про другое — ПМ + discriminated unions, если отбросить исторические корни, можно с равным правом отнести кака к ООП, так и к ФП, и совершенно непонятно, почему в ФП языках он уместен, а в ООП уже лишний.

V>Из-за принципа подстановки Лисков. Т.е., если ввести в язык алгебраические типы ака размеченные объединения, и они будут стоять где-то сбоку от ООП-возможностей языка — то можно, если же начнется наследование по ним наследование, напр. размеченные объединения будут представлять из себя иерархию классов (как в Nemerle), то получаем потенциальное нарушение инвариантов базового класса. Крайне неприятная мина в коде.

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

АлгТД и ПМ по духу принципам Лисковой не противоречат. По букве, да. Но букву можно и подправить.

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

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

Именно.

VD>Иначе таки, нет — универсальный язык таки может быть лучше для всех задач чет другой универсальный язык.

Наверно хотел сказать "чем другой неуниверсальный"? Согласен, банальность.


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

VB 6.0 более низкоуровневый, чем С/С++? Однако, он генерит гораздо лучший код для работы с COM-объектами, эффективно удаляя лишние пары AddRef/Release и лишние QueryInterface (если замечено преобразование к базе, или к тому же типу), чего не могут делать люди ни вручную, ни с помощью разных com_ptr<>. Так же автоматически кеширует для типов результаты вызовов методов IDispatch при динамическом запросе DISPID и прочее, прочее, прочее. В общем, специализированный тул, он и в Африке специализированный. (Кстати, он и обычную арифметику и все внутренние вызовы тоже неплохо оптимизирует, не намного хуже С/С++, на нем еще те числобробилки делать можно, и удобнее гораздо)


V>>А как же популярность Явы?

VD>А что в Яве нет дженириков или она вообще не изменялась за время существования?
VD>Ява 1.0 действительно мало для чего серьезного пригодна.

V>>Мы когда смотрели ее спецификации в 95-м, тоже ухахатывались, за животы держались.. а оно вон как вышло, кто бы мог подумать.

VD>А ты сравни эту спецификацию со спецификацией современной.

Разбежался.
До второго дотнета там ничего в плане языка не происходило, т.е. десяток лет застоя и все её хвалили. Надо было раньше шевелиться.


VD>К тому же в лагере явы тоже не стоят на месте. Там уже есть такие языки как Clojur, Groovy и конечно же Scala!

Спустя 15 лет существования платформы что-то есть в бета-версиях. Несомненный успех.


V>>Именно, только в конце приписать надо "для каждой конкретной задачи". Чем более специализирован язык, тем он проще и тем сложнее ошибиться программисту.

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

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


VD>По твоему, скажем, F# более специализированный нежели C#? Или как понять твои слова?

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

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

V>Элегантность была в однозначности конструкций. Это ушло.

Ты высосал ее из пальца. Подобные проблемы были в шаре всегда.

V>Нет, спецификации и правила ресолвинга сигнатур ф-ий постоянно добавляются.

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

V>У нас после перехода с 2.0 на 3.5 все прекрасно скомпилировалось без ошибок, но программа стала падать, из-за этих самых изменений. И что бесит, ни варнингов, ни ошибок — ничего. Аналогичный этюд про перегрузку Ников привел примерно год спустя, до этого кому не показывал код — все тоже были поражены, насколько неочевидно, и "втихую" все происходит по новым спецификациям.

Сдается мне ты выдумываешь. Да... и 2.0 и 3.5 — это ведь не версии C#, правда?

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

Ну, то есть проблема была в библиотеке?

Покажи что изменилсь в Шарпе, что привело к проблеме.

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

VD>>Иначе таки, нет — универсальный язык таки может быть лучше для всех задач чет другой универсальный язык.

V>Наверно хотел сказать "чем другой неуниверсальный"? Согласен, банальность.

Нет. Что хотел, то и сказал. А ты просто в софистике упражняешься.

V>Просто есть уже отработанный метод относительно безопасного получения "мощности" языка для специальных задач. Надеюсь, понятие "мощности" применимое к ЯП для всех присутствующих означает степень его выразительности, т.е. мы об одном и том же?

ОК.

Излагай свою теорию по поводу того почему лучше использовать два маломощьных ЯПОН-а, а не один более мощный.

В такой терминологии обсуждение смысла не лишено. Но, плиз, больше не упоминай ДСЛ-и. Иначе твой слив будет засчитан в автоматическом режиме. ОК?

VD>>По твоему, скажем, F# более специализированный нежели C#? Или как понять твои слова?

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

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

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

V>Просто до сих пор все изменения зыка были не ломающими предыдущий код.

Не все. Как минимум были изменения overload resolution, которые могли потенциально старый код сломать.

V>Мне показалось, что предполагается сделать как в Scala — матчить по типам

Конструкция typeswitch возможно когда нибудь и появится.

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

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

Хм, не могу разглашать источники информации, но оптимальным размером сборки является 300Кб-3Мб.

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

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

Ты там выше, очень верно заметил, что не смотря на то, что лучше SQL-я для БД ничего не придумали, на лицо явная тенденция перетащить сиквельную часть в C#. Потому что удобно делать все в одном языке, а не в специализированых.