_>>запилить макрос для WinForms, оборачивающий каждый вызов к Control'у из метода вызываемого из Thread в Invoke/BeginInvoke. И такой же аналог для WPF через Dispatcher. К>Есть очень веские причины, почему так не было сделано. К>Возможен deadlock двух потоков, message loop может быть занят блокирующим вызовом, проблемы с COM apartments, проблемы с возвращаемым значением, и ещё вагон других.
Ты перечислил проблемы которые относятся к самим Invoke. Это аргумент против использования таких вызовов вообще. Но ни разу не аргумент против оборачивания в макросы именно этих вызовов если они всё-таки есть. Более того, столкнувшись с проблемой ты можешь поменять код макроса, и он будет сам проверять на InvokeRequired, следить за таймаутом, чтобы не зависнуть в блокирующем вызове совсем, и другими способами обойти проблемы. Т.е. код, который собственно лезет в UI, править не придётся + защита от случайного забывания вызвать Invoke. Profit.
К>В случае с foreach я таких тяжких последствий не вижу, он или работает или нет.
Да это пример был. Представь программирование на C# без foreach. Вот это ощущение что ты регулярно пишешь ненужные но обязательные из-за убогости языка куски кода у тебя будет каждый раз когда ты будешь садиться за C# после Nemerle. В C# нет foreach {} else {}, нет foreach(index, element), и т.д. и т.п. — отстутвие каждой такой фича по отдельности вроде как не смертельно. Но когда их нет всех вместе, а особенно нет возможности объявить свою, нужную один раз, но здесь и сейчас, получаешь незабываемое ощущение что убогость языка тебе программировать реально мешает
Re[4]: Nemerle через 5 лет - выстрелит или скончается?
. В такой ситуации любая адекватная замена будет подхвачена на ура. Без скалы вся JVM — кобол
Не любая, но в общем верно. Только не совсем понятно какое это имеет отношение к обсуждаемому в ветке вопросу "почему Немерле труп". Мой тезис такой: "в 2014 Немерле не нужен, потому что есть Скала которая лучше во всем". В 2009 это было не так.
_>Ровно таже проблема у C++ — дикая перегруженность синтаксиса и груз обратной совместимости с одной стороны, и никакого выигрыша за эту перегруженность с другой. Именно поэтому все с таким энтузиазмом подхватывают очередную замену C++, будь то Go (можно сказать что уже не взлетело), или Rust (будем посмотреть, может реально что-то нормальное получится).
Это опять же оффтоп, но я придерживаюсь другого мнения. Просто новый язык для системного программирования сложнее интегрировать в экосистему, так как он лежит в фундаменте. Все сильно набравшее популярность последнее время(Python, Scala, Ruby, Clojure, Haskell, Erlang) явно не из этой серии.
Re[21]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:
WH>Кода более чем в два раза меньше.
Убрал usings которые никто не читает, и каменты которые есть только в T4 версии.
T4 3437 байт, Nemerle 2237 байт. Нет, это не "более чем в два раза меньше".
К>>непонятного на Nemerle, со всякими def mods = Modifiers(tb.Attributes, [<[ WrapStaticMethods($(tb.ParsedTypeName), $(symbol : string)) ]>]); К>> WH>А ты хоть пытался разобраться?
Разобраться можно даже в скомпилированном коде. Вопрос в целосообразности тратить на это время.
К>>Интересно, с этими вот макросами отладчик дружит, как в случае T4? WH>С макросами и отладчик и ИДЕ дружат отлично.
Ставлю breakpoint в этом вот макросе и нажимаю "Build project" — breakpoint сработает?
Re[19]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, bazis1, Вы писали:
B>>Я никогда не копипастю (ну кроме proof-of-concept кода, который пишется на один раз), я просто умею применять стандартные механизмы типа того же наследования, которые позволяют избавится от копипасты без перехода на новый язык. И от людей, рекламирующих новое "средство от копипасты" ожидаю наглядной демонстрации, чем их средство лучше стандартных. WH> Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.
Браво, наконец нашли хороший пример. Это шаг в правильном направлении, но одного этого примера мало. Если вы хотите успеха и популярности, вам надо:
1) Найти штук 10 таких примеров
2) Сделать так, чтобы ваш язык работал поверх C#. Т.е. чтобы я мог добавить какой-нибудь хитрый аттрибут в свою C#-программу, который C#-компилятор проигнорирует, потом Nemerle-компилятор его обработает и добавит в мою сборку пару классов/методов. Тогда я (абстрактный потенциальный пользователь):
а) буду знать что в случае проблем я могу всегда переписать руками бойлерплейт и вернуться к обычному C#. Страховка, если хотите.
б) не буду платить за то, чем не пользуюсь. Т.е. для задач, где мне комфортно использовать C# я буду использовать C#. А как только наткнусь на подобный ботлнек, возьму столько немерла, сколько мне нужно.
в) Написать несколько статей не в духе "об оптимальной реализации макросов, Тьюринг-полных на момент компиляции", а в стиле "вот эта фигня, которая на C# делается за 5 минут с нашей перделкой делается в один клик".
г) быть готовым к скептическим вопросам. Например, касательно INotifyPropertyChanged я бы поспорил, что:
1. Имплементация INotifyPropertyChanged лично у заняла меньше 15 минут суммарно за 5 лет разработки на C#. Переходить на новый язык для экономии 15 минут за 5 лет было бы довольно странно.
2. Есть продукты, которые это автоматизируют без риска перехода на новый язык.
3. Если меня одолеет непреодолимая тяга подрочить на фреймворки к экспериментаторству, то я сделаю обертку через Reflection.Emit, которая будет генерить классы-наследники, имплементирующие этот интерфейс, и создавать их через MyStubFactory.Create<MyClass>() наподобие того, как сделан Remoting.
Дополнение: пример с INotifyPropertyChanged был бы в 10 раз убедительней, будь он представлен в течение года после появления WPF. Когда мысль "блин, как же INotifyPropertyChanged достал" возникала в голове у многих людей, осваивающих этот фреймворк. Сейчас каждый эту проблему для себя решил. Кто-то, смирившись, кто-то, наняв кодера за $15/час, кто-то с помощью стороннего продукта, кто-то, написав свой костыль... Поэтому ищите применения среди новых и быстрорастущих технологий. Пример с потолка: язык высокого уровня, который может компилироваться как в .Net-овские сборки, так и в Dalvik VM bytecode для исполнения на Android. ВНЕЗАПНО куча людей, которых не устраивает Mono, будут заинтересованно тыкать палкой в ваш продукт.
Здравствуйте, Константин, Вы писали:
К>T4 3437 байт, Nemerle 2237 байт. Нет, это не "более чем в два раза меньше".
Кручу, верчу запутать хочу... но даже так немерле всё равно значительно опережает.
К>Разобраться можно даже в скомпилированном коде. Вопрос в целосообразности тратить на это время.
Значит, не пытался.
WH>>С макросами и отладчик и ИДЕ дружат отлично. К>Ставлю breakpoint в этом вот макросе и нажимаю "Build project" — breakpoint сработает?
Да. Если запустить сборку проекта под отладкой.
Ну или просто воткнуть в макрос
System.Diagnostics.Debug.Assert(false);
И присоединится студией, когда вылетит ассерт.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, hi_octane, Вы писали:
_>Ты перечислил проблемы которые относятся к самим Invoke. Это аргумент против использования таких вызовов вообще.
Мы же оба понимаем, что невозможно их не использовать.
_>столкнувшись с проблемой ты можешь поменять код макроса, и он будет сам проверять на InvokeRequired
Это без макросов прекрасно делается, на Actions/Functions
_>и другими способами обойти проблемы
Почему ты решил, что обходить проблемы в данном случае должна реализация, а не тот кто вызывает?
Я вот наоборот считаю, что тот кто вызывает — поэтому не нужно прятать эту сложность от программиста.
UI не многопоточный, и абстракция что можно просто так взять и поменять UI из любого потока неизбежно обильно протечёт. Иначе бы кстати это встроили в .NET framework.
_>защита от случайного забывания вызвать Invoke.
Она и так есть — runtime бросает MethodAccessException, который элементарно чинится за 2 минуты.
А вот в результате неправильного использования твоего макроса будут странные зависания, исключения почти без call stack которые непонятно даже откуда прилетели, dead locks (их хоть понятно как чинить, debugger показывает что именно остановилось), и т.п.
А потом ты выяснишь, что некоторые методы класса Control не нужно маршалить в GUI поток, причём програмно об этом не узнаешь только документацию читать.
А потом у тебя будут несчисленные проблемы с third-party controls вроде Telerik.
А потом ты столкнёшься с тем, что некоторые API привязаны к потоку, поэтому не все автомагически промаршаленные методы корректно работают.
И т.д., и т.п.
К>>В случае с foreach я таких тяжких последствий не вижу, он или работает или нет. _>Да это пример был.
Да я понимаю конечно что пример.
Но мне бы хотелось других примеров, где использование этого вашего немерле будет оправдано.
А не таких вот, которые создают намного больше проблем, чем решают.
_>Представь программирование на C# без foreach.
А шо такого?
foreach можно один раз реализовать через while(...) и Action<tElement> / Function<tElement, bool> для conditional остановки.
Как и разные "foreach(index, element)": forEach( this IEnumerable<tElement> seq, Action<int, tElment> act )
Re[22]: Nemerle через 5 лет - выстрелит или скончается?
_>>Да потому что так явная убогость C#/T4 проявляется в полный рост. К>Чудесно, только для продажи nemerle нужно не убогости C# выискивать, а продемонстрировать, для каких задач ему нет нормальной альтернативы.
Вот каждый раз когда ты пишешь кусок кода, который ты уже писал для идентичной задачи — ты столкнулся со случаем когда реальной альтернативы, кроме как написать этот кусок кода ещё раз, и в следующем файле ещё раз, у тебя нет.
К>В случае с сериализацией/десериализацией нормальные альтернативы есть. К>Имел в виду reflection не на каком-то их этапов сборки, а в runtime.
Да ну нафиг. Runtime вообще появляются на свет только из-за отсутствия compile-time решений. Спроси у C++ников, они вон буст придумали, лишь бы в рантайм не ходить . И что там было насчёт применимости T4 для задач генерации кода? Ну чего-же проще-то? Взять поля, в одном методе сложить, в другом достать. Опять T4 оказался плохо применим? Я так и думал А уж задачи изменения кода, под конкретную ситуацию, я вообще не касаюсь. Посмотрим на Roslyn, может хоть там что-то приличное появится.
_>>В программировании можно всё, вопрос в том сколько ты потратишь человеко-часов в одном случае и сколько в другом. К>Ну я вот не вижу преимущества в человеко-часах одного перед другим.
Ну раз уж ты за C#, открой историю форума, почитай споры C# vs Любой Другой Язык. Людям тогда прочно стоявшим на позиции "я в своём языке могу тоже самое, максимум на 2-3 строчки больше писать" — никто ничего доказать не мог. Они цепляются до последнего за свои if и goto, и всегда говорят что на 3-4 строчки больше, это ещё не повод чтобы менять язык. Но на больших проектах это выливается в огромную разницу. Сравни roslyn и nemerle, и прикинь что nemerle внезапно умеет не только себя компилировать но и сорцы на C#, прямо в своих проектах. И там, в этих сорцах C#, работает отладчик, автокомплит, подсветка. Сравни размеры команд работающих над тем и над другим, подумай затратах на то и на другое, о человеко-часах, может увидишь наблюдаемую разницу
Re[23]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, hi_octane, Вы писали:
_>Вот каждый раз когда ты пишешь кусок кода, который ты уже писал для идентичной задачи — ты столкнулся со случаем когда реальной альтернативы, кроме как написать этот кусок кода ещё раз, и в следующем файле ещё раз, у тебя нет.
Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз.
К>>Имел в виду reflection не на каком-то их этапов сборки, а в runtime. _>Runtime вообще появляются на свет только из-за отсутствия compile-time решений.
Только в очень узкой области так.
Куча задач вообще лучше подходит для интерпретируемых языков, в которых вообще нет компилятора, а только парсер и рантайм.
Причём C# со своими анонимными типами и dynamics заимствует некоторые вещи оттуда, и вовсе не из-за отсутствия compile-time решений.
_>Спроси у C++ников, они вон буст придумали, лишь бы в рантайм не ходить
Мне не надо ни у кого спрашивать, я сам много лет на C++ программировал. Буст придумывали не для этого.
_>И что там было насчёт применимости T4 для задач генерации кода?
Нормально применим, я использовал, когда было нужно.
_>Сравни размеры команд работающих над тем и над другим, подумай затратах на то и на другое, о человеко-часах, может увидишь наблюдаемую разницу
Разницу в том, что nemerle наколеночное поделие, а за рослиным стоит лидер индустрии разработки ПО?
Со всеми вытекающими обстоятельствами про качество реализации, качество и объем поддержки, маркетинг и обучение разработчиков?
Re[22]: Nemerle через 5 лет - выстрелит или скончается?
_>>Ты перечислил проблемы которые относятся к самим Invoke. Это аргумент против использования таких вызовов вообще. К>Мы же оба понимаем, что невозможно их не использовать.
Так это ты начал пугать тем что их лучше не использовать. Я-то понимаю, поэтому предпочитаю вызывать методы и не париться о том что там внутрях .Invoke. Или ты против Remoting/WCF, ведь у них там тоже под капотом не прямой вызов объекта?
_>>столкнувшись с проблемой ты можешь поменять код макроса, и он будет сам проверять на InvokeRequired К>Это без макросов прекрасно делается, на Actions/Functions
Ага. Отличное решение. Главное никому не забывать, и чтоб не надоедало.
_>>и другими способами обойти проблемы К>Почему ты решил, что обходить проблемы в данном случае должна реализация, а не тот кто вызывает? К>Я вот наоборот считаю, что тот кто вызывает — поэтому не нужно прятать эту сложность от программиста.
Потому что иногда оказываюсь в ситуации когда профи пилят непрошибаемое нутро, а простые задачи оставляют людям с квалификацией поменьше. И этих людей неплохо бы и в выборе методов решения ограничить, и соломку где надо подстелить.
К>UI не многопоточный, и абстракция что можно просто так взять и поменять UI из любого потока неизбежно обильно протечёт. Иначе бы кстати это встроили в .NET framework.
Так я не общее решение для .NET Framework продвигаю, а удобство использования конкретных решений под конкретную ситуацию. Наш проект и нам решать, удобно иметь такую обёртку или нет. В другом проекте обойдёмся, главное что возможность выбора в случае Nemerle есть, а в случае C# — Action/Func, отличный выбор
_>>защита от случайного забывания вызвать Invoke. К>Она и так есть — runtime бросает MethodAccessException, который элементарно чинится за 2 минуты.
Ага. Windows 7, реальный проект, вместо исключений Aero тупо слетал у клиентов раз в неделю, всего-то забыли где-то Invoke. Вот я за язык в котором это невозможно. А ты видимо за сложность.
К>А вот в результате неправильного использования твоего макроса будут странные зависания, исключения почти без call stack которые непонятно даже откуда прилетели, dead locks (их хоть понятно как чинить, debugger показывает что именно остановилось), и т.п. К>А потом ты выяснишь, что некоторые методы класса Control не нужно маршалить в GUI поток, причём програмно об этом не узнаешь только документацию читать. К>А потом у тебя будут несчисленные проблемы с third-party controls вроде Telerik. К>А потом ты столкнёшься с тем, что некоторые API привязаны к потоку, поэтому не все автомагически промаршаленные методы корректно работают. К>И т.д., и т.п.
Это сейчас мысленный эксперимент был? Так вот реальный опыт показывает что проблем уж точно меньше чем у async/await которые умеют показать что Scheduler задач не осталось, а прога при этом тупо висит, ждёт чего-то. Например макрос на этапе компиляции может вообще ничего не вызывать, а только проверять что его вызывают из класса, которому к GUI обращаться по-определению запрещено, и валить компиляцию. Может предложишь решение на Action/Func для такого случая?
К>>>В случае с foreach я таких тяжких последствий не вижу, он или работает или нет. _>>Да это пример был. К>Да я понимаю конечно что пример. К>Но мне бы хотелось других примеров, где использование этого вашего немерле будет оправдано. К>А не таких вот, которые создают намного больше проблем, чем решают. Ну почитай
— это из реального проекта. И прикинь сколько из того реализуемо на костылях, а сколько вообще проще не начинать.
_>>Представь программирование на C# без foreach. К>А шо такого? К>foreach можно один раз реализовать через while(...) и Action<tElement> / Function<tElement, bool> для conditional остановки. К>Как и разные "foreach(index, element)": forEach( this IEnumerable<tElement> seq, Action<int, tElment> act )
Да ничего. Тут главное что ты представил — без любых фич можно жить, но подтормаживать они тебя будут каждая по чуть-чуть и все вместе вполне конкретно.
Re[12]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Ikemefula, Вы писали:
I>В преимущества C# нужно добавить наличие полноценных тулов почти на все случаи жизни.
Добавь. Только исходная мысль была о том, что даже их наличие у Шарпа не достаточно чтобы его предпочесть.
I>Раз тебе не хватает только рекламы, то это значит что язык готов для индустрии. Подготовка специалистов "на вырост" это важный аспект индустрии. Покажи как этот аспект работает в Немерле. На этот раз очень желательно без аргументов в духе "не то мироустройство"
Мне еще и этим заняться? Вот раз ты в этом знаешь толк, то и помог бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Nemerle через 5 лет - выстрелит или скончается?
_>>Вот каждый раз когда ты пишешь кусок кода, который ты уже писал для идентичной задачи — ты столкнулся со случаем когда реальной альтернативы, кроме как написать этот кусок кода ещё раз, и в следующем файле ещё раз, у тебя нет. К>Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз.
foreach{} else{} — давай, придумывай
_>>Спроси у C++ников, они вон буст придумали, лишь бы в рантайм не ходить К>Мне не надо ни у кого спрашивать, я сам много лет на C++ программировал. Буст придумывали не для этого.
Я тоже настоящий сварщик Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе.
_>>И что там было насчёт применимости T4 для задач генерации кода? К>Нормально применим, я использовал, когда было нужно.
Нормально применим только в одном случае — когда у тебя есть готовый источник на базе которого ты будешь генерировать код, и нет никакой необходимости трогать уже сущетсвующий код. Кому-то этого хватает, но с такими ограничениями заявлять что "Для генерации кода есть T4", слишком смело ИМХО.
_>>Сравни размеры команд работающих над тем и над другим, подумай затратах на то и на другое, о человеко-часах, может увидишь наблюдаемую разницу К>Разницу в том, что nemerle наколеночное поделие, а за рослиным стоит лидер индустрии разработки ПО? К>Со всеми вытекающими обстоятельствами про качество реализации, качество и объем поддержки, маркетинг и обучение разработчиков? Смешались в кучу кони-люди А причём тут объём поддержки и обучение разработчиков? Ты кодовую базу сравнивал? На разницу в количестве фич умножал? Желаемую разницу в человеко-часах увидел?
Re[25]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, hi_octane, Вы писали:
К>>Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз. _>foreach{} else{} — давай, придумывай
Вот готовый http://www-jo.se/f.pfleger/.net-for-else но мне никогда не было нужно такого.
_>Я тоже настоящий сварщик Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе.
В С++ конечно, но в C# уже не так однозначно, т.к. runtime намного более годный.
К>>Нормально применим, я использовал, когда было нужно. _>Нормально применим только в одном случае — когда у тебя есть готовый источник на базе которого ты будешь генерировать код, и нет никакой необходимости трогать уже сущетсвующий код. Кому-то этого хватает, но с такими ограничениями заявлять что "Для генерации кода есть T4", слишком смело ИМХО.
Во-первых очень надуманное ограничение.
Если очень нужно, вполне можно использовать например CodeDOM.
Но нужно бывает редко, потому что рефлексия + функциональщина; я например могу по пальцам одной руки пересчитать написанные за карьеру T4 templates, а reflection постоянно использую для разного.
К>>Разницу в том, что nemerle наколеночное поделие, а за рослиным стоит лидер индустрии разработки ПО? К>>Со всеми вытекающими обстоятельствами про качество реализации, качество и объем поддержки, маркетинг и обучение разработчиков? _>А причём тут объём поддержки и обучение разработчиков?
При том, что продукт это не только исходный код который компилируется, это ещё и поддержка, и обучение пользователей, и сообщество.
Кстати про сообщество: на SO два вопроса с тегом nemerle. Для сравнения, там 500 вопросов с тегом clojure, 4000 вопросов с тегом scala, и 140’000 вопросов с тегом C#. Даже безотносительно вопроса «почему так мало», это говорит о том, что если у меня возникнут по нему вопросы, в мире найдутся очень немного людей, способных мне помочь.
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, bazis1, Вы писали: VD>>Подробнее читай http://martinfowler.com/dsl.html B>Опять ты соскакиваешь с темы и предлагаешь мне убить полдня, читая какой-то мутный талмуд. А конкретных примеров, имеющих отношение к Nemerle так и нет.
Извини, что предложил тебе набраться знаний. Тебе, конечно же, некогда. Ведь трясти надо.
Скрытый текст
Решили как-то сравнить прапорщика с обезьяной. посадили их в две одинаковые комнаты с деревом и бананом на дереве. Обезьяна потрясла, потрясла дерево — банан не падает. видит палка в углу стоит, зацепила банан палкой, сидит и жрёт довольная.
Прапорщик же трясёт пальму трясёт, трясёт, трясёт. Час трясёт, два трясёт. Ему говорят: "товарищ прапорщик, ну вы вокруг посмотрите, подумайте немного.", на что тот отвечает: "Некогда думать! Трясти надо!"
Иди базарь про таргетинг и прочую муру, а сам тем временем "тряси".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH> Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.
Он языком больше работник. А на практике он просто говорит себе "так другого способа нет" и копипастит. Потом идет на форум и с пеной у рта рассказывает о своей крутости, таргетинге и том как на дженирках и наследовании все проблемы программирования решать.
Трепачь, короче.
Мартышка к старости слаба глазами стала;
А у людей она слыхала,
Что это зло еще не так большой руки:
Лишь стоит завести Очки.
Очков с полдюжины себе она достала;
Вертит Очками так и сяк:
То к темю их прижмет, то их на хвост нанижет,
То их понюхает, то их полижет;
Очки не действуют никак.
"Тьфу пропасть! — говорит она, — и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них".
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.
___
К несчастью, то ж бывает у людей:
Как ни полезна вещь, — цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Ikemefula, Вы писали:
I>Создание лямбды и её вызов ничтожны по сравнению с асинхронной операцией. Более того — ничтожны даже сравнивая со временем переключения контекста.
Во-первых, это это не так. Блокировки разные бывают. Например, spinlock-и.
Во-вторых, бямбда то создается в коде который полезную работу осуществляет, так что тормозится именно она. Тут еще умник предлагает через рефлексию автоматизацией заниматься. Вас послушать и компилируемый язык превратится в тормоз почище интерпретируемого.
В-третьих, выделение памяти влияет на все приложение, так как дает нагрузку на ЖЦ.
В-четвертрых, это только пример и ситуации в жизни бывает самые разные. Городить кучу лямбд для решения несвойственных им задач приведет к замусориванию кода и деградации производительности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Константин, Вы писали:
VD>>Не очень то наглядно К>Вкусовщина.
На одном примере еще можно поспорить. Когда вся программа такими "решениями" забита она превращается в говнокод.
VD>>медленно, так как ни за что, ни про что получаем создание лямбды и ее вызов. К>В задачах, настолько критичных к производительности что "создание лямбды и ее вызов" это медленно, противопоказан не только C#, ещё весь .NET.
Не могу согласиться с подобным мнением. Примеров противоречащих ему масса. Например, код VS или ReSharper не могут себе позволить такую роскошь. В по началу понаписали кода с лямбдами, а потом специально сидели его вычищали, так как профайлинг показал, что он втыкает.
Ну, рассуждения детские какие-то. Типа пришел фанат ц++ и всем нос утер. Дотнет давно используется для кучи задач где производительность крайне важна. И терять ее на пустом месте нет никакого смысла. А уж использовать расточительство к ресурсам как оправдание для собственной отсталости — это вообще ни в какие ворота.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Nemerle через 5 лет - выстрелит или скончается?
Так усложняет чтение кода...
К>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.
Пойди сделай с его помощью тот же await lock. T4 — это примитивная форма метапрограммирования с кучей ограничений. Лучше чем ничего, но с макросами не сравнить по мощности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WolfHound, Вы писали:
WH>> Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.
VD>Он языком больше работник. А на практике он просто говорит себе "так другого способа нет" и копипастит. Потом идет на форум и с пеной у рта рассказывает о своей крутости, таргетинге и том как на дженирках и наследовании все проблемы программирования решать.
Да-да-да, когда аргументы кончаются, мы переходим на личности и начинаем додумывать за собеседника. Интересно, почему все мелочные неудачники так похожи?
VD>Трепачь, короче.
Слушай, я человеку выше вполне конкретно ответил. Если у тебя баттхерт от того, что фигню, на которую ты потратил кучу времени, почти никто всерьез не воспринимает, то это твои личные проблемы и к обсуждаемой теме они отношения не имеют.
Re[20]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Константин, Вы писали:
К>Ну вы заменили 2 страницы понятного C# кода на полторы страницы непонятного на Nemerle, со всякими def mods = Modifiers(tb.Attributes, [<[ WrapStaticMethods($(tb.ParsedTypeName), $(symbol : string)) ]>]);
Он тебе непонятен только потому, что ты не потрудился АПИ изучить. Лично у меня в нем особо вопросов не возникло. Разве что кое что можно было по короче написать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.
Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе.