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

DS>>>Не надо ля-ля. Ты можешь спокойно использовать Н ничего не зная о макросах.

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

DS>Ну и? Но ты можешь и не вникать в макры:

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

> ты просто пишешь ключевые слова в редакторе и все.

Тоже самое говорят про все языки программирование.

> Когда тебе понадобится что-то большее можно начинать думать о макрах. Чем и хорошь Н — что можно двигаться по ступенькам вверх. А то чем ты занимаешься — это демагогия.

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

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

DS>>Ну и? Но ты можешь и не вникать в макры:
I>Я плохо понимаю, как можно не вникать в то, как работает инструмент. И непонятно, как изучать конкретную вычислительную модель, кроме как читая метакод

Исходники компилятора C# тоже читал чтобы вникнуть в то, как там работает while?

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

DS>>>Ну и? Но ты можешь и не вникать в макры:
I>>Я плохо понимаю, как можно не вникать в то, как работает инструмент. И непонятно, как изучать конкретную вычислительную модель, кроме как читая метакод

EP>Исходники компилятора C# тоже читал чтобы вникнуть в то, как там работает while?

Некорретная аналогия. Макро-программирование именно это и предлагает. Скажем, если я увидел макрос [NotifyPropertyChanged] но ни слухом ни духом про этот паттерн, выбора совсем немного — надо из метакода восстанавливать все детали. И это самый просто случай.

Аналогичный пример — метапрограммирование навроде буст-спирит. Товарищ, который возьмется осваивать комбинаторы парсеров на этом спирите, очень быстро ошалеет. Эта вещь хорошо работает только для того, кто на раз понимает, как работает эта вычислительная модель. Что интересно, реализация recursive descent в лоб без единого макропрограммирования дает очень пологую кривую входа.
Сам подумай — грамматики и парсинг это примерно 2й-3й курс университета. А вот комбинаторы парсеров хорошо понимает совсем небольшое количество людей даже с серьёзным опытом в разработке. За примерами далеко ходить не надо — смотри топик в соседнем форуме.

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

DS>>>>Ну и? Но ты можешь и не вникать в макры:
I>>>Я плохо понимаю, как можно не вникать в то, как работает инструмент. И непонятно, как изучать конкретную вычислительную модель, кроме как читая метакод
EP>>Исходники компилятора C# тоже читал чтобы вникнуть в то, как там работает while?
I>Некорретная аналогия. Макро-программирование именно это и предлагает.

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

I>Скажем, если я увидел макрос [NotifyPropertyChanged] но ни слухом ни духом про этот паттерн, выбора совсем немного — надо из метакода восстанавливать все детали. И это самый просто случай.

Чтобы не нужно было вникать в реализацию, должна быть нормальная документация — какие пред/пост-условия, примеры использования и т.п.

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

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

Или другой пример — Boost.Preprocessor — документация в порядке, примеры есть, разбираться в финтах используемых при реализации абсолютно необязательно.

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

I>>Некорретная аналогия. Макро-программирование именно это и предлагает.

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

Это одно и то же.

I>>Скажем, если я увидел макрос [NotifyPropertyChanged] но ни слухом ни духом про этот паттерн, выбора совсем немного — надо из метакода восстанавливать все детали. И это самый просто случай.

EP>Чтобы не нужно было вникать в реализацию, должна быть нормальная документация — какие пред/пост-условия, примеры использования и т.п.

Ни разу не видел серьезного проекта с полноценной документацией

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

EP>Я вот как раз хотел Boost.Spirit в качестве примера привести. У него внятная документация и примеры использования.

Это не поможет

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

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

EP>Или другой пример — Boost.Preprocessor — документация в порядке, примеры есть, разбираться в финтах используемых при реализации абсолютно необязательно.

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

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

I>>>Скажем, если я увидел макрос [NotifyPropertyChanged] но ни слухом ни духом про этот паттерн, выбора совсем немного — надо из метакода восстанавливать все детали. И это самый просто случай.
EP>>Чтобы не нужно было вникать в реализацию, должна быть нормальная документация — какие пред/пост-условия, примеры использования и т.п.
I>Ни разу не видел серьезного проекта с полноценной документацией

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

I>Пудозреваю, ты освоил эту область где то еще, и только потом посмотрел в спирит. А что делать тем, кому на голову свалился код целиком в этом спирите ?

Изучать документацию. Так же как и приходится изучать незнакомый язык, при встрече исходного кода на нём.

EP>>Или другой пример — Boost.Preprocessor — документация в порядке, примеры есть, разбираться в финтах используемых при реализации абсолютно необязательно.
I>Я эту хохму слышу постоянно. И постоянно ловлю себя на том, что приходится рыться в коде либы, ибо автор забыл указать например нюансы многопоточности, косяки, безопасности и тд и тд

Это вопрос к качеству реализации. Часто приходилось копаться в багах C# компилятора?
Или ты имеешь в виду, что у авторов библиотеки стандартных макросов не получиться сделать нормальную документацию и реализацию (в то время как у авторов C#, по всей видимости получилось)? Это уже совершенно другой аргумент.

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

I>>>>Скажем, если я увидел макрос [NotifyPropertyChanged] но ни слухом ни духом про этот паттерн, выбора совсем немного — надо из метакода восстанавливать все детали. И это самый просто случай.
EP>>>Чтобы не нужно было вникать в реализацию, должна быть нормальная документация — какие пред/пост-условия, примеры использования и т.п.
I>>Ни разу не видел серьезного проекта с полноценной документацией

EP>В исходниках C# приходилось копаться?

Дотнет как раз избавляет от этой необходимости. Немерле — усугубляет.

EP>Так и тут же речь идёт о базовых макросах — считай что ты учишь язык, а не стандартные макросы.

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

I>>Пудозреваю, ты освоил эту область где то еще, и только потом посмотрел в спирит. А что делать тем, кому на голову свалился код целиком в этом спирите ?

EP>Изучать документацию. Так же как и приходится изучать незнакомый язык, при встрече исходного кода на нём.

То есть, метапрограммирование, требует другой подход к ревью, хранению кода, документированию и тд и тд.

EP>>>Или другой пример — Boost.Preprocessor — документация в порядке, примеры есть, разбираться в финтах используемых при реализации абсолютно необязательно.
I>>Я эту хохму слышу постоянно. И постоянно ловлю себя на том, что приходится рыться в коде либы, ибо автор забыл указать например нюансы многопоточности, косяки, безопасности и тд и тд

EP>Это вопрос к качеству реализации. Часто приходилось копаться в багах C# компилятора?

Нечасто, в том то и дело.

EP>Или ты имеешь в виду, что у авторов библиотеки стандартных макросов не получиться сделать нормальную документацию и реализацию (в то время как у авторов C#, по всей видимости получилось)? Это уже совершенно другой аргумент.

Именно это и имею ввиду. Меня интересует реальное положение дел, а не гопотетически достижимое.

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

EP>>Изучать документацию. Так же как и приходится изучать незнакомый язык, при встрече исходного кода на нём.
I>То есть, метапрограммирование, требует другой подход к ревью, хранению кода, документированию и тд и тд.

Ещё раз, в этой ветке обсуждается использование Nemerle без метопрограммирования, то есть только готовые стандартные макросы, или написанные "специально обученными людьми" (с документацией, примерами, тестами и приферансом).

EP>>Или ты имеешь в виду, что у авторов библиотеки стандартных макросов не получиться сделать нормальную документацию и реализацию (в то время как у авторов C#, по всей видимости получилось)? Это уже совершенно другой аргумент.
I>Именно это и имею ввиду. Меня интересует реальное положение дел, а не гопотетически достижимое.

В целом идея "не хочешь МП — используй просто стандартные макросы как будто это часть языка" рабочая. И я думал что спор идёт об этом.
А вот какое реальное положение дел в Nemerle я не знаю.
Да и вообще не представляю выживет ли он с таким мощным антипиаром от VladD2 А ведь хотелось бы чтоб выжил — как минимум в качестве живого доказательства практичности идеи, а там смотри и mainstream подтянется.

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

EP>>>Изучать документацию. Так же как и приходится изучать незнакомый язык, при встрече исходного кода на нём.
I>>То есть, метапрограммирование, требует другой подход к ревью, хранению кода, документированию и тд и тд.

EP>Ещё раз, в этой ветке обсуждается использование Nemerle без метопрограммирования, то есть только готовые стандартные макросы, или написанные "специально обученными людьми" (с документацией, примерами, тестами и приферансом).

Это всё равно что использовать С# в отрыве от фремворка.

EP>>>Или ты имеешь в виду, что у авторов библиотеки стандартных макросов не получиться сделать нормальную документацию и реализацию (в то время как у авторов C#, по всей видимости получилось)? Это уже совершенно другой аргумент.
I>>Именно это и имею ввиду. Меня интересует реальное положение дел, а не гопотетически достижимое.

EP>В целом идея "не хочешь МП — используй просто стандартные макросы как будто это часть языка" рабочая. И я думал что спор идёт об этом.

И об этом тоже. В языке основной тред это метапрограммирование, потому без макров ну никак не выйдет

EP>А вот какое реальное положение дел в Nemerle я не знаю.
EP>Да и вообще не представляю выживет ли он с таким мощным антипиаром от VladD2 А ведь хотелось бы чтоб выжил — как минимум в качестве живого доказательства практичности идеи, а там смотри и mainstream подтянется.

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

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

I>Там вообще-то MVVM, который является очень хорошим решением для интерактивных интерфейсов. MVC больше подходит для статичного рендеринга

MVC неплохо подходит для всего, даже для REST-сервисов. И с MVVM в лице того же нокаута он прекрасно стыкуется.

I>, и его выбор в популярных фреймворках, имхо, скорее обусловлен тем, что основная масса пользователей с MVC уже знакома.

Я тебе просто напомню, что MVC стартовал как небольшой побочный проект и очень быстро набрал популярность. Еще до того как его включили в веб-платформу.

I> Ну и тем, что MVVM вышел из под крыла MS.

Самому не смешно?

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

EP>Исходники компилятора C# тоже читал чтобы вникнуть в то, как там работает while?

Для C# есть стандарт.

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

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

Проблема в том, что мне тут уже предлагали переписать if. Заметь, без каких либо хитрых задач.
Для того чтобы Немерле можно было использовать как ты говоришь — нужно вылизать до блеска некоторый базовый набор макросов + плюс устранить все шероховатости типа нестандартных скобок для параметров дженериков. А потом для этого базового набора макросов зафиксировать стандарт.
Вот тогда можно будет говорить о том, что для чтения совсем чужого кода мне относительно редко придется заныривать в потроха макросов.
А по ка имеем что имеет — совсем неслучайные постоянные отсылы к макросам. И пока не будет понимания, что сами по себе макросы в отдельном языке не обладают практической ценностью, более менее крупного коммьюнити у Немерле не будет.
В чем разница с метапрограммированием на шаблонах в С++, думаю, из вышесказанного ты выведешь сам.

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

G>Ну т.е. в C# "два синтаксиса для if" их, надо понимать, не пугает.

Почему не пугает? Тоже косяк. Но этот косяк тянется еще из времен С, так что прошит на подкорку большинства программистов.

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

EP>В целом идея "не хочешь МП — используй просто стандартные макросы как будто это часть языка" рабочая. И я думал что спор идёт об этом.

Рабочая. Именно этот подход использовал.
Немного воспоминаний Я начинал писать еще под DOS — Quick Basic, Borland C++, Macroassembler. Писал решения диф уравнений числовым методом — причем что-то вроде DSL-я — элементы: интегратор, переключатель и пр. Т.е. например, программа рисовала график напряжения в переходном процессе в определенно заданной электрической схеме при замыканнии/размыкании переключателя. Причем задача решалась легко даже в схемах с несвязанными контурами, что аналитически не решалось.

EP>А вот какое реальное положение дел в Nemerle я не знаю.

Резюмирая ветку: Икемефула занимется демагогией. Начать со страницы C# differences можно легко. И не разу не потребовалось лезть в недра реализации, например foreach. Причина его неприятия Н не в самом языке. Он мне все больше и больше напоминает капризную барышню с затаенными обидками.

EP>Да и вообще не представляю выживет ли он с таким мощным антипиаром от VladD2 А ведь хотелось бы чтоб выжил — как минимум в качестве живого доказательства практичности идеи, а там смотри и mainstream подтянется.

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

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

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

EP>>Исходники компилятора C# тоже читал чтобы вникнуть в то, как там работает while?

AVK>Для C# есть стандарт.

Ну конечно есть. MS так нехило его пропихнули.

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

AVK>>Для C# есть стандарт.
DS>Ну конечно есть. MS так нехило его пропихнули.

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

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

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

I>>Там вообще-то MVVM, который является очень хорошим решением для интерактивных интерфейсов. MVC больше подходит для статичного рендеринга
AVK>MVC неплохо подходит для всего, даже для REST-сервисов. И с MVVM в лице того же нокаута он прекрасно стыкуется.
Абсолютно согласен.

I>>, и его выбор в популярных фреймворках, имхо, скорее обусловлен тем, что основная масса пользователей с MVC уже знакома.
AVK>Я тебе просто напомню, что MVC стартовал как небольшой побочный проект и очень быстро набрал популярность. Еще до того как его включили в веб-платформу.
Да, но основное применение он нашёл в веб фреймворках. Именно потому что он идеально вписывается в stateless архитектуру.

Для приложений, в которых представление связано с моделью биндингами, имхо, лучше подходит MVVM. То, что популярные client-side фреймворки выбрали MVC, это повторюсь в угоду пользователям, которые просто привыкли к MVC. MVVM
в таких сценариях удобнее.

I>> Ну и тем, что MVVM вышел из под крыла MS.
AVK>Самому не смешно?
Почему должно быть? У Open Source сообщества есть определённая неприязнь ко всему, что делает МС.

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

I>Да, но основное применение он нашёл в веб фреймворках.

???

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

Ты опять противопостовляешь MVC и MVVM, в то время как они прекрасно друг друга дополняют. Ну да бог с ним, с MVC. Речь не о том. MVVM, точно так же как и MVC, облегчает разделение представления и логики. А в вашем примере, напоминаю, все с точностью до наоборот, логика тщательно размешана с представлением.

I>>> Ну и тем, что MVVM вышел из под крыла MS.
AVK>>Самому не смешно?
I>Почему должно быть? У Open Source сообщества есть определённая неприязнь ко всему, что делает МС.

И именно поэтому MVC популярен. Интересная логика.

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

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

I>>Да, но основное применение он нашёл в веб фреймворках.
AVK>???
!!!

I>>Для приложений, в которых представление связано с моделью биндингами, имхо, лучше подходит MVVM.
AVK>Ты опять противопостовляешь MVC и MVVM, в то время как они прекрасно друг друга дополняют.
Потому что это разные паттерны. Вместе они не могу ужиться никак. Их "содружество" возможно только в слечае если один находится на клиенте, другой на сервере.

AVK>Ну да бог с ним, с MVC. Речь не о том. MVVM, точно так же как и MVC, облегчает разделение представления и логики. А в вашем примере, напоминаю, все с точностью до наоборот, логика тщательно размешана с представлением.
Попытался бы хоть разобраться. Ничего там не перемешано.

I>>>> Ну и тем, что MVVM вышел из под крыла MS.
AVK>>>Самому не смешно?
I>>Почему должно быть? У Open Source сообщества есть определённая неприязнь ко всему, что делает МС.
AVK>И именно поэтому MVC популярен. Интересная логика.
Нет. Именно поэтому MVVM не так популярен, как MVC. Хотя тот же AngularJS начали фактически с MVC и пришли в конце концов к MVVM.

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

I>Потому что это разные паттерны.

Аргументище!

I> Вместе они не могу ужиться никак.

У кого не могут, а у кого и вполне уживаются.

AVK>>И именно поэтому MVC популярен. Интересная логика.
I>Нет. Именно поэтому MVVM не так популярен, как MVC.

Вот ведь МС какая злая Вот только и ASP.NET MVC тоже из МС произошел, такая незадача.