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

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

Единственый факт заключаетсая в том, что и ты, и я, и ИТ использовали и используем разные мелкие и не очень ДСЛ-и в своих проектах. За неимением качественных средств их создания и отладки мы используем разные мало приспособленные для этого вещи. Лично ты, например, используешь ХСЛТ. ИТ вообще до Эмита докатился.

То есть потребность есть. И ответ орла из МС кроме как отмазкой назвать нельзя.

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

IT>Язык должен меняться не под людей, а под задачу. Меняется задача — меняется/настраивается язык.

Я не про это спрашивал. Я про другое — считаешь ли ты допустимым вне контекста Nemerle, сменить для команды, писавшей пару лет на C#, язык на Java, только потому что есть ряд библиотек на ней, которые будут удобны в текущем проекте?

IT>Для меня решающий фактор один — простота конечного прикладного кода.

Это многофакторный параметр.

IT>И вижу, что это может продолжить линейку развития структурное программирование -> ООП -> компонентное программирование -> метапрограммирование.

Олично. А я не вижу. Ты считаешь, что правда за тобой?

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

GZ>Совсем без каких либо оптимизаций хотя бы на уровне expression lambda.

Кто такой expression lambda и о каких оптимизациях речь?

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

Ссылку в студию, где я этим возмущался. Я лично не вижу в этом особой нужды.

AVK>>и type inference
GZ>Тоже Влад тут уже возмущался. Недоделанный какой-то.

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

AVK>>(совсем не половинки) в сухом остатке наличествуют.
GZ>Так что IMHO недоделочки все это.

Ну, таким манером недоделками можно назвать что угодно.

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

AVK>>В программировании это совсем нечастая ситуация.

VD>Ты меня пугашь.

А я то тут при чем? Не я придумал этот мир.

AVK>>Влад, я не являюсь его (Nemerle) фанатом

VD>Я вообще фанатом не являюсь.

Извини, но когда 100% топиков в философии с твоим участием превращаются в обсуждение Nemerle, других выводов я сделать не могу.

AVK>>и у меня не было никакого желания заниматься PR, подобным тому что занимаешься ты.

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

Уж если проект получил грант от МС, то уж знают о нем они наверняка, не переживай.

AVK>> Если тебе кажется что это способно принести хоть какую то пользу, ты можешь написать ему на e-mail все что хочешь.

VD>Ну, кинь мыло... попробую как-нить на досуге черкнуть...

http://blogs.msdn.com/lukeh/contact.aspx

AVK>> Лично меня этот вопрос не интересует. Я и про макросы то спросил исключительно потому что ты очень желал услышать ответ.

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

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

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

AVK>Я не про это спрашивал. Я про другое — считаешь ли ты допустимым вне контекста Nemerle, сменить для команды, писавшей пару лет на C#, язык на Java, только потому что есть ряд библиотек на ней, которые будут удобны в текущем проекте?
Ты подменил вопрос с "немного изменить язык под задачу" на "сменить платформу".
Первое болие чем реально, а второе несколько болие проблематично но тоже реально оссбенно если библиотеки реально сократят сроки разработки.

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

AVK>Извини, но когда 100% топиков в философии с твоим участием превращаются в обсуждение Nemerle, других выводов я сделать не могу.

100% твоих сообщений о дотнете и МС. Делаем выводы о твоем фанатизме?

Сейчас мне интересна тема Немерла. Только и всего.

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

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

AVK>Уж если проект получил грант от МС, то уж знают о нем они наверняка, не переживай.

Зная размеры МС не удивлюсь тому, что одна рука не знает, что делает другая.

Но дело не в этом. Меня интересует их мысли по поводу этого языка.

AVK>http://blogs.msdn.com/lukeh/contact.aspx

Думаешь он ответит на вопрос заданный незнамо кем?

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

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

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

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

AVK>>>и type inference
GZ>>Тоже Влад тут уже возмущался. Недоделанный какой-то.

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

Почему же в конце то? А то, что в C# 3.0 при инициализации коллекций вывод типов может делаться очень далеко от самого объявления — это тоже прблема?

AVK>>>(совсем не половинки) в сухом остатке наличествуют.
GZ>>Так что IMHO недоделочки все это.

AVK>Ну, таким манером недоделками можно назвать что угодно.

Анонимные типы никак по другому язык не поворачивается назвать. А ведь все что нужно сделать — это создать синтаксис декларации анонимного типа и средства для распаковки анонимного объекта. Смотри насколько это интуитивно выклядит в паре с достойным выводом типов:

GetData(id : int) : IEnumeramle<string * string>
{
    ExecuteReaderLoop ("SELECT firstname, lastname FROM employee WHERE firstname = $id", dbcon,
    {
        yield (firstname, lastname);
    });
}
...
foreach ((firstname, lastname) in GetData(1))
    WriteLine($"First name: $firstname  Last name: $lastname");

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

IT>И вижу, что это может продолжить линейку развития структурное программирование -> ООП -> компонентное программирование -> метапрограммирование.

Подумалось. Наверно не верно ставить их в линейку. Это технологии которые прекрасно дург с другом совмещаются. Так что стрелочки могут определять не равитие а последовательность появлений. А линейка развития должна выглядить так:
структурное программирование
+ ООП
+ компонентное программирование
+ метапрограммирование

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

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

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

AVK>>Я не про это спрашивал. Я про другое — считаешь ли ты допустимым вне контекста Nemerle, сменить для команды, писавшей пару лет на C#, язык на Java, только потому что есть ряд библиотек на ней, которые будут удобны в текущем проекте?
WH>Ты подменил вопрос с "немного изменить язык под задачу" на "сменить платформу".

Я не подменял. Я первого вопроса никогда не задавал.

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

VD>Почему же в конце то? А то, что в C# 3.0 при инициализации коллекций вывод типов может делаться очень далеко от самого объявления — это тоже прблема?

Далеко? По моему там все ограничено одним выражением.

AVK>>Ну, таким манером недоделками можно назвать что угодно.

VD>Анонимные типы никак по другому язык не поворачивается назвать.

Влад, ты внимательно читал мои сообщения? Судя по всему нет.

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

AVK>>Извини, но когда 100% топиков в философии с твоим участием превращаются в обсуждение Nemerle, других выводов я сделать не могу.

VD>100% твоих сообщений о дотнете и МС. Делаем выводы о твоем фанатизме?

Нет, делаем выводы о твоей правдивости.
И, собственно, речь не о том, что чьи то сообщения о чем то, а о том что любой вопрос ты превращаешь в обсуждение Nemerle. Помнишь как СГ на каждый вопрос находил единственный ответ — Oberon. Ты сейчас делаешь тоже самое.
Вобщем неважно. Важно другое — лично я не испытываю жуткого интереса к Nemerle, чтобы спрашивать о нем всегда и везде. Да и не только спрашивать, потому что собственно я вопроса пока даже не услышал, а агитировать за него.

VD>Сейчас мне интересна тема Немерла. Только и всего.

А мне нет, только и всего.

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

Ты неверно воспринял исходный топик. Это не обсуждение твоей личности, это скорее обсуждение моей личности.

AVK>>http://blogs.msdn.com/lukeh/contact.aspx

VD>Думаешь он ответит на вопрос заданный незнамо кем?

Тогда пиши мне, я попытаюсь переправить.

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

VD>Причем тут "Nemerle восхитителен"?

Ну а какой бы ответ тебя устроил, кроме абсолютно положительного?

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

На этот вопрос ты ответ получил — технических причин нет или они, по крайней мере, не основные.

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

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

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

VD>Если ты о С++/CLI, то это явно не то что нужно нам.
Ну да. Надо же потом будет как-то в глаза ПК смотреть

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

WH>>Ты подменил вопрос с "немного изменить язык под задачу" на "сменить платформу".
AVK>Я не подменял. Я первого вопроса никогда не задавал.

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

А это что за вопрос?

К томуже тут нужно говорить не о смене языка, а о настройке языка для некоторых задач. А в большинстве случаев Nemerle со стандартными макросами будет работать болие чем нормально. Но в некоторых случаях когда жареный петух... Например помнишь то попадалово с с реализацией иерархии контролов? Там макросы Nemerle решили бы все проблемы.
А Гашиш Кумарам не важно инидйского или местного разлива писать или использовать левые макросы можно просто запретить.

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

WH>>>Ты подменил вопрос с "немного изменить язык под задачу" на "сменить платформу".
AVK>>Я не подменял. Я первого вопроса никогда не задавал.
WH>

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

Ну и? Где там про "немного изменить"? Я вобщем то спрашивал про разные языки.

WH>К томуже тут нужно говорить

Кому нужно?

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

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

WH> Например помнишь то попадалово с с реализацией иерархии контролов? Там макросы Nemerle решили бы все проблемы.

И миксины тоже.

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

IT>>Язык должен меняться не под людей, а под задачу. Меняется задача — меняется/настраивается язык.

AVK>Я не про это спрашивал. Я про другое — считаешь ли ты допустимым вне контекста Nemerle, сменить для команды, писавшей пару лет на C#, язык на Java, только потому что есть ряд библиотек на ней, которые будут удобны в текущем проекте?

Я об этом даже речи не вёл и вне контекста ситуации на этот вопрос нельзя ответить. Но если тебя интересует однозначный ответ, то скорее нет, чем да. Да и к макросам и DSL это отношения не имеет. В их случае все библиотеки и даже привычная среда остаются. Меняется/модифицируется язык под конкретную задачу.

