Здравствуйте, bazis1, Вы писали:
B>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, bazis1, Вы писали:
B>>>Да-да-да, с таким подходом немерле обязательно взлетит, обретет много новых пользователей и обгонит C# по популярности. Удачи...
VD>>В таким как ты никакой подход не подходит. По сему тратить время просто глупо. B>А ты много видел людей, которые без какой-то ощутимой пользы просто так начинали бы копаться в ваших талмудах?
bazis1 — Да оно круглое!
VladD2 — Нет, оно зеленое.
bazis1 — Вот смотри, есть круг, есть квадрат, а есть вообще треугольник. Но то, о чем мы говорим круг!
VladD2 — Хорошо приведи пример как другая вещь может быть красной, я посмотрю и по аналогии докажу, что эта вещь зеленая.
bazis1 — Стол например квадратный или прямоугольный.
VladD2 — Он зеленый!
Re[17]: Nemerle через 5 лет - выстрелит или скончается?
К>>По-моему наглядный, и ничего не мешает?
VD>Не очень то наглядно
Вкусовщина.
VD>медленно, так как ни за что, ни про что получаем создание лямбды и ее вызов.
В задачах, настолько критичных к производительности что "создание лямбды и ее вызов" это медленно, противопоказан не только C#, ещё весь .NET.
Re[17]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, bazis1, Вы писали:
B>>Язык — это в первую очередь инструмент. Инструмент, решающий некую задачу. Задача "а не расширить ли мне язык каким-нибудь макросом?" — довольно странная.
VD>Язык — это язык. Сравнивать его с инструментом довольно неразумно. Язык программирование куда ближе к человеческому языку. Вот с ним и сравнивай. Как совершенно естественно расширять свой словарный запас новыми терминами, так совершенно естественно расширять язык новыми конструкциями. Если бы это было не так, то не вышло бы C++ 11/14 и C# 5.0.
Новые термины появляются для описания новых явлений. Новые конструкции — для упрощения релевантных задач, которые слишком сложно решаются старыми. Если просто вывалить на пользователя десяток новых конструкций, то ничего кроме ухмылки это не вызовет. У меня такое ощущение, что ты рассуждаешь как программист, который сегодня пишет программу на дядю, а завтра думает что если просто возьмет и напишет другую на себя, то сам станет дядей, без анализа рынка, таргетинга, управления продажами и прочих процессов, которых обычный программист обычно не видит, но которые непосредственно влияют на то, куда копать.
B>>Опять же, конкретный пример, пожалуйста, где создание DSL вместо использования стандартных паттернов управления сложностью принесет плоды. Ведь со стандартными паттерными хорошо работает отладчик, рефактор и другие функции IDE.
VD>Их тысячи. То что ты сам, возможно, используешь каждый день: Разор, регекспы, Linq/SQL, BNF, CSS, LESS, DOT ... Еще есть встроенные DSL-и о которых только линивый не говорит. Многие прикладные задачи решаются на ДСЛ-ях проще и лучше. Вопрос только в сложности их создания. С макросами этот подход становится доступен прикладным программистам. От части, Нитра призвана еще больше упростить создание и использование ДСЛ-ей и убрать имеющиеся в Немерле ограничения.
VD>Подробнее читай http://martinfowler.com/dsl.html
Опять ты соскакиваешь с темы и предлагаешь мне убить полдня, читая какой-то мутный талмуд. А конкретных примеров, имеющих отношение к Nemerle так и нет.
B>>Генерировать из чего? В ToString() обычно помещают некую краткую сводку о состоянии объекта, упрощающую просмотр в отладчике, либо в GUI. VD>Туда частенько помещают значения полей. Например, для анонимных типов МС сделало дефолтную реализацию ToString, и это удобно. Писать по 100 раз одно и то же хотят не только лишь все (ц).
Делаем базовый класс, реализуем там ToString(), через reflection дергаем поля. Просто, красиво, 100% стандартые средства.
VD>Ага. И когда он пишется в 100500-й раз "под одну копирку", невольно возникает вопрос — "Нельзя ли автоматизировать этот мартышкин труд?". И дело тут не в ToString. Это всего лишь один из примеров. Везде когда ты пишешь что-то по одному шаблону можно автоматизировать.
Мартышкин труд безусловно нужно автоматизировать. Но с этим довольно хорошо справляется наследование и generic-и (см. пример выше).
B>>Для чего может понадобиться их генерировать, что это упростит? Как будет работать пошаговый прогон отладчиком по такому методу и Edit-and-continue, дабы исправить мелкий баг без перезапуска программы?
VD>И ты их найдешь, потому что кто хочет сделать дело, ищет возможности, а кто не хочет, ищет оправдания. Вот ты из последний. Иди пили все руками. Копипасть и наслаждайся результатом. VD>Пока ты не поймешь, что у тебя нет проблем, потому что ты многого не знаешь, ты так и будешь искать себе оправдания. Но это, плиз, без меня. Я лучше пообщаюсь с теми кто ищет возможности.
Я никогда не копипастю (ну кроме proof-of-concept кода, который пишется на один раз), я просто умею применять стандартные механизмы типа того же наследования, которые позволяют избавится от копипасты без перехода на новый язык. И от людей, рекламирующих новое "средство от копипасты" ожидаю наглядной демонстрации, чем их средство лучше стандартных.
Re[9]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, bazis1, Вы писали:
B>>Конкретно по C# меня много лет назад достало пилить GUI на WTL и я решил попробовать другие фреймворки.
VD>Если дело было только в GUI, то нужно было просто открыть для себя Qt.
Я знаю Qt, но для простых задач нахожу C#/WinForms более удобным.
Re[17]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, hi_octane, Вы писали:
_>А вот ещё редкая фича: _>
_>virtual void Initialize()
_>{
_>//такое объявление уходит в тело класса
_>//но сама переменная видна только внутри этой функции и её наследниках (если protected)
_>private bool initialized = false;
_>if(initialized)
_> return;
_>}
_>
_>Может всего пару раз на проект нужны такие переменные которые видны в одном конкретном методе. Удобно? Ну конечно.
Похожее можно запилить в имеющемся C#,
например static void initOnce( ref bool bInitialized, Action whatToDo );
К>>По-моему наглядный, и ничего не мешает? _>Я всё-таки предпочитаю using(await lockable), который в dispose отпускается. Но это всё костыли, от недостатка нормальных решений.
Во-первых, добавление фич в язык это ж не бесплатно, например растёт сложность чтения кода.
Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.
Re[2]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, uncommon, Вы писали:
U>А вот Clojure отлично за это время развилась. Учитывая ещё тот факт, что Clojure появилась два года после Nemerle в 2007м, но уже в 2008 вышла первая версия. А теперь у Clojure есть офигенное количество библиотек, документации, книжек и контрибьюторов.
U>А команда Nemerle всё это время пилила интеграцию с VS...
Clojure и прочие питоны не совсем удачное сравнение, они намного проще, но есть и удачное. Немерле — полный труп по сравнению со Скалой. В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support. ИМХО кроссплатформа есть главная причина и об этом отцам-основателям говорили пять лет назад. 95% энтузиастов не будут вкладываться в windows-only. Mono никому, включая Мигеля, был уже тогда не нужен.
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Константин, Вы писали:
К>Во-первых, добавление фич в язык это ж не бесплатно, например растёт сложность чтения кода. К>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.
1. заменяя фичу полсотней строк кода чтение не упрощается, а написание увеличивает вероятность ошибки в десятки раз.
2. Часто надо не только генерировать код, а например дополнять или модифицировать.
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, bazis1, Вы писали:
B>Я никогда не копипастю (ну кроме proof-of-concept кода, который пишется на один раз), я просто умею применять стандартные механизмы типа того же наследования, которые позволяют избавится от копипасты без перехода на новый язык. И от людей, рекламирующих новое "средство от копипасты" ожидаю наглядной демонстрации, чем их средство лучше стандартных. Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, uncommon, Вы писали:
U>>А вот Clojure отлично за это время развилась. Учитывая ещё тот факт, что Clojure появилась два года после Nemerle в 2007м, но уже в 2008 вышла первая версия. А теперь у Clojure есть офигенное количество библиотек, документации, книжек и контрибьюторов.
U>>А команда Nemerle всё это время пилила интеграцию с VS...
N>Clojure и прочие питоны не совсем удачное сравнение, они намного проще, но есть и удачное. Немерле — полный труп по сравнению со Скалой. В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support. ИМХО кроссплатформа есть главная причина и об этом отцам-основателям говорили пять лет назад. 95% энтузиастов не будут вкладываться в windows-only. Mono никому, включая Мигеля, был уже тогда не нужен.
Скала по идеи должна отстать от Н2 значительно, сейчас Н1 и Скала по языку в паритете. Я вижу 3 причины почему это может не произойти: бросят писать, увлекутся совместимостью, переделывая язык будут приоритетно поддерживать Нет.
Скала кроссплатформена? И какая этому цена производительности, совместимости и т д? Или имеется ввиду ВМДж?
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Константин, Вы писали:
К>Во-первых, добавление фич в язык это ж не бесплатно, например растёт сложность чтения кода.
Это воображаемая проблема. Читать код с использованием неизвестной библиотеки, которая делает что-то сложное обычно намного сложнее. А для простых случав макры никто писать не будет.
Реальная проблема в том, что фичу из языка убрать нельзя.
Даже если 99.999% программистов ей не пользуются.
В то же время ненужные макросы просто исчезнут так же как не нужные библиотеки.
К>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.
Было: http://rsdn.ru/forum/dotnet/4159707.1
Здравствуйте, s22, Вы писали:
s22>Скала по идеи должна отстать от Н2 значительно, сейчас Н1 и Скала по языку в паритете.
В чем? В скорости парсера?
И потом H-2 это разве не просто набор компонент с которыми играются три человека в JB, появившийся полгода назад?
s22>Я вижу 3 причины почему это может не произойти: бросят писать, увлекутся совместимостью, переделывая язык будут приоритетно поддерживать Нет.
Даже если завтра JB бросят 100% усилий на H-2 будет пшик, пока платформу нельзя использовать нигде кроме винды.
s22>Скала кроссплатформена? И какая этому цена производительности, совместимости и т д? Или имеется ввиду ВМДж?
Имеется ввиду что Скала работает на ~100% серверного железа, 80% из которого пашет на *nix.
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
К>Во-первых, добавление фич в язык это ж не бесплатно, например растёт сложность чтения кода.
Нее, макросы пишут чтобы упрощать чтение кода. Вот например ты сам можешь элементарно запилить макрос для WinForms, оборачивающий каждый вызов к Control'у из метода вызываемого из Thread в Invoke/BeginInvoke. И такой же аналог для WPF через Dispatcher. И будешь вызывать UI и рабочих потоков, без видимых лямбд и делегатов. Точно также foreach упрощает чтение кода, по сравнению с ручной росписью этой фигни.
К>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.
T4 — это обнять и плакать. Запили мне на T4 сериализацию C# объекта в том же проекте, или мемоизацию ответов от веб-сервиса.
Re[3]: Nemerle через 5 лет - выстрелит или скончается?
N>В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support. ИМХО кроссплатформа есть главная причина и об этом отцам-основателям говорили пять лет назад.
. В такой ситуации любая адекватная замена будет подхвачена на ура. Без скалы вся JVM — кобол
Ровно таже проблема у C++ — дикая перегруженность синтаксиса и груз обратной совместимости с одной стороны, и никакого выигрыша за эту перегруженность с другой. Именно поэтому все с таким энтузиазмом подхватывают очередную замену C++, будь то Go (можно сказать что уже не взлетело), или Rust (будем посмотреть, может реально что-то нормальное получится).
Re[19]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, s22, Вы писали:
s22>1. заменяя фичу полсотней строк кода чтение не упрощается, а написание увеличивает вероятность ошибки в десятки раз.
Если вам нужно копипастить boilerplate код по 50 строк, возможно вы просто плохо умеете C#.
Примеры, которые я видел выше по тредику, прекрасно решаются в рамках обычного C#, при неизменном количестве строк кода, соответственно без роста вероятности ошибок.
s22>2. Часто надо не только генерировать код, а например дополнять или модифицировать.
Опять-таки, если вам часто нужно дополнять или модифицировать код, вы вероятно плохо умеете пользоваться функциональными фичами C# и/или reflection-ом.
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
К>Похожее можно запилить в имеющемся C#, К>например static void initOnce( ref bool bInitialized, Action whatToDo );
Ты, кстати, не понял. Заменить нельзя ничем — ибо твой bInitialized будет торчать видимым для всех методов класса, в котором этот bInitialized объявлен. В моём примере — этот bInitialized виден только там где он объявлен, хотя в результирующем IL он является приватным членом класса. Из других методов этот bInitialized ни поменять, ни прочитать невозможно. И это не ограничивается только приведённым примером — часто встречаются случаи когда какому-то методу нужно хранить чисто свои, важные только для этого метода, переменные, а другим, даже методам в том же классе про них и знать не надо. Т.е. фича удобная, такая же как, например если бы в C# было можно так:
public int Prop
{
int p1;//переменные видны только тут, для других методах этого же класса их нетbool p2;
get
{
//код использующий f1 и f2
}
set
{
//аналогично
}
}
В Nemerle это всё можно, и ещё куча всего, что придумывается прямо в процессе, по ходу проекта. Кто-то говорит "а вот мы тут часто делаем XXX, было бы здорово если бы это делалось автоматом". Бац и запилили. И если надо реализацию поменять — то меняешь макрос реализующий это "автоматом", и меняется реализация фичи на всём проекте. Без рефакторингов. В приведенном примере, можно было бы по ходу дела bInitialized заменить на volatile если надо, или менять строго через Interlocked с проверкой на сохранность предыдущего и RaceConditionException если обнаружилось что два потока которые логически разделены, вдруг пересеклись. Это всё легко делается макросами, и через прорву рукопашного кода без них.
Re[19]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, hi_octane, Вы писали:
_>запилить макрос для WinForms, оборачивающий каждый вызов к Control'у из метода вызываемого из Thread в Invoke/BeginInvoke. И такой же аналог для WPF через Dispatcher.
Есть очень веские причины, почему так не было сделано.
Возможен deadlock двух потоков, message loop может быть занят блокирующим вызовом, проблемы с COM apartments, проблемы с возвращаемым значением, и ещё вагон других.
В случае с foreach я таких тяжких последствий не вижу, он или работает или нет.
_>T4 — это обнять и плакать. Запили мне на T4 сериализацию C# объекта в том же проекте
Зачем обязательно в том же?
Это же прекрасно делается через reflection.
Вот например один мой вариант сериализатора .NET объектов в странное хранилище.
Re[19]: Nemerle через 5 лет - выстрелит или скончается?
Ну вы заменили 2 страницы понятного C# кода на полторы страницы непонятного на Nemerle, со всякими def mods = Modifiers(tb.Attributes, [<[ WrapStaticMethods($(tb.ParsedTypeName), $(symbol : string)) ]>]);
Интересно, с этими вот макросами отладчик дружит, как в случае T4?
_>>T4 — это обнять и плакать. Запили мне на T4 сериализацию C# объекта в том же проекте К>Зачем обязательно в том же?
Да потому что так явная убогость C#/T4 проявляется в полный рост. Да и стандартная реализация ISerializable и конструктор подразумевают их объявление в том же классе Кстати, я вкурсе что можно выкручиваться на суррогатах и биндерах, но это всё от убогости. Всё равно про биндеры придётся помнить в том месте где собираешься сериализовать. Одни костыли короче.
К>Это же прекрасно делается через reflection.
Через reflection я и сам могу. И не надо мне в качестве post-build предлагать ILMerge , у меня от него pdb-шки слетают
Ты понимаешь что обсуждение уже скатывается на уровень "любую фичу можно сделать имея if и goto"? В программировании можно всё, вопрос в том сколько ты потратишь человеко-часов в одном случае и сколько в другом.
Re[20]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Константин, Вы писали:
К>Ну вы заменили 2 страницы понятного C# кода на полторы страницы
Кода более чем в два раза меньше. И это на простой задачке.
К>непонятного на Nemerle, со всякими def mods = Modifiers(tb.Attributes, [<[ WrapStaticMethods($(tb.ParsedTypeName), $(symbol : string)) ]>]);
А ты хоть пытался разобраться?
К>Интересно, с этими вот макросами отладчик дружит, как в случае T4?
С макросами и отладчик и ИДЕ дружат отлично.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hi_octane, Вы писали:
К>>Зачем обязательно в том же? _>Да потому что так явная убогость C#/T4 проявляется в полный рост.
Чудесно, только для продажи nemerle нужно не убогости C# выискивать, а продемонстрировать, для каких задач ему нет нормальной альтернативы.
В случае с сериализацией/десериализацией нормальные альтернативы есть.
_>стандартная реализация ISerializable
Я не использовал. Костылей совсем немного, там у меня довольно чистый код на атрибутах и reflection.
К>>Это же прекрасно делается через reflection. _>Через reflection я и сам могу.
Имел в виду reflection не на каком-то их этапов сборки, а в runtime.
С требованием про тот же проект я ошибся — оно прекрасно делается и в том же, и в любом другом.
_>В программировании можно всё, вопрос в том сколько ты потратишь человеко-часов в одном случае и сколько в другом.
Ну я вот не вижу преимущества в человеко-часах одного перед другим.
Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.
Кстати, я вкурсе что можно выкручиваться на суррогатах и биндерах, но это всё от убогости. Всё равно про биндеры придётся помнить в том месте где собираешься сериализовать. Одни костыли короче.
