Re[9]: Снова о Nemerle или профанация не пройдет :) - Философия программирования

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

VD>Если сможешь с помощью С++-шаблонов сгенерировать код конструктора и эксесор-методы для полей, то я сниму перед тобой шляпу.

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

VD>Эх. Как бы заставить обратить внимание МС на этот проект?! Ведь сейчас проекту нехватает гарммотного коммерческого подхода. Сейчас нужно было бы произвести ревизию фич, заморозить проект и довести, что назвается, его до релиза! Ведь щастье так близко, но все может погубить отсуствие коммерческой жилки у проекта.

На rsdn наблюдается удивительная плотность MVP в пересчете на квадратный сантиметр ГУИ сайта

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

AVK>CAS спасет отца русской демократии.

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>Здорово, но не то. Нужно, чтобы он примерно то же вывел бы в следующем случае:
VD>

VD>def a = <[ foreach(n in nums) printf("%d\n", n) ]>;
VD>pretty_print_expr(, true);
VD>

Фигня вопрос. Смотрим код макроса (core.n):

def ctx = if (expand) Some (Macros.ImplicitCTX()) else None ();
PrettyPrint.PrintExpr (ctx, exp);

Как видишь, внутри вызов обычной функции — только контекст нужен. Итого: делаем ctx (как в макросе) и пихаем вместе с AST в PrintExpr().

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

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

Для начала хотелось бы услышать ответ от самих разработчиков — может, таки есть вариант покрасивше?... Я уже им на форум запостил — будем ждать.

Здравствуйте, Vermicious Knid, Вы писали:
VK>

VK>$"Имя:$(name)Фамилия:$lastname"
VK>

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

По идее, если бы я решал все с чистого листа, то вместо string.Format я бы звал что-то типа специализированного метода:

namespace Resources
public class Ru
{
  public string PersonConverter(IPerson person)
    {
        return "Имя: "+person.name+"Фамилия: "+person.lastname;
    }
}
...

{
  PersonTitle.Text = Resources.Ru.PersonConverter(person);
}

Таким образом, я был бы застрахован с обоих сторон: и со стороны использования (я не смогу передать ничего, кроме персона в этот конвертер), и со стороны локализации (я не могу использовать ничего, кроме свойств IPerson).
Увы, такую локализацию мне ни один текрайтер не напишет.
Здесь, наверное, и можно применить макрос Влада: выкидываем из Resources.Ru все, кроме тел этих методов, записанных как можно более компактно.
То есть я (как разработчик) объявляю себе класс PersonResources c виртуальными методами, а текрайтерам отдается что-то вроде:

PersonResources.Ru : PersonResources
{
  PersonConverter: IPerson => $"Имя:$(name)Фамилия:$lastname";
}

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

1.1.4 stable rev. 510

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

V>Во-первых, основной мой упор был на аргумент гибкости и "незасоряемости" домена после обновлений кода, без остановки, скажем, сервера приложений (именно так).

Я не про основной упор, а про конкретный п.6

V>Во-вторых, CAS действует уже в run-time. А значит мы головную боль перекладываем с разработчика системы на разработчика прикладной платформы (то бишь на продвинутого юзера системы).

С чего бы это? CAS сугубо программная технология и забота программиста. Юзер этого не видит.

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

Зато будет гарантия безопасности, даже если ты внутри служебных функций дырку оставил.

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

А в их руки его вручать и не надо.

... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>

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

O>

Тебе Reflection.Emit больше нравится?

Я его не использую.

O> С XSLT не имеет смысла сравнивать, поскольку тут точно уж лучше макросы.

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

... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>

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

VD>Как обычно. Сказать есть что, но тебе это не нравится.

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

VD>match заменяет и if, и switch и даже операторы вроде && и ||. Доказательством служит то, что в Нэмерел операторы if реализован на базе match, а switch вообще отсуствует, так как проигрывает match-у в выразительности.

VD>Но это сказать это, все равно что ничего не сказать.
VD>match — это в разы большее мошьная конструкция.
VD>Конечно, все что можно сделать с помощь match можно сэмулировать сочетанием груды if-ов cо switch-ами, плюс прийдется пользоваться хэш-таблицами и писать кучу кода.

Влад, сопостовление с образцом это средство связывания данных с кодом их обрабатывающим, можно сказать средство создания контекста выполнения. Вот тебе пример из A Gentle Introduction to Haskel:

4.1 Pattern-Matching Semantics
A successful match binds the formal parameters in the pattern.
При успешном сопоставлении (данные) связываются с формальными параметрами образца.
/.../
4.3 Case Expressions
Pattern matching provides a way to "dispatch control" based on structural properties of a value.
Сопоставлени с образцом позволяет "передавать управление" в зависимости от структуры значения.

Кроме операторов ветвления if/switch в современных языках есть другие способы как передачи управления, так и связывания кода с данными. Это, известные всем, методы объектов, где код всегда связан с нужными данными. И перегрузка методов в статически типизируемых языках.

И ежу понятно, что сопоставление с образцом более гибко, чем объекты + (виртуальные) методы, потому, что структура объектов более жесткая. Но, поскольку сказано, что пример "наглядно демонстрирует некоторые отличия между Nemerle и C#", то, корректной была бы программа-образец в которой сравнивались методы + объекты + if/switch с сопоставлением. Использованный пример можно заимплементить даже без if (Что я и показал). Что интересно, достаточно легко выбрать задачу, которая через сопоставление решается "веселее" чем на конструировании объектов/методов/if-ов. Простейший пример — любая задача требующая множественной диспетчеризации (для примера может хватить и двойной).

А уж если сравнивать сопоставление только с if/switch, то нужно было бы взять читый C. Только сомневаюсь, что сравнение Nemerle с С добавит первому очков.

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

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

VD>Не приймите, это за наезд или оскорбление, но вам похоже нужно просто по серьезнее изучить match и его возможности. Тогда вам будет очевидно, что match — это намного более универсальная и выразительная вещь чем switch. Ну, а if является более врыазительным в некоторых случаях, но не обеспечивает всего функционала. Куча же if-фов является явно менее выразительной.

А мужики то и не знают, что match нужно сравнивать со switch. А они взяли и написали:

Сопоставление с образцом это способ разложения сложных структур.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

И что, у меня будет возможность ЗАПРЕТИТЬ динамически подгружать в домен произвольную сборку?

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

O>> С XSLT не имеет смысла сравнивать, поскольку тут точно уж лучше макросы.

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

Смотри — ты всё равно в итоге генерируешь код из XML, используя XSLT, на этапе компиляции, правильно? Почему бы не использовать Nemerle вместо XML и макросы вместо XSLT?

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

WP>И меня бесят макры R5RS за свою однопроходность.

Интресно, а когда собираются принимать следующий стандарт?

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

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

V>И что, у меня будет возможность ЗАПРЕТИТЬ динамически подгружать в домен произвольную сборку?
Конечно! CAS на то и CAS, что ежели коду права не дадены, то он никаким чудом их не получит.

1.1.4 stable rev. 510

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

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

V>4. Механизм Лисп-машины можно использовать как бэк-энд для других скриптовых нужд.

V>5. Очень прост сам способ расширения функциональности Лисп-машины.

V>Какие еще есть коссвенные преимущества:
V>6. Управляемость и надежность. Мне страшно давать в руки бухгалтера какой-нить JavaScript.Net

Дима, глянь, когда будет время на Ruby. Может ничего и писать не придется.
Не Lisp, конечно, о очень себе pragmatic.

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

VD>Извини, но в данном контексте это выглядит как усмешка, а не как добрая шутка.

А это и была добрая и ироничная усмешка, но не добрая шутка.