Как я понимаю, ты опасаешься, что "писатели" с большой буквы "ПЫ" на макросах могут такого понаписывать, что потом не разберёшься. Так вот я тебя могу успокоить. Они и без макросов отлично это умеют делать. Порой приходится месяцами убеждать и показывать на примерах что так и так делать нельзя. Про 77 классов, имплементирующих одностраничный отчёт я уже здесь рассказывал не раз. Про "медленность" исключений и замену их на коды возврата тоже. Всё это не имеет к метапрограммированию никакого отношения. Это проблема отсутствия либо опыта, либо мозгов помноженная на гипертрофированное самомнение.

IT>>Для меня решающий фактор один — простота конечного прикладного кода.

AVK>Это многофакторный параметр.

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

IT>>И вижу, что это может продолжить линейку развития структурное программирование -> ООП -> компонентное программирование -> метапрограммирование.

AVK>Олично. А я не вижу. Ты считаешь, что правда за тобой?

Я пытаюсь это понять. В моих приложениях рантайм генерация кода занимает весьма заметную роль. Её замена на compile-time была бы идеальным решением и закрыла бы некоторые сопутствующие рантайм генерации проблемы. При этом аргументы типа "трудность вхождения в команду" менять просто бесят О чём вообще идёт речь те кто это говорит понимают? Вот примерчик из пока не доделанного demo для bltoolkit:

using System;
using System.ComponentModel;

using BLToolkit.Mapping;
using BLToolkit.Validation;

namespace BLToolkit.Demo.ObjectModel
{
    [MapField("PersonID", "ID")]
    public abstract class Person : BizEntity
    {
        [MaxLength(50), Required] public abstract string LastName   { get; set; }
        [MaxLength(50), Required] public abstract string FirstName  { get; set; }
        [MaxLength(50)]           public abstract string MiddleName { get; set; }
        [               Required] public abstract Gender Gender     { get; set; }

        [MapIgnore]
        public string FullName
        {
            get
            {
                return string.Format(
                    string.IsNullOrEmpty(MiddleName)? "{2}, {0}": "{2}, {0} {1}.",
                    FirstName, MiddleName, LastName);
            }
        }
    }
}

Класс поддерживает AcceptChanges, RejectChanges, IsDirty, валидацию и прочую байду. Генерируется в рантайме. Трудно войти? Что тут непонятного?

Вот возможный DataAccessor:

public abstract class PersonAccessor : DataAccessor<Person>
{
    [SqlQuery("SELECT * FROM Person WHERE LastName = @lastName")]
    public abstract List<Person> SelectByLastName(string lastName);

    [SqlQuery("SELECT * FROM Person WHERE {0} = @value")]
    public abstract List<Person> SelectBy([Format] string fieldName, string value);

    [SqlQuery("SELECT TOP {0} * FROM Person WHERE LastName = @lastName")]
    public abstract List<Person> SelectByLastName(string lastName, [Format(0)] int top);
}

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

А вот полный код формы редактирования объекта Person:

using System;

using BLToolkit.Demo.ObjectModel;

namespace BLToolkit.Demo.Forms
{
    public partial class EditPersonForm : BizEntityForm, IBizEntityForm<Person>
    {
        public EditPersonForm()
        {
            InitializeComponent();
        }

        public void SetBizEntity(Person person)
        {
            personBinder.Object = person;
        }
    }
}

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

// Редактирование записи.
//
BizEntityForm.Edit<EditPersonForm, Person>(person, delegate(Person p)
{
    new PersonManager().Update(p);
});

// Добавление новой.
//
Person person = BizEntityForm.EditNew<EditPersonForm, Person>(delegate(Person p)
{
    new PersonManager().Insert(p);
});

Код PersonManager не привожу, т.к. это пока pass-through класс.

Это практически весь прикладной код, реализующий поддержку класса Person в приложении. Любой вменяемый WinForms девелопер, только что вошедший в команду, уже через два дня будет печь такие формы как пирожки. И не надо убеждать меня в обратном. А если бы сюда прикрутить метапрограммирование, то всё это хозяйство можно было бы ещё упростить. Ушли бы абстрактные классы и возможно получилось бы обойти ограничения WinForms с дженериками и убрать из формы метод SetBizEntity и лишний интерфейс.

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

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

VD>Подумалось. Наверно не верно ставить их в линейку. Это технологии которые прекрасно дург с другом совмещаются. Так что стрелочки могут определять не равитие а последовательность появлений.

OK, с этим спорить я не буду

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

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

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

VD>Даже если так, все равно глупо делать недоработанные решения. Пусть анонимные типы происходят из Линков, но драли их явно из ФЯ. Почему было не взять полноценное решение?
Насколько я правильно понял tuple, он при реализации в чистом виде подразумевают динамическую типизацию. А они сделали строготипизированную приблуду. То ли обленились, то ли политика такая.

Consider anonymous types to be a compile-time feature to create a strongly typed class for you when and if you need it.
There is no inclination to reduce the strongly-typed nature of C#. If anything, LINQ is more about increasing the amount of strong-typing that happens in your code.

Отсюда
Но почему они ограничились именно функцией? хз.

GZ>>А DSL tools тогда как продавать? Тут политика, блин. Коммерция.
VD>Это откровенная ерунда. MS зарабатывает основные деньги на ОС. Ну, там серверы еще можно упомянуть, Офис... Но студия и фрэймвок для них это средство удержания рунка, а не коммерческие продукты в полном смысле этого слова. Потому и придуманы все эит Экспрессы.
Есть еще всякие Axapta с Navision. Есть у Microsoft достаточно много заказух. Есть еще огромный корпоративный рынок с которого Oracle c IBM многомиллиардные бабки сколачивает. И на котором властвует Java, в котором набор стандартов для таких решений значительно больше и удобнее.

VD>Так что проблема тут в другом. Похоже что они действительно чтобы реализовать функциональность линка решили взять идеи из ФЯ, Смолтока и т.п., но потом, то ли они сами испугались того, что они за монстра могут породить, то ли их архитекторы безбожно тупят. Оба расклада не радуют.
Я думаю здесь постарались маркетологи. Отсутсвие стандарта на persisting objects действительно сильно влияет на рынок. Я сам часто лазию по JSR и, стыдно сказать, завидую. Хорошие или плохие стандарты, это уже другой вопрос. Они есть, есть их реализации, а недостатки или достоинства языка меньше влияют на применимость, сколько отсутвие стандартов и библиотек.

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

GZ>>Совсем без каких либо оптимизаций хотя бы на уровне expression lambda.
AVK>Кто такой expression lambda и о каких оптимизациях речь?
Это те которые не statement. Об оптимизациях говорить не буду, потому как не спец. Если брать функциональные языки, то там математически доказанных оптимизаций до фигищи. Мне просто это мало интересно. Если хочешь, спроси у них на форуме, они накатают вагон и маленькую тележку.

GZ>>Единственное для чего — сериализовать некоторые условия(он не сериализует весь запрос, только лямбду) чтобы его смогли интерпретировать кто-то другой. И при этом без десериализации в код. Сам же возмущаешься.
AVK>Ссылку в студию, где я этим возмущался. Я лично не вижу в этом особой нужды.
Хитро. Дескать я спросил, только чтобы отмазаться. Охотно верю что ты даже не обращаешь на него внимания, поскольку пользовать его и не собираешься. В нынешнем виде, действительно, плохо применимо. Хотя кое что я нашел.
Фактически мне показалось странным ответ Хобана. У них есть одна хитрость. Вместе с Linq они поставляют некоторый пример Espresso. Это как раз динамический интерпретатор(насколько я в нем разобрался) запросов. Почему они его вшпилили именно как sample, а не API, не знаю. Подозреваю какую-то хитрость. Но иметь такое API — надо, а в виде достаточно сложного сэмпла, это не есть гуд. Он врядли будет хорошо документирован. К тому же мне понадобилось много времени, чтобы вообще обратить на него внимание. Вобщем, то что это не API — недоделка.

AVK>>>и type inference
GZ>>Тоже Влад тут уже возмущался. Недоделанный какой-то.
AVK>И слава богу. Вывод типов по выражениям в конце метода резко снизит читаемость.
Не соглашусь. Во многом эта ситуация похожа на ситуацию с generic. Мы не знаем что это за тип, нас волнует только логика обработки. А ежели где напакостничили, то компилятор нам об этом сообщит. Или надо будет смотреть по коду что это за тип.

AVK>>>(совсем не половинки) в сухом остатке наличествуют.
GZ>>Так что IMHO недоделочки все это.
AVK>Ну, таким манером недоделками можно назвать что угодно.
Когда есть с чем сравнивать, определить доделанность той или иной фичи не представляет труда.

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

AVK>Я не подменял. Я первого вопроса никогда не задавал.

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

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

AVK>Далеко? По моему там все ограничено одним выражением.

Забавный аргумент. В Немерле тело любой функции — это одно выражение.
Но вот оно может быть довольно большим. Точно так же большим может быть и инициализатор в C#.

VD>>Анонимные типы никак по другому язык не поворачивается назвать.

AVK>Влад, ты внимательно читал мои сообщения? Судя по всему нет.

Внимательно. И из них явно следует, что в релиз поподет эта недоделка:

2) По поводу недоступности анонимных типов вне контекста функции: проблема известна, но по поводу ее решения он ничего сказать не смог. Боюсь, в релизе linq все останется как есть сейчас.