VD>Понимаш ли в чем дело. Ты тут споришь с теми С++-никами которые не пожелали влиться в стройные редя Буст-комьюнити. И не пожелали не потому, что тыпы чтобы понять и проникнуться, а наоборот они слишком умны (скромно

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

Видишь ли, я ведь так же не пожелал влиться в ряды Boost-комьюнити.

VD>Я люблю чистые решения. И очень страдаю от того, что реальные решения не всегда чисты. Так вот Нэмерел для меня — это шанс страдать меньше.

Я не вижу принципиальной разници между Boost писателями (которые так же хотят страдать меньше, но в C++) и Nemerle macro писателями. Поскольку и те и другие пишут код низкого уровня, требующий знаний тонкостей языка и особенностей работы компилятора. А результаты их работы будут потреблять другие программисты, которым все эти нюансы по барабану.

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

И если ты хочешь еще более чистых решений, без суеты вокруг AST, то посмотри в сторону динамических языков. Генерация getter-ов и setter-ов в том же Ruby выглядит вообще элементарно:

def self.getter_setter_for( a_attribute )
    class_eval %Q{
        def get_#{a_attribute}
            @#{a_attribute}
        end
        def #{a_attribute}( a_value )
            @#{a_attribute} = a_value
        end
    }
end

# И используются затем:
getter_setter_for    :decl_file
getter_setter_for    :impl_file

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

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

VD>

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

Может мои ироничные подколки сторонников Nemerle только закаляют?

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

E>Я не вижу принципиальной разници между Boost писателями (которые так же хотят страдать меньше, но в C++) и Nemerle macro писателями. Поскольку и те и другие пишут код низкого уровня, требующий знаний тонкостей языка и особенностей работы компилятора. А результаты их работы будут потреблять другие программисты, которым все эти нюансы по барабану.

Да. Разве что на Nemerle всё-таки проще писать и возможностей больше (Андрюха-то чего мучался со всякими списками типов — ему узких рамок шаблонов не хватало). А так да.

E>Я понял, что меня сильно смущало в этом обсуждении. Здесь не идет речи о том, как на Nemerle делать конкретный прикладной код. Все разговоры вокруг макросов.
E>Хорошо хоть с ними более менее ситуация прояснилась, ну а дальше что?

А дальше как на C#

Ну чуть лучше засчёт функциональных фич.

E>И если ты хочешь еще более чистых решений, без суеты вокруг AST, то посмотри в сторону динамических языков. Генерация getter-ов и setter-ов в том же Ruby выглядит вообще элементарно:

...

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

Интересно. А что-нибудь более сложное там можно проворачивать? Например, точно та же задача, решение для которой на Nemerle я привёл?

[... история поскипана ...]

Хорошая история.

E>Может мои ироничные подколки сторонников Nemerle только закаляют?

Угу. Мозга всё крепчее и крепчее...

Хотел добавить, что мне лично ещё нравится в Nemerle. Так вот — мне лично ещё в Nemerle нравится то, что он написан под .NET и органично с ним сочетается. Потому что BCL уж очень нравится — неохота с ней слезать. Да и CLR ничё так. Межъязыковое взаимодействие, опять же — сгенерить часть кода с помощью Nemerle и юзать из C#, например.

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

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

O>Интересно. А что-нибудь более сложное там можно проворачивать? Например, точно та же задача, решение для которой на Nemerle я привёл?

Это про исходную, где задаются свойства, а нужно сгенерировать класс с getter-ами и setter-ами?

O>Хотел добавить, что мне лично ещё нравится в Nemerle. Так вот — мне лично ещё в Nemerle нравится то, что он написан под .NET и органично с ним сочетается. Потому что BCL уж очень нравится — неохота с ней слезать. Да и CLR ничё так. Межъязыковое взаимодействие, опять же — сгенерить часть кода с помощью Nemerle и юзать из C#, например.

+1
Это понятно. Это как раз то, чем .NET привлекательнее, чем Java от Sun. Java изначально была моноязыковой средой.

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	23.02.06 08:14
Оценка:	+1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	23.02.06 08:19
Оценка:	-1

От:	Oyster	https://github.com/devoyster
Дата:	23.02.06 08:33
Оценка:

	От:	vdimas
	Дата:	23.02.06 08:39
	Оценка:	+1

	От:	vdimas
	Дата:	23.02.06 08:47
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	23.02.06 10:41
Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	23.02.06 11:06
Оценка:	+1

От:	eao197	http://eao197.blogspot.com
Дата:	23.02.06 13:32
Оценка: