Nemerle через 5 лет - выстрелит или скончается? - Nemerle

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

B>>>б) сделать это лучше конкурентов
DS>>Решено. А они только еще Рослин лобзиком выпиливают.

I>Лучше имеется ввиду качество, экономический эффект и тд. Здесь очень хочется познакомиться с методикой оценки.

Ок. Базис1 вроде как обещал предоставить методику оценки. Иначе зачем он об этом упоминал?

B>>>в) сделать это настолько лучше конкурентов, чтобы перекрыть риски перехода на новый продукт
DS>>А как оценить риски? Слишком много в этой оценке субъективизма.

I>Так же, как это делают в серьёзных проектах. Например один из первых рисков — качество инструментов разработки. Следующий — внятная поддержка в будущем. Далее — малое количество людей которые понимают хотя бы функциональное программирование, далее — еще меньшее количество людей которые умеют внятно спроектировать ДСЛ не говоря о том, что еще и реализовать его на макрах.
I>Еще риски — поддержка новых платформ, как это было с Silverlight и тд.

Ма-ла-дец. Ты сам все сказал. Нет никаких гарантий. Вот такая крупная и большая МС, а взяли и передумали с Сервелатом. А вот взяли и прекратили поддержку iehost.dll в Осле. Сначала статьи были: "это круто и безопасно", а потом просто идите на йух без объяснения причин.
Ты напоминаешь мне мою девушку. И я и она были в браке неоднократно. Но вот в загс веди и все тут — я хочу гарантий. Говорю ей, печать в паспорте не гарантия от развода и расставания. Но нет — какой-то в уме стереотип и все

DS>>А что за смысл ты вложил в слово "изящность"? Интересно узнать.

I>Скорее всего это разные макро-ДСЛ.

Не будем гадать за автора "изящности".

B>>> Поэтому, я не думаю, что за 5-10-15 лет что-то кардинально изменится. Любители пилить код есть и будут всегда, а индустриальное использование будет оставаться совершенно другим миром...

DS>>Ага. Странно, что любители пилить код в данный момент индустриально работают в JetBrains

I>Если Джетбрейнс массово перешла, переходит или планирует перейти на Немерле, то это аргумент. Если нет — то твой аргумент просто фейл, эпик фейл.

Наверное, они просто так этим занимаются. Для лулзов.

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

Эээ... Чего? Программная воздушно десантная команда быстрого реагирования

Ты тоже с Базисом что-то куришь?

I>Скажем, для проектов на функциональных языках, навроде F#, Erlang, Haskell, Closure это очень болезненный шаг.
I>Прямо сейчас одна контора хочет перенести в наш регион разработку на функциональщине, в частности Closure и разной подобной экзотике. Треш, не передать словами — 99% кандидатов не могут пройти собеседование от слова совсем.

DS>>И да, мы знаем множество примеров, программ полученных в результате "индустриального использования", которые просто говно

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

При этом они могут оставаться говном. И, кстати, штат, который мог бы быть в разы меньше и прочее. Теплое != мягкое.

I> Что там Немерле наокупал в джетбрейнс ?

Ну вот как. Как отвечать на эти говновопросы?
Ты часто употребляешь наркотики? Отвечай только да или нет.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

VD>У меня вот ребенок тоже на красивые упаковки падок. Но я его учу, что не в каждой красивой упаковке лежит вкусная начинка. Даю убедиться в этом на практике. Она учится. Ей всего 4 года. Надеюсь, что когда она вырастит, то научится отличать дерьмо в красивой упаковке от вещей в невзрачной. Но вы же взрослые люди, а таких элементарных вещей не освоили.

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

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

VD>>Как язык Немерл в разы лучше того же Шарпа. И задачи он позволят решать намного удобнее и лучше конкурентов. Оценка рисков это чисто субъективный процесс, так что при некотором объеме предвзятости риски будут всегда выше любых разумных соображений.
B>Ну, блин, расскажите кто-нибудь нормальным языком, что он решает лучше C#. А то как сектанты долбанные какие-то, "Nemerle круче всех", "Nemerle — сила", " Nemerle — расширяемый", "на Nemerle написан компилятор C#", а конкретики ноль. В лучшем случае отправляете ваши талмуды читать.

Ты конечно, извини, если обижу. Но, во первых, не талмуды, а во вторых чтобы что-то изучить — надо что-то почитать. Или нам здесь на форуме тебя просветить? Или по языку C# тебе благословение свыше во сне снизошло?

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

AM>Дает. Ибо база языка была рождена не Васей Пупкиным долгими ночами в своей детской комнате (php?).

То–то, я гляжу, пхп никто не использует, а все пишут на Скале.

AM>Это какие такие у скалы проблемы?

Там куча концепций не выразимых в яве. Если тебе это интересно, задай вопрс в Декларативном программирование.

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

DS>Ты конечно, извини, если обижу. Но, во первых, не талмуды, а во вторых чтобы что-то изучить — надо что-то почитать. Или нам здесь на форуме тебя просветить? Или по языку C# тебе благословение свыше во сне снизошло?
Конкретно по C# меня много лет назад достало пилить GUI на WTL и я решил попробовать другие фреймворки. WinForms оказался хорошим решением (ускоряющим написание GUI засчет автоматизации ряда вещей типа управления памятью и лучшей интеграции с редактором), что и послужило толчком к переходу меня на C#. Конкретная проблема (низкая эффективность разработки GUI) — конкретное решение. Приступа "а не прочитать ли мне 500-страничный талмуд про (случайно выбранный C#) просто так?" не возникало.

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

J>Не совсем. Вот шаблоны используешь, но при этом не платишь — потому что все в compile time и затачивается именно под твою архитектуру, безо всяких runtime-оберток.

J>Иными словами, если в С++ добавляется фича, то она не должна в идеале приводить ни к каким дополнительным расходам, даже если ее используешь. Если фича требует каких-то накладных расходов — это должна быть суперфича, чтоб ее решили включить в язык.
Макросы немерла обладают ровно этими свойствами но в 1000 раз проще и мощнее чем шаблоны С++14.
И в отличие от монолитных языков ты можешь использовать ровно те макросы, которые тебе нужны.
Из этого, кстати, следует весьма забавное свойство: Языковые фичи могут не только появляется. Но и исчезать. Так же как сейчас исчезают плохие библиотеки.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

DS>

DS>Мужик пилит дерево, к нему подходит другой и говорит:
DS>— Мужик, давно пилишь?
DS>— 3 дня.
DS>— А может Тебе пилу заточить? Мы тут с пацанами в гараже новую точилку придумали, ищем, на ком бы ее опробовать.
DS>— Некогда мне, пилить нужно.

DS>Ну ты просто мастер аналогий. Жесть. Бензин — ЯП. Да... Трехтомник... Ты одну хотя-бы статью прочти. Или тебе пилить надо?

Мне нужно понять, что "новая уникальая точилка, над которой работают аж 3 человека" таки принесет плоды, а не поломает на моей пиле половину зубьев типа "ну не шмогла". Реальность такова, что всяких петриков, работающих над "революционными решениями" в разы больше, чем реально качественных решений и тратить время на чтение талмудов каждого Пертика — жизни не хватит. Поэтому бремя доказательства, что продукт реально стоит времени пользователей, лежит на его авторах. Я не говорю, что это хорошо, или справедливо, я просто пытаюсь на пальцах объяснить, как работает мир...

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

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

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

VD>Не учи отца... Я не один килобакс на софте и журналах, в своей жизни, заработал. Язык это совсем другая история. И зарабатывание денег тут не причем.
И при этом ни разу не пришлось заниматься анализом целевой аудитории, формулировкой критичных фич, созданием landing pages, участием в trade shows с ответами на неожиданные вопросы посетителей по твоему продукту? Или "заработал" это гранты/зарплата?

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

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

_>Спили мушку ковбой. У меня был ком продукт на килобаксы. Не ухахатываюсь.
Т.е. тебя абсолютно не смущает, что на вопрос "чем ваш продукт лучше конкурентов" никто в упор не дает внятного ответа?

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

EP>Немного offtopic: а какие у Nemerle основные принципы дизайна? Какова основная идея? Чем руководствуются создатели при принятии тех или иных решений?
EP>Например если взять C++, Pascal, Python и даже C# — то там всё сразу понятно зачем и почему.

Предлагаю тебе сначала описать, что ты имеешь в виду под "принципы дизайна". Мне вот по Немерлу сразу понятно зачем и почему (ц). Давай ты опишешь то что ты имеешь в виду для C#, а я попробую в этом же стиле тебе тоже самое по Немерлу описать.

ЗЫ

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

Компилятор доступен. Материалов по нему выше крыши. Бери и пробуй, а не выдумывай какую-то муть о принципах дизайна.

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

VD>Задолбался это делать много лет назад. Большая часть людей или тупо не хочте потратить время чтобы попробовать, или вообще, начинает искать "аргументы", чтобы обосновать почему Немерл не нужен.
Ну сделай FAQ и скинь ссылку на него. И да, большинство людей не горит желанием пробовать все подряд, что попадает в зону их внинмания. Так устроен мир.

VD>Сектанты — это вы. Вместо того чтобы взять, попробовать, оценить и помочь в развитии, вы сидите на форуме и рассказываете тем нам (тем кто уже попробовал, оценил и помогает в развитии) о том какие мы сектанты.
Кто "мы"? Люди, населяющие планету Земля, за исключением нескольких человек, пилящих немерл?

VD>Так для справки. Я не автор Немерла. Я всего лишь увидел его и стал помогать проекту. Так же я являюсь его пользователем. Пишу на нам софт. Написал не мало уже. В отличии от форумных болтунов могу судить о языке не по наслышке.
И? У чистого Си миллионы последователей, написавших на нем много софта и готовых с пеной изо рта доказывать, что C++ — это зло. Наличие пользователей — не аргумент. Аргумент — наличие решений конкретных задач.

VD>Тебе то что? Ты же сюда пришел доказать, что что-то не нужно. Мне не интересно тратить на вас свое время. Если есть интерес, найти описание проекта не сложно...
VD>Рад буду ответить на конкретные технические вопросы. А доказывать что-то очередному форумному гуру маркетинга и софтостроения я не хочу. Не обижайся.
Я не гуру маркетинга и софтостроения. Я обычный пользователь, который мог бы потенциально быть пользователем вашего продукта, если бы вы умели его продавать. Но, судя по всему, вас устраивает ситуация "мы тут 3 гения пилим мега-продукт, а весь остальной мир — несправедливая секта, которая из-за собственной ущербности не желает им пользоваться. поэтому мы будем пилить дальше и ныть о несправедливости бытия и отсутствии миллионов на маркетинг".

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

WH>Макросы немерла обладают ровно этими свойствами но в 1000 раз проще и мощнее чем шаблоны С++14.
WH>И в отличие от монолитных языков ты можешь использовать ровно те макросы, которые тебе нужны.
Какие проблемы конечного пользователя решают ваши волшебные макросы?

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

EP>Немного offtopic: а какие у Nemerle основные принципы дизайна? Какова основная идея?

Ну, на это любой РСДНовский завсегдатай ответит, даже посещая форум Немерлы раз в год!

Основа Немерле — это МАКРОСЫ. Имея небольшую базу, весь остальной язык написан именно на них. В чём радость? В том, что эти макросы доступны не только команде Немерле, но и вообще ВСЕМ ПРОГРАММИСТАМ! То есть не надо ждать 5 лет, пока всхЛипперт придумает очередную отмазу "почему у нас до сих пор нет multiple return values" — ты просто садишься за IDE и сам пишешь себе фичу — с блэкджеком и параметрами. Таким образом, ты не просто добавляешь какую-то перделку в библиотеку, а создаёшь полноценный DSL, позволяющий тебе писать намного более безошибочный, интуитивно понятный и краткий код.

EP> Чем руководствуются создатели при принятии тех или иных решений?

Как обычно — разумностью.

Практикой. Удобством. В Немерле есть даже специальный модуль imperative, чтобы мы, шарповоды, могли легче адаптироваться к языку.

В общем, Немерле — он как ДВС в 17 веке — вроде бы у некоторых возникает просветление, что это будущее, но пока большинство запрягает лошадей, очень трудно убедить это большинство помочь полировать цилиндры.

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

DS>Ма-ла-дец. Ты сам все сказал. Нет никаких гарантий. Вот такая крупная и большая МС, а взяли и передумали с Сервелатом. А вот взяли и прекратили поддержку iehost.dll в Осле. Сначала статьи были: "это круто и безопасно", а потом просто идите на йух без объяснения причин.

Если есть основания не доверять большой фирме, то для маленькой команды все стократ хуже

DS>Ты напоминаешь мне мою девушку.

Ужос, твоя девушка бородатый мужик ростом/весом 192/115 :faceplam:

I>>Если Джетбрейнс массово перешла, переходит или планирует перейти на Немерле, то это аргумент. Если нет — то твой аргумент просто фейл, эпик фейл.

DS>Наверное, они просто так этим занимаются. Для лулзов.

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

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

DS>Эээ... Чего? Программная воздушно десантная команда быстрого реагирования

DS>Ты тоже с Базисом что-то куришь?

Специально для тебя был пример, который ты проигнорировал:

Скажем, для проектов на функциональных языках, навроде F#, Erlang, Haskell, Closure это очень болезненный шаг.
Прямо сейчас одна контора хочет перенести в наш регион разработку на функциональщине, в частности Closure и разной подобной экзотике. Треш, не передать словами — 99% кандидатов не могут пройти собеседование от слова совсем.

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

DS>При этом они могут оставаться говном. И, кстати, штат, который мог бы быть в разы меньше и прочее. Теплое != мягкое.

1 Для начала нужен экономический эффект. Где он ?
2 Экономия издержек имеет смысл только на полностью забитом рынке. В другое время приоритет имеет выход на рынок и прочие вещи, скажем, качественные требования и толковое тестирование.

I>> Что там Немерле наокупал в джетбрейнс ?

DS>Ну вот как. Как отвечать на эти говновопросы?

Прямо. Не знаешь — так и пиши.

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

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

По пресидать и "ку" сказать не надо?
Вот http://rsdn.ru/?/summary/3766.xml куча материала на русском. Там на любой вкус есть.

B>Кто "мы"? Люди, населяющие планету Земля, за исключением нескольких человек, пилящих немерл?

Вы — трепачи лазящие по форумам и ищущие основания почему что-то не надо делать/пробовать.

B>И? У чистого Си миллионы последователей, написавших на нем много софта и готовых с пеной изо рта доказывать, что C++ — это зло. Наличие пользователей — не аргумент. Аргумент — наличие решений конкретных задач.

Вам ни что не аргумент. Плевать вам, что за код существования того же Немерал на нем было написано куча кода. Это очередное обоснование того почему тебе не нужно что-то пробовать/изучать и почему ты обсуждаешь то, что даже не пробовал.

B>Я не гуру маркетинга и софтостроения. Я обычный пользователь, который мог бы потенциально быть пользователем вашего продукта, если бы вы умели его продавать. Но, судя по всему, вас устраивает ситуация "мы тут 3 гения пилим мега-продукт, а весь остальной мир — несправедливая секта, которая из-за собственной ущербности не желает им пользоваться. поэтому мы будем пилить дальше и ныть о несправедливости бытия и отсутствии миллионов на маркетинг".

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

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

EP>>Немного offtopic: а какие у Nemerle основные принципы дизайна? Какова основная идея? Чем руководствуются создатели при принятии тех или иных решений?
EP>>Например если взять C++, Pascal, Python и даже C# — то там всё сразу понятно зачем и почему.
VD>Предлагаю тебе сначала описать, что ты имеешь в виду под "принципы дизайна". Мне вот по Немерлу сразу понятно зачем и почему (ц). Давай ты опишешь то что ты имеешь в виду для C#, а я попробую в этом же стиле тебе тоже самое по Немерлу описать.

Для C++ (цитаты Страуструпа):

The aim of C++ is to help in classical systems programming tasks. It supports the use of light-weight abstraction for resource-constrained and often mission-critical infrastructure applications. The aim is to allow a programmer to work at the highest feasible level of abstraction by providing
* A simple and direct mapping to hardware
* Zero-overhead abstraction mechanisms
The aim is to support a type-rich style of programming. In particular, C++ supports type-safe programming with a non-trivial set of types.
By “light-weight abstraction,” I mean abstractions that do not impose space or time overheads in excess of what would be imposed by careful hand coding of a particular example of the abstraction.

Тут описаны самые общие принципы дизайна. Помимо этого есть и более конкретные/низкоуровневые, например:

* C++’s evolution must be driven by real problems
* Leave no room for a lower-level language below C++ (except assembler)
* What you don’t use, you don’t pay for (zero-overhead rule).
* No gratuitous incompatibilities with C
* It is more important to allow a useful feature than to prevent every misuse
[etc, etc]

Думаю такого описания достаточно, чтобы понять о чём именно идёт речь.

По принципам C# у меня сложилось мнение, но описывать не буду, дабы не давать повода для возможного холивара, который был бы совершенно offtopic. Если кто-то знает официальную/каноничную картину — ссылки лишними не будут.

VD>ЗЫ
VD>На мой взгляд языки по Вики не познаются.

А причём тут wiki? Я зашёл на nemerle.org/About и там в самом начале описания "мульти-парадигменный, много-фичевой и лучше C#". Хотелось бы узнать зачем и почему.

Вот, например, подобное описание по Python'у:

* “Things should be as simple as possible, but no simpler.” (Einstein)
* Do one thing well (The "UNIX philosophy").
...
* Don’t try for perfection because “good enough” is often just that.
...
* The Python implementation should not be tied to a particular platform. It’s okay if some functionality is not always available, but the core should work everywhere.
...
* A bug in the user’s Python code should not be allowed to lead to undefined behavior of the Python interpreter; a core dump is never the user’s fault
...
Tim Peters, a long time Python user who eventually became its most prolific and tenacious core developer, attempted to capture my unstated design principles in what he calls the “Zen of Python.” I quote it here in its entirety:
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
...

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

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

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

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

B>Какие проблемы конечного пользователя решают ваши волшебные макросы?

Конечный пользователь Немерла — это программист, так как Немерл — это язык программирования.

Макросы позволяют:
* Расширять язык необходимыми конструкциями или улучшить имеющиеся. Например, в Немерле почти все операторы — это макросы. И болшинство из них сильно мощнее аналогичных шарповских.
* Создавать встроенные DSL-и для того чтобы решать задачи на более высоком уровне.
* Автоматизировать программирование генерируя код по декларациям. Например, сделать атрибут ToString, который будет автоматически генерировать метод ToString к классам. Или атрибут StructuralEquality, который автоматически реализует методы Equals и GetHashCode.

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

EP>>Немного offtopic: а какие у Nemerle основные принципы дизайна? Какова основная идея?
B>Ну, на это любой РСДНовский завсегдатай ответит, даже посещая форум Немерлы раз в год!

Основа Немерле — это МАКРОСЫ. Имея небольшую базу, весь остальной язык написан именно на них. В чём радость? В том, что эти макросы доступны не только команде Немерле, но и вообще ВСЕМ ПРОГРАММИСТАМ! То есть не надо ждать 5 лет, пока всхЛипперт придумает очередную отмазу "почему у нас до сих пор нет multiple return values" — ты просто садишься за IDE и сам пишешь себе фичу — с блэкджеком и параметрами. Таким образом, ты не просто добавляешь какую-то перделку в библиотеку, а создаёшь полноценный DSL, позволяющий тебе писать намного более безошибочный, интуитивно понятный и краткий код.

Это не идеи или принципы дизайна, а

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

Я выше приводил основные идеи C++ — там, например, ни слова про шаблоны или перегрузку.

EP>> Чем руководствуются создатели при принятии тех или иных решений?
B>Как обычно — разумностью.

Практикой. Удобством.

За всё хорошее, против всего плохого?
Пример: в некий сферический язык можно добавить runtime reflection, а можно не добавлять. Прими решение руководствуясь разумностью, практикой и удобством

_>>Спили мушку ковбой. У меня был ком продукт на килобаксы. Не ухахатываюсь.
B>Т.е. тебя абсолютно не смущает, что на вопрос "чем ваш продукт лучше конкурентов" никто в упор не дает внятного ответа?

В правильно заданном вопросе — обычно содержится половина ответа.

Историю форума полистай — каждый месяц приходит кто-то вопросом почему Nemerle ещё не захватил мир. Отвечаешь, а человек оказывается не за ответом на вопрос пришёл, а пожаловаться на то что мир опять не идеален. И если раньше скептики пытались указать на то что какой-то фичи C# нету, то сейчас уже поняли вроде что всё либо давно есть, либо макросами прикручивается больше чем есть в том C#, и теперь основные претензии "ReSharper'a нету" (ау, скептики, если Nitra выстрелит в заявленом объёме, на неё не то что ReSharper, Идею переведут, слабо такое представить??

), или "мэнеджеры не посадили нас копать на Nemerle, а посадили копать на C#, потому что так нас будет потом легче заменить на новичков с зарплатой поменьше" из чего внезапно делается вывод, что не менеджеры отстой и не они сами не могут себе найти интересную работу, а Nemerle виноват

Почитай историю форума, посмотри в мой профиль — там постмортем проекта который я выкатил в продакшн годы тому назад, ~~когда деревья были мелкие а девки страшные~~ когда N1 был ещё альфой, и задавай внятные вопросы. Не обязательно сразу вида "хотел фичу XXX из YYY, макросами не вышло из-за ZZZ, пофиксил там-то, кому пулл-реквест посылать?", но хоть что-то. Вот известный человек попросил показать пример сравения N1 с T4 в плане метапрограммирования, ему ответили. Вот другой известный человек засомневался в наличии киллер-фичи C#5, убедился что был невнимателен. Т.е. внятные ответы есть, вопросов мало.

B>Не понял. У вашего невмерла нет Edit and Continue и вы всерьез ожидаете, что им кто-то будет пользоваться? Ну браво, чего уж тут...

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

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

_>Эта штука у тебя работает? У меня всё время пишет что вот прям щаз нельзя, но в другой раз точно можно будет... Все релизные апдейты на студию стоят.
Она на методах с лямбдами не работает. Ибо лямбды генерят типы. А если тронуть типы, то E&C отваливается.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

B>Какие проблемы конечного пользователя решают ваши волшебные макросы?

Ну вот пример — прямо сейчас async/await не совместим с lock в C#. Вообще. Т.е. методы содержащие lock() { ... await ... } не будут компилироваться. Имея макросы, ты бы мог решить эту проблему десятком способов, например взять с гугла любой AsyncMutex, сделать свой lock принимающий этот AsyncMutex, и всё готово. Оставаясь на C# ты просто ждёшь, непонятно чего, так как эта фича пока даже не заявлена в C#6, и неизвестно будет ли вообще когда-то заявлена. Как C# решает проблему того что async/await есть, а внятной синхронизации нет? using(IDispoableAsyncMutex)? try{ await AsyncMutex } finnaly { AsyncMutext.Release() } ? Использовать scheduler-обёртку над защищаемым объектом, и стартовать таски в нём? Методы один хуже другого, и все дико не наглядные, тупо мешающие читать код, по сравнению с lock().

Пример макрса для многопоточности readlock, writelock, одного из первых, использованного в реальном проекте. Оно уже годы в продакшене, а на C# как обычно даже в планах нету. Вот так и решает, макрос за макросом, и рукописного кода надо писать всё меньше, на задачу времени остаётся всё больше.

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

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

DS>>Ма-ла-дец. Ты сам все сказал. Нет никаких гарантий. Вот такая крупная и большая МС, а взяли и передумали с Сервелатом. А вот взяли и прекратили поддержку iehost.dll в Осле. Сначала статьи были: "это круто и безопасно", а потом просто идите на йух без объяснения причин.

I>Если есть основания не доверять большой фирме, то для маленькой команды все стократ хуже

Смотря как посмотреть.
Вот решит МС — убрать ХХХ из своих продуктов. Ну не окупается. Или просто в процессе внутрикорпоративных интриг кто-то там победил. И они просто кидают всех через х. Пример из личной практики приводил — iehost.dll. Убрали из .Net 4.5 и все.

DS>>Ты напоминаешь мне мою девушку.

I>Ужос, твоя девушка бородатый мужик ростом/весом 192/115 :faceplam:

Это типа смешная шутка?
Нет моя девушка — девушка. Но ты как и она требуешь гарантий от жизни ради ощущения иллюзии стабильности.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

VD>Здравствуйте, Alexey.Maletin, Вы писали:

AM>>Дает. Ибо база языка была рождена не Васей Пупкиным долгими ночами в своей детской комнате (php?).

VD>То–то, я гляжу, пхп никто не использует, а все пишут на Скале.

И что же хорошего на нём написано? Вконтактик не считается. Им в итоге пришлось свой компилятор пилить.

AM>>Это какие такие у скалы проблемы?

VD>Там куча концепций не выразимых в яве. Если тебе это интересно, задай вопрс в Декларативном программирование.

Но компилируются то они именно в жаба концепции.

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

B>>Какие проблемы конечного пользователя решают ваши волшебные макросы?

_>Как C# решает проблему того что async/await есть, а внятной синхронизации нет?
Одна из дизайн-целей этого async-await была сделать так, чтобы традиционная синхронизация стала не нужна.
Я уже много лет пишу async-await код, мутексы понадобились всего пару раз за это время в очень странных случаях, как например background audio agent для windows phone — по-моему это говорит о том, что у афтаров получилось.

_>Методы один хуже другого, и все дико не наглядные, тупо мешающие читать код
Забыли функциональный метод:

await withLock( aLock, async () =>
{ 
    await something();
} );

По-моему наглядный, и ничего не мешает?

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

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

J>>Не совсем. Вот шаблоны используешь, но при этом не платишь — потому что все в compile time и затачивается именно под твою архитектуру, безо всяких runtime-оберток.

J>>Иными словами, если в С++ добавляется фича, то она не должна в идеале приводить ни к каким дополнительным расходам, даже если ее используешь. Если фича требует каких-то накладных расходов — это должна быть суперфича, чтоб ее решили включить в язык.
WH>Макросы немерла обладают ровно этими свойствами но в 1000 раз проще и мощнее чем шаблоны С++14.
WH>И в отличие от монолитных языков ты можешь использовать ровно те макросы, которые тебе нужны.
WH>Из этого, кстати, следует весьма забавное свойство: Языковые фичи могут не только появляется. Но и исчезать. Так же как сейчас исчезают плохие библиотеки.

Ты мне это так рассказываешь, будто я когда-то с этим спорил

Я вообще большой поклонник всяческой кодогенерации и был бы счастлив иметь нечто похожее на немерлевые макросы в С++ (потому что сейчас в моих проектах и шаблонные метаизвраты, и Boost.Preprocessor, и perl, и xslt, и чего еще только нет — конечно, было бы гораздо лучше, если бы это все объединялось под единой крышей мощной макросистемы типа немерловской — т.е. связанной с типами, перегруженными именами и прочим).

ЗЫ Так что с нетерпением жду Нитры, которая сможет генерить/взаимодействовать с С++. Для меня самый большой (собственно, блокирующий) недостаток Немерла — это ограниченность его дотнетом.

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

AM>И что же хорошего на нём написано? Вконтактик не считается. Им в итоге пришлось свой компилятор пилить.

Считаем. И еще 100500 сайтов тоже считаем. Компиляторов у языка может быть сколько угодно.

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

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

AM>Но компилируются то они именно в жаба концепции.

Это не важно. Важно, что из из Явы полноценно использовать нельзя. Да и с Явой из Скалы, вроде как, проблемы имеются. А вот у Немерла с тем же Шарпом проблем куда меньше и решаются они просто.

Это опять таки к вопросу, что твои аргументы не очень верные.

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

VD>Вы — трепачи лазящие по форумам и ищущие основания почему что-то не надо делать/пробовать.
VD>Вам ни что не аргумент. Плевать вам, что за код существования того же Немерал на нем было написано куча кода. Это очередное обоснование того почему тебе не нужно что-то пробовать/изучать и почему ты обсуждаешь то, что даже не пробовал.
VD>Я уже говорил по этому поводу. Мне не интересно убеждать людей имеющих мнение высосанное из пальца. Я потратил много времени, чтобы написать кучу материала по Немерлу. Там есть и учебники, и объяснения, и много чего еще.
Да-да-да, с таким подходом немерле обязательно взлетит, обретет много новых пользователей и обгонит C# по популярности. Удачи...

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

B>>Какие проблемы конечного пользователя решают ваши волшебные макросы?

_>Ну вот пример — прямо сейчас async/await не совместим с lock в C#. Вообще. Т.е. методы содержащие lock() { ... await ... } не будут компилироваться. Имея макросы, ты бы мог решить эту проблему десятком способов, например взять с гугла любой AsyncMutex, сделать свой lock принимающий этот AsyncMutex, и всё готово. Оставаясь на C# ты просто ждёшь, непонятно чего, так как эта фича пока даже не заявлена в C#6, и неизвестно будет ли вообще когда-то заявлена. Как C# решает проблему того что async/await есть, а внятной синхронизации нет? using(IDispoableAsyncMutex)? try{ await AsyncMutex } finnaly { AsyncMutext.Release() } ? Использовать scheduler-обёртку над защищаемым объектом, и стартовать таски в нём? Методы один хуже другого, и все дико не наглядные, тупо мешающие читать код, по сравнению с lock().
Async/await вроде бы сделан специально для высокоуровневых вещей, где явная синхронизация не нужна, не? Ладно, допустим я ошибаюсь, проведем мысленный эксперимент — опрос среди пользователей C#: нужна ли вам поддержка lock() в асинхронных методах? С 3мя вариантами: нужна в ежедневных задачах, нужна была пару раз, ни разу не сталкивался с необходимостью. Как думаете, наберет первый вариант больше 1%?

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

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

_>>Эта штука у тебя работает? У меня всё время пишет что вот прям щаз нельзя, но в другой раз точно можно будет... Все релизные апдейты на студию стоят.
WH>Она на методах с лямбдами не работает. Ибо лямбды генерят типы. А если тронуть типы, то E&C отваливается.
В VS2013 это частично пофиксили — теперь методы трогать можно, главное не трогать сами лямбды. Ну и LINQ до кучи.

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

VD>Макросы позволяют:
VD>* Расширять язык необходимыми конструкциями или улучшить имеющиеся. Например, в Немерле почти все операторы — это макросы. И болшинство из них сильно мощнее аналогичных шарповских.
Язык — это в первую очередь инструмент. Инструмент, решающий некую задачу. Задача "а не расширить ли мне язык каким-нибудь макросом?" — довольно странная.
VD>* Создавать встроенные DSL-и для того чтобы решать задачи на более высоком уровне.
Опять же, конкретный пример, пожалуйста, где создание DSL вместо использования стандартных паттернов управления сложностью принесет плоды. Ведь со стандартными паттерными хорошо работает отладчик, рефактор и другие функции IDE.
VD>* Автоматизировать программирование генерируя код по декларациям. Например, сделать атрибут ToString, который будет автоматически генерировать метод ToString к классам. Или атрибут StructuralEquality, который автоматически реализует методы Equals и GetHashCode.
Генерировать из чего? В ToString() обычно помещают некую краткую сводку о состоянии объекта, упрощающую просмотр в отладчике, либо в GUI. И каждый метод обычно пишется руками для конкретного класса. Для чего может понадобиться их генерировать, что это упростит? Как будет работать пошаговый прогон отладчиком по такому методу и Edit-and-continue, дабы исправить мелкий баг без перезапуска программы?

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

B>Да-да-да, с таким подходом немерле обязательно взлетит, обретет много новых пользователей и обгонит C# по популярности. Удачи...

В таким как ты никакой подход не подходит. По сему тратить время просто глупо.

А вот Clojure отлично за это время развилась. Учитывая ещё тот факт, что Clojure появилась два года после Nemerle в 2007м, но уже в 2008 вышла первая версия. А теперь у Clojure есть офигенное количество библиотек, документации, книжек и контрибьюторов.

А команда Nemerle всё это время пилила интеграцию с VS...

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

B>Язык — это в первую очередь инструмент. Инструмент, решающий некую задачу. Задача "а не расширить ли мне язык каким-нибудь макросом?" — довольно странная.

Язык — это язык. Сравнивать его с инструментом довольно неразумно. Язык программирование куда ближе к человеческому языку. Вот с ним и сравнивай. Как совершенно естественно расширять свой словарный запас новыми терминами, так совершенно естественно расширять язык новыми конструкциями. Если бы это было не так, то не вышло бы C++ 11/14 и C# 5.0.

B>Опять же, конкретный пример, пожалуйста, где создание DSL вместо использования стандартных паттернов управления сложностью принесет плоды. Ведь со стандартными паттерными хорошо работает отладчик, рефактор и другие функции IDE.

Их тысячи. То что ты сам, возможно, используешь каждый день: Разор, регекспы, Linq/SQL, BNF, CSS, LESS, DOT ... Еще есть встроенные DSL-и о которых только линивый не говорит. Многие прикладные задачи решаются на ДСЛ-ях проще и лучше. Вопрос только в сложности их создания. С макросами этот подход становится доступен прикладным программистам. От части, Нитра призвана еще больше упростить создание и использование ДСЛ-ей и убрать имеющиеся в Немерле ограничения.

Подробнее читай http://martinfowler.com/dsl.html

B>Генерировать из чего? В ToString() обычно помещают некую краткую сводку о состоянии объекта, упрощающую просмотр в отладчике, либо в GUI.

Туда частенько помещают значения полей. Например, для анонимных типов МС сделало дефолтную реализацию ToString, и это удобно. Писать по 100 раз одно и то же хотят не только лишь все (ц).

B>И каждый метод обычно пишется руками для конкретного класса.

Ага. И когда он пишется в 100500-й раз "под одну копирку", невольно возникает вопрос — "Нельзя ли автоматизировать этот мартышкин труд?". И дело тут не в ToString. Это всего лишь один из примеров. Везде когда ты пишешь что-то по одному шаблону можно автоматизировать.

B>Для чего может понадобиться их генерировать, что это упростит? Как будет работать пошаговый прогон отладчиком по такому методу и Edit-and-continue, дабы исправить мелкий баг без перезапуска программы?

И ты их найдешь, потому что кто хочет сделать дело, ищет возможности, а кто не хочет, ищет оправдания. Вот ты из последний. Иди пили все руками. Копипасть и наслаждайся результатом.

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

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

VD>>Предлагаю тебе сначала описать, что ты имеешь в виду под "принципы дизайна". Мне вот по Немерлу сразу понятно зачем и почему (ц). Давай ты опишешь то что ты имеешь в виду для C#, а я попробую в этом же стиле тебе тоже самое по Немерлу описать.

EP>Для C++ (цитаты Страуструпа): ...

Меня не слышат? Я же попросил "для C#".

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

EP>Думаю такого описания достаточно, чтобы понять о чём именно идёт речь.

Это описание не плохо подходит для С, Дельфи и тучи других языков.

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

EP>По принципам C# у меня сложилось мнение, но описывать не буду, дабы не давать повода для возможного холивара, который был бы совершенно offtopic. Если кто-то знает официальную/каноничную картину — ссылки лишними не будут.

Ну, и о чем с тобой говорить, если ты свое описание заранее оцениваешь как флеймовое?

EP>А причём тут wiki?

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

EP>Я зашёл на nemerle.org/About и там в самом начале описания "мульти-парадигменный, много-фичевой и лучше C#". Хотелось бы узнать зачем и почему.

Я уже давал ссылку где можно найти все ответы.

Как язык он лучше чем C# он почти всем. Перечислять задолбаешся. В кратце, он полноценно поддерживает все парадигмы, кога как у Шарпа поддержка ФП ограничена лямбдами и функциями высшего порядка (все фичи устанешь перечислять, тут тебе и паттерн-матчинг, с алгеброическими типами, и концепция "все является выражением" и много чего еще), а поддержки метапрограммирования нет и в помине. Буквально все в языке хоть чуть-чуть, но лучше шарпа. Даже банальные циклы вроде foreach имеют кучу полезных расширений. Но главное, что в Немерле есть макросы, которых нет ни в C++, ни в C#. С их помощью можно: автоматизировать программирование (генерировать код), расширять возможности языка (синтаксис и семантику), создавать DSL-и. Кроме того компилятор расширяемый. Так что Немерл позволяет компилировать C# и Нитру в составе одно проекта (а кто угодно может добавить поддержку своего языка).

EP>Вот, например, подобное описание по Python'у:
EP>* “Things should be as simple as possible, but no simpler.” (Einstein)

Гениально! Скомуниздили высказывание Энштейна и назвали это описанием концепции языка. А есть на земле вещи для которых эта концепция не является актуальной?

EP>* Do one thing well (The "UNIX philosophy").

Из той же серии. Опупенное знание. Прямо "М-Видео — нам не все равно!" (нам по хрену).

Остальное в том же духе. Что тебе дает этот рекламный бред?
Ведь если я тебе таких агиток накидаю, ты же меня раскритикуешь в пух и прах (и будешь прав).

EP>* The Python implementation should not be tied to a particular platform. It’s okay if some functionality is not always available, but the core should work everywhere.

Для каких языков не актуально это утверждение? Даже Дельфи, на сегодня, перенесено на множество платформ.

EP>* A bug in the user’s Python code should not be allowed to lead to undefined behavior of the Python interpreter; a core dump is never the user’s fault

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

EP>...principles in what he calls the “Zen of Python.” I quote it here in its entirety:
EP> Beautiful is better than ugly.
EP> Simple is better than complex.
EP> Complex is better than complicated.

Богатый лучше чем бедный!
Здоровый лучше чем больной!

EP> Explicit is better than implicit.

Я тоже считаю, что явная типизация лучше чем не явная, но авторы Питона с этим не согласны.

EP> Flat is better than nested.

Питоном создатели МС-ДОС 1.0 занимались, что ли? Они тоже считали, что каталоги для файловой системы не нужны.

Короче — бред. Набор рекламного булшита. Тебе этого надо?

EP>Интересно почему именно этот набор возможностей, в какую сторону возможно развитие, а в какую нет.

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

EP>Я предполагаю что фичи всё-таки добавлялись в соответствии с какими-то принципами, преследуя определённые идеалы, а не как в той байке
EP>

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

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

Вкратце можно сказать, что немерл — это C# в котором исправлены ошибки дизана, добавлена качетвенная поддержка функционального программирования и маро-система. Причем сам язык во многом создан на своих же макросах. Но проще прочесть пару-тройку статей по языку и все станет намного понятнее. Для начала можно прочесть:
http://rsdn.ru/article/nemerle/NemerleIntro.xml
http://rsdn.ru/article/nemerle/NemerleStingFormating.xml
http://rsdn.ru/article/Nemerle/TheNemerleLanguage.xml (первую часть, или все для изучения языка)

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

VD>>Правда несколько отличается от твоих фантазий. C# имеет только два реальных преимущества перед Nemerle на сегодня:
VD>>1. Скорость компиляции.
VD>>2. Поддержка Edit and continue.

I>Внятный рефакторинг нужен вне зависимости от парадигмы

Какая связь моей цитаты и этого утверждения?

VD>>Решарпер — отличный продукт и многие откровенные косяки шарпа сглаживает, но мы почему-то предпочитаем писать сложный код на Nemerle.

I>Сколько лично ты подготовил студентов на немерле ? Сколько вообще студентов у вас использует немерле ?

Опять не вижу связи. У меня не было такой задачи.

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

DS>Ок. Базис1 вроде как обещал предоставить методику оценки. Иначе зачем он об этом упоминал?

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

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

B>Конкретно по C# меня много лет назад достало пилить GUI на WTL и я решил попробовать другие фреймворки.

Если дело было только в GUI, то нужно было просто открыть для себя Qt.

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

EP>А для Nemerle основная идея-то какая? Сделать язык с кучей фич и "лучше C#"?

Хороший подход! Можно продолжить этот ряд.

Порш — это автомобиль с кучей фич и лучше чем Жигули.
Суперджет — это самолет с кучей фич и лучше чем Як-42.

Ну, да. Все так. Только эта куча фич и отличает Порш от Жугулей и Суперджет от Як-42.

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

s22>>Немерли функциональный (но не чисто функциональный), в нем хорошо интегрированы классы и есть ПОЛНОЦЕННЫЕ МАКРОСЫ
AD>Это и есть основная идея немерле?

Вы так говорите, как будто — этого мало.

В Лиспе вообще одни макросы есть, но именно это его основная идея и именно этим он рвет большую часть языков как Тузик грелку.

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

К>Забыли функциональный метод:
К>

К>await withLock( aLock, async () =>
К>{ 
К>    await something();
К>} );
К>

К>По-моему наглядный, и ничего не мешает?

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

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

J>Ты мне это так рассказываешь, будто я когда-то с этим спорил

Я вообще большой поклонник всяческой кодогенерации и был бы счастлив иметь нечто похожее на немерлевые макросы в С++ (потому что сейчас в моих проектах и шаблонные метаизвраты, и Boost.Preprocessor, и perl, и xslt, и чего еще только нет — конечно, было бы гораздо лучше, если бы это все объединялось под единой крышей мощной макросистемы типа немерловской — т.е. связанной с типами, перегруженными именами и прочим).

J>ЗЫ Так что с нетерпением жду Нитры, которая сможет генерить/взаимодействовать с С++. Для меня самый большой (собственно, блокирующий) недостаток Немерла — это ограниченность его дотнетом.

Для генерации и парсинга C++ нитра уже пригодна. Остается только написать грамматику C++. Те же квази-цитаты будут из каробки доступны. Вот типизацию придется подождать.

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

EP>Я выше приводил основные идеи C++ — там, например, ни слова про шаблоны или перегрузку.

Без слов про шаблоны и перегрузку эти слова так же подходят к С и Дельфи, например.

Так что ты хочешь услышать концептуального о C#?

EP>>> Чем руководствуются создатели при принятии тех или иных решений?
B>>Как обычно — разумностью.

Практикой. Удобством.

EP>За всё хорошее, против всего плохого?

Именно это написано в твоих цитатах про Питон. Я сильно ржал когда читал:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.

EP>Пример: в некий сферический язык можно добавить runtime reflection, а можно не добавлять. Прими решение руководствуясь разумностью, практикой и удобством

Какие проблемы? Если язык поддерживает ЖЦ, то наличие рефлексии вполне очевидно. Доп-информацию в объектах все равно хранить надо. В С++ с его идеями экономии на спичках и не рассчитанностью на рефлексию маросов, рефлексия является довольно спорным решением.

К тому же это уже не совсем язык. Например, для С++ в дотнете тоже поддерживается рефлексия. А для Шарпа на телефонах под Моно — нет.

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

VD>>Не лучше ли взглянуть на комиты:

I>Я тебе страшное скажу — смотрят не коммиты, а трекер: https://github.com/rsdn/nemerle/issues
I>С начала года ничего внятного не произошло

Дык тебе докапаться не до чего, вот ты ищешь причины.

Большое количество комитов показывает, что над проектом работают. Раз так, твои рассуждения:

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

высосаны из пальца.

ЗЫ

Зачем ты ходишь на этот форум, если от тебя кроме флуда и флейма ничего нет?
Тебе флеймов не хватает?

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

EP>Для C++ (цитаты Страуструпа)

Это все сводится к ровно двум вещам:
1) Уметь все, что умеет Си, чтоб быть способным заменить Си в ее нише
2) Предоставить клевые фичи (абстракции и т.п.), если только они не будут противоречить фиче 1.

Т.е. Си + абстракции.

В этом смысле Немерле по отношению к шарпу точно в такой же позиции находится, имхо: шарп + макросы.

ЗЫ Продвинутая макросистема никак не противоречит философии С++. По той простой причине, что она целиком compile-time.

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

VD>Здравствуйте, Alexey.Maletin, Вы писали:

AM>>Но компилируются то они именно в жаба концепции.

VD>Это не важно. Важно, что из из Явы полноценно использовать нельзя.

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

VD>Да и с Явой из Скалы, вроде как, проблемы имеются. А вот у Немерла с тем же Шарпом проблем куда меньше и решаются они просто.
VD>Это опять таки к вопросу, что твои аргументы не очень верные.

Аргументы о чём? Что скала — это совместимый язык для jvm с отличной коммерческой, комьюнити и научной поддержкой? Что у щеневмерла этого нет?

Я не пойму, что ты хочешь доказать. Что немерл невероятно круче скалы, но шайтан его пойми, не взлетает чего-то? Может все таки изначальный посыл неверен.

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

AM>>И что же хорошего на нём написано? Вконтактик не считается. Им в итоге пришлось свой компилятор пилить.

VD>Считаем. И еще 100500 сайтов тоже считаем. Компиляторов у языка может быть сколько угодно.

VD>Тот же вопрос "что хорошего написано на Скале?", так же можно поставить. И список будет куда уже.

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

Ну немерлу хотя бы до скалы дорасти.
Что касается мейнстримовости пхп — бизнесу всегда будут выгодны более простые инструменты с более доступными и дешевыми работягами.

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

EP>>Для C++ (цитаты Страуструпа)
J>Это все сводится к ровно двум вещам:
J>1) Уметь все, что умеет Си, чтоб быть способным заменить Си в ее нише
J>2) Предоставить клевые фичи (абстракции и т.п.), если только они не будут противоречить фиче 1.
J>Т.е. Си + абстракции.

Это сейчас ниша C чётко очерчена, а в своё время, под это описание также подходил Objective-C.

J>В этом смысле Немерле по отношению к шарпу точно в такой же позиции находится, имхо: шарп + макросы.

То есть цель — заменить C# в его нише более мощным и гибким языком? Собственно я это и спрашивал.

J>ЗЫ Продвинутая макросистема никак не противоречит философии С++. По той простой причине, что она целиком compile-time.

Так я же и не против продвинутых макросов (пруф), или хотя бы чего-то эквивалентного (пруф), типа mixin в D (грубо говоря, строчка возвращённая constexpr функцией встраивается прямо в код)

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

VD>>>Предлагаю тебе сначала описать, что ты имеешь в виду под "принципы дизайна". Мне вот по Немерлу сразу понятно зачем и почему (ц). Давай ты опишешь то что ты имеешь в виду для C#, а я попробую в этом же стиле тебе тоже самое по Немерлу описать.
EP>>Для C++ (цитаты Страуструпа): ...
VD>Меня не слышат? Я же попросил "для C#".

Это так принципиально для понимания?

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

Ещё раз, это цели и принципы дизайна, а не описание набора фич.

VD>Ну, разве что язык близкий к железу.

Легковесные абстракции над железом, так и есть

EP>>Думаю такого описания достаточно, чтобы понять о чём именно идёт речь.
VD>Это описание не плохо подходит для С, Дельфи и тучи других языков.

Это Delphi-то подходит?

* Leave no room for a lower-level language below C++ (except assembler)
* What you don’t use, you don’t pay for (zero-overhead rule).
* No gratuitous incompatibilities with C

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

Если основная цель создать мощный и гибкий .NET язык, без привязки к каким-то конкретным задачам (помимо тех привязок что даёт .NET) — то почему бы и нет?

EP>>По принципам C# у меня сложилось мнение, но описывать не буду, дабы не давать повода для возможного холивара, который был бы совершенно offtopic. Если кто-то знает официальную/каноничную картину — ссылки лишними не будут.
VD>Ну, и о чем с тобой говорить, если ты свое описание заранее оцениваешь как флеймовое?

Я не описание оцениваю как флеймовое, а то, во что тут обычно вырождается практически любой вопрос по языкам.
ОК, вот моё краткое описание:
Язык программирования для корпоративных информационных систем, опердней и всего подобного. Некоторые руководствующие принципы:
* реализация поддержки конкретных use-case'ов ASAP
* отдельная конкретная фича важнее предоставления обобщённых возможностей позволяющих её реализовать (delegate, await, linq, nullable и т.п.)
* надёжность и безопасность важнее скорости.

EP>>А причём тут wiki?
VD>Ты же оттуда абзац выдрал и начал к нему докапываться.

Ещё раз, абзац вот отсюда: nemerle.org/About
И к нему я не докапывался, а всего лишь спросил — правильно я понял из него основную идею языка.

VD>Как язык он лучше чем C# он почти всем.

То что он лучше, я не сомневаюсь. И с тем что его макросы мощная и полезная фича тоже не спорю.
Я всего лишь спрашиваю какова цель, а не сравнение feature-by-feature.

EP>>* “Things should be as simple as possible, but no simpler.” (Einstein)
VD>Гениально! Скомуниздили высказывание Энштейна и назвали это описанием концепции языка. А есть на земле вещи для которых эта концепция не является актуальной?

Конечно. Python очень простой и лаконичный язык. В C++, например, простоту часто приносят в жертву другим идеалам

VD>Остальное в том же духе. Что тебе дает этот рекламный бред?

Отчего же:

* Don’t try for perfection because “good enough” is often just that.

С другой стороны есть языки которые как раз и стремятся к perfection

EP>>* A bug in the user’s Python code should not be allowed to lead to undefined behavior of the Python interpreter; a core dump is never the user’s fault
VD>Вообще вранье. Не раз слышал о "странном поведении" Питона.

Это цель, а не утверждение.

EP>>Интересно почему именно этот набор возможностей, в какую сторону возможно развитие, а в какую нет.
VD>Набор возможностей потому что он требовался авторам и пользователям языка.

ОК, какие задачи решали авторы и пользователи языка, в каких областях, что им понадобились эти конкретные фичи?

EP>>Я предполагаю что фичи всё-таки добавлялись в соответствии с какими-то принципами, преследуя определённые идеалы, а не как в той байке
EP>>

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

VD>Ты не понимешь что такое Немерл и отсюда у тебя растут неверные вопросы.

"Мощный и расширяемый язык для .NET" — это я неправильно понимаю?

VD>Вкратце можно сказать, что немерл — это C# в котором исправлены ошибки дизана, добавлена качетвенная поддержка функционального программирования и маро-система.

ОК, пока что всё сводится к тому, что это мощный язык-замена для C#, соответственно с той же областью применения — так?

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

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

EP>>>Для C++ (цитаты Страуструпа)
J>>Это все сводится к ровно двум вещам:
J>>1) Уметь все, что умеет Си, чтоб быть способным заменить Си в его нише
J>>2) Предоставить клевые фичи (абстракции и т.п.), если только они не будут противоречить фиче 1.
J>>Т.е. Си + абстракции.
EP>Это сейчас ниша C чётко очерчена, а в своё время, под это описание также подходил Objective-C.

Ну в пунктах выше никаких ниш не упоминается

С++ старался бить Си на его же поле, где бы оно ни было

А Objective-C, все-таки, не совсем то — так слишком много динамики (т.е. рантайм-оверхеда) по сравнению с Си.
То же ООП естественным образом реализуется на Си при помощи указателей на функции (в случае виртуальных функций) и обычных функций (в случае невиртуальных) — и именно это и делается в С++, в отличие от Objective-C, где объекту передается строка, которую надо интерпретировать, с соответствующими тормозами и отсутствием проверки типов аргументов. (Справедливости ради, в K&R тоже с типами аргументов было худо, конечно — но это было до Objective-C.)
Так что Objective-C, скорее, ближе к СОМ-овскому IDispatch, чем к СОМ-овским же скоростным сишным интерфейсам.

J>>В этом смысле Немерле по отношению к шарпу точно в такой же позиции находится, имхо: шарп + макросы.
EP>То есть цель — заменить C# в его нише более мощным и гибким языком? Собственно я это и спрашивал.

Более того, ты это и процитировал с их вики

J>>ЗЫ Продвинутая макросистема никак не противоречит философии С++. По той простой причине, что она целиком compile-time.
EP>Так я же и не против продвинутых макросов (пруф), или хотя бы чего-то эквивалентного (пруф), типа mixin в D (грубо говоря, строчка возвращённая constexpr функцией встраивается прямо в код)

Угу. Хотя мне строковые миксины не нравятся — имхо, это костыль. Реальное решение — это продвинутые макросы.

DS>Это трындец. Сколько программирую, столько же считаю, что фича эдит_энд_континью — нафиг не впилась

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

Её проблема не в ненужности, а в том, что она всё равно нормально не работает. Как только появляется LINQ-выражение, которое надо поправить, студия начинает кричать, что она так не умеет и идите перезапускаться.

B>Async/await вроде бы сделан специально для высокоуровневых вещей, где явная синхронизация не нужна, не? Ладно, допустим я ошибаюсь, проведем мысленный эксперимент — опрос среди пользователей C#: нужна ли вам поддержка lock() в асинхронных методах? С 3мя вариантами: нужна в ежедневных задачах, нужна была пару раз, ни разу не сталкивался с необходимостью. Как думаете, наберет первый вариант больше 1%?

Вопрос нужна ли фича XXX или это что-то редко используемое и в языке нафиг не сдалось, старше меня. Ещё в FIDO обсуждалось, нужны ли C или C-- (был такой), или ассемблер единственный выбор настоящего программиста. Прямо сейчас ребята из клана java доказывают что linq не нужен, и уже почти себя в этом убедили. Создатели C# сходу объяснили нам что не нужны тьюринг-полные шаблоны и множественное наследование. Самые крутые как всегда математики, они реально, наверняка неопровержимо, доказали что GOTO не нужен, всё это программирование сводится только к IF

Сила макросов в том что ты можешь сделать под конкретный проект фичи, которые нужны только тебе и только в твоём проекте. Многопоточность — вот тебе ключевые слова на каждый чих, много работы с БД — и в твоём linq появятся insert, update, delete, commit, rollback, aggregate, count и т.п. Работаешь с JSON/REST — и у тебя вместо жуткого набивания динамиков возможность описать кусок json прямо в твоём коде, и т.д. и т.п. И какую фичу не возьми — она не то что каждому программисту, она одному и тому же программисту <1% проектов нужна будет.

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

J>>>В этом смысле Немерле по отношению к шарпу точно в такой же позиции находится, имхо: шарп + макросы.
EP>>То есть цель — заменить C# в его нише более мощным и гибким языком? Собственно я это и спрашивал.
J>Более того, ты это и процитировал с их вики

Там написано что Nemerle мощнее C#, и что можно использовать его как продвинутый C#. Но из этого не следует что целью была только замена C#.

J>Угу. Хотя мне строковые миксины не нравятся — имхо, это костыль. Реальное решение — это продвинутые макросы.

Да, костыль, самый примитивный, зато мощный. Прикидывая когда продвинутые макросы смогут к нам добраться (C++2y? C++3y?? C++4y!?!?!), я бы не отказался от такого костыля сейчас, тем более гипотетическим продвинутым макросам он никак не помешает.

К>Я уже много лет пишу async-await код, мутексы понадобились всего пару раз за это время в очень странных случаях, как например background audio agent для windows phone — по-моему это говорит о том, что у афтаров получилось.

Эта действительно частный пример узкоспециализированной фичи, нужной в одном проекте. А вот ещё редкая фича:

virtual void Initialize()
{
//такое объявление уходит в тело класса
//но сама переменная видна только внутри этой функции и её наследниках (если protected)
private bool initialized = false; 
if(initialized)
    return;
}

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

К>Забыли функциональный метод:
К>По-моему наглядный, и ничего не мешает?

Я всё-таки предпочитаю using(await lockable), который в dispose отпускается. Но это всё костыли, от недостатка нормальных решений.

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

EP>>А для Nemerle основная идея-то какая? Сделать язык с кучей фич и "лучше C#"?
VD>Хороший подход!

Собственно я и предполагал что так оно и есть, спасибо что подтвердил.

VD>Можно продолжить этот ряд.
VD>Порш — это автомобиль с кучей фич и лучше чем Жигули.
VD>Суперджет — это самолет с кучей фич и лучше чем Як-42.
VD>Ну, да. Все так. Только эта куча фич и отличает Порш от Жугулей и Суперджет от Як-42.

Конечно можно, и принципов-то ведь никаких не было, ни у Порша, ни у Суперджета — были только, как ты говоришь, "рекламный бред", "агитки" и "булшит". А фичи добавлялись спонтанно, ничем не руководствуясь, без всякой цели.
Вообще, если взять Жигули, начать добавлять рандомные фичи, то ведь обязательно получится Порш — так?

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

VD>Большое количество комитов показывает, что над проектом работают. Раз так, твои рассуждения:
VD>

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

VD>высосаны из пальца.

Хороший приёмчик. Когда у меня, бывает, непруха, я тоже так делаю: "Смотри, сколько коммитов. А здесь, вот в этом, я вообще 50 файлов модицировал"

VD>Зачем ты ходишь на этот форум, если от тебя кроме флуда и флейма ничего нет?

Зачем ты повторяешь этот вопрос ? Ответ был даден много раз, ничего не изменилось.

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

VD>>>Правда несколько отличается от твоих фантазий. C# имеет только два реальных преимущества перед Nemerle на сегодня:
VD>>>1. Скорость компиляции.
VD>>>2. Поддержка Edit and continue.

I>>Внятный рефакторинг нужен вне зависимости от парадигмы

VD>Какая связь моей цитаты и этого утверждения?

В преимущества C# нужно добавить наличие полноценных тулов почти на все случаи жизни.

VD>>>Решарпер — отличный продукт и многие откровенные косяки шарпа сглаживает, но мы почему-то предпочитаем писать сложный код на Nemerle.
I>>Сколько лично ты подготовил студентов на немерле ? Сколько вообще студентов у вас использует немерле ?

VD>Опять не вижу связи. У меня не было такой задачи.

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

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

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

Создание лямбды и её вызов ничтожны по сравнению с асинхронной операцией. Более того — ничтожны даже сравнивая со временем переключения контекста.

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

VD>Вы так говорите, как будто — этого мало.

VD>В Лиспе вообще одни макросы есть, но именно это его основная идея и именно этим он рвет большую часть языков как Тузик грелку.

На рынке доля лиспа далеко за гранью статистической погрешности. Это и есть "вет большую часть языков как Тузик грелку" ?

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

VD>Порш — это автомобиль с кучей фич и лучше чем Жигули.
VD>Суперджет — это самолет с кучей фич и лучше чем Як-42.

VD>Ну, да. Все так. Только эта куча фич и отличает Порш от Жугулей и Суперджет от Як-42.

Это заблуждение. Порши и Жигули изначально проектировались под разные цели, отсюда у них совершенно разные конструкции и, следовательно, возможности и ограничения.

Отсюда ясно, что добавляя по фиче в жигули и як-42 никогда не получишь ни порш, ни суперджет.

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

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

EP>>А для Nemerle основная идея-то какая? Сделать язык с кучей фич и "лучше C#"?

VD>Хороший подход! Можно продолжить этот ряд.

VD>Порш — это автомобиль с кучей фич и лучше чем Жигули.
VD>Суперджет — это самолет с кучей фич и лучше чем Як-42.

VD>Ну, да. Все так. Только эта куча фич и отличает Порш от Жугулей и Суперджет от Як-42.

Порш ездит быстрее жигулей в несколько раз.
А суперджет летает быстрее як-42 в несколько раз.

А вот программы на Немерле будут быстрее работать чем на C# ?

PS: Вообще я за то, чтобы проект пилили и дальше. Тем более у вас уже есть финансирование.
А чего еще нужно, чтобы тихой неспешной сапкой проверять гипотезы, по вечерам попивая пивко ?

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

I>На рынке доля лиспа далеко за гранью статистической погрешности. Это и есть "вет большую часть языков как Тузик грелку" ?

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

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

I>>На рынке доля лиспа далеко за гранью статисти\ческой погрешности. Это и есть "вет большую часть языков как Тузик грелку" ?

BC>Ну не скажите. Лисп чуть ли не самый старейший из высокоуровневых языков в мире и пережил всякие там фортраны, коболы и прочье.
BC>В приличных вузах, как минимум, вполне себе преподается.

Где он на рынке ?

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

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

I>>>На рынке доля лиспа далеко за гранью статисти\ческой погрешности. Это и есть "вет большую часть языков как Тузик грелку" ?

BC>>Ну не скажите. Лисп чуть ли не самый старейший из высокоуровневых языков в мире и пережил всякие там фортраны, коболы и прочье.
BC>>В приличных вузах, как минимум, вполне себе преподается.

I>Где он на рынке ?

Не у всех языках миссия оккупировать рынок.
Достаточно что он уже 50 лет "на слуху".
И проектов хватает.
Можно поиграться с статистикой популярности для разных технологий на разных ресурсов здесь:
http://booben.com/Stat?q=%D0%BB%D0%B8%D1%81%D0%BF%20%D1%88%D0%B0%D1%80%D0%BF

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

BC>Не у всех языках миссия оккупировать рынок.
BC>Достаточно что он уже 50 лет "на слуху".
BC>И проектов хватает.

Когда проектов хватает это проявляется в виде вакансий.

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

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

BC>>Не у всех языках миссия оккупировать рынок.
BC>>Достаточно что он уже 50 лет "на слуху".
BC>>И проектов хватает.

I>Когда проектов хватает это проявляется в виде вакансий.

Вакансий действительно мало, но они есть.
Даже не в США, а в Москве

http://hh.ru/vacancy/9185449

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

VD>Для генерации и парсинга C++ нитра уже пригодна. Остается только написать грамматику C++. Те же квази-цитаты будут из каробки доступны. Вот типизацию придется подождать.
Ты очень оптимистичен.
В С++ есть препроцессор.
А вот что на нём творят:
http://www.boost.org/doc/libs/1_56_0/libs/preprocessor/doc/index.html
Посмотри примеры.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

B>>Да-да-да, с таким подходом немерле обязательно взлетит, обретет много новых пользователей и обгонит C# по популярности. Удачи...

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

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

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

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

B>>>Да-да-да, с таким подходом немерле обязательно взлетит, обретет много новых пользователей и обгонит C# по популярности. Удачи...

VD>>В таким как ты никакой подход не подходит. По сему тратить время просто глупо.
B>А ты много видел людей, которые без какой-то ощутимой пользы просто так начинали бы копаться в ваших талмудах?

bazis1 — Да оно круглое!
VladD2 — Нет, оно зеленое.
bazis1 — Вот смотри, есть круг, есть квадрат, а есть вообще треугольник. Но то, о чем мы говорим круг!
VladD2 — Хорошо приведи пример как другая вещь может быть красной, я посмотрю и по аналогии докажу, что эта вещь зеленая.
bazis1 — Стол например квадратный или прямоугольный.
VladD2 — Он зеленый!

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

К>>Забыли функциональный метод:
К>>

К>>await withLock( aLock, async () =>
К>>{ 
К>>    await something();
К>>} );
К>>

К>>По-моему наглядный, и ничего не мешает?

VD>Не очень то наглядно
Вкусовщина.

VD>медленно, так как ни за что, ни про что получаем создание лямбды и ее вызов.
В задачах, настолько критичных к производительности что "создание лямбды и ее вызов" это медленно, противопоказан не только C#, ещё весь .NET.

Здравствуйте, 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 кода, который пишется на один раз), я просто умею применять стандартные механизмы типа того же наследования, которые позволяют избавится от копипасты без перехода на новый язык. И от людей, рекламирующих новое "средство от копипасты" ожидаю наглядной демонстрации, чем их средство лучше стандартных.

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

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

B>>Конкретно по C# меня много лет назад достало пилить GUI на WTL и я решил попробовать другие фреймворки.

VD>Если дело было только в GUI, то нужно было просто открыть для себя Qt.
Я знаю Qt, но для простых задач нахожу C#/WinForms более удобным.

Здравствуйте, 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.

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

U>А вот Clojure отлично за это время развилась. Учитывая ещё тот факт, что Clojure появилась два года после Nemerle в 2007м, но уже в 2008 вышла первая версия. А теперь у Clojure есть офигенное количество библиотек, документации, книжек и контрибьюторов.

U>А команда Nemerle всё это время пилила интеграцию с VS...

Clojure и прочие питоны не совсем удачное сравнение, они намного проще, но есть и удачное. Немерле — полный труп по сравнению со Скалой. В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support. ИМХО кроссплатформа есть главная причина и об этом отцам-основателям говорили пять лет назад. 95% энтузиастов не будут вкладываться в windows-only. Mono никому, включая Мигеля, был уже тогда не нужен.

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

К>Во-первых, добавление фич в язык это ж не бесплатно, например растёт сложность чтения кода.
К>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.

1. заменяя фичу полсотней строк кода чтение не упрощается, а написание увеличивает вероятность ошибки в десятки раз.
2. Часто надо не только генерировать код, а например дополнять или модифицировать.

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

B>Я никогда не копипастю (ну кроме proof-of-concept кода, который пишется на один раз), я просто умею применять стандартные механизмы типа того же наследования, которые позволяют избавится от копипасты без перехода на новый язык. И от людей, рекламирующих новое "средство от копипасты" ожидаю наглядной демонстрации, чем их средство лучше стандартных.

Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, 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 причины почему это может не произойти: бросят писать, увлекутся совместимостью, переделывая язык будут приоритетно поддерживать Нет.
Скала кроссплатформена? И какая этому цена производительности, совместимости и т д? Или имеется ввиду ВМДж?

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

К>Во-первых, добавление фич в язык это ж не бесплатно, например растёт сложность чтения кода.
Это воображаемая проблема. Читать код с использованием неизвестной библиотеки, которая делает что-то сложное обычно намного сложнее. А для простых случав макры никто писать не будет.
Реальная проблема в том, что фичу из языка убрать нельзя.
Даже если 99.999% программистов ей не пользуются.
В то же время ненужные макросы просто исчезнут так же как не нужные библиотеки.

К>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.
Было: http://rsdn.ru/forum/dotnet/4159707.1
Стало: http://rsdn.ru/forum/dotnet/4187035.1

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

s22>Скала по идеи должна отстать от Н2 значительно, сейчас Н1 и Скала по языку в паритете.
В чем? В скорости парсера?

И потом H-2 это разве не просто набор компонент с которыми играются три человека в JB, появившийся полгода назад?

s22>Я вижу 3 причины почему это может не произойти: бросят писать, увлекутся совместимостью, переделывая язык будут приоритетно поддерживать Нет.
Даже если завтра JB бросят 100% усилий на H-2 будет пшик, пока платформу нельзя использовать нигде кроме винды.

s22>Скала кроссплатформена? И какая этому цена производительности, совместимости и т д? Или имеется ввиду ВМДж?
Имеется ввиду что Скала работает на ~100% серверного железа, 80% из которого пашет на *nix.

К>Во-первых, добавление фич в язык это ж не бесплатно, например растёт сложность чтения кода.

Нее, макросы пишут чтобы упрощать чтение кода. Вот например ты сам можешь элементарно запилить макрос для WinForms, оборачивающий каждый вызов к Control'у из метода вызываемого из Thread в Invoke/BeginInvoke. И такой же аналог для WPF через Dispatcher. И будешь вызывать UI и рабочих потоков, без видимых лямбд и делегатов. Точно также foreach упрощает чтение кода, по сравнению с ручной росписью этой фигни.

К>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.

T4 — это обнять и плакать. Запили мне на T4 сериализацию C# объекта в том же проекте, или мемоизацию ответов от веб-сервиса.

N>В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support. ИМХО кроссплатформа есть главная причина и об этом отцам-основателям говорили пять лет назад.

Причина взлёта скалы ровно одна — полнейшая убогость и застой Java. Даже нововведения в Java имеют странности. В такой ситуации любая адекватная замена будет подхвачена на ура. Без скалы вся JVM — кобол

Ровно таже проблема у C++ — дикая перегруженность синтаксиса и груз обратной совместимости с одной стороны, и никакого выигрыша за эту перегруженность с другой. Именно поэтому все с таким энтузиазмом подхватывают очередную замену C++, будь то Go (можно сказать что уже не взлетело), или Rust (будем посмотреть, может реально что-то нормальное получится).

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

s22>1. заменяя фичу полсотней строк кода чтение не упрощается, а написание увеличивает вероятность ошибки в десятки раз.
Если вам нужно копипастить boilerplate код по 50 строк, возможно вы просто плохо умеете C#.
Примеры, которые я видел выше по тредику, прекрасно решаются в рамках обычного C#, при неизменном количестве строк кода, соответственно без роста вероятности ошибок.

s22>2. Часто надо не только генерировать код, а например дополнять или модифицировать.
Опять-таки, если вам часто нужно дополнять или модифицировать код, вы вероятно плохо умеете пользоваться функциональными фичами C# и/или reflection-ом.

К>Похожее можно запилить в имеющемся 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 если обнаружилось что два потока которые логически разделены, вдруг пересеклись. Это всё легко делается макросами, и через прорву рукопашного кода без них.

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

_>запилить макрос для WinForms, оборачивающий каждый вызов к Control'у из метода вызываемого из Thread в Invoke/BeginInvoke. И такой же аналог для WPF через Dispatcher.
Есть очень веские причины, почему так не было сделано.
Возможен deadlock двух потоков, message loop может быть занят блокирующим вызовом, проблемы с COM apartments, проблемы с возвращаемым значением, и ещё вагон других.
В случае с foreach я таких тяжких последствий не вижу, он или работает или нет.

_>T4 — это обнять и плакать. Запили мне на T4 сериализацию C# объекта в том же проекте
Зачем обязательно в том же?
Это же прекрасно делается через reflection.
Вот например один мой вариант сериализатора .NET объектов в странное хранилище.

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

WH>Было: http://rsdn.ru/forum/dotnet/4159707.1
WH>Стало: http://rsdn.ru/forum/dotnet/4187035.1
Ну вы заменили 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"?

В программировании можно всё, вопрос в том сколько ты потратишь человеко-часов в одном случае и сколько в другом.

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

К>Ну вы заменили 2 страницы понятного C# кода на полторы страницы
Кода более чем в два раза меньше. И это на простой задачке.

К>непонятного на Nemerle, со всякими def mods = Modifiers(tb.Attributes, [<[ WrapStaticMethods($(tb.ParsedTypeName), $(symbol : string)) ]>]);
А ты хоть пытался разобраться?

К>Интересно, с этими вот макросами отладчик дружит, как в случае T4?
С макросами и отладчик и ИДЕ дружат отлично.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

К>>Зачем обязательно в том же?
_>Да потому что так явная убогость C#/T4 проявляется в полный рост.
Чудесно, только для продажи nemerle нужно не убогости C# выискивать, а продемонстрировать, для каких задач ему нет нормальной альтернативы.
В случае с сериализацией/десериализацией нормальные альтернативы есть.

_>стандартная реализация ISerializable
Я не использовал. Костылей совсем немного, там у меня довольно чистый код на атрибутах и reflection.

К>>Это же прекрасно делается через reflection.
_>Через reflection я и сам могу.
Имел в виду reflection не на каком-то их этапов сборки, а в runtime.
С требованием про тот же проект я ошибся — оно прекрасно делается и в том же, и в любом другом.

_>В программировании можно всё, вопрос в том сколько ты потратишь человеко-часов в одном случае и сколько в другом.
Ну я вот не вижу преимущества в человеко-часах одного перед другим.

_>>запилить макрос для 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), и т.д. и т.п. — отстутвие каждой такой фича по отдельности вроде как не смертельно. Но когда их нет всех вместе, а особенно нет возможности объявить свою, нужную один раз, но здесь и сейчас, получаешь незабываемое ощущение что убогость языка тебе программировать реально мешает

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

_>Причина взлёта скалы ровно одна — полнейшая убогость и застой Java. Даже нововведения в Java имеют странности. В такой ситуации любая адекватная замена будет подхвачена на ура. Без скалы вся JVM — кобол

Не любая, но в общем верно. Только не совсем понятно какое это имеет отношение к обсуждаемому в ветке вопросу "почему Немерле труп". Мой тезис такой: "в 2014 Немерле не нужен, потому что есть Скала которая лучше во всем". В 2009 это было не так.

_>Ровно таже проблема у C++ — дикая перегруженность синтаксиса и груз обратной совместимости с одной стороны, и никакого выигрыша за эту перегруженность с другой. Именно поэтому все с таким энтузиазмом подхватывают очередную замену C++, будь то Go (можно сказать что уже не взлетело), или Rust (будем посмотреть, может реально что-то нормальное получится).
Это опять же оффтоп, но я придерживаюсь другого мнения. Просто новый язык для системного программирования сложнее интегрировать в экосистему, так как он лежит в фундаменте. Все сильно набравшее популярность последнее время(Python, Scala, Ruby, Clojure, Haskell, Erlang) явно не из этой серии.

Здравствуйте, 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 сработает?

Здравствуйте, 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>>

Здравствуйте, 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 )

_>>Да потому что так явная убогость 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#, работает отладчик, автокомплит, подсветка. Сравни размеры команд работающих над тем и над другим, подумай затратах на то и на другое, о человеко-часах, может увидишь наблюдаемую разницу

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

_>Вот каждый раз когда ты пишешь кусок кода, который ты уже писал для идентичной задачи — ты столкнулся со случаем когда реальной альтернативы, кроме как написать этот кусок кода ещё раз, и в следующем файле ещё раз, у тебя нет.
Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз.

К>>Имел в виду reflection не на каком-то их этапов сборки, а в runtime.
_>Runtime вообще появляются на свет только из-за отсутствия compile-time решений.
Только в очень узкой области так.
Куча задач вообще лучше подходит для интерпретируемых языков, в которых вообще нет компилятора, а только парсер и рантайм.
Причём C# со своими анонимными типами и dynamics заимствует некоторые вещи оттуда, и вовсе не из-за отсутствия compile-time решений.

_>Спроси у C++ников, они вон буст придумали, лишь бы в рантайм не ходить
Мне не надо ни у кого спрашивать, я сам много лет на C++ программировал. Буст придумывали не для этого.

_>И что там было насчёт применимости T4 для задач генерации кода?
Нормально применим, я использовал, когда было нужно.

_>Сравни размеры команд работающих над тем и над другим, подумай затратах на то и на другое, о человеко-часах, может увидишь наблюдаемую разницу
Разницу в том, что nemerle наколеночное поделие, а за рослиным стоит лидер индустрии разработки ПО?
Со всеми вытекающими обстоятельствами про качество реализации, качество и объем поддержки, маркетинг и обучение разработчиков?

_>>Ты перечислил проблемы которые относятся к самим 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 )
Да ничего. Тут главное что ты представил — без любых фич можно жить, но подтормаживать они тебя будут каждая по чуть-чуть и все вместе вполне конкретно.

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

I>В преимущества C# нужно добавить наличие полноценных тулов почти на все случаи жизни.

Добавь. Только исходная мысль была о том, что даже их наличие у Шарпа не достаточно чтобы его предпочесть.

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

Мне еще и этим заняться? Вот раз ты в этом знаешь толк, то и помог бы.

_>>Вот каждый раз когда ты пишешь кусок кода, который ты уже писал для идентичной задачи — ты столкнулся со случаем когда реальной альтернативы, кроме как написать этот кусок кода ещё раз, и в следующем файле ещё раз, у тебя нет.
К>Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз.
foreach{} else{} — давай, придумывай

_>>Спроси у C++ников, они вон буст придумали, лишь бы в рантайм не ходить
К>Мне не надо ни у кого спрашивать, я сам много лет на C++ программировал. Буст придумывали не для этого.
Я тоже настоящий сварщик

Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе.

_>>И что там было насчёт применимости T4 для задач генерации кода?
К>Нормально применим, я использовал, когда было нужно.
Нормально применим только в одном случае — когда у тебя есть готовый источник на базе которого ты будешь генерировать код, и нет никакой необходимости трогать уже сущетсвующий код. Кому-то этого хватает, но с такими ограничениями заявлять что "Для генерации кода есть T4", слишком смело ИМХО.

_>>Сравни размеры команд работающих над тем и над другим, подумай затратах на то и на другое, о человеко-часах, может увидишь наблюдаемую разницу
К>Разницу в том, что nemerle наколеночное поделие, а за рослиным стоит лидер индустрии разработки ПО?
К>Со всеми вытекающими обстоятельствами про качество реализации, качество и объем поддержки, маркетинг и обучение разработчиков?

~~Смешались в кучу кони-люди~~ А причём тут объём поддержки и обучение разработчиков? Ты кодовую базу сравнивал? На разницу в количестве фич умножал? Желаемую разницу в человеко-часах увидел?

Здравствуйте, 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#. Даже безотносительно вопроса «почему так мало», это говорит о том, что если у меня возникнут по нему вопросы, в мире найдутся очень немного людей, способных мне помочь.

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

VD>>Подробнее читай http://martinfowler.com/dsl.html
B>Опять ты соскакиваешь с темы и предлагаешь мне убить полдня, читая какой-то мутный талмуд. А конкретных примеров, имеющих отношение к Nemerle так и нет.

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

	Скрытый текст
	Решили как-то сравнить прапорщика с обезьяной. посадили их в две одинаковые комнаты с деревом и бананом на дереве. Обезьяна потрясла, потрясла дерево — банан не падает. видит палка в углу стоит, зацепила банан палкой, сидит и жрёт довольная. Прапорщик же трясёт пальму трясёт, трясёт, трясёт. Час трясёт, два трясёт. Ему говорят: "товарищ прапорщик, ну вы вокруг посмотрите, подумайте немного.", на что тот отвечает: "Некогда думать! Трясти надо!"

Иди базарь про таргетинг и прочую муру, а сам тем временем "тряси".

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

WH>

Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.

Он языком больше работник. А на практике он просто говорит себе "так другого способа нет" и копипастит. Потом идет на форум и с пеной у рта рассказывает о своей крутости, таргетинге и том как на дженирках и наследовании все проблемы программирования решать.

Трепачь, короче.

Мартышка к старости слаба глазами стала;
А у людей она слыхала,
Что это зло еще не так большой руки:
Лишь стоит завести Очки.
Очков с полдюжины себе она достала;
Вертит Очками так и сяк:
То к темю их прижмет, то их на хвост нанижет,
То их понюхает, то их полижет;
Очки не действуют никак.
"Тьфу пропасть! — говорит она, — и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них".
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.

___

К несчастью, то ж бывает у людей:
Как ни полезна вещь, — цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.

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

I>Создание лямбды и её вызов ничтожны по сравнению с асинхронной операцией. Более того — ничтожны даже сравнивая со временем переключения контекста.

Во-первых, это это не так. Блокировки разные бывают. Например, spinlock-и.
Во-вторых, бямбда то создается в коде который полезную работу осуществляет, так что тормозится именно она. Тут еще умник предлагает через рефлексию автоматизацией заниматься. Вас послушать и компилируемый язык превратится в тормоз почище интерпретируемого.
В-третьих, выделение памяти влияет на все приложение, так как дает нагрузку на ЖЦ.
В-четвертрых, это только пример и ситуации в жизни бывает самые разные. Городить кучу лямбд для решения несвойственных им задач приведет к замусориванию кода и деградации производительности.

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

VD>>Не очень то наглядно
К>Вкусовщина.

На одном примере еще можно поспорить. Когда вся программа такими "решениями" забита она превращается в говнокод.

VD>>медленно, так как ни за что, ни про что получаем создание лямбды и ее вызов.
К>В задачах, настолько критичных к производительности что "создание лямбды и ее вызов" это медленно, противопоказан не только C#, ещё весь .NET.

Не могу согласиться с подобным мнением. Примеров противоречащих ему масса. Например, код VS или ReSharper не могут себе позволить такую роскошь. В по началу понаписали кода с лямбдами, а потом специально сидели его вычищали, так как профайлинг показал, что он втыкает.

Ну, рассуждения детские какие-то. Типа пришел фанат ц++ и всем нос утер.

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

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

К>Во-первых, добавление фич в язык это ж не бесплатно, например растёт сложность чтения кода.

Ну, да. Ну, да. Вместо:

await withLock( aLock, async () =>
{ 
    await something();
} );

Писать:

await lock (awaitLock)
  await something();

Так усложняет чтение кода...

К>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.

Пойди сделай с его помощью тот же await lock. T4 — это примитивная форма метапрограммирования с кучей ограничений. Лучше чем ничего, но с макросами не сравнить по мощности.

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

s22>2. Часто надо не только генерировать код, а например дополнять или модифицировать.

Скорее встраивать в код на высокоуровневом языке. Ведь ДСЛ-и сами по себе редко бывают полезны. Для них нужен "клей" в виде языка общего назначения.

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

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

WH>>

Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.

VD>Он языком больше работник. А на практике он просто говорит себе "так другого способа нет" и копипастит. Потом идет на форум и с пеной у рта рассказывает о своей крутости, таргетинге и том как на дженирках и наследовании все проблемы программирования решать.
Да-да-да, когда аргументы кончаются, мы переходим на личности и начинаем додумывать за собеседника. Интересно, почему все мелочные неудачники так похожи?

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

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

К>Ну вы заменили 2 страницы понятного C# кода на полторы страницы непонятного на Nemerle, со всякими def mods = Modifiers(tb.Attributes, [<[ WrapStaticMethods($(tb.ParsedTypeName), $(symbol : string)) ]>]);

Он тебе непонятен только потому, что ты не потрудился АПИ изучить. Лично у меня в нем особо вопросов не возникло. Разве что кое что можно было по короче написать.

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

VD>Извини, что предложил тебе набраться знаний. Тебе, конечно же, некогда. Ведь трясти надо.
Ты в качестве аргумента кинул ссылку на сайт, предлагающий купить 640-страничную книгу на довольно широкую тему. Давай я тебе в ответ ссылку на Александреску кину, пойдешь молча читать, поблагодарив за знания, или покрутишь пальцем у виска а-ля "какое отношение это имеет к теме дискуссии"?

VD>

	Скрытый текст
	Решили как-то сравнить прапорщика с обезьяной. посадили их в две одинаковые комнаты с деревом и бананом на дереве. Обезьяна потрясла, потрясла дерево — банан не падает. видит палка в углу стоит, зацепила банан палкой, сидит и жрёт довольная. VD>Прапорщик же трясёт пальму трясёт, трясёт, трясёт. Час трясёт, два трясёт. Ему говорят: "товарищ прапорщик, ну вы вокруг посмотрите, подумайте немного.", на что тот отвечает: "Некогда думать! Трясти надо!"

VD>Иди базарь про таргетинг и прочую муру, а сам тем временем "тряси".
Нахамить оппоненту на форуме можно всегда. Только пользователей это вашей замечательной поделке не прибавит. Я же пытаюсь донести мое понимание того, что могло бы прибавить. Посмотрим, что WolfHound ответит.

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

К>Разобраться можно даже в скомпилированном коде. Вопрос в целосообразности тратить на это время.

А тебя не смутили три комента // HACK..., поиск ключевого слова через header.Contains(" static ") и приседания с "prevNamespace" и пространствами имен?

К>Ставлю breakpoint в этом вот макросе и нажимаю "Build project" — breakpoint сработает?

Да, если перед этим зайдешь в свойства проекта в котором он используется и установишь в свойствах проекта, на закладке "Build", значение "Run debugger" в true. А можно, просто, в нужном месте макроса вызвать assert2(false) и запустить компиляцию. Вылетит диалог ассерат, по нажатие Retry запустится отладчик...

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

_>Да ну нафиг. Runtime вообще появляются на свет только из-за отсутствия compile-time решений. Спроси у C++ников, они вон буст придумали, лишь бы в рантайм не ходить

А уж задачи изменения кода, под конкретную ситуацию, я вообще не касаюсь. Посмотрим на Roslyn, может хоть там что-то приличное появится.

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

_>...но и сорцы на C#, прямо в своих проектах. И там, в этих сорцах C#, работает отладчик, автокомплит, подсветка.

Комплит не работает. Подсветка стандартная, студийная. Отладчик работает.

Переведем Немерл на Нитру, заработает все и в высоком качестве.

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

К>Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз.

Да чтобы яму выкопать, всегда можно взять лопату. Еще можно найти 100500 отмазок, чтобы не брать эксковатор. Типа на нем учиться работать надо. Не все фирмы примут эксковатор. Все привыкли к лопате.

Когда имеющиеся решения решают проблему с нужным качеством, то нужды обращаться к макросам, конечно же, нет. Вот только почему-то в нашем коде макросов целая уйма. Все они нужны. Без них работа была бы неподъемной для маленького коллектива.

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

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

Встроить код внутрь шарповских методов с помощью Т4 нельзя. Значит склеивание дсл-ей и автоматизация внутри методов для нас закрыта.

С отдельным файлом тоже оргромная проблема. Его ведь нужно отпарить и стипизировать (извлечь из него информацию, семантику). И тут Т4 нам ничего не предлагает.

Немерл же предлагает отличное решение как для генерации классов и их членов, так и для склеивания ДСЛ-ей внтури тел методов. С его помощью можно интегрировать ДСЛ-и прямо в код. Причем интегрировать "глубоко" (осуществлять проверки ошибок как в самом ДСЛ-е так и в его сопряжении с основным кодом, делать подсветку, отладку и т.п.).

К>>>Имел в виду reflection не на каком-то их этапов сборки, а в runtime.
_>>Runtime вообще появляются на свет только из-за отсутствия compile-time решений.
К>Только в очень узкой области так.

Широта облести определяется только твоей фантазией и опытом. Если у тебя с ними все впорядке, то ты почти все сможешь сделать в компайлтайме. Даже саму рефлексию времени выполнения.

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

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

К>Причём C# со своими анонимными типами и dynamics заимствует некоторые вещи оттуда, и вовсе не из-за отсутствия compile-time решений.

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

Это ли не демонстрация силы макросов?

Ну, и не надо забывать, что именно из-за макросов Немерл в разы удобнее и элегантнее Шарпа. Даже средства имеющие аналоги в Шарпе в Немерле реализованы куда более удобно и мощно. Даже примитивные if и foreach в разы мощнее шарповских аналогов. И если тебе все же что-то нехватает, ты можешь не ждать от моря погоды, а сесть и сделать нужную фичу самому.

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

_>>foreach{} else{} — давай, придумывай

К>Вот готовый http://www-jo.se/f.pfleger/.net-for-else но мне никогда не было нужно такого.

Ага. И получите и распишитесь тормоза от лямбд и убогий синтаксис. И все это на ровном месте.

_>>Я тоже настоящий сварщик

Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе.
К>В С++ конечно, но в C# уже не так однозначно, т.к. runtime намного более годный.

Годный. Но кода на нем получается много и код оплучается медленным. Довольно жалко выбирать компилируемый язык и получать на нем решения медленнее и опаснее чем на интерпретируемом.

К>>>Нормально применим, я использовал, когда было нужно.
_>>Нормально применим только в одном случае — когда у тебя есть готовый источник на базе которого ты будешь генерировать код, и нет никакой необходимости трогать уже сущетсвующий код. Кому-то этого хватает, но с такими ограничениями заявлять что "Для генерации кода есть T4", слишком смело ИМХО.
К>Во-первых очень надуманное ограничение.

Ограничения — это загонять себя в рамки Т4. Кстати, не надо еще забывать, что в нем хорош генерируются только иерархии вроде классов и методов, а вот герерация сложного кода внутри методов с помощью его шаблонизатора делается крайне коряво. Фактически работа скатывается к написанию текстовых строк. О какой-то там гигиене и говорить не рпиходится.

К>Если очень нужно, вполне можно использовать например CodeDOM.

Попробуй, потом расскажешь. Я как раз в 2005-ом с этого начал. Был такое проект R#. В нем я начал делать более качественную версию КодДома. Было даже сделал, но когда я увидел Немерл, то мне стало жаль бездарно потраченное время, так как мой проект ему в подметки не годился.

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

Костыль на костыле, короче.

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

К>Но нужно бывает редко, потому что рефлексия + функциональщина; я например могу по пальцам одной руки пересчитать написанные за карьеру T4 templates, а reflection постоянно использую для разного.

Ты с какими-то совсем не критичными к производительности задачами работаешь. Может тебе просто на скрипты перейти? Надежность, ведь, у решений на рефлексии еще хуже чем у скриптовых.

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

Ну, начались песни о старом. А зачем ты тогда Шарп то используешь? Писал бы на С, раз главное это обучение пользователей, а время на написание кода у тебя не уходит.

К>Кстати про сообщество: на SO два вопроса с тегом nemerle. Для сравнения, там 500 вопросов с тегом clojure, 4000 вопросов с тегом scala, и 140’000 вопросов с тегом C#. Даже безотносительно вопроса «почему так мало», это говорит о том, что если у меня возникнут по нему вопросы, в мире найдутся очень немного людей, способных мне помочь.

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

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

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

B>Да-да-да, когда аргументы кончаются, мы переходим на личности и начинаем додумывать за собеседника. Интересно, почему все мелочные неудачники так похожи?

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

Вот тебе аргумент которого ты заслуживаешь:

Мартышка к старости слаба глазами стала;
А у людей она слыхала,
Что это зло еще не так большой руки:
Лишь стоит завести Очки.
Очков с полдюжины себе она достала;
Вертит Очками так и сяк:
То к темю их прижмет, то их на хвост нанижет,
То их понюхает, то их полижет;
Очки не действуют никак.
"Тьфу пропасть! — говорит она, — и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них".
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.

___

К несчастью, то ж бывает у людей:
Как ни полезна вещь, — цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.

VD>>Трепачь, короче.
B>Слушай, я человеку выше вполне конкретно ответил. Если у тебя баттхерт от того, что фигню, на которую ты потратил кучу времени, почти никто всерьез не воспринимает, то это твои личные проблемы и к обсуждаемой теме они отношения не имеют.

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

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

_>Да это пример был. Представь программирование на C# без foreach. Вот это ощущение что ты регулярно пишешь ненужные но обязательные из-за убогости языка куски кода у тебя будет каждый раз когда ты будешь садиться за C# после Nemerle. В C# нет foreach {} else {}, нет foreach(index, element), и т.д. и т.п. — отстутвие каждой такой фича по отдельности вроде как не смертельно. Но когда их нет всех вместе, а особенно нет возможности объявить свою, нужную один раз, но здесь и сейчас, получаешь незабываемое ощущение что убогость языка тебе программировать реально мешает

Я это называю — "ломка". После того как возвращаешься с Немерла на Шарп в первый раз наступает ужасное ощущение связанности рук. Не хватает того, сего, пятого десятого. Ты выкручиваешься подручными средствами, но в какой-то момент говоришь себе — "Стоп! Хватит! Ради чего я над собой издеваюсь?". И только по переходив туда, сюда начинаешь свыкаться с неизбежностью отсутствия выразительных возможностей.

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

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

I>>Создание лямбды и её вызов ничтожны по сравнению с асинхронной операцией. Более того — ничтожны даже сравнивая со временем переключения контекста.

VD>Во-первых, это это не так. Блокировки разные бывают. Например, spinlock-и.

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

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

Если такие издержки критичны, то однозначно стратегия синхронизации выбрана принципиально неверно.

VD>В-третьих, выделение памяти влияет на все приложение, так как дает нагрузку на ЖЦ.

Ничтожная нагрузка. Замерить такие издержки на лямбды можно только в синхронном коде каких нибудь числодробилок.
Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.

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

К>>В С++ конечно, но в C# уже не так однозначно, т.к. runtime намного более годный.
VD>Годный. Но кода на нем получается много и код оплучается медленным.
Не умеешь значит.

К>>Если очень нужно, вполне можно использовать например CodeDOM.
VD>Попробуй, потом расскажешь.
Пробовал, прекрасно работал.
Например когда-то (в эпоху C# 4.0 + Async CTP) запилил на нём генератор task-based асинхронных WCF клиентов (щас в коробке со студией), и task-based асинхронных реализаций сервера (по-моему до сих пор нет в коробке), на входе — CodeDOM с WCF интерфейсами.

К>>Но нужно бывает редко, потому что рефлексия + функциональщина; я например могу по пальцам одной руки пересчитать написанные за карьеру T4 templates, а reflection постоянно использую для разного.
VD>Ты с какими-то совсем не критичными к производительности задачами работаешь.
Точно не умеешь.
Рефлексия нужна один раз за запуск приложения, построить из type information и закешировать какие-нить функторы.
Если нужна производительность, подойдёт например Expression.Compile, получившийся IL код не будет отличаться по производительности от скомпилированного компилятором.

VD>Надежность, ведь, у решений на рефлексии еще хуже чем у скриптовых.
Если входные параметры не проверять, то надёжности не будет и у скомпилированного кода.

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

EP>Немного offtopic: а какие у Nemerle основные принципы дизайна? Какова основная идея? Чем руководствуются создатели при принятии тех или иных решений?

Мое впечатление и ИМХО. Никакой идеологии и общего видения у Немерле нет. Когда читал доки, создалось впечатление, что язык весьма неконсистентен (говорю только про первую версию). Что-то дернуто оттуда, что-то отсюда.
Хуже того, у языка нет киллер-фичи. Просто фичи есть, а киллер-фич — нет. Макросы — это хорошо, но лично мне за много лет программирования что-то подобное требовалось считанные разы (да, компиляторы я не пишу). Опять же, сложилось впечатление, что в основном макросы нужны для трансформации самого языка. Но кому нужен язык-конструктор? Ну может кому-то и нужен, но это явно маргинальное направление. Типа как дали человеку кусок глины — лепи чего хочешь.

На мой взгляд, людям в основном требуется совсем иное — продуманный язык с определенным предназначением и видимыми достоинствами (ну и проистекающими из всего этого недостатками, само собой).

Я согласен с кем-то из этого топика, что более полезным Немерле был бы в виде надмножества C#, как в начале своего развития С++ был надмножеством С. Пишешь на чистом C#, а когда надо — применяешь пару убойных штук, которые "не для масс" (те же макросы). Это было бы очень круто и многим энтузиастам бы понравилось. Правда, C# тоже развивается и остается все меньше места для этих всех надмножеств, скоро словосочетание "надмножество С#" будет вызывать такой же глупый смех, как сейчас "надмножество С++" (это же полный п).

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

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

ARK>Я согласен с кем-то из этого топика, что более полезным Немерле был бы в виде надмножества C#, как в начале своего развития С++ был надмножеством С. Пишешь на чистом C#, а когда надо — применяешь пару убойных штук, которые "не для масс" (те же макросы). Это было бы очень круто и многим энтузиастам бы понравилось. Правда, C# тоже развивается и остается все меньше места для этих всех надмножеств, скоро словосочетание "надмножество С#" будет вызывать такой же глупый смех, как сейчас "надмножество С++" (это же полный п).
Это возможно сейчас.
Компилятор Nemerle умеет компилировать C# . ( Не все фишки и есть некоторые нюансы )
И тут можно использовать макросы Nemerle, на сегодня только макроатрибуты т.к. они не меняют синтаксис.

Например берем Memoize:

class A
{
  [Nemerle.Memoize] 
  public static int F(int a, int b) { return a+b; }
}

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

_NN>Это возможно сейчас.

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

"Возможно" — это вот здесь: http://www.postsharp.net/
Вот там все возможно. А у Немерле невозможно.

Когда будет стабильный компилятор, нормальный сайт, установка одним кликом и полноценное использование внутри студии, подробная документация, какое-никакое сообщество и ответы на StackOverflow — вот тогда это можно назвать "возможно".

_NN>Компилятор Nemerle умеет компилировать C# . ( Не все фишки и есть некоторые нюансы )

Так вот надо бы сделать все фишки и устранить все нюансы, а не рассказывать басни про Нью-Васюки.

_NN>И тут можно использовать макросы Nemerle, на сегодня только макроатрибуты т.к. они не меняют синтаксис.

Это неплохо, но, ИМХО, даже до t4 не дотягивает.

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

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

ARK>>Я согласен с кем-то из этого топика, что более полезным Немерле был бы в виде надмножества C#, как в начале своего развития С++ был надмножеством С. Пишешь на чистом C#, а когда надо — применяешь пару убойных штук, которые "не для масс" (те же макросы). Это было бы очень круто и многим энтузиастам бы понравилось. Правда, C# тоже развивается и остается все меньше места для этих всех надмножеств, скоро словосочетание "надмножество С#" будет вызывать такой же глупый смех, как сейчас "надмножество С++" (это же полный п).
_NN>Это возможно сейчас.
_NN>Компилятор Nemerle умеет компилировать C# . ( Не все фишки и есть некоторые нюансы )
_NN>И тут можно использовать макросы Nemerle, на сегодня только макроатрибуты т.к. они не меняют синтаксис.

_NN>Например берем Memoize:
_NN>

_NN>class A
_NN>{
_NN>  [Nemerle.Memoize] 
_NN>  public static int F(int a, int b) { return a+b; }
_NN>}
_NN>

1. Как добавить интервал обновления кеша ?
2. Как добавить правило обновления кеша ?
3. Как из другого кода вызвать очищение кеша ?

Пока хватит.

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

BC>1. Как добавить интервал обновления кеша ?
BC>2. Как добавить правило обновления кеша ?
BC>3. Как из другого кода вызвать очищение кеша ?
BC>Пока хватит.
Никак. Данный макрос это не умеет.
Но ты можешь написать свой. И делать все, что тебе надо. И ровно, так как тебе надо в данном конкретном проекте.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

К>>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.
WH>Было: http://rsdn.ru/forum/dotnet/4159707.1
WH>Стало: http://rsdn.ru/forum/dotnet/4187035.1

Было: читаемый код визитора, в котором всё предельно понятно
Стало: макрокод из которого не очевиден, собтвенно, сам визитор.

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

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

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

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

I>Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.
Для того чтобы фрагментировать память лямбдами нужно очень сильно постараться.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

B>Ты в качестве аргумента кинул ссылку на сайт, предлагающий купить 640-страничную книгу на довольно широкую тему.

Скажу по секрету, что наш мир не столь справедлив и, если тебе жаль денег автору, то его книгу можно найти и нелегально в формате ПДФ.

B>Давай я тебе в ответ ссылку на Александреску кину, пойдешь молча читать, поблагодарив за знания, или покрутишь пальцем у виска а-ля "какое отношение это имеет к теме дискуссии"?

Я его книгу читал. Это была одна из книг подтолкнувшая меня на путь полноценного метапрограммирования.

B>Нахамить оппоненту на форуме можно всегда. Только пользователей это вашей замечательной поделке не прибавит. Я же пытаюсь донести мое понимание того, что могло бы прибавить. Посмотрим, что WolfHound ответит.

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

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

I>>Это ничего не меняет, поскольку проблема в самом ожидании. Спинлок только в идеальном случае вернет управление сразу, без ожидания.
WH>Если ты часто отвисаешь на локах, то ты очень плохо спроектировал приложение.

Интересный способ ведения беседы — перефразировать часть скипнутого текста. Цитирую себя:"Если такие издержки критичны, то однозначно стратегия синхронизации выбрана принципиально неверно."

I>>Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.
WH>Для того чтобы фрагментировать память лямбдами нужно очень сильно постараться.

В том то и дело, я про то и пишу.

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

I>Это ничего не меняет, поскольку проблема в самом ожидании. Спинлок только в идеальном случае вернет управление сразу, без ожидания.

Твоя компетенция поражает. Чужой блокировки может не быть при 99% попытках ее получения. Операция может быть (и обычно так оно и бывает) крохотной, например, присвоением поля или вызовом не затратной по времени функции.

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

I>Если такие издержки критичны, то однозначно стратегия синхронизации выбрана принципиально неверно.

Универсальные отбрехи пошли.

VD>>В-третьих, выделение памяти влияет на все приложение, так как дает нагрузку на ЖЦ.

I>Ничтожная нагрузка.

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

I>Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.

Я уже приводил пример из реального проекта — ReSharper. В нем были вынуждены специально проходиться по коду и преобразовывать линк-код в императивный, так как профайлер показал, что лямбды привели к тормозам.

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

К>>>Если очень нужно, вполне можно использовать например CodeDOM.
VD>>Попробуй, потом расскажешь.
К>Пробовал, прекрасно работал.

Уровень твоей не компетенции зашкаливает. И ты еще спорить лезешь?

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

WH>Ты очень оптимистичен.

Отнюдь.

WH>В С++ есть препроцессор.

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

Вот отсутствие типизации возможности ограничивает. Это, да.

WH>Посмотри примеры.

Мне это не интересно. Я им сам по полной программе пользовался. Обычный интерпретатор-реплейсерка.

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

I>Где он на рынке ?

На *никсах его довольно много. Как минимум в Емаксе вся автоматизация на нем.

Мне интересно где будет на рынке C# через 50 лет. Думаю, что его забудут. А вот вероятность того, что Лисп сохранится довольно велика, так как первые 50 лет он пережил.

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

EP>Собственно я и предполагал что так оно и есть, спасибо что подтвердил.

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

EP>Конечно можно, и принципов-то ведь никаких не было, ни у Порша, ни у Суперджета — были только, как ты говоришь, "рекламный бред", "агитки" и "булшит". А фичи добавлялись спонтанно, ничем не руководствуясь, без всякой цели.

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

Короче, ты уже утомил. Сформулируй свои принципы для C# или признай, что это бредовое занятие.

EP>Вообще, если взять Жигули, начать добавлять рандомные фичи, то ведь обязательно получится Порш — так?

Ну, вот берут люди Камаз. Добавляют "рандомные" фичи и получают победителей рали Париж-Дакар.

Или берут люди обычный Ford Focus. Добавляют к нему "рандомные" фичи и получают гоночные автомобили для бедных — Ford Focus ST/RS.

Можно, конечно, возразить, что фичи то не рандомные. Но это ты из пальца высосал, что фичи немерла рандомные.

Ну, и в отличии от Ford Focus, Nemerle — это конструктор со сменными элементами. Он не просто напичкан фичами которые делают из Ford Focus какой-то там Ford Focus ST. Он позволяет прикреплять и снимать фичи для каждого отдельного проекта, а так же имеет набор готовых фич которые удобны для любых проектов.

Это будущее, но мартышки его тупо не могут разглядеть по невежеству и потому хаят.

Если посмотреть на C#, то это как раз он перепичкан фичами и пачкается ими с каждой новой версией. Причем фич все равно не хватает, так как каждому нужны свои фичи, а разработчик не может впихнуть узкоспециализированных фич на все случаи жизни, так как это превратится в Ад во время поддержки и неподъемное обучение для пользователей.

Тут же предложено гениальное решение — пристегивающиеся/отстегивающиеся фичи. Можно спокойно делать альтернативый набор фич и выбирать лучшие. Или брать готовые фичи для конкретного типа проектов. Все что для этого нужно — комьюнити клепающее эти фичи и сайт где они будут перечислены. Но потенциальное комьюнити занято "мартышкиным трудом" (в смысле "свой толк все к худу клонит").

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

I>Отсюда ясно, что добавляя по фиче в жигули и як-42 никогда не получишь ни порш, ни суперджет.

Именно так и был создан сам Як-42. Взяли Як-40 и дополнили его новыми "фичами".

Понятно, что Жигуль и Порш — это утрирование.

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

BC>Порш ездит быстрее жигулей в несколько раз.

Менее чем в два. Но это и есть одна из его главных фич.

BC>А суперджет летает быстрее як-42 в несколько раз.

На 50 километров, если быть точным. Крейсерская выше на 100 Км. Это конечно приятная фича, но не как не "быстрее як-42 в несколько раз".

BC>А вот программы на Немерле будут быстрее работать чем на C# ?

Да. На некоторых задачах существенно (в разы). На некоторых просто будет комфортнее. Если устранить отставание с тулингом и скоростью компиляции, то найти область в которой C# будет хотя бы сравним будет невозможно.

BC>PS: Вообще я за то, чтобы проект пилили и дальше. Тем более у вас уже есть финансирование.
BC>А чего еще нужно, чтобы тихой неспешной сапкой проверять гипотезы, по вечерам попивая пивко ?

Ну, чтобы "мартышки перестали бить очки", а задумались над своей производительностью и комфортом работы.

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

VD>>Меня не слышат? Я же попросил "для C#".

EP>Это так принципиально для понимания?

Да, так как ты этого явно сделать не можешь. А языки близкие. На одной платформе. Во многом совместимы.

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

EP>Это Delphi-то подходит?
EP>

EP>* Leave no room for a lower-level language below C++ (except assembler)
EP>* What you don’t use, you don’t pay for (zero-overhead rule).
EP>* No gratuitous incompatibilities with C

EP>

За исключением последнего пункта — да. Уж к какому-нибудь D подходят на 146%.

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

J>В этом смысле Немерле по отношению к шарпу точно в такой же позиции находится, имхо: шарп + макросы.

Именно так, только еще + полноценное функциональное программирование.

J>ЗЫ Продвинутая макросистема никак не противоречит философии С++. По той простой причине, что она целиком compile-time.

+1

Более того, макросистема могла бы нивелировать отсутствие рефлексии.

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

VD>>>Меня не слышат? Я же попросил "для C#".
EP>>Это так принципиально для понимания?
VD>Да, так как ты этого явно сделать не можешь. А языки близкие. На одной платформе. Во многом совместимы.

В сообщении на которое ты ответил как раз и было описание для C#:

Я не описание оцениваю как флеймовое, а то, во что тут обычно вырождается практически любой вопрос по языкам.
ОК, вот моё краткое описание:
Язык программирования для корпоративных информационных систем, опердней и всего подобного. Некоторые руководствующие принципы:
* реализация поддержки конкретных use-case'ов ASAP
* отдельная конкретная фича важнее предоставления обобщённых возможностей позволяющих её реализовать (delegate, await, linq, nullable и т.п.)
* надёжность и безопасность важнее скорости.

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

VD>Здравствуйте, bazis1, Вы писали:
B>>Ты в качестве аргумента кинул ссылку на сайт, предлагающий купить 640-страничную книгу на довольно широкую тему.
VD>Скажу по секрету, что наш мир не столь справедлив и, если тебе жаль денег автору, то его книгу можно найти и нелегально в формате ПДФ.
Я в курсе про DSL. Я не говорю, что это не круто. Я говорю, что в текущей форме это непрактично. Книга же, судя по всему, практичность и риски не затрагивает.

B>>Давай я тебе в ответ ссылку на Александреску кину, пойдешь молча читать, поблагодарив за знания, или покрутишь пальцем у виска а-ля "какое отношение это имеет к теме дискуссии"?
VD>Я его книгу читал. Это была одна из книг подтолкнувшая меня на путь полноценного метапрограммирования.
Ок, как насчет книги Синка "On the Business of Software"? Ссылку дать?

B>>Нахамить оппоненту на форуме можно всегда. Только пользователей это вашей замечательной поделке не прибавит. Я же пытаюсь донести мое понимание того, что могло бы прибавить. Посмотрим, что WolfHound ответит.

VD>Я не вижу оппонента. Я вижу человека, своим поведением, смахивающего на мартышку из басни. Не в силах понять ты ищешь фатальные недостатки в том что не понимаешь и тех кто занимается непонятными тебе вещами.
Ты просто считаешь свою точку зрения единственно верной, а то, что человек указывает на факторы вне твоей зоны внимания, считаешь признаком невежества. Ты наверое удивишься, но я в свое время тоже баловался проектированием языков (см. публикацию и IDE) и язык этот точно так же не взлетел, несмотря на огромное превосходство над VHDL. Что сподвигнуло меня на изучение маркетинга, анализ аудитории путем перетирания о жизни с кучей народа на конференциях и т.п. В итоге следующие продукты создавались из расчета на решение существующих проблем и ВНЕЗАПНО уже не были провальными. А мог бы продолжать сидеть в немецком универе, ныть про несправедливость мира и кидаться в людей ссылками про семантику register-transfer-level-языков. Как-то так.

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

EP>Это сейчас ниша C чётко очерчена, а в своё время, под это описание также подходил Objective-C.

Под это подходят все языки-наследники. Паскаль -> Дельфи, С -> (С++, Objective-C, D), Ява -> C# -> Nemerle.

EP>То есть цель — заменить C# в его нише более мощным и гибким языком? Собственно я это и спрашивал.

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

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

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

Раньше мне казалось, что люди разумны и достаточно им просто показать лучшее решение, как они соберутся вместе и решат все технические и моральные сложности, что мешают достижению цели. Но, нет. Мартышкам проще и приятнее бить очки, чем разбираться.

EP>Так я же и не против продвинутых макросов (пруф), или хотя бы чего-то эквивалентного (пруф), типа mixin в D (грубо говоря, строчка возвращённая constexpr функцией встраивается прямо в код)

Сколько ты написал кода на D?

Кстати, миксины в Ди — это убогая пародия на мары немерла. Она и была создана под влиянием Немерла.

Скала тоже идет в направление макросов. Пока что ограниченных. Но все же. И опять таки под влиянием немерла. Я лично дал автору макросистемы Скалы идею в какой форме их можно внедрить в Скалу. Похоже, что у них это успешно получается.

В отличии от вас, я желаю обоим проектам (D и Scala) успехов в развитии. И не буду бить очки понося их, несмотря на то, что вижу в них некоторые существенные недостатки.

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

D, Scala и Nemerle используют ничтожное количество программистов, не смотря на то, что эти языки существенно превосходят своих прородителей.

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

EP>Там написано что Nemerle мощнее C#, и что можно использовать его как продвинутый C#. Но из этого не следует что целью была только замена C#.

У немерла было как минимум два автора.

Один хотел сделать "переходный" язык который бы позволил бы программистам перейти в мир функционального программирования из мира императивного и объектного. Это привело к тому, что Немерл стал мультипарадигмным. Но результат оказался прямо противоположным. Язык получился мультипарадигмным. В нем удобно использовать любую парадигму. А развите языка происходило от чисто функционального в стиле МЛ, к шарпоподобному. В итоге получилась очень качественная комбинация.

Так же этот автор воплотил в Немерле совою идею локального вывода типов. Вывод типов получился очень хорошим. Единственный недостаток — текущая реализация довольно медленна (раз 10 медленее шарповской). Но он устраним если вложить в него силы или деньги.

Другой автор хотел опробовать концепцию макросов Лиспа в языке с синтаксисом. У него это успешно получилось. Есть ряд шероховатостей, но в цеолом получилось лучшее в мире решение. Тут опять таки есть куда копать и есть куча внутренних проблем. Мы их решаем в Nitra. Но главное, что удалось создать расширяемый язык с синтаксисом и доказать живучесть этой концепции.

EP>Да, костыль, самый примитивный, зато мощный. Прикидывая когда продвинутые макросы смогут к нам добраться (C++2y? C++3y?? C++4y!?!?!), я бы не отказался от такого костыля сейчас, тем более гипотетическим продвинутым макросам он никак не помешает.

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

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

ARK>Мое впечатление и ИМХО. Никакой идеологии и общего видения у Немерле нет. Когда читал доки, создалось впечатление, что язык весьма неконсистентен (говорю только про первую версию). Что-то дернуто оттуда, что-то отсюда.

То есть, язык ты по диагонали "посмотрел" и не пробуя вывод сделал?

Замечательно!

Давай ты попробуешь обосновать свои утверждение. А то у меня ИМХО, что ты не компетентен в вопросе. Развей его, плиз.

"неконсистентен"? ОК, приведи примеры этой самой неконсистентности.

ARK>Хуже того, у языка нет киллер-фичи.

Ну, да. Макрос, отличная поддержка ФП, отличный вывод типов — это не фичи. Вот когда МС поделки представляет — это ура! крютя!

А тут хрень какая-то стеклянная. Ты ее и к темени приложил и на хвост надел, но проку нету в них.

ARK>Просто фичи есть, а киллер-фич — нет.

Назови, плиз, киллер-фичи того же C#. Вот какие в нем были (в первой версии) фичи, которых хотя бы не было в Яве? Я помню только делегаты и события. Это киллер-фичи?

ARK>Макросы — это хорошо, но лично мне за много лет программирования что-то подобное требовалось считанные разы (да, компиляторы я не пишу).

Ну, так и мартышка не нашла применение очкам. Это же не значит, что очки бесполезны?

ARK>Опять же, сложилось впечатление, что в основном макросы нужны для трансформации самого языка. Но кому нужен язык-конструктор?

Тем у кого есть мозг. А остальные прыгают по форуму шарпа в ожидании когда какую-нибудь мелку фичу им Майкрософт нарисуют. Так и ждут по 10 лет. используют костыли вроде Т4, для того чтобы хоть как-то код сгенерировать. Но кода им показывают мощную систему метапрограммирования интегрированную с компилятором и IDE, они тупо хлопают глазками и говорят:

Тьфу пропасть! и тот дурак,
Кто слушает людских всех врак:
Всё про Макросы лишь мне налгали;
А проку на-волос нет в них

ARK>Ну может кому-то и нужен, но это явно маргинальное направление.

Да, да. Проблема не в тебе. Верь в это. Будь с миллионами мух. Они ведь не могут ошибиться.

ARK>Типа как дали человеку кусок глины — лепи чего хочешь.

На мой взгляд, людям в основном требуется совсем иное — продуманный язык с определенным предназначением и видимыми достоинствами (ну и проистекающими из всего этого недостатками, само собой).

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

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

ARK>Я согласен с кем-то из этого топика, что более полезным Немерле был бы в виде надмножества C#, как в начале своего развития С++ был надмножеством С. Пишешь на чистом C#, а когда надо — применяешь пару убойных штук, которые "не для масс" (те же макросы). Это было бы очень круто и многим энтузиастам бы понравилось. Правда, C# тоже развивается и остается все меньше места для этих всех надмножеств, скоро словосочетание "надмножество С#" будет вызывать такой же глупый смех, как сейчас "надмножество С++" (это же полный п).

Это возможно, но язык бы много потерял, если бы был чистым надмножеством Шарпа. Шарп не рассчитан на поддержку ФП (функционального программирования), так же как Жигули не предназначен для быстрой езды.

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

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

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

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

Вот сейчас выйдет Розлин и вы все будут охать и ахать как же это хорош и здорово. А то что еще 8 лет назад был Немерл предоставлявший тоже самое и намного больше вы скромно умолчите.

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

_NN>И тут можно использовать макросы Nemerle, на сегодня только макроатрибуты т.к. они не меняют синтаксис.

Макроы имеющие синтаксис функций тоже можно использовать без проблем.

Проблема только в том, что нет поддержки IDE в для встроенного шарпа.

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

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

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

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

I>>Это ничего не меняет, поскольку проблема в самом ожидании. Спинлок только в идеальном случае вернет управление сразу, без ожидания.

VD>Твоя компетенция поражает. Чужой блокировки может не быть при 99% попытках ее получения. Операция может быть (и обычно так оно и бывает) крохотной, например, присвоением поля или вызовом не затратной по времени функции.

Это очевидно. Вопрос в издержках в пересчете на системные ресурсы и время пользователя.

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

I>>Если такие издержки критичны, то однозначно стратегия синхронизации выбрана принципиально неверно.

VD>Универсальные отбрехи пошли.

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

I>>Ничтожная нагрузка.

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

Лямбда это не самая проблемная вещь в плане перформанса.
Самые проблемные вещи в перформансе
0. кривые алгоритмы и структуры данных, включая встроеные во фремворк
1. неправильное кеширование, например из за write barrier
2. ленивый код итераторов, генераторов
3. неэффективный расход памяти, например конское количество объектов в Gen2 или туча фрагментации
4. боксинг-анбоксинг

Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет

пустая итерация 2 сек (числа ниже получены вычетом этого значения из реального замера)
инстанцирование лямбд 2.5 сек + итерация
инстанцирование с вызовом лямбды 7 сек + итерация
вызов метода 2 сек + итерация
итерация по массиву лямбд с вызовом 5 сек + итерация
итерация по массиву вызовом метода 2.5 сек + итерация
итерация через итератор лямбд с вызовом 10 сек + итерация
итерация через итератор вызовом метода 8 сек + итерация

Создание лямбды быть хуже, если много всего замыкается за раз, но не сильно.

I>>Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.

VD>Я уже приводил пример из реального проекта — ReSharper. В нем были вынуждены специально проходиться по коду и преобразовывать линк-код в императивный, так как профайлер показал, что лямбды привели к тормозам.

Ощущение, что ты в профайлер никогда не смотрел. Линк это прежде всего конские итераторы. См выше — потери из за итератора в 4 раза , и то, это в идеальном случае, когда итератор примитивный, на массиве. Реальные итераторы линка могут дать "профит" в 10-15 раз хуже.

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

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

VD>Немерл и есть такой язык. Продуманный и очень удобны.

VD>Но ты не подрудился даже попробовать его. Не то что разобраться.

Да, это так. Потому что я не вижу причин его пробовать, как и многие другие языки.

Остальное скипнул, прошу прощения. Других людей вы не слышите, ни тогда, ни сейчас. Ваш пост хорошо иллюстрирует, почему язык за 5 лет так и не выстрелил. Ну, точнее выстрелил — в лужу.

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

I>>Где он на рынке ?

VD>На *никсах его довольно много. Как минимум в Емаксе вся автоматизация на нем.

Так много, что вакансий около нуля.

А я хотел почитать про немерле, а вики уже полгода не работает http://nemerle.org/wiki/index.php?title=Main_Page

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

I>>Отсюда ясно, что добавляя по фиче в жигули и як-42 никогда не получишь ни порш, ни суперджет.

VD>Именно так и был создан сам Як-42. Взяли Як-40 и дополнили его новыми "фичами".

Не фичами, а конструкцию пересмотрели.

Здравствуйте, Аноним, Вы писали:

А>А я хотел почитать про немерле, а вики уже полгода не работает http://nemerle.org/wiki/index.php?title=Main_Page

Так в чем проблема-то — "сять и помоги улучшить, чем трепаться то" (с)

Заодно и любовь к Немерле придет.

Здравствуйте, Аноним, Вы писали:

А>А я хотел почитать про немерле, а вики уже полгода не работает http://nemerle.org/wiki/index.php?title=Main_Page
https://github.com/rsdn/nemerle/wiki вики здесь

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

EP>В сообщении на которое ты ответил как раз и было описание для C#:

Сори. Достало ваши унылые песни читать. Стал по диагонали смореть. ОК, попробуем понять что же за концеции у шарпа.

EP>Язык программирования для корпоративных информационных систем, опердней и всего подобного. Некоторые руководствующие принципы:

Во-первых, какая же это концепция? Или ты предназначение под концепцией понимаешь?
Во-вторых, это ошибочное утверждение. Никаких специальных для оперденей фич в Шарпе нет. И Шарп вполне успешно используют для вполне себе системного программирования. Примеры? Их есть у меня (ц):
1. Розлин пишется на шарпе. А значит на шарпе будет компилятор Шарпа (вполне себе системная залача) и интеграция шарпа с IDE.
2. Весь Решарпер написан на Шарпе. Огромнейший продукт. Очень критичный к производительности.
3. На Шарпе написана эксперементальная ОС "Сингулярити". Она показала весьма приличную производительность. И уж более системную задачу придумать нельзя.

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

EP>* реализация поддержки конкретных use-case'ов ASAP

Я даже не знаю кто такой ASAP, а ты его в концепции записываешь.

EP>* отдельная конкретная фича важнее предоставления обобщённых возможностей позволяющих её реализовать (delegate, await, linq, nullable и т.п.)

Возможно я не распарсил это.

Делегат тут явно поставлен в не свойственный ему ряд. Он аналогичен указателю на функции/методы в С++. Остальное высокоуровневые фичи.

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

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

Немерл построен на базе компактного ядра и подобные сахарные фичи в нем реализуются сугубо с помощью макросов. В этом отношеии он превосходит и Шарп, где просто нельзя делать свой сахар, и С++, где это делается через одно место.

EP>* надёжность и безопасность важнее скорости.

Спорное утвеждение. Но раз ты так считаешь про Шарп, значит то же можно утверждать про немерл. Хотя, почему-то Решарпер вполне себе быстро работает на будтчи написанным на Шарпе, а Сингулярити работает на со скоростью сравнимой со скоростью ОС написанных на С.

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

BC>1. Как добавить интервал обновления кеша ?

Что такое "интервал обновления" и зачем он нужен я не знаю. Если тебе нужно собственное решение, создай свой макрос.

BC>2. Как добавить правило обновления кеша ?

BC>3. Как из другого кода вызвать очищение кеша ?

Вот тут примеры использования.
Внизу, в коментах, выхлом (это тесты такие у немерлового компилятора).

using System.Console;

[Record]
public class F
{
  name : string;

  [Nemerle.Memoize]
  public Method1(a : void -> int) : int
  {
    Write($"$name.Method1(): ");
    a()
  }

  [Nemerle.Memoize(Scope = Class, Synchronized = true)]
  public Method2(a : void -> int) : int
  {
    Write($"$name.Method2(): ");
    a()
  }

  [Nemerle.Memoize(Synchronized = true)]
  public Method3(a : void -> int) : int
  {
    Write($"$name.Method3(): ");
    a()
  }

  [RecordIgnore] private mutable method4_switch : bool;

  [Nemerle.Memoize(InvalidValue = 0)]
  public Method4(x : int) : int
  {
    if(method4_switch) {
      x
    } else {
      method4_switch = true;
      0
    }
  }

  [Nemerle.Memoize]
  public static Method5(a : void -> int) : int
  {
    Write("static Method5(): ");
    a()
  }
}

module Program
{
  Main() : void
  {
    def test()
    {
      WriteLine("side effect");
      3
    }
    def a = F("a");
    WriteLine(a.Method1(test));
    WriteLine(a.Method1(test));
    WriteLine(a.Method2(test));
    WriteLine(a.Method2(test));
    WriteLine(a.Method3(test));
    WriteLine(a.Method3(test));
    def b = F("b");
    WriteLine(b.Method1(test));
    WriteLine(b.Method1(test));
    WriteLine(b.Method2(test));
    WriteLine(b.Method2(test));
    WriteLine(b.Method3(test));
    WriteLine(b.Method3(test));
    def c = F("c");
    WriteLine(c.Method4(7));
    WriteLine(c.Method4(7));
    WriteLine(c.Method4(7));
    WriteLine(F.Method5(test));
    WriteLine(F.Method5(test));
    WriteLine(F.Method5(test));
    WriteLine(F.Method5(test));
    //_ = ReadLine();
  }
}

/*

BEGIN-OUTPUT
a.Method1(): side effect
3
3
a.Method2(): side effect
3
3
a.Method3(): side effect
3
3
b.Method1(): side effect
3
3
3
3
b.Method3(): side effect
3
3
0
7
7
static Method5(): side effect
3
3
3
3
END-OUTPUT
*/

Вики с доками, к сожалению, положили и так и не подняли.

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

VD>Что такое "интервал обновления" и зачем он нужен я не знаю.

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

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

I>Хороший приёмчик.

Да, неплохой. Логика называется. Когда кто-то делает неверные утверждения, я привожу факты их опровергающие.

I>Когда у меня, бывает, непруха, я тоже так делаю: "Смотри, сколько коммитов. А здесь, вот в этом, я вообще 50 файлов модицировал"

Дык, ты других то по себе не суди.

Мы правим Немерл просто потому что это нужна нам или пользователям немерла. Предполагается, что любой может это сделать. Присоединяйся! Консультациями мы тебе поможем.

VD>>Зачем ты ходишь на этот форум, если от тебя кроме флуда и флейма ничего нет?

I>Зачем ты повторяешь этот вопрос ? Ответ был даден много раз, ничего не изменилось.

Понять хочу. Ну, не нравится тебе что-то. Обосновать это все равно не можешь, зачем ходить и мешать окружающим флеймами?

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

AM>Крупные коммерческие конторы используют скалу основным языком (из русских Тинькофф, например).

С какого перепугу Тинькофф стал "крупной коммерческой конторой"?

AM>Тонны жаба кода переписывалась на скалу.

Этому есть подтверждение?

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

K>Он уже умер. Просто не все успели понять, что стюардессу уже пора закапывать.

Да, да. А мы не заметили этого и 6 год труп насилуем.

На, вот, открой для себя продукт написанный на языке-трупе.

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

N>Clojure и прочие питоны не совсем удачное сравнение, они намного проще, но есть и удачное. Немерле — полный труп по сравнению со Скалой.

Ну, что бредить то? Лагины IDE для скалы глючат много лет. JetBrains посчитав Скалу очень сложной начал пилить свою лайт-версию — Котлин.

Компилятор и интеграция с IDE для немерла доступны уже 6 лет. Они обновляются по мере выхода новых фреймворков/студий и появления новых фич.
Кричать мы по его поводу перестали. Но это не значит, что кто-то там труп.

Вот тебя в этом мире тоже никто не знает и никто про тебя кричит. Но это же не значит, что ты труп?

N>В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support.

Дык и в Немерле есть все что есть в Скале и поддержка IDE.

N>ИМХО кроссплатформа есть главная причина и об этом отцам-основателям говорили пять лет назад. 95% энтузиастов не будут вкладываться в windows-only. Mono никому, включая Мигеля, был уже тогда не нужен.

Кроссплатформенность это хорошо. В будущем мы тоже хотели бы ее сделать. Причем не на базе явы, а более общий вариант. И не только для Немерла, а для всех языков поднятых на базе Nitra.

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

BC>Основная проблема кешей в том, что их нужно както обновлять и синхронизировать.
Основная проблема в том, что данный макрос решает очень частную задачу. И решает её хорошо.
Ничего из того о чём ты говоришь ему не нужно.

BC>Вы работали когда с кешами в рабочем проекте ?
Пальцы спрячь. Если я сейчас начну рассказывать тебе о кешах у тебя уши в трубочку свернуться.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>>Так я же и не против продвинутых макросов (пруф), или хотя бы чего-то эквивалентного (пруф), типа mixin в D (грубо говоря, строчка возвращённая constexpr функцией встраивается прямо в код)
VD>Сколько ты написал кода на D?

Строчек сто — проверял как работает одна фича, которую эмулировал в C++. В целом, на данный момент, в D метапрограммирование на голову выше чем в C++.
А к чему вопрос?

VD>Кстати, миксины в Ди — это убогая пародия на мары немерла.

Разные средства для решения в чём-то подобных задач

И да, эти миксины — крайне низкоуровневая и негигиеничная фича.

VD>Она и была создана под влиянием Немерла.

Сам придумал?

VD>В отличии от вас, я желаю обоим проектам (D и Scala) успехов в развитии. И не буду бить очки понося их, несмотря на то, что вижу в них некоторые существенные недостатки.

Алле! От кого нас? Я им тоже желаю успехов, и вроде никак не принижал

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

Конкретно у D цели отличаются от C++, об этом явно и говорят авторы, и соответственно область применения не совпадает на 100%. Даже сейчас уже видно что пути языков расходятся

P.S. Не пойму причину твоей агрессии и хамства

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

s22>>Скала по идеи должна отстать от Н2 значительно, сейчас Н1 и Скала по языку в паритете.
N>В чем? В скорости парсера?

Во всем кроме мкросов. Макры у Немерла мощнее. Хотя в Склаен реализован интересный их вариант.

N>И потом H-2 это разве не просто набор компонент с которыми играются три человека в JB, появившийся полгода назад?

Мы переименовали проект в языкового воркбенча в Nitra. Новый немерл будет называться Nemerle 2.0. Можно его называть Н2.

N>Даже если завтра JB бросят 100% усилий на H-2 будет пшик, пока платформу нельзя использовать нигде кроме винды.

Как-то миллины пользователей шарпа так не считают. В прочем, мы хотим сделать в Nitra поддержку сменяемых бэкндов для поддержки разных платформ. Если все удастся в срок, будет Немерл кросплатформным. Возможно и нативный клиент сделаем.

N>Имеется ввиду что Скала работает на ~100% серверного железа, 80% из которого пашет на *nix.

Дык Моно на нем тоже работает. Кроме того сейчас популярны облока, а с ними в дотнете все ОК.

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

EP>>Там написано что Nemerle мощнее C#, и что можно использовать его как продвинутый C#. Но из этого не следует что целью была только замена C#.
VD>У немерла было как минимум два автора.
VD>Один хотел сделать "переходный" язык который бы позволил бы программистам перейти в мир функционального программирования из мира императивного и объектного. Это привело к тому, что Немерл стал мультипарадигмным. Но результат оказался прямо противоположным. Язык получился мультипарадигмным. В нем удобно использовать любую парадигму. А развите языка происходило от чисто функционального в стиле МЛ, к шарпоподобному. В итоге получилась очень качественная комбинация.
VD>Так же этот автор воплотил в Немерле совою идею локального вывода типов. Вывод типов получился очень хорошим. Единственный недостаток — текущая реализация довольно медленна (раз 10 медленее шарповской). Но он устраним если вложить в него силы или деньги.
VD>Другой автор хотел опробовать концепцию макросов Лиспа в языке с синтаксисом. У него это успешно получилось. Есть ряд шероховатостей, но в цеолом получилось лучшее в мире решение. Тут опять таки есть куда копать и есть куча внутренних проблем. Мы их решаем в Nitra. Но главное, что удалось создать расширяемый язык с синтаксисом и доказать живучесть этой концепции.

Вот, уже интересно — вырисовывается кривая развития, и видно что на разных этапах были разные авторы, с разными целями и идеями.

EP>>Да, костыль, самый примитивный, зато мощный. Прикидывая когда продвинутые макросы смогут к нам добраться (C++2y? C++3y?? C++4y!?!?!), я бы не отказался от такого костыля сейчас, тем более гипотетическим продвинутым макросам он никак не помешает.
VD>Блин. Нет слов. Они доступны уже сейчас. Качаешь инсталлятор немерла и пользуешься. Но нет, надо помечтать о том, что никогда не случится.

Нужен будет .NET — обязательно посмотрю в сторону Nemerle (как минимум потому что C# слишком дубовый). На данный же момент мне важна скорость, кроссплатформенность и некоторые нативные библиотеки.

VD>Причем не случится именно из-за таких как вы, хаящих все в чем не смогли разобраться и закидывающих дерьмом всех кто пытается приблизить прогресс.

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

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

N>Не любая, но в общем верно. Только не совсем понятно какое это имеет отношение к обсуждаемому в ветке вопросу "почему Немерле труп". Мой тезис такой: "в 2014 Немерле не нужен, потому что есть Скала которая лучше во всем". В 2009 это было не так.

Это и сейчас не так. Она лучше "ни в чем". Разве что платформа более распространенная и менее прапроитарная. Только это не вина языка.

N>Это опять же оффтоп, но я придерживаюсь другого мнения. Просто новый язык для системного программирования сложнее интегрировать в экосистему, так как он лежит в фундаменте. Все сильно набравшее популярность последнее время(Python, Scala, Ruby, Clojure, Haskell, Erlang) явно не из этой серии.

Все тоже саме. Есть Ди, Раст, Го. Да и домыслы о том, что дотнет или ява не подходят для "системного программирования" — всего лишь домыслы. В прочем, как и рассказы о том, что перечисленные языки (за исключением Питона) имеют серьезную популярность. На фоне Шарп, Ява, С++ эти языки имеют популярность близкую к плинтусу. Были всплески, но они прошли. Питон — отдельная песня. Язык ниже среднего, но его развивают гиганты. Результат на лицо.

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

VD>И что? Он доступен в виде отдельного приложения. Прогнал перед парсингом и нет проблем. В конечном коде препроцессор не нужен.
Прощай IDE.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

I>Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет
I>пустая итерация 2 сек (числа ниже получены вычетом этого значения из реального замера)
I>инстанцирование лямбд 2.5 сек + итерация
I>инстанцирование с вызовом лямбды 7 сек + итерация
I>вызов метода 2 сек + итерация
I>итерация по массиву лямбд с вызовом 5 сек + итерация
I>итерация по массиву вызовом метода 2.5 сек + итерация
I>итерация через итератор лямбд с вызовом 10 сек + итерация
I>итерация через итератор вызовом метода 8 сек + итерация

Это какой-то простой код с выключенным оптимизатором?

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

I>Это очевидно. Вопрос в издержках в пересчете на системные ресурсы и время пользователя.

У спинов издержки близкие к нулю.

I>Лямбда это не самая проблемная вещь в плане перформанса.

Сама, не самая — не играет рояли. Факт в том, что выши костыли порождают такие затраты повсеместно.

I>Самые проблемные вещи в перформансе
I>0. кривые алгоритмы и структуры данных, включая встроеные во фремворк

Одно другого не искючает. Реализация примитивов через лямбды замедляет кривые алгоритмы еще больше.
У алгоритма есть вычислительная сложность и константа. Чем выше константа, тем сильнее тормоза.
Если алгоритмы оптимальны, то кроме как убрать константу ничего другого сделать и нельзя. А хороший программист, все таки, старается использовать подходящие алгоритмы.

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

I>1. неправильное кеширование, например из за write barrier

Это частный случай пункта 0.

I>2. ленивый код итераторов, генераторов

Это та самая константа которую можно убирать макросами. У нас в коде парсеинга нет ни лябд ни итераторов. В купе с, теми самыми, алгоритмами дает хороший результат.

I>3. неэффективный расход памяти, например конское количество объектов в Gen2 или туча фрагментации

Опять же следствие. И опять же макры позволяют его лечить. Пишем генератор код. Описываем задачи на ДСЛ. Генерируем для них оптимальный код. Можно копипастить и плевать на все правила программирования, так как код абстрагируется за счет генерации.

I>4. боксинг-анбоксинг

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

I>Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет

Ты нашел кого учить.

I>Создание лямбды быть хуже, если много всего замыкается за раз, но не сильно.

Я тут уже много раз повторял. Пример из реальной жизни. В ДжетБрэйнсе специально вычищали Линк из кода, так как он давал тормоза. А ты все какую-то синтетичекую финю рассматриваешь.

Когда перейдешь на следующий уровень (если перейдешь), то поймешь, что измерять тоже нужно с умом. И что от синтетических тестов обычно мало толку. В них легко неучесть разных факторов. Например, того фактора, что лямбды пораждают развесистые иерархии объектов, которые, будучи созданные в больших обемах негативно влияют на ЖЦ.

I>См выше — отказ от лямбд дает тебе от силы удвоение пропускной способности в самом идеальном случае — когда лямбда ничего не делает

Это дилетантские рассуждения. Если, например, запихать создание лябмд в процесс парсинга, то его легко замедлить до неприемлемых значений.

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

По сему в чистых ФЯ делают кучу оптимизаций направленных на устранение влияния функций высшего порядка на скорость. Но в дотнете этого не делается. Так что перформанс-пинальти имеется всегда.

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

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

I>Не фичами, а конструкцию пересмотрели.

Это и есть фичи.

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

EP>Вот, уже интересно — вырисовывается кривая развития, и видно что на разных этапах были разные авторы, с разными целями и идеями.

Не на разных этапах, а параллельно.

EP>Нужен будет .NET — обязательно посмотрю в сторону Nemerle (как минимум потому что C# слишком дубовый). На данный же момент мне важна скорость, кроссплатформенность и некоторые нативные библиотеки.

Со скоростью все ОК. Кросплатформность через Моно обеспечивается. Хотя, согласен, что Моно не айс.
С библиотеками нативными тоже проблем нет. Интероп на уровне.

EP>Где я хаял или закидывал Nemerle?

А здесь ты чем занимаешься?

EP>Хотя бы то, что что затея с высокоуровневыми макросами в современном языке с малым ядром доказала свою живучесть — это уже превосходный результат

Я тоже так считаю. Но это не одна идея.

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

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

VD>На, вот, открой для себя продукт написанный на языке-трупе.

А к этому продукту есть более актуальный Roadmap?

А то с мая 2013 когда он редактировалася уже много воды утекло...

... << RSDN@Home 1.2.0 alpha 5 rev. 75>>

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

I>>Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет
I>>пустая итерация 2 сек (числа ниже получены вычетом этого значения из реального замера)
I>>инстанцирование лямбд 2.5 сек + итерация
I>>инстанцирование с вызовом лямбды 7 сек + итерация
I>>вызов метода 2 сек + итерация
I>>итерация по массиву лямбд с вызовом 5 сек + итерация
I>>итерация по массиву вызовом метода 2.5 сек + итерация
I>>итерация через итератор лямбд с вызовом 10 сек + итерация
I>>итерация через итератор вызовом метода 8 сек + итерация

EP>Это какой-то простой код с выключенным оптимизатором?

Да, простой код. точность примерно пол-секунды. Позволяет внятно оценить масштаб .net vs .net

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

I>>Это очевидно. Вопрос в издержках в пересчете на системные ресурсы и время пользователя.

VD>У спинов издержки близкие к нулю.

Спасибо, капитан.

I>>Лямбда это не самая проблемная вещь в плане перформанса.

VD>Сама, не самая — не играет рояли. Факт в том, что выши костыли порождают такие затраты повсеместно.

Вообще то имеет значение. Что бы лямбда стала узким местом это _очень_ редкий случай.

I>>Самые проблемные вещи в перформансе
I>>0. кривые алгоритмы и структуры данных, включая встроеные во фремворк

VD>Одно другого не искючает. Реализация примитивов через лямбды замедляет кривые алгоритмы еще больше.

1 исправление алгоритма даёт на порядки больше профита, нежели приседания с лямбдами
2 приседания с лямбдами не отменяют исправление алгоритма

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

И для чего эти общие слова ?

I>>1. неправильное кеширование, например из за write barrier

VD>Это частный случай пункта 0.

Разумеется, я перечисляю все частные случаи, при чем в порядке убывания веса. Все случаи что я перечислил, создают бОльшие проблемы нежели лямбды

I>>2. ленивый код итераторов, генераторов

VD>Это та самая константа которую можно убирать макросами.

Заметь — она дает влияние гораздо большее, нежели лямбды.

I>>3. неэффективный расход памяти, например конское количество объектов в Gen2 или туча фрагментации

VD>Опять же следствие. И опять же макры позволяют его лечить. Пишем генератор код. Описываем задачи на ДСЛ. Генерируем для них оптимальный код. Можно копипастить и плевать на все правила программирования, так как код абстрагируется за счет генерации.

Ты не отвлекайся — речь была про лямбды.

I>>4. боксинг-анбоксинг
VD>Следствие ручного кодирования однотипных операций. Опять же лечится маросами.

Тем не менее это бОльшая проблема, нежели лямбды.

I>>Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет

VD>Ты нашел кого учить.

Сильное ощущение что ты профайлер раз в год запускаешь

I>>Создание лямбды быть хуже, если много всего замыкается за раз, но не сильно.

VD>Я тут уже много раз повторял. Пример из реальной жизни. В ДжетБрэйнсе специально вычищали Линк из кода, так как он давал тормоза. А ты все какую-то синтетичекую финю рассматриваешь.

Ты линк в профайлере никогда не видел. Основной профит дает устранение энумераторов.

VD>Когда перейдешь на следующий уровень (если перейдешь), то поймешь, что измерять тоже нужно с умом. И что от синтетических тестов обычно мало толку. В них легко неучесть разных факторов. Например, того фактора, что лямбды пораждают развесистые иерархии объектов, которые, будучи созданные в больших обемах негативно влияют на ЖЦ.

Итераторы всё равно больше проблем создают, в них иерархии намного больше и тяжелее.

I>>См выше — отказ от лямбд дает тебе от силы удвоение пропускной способности в самом идеальном случае — когда лямбда ничего не делает

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

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

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

I>>Не фичами, а конструкцию пересмотрели.

VD>Это и есть фичи.

Это _не_ фичи. Это конструктивные особнности. Фича, это когда ты в грузовой отсек кресел напихал. А если изменилась несущая конструкция это уже не фича, принципиально иное решение.

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

VD>>Причем не случится именно из-за таких как вы, хаящих все в чем не смогли разобраться и закидывающих дерьмом всех кто пытается приблизить прогресс.

EP>Где я хаял или закидывал Nemerle?

Он всех, кто с ним не согласен, записывает во враги народа. А ты практически преступление совершил — "Нужен будет .NET — ... На данный же момент мне важна скорость, кроссплатформенность и некоторые нативные библиотеки."

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

EP>P.S. Не пойму причину твоей агрессии и хамства

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

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

EP>>Это какой-то простой код с выключенным оптимизатором?
I>Да, простой код. точность примерно пол-секунды. Позволяет внятно оценить масштаб .net vs .net

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

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

VD>Макросы же позволяют генерировать любой код. В том числе и без лямбды и прочего оверхэда. Наши парсеры содержат код в стиле старого доброго С. Только функции и простые аргументы. И за этом мы не платим говногодом, так как говнокод генерируется по простым шаблонам. Мы же 100% времени заняты теми самыми алгоритмами.

А в чем был посыл ?
Если скорость работы С# не устраивает, то переходят не на Nemerle, а на Си, разве не так ?

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

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

EP>>>Это какой-то простой код с выключенным оптимизатором?
I>>Да, простой код. точность примерно пол-секунды. Позволяет внятно оценить масштаб .net vs .net

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

Скорей всего компиляция в Debug

К>>>Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз.
_>>foreach{} else{} — давай, придумывай

К>Вот готовый http://www-jo.se/f.pfleger/.net-for-else но мне никогда не было нужно такого.
Естественно. Городить вложенные лямбды со всеми спецэффектами захвата — в таком виде оно никому не нужно, очевидно что и тебе тоже

Ты, кстати, уверен что эта поделка сработает на всех тех же сценариях на которых сработает foreach else из Nemerle? Ты понимаешь что мы сейчас обсуждаем не фичу Nemerle как языка программирования, а один единственный, простейший макрос, который в случае надобности под проект на ходу пишется?

_>>Я тоже настоящий сварщик

Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе.
К>В С++ конечно, но в C# уже не так однозначно, т.к. runtime намного более годный.
Если бы в C# компайл-тайм был реально годный, никто в runtime не лез бы. Но с трэндом в .NET Native и выходом roslyn мы ещё увидим ренессанс compile-time.

К>Но нужно бывает редко, потому что рефлексия + функциональщина; я например могу по пальцам одной руки пересчитать написанные за карьеру T4 templates, а reflection постоянно использую для разного.
А я к чему и веду?

К>>>Разницу в том, что nemerle наколеночное поделие, а за рослиным стоит лидер индустрии разработки ПО?
Так это проблема лидера индустрии что они оказались не в состоянии найти людей способных написать модульный компилятор с минимальным микроядром в своей основе

Кстати, внезапно, в исходниках roslyn я снова вижу хардкод фич поштучно. Интересно, если Nitra таки их уделает в хлам, они будут 1)догонять по фичам поштучно 2)снова переписывать, или 3)купят JB?

К>>>Со всеми вытекающими обстоятельствами про качество реализации, качество и объем поддержки, маркетинг и обучение разработчиков?

_>>А причём тут объём поддержки и обучение разработчиков?
К>При том, что продукт это не только исходный код который компилируется, это ещё и поддержка, и обучение пользователей, и сообщество.
Подожди. У тебя была проблема — ты не видел "преимущества в человеко-часах одного перед другим". С точки зрения программиста — человека который пишет код, это преимущество линейно зависит от того сколько кода писать _не_надо_ для получения хотя-бы аналогичного решения. И там и там мы видим компиляторы. Причём один может больше чем другой. У обоих исходники открыты, объём писанины сравнить можно. Переводя стрелки на какое-то обучение, маркетинг, и некий объём, ты сейчас с темы спрыгиваешь, или как это понимать?

К>Кстати про сообщество: на SO два вопроса с тегом nemerle. Для сравнения, там 500 вопросов с тегом clojure, 4000 вопросов с тегом scala, и 140’000 вопросов с тегом C#. Даже безотносительно вопроса «почему так мало», это говорит о том, что если у меня возникнут по нему вопросы, в мире найдутся очень немного людей, способных мне помочь.
Я принимаю вызов! Там 250 000 вопросов по jquery, и темп появления новых такой, что скоро C# обойдут ровно в 2 раза. Такой рост, за каких-то 7 лет, при том что за ней вроде не замечено гиганта типа MS, говорит о том что тебе пора срочно бросать C# и переводить все проекты на чистый jquery!

А также, полагаю, о никудышном качестве ПО, маркетинге, и обучении MS! Может больше денег в C# вкладывать надо?
А если серьёзно — то, имхо, чем более продвинутая относительно среднего уровная штука, тем меньше по ней вопросов на SO. SO — это выражение проблем джуниоров. Поверь, когда джуниоры навалятся на штуковину уровня Nemerle, профессионалы будут уже гораздо дальше.

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

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

Пусть будет предназначение. Из предназначения вытекает концепция, хотя бы частично.

VD>Во-вторых, это ошибочное утверждение. Никаких специальных для оперденей фич в Шарпе нет. И Шарп вполне успешно используют для вполне себе системного программирования. Примеры? Их есть у меня (ц):

Я сужу по тем фичам, которые в него добавляют, и с которыми носятся больше всего — например linq (по крайней мере "основное" его предназначение).
Символично высказывание которое всплывает практически в каждом холиваре — "это экономия на спичках, в реальности всё базу упирается", оно хорошо характеризует основную аудиторию — разве нет?

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

Это то как вижу я — корпоративные системы это драйвер развития, а остальное — побочные эффекты. Я же сказал — если кто знает официальные цели и идеи — цитата не будет лишней.
Например, те же опердни можно писать и на C++, и что характерно некоторые и пишут — но основное предназначение у него другое.

EP>>* надёжность и безопасность важнее скорости.
VD>Спорное утвеждение. Но раз ты так считаешь про Шарп, значит то же можно утверждать про немерл. Хотя, почему-то Решарпер вполне себе быстро работает на будтчи написанным на Шарпе, а Сингулярити работает на со скоростью сравнимой со скоростью ОС написанных на С.

Во-первых, то что какая-то программа не испытывает проблем со скоростью, отнюдь не говорит о том, что язык даёт большую скорость. (мини-числодробилки можно и на динамическом языке без проблем писать)
Во-вторых, и на Java можно выкручиваться и делать быстрый код, только в этом случае язык будет работать против тебя. Например, из-за отсутствия структур приходится ~~левой пяткой правое ухо чесать~~ раскладывать вручную данные по массивам байт. Но да — зато код получается быстрый.
Да и далеко ходить не надо — даже в этой теме обсуждается какие же лямбды тормозные (хотя в C++ они фактически бесплатны).

BC>Если скорость работы С# не устраивает, то переходят не на Nemerle, а на Си, разве не так ?

Макросы это вообще-то про генерацию кода. Почему не генерировать код на Си из выскоуровневого кода на Nemerle? Вот есть такой проект NUDA, там в качестве примера, вычисления написанные на Nemerle выполняются на GPU, так что ничего невозможного нет.

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

VD>Ну, что бредить то? Лагины IDE для скалы глючат много лет.
Хамить не надо. Все в мире глючит. В эклипсе Скала рабочая уже пару лет как. Люди никак не связанные с Одерски пишут на ней серьезные вещи в серьезных конторах.

VD>JetBrains посчитав Скалу очень сложной начал пилить свою лайт-версию — Котлин.
Сам от Скалы не в восторге, но это же не повод становиться страусом.

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

N>>В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support.
VD>Дык и в Немерле есть все что есть в Скале и поддержка IDE.
смотри c) ^

VD>Кроссплатформенность это хорошо.
Это не хорошо, а абсолютно необходимо для популяризации языка, если у тебя нет контроля над платформой и бюджетов сопоставимых с MS/Apple.

VD>В будущем мы тоже хотели бы ее сделать. Причем не на базе явы, а более общий вариант. И не только для Немерла, а для всех языков поднятых на базе Nitra.
Дерзайте, тогда и поговорим.

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

VD>Все тоже саме. Есть Ди, Раст, Го.
Их никто не использует, кроме их авторов.

VD>Да и домыслы о том, что дотнет или ява не подходят для "системного программирования" — всего лишь домыслы.
Очень хочется пофлудить про Сингулярити? Нет, спасибо.

VD>На фоне Шарп, Ява, С++ эти языки имеют популярность близкую к плинтусу.
Как и на фоне Кобола, но мы вроде говорим за Немерле и Скалу. На фоне Скалы Немерле не видно даже в микроскоп.

VD>Были всплески, но они прошли.
Всплеск Скалы идет именно сейчас.

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

VD>Дык Моно на нем тоже работает.
Дык само Моно никто не использует.

VD>Кроме того сейчас популярны облока, а с ними в дотнете все ОК.
Облако оно тем и хорошо, что платформу, как она есть, можно в него переместить. Платформу менять — адь. Делать это ради Н — глупость.

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

AM>>Тонны жаба кода переписывалась на скалу.
VD>Этому есть подтверждение?

Вот такого тебе хватит?

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

EP>>>Это какой-то простой код с выключенным оптимизатором?
I>>Да, простой код. точность примерно пол-секунды. Позволяет внятно оценить масштаб .net vs .net

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

Мешает политика руководства и говённый джит как следствие. До смешного доходит — кое что уже можно сварганить на джаваскрипте и это будет быстрее работать.

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

VD>Здравствуйте, Alexey.Maletin, Вы писали:

AM>>Крупные коммерческие конторы используют скалу основным языком (из русских Тинькофф, например).

VD>С какого перепугу Тинькофф стал "крупной коммерческой конторой"?

ТКС-то не крупная? Ну не знаю. Загляни в вики, что-ле. Оборот и собственный капитал вполне себе и почти 7000 сотрудников.

Хотя куда им до команды немерле.

AM>>Тонны жаба кода переписывалась на скалу.

VD>Этому есть подтверждение?

Пардоньте, не только с жабы, но и с других языков/платформ. С руби, например, или питона.
Из крупных — библиотеки твиттера. Мелочь гуглится и её очень много.

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

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

EP>>Где я хаял или закидывал Nemerle?
VD>А здесь ты чем занимаешься?

Задал вопрос, на который не нашёл ответа на сайте

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

Есть задача сгенерировать определённый код из схемы (допустим из .xml), причём результирующий код не только на C++.
Насколько я понимаю, Nemerle/Nitra в этом контексте может использоваться как парсер схемы на компактном и удобном DSL (вместо .xml), плюс шаблонизатор (свой DSL для шаблонов), и соответственно генератор кода. Из плюшек, как я понимаю — автоматическая интеграция DSL'ей (схемы и шаблонов) в IDE, так?
Может есть какие-то другие сценарии применения для данного контекста?

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

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

EP>Есть задача сгенерировать определённый код из схемы (допустим из .xml), причём результирующий код не только на C++.

Знакомо

У меня в проекте xslt этим занимается (xml-файл предоставлен другой командой, они его для своих java-нужд используют)

EP>Насколько я понимаю, Nemerle/Nitra в этом контексте может использоваться как парсер схемы на компактном и удобном DSL (вместо .xml), плюс шаблонизатор (свой DSL для шаблонов), и соответственно генератор кода. Из плюшек, как я понимаю — автоматическая интеграция DSL'ей (схемы и шаблонов) в IDE, так?
EP>Может есть какие-то другие сценарии применения для данного контекста?

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

Без этого Нитра для меня будет просто очередным перлом, которым я сгенерю обобщенное нечто, в котором будут сплошные вызовы перегрузок и метафункций для собственно определения нужных типов и вызовов (т.е. генерится куча одинакового кода с enable_if и прочая, в расчете на то, что компилятор потом выкинет все ненужное и найдет все перегрузки). Другого пути сделать типо-корректную кодогенерацию в С++ я не придумал, в отсутствии прямой связи генератора с системой типов (это же относится и к Boost.Preprocessor — он ведь тоже никак не связан с системой типов, так что все те же самые проблемы).

Ну разве что делать плагин для GCC — у меня такая идея давно сидит (с 4.7?), но времени покопаться так и нету.

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

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

I>>>Не фичами, а конструкцию пересмотрели.

VD>>Это и есть фичи.

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

Это несомненно очень важное и конструктивное замечание в контескте данного топика. Развивай абстрактное мышление.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

I>Это _не_ фичи. Это конструктивные особнности.

Гы. Иди почитай перевод слова "фича".

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

ARK>Да, это так. Потому что я не вижу причин его пробовать, как и многие другие языки.

А в чем причина твоего появления здесь? Зачем ты тратишь свое и чужое время?

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

N>Дык само Моно никто не использует.

Тебя послушать, так если ты чего-то не используешь, то никто это и не использует.

А что используется то?

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

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

U>>А вот Clojure отлично за это время развилась. Учитывая ещё тот факт, что Clojure появилась два года после Nemerle в 2007м, но уже в 2008 вышла первая версия. А теперь у Clojure есть офигенное количество библиотек, документации, книжек и контрибьюторов.

VD>Все это есть у немерла.

Где? Наверное здесь: The resource cannot be found.

U>>А команда Nemerle всё это время пилила интеграцию с VS...

VD>Мы уже 6 лет как ее эксплуатируем, как и сам немерл. А вы все ходите и ищите фатальные ндостатки.

Собственно, мы ходим и ищем библиотеки и документацию. Тут вам даже товарищ на google groups задаёт следующий вопрос: Broken docs link and installer error.

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

B>Немерле пока создает впечатление проекта от клуба любителей пилить код но ночам. Типа "смотрите, как изящно на nemerle делается xxx" в полном отрыве от того, скольким людям нужно xxx и насколько им важна изящность.

Изящность важна для создания легко читаемого, легкоподдерживаемого, и как следствие, менее бажного кода. Оцени вот такой простой кусок кода:

        protected override bool ЧитатьСтрокуБезПроверок()
        {
            var стр = ПотокЧтения.ReadLine();
            if( стр == null ) {
                // достигнут конец файла
                ТекСтрока = null;
                return false;
            }
            else {
                // что-то считали
                if( string.IsNullOrWhiteSpace(стр) ) {
                    // рекурсивный пропуск пустых строк
                    return ЧитатьСтрокуБезПроверок();
                }
                else {
                    // строка считана
                    ТекСтрока = стр.Split( new char[] { ';' } );
                    return true;
                }
            }
        }

        protected override ЧитатьСтрокуБезПроверок() : bool
        {
            match( ПотокЧтения.ReadLine() ) {
                | стр when стр == null =>
                    // достигнут конец файла
                    ТекСтрока = null;
                    false

                | стр when string.IsNullOrWhiteSpace(стр) =>
                    // рекурсивный пропуск пустых строк
                    ЧитатьСтрокуБезПроверок()

                | стр =>
                    // строка считана
                    ТекСтрока = стр.Split( { ';' } );
                    true
            }
        }

Вместо ветвлений if/else — линейный match. Это здесь еще ветвлений мало.
Изящность, как синоним слова красота. А красота критерий совершенства. Человек, не разбираясь, например в танцах или боевых исскуствах, может посмотреть как двигается исполнитель и оценить технику исполнения... Если это красиво.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

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

B>>Немерле пока создает впечатление проекта от клуба любителей пилить код но ночам. Типа "смотрите, как изящно на nemerle делается xxx" в полном отрыве от того, скольким людям нужно xxx и насколько им важна изящность.

DS>Изящность важна для создания легко читаемого, легкоподдерживаемого, и как следствие, менее бажного кода. Оцени вот такой простой кусок кода.

Да оно же одинаково! Только else if надо писать.

Pattern matching вещь хорошая только видимо ты не понимаешь почему.

PS: а че стек оверфлоу не будет?

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

BC>>Если скорость работы С# не устраивает, то переходят не на Nemerle, а на Си, разве не так ?

_>Макросы это вообще-то про генерацию кода. Почему не генерировать код на Си из выскоуровневого кода на Nemerle? Вот есть такой проект NUDA, там в качестве примера, вычисления написанные на Nemerle выполняются на GPU, так что ничего невозможного нет.

Ваше предложение выглядит примерно так:

— Пиши на Javascript
— Но он медленный, я лучше буду использовать Си
— Да, но на Javascript ты можешь написать генератор, который будет тебе генерировать программы на Си.

Или так:

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

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

I>>Это _не_ фичи. Это конструктивные особнности.

VD>Гы. Иди почитай перевод слова "фича".

Если брать буквальный перевод, то надо признать, что из Жигуля путем добавления фич можно сделать даже Белаз, не то что Порше Кайен.

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

VD>>>Собственно если тебя интерсуют Плюсы, то можешь попробовать использовать Натйру для реализации кодогенерации для плюсов. Тоже интересное направление.
EP>>Есть задача сгенерировать определённый код из схемы (допустим из .xml), причём результирующий код не только на C++.
J>Знакомо

А у меня xml схема + python.
Помню предлагал на начальном этапе рассмотреть xslt, как минимум для некоторых частей, но как-то не прижилось. Кстати, как он себя показывает? Не слишком многословен? Хватает ли возможностей?

J>Ну разве что делать плагин для GCC — у меня такая идея давно сидит (с 4.7?), но времени покопаться так и нету.

Можно не GCC, а Clang. Недавно была презентация на подобную тему:
https://raw.githubusercontent.com/boostcon/cppnow_presentations_2014/master/files/Create-Your-Own-Refactoring-Tool-with-Clang.pdf
http://www.youtube.com/watch?v=8PndHo7jjHk
Достаточно .pdf просмотреть.

Вкратце — у Clang'а есть библиотека которая позволяет искать в AST поддеревья заданные декларативными конструкциями вида:

forStmt(hasLoopInit(declStmt(hasSingleDecl(varDecl(hasInitializer(integerLiteral(equals(0))))))))
// или
constructExpr
(
    hasDeclaration(methodDecl(hasName(StringConstructor))),
    argumentCountIs(2),
    hasArgument
    (
        0,
        id
        (
            "call",
            memberCallExpr
            (
                callee(id("member", memberExpr())),
                callee(methodDecl(hasName(StringCStrMethod))),
                on(id("arg", expr()))
            )
        )
    ),
    hasArgument(1, defaultArgExpr())
)

Каждое подходящее поддерево Clang передаётся нашему callback'у. Так же можно это дерево изменить (например в целях рефакторинга) — и всё автоматом преобразуется обратно в C++ код. Т.е. это своего рода regex для C++ AST.

Но возможно в твоём случае это не подойдёт, может фаза слишком ранняя. Зависит от того, какая именно информация нужна.

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

VD>А в чем причина твоего появления здесь? Зачем ты тратишь свое и чужое время?

Просто высказал свое мнение. Форум вроде для того и существует, разве нет? Или это запрещено правилами?
Кроме того, я писал вовсе не вам. Так что зачем вы тратите свое время на простыни про мартышек и очки — это вам виднее.

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

DS>Оцени вот такой простой кусок кода:

Оба куска кода абсолютно одинаковые.
Разве что в первом случае в глазах не рябит от похожести символов "|" и "}".

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

VD>А что используется то?

Что угодно, нo платформа должна быть едина и "первоклассна". "Первоклассность" в случае .NET означает винду, но тогда возникает проблема с единством. К примеру тот же грид/кластер на винде — экзотика.

Самое смешное что последнее время в наиболее "продвинутых" местах (инвест. банки, аэроспейс, интернет-монстры) у .NET языков стали появились проблемы даже с гуями. Клиенты-то обычно конечно винда, но код хочется иметь единый и не городить интеропа, а значит "щарпы" на помоечку. На моем PC к примеру сейчас осталась ровно одна .NET апликуха, все остальное на {QT|wx}/Python или EclipseRCP/Java. Наши конкуренты, очень захотевшие WPF, вложились в питоновский байндинг к .NET — вроде тоже полет нормальный.

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

I>Так много, что вакансий около нуля.

Acь?
http://www.glassdoor.com/Job/clojure-jobs-SRCH_KO0,7.htm

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

EP>Помню предлагал на начальном этапе рассмотреть xslt, как минимум для некоторых частей, но как-то не прижилось. Кстати, как он себя показывает? Не слишком многословен? Хватает ли возможностей?

Ну для моего сценария — да, вполне хватило.

J>>Ну разве что делать плагин для GCC — у меня такая идея давно сидит (с 4.7?), но времени покопаться так и нету.

EP>Можно не GCC, а Clang. Недавно была презентация на подобную тему

Ага. На BoostCon тоже прикольная штука была про REPL для шаблонного метапрограммирования, тоже на Clang.
Он вообще фичастый в этом плане.

EP>Но возможно в твоём случае это не подойдёт, может фаза слишком ранняя. Зависит от того, какая именно информация нужна.

Мне не подойдет его кодогенератор. Все-таки GCC генерит более оптимальный код.
Так что если и юзать Clang, то в качестве стороннего инструмента для какого-нть хиторого анализа кода по аннотациям (например, для проверки, что ни одна строчка в функции не бросает исключений — наверняка это можно сделать на Clang)

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

VD>Для генерации и парсинга C++ нитра уже пригодна. Остается только написать грамматику C++. Те же квази-цитаты будут из каробки доступны. Вот типизацию придется подождать.
Для того чтобы парсить с++ нужно уметь его типизировать. Я имею ввиду разрешение неоднозначностей типа: a(b) — декларация b или вызов функции a; xxx< ... — аргументы шаблона или оператор меньше.
Что сейчас предлагается с этим делать?

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

J>Мне не подойдет его кодогенератор. Все-таки GCC генерит более оптимальный код.

Это скажем так "depends" и надо мерить: http://stackoverflow.com/questions/3187414/clang-vs-gcc-which-produces-better-binaries
И если для тебе это так критично почему не ICC?

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

Z>Для того чтобы парсить с++ нужно уметь его типизировать. Я имею ввиду разрешение неоднозначностей типа: a(b) — декларация b или вызов функции a; xxx< ... — аргументы шаблона или оператор меньше.
Z>Что сейчас предлагается с этим делать?
Парсер может создавать неоднозначный АСТ. Те там просто будут оба варианта.
А типизатор уже разберется, что это было.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

J>Ага. На BoostCon тоже прикольная штука была про REPL для шаблонного метапрограммирования, тоже на Clang.

Видел, точнее пролистал презентацию — насколько я понял там интерактивный REPL печатающий тип выражения (результат метафункции) + pretty-printer. Не знаю на сколько удобно — всегда хватало форсинга ошибки компиляции с нужным типом в сообщении.

EP>>Но возможно в твоём случае это не подойдёт, может фаза слишком ранняя. Зависит от того, какая именно информация нужна.
J>Мне не подойдет его кодогенератор. Все-таки GCC генерит более оптимальный код.
J>Так что если и юзать Clang, то в качестве стороннего инструмента для какого-нть хиторого анализа кода по аннотациям

Да, я и имел в виду использование как внешней утилиты, без генерации бинарников.

J>(например, для проверки, что ни одна строчка в функции не бросает исключений — наверняка это можно сделать на Clang)

Ещё можно использовать для запрещения ряда конструкций (например new), точнее запрещение по-умолчанию. Можно вообще оставить только безопасное babysitting подмножество (для тех случаев где нужны жёсткие гарантии), где весь unsafe будет в специальных библиотеках.
Или хоть тот же compile-time reflection (вызывать макросы Boost.Fusion для помеченных атрибутами классов, либо для всех в файле и т.п.).
В общем есть где разгуляться

BC>- Да, но на Javascript ты можешь написать генератор, который будет тебе генерировать программы на Си.
BC>- Да, но зачем нам морочить голову с Си ? Давайте на Си нагенерим генератором ассемблерные команды.

Ты всё перепутал. Я говорю: "Не трать время на переходы с одного ограниченного языка на другой. Пиши сразу на генераторе. В этом случае у тебя будет возможность генерировать любые команды."

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

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

B>>Немерле пока создает впечатление проекта от клуба любителей пилить код но ночам. Типа "смотрите, как изящно на nemerle делается xxx" в полном отрыве от того, скольким людям нужно xxx и насколько им важна изящность.

DS>Изящность важна для создания легко читаемого, легкоподдерживаемого, и как следствие, менее бажного кода. Оцени вот такой простой кусок кода:
DS>Вместо ветвлений if/else — линейный match. Это здесь еще ветвлений мало.
Оба варианта — какой-то дикий адский overengineering того, что в принципе делается одной строчкой:

return File.ReadAllLines(fn).Where(l => !string.IsNullOrEmpty(l)).First().Split(';');

Если не надо читать весь файл сразу, то можно вместо ReadAllLines сделать свою версию на yield return. Издержки на создание итераторов все равно будут минимальными по сравнению с disk IO.
DS>Изящность, как синоним слова красота. А красота критерий совершенства. Человек, не разбираясь, например в танцах или боевых исскуствах, может посмотреть как двигается исполнитель и оценить технику исполнения... Если это красиво.
Большинству людей надо ехать, а не шашечки. Изящное такси со стеклянным прозрачным мотором, где видна техника исполнения — это безусловно бальзам на душу дизайнера двигателей, но если мне нужно такси, то я возьму то, что быстрее приедет и дешевле отвезет, а требования к комфорту и изящности будут довольно стандартные.

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

Z>Для того чтобы парсить с++ нужно уметь его типизировать. Я имею ввиду разрешение неоднозначностей типа: a(b) — декларация b или вызов функции a; xxx< ... — аргументы шаблона или оператор меньше.
Z>Что сейчас предлагается с этим делать?

Тупо парсится оба варианта. Никаких специальных действий предпринимать не надо. Потом можно будет выбрать нужные на базе информации о типах.

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

GIV>Да оно же одинаково! Только else if надо писать.

Неодинаково. Если добавить еще ветвления условий, то код на шарпе будет плохо читаться.

GIV>Pattern matching вещь хорошая только видимо ты не понимаешь почему.

Это просто маленький примерчик. Но ты все равно объясни, о мудрейший.

GIV>PS: а че стек оверфлоу не будет?

Из-за пары строк не будет.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

B>Оба варианта — какой-то дикий адский overengineering того, что в принципе делается одной строчкой:

Да ты што!
B>

B>return File.ReadAllLines(fn).Where(l => !string.IsNullOrEmpty(l)).First().Split(';');
B>

B>Если не надо читать весь файл сразу, то можно вместо ReadAllLines сделать свою версию на yield return. Издержки на создание итераторов все равно будут минимальными по сравнению с disk IO.
Чиать надо построчно — реализация аналогична IDataReader.
Ну а теперь приведи весь код с созданием итератора. И мы посмотрим на твою одну строку

DS>>Изящность, как синоним слова красота. А красота критерий совершенства. Человек, не разбираясь, например в танцах или боевых исскуствах, может посмотреть как двигается исполнитель и оценить технику исполнения... Если это красиво.
B>Большинству людей надо ехать, а не шашечки. Изящное такси со стеклянным прозрачным мотором, где видна техника исполнения — это безусловно бальзам на душу дизайнера двигателей, но если мне нужно такси, то я возьму то, что быстрее приедет и дешевле отвезет, а требования к комфорту и изящности будут довольно стандартные.

Опять идиотские аналогии абсолютно не в кассу.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

GIV>PS: а че стек оверфлоу не будет?

И это, компилятор рекурсию развернет в цикл, если обернуть матч в локальную ф-цию.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

GIV>>PS: а че стек оверфлоу не будет?

DS>И это, компилятор рекурсию развернет в цикл, если обернуть матч в локальную ф-цию.

Это видимо для пущей простоты и читаемости.

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

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

B>>Оба варианта — какой-то дикий адский overengineering того, что в принципе делается одной строчкой:

DS>Да ты што!
B>>

B>>return File.ReadAllLines(fn).Where(l => !string.IsNullOrEmpty(l)).First().Split(';');
B>>

B>>Если не надо читать весь файл сразу, то можно вместо ReadAllLines сделать свою версию на yield return. Издержки на создание итераторов все равно будут минимальными по сравнению с disk IO.
DS>Чиать надо построчно — реализация аналогична IDataReader.
DS>Ну а теперь приведи весь код с созданием итератора. И мы посмотрим на твою одну строку

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

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

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

AVK>Делаю предсказание. Если за пять лет ситуация не изменится (а она, судя по всему, не изменится, потому что даже самые активные любители Немерле занимаются Немерле исключительно ради Немерле), то Немерле тихо мирно скончается.

Как может умереть то, что и так мертво? Нашествие живых мертвецов и срочно требуется серебряная пуля?

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

AM>Вобщем, немерле нужно больше золота и пиара.

Гик-оринтированному, Windows-only языку никакие деньги и пиар не помогут. Надо просто перестать насиловать труп и закопать его

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

BC>>- Да, но на Javascript ты можешь написать генератор, который будет тебе генерировать программы на Си.
BC>>- Да, но зачем нам морочить голову с Си ? Давайте на Си нагенерим генератором ассемблерные команды.

_>Ты всё перепутал. Я говорю: "Не трать время на переходы с одного ограниченного языка на другой. Пиши сразу на генераторе. В этом случае у тебя будет возможность генерировать любые команды."

Так никто в мире высокопроизводительные программы не пишет на генераторах.
За что мне такое наказание ?

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

DS>Изящность важна для создания легко читаемого, легкоподдерживаемого, и как следствие, менее бажного кода. Оцени вот такой простой кусок кода:
DS>

DS>        protected override bool ЧитатьСтрокуБезПроверок()
DS>        {
DS>            var стр = ПотокЧтения.ReadLine();
DS>            if( стр == null ) {
DS>                // достигнут конец файла
DS>                ТекСтрока = null;
DS>                return false;
DS>            }
DS>            else {
DS>                // что-то считали
DS>                if( string.IsNullOrWhiteSpace(стр) ) {
DS>                    // рекурсивный пропуск пустых строк
DS>                    return ЧитатьСтрокуБезПроверок();
DS>                }
DS>                else {
DS>                    // строка считана
DS>                    ТекСтрока = стр.Split( new char[] { ';' } );
DS>                    return true;
DS>                }
DS>            }
DS>        }
DS>

Этот же код упадет со Stackoverflow при наличии длинного файла, не ?
Первый раз в жизни вижу такое ... хм ... экзотическоре решение на рекурсии.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

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

DS>>Оцени вот такой простой кусок кода:

ARK>Оба куска кода абсолютно одинаковые.
ARK>Разве что в первом случае в глазах не рябит от похожести символов "|" и "}".

        protected override ЧитатьСтрокуБезПроверок() : bool
        {
            match( ПотокЧтения.ReadLine() ) {
                | стр when стр == null                    => { ТекСтрока = null; false }
                | стр when string.IsNullOrWhiteSpace(стр) => ЧитатьСтрокуБезПроверок()
                | стр                                     => { ТекСтрока = стр.Split(';'); true }
            }
        }

Так не рябит в глазках?

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

BC>Так никто в мире высокопроизводительные программы не пишет на генераторах.
Да неужели?

А на чём пишут? И чтоб два раза не вставать, что такое компилятор C как не генератор ассемблерных инструкций из чуть более высокоуровневых?

BC>За что мне такое наказание?
Нефиг было в тему влазить!

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

ARK>>Разве что в первом случае в глазах не рябит от похожести символов "|" и "}".

DS>

DS>        protected override ЧитатьСтрокуБезПроверок() : bool
DS>        {
DS>            match( ПотокЧтения.ReadLine() ) {
DS>                | стр when стр == null                    => { ТекСтрока = null; false }
DS>                | стр when string.IsNullOrWhiteSpace(стр) => ЧитатьСтрокуБезПроверок()
DS>                | стр                                     => { ТекСтрока = стр.Split(';'); true }
DS>            }
DS>        }
DS>

DS>Так не рябит в глазках?

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

Недавно тут некий VladD2 спрашивал про неконсистентность. Вот без особого моего желания всплыл пример: почему условия начинаются с символа "|", а продолжаются ключевым словом "when"? Почему не сделать "case-when-then"? Или "when-if-then"?
Еще тут же — почему символ "=>" используется как в ветках ПМ, так и в лямбдах, в разных семантически контекстах, но похожих синтаксически?

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

BC>>Так никто в мире высокопроизводительные программы не пишет на генераторах.
_>Да неужели?

А на чём пишут? И чтоб два раза не вставать, что такое компилятор C как не генератор ассемблерных инструкций из чуть более высокоуровневых?

Компилятор Си не генератор кода ассемблерных инстукрций. Его цель не файл с листингами ассемблерных комманд, а бинарный файл с машинными коммандами.
И да, если возникают проблемы с быстродействием Си, спускаются на уровень ниже и пишут ассемблерные вставки, тюнят алгоритм. Генератору места там нет.

ЗЫ: Не понимаю, зачем пытаться пропихнуть Немерле во все щели вподряд. Щас еще чуть-чуть и адепты Немерле сделают с него убийцу Си и Ассемблера.
Вам нужно не врываться во все сферы вподряд, ограничиться своим огородом и потихоньку его вспахивать. По крайней мере это со стороны будет выглядеть разумней.

_>>что такое компилятор C как не генератор ассемблерных инструкций из чуть более высокоуровневых?

BC>Компилятор Си не генератор кода ассемблерных инстукрций. Его цель не файл с листингами ассемблерных комманд, а бинарный файл с машинными коммандами.
BC>И да, если возникают проблемы с быстродействием Си, спускаются на уровень ниже и пишут ассемблерные вставки, тюнят алгоритм. Генератору места там нет.

Причём тут цель? Какие проблемы? Куда с темы съезжаешь? Ты утверждаешь что преобразование высокоуровневых инструкций в низкоуровневые компилятором С есть или что этого преобразования нет?

BC>ЗЫ: Не понимаю, зачем пытаться пропихнуть Немерле во все щели вподряд. Щас еще чуть-чуть и адепты Немерле сделают с него убийцу Си и Ассемблера.
BC>Вам нужно не врываться во все сферы вподряд, ограничиться своим огородом и потихоньку его вспахивать. По крайней мере это со стороны будет выглядеть разумней.

Чёт я не догоняю. Вот это сообщение ты написал? Или это я полез в форум cpp революционные идейки пропихивать??

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

_>Причём тут цель? Какие проблемы? Куда с темы съезжаешь? Ты утверждаешь что преобразование высокоуровневых инструкций в низкоуровневые компилятором С есть или что этого преобразования нет?

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

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

B>Для того, чтобы продукт "взлетел", он должен:

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

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

BC>Так никто в мире высокопроизводительные программы не пишет на генераторах.

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

Собственно общий подход:
1. Придумываем ДСЛ на котором можно решить задачу.
2. Делаем компилятор этого ДСЛ-я транслирующий его в некоторый язык (от машинного, до языка высокого уровня).
3. Пишем решение на ДСЛ-е.
4. Запускаем компилятор, передаем ему код на ДСЛ и получаем программу.

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

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

_>>Причём тут цель? Какие проблемы? Куда с темы съезжаешь?
Ты утверждаешь что преобразование высокоуровневых инструкций в низкоуровневые компилятором С есть или что этого преобразования нет?

BC>Тебе нужно отличать компиляторы от кодогенераторов.
Это такой ответ на однозначный вопрос??

BC>У компиляторов цель собрать файл с машинными инструкциями.
javaс с первых строк смотрит на нас с недоумением. Равно как компилятор C# и тыщи других.

Я в общем тоже сомневаюсь. Вот компилятор C, например, генерирует некие объектники, которые для исполнения непригодны. Они пригодны лишь для чтения, и выбор выходного формата определяется ключами компиляции. Один из форматов доступен для чтения человеком — там вполне себе ассемблер (gcc -S например). Более того, много лет назад, были компиляторы C которые только так и работали — генерировали асм, который потом шёл в TASM/MASM. Но сейчас чаще используется другой формат, который другая программа — линкер, собирает во что-то ещё. Но даже это что-то, для исполнения тоже не годится — нужен ещё системный лоадер, который напоследок фиксит там адреса всякие, располагает что где надо, и только после этого можно говорить о каких-то инструкциях.

BC>У кодогенераторов — нагенерить код другого, более низкоуровнего языка.
Википедия, статья Трансляторы. Там и про компиляторы, и стадии генерации внезапно, тоже есть.

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

BC>Компилятор Си не генератор кода ассемблерных инстукрций. Его цель не файл с листингами ассемблерных комманд, а бинарный файл с машинными коммандами.
BC>И да, если возникают проблемы с быстродействием Си, спускаются на уровень ниже и пишут ассемблерные вставки, тюнят алгоритм. Генератору места там нет.

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

Собственно компилятор (он же транслятор) это преобразователь из одного языка в другой. Это общее его определение. Если не веришь, сходи на Википеди и убедись.

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

BC>Тебе нужно отличать компиляторы от кодогенераторов.

В этом нет особого смысла. Например, первый компилятор С++ был годогенератором в С. Но от этого он не переставал быть компилятором С++.

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

BC>У компиляторов цель собрать файл с машинными инструкциями.
BC>У кодогенераторов — нагенерить код другого, более низкоуровнего языка.

Вот только разница между этим не очень большая. Промежуточная генерация С чуть-чуть замедлит процесс компиляции, но резко упростит компилятор. Ты можешь скрыть эту стадию, если хочешь.

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

I>Если брать буквальный перевод, то надо признать, что из Жигуля путем добавления фич можно сделать даже Белаз, не то что Порше Кайен.

С точки зрения абстракции так оно и есть. А не делают так только потому, что проще с нуля все сделать, чем фичи добавлять.

С языками же все совсем не так.

В прочем, Немерл и был создан с нуля. К мимикрии под Шарп он шел долгие годы. Первая версия была написана на МЛ-е. Это и сейчас можно наблюдать, если посмотреть начальные комиты в репозитории.

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

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

BC>>На самом деле разницы между ассемблерным листингом и машкодами нет.

Есть разница в недокументированых возможностях.
Но не суть важно, вопрос к обеим.

Каким образом программа на Немерле будет работать быстрее чем на Си ?
И как убедить человека, если нужно улучшить быстродействие программы, переписать ее не с С# на Си
А с С# на Немерле (Нитра).

В этом был вопрос.
И вы почемуто потянули для себя этот бесполезный спор.

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

VD>>На самом деле разницы между ассемблерным листингом и машкодами нет.
BC>Есть разница в недокументированых возможностях.

Даже не так
However, in some cases, an assembler may provide pseudoinstructions (essentially macros) which expand into several machine language instructions to provide commonly needed functionality. For example, for a machine that lacks a "branch if greater or equal" instruction, an assembler may provide a pseudoinstruction that expands to the machine's "set if less than" and "branch if zero (on the result of the set instruction)". Most full-featured assemblers also provide a rich macro language (discussed below) which is used by vendors and programmers to generate more complex code and data sequences.

Ассемблер есть в какойто мере небольшой абстракцией над машинными коммандами.
Тоесть разница между ассемблерным листингом и машкодами есть, это не тупое соответствие имен к машкодам.

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

ARK>Просто высказал свое мнение.

А кому здесь нужно мнение человека не знающего предмета обсуждения?

Как бы, люди говорящее — "не нужен" ненужны.

BC>Каким образом программа на Немерле будет работать быстрее чем на Си ?
А если критическая важная часть будет компилироваться на CUDA или FPGA

BC>И как убедить человека, если нужно улучшить быстродействие программы, переписать ее не с С# на Си
Для начала он должен посидеть с профайлером не один час, прежде чем принимать такое радикально решение

BC>А с С# на Немерле (Нитра).
BC>В этом был вопрос.
В реальной жизни люди ищут пути вытягивать работающий код через трансляцию, а не кидаться всё переписать. Переписать что-то большое и работающее может стоить дороже чем подарить клиенту, у которого тормозит, новое железо.

BC>И вы почемуто потянули для себя этот бесполезный спор.

А кто-то пытался убедить тебя в том что Nemerle будет быстрее чем что-то там? Разве имеет смысл вообще сравение на скорость сферических программ в вакууме?

Мы же сейчас как школота, спорим "кто сильнее, бэтмэн или человек-паук?".

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

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

GIV>Да оно же одинаково! Только else if надо писать.

Вообще-то оно процентов на 10 короче и линейнее. Понятно, что чем сложнее пример, тем больше различие, но и тут выигрыш на лицо.

GIV>PS: а че стек оверфлоу не будет?

Это еще одна фича языка — гарантированная оптимизация (переписывание в цикл) концевой рекурсии.

Так что прибавь в этот пример еще цикл на шаре, так как в нем оптимизация концевой рекурсии не гарантируется.

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

DS>И это, компилятор рекурсию развернет в цикл, если обернуть матч в локальную ф-цию.

Он ее и так развернет. Главное чтобы возвращаемое значение рекурсивной функции не использовалось (т.е., чтобы рекурсия была концевая).

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

DS>>И это, компилятор рекурсию развернет в цикл, если обернуть матч в локальную ф-цию.

GIV>Это видимо для пущей простоты и читаемости.

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

И, да — это для простоты. Для простоты использования функциональных алгоритмов. В Немерле можно использовать циклы, а можно концевую рекурсию. Результат будет одинаков. В Шарпе же концевая рекурсия будет оптимизироваться в релизи некоторыми рантаймами, а некоторыми не будет. Короче, не гарантировано спецификация, а значит не применимо для общего случая и дает оверхед, даже если переполнения стека не произойдет.

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

DS>

DS>        protected override ЧитатьСтрокуБезПроверок() : bool
DS>        {
DS>            match( ПотокЧтения.ReadLine() ) {
DS>                | стр when стр == null                    => { ТекСтрока = null; false }
DS>                | стр when string.IsNullOrWhiteSpace(стр) => ЧитатьСтрокуБезПроверок()
DS>                | стр                                     => { ТекСтрока = стр.Split(';'); true }
DS>            }
DS>        }
DS>

DS>Так не рябит в глазках?

Скобки ненужны. Можно так:

        protected override ЧитатьСтрокуБезПроверок() : bool
        {
            match( ПотокЧтения.ReadLine() )
            {
                | стр when стр == null                    => ТекСтрока = null; false
                | стр when string.IsNullOrWhiteSpace(стр) => ЧитатьСтрокуБезПроверок()
                | стр                                     => ТекСтрока = стр.Split(';'); true
            }
        }

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

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

Что бы ты не делал, переписав код на Шарп ты получишь более корявое решение.

DarthSidius пытался продемонстрировать, что в Немерле можно избежать вложенных ветвлений превратив их в плоский список.
Мелочь, конечно, но их в Немерле море.

ARK>Недавно тут некий VladD2 спрашивал про неконсистентность. Вот без особого моего желания всплыл пример: почему условия начинаются с символа "|", а продолжаются ключевым словом "when"? Почему не сделать "case-when-then"? Или "when-if-then"?

По грамматике. Вот только "неконсистентность" тут не причем.

Матч (упрощенно) имеет такую грамматику:

syntax Match = 
  "match" "(" Expr ")"
  "{"
      Case+
  "}";

syntax Case = ("|" Pattarn)+ Guard? "=>" Expr+;

syntax Guard = "when" Expr;

Один из видов паттернов — это подстановочный символ (вилкард) — "_". Он сопоставляется с любым выражением. Так же есть паттерн "переменная". Она так же сопоставляется с любым выражением, но позволяет связать с ним имя.

Guard = это дополнительное условие применимое к любому паттерну. В том числе и к паттернам "_" и "переменная". Таким образом можно создать вырожденный match который паттерны которого будут всегда сопоставляться, но вызовется только тот, чей Guard вернет true. Если таких Guard-ов несколько, то сработает тот что указан в матче раньше.

ARK>Еще тут же — почему символ "=>" используется как в ветках ПМ, так и в лямбдах, в разных семантически контекстах, но похожих синтаксически?

Нормальное явление для языков. Тем более, что по смыслу эти вещи очень похоже. Тебя не смущает, что в C# using используется и в качестве стейтмента, и в качестве директивы импорта? А то что в дженериках используются знаки < и >?

Короче, ты просто придираешься.

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

B>Оба варианта — какой-то дикий адский overengineering того, что в принципе делается одной строчкой:
B>

B>return File.ReadAllLines(fn).Where(l => !string.IsNullOrEmpty(l)).First().Split(';');
B>

Какой мощный язык этот ваш C#?! Убедил!

Если серьезно, тебе показывали абстрактный пример. Ты начал умничать. В этом примитивном случает ты может и сможешь переписать код на ФВП, но во общем случае — нет. К тому же по соображениям производительности ФВП могут быть недопустимы.

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

К тому же это явно не эквивалентный код. Твой вариант а) обламывается на конце файла: б) не его нельзя вызвать последовательно для получения значений. Короче, это сжатие методом jpeg, с потерей качестве

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

B>Ну тогда надо сравнивать код реализации итератора с кодом вашего вундер-компилятора

Тебе пример и на шарпе написали. Подразумевается, что эта функция может вызваться последовательно для считывания отдельных строк из потока.

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

B>Ты хочешь понять, почему у вас мало юзеров, или меня убедить что завтра все вдруг оценят ваш немерле и пойдут им пользоваться?

У кого у нас? Мы сами юзеры. А вы мартышки из известной басни. И заняться вам не чем. Вот вы здесь и занимаетесь гоном на вещи которые понять не смогли.

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

BC>Этот же код упадет со Stackoverflow при наличии длинного файла, не ?
BC>Первый раз в жизни вижу такое ... хм ... экзотическоре решение на рекурсии.

Шарповская версия — да. Немерловая — нет, так как в Немерле ганатирована (спецификацией) оптимизация хвостовой рекурсии.

В Немерле реально циклов даже нет. Это все макросы переписывающие код в рекурсивные локальные функции. А уже компилятор оптимизирует код и превращает его в условные и безусловные переходы в МСИЛ-е (т.е. в аналоги циклов).

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

IT>Это заблуждение. Для того, чтобы взлететь нужно с годик, два, три массово и навязчиво попиарить продукт где только можно. Какой для этого нужен бюджет понятия не имею. Но вот то, что новых фич там может и не быть совсем — это факт.

Согласен. Но и продукт должен быть надлежащего качества. Так что мы прежде чем по новой пробовать пиарить, все таки родим убер-реализацию

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

KP>Гик-оринтированному, Windows-only языку никакие деньги и пиар не помогут. Надо просто перестать насиловать труп и закопать его

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

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

KP>Как может умереть то, что и так мертво? Нашествие живых мертвецов и срочно требуется серебряная пуля?

Лучше скажи, как может быть мертво то, чем пользуются люди?

Вот сколько у тебя продуктов на Расте написано? У меня на Немерле где-то 10 приложений. В том числе Нитра, которая уже по сложности переплюнула Немерл.

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

BC>>Каким образом программа на Немерле будет работать быстрее чем на Си ?
_>А если критическая важная часть будет компилироваться на CUDA или FPGA

Сколько кода уже скомпилировано в продакшин Немерле->CUDA\FPGA ?

BC>>И как убедить человека, если нужно улучшить быстродействие программы, переписать ее не с С# на Си
_>Для начала он должен посидеть с профайлером не один час, прежде чем принимать такое радикально решение

А что там курить ? Шарп\Немерле по сравнению с Си скриптовый язык.
Ты вот эту штучку покури, например как на Си написана обычное Trie, может
горячий пыл CUDA\FPGA\Генераторы Шмырыгаторы поутихнет.
http://judy.sourceforge.net/doc/shop_interm.pdf

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

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

B>>Ну тогда надо сравнивать код реализации итератора с кодом вашего вундер-компилятора

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

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

B>>Ты хочешь понять, почему у вас мало юзеров, или меня убедить что завтра все вдруг оценят ваш немерле и пойдут им пользоваться?

VD>У кого у нас? Мы сами юзеры. А вы мартышки из известной басни. И заняться вам не чем. Вот вы здесь и занимаетесь гоном на вещи которые понять не смогли.
Нет проблем. Добавил Nemerle в фильтр рядом с политикой. Больше беспокоить ваше царство не буду. Удачи.

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

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

Давай, разберем тобой написанное:
>Человек, не разбираясь, например в танцах или боевых исскуствах, может посмотреть как двигается исполнитель и оценить технику исполнения
>ТекСтрока = null;
>ТекСтрока = стр.Split( { ';' } );
>Вместо ветвлений if/else — линейный match.
с теми же самыми проблемами.

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

>protected override
Этому проектированию явно не хватает анемичности

>var стр = ПотокЧтения.ReadLine();
У этого кода избыток побочных эффектов (неявное IO)

>ТекСтрока = null;
У этого кода избыток побочных эффектов (мутабельный стейт)

>return ЧитатьСтрокуБезПроверок();
Надуманные глупости, ведь никто, пишущий в стиле "ТекСтрока = null" не станет звать рекурсию.

Резюмируя: нельзя вот так просто взять кусок неадекватного кода, "присахарить", и утверждать, что на Немерле такая ***ня пишется лучше.

Этот пример демонстрирует только проблемы Немерле: отсутствие не нуллабельных классов, отсутствие чистых функций, подверженность ООП-"декомпозиции".

BC>>>Каким образом программа на Немерле будет работать быстрее чем на Си ?
_>>А если критическая важная часть будет компилироваться на CUDA или FPGA

BC>Сколько кода уже скомпилировано в продакшин Немерле->CUDA\FPGA ?
В вопросах "сколько кода в продакшн" последние лет 40 всех заруливает Кобол. Главное, я так понимаю, вопрос "каким образом" с повестки дня уже снят?

BC>А что там курить ? Шарп\Немерле по сравнению с Си скриптовый язык.
И как же я в студии смотрю show disassembly в .NET отладчике? Есть идеи, как такое вообще возможно для языков которые ты называешь скриптовыми?

BC>Ты вот эту штучку покури, например как на Си написана обычное Trie, может
BC>горячий пыл CUDA\FPGA\Генераторы Шмырыгаторы поутихнет.
BC>http://judy.sourceforge.net/doc/shop_interm.pdf
Посмотрел. Показалось что там нет ничего относящегося к теме которую мы тут сейчас обсуждаем.

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

BC>А что там курить ? Шарп\Немерле по сравнению с Си скриптовый язык.

Разве что с точки зрения полного дилетанта.

BC>Ты вот эту штучку покури, например как на Си написана обычное Trie, может
BC>горячий пыл CUDA\FPGA\Генераторы Шмырыгаторы поутихнет.
BC>http://judy.sourceforge.net/doc/shop_interm.pdf

Какая-то детская пенесометрия.

И глупая к тому же, так как если алгоритм параллелится на CUDA, то тягаться с ним способом битовыжимания на ЦП является полнейшим идиотизмом.

ЗЫ

Короче, уж пенесометрия тут точно офтоп. Завязывайте пока не поздно.

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

B>Нет проблем. Добавил Nemerle в фильтр рядом с политикой. Больше беспокоить ваше царство не буду. Удачи.

Удачно потрясти!

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

>>protected override
STD>Этому проектированию явно не хватает анемичности

Щито?

>>var стр = ПотокЧтения.ReadLine();
STD>У этого кода избыток побочных эффектов (неявное IO)
>>ТекСтрока = null;
STD>У этого кода избыток побочных эффектов (мутабельный стейт)

Не смеши! Напиши DataReader без побочных эффектов. Без IO и без мутабельного стейта.

>>return ЧитатьСтрокуБезПроверок();
STD>Надуманные глупости, ведь никто, пишущий в стиле "ТекСтрока = null" не станет звать рекурсию.

STD>Резюмируя: нельзя вот так просто взять кусок неадекватного кода, "присахарить", и утверждать, что на Немерле такая ***ня пишется лучше.

STD>Этот пример демонстрирует только проблемы Немерле: отсутствие не нуллабельных классов, отсутствие чистых функций, подверженность ООП-"декомпозиции".

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

B>>>Если не надо читать весь файл сразу, то можно вместо ReadAllLines сделать свою версию на yield return. Издержки на создание итераторов все равно будут минимальными по сравнению с disk IO.
DS>>Чиать надо построчно — реализация аналогична IDataReader.
DS>>Ну а теперь приведи весь код с созданием итератора. И мы посмотрим на твою одну строку

B>Ну тогда надо сравнивать код реализации итератора с кодом вашего вундер-компилятора

Съехал с темы. Слив засчитан.
Значит одной строчкой итератор не создать.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

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

B>>>>Если не надо читать весь файл сразу, то можно вместо ReadAllLines сделать свою версию на yield return. Издержки на создание итераторов все равно будут минимальными по сравнению с disk IO.
DS>>>Чиать надо построчно — реализация аналогична IDataReader.
DS>>>Ну а теперь приведи весь код с созданием итератора. И мы посмотрим на твою одну строку

B>>Ну тогда надо сравнивать код реализации итератора с кодом вашего вундер-компилятора

DS>Съехал с темы. Слив засчитан.
DS>Значит одной строчкой итератор не создать.
Ага, нужно ВНЕЗАПНО аж целых 3:

        public static IEnumerable<string> ReadLineByLine(string fn)
        {
            using (var sr = File.OpenText(fn))
                while (!sr.EndOfStream)
                    yield return sr.ReadLine();
        }

Dispose() по выходу из foreach() вызывается, если что. Причем, этот код пищется один раз, запихивается в какой-нибудь внутренний AcmeUtilityLib и вызывается не сложнее File.ReadAllLines().

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

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

B>>Нет проблем. Добавил Nemerle в фильтр рядом с политикой. Больше беспокоить ваше царство не буду. Удачи.

VD>Удачно потрясти!
Продолжая аналогию, я-таки открыл для себя, что купить банан в магазине выходит дешевле, чем ехать на плантацию и трясти пальму самому и поэтому с удивлением смотрю на людей, порочащих всеобщее применение инновационной палке, позволяющей сбивать бананы в 2 раза быстрее...

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

B>Продолжая аналогию, я-таки открыл для себя, что купить банан в магазине выходит дешевле, чем ехать на плантацию и трясти пальму самому и поэтому с удивлением смотрю на людей, порочащих всеобщее применение инновационной палке, позволяющей сбивать бананы в 2 раза быстрее...

Я сморю тебе с нами понравилось! Оставайся, только смени свой менторский тон на дружелюбный. Мы тебе много интересного можем рассказать.

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

Только банан купленный в магазине зеленный и невкусный — ни запаха, ни вкуса, ни витаминов. Один понос от него.
А банан с пальмы — ароматный, спелый, вкусный, полезный.

Какой банан выбираешь ты?

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

DS>>Значит одной строчкой итератор не создать.
B>Ага, нужно ВНЕЗАПНО аж целых 3:

Так и там тоже 3 строчки. И все они перед глазами, все ясно, что и как.
Но вот до сих пор не пойму, речь шла о развесистых деревьях if/else vs match — на что я привел маааленький пример. Тут же нашлась куча критиков, но весь издаваемый ими шум не по теме:
— один сказал, что все одинаково
— другой сказал, что в глазах рябит от палочек и скобочек
— третий, что здесь надо делать итераторы и сувать их как можно глубже... в библиотеку
— четвертый, что: КАК-ТАК! Здесь же IO

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

Ну и где конструктив?

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

D>Это еще одна фича языка — гарантированная оптимизация (переписывание в цикл) концевой рекурсии.

VD>Так что прибавь в этот пример еще цикл на шаре, так как в нем оптимизация концевой рекурсии не гарантируется.

А ну да, протупил, она ж концевая.

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

VD>Лучше скажи, как может быть мертво то, чем пользуются люди?

Ты это про 2,5 энтузиастов + авторов компилятора? Люди пользуются Scala, Clojure и это понятно почему и дальше будет так же. Но вот в случае с Немерле народу не прибавится.

VD>Вот сколько у тебя продуктов на Расте написано? У меня на Немерле где-то 10 приложений. В том числе Нитра, которая уже по сложности переплюнула Немерл.

А причем тут Раст? Я на него, по сравнению с твоими затратами ресурсов на Немерле, времени вообще не трачу. Взлетит – хорошо, уже в курсе что это, не взлетит – так C++17 очень прикольно выглядит

Но в случае с Немерле наблюдается что-то странное, даже более жесткое чем движения вокруг D.

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

BC>>http://judy.sourceforge.net/doc/shop_interm.pdf
_>Посмотрел. Показалось что там нет ничего относящегося к теме которую мы тут сейчас обсуждаем.

Относится к теме напрямую.
Выше тип проекта который можно написать только на Си.
На Шарпе или Немерле его писать или невозможно или не имеет смысла.
А вот как найти тип проекта, который имеет смысл писать только на Немерле и невозможно написать на Шарп и Си — вот в этом вопрос

Если Вы сможете найти такие типы проектов — то легко получите свою долю рынка

Кстате, ребятки, Бубен о Немерле.
Упоминают про Немерле мало, но кое-что есть.

Геймдев
http://booben.com/?q=gamedev.ru:%D0%BD%D0%B5%D0%BC%D0%B5%D1%80%D0%BB%D0%B5

Доу
http://booben.com/?q=dou.ua:%D0%BD%D0%B5%D0%BC%D0%B5%D1%80%D0%BB%D0%B5

Скуль
http://booben.com/?q=sql.ru:%D0%BD%D0%B5%D0%BC%D0%B5%D1%80%D0%BB%D0%B5

Отдельно о тренде популярности Немерле:
http://booben.com/Stat?q=s=sql.ru:%D0%BD%D0%B5%D0%BC%D0%B5%D1%80%D0%BB%D0%B5

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

BC>А вот как найти тип проекта, который имеет смысл писать только на Немерле и невозможно написать на Шарп и Си — вот в этом вопрос

Это такой же глупый вопрос, как найти дорогу, где жигули проедет, а запорожец — нет. ОБЕ машины могут преодолеть любые дороги, но на одной из них это можно сделать гораздо быстрее и комфортнее. Зачем тогда гемороить жизнь?
Кроме того, разработка — это не просто студенческое "написал-забыл" — ещё есть СОПРОВОЖДЕНИЕ. И чем проще и высокоуровневее программа, тем легче потом в неё вникать. Немерля/Нитра тем и хороши, что выводят программинг на новый уровень: от тупого кодирования на ЯОН к миру выразительных DSL!

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

I>>Так много, что вакансий около нуля.

N>Acь?
N>http://www.glassdoor.com/Job/clojure-jobs-SRCH_KO0,7.htm

Мне на любой язык показывает до одной вакансии. Это такой аргумент был ?

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

B>Это такой же глупый вопрос, как найти дорогу, где жигули проедет, а запорожец — нет. ОБЕ машины могут преодолеть любые дороги, но на одной из них это можно сделать гораздо быстрее и комфортнее. Зачем тогда гемороить жизнь?

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

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

KP>Ты это про 2,5 энтузиастов + авторов компилятора?

А ты ведешь учет пользователей?

KP>Люди пользуются Scala, Clojure и это понятно почему и дальше будет так же. Но вот в случае с Немерле народу не прибавится.

Ты это про 2.5 пользователя? Я вот ни одного человека не знаю кто писал бы на Клозьре. Ну, и Клозюр — это язык с 50-летней историей, а не новояз.

Из тех кто пишет на скале я знаю ровно одного человека. Как-то не густо для популярного языка.

Вот явщиков и шарпщиков хоть отбавляй.

Так что не выдумывай.

KP>А причем тут Раст? Я на него, по сравнению с твоими затратами ресурсов на Немерле, времени вообще не трачу. Взлетит – хорошо, уже в курсе что это, не взлетит – так C++17 очень прикольно выглядит

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

KP>Но в случае с Немерле наблюдается что-то странное, даже более жесткое чем движения вокруг D.

Со всеми языками наблюдается одно и то же. Без пиара и бабла они продвигаются очень тяжело. Просто лучшего языка явно не достаточно.

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

VD>Со всеми языками наблюдается одно и то же. Без пиара и бабла они продвигаются очень тяжело. Просто лучшего языка явно не достаточно.

Пять лет на РСДН в отдельном разделе это не пиар ?

ИМХО пиар нужен когда люди не знают о проекте, маленькая аудитория.
На сегодня о Немерле знают, наверное, несколько сотен тысяч человек.
Если люди приходят, пробуют, смотрят и уходят то пиар не поможет.

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

I>>>Так много, что вакансий около нуля.

N>>Acь?
N>>http://www.glassdoor.com/Job/clojure-jobs-SRCH_KO0,7.htm

I>Мне на любой язык показывает до одной вакансии. Это такой аргумент был ?

В смысле "до одной"? Мой линк показывает сотни.

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

VD>Ты это про 2.5 пользователя? Я вот ни одного человека не знаю кто писал бы на Клозьре. Ну, и Клозюр — это язык с 50-летней историей, а не новояз.
VD>Из тех кто пишет на скале я знаю ровно одного человека. Как-то не густо для популярного языка.

Поиск на glassdoor:
a) 35879 python jobs
b) 24755 scala jobs
c) 209 clojure jobs
d) Your search Jobs for nemerle did not match any jobs.

Как мы видим Скала практически в одной категории с признанным тобой "популярным" Питоном.

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

BC>Кстате, ребятки, Бубен о Немерле.
BC>Упоминают про Немерле мало, но кое-что есть.

BC>Геймдев
BC>http://booben.com/?q=gamedev.ru:%D0%BD%D0%B5%D0%BC%D0%B5%D1%80%D0%BB%D0%B5

An item with the same key has already been added.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

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

BC>>Кстате, ребятки, Бубен о Немерле.
BC>>Упоминают про Немерле мало, но кое-что есть.

BC>>Геймдев
BC>>http://booben.com/?q=gamedev.ru:%D0%BD%D0%B5%D0%BC%D0%B5%D1%80%D0%BB%D0%B5

DS>

DS>An item with the same key has already been added.

DS>

Вроде починил.
Там глюк с синхронизацией на многопоточном сервере был.

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

BC>Вроде починил.
BC>Там глюк с синхронизацией на многопоточном сервере был.

Так. Пора переходить на Немерль.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

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

BC>>Вроде починил.
BC>>Там глюк с синхронизацией на многопоточном сервере был.

DS>Так. Пора переходить на Немерль.

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

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

N>b) 24755 scala jobs

Попробовал. Почему-то на "scala" мне выдали "27 scala jobs". Причем по делу из них ровно одно.

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

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

Люди не хотят вникать. Среди тех кто вник процент тех кто не оценил минимален.

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

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

BC>>>http://judy.sourceforge.net/doc/shop_interm.pdf
_>>Посмотрел. Показалось что там нет ничего относящегося к теме которую мы тут сейчас обсуждаем.

BC>Относится к теме напрямую.
BC>Выше тип проекта который можно написать только на Си.

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

Что не позволит написать какую-то там структуру данных на Немерле или Шарпе?

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

VD>Попробовал. Почему-то на "scala" мне выдали "27 scala jobs". Причем по делу из них ровно одно.
Похоже, glassdoor определяет страну и показывает результаты только для неё.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

VD>Что не позволит написать какую-то там структуру данных на Немерле или Шарпе?

Отсудствие работы напрямую с памятью, например.
Вообще переписать можно конечно на что угодно, ну там пару костылей и готово.
Другой вопрос, кому нужна будет структура данных, которая работает в раз 20 медленей чем на Си.

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

BC>Отсудствие работы напрямую с памятью, например.

Во-первых, она есть как в Шарпе, так и в Немерле. В Шарпе есть указатели в ансэйф режиме. В Немерле просто доступны все возможности дотнета. Пишеш себе необходимый макрос и все ОК.
Во-вторых, в есть возможность делать все что нужно и без нее.

Ты сначала разобрался в вопросе, а то глупо выглядишь.

BC>Вообще переписать можно конечно на что угодно, ну там пару костылей и готово.

Вообще-то можно и без костылей.

BC>Другой вопрос, кому нужна будет структура данных, которая работает в раз 20 медленей чем на Си.

Это ты по не компетентности говоришь. Никаких 20 раз там нет. Та же Найтра использует очень низкоуровневые структуры данных пакуемые в два массива интов. Производительности хватает. Алгоритмы играют куда большую роль. Самый оптимально написанный GLR/GLL-парсер написанный на C сольет по скорости Найтре в разы.

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

BC>>Другой вопрос, кому нужна будет структура данных, которая работает в раз 20 медленей чем на Си.

VD>Это ты по не компетентности говоришь. Никаких 20 раз там нет. Та же Найтра использует очень низкоуровневые структуры данных пакуемые в два массива интов. Производительности хватает. Алгоритмы играют куда большую роль. Самый оптимально написанный GLR/GLL-парсер написанный на C сольет по скорости Найтре в разы.

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

А пока что, любые низкоуровневые структуры данных, как то хештаблицы, или деревья, пишутся на низкоуровневых языках типо Си.
Внутри там постраничное выделение памяти и ацки сложный код с многими низкоуровневыми финтами которых в шарп (и тем более в немерле)
нет и не будет. У меня проект разделен на две части. На Си и на Шарпе и я прекрасно понимаю и сравниваю разницу между ними.
Потому Шарп — прототип, Си — реализация.

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

VD>Это ты по не компетентности говоришь. Никаких 20 раз там нет. Та же Найтра использует очень низкоуровневые структуры данных пакуемые в два массива интов. Производительности хватает. Алгоритмы играют куда большую роль. Самый оптимально написанный GLR/GLL-парсер написанный на C сольет по скорости Найтре в разы.

Угу, алгоритмы всё решают. В том числе и алгоритмы работы оптимизатора в компиляторе.

И в этом смысле дотнетовское чудо стоит на несколько ступеней развития ниже, чем gcc или icc.

Хотя 20 раз — это конечно же тоже преувеличение. )))

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

VD>>Попробовал. Почему-то на "scala" мне выдали "27 scala jobs". Причем по делу из них ровно одно.
WH>Похоже, glassdoor определяет страну и показывает результаты только для неё.

Угу, но это можно поменять — второе поле в запросе.

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

I>Мне на любой язык показывает до одной вакансии. Это такой аргумент был ?

Там второе поле в фильтр страна, по умолчанию (пусто) выбирается твоя. Смени не империю добра.

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

_>Хотя 20 раз — это конечно же тоже преувеличение. )))

Ничего не преувеличение.
В Си можно делать вот например такие финты:

void* pBuff = getBuff();
Packet* pPacket = (Packet*)pBuff;

if(pPacket->Type==2)
{
PacketV2* pPacketV2 = (PacketV2*)pBuff;
...
}

Преобразование буфера в пару машинных комманд сначала в один тип, потом в другой.
Как такое в Шарпе можно сделать без костылей и маршалинга — даже не предсталяю.
А фича очень удобная в низкоуровневом программирование.

using System;
using System.Runtime.InteropServices;

namespace ConsoleApplication2
{
    [StructLayout(LayoutKind.Sequential, Pack = 4)]
    struct A
    {
        public int a;
        public int b;
    }

    [StructLayout(LayoutKind.Sequential, Pack = 8)]
    struct B
    {
        public long x;
    }

    class Program
    {
        static unsafe void Main(string[] args)
        {
            A* q = (A*)Marshal.AllocHGlobal(100);
            ((B*) q)->x = 10;

            Console.Write(q->a);
        }
    }
}

BC>А фича очень удобная в низкоуровневом программирование.

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

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

BC>>Преобразование буфера в пару машинных комманд сначала в один тип, потом в другой.
BC>>Как такое в Шарпе можно сделать без костылей и маршалинга — даже не предсталяю.
_NN>Вы серьезно ?
_NN>Откройте unsafe
_NN>

_NN>using System;
_NN>using System.Runtime.InteropServices;

_NN>namespace ConsoleApplication2
_NN>{
_NN>    [StructLayout(LayoutKind.Sequential, Pack = 4)]
_NN>    struct A
_NN>    {
_NN>        public int a;
_NN>        public int b;
_NN>    }

_NN>    [StructLayout(LayoutKind.Sequential, Pack = 8)]
_NN>    struct B
_NN>    {
_NN>        public long x;
_NN>    }

_NN>    class Program
_NN>    {
_NN>        static unsafe void Main(string[] args)
_NN>        {
_NN>            A* q = (A*)Marshal.AllocHGlobal(100);
_NN>            ((B*) q)->x = 10;

_NN>            Console.Write(q->a);
_NN>        }
_NN>    }
_NN>}

_NN>

BC>>А фича очень удобная в низкоуровневом программирование.

Во-первых, если мы включаем Унсейф, то можно говорить что это уже не совсем шарп. А такая себе вставка Сишных команд.
Во-вторых, ключевой момент — в пару машинных комманд. Вызов функции Marshal.AllocHGlobal это уже пару сотен машинных комманд с длинными джампами.

Так что код выше может работать и в 20, а может даже в 100 раз медленей чем на Си.

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

BC>Во-первых, если мы включаем Унсейф, то можно говорить что это уже не совсем шарп. А такая себе вставка Сишных команд.
Да ну ? Это все в спецификации C#.

С таким же успехом я могу сказать , что если в С пишем __asm , это совсем не С, а такая себе вставка ассемблерных комманд.
А если еще __emit(machine code) то вообще.

BC>Во-вторых, ключевой момент — в пару машинных комманд. Вызов функции Marshal.AllocHGlobal это уже пару сотен машинных комманд с длинными джампами.
BC>Так что код выше может работать и в 20, а может даже в 100 раз медленей чем на Си.
Хотите стек? Есть stackalloc , проблема то.

Точно также я и про malloc против стека могу сказать.

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

_NN>С таким же успехом я могу сказать , что если в С пишем __asm , это совсем не С, а такая себе вставка ассемблерных комманд.

Если ты в код Си вставляешь ассемблерную вставку то да, это не Си, это кусок ассемблера.
Разве это не очевидно ?

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

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

_NN>>С таким же успехом я могу сказать , что если в С пишем __asm , это совсем не С, а такая себе вставка ассемблерных комманд.

BC>Если ты в код Си вставляешь ассемблерную вставку то да, это не Си, это кусок ассемблера.
BC>Разве это не очевидно ?

Однако от этого программа не перестает быть написанной на C .
Я так понимаю недовольство в том, что в С# можно работать напрямую с памятью

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

А>>А я хотел почитать про немерле, а вики уже полгода не работает http://nemerle.org/wiki/index.php?title=Main_Page
STD>https://github.com/rsdn/nemerle/wiki вики здесь

Может тогда исправить ссылку в nemerle.org/About, которая ведёт на wiki?

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

BC>Преобразование буфера в пару машинных комманд сначала в один тип, потом в другой.
BC>Как такое в Шарпе можно сделать без костылей и маршалинга — даже не предсталяю.

Так иди и займись своим образованием, а не неси пургу по форумам демонстрируя свое невежество.
Открой для себя безопасные приведения типов, классы, вариантные типы, ансэйф (в конце, концов).

BC>А фича очень удобная в низкоуровневом программирование.

Фича нужная очень редко и чреватая серьезными багами.

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

BC>Я эти сказки уже давно слышу. Но при попытках сравнить парсеры или скорости работы, сразу банят.

Банят тебя потому что ты правила форума не уважаешь. Вот здесь развел офтопик, например.

Я не хочу трать время на невежд и недоучек. Иди в КСВ, создавай там тему и получай удовольствие от того, что над тобой будут смеяться. А здесь все это разводить не надо. Будешь продолжать — за баню.

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

EP>Может тогда исправить ссылку в nemerle.org/About, которая ведёт на wiki?

По хорошему нужно восстановить старую вики или перенести ее контент на новый сервер, так как, иначе, много информации оказывается потерянной.

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

EP>>Может тогда исправить ссылку в nemerle.org/About, которая ведёт на wiki?
VD>По хорошему нужно восстановить старую вики или перенести ее контент на новый сервер, так как, иначе, много информации оказывается потерянной.

На эту wiki много внешних ссылок (видел на rsdn, stackoverflow, dlang.org. подозреваю что таких мест очень много) — они все сейчас "битые". Это может отбить всякое желание к изучению (типа "а оно ещё живое?"), или как минимум оставить осадочек ("да там даже wiki не работает").

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

EP>На эту wiki много внешних ссылок (видел на rsdn, stackoverflow, dlang.org. подозреваю что таких мест очень много) — они все сейчас "битые". Это может отбить всякое желание к изучению (типа "а оно ещё живое?"), или как минимум оставить осадочек ("да там даже wiki не работает").

Согласен. Не хорошо. Постараюсь толкнуть этот вопрос в понедельник.

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

BC>Ничего не преувеличение.
BC>В Си можно делать вот например такие финты:
BC>...
BC>Преобразование буфера в пару машинных комманд сначала в один тип, потом в другой.
BC>Как такое в Шарпе можно сделать без костылей и маршалинга — даже не предсталяю.
BC>А фича очень удобная в низкоуровневом программирование.

Какие ещё пара машинных команд для преобразования типа? Для процессора не существует никаких типов, так что подобное "преобразование" занимает ровно 0 команд. Причём на любом языке, дающем прямой доступ к памяти. В том числе и на C# в unsafe режиме.

Если говорить о преимуществах по быстродействию над .net'ом языков типа C, то очевидно надо рассматривать нормальную работу с данными на стеке, оптимизацию работы с памятью и вообще оптимизацию кода (полноценный инлайн, развертки и т.п.). По последним параметрам .net очень далеко отстаёт от современных компиляторов C/C++. Ну и если взять C++, то ещё дополнительно добавится МП времени компиляции, которое позволяет делать вообще не представимые в мире C# вещи. В итоге это всё сводится к существенному преимуществу в быстродействие. Бывает до 3-4 раз. Но никак не 20. Собственно большинство современных компилируемых языков укладываются в рамки отставания где-нибудь раз в 5... А 20 — такие цифры возможны только при сравнение с C/C++ скриптовых языков и то далеко не всех.

А вообще, выдвигая абсолютно правильный тезис об ущербности платформы .net в плане производительности (естественно в сравнение с C/C++), но при это аргументируя его такими странными цифрами и такими странными примерами, ты по сути дискредитируешь сам этот тезис...

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

_> Бывает до 3-4 раз.

Очень точное замечание. Бывает 3-4, а бывает и -2. В среднем немногим медленее, так как большая часть кода укладывается в тупой вызов методов по указателям. Дотнет не стоял на месте последние годы и кое-какие оптимизации сделали.

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

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

_>А вообще, выдвигая абсолютно правильный тезис об ущербности платформы .net в плане производительности (естественно в сравнение с C/C++), но при это аргументируя его такими странными цифрами и такими странными примерами, ты по сути дискредитируешь сам этот тезис...

В целом готов согласиться, только твоя оценка тоже приукрашена. 3-5 раз — это в худшем случае. Возможно, есть совсем клинические случаи, где можно и больше отставание получить. У плюсов и сей действительно есть некоторые преимущества в области оптимизации, но чем за это приходится платить? Надежность, временем необходимым на доведение кода до качественного состояния, сложностью в дизайне и т.п. В среднем же, если не заниматься вылизыванием каждой строчки кода, то оставание дотнета не превысит и двух раз. Реальный средний гандикап измеряется процентами. Ну, а там где нужно вылизать есть ансэйф и даже С/С++. Но код на них, лично я, предпочитаю не писать вручную, а генерировать по модели. А модель и генератор кода куда удобнее делать на Немерле.

Кстати, в нашем текущем проекте производительность очень критична. Возможно кода-то мы прибегнем к генерации сишного кода, или даже к генерации машинных кодов (так как там гибкость еще больше выходит, а что генерировать особой рояли не имеет. Но, как всегда бывает, есть куча куда более важных задач. Так что когда мы этим займемся, и займемся ли вообще, неизвестно. В конце концов инкрементальный парсинг даст куда более стабильное и существенное ускорение при редактировании файлов, нежели оптимизации которые может выжать хороший компилятор С++.

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

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

VD>Очень точное замечание. Бывает 3-4, а бывает и -2. В среднем немногим медленее, так как большая часть кода укладывается в тупой вызов методов по указателям. Дотнет не стоял на месте последние годы и кое-какие оптимизации сделали.

Вообще то даже если бы и просто в 2 раза, то это тоже более чем серьёзно для многих задач, но на самом деле картина совсем другая. Я делал разные тесты... C# и Java дают существенное стабильное отставание. А вот unsafe C# даёт совсем другие цифры, которые достаточно близки к цифрам C++ (т.е. на самом деле отставание совсем небольшое, заметно меньше даже коэффициента 2).

Кстати, а в Nemerle unsafe работает?

VD>Остается основной гандикап — различные безопасные точки и барьеры записи которые снижают быстродействие на несколько процентов и которые никогда не получится устранить. С другой стороны выделение памяти в хипе тоже в разы быстрее. В итоге преимущество становится иллюзорным и слихвой покрывается существенно больше безопасностью кода и простотой программирования.

А вот насчёт выделения памяти — это точно миф. Причём довольно известный и старый. Он был придуман ещё любителями Java, когда они типа нашли один специфический пример, на котором Java код опережает C/C++. На самом деле фокус конечно же заключается в оригинальном написание C/C++ примера, которое ни один профессионал в нём не сделает. Сейчас поясню в деталях. В большинстве случаев в реальных задачах мы встречаем или выделение отдельных небольших объектов (в C++ принято для этого использовать стек — обычно на голову быстрее всех остальных) или же сразу больших блоков/массивов (тут у большинства нормальных языков будут одинаковые цифры). Однако есть ещё один довольно специфический случай — выделение (и главное удаление!) большого числа отдельных мелких объектов. Если решить эту задачу с помощью банального new/delete, то она действительно будет несколько отставать от реализации на Java/C#. Только вот фокус в том, что никто в своём уме не будет писать подобный код на C++, а применит для этой задачи аллокатор на пуле (который опять же окажется на голову быстрее варианта на Java/C#). Да, для тех, кто не особо в курсе C++ и подумал сейчас о каких-то проблем с нестандартным выделением памяти, написанием велосипедов и т.п., напомню, что все стандартные библиотеки C++ поддерживают указание пользовательского аллокатора. Ну и готовая эффективная реализация такого алллокатора на пуле тоже уже давно имеется в стандартных библиотеках. В общем в итоге, стандартные средства C/C++ заметно эффективнее на большинстве задач. А для одной специфической задачи, где это не так, тоже имеется готовое решение (которое опять же заметно эффективнее). Но некоторые "умные" товарищи проводят тестирование понятно как и соответственно получаем данный известный миф.

VD>Что до МП времени компиляции, то тут Немерл рвет С++, как Тузик грелку. Так что это преимущество тоже стоит забыть.

Это безусловно так, но мы же сравниваем один мейнстрим язык (C++) с другим мейнстрим языком (C#) и здесь у C# вообще нечего предъявить для сравнения. А если сравнивать уже не мейнстрим, то сразу же вспоминается D, у которого тоже весьма не плохое МП и при этом быстродействие на уровне unsafe C#.

Но на самом деле и C++ понемногу продвигается вперёд. Как тебе например такой http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc примерчик?)

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

Нет, это всё касается языка C. А современный C++ совсем другой. Он позволяет писать код с такой же скоростью и удобством, как и C# и при этом даже более надёжный (за счёт стремления к проверкам времени компиляции, а не времени исполнения). Но и конечно же цена за всё это тоже есть, только у современного C++ она заключена совсем в ином. Его проблема в том, что для решения одной и той же задачи требуется программист на C# одного уровня (допустим невысокого) и программист на C++ совсем другого уровня (заметно выше). Ну а в современном мире гораздо чаще оказывается дешевле купить железо помощнее, чем найти высокоуровнего специалиста.

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

Генерация — это уже совсем другое дело. И я пока не встречал инструмента с эффективной реализаций подобного. Т.е. просто какие-то генераторы периодически встречаются (ну скажем какие-нибудь там доступы к БД по xml схемам и т.п.), а вот чтобы с упором на быстродействие...

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

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

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

Нууу это кому как. Я тебе ещё несколько лет назад говорил, что в принципе Nemerle может быть интересен нам, но только при условие наличия полноценной нативной реализации — .net нам не походит вообще никак по целому ряду причин. Ты тогда ещё сказал что в принципе Nemerle не завязан на .net, так что в недалёком будущем такое возможно. Однако насколько я понимаю, за все эти годы подобное будущее ещё даже не начало приближаться?

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

VD>Я не хочу трать время на невежд и недоучек.

Ну людям свойственно свои недостатки клеить другим.
Вообщем я с хамами не общаюсь. Удачи в сизифов труде

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

_>А 20 — такие цифры возможны только при сравнение с C/C++ скриптовых языков и то далеко не всех.

Я не говорил "в среднем в 20 раз", я говорил есть задачи на которых Си будет быстрее Шарпа "в 20+ раз".
И как пример привел пример с приведением типов. Если не прикручивать ансейф костыль, то как раз в 20+ присест и получим.

ARK>>Просто высказал свое мнение.
VD>А кому здесь нужно мнение человека не знающего предмета обсуждения?
VD>Как бы, люди говорящее — "не нужен" ненужны.

Да ты просто бог маркетинга

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

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

_>>А 20 — такие цифры возможны только при сравнение с C/C++ скриптовых языков и то далеко не всех.

BC>Я не говорил "в среднем в 20 раз", я говорил есть задачи на которых Си будет быстрее Шарпа "в 20+ раз".
BC>И как пример привел пример с приведением типов. Если не прикручивать ансейф костыль, то как раз в 20+ присест и получим.
Да, будет быстрее, но какой ценной ?
Ценной возможных трудноуловимых ошибок !

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

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

BC>Вообщем я с хамами не общаюсь. Удачи в сизифов труде

Вот и продолжай это делать.

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

VD>С другой стороны выделение памяти в хипе тоже в разы быстрее.

В вопросах производительности не имеет особого смысла рассматривать выделение памяти отдельно от освобождения.
Но да, есть случаи, как уже выше сказал alex_public, где стандартный аллокатор управляемых языков будет быстрее стандартных new/delete C++

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

VD>У плюсов и сей действительно есть некоторые преимущества в области оптимизации, но чем за это приходится платить? Надежность, временем необходимым на доведение кода до качественного состояния, сложностью в дизайне и т.п. В среднем же, если не заниматься вылизыванием каждой строчки кода, то оставание дотнета не превысит и двух раз. Реальный средний гандикап измеряется процентами. Ну, а там где нужно вылизать есть ансэйф и даже С/С++.

Вот только нужно не забывать, что C++ это не только преимущества в скорости, но ещё и в гибкости.
На C# — шаг влево, шаг вправо и упираешься в забор, в результате код получается более многословный.
Обобщённый код (это даже не метапрограммирование) на C++ получается разы короче и проще.

Вот например, на Python можно сделать так (будет работать для любых типов имеющих соответствующие операторы):

def add(x, y):
    return x + y

def sub(x, y):
    return x - y

def apply(f, *args):
    return f(*args)

print(apply(apply, apply, apply, add, 1, 2))
print(apply(apply, apply, sub, 11, 2))

Аналог на C++:

auto add = [](auto x, auto y)
{
    return x + y;
};
auto sub = [](auto x, auto y)
{
    return x - y;
};
auto apply = [](auto f, auto... args)
{
    return f(args...);
};

print(apply(apply, apply, apply, add, 1, 2));
print(apply(apply, apply, sub, 11, 2));

На C# будет облом.
И, что-то мне подсказывает, если это и получится на Nemerle, то не так складно, ибо система типов .NET — примитивней

Ожидаю блаб-объяснений что это и не нужно, потому что можно без этого

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

BC>>Я не говорил "в среднем в 20 раз", я говорил есть задачи на которых Си будет быстрее Шарпа "в 20+ раз".
BC>>И как пример привел пример с приведением типов. Если не прикручивать ансейф костыль, то как раз в 20+ присест и получим.
_NN>Да, будет быстрее, но какой ценной ?
_NN>Ценной возможных трудноуловимых ошибок !

Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается.

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

_>Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается.
К сожалению, чтобы этого добиться в С++ нужно гораздо больше понимать чем в C#.
И научить людей всем нюансам гораздо сложнее, ведь многое в понимании приходит только с опытом.

Например я нигде не видел у нас в коде использование vector::at для проверок границ.
А вот ошибка потенциально имеет место быть если не будет ревью или обработки статического/динамического анализатора.

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

_>>Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается.
_NN>К сожалению, чтобы этого добиться в С++ нужно гораздо больше понимать чем в C#.
_NN>И научить людей всем нюансам гораздо сложнее, ведь многое в понимании приходит только с опытом.

Согласен, это один из основных недостатков C++ в данный момент) Ну так полного идеала нет нигде. ) Лично для нас этот недостаток не особо напрягающий. А скажем для большинства не IT компаний думаю это весьма существенно...

Для нас более критично отсутствие интроспекции (времени компиляции) и работы со строками в шаблонах. Надеюсь когда-нибудь поправят — тогда для нас будет совсем позитивно.

Хотя кто его знает, какое направление развитие будет в дальнейшем. К примеру мы особо не ждали полиморфные лямбды, но когда увидели их, то изменили своё мнение — крайне мощный инструмент. Настолько мощный, что варианты его использования ещё не целиком проглядываются (потому и не особо ждали наверное)...

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

_>Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается.

Ты тут рядом типа мифы развенчивал, а тут сам мифы придумываешь.

ЗЫ

Как бы мы с Вольфхаундом старые С/С++-ники. И с радостью выкинули эти языки на свалку истории. Догадайся почему?

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

_>>Всё правильно. Если сравнивать C# и C. А вот при сравнение C# и C++ уже ничего подобного не наблюдается.
VD>Ты тут рядом типа мифы развенчивал, а тут сам мифы придумываешь.

Можешь продемонстрировать большую надёжность C# кода по сравнению с C++ (а не C!) кодом? )

VD>Как бы мы с Вольфхаундом старые С/С++-ники. И с радостью выкинули эти языки на свалку истории. Догадайся почему?

Пока не особо представляю. Потому как сам пока что не могу выкинуть C++ даже в варианте перехода C++ -> D...

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

_>Можешь продемонстрировать большую надёжность C# кода по сравнению с C++ (а не C!) кодом? )

Что там демонстрировать? Язык с ручным управлением памятью и легко доступными небезопасными приведениями типов, отсутствием контроля границ массивов и адресной арифметикой надежным не может быть по определению. Программирование на нем сравни хождению по минному полю. Если ты большой профессионал, то тебе удастся пройти между заботливо разложенными ~~граблями~~минами. Но если ты оступился, то может оторвать важные части тела.

Обвешивание разными смартпоинтерами и прочими приблудами упрощающими жизнь стремительно приводит производительность к тому что ты мог бы получить на Шарпе без малейшего напряжения.

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

_>>Можешь продемонстрировать большую надёжность C# кода по сравнению с C++ (а не C!) кодом? )
VD>Что там демонстрировать? Язык с ручным управлением памятью и легко доступными небезопасными приведениями типов и адресной арифметикой надежным не может быть по определению. Программирование на нем сравни хождению по минному полю. Если ты большой профессионал, то тебе удастся пройти между заботливо разложенными ~~граблями~~минами. Но если ты оступился, то может оторвать важные части тела.

Эээ, я же вроде бы чётко указал, что у нас речь идёт о C++, а не о C.

VD>Обвешивание разными смартпоинтерами и прочими приблудами упрощающими жизнь стремительно приводит производительность к тому что ты мог бы получить на Шарпе без малейшего напряжения.

Ха, человек хорошо знающий C++ никогда такого не напишет. Там же краеугольный камень всей идеологии языка в нулевом оверхеде всех абстракций и он соблюдается неукоснительно.

А вообще, я смотрю что ты игнорируешь множество интересных (но видимо неудобных тебе?) вопросов в данной темке, хотя при этом комментируешь всякие мелкие оффтопики... Ну и какой смысл тогда нормально общаться? )

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

_>А вообще, я смотрю что ты игнорируешь множество интересных (но видимо неудобных тебе?) вопросов в данной темке, хотя при этом комментируешь всякие мелкие оффтопики... Ну и какой смысл тогда нормально общаться? )

У меня времен нет развернуто отвечать. Будет время отвечу.

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

VD>ЗЫ
VD>Как бы мы с Вольфхаундом старые С/С++-ники. И с радостью выкинули эти языки на свалку истории. Догадайся почему?

Извини, конечно, но в том-то и дело, что вы слишком старые С++ники. Современным С++никам нет нужды знать WinAPI и все нюансы реализации COM, им нужны другие знания и умения. Даже в MSDN заглядывать практически никогда не приходится.

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

VD>>Что там демонстрировать? Язык с ручным управлением памятью и легко доступными небезопасными приведениями типов и адресной арифметикой надежным не может быть по определению. Программирование на нем сравни хождению по минному полю. Если ты большой профессионал, то тебе удастся пройти между заботливо разложенными ~~граблями~~минами. Но если ты оступился, то может оторвать важные части тела.
_>Эээ, я же вроде бы чётко указал, что у нас речь идёт о C++, а не о C.
Что из этого не относится к С++?

_>Ха, человек хорошо знающий C++ никогда такого не напишет. Там же краеугольный камень всей идеологии языка в нулевом оверхеде всех абстракций и он соблюдается неукоснительно.
Расскажи ка мне про производительность InterlockedIncrement/InterlockedDecrement которые необходимы для подсчёта ссылок в многопоточной программе.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

_>>Ха, человек хорошо знающий C++ никогда такого не напишет. Там же краеугольный камень всей идеологии языка в нулевом оверхеде всех абстракций и он соблюдается неукоснительно.
WH>Расскажи ка мне про производительность InterlockedIncrement/InterlockedDecrement которые необходимы для подсчёта ссылок в многопоточной программе.

Структуру данных JudyArray в пару тысяч строк писало целое подразделение отличных алгоритмистов из IBM несколько лет.
Смешно читать при таких проектах не только про "ошибки в коде на Си", но даже про дебаг.
Высокопроизводительный код, пишется годами и вылизывается до блеска без какого либо оверхеда.
И самое интересное — что альтернативы коду на Си просто нет, если речь идет о производительности

Шарп да Джава точились на 80% для ынтырпрайза. Это когда в одном опенспейсе сажают с два десятка хомячков которые усиленно скриптуют какую-нибудь склад-бухгалтерию.

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

WH>Расскажи ка мне про производительность InterlockedIncrement/InterlockedDecrement которые необходимы для подсчёта ссылок в многопоточной программе.

1. Для ref-counted smart pointers лишние передёргивания ссылок требуются только когда время жизни объекта реально "раздваивается", в большинстве же случаев достаточно move. Эти редкие атомарные ++ -- конечно же прям наисерьезнейшая проблема по сравнению с stop-the-world и прочими GC радостями.
2. Это всего лишь один из вариантов smart-pointer'ов. Есть другие — например есть ref-counted без синхронизации, а есть и вовсе без всяких counter'ов.
3. Значимость smart pointers сильно преувеличенна теми, кто полагает что для каждого new в управляемых языках, единственная альтернатива на C++ это smart pointer. На практике же, для большинства случаев достаточно scoped-based lifetime.

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

VD>>>Что там демонстрировать? Язык с ручным управлением памятью и легко доступными небезопасными приведениями типов и адресной арифметикой надежным не может быть по определению. Программирование на нем сравни хождению по минному полю. Если ты большой профессионал, то тебе удастся пройти между заботливо разложенными ~~граблями~~минами. Но если ты оступился, то может оторвать важные части тела.
_>>Эээ, я же вроде бы чётко указал, что у нас речь идёт о C++, а не о C.
WH>Что из этого не относится к С++?

Собственно ничего. Ну или с другой стороны всё, но в таком случае оно и к C# относится (у нас же там имеется unsafe, не так ли?).

_>>Ха, человек хорошо знающий C++ никогда такого не напишет. Там же краеугольный камень всей идеологии языка в нулевом оверхеде всех абстракций и он соблюдается неукоснительно.
WH>Расскажи ка мне про производительность InterlockedIncrement/InterlockedDecrement которые необходимы для подсчёта ссылок в многопоточной программе.

Для начала тогда уж std::atomic, а не эта хрень из win api. Ну а потом собственно причём тут это? Мы говори о нулевом оверхеде неких абстракций. А здесь у нас совсем не абстракция, а прямая функциональность — синхронизация. Так что само понятие оверхед тут не применимо, т.к. ресурсы тратятся не на реализацию абстракции, а на "дело". Ну или ты хочешь сказать, что можешь привести случаи, когда в C++ синхронизация нужна, а в том же случае в C# не нужна? )

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

EP>1. Для ref-counted smart pointers лишние передёргивания ссылок требуются только когда время жизни объекта реально "раздваивается", в большинстве же случаев достаточно move.
Вот только компилятор не в состоянии определить большинство таких ситуаций.
Так что тебе придется писать что-то типа ptr1.moveFrom(ptr2). И не дай байт написать это лишний раз.

EP>Эти редкие атомарные ++ -- конечно же прям наисерьезнейшая проблема по сравнению с stop-the-world и прочими GC радостями.
http://www.azulsystems.com/technology/c4-garbage-collector

EP>2. Это всего лишь один из вариантов smart-pointer'ов. Есть другие — например есть ref-counted без синхронизации, а есть и вовсе без всяких counter'ов.
И если он не дай байт залетит в другой поток, случится феерверк.

EP>3. Значимость smart pointers сильно преувеличенна теми, кто полагает что для каждого new в управляемых языках, единственная альтернатива на C++ это smart pointer. На практике же, для большинства случаев достаточно scoped-based lifetime.
Ну, это ты сильно погорячился.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

_>Собственно ничего. Ну или с другой стороны всё, но в таком случае оно и к C# относится (у нас же там имеется unsafe, не так ли?).
Его отдельно включать надо.

_>Для начала тогда уж std::atomic, а не эта хрень из win api.
Не важно. Уверен, что std::atomic на винде через эту хрень и работает.
Ну, или эту хрень туда тупо скопипастили.

_>Ну а потом собственно причём тут это? Мы говори о нулевом оверхеде неких абстракций. А здесь у нас совсем не абстракция, а прямая функциональность — синхронизация. Так что само понятие оверхед тут не применимо, т.к. ресурсы тратятся не на реализацию абстракции, а на "дело". Ну или ты хочешь сказать, что можешь привести случаи, когда в C++ синхронизация нужна, а в том же случае в C# не нужна? )

class Foo
{
  Baz baz;
  void Bar()
  {
    var localBaz = new Baz();//раз
    baz = localBaz;//два
    //три
  }
  //удаление Foo четыре
}

В C# не нужно ни разу.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

EP>>1. Для ref-counted smart pointers лишние передёргивания ссылок требуются только когда время жизни объекта реально "раздваивается", в большинстве же случаев достаточно move.
WH>Вот только компилятор не в состоянии определить большинство таких ситуаций.
Ссылку на "большинство" не затруднит привести? Компилятор как раз отлично знает, где у него что, гуглить rvalue references.

WH>Так что тебе придется писать что-то типа ptr1.moveFrom(ptr2). И не дай байт написать это лишний раз.
Крайне редко это придется писать, уж поверь. Судя по тому, что ты пишешь moveFrom() вместо std::move и rvalue references, о С++11 ты имеешь довольно смутное представление.

EP>>2. Это всего лишь один из вариантов smart-pointer'ов. Есть другие — например есть ref-counted без синхронизации, а есть и вовсе без всяких counter'ов.
WH>И если он не дай байт залетит в другой поток, случится феерверк.
А если единорог придет, то вообще труба.

EP>>3. Значимость smart pointers сильно преувеличенна теми, кто полагает что для каждого new в управляемых языках, единственная альтернатива на C++ это smart pointer. На практике же, для большинства случаев достаточно scoped-based lifetime.
WH>Ну, это ты сильно погорячился.

То есть в твоих программах на С++ сплошные сплошные динамические полиморфные объекты с неопределенным временем жизни? Ну тогда конечно.

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

EP>>1. Для ref-counted smart pointers лишние передёргивания ссылок требуются только когда время жизни объекта реально "раздваивается", в большинстве же случаев достаточно move.
WH>Вот только компилятор не в состоянии определить большинство таких ситуаций. Так что тебе придется писать что-то типа ptr1.moveFrom(ptr2).

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

WH>И не дай байт написать это лишний раз.

Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.

EP>>Эти редкие атомарные ++ -- конечно же прям наисерьезнейшая проблема по сравнению с stop-the-world и прочими GC радостями.
WH>http://www.azulsystems.com/technology/c4-garbage-collector

Как-будто конкуренция куда-то делась

Continuously Concurrent Compacting Collector

EP>>2. Это всего лишь один из вариантов smart-pointer'ов. Есть другие — например есть ref-counted без синхронизации, а есть и вовсе без всяких counter'ов.
WH>И если он не дай байт залетит в другой поток, случится феерверк.

Baby-sitting'а нет, откуда вытекает мощность с одной стороны, и возможность делать плохие вещи с другой.

EP>>3. Значимость smart pointers сильно преувеличенна теми, кто полагает что для каждого new в управляемых языках, единственная альтернатива на C++ это smart pointer. На практике же, для большинства случаев достаточно scoped-based lifetime.
WH>Ну, это ты сильно погорячился.

Это опыт реальных проектов. Как ты говорил "уж поверь практикам".

При этом не отрицаю что есть некоторые задачи где время жизни определяется внешними факторами. А иногда даже таким способом, что возможны жёсткие циклы в графе зависимостей.

P.S. Кстати, а есть ли готовая возможность в Nemerle для освобождения ресурса, как только все ссылки на него выйдут из scope? using'и или их аналоги тут не особо помогают:

using System;
using System.IO;

public class Test
{
    public delegate void fireworks();
    public static fireworks make_closure(FileStream fs)
    {
        return () => fs.Read(new byte[10], 0, 10);
    }
    public static fireworks fire()
    {
        using (var fs = File.Open("file", FileMode.Open))
        {
            return make_closure(fs);
        }
    }
    public static void Main()
    {
        fire()();
    }
}

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

J>Ссылку на "большинство" не затруднит привести? Компилятор как раз отлично знает, где у него что, гуглить rvalue references.

http://rsdn.ru/forum/nemerle/5811981.1
Объясни, как компилятор поймет, что нужно щелкать счётчиком ссылок 2, а не 4 раза?

J>Крайне редко это придется писать, уж поверь. Судя по тому, что ты пишешь moveFrom() вместо std::move и rvalue references, о С++11 ты имеешь довольно смутное представление.
Пальцы спрячь. С++ я знаю не хуже всех вас вместе взятых.

WH>>И если он не дай байт залетит в другой поток, случится феерверк.
J>А если единорог придет, то вообще труба.
Знакомая песня. А потом софт в продакшене падает.

J>То есть в твоих программах на С++ сплошные сплошные динамические полиморфные объекты с неопределенным временем жизни? Ну тогда конечно.
Это весьма частый сценарий. Особенно если логика сложная.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

J>>Ссылку на "большинство" не затруднит привести? Компилятор как раз отлично знает, где у него что, гуглить rvalue references.
WH>

http://rsdn.ru/forum/nemerle/5811981.1
WH>Объясни, как компилятор поймет, что нужно щелкать счётчиком ссылок 2, а не 4 раза?

Почитай что-нибудь про move-конструкторы, знаток вместе взятых.

J>>Крайне редко это придется писать, уж поверь. Судя по тому, что ты пишешь moveFrom() вместо std::move и rvalue references, о С++11 ты имеешь довольно смутное представление.
WH>Пальцы спрячь. С++ я знаю не хуже всех вас вместе взятых.
Ты "11" не заметил или специально пропустил? То, что ты знал С++98/03 не хуже всех — не сомневаюсь. Но С++11/14 — то, что ты тут пишешь, говорит само за себя, уж извини.

WH>Знакомая песня. А потом софт в продакшене падает.
Вот-вот, знакомая песня про мифический софт, который у кого-то (у тебя?) в продакшене падает.
У нас вот ничего не падает уже который год, и мы смотрим на тебя с недоумением.
Что-то мы явно делаем не так.

J>>То есть в твоих программах на С++ сплошные сплошные динамические полиморфные объекты с неопределенным временем жизни? Ну тогда конечно.
WH>Это весьма частый сценарий. Особенно если логика сложная.

Ну куда уж нам с нашей простецкой логикой, в которой 99.999% объектов имеют автоматическое время жизни.

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

EP>Если прям стоит задача минимизировать лишние передёргивания, то можно запретить неявные копии и оставить только явные move или copy — в любой непонятной ситуации компилятор будет задавать вопрос.
Ну, так я и говорю, что тебе придётся всё это руками выписывать.

EP>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
Если на асме каждую инструкцию отполировать будет ещё быстрее.

EP>Как-будто конкуренция куда-то делась
EP>

EP>Continuously Concurrent Compacting Collector

Не стоит отвечать на одно слово.
В данном случае это слово означает, что stop-the-world не бывает вообще.

EP>Это опыт реальных проектов. Как ты говорил "уж поверь практикам".
У меня С++ного опыта тоже не мало.

EP>При этом не отрицаю что есть некоторые задачи где время жизни определяется внешними факторами. А иногда даже таким способом, что возможны жёсткие циклы в графе зависимостей.
Во-во. Распутать клубок зависимостей в нитре у меня при всём желании не получится.
Хотя конечно можно сложить каждый отдельный клубок в собственный пул.
Но это куча работы на ровном месте. А у меня и так есть чем заняться.

EP>P.S. Кстати, а есть ли готовая возможность в Nemerle для освобождения ресурса, как только все ссылки на него выйдут из scope? using'и или их аналоги тут не особо помогают:
Я и на С++ так никогда не писал.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

WH>>

http://rsdn.ru/forum/nemerle/5811981.1
WH>>Объясни, как компилятор поймет, что нужно щелкать счётчиком ссылок 2, а не 4 раза?
J>Почитай что-нибудь про move-конструкторы, знаток вместе взятых.
Я знаю, что такое move-конструкторы. Я их еще до С++11 делал.
А теперь давай разбери конкретный пример.
Как тут поможет move-конструктор.
Подсказка: move-конструктор тут использовать нельзя от слова совсем.

J>Вот-вот, знакомая песня про мифический софт, который у кого-то (у тебя?) в продакшене падает.
J>У нас вот ничего не падает уже который год, и мы смотрим на тебя с недоумением.
J>Что-то мы явно делаем не так.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

> Nemerle через 5 лет — выстрелит или скончается?

Выстрелит себе в голову

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

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

WH>>>

http://rsdn.ru/forum/nemerle/5811981.1
WH>>>Объясни, как компилятор поймет, что нужно щелкать счётчиком ссылок 2, а не 4 раза?
J>>Почитай что-нибудь про move-конструкторы, знаток вместе взятых.
WH>Я знаю, что такое move-конструкторы. Я их еще до С++11 делал.
WH>А теперь давай разбери конкретный пример.
WH>Как тут поможет move-конструктор.
WH>Подсказка: move-конструктор тут использовать нельзя от слова совсем.

"Конкретный пример" по ссылке выше? Я ничего в нем не понял, сорри. Если не секрет, что он делает?

J>>Вот-вот, знакомая песня про мифический софт, который у кого-то (у тебя?) в продакшене падает.
J>>У нас вот ничего не падает уже который год, и мы смотрим на тебя с недоумением.
J>>Что-то мы явно делаем не так.

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

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

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

_>>Собственно ничего. Ну или с другой стороны всё, но в таком случае оно и к C# относится (у нас же там имеется unsafe, не так ли?).
WH>Его отдельно включать надо.

Угу, когда не хватает производительности или нужного доступа. А вот мне на C++ включать "режим C" вообще не надо, т.к. всего хватает на нормальном уровне абстракций. )

_>>Для начала тогда уж std::atomic, а не эта хрень из win api.
WH>Не важно. Уверен, что std::atomic на винде через эту хрень и работает.
WH>Ну, или эту хрень туда тупо скопипастили.

Мдаааааааааа...

А ты например в курсе про x86 инструкцию CMPXCHG и то, как она используется для синхронизации в современном C/C++? )

_>>Ну а потом собственно причём тут это? Мы говори о нулевом оверхеде неких абстракций. А здесь у нас совсем не абстракция, а прямая функциональность — синхронизация. Так что само понятие оверхед тут не применимо, т.к. ресурсы тратятся не на реализацию абстракции, а на "дело". Ну или ты хочешь сказать, что можешь привести случаи, когда в C++ синхронизация нужна, а в том же случае в C# не нужна? )
WH>

WH>class Foo
WH>{
WH>  Baz baz;
WH>  void Bar()
WH>  {
WH>    var localBaz = new Baz();//раз
WH>    baz = localBaz;//два
WH>    //три
WH>  }
WH>  //удаление Foo четыре
WH>}
WH>

WH>В C# не нужно ни разу.

И что должна означать этот код? ) Я не вижу какое он вообще имеет отношение к вопросам синхронизации.

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

EP>>Если прям стоит задача минимизировать лишние передёргивания, то можно запретить неявные копии и оставить только явные move или copy — в любой непонятной ситуации компилятор будет задавать вопрос.
WH>Ну, так я и говорю, что тебе придётся всё это руками выписывать.

Не всё, а только в тех вариантах где возможна копия. Там где возможны только move — неявные move пусть вызываются.

EP>>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
WH>Если на асме каждую инструкцию отполировать будет ещё быстрее.

Да, и?

EP>>Как-будто конкуренция куда-то делась
EP>>

EP>>Continuously Concurrent Compacting Collector

WH>Не стоит отвечать на одно слово.
WH>В данном случае это слово означает, что stop-the-world не бывает вообще.

Действительно не стоит, речь ведь шла не только про stop-the-world, но и про прочие GC радости

А уж какие там конкретно GC радости в замену нескольких атомарных передёргиваний счётчика — рояли не играет.

EP>>Это опыт реальных проектов. Как ты говорил "уж поверь практикам".
WH>У меня С++ного опыта тоже не мало.

И что, прям весь код был заселён ref-counting'ом, и он там был действительно к месту?

EP>>При этом не отрицаю что есть некоторые задачи где время жизни определяется внешними факторами. А иногда даже таким способом, что возможны жёсткие циклы в графе зависимостей.
WH>Во-во. Распутать клубок зависимостей в нитре у меня при всём желании не получится.
WH>Хотя конечно можно сложить каждый отдельный клубок в собственный пул.

Можно и так, а при желании можно и GC — C++ -то позволяет

Для некоторых задач GC действительно удобнее всего, но таких задач крайне мало.

EP>>P.S. Кстати, а есть ли готовая возможность в Nemerle для освобождения ресурса, как только все ссылки на него выйдут из scope? using'и или их аналоги тут не особо помогают:
WH>Я и на С++ так никогда не писал.

Конечно здорово, но это не ответ на вопрос. Если ничего готового нет — то ок, с prompt finalization проблемы

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

J>"Конкретный пример" по ссылке выше? Я ничего в нем не понял, сорри. Если не секрет, что он делает?
Не понял, а отправляешь меня читать TFM. Не хорошо.
Создаёт локальную переменную и присваивает её полю объекта.

J>Т.е. смотри — у меня не падает, у тебя не падает, у Евгения не падает, у еще доброго десятка С++ программеров в соответствующем форуме тоже не падает. Но стоит теме С++ всплыть в форуму по Немерле — и всё начинает падать, аки перезрелый виноград.
Проблема в том что на предыдущих работах где очень много чего было на С++ у большинства коллег всё регулярно падало.
Я тоже далеко не сразу научился писать, так чтобы не падало.
Тех кто умеет писать на С++ так чтобы не падало очень не много.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>Не всё, а только в тех вариантах где возможна копия. Там где возможны только move — неявные move пусть вызываются.
Их не так много.
1)Передача объекта в функцию. Но для этого обычно используются константные ссылки.
2)Возвращение из функции свеже созданного объекта или локальной переменной.

EP>>>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
WH>>Если на асме каждую инструкцию отполировать будет ещё быстрее.
EP>Да, и?
И сколько времени у тебя на это уйдёт?

EP>Действительно не стоит, речь ведь шла не только про stop-the-world, но и про прочие GC радости

EP>А уж какие там конкретно GC радости в замену нескольких атомарных передёргиваний счётчика — рояли не играет.
Это ещё большой вопрос.

EP>И что, прям весь код был заселён ref-counting'ом, и он там был действительно к месту?
Разные проекты были. Был такой, где действительно всё было засалено этой субстанцией. И иначе было нельзя.

EP>Можно и так, а при желании можно и GC — C++ -то позволяет

Для некоторых задач GC действительно удобнее всего, но таких задач крайне мало.
Это не ГЦ. Это говно.
Нормальный ГЦ С++ не позволяет.

EP>Конечно здорово, но это не ответ на вопрос. Если ничего готового нет — то ок, с prompt finalization проблемы

Ты первый кто её просит. А раз никто не просит то никто и не делает.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

_>Угу, когда не хватает производительности или нужного доступа. А вот мне на C++ включать "режим C" вообще не надо, т.к. всего хватает на нормальном уровне абстракций. )
Не правильно. Ты его тупо отключить не можешь.

_>Мдаааааааааа...
Сам такой.

_>А ты например в курсе про x86 инструкцию CMPXCHG и то, как она используется для синхронизации в современном C/C++? )
А интерлокеды что, по-твоему, делают?

_>И что должна означать этот код? ) Я не вижу какое он вообще имеет отношение к вопросам синхронизации.
Прямое. Я посчитал сколько раз С++ щёлкнет счётчиком ссылок.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

J>>"Конкретный пример" по ссылке выше? Я ничего в нем не понял, сорри. Если не секрет, что он делает?
WH>Не понял, а отправляешь меня читать TFM. Не хорошо.
WH>Создаёт локальную переменную и присваивает её полю объекта.

И всё? А зачем там тогда вообще локальная переменная? Почему нельзя присвоить/поменять поле объекта напрямую?
Плюс поле у тебя, вроде как, по значению хранит объект, а локальная переменная — по указателю в кучу.
Или там везде указатели на самом деле?
В общем, я не понимаю смысла этого кода. На С++ он смысла не имеет, тупо не скомпилируется. Не хорошо (с).

ЗЫ Раз ты знаешь, что такое move-constructor, то ты ведь и про move-assignment Тоже, наверняка, знаешь?

J>>Т.е. смотри — у меня не падает, у тебя не падает, у Евгения не падает, у еще доброго десятка С++ программеров в соответствующем форуме тоже не падает. Но стоит теме С++ всплыть в форуму по Немерле — и всё начинает падать, аки перезрелый виноград.
WH>Проблема в том что на предыдущих работах где очень много чего было на С++ у большинства коллег всё регулярно падало.
WH>Я тоже далеко не сразу научился писать, так чтобы не падало.
WH>Тех кто умеет писать на С++ так чтобы не падало очень не много.

Ну хз. Мне везет, наверное. К нам один раз только попало такое чудо в команду — его быстро перевели в скрипто-писатели (и при первой же возможности уволили, ессно). Ну так он и на Питоне "с GC и лямбдами" умудрялся так овнокодить, что потом еще пару лет разгребали за ним его скрипты, и они вдруг начинали работать 5 минут вместо 2 часов (серьезно, так и было). Так что, имхо, тут не в языке проблемы обычно. Программер, у которого падают программы на С++, будет генерить глюкалово на любом языке.

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

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

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

J>Плюс поле у тебя, вроде как, по значению хранит объект, а локальная переменная — по указателю в кучу.
J>Или там везде указатели на самом деле?
В .НЕТ это зависит от типа объекта.

J>ЗЫ Раз ты знаешь, что такое move-constructor, то ты ведь и про move-assignment Тоже, наверняка, знаешь?
Знаю. Но при присвоении одной переменной другой его использовать нельзя.

J>Ну хз. Мне везет, наверное. К нам один раз только попало такое чудо в команду — его быстро перевели в скрипто-писатели (и при первой же возможности уволили, ессно). Ну так он и на Питоне "с GC и лямбдами" умудрялся так овнокодить, что потом еще пару лет разгребали за ним его скрипты, и они вдруг начинали работать 5 минут вместо 2 часов (серьезно, так и было). Так что, имхо, тут не в языке проблемы обычно. Программер, у которого падают программы на С++, будет генерить глюкалово на любом языке.
У меня пока меленький был тоже падали. Уверен, что и у тебя падали.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

_>>А ты например в курсе про x86 инструкцию CMPXCHG и то, как она используется для синхронизации в современном C/C++? )
WH>А интерлокеды что, по-твоему, делают?

Для начале это функции win api, со всеми вытекающими последствиями для быстродействия... Ну а внутри там насколько я помню xadd.

_>>И что должна означать этот код? ) Я не вижу какое он вообще имеет отношение к вопросам синхронизации.
WH>Прямое. Я посчитал сколько раз С++ щёлкнет счётчиком ссылок.

Ээээ, а там где-то в этом коде находятся сущности работающие по принципу подсчёта ссылок? ) И как я должен был об этом догадаться по такому коду?

И главное, а зачем они там собственно? )

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

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

EP>В вопросах производительности не имеет особого смысла рассматривать выделение памяти отдельно от освобождения.

А что с ним не так? В средах с GC освобождение памяти бесплатно. Наоборот, платить приходится за живые объекты (временем затрачиваемым на построение графа живых объектов и дефрагментацию кучи).

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

EP>Но да, есть случаи, как уже выше сказал alex_public, где стандартный аллокатор управляемых языков будет быстрее стандартных new/delete C++

Дык стандартный и используются в 99% случаев. Для отдельных задач конечно можно создать более быстрые решения, но в общем случае они не работают. Разве что межпоточной безопасностью можно пренебречь и выиграть с этого некоторое количество тактов.

EP>Вот только нужно не забывать, что C++ это не только преимущества в скорости, но ещё и в гибкости.
EP>На C# — шаг влево, шаг вправо и упираешься в забор, в результате код получается более многословный.

Да, несомненно. Если мериться с C#, то кое какая гибкость есть. Правда платить за это приходится массой неудобств и костылей/велосипедов для решения даже базовых задач вроде передачи ссылки на метод или долгоживущих объектов в функцию.

Но это по сравнению с C#. А Nemerle, который мы тут обсуждаем этих недостатков не имеет. Он значительно гибче плюсов, и за это не нужно платить неудобствами в повседневной жизни. Он более удобен чем C# и гибче чем C++. Проблемы по ссылки выше в Nemerle просто нет. Но это мелочи.

EP>Обобщённый код (это даже не метапрограммирование) на C++ получается разы короче и проще.

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

Недостаток же гибкости компенсируется использованием функций высшего порядка.

У Nemerle же и эти недостатки дотнета компенсируются еще и макросами. Шаблоны C++ можно рассматривать как подмножество макросов Nemerle. На макросах Nemerle можно сделать все что можно сделать на шаблонах C++ и много чего еще, что шаблонам C++ недоступно. Причем даже если одно и то же можно сделать и на шаблонах, и на макроса, то решение на макросах, обычно, будет более качественным за счет более тесной интеграции с компилятором.

EP>Вот например, на Python можно сделать так (будет работать для любых типов имеющих соответствующие операторы):...
EP>Аналог на C++:
EP>

EP>auto add = [](auto x, auto y)
EP>{
EP>    return x + y;
EP>};
EP>auto sub = [](auto x, auto y)
EP>{
EP>    return x - y;
EP>};
EP>auto apply = [](auto f, auto... args)
EP>{
EP>    return f(args...);
EP>};
EP>print(apply(apply, apply, apply, add, 1, 2));
EP>print(apply(apply, apply, sub, 11, 2));
EP>

EP>На C# будет облом.

Забавный финт ушами. Ничего не скажешь. В C# его можно попытаться воспроизвести на dynamic-ах, но там куча проблем, так что оно точно не будет простым и быстрым. Переменное число параметров в дотнете и C# поддерживается, но типы всех параметров должны быть одинаковы. Кроме того есть проблемы с приведением методов к делегатам. Это надо делать явно.

Вот только это довольно надуманный пример. На практике он мало что дает.

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

Пишется вот такой макрос:

macro apply(f, params args : array[PExpr])
{
  <[ $f(..$args) ]>
}

В макросах тоже поддерживается список параметров, но типы аргументов не важны, так как в данном случае работа идет с кодом (AST-ом), а не со значениями. Таким образом, как и в C++, в Nemerle apply "раскроется" во время компиляции и породит нужный код.

Вот код использования:

using System.Console;

module Program
{
  Main() : void
  {
    
    WriteLine(apply(apply, apply, apply, _ + _, 1, 2));
    WriteLine(apply(apply, apply, _ - _, 11, 2));
    _ = ReadLine();
  }
}

EP>И, что-то мне подсказывает, если это и получится на Nemerle, то не так складно, ибо система типов .NET — примитивней

EP>Ожидаю блаб-объяснений что это и не нужно, потому что можно без этого

Ну, тебе все время что-то подсказывает не верные выводы.

Ты бы лучше меньше слушал бы это что-то.

Я не просто так говорю, что Nemerle мощнее C++ и всех остальных мэйнстрим-языков. Я бы не сменил C++ на C#, а потом C# на Nemerle, если бы на то не было бы весомых оснований. Так что лучше пытаться тягаться длинной пенисов (у меня все равно он длиннее окажется

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

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

VD>Не лучше ли взглянуть на комиты:
VD>https://github.com/rsdn/nemerle/commits/

Сорри что встреваю, но вот как раз что то количество коммитов совсем не впечатляет. Для сранения коммиты по rsdn.ru с начала сентября (для информации — занимаюсь сайтом только я в свободное от работы время по чуть чуть).

	Скрытый текст
	Tuesday, October 7, 2014 New quota format in testbed ad8d70 by andrewvk <avk@rsdn.ru>, Tuesday Monday, October 6, 2014 New quota format in testbed 0eb55c by andrewvk <avk@rsdn.ru>, Monday Sunday, October 5, 2014 Linq2db update 498a3a by andrewvk <avk@rsdn.ru>, Sunday Friday, October 3, 2014 Fix poll list a47728 by andrewvk <avk@rsdn.ru>, 10/3/2014 Fix subscription, fix broken links 5a7a9d by andrewvk <avk@rsdn.ru>, 10/3/2014 Working on NNTP provider update 438089 by andrewvk <avk@rsdn.ru>, 10/3/2014 Thursday, October 2, 2014 Update Nemerle.xml 99431d by andrewvk <avk@rsdn.ru>, 10/2/2014 Fix subscription 1c6848 by andrewvk <avk@rsdn.ru>, 10/2/2014 Wednesday, October 1, 2014 Fix subscription b89f74 by andrewvk <avk@rsdn.ru>, 10/1/2014 Tuesday, September 30, 2014 Activate new poll list 743a69 by andrewvk <avk@rsdn.ru>, 9/30/2014 Fix title script 2edabc by andrewvk <avk@rsdn.ru>, 9/30/2014 Fix RSDN-37 3e1004 by andrewvk <avk@rsdn.ru>, 9/30/2014 Sunday, September 28, 2014 Fix script 66f6ee by andrewvk <avk@rsdn.ru>, 9/28/2014 Block title update for side frames 3651ff by andrewvk <avk@rsdn.ru>, 9/28/2014 Limit posting by user rate 844e4f by andrewvk <avk@rsdn.ru>, 9/28/2014 Fix moderator UI. Working on new poll list df4e00 by andrewvk <avk@rsdn.ru>, 9/28/2014 Saturday, September 27, 2014 Replace Vote.aspx by new poll control. 1b1968 by andrewvk <avk@rsdn.ru>, 9/27/2014 Sort in poll control 657e41 by andrewvk <avk@rsdn.ru>, 9/27/2014 Sort in poll control 75bdbe by andrewvk <avk@rsdn.ru>, 9/27/2014 Sort in poll control 0f9a93 by andrewvk <avk@rsdn.ru>, 9/27/2014 Sort in poll control fdb8aa by andrewvk <avk@rsdn.ru>, 9/27/2014 Replace Vote.aspx by new poll control. b1f7e8 by andrewvk <avk@rsdn.ru>, 9/27/2014 Poll control improvements. Replace Vote.aspx by new poll control. 145348 by andrewvk <avk@rsdn.ru>, 9/27/2014 Friday, September 26, 2014 New format testbed 5f3284 by andrewvk <avk@rsdn.ru>, 9/26/2014 Table styles 3fb019 by andrewvk <avk@rsdn.ru>, 9/26/2014 New format testbed 57238e by andrewvk <avk@rsdn.ru>, 9/26/2014 Fix formatter bug on empty links f9426c by andrewvk <avk@rsdn.ru>, 9/26/2014 Thursday, September 25, 2014 Quotations in format testbed bd1739 by andrewvk <avk@rsdn.ru>, 9/25/2014 Quotations in format testbed c90a8e by andrewvk <avk@rsdn.ru>, 9/25/2014 Fix mod bug 55950d by andrewvk <avk@rsdn.ru>, 9/25/2014 Moderator UI separation from admin cd071d by andrewvk <avk@rsdn.ru>, 9/25/2014 Moderator UI separation from admin 008c93 by andrewvk <avk@rsdn.ru>, 9/25/2014 New format testbed 7825ce by andrewvk <avk@rsdn.ru>, 9/25/2014 Wednesday, September 24, 2014 Moderator UI separation from admin 8e2ef2 by andrewvk <avk@rsdn.ru>, 9/24/2014 Small fixes 556563 by andrewvk <avk@rsdn.ru>, 9/24/2014 Tuesday, September 23, 2014 Hot tab in mainlist badf09 by andrewvk <avk@rsdn.ru>, 9/23/2014 Mainlist improvements. 11f9e9 by andrewvk <avk@rsdn.ru>, 9/23/2014 Monday, September 22, 2014 Virtual keyboard 1ab4d8 by andrewvk <avk@rsdn.ru>, 9/22/2014 Fix editor script d11d42 by andrewvk <avk@rsdn.ru>, 9/22/2014 Update frameset title in all new pages layout, refactoring c70722 by andrewvk <avk@rsdn.ru>, 9/22/2014 Fix caching issue in IE 5a8155 by andrewvk <avk@rsdn.ru>, 9/22/2014 Small fix 07f980 by andrewvk <avk@rsdn.ru>, 9/22/2014 Fix script 1e316a by andrewvk <avk@rsdn.ru>, 9/22/2014 Fix urls, drop old mainlist 372d86 by andrewvk <avk@rsdn.ru>, 9/22/2014 Sunday, September 21, 2014 Mainlist improvements. 8e47ae by andrewvk <avk@rsdn.ru>, 9/21/2014 Script fix eb1cf9 by andrewvk <avk@rsdn.ru>, 9/21/2014 Mainlist improvements. 2a0bd2 by andrewvk <avk@rsdn.ru>, 9/21/2014 Working on new poll list 510234 by andrewvk <avk@rsdn.ru>, 9/21/2014 Working on new poll list 9a1520 by andrewvk <avk@rsdn.ru>, 9/21/2014 Working on new poll list, mainlist fix f779a4 by andrewvk <avk@rsdn.ru>, 9/21/2014 Working on new poll list 6509b9 by andrewvk <avk@rsdn.ru>, 9/21/2014 Small mainlist fix 87b164 by andrewvk <avk@rsdn.ru>, 9/21/2014 Fix poll edit bug 5256e1 by andrewvk <avk@rsdn.ru>, 9/21/2014 Saturday, September 20, 2014 Small fixes 8c3b5f by andrewvk <avk@rsdn.ru>, 9/20/2014 Mainlist autorefresh 881ffc by andrewvk <avk@rsdn.ru>, 9/20/2014 Admin UI improvements, dbproj update 9548fb by andrewvk <avk@rsdn.ru>, 9/20/2014 Mainlist autorefresh 116617 by andrewvk <avk@rsdn.ru>, 9/20/2014 Mainlist autorefresh cb8912 by andrewvk <avk@rsdn.ru>, 9/20/2014 Preview in mainlist 614564 by andrewvk <avk@rsdn.ru>, 9/20/2014 Alt + number guard in message editor 4216fb by andrewvk <avk@rsdn.ru>, 9/20/2014 SiteSubj/NotSiteSubj tabs in mainlist 9098e4 by andrewvk <avk@rsdn.ru>, 9/20/2014 Track ajax by ga b32f7e by andrewvk <avk@rsdn.ru>, 9/20/2014 Forum filter UI improvements 5acd07 by andrewvk <avk@rsdn.ru>, 9/20/2014 Mistyping 03d153 by andrewvk <avk@rsdn.ru>, 9/20/2014 Forum filter UI in mainlist 7e989d by andrewvk <avk@rsdn.ru>, 9/20/2014 Flag styles 608274 by andrewvk <avk@rsdn.ru>, 9/20/2014 Friday, September 19, 2014 Colors in mainlist 45330c by andrewvk <avk@rsdn.ru>, 9/19/2014 Colors in mainlist 549bdb by andrewvk <avk@rsdn.ru>, 9/19/2014 Fix script 421eff by andrewvk <avk@rsdn.ru>, 9/19/2014 Page size in mainlist 37bef2 by andrewvk <avk@rsdn.ru>, 9/19/2014 Fix editor tooltips cab160 by andrewvk <avk@rsdn.ru>, 9/19/2014 New mainlist improvements. Redirect from old MainList. d5e1d3 by andrewvk <avk@rsdn.ru>, 9/19/2014 Admin UI improvements aba6f2 by andrewvk <avk@rsdn.ru>, 9/19/2014 Thursday, September 18, 2014 Update dbproj 7fd304 by andrewvk <avk@rsdn.ru>, 9/18/2014 Revert "Country image links tmp fix"... b56109 by andrewvk <avk@rsdn.ru>, 9/18/2014 Fix routing 1aa973 by andrewvk <avk@rsdn.ru>, 9/18/2014 Working on new mainlist b106e8 by andrewvk <avk@rsdn.ru>, 9/18/2014 Mainlist layout 24057c by andrewvk <avk@rsdn.ru>, 9/18/2014 Mainlist layout d6c6c5 by andrewvk <avk@rsdn.ru>, 9/18/2014 Country image links tmp fix d286c2 by andrewvk <avk@rsdn.ru>, 9/18/2014 Working on new mainlist 050861 by andrewvk <avk@rsdn.ru>, 9/18/2014 Working on new mainlist 1e3e4d by andrewvk <avk@rsdn.ru>, 9/18/2014 Wednesday, September 17, 2014 Add gravatar and country to janus ws 23574d by andrewvk <avk@rsdn.ru>, 9/17/2014 Delete old forum search e523b7 by andrewvk <avk@rsdn.ru>, 9/17/2014 Fix rate base svc bb1cb5 by andrewvk <avk@rsdn.ru>, 9/17/2014 Src encoding 78f265 by andrewvk <avk@rsdn.ru>, 9/17/2014 Flat mode performance e3dad5 by andrewvk <avk@rsdn.ru>, 9/17/2014 Country dispersion d6b4ce by andrewvk <avk@rsdn.ru>, 9/17/2014 Fix country cache c9bb45 by andrewvk <avk@rsdn.ru>, 9/17/2014 Fix country cache 25fb2f by andrewvk <avk@rsdn.ru>, 9/17/2014 Tuesday, September 16, 2014 Admin UI improvements 1a2c65 by andrewvk <avk@rsdn.ru>, 9/16/2014 Admin UI improvements 36323a by andrewvk <avk@rsdn.ru>, 9/16/2014 Country recognition fixes e421b8 by andrewvk <avk@rsdn.ru>, 9/16/2014 Country recognition improvements a0353e by andrewvk <avk@rsdn.ru>, 9/16/2014 Country recognition improvements 01625c by andrewvk <avk@rsdn.ru>, 9/16/2014 Wiki fixes f3e19e by andrewvk <avk@rsdn.ru>, 9/16/2014 Fix compilation 83a8bf by andrewvk <avk@rsdn.ru>, 9/16/2014 Fix compilation ab90ad by andrewvk <avk@rsdn.ru>, 9/16/2014 Fix compilation 3abd86 by andrewvk <avk@rsdn.ru>, 9/16/2014 Update dbproj, message page refactoring 124a55 by andrewvk <avk@rsdn.ru>, 9/16/2014 Monday, September 15, 2014 Fix compilation 0d8c6e by andrewvk <avk@rsdn.ru>, 9/15/2014 Country flags in origin 07590a by andrewvk <avk@rsdn.ru>, 9/15/2014 MS icons 681ec9 by andrewvk <avk@rsdn.ru>, 9/15/2014 Working on new navtree c20712 by andrewvk <avk@rsdn.ru>, 9/15/2014 Fix tree editor cf1e45 by andrewvk <avk@rsdn.ru>, 9/15/2014 Navtree control d7f206 by andrewvk <avk@rsdn.ru>, 9/15/2014 Sunday, September 14, 2014 Do not create poll control in quotas ec85d5 by andrewvk <avk@rsdn.ru>, 9/14/2014 Fix style 76fdf3 by andrewvk <avk@rsdn.ru>, 9/14/2014 Replace poll links in messages to poll control 92b866 by andrewvk <avk@rsdn.ru>, 9/14/2014 Saturday, September 13, 2014 Working on poll control 992ba3 by andrewvk <avk@rsdn.ru>, 9/13/2014 Working on poll control 48700f by andrewvk <avk@rsdn.ru>, 9/13/2014 Poll control 2697c9 by andrewvk <avk@rsdn.ru>, 9/13/2014 Friday, September 12, 2014 Editor fixes a699da by andrewvk <avk@rsdn.ru>, 9/12/2014 Rewrite article adv logic 107051 by andrewvk <avk@rsdn.ru>, 9/12/2014 Rewrite article adv logic 256eac by andrewvk <avk@rsdn.ru>, 9/12/2014 Rewrite article adv logic b7782b by andrewvk <avk@rsdn.ru>, 9/12/2014 Rewrite article adv logic 02a257 by andrewvk <avk@rsdn.ru>, 9/12/2014 Add last topics to main page. Fix GetElapsedString bugs. 7d5aab by andrewvk <avk@rsdn.ru>, 9/12/2014 Custom styles support 9f37b8 by andrewvk <avk@rsdn.ru>, 9/12/2014 Thursday, September 11, 2014 Fix focusing behavior in FF&Opera 9e6ba7 by andrewvk <avk@rsdn.ru>, 9/11/2014 Fix close button in FF 0733b8 by andrewvk <avk@rsdn.ru>, 9/11/2014 Fix layout 72e259 by andrewvk <avk@rsdn.ru>, 9/11/2014 Spaces around inline tags 45750e by andrewvk <avk@rsdn.ru>, 9/11/2014 Fix editor script 4587ca by andrewvk <avk@rsdn.ru>, 9/11/2014 Tabs in editor a83d2b by andrewvk <avk@rsdn.ru>, 9/11/2014 Send message hotkey c50ac8 by andrewvk <avk@rsdn.ru>, 9/11/2014 Editor fixes 99f3f7 by andrewvk <avk@rsdn.ru>, 9/11/2014 Style fix 4c5554 by andrewvk <avk@rsdn.ru>, 9/11/2014 Wednesday, September 10, 2014 Update packages 999996 by andrewvk <avk@rsdn.ru>, 9/10/2014 Style fixes ebb778 by andrewvk <avk@rsdn.ru>, 9/10/2014 Fix start page wikies query b7372c by andrewvk <avk@rsdn.ru>, 9/10/2014 Update dbproj 0c272d by andrewvk <avk@rsdn.ru>, 9/10/2014 Popup position 0df892 by andrewvk <avk@rsdn.ru>, 9/10/2014 Fix message name row visibility cd035b by andrewvk <avk@rsdn.ru>, 9/10/2014 URL tag specific handling 2cf877 by andrewvk <avk@rsdn.ru>, 9/10/2014 Missing tags in editor 60d23d by andrewvk <avk@rsdn.ru>, 9/10/2014 Fix message name disappearing on preview 306081 by andrewvk <avk@rsdn.ru>, 9/10/2014 Allow "wikitize" messages without name 0d762a by andrewvk <avk@rsdn.ru>, 9/10/2014 Fix scripts f43dc6 by andrewvk <avk@rsdn.ru>, 9/10/2014 Refactoring&cleanup 5822ba by andrewvk <avk@rsdn.ru>, 9/10/2014 Theme settings layout b3be72 by andrewvk <avk@rsdn.ru>, 9/10/2014 Drop www prefixes 22f0e5 by andrewvk <avk@rsdn.ru>, 9/10/2014 Move id attr in svgie.js ebac5e by andrewvk <avk@rsdn.ru>, 9/10/2014 Tuesday, September 9, 2014 Refactoring, style fixes a608eb by andrewvk <avk@rsdn.ru>, 9/9/2014 Meta in newmsg page 55a56a by andrewvk <avk@rsdn.ru>, 9/9/2014 Move editor demo to production page d5a3c0 by andrewvk <avk@rsdn.ru>, 9/9/2014 Tooltips in editor fb8f52 by andrewvk <avk@rsdn.ru>, 9/9/2014 Decode urls in link text 11f8f5 by andrewvk <avk@rsdn.ru>, 9/9/2014 Fix formatter bug 521c6a by andrewvk <avk@rsdn.ru>, 9/9/2014 Working on editor demo 0e5b2d by andrewvk <avk@rsdn.ru>, 9/9/2014 Working on editor demo 108a5a by andrewvk <avk@rsdn.ru>, 9/9/2014 Fix copy code issue. Working on editor demo 7cd485 by andrewvk <avk@rsdn.ru>, 9/9/2014 Working on editor demo dc727b by andrewvk <avk@rsdn.ru>, 9/9/2014 Editor demo (own control) 0d8df9 by andrewvk <avk@rsdn.ru>, 9/9/2014 Monday, September 8, 2014 Meta in forum page e7e721 by andrewvk <avk@rsdn.ru>, 9/8/2014 Wiki changes on start page 834aa1 by andrewvk <avk@rsdn.ru>, 9/8/2014 Fix styles in mail 45fa30 by andrewvk <avk@rsdn.ru>, 9/8/2014 Meta in msg page bbb05b by andrewvk <avk@rsdn.ru>, 9/8/2014 Increase janus svc limits 6a0232 by andrewvk <avk@rsdn.ru>, 9/8/2014 Sunday, September 7, 2014 Fix origin d56cec by andrewvk <avk@rsdn.ru>, 9/7/2014 Fix origin 470717 by andrewvk <avk@rsdn.ru>, 9/7/2014 Fix origin 3062e3 by andrewvk <avk@rsdn.ru>, 9/7/2014 Fix origin 12f52e by andrewvk <avk@rsdn.ru>, 9/7/2014 Fix preview bcda61 by andrewvk <avk@rsdn.ru>, 9/7/2014 Daily stat for team cee1c6 by andrewvk <avk@rsdn.ru>, 9/7/2014 Forum wiki as default forum page 06d278 by andrewvk <avk@rsdn.ru>, 9/7/2014 Reply count in wiki page 72a6c5 by andrewvk <avk@rsdn.ru>, 9/7/2014 Fix auth bug 55da58 by andrewvk <avk@rsdn.ru>, 9/7/2014 Saturday, September 6, 2014 Fix script 42ee1b by andrewvk <avk@rsdn.ru>, 9/6/2014 Restore addthis 7de805 by andrewvk <avk@rsdn.ru>, 9/6/2014 Fix rate bug b905ca by andrewvk <avk@rsdn.ru>, 9/6/2014 AJAX topic subs 47e806 by andrewvk <avk@rsdn.ru>, 9/6/2014 Fix styles 81ef25 by andrewvk <avk@rsdn.ru>, 9/6/2014 Show subs status 902bc5 by andrewvk <avk@rsdn.ru>, 9/6/2014 Show subs status 547cee by andrewvk <avk@rsdn.ru>, 9/6/2014 AJAX AddFav 79e09e by andrewvk <avk@rsdn.ru>, 9/6/2014 AJAX AddFav 3af7d3 by andrewvk <avk@rsdn.ru>, 9/6/2014 Refactoring 2d0adb by andrewvk <avk@rsdn.ru>, 9/6/2014 Refactoring 77877c by andrewvk <avk@rsdn.ru>, 9/6/2014 Refactoring f6fad8 by andrewvk <avk@rsdn.ru>, 9/6/2014 Fix script 25e589 by andrewvk <avk@rsdn.ru>, 9/6/2014 Fix script 63353a by andrewvk <avk@rsdn.ru>, 9/6/2014 Fix RSDN-25 8424ff by andrewvk <avk@rsdn.ru>, 9/6/2014 js => ts bbe592 by andrewvk <avk@rsdn.ru>, 9/6/2014 Friday, September 5, 2014 Show message name in header a903b8 by andrewvk <avk@rsdn.ru>, 9/5/2014 Adding TypeScript 5fd726 by andrewvk <avk@rsdn.ru>, 9/5/2014 Refactoring, colors 119d38 by andrewvk <avk@rsdn.ru>, 9/5/2014 Do not assign rate to user, if message is wiki b70946 by andrewvk <avk@rsdn.ru>, 9/5/2014 Do not assign rate to user, if message is wiki 5b5b8e by andrewvk <avk@rsdn.ru>, 9/5/2014 Thursday, September 4, 2014 FB share in blogs 8eebef by andrewvk <avk@rsdn.ru>, 9/4/2014 FB meta tags in blogs 69d36e by andrewvk <avk@rsdn.ru>, 9/4/2014 FB meta tags in blogs 21850b by andrewvk <avk@rsdn.ru>, 9/4/2014 FB meta tags in blogs 84fe3b by andrewvk <avk@rsdn.ru>, 9/4/2014 FB meta tags in blogs 7733f5 by andrewvk <avk@rsdn.ru>, 9/4/2014 Small fix 181bf1 by andrewvk <avk@rsdn.ru>, 9/4/2014 Message edit comments b1b6d2 by andrewvk <avk@rsdn.ru>, 9/4/2014 Message edit comments 7acd5f by andrewvk <avk@rsdn.ru>, 9/4/2014 Formatter fixes 0ef862 by andrewvk <avk@rsdn.ru>, 9/4/2014 Wednesday, September 3, 2014 fix origin bf32da by andrewvk <avk@rsdn.ru>, 9/3/2014 Formatter layout d1f2cf by andrewvk <avk@rsdn.ru>, 9/3/2014 Style fixes bbf152 by andrewvk <avk@rsdn.ru>, 9/3/2014 Well known host links highlight in message body 03fadf by andrewvk <avk@rsdn.ru>, 9/3/2014 Well known host links highlight in message body dc179f by andrewvk <avk@rsdn.ru>, 9/3/2014 Well known host links highlight in message body e620ba by andrewvk <avk@rsdn.ru>, 9/3/2014 Tuesday, September 2, 2014 Quotation level 1fee17 by andrewvk <avk@rsdn.ru>, 9/2/2014 Quotation level 354289 by andrewvk <avk@rsdn.ru>, 9/2/2014 Sync formatter with main repo a62cc7 by andrewvk <avk@rsdn.ru>, 9/2/2014 Admin UI improvements 4a1360 by andrewvk <avk@rsdn.ru>, 9/2/2014 Anti XSS protection 561ef4 by andrewvk <avk@rsdn.ru>, 9/2/2014 Anti XSS protection eb4260 by andrewvk <avk@rsdn.ru>, 9/2/2014 Fix messageNameRow visibility 7f7905 by andrewvk <avk@rsdn.ru>, 9/2/2014 Fix messageNameRow visibility ea7a74 by andrewvk <avk@rsdn.ru>, 9/2/2014 Fix blog news query 2e8549 by andrewvk <avk@rsdn.ru>, 9/2/2014 Formatter styles 597b2a by andrewvk <avk@rsdn.ru>, 9/2/2014 Links 79b409 by andrewvk <avk@rsdn.ru>, 9/2/2014 Monday, September 1, 2014 Collapsible versions 51a133 by andrewvk <avk@rsdn.ru>, 9/1/2014 Wiki layout 9cede5 by andrewvk <avk@rsdn.ru>, 9/1/2014 Wiki layout 41c95b by andrewvk <avk@rsdn.ru>, 9/1/2014 Access checks on message edit 57ed54 by andrewvk <avk@rsdn.ru>, 9/1/2014 Working on wiki 573202 by andrewvk <avk@rsdn.ru>, 9/1/2014 NewMsg.aspx refactoring & fixes 35304d by andrewvk <avk@rsdn.ru>, 9/1/2014 Wiki icon 1429ba by andrewvk <avk@rsdn.ru>, 9/1/2014 Wiki history 3f88b0 by andrewvk <avk@rsdn.ru>, 9/1/2014 Wiki history 436cc1 by andrewvk <avk@rsdn.ru>, 9/1/2014 Fix tags saving on edit 6f2c32 by andrewvk <avk@rsdn.ru>, 9/1/2014 Working on wiki 5da9ac by andrewvk <avk@rsdn.ru>, 9/1/2014 Working on wiki c8e33f by andrewvk <avk@rsdn.ru>, 9/1/2014

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

WH>>>>>И не дай байт написать это лишний раз.
EP>>>>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
WH>>>Если на асме каждую инструкцию отполировать будет ещё быстрее.
EP>>Да, и?
WH>И сколько времени у тебя на это уйдёт?

В разы, а то и на порядок больше чем если бы не было полировки, так как код C++ — optimization-friendly, после прохода оптимизатора остаётся не так много возможностей для улучшения

К чему вопрос-то?
Неужели ты считаешь цену ручной оптимизации ASM кода сопоставимой с ценой правильной расстановкой move/copy?
Или это как-то сравнимо с тем, когда для производительности полностью отказываются от GC, а-ля garbage-free?

EP>>Действительно не стоит, речь ведь шла не только про stop-the-world, но и про прочие GC радости

EP>>А уж какие там конкретно GC радости в замену нескольких атомарных передёргиваний счётчика — рояли не играет.
WH>Это ещё большой вопрос.

Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec, с другой — конкурентная-пакость, которая параллельно основным потокам шарит по их данным и делает какие-то манипуляции, хорошо ещё если lock-free.

EP>>И что, прям весь код был заселён ref-counting'ом, и он там был действительно к месту?
WH>Разные проекты были. Был такой, где действительно всё было засалено этой субстанцией. И иначе было нельзя.

А хотя бы чем было обусловлено? Какими-то алгоритмическими/прикладными особенностями? Или возможно каким-то interop'ом?

EP>>Можно и так, а при желании можно и GC — C++ -то позволяет

Для некоторых задач GC действительно удобнее всего, но таких задач крайне мало.
WH>Это не ГЦ. Это говно.
WH>Нормальный ГЦ С++ не позволяет.

Нормальный это какой?
В стандарте есть интерфейс для для консервативного GC.
Есть точные GC — но они менее автоматизированные чем консервативные. При использовании точных нужно заменять T* на gc_ptr<T> и т.п. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.

EP>>Конечно здорово, но это не ответ на вопрос. Если ничего готового нет — то ок, с prompt finalization проблемы

WH>Ты первый кто её просит. А раз никто не просит то никто и не делает.

Хотя бы как тогда разруливается ситуация с IDisposable? Например — один метод поставил using скобки на объект, передал его в другой метод, который втихую сохранил его до лучших времён — в итоге у него окажется ссылка на disposed объект. Фейерверк?

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

J>В этом смысле Немерле по отношению к шарпу точно в такой же позиции находится, имхо: шарп + макросы.

К сожалению это не так. В Немерле есть много (относительно шарпа) странностей — другие скобки для дженериков, последнее выражение в блоке как return, да даже обязательная необходимоть писать else у if. Каждая по отдельность проблемочка — яйца выеденного не стоит, но в комплексе оно все делает язык довольно далеко отстоящим от шарпа.
Что самое печальное, вместо того чтобы попытаться как то поправить странности, пусть даже и с потерей некоторой абстрактной стройности концепций (хотя ряд фич там не из за концепций, а просто потому что захотелось так изначальным полякам), на практике мы видим попытки нас убедить, что это наоборот, все зашибись, просто мы не прониклись.
А так я лет 5 назад предлагал взять шарп, выкинуть из него некоторое количество хвостов и косяков, да добавить туда самые вкусные моменты — ПМ, сахарок разный типа того, что отчасти реализовали, отчасти напредлагали в C# 6 и т.п. Тогда, особенно на фоне микроизменений в C# 4 и 5, у языка были бы шансы. А Немерле нет, никогда не станет существенно популярным, увы.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

VD>Мартышкам проще и приятнее бить очки, чем разбираться.

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

_NN>Компилятор Nemerle умеет компилировать C# . ( Не все фишки и есть некоторые нюансы )

Ага. Вот еще новое навигационное дерево для rsdn.ru. Тоже практически работает, но есть некоторые нюансы.
Есть только одна закавыка — я тут сел и за час на голом JS (ок, на TS) написал это проклятущее дерево. Пусть без модных фишек типа запинивания, зато на 100% вписывающееся в существующую серверную инфраструктуру. И, что характерно, никаких "это невозможно в нашей концепции".

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

>> Nemerle через 5 лет — выстрелит или скончается?

K>Выстрелит себе в голову

Евгений Ваганович, перелогинтесь.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

AVK>К сожалению это не так. В Немерле есть много (относительно шарпа) странностей — другие скобки для дженериков, последнее выражение в блоке как return, да даже обязательная необходимоть писать else у if.
Немерл не является надмножеством шарпа. Это другой язык с иными приоритетами и синтаксисом.

AVK>...делает язык довольно далеко отстоящим от шарпа.
Далеко отстоящим от шарпа язык делает не набор синтаксических отличий, а концепции положенные в основу.
Надо понимать, что ядро Немерле — минималистичный ML, но возможности его макросистемы позволяют создать диалект достаточно близкий к C#.

AVK>Что самое печальное, вместо того чтобы попытаться как то поправить странности, пусть даже и с потерей некоторой абстрактной стройности концепций (хотя ряд фич там не из за концепций, а просто потому что захотелось так изначальным полякам), на практике мы видим попытки нас убедить, что это наоборот, все зашибись, просто мы не прониклись.
Если странности — это синтаксис "относительно шарпа", то см. выше, иначе надо более развернуто.

AVK>А так я лет 5 назад предлагал взять шарп, выкинуть из него некоторое количество хвостов и косяков, да добавить туда самые вкусные моменты — ПМ, сахарок разный типа того, что отчасти реализовали, отчасти напредлагали в C# 6 и т.п.
Это, имхо, знатное чсв, что можно взять шарп и что-то там убрать или добавить. Шарп делают умнейшие люди, которые ищут локальный максимум в пространстве с осями: обратная совместимость, интероперабельность в рамках CLR/Mono и, конечно, фичи/хотелки. Может, я утрирую, и там еще сложней.

AVK> Тогда, особенно на фоне микроизменений в C# 4 и 5, у языка были бы шансы.
Ну микроядро языка позволяет строить разные языки. То что стандартная библиотека изображает из немерла шарп еще не значит, что это единственный путь развития.

AVK> Немерле нет, никогда не станет существенно популярным, увы.
Популярность Немерле — это примерно как популярность Линукса. С одно стороны ядро, с другой — куча дистрибутивов. Я полагаю, что делая дистрибутив "шарп с плюшками", сложно придти к популярности. Потому что флагман известен, но цели его не ясны, а добежать туда раньше можно только случайно, но и это не гарантирует успеха.

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

DS>- четвертый, что: КАК-ТАК! Здесь же IO

и код не анемичный
DS>Ну и где конструктив?

Претензии были к тому, что невозможно оценить преимущества языка, используя не идиоматичные конструкции. В данном конкретном случае код императивный с побочными эффектами. Для его понимания _необходимо_ прочитать все ветки (неважно, как они организованы и какой там сахар) и внимательно изучить. На мой взгляд, этот пример ничего не демонстрирует.

> код не анемичный
Ну да. После override все остальное читать желания нет — очевидно, что часть контекста "скромно" отсутствует.

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

EP>>В вопросах производительности не имеет особого смысла рассматривать выделение памяти отдельно от освобождения.
VD>А что с ним не так? В средах с GC освобождение памяти бесплатно. Наоборот, платить приходится за живые объекты (временем затрачиваемым на построение графа живых объектов и дефрагментацию кучи).

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

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

Pool это когда есть что-то типа free list'а уже готовых кусочков, и вся аллокация/деаллокация сводится к практически бесплатным pop/push в этот free list.
Ни в Java, ни в .NET, GC и близко не приближается по производительности к Pool'у — отсюда и все эти заморочки с garbage-free и т.п.

EP>>Но да, есть случаи, как уже выше сказал alex_public, где стандартный аллокатор управляемых языков будет быстрее стандартных new/delete C++

VD>Дык стандартный и используются в 99% случаев.

Да, но используются они совершенно по-разному.
В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокация — одна на массив указателей, и по одной на каждый объект.

VD>Разве что межпоточной безопасностью можно пренебречь и выиграть с этого некоторое количество тактов.

Самый быстрый аллокатор это Region/Arena/Zone. Аллокация это просто увеличение счётчика текущей позиции в свободной памяти на выделяемый размер, а деалокации нет, то есть бесплатная.
Опять же, по производительности GC и рядом не стоит с регионами, и разница отнюдь не "некоторое количество тактов" — это как небо и земля.

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

Непонятно о каком общем случае идёт речь — если GC это сферически общий случай, тогда и Region-based — это такой же общий случай.
А если по хорошему — то оба способа хорошо применимы только для определённых сценариев, что мы и видим на практике.

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

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

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

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

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

J>>И всё? А зачем там тогда вообще локальная переменная? Почему нельзя присвоить/поменять поле объекта напрямую?
WH>Это минимальный пример воспроизводящий проблему.
WH>В реальности там может быть намного больше кода. Просто я его не написал, ибо к проблеме он отношения не имеет.
Единственная проблема у этого кода, как он написан сейчас — в том, что он не имеет смысла.
Я не прошу тебя приводить весь код, просто объясни, зачем там вообще нужно создание временного объекта, да еще и в куче? Для чего нужны приседания с локальной переменной (указателем?), если она первой же строчкой уезжает(?) в поле класса?

J>>Плюс поле у тебя, вроде как, по значению хранит объект, а локальная переменная — по указателю в кучу.
J>>Или там везде указатели на самом деле?
WH>В .НЕТ это зависит от типа объекта.
Уволь меня от погружения в тонкости .НЕТ, плиз. Объясни нормальным сиплюсовым языком.

J>>ЗЫ Раз ты знаешь, что такое move-constructor, то ты ведь и про move-assignment тоже, наверняка, знаешь?
WH>Знаю. Но при присвоении одной переменной другой его использовать нельзя.

Вот это новости от знатока. Похоже, ты знаешь о нем что-то не то.

    D d1, d2;
    d2 = std::move(d1);

J>>Ну хз. Мне везет, наверное. К нам один раз только попало такое чудо в команду — его быстро перевели в скрипто-писатели (и при первой же возможности уволили, ессно). Ну так он и на Питоне "с GC и лямбдами" умудрялся так овнокодить, что потом еще пару лет разгребали за ним его скрипты, и они вдруг начинали работать 5 минут вместо 2 часов (серьезно, так и было). Так что, имхо, тут не в языке проблемы обычно. Программер, у которого падают программы на С++, будет генерить глюкалово на любом языке.
WH>У меня пока меленький был тоже падали. Уверен, что и у тебя падали.
Когда я был маленький, я и в таблице умножения путался. Только вот какое это имеет отношение к продакшену, который, вроде как, пилится профессионалами

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

AVK>К сожалению это не так. В Немерле есть много (относительно шарпа) странностей — другие скобки для дженериков, последнее выражение в блоке как return, да даже обязательная необходимоть писать else у if.
Вот, кстати, про if/else. По началу часто натыкался на эти грабли и до сих пор не могу понять, почему нельзя if без else воспринимать как statement, коим сейчас является when. Имхо, when это лишнее ключевое слово.

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

AVK>Ага. Вот еще новое навигационное дерево для rsdn.ru. Тоже практически работает, но есть некоторые нюансы.
AVK>Есть только одна закавыка — я тут сел и за час на голом JS (ок, на TS) написал это проклятущее дерево. Пусть без модных фишек типа запинивания, зато на 100% вписывающееся в существующую серверную инфраструктуру. И, что характерно, никаких "это невозможно в нашей концепции".

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

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

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

VD>Да, несомненно. Если мериться с C#, то кое какая гибкость есть. Правда платить за это приходится массой неудобств и костылей/велосипедов для решения даже базовых задач вроде передачи ссылки на метод или долгоживущих объектов в функцию.

Что конкретно имеется в виду? То что можно использовать библиотеки, там где у C# фичи прибиты в язык гвоздями?

EP>>Обобщённый код (это даже не метапрограммирование) на C++ получается разы короче и проще.
VD>Ну, это преувеличение. Проще писать как раз на C#. C# обладает всегда достаточной гибкость. Но случаи когда ее не хватает не так уж часты.

Даже если из примера с apply убрать переменное число параметров — то на C# всё равно будет много проблем. Пример же в действительности простейший.

VD>У Nemerle же и эти недостатки дотнета компенсируются еще и макросами. Шаблоны C++ можно рассматривать как подмножество макросов Nemerle.

Не уверен что строгое надмножество. Макросы Nemerle живут в отдельной сборке, шаблоны — в том же translation unit что и обычный код.
Результат работы шаблона может зависеть от него самого же. Или другой вариант — действия шаблона зависят от результата функции которая использует этот шаблон. Такая вот особая ~~уличная магия~~мета-рекурсия.
Если абстрактно, то представь что папа Карло (метапрограмма) вырезает из полена Буратино (программа), и ещё не созданный до конца Буратино, помогает вырезать себя же. Какого-то хорошего примера пока не придумал, но думаю что суть ясна.
В случае же Nemerle — макрос даже и сослаться на эту функцию не может, так как нет соответствующей сборки, а появится она когда макрос уже не будет работать.

VD>Вот только это довольно надуманный пример. На практике он мало что дает.

Это самый обычный FP-style.

EP>>И, что-то мне подсказывает, если это и получится на Nemerle, то не так складно, ибо система типов .NET — примитивней

EP>>Ожидаю блаб-объяснений что это и не нужно, потому что можно без этого

VD>Ну, тебе все время что-то подсказывает не верные выводы.

Ты бы лучше меньше слушал бы это что-то.

Как раз хорошая демонстрация того, что я имел в виду.
Вот есть у нас функции, и мы их используем.
Чуть сложнее пример — ок, берём generic'и. Всё практически то же самое — такие же обычные параметры, такой же обычный код.
Ещё чуть сложнее — и вот уже приходится использовать макросы, лезть в отдельную сборку. И параметры уже не параметры, а куски распаренной грамматики, которые нужно сплайсить в код, который кстати тоже уже не код, а квазицитата. И при этом при использовании одного параметра несколько раз, нужно подставлять костыли чтобы он не вычислялся несколько раз и т.д и т.п.
Хотя усложнение — минимальное. Были бы generic'и и система типов мощнее — не пришлось бы лезть в макросы.
Или, например, если нужно вернуть/передать/сохранить этот apply куда-нибудь — тоже начнутся пляски.

Да, язык можно расширять макросами, но была бы основа мощнее и гибче — к этому пришлось бы прибегать реже. Например — вот есть же generic'и — вы же их просто берёте и используете, а не было бы — пришлось бы точно также эмулировать.

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

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

VD>Я не просто так говорю, что Nemerle мощнее C++ и всех остальных мэйнстрим-языков. Я бы не сменил C++ на C#, а потом C# на Nemerle, если бы на то не было бы весомых оснований. Так что лучше пытаться тягаться длинной пенисов (у меня все равно он длиннее окажется

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

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

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

VD>Привлекать мартышек себе дороже.

Не привлекай. Но зачем делать их врагами? Вы ведь уже допиарились до такого состояния, что один наш общий знакомый считает, что первое что нужно сделать для оживления Немерле — переименовать его во что нибудь другое.
Но это еще полбеды. Хуже другое — есть некоторое количество людей, которые могут быть согласны с частью того, что пишет тобою обзываемый. И видя твои обзывания, они тоже начинают воспринимать тебя как неадекватного хама. А в результате имеем что имеем — куче народу не просто пофик на Немерле, они агрессивно против него и создают вам такой антипиар, какой вы пересилить не в состоянии просто в силу существенно меньшего количества сторонников.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

STD>Немерл не является надмножеством шарпа.

Он даже не является надмножеством самой самой основы шарпа. В этом и проблема.

STD>Надо понимать, что ядро Немерле — минималистичный ML

Есть одна проблемка — минималистичный ML нужен только гикам.

STD>, но возможности его макросистемы позволяют создать диалект достаточно близкий к C#.

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

STD>Это, имхо, знатное чсв, что можно взять шарп и что-то там убрать или добавить.

Как любит говорить один старый пользователь RSDN — перешел на личности значит слил.

STD> Шарп делают умнейшие люди

Ты как то извратно все понял. Дело не в неумности тех, кто занимается шарпом. Дело в необходимости обеспечения обратной совместимости даже в мелочах. 100% компилируемость старого кода — строгий императив.

STD>Ну микроядро языка позволяет строить разные языки.

Опять позволяет. Все разговоры в будущем времени.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

I>Не хочу поднимать старый спор, но проблема была не в "это невозможно в нашей концепции"

Это практически точная цитата.

I>а в том, что мы банально не могли договориться о каких-то очевидных вещах.

Ага. К примеру о том что вариант, когда на все приложение может быть строго одно дерево, неприемлем. Потому что не закатывать провайдер дерева в статическое свойство "невозможно в нашей концепции".

I>Преимущества от НемерлеВеб заметны там где нужно более менее сложное взаимодействие. Напишешь ты это дерево за час на НемерлеВеб или за два на яваскрипте, разницы и правда большой нет.

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

J>Я не прошу тебя приводить весь код, просто объясни, зачем там вообще нужно создание временного объекта, да еще и в куче? Для чего нужны приседания с локальной переменной (указателем?), если она первой же строчкой уезжает(?) в поле класса?
Ты вообще читал, на что отвечаешь?
Или ты предпочитаешь чтобы я на тебя сейчас вывалил мегабайт кода в котором без ГЦ вообще не разобраться?

J>Уволь меня от погружения в тонкости .НЕТ, плиз. Объясни нормальным сиплюсовым языком.
Я просто показал в каком месте С++у нужна синхронизация, а .НЕТу нет.

J>

Вот это новости от знатока. Похоже, ты знаешь о нем что-то не то.

Всё я о нём знаю. Переменная d1 в этом случае разрушается.
А это далеко не всегда приемлемо.

J>Когда я был маленький, я и в таблице умножения путался. Только вот какое это имеет отношение к продакшену, который, вроде как, пилится профессионалами

И сколько лет практики должно быть у человека, прежде чем он станет профессионалом?
По моим наблюдениям 5-10 лет в зависимости от таланта.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>Неужели ты считаешь цену ручной оптимизации ASM кода сопоставимой с ценой правильной расстановкой move/copy?
Если задача сложнее чем переливание из пустого в порожнее, то цена может быть весьма существенной.

EP>Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec,
Про то, что они редкие это исключительно твоя спекуляция.

EP>с другой — конкурентная-пакость, которая параллельно основным потокам шарит по их данным и делает какие-то манипуляции, хорошо ещё если lock-free.
Мусорщик запрещает доступ к тем страницам памяти, которые убирает.
При этом саму память освобождает. Зарезервированным остаётся только адресное пространство.
Если кто-то обращается к этим страницам, то происходит аппаратное исключение.
Мусорщик его перехватывает, исправляет указатель на правильный и запускает поток работать дальше.
Все дальнейшие обращения по этому указателю пойдут без всяких накладных расходов.

EP>А хотя бы чем было обусловлено? Какими-то алгоритмическими/прикладными особенностями? Или возможно каким-то interop'ом?
Например был огромный COM сервер.

EP>Нормальный это какой?
EP>В стандарте есть интерфейс для для консервативного GC.
Консервативный ГЦ это хрень полнейшая.

EP>Есть точные GC — но они менее автоматизированные чем консервативные. При использовании точных нужно заменять T* на gc_ptr<T> и т.п. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
Поколения есть?
Память уплотняет?

EP>Хотя бы как тогда разруливается ситуация с IDisposable? Например — один метод поставил using скобки на объект, передал его в другой метод, который втихую сохранил его до лучших времён — в итоге у него окажется ссылка на disposed объект. Фейерверк?
Нет. Обычное исключение.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>В случае же Nemerle — макрос даже и сослаться на эту функцию не может, так как нет соответствующей сборки, а появится она когда макрос уже не будет работать.
Может. И на функции. И на типы. И на всё остальное.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>>В случае же Nemerle — макрос даже и сослаться на эту функцию не может, так как нет соответствующей сборки, а появится она когда макрос уже не будет работать.
WH>Может. И на функции. И на типы. И на всё остальное.

Естественно имелась в виду не просто "forward" ссылка, а именно использование.
Если это доступно — то в двух словах какой механизм?

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

EP>Естественно имелась в виду не просто "forward" ссылка, а именно использование.
EP>Если это доступно — то в двух словах какой механизм?
Это и шаблоны не могут.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

AVK>Здравствуйте, ionoy, Вы писали:
I>>Не хочу поднимать старый спор, но проблема была не в "это невозможно в нашей концепции"
AVK>Это практически точная цитата.
У нас все ходы записаны. Если интересно, можешь посмотреть коммит в котором я удалил все эти твои интерфейсы и вернулся к старому дереву https://github.com/NemerleWeb/NemerleWeb/commit/e1ad68d72b7aac33daa0e762691bbdb80d3a0621

I>>а в том, что мы банально не могли договориться о каких-то очевидных вещах.
AVK>Ага. К примеру о том что вариант, когда на все приложение может быть строго одно дерево, неприемлем. Потому что не закатывать провайдер дерева в статическое свойство "невозможно в нашей концепции".
Это неправда. Такого я сказать не мог, так как наша концепция важна только на стороне клиента, на сервере ты можешь делать всё что угодно.

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

I>>Преимущества от НемерлеВеб заметны там где нужно более менее сложное взаимодействие. Напишешь ты это дерево за час на НемерлеВеб или за два на яваскрипте, разницы и правда большой нет.
AVK>Ладно бы преимущества. Проблема в том, что вы часовую работу растянули на несколько недели, и так ее и не доделали.
Ну да, я два раза по пару часов садился за это время, и в ту самую субботу был готов интегрировать код с твоим.

AVK>Поэтому все эти разговоры о концепциях и будущем лично мне уже окончательно стали неинтересны. Потому что прошло много лет, а там все концепции.
Ещё раз говорю, никаких ограничений в нашей концепции нет и не было. Проблема была в том, что мы друг друга не слышали.

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

EP>>Неужели ты считаешь цену ручной оптимизации ASM кода сопоставимой с ценой правильной расстановкой move/copy?
WH>Если задача сложнее чем переливание из пустого в порожнее, то цена может быть весьма существенной.

Каким образом? Чисто механическое занятие.
Я думаю это дело даже можно частично автоматизировать — если после копии ref-counted куда-то, он больше не использовался — то достаточно move'а.

EP>>Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec,
WH>Про то, что они редкие это исключительно твоя спекуляция.

Конкретный пример где ref-counting действительно к месту:
Есть что-то типа прокси-сервера — данные от первой стороны передаются второй, и от второй — первой. Соответственно имеются два асинхронных цикла, каждый из которых вида "ждём данные, получаем, отправляем, опять ждём и т.д.". У этих "циклов" есть некоторое разделяемое состояние, которое можно освободить по завершении обоих циклов. Причём состояние ещё и передаётся от каждого обработчика к следующему (например от "получаем" к "отправляем").
Какой из циклов завершится раньше заранее не известно, вот тут и требуется ref-counting.
Причём достаточно чтобы счётчик прошёл только следующую последовательность состояний: "1, 2, 1, 0". А вот передёргивать при переходе, например, от состояния "получаем" к "отправляем" — нет никакой необходимости, достаточно move — так как эстафета передаётся.

Как видно из примера, передёргивание счётчика требуется только при: "раздвоении" времени жизни на несколько веток и в конце каждой из этих веток.
Во многих же реальных примерах использования ref-counting которые я видел — развилок времени жизни не много.

WH>Если кто-то обращается к этим страницам, то происходит аппаратное исключение.

И начинается ping-pong кэш-линиями и аппаратными исключениями, не говоря уже о том, что проедется аппаратный поток.

EP>>А хотя бы чем было обусловлено? Какими-то алгоритмическими/прикладными особенностями? Или возможно каким-то interop'ом?
WH>Например был огромный COM сервер.

То есть interop, а не какая-то алгоритмическая/прикладная задача. Причём если брать ref-counting обусловленный чисто interop'ом, а не алгоритмическими особенностями — то и реальных передёргиваний счётчика требуется минимум.
Причём при interop'е в стиле COM, подсчёт ссылок нужен только в интерфейсе с внешним миром, а не внутри всего кода.

EP>>Нормальный это какой?
EP>>В стандарте есть интерфейс для для консервативного GC.
WH>Консервативный ГЦ это хрень полнейшая.

У него есть своя область применения

WH>Память уплотняет?

Раз он точный, то память уплотнить (и обновить указатели) не проблема, но ограничения определённые есть. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.

WH>Поколения есть?

Тоже не вижу проблемы.

EP>>Хотя бы как тогда разруливается ситуация с IDisposable? Например — один метод поставил using скобки на объект, передал его в другой метод, который втихую сохранил его до лучших времён — в итоге у него окажется ссылка на disposed объект. Фейерверк?
WH>Нет. Обычное исключение.

Но доступность-то не гарантированна, значит нет надёжности

А вот что в случае бага вылетит — AV или исключение — рояли не играет. Баг есть баг.
Грубо говорят если из-за бага в алгоритме он вышел за пределы диапазона, но кинул исключение — работу свою он не выполнил, постусловий не достиг, перевёл программу в неопределённое состояние.

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

EP>Каким образом? Чисто механическое занятие.
Полировка асма тоже чисто механическое занятие.

EP>Конкретный пример где ref-counting действительно к месту:
Это очень простая задача.

WH>>Если кто-то обращается к этим страницам, то происходит аппаратное исключение.
EP>И начинается ping-pong кэш-линиями и аппаратными исключениями, не говоря уже о том, что проедется аппаратный поток.
Только происходит это не каждый раз. А если не повезёт и мутатор столкнется с мусорщиком.

WH>>Например был огромный COM сервер.
EP>То есть interop, ...
Экстраполяция из точки. Там было очень много чего намешано.

WH>>Консервативный ГЦ это хрень полнейшая.
EP>У него есть своя область применения

Нет. Совсем нет.
Либо точный. Либо без ГЦ вообще.

WH>>Память уплотняет?
EP>Раз он точный, то память уплотнить (и обновить указатели) не проблема, но ограничения определённые есть. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
Это в С++ то? А если в объекте, которым управляет мусорщик, есть поле с объектом, который двигать нельзя?

WH>>Поколения есть?
EP>Тоже не вижу проблемы.
Не видишь или есть?

EP>Грубо говорят если из-за бага в алгоритме он вышел за пределы диапазона, но кинул исключение — работу свою он не выполнил, постусловий не достиг, перевёл программу в неопределённое состояние.
Нет. Программу в неопределенное состояние переводит тихий проезд по памяти.
А вот после нормального исключения можно легко восстановиться.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

VD>Дык стандартный и используются в 99% случаев. Для отдельных задач конечно можно создать более быстрые решения, но в общем случае они не работают. Разве что межпоточной безопасностью можно пренебречь и выиграть с этого некоторое количество тактов.

Да, только я там же указал, что на большинстве задач стандартные средства C++ заметно превосходят стандартные средства Java/C#.

VD>Я не просто так говорю, что Nemerle мощнее C++ и всех остальных мэйнстрим-языков. Я бы не сменил C++ на C#, а потом C# на Nemerle, если бы на то не было бы весомых оснований. Так что лучше пытаться тягаться длинной пенисов (у меня все равно он длиннее окажется

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

Какие интересные вещи открываются... Ну т.е. я вполне понял был эволюцию C++ -> Nemerle, т.к. здесь мы в обмен на кучу проблем .net'a получаем взамен крутое метапрограммирование. Конечно не все на такое согласятся, но любители МП точно. Однако, добровольный переход C++ -> C# для любителя МП вообще не мыслим, т.к. в C# в этом смысле полная пустота. А ты говоришь что когда-то так перешёл...Т.е. или у тебя раздвоение личности, то ли ты где-то не честен.

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

AVK>> Немерле нет, никогда не станет существенно популярным, увы.
STD>Популярность Немерле — это примерно как популярность Линукса. С одно стороны ядро, с другой — куча дистрибутивов. Я полагаю, что делая дистрибутив "шарп с плюшками", сложно придти к популярности. Потому что флагман известен, но цели его не ясны, а добежать туда раньше можно только случайно, но и это не гарантирует успеха.

Сомнительное сравнение, т.к. Линух уже является явным лидером в нескольких областях. А у Немерле пока что нет ни одной такой области.

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

VD>>Привлекать мартышек себе дороже.

AVK>Не привлекай. Но зачем делать их врагами?

Проблема в том, что они в принципе враги. Времени у них много, а мозга мало. Флэймы создают именно они. Спорить с мартышкой бесполезно. Она все равно заявит, что проку с ваших очков нет, так как она попробовала и проку на не нашла (а зачастую и заочно осудила).

Развенчивать кучу домыслов и высосанных из пальца ИМХО — это дело очень не благодарное. Я долгое время пытался, но потом понял, что это сизифов труд. Возможно поняв, что люди ведут себя как мартышка из басни рефлексируют и начнут мыслить конструктивно. Ну, а если не начнут — это их проблемы.

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

Я такие мнения слышал с самого начала.

AVK>Но это еще полбеды. Хуже другое — есть некоторое количество людей, которые могут быть согласны с частью того, что пишет тобою обзываемый.

То есть есть люди которые тоже по сути ведут себя как мартышки?

Или речь о вменяемых аргументах? Дык с ними никто и спорить не собирается. Если есть недостатки или спорные моменты их можно обсуждать. Здоровая критика полезна.

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

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

AVK>А в результате имеем что имеем — куче народу не просто пофик на Немерле, они агрессивно против него и создают вам такой антипиар, какой вы пересилить не в состоянии просто в силу существенно меньшего количества сторонников.

Куче народа по фиг, да. Но они не шляются по форумам и не пытаются налить дерма на то что им по фиг. Я как бы сам профан во многих вещах. Но я не хожу и не критикую Агду или там Бугати Веерон просто на том основании, что не вижу в них толку.

Это явление малость под утомило. Мартышек много и они активны. Ответить на все глупости которые они говорят не хватит и всей жизни. Проводить остаток жизни в споре с ними нет никакого желания.

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

_>Да, только я там же указал, что на большинстве задач стандартные средства C++ заметно превосходят стандартные средства Java/C#.

В это главное верить. Иначе тяжело себе объяснить зачем МС переписывает свои компиляторы и IDE на дотнете.

_>Какие интересные вещи открываются... Ну т.е. я вполне понял был эволюцию C++ -> Nemerle, т.к. здесь мы в обмен на кучу проблем .net'a получаем взамен крутое метапрограммирование. Конечно не все на такое согласятся, но любители МП точно. Однако, добровольный переход C++ -> C# для любителя МП вообще не мыслим, т.к. в C# в этом смысле полная пустота. А ты говоришь что когда-то так перешёл...Т.е. или у тебя раздвоение личности, то ли ты где-то не честен.

Из МП в Шарпе действительно не густо. Разве что внешние средства и куцие встроенные ДСЛ-и. Но как язык он в разы удобнее С++. Немерл же это квинтесенция удобства и простоты шарпа и возможностей МП сильно превосходящих С++.

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

J>Т.е. смотри — у меня не падает, у тебя не падает, у Евгения не падает, у еще доброго десятка С++ программеров в соответствующем форуме тоже не падает. Но стоит теме С++ всплыть в форуму по Немерле — и всё начинает падать, аки перезрелый виноград.

Ну, вы же все тут герои. А у Майкрософт падает. Вот они и переписывают убер-С++-код на Шарпе. Глупцы! Надо было на форум по С++ зайти

.

У меня вот тоже софт падает. Я не идеален. И лишний геморрой мне тоже не нужен. Потому я засунул С++ куда по дальше. Пишу на языке в разы мощнее и наслаждаюсь процессом. А вы давайте еще пенсами по меряйтесь. Глядишь поможет.

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

EP>Если прям стоит задача минимизировать лишние передёргивания, то можно запретить неявные копии и оставить только явные move или copy — в любой непонятной ситуации компилятор будет задавать вопрос.

Первый вопрос задам я. Зачем мне этот геморрой?

EP>Baby-sitting'а нет, откуда вытекает мощность с одной стороны, и возможность делать плохие вещи с другой.

Зачем мне "возможность делать плохие вещи"?

EP>При этом не отрицаю что есть некоторые задачи где время жизни определяется внешними факторами. А иногда даже таким способом, что возможны жёсткие циклы в графе зависимостей.

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

EP>P.S. Кстати, а есть ли готовая возможность в Nemerle для освобождения ресурса, как только все ссылки на него выйдут из scope? using'и или их аналоги тут не особо помогают:...

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

У С++-ников вообще пунктик на освобождении ресурсов, так как половина багов именно при этом возникает. В реальности когда единственным ресурсом в программе становится фал, то в большинстве случаев его тупо читают залпом на месте. Чай не 1990-й год, и памяти не 640 Кб. А память вообще не ресурс. Она сама и освободиться когда перестанет быть кому-то нужна.

Но вам чего-то объяснить невозможно, так как вы как флюс. Полнота ваша односторонняя. Знаете много, но в одной области. Хотя, казалось бы, достаточно пописать на Яве или Дотнете с пол годика и все фобии уходят.

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

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

_>Собственно ничего. Ну или с другой стороны всё, но в таком случае оно и к C# относится (у нас же там имеется unsafe, не так ли?).

В unsafe чтобы получить доступ к управляемой памяти ее сначала нужно запинить. Запиненый объект точно не передвинится. Это конечно не гарантия, но все же. При выходе управления в неуправляемый мир сборка мусора невозможно, а значит ничего не испортится. Так что все сильно безопаснее. Хотя unsafe есть unsafe. Ну, и применяется unsafe крайне редко. Лично я только баловался с ним.

У нас есть одна задачка в которой unsafe должен дать хорошие результаты, но там весь код генерированный и unsafe не так уж и страшен. Ошибки не придется искать по тонне кода. Дополируем алгоритмы, попробуем unsafe. Потом можно будет сказать, что это дает в реальном применении.

_>Для начала тогда уж std::atomic, а не эта хрень из win api.

Это важное уточнение

.

_>Ну а потом собственно причём тут это? Мы говори о нулевом оверхеде неких абстракций.

Как оверхэд может быть нулевым, если есть конструкторы, деструкторы и, тем более, подсчет ссылок?

_>А здесь у нас совсем не абстракция, а прямая функциональность — синхронизация. Так что само понятие оверхед тут не применимо, т.к. ресурсы тратятся не на реализацию абстракции, а на "дело". Ну или ты хочешь сказать, что можешь привести случаи, когда в C++ синхронизация нужна, а в том же случае в C# не нужна? )

Как бы оверхэд есть оверхэд. В управляемом мире при копировании ссылок никаких затрат нет. Просто указатель переезжает в другую область памяти. Синхронизация если и есть, то только при выделении памяти (для сдвижки указателя хипа), или нет вообще, так как хип локален для потока.

Про освобождение вообще говорить не чего. Для ЖЦ-объекта понятие "освобождение" нет в принципе. Нет ссылок — значит умер.

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

AVK>К сожалению это не так. В Немерле есть много (относительно шарпа) странностей — другие скобки для дженериков, последнее выражение в блоке как return, да даже обязательная необходимоть писать else у if. Каждая по отдельность проблемочка — яйца выеденного не стоит, но в комплексе оно все делает язык довольно далеко отстоящим от шарпа.
AVK>Что самое печальное, вместо того чтобы попытаться как то поправить странности, пусть даже и с потерей некоторой абстрактной стройности концепций (хотя ряд фич там не из за концепций, а просто потому что захотелось так изначальным полякам), на практике мы видим попытки нас убедить, что это наоборот, все зашибись, просто мы не прониклись.

Я согласен, что отличия препятствуют осваивать язык тем кто не готов потратить неделю-другую на освоение этих "начальных" (я бы их так назвал) отличий. Но эти отличия в основном не просто так. Что-то действительно удобнее. Тот же отсутствие ретурна — это маленький кусочек реализации концепции "все является выражением". Эта концепция во многом очень удобна. Но осзнавать это начинаешь только пройдя этот двухнедельный курс въезжания.

Квадратные скобки в дженериках — это скорее слабость технологий на которых сделан Немерл. У поляков просто не хватило скилов справиться с неоднозначностями вызваемыми треугольными скобками. Первые версии Немерла были с треугольными скобками, но потом от них отказались в пользу квадратных, из-за глюков в парсере вызванных неоднозначностью. Была бы тогда Найтра, проблема просто не возникла бы.

AVK>А так я лет 5 назад предлагал взять шарп, выкинуть из него некоторое количество хвостов и косяков, да добавить туда самые вкусные моменты — ПМ, сахарок разный типа того, что отчасти реализовали, отчасти напредлагали в C# 6 и т.п. Тогда, особенно на фоне микроизменений в C# 4 и 5, у языка были бы шансы. А Немерле нет, никогда не станет существенно популярным, увы.

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

Следующую версию Немерла мы напишем с использованем Найтры. Это позволит тупо сделать два языка. Один — потом немерла со всеми его "странностями", а другой — потомок шарпа. Кстати, грамматика Шарпа у нас уже есть.

Кстати, Немерл умеет компилировать шарпный код (точнее немерл с синтаксисом шарпа). Там много чего нет, но главное — возможность использовать макросы — есть. К сожалению при этом нет интеллисенса. Так что решение ограниченное. Мы его используем, в основном, когда нужно скопировать имеющийся шарпный код. Например, NounUtil.cs из немерлового проекта.

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

I>Вот, кстати, про if/else. По началу часто натыкался на эти грабли и до сих пор не могу понять, почему нельзя if без else воспринимать как statement, коим сейчас является when. Имхо, when это лишнее ключевое слово.

Дык, нет стетментов в Немерле.

Стейтментом можно назвать то, что имеет тип void. Но в процессе парсинга типов еще нет. По сему получается неоднозначность.

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

AVK>Сорри что встреваю, но вот как раз что то количество коммитов совсем не впечатляет.

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

Будешее Немерла в Найтре. Сколько коммитов в ней можешь так же посмотреть. Мы сделали уже треть коммитов от всех коммитов Немерла, хотя нас на проекте трое, а над Немерлом работало 50 человек, в разное время. И проект немерла старше на 6 лет.

Плюс все зависит от стиля. Вольфхаунд у нас может месяц не комитить ни фига. Не скажу, что это хоршо. Но это факт.

Буквально сегодня Хардкейс пофиксил макро-визард, который как оказалось отвалился в одном из прошлых релизов.

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

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

J>>Т.е. смотри — у меня не падает, у тебя не падает, у Евгения не падает, у еще доброго десятка С++ программеров в соответствующем форуме тоже не падает. Но стоит теме С++ всплыть в форуму по Немерле — и всё начинает падать, аки перезрелый виноград.

VD>Ну, вы же все тут герои. А у Майкрософт падает. Вот они и переписывают убер-С++-код на Шарпе. Глупцы! Надо было на форум по С++ зайти

.

VD>У меня вот тоже софт падает. Я не идеален. И лишний геморрой мне тоже не нужен. Потому я засунул С++ куда по дальше. Пишу на языке в разы мощнее и наслаждаюсь процессом. А вы давайте еще пенсами по меряйтесь. Глядишь поможет.

И что б мы без тебя, Влад, делали

Совсем со скуки померли бы

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

EP>Бесплатное освобождение это когда ничего не нужно ни перемещать, ни бегать по развесистым графам, ни мир останавливать.
EP>То есть кроме выделения не производится абсолютно никаких операций.

Дык при освобождении ничего и не делается. Точнее даже самого освобождения нет. По графам бегают в других потоках. При этом остальные потоки не останавливаются. И мертвых объектов в этом графе нет. Мир останавливается не всегда. Есть конкурентные GC. А те что останавливают, делают это на очень короткие промежутки времени и исключительно для дефрагментации памяти, о которой в С++ даже мечтать нельзя.

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

EP>Pool это когда есть что-то типа free list'а уже готовых кусочков, и вся аллокация/деаллокация сводится к практически бесплатным pop/push в этот free list.
EP>Ни в Java, ни в .NET, GC и близко не приближается по производительности к Pool'у — отсюда и все эти заморочки с garbage-free и т.п.

Ох, ох, ох. Еще один спорщик черпающий знания перед ответом в Википедии. Ты все напутал. Free list — это как раз простейший алгоритм используемый в С-шных/С++-ных менеджерах памяти. Именно он вызывает фрагментацию хипов и тормоза.

Пул же это когда память выделяется большим блоком (пулом) и нарезается для конкретных нужд. Ты ниже это назвал Region-based. Free list же не имеет к нему никакого отношения. Это всего лишь тупой и тормозной алгоритм из дремучих веков.

А вот в GC используют Region-based (если тебе так понятнее) принцип. Выделение памяти в GC — это всего лишь увеличение указателя на начало свободной памяти в хипе. Освобождение вообще не просходит.

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

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

Дефрагментация и тем более обход графа обычно идут в параллельных потоках. Учитывая, что голов у современных процессоров довольно много, это не сильно напрягает рабочие потоки.

Быстрее, как я уже говорил, только пулы (Region-based, если тебе так угодно) которые создаются под группу объектов которые имеют одинаковый срок жизни. При этом можно уничтожить весь пул, а не возиться с каждый отдельным объектом.

Но тут есть ряд проблем. Не все алгоритмы позволяют использовать такой подход. Нужно знать каков максимальный объем пула потребуется алгоритму. Малейшая ошибка может привести к работе с освобожденной памятью. В GC же этих проблем не существует.

По жизни в С++, если нужно строить графы объектов, обычно используют обычную кучу и один из способов полуавтоматического управления памятью (смартуказатели со стратегиями владения или подсчет ссылок). Например, в броузерах обычно используется именно подсчет ссылок. Причем идет тенденция к переходу на GC.

EP>Да, но используются они совершенно по-разному.
EP>В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокация — одна на массив указателей, и по одной на каждый объект.

Ну, это явное заблуждение. В Шарпе (точнее в дотнете) есть варианты. Можно создать структуру и она будет точно так же размещена в массиве. Мы частенько пользуемся таким подходом. К сожалению этот подход не работает, если речь идет о графах объектов. Тут только ссылки.

EP>Самый быстрый аллокатор это Region/Arena/Zone. Аллокация это просто увеличение счётчика текущей позиции в свободной памяти на выделяемый размер, а деалокации нет, то есть бесплатная.
EP>Опять же, по производительности GC и рядом не стоит с регионами, и разница отнюдь не "некоторое количество тактов" — это как небо и земля.

Очень смешно. Я тебя расстрою. В GC именно так память и выделяется. Разве что интерлок используется, для потокобезопасности.

Region-based (он же пул) без сборки мусора — это очень специфичная штука подходящая не очень часто. По крайней мере я за всю жизнь видел пару применений этого подхода. Собственно повторяться не буду, так как говорил об этом выше.

Так что, как говорится, не учи отца ... делать детей.

Ты наверно еще в школу ходил, когда я делал реально универсальные "самые быстрые в мире"

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

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

И я точно знаю, что грамотно написанные дотнет-приложения отстают от аналогичных С++-приложений очень незначительно и виной тому слабые оптимизации компиляторов, а отнюдь не GC. Есть приложения в которых сборка мусора становится узким местом, но это скорее алгоритмическая проблема. Она бы вылезла и в С++.

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

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

EP>Непонятно о каком общем случае идёт речь — если GC это сферически общий случай, тогда и Region-based — это такой же общий случай.
EP>А если по хорошему — то оба способа хорошо применимы только для определённых сценариев, что мы и видим на практике.

GC — это общее решение автоматического проблемы управления памятью. Она тебе просто перестает волновать. Нужно помнить только то, что не стоит складывать все выделенные объекты в динамический массив ссылка на который помещена в статическую переменную

.

Основан он на том же пуле. Люди не одну плешь себе на темени проели стараясь сделать GC более быстрым и не делающим заметных задержек программы (что намного сложнее нежели просто быстрый).

Обогнать его могут далеко не только лишь все (ц). А вот накосячить управляя памятью вручную может каждый. Чтобы это не случилось люди используют разные техники вроде смартпоинтров, что выливается в накладные расходы сравнимые с райт-берьерами в GC. Подсчет ссылок обычно более медленный механизм нежели GC. Если бы это было не так, то GC и строили на базе подсчета ссылок, так как реализация этого способа элементарна.

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

J>И что б мы без тебя, Влад, делали

Совсем со скуки померли бы

Да вы тут совсем пенсами замедлись бы. Все, блин, эксперты один экспертнее другого. Вот учите плюсам человека который в плюсах собак по больше вашего съел.

Старайтесь! Это повышает ЧСВ!

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

_>Да, только я там же указал, что на большинстве задач стандартные средства C++ заметно превосходят стандартные средства Java/C#.

Это языком если. А на практике плюсовый код все чаще переписывается на Явах с Дотнетами, а плюсовый выкидывается. У плюсов остаются только ниши где за производительность можно заплатить очень дорого, так как затраты на разработку не соизмеримы с доходами. Но это удел высокотиражного софта вроде ОС, офисных приложений и игр-блокбастеров. Ну, еще ниши где управляемые языки не применимы (драва, например). В остальных же процесс перехода на более безопасные языки идет полным ходом. Люди даже тормозной Питон используют лишь бы с плюсами не связываться. Хотя тебя послушать, так питон отдыхает.

Вот ты над чем на работе работаешь?

_>Какие интересные вещи открываются... Ну т.е. я вполне понял был эволюцию C++ -> Nemerle, т.к. здесь мы в обмен на кучу проблем .net'a получаем взамен крутое метапрограммирование. Конечно не все на такое согласятся, но любители МП точно. Однако, добровольный переход C++ -> C# для любителя МП вообще не мыслим, т.к. в C# в этом смысле полная пустота. А ты говоришь что когда-то так перешёл...Т.е. или у тебя раздвоение личности, то ли ты где-то не честен.

Очнись. Переход с С++ на C# шел все прошлое десятилетие. В MS VS объем С++ кода сократился со 100%, то 20. А в скором времени и его не станет.

Уже легвидж сервесы для С++ пишут на C#.

Я как бы не в восторге от того, что в C# нет даже тех возможностей МП, как в С++. Но это не значит, что у Шарпа нет других преимуществ по сравнению с плюсами.

Скорость разработки на C# и С++ одного разработчика разная. И эта разница, не смотря на отсутствие МП, не в пользу С++.

Плюсы развиваются очень медленно и получается это очень криво. На лямбды без слез не взглянешь. Понять код на новязе становится сложно даже тем, кто до этого 10 лет писал на функциональных языках.

Кучу полезных вещей (например, концепты) до сих пор не включили в стандарт (и компиляторы), хотя мы их обсуждали здесь еще 10 лет назад. Качество диагностики компилятора на уровне плинтуса. Приличной альтернативы рефлексии та же нет (хотя так же обсуждали 10 лет назад).

По уму нужно было перейти на новый найтивный язык вроде Ди. Но все носятся вокруг этого пристарелого С++ с писаной торбой и норовят померяться пенисами в каких-то там мелочах.

C# — это банально более продуманный и последовательный язык с автоматическим управлением памятью на котором проще писать. Проще и все тут. Достаточно попробовать написать несколько приложений и вопрос отпадет сам собой.

Как бы хаять С++ нет желания. Его используют и будут использовать. У него есть свои ниши. Но и превозносить его тоже не стоит. У языка куча недостатков которые уже вряд ли можно исправить.

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

I>>Вот, кстати, про if/else. По началу часто натыкался на эти грабли и до сих пор не могу понять, почему нельзя if без else воспринимать как statement, коим сейчас является when. Имхо, when это лишнее ключевое слово.

VD>Дык, нет стетментов в Немерле.

Стейтментом можно назвать то, что имеет тип void. Но в процессе парсинга типов еще нет. По сему получается неоднозначность.

Ну мы ведь можем понять, что when возвращает void, даже не типизируя его. То же самое с "a = b". Почему нельзя добавить PExpr.IfStatement или что-то вроде него?

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

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

I>>>Вот, кстати, про if/else. По началу часто натыкался на эти грабли и до сих пор не могу понять, почему нельзя if без else воспринимать как statement, коим сейчас является when. Имхо, when это лишнее ключевое слово.

VD>>Дык, нет стетментов в Немерле.

Стейтментом можно назвать то, что имеет тип void. Но в процессе парсинга типов еще нет. По сему получается неоднозначность.

I>Ну мы ведь можем понять, что when возвращает void, даже не типизируя его. То же самое с "a = b". Почему нельзя добавить PExpr.IfStatement или что-то вроде него?

Позволю себе вмешаться...

Вам же объяснили, что there ain't no such thing as a statement. Рассуждения Влада за "выражения, возвращающие void", это, имхо, попытка говорить на понятном Вам языке. Что вас, похоже, только ещё более запутывает.

"Всё есть выражение" — это махровый ФЯ принцип. И то, что Nemerle его последовательно придерживается — это круто. Имхо, конечно. Правило последнего выражения – из той же оперы, кстати.

Я не знаю, какой тип у _выражения_ a = b. На мой весьма извращенный ФЯ взгляд, логично бы было возвращать значение b приведенное к типу a... но, даже если в действительности возвращается void — это все равно выражение, со всеми вытекающими

. Не настолько полезное, конечно, как в первом случае, но, тем не менее.

И таки да — when — это тоже выражение, которое — в отличие от if/else — _всегда_ возвращает void. Макрос, как я понял по форуму, введен как раз для «облегчения страданий».

Чисто теоретически, наверное, можно (не специалист, ибо) объявить else часть в макросе if опциональной. И «переписывать» его в зависимости от. Просто, это приведет к еще большим «непоняткам». В одном случае у вас будет возвращаться результат последнего выражения в блоке… в другом – «прибитый гвоздями» void. Область применения этих выражений (if и if/else) окажется разной, от слова совсем. А вот «на глаз» будет уже не отличить.

И вот оно действительно надо вам?!

---
С уважением, Константин Сиваков

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

VD>На, вот, открой для себя продукт написанный на языке-трупе.

Ни́тра (словацк. Nitra, нем. Neutra), пятый по численности населения город в западной Словакии, ...
Сколько человек использует продукт?

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

VD>>>Дык, нет стетментов в Немерле.

Стейтментом можно назвать то, что имеет тип void. Но в процессе парсинга типов еще нет. По сему получается неоднозначность.

I>>Ну мы ведь можем понять, что when возвращает void, даже не типизируя его. То же самое с "a = b". Почему нельзя добавить PExpr.IfStatement или что-то вроде него?

G>Позволю себе вмешаться...

G>Вам же объяснили, что there ain't no such thing as a statement. Рассуждения Влада за "выражения, возвращающие void", это, имхо, попытка говорить на понятном Вам языке. Что вас, похоже, только ещё более запутывает.

Мне кажется, это семантика. Если в Немерле тип void фактически невозможно использовать, то почему бы не называть выражения его возвращающие — statement. Хотя если это настолько некорректно, то могу писать void-выражения, мне не сложно.

G> Чисто теоретически, наверное, можно (не специалист, ибо) объявить else часть в макросе if опциональной. И «переписывать» его в зависимости от. Просто, это приведет к еще большим «непоняткам». В одном случае у вас будет возвращаться результат последнего выражения в блоке… в другом – «прибитый гвоздями» void. Область применения этих выражений (if и if/else) окажется разной, от слова совсем. А вот «на глаз» будет уже не отличить.

По моему вполне логично, что if без else никоим образом не может вернуть результат. То что под капотом if/else будет кардинально отличаться от just-if, не означает что люди будут в чём-то путаться. Между прочим компилятор подсказывает, когда значение выражения не было использовано.

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

AM>Мартину Одерски на Scala предоставили грант 2,3 миллиона, на который он основал коммерческую контору Typesafe по поддержке Scala.
AM>Вот тогда новый язык и выстрелил. Хотя пилили скалу еще с 2001 года.

AM>Вобщем, немерле нужно больше золота и пиара.

Под Windows (only) нужно внимание Microsoft.

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

G>>Вам же объяснили, что there ain't no such thing as a statement. Рассуждения Влада за "выражения, возвращающие void", это, имхо, попытка говорить на понятном Вам языке. Что вас, похоже, только ещё более запутывает.

I>Мне кажется, это семантика. Если в Немерле тип void фактически невозможно использовать, то почему бы не называть выражения его возвращающие — statement. Хотя если это настолько некорректно, то могу писать void-выражения, мне не сложно.

Ну в какой-то мере, все вокруг — вопрос семантики. Называть выражение, возращающее void — statement, это как называть ф-цию возвращающую void — процедурой. Там где, это действительно имеет значение, эти два понятия (ф-ция и процедура) явным образом разделяют. Ну т.е. называть-то, конечно вы можете что угодно, и как угодно. Но, ясности это вам сильно вряд ли прибавит.

Смысл принципа — "всё есть выражение", если "на пальцах" — позволить вам весьма свободно эти самые выражения комбинировать. А это, в свою очередь, позволяет огранизовать вычисление таким образом, что бы т.н. side-effect... ну, если уж не избежать его совсем, то, уж сильно его минимизировать, так сказать, количественно

Ну а как только у вас появляются "процедуры" (сиречь, statement), вы такой свободы лишаетесь автоматом. Скатываетесь в императив, т.с.

G>> Чисто теоретически, наверное, можно (не специалист, ибо) объявить else часть в макросе if опциональной. И «переписывать» его в зависимости от. Просто, это приведет к еще большим «непоняткам». В одном случае у вас будет возвращаться результат последнего выражения в блоке… в другом – «прибитый гвоздями» void. Область применения этих выражений (if и if/else) окажется разной, от слова совсем. А вот «на глаз» будет уже не отличить.

I>По моему вполне логично, что if без else никоим образом не может вернуть результат.

Тут вы ошибаетесь. Идеологически, ничто не запрещает сделать так, что бы при вычислении предиката в false и отсутсвии альтернатив, "результатом" вычисления становился какой-нибудь NoMatchException.
Правда, в том варианте, в котором if[/else] существует сейчас, в этом мало слысла. Но, насколько я понимаю, никто нам не запрещает "нафантазировать" if, например, в стиле à la erlang

Будет ли он ценен? Возможно. Но, семантически, он совершенно точно будет отличаться от "just-if". Хотя, и будет выглядеть так же.

I>То что под капотом if/else будет кардинально отличаться от just-if, не означает что люди будут в чём-то путаться.

Еще раз... сейчас вы "не путаетесь" по одной простой причине. В C# if, что с else, что без — императив. Т.е. разницы нет. Когда разница есть — тернарный оператор, например — никто в здавом уме не делает его не отличимым от.

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

А это-то тут вообще причем?!

---
С уважением, Константин Сиваков

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

G>...

У меня такое ощущение, что мы с вами не Немерле обсуждаем, а некий абстрактный язык.
Конкретно в Немерле, для программиста, "when" и "a = b" ничем не отличается от statement. Зачем вы мне рассказываете про "всё есть выражение"? Я прекрасно понимаю почему это хорошо и как оно работает.

if без else, возвращающий void вызовет значительно меньше удивлений, чем текущее положение дел. Я почти уверен, что абсолютно все без исключения, кто работал с Немерле, хоть раз, но писали по привычке if (...) DoSomething() и удивлялись, в чём ошибка.

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

VD>Да ладно себя обманывать! Если бы это было так, то весь мир ел бы мороженое саратовской фабрики, а не Nestle (которое и мороженым то назвать нельзя).
VD>Как язык Немерл в разы лучше того же Шарпа. И задачи он позволят решать намного удобнее и лучше конкурентов. Оценка рисков это чисто субъективный процесс, так что при некотором объеме предвзятости риски будут всегда выше любых разумных соображений.
VD>Миром рулит бабло и пиар (он же пропаганда). По сему куча более качественных вещей остаются невостребованными. Менять мир довольно бесперспективно. Так что если хочется продвинуть язык, то нужно сделать его качественную реализацию и пиарить его всеми имеющимися средствами.
VD>Мы сейчас работаем над первой задачей. Nitra — это тул необходимый для качественной реализации современного расширяемого языка. Мы пытаемся сделать Нитру настолько качественной и гибкой насколько это возможно. Для команды из трех человек это довольно объемная задача.

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

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

Очевидно, что только идиот(ну либо фанат в собственном стартапе) начнет серьезную коммерческую разработку на языке который пилят 3 человека в мире. А значит есть всего два варианта: бабло или комьюнити. Бабла нет. Что остается?

А чтобы создать комьюнити надо сделать всего-то несколько шагов:
1. перестать хамить в ответ на вопрос "а что я получу если начну использовать Немерле".
2. начать отвечать, но не в стиле "сможешь писать супер дсл, вот иди читай вон тот трехтомник". А отвечать так, как способна оценить целевая аудитория. Вот что получит конкретный Вася, который на досуге пилит какой-нибудь несложный проектик для себя? У него нет и не будет дсл и прочей зауми. Ему надо удобный UI, немного стандартной обвязки типа логгинга и набор стандартных либ. Все это в том или ином виде у него есть в шарпе. Ну так продайте ему что-то еще. Но именно продайте, а не расскажите, что он идиот, раз не использует макросы.

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

G>>...

I>У меня такое ощущение, что мы с вами не Немерле обсуждаем, а некий абстрактный язык.
I>Конкретно в Немерле, для программиста, "when" и "a = b" ничем не отличается от statement. Зачем вы мне рассказываете про "всё есть выражение"? Я прекрасно понимаю почему это хорошо и как оно работает.

Я действительно не спец. в Nemerle. Но, если по вашему — ничем не отличается — значит, не все вы понимаете.

Я еще могу согласится с тем, что в подавляющем большинстве случаев вычисление выражения в void лишает выражение "смысла", т.с. Но, в statement из-за этого это выражение не превращается. Унарные операторы — тоже, например, вычисляются в void... при этом, какой-никакой а "смысл" как выражения они имеют. При этом, судя по коду, например, в макрос for в качестве change вполне может быть передано выражение a = b и даже when

Есть или нет в этом "смысл" — разговор отдельный. Но, если бы это был statement такое просто было бы не возможно... пришлось бы в лямбду "заворачивать".

I>if без else, возвращающий void вызовет значительно меньше удивлений, чем текущее положение дел. Я почти уверен, что абсолютно все без исключения, кто работал с Немерле, хоть раз, но писали по привычке if (...) DoSomething() и удивлялись, в чём ошибка.

Слушайте... ня что-то не понимаю, наверное

Но, вы действительно считаете, что "удивления" за "wtf?! закоментил else — перестало собираться" — лучше?! Или — возвращаясь к C# — то, что там тернарный оператор не похож на — есть "бяда-бяда"?!

Ну привыкли вы к имеративу. Понятно всё. Ворчать-то чего?!

---
С уважением, Константин Сиваков

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

EP>>Бесплатное освобождение это когда ничего не нужно ни перемещать, ни бегать по развесистым графам, ни мир останавливать.
EP>>То есть кроме выделения не производится абсолютно никаких операций.
VD>Дык при освобождении ничего и не делается. Точнее даже самого освобождения нет. По графам бегают в других потоках.

Это и есть цена освобождения. Если ты за освобождение считаешь что-то другое — то ок, но это вопрос терминологический и ничего не меняющий. Медленный этап всё равно остаётся как ты его не назови — "освобождение" или "генеральная уборка мусора, для доступа к пространству им занимаемым".

EP>>Pool это когда есть что-то типа free list'а уже готовых кусочков, и вся аллокация/деаллокация сводится к практически бесплатным pop/push в этот free list.
EP>>Ни в Java, ни в .NET, GC и близко не приближается по производительности к Pool'у — отсюда и все эти заморочки с garbage-free и т.п.
VD>Ох, ох, ох. Еще один спорщик черпающий знания перед ответом в Википедии.

Ссылку я дал тебе дабы избежать путаницу, так как название не всем знакомое (и по его виду можно не понять что это специальный термин), но ты всё равно запутался

Потрать хоть минуту, открой ссылку, и прочитай что там написано — иначе конструктивная дискуссия невозможна, так как ты понимаешь free list как-то по-своему.

VD>Ты все напутал. Free list — это как раз простейший алгоритм используемый в С-шных/С++-ных менеджерах памяти.

Это ты всё напутал. Free list это вообще не алгоритм.

VD>Именно он вызывает фрагментацию хипов и тормоза.

При использовании free list'а как основы пула объектов — вешняя фрагментация всегда нулевая, а внутренняя нулевая почти всегда

VD>Пул же это когда память выделяется большим блоком (пулом) и нарезается для конкретных нужд. Ты ниже это назвал Region-based.

Region это способ организации набора объектов разного размера, при котором все они деаллоцируются одним махом.
Пул же, хоть и допускает возможность такой же быстрой деаллокации всех объектов в некоторых случаях, в общем случае не предполагает этого. Более того, в общем случае объекты можно "возвращать" в пул, для повторного использования места ими занимаемого в рамках одной сессии/"времени жизни пула". А если ещё более конкретно, то когда говорят о пулах — обычно подразумевают управление блоками фиксированного размера.
Смешивать понятия пулов и регионов (хотя они и имеют некоторые схожие черты) — неправильно, и только вносит терминологическую путаницу.

VD>Free list же не имеет к нему никакого отношения.

Free list это всего лишь способ нарезки куска памяти, при котором не теряется память на связи между узлами списка.

VD>Это всего лишь тупой и тормозной алгоритм из дремучих веков.

Смешно

VD>А вот в GC используют Region-based (если тебе так понятнее) принцип.

При region-based есть только выделение, и никаких остановок мира или конкурентных-пакостей

VD>Выделение памяти в GC — это всего лишь увеличение указателя на начало свободной памяти в хипе.

И? http://rsdn.ru/forum/dotnet/5805346.flat#5805346

EP>Непонятно с чем связанно удивление — это много или мало?
EP>У Compacting GC выделение памяти на Happy-Path это, фактически, просто увеличение указателя на требуемый размер

Проблема в том, что ты априори недооцениваешь собеседников, при том что сам плаваешь в теме.

VD>Освобождение вообще не просходит.

GC это и есть пляска для освобождения/reclaiming памяти занимаемой мусором.

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

Ты сегодня прям отжигаешь, T.G.I.F.

VD>Дефрагментация и тем более обход графа обычно идут в параллельных потоках. Учитывая, что голов у современных процессоров довольно много, это не сильно напрягает рабочие потоки.

Если бы всё было шоколадно, то не было бы этих заморочек с garbage-free design.

VD>Быстрее, как я уже говорил, только пулы (Region-based, если тебе так угодно) которые создаются под группу объектов которые имеют одинаковый срок жизни. При этом можно уничтожить весь пул, а не возиться с каждый отдельным объектом.

Это Region, а не Pool.

VD>По жизни в С++, если нужно строить графы объектов, обычно используют обычную кучу и один из способов полуавтоматического управления памятью (смартуказатели со стратегиями владения или подсчет ссылок). Например, в броузерах обычно используется именно подсчет ссылок. Причем идет тенденция к переходу на GC.

Я же и говорю — есть специфические задачи где возможны жёсткие циклы.

EP>>Да, но используются они совершенно по-разному.
EP>>В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокация — одна на массив указателей, и по одной на каждый объект.
VD>Ну, это явное заблуждение. В Шарпе (точнее в дотнете) есть варианты. Можно создать структуру и она будет точно так же размещена в массиве.

Ты конечно же не читатель — слово "класс" я для кого подчеркнул? То что в C# возможно использовать структуры это конечно хорошо (поэтому я и сказал "уж тем более в Java"), но это требует дополнительных движений (которые по умолчанию и не делают), т.е. нельзя просто взять и положить любой класс как структуру в массив.

EP>>Самый быстрый аллокатор это Region/Arena/Zone. Аллокация это просто увеличение счётчика текущей позиции в свободной памяти на выделяемый размер, а деалокации нет, то есть бесплатная.
EP>>Опять же, по производительности GC и рядом не стоит с регионами, и разница отнюдь не "некоторое количество тактов" — это как небо и земля.
VD>Очень смешно. Я тебя расстрою. В GC именно так память и выделяется.

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

VD>Разве что интерлок используется, для потокобезопасности.

Не используется, память берётся из TLS-кусочка, читай ссылку выше.

VD>Region-based (он же пул) без сборки мусора — это очень специфичная штука подходящая не очень часто.

А я разве говорил что она универсальная? Я привёл пример самого быстрого аллокатора, в котором вообще нет освобождения, и никакой другой дополнительной работы

VD>Так что, как говорится, не учи отца ... делать детей.

Пальцы разогни, ок?

VD>GC — это общее решение автоматического проблемы управления памятью. Она тебе просто перестает волновать.

И именно поэтому "не" волнуются об stop-the-world, LOH'ах, и "не" пилят garbage-free.

VD>Основан он на том же пуле.

GC? На пуле?

VD>Подсчет ссылок обычно более медленный механизм нежели GC. Если бы это было не так, то GC и строили на базе подсчета ссылок, так как реализация этого способа элементарна.

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

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

VD>Ты наверно еще в школу ходил, когда я делал реально универсальные "самые быстрые в мире"

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

Что характерно, в этом самом QuickHeap, который ты пилил 12 лет назад, как раз и можно было использовать Free List, чтобы не тратить дополнительно место под m_pNext в каждом QHBlock, ты тогда этого не знал.
Но и через 12 лет, когда тебе пытаются дать новую информацию, ты её отказываешься усваивать и начинаешь хамить.
Как ты там цитировал

К несчастью, то ж бывает у людей:
Как ни полезна вещь, — цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.

Кстати, у Алкесандреску про подобные пулы хорошо описано в Modern C++ Design 2001 года

Он там и использовал free list. Плюс operator delete который принимает size вторым аргументом (а в C++14 появился подобный delete, который ещё и non-member).

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

VD>В это главное верить. Иначе тяжело себе объяснить зачем МС переписывает свои компиляторы и IDE на дотнете.

Готовятся к переезду в Индию? ) Там это будет весьма актуально... )

VD>Из МП в Шарпе действительно не густо. Разве что внешние средства и куцие встроенные ДСЛ-и. Но как язык он в разы удобнее С++. Немерл же это квинтесенция удобства и простоты шарпа и возможностей МП сильно превосходящих С++.

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

Кстати, с таким подходом, в Немерле вообще нет смысла, т.к. кроме МП там нет ничего интересного. Я уже молчу про ограниченность сомнительной .net платформой.

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

_>>Для начала тогда уж std::atomic, а не эта хрень из win api.
VD>Это важное уточнение

.

А ты думаешь разницы нет? )

VD>Как оверхэд может быть нулевым, если есть конструкторы, деструкторы и, тем более, подсчет ссылок?

Конструкторы и деструкторы естественно инлайнятся по полной. Иначе бы эти килобайты высокоуровневых абстракций из boost'a не превращались в пару ассемблерных инструкций в итоге. )

А обязательный подсчёт ссылок ты откуда в C++ взял? ) Ты случаем не путаешь C++ с COM? )

VD>Как бы оверхэд есть оверхэд. В управляемом мире при копировании ссылок никаких затрат нет. Просто указатель переезжает в другую область памяти. Синхронизация если и есть, то только при выделении памяти (для сдвижки указателя хипа), или нет вообще, так как хип локален для потока.

Что за операция такая, "копирование ссылок"? ) Непонятно. )

VD>Про освобождение вообще говорить не чего. Для ЖЦ-объекта понятие "освобождение" нет в принципе. Нет ссылок — значит умер.

Если бы такое написал какой-нибудь новичок в java/c#, то это я бы ещё понял. Но ты же вроде бы разбираешься и вполне представляешь себе какую цену приходится платить за "автоматической управление памятью"... Тогда зачем такое писать? )

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

VD>Да вы тут совсем пенсами замедлись бы. Все, блин, эксперты один экспертнее другого. Вот учите плюсам человека который в плюсах собак по больше вашего съел.

VD>Старайтесь! Это повышает ЧСВ!

О, а можешь ответить на один простенький вопросик? ) В каком году ты написал свой последний серьёзный проект на C++? )

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

VD>Дык при освобождении ничего и не делается. Точнее даже самого освобождения нет. По графам бегают в других потоках. При этом остальные потоки не останавливаются. И мертвых объектов в этом графе нет. Мир останавливается не всегда. Есть конкурентные GC. А те что останавливают, делают это на очень короткие промежутки времени и исключительно для дефрагментации памяти, о которой в С++ даже мечтать нельзя.
Azul C4 ещё круче. Он даже для дефрагментации памяти потоки не останавливает.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

G>Чисто теоретически, наверное, можно (не специалист, ибо) объявить else часть в макросе if опциональной.

Практически тоже можно.

  macro IF(cond, e1, e2)
  syntax ("IF", "(", cond, ")", e1, Optional("ELSE", e2)) 
  {
    match(e2) 
    { 
      | null => <[ match ($cond) { | true => $e1; () | _  => ()  } ]>
      | _    => <[ match ($cond) { | true => $e1     | _  => $e2 } ]>
    }
  }

И даже работает.

    IF(true) WriteLine("ok");
    def x = IF(false) "true" ELSE "false";

Я думал так: when/unless созданы для побочных эффектов, а ifelse — для "чистых" вычислений. Но в этом нет смысла, потому исключительно вопрос вкуса.

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

STD>>Популярность Немерле — это примерно как популярность Линукса. С одно стороны ядро, с другой — куча дистрибутивов. Я полагаю, что делая дистрибутив "шарп с плюшками", сложно придти к популярности. Потому что флагман известен, но цели его не ясны, а добежать туда раньше можно только случайно, но и это не гарантирует успеха.
_>Сомнительное сравнение, т.к. Линух уже является явным лидером в нескольких областях.
Линукс — это ядро, на базе которого создаются дистрибутивы для решения конкретных задач. А востребованность дистрибутива зависит от того, как он эти задачи решает. Продолжая аналогию, можно сказать, что займись сообщество созданием дистрибутива, слепо копирующего условную MaсOS, то шансы на лидерство в нескольких областях сильно бы упали.

_>А у Немерле пока что нет ни одной такой области.
Потому что копируя C#, Nemerle попадает в его же ниши и проигрывает конкуренцию. Отсюда и бесконечные вопросы "почему Немерле не совсем C#?" и "на кой ляд он мне сдался Немерле, если мне и в экосистеме C# хорошо?".

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

_>>Да, только я там же указал, что на большинстве задач стандартные средства C++ заметно превосходят стандартные средства Java/C#.
VD>Это языком если. А на практике плюсовый код все чаще переписывается на Явах с Дотнетами, а плюсовый выкидывается. У плюсов остаются только ниши где за производительность можно заплатить очень дорого, так как затраты на разработку не соизмеримы с доходами. Но это удел высокотиражного софта вроде ОС, офисных приложений и игр-блокбастеров.

Если ты считаешь, что быстродействие языка — это единственное, что определяет его применимость, то ты явно ничего не понимаешь в бизнесе. Фактор возможности использования низкоквалифицированных программистов намного важнее для любых не IT компаний.

VD>Ну, еще ниши где управляемые языки не применимы (драва, например).

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

VD>В остальных же процесс перехода на более безопасные языки идет полным ходом. Люди даже тормозной Питон используют лишь бы с плюсами не связываться. Хотя тебя послушать, так питон отдыхает.

Хы, я как раз Питончик люблю и везде его советую. )))

VD>Вот ты над чем на работе работаешь?

C++, спец. язык для SIMD, Python, Prolog, JS и ещё куча всяких узкоспециализированных (типа xslt, wix, plantuml, и т.д.).

VD>Очнись. Переход с С++ на C# шел все прошлое десятилетие. В MS VS объем С++ кода сократился со 100%, то 20. А в скором времени и его не станет.

О да, в фантазия MS. )))

VD>Я как бы не в восторге от того, что в C# нет даже тех возможностей МП, как в С++. Но это не значит, что у Шарпа нет других преимуществ по сравнению с плюсами.

Для профессионала вообще нет никаких преимуществ. В принципе. А вот для бизнеса, у которого it отдел является не профильной деятельностью, преимущества очевидны...

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

Никто и не говорит, что C++ — это идеал. Просто ничего лучшего пока не видно. Ну точнее есть D и в перспективе Rust, но они пока хороши только как сами языки, а вот инфраструктуры за ними никакой...

VD>C# — это банально более продуманный и последовательный язык с автоматическим управлением памятью на котором проще писать. Проще и все тут. Достаточно попробовать написать несколько приложений и вопрос отпадет сам собой.

Это не верная формулировка. Для специалиста как раз на C++ может оказаться проще. Правильная формулировка такая: низкоуровневому программисту проще писать на Java/C#, чем на C++. И это действительно чистая правда.

VD>Как бы хаять С++ нет желания. Его используют и будут использовать. У него есть свои ниши. Но и превозносить его тоже не стоит. У языка куча недостатков которые уже вряд ли можно исправить.

Ну так и про C# у меня точно такое же мнение. У него есть своя ниша, в которой он очень хорош. Причём если считать в программистах, а не в инсталляциях софта, эта ниша ещё и побольше чем у C++.

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

AVK>Он даже не является надмножеством самой самой основы шарпа. В этом и проблема.
Что такое самая основа шарпа? C# — монолитный язык, ниже него только CLI.

AVK>Есть одна проблемка — минималистичный ML нужен только гикам.
AVK>Дело не в неумности тех, кто занимается шарпом. Дело в необходимости обеспечения обратной совместимости даже в мелочах. 100% компилируемость старого кода — строгий императив.
AVK>так я лет 5 назад предлагал взять шарп, выкинуть из него некоторое количество хвостов и косяков, да добавить туда самые вкусные моменты — ПМ, сахарок разный типа того, что отчасти реализовали, отчасти напредлагали в C# 6 и т.п.
Вот пусть C# старый код на C# и компилирует. Как взять и выкинуть из него хвосты и косяки — непонятно. Как взять нужный только гикам минималистичный ML (содержащий в себе базовые идиомы вроде ПМ, ФВП, классов, макросов) и добавить разный сахарок — понятно лучше. Другой вопрос, что один C# уже есть и нужность второго вызывает сомнения.

STD>>Ну микроядро языка позволяет строить разные языки.
AVK>Опять позволяет. Все разговоры в будущем времени.
>самые вкусные моменты — ПМ, сахарок разный типа того, что отчасти реализовали, отчасти напредлагали в C# 6 и т.п.
Все это уже есть, но пользоваться этим якобы мешают "отдельные яйца выеденного не стоящие проблемочки".
Я пишу "якобы мешают", потому что считаю "довольно далеко отстоящесть от шарпа" надуманным обоснованием малой популярности Немерла. И вижу 3 варианта:
1. "самые вкусные моменты" не настолько вкусны, чтобы ради них потратить 5 минут на изучение таблички. Это значит, что человека устраивает C#. Ведь, к примеру, языкам под JVM синтаксические различия с Java не мешают, а, наоборот, подаются в качестве достоинства.
2. существуют иные (реальные) технические проблемы.
3. популяризацией Немерле никто не занимается, а само оно что-то не взлетает.

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

EP>>Естественно имелась в виду не просто "forward" ссылка, а именно использование.
EP>>Если это доступно — то в двух словах какой механизм?
WH>Это и шаблоны не могут.

Как это не могут? http://coliru.stacked-crooked.com/a/6dce64982d71fae4

constexpr int Buratino(int);

template<int X>
constexpr int Carlo()
{
    return Buratino(X+3)+4;
}

constexpr int Buratino(int x)
{
    if(x <= 0)
        return Carlo<1>() + 2;
    else
        return x+5;
}

int main()
{
    static_assert(Buratino(0) == 15, "");
}

Функция использует шаблон, который вызывает функцию — всё в одном TU, и даже вычисляется на этапе компиляции

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

EP>Функция использует шаблон, который вызывает функцию — всё в одном TU, и даже вычисляется на этапе компиляции

Ну и я могу сделать два макроса, которые друг друга вызывают.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>>Функция использует шаблон, который вызывает функцию — всё в одном TU, и даже вычисляется на этапе компиляции

WH>Ну и я могу сделать два макроса, которые друг друга вызывают.

Естественно что аналогичный результат можно получить и другими способами, речь-то не об этом.
Выше было заявлено, что шаблоны это фактически препроцессор, что макросы Nemerle это надмножество шаблонов, и что на них можно сделать всё то, что и на шаблонах.
Я привёл контраргумент, а потом конкретный пример в поддержку этого аргумента.
constexpr там лишь усиливает эффект, но грубо говоря не обязателен. И там не два шаблона, а шаблон функции и функция.

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

STD>Я думал так: when/unless созданы для побочных эффектов, а ifelse — для "чистых" вычислений. Но в этом нет смысла, потому исключительно вопрос вкуса.
http://en.wikipedia.org/wiki/Dangling_else

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>constexpr там лишь усиливает эффект, но грубо говоря не обязателен. И там не два шаблона, а шаблон функции и функция.
Без constexpr получается "forward" ссылка.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>>constexpr там лишь усиливает эффект, но грубо говоря не обязателен. И там не два шаблона, а шаблон функции и функция.
WH>Без constexpr получается "forward" ссылка.

Да, можно и так трактовать, но как раз constexpr и устраняет неоднозначность в трактовке результата. Для этого, собственно, он там и стоит.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

EP>>Да, можно и так трактовать, но как раз constexpr и устраняет неоднозначность в трактовке результата. Для этого, собственно, он там и стоит.
WH>В этом случае мы имеем два макроса.

Почему? constexpr функция тоже макрос?
Buratino можно вызывать с runtime значениями, брать адрес и т.п.

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

EP>Почему? constexpr функция тоже макрос?
EP>Buratino можно вызывать с runtime значениями, брать адрес и т.п.
Буратин два. Один макрос. Второй рантайм функция.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

WH>Вольфхаунду тупо нечего комитить пока он не решит очередную задачку неберучку.

И это не правильно.

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

WH>Azul C4 ещё круче. Он даже для дефрагментации памяти потоки не останавливает.

Если не ошибаюсь, конкурентный ЖЦ в последних версиях дотнета тоже не останавливает. В прочем и раньше влияние этих остановок было не заметить невооруженным взглядом. Они же делаются только при сборе 2-го поколения и обычно во время простоя или при острой нехватке памяти (что уже пипец, в общем то).

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

_>О, а можешь ответить на один простенький вопросик? ) В каком году ты написал свой последний серьёзный проект на C++? )

Где-то в 2006-ом. Можно подумать, что за это время что-то расцвело в плюсах. О всех новшествах я в курсе. О том что так и не вошло, тоже в курсе.

Все что вы получили в С++11/14 и намного больше я имел еще в 2006 в Немерле. После знакомства с ним тема С++ для меня была закрыта раз и на всегда.

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

WH>>Вольфхаунду тупо нечего комитить пока он не решит очередную задачку неберучку.
VD>И это не правильно.
Ну, закомитил я вчера кровавые ошмётки неработающего решения. Тебе легче стало?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

_>А обязательный подсчёт ссылок ты откуда в C++ взял? )

С чего ты взял, что я его там брал? Это единственный паттерн условно автоматического управления памяти доступный в С++, если забыть про GC, которое "плохое".

_>Ты случаем не путаешь C++ с COM? )

Да конечно путаю! Ведь ты у нас тут высокий профессионал, а остальные лаптем щи хлебают.

Ты бы свое ЧСВ чесал бы в другом месте. А уж если пришел сюда общаться, то будь добр исходить из того, что находящиеся тут люди как минимуму не дурне тебя и знаю не меньше.

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

VD>>В это главное верить. Иначе тяжело себе объяснить зачем МС переписывает свои компиляторы и IDE на дотнете.
_>Готовятся к переезду в Индию? ) Там это будет весьма актуально... )

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

_>Как интересно... Т.е. оказывается для тебя вполне возможна ситуация, когда язык вообще без МП будет предпочтительнее языка с МП при условии наличия пары мелких украшательств? ))) Необычно такое слышать от вечного проповедника МП... )))

МП — это конечно хорошо, но код то приходится писать куда чаще, чем метапрограммы. На худой конец МП можно и снаружи прикрутить. Когда ты пишешь код руками, даже полноценный интеллисенс уже является большим преимуществом. Ну, и уровень языка, само собой. Производительность руда повышается. Я могу написать больше полезного кода и потратить меньше времени на отладку. Опять же появляются рантайм-фичи вроде рефлексии, генерации IL, динамической загрузки компонентов без приседаний и т.п.

_>Кстати, с таким подходом, в Немерле вообще нет смысла, т.к. кроме МП там нет ничего интересного. Я уже молчу про ограниченность сомнительной .net платформой.

Немерл это лучшее из двух миров. Это и удобный язык, и мощное МП. Зачем мне выбирать неполноценные решения, если есть полноценное? К тому же Немерл просто как (без учета МП) язык лучше Шарпа и уж тем более лучше Плюсов. Отдельный вопрос, что это стало возможно былагодоря макрам, но даже если бы он был таким в монолитном виде, то я бы с удовольствием на нем бы писал.

На Немерле код получается кратким как питоновский (и даже кратче), типизированным как шарповский и при этом он гибче чем С++. Ну, что еще хотеть? Разве что более высокой производительности и переносимости дотнета, и более качественной поддержки в IDE.

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

VD>Где-то в 2006-ом. Можно подумать, что за это время что-то расцвело в плюсах. О всех новшествах я в курсе. О том что так и не вошло, тоже в курсе.

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

). Иначе не было бы такой кучи смешных с точки зрения любого спеца по C++ высказываний. Из твоих слов иногда кажется, что C++ — это такой C#/Java, только без сборщика мусора, рефлексии и т.п. )))

VD>Все что вы получили в С++11/14 и намного больше я имел еще в 2006 в Немерле. После знакомства с ним тема С++ для меня была закрыта раз и на всегда.

Такое я ещё вполне могу понять. Конечно при условии, что нет необходимости писать софт недоступный платформе .net (к примеру у меня именно такой требуется). А вот вариант с переходом на C# явно не укладывается в схему с высокоуровневым специалистом, неравнодушным к МП.

Кстати, а что ты думаешь про D и Rust? ) Конечно не раз их уже обсуждали на этом форуме и в целом ты писал, что "желаешь им успеха"... Но интересно более развёрнуто. ) Nemerle же всё равно не является им конкурентом, пока цепляется за .net.

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

_>>А обязательный подсчёт ссылок ты откуда в C++ взял? )
VD>С чего ты взял, что я его там брал? Это единственный паттерн условно автоматического управления памяти доступный в С++, если забыть про GC, которое "плохое".

Ой как забавно. ) А unique_ptr — это тогда что, некая магия? )

_>>Ты случаем не путаешь C++ с COM? )
VD>Да конечно путаю! Ведь ты у нас тут высокий профессионал, а остальные лаптем щи хлебают.

VD>Ты бы свое ЧСВ чесал бы в другом месте. А уж если пришел сюда общаться, то будь добр исходить из того, что находящиеся тут люди как минимуму не дурне тебя и знаю не меньше.

Это естественно была ирония. ) Но вызванная как раз реальными сомнениями в твоём знание C++. Точнее одно из двух: или ты действительно многое забыл/не знал, или же ты просто сознательно пишешь неправду ради попытки "победы" в форумном споре. У меня возникают только такие выводы, после твоего высказывания о подсчёте ссылок, как об основном инструменте управления памятью в C++. Не говоря уже о множестве других мелких оговорок.

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

VD>>>В это главное верить. Иначе тяжело себе объяснить зачем МС переписывает свои компиляторы и IDE на дотнете.
_>>Готовятся к переезду в Индию? ) Там это будет весьма актуально... )
VD>Ты думаешь ты такими выпадами кого-то унизил? Ты прав — себя. Выглядишь глупо. Люди не малые деньги в разработку вкладывают. Они уж точно понимают, что делают.

А с чего ты собственно взял, что "переезд в Индию" не является выгодным акционерам? ) Правда в дальней перспективе у такой ситуации есть свои недостатки — все инновации придётся "создавать" только скупкой стартапов. Но это тоже решение, причём возможно даже менее рисковое для финансистов.

Кстати, по моим сведениям у них этот процесс уже давно идёт в тихом режиме. )))

VD>Немерл это лучшее из двух миров. Это и удобный язык, и мощное МП. Зачем мне выбирать неполноценные решения, если есть полноценное? К тому же Немерл просто как (без учета МП) язык лучше Шарпа и уж тем более лучше Плюсов. Отдельный вопрос, что это стало возможно былагодоря макрам, но даже если бы он был таким в монолитном виде, то я бы с удовольствием на нем бы писал.

VD>На Немерле код получается кратким как питоновский (и даже кратче), типизированным как шарповский и при этом он гибче чем С++. Ну, что еще хотеть? Разве что более высокой производительности и переносимости дотнета, и более качественной поддержки в IDE.

Ты похоже немного не понимаешь расклада. Во всяком случае если говорить не лично о тебе (как о фанате языка), а вообще. Если мы сравниваем мейнстрим языки, то действительно можно посмотреть на всякие нюансы типа синтаксического сахара. Т.к. по различным инфраструктурным параметрам там у всех имеется полный набор всего. Если же мы говорим о не мейнстримных языках, то чтобы иметь какие-то шансы, язык должен иметь киллер-фичу. У Nemerle вроде бы есть такая — это как раз макросы. Правда есть и ограничение в платформе (только .net), но и это тоже не плохой кусочек рынка (хотя не уверен, что на этом рынке особенно популярны такие нетривиальные вещи, как МП). А вот Nemerle без макросов на 100% не имеет шансов, даже если у него там есть какие-то небольшие преимущества в синтаксисе перед C#, т.к. у него нет кучи важных инфраструктурных вещей.

Кстати, а вот Swift похоже уже взлетел, хотя официально ещё не выпущен.

Причём какой-то явной киллер-фичи у него нет, а имеется опять же множество мелких приятностей в синтаксисе. Но зато у него гарантированно нет проблем с инфраструктурой.

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

EP>>Конкретный пример где ref-counting действительно к месту:
WH>Это очень простая задача.

Покажи сложнее.

WH>>>Если кто-то обращается к этим страницам, то происходит аппаратное исключение.
EP>>И начинается ping-pong кэш-линиями и аппаратными исключениями, не говоря уже о том, что проедется аппаратный поток.
WH>Только происходит это не каждый раз.
WH>А если не повезёт и мутатор столкнется с мусорщиком.

Просмотрел я paper по C4:
* работает на специальном железе (привет Лисп-машинам).
* либо на Linux с модифицированным ядром (привет Windows), так как требуется много remaping'ов виртуальных страниц на физические.
* реализация для JVM (привет .NET).
* в реализации описанной в статье stop-the-world всё-таки присутствует, пишут что меньше миллисекунды.
* при загрузке каждого указателя происходят условные проверки и манипуляции с его значением, так как часть его бит используется для нужд GC. Это хозяйство размазывается тонким слоем по всему пользовательскому коду.
* наткнувшись на значение указателя по которому ещё не проходил GC в текущей фазе, пользовательский поток помещает его в очередь (по всей видимости atomic'ами, но чёткого описания не встретил), обновляет бит в его значении, и атомарно записывает обратно в память.
* наткнувшись на не-до-реалоцированный объект (защищённая страница упомянутая тобой), пользовательский поток сам его перемещает.
* суммарно энергии на работу GC (kWh, вычислительные ресурсы), по идее, затрачивается намного больше чем у обычного stop-the-world
* конкурентные сборщики (по одному на каждое поколение), отъедают железные потоки, загружают/вымывают кэши, отбирают ценный memory throughput
* думаю вполне реально ситуация, когда мусор генерируется быстрее чем сборщики способны его подчищать — в итоге вся память забьётся, и весь процесс деградирует до скорости уборки мусора.
* этот GC нацелен в основном на время отклика и минимизацию задержек.

WH>>>Например был огромный COM сервер.
EP>>То есть interop, ...
WH>Экстраполяция из точки. Там было очень много чего намешано.

Например?

WH>>>Консервативный ГЦ это хрень полнейшая.
EP>>У него есть своя область применения

WH>Нет. Совсем нет.
WH>Либо точный. Либо без ГЦ вообще.

Раскрой мысль.

EP>>Раз он точный, то память уплотнить (и обновить указатели) не проблема, но ограничения определённые есть. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
WH>Это в С++ то? А если в объекте, которым управляет мусорщик, есть поле с объектом, который двигать нельзя?

Я же написал что есть ограничения. Они, очевидно, есть и даже без уплотнения — скажем raw pointer не удержит объект живым.

WH>>>Поколения есть?
EP>>Тоже не вижу проблемы.
WH>Не видишь или есть?

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

WH>А вот после нормального исключения можно легко восстановиться.

Цель программы обработать данные, а из-за бага обработка невозможна (пусть хоть исключения летают, хоть акробаты), цель не достигнута, хотя по контракту должна была быть

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

_>т.к. у него нет кучи важных инфраструктурных вещей.

Что это за загадочные вещи?

_>Кстати, а вот Swift похоже уже взлетел, хотя официально ещё не выпущен.

Причём какой-то явной киллер-фичи у него нет, а имеется опять же множество мелких приятностей в синтаксисе. Но зато у него гарантированно нет проблем с инфраструктурой.

С родителями у него нет проблем. У них много бабла и пиара. Это ты имеешь в виду под инфраструктурой?

VD>Это явление малость под утомило. Мартышек много и они активны. Ответить на все глупости которые они говорят не хватит и всей жизни. Проводить остаток жизни в споре с ними нет никакого желания.
Вот это жесть конечно, я даже забросил Политику. У меня, после прочтения всего этого, все меньше и меньше сомнений жив Немерле или мертв.

зы. И кстати да, переименовывать Немеле не надо, просто замените орла на банан

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

AVK>Но это еще полбеды. Хуже другое — есть некоторое количество людей, которые могут быть согласны с частью того, что пишет тобою обзываемый. И видя твои обзывания, они тоже начинают воспринимать тебя как неадекватного хама.
Когда ты уже очнешься, никто не начинает его воспринимать как неадекватного хама. За столько лет все всё прекрасно понимают. Жаль что вы это только поощряете.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

AVK>>Он даже не является надмножеством самой самой основы шарпа. В этом и проблема.
STD>Что такое самая основа шарпа? C# — монолитный язык, ниже него только CLI.

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

STD>Я пишу "якобы мешают", потому что считаю "довольно далеко отстоящесть от шарпа" надуманным обоснованием малой популярности Немерла.

Считай.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

VD>Тот же отсутствие ретурна — это маленький кусочек реализации концепции "все является выражением".

Но с другой стороны — нет никаких проблем разрешить if без else, вместо того чтобы писать вместо этого when.

VD>Но осзнавать это начинаешь только пройдя этот двухнедельный курс въезжания.

Так ты корову не продашь.

VD>Как бы можно тупо сваять язык на базе Шарпа, но это будет другой, менее красивый и удобный язык.

Красивый — возможно. А насчет удобства я бы поспорил.

VD>Кстати, Немерл умеет компилировать шарпный код (точнее немерл с синтаксисом шарпа).

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

I>У нас все ходы записаны.

У меня тоже.

I> Если интересно, можешь посмотреть коммит в котором я удалил все эти твои интерфейсы и вернулся к старому дереву

Зачем мне его смотреть?

AVK>>Ага. К примеру о том что вариант, когда на все приложение может быть строго одно дерево, неприемлем. Потому что не закатывать провайдер дерева в статическое свойство "невозможно в нашей концепции".
I>Это неправда.

Это ваши слова.

I>Проще говоря, всё было практически сделано

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

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

Просто ты не слышал ответы.

I>Ещё раз говорю, никаких ограничений в нашей концепции нет и не было.

Но работа не сделана.

I> Проблема была в том, что мы друг друга не слышали.

Мнея не надо было слышать. Я вам отдел исходники реальных интерфейсов. Никаких неоднозначностей. А в ответ вы меня кормили рассказами про то, что ваше дерево настолько универсально, что адаптировать под конкретные требования вы его не собираетесь, и вообще вам rsdn не особо интересен. В результате и с rsdn вы не справились и больше нигде в более менее крупных проектах ваше дерево так и не используется. Epic fail.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

AVK>Набор конструкций, который используется практически в любом коде.
Ты набор-то приведи. А потом уже посмотрим, является Немерле надмножеством или нет.

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

AVK>>А в результате имеем что имеем — куче народу не просто пофик на Немерле, они агрессивно против него и создают вам такой антипиар, какой вы пересилить не в состоянии просто в силу существенно меньшего количества сторонников.
Dog>Так и есть.

Ну как там сказано.
"Нет пророка в своем отечестве"(с)
"Нужно идти туда, где не знают"(с)

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

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

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

I>>У нас все ходы записаны.
AVK>У меня тоже.
Покажи. Я ведь показал.

I>> Если интересно, можешь посмотреть коммит в котором я удалил все эти твои интерфейсы и вернулся к старому дереву
AVK>Зачем мне его смотреть?
Чтобы увидеть те интерфейсы, которые ты от меня требовал.

AVK>>>Ага. К примеру о том что вариант, когда на все приложение может быть строго одно дерево, неприемлем. Потому что не закатывать провайдер дерева в статическое свойство "невозможно в нашей концепции".
I>>Это неправда.
AVK>Это ваши слова.
Это твоя выдумка.

Я не знаю как тебе объяснить ещё, что у нас на сервере всегда был обыкновенный ASP.NET MVC контроллер. Что хочешь с ним, то и делай.

I>>Проще говоря, всё было практически сделано
AVK>Вот я и говорю — ну уже проактически совсем. Но почему то постоянно какие то досадные проблемки.
Дык мне от тебя нужна была информация, о том как ты будешь передавать провайдер. Ты мне отвечал что это "неважно", и так в течение часа беседы в скайпе.

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

I>>Ещё раз говорю, никаких ограничений в нашей концепции нет и не было.
AVK>Но работа не сделана.
Сделана. Только ты не захотел её интегрировать.
Если дашь код, который показывает откуда у тебя берётся провайдер (DI, создание по месту или ещё что), то можно в течение 15-20 минут всё интегрировать.

I>> Проблема была в том, что мы друг друга не слышали.
AVK>Мнея не надо было слышать. Я вам отдел исходники реальных интерфейсов. Никаких неоднозначностей. А в ответ вы меня кормили рассказами про то, что ваше дерево настолько универсально, что адаптировать под конкретные требования вы его не собираетесь, и вообще вам rsdn не особо интересен.
Ты коммит то посмотри. Зачем врать?

AVK>В результате и с rsdn вы не справились и больше нигде в более менее крупных проектах ваше дерево так и не используется. Epic fail.
Я не совсем понимаю твой агрессивный настрой по отношению к нам? Я разве тебе что-то плохое сделал?

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

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

BC>Надо свернуть аккуратно Немерл и попытаться пропихнуть его под новым именем на незнакомой площадке.
BC>Шансы есть у даже самого неудачного проекта. Тут конечно уже получилось вязкое болото "соотечественников".

Вставлю 5 копеек как человек, узнавший про Nemerle где-то полгода назад, прочитавший статьи, впечатлившийся, попробовавший и не ставший внедрять.
Ибо:
1) Поддержка IDE установилась раза с седьмого после нескольких попыток поставить Nemerle разных версий (на VS2013)
2) Поддержка IDE конфликтует с плагинами, например TabSanity (ломается интелисенс)
3) Стандартная библиотека ставится в GAC, NuGet-пакет с нужными сборками просто-напросто отсутствует, что делает невозможным нормальное использование Nemerle при разработке библиотек. Выражается это тем, что непонятно как таскать за собой зависимости (включать в пакет и ловить конфликты с другой библиотекой на Nemerle?) и невозможности собрать на сферическом билд-сервере в вакууме без дополнительной настройки, хотя казалось бы, в чём проблема стандартную библиотеку, компилятор и MSBuild-таски распространять через NuGet, закидывая их скриптами в директорию в корне решения, как это делает сам NuGet для поддержки Package Restore.
4) Самое важное: .NET-разработчики, и я в том числе, как на наркотик подсели на ReSharper. Он слишком много делает за нас, слишком много позволяет сделать в 2 клика. Пока в нём не будет поддержки Nemerle о массовом промышленном внедрении можно забыть. У Scala, кстати, с IDE схожие проблемы, недавно пришлось поддерживать небольшой компонент на ней, долго плевался.

В итоге сижу и жду, пока допилят нитру и, если повезёт, прикрутят поддержку немерла к решарперу.

EP>>>Да, но используются они совершенно по-разному.
EP>>>В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокация — одна на массив указателей, и по одной на каждый объект.
VD>>Ну, это явное заблуждение. В Шарпе (точнее в дотнете) есть варианты. Можно создать структуру и она будет точно так же размещена в массиве.
EP>Ты конечно же не читатель — слово "класс" я для кого подчеркнул? То что в C# возможно использовать структуры это конечно хорошо (поэтому я и сказал "уж тем более в Java"), но это требует дополнительных движений (которые по умолчанию и не делают), т.е. нельзя просто взять и положить любой класс как структуру в массив.

Конкретный пример:
http://coliru.stacked-crooked.com/a/169cb8f18b2d07f8

struct Shape
{
    virtual void draw() const = 0;
};

struct Triangle : Shape
{
    void draw() const override
    {
        cout << "Triangle" << endl;
    }
};

struct Circle : Shape
{
    void draw() const override
    {
        cout << "Circle" << endl;
    }
};

int main()
{
    vector<Triangle> triangles = {{}, {}};
    vector<Circle> circles = {{}};
    vector<Shape*> shapes = {&triangles[0], &circles[0], &triangles[1]};

    for(auto x : shapes)
        x->draw();
}

Где здесь для C#/.NET ставить struct? Не говоря уже о том, что эти Circle/Triangle могут быть недоступны для изменений.

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

_>>т.к. у него нет кучи важных инфраструктурных вещей.
VD>Что это за загадочные вещи?

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

_>>Кстати, а вот Swift похоже уже взлетел, хотя официально ещё не выпущен.

Причём какой-то явной киллер-фичи у него нет, а имеется опять же множество мелких приятностей в синтаксисе. Но зато у него гарантированно нет проблем с инфраструктурой.
VD>С родителями у него нет проблем. У них много бабла и пиара. Это ты имеешь в виду под инфраструктурой?

См. выше. Сейчас конечно же ещё не всё есть, но очевидно что 100% будет. Т.е. уже даже сейчас (ещё до официального выхода) вложение в разработку на Swift'e не будет сильно рискованным шагом.

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

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

BC>>Надо свернуть аккуратно Немерл и попытаться пропихнуть его под новым именем на незнакомой площадке.
BC>>Шансы есть у даже самого неудачного проекта. Тут конечно уже получилось вязкое болото "соотечественников".

K>Вставлю 5 копеек как человек, узнавший про Nemerle где-то полгода назад, прочитавший статьи, впечатлившийся, попробовавший и не ставший внедрять.
K>Ибо:
K>1) Поддержка IDE установилась раза с седьмого после нескольких попыток поставить Nemerle разных версий (на VS2013)
K>2) Поддержка IDE конфликтует с плагинами, например TabSanity (ломается интелисенс)
K>3) Стандартная библиотека ставится в GAC, NuGet-пакет с нужными сборками просто-напросто отсутствует, что делает невозможным нормальное использование Nemerle при разработке библиотек. Выражается это тем, что непонятно как таскать за собой зависимости (включать в пакет и ловить конфликты с другой библиотекой на Nemerle?) и невозможности собрать на сферическом билд-сервере в вакууме без дополнительной настройки, хотя казалось бы, в чём проблема стандартную библиотеку, компилятор и MSBuild-таски распространять через NuGet, закидывая их скриптами в директорию в корне решения, как это делает сам NuGet для поддержки Package Restore.
K>4) Самое важное: .NET-разработчики, и я в том числе, как на наркотик подсели на ReSharper. Он слишком много делает за нас, слишком много позволяет сделать в 2 клика. Пока в нём не будет поддержки Nemerle о массовом промышленном внедрении можно забыть. У Scala, кстати, с IDE схожие проблемы, недавно пришлось поддерживать небольшой компонент на ней, долго плевался.

K>В итоге сижу и жду, пока допилят нитру и, если повезёт, прикрутят поддержку немерла к решарперу.

Могу добавить в список другие мелкие недоработки которые мешают использовать язык:

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

В связи с пунктом 1 интеграция для 2010 и выше работает с компилятором только для .NET 4 . Можно конечно использовать хаки, но это не то.

Нет поддержки авто-генерации перенаправлений(AutoGenerateBindingRedirects) , в связи с чем невозможно использовать SignalR 2.0 и другие библиотеки.

Сама стандартная библиотека Nemerle нуждается в переработке с учетом новых возможностей .NET , но этим пока никто не занимался, в итоге бывает трудно выбрать какой метод использовать Select vs. MapLazy например.

Нет хорошей поддержки *NIX систем. Конечно в Mono есть баги и нужно их учитывать, но с поддержкой Mono можно было бы использовать язык для мобильных приложений. Кроме того это увеличивает количество людей , которым язык мог бы быть интересен.

Нет поддержки новых фич .NET , например dynamic . Конечно есть аналог , однако использовать библиотеку C# где есть dynamic немного неудобно.

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

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

>> Нет возможности компилировать для других версий отличных от компилятора.
Если не ошибаюсь, в Mono проблему решили переездом компилятора на IKVM.Reflection.Emit. Равно как и бред с "можно делать 64-битные сборки только при запуске компилятора в 64-битном дотнете".

>> Нет хорошей поддержки *NIX систем. Конечно в Mono есть баги и нужно их учитывать, но с поддержкой Mono можно было бы использовать язык для мобильных приложений. Кроме того это увеличивает количество людей , которым язык мог бы быть интересен.
По идее там не заводится только компилятор, результирующие сборки работают нормально, так что с Xamarin-овскими утилитами, заточенными на работу в VS принципиальных и неустранимых проблем быть не должно. Xamarin Studio же до сих пор представляет из себя нечто малоюзабельное: несмотря на то что уже пятый год использую Mono в продакшне на серверсайде, для разработки применяем исключительно VS.

>>Сходу все не вспомнишь, но мелочи каждый раз немного достают.
Ну и 183 открытых issue на GitHub говорят о многом, да. В общем и целом создаётся впечатление, что проект скорее мёртв чем жив.

Принципиальный вопрос на самом деле немного в другом. Если в дальнейшем планируется переход на Nitra, имеет ли вообще сейчас смысл трогать хоть как-то компилятор и стандартную библиотеку (немалую часть которой составляют макросы, которые тоже придётся полностью переписывать)?

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

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

>>> Нет возможности компилировать для других версий отличных от компилятора.
K>Если не ошибаюсь, в Mono проблему решили переездом компилятора на IKVM.Reflection.Emit. Равно как и бред с "можно делать 64-битные сборки только при запуске компилятора в 64-битном дотнете".
В Nemerle тоже хотели решить этим способом, но , к сожалению, так и не довели до конца

https://github.com/rsdn/nemerle/tree/ikvm

>>> Нет хорошей поддержки *NIX систем. Конечно в Mono есть баги и нужно их учитывать, но с поддержкой Mono можно было бы использовать язык для мобильных приложений. Кроме того это увеличивает количество людей , которым язык мог бы быть интересен.
K>По идее там не заводится только компилятор, результирующие сборки работают нормально, так что с Xamarin-овскими утилитами, заточенными на работу в VS принципиальных и неустранимых проблем быть не должно. Xamarin Studio же до сих пор представляет из себя нечто малоюзабельное: несмотря на то что уже пятый год использую Mono в продакшне на серверсайде, для разработки применяем исключительно VS.
Только невозможна кросс-компиляция и поэтому с Xamarin не пойдет.

K>Принципиальный вопрос на самом деле немного в другом. Если в дальнейшем планируется переход на Nitra, имеет ли вообще сейчас смысл трогать хоть как-то компилятор и стандартную библиотеку (немалую часть которой составляют макросы, которые тоже придётся полностью переписывать)?
Сейчас Nitra это не компилятор, а парсер.
Я не знаю сроки окончания его, но пока его не закончат о компиляторе Nemerle2 вообще речи и не идет.

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

_NN>Только невозможна кросс-компиляция

А в чём там основная проблема со сборкой? Вы же там с lambdalice что-то ковыряли, на чём застряли? Я немного знаю потроха Mono, может, подскажу что.

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

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

_NN>>Только невозможна кросс-компиляция

K>А в чём там основная проблема со сборкой? Вы же там с lambdalice что-то ковыряли, на чём застряли? Я немного знаю потроха Mono, может, подскажу что.

Я о том, что компилятор не может же компилировать для других версий фреймворка.

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

_NN>Я о том, что компилятор не может же компилировать для других версий фреймворка.

Mono же вроде как сиренево, с какой версией слинкованы сборки (там даже есть ключ --runtime= для явного указания, а в списке рассылки было предложение выкинуть отдельную компиляцию для .NET, предлагалось всё запускать с актуальной версией). Опять же можно post-build таском через Mono.Cecil пройтись и поправить нужное.

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

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

_NN>>Я о том, что компилятор не может же компилировать для других версий фреймворка.

K>Mono же вроде как сиренево, с какой версией слинкованы сборки (там даже есть ключ --runtime= для явного указания, а в списке рассылки было предложение выкинуть отдельную компиляцию для .NET, предлагалось всё запускать с актуальной версией). Опять же можно post-build таском через Mono.Cecil пройтись и поправить нужное.

Не знаю, это надо смотреть

Я что-то подумал , что он также как и .NET работает.

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

EP>>>Конкретный пример где ref-counting действительно к месту:
WH>>Это очень простая задача.
EP>Покажи сложнее.
Nitra. Там одно восстановление после ошибок на порядки сложнее.

EP>* работает на специальном железе (привет Лисп-машинам).
Насколько я понял это предыдущая версия. Новая как я понял работает на любом.
В любом случае я не вижу проблем в том, чтобы совершенствовать железо.

EP>* либо на Linux с модифицированным ядром (привет Windows), так как требуется много remaping'ов виртуальных страниц на физические.
EP>* реализация для JVM (привет .NET).
И что?

EP>* в реализации описанной в статье stop-the-world всё-таки присутствует, пишут что меньше миллисекунды.
Ещё они пишут, что можно убрать совсем. Но не видят смысла.

EP>>>У него есть своя область применения

WH>>Нет. Совсем нет.
WH>>Либо точный. Либо без ГЦ вообще.
EP>Раскрой мысль.
Тормоза. Утечки памяти. Невозможность дефрагментации памяти.

EP>Я же написал что есть ограничения. Они, очевидно, есть и даже без уплотнения — скажем raw pointer не удержит объект живым.
Все эти ограничения сводят полезность ГЦ к нулю.

EP>В той конкретной реализации скорей всего нет.
EP>А вообще, при возможности двигать объекты — да, не вижу проблемы создать поколения.
Вот только этой возможности в С++ нет и не предвидится.

WH>>А вот после нормального исключения можно легко восстановиться.
EP>Цель программы обработать данные, а из-за бага обработка невозможна (пусть хоть исключения летают, хоть акробаты), цель не достигнута, хотя по контракту должна была быть

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

AVK>Но с другой стороны — нет никаких проблем разрешить if без else, вместо того чтобы писать вместо этого when.

Слушайте... ну объясните мне за кипиш с if[/else]?! В чем проблема-то? Я правильно понимаю, что если текущий if/else заменить на гипотетический when/else, а if/else "переписать" на опциональный else и сделать вычисляемым всегда в void, то ваша проблема исчезнет? Так?

Ребята... что if, что when — емнип — макросы. Что мешает, сами себе сделать вам красиво?! Или я чего-то не понимаю?

---
С уважением, Константин Сиваков

P.S. А вычисление assignment в void откуда есть у Nemerle пошло, если не секрет? От поляков?

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

EP>Что характерно, в этом самом QuickHeap, который ты пилил 12 лет назад, как раз и можно было использовать Free List, чтобы не тратить дополнительно место под m_pNext в каждом QHBlock, ты тогда этого не знал.

Читаем что написано по твоей ссылке:

A free list is a data structure used in a scheme for dynamic memory allocation. It operates by connecting unallocated regions of memory together in a linked list, using the first word of each unallocated region as a pointer to the next. It is most suitable for allocating from a memory pool, where all objects have the same size.

Может быть ты сам написанное не понял? У меня ровно это и делается. Только у них пулы выбираются статически, так как язык знает о размере объекта, а у меня был С/С++ с размером объекта передаваемым в параметре. Приходилось сначала искать нужный пул по массиву, а потом уже пользоваться тем самым связанным списком свободных блоков.

EP>Но и через 12 лет, когда тебе пытаются дать новую информацию, ты её отказываешься усваивать и начинаешь хамить.

Нет там никакой новой для меня информации. Ты просто пургу несешь.

EP>Кстати, у Алкесандреску про подобные пулы хорошо описано в Modern C++ Design 2001 года

Я за него рад. Я его книжку увидел сильно позже.

Так вот что касается пулов/регионов. Это весьма опасное решение, хотя и быстрое. Примерно так работает и GC, только он гарантирует корректность управления памятью.

Кроме того в продвинутых GC (к сожалению пока что имеющихся только в Яве) есть такие фишки как escape analysis которые позволяют в автоматическом режиме применять оптимизации вроде размещения памяти в пуле или на стеке для объектов не прикапываемых внутри функций.

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

EP>Где здесь для C#/.NET ставить struct? Не говоря уже о том, что эти Circle/Triangle могут быть недоступны для изменений.

Это пример небезопасной манипуляции указателями. После его применения ты будешь следить за временем жизни объектов из shapes вручную.

Тут вокруг носится alex_public и постоянно доказывает, что С++ не С и. Что в нем то контроль по чище Шарпа...

Ну, да используя разные приседания в С++ можно писать более эффективный код, только расплатой за это будет куча граблей разложенных повсюду в коде. О том и речь.

Если производительность все, а на написание кода и его отладку можно потратить неограниченное время, то может такой подход и приемлем. Но это не такой уж частый случай. Для большинства задач проще поплатиться небольшим оверхэдом (в основном связанным с расходом памяти) и получить решение значительно быстрее и надежнее.

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

EP>Да, можно и так трактовать, но как раз constexpr и устраняет неоднозначность в трактовке результата. Для этого, собственно, он там и стоит.

Он превращает выражение в вычисляемое во время компиляции. А это == коду макроса. Я тебе любые вычисления на constexpr превращу в аналогичные внутри макроса.

Тут первично "где и когда выполняется код". Если он constexpr или макрос, то выполняться он будет во время компиляции.

Вся разница с макросами заключается в том, что макрос — это точка входа, а не сама функция. Вот как твой пример реализуется на макросах:

macro Buratino(x : int)
{
  // локальные функции выполняемые во время компиляции.
  // В отличии от ограниченных плюсов тут можно выполнять 
  // любой код. Создать экземпляры обычных классов. Сходить в БД...
  def Carlo(x : int)
  {
    buratino(x + 3) + 4
  }
  and buratino(x : int)
  {
    if (x <= 0)
      Carlo(1) + 2
    else
      x + 5
  }
  
  <[ $(buratino(x)) ]>
}

Вызов аналогичен.

Один. Макрос не функция, а точка входа.

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

EP>Почему? constexpr функция тоже макрос?
EP>Buratino можно вызывать с runtime значениями, брать адрес и т.п.

Ну, возьми адрес глобальной переменной. Хе-хе.

ЗЫ

Ты похоже не понимаешь, что в Немерле таким constexpr может быть любая функция. Просто ее нужно скомпилировать к моменту применения в макросе. Ее же можно и в рантайме использовать. Просто подключи ссылку на библиотеку и к макро-проекту, и к проекту в котором нужна эта функция.

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

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

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

_>Инфраструктура языка это прежде всего: множество родных библиотек, поддержка для него в основных индустриальных инструментах и возможно несколько родных инструментов, большее сообщество разработчиков.

Какие проблемы с библиотеками и инструментами? Уж у Немерла с ними сильно лучше чем в С++ (где брать чужие библиотеки вообще приключение). Но что-то мне подсказывает, что ты сейчас мне начнешь рассказывать обратное.

Сообщество? Так вот сидят эти потенциальные члены сообщества и ищут причину чтобы не смотреть или фатальный недостаток чтобы отказаться.

Мне с самого начала казалось, что вот есть хороший язык. Люди должны его оценить, создать сообщество. Далее создать качественные инструменты и библиотеки — это дело техники. Тем более, что библиотеки уже есть в больших количествах в дотнете.

Но ни фига. "Умников" спешащих покритиковать (точнее смешать с дерьмом) пруд пруди. Но среди них нет ни одного, что бы попытался разобраться и попробовать пописать на языке.

Причем среди тех кто попробовал почти 100% приятие языка и высокая оценка его возможностей.

А далее замкнутый круг. Без комьюнити не сделать качественной реализации той же поддержки IDE, так как объем работ большой, возможности автоматизации низкие, и куча непонятного и плохо документированного (или вообще не документированного) API от Microsoft. Плюс баги в SRE от того же производителя.

И вот выходит великий язык Свифт который примерно на 90% == немерл, только без перегрузок, макросов и прочих мелких вкусностей. Имеет он ровно две новые фичи, которые по сути сахар. Тулов к нему особых нет. Библиотеки ни чем не отличаются от немерловых. Но сообщество возникнет обязательно! Надо только запретить писать под свои продукты на чем либо кроме этого языка.

А теперь задумаемся что же такого скрывается за этой "инфраструктурой"? Да ничего технического! Только бабло и известность. И выходит, что богатый и известный может протолкнуть и говно. Надо лишь его в красивую обертку закатать, отполировать чтобы блестело, и распиарить по сильнее. Да даже и пиарить то не надо. Брэнд же уже ОГО-ГО.

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

Вот не устраивает тебя дотнет. Замечательно! Давно хотели нэйтив-компиляцию на базе той же LLVM залудить. Но рук то на все не хватает. Вот взялся бы в свободное от работы (а то и рабочее) время и помог реализовать эту амбициозную задачу. Был у нас нативный немерл, который и по производительности уже мало чем С++ уступал бы.

Но ведь фига два ты возьмешься помогать. Критиковать то куда проще. Правда?

VD>>С родителями у него нет проблем. У них много бабла и пиара. Это ты имеешь в виду под инфраструктурой?

_>См. выше. Сейчас конечно же ещё не всё есть, но очевидно что 100% будет. Т.е. уже даже сейчас (ещё до официального выхода) вложение в разработку на Swift'e не будет сильно рискованным шагом.

Долго смотрел, но так и не понял причин близорукости. То ли ты реально не можешь оценить то что критикуешь (как остальные критиканы), то ли стесняешься себе признаться, что причина в том о чем говорю я, а не в "инфраструктуре".

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

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

_>Если ты считаешь, что быстродействие языка — это единственное, что определяет его применимость, то ты явно ничего не понимаешь в бизнесе. Фактор возможности использования низкоквалифицированных программистов намного важнее для любых не IT компаний.

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

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

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

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

Хотя я лично предпочитаю маленькие команды проффесионалов (на любом языке). Но прекрасно понимаю, что команд в 40 может сделать больше чем команда из 3 с супер-языком.

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

VD>>Ну, еще ниши где управляемые языки не применимы (драва, например).

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

Таких ниш очень мало в последнее время. Вот уже поддержку IDE для С++ на Яве пишут.

_>Хы, я как раз Питончик люблю и везде его советую. )))

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

VD>>Вот ты над чем на работе работаешь?

_>C++, спец. язык для SIMD, Python, Prolog, JS и ещё куча всяких узкоспециализированных (типа xslt, wix, plantuml, и т.д.).

Я спрашивал не на чем, а над чем.

В прочем, это тоже интересно.

Кстати, сколько ты программ на C# (про Немерл просто умолчим) написал?

А то я чувствую, у нас с тобой интересный разговор получается. Я то на С и С++ пописал не мало. Лет 10, примерно, писал. Ну, да бросил я его до выхода С++14 (который еще толком и не реализован нигде), где язык малость подтянули до современного уровня. Но все же я прекрасно понимаю о чем говорю. А вот на каком уровне ты знаком с тем же дотнетом?

VD>>Очнись. Переход с С++ на C# шел все прошлое десятилетие. В MS VS объем С++ кода сократился со 100%, то 20. А в скором времени и его не станет.

_>О да, в фантазия MS. )))

Хороши такие фантазии. Энтерпрайз весь на управляемых языках. Самые крутые тулы для разработчиков тоже на них. Остались разве что 3D-игры, ОС и браузеры. Остальные сферы в лучшем случае имеют аналоги на управляемых языках.

_>Для профессионала вообще нет никаких преимуществ. В принципе. А вот для бизнеса, у которого it отдел является не профильной деятельностью, преимущества очевидны...

Я с твоего ЧСВ просто балдею!

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

_>Ну так и про C# у меня точно такое же мнение. У него есть своя ниша, в которой он очень хорош. Причём если считать в программистах, а не в инсталляциях софта, эта ниша ещё и побольше чем у C++.

У C# тоже есть свои проблемы. Но многие проблемы C++ он успешно преодалел. Тот же С++14 во многом нагоняет C#. Убогость инициализаторов меня всегда в С++ бесила. Всякие вариадик-шаблоны и констэкспрешоны немного подтягиваеют С++ к немерлу, но все равно это все не то.

У С++ остается только два реальных преимущества.
1. Минималистичный рантайм.
2. Возможность выжимать из железа последние соки.

Остальное от лукавого.

Причем есть Ди, который, довольно близок к С++ по главным его характеристикам. И есть Немерл/Скала, которые большую фору С++ как языку дадут. Но вы так и будете до пенсии славить С++ и жалеть о том, что в нем "все же не все хорошо" (ц)

ЗЫ

Ты тут спрашивал меня кое-что. Времени отвечать на все не хватает. Так что отвечу блицом
1. Unsafe в Nemerle реализован в виде макросов и микроскопической правки ядра. На все про все ушло 3 дня работы. Жаль, что на практике так и не применили, так ак о оптимизаций еще руки не дошли. Тормоза что у нас есть все упираются в комбинаторные взрывы (ака экспонента), что ансэйфом не лечится, как ты понимашь.
2. Мое отношение к Ди и Расту — заочное. Говорить серьезно о языках которые я не использовал на практике считаю не очень правильным. Могу только высказать свое мнение о их дизайне.

Ди не плохой продолжатель дела С++ и мог бы быть его заменой. Автору не хватает смелости (автор слишком консервативен). Язык до сих пор пишется на С++ (не забутстраплен), что минус. Отсюда же растут некоторые недостатки (на мой взгляд). В зыке нет паттерн-матчинга и алгеброических типов. На мой взгляд эта важная фича. Та МП то есть в Ди слабовато, хотя и выглядит не плохо на фоне С++. Главное что там есть модульность, безопасность и прочие атрибуты современного языка.

Раст имеет ровно обратные проблемы по сравнению с Ди — слишком новаторский. Он еще попросту не устаканился. У авторов явно не было четкого плана действий (а вы тут еще Немерл в отсутствии концепций обвиняли, гы-гы). Авторы дергаются в разные стороны. То 100500 видов указателей, а потом их под нож. То изменение синтаксиса... Макросы у него есть, но они очень примитивные (насколько я могу судить). Их преимущество — их не надо отдельно компилировать как немерловые. Но это же не дает им быть такими же быстрыми и мощными.

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

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

VD>

VD>A free list is a data structure used in a scheme for dynamic memory allocation. It operates by connecting unallocated regions of memory together in a linked list, using the first word of each unallocated region as a pointer to the next. It is most suitable for allocating from a memory pool, where all objects have the same size.

VD>Может быть ты сам написанное не понял? У меня ровно это и делается.

Имеется в виду то, что указатель хранится внутри свободного буфера, а не отдельно (требуя дополнительную память на связи).

Да даже если это не считать существенной частью free list'а, а брать только то что это стэк свободных буферов, то что ты тут-то имел в виду:

VD>Пул же это когда память выделяется большим блоком (пулом) и нарезается для конкретных нужд. Ты ниже это назвал Region-based. Free list же не имеет к нему никакого отношения. Это всего лишь тупой и тормозной алгоритм из дремучих веков.

Free list'ы как раз и используются как основа пулов

VD>Только у них пулы выбираются статически, так как язык знает о размере объекта, а у меня был С/С++ с размером объекта передаваемым в параметре. Приходилось сначала искать нужный пул по массиву, а потом уже пользоваться тем самым связанным списком свободных блоков.

Free list это всего лишь список/стэк свободных блоков, грубо говоря структура данных.
В твоём же примере free list'ов несколько, грубо говоря они являются основой алгоритма управления памятью, а не самим алгоритмом.

VD>Так вот что касается пулов/регионов. Это весьма опасное решение, хотя и быстрое. Примерно так работает и GC, только он гарантирует корректность управления памятью.

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

VD>Кроме того в продвинутых GC (к сожалению пока что имеющихся только в Яве) есть такие фишки как escape analysis которые позволяют в автоматическом режиме применять оптимизации вроде размещения памяти в пуле или на стеке для объектов не прикапываемых внутри функций.

Это не часть "продвинутого GC", а фактически заглушка для избегания GC.
Если бы GC был "самым быстрым в мире алгоритм распределения памяти", то никто бы от него не убегал при первой же возможности.

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

VD>Мне с самого начала казалось, что вот есть хороший язык. Люди должны его оценить, создать сообщество. Далее создать качественные инструменты и библиотеки — это дело техники. Тем более, что библиотеки уже есть в больших количествах в дотнете.

Люди "должны" — квинтэссенция твоего евангелизма

Только узнаел про Немерле и уже должен. Ага.

VD>Причем среди тех кто попробовал почти 100% приятие языка и высокая оценка его возможностей.

Этот аргумент, что харктерно, справедлив и про секты, и про наркоту и тд.

VD>А далее замкнутый круг. Без комьюнити не сделать качественной реализации той же поддержки IDE, так как объем работ большой, возможности автоматизации низкие, и куча непонятного и плохо документированного (или вообще не документированного) API от Microsoft. Плюс баги в SRE от того же производителя.

А как же другие проекты, которые в таких же условиях находились, взять лялих тот же ?

VD>И вот выходит великий язык Свифт который примерно на 90% == немерл, только без перегрузок, макросов и прочих мелких вкусностей. Имеет он ровно две новые фичи, которые по сути сахар. Тулов к нему особых нет. Библиотеки ни чем не отличаются от немерловых. Но сообщество возникнет обязательно! Надо только запретить писать под свои продукты на чем либо кроме этого языка.

Не надо ничего запрещать. Свифт нисколько не Немерл. Свифт очень привычный любому современному разработчику язык, то есть искаропки. Немерл — это макро-ориентированое-программирование.
Фактически, ты хочешь вместе с хорошим языком продать экзотическую парадигму.
Есть один тренд, который ты почему то игнорируешь — даже ООП знает очень мало людей, не говоря об ФП. А ты решил еще и макро-парадигму протащить.

VD>Но такие как вы будут учить как надо делать. Что надо делать. Как маркетинг проводить...

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

>...И это вместо того чтобы взять и помочь в развитии.

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

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

VD>Хотя я лично предпочитаю маленькие команды проффесионалов (на любом языке). Но прекрасно понимаю, что команд в 40 может сделать больше чем команда из 3 с супер-языком.

Похоже, что ты подогнал коммюнити под удобный для тебя размер команды.

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

Как ты предлагаешь порог замерять ? "У меня получилось, значит всё просто" ?

И в чем проявяется этот самый порог ?

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

I>Не надо ничего запрещать. Свифт нисколько не Немерл. Свифт очень привычный любому современному разработчику язык, то есть искаропки. Немерл — это макро-ориентированое-программирование.

Мне кажется, что даже без макросов Немерле очень удобный язык. Если сегодня взять и убрать макросы, но дать инфраструктуру сравнимую по качеству хотя бы с F# (не говоря уже о C#), то я бы предпочёл Немерле любому другому языку.

Сейчас же получается так, что несмотря на мою привязанность к этому языку, я выбираю не его использовать на работе, а писать на связке C# + Resharper. Что бы Влад не говорил, но Resharper сильно изменил скорость написания, а главное поддержки кода. Если в C# я скучаю по ПМ и АТД, то в Немерле я скучаю по решарперу

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

EP>>Где здесь для C#/.NET ставить struct? Не говоря уже о том, что эти Circle/Triangle могут быть недоступны для изменений.
VD>Это пример небезопасной манипуляции указателями. После его применения ты будешь следить за временем жизни объектов из shapes вручную.

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

Этот пример показывает, что аллокаторы в C++ vs C# используются совершенно по разному.
Массив объектов конкретного типа (пусть даже если это объекты с виртуальными методами) — для C++ типичное явление.
В то время как в .NET, для получение подобного эффекта нужно писать специальный код, отступая от идиом (как там покрасивее воспроизвести этот пример?). А вот массив указателей на объекты выделенных динамически — это дефолт.

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

VD>Он превращает выражение в вычисляемое во время компиляции. А это == коду макроса. Я тебе любые вычисления на constexpr превращу в аналогичные внутри макроса.

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

VD>Вся разница с макросами заключается в том, что макрос — это точка входа, а не сама функция. Вот как твой пример реализуется на макросах:
VD>

VD>macro Buratino(x : int)
VD>{
VD>  // локальные функции выполняемые во время компиляции.
VD>  // В отличии от ограниченных плюсов тут можно выполнять 
VD>  // любой код. Создать экземпляры обычных классов. Сходить в БД...
VD>  def Carlo(x : int)
VD>  {
VD>    buratino(x + 3) + 4
VD>  }
VD>  and buratino(x : int)
VD>  {
VD>    if (x <= 0)
VD>      Carlo(1) + 2
VD>    else
VD>      x + 5
VD>  }
  
VD>  <[ $(buratino(x)) ]>
VD>}
VD>

VD>Вызов аналогичен.

Тут, как я понял, Buratino это макрос, а buratino это функция.
Речь же шла про вызов шаблона (или макроса), функцией, который впоследствии вызывает эту же функцию. А в твоём примере макрос определяет две локальные функции, которые вызывают друг друга

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

VD>Какие проблемы с библиотеками и инструментами? Уж у Немерла с ними сильно лучше чем в С++ (где брать чужие библиотеки вообще приключение). Но что-то мне подсказывает, что ты сейчас мне начнешь рассказывать обратное.

Это ты видимо C# библиотеки хочешь включить в список библиотек Nemerle? ) Потому как если говорить о его родных, то их думаю поменьше чем даже у D, у которого всё довольно печально.

VD>Сообщество? Так вот сидят эти потенциальные члены сообщества и ищут причину чтобы не смотреть или фатальный недостаток чтобы отказаться.

Как раз все смотрят, но пока не видят подходящего инструмента для работы.

VD>Мне с самого начала казалось, что вот есть хороший язык. Люди должны его оценить, создать сообщество. Далее создать качественные инструменты и библиотеки — это дело техники. Тем более, что библиотеки уже есть в больших количествах в дотнете.

VD>Но ни фига. "Умников" спешащих покритиковать (точнее смешать с дерьмом) пруд пруди. Но среди них нет ни одного, что бы попытался разобраться и попробовать пописать на языке.

VD>Причем среди тех кто попробовал почти 100% приятие языка и высокая оценка его возможностей.

VD>А далее замкнутый круг. Без комьюнити не сделать качественной реализации той же поддержки IDE, так как объем работ большой, возможности автоматизации низкие, и куча непонятного и плохо документированного (или вообще не документированного) API от Microsoft. Плюс баги в SRE от того же производителя.

Всё правильно. Это известный замкнутый круг. Он в различных ипостасях присутствует во многих местах индустрии. Например с некоторыми видами ПО под линухом. И решается это обычно (если вообще решается

) поворотом какой-то одной крупной компании (пример Steam под линух).

VD>И вот выходит великий язык Свифт который примерно на 90% == немерл, только без перегрузок, макросов и прочих мелких вкусностей. Имеет он ровно две новые фичи, которые по сути сахар. Тулов к нему особых нет. Библиотеки ни чем не отличаются от немерловых. Но сообщество возникнет обязательно! Надо только запретить писать под свои продукты на чем либо кроме этого языка.

Они как раз ничего не запретили. Obj-C вполне себе продолжает жить. Правда он настолько убогий, что все нормальные программисты с радостью сами убегут с него на Swift. )))

Ну и кстати на .net этот язык совсем не похож. Начнём с его организации памяти, компиляции и т.п. Он скорее похож на упрощённый (без МП) и чуть более изящный D. Т.е. он вполне хорошо позиционируется на место современного системного языка, в отличие от Java/C#.

VD>А теперь задумаемся что же такого скрывается за этой "инфраструктурой"? Да ничего технического! Только бабло и известность. И выходит, что богатый и известный может протолкнуть и говно. Надо лишь его в красивую обертку закатать, отполировать чтобы блестело, и распиарить по сильнее. Да даже и пиарить то не надо. Брэнд же уже ОГО-ГО.

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

VD>Но такие как вы будут учить как надо делать. Что надо делать. Как маркетинг проводить... И это вместо того чтобы взять и помочь в развитии.

Я как раз ничего не советовал. ) Я лишь указал на наличие проблемы у Nemerle (такой же как и у D и т.п.), а как её решить у меня нет идей. Ну если конечно кто-то из монстров вдруг не повернётся к языку.

VD>Вот не устраивает тебя дотнет. Замечательно! Давно хотели нэйтив-компиляцию на базе той же LLVM залудить. Но рук то на все не хватает. Вот взялся бы в свободное от работы (а то и рабочее) время и помог реализовать эту амбициозную задачу. Был у нас нативный немерл, который и по производительности уже мало чем С++ уступал бы.

VD>Но ведь фига два ты возьмешься помогать. Критиковать то куда проще. Правда?

Совершенно верно. Мне сейчас интересны только готовые отточенные инструменты, а времени заниматься доработкой потенциально интересных у меня нет — через полгода надо новый продукт выдать (причём реально инновационный, а не очередные формочки к БД).

Но разве от этого факта моё мнение о продукте становится менее правильным? )

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

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

Ммм, понимаешь... Мне, как потребителю продукта, не особо принципиальны причины всего этого. Главное сам факт, что у Swift'a оно есть/будет, а у Nemerle в данный момент нет. Т.е. деньги это или пиар или ещё нюансы какие-то, типа упоминаемых мною выше, результат то один и именно он важен при выборе инструмента для работы.

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

EP>>Почему? constexpr функция тоже макрос?
EP>>Buratino можно вызывать с runtime значениями, брать адрес и т.п.
VD>Ну, возьми адрес глобальной переменной. Хе-хе.

Ты о чём конкретно?

VD>Ты похоже не понимаешь, что в Немерле таким constexpr может быть любая функция. Просто ее нужно скомпилировать к моменту применения в макросе. Ее же можно и в рантайме использовать. Просто подключи ссылку на библиотеку и к макро-проекту, и к проекту в котором нужна эта функция.

Это естественно следует из факта, что макро-проект по сути является плагином к компилятору. Делая плагин к Clang'у на C++, можно использовать библиотеку X, которая будет доступна и для использования в программе компилируемой Clang'ом.
Из этого также следуют и ограничения подхода — пока работает плагин компилятора, результат ещё не скомпилирован, и его нельзя использовать во время работы плагина (что справедливого и для плагина к Clang'у, и Nemerle).
В то время если называть шаблоны "макросами" — то пример выше как раз и демонстрирует, что "результат" работы этого "макроса", может использоваться самим "макросам".

http://rsdn.ru/article/nemerle/nemerleMacros.xml

9.4. Раздельная компиляция

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

Наиболее важное достоинство состоит в том, что это просто и легко для понимания – сперва нужно скомпилировать макросы (возможно, объединив их в какую-то библиотеку), затем загрузить их в компилятор, и, наконец, использовать. Таким образом, этапы компиляции четко разделены хорошо понятным образом – важное преимущество в промышленной среде, где метапрограммирование – новая и все еще малопонятная область.

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

Это как раз uber-wunderwaffe, с этим никто и не спорит, я даже неоднократно соглашался. (зачем опять-то повторять эту мантру?)
Хорошо бы было ещё иметь хороший оптимизатор в придачу, то есть чтобы можно было сразу генерировать более высокоуровневый код, без всякого penalty.

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

I>Я могу помочь только такому языку, который нравится лично мне. Вот макросы мне категорически не нравятся, я принципиально против макросов. Соответсвующее направление движения языка мне абсолютно не нравится.

Ну вот, а говорил не похож... Такой же капризный

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

VD>>Какие проблемы с библиотеками и инструментами? Уж у Немерла с ними сильно лучше чем в С++ (где брать чужие библиотеки вообще приключение). Но что-то мне подсказывает, что ты сейчас мне начнешь рассказывать обратное.

_>Это ты видимо C# библиотеки хочешь включить в список библиотек Nemerle? )

Гы ) Открою тебе секрет: ложки... библиотек C# не существует. Существуют только библиотеки .Net

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

VD>Я считаю, что ты зазнался малость и превозносишь этот С++, так как сотворил себе из него кумира.

У тебя какое-то нарушение в логике. ) Эта фраза имела бы смысл, если бы я был автором C++. )

VD>Ничего особого в С++ нет. То что ты называешь квалификацией — то всего лишь натренированность обходить грабли и решать проблемы вроде управления памятью.

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

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

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

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

Безусловно минус. И как раз на этом Java (в большей степении) и C# (в меньшей) захватили большую часть рынка. Естественно если считать в программистах, а не в инсталляциях.

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

А кто-то с этим спорил? ) Естественно хочется язык с возможностями C++, но при этом с простотой Python'а или вообще JavaScript. Но это же пока только мечты... )))

_>>Таких ниш очень много. И это связано не только с доступом к железу, но и с быстродействием.
VD>Таких ниш очень мало в последнее время. Вот уже поддержку IDE для С++ на Яве пишут.

О да, очень мало.))) С удовольствием посмотрю на реализацию сложной фильтрации в реальном времени FHD/4K видео на скажем Java... Если что, это очень даже актуальная сейчас задача в целом ряде направлений.

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

А на Nemerle вообще можно удобно писать скрипты? )

VD>Кстати, сколько ты программ на C# (про Немерл просто умолчим) написал?

VD>А то я чувствую, у нас с тобой интересный разговор получается. Я то на С и С++ пописал не мало. Лет 10, примерно, писал. Ну, да бросил я его до выхода С++14 (который еще толком и не реализован нигде), где язык малость подтянули до современного уровня. Но все же я прекрасно понимаю о чем говорю. А вот на каком уровне ты знаком с тем же дотнетом?

1. Ты говорил, что в 2006-ом бросил, так что и C++11 не застал (а это заметно большее изменение).
2. Мой текущий компилятор C++ отлично поддерживает стандарт C++14 — с кактуса MS мы слезли давным давно. )))
3. На знание Nemerle я и не претендовал нигде. Но пока он ограничен платформой .net, я вполне могу говорить о множестве его недостатков, проистекающих из ограничений платформы.
4. Что касается моих отношений с C#, то они имеют весьма продолжительную основу. ))) Помнится я ещё с Доном Боксом спорил на эти темы — вот это настоящий пропагандист .net'а, не чета народу с этого форума (как он программировал в блокнотике помнится). А первым моим приложением на C# были животинки для Террариума, на конкурс. Если ты в курсе о чём я. )))

VD>Хороши такие фантазии. Энтерпрайз весь на управляемых языках. Самые крутые тулы для разработчиков тоже на них. Остались разве что 3D-игры, ОС и браузеры. Остальные сферы в лучшем случае имеют аналоги на управляемых языках.

Вот у меня на компьютере установлена огромная куча ПО. И из него всего только одно приложение написано на .Net. Кстати, у него как раз самый страшный интерфейс из всех и оно живёт у меня на компьютере только по необходимости (системная хрень). Плюс имеется два приложения на Java. Надо признать что приятных. А все остальные десятки приложений — это или натив или натив+скрипт. И это всё явно не "игры или браузеры". Так кто из нас живёт в виртуальной реальности? )

_>>Для профессионала вообще нет никаких преимуществ. В принципе. А вот для бизнеса, у которого it отдел является не профильной деятельностью, преимущества очевидны...
VD>Я с твоего ЧСВ просто балдею!

Ты типа "профессионалка"! А на бизнес лохи работают. Для бизнеса, между прочем, пишется вполне себе коробочный софт. И работают там вполне себе профессионалы и высококлассные специалисты. Многие в прошлом работали на том же С/С++. Так что ты бы уж так не зазнавался говоря о бизнесе.

Ты так и не понял о чём была речь? ))) Не важно кто там работает. Важно кого там бизнес хочет видеть. И это явно не уникальные специалисты. Это если мы говорим про не IT бизнес.

_>>Никто и не говорит, что C++ — это идеал. Просто ничего лучшего пока не видно. Ну точнее есть D и в перспективе Rust, но они пока хороши только как сами языки, а вот инфраструктуры за ними никакой...
VD>Я эту песню слышал уже 100 раз. Начни сначала использовать этот Ди или Раст, а потом уже про инфраструктуру говори. Будет таких как вы хотя бы сотня человек и вы сами всю инфраструктуру сделаете. Причем такую какая вам нужна.

У меня нет на это времени.

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

Вообще то как раз очень многие C# программисты с трудом представляют что у них в реальности происходит. Я это не раз замечал по обсуждениям. Вот к примеру появился await/async и сразу все начали бездумно вставлять их везде. При этом только небольшая часть понимает что реализовано оно через сопрограммы (причём stackless) с соответствующими последствиями из этого. А так же понимает какая часть кода будет вызвана из какого потока и в какой момент (причём это ещё зависит от некоторых опций и использованных функций). Но используют все, как типа "некую магию". Ну и кстати именно такой стиль использования языка и поощряется в MS.

Да, и я не говорю что это ужасно. Но надо понимать, что это именно что особая ниша (хотя и весьма широкая).

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

И как ты будешь колбасить код? ) С созданием объектов через new, а не в стеке? С хранением указателей в shared_ptr вместо unique_ptr? Ты разве не понял, что основные претензии к тебе были не из-за незнания новейших ключевых слов, а из-за самого подхода, стиля. Ты постоянно предлагал для C++ код в стиле Java/C#. Да, C++ позволяет писать код и так. Но это явно не C++ стиль и он конечно же будет не самым эффективным — с таким можно и посравнивать Java/C# решения...

VD>У C# тоже есть свои проблемы. Но многие проблемы C++ он успешно преодалел. Тот же С++14 во многом нагоняет C#. Убогость инициализаторов меня всегда в С++ бесила. Всякие вариадик-шаблоны и констэкспрешоны немного подтягиваеют С++ к немерлу, но все равно это все не то.

VD>У С++ остается только два реальных преимущества.
VD>1. Минималистичный рантайм.
VD>2. Возможность выжимать из железа последние соки.

VD>Остальное от лукавого.

Так ты C++ с C# сравнивай, а не с Nemerle — они хотя бы в одной весовой категории. При таком сравнение у C# есть всего один плюс (возможность использовать слабых программистов) и целая куча минусов (нет быстродействия, нет доступа к железу, нет МП и т.д. и т.п.).

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

VD>Причем есть Ди, который, довольно близок к С++ по главным его характеристикам. И есть Немерл/Скала, которые большую фору С++ как языку дадут. Но вы так и будете до пенсии славить С++ и жалеть о том, что в нем "все же не все хорошо" (ц)

Вот лично моё субъективное мнение: если бы не выход C++11/14, то глобальный переход на D всё же состоялся бы. Его уже многие начали тогда ковырять, а кактус старого C++ совсем утомил. Но в новом C++ появилось реально много удобств (причём часть из того же D), так что многие отложили переход. И что-то мне кажется, что теперь уже не вернутся к этой теме. Теперь разве что Rust или что-то ещё в далёком будущем. Кстати, если Swift сделают кроссплатформенным, то у него тоже есть шансы...

VD>2. Мое отношение к Ди и Расту — заочное. Говорить серьезно о языках которые я не использовал на практике считаю не очень правильным. Могу только высказать свое мнение о их дизайне.

Спасибо. У меня похоже мнение. С поправкой на текст чуть выше про D.

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

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

AVK>>Но с другой стороны — нет никаких проблем разрешить if без else, вместо того чтобы писать вместо этого when.

G>Слушайте... ну объясните мне за кипиш с if[/else]?! В чем проблема-то? Я правильно понимаю, что если текущий if/else заменить на гипотетический when/else, а if/else "переписать" на опциональный else и сделать вычисляемым всегда в void, то ваша проблема исчезнет? Так?

G>Ребята... что if, что when — емнип — макросы. Что мешает, сами себе сделать вам красиво?! Или я чего-то не понимаю?

На самом деле, считаю, что проблема if/else/when/unless яйца выеденного не стоит. Но о чем-то людям пофлеймить надо, вот и шумят. Есть куда более важные задачи. Вобщем ждем Н2.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

I>>Не надо ничего запрещать. Свифт нисколько не Немерл. Свифт очень привычный любому современному разработчику язык, то есть искаропки. Немерл — это макро-ориентированое-программирование.

I>Мне кажется, что даже без макросов Немерле очень удобный язык. Если сегодня взять и убрать макросы, но дать инфраструктуру сравнимую по качеству хотя бы с F# (не говоря уже о C#), то я бы предпочёл Немерле любому другому языку.

Именно. Тот же PM и АТД хотя и довольно трудная фича, но востревована довольно широко.

I>Сейчас же получается так, что несмотря на мою привязанность к этому языку, я выбираю не его использовать на работе, а писать на связке C# + Resharper. Что бы Влад не говорил, но Resharper сильно изменил скорость написания, а главное поддержки кода. Если в C# я скучаю по ПМ и АТД, то в Немерле я скучаю по решарперу

В энтерпрайзе поддержка это очень критический аспект. Часто приходится наблюдать, что код пишет одна команда, майнтейнит другая, суппортит третья. А если про долгострой, то это вообще норма, когда за время жизни проекта состав команды полностью обновляется несколько раз.
Эта специфика требует, что бы вход был достаточно пологим. Нынешняя концепция Немерле это макро-ориентированое программирование == новая парадигма.

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

G>Так вы слона не продадите никому и никогда. Вообще этот топик очень показательный, то хамство, то попытка доказать, что все вокруг дураки раз не оценили, то "а остальные еще хуже", то карго культ поминают.

очень показательная статья и особенно комментарии

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

G>Ребята... что if, что when — емнип — макросы. Что мешает, сами себе сделать вам красиво?! Или я чего-то не понимаю?

Ты не понимаешь одной простой вещи — если на подобные вопросы будет следовать ответ "перепишите сами" то языком никто пользоваться не будет.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

I>Эта специфика требует, что бы вход был достаточно пологим. Нынешняя концепция Немерле это макро-ориентированое программирование == новая парадигма.

Не надо ля-ля. Ты можешь спокойно использовать Н ничего не зная о макросах. Достаточно прочитать страничку CSharp Similarities and Differences

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

G>>Ребята... что if, что when — емнип — макросы. Что мешает, сами себе сделать вам красиво?! Или я чего-то не понимаю?

AVK>Ты не понимаешь одной простой вещи — если на подобные вопросы будет следовать ответ "перепишите сами" то языком никто пользоваться не будет.

При всем моем уважении... это вы так про язык, девизом которого вполне может быть это самое — "сделай сам себе красиво"?!

Ну и я таки правильно понял, что ваш поит в том, что использовать слова if и else для "этого" не кошерно?

---
С уважением, Константин Сиваков

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

G>это вы так про язык, девизом которого вполне может быть это самое — "сделай сам себе красиво"?!

Я, конечно, уважаю выбор авторов (разработать язык с таким девизом), но, ИМХО, такой подход не сильно востребован. Хотя бы потому, что мало кто вообще представляет, как это сделать. А кто-то может и думает, что представляет, а в результате его представлений получится неподдерживаемая смесь бульдога с носорогом. Я на досуге ковыряю собственный язычок программирования (пока на уровне концепций) и отлично понимаю, сколько всего надо учесть для того, чтобы на выходе получилось что-то более-менее хорошее. Сколько всяких очевидных и не очень мелочей и как все на самом деле сложно. А тут "сделай сам себе красиво".

Да никто не будет этого делать (и по факту не делает).

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

ARK> А тут "сделай сам себе красиво".

Да никто не будет этого делать (и по факту не делает).

Да не надо писать язык с нуля. Есть базовые вещи плюс макролибы разработанные комунити, типа Computation Expressions и пр. Но если охота добавить какую-то мелочь — вот и "делай себе красиво".

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

G>>это вы так про язык, девизом которого вполне может быть это самое — "сделай сам себе красиво"?!

ARK>Я, конечно, уважаю выбор авторов (разработать язык с таким девизом), но, ИМХО, такой подход не сильно востребован.

Да ну?! А имхо, там где язык допускает хоть какую-то возможность мета-программирования — её используют на полную. Пока у нас нет примеров (кроме сабжа) с достаточно простой системой МП — говорить о том, что "такой подход не сильно востребован", мягко говоря, не корректно. МП — само по себе — очень даже востребовано. Так? Существующие системы МП имеют достаточно высокий порог входа. Только и всего. Ребята пытаются (и нельзя не признать, что в целом у них получается) этот порог снизить. Есть какие-то причины, по которым МП — при снижении порога вхождения — стало вдруг не востребовано?

ARK> Хотя бы потому, что мало кто вообще представляет, как это сделать. А кто-то может и думает, что представляет, а в результате его представлений получится неподдерживаемая смесь бульдога с носорогом.

А примеры можно? А то вот я вижу, что шаблоны плюсов во всю используют... и в качестве МП тоже. И parse_transform в erlang, и макросы в lisp... и т.д. и т.п. Макросы в Nemerle — гораздо проще всех этих вещей (ну может быть с lisp не так). А получается, что "не только лишь все". Язык позволяет сделать, так как надо именно тебе, именно сейчас и конкретно в этом месте. Сделать весьма просто. Это фича языка. Главная... не главная... вопрос отдельный. Есть и другие фичи.

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

ARK> Да никто не будет этого делать (и по факту не делает).

Там, где можно это сделать — очень даже делают.

---
С уважением, Константин Сиваков

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

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

Причём тут возможность назвать как удобно тебе? Мы говорим не о собственном удобстве, ведь люди которые некоторое время пишут на Немерле перестают спотыкаться об if/when. Разговор идёт о новых пользователях, которых может оттолкнуть непонятная ошибка компиляции в простейшем коде. Нормальных оправданий для when нет. Конкретная ситуация — это чистой воды пуризм авторов.

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

I>Причём тут возможность назвать как удобно тебе? Мы говорим не о собственном удобстве, ведь люди которые некоторое время пишут на Немерле перестают спотыкаться об if/when. Разговор идёт о новых пользователях, которых может оттолкнуть непонятная ошибка компиляции в простейшем коде. Нормальных оправданий для when нет. Конкретная ситуация — это чистой воды пуризм авторов.

Да ладно. Говорите нет нормальных оправданий для when? И спор не за названия. Тогда скажите на каком из двух нижеприведенных утверждений вы в серьез готовы наставивать:

1. Выражение if[/else] всегда вычисляется в void;
2. Если выражение if содержит else, то оно вычисляется "нормально". Иначе, оно вычисляется в void.

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

---
С уважением, Константин Сиваков

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

G>Да ладно. Говорите нет нормальных оправданий для when? И спор не за названия. Тогда скажите на каком из двух нижеприведенных утверждений вы в серьез готовы наставивать:

G>1. Выражение if[/else] всегда вычисляется в void;
G>2. Если выражение if содержит else, то оно вычисляется "нормально". Иначе, оно вычисляется в void.

G>Причем, у меня почему-то нет сомнений, что вы и сами можете привести весьма и весьма серьезные доводы против любого из этих утверждений. Альтернативы?

Второе конечно.

Вполне очевидно, что такая запись должна компилироваться:

def a = if (cond) f0() 
        else f1()

А такая — нет:

def a = if (cond) f0()

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

I>>Эта специфика требует, что бы вход был достаточно пологим. Нынешняя концепция Немерле это макро-ориентированое программирование == новая парадигма.

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

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

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

I>Вполне очевидно, что такая запись должна компилироваться:

I>

I>def a = if (cond) f0() 
I>        else f1()
I>

I>А такая — нет:

I>

I>def a = if (cond) f0()
I>

А кому очевидно-то? Вам? Мне? Или новичку, который закоментил else и у него вылезло, что-то типа this expression was expected to have type void but here has type X?! И тыкают, его не в assignment, а в сам if... не, ну а что, очевидно же

Вы бы, кстати, поинтересовались на досуге, как в F# относятся к такому if

По сути, если вы хотите пойти таким же путем (неявный else, вычисляемый в void), то придется вводить ещё и третий вариант — ибо вложенные if придется как-то учиться разбирать... ну чтоб хоть "ругаться" осмысленно в случае чего.

Я уж молчу про то, что на практике else от своего if может находится — скажем так — весьма далеко. А "нам надо знать"

И да... к чему, в конце концов, все эти "танцы"?! Считаете, что новичкам трудно? Ну так свояйте для них, какую-нибудь Nemerle.Macro.Newby — кто запрещает-то?!

---
С уважением, Константин Сиваков

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

G>А кому очевидно-то? Вам? Мне? Или новичку, который закоментил else и у него вылезло, что-то типа this expression was expected to have type void but here has type X?! И тыкают, его не в assignment, а в сам if... не, ну а что, очевидно же

Ещё раз говорю, такой код очевидно не должен компилироваться:

def a = if (cond) f0()

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

G>Я уж молчу про то, что на практике else от своего if может находится — скажем так — весьма далеко. А "нам надо знать"

Как это дело относится? Если у тебя if/else возвращает значение, то ты не будешь коментировать else. А если и будешь, то справедливо получишь по рукам.

G>И да... к чему, в конце концов, все эти "танцы"?! Считаете, что новичкам трудно? Ну так свояйте для них, какую-нибудь Nemerle.Macro.Newby — кто запрещает-то?!
Я считаю, что текущая ситуация никому ничего не даёт, но в то же время отпугивает новичков, тем что "в Немерле два синтаксиса для if".

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

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

G>Да ну?!

Ну да.

G>МП — само по себе — очень даже востребовано. Так?

Думаю, это утверждение требует обоснования или, как минимум, уточнения — кем МП востребовано.
Лично я, со своей стороны, на абсолютную истину не претендую. Возможно я не прав. Но мое ощущение именно такое — что МП является далеко не мейнстримным направлением.

G>Есть какие-то причины, по которым МП — при снижении порога вхождения — стало вдруг не востребовано?

А кем оно должно быть востребовано? Всеми? Мной вот не востребовано, например.

ARK>> Хотя бы потому, что мало кто вообще представляет, как это сделать. А кто-то может и думает, что представляет, а в результате его представлений получится неподдерживаемая смесь бульдога с носорогом.
G>А примеры можно?

Нет.

G>А то вот я вижу, что шаблоны плюсов во всю используют... и в качестве МП тоже.

Это, ИМХО, несколько другое.

G>Язык позволяет сделать, так как надо именно тебе, именно сейчас и конкретно в этом месте. Сделать весьма просто.

Угу. А потом придешь на место такого знатока и разгребай кучу мусора, которая черт знает что и значит.

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

А есть еще не аргумент, а факт — у Немерле за много лет не появилось сообщества-коммунити. И обычная реакция людей на Немерле тоже весьма показательна: http://habrahabr.ru/post/239421/

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

I>

I>def a = if (cond) f0() 
I>        else f1()
I>

I>А такая — нет:

I>

I>def a = if (cond) f0()
I>

С чего бы это ?
void можно использовать в качестве результата в Nemerle , чтобы писать более общий код.

using System;
public class Test
{
    public static Main() : void
    {
        def f() {}
        def a = f();
        a;
    }
}

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

_NN>С чего бы это ?
_NN>void можно использовать в качестве результата в Nemerle , чтобы писать более общий код.

_NN>

_NN>using System;
_NN>public class Test
_NN>{
_NN>    public static Main() : void
_NN>    {
_NN>        def f() {}
_NN>        def a = f();
_NN>        a;
_NN>    }
_NN>}
_NN>

То есть ты реально за то, чтобы такой код компилировался?

def a = if(true) 1;

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

I>То есть ты реально за то, чтобы такой код компилировался?

I>

I>def a = if(true) 1;
I>

Тут warning должен быть "пиши так: if(true) _ = 1;"

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

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

_NN>>С чего бы это ?
_NN>>void можно использовать в качестве результата в Nemerle , чтобы писать более общий код.

_NN>>

_NN>>using System;
_NN>>public class Test
_NN>>{
_NN>>    public static Main() : void
_NN>>    {
_NN>>        def f() {}
_NN>>        def a = f();
_NN>>        a;
_NN>>    }
_NN>>}
_NN>>

I>То есть ты реально за то, чтобы такой код компилировался?

I>

I>def a = if(true) 1;
I>

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

Например, операция '=' возвращает 'void'.
Несмотря на это ее можно присвоить дальше и это не ошибка.

_ = _ = _ = ();

_NN>>using System;
_NN>>public class Test
_NN>>{
_NN>>    public static Main() : void
_NN>>    {
_NN>>        def f() {}
_NN>>        def a = f();
_NN>>        a;
_NN>>    }
_NN>>}
_NN>>

I>То есть ты реально за то, чтобы такой код компилировался?

I>

I>def a = if(true) 1;
I>

Я приводил реализацию влоб макроса if-else макроса, с опциональным else
На что WolfHound показал, в чем может быть проблема

Если говорить про Dangling_else, то else всегда привязывается к ближайшему if (вроде привычное всем поведение)

    IF(true)
      IF(false) WriteLine("3434");
      ELSE      WriteLine("3434");

С выражениями вида

def x = IF(true) 1 ELSE 2;

проблем нет никаких — все по прежнему (относительно Немерле).

Если опустить ELSE рождается Warning.

Но его можно убрать стандартным способом

IF(true) _ =  1;

Если опустить ELSE (допустим случайно) и попытаться запомнить результат,

    
    def y = IF(true) 1;
    WriteLine(y);

то в итоге разобьемся об его использование (или об очередной ворнинг, если никакого использования нет).

Вроде никаких шокирующих новостей.

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

I>Конкретная ситуация — это чистой воды пуризм авторов.

Хуже. Это просто артефакт, ошибка проектирования (может даже и в угоду чистоте линий, не важно). А поправить то ли лень, то ли совместимость поломает.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

ARK>А есть еще не аргумент, а факт — у Немерле за много лет не появилось сообщества-коммунити. И обычная реакция людей на Немерле тоже весьма показательна: http://habrahabr.ru/post/239421/

Да там и пример показателен. MVC, основная идея которого — отделить шаблоны страниц от контроллеров, объективно становится основным .net фреймворком для веба. А там все с точностью до наоборот — давайте смешаем контроллер и вьюху в одно целое.
Нет, я вполне верю что, при правильном подходе, и в NemerleWeb можно расцепить вьюхи и контроллер. Но пример в статье ...!
Все это демонстрирует одну важную вещь — рулят не столько крутые инструментальные фигушечки, сколько правильная концепция. А в проектировании языков оно рулит еще больше, чем в проектировании фреймворков. А уж как это реализовано — вопрос хоть и тоже важный, но второго порядка.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

I>И, вообще, это самая малая из проблем, которые сейчас есть у Немерле.

Сама по себе — да. Но из кучи таких проблемок складывается картинка. Тут, ИМХО, без вариантов: хочется создать коммьюнити — без целенаправленной работы над устранением лишних шероховатостей с C# не обойтись. Причем это необходимое, но не достаточное условие.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

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

I>Ещё раз говорю, такой код очевидно не должен компилироваться:

I>

I>def a = if (cond) f0()
I>

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

Возможно, вам что-то там и очевидно. А я, например, не понимаю почему этот код "очевидно не должен компилироваться"?! В erlang, например, аналогичная конструкция очень даже компилируется

Поймите, если пойти по пути F# (а в нем примерно такой if, который, как я понимаю, вам так хочется), то компилироваться перестанет и просто

if (cond) f0()

при условии, что f0() вычисляется не в void. Собственно, предложенная вами конструкция, "очевидно не компилируется" по причине не возможности вычислить if, а не выполнить assignment. А если вычисление таки прошло, и мы получили свой "заветный" void, то и assignment будет вычислен успешно (на что вам ниже и указал _NN_). Просто нет причин, по которым он "очевидно не должен" этого делать

Я так понимаю, что вам хотится таки честный statement. А их нету

I>Я считаю, что текущая ситуация никому ничего не даёт, но в то же время отпугивает новичков, тем что "в Немерле два синтаксиса для if".

Ну т.е. в C# "два синтаксиса для if" их, надо понимать, не пугает. А вот в Nemerle — аж по коленкам бежит?!

---
С уважением, Константин Сиваков

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

G>>МП — само по себе — очень даже востребовано. Так?

ARK>Думаю, это утверждение требует обоснования или, как минимум, уточнения — кем МП востребовано.

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

Исключением можно, наверное, признать лишь lisp. Но, там особые прикладники, и там, кстати, "это норма"

ARK>А кем оно должно быть востребовано? Всеми? Мной вот не востребовано, например.

А вы таки пробовали?! А если бы у вас был более нормальный инструмент?

G>>А то вот я вижу, что шаблоны плюсов во всю используют... и в качестве МП тоже.

ARK>Это, ИМХО, несколько другое.

В чем другое-то?!

G>>Язык позволяет сделать, так как надо именно тебе, именно сейчас и конкретно в этом месте. Сделать весьма просто.

ARK>Угу. А потом придешь на место такого знатока и разгребай кучу мусора, которая черт знает что и значит.

Ну т.е. не пробовали

ARK>А есть еще не аргумент, а факт — у Немерле за много лет не появилось сообщества-коммунити. И обычная реакция людей на Немерле тоже весьма показательна: http://habrahabr.ru/post/239421/

И виной всему, следует полагать, if/else?!

---
С уважением, Константин Сиваков

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

G>Поймите, если пойти по пути F# (а в нем примерно такой if, который, как я понимаю, вам так хочется), то компилироваться перестанет и просто
G>

G>if (cond) f0()
G>

G>при условии, что f0() вычисляется не в void. Собственно, предложенная вами конструкция, "очевидно не компилируется" по причине не возможности вычислить if, а не выполнить assignment. А если вычисление таки прошло, и мы получили свой "заветный" void, то и assignment будет вычислен успешно (на что вам ниже и указал _NN_). Просто нет причин, по которым он "очевидно не должен" этого делать

Действительно, def a = when (true) 1; вполне себе присваивает "a" void. Если честно, не знал этого раньше.
Только я всё-таки не понимаю, что это меняет. if без else может быть фактически аналогом when, то есть тот же if, тело которого возвращает void. Единственная проблема в том, что компилятор не даёт warning, если внутри тела будет вычислено значение, которое в последствие не используется. Но учитывая то, что левая часть станет void, компиляция у тебя так и так завершится с ошибкой.

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

AVK>Да там и пример показателен. MVC, основная идея которого — отделить шаблоны страниц от контроллеров, объективно становится основным .net фреймворком для веба. А там все с точностью до наоборот — давайте смешаем контроллер и вьюху в одно целое.

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

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

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

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

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

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

I>Действительно, def a = when (true) 1; вполне себе присваивает "a" void. Если честно, не знал этого раньше.
I>Только я всё-таки не понимаю, что это меняет. if без else может быть фактически аналогом when, то есть тот же if, тело которого возвращает void. Единственная проблема в том, что компилятор не даёт warning, если внутри тела будет вычислено значение, которое в последствие не используется. Но учитывая то, что левая часть станет void, компиляция у тебя так и так завершится с ошибкой.

Получается, что проблемы нет.

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

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

I>>Действительно, def a = when (true) 1; вполне себе присваивает "a" void. Если честно, не знал этого раньше.
I>>Только я всё-таки не понимаю, что это меняет. if без else может быть фактически аналогом when, то есть тот же if, тело которого возвращает void. Единственная проблема в том, что компилятор не даёт warning, если внутри тела будет вычислено значение, которое в последствие не используется. Но учитывая то, что левая часть станет void, компиляция у тебя так и так завершится с ошибкой.

_NN>Получается, что проблемы нет.

О том и разговор. Осталось только позволить использовать if без else

Здравствуйте, 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.

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

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

Рабочая. Именно этот подход использовал.
Немного воспоминаний

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

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

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

EP>Да и вообще не представляю выживет ли он с таким мощным антипиаром от VladD2

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

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

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

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

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

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

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

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

Здравствуйте, 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 популярен. Интересная логика.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

Здравствуйте, 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 тоже из МС произошел, такая незадача.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

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

I>>Потому что это разные паттерны.
AVK>Аргументище!
Я их противопоставляю, потому что это разные паттерны. И на клиентской стороне они друг с другом конкурируют. Что тут непонятного?

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

AVK>>>И именно поэтому MVC популярен. Интересная логика.
I>>Нет. Именно поэтому MVVM не так популярен, как MVC.
AVK>Вот ведь МС какая злая

Вот только и ASP.NET MVC тоже из МС произошел, такая незадача.
MVC был придуман задолго до MS. MVVM родился именно там (хоть у него и были прародители).

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

_>Это ты видимо C# библиотеки хочешь включить в список библиотек Nemerle? ) Потому как если говорить о его родных, то их думаю поменьше чем даже у D, у которого всё довольно печально.

Ты несешь настолько явную чушь, что на нее очень тяжело отвечать сдержанно и аргументированно. Ведь тяжело аргументировать банальные и очевидные вещи.

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

У Немерла есть одна малюсенькая либа в которой находятся типы и функции небходимые для работы самого языка и несколько неизменяемых коллекций удобных в функциональном коде.

Все дотнетные библиотеки являются родными для немерла. Зачем мене писать, например, библиотеку ввода–вывода, если она уже есть в дотнете?

_>Всё правильно. Это известный замкнутый круг. Он в различных ипостасях присутствует во многих местах индустрии. Например с некоторыми видами ПО под линухом. И решается это обычно (если вообще решается

) поворотом какой-то одной крупной компании (пример Steam под линух).

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

_>Они как раз ничего не запретили. Obj-C вполне себе продолжает жить. Правда он настолько убогий, что все нормальные программисты с радостью сами убегут с него на Swift. )))

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

_>Ну и кстати на .net этот язык совсем не похож. Начнём с его организации памяти, компиляции и т.п. Он скорее похож на упрощённый (без МП) и чуть более изящный D. Т.е. он вполне хорошо позиционируется на место современного системного языка, в отличие от Java/C#.

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

О сходстве с Ди интересно услышать в двойне. Например каковы в Ди аналоги паттерн–матчинга и алгебраических типов данных.

Хотя про организацию памяти тоже очень интересно услышать.

_>Не совсем так. В данном случае за языком стоит производитель ОС и производитель главной IDE под эту ОС. Т.е. мы заранее имеем гарантии наличия всех необходимых инструментов для языка.

VD>>Но такие как вы будут учить как надо делать. Что надо делать. Как маркетинг проводить... И это вместо того чтобы взять и помочь в развитии.

_>Я как раз ничего не советовал. ) Я лишь указал на наличие проблемы у Nemerle (такой же как и у D и т.п.), а как её решить у меня нет идей. Ну если конечно кто-то из монстров вдруг не повернётся к языку.

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

VD>>Но ведь фига два ты возьмешься помогать. Критиковать то куда проще. Правда?

_>Совершенно верно. Мне сейчас интересны только готовые отточенные инструменты, а времени заниматься доработкой потенциально интересных у меня нет — через полгода надо новый продукт выдать (причём реально инновационный, а не очередные формочки к БД).

Ты потратил довольно много времени в этой теме. Потратил бессмысленно, если не сказать — "во вред". За это время ты мог бы с тем же Ди разобраться. Глидишь он все же подошел бы для ваших проектов и ты бы сэкономил туче времени в будущем.

Кстати ты так и не сказал, над какого рода проектами вы работаете, что без С++ в них не обойтись.

_>Но разве от этого факта моё мнение о продукте становится менее правильным? )

Я бы сказал, что оно вообще из пальца высосано. Правильным оно может быть толко случайно.

_>Ммм, понимаешь... Мне, как потребителю продукта, не особо принципиальны причины всего этого. Главное сам факт, что у Swift'a оно есть/будет, а у Nemerle в данный момент нет.

Да даже не спорю. Мне просто интересно кто это загадочное "оно"? Комьюнити? Ну тык вы и есть это комьюнити. И пока вы будете потреблять любое говно каторое вам подсовывают маркетологи и корпорации вы не дадите пробиться чему–то стоящему.

Свифт образца 2014-го года недотягивает до Немерла образца 2006-го года. У Немерла есть и IDE, и библиотеки. Он прожил уже 10 лет и умирать не собирается. Но миллионы мух сбегаются на форум, чтобы потоптаться здесь своими грязными лапками и позлорадствовать над отсутствием огромного комьюнити.

_>Т.е. деньги это или пиар или ещё нюансы какие-то, типа упоминаемых мною выше,

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

_>результат то один и именно он важен при выборе инструмента для работы.

О бабле и пиаре я тебе сказал в самом начале. Но ты начал спорить. В итоге мы пришли к тому, что кроме бабла и пиара за наукообразным термином "инфраструктура" не стоит.

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

EP>Это естественно следует из факта, что макро-проект по сути является плагином к компилятору. Делая плагин к Clang'у на C++, можно использовать библиотеку X, которая будет доступна и для использования в программе компилируемой Clang'ом.
EP>Из этого также следуют и ограничения подхода — пока работает плагин компилятора, результат ещё не скомпилирован, и его нельзя использовать во время работы плагина (что справедливого и для плагина к Clang'у, и Nemerle).

Ну, и? Капитан очевидность?

Так и есть.

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

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

В общем не понимаю, что ты тут хочешь доказать.

EP>Это как раз uber-wunderwaffe, с этим никто и не спорит, я даже неоднократно соглашался. (зачем опять-то повторять эту мантру?)

А с чем ты вообще споришь и зачем?

EP>Хорошо бы было ещё иметь хороший оптимизатор в придачу, то есть чтобы можно было сразу генерировать более высокоуровневый код, без всякого penalty.

Да, не плохо. И что? Почему это не мешает тебе использовать Шара. Ведь оптимизатор у него с немерлом один и тотже.

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

VD>А кто называл шаблон макросом? Тебе сказали простую и очевидную мысль — шаблоны, как и макросы работают во время компиляции и манипулируют кодом (АСТ–ом), а не рантайм–данными (как Питон, например). Ты в ответ привел констэкспрешоны — которые к шаблонам особого отношения не имеют, а являются хаком позволяющим писать функции, которые можно вычислять как во время компиляции, так и в рантацме. Ну, дык любую (а не только констэкспр) функцию немерла так же можно променять когда угодно.
VD>В общем не понимаю, что ты тут хочешь доказать.

Ещё раз:

EP>Естественно что аналогичный результат можно получить и другими способами, речь-то не об этом.
EP>Выше было заявлено, что шаблоны это фактически препроцессор, что макросы Nemerle это надмножество шаблонов, и что на них можно сделать всё то, что и на шаблонах.
EP>Я привёл контраргумент, а потом конкретный пример в поддержку этого аргумента.
EP>constexpr там лишь усиливает эффект, но грубо говоря не обязателен. И там не два шаблона, а шаблон функции и функция.

EP>>Это как раз uber-wunderwaffe, с этим никто и не спорит, я даже неоднократно соглашался. (зачем опять-то повторять эту мантру?)
VD>А с чем ты вообще споришь и зачем?

Где именно? — тут уже много под-веток

А то что макросы это крутая штука, я сказал практически в начале топика, и ты это даже прочитал (так как ответил), но всё равно ведёшь себя так, как-будто "кругом враги! Nemerle в опасносте!"

EP>>Хорошо бы было ещё иметь хороший оптимизатор в придачу, то есть чтобы можно было сразу генерировать более высокоуровневый код, без всякого penalty.
VD>Да, не плохо. И что? Почему это не мешает тебе использовать Шара. Ведь оптимизатор у него с немерлом один и тотже.

Там где скорость не нужна, в основном использую Python (который на голову гибче C#, и даже более кросс-платформенный). Если понадобится именно .NET — обязательно посмотрю на Nemerle (наверное уже раз третий повторяю).
Даже так, практически везде где мне нужны DSL'и — требуется скорость, значит нужно генерировать C++. Тут основной выбор — либо метапрограммирование на шаблонах (что мягко-говоря громоздко), либо внешняя генерация кода, причём особо не важно чем (в этом плане Nemerle даёт минимум).
Если же нужен DSL, но без скорости — то можно и просто строчки в runtime парсить и интерпретировать

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

VD>>Я считаю, что ты зазнался малость и превозносишь этот С++, так как сотворил себе из него кумира.

_>У тебя какое-то нарушение в логике. ) Эта фраза имела бы смысл, если бы я был автором C++. )

С логикой проблема как раз у тебя, так как превозносить можно и язык автором которого ты не являешься. Именно это ты и делаешь.

_>Для этого надо знать об устройстве этой памяти, и не только её.

1. С какого ражна мне нужно знать об устройстве памити, если С и С++ как раз и ценны тем, что предлагают бнезависимую абстракцию — указатель?

2. Об устройстве этой памяти расказывают в любом программистском ВУЗ–е.

Вранье это все. В С++ самый важный скил — это умение обходить грабли заботливо расставленные автором языка в порыве оставить совместимость с С и в борьбе за эффективность.

_>Безусловно. Но сам язык будет ему позволять решать далеко не все задачи. Если круг задач укладывается в возможности этого нового языка, то почему бы и нет. )

Устал тебе повторять о твоем предвзятом отношении. В реальности задач которые нельзя решать на яве или дотнете крайне мало.

Сейчас на управляемых языках пишут такие требовательные к производительности вещи как IDE и компиляторы.

Еще раз задаю тот же вопрос: какие задачи решаете вы на работе (на плюсах) ?

_>А кто-то с этим спорил? ) Естественно хочется язык с возможностями C++, но при этом с простотой Python'а или вообще JavaScript. Но это же пока только мечты... )))

Ты себе сочинил сказки про фатальный недостаток в производительности дотнета с свой и отказываешся в упор видеть тот самый язык, что даст фору Питону с Жабоскрипом.

_>О да, очень мало.))) С удовольствием посмотрю на реализацию сложной фильтрации в реальном времени FHD/4K видео на скажем Java... Если что, это очень даже актуальная сейчас задача в целом ряде направлений.

Да — мало. Один твой пример (весьма спорный) этотутверждение не опровергает. Задач которые приемлемо решаются на дотнете и яве несравнимо больше. На немерле есть макрос преобразующий немерловый код в CODE. Твой С++ будет нервно курить на задачах решаемых на GPU.

_>А на Nemerle вообще можно удобно писать скрипты? )

А ты (для себя) сначала сформулируй определение этого термина. Если это окажется — быстрым написанием кода автоматизации рутинных операций, то вполне можно. Тут дело в уровне языка и возможностях его специализации под задачи.

_>1. Ты говорил, что в 2006-ом бросил, так что и C++11 не застал (а это заметно большее изменение).

В С++ не появилось ничего радикально нового. Все изменения перечислены в вики легко изучаются за вечер. Неужели ты думаешь я этого не сделал?

Что до библиотек, ты мы щи тоже не лаптем хлебали. У нас были свои смартпоинтеры с политиками владения. С++ 11 всего лишь поднял производительность и позволил отличать некоторые случаи (засчет &&). У нас все это было. Только с большим числом копирований и на конвенциях. Радикально этот && ничего не мешает. Остальные изменения вообще по большей части косметика. Кривые лябды — это хорошо, но и раньше были выкрутасы в разных бустах. Ну, а того же полноценного функционированого типа так и не ввели. В каждом компиляторе под std::function может быть скрыто что угодно. Бинарногоформата нет. Совместимость только через С–экспорт/импорт. Модульности нет. Управление память — ручное. Интеллисенс в больших проектах всегда ломается, так как дизай языка на него не расчитан. Причем новшества только ухудшают ситуацию разрешая глобальный вывод типов. Короче, допотопный язык с тучей нерешенных проблем.

_>2. Мой текущий компилятор C++ отлично поддерживает стандарт C++14 — с кактуса MS мы слезли давным давно. )))

И куда девается хваленая стандартность и совместимость? И ты еще по инфраструктуру говоришь? А сколько тулов (IDE и т.п.) его поддерживает?

_>4. Что касается моих отношений с C#, то они имеют весьма продолжительную основу. ))) Помнится я ещё с Доном Боксом спорил на эти темы — вот это настоящий пропагандист .net'а, не чета народу с этого форума (как он программировал в блокнотике помнится). А первым моим приложением на C# были животинки для Террариума, на конкурс. Если ты в курсе о чём я. )))

Мне не интересны твои дисскуссии с еванголистами Майкрософт. Я спросил — "сколько серьезных проектов ты написал на Шарпе?". Добавлю вопрос: с какими проблемами ты в них столкнулся. Похоже, что знакомство с языком ограничилось играми на конкурсе, а зниние о производительности основано на домыслах.

Вот просто ответь на простой вопрос. Нужна ли производительнось в IDE? И, если — да, то почему же их с успехом пишут на дотнете и яве, а нативный код выбрасывают?

_>Вот у меня на компьютере установлена огромная куча ПО. И из него всего только одно приложение написано на .Net. Кстати, у него как раз самый страшный интерфейс из всех и оно живёт у меня на компьютере только по необходимости (системная хрень). Плюс имеется два приложения на Java. Надо признать что приятных. А все остальные десятки приложений — это или натив или натив+скрипт. И это всё явно не "игры или браузеры". Так кто из нас живёт в виртуальной реальности? )

К сожалению, опять вынужден констотировать проблемы в твоей логике. Какая связь между твоим софтом и возможностью писать софт на дотнете? Ну, а про скрипты вообше смешно. Если софт можно написать на тормозном скрипте, то его уж точно можно написать на дотнете.

Ладно. Отвечать с телефона на такие простыни нет ни желания, ни сил.

Здравствуйте, VladD2, Вы писали:

VD>Твой С++ будет нервно курить на задачах решаемых на GPU.

Ты ври-то, да не завирайся.
Для GPGPU основная задача в том, чтобы написать быстрое ядро. Там шаг влево, шаг вправо — и просадка по скорости на порядок. Причём если скорость сильно потерянна, то и смысла заморачиваться с GPGPU нет.
А уж как там ты будешь описывать ядра — на DSL'е, на Nuda, на C++ AMP, на CUDA, на голом OpenCL, на OpenACC, на TaskGraph — рояли не играет. Точнее из этого ряда немного выделяется только TaskGraph — так как умеет автоматически оптимизировать ядра под конкретные данные, на лету.

Здравствуйте, Ikemefula, Вы писали:

I>Я эту хохму слышу постоянно. И постоянно ловлю себя на том, что приходится рыться в коде либы, ибо автор забыл указать например нюансы многопоточности, косяки, безопасности и тд и тд

Какие проблемы? Смотри сгенерированный макрой код. Смотреть код макры для этого не надо.

Ты, видимо, по опыту из С++ судишь. Там сгенерированных исходников увидеть нельзя. И это проблема. Но не МП, а плюсов. У Немерла ее нет. Исходники может генерить сама макра или их можно добыть декомпилятором.

Здравствуйте, ionoy, Вы писали:

I>Для приложений, в которых представление связано с моделью биндингами, имхо, лучше подходит MVVM. То, что популярные client-side фреймворки выбрали MVC, это повторюсь в угоду пользователям, которые просто привыкли к MVC. MVVM
I>в таких сценариях удобнее.

Вот эта мысль, причем с обоснованием, должна быть первой во вводной стать по НВеб.

Здравствуйте, AndrewVK, Вы писали:

K>А в вашем примере, напоминаю, все с точностью до наоборот, логика тщательно размешана с представлением.

А можно по подробнее описать это смешивание, а то я его в упор не вижу. Или ты считаешь смешиванием размещение кода модели и представления внутри одногофайла?

Здравствуйте, VladD2, Вы писали:

VD>Ты несешь настолько явную чушь, что на нее очень тяжело отвечать сдержанно и аргументированно. Ведь тяжело аргументировать банальные и очевидные вещи.

VD>Я просто не понимаю на каком основании нужно говорить только о "родных" библиотеках. Ну, какого черта рассуждая о Шарпе у тебя не приходит на ум считать библиотеки дотнета не родными для шарпа и "не засчитывать" их наличие.

VD>У Немерла есть одна малюсенькая либа в которой находятся типы и функции небходимые для работы самого языка и несколько неизменяемых коллекций удобных в функциональном коде.

VD>Все дотнетные библиотеки являются родными для немерла. Зачем мене писать, например, библиотеку ввода–вывода, если она уже есть в дотнете?

Вот на языке C существуют тысячи библиотек, почти на все случаи жизни. Однако почему-то глупые программисты на C++ любят переписывать их на C++ не смотря на то, что любая библиотека на C является родной для C++. Как ты думаешь, почему? )

Могу подсказать: если библиотека написана на C++, то пользоваться ею намного удобнее, благодаря возможностям языка (в сравнение с C). Аналогично должно быть и с Nemerle. Конечно при условии, что Nemerle предоставляет какие-то расширенные возможности в сравнение с C#. Но ведь если нет, то тогда зачем он вообще нужен? )

VD>Ну, так не фига выдумывать сказки про какую–то там инфраструктуру, которую ты даже описать не можешь. Все упирается в брэнд, бабло и рекламу.

Вот снова ты ничего не понимаешь. Пользователи не идут на линух не потому, что у него нет пиара, а потому что там нет нужного софта. А софта нет, потому что там мало пользователей и производители соответствующего софта не тратят усилия на разработку под эту платформу. Как видишь, в данном круге никаких упоминаний бабла или пиара нет.

И да, разрывается этот круг вложением крупной компании. Но не тупо бабла и уж точно не в пиар. Если мы говорим допустим про игры (одна из главных проблем в линухе для домашних пользователей) и пример Steam'а, то там ведущий распространитель и один из солидных разработчиков игр вложился в том смысле, что доработал свою платформу под Линух и начал делать под него игры. Теперь бы ещё в паре областей (например в CAD и т.п.) кто-то из лидеров рынка аналогично вложился и Линух совсем хорош станет в смысле ПО.

VD>О, как? Становится веселее! С этого места, пожалуйста, по подробнее. В чем схожесть с Ди и различие с дотнетом? Только чер с примерами.

Работа с голыми указателями естественно. ) Swift — это полноценный системный язык, как и D. В отличие от языков .net.

VD>О сходстве с Ди интересно услышать в двойне. Например каковы в Ди аналоги паттерн–матчинга и алгебраических типов данных.

Вот ты как раз перечислил ту пару мелких дополнений в Swift'e, которые отсутствуют в D. Аналогично есть ещё и куча возможностей в D, которые не взяты в Swift. Но в целом по сумме возможностей и подходов D является наверное самым близким сейчас к Swift'у.

VD>Хотя про организацию памяти тоже очень интересно услышать.

А что там говорить то, если в .net у нас сборщик мусора, а в Swift используется классический для всей платформы Apple ARC (разновидность подсчёта ссылок, но весьма эффективная на 64 битных процессорах).

_>>Я как раз ничего не советовал. ) Я лишь указал на наличие проблемы у Nemerle (такой же как и у D и т.п.), а как её решить у меня нет идей. Ну если конечно кто-то из монстров вдруг не повернётся к языку.

VD>Ты выдвинул гипотизу об отсутствии инфраструктуры. При попытке обяснить этот термин напридумывал что–то мало относящееся к реальности. Здравыми мыслями были комьюнити и большая компания. Но причем тут загадочная инфраструктура? Может пора признать, что ты в чем–то заблуждаешься?

Комьюнити — это и есть часть инфраструктуры. А большая компания к инфраструктуре прямого отношения не имеет, но может быть гарантией создания других компонентов инфраструктуры (IDE, компиляторов, отладчиков, библиотек и т.п.)

VD>Ты потратил довольно много времени в этой теме. Потратил бессмысленно, если не сказать — "во вред". За это время ты мог бы с тем же Ди разобраться. Глидишь он все же подошел бы для ваших проектов и ты бы сэкономил туче времени в будущем.

Ну так отдыхать то тоже иногда надо. ) Я на этом форуме отдыхаю и развлекаюсь (ну максимум помогаю кому-то советом), а не работаю.

С D я уже давно разобрался. Мы делали стажёрский проектик на базе этой http://vibed.org штуки. Однако для основных наших дел D пока не особо подходит. Ну и у меня есть подозрение, что он уже не взлетит. Просто потому, что современный C++ начал быстро развиваться и как раз в сторону D. Собственно на мой взгляд вполне возможно модернизировать C++ почти до всех возможностей D без потери обратной совместимости. Возможно сможет взлететь Rust, т.к. он более радикален и до него C++ не получится развиться никакими эволюционными методами.

VD>Да даже не спорю. Мне просто интересно кто это загадочное "оно"? Комьюнити? Ну тык вы и есть это комьюнити. И пока вы будете потреблять любое говно каторое вам подсовывают маркетологи и корпорации вы не дадите пробиться чему–то стоящему.

Оно — это инфраструктура конечно же. )

VD>Свифт образца 2014-го года недотягивает до Немерла образца 2006-го года.

Смешное сравнение. Nemerle можно сравнивать со Scala (как с конкурентом) или с Java/C# (как с нижележащей платформой). А языки типа C++, D, Rust, Swift — это другой мир, в котором нижележащим базисом является C.

VD>Да, нет ничего выше кроме домыслов. Остаются только денги, пиар и брэнд. Но ты стакательно не хочешь признавать, это не инфраструктура, а маркетинговые ресурсы.

VD>О бабле и пиаре я тебе сказал в самом начале. Но ты начал спорить. В итоге мы пришли к тому, что кроме бабла и пиара за наукообразным термином "инфраструктура" не стоит.

Это не мы пришли к такому выводу, а ты. Не заметив в упор указаний на то, что за языком стоит производитель главной IDE для платформы (т.е. автоматом получаем с ходу большую часть инструментов) и производитель ОС (т.е. автоматом все библиотеки ОС являются нативными для этого языка). Да, бренд и деньги безусловно тоже играет роль, но если бы новый язык предложил к примеру Samsung, то это вряд ли особо ему помогло бы на старте...

Здравствуйте, VladD2, Вы писали:

VD>С логикой проблема как раз у тебя, так как превозносить можно и язык автором которого ты не являешься. Именно это ты и делаешь.

Превозносить безусловно можно. Но это уже не будет зазнайством, в котором ты меня обвинил. ) Кстати, а вот когда ты говоришь аналогичное про Nemerle, то...

Ну и кстати я C++ совсем не превозношу. Это довольный ужасный язык и я могу перечислять сотни его недостатков. Просто все другие ещё хуже. По сумме параметров конечно же, включая и инфраструктурные.

VD>1. С какого ражна мне нужно знать об устройстве памити, если С и С++ как раз и ценны тем, что предлагают бнезависимую абстракцию — указатель?

Имеется в виду не об устройстве конкретной платформы (хотя для максимального быстродействия тоже не плохо бы), а о тех же самых указателях. К примеру пользователю Java вообще не надо знать, что такое существует в природе.

VD>Вранье это все. В С++ самый важный скил — это умение обходить грабли заботливо расставленные автором языка в порыве оставить совместимость с С и в борьбе за эффективность.

Возможно. ))) Но других то альтернатив особо не видно. )

VD>Устал тебе повторять о твоем предвзятом отношении. В реальности задач которые нельзя решать на яве или дотнете крайне мало.

Смешно. ) Хотя если ты говоришь про всякие формочки внутрикорпоративные, то тогда конечно же можно согласиться. )

VD>Ты себе сочинил сказки про фатальный недостаток в производительности дотнета с свой и отказываешся в упор видеть тот самый язык, что даст фору Питону с Жабоскрипом.

У дотнета полно недостатков и без проблемы с производительностью. Но в нашем случае было бы достаточно уже этой проблемы.

Ну у насчёт сочинил... Я не очень понял, ты хочешь сказать, что производительность .net сравнима с решениями на C++ или что? ) Вроде как где-то выше ты соглашался, что отставание имеет место.

VD>Да — мало. Один твой пример (весьма спорный) этотутверждение не опровергает. Задач которые приемлемо решаются на дотнете и яве несравнимо больше. На немерле есть макрос преобразующий немерловый код в CODE. Твой С++ будет нервно курить на задачах решаемых на GPU.

Ну так я могу ещё накидать примеров, если надо)))

VD>А ты (для себя) сначала сформулируй определение этого термина. Если это окажется — быстрым написанием кода автоматизации рутинных операций, то вполне можно. Тут дело в уровне языка и возможностях его специализации под задачи.

Я пока про более банальные вещи спрашиваю. Могу ли я создать текстовый файл с содержимым вида:

import os
os.system('notepad')

и чтобы по клику на нём в Проводнике запустился блокнот? )

Ключевым тут естественно является объём кода и удобство его исполнения.

_>>2. Мой текущий компилятор C++ отлично поддерживает стандарт C++14 — с кактуса MS мы слезли давным давно. )))
VD>И куда девается хваленая стандартность и совместимость? И ты еще по инфраструктуру говоришь? А сколько тулов (IDE и т.п.) его поддерживает?

Это вопрос к MS. ))) Собственно они всегда этим отличались, но как говорится "есть нюансы". Когда они плевали на стандарты в том смысле что отрывались от них будущее (т.е. их решения были лучше стандартов), то это им многими (в том числе и нами) прощалось. Но когда они стали банально отставать и халтурить — нет, спасибо, прощайте. )

Да, а с инфраструктурой как раз всё отлично) GCC поддерживают все инструменты. Собственно многие поддерживают только его. ))) Хотя clang сейчас тоже сильно продвинулся. У него есть плюс в более вменяемых сообщениях об ошибках, но при этом по быстродействию создаваемого кода он пока отстаёт. Ну и конечно ещё ICC, но это отдельная песня. )))

VD>Мне не интересны твои дисскуссии с еванголистами Майкрософт. Я спросил — "сколько серьезных проектов ты написал на Шарпе?". Добавлю вопрос: с какими проблемами ты в них столкнулся. Похоже, что знакомство с языком ограничилось играми на конкурсе, а зниние о производительности основано на домыслах.

Вообще то разные сравнивательные тесты производительности мы даже прямо на этом форуме делали. И пока что ни один сторонник .net'a не смог представить решения, дотягивающегося до представляемых мною версий на C++. Причём это в основном были тесты (кстати, парсеры например и т.п.) ещё и не из моей профильной области. А если взять оттуда, то вообще смешно будет.

VD>Вот просто ответь на простой вопрос. Нужна ли производительнось в IDE? И, если — да, то почему же их с успехом пишут на дотнете и яве, а нативный код выбрасывают?

Вообще то я знаю ровно одну ide, которую переписали с нативного языка на управляемый. Причём это очевидно имело политический смысл (кстати, всю эту политику демонстративного забвения нативной разработки не так давно свернули, но уже поздно — большинство нативных разработчиков уже ушли с их инструментов), т.к. данная компания проталкивала совсем другие инструменты. Да, кстати... И я помню сколько ругани на тормознутость той первой версии было тогда на форумах. )))

_>>Вот у меня на компьютере установлена огромная куча ПО. И из него всего только одно приложение написано на .Net. Кстати, у него как раз самый страшный интерфейс из всех и оно живёт у меня на компьютере только по необходимости (системная хрень). Плюс имеется два приложения на Java. Надо признать что приятных. А все остальные десятки приложений — это или натив или натив+скрипт. И это всё явно не "игры или браузеры". Так кто из нас живёт в виртуальной реальности? )
VD>К сожалению, опять вынужден констотировать проблемы в твоей логике. Какая связь между твоим софтом и возможностью писать софт на дотнете? Ну, а про скрипты вообше смешно. Если софт можно написать на тормозном скрипте, то его уж точно можно написать на дотнете.

Что значит какая связь? Я же тоже пользователь. Я предлагаю посмотреть какой процент нативного/управляемого софта стоит на машине среднестатистического пользователя. Для начала я взял в рассмотрение себя. Я конечно совсем не среднестатистический пользователь, но это идёт как раз в пользу управляемым языкам, т.к. тех двух программок на Жабке у них точно не будет. А вот большинство нативных будет...

Что касается скриптов. Ты читай внимательно. У меня написано натив+скрипт, а не просто скрипт. Это абсолютно разные вещи. Чтобы было понятно о чём речь, могу привести простейший пример. Ну скажем одна из самых популярных онлайновых игр сейчас, танчики (WoT). Написана на C++ с управляющей игровой логикой на встроенном Python'е (ну точнее там ещё Flash есть в роли GUI библиотеки, но это уже мелочь). На мой взгляд вполне оптимальное решение, сочетающее в себе и быстродействующий код и быструю разработку. Ну и что ты хочешь переписать тут на .net?

Здравствуйте, DarthSidius, Вы писали:

DS>Гы ) Открою тебе секрет: ложки... библиотек C# не существует. Существуют только библиотеки .Net

Юмор хорош только если он по делу. ) А тут боюсь что нет. См. мой ответ Владу.

Здравствуйте, VladD2, Вы писали:

VD>Кроме того в продвинутых GC (к сожалению пока что имеющихся только в Яве) есть такие фишки как escape analysis которые позволяют в автоматическом режиме применять оптимизации вроде размещения памяти в пуле или на стеке для объектов не прикапываемых внутри функций.

Вот собственно говоря это "продвинутое" решение, которое иногда может сработать в некоторых реализациях на Java и является полным аналогом стандартной работы с памятью в C++. )))

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, DarthSidius, Вы писали:

DS>>Гы ) Открою тебе секрет: ложки... библиотек C# не существует. Существуют только библиотеки .Net

_>Юмор хорош только если он по делу. ) А тут боюсь что нет. См. мой ответ Владу.

У меня серьезное сообщение. А ты насмешил. Так бывает — от незнания предмета. Это одно из важных преимуществ платформы — неважно на каком языке написаны библиотеки, использовать их могут все. И ты извини конечно, но твое сообщение Владу — ахинея.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

Здравствуйте, alex_public, Вы писали:

_>Ну и кстати я C++ совсем не превозношу. Это довольный ужасный язык и я могу перечислять сотни его недостатков. Просто все другие ещё хуже. По сумме параметров конечно же, включая и инфраструктурные.

Ты себе создал уютный теплый мирок, где тебе более менее все знакомо. И не желая выходить из него говоришь: "мне и здесь хорошо, а там снаружи все плохо". Ну сиди в своем мирке, но зачем всем вокруг доказывать, что, то что вовне — авно?

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

Здравствуйте, DarthSidius, Вы писали:

DS>У меня серьезное сообщение. А ты насмешил. Так бывает — от незнания предмета. Это одно из важных преимуществ платформы — неважно на каком языке написаны библиотеки, использовать их могут все. И ты извини конечно, но твое сообщение Владу — ахинея.

До тебя так и не доходит? ) Использовать то конечно могут, но зачем они такие неполноценные нужны в продвинутом языке? Или быть может ты хочешь сказать, что все C# библиотеки архитектурно рассчитаны на приём алгебраических типов данных (из того же F#)? Про макросы Немерле я вообще молчу.

Тут имеется полная аналогия с языком C и языками предоставляющими свободное использование библиотек на нём (C++, D, Rust, Swift и т.д.). Использовать безусловно можно, но лучше переписать на самом языке, чтобы можно было использовать исключения, передавать классы или вообще шаблонные параметры и т.п.

Да, и кстати если F# вряд ли можно назвать успешным примером, то есть на эту тему и очевидные успешные образцы. Предлагаю взглянуть на Scala и оценить количество родных библиотек на нём. Хотя там опять же доступны все библиотеки на Java, которые уж точно есть на все случаи жизни (сравнимо с C).

Здравствуйте, DarthSidius, Вы писали:

DS>Ты себе создал уютный теплый мирок, где тебе более менее все знакомо. И не желая выходить из него говоришь: "мне и здесь хорошо, а там снаружи все плохо". Ну сиди в своем мирке, но зачем всем вокруг доказывать, что, то что вовне — авно?

И какой именно у меня по твоему мирок? ) Потому как "мирок C++" явно не подходит — я и к D присматриваюсь для замены C++ и к Rust и к Swift. И прямо сейчас использую Python и даже вообще Prolog (совместно с C++). Так что у меня за мирок? Или быть может всё наоборот и это ты живёшь в виртуальном мирке Nemerle? )

Хыхы, я смотрю фанаты Nemerle дружно заминусовали это моё сообщение, но при этом ни один не смог представить ни одного аргументированного возражения. В общем то совсем не удивительно...

Наверное если бы rsdn был бы форумом Nemerle, то меня бы вообще забанили от греха подальше. )))

Кстати, а вот если бы Nemerle был кроссплатформенным системным языком, то я обязательно бы его попробовал даже без наличия какой-либо инфраструктуры. И возможно (если бы понравился, а вообще макросы выглядят интересно) даже стал бы пропагандировать его.

Здравствуйте, Ikemefula, Вы писали:

I>Лямбда это не самая проблемная вещь в плане перформанса.
I>Самые проблемные вещи в перформансе
I>0. кривые алгоритмы и структуры данных, включая встроеные во фремворк
I>1. неправильное кеширование, например из за write barrier
I>2. ленивый код итераторов, генераторов
I>3. неэффективный расход памяти, например конское количество объектов в Gen2 или туча фрагментации
I>4. боксинг-анбоксинг
Ну так с моей точки зрения, единственный способ борьбы с п.1 — это повышение уровня абстракции.
Очень часто проблемы с перформансом вылезают только после передачи проекта в продакшн. Зачастую — далеко не сразу.
В хорошем случае — потому, что программист заложился на нереалистичную статистику использования. Грубо говоря, рассчитывал на 20k пользователей с одной фоткой каждый, а получил 100 пользователей с 10k фоток у каждого. В плохом — потому, что программист вообще не понимает, как работает перформанс, и покрыл исключительно функциональные требования.

Хороший пример — это Linq и запросы с опциональными параметрами. В классическом подходе мы получаем либо хреновый перформанс (where (orderDate = @orderDate or @orderDate is null)), либо ад в поддержке, либо и то и другое, и ещё нечитаемого кода километр.
Linq прячет всю эту кухню за кадром, гарантируя корректность всех 2^N запросов, которые нужно построить для каждого сочетания параметров. А RDBMS гарантирует применение всей мощи оптимизатора к таким запросам, которые не содержат разветвлённой логики.

Менее известный пример — switch statement в C#, который автоматически раскрывается либо в серию if, либо в обращение по словарю. Заниматься выбором стратегии руками — не самое эффективное времяпровождение.

И так везде — чем декларативнее код, тем больше шансов заменить реализацию нижнего уровня.
В C# уже много чего встроено для таких вещей. Но каждой фенечки приходится ждать по три года.
Nemerle — это попытка ответить на вопрос "как мне писать код на более высоком уровне абстракции, чем в C#, сохраняя совместимость с .Net FW".
К сожалению, пока что набор killer examples не перевешивает скепсиса аудитории. Необразованные люди не отличают nemerle от не-немерле; мышление образованных устроено так, что выискивает во всём недостатки, подсознательно считая безусловный восторг признаком некомпетентности.

Здравствуйте, Sinclair, Вы писали:

S>Менее известный пример — switch statement в C#, который автоматически раскрывается либо в серию if, либо в обращение по словарю.

В текущем шарпе switch никогда не раскрывается в серию if. Либо в инструкцию switch в IL, либо в поиск по хештаблице для строк. Единственное, я не помню где поддержка switch по nullable типам реализована — в CLR или в компиляторе C#.

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

Здравствуйте, AndrewVK, Вы писали:

AVK>В текущем шарпе switch никогда не раскрывается в серию if. Либо в инструкцию switch в IL, либо в поиск по хештаблице для строк. Единственное, я не помню где поддержка switch по nullable типам реализована — в CLR или в компиляторе C#.
Я думаю, ты сильно заблуждаешься.

    switch (int.Parse(System.Console.ReadLine()))
    {
      case 123: System.Console.WriteLine(123); break;
      case 678456: System.Console.WriteLine(678456); break;
      case 347645: System.Console.WriteLine(347645); break;
      case 23452: System.Console.WriteLine(23452); break;
      case 1645634: System.Console.WriteLine(1645634); break;
      case 5845: System.Console.WriteLine(5845); break;
    }

Превращается в:

Скрытый текст

    IL_0000: nop
    IL_0001: call string [mscorlib]System.Console::ReadLine()
    IL_0006: call int32 [mscorlib]System.Int32::Parse(string)
    IL_000b: stloc.0
    IL_000c: ldloc.0
    IL_000d: ldc.i4 23452
    IL_0012: bgt.s IL_002b

    IL_0014: ldloc.0
    IL_0015: ldc.i4.s 123
    IL_0017: beq.s IL_0045

    IL_0019: ldloc.0
    IL_001a: ldc.i4 5845
    IL_001f: beq.s IL_0083

    IL_0021: ldloc.0
    IL_0022: ldc.i4 23452
    IL_0027: beq.s IL_0069

    IL_0029: br.s IL_0090

    IL_002b: ldloc.0
    IL_002c: ldc.i4 347645
    IL_0031: beq.s IL_005c

    IL_0033: ldloc.0
    IL_0034: ldc.i4 678456
    IL_0039: beq.s IL_004f

    IL_003b: ldloc.0
    IL_003c: ldc.i4 1645634
    IL_0041: beq.s IL_0076

    IL_0043: br.s IL_0090

    IL_0045: ldc.i4.s 123
    IL_0047: call void [mscorlib]System.Console::WriteLine(int32)
    IL_004c: nop
    IL_004d: br.s IL_0090

    IL_004f: ldc.i4 678456
    IL_0054: call void [mscorlib]System.Console::WriteLine(int32)
    IL_0059: nop
    IL_005a: br.s IL_0090

    IL_005c: ldc.i4 347645
    IL_0061: call void [mscorlib]System.Console::WriteLine(int32)
    IL_0066: nop
    IL_0067: br.s IL_0090

    IL_0069: ldc.i4 23452
    IL_006e: call void [mscorlib]System.Console::WriteLine(int32)
    IL_0073: nop
    IL_0074: br.s IL_0090

    IL_0076: ldc.i4 1645634
    IL_007b: call void [mscorlib]System.Console::WriteLine(int32)
    IL_0080: nop
    IL_0081: br.s IL_0090

    IL_0083: ldc.i4 5845
    IL_0088: call void [mscorlib]System.Console::WriteLine(int32)
    IL_008d: nop
    IL_008e: br.s IL_0090

    IL_0090: ret

    int num = int.Parse(Console.ReadLine());
    if (num <= 23452)
    {
        if (num != 123)
        {
            if (num != 5845)
            {
                if (num == 23452)
                {
                    Console.WriteLine(23452);
                }
            }
            else
            {
                Console.WriteLine(5845);
            }
        }
        else
        {
            Console.WriteLine(123);
        }
    }
    else
    {
        if (num != 347645)
        {
            if (num != 678456)
            {
                if (num == 1645634)
                {
                    Console.WriteLine(1645634);
                }
            }
            else
            {
                Console.WriteLine(678456);
            }
        }
        else
        {
            Console.WriteLine(347645);
        }
    }

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, alex_public, Вы писали:

_>Хыхы, я смотрю фанаты Nemerle дружно заминусовали это моё сообщение, но при этом ни один не смог представить ни одного аргументированного возражения. В общем то совсем не удивительно...
В этом обсуждении я тут скорее "на твоей стороне", да и фанатом немерле никогда не был. Но с утверждением "дотнетовские либы так же (не)удобны для немерле как сишные для плюсовых" не согласен. Я бы скорее с С++03/С++11 сравнил. То есть — кое-что (пусть даже многое) стало удобнее, но с использованием "старых" либ никаких проблем нет, ведь многие неудобства спрятаны внутри реализации.

Ну и ещё немного офтопа — чем тебя свифт зацепил ума не приложу. По моему, унылый язычок, сравнивать его с Д/Растом/Немерле не стал бы. Всё, что у него есть — это поддержка. Другое дело, что этого, в данном случае, достаточно...

Если что я "болею" именно за раст.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, DarthSidius, Вы писали:

DS>>У меня серьезное сообщение. А ты насмешил. Так бывает — от незнания предмета. Это одно из важных преимуществ платформы — неважно на каком языке написаны библиотеки, использовать их могут все. И ты извини конечно, но твое сообщение Владу — ахинея.

_>До тебя так и не доходит? ) Использовать то конечно могут, но зачем они такие неполноценные нужны в продвинутом языке? Или быть может ты хочешь сказать, что все C# библиотеки архитектурно рассчитаны на приём алгебраических типов данных (из того же F#)? Про макросы Немерле я вообще молчу.

_>Тут имеется полная аналогия с языком C и языками предоставляющими свободное использование библиотек на нём (C++, D, Rust, Swift и т.д.). Использовать безусловно можно, но лучше переписать на самом языке, чтобы можно было использовать исключения, передавать классы или вообще шаблонные параметры и т.п.

Оно, конечно, так, но важнейщей фичей С++ на ранних порах была именно совместимость с Си и то, что из С++ можно напрямую использовать сишные библиотеки.
Так что тут Немерле по отношению к C# (вернее, к .NET) ровно в такой же позиции.

И обрати внимание, с теми же граблями.
Как С++ никак не может отделаться от "плохих" сишных вещей из-за требований совместимости, которая изначально его продвинула, так и Немерле остается привязанным к дотнету и плакала его кроссплатформенность.
Хотя у обоих языков какие-то шансы вырваться есть. У Немерле — упрятать все еще один слой макросов, который инкапсулирует дотнет (тут я не копенгаген, но то, что я помню из статей Влада про макросы Немерле, было сильно завязано на рефлексию дотнета). У С++ — ты и сам в курсе как последних, так и планируемых изменений (например, модулей, чтобы наконец выкинуть #include на свалку истории), которые делают древние сишные конструкции либо вообще ненужными, либо явно огороженными проверками времени компиляции.

Здравствуйте, DarkEld3r, Вы писали:

DE>Ну и ещё немного офтопа — чем тебя свифт зацепил ума не приложу. По моему, унылый язычок, сравнивать его с Д/Растом/Немерле не стал бы. Всё, что у него есть — это поддержка. Другое дело, что этого, в данном случае, достаточно...
Люди просто боятся себе признаться в том, что им нравится язык не по тому, что он хороший, а по тому, что за ним бабло.
Нет чтобы честно сказать что я буду использовать язык А ибо его двигает огромная корпорация. И не буду использовать язык Б ибо завтра его группа поддержки может исчезнуть.
Вполне нормальный объективный аргумент.
Но нет. Разводят кучу философии на ровном месте.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, DarkEld3r, Вы писали:

DE>В этом обсуждении я тут скорее "на твоей стороне", да и фанатом немерле никогда не был. Но с утверждением "дотнетовские либы так же (не)удобны для немерле как сишные для плюсовых" не согласен. Я бы скорее с С++03/С++11 сравнил. То есть — кое-что (пусть даже многое) стало удобнее, но с использованием "старых" либ никаких проблем нет, ведь многие неудобства спрятаны внутри реализации.

Не согласен, т.к. в C++03 уже было МП на шаблонах, пусть и менее эффективное. И в Nemerle МП есть. А вот в C и C# ничего подобного.

Т.е. если перейти к примерам и взять допустим много раз упоминающийся тут Boost.Spirit, то понятно что его аналог (с аналогичным удобством и быстродействием) на C# не пишется (даже если и сделать подобие, то там будет всё рантайм, с соответствующим быстродействием). А вот на Nemerle уже вполне можно. Только вот где оно готовое? Это как раз и есть пример слабой инфраструктуры языка и как видно C# библиотеки тут ничем не помогут по определению. А ведь в Nemerle МП посильнее чем в C++, и значит аналогичных примеров (где реализация на Nemerle возможна, а на C# нет) может быть очень много.

DE>Ну и ещё немного офтопа — чем тебя свифт зацепил ума не приложу. По моему, унылый язычок, сравнивать его с Д/Растом/Немерле не стал бы. Всё, что у него есть — это поддержка. Другое дело, что этого, в данном случае, достаточно...

Он не зацепил, т.к. пока даже непонятно будет ли он кроссплатформенным (без этого он мне в принципе не интересен). А так в принципе ничего так язык. Только опять же с МП проблема. )))

А в данной темке он всплыл в другом контексте. Речь шла о том, что он позиционируется в ту же самую нишу, что и C++, D, Rust. В то время как все языки платформы Java и платформы .Net (включая Nemerle) явно не могут перекрыть эту нишу именно в силу ограничений платформы.

Здравствуйте, jazzer, Вы писали:

J>Оно, конечно, так, но важнейщей фичей С++ на ранних порах была именно совместимость с Си и то, что из С++ можно напрямую использовать сишные библиотеки.
J>Так что тут Немерле по отношению к C# (вернее, к .NET) ровно в такой же позиции.

Так я именно про это и говорю, что ситуация полностью аналогичная. И соответственно пока на Nemerle не напишут свой "Boost", говорить о развитых библиотеках странно.

J>И обрати внимание, с теми же граблями.
J>Как С++ никак не может отделаться от "плохих" сишных вещей из-за требований совместимости, которая изначально его продвинула, так и Немерле остается привязанным к дотнету и плакала его кроссплатформенность.

Видимо зависит от уровня этой совместимости. Т.к. скажем D, Rust, Swift без проблем работают с C библиотеками, но при этом внутри у них нет никаких намёков на "ужасы C". )

J>Хотя у обоих языков какие-то шансы вырваться есть. У Немерле — упрятать все еще один слой макросов, который инкапсулирует дотнет (тут я не копенгаген, но то, что я помню из статей Влада про макросы Немерле, было сильно завязано на рефлексию дотнета). У С++ — ты и сам в курсе как последних, так и планируемых изменений (например, модулей, чтобы наконец выкинуть #include на свалку истории), которые делают древние сишные конструкции либо вообще ненужными, либо явно огороженными проверками времени компиляции.

Для всего этого надо:
1. Целенаправленное желание
2. Ресурсы для реализации

И насколько я вижу у Nemerle и C++ тут совсем разные расклады.

Здравствуйте, alex_public, Вы писали:

_>Т.е. если перейти к примерам и взять допустим много раз упоминающийся тут Boost.Spirit, то понятно что его аналог (с аналогичным удобством и быстродействием) на C# не пишется (даже если и сделать подобие, то там будет всё рантайм, с соответствующим быстродействием). А вот на Nemerle уже вполне можно. Только вот где оно готовое?
Уж несколько лет как написано.
https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser

Мне вас всех так весело читать. Прилетаете, бьёте себя пяткой в грудь и кричите "этого в немерле нет и не будет". Получаете в ответ ссылку на реализацию и исчезаете.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, alex_public, Вы писали:

_>Хыхы, я смотрю фанаты Nemerle дружно заминусовали это моё сообщение, но при этом ни один не смог представить ни одного аргументированного возражения.

Ты уж меня прости, но я тут отдыхаю в Египте и читаю рсдн с телефона. По сему развернуто отвечать на прстыни текста нет ни возможнести, ни желания. К тому же ты, в своей аргементации, стремительно скатываешься к уровню зверька из известной башни. Ты, наверное, не прохой сиплюсплюсние, но за его пределами, ты явно ничего не видел. Опронировать к твоим абсурдным заявлениям без смеха сложно. Мой тебе совет — ты или освой, как следует, то о чем высказываешься, или просто молчи. А то, твой авторитет стремительно таит в глазах тех, кто разбирается в вопросах.

Еще один совет — по осторожнее с экстрополяцией. Не стоит переносить опыт из С/С++ на другие области и языки. С/С++ имеют кучу проблем вызванных тем, что эти языки одного возраста с говном мамонта.

Например, в мире С++не принято брать чужих библиотек без исходников. Есть проблемы с совмещением разных библиотек. С–шные библиотеки имеют процедерный дизайн и (зачастую) слабую типизацию. В мире дотнета и явы все иначе. Дизай систем и зашитые в них стандарты нацелены на массовое совместное испльзование библиотек. Причем в бинарном виде.

По этому твоя экстрополяцтя опыта использования сишных библиотек на дотнет не верна. Дотнетные библиотеки имеют довольно высокое качество и не требуют пнреписывания для использования в немерле или любом другом языке.

Твои рассуждениия о системности языков на основании наличия в них указателей ничего кроме смеха не вызывает, так как в том же шарпе указатели тоже имеются.

В общем, оппонировать к твоим словам сложно, так как они (если речь идет о чем–то отличном от С++), в основном, является набором домыслов и предрассудков.

Хочешь говорить серьезно? Разберись в технологиях о которых рассуждаешь. Правда, при этом, скорее всего спорить уже будет не о чем.

Здравствуйте, alex_public, Вы писали:

_>Кстати, а вот если бы Nemerle был кроссплатформенным системным языком, то я обязательно бы его

Может ты уже ответишь, как те задачи вы решаете на работе? Зачем тебе "системный" язык и что ты в это вкладываешь, наоми указателей которые есть и в шарпе.

Здравствуйте, alex_public, Вы писали:

_>Не согласен, т.к. в C++03 уже было МП на шаблонах, пусть и менее эффективное. И в Nemerle МП есть. А вот в C и C# ничего подобного.
Дык, в большинстве бустовых либ МП "внутри". А интерфейс обычный.

Но вообще, я скорее про другое. Между С++ и С разница огромна, а между дотнетовыми либами и немерле такой разницы нет.

Опять же, в дотнете есть много всего "для всех случаев жизни", пусть и "под одну платформу" (условно). Это в С++ ничего такого не было, потому и есть отдельные огромные либы/фреймворки. Это примерно как если бы в стандарте языка был пусть не буст, но какое-нибудь Qt. Придумывать ещё один уровень абстракции поверх? Зачем?

Пишу я на С++, если что.

Здравствуйте, alex_public, Вы писали:

_>А вот насчёт выделения памяти — это точно миф. Причём довольно известный и старый. Он был придуман ещё любителями Java, когда они типа нашли один специфический пример, на котором Java код опережает C/C++. На самом деле фокус конечно же заключается в оригинальном написание C/C++ примера, которое ни один профессионал в нём не сделает. Сейчас поясню в деталях. В большинстве случаев в реальных задачах мы встречаем или выделение отдельных небольших объектов (в C++ принято для этого использовать стек — обычно на голову быстрее всех остальных) или же сразу больших блоков/массивов (тут у большинства нормальных языков будут одинаковые цифры). Однако есть ещё один довольно специфический случай — выделение (и главное удаление!) большого числа отдельных мелких объектов. Если решить эту задачу с помощью банального new/delete, то она действительно будет несколько отставать от реализации на Java/C#. Только вот фокус в том, что никто в своём уме не будет писать подобный код на C++, а применит для этой задачи аллокатор на пуле (который опять же окажется на голову быстрее варианта на Java/C#). Я, конечно, уже лет 10 как не пишу на С++. Но в те времена, когда я писал, это был один из самых популярных языков. Так вот — нестандартные аллокаторы я видел в 0 (нуле) из тех проектов, в которых я принимал участие.
Поэтому у меня есть некоторый скепсис относительно "никто в своём уме".
По моему опыту, большинство проектов делается минимально компетентными для успешного завершения сотрудниками. Зачастую — даже ниже, но эти проекты просто не достигают успеха.
Какой там "кастомные аллокаторы". Если программа не крешится, если быстро нажать подряд два пункта меню — уже и на этом спасибо.

Вот, скажем, в одной компании на плюсах пишут в основном в департаменте виртуализации. Между прочим, мирового уровня спецы работают.
Тем не менее, Management Console пару мажорных версий подряд тупо не умела обрабатывать сбои связи с сервером, которые происходят в рабочих потоках. Типа вот ты нажал на кнопочку "стартовать VM", там часики закрутились — и всё. Если сервер сказал "фейл", то ещё шансы есть на показать резульат в гуе (если пользователь не успел далеко убежать в интерфейсе — например, затаив дыхание смотрит всё в то же окно). А если "фейл" сказал сокет (скажем, таймаут на чтение), то результат молча глотается.
При этом таймауты происходят оттого, что авторы консоли представляли основным сценарий "один сервер с одной VM и несколькими клиентами", а случаи типа "1 сервер с 50 VM на другом берегу океана" им вообще в голову не приходили (хотя это как раз штатный случай для сервера). В итоге клиент-серверный протокол был спроектирован так, что утилита пыталась прокачать несколькомегабайтный XML несолько раз в секунду. Пока размер XML был по полметра, а до сервера — гигабитный Ethernet, это никак не сказывалось на плавности UI.
А когда мы стали запускать это в продакшн, все особенности такой архитектуры сразу выбежали на передний план.

К чему это я рассказываю? Да к тому, что под профайлером эту консольку явно не запускали ни разу в жизни. А ведь без профайлера никто в своём уме не полезет менять аллокатор.

Здравствуйте, alex_public, Вы писали:

_>Не согласен, т.к. в C++03 уже было МП на шаблонах, пусть и менее эффективное. И в Nemerle МП есть. А вот в C и C# ничего подобного.

И что? Ну написали в МС 100500 тонн кода решающих базовые проблемы силами 100500 программистов, а не пяти. Это их проблемы.

Там где решение в виде библиотек получается хреновым немерл предоставляет макросы.

Например, то же IO не плохо запихивается в библиотеки без макросов, GUI отлично ложится на ООП, а вот замены буст.спорит–а в дотнете просто нет. Но в немерле мы имеем Nemerle.PEG и Nitra, которые реализованы на макрах и рвут спирит как Тузик грелку.

_>Т.е. если перейти к примерам и взять допустим много раз упоминающийся тут Boost.Spirit, то понятно что его аналог (с аналогичным удобством и быстродействием) на C# не пишется (даже если и сделать подобие, то там будет всё рантайм, с соответствующим быстродействием).

Я тебя расстрою — лечшие генераторы парсеров написаны для дотнета и явы. Только они являются отдельными приложениями. Например, ANTLR 4.

В Немерле действительно аналоги сделаны на макросах. Но они рвут не только Спирит, но и тот же ANTLR.

Вообще, если бы без МП нель было бы жить, то дотнет и ява просто бы не взлетели. Сильный программист может повысить свою эффективность применяч МП в некоторых случаях, но тема кода пишется ручками и МП при этом не сильно помогает.

Более того. Любой код можно написать без МП. Вопрос лишь в трудозатратах. Корпорации типа МС могут выбрасывать мегобаксы на ветер. Низкое КПД компенсируется высоким качеством результата и пиаром (брендом).

_>А вот на Nemerle уже вполне можно. Только вот где оно готовое?

Помилуй, прямо в поставке есть Nemerle.PEG и можно скачать Nitra. Твой спирит бледное подобие. Не более.

Тоже самое для других проблем не решаемых библиотеками на должном уровне.

_>Это как раз и есть пример слабой инфраструктуры языка и как видно C# библиотеки тут ничем не помогут по определению.

Это пример твоей слабой осведомленности и терминологическоц путанницы. Мы не называет макросы библиотекой. Макро–библиотеки немного другое дело.

Они есть и их не так мало. Больше чем для С++, по крайней мере. Точнее так, большая часть шаблонного метапрограммирования закрывает дыры в языке, в то время как в немерле предоставляет DSL–и вроде спирита. Вот где С++-библиотеки для хмл–литерало (чтобы можно было формировать хмл из тегов, а не черт знает чего или возможность декларативно описать конечные автоматы? А строки в плюсах почему формируются допотопными средствами?

_> А ведь в Nemerle МП посильнее чем в C++, и значит аналогичных примеров (где реализация на Nemerle возможна, а на C# нет) может быть очень много.

Ну, привели. За чем дело стало?

_>Он не зацепил, т.к. пока даже непонятно будет ли он кроссплатформенным (без этого он мне в принципе не интересен). А так в принципе ничего так язык. Только опять же с МП проблема. )))

_>А в данной темке он всплыл в другом контексте. Речь шла о том, что он позиционируется в ту же самую нишу, что и C++, D, Rust.

Свифт — это немерл без макросов, перегрузки методов и с подсчетом ссылок вместо полноценного ЖЦ.

Он не более системный чем шара, например. В прочем и на шарпе написана ОС (Сингулярити). На Обероне — тоже. Так, что деление на системный и нет — это маркетинговый булшит и каша у тебя в голове.

Вот что в Википедии написано о Rust:

Основная задача Rust — быть удобным языком для написания больших клиент-серверных приложений, работающих в сети Интернет.

Позвольте, не это ли предназначение явы, дотнета и всех скриптовых языков?

Поинтеры есть и в шапке.

Получается, что с системностью та же байда, что с инфраструктурой — красивое слово скрывающее за собой, всего лишь, отсутствие развесистого рантайма.

_>В то время как все языки платформы Java и платформы .Net (включая Nemerle) явно не могут перекрыть эту нишу именно в силу ограничений платформы.

Что за ниша то? Какие ограничения то?

Вы тут все драйвера пишите, кодеки или ОСы?

Еще раз спрашиваю — что за софт вы пишите на С++.

Здравствуйте, WolfHound, Вы писали:

WH>Уж несколько лет как написано.
WH>https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser

WH>Мне вас всех так весело читать. Прилетаете, бьёте себя пяткой в грудь и кричите "этого в немерле нет и не будет". Получаете в ответ ссылку на реализацию и исчезаете.

Вообще то я как раз не говорил что не будет, а наоборот сказал что обязательно должно быть. ) Т.е. ты как раз подтверждаешь мои слова о необходимости таких библиотек на Nemerle. Собственно осталось написать (или может я просто не в курсе и уже всё написано?) на Nemerle аналог stl + boost и уже можно считать что с библиотеками дела обстоят более менее.

Кстати, если кто-то сомневается зачем переписывать уже существующие в C# вещи, то могу пояснить на хорошем примере. Если взять Range'и из D, то в них заложена такая же идея (IEnumerable) как и в linq в C# (кстати, нечто подобное имеем и в Swift'e). Только вот реализация на D на голову мощнее варианта на C# как раз за счёт метапрограммирования. Например там все алгоритмы имеют по несколько реализации и нужная выбирается (естественно в момент компиляции) в зависимости от типа контейнера (т.е. скажем если можно применять произвольный доступ, а не только последовательный, то можно использовать намного более эффективный алгоритм). Насколько я понимаю, на Nemerle подобное тоже реализуемо, так что переписав стандартную библиотеку контейнеров и алгоритмов, можно получить заметное превосходство над C#. Но это не планируется, как я понимаю? Или планируется? Или вообще уже реализовано, а я просто не в курсе действительно развитой инфраструктуры языка? )

Да, насчёт парсера... А можно микроскопический тестик для интереса? ) Просто мы тут прямо на этом форуме год назад делали небольшие тесты на эту тему. Была простейшая задачка, решение которой на boost'e занимало ровно 5 строк. Так вот аналогичный (тоже в несколько строк) код на C# отставал помнится раз в 15. Да, если что, на C# писал не я, а эксперт в нём. ))) Потом он сумел довести отставание всего до 2-ух раз, но ценой этого стал огромный макаронный unsafe код. Соответственно очень любопытно было бы сравнить решение на Nemerle. Если вдруг решишься, то вот условия задачки (цитирую запись с форума годовой давности):

Можем провести простейший тест. Допустим есть обычный текстовый файл. Он состоит из 100 строк. Каждая строка состоит из 100 000 (вполне нормальная ситуация для обработки экспериментальных данных) int'ов, разделённых запятыми. Задачка: прочитать файл, посчитать среднее по каждой строке и допустим вывести в отсортированном виде в консоль (это чтобы проконтролировать результат работы — тогда можно exe обменяться, а не напрягаться с построением чужих библиотек).

Здравствуйте, VladD2, Вы писали:

VD>Ты уж меня прости, но я тут отдыхаю в Египте и читаю рсдн с телефона. По сему развернуто отвечать на прстыни текста нет ни возможнести, ни желания. К тому же ты, в своей аргементации, стремительно скатываешься к уровню зверька из известной башни. Ты, наверное, не прохой сиплюсплюсние, но за его пределами, ты явно ничего не видел. Опронировать к твоим абсурдным заявлениям без смеха сложно. Мой тебе совет — ты или освой, как следует, то о чем высказываешься, или просто молчи. А то, твой авторитет стремительно таит в глазах тех, кто разбирается в вопросах.

Вообще то на простыни текста тебя как раз хватает. Только твои простыни стараются держаться подальше от обсуждения собственно профессиональных вопросов, которые затрагиваю я, и упорно пытаются перейти к обсуждению моей личности. ) Догадываешься какие из этого следуют выводы? )

VD>Например, в мире С++не принято брать чужих библиотек без исходников. Есть проблемы с совмещением разных библиотек. С–шные библиотеки имеют процедерный дизайн и (зачастую) слабую типизацию. В мире дотнета и явы все иначе. Дизай систем и зашитые в них стандарты нацелены на массовое совместное испльзование библиотек. Причем в бинарном виде.

У тебя постоянная путаница между C и C++. Про C++ написано верно, а вот C библиотеки как раз частенько передают в скомпилированном виде. Собственно в этом смысле C# как раз ближе к C, чем к C++. А вот Nemerle с его макросами уже ближе к C++, т.к. без исходников просто не выйдет.

VD>По этому твоя экстрополяцтя опыта использования сишных библиотек на дотнет не верна. Дотнетные библиотеки имеют довольно высокое качество и не требуют пнреписывания для использования в немерле или любом другом языке.

Естественно не требуют. Как и C библиотеки не требуют переписывания для использования их в C++ (или D, Rust, Swift и т.п.). Но при таком раскладе у тебя получается использование убогой библиотеки из красивого языка. И соответственно в точке использования ты теряешь все преимущества использования своего красивого языка. Т.е. использовать то безусловно можно, но лучше бы всё же переписать по родному... )

VD>Твои рассуждениия о системности языков на основании наличия в них указателей ничего кроме смеха не вызывает, так как в том же шарпе указатели тоже имеются.

Не забудь ещё отправить в топку обязательный сборщик мусора и посмотрим что останется от C#. )

VD>В общем, оппонировать к твоим словам сложно, так как они (если речь идет о чем–то отличном от С++), в основном, является набором домыслов и предрассудков.

Любые домыслы легко опровергаются тестовыми примерами или ссылками на спецификации. Но я уже понял что от тебя мы дождёмся только очередного обсуждения моей персоны, но никак и не кода/документации.

Здравствуйте, alex_public, Вы писали:

J>>Так что тут Немерле по отношению к C# (вернее, к .NET) ровно в такой же позиции.

Для кроссплатформности есть Моно. Не венец твореня, но говоря, что кросплатформности нет человек явно лукавит.

_>Так я именно про это и говорю, что ситуация полностью аналогичная. И соответственно пока на Nemerle не напишут свой "Boost", говорить о развитых библиотеках странно.

Буст — это библиотека залатывающая дыры стандарта С++. Аналогичные возможности или уже есть в библиотеках дотнета, или она не нужна, так как является костылями для плюсов.

Что, за исключением спорита (превосходящих его аналогов макросов сразу два) , есть в тесте, что нет в библиотеках дотнета или в самом дотнете? Только конкретно.

_>Видимо зависит от уровня этой совместимости. Т.к. скажем D, Rust, Swift без проблем работают с C библиотеками, но при этом внутри у них нет никаких намёков на "ужасы C". )

Все языки дотнета отлично работают с С–библиотеками даже без ансейфа. Кури interop. Этому в дотнете посвящено очень многое. В Шарпе и Немерле еще можно и указатели использовать.

У Раста совместимость с С не лучше. У Свифта (судя по бокам) кроме указателей и импорта простых дефайнутых констант ничего и нет. С Ли все по веселее, но тоже примерно на том же уровне.

Ну, и как и в случае с С++ сишные либы будут выглядеть убого без оберток. Так что смысл их использования исчезающе мал.

_>Для всего этого надо:
_>1. Целенаправленное желание
_>2. Ресурсы для реализации

А можно узнать реализации чего ты ждешь?

_>И насколько я вижу у Nemerle и C++ тут совсем разные расклады.

А можно о расскладах по по подробнее?

Вот нормальная IDE для плюсов за 30 лет уже появилась?

А когда буст.спирит дотянет хотя бы до немерле.ПЕГ? А когда Qt дотянет до WPF?

Здравствуйте, DarkEld3r, Вы писали:

DE>Дык, в большинстве бустовых либ МП "внутри". А интерфейс обычный.

Мммм оно может быть и внутри, но работает в процессе сборки приложения, а не библиотеки. Т.е. требуется именно компилятор с шаблонами для сборки самого приложения — не получится собрать библиотеку, а потом использовать её в компиляторе без шаблонов. И как я понимаю у Nemerle аналогичная ситуация.

DE>Но вообще, я скорее про другое. Между С++ и С разница огромна, а между дотнетовыми либами и немерле такой разницы нет.

Для того, чтобы так говорить, надо в начале глянуть на канонические (с полноценным использование макросов и т.п.) библиотеки Nemerle. Т.е. посмотреть на какой-то местный аналог Boost'a. Что-то мне кажется, что там код будет весьма отличаться от обычного C#.

DE>Опять же, в дотнете есть много всего "для всех случаев жизни", пусть и "под одну платформу" (условно). Это в С++ ничего такого не было, потому и есть отдельные огромные либы/фреймворки. Это примерно как если бы в стандарте языка был пусть не буст, но какое-нибудь Qt. Придумывать ещё один уровень абстракции поверх? Зачем?

И по хорошему значительную часть всего этого надо бы переписать на Nemerle. Почему? См. например здесь http://rsdn.ru/forum/nemerle/5825140. Понятно что при самом старте языка использование готовой чужой инфраструктуры — это абсолютно правильное решение. Собственно C++ так и поднялся на базе C. Но со временем обязательно надо создавать свою инфраструктуру.

Здравствуйте, alex_public, Вы писали:

DE>>Дык, в большинстве бустовых либ МП "внутри". А интерфейс обычный.
_>Мммм оно может быть и внутри, но работает в процессе сборки приложения, а не библиотеки. Т.е. требуется именно компилятор с шаблонами для сборки самого приложения — не получится собрать библиотеку, а потом использовать её в компиляторе без шаблонов. И как я понимаю у Nemerle аналогичная ситуация.

В Nemerle библиотека с макросами — это фактически плагин к компилятору, распространяемый в виде динамической библиотеки (бинарной).

Здравствуйте, Sinclair, Вы писали:

S>Я, конечно, уже лет 10 как не пишу на С++. Но в те времена, когда я писал, это был один из самых популярных языков. Так вот — нестандартные аллокаторы я видел в 0 (нуле) из тех проектов, в которых я принимал участие.
S>Поэтому у меня есть некоторый скепсис относительно "никто в своём уме".
S>По моему опыту, большинство проектов делается минимально компетентными для успешного завершения сотрудниками. Зачастую — даже ниже, но эти проекты просто не достигают успеха.
S>Какой там "кастомные аллокаторы". Если программа не крешится, если быстро нажать подряд два пункта меню — уже и на этом спасибо.

Ну так я же вроде как указал, что это требуется только для достаточно редкой ситуации. Т.е. в большинстве случаев стандартные средства и так быстрее всех.

А вообще нестандартные аллокаторы применялись и 10 лет назад, но конечно ещё реже. Просто тогда их приходилось не просто применять, а в начале ещё и собственно написать. Т.е. грубо говоря тогда была только stl, которая предоставляет интерфейсы для них, но не реализации. А сейчас есть Boost (и не только), с готовыми отлаженными вариантами.

S>Вот, скажем, в одной компании на плюсах пишут в основном в департаменте виртуализации. Между прочим, мирового уровня спецы работают.
S>Тем не менее, Management Console пару мажорных версий подряд тупо не умела обрабатывать сбои связи с сервером, которые происходят в рабочих потоках. Типа вот ты нажал на кнопочку "стартовать VM", там часики закрутились — и всё. Если сервер сказал "фейл", то ещё шансы есть на показать резульат в гуе (если пользователь не успел далеко убежать в интерфейсе — например, затаив дыхание смотрит всё в то же окно). А если "фейл" сказал сокет (скажем, таймаут на чтение), то результат молча глотается.
S>При этом таймауты происходят оттого, что авторы консоли представляли основным сценарий "один сервер с одной VM и несколькими клиентами", а случаи типа "1 сервер с 50 VM на другом берегу океана" им вообще в голову не приходили (хотя это как раз штатный случай для сервера). В итоге клиент-серверный протокол был спроектирован так, что утилита пыталась прокачать несколькомегабайтный XML несолько раз в секунду. Пока размер XML был по полметра, а до сервера — гигабитный Ethernet, это никак не сказывалось на плавности UI.
S>А когда мы стали запускать это в продакшн, все особенности такой архитектуры сразу выбежали на передний план.

Хы, ну да, косяки в архитектуре позволяют просадить производительность гораздо круче, чем выбор неоптимального языка и т.п. нюансы.

S>К чему это я рассказываю? Да к тому, что под профайлером эту консольку явно не запускали ни разу в жизни. А ведь без профайлера никто в своём уме не полезет менять аллокатор.

В данном случае и профайлер не нужен был. Скорее вопрос к организации тестирования ПО. )

Здравствуйте, alex_public, Вы писали:

_>Вообще то на простыни текста тебя как раз хватает.

К сожалению, нет. И твои простыни тут не в одиночестве.
Попробуй ответить хотя бы на одно сообщение с телефона.

_>Только твои простыни стараются держаться подальше от обсуждения собственно профессиональных вопросов, которые затрагиваю я, и упорно пытаются перейти к обсуждению моей личности. ) Догадываешься какие из этого следуют выводы? )

Когда я виде некомпетентнось и домыслы, то так и говорю. По началу твои сообщения выглядили достойно, но сейчас уже вызывают смех.

VD>>Например, в мире С++не принято брать чужих библиотек без исходников. Есть проблемы с совмещением разных библиотек. С–шные библиотеки имеют процедерный дизайн и (зачастую) слабую типизацию. В мире дотнета и явы все иначе. Дизай систем и зашитые в них стандарты нацелены на массовое совместное испльзование библиотек. Причем в бинарном виде.

_>У тебя постоянная путаница между C и C++.
_>Про C++ написано верно, а вот C библиотеки как раз частенько передают в скомпилированном виде.

Во как? А может ты читаешь плохо или фантазия у тебя разыгралась? А ну–ка покажи где я утверждал, что сишные библиотеки передаются только в исходниках?

Я говорю о том, что ваши тараканы не приминимы к другим мирам.

И ты уже малость задрал мне рассказывать о моем плохом знании С++. Давай лучше поговорим о твоей почти полной не компетенции в области дотнета, который ты тут критикуешь и котором ты здесь делаешь заявления.

_>Собственно в этом смысле C# как раз ближе к C, чем к C++.

Шарп далек от них обоих, так как имеет полноценный бинарный модульный формат и отличную стандартную библиотеку. Да и не Шарп, а дотнет, т.е. все его языки.

_>А вот Nemerle с его макросами уже ближе к C++, т.к. без исходников просто не выйдет.

Это ты тоже от незнания говоришь. (ну как тут не говорить о твоей компетенции?)

У немерла есть библиотеки, которые обратно совместимы с дотнетными и есть макро–библиотеки, которые уникальны для немерла. Так вот, библиотеки дотнета являются для немерла родными. Никаких приседаний для их использования делать не надо. Аналогия с С/С++ не верна. И об этом тебе сказали даже ярые противники немерла (и мои).

_>Естественно не требуют. Как и C библиотеки не требуют переписывания для использования их в C++ (или D, Rust, Swift и т.п.). Но при таком раскладе у тебя получается использование убогой библиотеки из красивого языка.

Это ты экстраполируешь свой опыт работы на убогих языках один из которых ты считаешь красивым.

С и С++ имеют разный набор поддерживаемых парадигм. В С нет классов и шаблонов. Естественно это приводит к дизайну либ не свойственному плюсам.

В Шарпе же (на котором пишется подавляющее большинство либ) есть и клаввы, и дженерики и функци высшего порядка. В нем нет только макросов и не принято писать код в функциональном стиле. Это усложняет написание кода, но этотне проблема для их использования.

_>И соответственно в точке использования ты теряешь все преимущества использования своего красивого языка.

Ничего я не тиряю. Наоборот, иногда там где на шарпе использование либ бывает громоздко, на немерле оно становится элегантно из–за ивпользования макр или фич языка.

Например, для библиотеки xlinq в немерле есть макра позволяющая описывать хмл квази–цитатами хмл–я, а не в виде иерархии объектов (АСТа).

_>Т.е. использовать то безусловно можно, но лучше бы всё же переписать по родному... )

Это твои домыслы.

_>Не забудь ещё отправить в топку обязательный сборщик мусора и посмотрим что останется от C#. )

Его не надо никуда отправлять. Указатели работают паралельно с ним. Просто безопасность кода снижается.

Боле того для совместимости с С—либами доже указатели не нужны. Дотнет позволяет проецировать сишные структуры данных на свои.

_>Любые домыслы легко опровергаются тестовыми примерами или ссылками на спецификации.

Их очень много. Мне за твое образование не платят. Да и как домысел вроде "в немерле дотнетные библиотеки не родные и их нужно переписать, потому что я имел опыт с С и С++ говорящий об этом" можно опровергнуть ссылкой? Это очевидный бред, но очевидно он только тем кто серьезно использовал, хотябы, шарп. Рассказывать кучу мелких деталей устройства дотнета, чтобы переубедить одного некомпетентного человека — явный оверкил.

Так, что или ты слушаешь и веришь компетентным в вопросах людям, или идешь изучать матчасть самостоятельно. Третьего не дано. Ты же продолжаешь обосновывать одними домыслами другие.

_>Но я уже понял что от тебя мы дождёмся только очередного обсуждения моей персоны, но никак и не кода/документации.

Я незнаю как эфимерные понятия и домыслы опровергать документацией.

По поводу "системности" языка я попросил от тебя определение. Ты сказазал, что системный язык — это язык с указателями. Я тебе ответил, что они есть в шарпе и немерле.

Казалось бы вопрос исчерпан, но ты продолжаешь гнуть линию не приводя ни одного разумного аргумента. Не считать же чешь вроде "Не забудь ещё отправить в топку обязательный сборщик мусора" аргументом? С какого перепуга надо выбрасывать сборщик? Как это опровергает факт поддержки указателей в дотнетных языках?

В общем, ты или меняй свое определение системности на "не использует сборщик мусора", или просто признай, что не прав.

Я уверен, что не признаешь. А ведь факт не опровержимые я тебе привел уже давно. Есть минимум две ОС написанныз на языках с ЖС: Сингулярити и Оберон ОС. Более системных задач чем написание ОС я не знаю. Но ты продолжай спорить.

Здравствуйте, alex_public, Вы писали:

_>Превозносить безусловно можно. Но это уже не будет зазнайством, в котором ты меня обвинил. ) Кстати, а вот когда ты говоришь аналогичное про Nemerle, то...

Собственно проблема не в том, что ты превозносишь плюсы. Проблема в том, что ты, при этом, надменно и снисходительно относишся к другим. Это ошибка. Все остальные твои рассуждения — ее следствие.

Здравствуйте, alex_public, Вы писали:

VD>>... есть такие фишки как escape analysis…

_>Вот собственно говоря это "продвинутое" решение, которое иногда может сработать в некоторых реализациях на Java и является полным аналогом стандартной работы с памятью в C++. )))

Ага. Разница только в том, что в С++ для этоготприходится брать управление памятью в свои руки, а тут это происходит автоматически и безопасно.

И не "в некоторых", а в основной яав–машине авторов явы которую использует большинство пользователей.

Здравствуйте, VladD2, Вы писали:

VD>И что? Ну написали в МС 100500 тонн кода решающих базовые проблемы силами 100500 программистов, а не пяти. Это их проблемы.

VD>Там где решение в виде библиотек получается хреновым немерл предоставляет макросы.

Ну так собственно и вопрос — уже по всех подобным местам они имеются? ) К примеру как насчёт linq?

VD>Например, то же IO не плохо запихивается в библиотеки без макросов, GUI отлично ложится на ООП, а вот замены буст.спорит–а в дотнете просто нет. Но в немерле мы имеем Nemerle.PEG и Nitra, которые реализованы на макрах и рвут спирит как Тузик грелку.

С IO тоже есть большие вопросы. Кстати, я пока этот вопрос не прояснял... А как у Nemerle с реализацией await/async?

VD>Вообще, если бы без МП нель было бы жить, то дотнет и ява просто бы не взлетели. Сильный программист может повысить свою эффективность применяч МП в некоторых случаях, но тема кода пишется ручками и МП при этом не сильно помогает.

VD>Более того. Любой код можно написать без МП. Вопрос лишь в трудозатратах. Корпорации типа МС могут выбрасывать мегобаксы на ветер. Низкое КПД компенсируется высоким качеством результата и пиаром (брендом).

Всё верно (ну кроме рассуждений о затратах, но бизнес вопросы лучше не будем с тобой затрагивать). Но в таком случае становится не очень понятно позиционирование Nemerle. Т.е. он базируется у нас платформе ориентированной как раз на простоту работы (с соответствующей ценой за это), но при этом предлагает сложные профессиональные инструменты. Тебе не кажется, что тут что-то не так? Или же ты можешь чётко сформулировать нишу для Nemerle? )

У того же C++ и МП в нём всё в порядке в этом смысле. Тут и сама платформа не простая, рекомендуемая к использованию только профессионалами, так что МП вполне гармонично вписывается.

VD>Это пример твоей слабой осведомленности и терминологическоц путанницы. Мы не называет макросы библиотекой. Макро–библиотеки немного другое дело.

Ну это ваше личное определение и не надо навязывать его всем окружающим. Или может макросы у вас вынесены в отдельные файлы другого типа и обрабатываемые другими инструментами?

Кстати, в том же Boost'е большая часть библиотек как раз может называться "макро-библиотеками" в твоей терминологии, т.к. они сами по себе вообще не компилируются в объектные файлы.

VD>Они есть и их не так мало. Больше чем для С++, по крайней мере. Точнее так, большая часть шаблонного метапрограммирования закрывает дыры в языке, в то время как в немерле предоставляет DSL–и вроде спирита. Вот где С++-библиотеки для хмл–литерало (чтобы можно было формировать хмл из тегов, а не черт знает чего или возможность декларативно описать конечные автоматы? А строки в плюсах почему формируются допотопными средствами?

Декларативные конечные автоматы в бусте имеются. Как раз недавно кому-то тут приводил пример их симпатичной реализации. А про xml и строки не понял. Что за формирование допотопными средствами? )

И возвращаясь к Nemerle. Библиотека парсера, конечных автоматом и т.п. — это конечно очень хорошо и правильно. Но как с самыми базовыми вещами? У того же C++ самая базовая библиотека (STL) пронизана шаблонами.

VD>Свифт — это немерл без макросов, перегрузки методов и с подсчетом ссылок вместо полноценного ЖЦ.

О как) Кстати, кажется ещё совсем недавно ты спрашивал про разницу в устройстве памяти с C# (да, а ты в курсе про хитрые нюансы этого подсчёта ссылок? Там совсем не обычная реализация). Сейчас ты это уже усвоил, но за вычетом этого по прежнему считаешь эти языки одинаковыми... Похоже потребуется много подобные итераций, чтобы ты разобрался с этим языком.

VD>Он не более системный чем шара, например. В прочем и на шарпе написана ОС (Сингулярити). На Обероне — тоже. Так, что деление на системный и нет — это маркетинговый булшит и каша у тебя в голове.

Сингулярити написана на Sing#, а не на C#. Не надо сказок. ) А в Обероне возможность системного программирования заложена изначально.

VD>Вот что в Википедии написано о Rust:
VD>

VD>Основная задача Rust — быть удобным языком для написания больших клиент-серверных приложений, работающих в сети Интернет.

VD>Позвольте, не это ли предназначение явы, дотнета и всех скриптовых языков?

Вот похоже у тебя все знания о других языках почерпнуты из подобных источников. ) А на сайт самого языка не пробовал заходить? ) Здесь http://www.rust-lang.org указано следующее:

Rust is a systems programming language that runs blazingly fast, prevents almost all crashes*, and eliminates data races.

VD>Что за ниша то? Какие ограничения то?
VD>Вы тут все драйвера пишите, кодеки или ОСы?
VD>Еще раз спрашиваю — что за софт вы пишите на С++.

Вот представь себе и ОС и кодеки и драйверы в одном проекте. ))) А поверх всего этого ещё сложная логика и красивый GUI. Причём всё это работает не на одном устройстве, а на многих (разных типов, на разных ОС и только часть с GUI), объединённых сетью (не интернетом) и должно работать без единой задержки.

Здравствуйте, alex_public, Вы писали:

_>У тебя постоянная путаница между C и C++. Про C++ написано верно, а вот C библиотеки как раз частенько передают в скомпилированном виде. Собственно в этом смысле C# как раз ближе к C, чем к C++. А вот Nemerle с его макросами уже ближе к C++, т.к. без исходников просто не выйдет.

1. Прекрати делать аналогии из мира (из уютного мирка

) С++. Они здесь не работают.
2. Если библиотека решает свою задачу, зачем ее переписывать?
3. Минусуют, а сами на сообщения не отвечают — дак устали уже. Толку 0. Этакий Шеридан, если ты понимаешь о чем я. Ты из раза в раз пишешь ерунду вроде вышеотквоченной. Причем это выдает твое незнание дотнета, а заниматься ликбезом в форуме никто не будет.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

Здравствуйте, alex_public, Вы писали:

_>Ну так собственно и вопрос — уже по всех подобным местам они имеются? ) К примеру как насчёт linq?

Линку костыли не требуются он и так работает.

Где нужны были аналоги их давно сделали. Языку уже 10 лет.

Есть вещи которые вы себе и представить не можете. Например computation expressions (билдеры монад) или оператор структурного присваенич.

_>С IO тоже есть большие вопросы. Кстати, я пока этот вопрос не прояснял... А как у Nemerle с реализацией await/async?

Есть аналог на computation expressions. Он чутка медленнее, но сильно гибче. Есть еще макры для многопоточности, но я их не использовал.

_>Всё верно (ну кроме рассуждений о затратах, но бизнес вопросы лучше не будем с тобой затрагивать). Но в таком случае становится не очень понятно позиционирование Nemerle. Т.е. он базируется у нас платформе ориентированной как раз на простоту работы (с соответствующей ценой за это), но при этом предлагает сложные профессиональные инструменты.

Ты малость достал. Давай договоримся, что на этом форуме все программисты профессионалы. И все инструменты проффесиональные.

_>Тебе не кажется, что тут что-то не так? Или же ты можешь чётко сформулировать нишу для Nemerle? )

Nemerle это средство повышения продуктивности программиста. Он не делает чедес. Он просто удобнее многих других языков в своей базе и позволяет сделать его еще более удобным для конкретной задачи.

Ни С++, ни Nemerle не сделают за тебя дизайн, не выберут оптимальный алгоритм, не заменят 30 проффесионалов. Это средство поднять КПД хорошего программиста. От применения Nemerle человек профессиональней не становится. Он просто получает более мощьный инструмент.

_>У того же C++ и МП в нём всё в порядке в этом смысле. Тут и сама платформа не простая, рекомендуемая к использованию только профессионалами, так что МП вполне гармонично вписывается.

СП в не дерьмовое. Тормозное, ограниченное. Не профессиональное, одним словом.

Все потому, что организовано на побочных эффектах от шаблонов, а не специальными средствами.

_>Ну это ваше личное определение и не надо навязывать его всем окружающим.

Общее определение библиотек МП не подразумевает.

_>Или может макросы у вас вынесены в отдельные файлы другого типа и обрабатываемые другими инструментами?

Они вынесены в отдельные сборки используемые только во время компиляции. Как тут уже тебе говорили макросы — это плагины к компилятору.

Библиотеки же сущность рантацмная.

_>Кстати, в том же Boost'е большая часть библиотек как раз может называться "макро-библиотеками" в твоей терминологии, т.к. они сами по себе вообще не компилируются в объектные файлы.

Я уже задавал этот вопрос, но ты его проигнорировал. Что кроме спирита в бусте нуждается в МП (не путать с обобщенным кодом) и при этом не является костылями для плюсов?

_>Декларативные конечные автоматы в бусте имеются. Как раз недавно кому-то тут приводил пример их симпатичной реализации.

А импортировать описания из систем моделирования КА они умеют?

_>А про xml и строки не понял. Что за формирование допотопными средствами? )

https://github.com/rsdn/nemerle/wiki/XML-literals

_>И возвращаясь к Nemerle. Библиотека парсера, конечных автоматом и т.п. — это конечно очень хорошо и правильно. Но как с самыми базовыми вещами? У того же C++ самая базовая библиотека (STL) пронизана шаблонами.

У немерла для этого хватает штатных средств. В дотнете для обобщений используются дженерики.

В дотнете куча своих контецнеров (коллекций в дотнет–терминологит). Плюс в стандартной библиотеке немерла есть ряд имютабл–коллекций удобных при использовании ФП.

VD>>Свифт — это немерл без макросов, перегрузки методов и с подсчетом ссылок вместо полноценного ЖЦ.

_>О как) Кстати, кажется ещё совсем недавно ты спрашивал про разницу в устройстве памяти с C#

Я спрашивал о том что ты подразкмеваешь под этим термином. Не надо выдымывать.

_>(да, а ты в курсе про хитрые нюансы этого подсчёта ссылок?

Не в курсе. Зато в курсе о проблемах этого подхода и что все кто может расстаются с ним в пользу ЖЦ.

_>Там совсем не обычная реализация).

Много где не обычная реализация. Рояги это не играет. Все плюсы и минусы остаются на месте.

_>Сейчас ты это уже усвоил,

Опять менторский тон и надменная спесь? Мое мнение о тебе стремительно ухудшается.

_>но за вычетом этого по прежнему считаешь эти языки одинаковыми... Похоже потребуется много подобные итераций, чтобы ты разобрался с этим языком.

Лучше сбей свою спесь. В противном случае я просто брошу общаться.

Прими за данность, что ты можешь быть не прав.

_>Сингулярити написана на Sing#, а не на C#. Не надо сказок. )

И в чем отличие этих языков ты знаешь? Sing# — это шарп в который встроинпаттерн обмена сообщениями. В самом компиляторе джит заменен на компиляцию во время установки (аналог ngen). Это все. GC на месте. Никаких других изменений нет.

Так, что не недо ляля.

_>А в Обероне возможность системного программирования заложена изначально.

И какиеже, позволю узнать? Не указатил ли?

_>Вот похоже у тебя все знания о других языках почерпнуты из подобных источников. )

Ды ты рассуждая о дотнете и туда не удосужился заглянуть.

А на сайт самого языка не пробовал заходить? ) Здесь http://www.rust-lang.org указано следующее:
_>

Rust is a systems programming language that runs blazingly fast, prevents almost all crashes*, and eliminates data races.

И чем этот рекламный булшит противоречит процитированному мной? Мы уже выяснили, что systems означает "наличие указателей" гы–гы.

_>Вот представь себе и ОС и кодеки и драйверы в одном проекте. )))

Не, не представляю. Хотелось бы прямой ответ услышать. Как–то глупо красивый гуй поверх драйверов выглядит.

Если вы пишите утилиты для ОС, то так и скажи. За одно скажи для какой, а лучше прямо "какие".

_>А поверх всего этого ещё сложная логика и красивый GUI. Причём всё это работает не на одном устройстве, а на многих (разных типов, на разных ОС и только часть с GUI), объединённых сетью (не интернетом)

Это одна софтяра или несколько?

_>и должно работать без единой задержки.

Без задержки даже одна инструкция процессора не исполняется. Ты это обязан знать.

Стало быть речь идет о предсказуемых задержках, ака гарантированном времени отклика, ака риалтайм или о просто быстро коде.

Я так и не понял о чем речь.

Гуй на С++ пишете?

Здравствуйте, VladD2, Вы писали:

VD>Буст — это библиотека залатывающая дыры стандарта С++. Аналогичные возможности или уже есть в библиотеках дотнета, или она не нужна, так как является костылями для плюсов.

VD>Что, за исключением спорита (превосходящих его аналогов макросов сразу два) , есть в тесте, что нет в библиотеках дотнета или в самом дотнете? Только конкретно.

Ты снова не понимаешь или притворяешься? Я же уже несколько раз повторил, что речь не о библиотеках, которых вообще нет в .net, а о библиотеках, переписывание которых с помощью МП позволяет добиться более эффективных результатов.

_>>Для всего этого надо:
_>>1. Целенаправленное желание
_>>2. Ресурсы для реализации
VD>А можно узнать реализации чего ты ждешь?

То, что предложил человек, которому я отвечал. )

_>>И насколько я вижу у Nemerle и C++ тут совсем разные расклады.
VD>А можно о расскладах по по подробнее?

Ну например размер команды работающей над языком у Nemerle и у C++ весьма разный. Это по поводу пункта 2. Ну и с первым пунктом разница видна уже по этой темке.

VD>Вот нормальная IDE для плюсов за 30 лет уже появилась?

Под винду есть 4 штуки, под линух тоже 4 (других), под мак 3 вроде. ) Это без учёта всяких там бета-версий и т.п. )

VD>А когда буст.спирит дотянет хотя бы до немерле.ПЕГ? А когда Qt дотянет до WPF?

А по какому конкретно параметру спирит должен дотянуться до PEG? ) Можно увидеть какие-то таблицы со сравнительным тестированием и т.п.? Кстати, заметь, я совсем не утверждаю что кто-то из них лучше в чём-то. У меня просто нет информации о подобном сравнение. Но и верить тебе на слово как-то сомнительно после многих очевидных проколов в данной дискуссии. Так что хотелось бы увидеть результаты тестов.

Qt лично мне не нравится. Но wpf ещё более сомнительное решение.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>В Nemerle библиотека с макросами — это фактически плагин к компилятору, распространяемый в виде динамической библиотеки (бинарной).

Так к компилятору то какому, не C# же (или каком-то другому из .net). Тут же речь шла о невозможности использования кода с макросами из безмакросового языка. Так же как из языка без шаблонов (ну т.е. C) не получится использоваться большую часть Boost'a.

Здравствуйте, alex_public, Вы писали:
_>Ну так я же вроде как указал, что это требуется только для достаточно редкой ситуации. Т.е. в большинстве случаев стандартные средства и так быстрее всех.
Ну откуда они могут быть "быстрее всех", когда за каждое убийство объекта приходится платить вставкой в список свободных?
Объекты фиксированного размера со стековым временем жизни в дотнете делаются на структурах и работают с той же скоростью, что и в С/С++.
А объекты динамического размера (строки, массивы) при детерминистической финализации таки проигрывают практически любому современному GC.

Здравствуйте, VladD2, Вы писали:

VD>Когда я виде некомпетентнось и домыслы, то так и говорю. По началу твои сообщения выглядили достойно, но сейчас уже вызывают смех.

Ну а твой стиль общения с пропуском всех неудобных тебе для ответа мест и постоянными переходами на личности вызывает не смех, а красноречиво говорит о том, кто тут у нас прав.

VD>Это ты тоже от незнания говоришь. (ну как тут не говорить о твоей компетенции?)

VD>У немерла есть библиотеки, которые обратно совместимы с дотнетными и есть макро–библиотеки, которые уникальны для немерла. Так вот, библиотеки дотнета являются для немерла родными. Никаких приседаний для их использования делать не надо. Аналогия с С/С++ не верна. И об этом тебе сказали даже ярые противники немерла (и мои).

Так в Nemerle код с макросами обязательно должен быть выделен в специальные файлы или же нет? Если нет, то я всё правильно написал. А если да, то тогда это получается какой-то внешний препроцессор и всё. )

VD>С и С++ имеют разный набор поддерживаемых парадигм. В С нет классов и шаблонов. Естественно это приводит к дизайну либ не свойственному плюсам.

VD>В Шарпе же (на котором пишется подавляющее большинство либ) есть и клаввы, и дженерики и функци высшего порядка. В нем нет только макросов и не принято писать код в функциональном стиле. Это усложняет написание кода, но этотне проблема для их использования.

Ну так и не проблема использовать C библиотеку в C++ коде. Собственно мы некоторые даже используем, т.к. их аналогов на C++ не найти (например определённая реализация Пролога). Но лучше бы C++ библиотеку. Так же как лучше родную Nemerle библиотеку (сам же сказал, что "усложняет написание").

VD>Их очень много. Мне за твое образование не платят. Да и как домысел вроде "в немерле дотнетные библиотеки не родные и их нужно переписать, потому что я имел опыт с С и С++ говорящий об этом" можно опровергнуть ссылкой? Это очевидный бред, но очевидно он только тем кто серьезно использовал, хотябы, шарп. Рассказывать кучу мелких деталей устройства дотнета, чтобы переубедить одного некомпетентного человека — явный оверкил.

Переписать очевидно не все, а только те, которые будут заметно эффективнее при использование Nemerle. Если же таких совсем мало, то как бы получается вывод что просто Nemerle — не нужен...

VD>По поводу "системности" языка я попросил от тебя определение. Ты сказазал, что системный язык — это язык с указателями. Я тебе ответил, что они есть в шарпе и немерле.

Я такого не говорил. Это ты домыслил за меня. Ещё одна черта к твоему стилю ведения дискуссии.

Кстати, если бы я руководил развитием проекта Nemerle, то точно запретил бы тебе общаться на форумах. Потому как худший антипиар даже трудно придумать. Ладно я, уже давно привычный фильтровать демагогию и игнорировать личные выпады. Но сколько ты спугнул таким образом не привычного к подобному народа... Ну да ладно, меня судьба Nemerle не особо беспокоит, так что можешь продолжать свои выпады в адрес критиков. Лично меня они не задевают.

VD>Казалось бы вопрос исчерпан, но ты продолжаешь гнуть линию не приводя ни одного разумного аргумента. Не считать же чешь вроде "Не забудь ещё отправить в топку обязательный сборщик мусора" аргументом? С какого перепуга надо выбрасывать сборщик? Как это опровергает факт поддержки указателей в дотнетных языках?

VD>В общем, ты или меняй свое определение системности на "не использует сборщик мусора", или просто признай, что не прав.

Ты для начал покажи, где я ввёл такое определение. )

Здравствуйте, VladD2, Вы писали:

VD>Ага. Разница только в том, что в С++ для этоготприходится брать управление памятью в свои руки, а тут это происходит автоматически и безопасно.

О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )

VD>И не "в некоторых", а в основной яав–машине авторов явы которую использует большинство пользователей.

Под некоторыми здесь подразумевалась не jvm, а ситуация в которой сработает этот анализ. В отличие от C++ (и ему подобных), где это чётко детерминировано.

Вообще, если говорить о сборщика мусора в современном программирование, то есть вот такая http://habrahabr.ru/post/188580/ очень полезная статья. Заголовок и вступление вроде как не про GC, но где-то с середины начинается самое интересное... )

Здравствуйте, DarthSidius, Вы писали:

DS>1. Прекрати делать аналогии из мира (из уютного мирка

) С++. Они здесь не работают.
DS>2. Если библиотека решает свою задачу, зачем ее переписывать?
DS>3. Минусуют, а сами на сообщения не отвечают — дак устали уже. Толку 0. Этакий Шеридан, если ты понимаешь о чем я. Ты из раза в раз пишешь ерунду вроде вышеотквоченной. Причем это выдает твое незнание дотнета, а заниматься ликбезом в форуме никто не будет.

В отличие от Влада, который чередует какие-то технические мысли с личными выпадами, от тебя я не видел вообще ни одного возражения по сути вопроса. Только рассуждения про уютные мирки и т.п. полезные "аргументы". )

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я думаю это дело даже можно частично автоматизировать — если после копии ref-counted куда-то, он больше не использовался — то достаточно move'а.
О, ещё немного — и вы изобретёте escape analysis.

EP>>>Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec,
WH>>Про то, что они редкие это исключительно твоя спекуляция.
EP>Причём достаточно чтобы счётчик прошёл только следующую последовательность состояний: "1, 2, 1, 0". А вот передёргивать при переходе, например, от состояния "получаем" к "отправляем" — нет никакой необходимости, достаточно move — так как эстафета передаётся.
И как компилятор гарантирует нам отсутствие обращений к источнику после move?

EP>Раз он точный, то память уплотнить (и обновить указатели) не проблема, но ограничения определённые есть. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
Точный GC в реальный C++ воткнуть не удастся. Потому что в нём 99% библиотек написаны в стиле "если сейчас луна в ущербе, то lParam — это указатель на cтруктуру; а если зима — то это идентификатор ресурса. Тип структуры определяется полем length".

EP>Но доступность-то не гарантированна, значит нет надёжности

EP>А вот что в случае бага вылетит — AV или исключение — рояли не играет. Баг есть баг.
Конечно же это играет роль! Детерминированный крэш однозначно выигрывает у UB. С учётом того, что в 99.99% UB — это вовсе не AV, а всего лишь инкремент чего-то не того. Type safety нету от слова совсем, а с битами манипулировать можно как угодно.
Классическая штука — я вызываю FileClose() на том, что считаю хэндлом файла. Если я использую поле от убитого объекта, у меня есть хорошие шансы скормить в FileClose мусор.
И иногда программа будет падать с ошибкой, а иногда будет просто закрывать валидный хэндл. А в жире годами будет висеть бага "иногда запись в файл самопроизвольно прерывается", а девелоперы будут считать, что глючная винда имеет наглость раз в иногда принудзакрывать файл, в который пишет активный процесс.

EP>Грубо говорят если из-за бага в алгоритме он вышел за пределы диапазона, но кинул исключение — работу свою он не выполнил, постусловий не достиг, перевёл программу в неопределённое состояние.
В том то и дело, что программу он перевёл в определённое состояние. Это гораздо, гораздо лучше неопределённого состояния, которым так гордятся программисты C++.

Здравствуйте, VladD2, Вы писали:

VD>Линку костыли не требуются он и так работает.

Хреново он работает, небыстро. Народ костыли наподобие LinqOptimizer делает, чтобы адекватную производительность получить. В немерле же сделать linq на макросах сам Б-г велел.

Здравствуйте, AndrewVK, Вы писали:

subj: Nemerle через 5 лет — выстрелит или скончается?
если выстрелит, то это не значит, что не скончается.

Здравствуйте, alex_public, Вы писали:

_>В отличие от Влада, который чередует какие-то технические мысли с личными выпадами, от тебя я не видел вообще ни одного возражения по сути вопроса. Только рассуждения про уютные мирки и т.п. полезные "аргументы". )

Они были, но ты их как-бе не заметил. Были, но ровно один раз, в отличии от Влада, который тебе повторяет по 100 раз.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

Здравствуйте, VladD2, Вы писали:

VD>Линку костыли не требуются он и так работает.

Если руководствоваться правилом "и так работает", то в общем то и Nemerle вообще не нужен, т.к. C# вообще то тоже вполне "и так работает".

А вот если всё же пытаться что-то улучшить, то можно увидеть что IEnumerable является очень бледной тенью Range из D. Причём как раз Nemerle (ну судя по тому, что ты о нём говоришь — я то его не изучал пока) мог бы легко поправить это.

VD>Где нужны были аналоги их давно сделали. Языку уже 10 лет.

Точно вот прямо все сделали? )

VD>Есть вещи которые вы себе и представить не можете. Например computation expressions (билдеры монад) или оператор структурного присваенич.

Гмм... И кто это только что говорил о самомнение, снисходительном отношение и т.п? )))

VD>Есть аналог на computation expressions. Он чутка медленнее, но сильно гибче. Есть еще макры для многопоточности, но я их не использовал.

Я правильно понял, что C# код с await/async в Nemerle сейчас работать не будет? А как тогда реализована работа с IOCP?

VD>Nemerle это средство повышения продуктивности программиста. Он не делает чедес. Он просто удобнее многих других языков в своей базе и позволяет сделать его еще более удобным для конкретной задачи.

Это не разговор. Нужна целевая ниша. Я вполне понимаю где выгодно применять Java/C#, где выгодно C++, а где Python и т.п. Так вот для Nemerle у меня нет такого же понимания. Потому как базируясь на платформе ориентированной на снижение цены разработки, он наоборот требует повышенной квалификации от программиста.

VD>Ни С++, ни Nemerle не сделают за тебя дизайн, не выберут оптимальный алгоритм, не заменят 30 проффесионалов. Это средство поднять КПД хорошего программиста. От применения Nemerle человек профессиональней не становится. Он просто получает более мощьный инструмент.

Ты периодически как-то извращённо понимаешь мои слова. Когда я говорю о профессиональных инструментах, то совсем не подразумеваю, что использование этого инструмента сделает человека профессионалом, как ты почему-то подумал. Откуда такая странная мысль? Я под этим подразумеваю, что для использования этого инструмента требуется повышенный уровень знаний, т.е. что имеется большой порог вхождения. И это как бы минус в условиях современного бизнеса, который должен обязательно чем-то компенсироваться.

К примеру я помнится видел какие-то исследования (по студентам кажется смотрели), что саму концепцию МП способны нормально осознать и применять только часть программистов.

VD>Они вынесены в отдельные сборки используемые только во время компиляции. Как тут уже тебе говорили макросы — это плагины к компилятору.

Про плагины я давно видел. Но я так и не понял, имеется ли какое-то чёткое формальное разделение nemerle кода с макросами и без?

VD>Я уже задавал этот вопрос, но ты его проигнорировал. Что кроме спирита в бусте нуждается в МП (не путать с обобщенным кодом) и при этом не является костылями для плюсов?

Насчёт костылей тут очень тонкий вопрос... Потому как многие вещи имеют реализацию в .net, но при этом исключительно времени исполнения. В то время как в Boost'е имеется аналогичные реализации, но времени компиляции. Я думаю ты не станешь спорить о том, какая реализация эффективнее (тем более, что на Nemerle можно сделать как раз как в C++ и даже лучше)? Так вот если учитывать такие вещи, то можно сразу гору библиотек накидать. Ну а если нет, то конечно же их сильно меньше будет. С ходу кроме Spirit'a вспоминаются Boost.Unit, Boost.Xpressive, Boost.MSM. Это из тех, что я сам трогал, а это естественно далеко не все.

Ну а вообще для программирование на Nemerle я бы поискал образцы скорее в стандартной библиотеке D, а не в Boost'e. Всё же в C++ МП слабенькое...

_>>А про xml и строки не понял. Что за формирование допотопными средствами? )
VD>https://github.com/rsdn/nemerle/wiki/XML-literals

А, понял. Ну так напомню, что Spirit — это не только парсер, но и генератор (ну и лексер ещё там есть). Хотя если этот твой код умеет скачивать и проверять при генерации xml схему, то такого конечно даже близко нет. А если без учёта схемы, то вроде как простая вещь.

VD>У немерла для этого хватает штатных средств. В дотнете для обобщений используются дженерики.

VD>В дотнете куча своих контецнеров (коллекций в дотнет–терминологит). Плюс в стандартной библиотеке немерла есть ряд имютабл–коллекций удобных при использовании ФП.

Я правильно понял, что ты считаешь, что с помощью МП улучшать в контейнерах .net'a нечего? )

VD>Не в курсе. Зато в курсе о проблемах этого подхода и что все кто может расстаются с ним в пользу ЖЦ.

Там счётчик и кое-какие флаги хранятся в самом указатели (на 64-ёх битных процессорах естественно).

VD>Прими за данность, что ты можешь быть не прав.

Готов принять, если и ты готов. )

VD>И в чем отличие этих языков ты знаешь? Sing# — это шарп в который встроинпаттерн обмена сообщениями. В самом компиляторе джит заменен на компиляцию во время установки (аналог ngen). Это все. GC на месте. Никаких других изменений нет.

VD>Так, что не недо ляля.

Цитирую из твой любимой википедии (http://en.wikipedia.org/wiki/Spec_Sharp):

Sing Sharp (or Sing#) is a superset of Spec Sharp. Microsoft Research developed Spec#, and later extended it into Sing# in order to develop the Singularity operating system. Sing# augments the capabilities of Spec# with support for channels and low-level programming language constructs, which are necessary for implementing system software.

Так что там про ляля? )

VD>И чем этот рекламный булшит противоречит процитированному мной? Мы уже выяснили, что systems означает "наличие указателей" гы–гы.

Мдааа. )

VD>Это одна софтяра или несколько?

Это программно-аппаратный комплекс, состоящий из нескольких взаимодействующих модулей. )

VD>Без задержки даже одна инструкция процессора не исполняется. Ты это обязан знать.

VD>Стало быть речь идет о предсказуемых задержках, ака гарантированном времени отклика, ака риалтайм или о просто быстро коде.

Да, местами реалтайм (это в микроконтроллерах), а местами просто быстрый код (это в "кодеках").

VD>Гуй на С++ пишете?

Да)

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, VladD2, Вы писали:

VD>>Буст — это библиотека залатывающая дыры стандарта С++. Аналогичные возможности или уже есть в библиотеках дотнета, или она не нужна, так как является костылями для плюсов.

VD>>Что, за исключением спорита (превосходящих его аналогов макросов сразу два) , есть в тесте, что нет в библиотеках дотнета или в самом дотнете? Только конкретно.

_>Ты снова не понимаешь или притворяешься?
Да сколько можно...

_> Я же уже несколько раз повторил, что речь не о библиотеках, которых вообще нет в .net,
В смысле нет? Весь дотнет это огромный конгломерат библиотек — dll-ек. Плюс мульон сторонних библиотек.

_> а о библиотеках, переписывание которых с помощью МП позволяет добиться более эффективных результатов.
То что имеет смысл быть написанно с МП уже написано давно. Это не сводится просто к библиотекам — это реально конструкции языка. Но библиотеки написанные при помощи этих конструкций могут быть использованы и в C#.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

Здравствуйте, Sinclair, Вы писали:

S>Ну откуда они могут быть "быстрее всех", когда за каждое убийство объекта приходится платить вставкой в список свободных?
S>Объекты фиксированного размера со стековым временем жизни в дотнете делаются на структурах и работают с той же скоростью, что и в С/С++.

О, т.е. мы можем взять экземпляр любого класса и разместить его в стеке или как?

S>А объекты динамического размера (строки, массивы) при детерминистической финализации таки проигрывают практически любому современному GC.

Только при условие бесконечной памяти. Я уже кинул Владу ссылку на полезную статью на эту тему. Ну повторю на всякий случай: http://habrahabr.ru/post/188580/. Причём в статье рассматривается ситуация с мобильными устройствами — там вообще мрак. Но и на больших системах память всё равно не бесконечна.

P.S. В C++ строки далеко не всегда хранятся в куче. Ну это я так, просто мелкий штришок к сведению. )

Здравствуйте, alex_public, Вы писали:
_>О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )
Вы мне лучше расскажите, что будет, если я потом напишу

return &a;

Вся штука escape-анализа — в том, что он сам определяет, передаю ли я ссылку за пределы скоупа, или можно обойтись стеком. С гарантиями.
А у вас в реальном коде будут постоянно развлечения на ровном месте. Для примитивных типов, понятное дело, семантика копирования заменяет вообще всё и решает все проблемы.
Вот только в дотнете для них же имеем ровно ту же реализацию.
А как только вы выйдете за их пределы и начнёте работать хотя бы со строками, вот тут и начнётся веселуха — либо беспричинные копирования со штрафом O(N), либо шансы нарваться на обращение к уничтоженному объекту, либо рефкаунты. А escape analysis позволяет программисту не думать о том, какие строки у него временные, а какие — надолго.
То есть уже 20 лет GC позволяет не думать об этом; EA всего лишь даёт дополнительную возможность снизить нагрузку на GC для алгоритмов с большим количеством временных объектов, в которых можно заменить new на stackalloc.

Здравствуйте, Sinclair, Вы писали:

_>>О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )
S>Вы мне лучше расскажите, что будет, если я потом напишу
S>

S>return &a;
S>

А зачем мне так писать? ) Я напишу:

return a;

И сразу замечу, что никакого копирования тут не будет (начиная ещё с C++11). Точнее оно и до C++11 могло сработать без копирования (RVO), но это была просто возможная оптимизация. А теперь это 100% гарантия на базе конструкции языка (move constructor). Точнее опять же может сработать просто RVO (и тогда вообще никаких действий не производится), а если не сработает, то гарантированно отработает мгновенный move constructor.

S>Вся штука escape-анализа — в том, что он сам определяет, передаю ли я ссылку за пределы скоупа, или можно обойтись стеком. С гарантиями.

Да, иногда определяет. )

S>А у вас в реальном коде будут постоянно развлечения на ровном месте. Для примитивных типов, понятное дело, семантика копирования заменяет вообще всё и решает все проблемы.
S>Вот только в дотнете для них же имеем ровно ту же реализацию.
S>А как только вы выйдете за их пределы и начнёте работать хотя бы со строками, вот тут и начнётся веселуха — либо беспричинные копирования со штрафом O(N), либо шансы нарваться на обращение к уничтоженному объекту, либо рефкаунты. А escape analysis позволяет программисту не думать о том, какие строки у него временные, а какие — надолго.

Move semantics позволяет всё тоже самое, только ещё более эффективно (потому как детерминировано).

S>То есть уже 20 лет GC позволяет не думать об этом; EA всего лишь даёт дополнительную возможность снизить нагрузку на GC для алгоритмов с большим количеством временных объектов, в которых можно заменить new на stackalloc.

Если бы все эти плюшки GC были бы совершенно бесплатными, то никто бы и не спорил (собственно тогда бы наверное не осталось языков без GC).

Здравствуйте, alex_public, Вы писали:

_>А зачем мне так писать?
Затем, что у вас в сигнатуре — A*.

) Я напишу:
_>

_>return a;
_>

_>И сразу замечу, что никакого копирования тут не будет (начиная ещё с C++11). Точнее оно и до C++11 могло сработать без копирования (RVO), но это была просто возможная оптимизация. А теперь это 100% гарантия на базе конструкции языка (move constructor). Точнее опять же может сработать просто RVO (и тогда вообще никаких действий не производится), а если не сработает, то гарантированно отработает мгновенный move constructor.
Ок, я был недостаточно убедителен.
Отлично — вы пишете

auto b = someOtherCoolFunction(a);

Как будет работать move constructor? Я так понимаю, что без inlining-а у компилятора маны не хватит на замену copy на move.
А если вы обнаружите, что стоимость копии a здесь чрезмерна, то попробуете передавать его по ссылке.
Но у вас нет никакой гарантии на то, что эту ссылку someOtherCoolFunction не прикопает ещё где-то — например, не передаст её в другой поток.
То есть мы опять возвращаемся к ручному управлению временем жизни и надежде на то, что "авось не стрельнет".
_>Move semantics позволяет всё тоже самое, только ещё более эффективно (потому как детерминировано).

Расскажите вкратце, как move semantics определяет, где её можно использовать, а где — нельзя.

_>Если бы все эти плюшки GC были бы совершенно бесплатными, то никто бы и не спорил (собственно тогда бы наверное не осталось языков без GC).
Зависит от задачи. Понятно, что если у вас адски ограниченный memory footprint, то GC — не ваше всё.

Здравствуйте, alex_public, Вы писали:
_>О, т.е. мы можем взять экземпляр любого класса и разместить его в стеке или как?
Зачем любого? Есть типы, которые хорошо работают с value-семантикой — например, TimeSpan, DateTime, Decimal.
Вот их можно запросто разместить на стеке.
А вот как, и, главное, зачем размещать на стеке объекты типа WebRequest я, простите, не понимаю.

_>Только при условие бесконечной памяти. Я уже кинул Владу ссылку на полезную статью на эту тему. Ну повторю на всякий случай: http://habrahabr.ru/post/188580/.
Не бесконечной, а достаточно большой.
Понятно, что GС даёт оверхед. Но даже в случае предельно ограниченной памяти, хороший GC даёт всего 70% потерь по сравнению с ручным менеджментом.
При двукратном превышении — отставание всего 17%. Начиная с 2.5-кратного превышения, перформанс GC и ручного управления становятся неразличимы.
На минуточку напомню, что мы говорим не о производительности приложения, а о затратах только на memory management. Т.е. если приложение хотя бы половину времени тратит на полезную работу, то разница между подходами к управлению памятью сокращается ещё вдвое.

И это — в обмен на гарантии type safety!
Для очень широкого класса задач это более чем приемлемая цена.

Здравствуйте, Sinclair, Вы писали:

_>>А зачем мне так писать?
S>Затем, что у вас в сигнатуре — A*.

Голые указатели в современном C++? Какая ересь. Тогда уж unique_ptr<A> будет...

S>Ок, я был недостаточно убедителен.
S>Отлично — вы пишете
S>

S>auto b = someOtherCoolFunction(a);
S>

S>Как будет работать move constructor? Я так понимаю, что без inlining-а у компилятора маны не хватит на замену copy на move.

Во многих случаях хватит. ) Но если нет, то можно ему подсказать, написав auto b = someOtherCoolFunction(move(a));.

S>А если вы обнаружите, что стоимость копии a здесь чрезмерна, то попробуете передавать его по ссылке.
S>Но у вас нет никакой гарантии на то, что эту ссылку someOtherCoolFunction не прикопает ещё где-то — например, не передаст её в другой поток.
S>То есть мы опять возвращаемся к ручному управлению временем жизни и надежде на то, что "авось не стрельнет".

Это всё в прошлом. )

S>Расскажите вкратце, как move semantics определяет, где её можно использовать, а где — нельзя.

Применяется ко всем временным объектам, т.е. грубо говоря таким, которые дальше однозначно не используются (соответственно автоматически подходят все return'ы, цепочки вычислений и т.п.). Плюс можно самому указать (см. выше).

S>Зависит от задачи. Понятно, что если у вас адски ограниченный memory footprint, то GC — не ваше всё.

Это не единственная проблема. Остановки мира тоже совсем не радуют на некоторых задачах. )

Здравствуйте, alex_public, Вы писали:

_>Во многих случаях хватит. ) Но если нет, то можно ему подсказать, написав auto b = someOtherCoolFunction(move(a));.
А что скажет компилятор на auto c = yetAnotherCoolFunction(a); парой строчек ниже?

_>Применяется ко всем временным объектам, т.е. грубо говоря таким, которые дальше однозначно не используются (соответственно автоматически подходят все return'ы, цепочки вычислений и т.п.).
Ну, то есть тот же самый escape analysis.
_>Плюс можно самому указать (см. выше).
Ага, вот это — основное отличие от EA.
_>Это не единственная проблема. Остановки мира тоже совсем не радуют на некоторых задачах. )
Stop the world коллекторов в природе осталось мало.

Здравствуйте, Sinclair, Вы писали:

S>Зачем любого? Есть типы, которые хорошо работают с value-семантикой — например, TimeSpan, DateTime, Decimal.
S>Вот их можно запросто разместить на стеке.
S>А вот как, и, главное, зачем размещать на стеке объекты типа WebRequest я, простите, не понимаю.

Ну вообще то работа со стеком заметно быстрее. Так что как раз нужны причины для не размещения на стеке.

S>Не бесконечной, а достаточно большой.
S>Понятно, что GС даёт оверхед. Но даже в случае предельно ограниченной памяти, хороший GC даёт всего 70% потерь по сравнению с ручным менеджментом.
S>При двукратном превышении — отставание всего 17%. Начиная с 2.5-кратного превышения, перформанс GC и ручного управления становятся неразличимы.
S>На минуточку напомню, что мы говорим не о производительности приложения, а о затратах только на memory management. Т.е. если приложение хотя бы половину времени тратит на полезную работу, то разница между подходами к управлению памятью сокращается ещё вдвое.

Сомнительные цифры, т.к. не указана реализация ручного управления — может там всё в том же самом стеке лежит?) Это больше похоже на изменение производительности GC относительно своего же идеального варианта. Вот в такое мне вполне верится...

S>И это — в обмен на гарантии type safety!
S>Для очень широкого класса задач это более чем приемлемая цена.

Насчёт последней фразы я конечно же согласен. ) К примеру я сам с удовольствием использую Python (а там вообще всё мрачно в этом смысле) и нисколько не напрягаюсь из-за его GC. )

Здравствуйте, alex_public, Вы писали:
_>Ну вообще то работа со стеком заметно быстрее.

_>Так что как раз нужны причины для не размещения на стеке.

Даже если вы сможете запихать WebRequest, у которого все члены — сплошная динамика, на стек, то выигрыш вы не сможете заметить и в микроскоп.
Банальная валидация URL на корректность уже сожрёт на порядок больше, чем инкремент heap pointer. Это я уже не говорю про собственно раундтрип на сервер — мы же webRequest не ради стека создаём.

_>Сомнительные цифры, т.к. не указана реализация ручного управления — может там всё в том же самом стеке лежит?) Это больше похоже на изменение производительности GC относительно своего же идеального варианта. Вот в такое мне вполне верится...
Ручное управление — через malloc и free. Читайте не пересказ для чайников, а ту самую статью, ссылка на которую лежит рядом со слайдом (2006 года, кстати. Т.е. в 2014 можно бы и перемерить результаты).

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Sinclair, Вы писали:

S>>Зачем любого? Есть типы, которые хорошо работают с value-семантикой — например, TimeSpan, DateTime, Decimal.
S>>Вот их можно запросто разместить на стеке.
S>>А вот как, и, главное, зачем размещать на стеке объекты типа WebRequest я, простите, не понимаю.

_>Ну вообще то работа со стеком заметно быстрее. Так что как раз нужны причины для не размещения на стеке.

Причина очень простая — время жизни объекта более чем вызов ф-ции/метода. Т.е. выигрыш может быть заметен только для локальных переменных.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

Здравствуйте, Sinclair, Вы писали:

S>А что скажет компилятор на auto c = yetAnotherCoolFunction(a); парой строчек ниже?

Ничего не скажет. Просто в yetAnotherCoolFunction пойдёт пустой объект.

_>>Применяется ко всем временным объектам, т.е. грубо говоря таким, которые дальше однозначно не используются (соответственно автоматически подходят все return'ы, цепочки вычислений и т.п.).
S>Ну, то есть тот же самый escape analysis.

Нуу не совсем. Всё же это не оптимизация, реализация которой может меняться в каждой версии, а чётко зафиксированный стандарт языка.

_>>Плюс можно самому указать (см. выше).
S>Ага, вот это — основное отличие от EA.

На самом деле в большинстве случаев автоматики хватает, а это для какой-то специальной оптимизации к примеру в замыканиях и т.п. Они же с приходом полиморфных лямбд стали совсем удобными. Можно даже такой http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc беспредел творить. )))

Здравствуйте, Sinclair, Вы писали:

S>Даже если вы сможете запихать WebRequest, у которого все члены — сплошная динамика, на стек, то выигрыш вы не сможете заметить и в микроскоп.
S>Банальная валидация URL на корректность уже сожрёт на порядок больше, чем инкремент heap pointer. Это я уже не говорю про собственно раундтрип на сервер — мы же webRequest не ради стека создаём.

Если запихивание требует каких-то усилий, то естественно в этом нет смысла. А если это как раз стандартная техника работы в языке, то почему бы и нет? )

Здравствуйте, Sinclair, Вы писали:

S>Объекты фиксированного размера со стековым временем жизни в дотнете делаются на структурах и работают с той же скоростью, что и в С/С++.
S>А объекты динамического размера (строки, массивы) при детерминистической финализации таки проигрывают практически любому современному GC.

А в чем пробелема поместить обьект диманического размера в стек? Как-нить так:

void f(uint64_t value)
{
    int n = __builtin_popcountl(value);
    uint64_t tmp[n];
    for (int i=0; i<n; ++n) {
        tmp[i] = value & (-value);
        value ^= tmp[i];
    }

    /* Process tmp */
    /* ........... */
}

Здравствуйте, alex_public, Вы писали:

S>>А что скажет компилятор на auto c = yetAnotherCoolFunction(a); парой строчек ниже?

_>Ничего не скажет. Просто в yetAnotherCoolFunction пойдёт пустой объект.
Отличная грабля. И это в то время, когда передовики производства совершенствуют средства обнаружения lack of definite assignment, у нас С++ неспособен отрепортить definite lack of assignment?

Здравствуйте, Mystic, Вы писали:

M>А в чем пробелема поместить обьект диманического размера в стек?
А какого размера у вас stack? Если я попробую поместить в стек 36мегабайтный битмэп, он не треснет?

Здравствуйте, Sinclair, Вы писали:

M>>А в чем пробелема поместить обьект диманического размера в стек?
S>А какого размера у вас stack? Если я попробую поместить в стек 36мегабайтный битмэп, он не треснет?
Поэтому у программиста C есть вьібор, где и как помещать.

Здравствуйте, Sinclair, Вы писали:

EP>>Я думаю это дело даже можно частично автоматизировать — если после копии ref-counted куда-то, он больше не использовался — то достаточно move'а.
S>О, ещё немного — и вы изобретёте escape analysis.

Во-первых, совершенно не в тему — мы говорим про минимизацию ++/--ref_count, а не конвертацию аллокаций в куче в аллокации на стэке.
Во-вторых, если уже говорить про escape analysis, то основной benefit который он даёт — в C++ это поведение по умолчанию

EP>>>>Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec,
WH>>>Про то, что они редкие это исключительно твоя спекуляция.
EP>>Причём достаточно чтобы счётчик прошёл только следующую последовательность состояний: "1, 2, 1, 0". А вот передёргивать при переходе, например, от состояния "получаем" к "отправляем" — нет никакой необходимости, достаточно move — так как эстафета передаётся.
S>И как компилятор гарантирует нам отсутствие обращений к источнику после move?

Там где он может гарантировать — он сам ставит move. А там где нет — его ставит пользователь.
Более того, использовать объект после того как из него что-то move'нули вполне возможно.

EP>>Раз он точный, то память уплотнить (и обновить указатели) не проблема, но ограничения определённые есть. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
S>Точный GC в реальный C++ воткнуть не удастся. Потому что в нём 99% библиотек написаны в стиле "если сейчас луна в ущербе, то lParam — это указатель на cтруктуру; а если зима — то это идентификатор ресурса. Тип структуры определяется полем length".

Во-первых, ты явно путаешь C++ и C.
Во-вторых, речь шла про какие-то специфические задачи, для которых без GC ну ни как. Я говорю о том, что для таких задач можно использовать точный GC в виде отдельной кучи (и привёл пример такого GC), а не про точный GC который будет работать для всех сторонних библиотек автоматом.

EP>>Грубо говорят если из-за бага в алгоритме он вышел за пределы диапазона, но кинул исключение — работу свою он не выполнил, постусловий не достиг, перевёл программу в неопределённое состояние.
S>В том то и дело, что программу он перевёл в определённое состояние.

Каким образом? Весь вызывающий код зависел от достижения постусловий данным алгоритмом, так как он честно выполнил все предусловия. Но этого не случилось из-за бага — получаем неопределённое состояние.

S>Это гораздо, гораздо лучше неопределённого состояния, которым так гордятся программисты C++.

Пруф.

Здравствуйте, DarthSidius, Вы писали:

_>>Ну вообще то работа со стеком заметно быстрее. Так что как раз нужны причины для не размещения на стеке.
DS>Причина очень простая — время жизни объекта более чем вызов ф-ции/метода. Т.е. выигрыш может быть заметен только для локальных переменных.

move semantics

S>return &a;
S>

http://coliru.stacked-crooked.com/a/ce7861835399bf6d

error: address of stack memory associated with local variable 'a' returned

S>Вот только в дотнете для них же имеем ровно ту же реализацию.
S>А как только вы выйдете за их пределы и начнёте работать хотя бы со строками, вот тут и начнётся веселуха — либо беспричинные копирования со штрафом O(N), либо шансы нарваться на обращение к уничтоженному объекту, либо рефкаунты. А escape analysis позволяет программисту не думать о том, какие строки у него временные, а какие — надолго.

#include <string>
using namespace std;

string test()
{
    string x = "abc";
    return x;
}

Не тут, ни "штрафа O(N)", ни refcount

Здравствуйте, Sinclair, Вы писали:

S>Stop the world коллекторов в природе осталось мало.

У не stop the world свой набор компромиссов, например размазывание тонким слоем по всему коду какой-нибудь конкурентной пакости.

Здравствуйте, Sinclair, Вы писали:

S>А как только вы выйдете за их пределы и начнёте работать хотя бы со строками, вот тут и начнётся веселуха — либо беспричинные копирования со штрафом O(N), либо шансы нарваться на обращение к уничтоженному объекту, либо рефкаунты. А escape analysis позволяет программисту не думать о том, какие строки у него временные, а какие — надолго.

Вообще говоря, тут мысль достаточно простая: там где в GC языках ставят "new", в 95%-99% случаях на C++ не будет никакого ref-counting и подобного, и это default style, причём это не только для памяти, а для всех ресурсов (с которыми в C# уже начинаются проблемы, которые не решаются полностью using-костылями).
То есть то, что себе фантазируют эвагелисты GC — "О, вот тут ставлю ещё один new, GC — хороший, escape analysis — хороший. А вот на C++ была бы обязательно возня со smart-pointers, бррр." — не более чем фантазия или впитанные рекламные мантры

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, alex_public, Вы писали:

S>>>А что скажет компилятор на auto c = yetAnotherCoolFunction(a); парой строчек ниже?

_>>Ничего не скажет. Просто в yetAnotherCoolFunction пойдёт пустой объект.
S>Отличная грабля. И это в то время, когда передовики производства совершенствуют средства обнаружения lack of definite assignment, у нас С++ неспособен отрепортить definite lack of assignment?

Вообще-то там явно руками был написан std::move(a). Куда уж definitee — ты его сам руками написал.

Здравствуйте, alex_public, Вы писали:

VD>>Есть аналог на computation expressions. Он чутка медленнее, но сильно гибче. Есть еще макры для многопоточности, но я их не использовал.

_>Я правильно понял, что C# код с await/async в Nemerle сейчас работать не будет?
Все будет работать.
Упрощенно можно сказать, что async/await — это сахар над

public Task<TResult> ContinueWith<TResult>(
    Func<Task, TResult> continuationFunction
)

А работу с тасками через продолжения никто не отменял.

Кроме того, есть синтаксический аналог async/await https://github.com/rsdn/nemerle/tree/master/snippets/Nemerle.Async
И как писали выше, есть https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro на которых реализуется 1 в 1 вычислитель над тасками, как в F# (https://github.com/fsprojects/fsharpx/blob/master/src/FSharpx.Core/ComputationExpressions/Monad.fs#L994).
С точки зрения эффективности генерируемого кода этот вариант проигрывает async/await, но по удобству впереди. Потому что если необходимо работать с отменой задачи или опциями продолжений, то весь async/await сахарок идет лесом, да еще эти параметры тащить руками через все вычисление.

 type TaskBuilder(?continuationOptions, ?scheduler, ?cancellationToken) =

А на ComputationExpressions автоматически без лишних телодвижений.

_>А как тогда реализована работа с IOCP?
IOCP из дотнета не видны. Есть Task<T> представляющий асинхронную операцию, а как она внутри устроена информации нет, да и способов узнать вроде тоже.

Здравствуйте, alex_public, Вы писали:

_>Если руководствоваться правилом "и так работает", то в общем то и Nemerle вообще не нужен, т.к. C# вообще то тоже вполне "и так работает".

Работает и, вопряки твоему высокомерному к нему отношению, работает не плохо.

Но, как ты верно заметили, МП в нем нет и расширяемости тоже. Еще ПМ нет, АлгТД и ряда удобных фичь немерла.

Собственно, одна из причин отсутствия масового причтия немерла среди шарп–программистов, то что шарп худо–бедно но развиваться. Линк — прекрасен. Лямбды тоже. Дженерики тоже не плохи, хотя и с проблемами.

_>А вот если всё же пытаться что-то улучшить, то можно увидеть что IEnumerable является очень бледной тенью Range из D.

Если ты попытаешься разобраться, узнаешь, что IEnumerable не догма ни в линках, ни в foreach. И то и другое спроектированно на базе паттернов.

Так что можно и производительность улучшить за счет перегрузок, и от использования интерфейсов избавиться.

Создание альтернативной экосистемы коллекций (например, в стиле stl) поломает совместимость, а большого толку не даст.

_>Причём как раз Nemerle (ну судя по тому, что ты о нём говоришь — я то его не изучал пока) мог бы легко поправить это.

Все и так не плохо. Хотя идея не лишина смысла. Можешь заняться. Будет еще один плюс и ещё одна альтернатива. Лично меня более–менее устраивает дотнетный подход и есть куча других задач.

_>Точно вот прямо все сделали? )

Все примерно как в плюсах. Все сделать нельзя. Сделано то что было востребованно теми кто использовал язык. Ну а частные проблемы можно решать создавая частные макро–либы. Если получится универсальное решение его можно предложить в стандартную макро–либу.

_>Гмм... И кто это только что говорил о самомнение, снисходительном отношение и т.п? )))

Я вижу, что ты и шарпе то не глубоко копал, а уж фичи из F#–я ты наверняка не не знаешь. В прочем, буду рад ошибиться.
Оператор структурного присвоения вообще штука еникальная. Делали аналог парповского инициализатора списков, а получилась вындервафля.

_>Я правильно понял, что C# код с await/async в Nemerle сейчас работать не будет?

Да. Хотя можно на те же компютейшоны транслировать. Но это поддержку шарпа нужно расширять.

_>А как тогда реализована работа с IOCP?

Что имеется в виду под этим сокращением? Completion Port винды? Если — да, то в дотнетных либах никаких проблем с ассинхроннвюым IO нет. Везде есть соответствующие перегрузки. Ну, а компьютейшоны отлично подходят для их "ввпрямления".

_>Это не разговор. Нужна целевая ниша.

Не нужна. Достаточно знать ограничения платформы.

_>Я вполне понимаю где выгодно применять Java/C#, где выгодно C++, а где Python и т.п. Так вот для Nemerle у меня нет такого же понимания. Потому как базируясь на платформе ориентированной на снижение цены разработки, он наоборот требует повышенной квалификации от программиста.

Все высокоуровневые языки ориентированы на снижение цены разработки. Посто есть и другие критерии. Скажем дотнет вряд ли приемлем для разработки для iOS или для драйверов. Питон не пригоден для требовательных к производительности алгоритмов, плюсы для задачи где надежность стоит сильно выше производительности.

Скажем если по прочим критериям задаче можно решить на Питоне, плюсах или Немерле, то я выберу Немерле именно из–за того, что на нам получится реализовать проект проще и дешевле.

_>Ты периодически как-то извращённо понимаешь мои слова. Когда я говорю о профессиональных инструментах, то совсем не подразумеваю, что использование этого инструмента сделает человека профессионалом, как ты почему-то подумал. Откуда такая странная мысль? Я под этим подразумеваю, что для использования этого инструмента требуется повышенный уровень знаний, т.е. что имеется большой порог вхождения. И это как бы минус в условиях современного бизнеса, который должен обязательно чем-то компенсироваться.

Это и есть твое надменное отношение. Ты ставишь знак равенства между специализацией (знанием граблей и паттернов позволяющих на них не наступать) и проффесианолизмом.

Если бы ты сказал "внимательности", "ответственности" и т.п. я бы не имел ничего против. Но делить людей на профессионалов и нет только на основании используемого языка — это просто глупость. Если я писал на плюсах (весьма успешно) и перешел на шара, я вдруг стал не профессиональным ламером? Гы–гы.

_>К примеру я помнится видел какие-то исследования (по студентам кажется смотрели), что саму концепцию МП способны нормально осознать и применять только часть программистов.

И что? Ну вот использует некоторый шарпщик T4.
Чем он от "проффесионала" лабающий код на плюсах без МП отличается?

_>Про плагины я давно видел. Но я так и не понял, имеется ли какое-то чёткое формальное разделение nemerle кода с макросами и без?

Макросы — это (грубо говоря) точка входа в программе. Она вызывает некий код который трансформирует код программы.

У макр есть свой спец синтаксис.

Но рассказывать об это долго. Особенно с телефона.

Почему бы не прочесть вводную статейку да не попробывать самому?

_>Насчёт костылей тут очень тонкий вопрос...

Вопрос очень прост. В дотнете есть функциональный тип (делегаты) , а в прюсах нет. Буст лечил эту недоработку, пока фанаты С++ обясняют почему эта фича не нужна...

_>...С ходу кроме Spirit'a вспоминаются Boost.Unit, Boost.Xpressive, Boost.MSM. Это из тех, что я сам трогал, а это естественно далеко не все.

Ну, вот ровно для этих задач и есть решения на макросах. Плюс еще эндцать задачек. Но контейнеры удовлетворяют дотнетовские. А если чего–то нет, то можно создать нужную реализацию без макросов. Кстати, в std: :vector я тоже МП не припоминаю.

.

_>Ну а вообще для программирование на Nemerle я бы поискал образцы скорее в стандартной библиотеке D, а не в Boost'e. Всё же в C++ МП слабенькое...

ОК. И что там?

Кстати, для ди инфраструктура всетаки есть или ее нет?

_>А, понял. Ну так напомню, что Spirit — это не только парсер, но и генератор (ну и лексер ещё там есть). Хотя если этот твой код умеет скачивать и проверять при генерации xml схему, то такого конечно даже близко нет. А если без учёта схемы, то вроде как простая вещь.

Схему не умеет, но научить это делать элементарно. Просто берем схему и проверяем через имеющицся АПИ. Это же не шаблоны. Макры могут хоть в интернет сходить, хоть в базу данных залезть.

_>Я правильно понял, что ты считаешь, что с помощью МП улучшать в контейнерах .net'a нечего? )

В этом нет необходимости.
А в каких контейнерах stl используется МП? И зачем?

_>Там счётчик и кое-какие флаги хранятся в самом указатели (на 64-ёх битных процессорах естественно).

И что? Это спосает отзацикливаний, фрагментации памяти и необходимости тратить время на подсчет ссылок и очистку памяти при нулевом их числе?

_>Готов принять, если и ты готов. )

Я всегда это осознаю. Покажите в чем я не прав и я изменю точку зрения.

_>Цитирую из твой любимой википедии (http://en.wikipedia.org/wiki/Spec_Sharp):
_>

Sing Sharp (or Sing#) is a superset of Spec Sharp. Microsoft Research developed Spec#, and later extended it into Sing# in order to develop the Singularity operating system. Sing# augments the capabilities of Spec# with support for channels and low-level programming language constructs, which are necessary for implementing system software.

_>Так что там про ляля? )

Ну, так потрудись найти список этих low-level programming language constructs. Может я чего не знаю.

VD>>И чем этот рекламный булшит противоречит процитированному мной? Мы уже выяснили, что systems означает "наличие указателей" гы–гы.

_>Мдааа. )

Что "мда"? Это твои слова? Если ты с собой не согласент, то дай другое определение того, что в языке должно быть, чтобы он стал "сиссстемным".

_>Это программно-аппаратный комплекс, состоящий из нескольких взаимодействующих модулей. )

Яснее сильно не стало.

_>Да, местами реалтайм (это в микроконтроллерах), а местами просто быстрый код (это в "кодеках").

Ну вот тут спорить не буду. Это задачи для С/С++. Но вы же не только их на плюсах решаете?

VD>>Гуй на С++ пишете?

_>Да)

Ну вот это совсем не по делу применение, если, конечно там все не настолько приметивно, что по фиг на чем писать.

Здравствуйте, alex_public, Вы писали:

_>О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )

Дело ж не в записи, а в том, что в одном случае я обязан заранее знать где и сколько будет жить обект, а во втором я не забиваю себе голову и получаю тот же оезутьтат, если время жизни соответствует размещению на стеке.

Здравствуйте, alex_public, Вы писали:

_>Ну так и не проблема использовать C библиотеку в C++ коде. Собственно мы некоторые даже используем, т.к. их аналогов на C++ не найти (например определённая реализация Пролога). Но лучше бы C++ библиотеку. Так же как лучше родную Nemerle библиотеку (сам же сказал, что "усложняет написание").

Я уже отвечал на этот вопрос. Аналогия не верна.

Переписывать имеет смысл, только только то, что даст приемущество отгегерации кода во время компиляции и т.п.

Но это, по факту, не такое частое явление.

Ситуция с Ли в корне отличается. В Ди вынуждены переписывать библиотеки из–за сильного парадигмного и технического (отсутствие модульности в С, например) отличия.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>То есть то, что себе фантазируют эвагелисты GC — "О, вот тут ставлю ещё один new, GC — хороший, escape analysis — хороший. А вот на C++ была бы обязательно возня со smart-pointers, бррр." — не более чем фантазия или впитанные рекламные мантры

Конечно в С++ все иначе. Там тупо размещают объект на стеке передают указатель на него функции, а та сует его в поле.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>У не stop the world свой набор компромиссов, например размазывание тонким слоем по всему коду какой-нибудь конкурентной пакости.

Только перед кодом меняющим ссылки. Рефкаунтинг размазывает не меньше.

Здравствуйте, Mystic, Вы писали:
M>Поэтому у программиста C есть вьібор, где и как помещать.
Ну и у программиста С# тоже есть выбор, где и как размещать. См. напр. stackalloc.

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Во-первых, совершенно не в тему — мы говорим про минимизацию ++/--ref_count, а не конвертацию аллокаций в куче в аллокации на стэке.
С точки зрения математики, вы решаете смежную задачу. EA определяет, передаётся ли ссылка за пределы контекста, а move analysis определяет, используется ли ссылка после передачи.

EP>Во-вторых, если уже говорить про escape analysis, то основной benefit который он даёт — в C++ это поведение по умолчанию

Основной бенефит EA — это type safety, которой в С++ нет и не предвидится.

EP>Там где он может гарантировать — он сам ставит move. А там где нет — его ставит пользователь.
EP>Более того, использовать объект после того как из него что-то move'нули вполне возможно.
А, ну круто. Это опять грабли на ровном месте: к моменту, когда управление попадёт в то место, которое обращается к передвинутому объекту, тот может быть уже мёртв.

EP>Во-первых, ты явно путаешь C++ и C.
Во-первых, нет. Покажите мне самую-самую С++ библиотеку для программирования под Windows, и я вас ткну в то место, где сидят ровно такие приведения.

EP>Во-вторых, речь шла про какие-то специфические задачи, для которых без GC ну ни как. Я говорю о том, что для таких задач можно использовать точный GC в виде отдельной кучи (и привёл пример такого GC), а не про точный GC который будет работать для всех сторонних библиотек автоматом.
Это всё будет работать на уровне соглашений. Никакого контроля за этим нет — ни за тем, чтобы в этой вашей куче не использовались union-ы или другие замаскированные указатели, ни за отсутствием ссылок на объекты в этой куче из не-GC кучи и наоборот.

EP>Каким образом? Весь вызывающий код зависел от достижения постусловий данным алгоритмом, так как он честно выполнил все предусловия. Но этого не случилось из-за бага — получаем неопределённое состояние.
Мы получаем вполне определённое состояние: вылет исключения. Есть стратегии детектирования таких состояний: catch-block.
Не всякий код выходит у нас exception-safe, но мы по крайней мере можем его таковым написать.
В С++ же обращение к разрушенному объекту невозможно надёжно задетектировать. От слова вообще.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, Sinclair, Вы писали:

_>>>О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )
S>>Вы мне лучше расскажите, что будет, если я потом напишу
S>>

S>>return &a;
S>>

EP>http://coliru.stacked-crooked.com/a/ce7861835399bf6d
EP>

EP>error: address of stack memory associated with local variable 'a' returned

EP>

S>>Вот только в дотнете для них же имеем ровно ту же реализацию.
S>>А как только вы выйдете за их пределы и начнёте работать хотя бы со строками, вот тут и начнётся веселуха — либо беспричинные копирования со штрафом O(N), либо шансы нарваться на обращение к уничтоженному объекту, либо рефкаунты. А escape analysis позволяет программисту не думать о том, какие строки у него временные, а какие — надолго.

EP>

EP>#include <string>
EP>using namespace std;

EP>string test()
EP>{
EP>    string x = "abc";
EP>    return x;
EP>}
EP>

Не тут, ни "штрафа O(N)", ни refcount

Давайте чуть усложним пример:

#include <string>
using namespace std;
string f(bool cond = false) {
  string first("first");
  string second("second");
  return cond ? first : second;
}

Ваш компилятор всё ещё сумеет RVO? Поздравляю, вы получаете штраф O(N) за вызов конструктора копирования. Если вы используете одну из типичных реализаций std::string, то при увеличении длины аргументов вы выйдете за порог SSO и получите refcount.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Вообще говоря, тут мысль достаточно простая: там где в GC языках ставят "new", в 95%-99% случаях на C++ не будет никакого ref-counting и подобного, и это default style, причём это не только для памяти, а для всех ресурсов (с которыми в C# уже начинаются проблемы, которые не решаются полностью using-костылями).
Как и большинство простых мыслей, эта имеет весьма отдалённое отношение к реальности.

Здравствуйте, jazzer, Вы писали:
J>Вообще-то там явно руками был написан std::move(a). Куда уж definitee — ты его сам руками написал.

Я, если честно, не вполне понимаю, какой вопрос вы тут хотели задать.
На всякий случай отвечу на вопрос "а чего синклер ожидал от компилятора в таком очевидном случае, почему, и зачем":
1. Я ожидал, что компилятор выдаст ошибку типа "possible using of a location without initialization".
2. Потому, что у компилятора достаточно данных для того, чтобы выдать такую ошибку
3. Для того, чтобы я не проимел ссылку в чуть более интересных сценариях:

auto a = some::factory.CreateNew(42);
if (isPrime(rand(1000000))
  auto b = dealWithA(move(a));
cout << a.status(); // dead or alive?

Здравствуйте, Sinclair, Вы писали:

EP>>Более того, использовать объект после того как из него что-то move'нули вполне возможно.
S>А, ну круто. Это опять грабли на ровном месте: к моменту, когда управление попадёт в то место, которое обращается к передвинутому объекту, тот может быть уже мёртв.
В смысле мёртв? Если мы муваем объект, то у нас остаётся "пустой" объект. Использовать его вполне корректно. С некоторыми ограничениями, но можно. Именно поэтому "possible using of a location without initialization" тут не катит. Ну да, выстрелить в ногу можно.

Здравствуйте, DarkEld3r, Вы писали:
DE>В смысле мёртв? Если мы муваем объект, то у нас остаётся "пустой" объект.
А что такое "пустой объект"? Я не помню такого термина в спецификации С++, по которой работал я (в своей пред-предыдущей жизни).

Здравствуйте, Sinclair, Вы писали:

S>А что такое "пустой объект"? Я не помню такого термина в спецификации С++, по которой работал я (в своей пред-предыдущей жизни).
Если на пальцах, то как-то так:

string s("test"); // s = "test".
foo(move(s)); // Тут у нас "пустой обьект".

s = "new value"; // Присваиваем новое значение, всё корректно.
foo(move(s)); // Можем смувить ещё раз.

Естественно, в спецификации будут несколько другие термины. Ну и после перемещения безопасно можно выполнять только некоторые действия (они перечислены, естественно). Скажем, размер, скорее всего, не будет обнуляться — для эффективности. То есть вот так нельзя:

foo(move(s)); 
if(s.size() > 1)
  s[0] = 'a';

Здравствуйте, VladD2, Вы писали:

EP>>То есть то, что себе фантазируют эвагелисты GC — "О, вот тут ставлю ещё один new, GC — хороший, escape analysis — хороший. А вот на C++ была бы обязательно возня со smart-pointers, бррр." — не более чем фантазия или впитанные рекламные мантры

VD>Конечно в С++ все иначе. Там тупо размещают объект на стене передают указатель на него функции, а та сует его в поле.

Или там лямбда захватывает

using System;
using System.IO;

public class Test
{
    public delegate void fireworks();
    public static fireworks make_closure(FileStream fs)
    {
        return () => fs.Read(new byte[10], 0, 10);
    }
    public static fireworks fire()
    {
        using (var fs = File.Open("file", FileMode.Open))
        {
            return make_closure(fs);
        }
    }
    public static void Main()
    {
        fire()();
    }
}

А вообще, у тебя аргументация какая-то казуистическая

Я говорю что в 95%-99% достаточно scope-based, ты типа как контраргумент приводишь случай из оставшегося 1%.
Да, в некоторых случаях недостаточно, и об этом выше я ни раз сам говорил. Что, тем не менее, никак не опровергает этот тезис

Здравствуйте, VladD2, Вы писали:

EP>>У не stop the world свой набор компромиссов, например размазывание тонким слоем по всему коду какой-нибудь конкурентной пакости.
VD>Только перед кодом меняющим ссылки. Реыкаунтинг размазывает не меньше.

Для refcounting (который нужен не всегда) происходит атомарный wait-free inc при копировании ссылки, и атомарный wait-free dec при выходе ссылки из scope.

В том же C4, на который вы тут не раз ссылались, манипуляции происходят при каждой загрузке указателя (и не только), плюс конкурентная пакость в отдельных потоках. Причём в нём всё равно есть stop-the-world, по крайней мере в реализации описанной в статье

Здравствуйте, Sinclair, Вы писали:

EP>>Во-первых, совершенно не в тему — мы говорим про минимизацию ++/--ref_count, а не конвертацию аллокаций в куче в аллокации на стэке.
S>С точки зрения математики, вы решаете смежную задачу. EA определяет, передаётся ли ссылка за пределы контекста, а move analysis определяет, используется ли ссылка после передачи.

Вот видишь, сам понимаешь, что хоть какие-то схожие черты есть, но задача-то другая, и решения у неё другие.

EP>>Во-вторых, если уже говорить про escape analysis, то основной benefit который он даёт — в C++ это поведение по умолчанию

S>Основной бенефит EA — это type safety, которой в С++ нет и не предвидится.

Непонятно что именно даёт здесь EA для type safety, которая и так была

EP>>Там где он может гарантировать — он сам ставит move. А там где нет — его ставит пользователь.
EP>>Более того, использовать объект после того как из него что-то move'нули вполне возможно.
S>А, ну круто. Это опять грабли на ровном месте: к моменту, когда управление попадёт в то место, которое обращается к передвинутому объекту, тот может быть уже мёртв.

Не мёртв, а пуст

Это считай своего рода swap с пустым объектом.

EP>>Во-первых, ты явно путаешь C++ и C.
S>Во-первых, нет. Покажите мне самую-самую С++ библиотеку для программирования под Windows,

Что такое "программирование под Windows"

Ок, например std::thread — в одной из реализаций внутри, там в том числе и "программирование под Windows"

S>и я вас ткну в то место, где сидят ровно такие приведения.

Внутри реализации или интерфейса?

EP>>Во-вторых, речь шла про какие-то специфические задачи, для которых без GC ну ни как. Я говорю о том, что для таких задач можно использовать точный GC в виде отдельной кучи (и привёл пример такого GC), а не про точный GC который будет работать для всех сторонних библиотек автоматом.
S>Это всё будет работать на уровне соглашений. Никакого контроля за этим нет — ни за тем, чтобы в этой вашей куче не использовались union-ы или другие замаскированные указатели, ни за отсутствием ссылок на объекты в этой куче из не-GC кучи и наоборот.

Без внешних утилит/верификаторов — да, только соглашения. Об ограничениях я говорил с самого начала, к чему капитанство — непонято.
Повторяю в N'ый раз

— эта техника подходит для затейливых задач, типа сложных графов, в которых без GC ну ни как.

EP>>Каким образом? Весь вызывающий код зависел от достижения постусловий данным алгоритмом, так как он честно выполнил все предусловия. Но этого не случилось из-за бага — получаем неопределённое состояние.
S>Мы получаем вполне определённое состояние: вылет исключения. Есть стратегии детектирования таких состояний: catch-block.
S>Не всякий код выходит у нас exception-safe, но мы по крайней мере можем его таковым написать.

Это вообще всё ортогонально. Невыполнение post-condition, при удовлетворённых pre-condition — это баг.
Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть.
В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях.

S>В С++ же обращение к разрушенному объекту невозможно надёжно задетектировать. От слова вообще.

Отчего же "от слова вообще"? Вот самый примитивный способ — клади каждый объект в отдельную виртуальную страницу. Или, например, используй инструментацию кода

Здравствуйте, Sinclair, Вы писали:

EP>>Вообще говоря, тут мысль достаточно простая: там где в GC языках ставят "new", в 95%-99% случаях на C++ не будет никакого ref-counting и подобного, и это default style, причём это не только для памяти, а для всех ресурсов (с которыми в C# уже начинаются проблемы, которые не решаются полностью using-костылями).
S>Как и большинство простых мыслей, эта имеет весьма отдалённое отношение к реальности.

Тогда расскажи нам, использующим C++ регулярно (а также и языки с GC), как же на самом деле у нас обстоят дела в C++.

Здравствуйте, Sinclair, Вы писали:

S>Отличная грабля. И это в то время, когда передовики производства совершенствуют средства обнаружения lack of definite assignment, у нас С++ неспособен отрепортить definite lack of assignment?

А с чего компилятор должен ругаться то? Никакой ошибки (в смысле падения и т.п.) при данном коде не произойдёт. Да, во вторую функцию не пойдут данные, но мы же самих переместили их в другое место в коде чуть выше. Т.е. твоя претензия тут аналогична такому:

vector<int> x={1, 2, 3};
x.clear();
f(x);//ой, а почему компилятор не предупредил меня, что я выше clear вызывал???

Здравствуйте, STDray, Вы писали:

STD>Кроме того, есть синтаксический аналог async/await https://github.com/rsdn/nemerle/tree/master/snippets/Nemerle.Async
STD>И как писали выше, есть https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro на которых реализуется 1 в 1 вычислитель над тасками, как в F# (https://github.com/fsprojects/fsharpx/blob/master/src/FSharpx.Core/ComputationExpressions/Monad.fs#L994).
STD>С точки зрения эффективности генерируемого кода этот вариант проигрывает async/await, но по удобству впереди. Потому что если необходимо работать с отменой задачи или опциями продолжений, то весь async/await сахарок идет лесом, да еще эти параметры тащить руками через все вычисление.
STD>

STD> type TaskBuilder(?continuationOptions, ?scheduler, ?cancellationToken) =
STD>

STD>А на ComputationExpressions автоматически без лишних телодвижений.

Ага, понятно. Т.е. всё же компилятор Nemerle не может компилировать современный C# код (существенное отличие от ситуации C->C++). Но при этом этот код можно переписать так, чтобы всё заработало.

Здравствуйте, alex_public, Вы писали:

_>А с чего компилятор должен ругаться то? Никакой ошибки (в смысле падения и т.п.) при данном коде не произойдёт. Да, во вторую функцию не пойдут данные, но мы же самих переместили их в другое место в коде чуть выше.

Я не мега-спец в C++, хочу узнать — что значит "не пойдут данные"? Если данные — это указатель, что туда "пойдет", NULL? А если int, то 0?

Здравствуйте, alex_public, Вы писали:

_>Ага, понятно. Т.е. всё же компилятор Nemerle не может компилировать современный C# код (существенное отличие от ситуации C->C++).
Nemerle — другой язык, в котором доступный идиомы из C# и даже больше. https://sites.google.com/site/gibekm/programming/nemerle/asyncawait

_> Но при этом этот код можно переписать так, чтобы всё заработало.
Это называется "переписать на Nemerle".

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Это вообще всё ортогонально. Невыполнение post-condition, при удовлетворённых pre-condition — это баг.
EP>Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть.
EP>В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях.
Вот есть у нас сервер. На нём работают 1000 пользователей.
В случае C# пользователь иногда будет получать сообщение: "Извыни дарагой. Нешмагла. У програмыст рука кривой. В него ужа патинка полетел."
Остальные 999 пользователей вообще ничего не заметят.

В случае с С++ если повезет упадёт весь сервер. Работа всех пользователей пропадёт.
Если не повезет. То сервер продолжит работать. Но вместо осмысленных ответов будет давать бред. Если совсем не повезёт то бред правдоподобный.
И этот баг будет жить годами.

Знаешь, как в яндексе борются с утечками памяти и проездами по памяти?
Рестартом демона по таймеру. Ну, или по факту выпадения в кору.

И это то, что происходит в реальности. А не в том эльфийском мире, который вы тут описываете.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

EP>>Это вообще всё ортогонально. Невыполнение post-condition, при удовлетворённых pre-condition — это баг.
EP>>Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть.
EP>>В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях.
WH>Вот есть у нас сервер. На нём работают 1000 пользователей.
WH>В случае C# пользователь иногда будет получать сообщение: "Извыни дарагой. Нешмагла. У програмыст рука кривой. В него ужа патинка полетел."
WH>Остальные 999 пользователей вообще ничего не заметят.

Цена не достижения постусловий везде разная. Где-то это очень важно, где-то нет.
Сглаживание последствий багов, никак не отменяет того что это баг.

WH>В случае с С++ если повезет упадёт весь сервер. Работа всех пользователей пропадёт.
WH>Если не повезет. То сервер продолжит работать. Но вместо осмысленных ответов будет давать бред. Если совсем не повезёт то бред правдоподобный.
WH>И этот баг будет жить годами.

Да, для некоторых классов багов, языки с GC и выключенным unsafe — дают определённые гарантии, которых нет в C++ без внешних тулз

WH>Знаешь, как в яндексе борются с утечками памяти и проездами по памяти?
WH>Рестартом демона по таймеру. Ну, или по факту выпадения в кору.

Ты так говоришь, как-будто проблемы утечек не существует для языков с GC.
Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны

WH>И это то, что происходит в реальности. А не в том эльфийском мире, который вы тут описываете.

Где мы описываем эльфийский мир?

Баги есть везде. И да, C++ на некоторые классы багов отвечает очень жёстко, самым низкоуровневым образом. Но это же очевидно, и с этим никто не спорил.

Здравствуйте, Sinclair, Вы писали:

S>Ваш компилятор всё ещё сумеет RVO?

RVO не было и в первом случае, был NRVO, или move

S>Поздравляю, вы получаете штраф O(N) за вызов конструктора копирования.

При таком коде — да, можно чуть изменить и не будет. Вообще-то уже выше по ветке обсуждали, что стандарт C++ говорит делать автоматический move только в некоторых случаях. Зачем повторятся-то?

Здравствуйте, Sinclair, Вы писали:

M>>Поэтому у программиста C есть вьібор, где и как помещать.
S>Ну и у программиста С# тоже есть выбор, где и как размещать. См. напр. stackalloc.

Только unsafe, да и class'ы пролетают

Здравствуйте, AlexRK, Вы писали:

_>>А с чего компилятор должен ругаться то? Никакой ошибки (в смысле падения и т.п.) при данном коде не произойдёт. Да, во вторую функцию не пойдут данные, но мы же самих переместили их в другое место в коде чуть выше.
ARK>Я не мега-спец в C++, хочу узнать — что значит "не пойдут данные"? Если данные — это указатель, что туда "пойдет", NULL? А если int, то 0?

Ни голый указатель, ни int не имеет смысла перемещать.
После того как объект переместили, он остаётся в valid'ном, но неопределённом состоянии. То есть в него можно что-то присвоить, или просто уничтожить.
Если хочется, в своих типах можно давать чуть большие гарантии, например после перемещения делать default contruction, но обычно делают просто "moved-from objects shall be placed in a valid but unspecified state".

Здравствуйте, AlexRK, Вы писали:

ARK>Я не мега-спец в C++, хочу узнать — что значит "не пойдут данные"? Если данные — это указатель, что туда "пойдет", NULL? А если int, то 0?
"Элементарные" типы данных не перемещаются (нет смысла) — они копируются. Так что указатель и инт и во второй вызов пойдут с оригинальными значениями. Для строк и прочих контейнеров "пойдут" пустые контейнеры. Вот unique_ptr действительно даст нулевой указатель.

Здравствуйте, VladD2, Вы писали:

VD>Работает и, вопряки твоему высокомерному к нему отношению, работает не плохо.

Почему высокомерное отношение то? Если я сам не раз писал, что C# великолепно справляется с задачами в своей нише (хотя Java в той же нише пожалуй ещё лучше, по сумме параметров).

VD>Собственно, одна из причин отсутствия масового причтия немерла среди шарп–программистов, то что шарп худо–бедно но развиваться. Линк — прекрасен. Лямбды тоже. Дженерики тоже не плохи, хотя и с проблемами.

Угу, по аналогичной причине D перестал быть так популярен (не в реальных проектах, где его и не было, а в мечтах о будущем) в последние годы.

Что касается LINQ, то он как раз не прекрасен, а ужасен, если вспомнить о быстродействие. Я это лично замерял несколько лет назад вместе с местными спецами по .net. Так вот там код с linq отставал от C++ аналогов не на традиционные для C# значения, а намного больше. Т.е. дело явно не в недостатках платформы .net, а в реализации самого linq. Ну или если не веришь мне, то вот тебе уже в этой темке коллеги подтвердили. )

Да, а насчёт лямбд... На C# уже можно написать код аналогичный такому http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc ?

VD>Если ты попытаешься разобраться, узнаешь, что IEnumerable не догма ни в линках, ни в foreach. И то и другое спроектированно на базе паттернов.
VD>Так что можно и производительность улучшить за счет перегрузок, и от использования интерфейсов избавиться.

Можно и сделано — это очень разные вещи. )

VD>Создание альтернативной экосистемы коллекций (например, в стиле stl) поломает совместимость, а большого толку не даст.

Ну если говорить о какой-то "нашлёпке" к C#, то безусловно смысла нет. Если же говорить об отдельном новом языке, то совсем другое дело.

VD>Все и так не плохо. Хотя идея не лишина смысла. Можешь заняться. Будет еще один плюс и ещё одна альтернатива. Лично меня более–менее устраивает дотнетный подход и есть куча других задач.

Не раньше чем Nemerle оторвётся от .net'a. )

VD>Все примерно как в плюсах. Все сделать нельзя. Сделано то что было востребованно теми кто использовал язык. Ну а частные проблемы можно решать создавая частные макро–либы. Если получится универсальное решение его можно предложить в стандартную макро–либу.

А есть какой-то общий известный каталог таких библиотек для Nemerle? ) Интересно посмотреть что там уже наделали... )

VD>Я вижу, что ты и шарпе то не глубоко копал, а уж фичи из F#–я ты наверняка не не знаешь. В прочем, буду рад ошибиться.
VD>Оператор структурного присвоения вообще штука еникальная. Делали аналог парповского инициализатора списков, а получилась вындервафля.

С F# не игрался, а с Haskell'ем игрался... )

_>>Я правильно понял, что C# код с await/async в Nemerle сейчас работать не будет?
VD>Да. Хотя можно на те же компютейшоны транслировать. Но это поддержку шарпа нужно расширять.

Т.е. получается, что Nemerle всё же не является надмножеством C# (как например у того же C->C++) и не может компилировать его код?

VD>Что имеется в виду под этим сокращением? Completion Port винды? Если — да, то в дотнетных либах никаких проблем с ассинхроннвюым IO нет. Везде есть соответствующие перегрузки. Ну, а компьютейшоны отлично подходят для их "ввпрямления".

Как раз главное преимущество реализации этого в C# в том, что позволяет пользоваться этим довольно не простым (внутри) инструментом даже не понимая, как оно в реальности работает.

VD>Скажем если по прочим критериям задаче можно решить на Питоне, плюсах или Немерле, то я выберу Немерле именно из–за того, что на нам получится реализовать проект проще и дешевле.

Для небольшого проекта при таких условиях я бы точно выбрал Питон. )

VD>Это и есть твое надменное отношение. Ты ставишь знак равенства между специализацией (знанием граблей и паттернов позволяющих на них не наступать) и проффесианолизмом.

Специализация тоже о многом говорит. ) К примеру если один дизайнер "специализируется" в Фотошопе, а другой в Paint'е, то... )))

VD>Если бы ты сказал "внимательности", "ответственности" и т.п. я бы не имел ничего против. Но делить людей на профессионалов и нет только на основании используемого языка — это просто глупость. Если я писал на плюсах (весьма успешно) и перешел на шара, я вдруг стал не профессиональным ламером? Гы–гы.

Ты не внимательно читаешь мои фразы. Там же чётко было указано — речь о пороге вхождение. Т.е. вопрос не в том, с чём ты сейчас работаешь (я вот может вообще bat файлик ваяю), а в том с чем ты способен работать.

VD>Макросы — это (грубо говоря) точка входа в программе. Она вызывает некий код который трансформирует код программы.
VD>У макр есть свой спец синтаксис.
VD>Но рассказывать об это долго. Особенно с телефона.
VD>Почему бы не прочесть вводную статейку да не попробывать самому?

Я не про это. Я про организацию кода. Вот на C++ мы можем смешать любые макросы, шаблоны, обычный код в одном файле. Можем конечно и раскидать по отдельным, но это как ты понимаешь будет исключительно наше разделение, а не формальное правило. С другой стороны, в том же упоминаемом выше T4 ситуация обратная и это как раз формальное требование. Так вот вопрос как у нас этим в Nemerle? )

Соответственно если в Nemerle ситуация с макросами как и в C++, то я не вижу особого смысла в каком-то выделение Nemerle библиотек, содержащих макросы. Ну разве что как раз в том смысле, что их нельзя использовать из других языков... )

_>>Насчёт костылей тут очень тонкий вопрос...
VD>Вопрос очень прост. В дотнете есть функциональный тип (делегаты) , а в прюсах нет. Буст лечил эту недоработку, пока фанаты С++ обясняют почему эта фича не нужна...

Не, речь о других вещах. Например различные техники работы с Tuple. В C++ то это всё во время компиляции отрабатывает. Так что тут именно тонкий вопрос. Я например могу сказать что ничего подобного в C# нет вообще и буду абсолютно прав. С другой стороны ты можешь сказать что tuple в C# имеется (только работает во время исполнения, что вообще скучно) и к нему даже не нужные какие-то специльные инструменты. И тоже будешь в какой-то степени прав. )))

_>>Ну а вообще для программирование на Nemerle я бы поискал образцы скорее в стандартной библиотеке D, а не в Boost'e. Всё же в C++ МП слабенькое...
VD>ОК. И что там?

А там всё тоже самое, но по другому. ) Я хочу сказать, что там реализована в общем то обычная функциональность стандартной библиотеки языка, но с изначальной заточкой на использование МП, вычисления во время компиляции и т.п. Итог получился очень приятный.

VD>Кстати, для ди инфраструктура всетаки есть или ее нет?

Дохленькая. Мы же это уже обсуждали когда-то. Даже библиотеку gui вменяемую не найти.

_>>Я правильно понял, что ты считаешь, что с помощью МП улучшать в контейнерах .net'a нечего? )
VD>В этом нет необходимости.

А вот в D вполне используют. ) Хотя от МП там всего лишь "static if" и нужен. )

VD>И что? Это спосает отзацикливаний, фрагментации памяти и необходимости тратить время на подсчет ссылок и очистку памяти при нулевом их числе?

А ты статью, на которую я кидал тебе ссылку, посмотрел? ) Ну там где про мобильную разработку и ужасы сборщика мусора в ней...

VD>Я всегда это осознаю. Покажите в чем я не прав и я изменю точку зрения.

Про разные мелкие косяки в дискуссии со мной (типа как с Sign# и т.п.) умолчим. Но тебе уже несколько человек в этой темке указывали на то, что ты абсолютно не верно проводишь сравнения с C++. Ты при этом всё время берёшь код, написанный в лучших традициях Java/C# (кстати, довольно странно для бывшего специалиста в C++

Здравствуйте, VladD2, Вы писали:

VD>Дело ж не в записи, а в том, что в одном случае я обязан заранее знать где и сколько будет жить обект, а во втором я не забиваю себе голову и получаю тот же оезутьтат, если время жизни соответствует размещению на стеке.

Во-первых не получаешь. Правильная формулировка такая: есть шанс, что получишь при определённых условиях работы на определённых java машинах.

А во-вторых в чём проблема знать где и сколько будет жить объект? ) Как бы это нормальная ситуация. ))) Раньше просто в C++ была проблема, что даже если ты знаешь, что объект живёт за пределами данной функции, то передать его выше удобным образом и одновременно с нулевым оверхедом было невозможно. Сейчас эта проблема решена.

Здравствуйте, VladD2, Вы писали:

VD>Я уже отвечал на этот вопрос. Аналогия не верна.
VD>Переписывать имеет смысл, только только то, что даст приемущество отгегерации кода во время компиляции и т.п.
VD>Но это, по факту, не такое частое явление.

Если это действительно так, то боюсь будет не так уж просто доказывать необходимость существования Nemerle вообще...

Здравствуйте, Sinclair, Вы писали:

S>Давайте чуть усложним пример:
S>

S>#include <string>
S>using namespace std;
S>string f(bool cond = false) {
S>  string first("first");
S>  string second("second");
S>  return cond ? first : second;
S>}
S>

S>Ваш компилятор всё ещё сумеет RVO? Поздравляю, вы получаете штраф O(N) за вызов конструктора копирования.

Ну вот как раз здесь компилятору и надо немного подсказать. Например так:

#include <string>
using namespace std;
string f(bool cond = false)
{
  string first("first");
  string second("second");
  return move(cond ? first : second);//а можно и так: return cond ? move(first):move(second);
}

опять же не будет никаких копирований.

Здравствуйте, AlexRK, Вы писали:

ARK>Я не мега-спец в C++, хочу узнать — что значит "не пойдут данные"? Если данные — это указатель, что туда "пойдет", NULL? А если int, то 0?

Туда пойдёт то, что определил автор перемещаемого класса в конструкторе перемещения. )

Кстати, если говорить о производительности и безопасности вместе и о .net в системном программирование... Есть вот такая http://habrahabr.ru/post/208608/ любопытная информация. Не знаю дадут ли этому когда-нибудь ход. Но если дадут, то я обязательно попробую. )

Но в любом случае там есть ряд довольно интересных фраз, особенно про переход на C++ в будущем. )))

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, Sinclair, Вы писали:
EP>Непонятно что именно даёт здесь EA для type safety, которая и так была

EA — это способ получить stack life cycle для объектов без потери type safety.
С++ гордится тем, что у него есть stack life cycle, но при этом в нём нет type safety.

EP>Не мёртв, а пуст

EP>Это считай своего рода swap с пустым объектом.
Что такое "пустой объект"?

EP>Что такое "программирование под Windows"

Это значит способ написания Windows-программ с GUI, удовлетворяющим стандартам платформы.
Я просто не в курсе, может быть после MFC, ATL, и WTL появилось что-то "более С++", чем эти пережитки C.

EP>Внутри реализации или интерфейса?
Внутри реализации, естественно. GC-то работает с реализацией, а не с интерфейсом.

EP>Повторяю в N'ый раз

— эта техника подходит для затейливых задач, типа сложных графов, в которых без GC ну ни как.
Эта техника подходит для дисциплинированных программистов. Затейливость задачи тут нерелевантна.
EP>Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть.
Да. Статический верификатор, способный проверить все постусловия, эквивалентен halting problem.
EP>В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях.
Поэтому давайте не будем сравнвать две бесконечности, а перейдём к инженерному подходу, в котором обсуждаются ровно способы облегчить последствия.
S>>В С++ же обращение к разрушенному объекту невозможно надёжно задетектировать. От слова вообще.
EP>Отчего же "от слова вообще"? Вот самый примитивный способ — клади каждый объект в отдельную виртуальную страницу.
Вы, фактически, предлагаете вообще отказаться от освобождения памяти — ведь если страница остаётся "занятой" навсегда, то в чём вообще смысл оператора delete()? Деструктор вызвали — и всё. Не, этот способ неприменим en masse: у 32х разрядного процесса в адресном пространстве нету столько страниц, чтобы хватило на всё время жизни приложения.
EP> Или, например, используй инструментацию кода

И что эта инструментация должна сделать?

Здравствуйте, DarkEld3r, Вы писали:

DE>Здравствуйте, Sinclair, Вы писали:

S>>А что такое "пустой объект"? Я не помню такого термина в спецификации С++, по которой работал я (в своей пред-предыдущей жизни).
DE>Если на пальцах, то как-то так:
DE>[ccode]
DE>string s("test"); // s = "test".
DE>foo(move(s)); // Тут у нас "пустой обьект".
По прежнему не вижу определения понятия "пустой объект".

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>RVO не было и в первом случае, был NRVO, или move

move, вообще-то, как раз O(N). Чудес-то не бывает.

EP>При таком коде — да, можно чуть изменить и не будет.
Попробуйте изменить.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Sinclair, Вы писали:

S>>Давайте чуть усложним пример:
S>>

S>>#include <string>
S>>using namespace std;
S>>string f(bool cond = false) {
S>>  string first("first");
S>>  string second("second");
S>>  return cond ? first : second;
S>>}
S>>

S>>Ваш компилятор всё ещё сумеет RVO? Поздравляю, вы получаете штраф O(N) за вызов конструктора копирования.

_>Ну вот как раз здесь компилятору и надо немного подсказать. Например так:
_>

_>#include <string>
_>using namespace std;
_>string f(bool cond = false)
_>{
_>  string first("first");
_>  string second("second");
_>  return move(cond ? first : second);//а можно и так: return cond ? move(first):move(second);
_>}

_>опять же не будет никаких копирований.
Сдаётся мне, что таки будут копирования. Можно посмотреть код move-конструктора для std::string?

Здравствуйте, Sinclair, Вы писали:

EP>>Непонятно что именно даёт здесь EA для type safety, которая и так была

S>EA — это способ получить stack life cycle для объектов без потери type safety.
S>С++ гордится тем, что у него есть stack life cycle, но при этом в нём нет type safety.

Вообще ортогональные вещи.
В C++ можно выделить подмножество (и даже сделать верификатор, для проверки соответствия), в котором будет и type safety, и "stack life cycle", и не будет EA

EP>>Не мёртв, а пуст

EP>>Это считай своего рода swap с пустым объектом.
S>Что такое "пустой объект"?

Для простоты считай default constructed. Грубо говоря:

{
    T x(something);
    T y;
    swap(x, y);
}
// approximatly equal to:
{
    T x(something);
    T y(std::move(x));
}

Здесь x остаётся живым — его можно использовать далее по коду.
Чуть более точные формулировки, были выше по топику.

EP>>Что такое "программирование под Windows"

S>Это значит способ написания Windows-программ с GUI, удовлетворяющим стандартам платформы.

С чего это вдруг "программирование под Windows" это обязательно GUI?
Тем не менее, std::thread в данном контексте ничем не отличается от GUI — он также внизу вызывает низкоуровневые функции OS.

S>Я просто не в курсе, может быть после MFC, ATL, и WTL появилось что-то "более С++", чем эти пережитки C.

Да взять хоть тот же QT.

EP>>Внутри реализации или интерфейса?
S>Внутри реализации, естественно. GC-то работает с реализацией, а не с интерфейсом.

Не пойму что ты пытаешься сказать — внутри реализаций .NET библиотек, использующих те или иные функции OS — будут те же самые lParam

EP>>Повторяю в N'ый раз

— эта техника подходит для затейливых задач, типа сложных графов, в которых без GC ну ни как.
S>Эта техника подходит для дисциплинированных программистов. Затейливость задачи тут нерелевантна.

Речь шла про задачи, в которых в силу их структуры возникают жёсткие циклы, с которыми ref_counting/weak_ptr не справится.
Даже если такие редкие и затейливые задачи возникнут при использовании C++ — всегда можно использовать под неё кучу с точным GC.
Разговора о том, чтобы использовать GC для всего приложения — не было.

EP>>Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть.
S>Да. Статический верификатор, способный проверить все постусловия, эквивалентен halting problem.

Да, об этом и речь.

EP>>В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях.
S>Поэтому давайте не будем сравнвать две бесконечности, а перейдём к инженерному подходу, в котором обсуждаются ровно способы облегчить последствия.

По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.
В целом же, я предпочитаю акцент на минимизации багов, чем на defensive programming. В общем случае, defensive programming применим только к некоторым классам проблем, и уж тем более никак не сможет заставить программу с багом выполнить свою задачу. От создания корректного кода никуда не деться.

S>>>В С++ же обращение к разрушенному объекту невозможно надёжно задетектировать. От слова вообще.
EP>>Отчего же "от слова вообще"? Вот самый примитивный способ — клади каждый объект в отдельную виртуальную страницу.
S>Вы, фактически, предлагаете вообще отказаться от освобождения памяти — ведь если страница остаётся "занятой" навсегда, то в чём вообще смысл оператора delete()? Деструктор вызвали — и всё.

Это всего лишь синтетический пример, показывающий что твоя оценка "от слова вообще" слишком категоричная.

S>Не, этот способ неприменим en masse: у 32х разрядного процесса в адресном пространстве нету столько страниц, чтобы хватило на всё время жизни приложения.

Естественно речь была про x64.

EP>> Или, например, используй инструментацию кода

S>И что эта инструментация должна сделать?

Например: у объекта, и всех указателей на него, сделать shared state в виде флага is_alive.

Здравствуйте, Sinclair, Вы писали:

EP>>RVO не было и в первом случае, был NRVO, или move

S>move, вообще-то, как раз O(N). Чудес-то не бывает.

С чего это вдруг O(N)?
Вот например swap двух строк, это какая сложность по-твоему?

EP>>При таком коде — да, можно чуть изменить и не будет.
S>Попробуйте изменить.

Проще всего вот так:

string f(bool cond = false)
{
    string first("first");
    string second("second");
    if(cond)
        return first;
    else
        return second;
}

Здравствуйте, Sinclair, Вы писали:

_>>Ну вот как раз здесь компилятору и надо немного подсказать. Например так:
_>>

_>>#include <string>
_>>using namespace std;
_>>string f(bool cond = false)
_>>{
_>>  string first("first");
_>>  string second("second");
_>>  return move(cond ? first : second);//а можно и так: return cond ? move(first):move(second);
_>>}

_>>опять же не будет никаких копирований.
S>Сдаётся мне, что таки будут копирования.

Не будет. Если немного упростить — допустим string это всего лишь обвёртка вокруг null terminated:

class string
{
    char *data;
public:
    string() : data (nullptr) {} // default
    //....
    ~string()
    {
        delete[] data; // if nullptr - does nothing
    }
};

тогда move конструктор выглядит следующим образом:

string(string &&donor)
{
    data = donor.data;
    donor.data = nullptr
}

То есть мы копируем все необходимые внутренности(в данном случае это один указатель), и "зануляем" внутренности донора таким образом, что бы для него смог корректно отработать его деструктор.

S>Можно посмотреть код move-конструктора для std::string?

https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00998_source.html#l00512

Здравствуйте, Sinclair, Вы писали:

S>Сдаётся мне, что таки будут копирования. Можно посмотреть код move-конструктора для std::string?

      /**
       *  @brief  Move construct string.
       *  @param  __str  Source string.
       *
       *  The newly-created string contains the exact contents of @a __str.
       *  @a __str is a valid, but unspecified string.
       **/
      basic_string(basic_string&& __str)
      : _M_dataplus(__str._M_dataplus)
      {
        __str._M_data(_S_construct(size_type(), _CharT(), get_allocator()));
      }

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В C++ можно выделить подмножество (и даже сделать верификатор, для проверки соответствия), в котором будет и type safety, и "stack life cycle", и не будет EA

Да. Для этого придётся всего лишь отказаться от указателей.

EP>Для простоты считай default constructed.
А если дефолтного конструктора нету?

EP>С чего это вдруг "программирование под Windows" это обязательно GUI?
Это я вам объяснил моё определение задачи, библиотеку для которой я ищу.
Но если вы так хотите выкрутиться, отказавшись от GUI, то я вам и в невизуальной части найду волшебные структуры данных, в которых невозможно статически определить наличие либо отсутствие указателей.
EP>Да взять хоть тот же QT.

EP>Не пойму что ты пытаешься сказать — внутри реализаций .NET библиотек, использующих те или иные функции OS — будут те же самые lParam

это будут не те же самые lParam. Внутри реализаций .Net библиотек данные живут в управляемом виде, а перевод в/из lParam происходит только в момент маршалинга. Благодаря этому мы уверены, что в момент сборки мусора у нас не может быть неизвестного нам указателя на managed объект.
В С++ это теоретически возможно, но на практике бы означало отказ от тех самых преимуществ "тонкой прослойки", т.е. С++-ные библиотеки стараются использовать raw data напрямую, без постоянной конвертации туда-сюда.

Это и есть основной show stopper для внедрения точного GC в C++ — это возможно, пока вы работаете в рамках hello world. Как только мы пытаемся задействовать стандартные библиотеки — сразу начинается упс, связанный с реинтерпретацией данных, и точный GC становится невозможен.

EP>Речь шла про задачи, в которых в силу их структуры возникают жёсткие циклы, с которыми ref_counting/weak_ptr не справится.
Речь также шла про задачи, в которых стоимость ref_counting слишком велика. По сравнению с GC и immutable objects.

EP>Разговора о том, чтобы использовать GC для всего приложения — не было.
Разговор о том, что у вас нет никакой гарантии, что "GC использован только для части приложения", из-за потенциальной возможности прикопать указатель где угодно.

EP>По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.
Совершенно верно. Юмор в том, что С++ не позволяет ни того, ни другого.

EP>В целом же, я предпочитаю акцент на минимизации багов, чем на defensive programming. В общем случае, defensive programming применим только к некоторым классам проблем, и уж тем более никак не сможет заставить программу с багом выполнить свою задачу. От создания корректного кода никуда не деться.
Речь не о defensive programming, а об UB vs FailFast. Ещё раз подчеркну: в нормальной среде о том, что произошла ошибка доступа к разрушенному объекту
1. вы узнаете (а не получите случайную наведённую ошибку где-то в совершенно постороннем коде)
2. узнаете не из рукопашных проверок постусловий в стиле defensive programming, а из вылета соответствующего исключения.

В С++, по факту, вы вообще не узнаете о подобной ошибке. У вас с вероятностью 99% стрельнет какой-то совершенно другой код — типа окажется, что в поле m_length записано -42. Потому, что поле читается из мусора, а не из реального объекта.

EP>Это всего лишь синтетический пример, показывающий что твоя оценка "от слова вообще" слишком категоричная.
Этот синтетический пример означает выход за пределы стандарта С++. Я не спорю — можно разработать другой язык, с другими правилами, и с другими стандартными библиотеками.
Но по факту мы работаем с реальным C++, а не с его воображаемым аналогом, только без шлюх и блэкджека.
EP>Естественно речь была про x64.
И даже на x64 вряд ли можно себе позволить неконтролируемый рост адресного пространства процесса.

EP>Например: у объекта, и всех указателей на него, сделать shared state в виде флага is_alive.
И как мы это сделаем для указателей, которые вычисляются при помощи арифметики?
И как мы обновим флаг во всех указателях в момент выполнения delete? Предполагается, что в объекте будет сидеть список backreferences на все указатели на него?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>С чего это вдруг O(N)?
EP>Вот например swap двух строк, это какая сложность по-твоему?
В зависимости от того, попали ли мы в SSO — либо о(N), либо o(1) + затраты на перещёлкивание ref_count.
Или у нас есть какая-то магия компилятора, которая отличает swap от s3=s1; s1=s2; s2=s3 для произвольных типов?

EP>Проще всего вот так:
EP>

EP>string f(bool cond = false)
EP>{
EP>    string first("first");
EP>    string second("second");
EP>    if(cond)
EP>        return first;
EP>    else
EP>        return second;
EP>}
EP>

И благодаря чему здесь компилятор ухитрится соптимизировать move? Вот у меня банальный код вызова:

void test()
{
  string s("test"); // байты для 't','e','s','t','\0' хранятся в stack frame этой функции благодаря SSO
  s = f(true);
  cout << s; // здесь в SSO-области s уже лежат байты 'f','i','r','s','t','\0'. Каким образом они тут оказались?
}

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>То есть мы копируем все необходимые внутренности(в данном случае это один указатель), и "зануляем" внутренности донора таким образом, что бы для него смог корректно отработать его деструктор.
Это всё здорово, но вы не привели copy-constructor.
При такой реализации в нём вам придётся делать std::memmove() на полные данные, т.к. скопировать указатель уже нельзя — деструктор одного из клонов вернёт буфер в хип, и первое же обращение ко второму клону получит UB.
Чтобы оптимизировать копирования, вам придётся перейти на COW-оптимизацию, а в ней уже нарваться на штраф за interlocked_increment рефкаунтера.

S>>Можно посмотреть код move-конструктора для std::string?

EP>https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00998_source.html#l00512

Отлично.
Можете сразу сделать Ctrl-F по "_M_refcount" чтобы найти места, где вас ждёт обещанный мной штраф за refcount.

Здравствуйте, Sinclair, Вы писали:

S>В зависимости от того, попали ли мы в SSO — либо о(N), либо o(1) + затраты на перещёлкивание ref_count.
S>Или у нас есть какая-то магия компилятора, которая отличает swap от s3=s1; s1=s2; s2=s3 для произвольных типов?

В текущей версии string нет SSO, но есть подсчёт ссылок. )

В будущей версии string (можно пользоваться уже сейчас под таким именем https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01594_source.html) есть SSO, но нет подсчёта ссылок. )

Здравствуйте, Sinclair, Вы писали:

S>При такой реализации в нём вам придётся делать std::memmove() на полные данные, т.к. скопировать указатель уже нельзя — деструктор одного из клонов вернёт буфер в хип, и первое же обращение ко второму клону получит UB.
Ну да, копирование — дорогая операция. И что?

S>Чтобы оптимизировать копирования, вам придётся перейти на COW-оптимизацию, а в ней уже нарваться на штраф за interlocked_increment рефкаунтера.
А зачем нам так оптимизировать копирование? Во первых, это не такая и однозначная оптимизация. Во вторых, это (уже) запрещено стандартом. Да, GCC в этом нюансе стандарт (пока?) нарушает. Вроде, есть отдельный "правильный" тип строк.

S>Можете сразу сделать Ctrl-F по "_M_refcount" чтобы найти места, где вас ждёт обещанный мной штраф за refcount.
Особенность реализации. Который может (и не должно) и не быть.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Sinclair, Вы писали:

S>>Сдаётся мне, что таки будут копирования. Можно посмотреть код move-конструктора для std::string?
_>

_>      /**
_>       *  @brief  Move construct string.
_>       *  @param  __str  Source string.
_>       *
_>       *  The newly-created string contains the exact contents of @a __str.
_>       *  @a __str is a valid, but unspecified string.
_>       **/
_>      basic_string(basic_string&& __str)
_>      : _M_dataplus(__str._M_dataplus)
_>      {
_>        __str._M_data(_S_construct(size_type(), _CharT(), get_allocator()));
_>      }
_>

Отлично. То есть вы ссылаетесь на реализацию GCC, в которой нет SSO. зато есть refcount.
Понятно, что в вырожденных сценариях типа "передачи владения" есть шанс обойтись без копирований и рефкаунтов.
Речь о том, что в классическом, банальном

string s("hello");
f1(s); // мы получаем copy constructor со штрафом за рефкаунт
f2(s);

Здравствуйте, alex_public, Вы писали:

_>А во-вторых в чём проблема знать где и сколько будет жить объект? )

Большинство современного GUI софта написано в асинхронном стиле. Объекты там создаются, скачут между контекстами, а потом, когда все подписчики отработают, подлежат уничтожению. Вручную искать момент завершения работы с объектом значит очень сильно переусложнить код. Никакого скоупа там нет.

Здравствуйте, alex_public, Вы писали:

_>Кстати, если говорить о производительности и безопасности вместе и о .net в системном программирование... Есть вот такая http://habrahabr.ru/post/208608/ любопытная информация. Не знаю дадут ли этому когда-нибудь ход. Но если дадут, то я обязательно попробую. )

_>Но в любом случае там есть ряд довольно интересных фраз, особенно про переход на C++ в будущем. )))

Как можно всеръёз воспринимать статью, которая в первых строчках показывает javascript как образец safety and productivity?

Не, я понимаю, яваскрипт реально удобная штука. Мне вот пару дней назад надо было из массива точек отобразить рисунок. На всё про всё ушло минуты, наверное две. В текстовом редакторе подставил перед каждой точкой lineTo, потом это дело скопировал в jsfiddle и отобразил на canvas. Удобно? Очень.

Но как только от маленькой задачи мы начинаем двигаться к большой, так сразу начинаются проблемы с поддержкой, скоростью разработки, качеством IDE и тд. В крупных проектах javascript и небезопасен, и непродуктивен. Большинство современных языков справляются с его задачами значительно лучше. Его преимущество только в абсолютной распространённости и кроссплатформенности благодаря браузерам.

Здравствуйте, Sinclair, Вы писали:

EP>>>>Непонятно что именно даёт здесь EA для type safety, которая и так была

S>>>EA — это способ получить stack life cycle для объектов без потери type safety.
S>>>С++ гордится тем, что у него есть stack life cycle, но при этом в нём нет type safety.
EP>>В C++ можно выделить подмножество (и даже сделать верификатор, для проверки соответствия), в котором будет и type safety, и "stack life cycle", и не будет EA

S>Да. Для этого придётся всего лишь отказаться от указателей.

Во-первых, только в пользовательских типах (std::vector можно считать частью платформы, также как и в .NET есть unsafe код).
Во-вторых, совершенно без разницы. Я показываю, что EA тут не даёт никакой type safety. Эта type safety в управляемых языках есть и без EA, а в C++ возможна без EA.

EP>>Для простоты считай default constructed.
S>А если дефолтного конструктора нету?

Я же сказал, для простоты. А в общем случае достаточно перевести в destructable состояние (то есть такое, для которого может корректно отработать деструктор).

S>Но если вы так хотите выкрутиться, отказавшись от GUI, то я вам и в невизуальной части найду волшебные структуры данных, в которых невозможно статически определить наличие либо отсутствие указателей.

Ты говоришь про общий случай. Для общего случая в C++ возможен только conservative GC, что уже обсуждалось выше по топику.
Для консервативного GC в C++ есть интерфейс (например позволяющий сказать, что в этом куске памяти указателей нет).

EP>>Не пойму что ты пытаешься сказать — внутри реализаций .NET библиотек, использующих те или иные функции OS — будут те же самые lParam

S>это будут не те же самые lParam. Внутри реализаций .Net библиотек данные живут в управляемом виде, а перевод в/из lParam происходит только в момент маршалинга. Благодаря этому мы уверены, что в момент сборки мусора у нас не может быть неизвестного нам указателя на managed объект.

И, конечно же, никаких fixed и unsafe там быть не может, да?

S>В С++ это теоретически возможно, но на практике бы означало отказ от тех самых преимуществ "тонкой прослойки", т.е. С++-ные библиотеки стараются использовать raw data напрямую, без постоянной конвертации туда-сюда.
S>Это и есть основной show stopper для внедрения точного GC в C++ — это возможно, пока вы работаете в рамках hello world. Как только мы пытаемся задействовать стандартные библиотеки — сразу начинается упс, связанный с реинтерпретацией данных, и точный GC становится невозможен.

Очевидные вещи говоришь, которые к тому же уже обсуждались выше. Зачем?

EP>>Разговора о том, чтобы использовать GC для всего приложения — не было.
S>Разговор о том, что у вас нет никакой гарантии, что "GC использован только для части приложения", из-за потенциальной возможности прикопать указатель где угодно.

Теоретически.
А практически, для таких сценариев и при необходимости гарантий (например при невозможности достижения их одними guidelines) — можно запретить брать raw указатели на такие GC объекты — частично языком + простейшим внешним верификатором.

EP>>По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.
S>Совершенно верно. Юмор в том, что С++ не позволяет ни того, ни другого.

А кто тогда позволяет? ObjectDisposed и OutOfBounds?

EP>>В целом же, я предпочитаю акцент на минимизации багов, чем на defensive programming. В общем случае, defensive programming применим только к некоторым классам проблем, и уж тем более никак не сможет заставить программу с багом выполнить свою задачу. От создания корректного кода никуда не деться.
S>Речь не о defensive programming, а об UB vs FailFast. Ещё раз подчеркну: в нормальной среде о том, что произошла ошибка доступа к разрушенному объекту
S>1. вы узнаете (а не получите случайную наведённую ошибку где-то в совершенно постороннем коде)
S>2. узнаете не из рукопашных проверок постусловий в стиле defensive programming, а из вылета соответствующего исключения.

Необязательно рукопашных, для памяти есть автоматизированные sanitizer'ы, valgrind'ы и т.п., которые легко включать при тестировании.
Если же тестирование слабое, или вообще отсутствует, то корректную программу среднего размера ты ни на одном языке не напишешь

EP>>Это всего лишь синтетический пример, показывающий что твоя оценка "от слова вообще" слишком категоричная.
S>Этот синтетический пример означает выход за пределы стандарта С++. Я не спорю — можно разработать другой язык, с другими правилами, и с другими стандартными библиотеками.
S>Но по факту мы работаем с реальным C++, а не с его воображаемым аналогом, только без шлюх и блэкджека.

Так это реальный C++, удовлетворяющий стандарту, а не аналог

Реализации никто не запрещает детектировать dangling pointer и т.п. Наоборот, UB в стандарте как раз позволяет это делать.

EP>>Например: у объекта, и всех указателей на него, сделать shared state в виде флага is_alive.
S>И как мы это сделаем для указателей, которые вычисляются при помощи арифметики?

Смотря о чём речь.
Если об арифметике внутри массива — то тут всё просто, указатель на элемент массива, держит весь массив. Если же произошёл выход за пределы — делаем terminate/exception или что там потребуется.
Если же, например, о сохранении указателя на диск, а потом повторном считывании — то в таких редких предельных случаях можно сделать утечку shared state — who cares.

S>И как мы обновим флаг во всех указателях в момент выполнения delete? Предполагается, что в объекте будет сидеть список backreferences на все указатели на него?

shared state — это ref counted объект, грубо говоря std::shared_ptr<bool>. На него ссылаются и сам объект и все указатели.
При разрушения объекта, он всего лишь записывает в этот флаг false.

Здравствуйте, DarkEld3r, Вы писали:
DE>Ну да, копирование — дорогая операция. И что?
То, что его нужно избегать.
Например, java и C# не копируют строки.

DE>А зачем нам так оптимизировать копирование?
Затем, что у нас очень много передач строк друг другу.
DE>Во первых, это не такая и однозначная оптимизация.
Однозначнее некуда. То, что в С++ она приводит к плохим последствиям — проблема С++.

DE>Во вторых, это (уже) запрещено стандартом. Да, GCC в этом нюансе стандарт (пока?) нарушает. Вроде, есть отдельный "правильный" тип строк.
DE>Особенность реализации. Который может (и не должно) и не быть.
Тогда будут О(N) копирования.

Здравствуйте, Sinclair, Вы писали:

S>Отлично. То есть вы ссылаетесь на реализацию GCC, в которой нет SSO. зато есть refcount.

Это старая реализация, не особо совместимая с новым стандартом. Но её пока оставили вроде как потому, что ломающие ABI изменения они делают только какими-то там этапами. Кстати, кажется следующий как раз в ближайшее время будет (4.10 версия). Нормальная версия давным давно добавлена, но под другим именем пока что. Ну это то, что мельком слышал. Специально не разбирался в "политических" деталях. )))

S>Понятно, что в вырожденных сценариях типа "передачи владения" есть шанс обойтись без копирований и рефкаунтов.

Это как раз не вырожденный, а самый основной случай. ) Причём сейчас некоторые пользователи стандартной библиотеки, даже не зная об этой технике, будут постоянно только её и использовать (если конечно стоит опция использования нового стандарта).

S>Речь о том, что в классическом, банальном
S>

S>string s("hello");
S>f1(s); // мы получаем copy constructor со штрафом за рефкаунт
S>f2(s);
S>

Этот код может приводить к абсолютно разным последствиям, в зависимости от прототипа функций f. Варианты с ходу:

f(string s);
f(string& s);
f(string&& s);
f(const string& s);

Здравствуйте, ionoy, Вы писали:

I>Большинство современного GUI софта написано в асинхронном стиле. Объекты там создаются, скачут между контекстами, а потом, когда все подписчики отработают, подлежат уничтожению. Вручную искать момент завершения работы с объектом значит очень сильно переусложнить код. Никакого скоупа там нет.

Вот только не надо опять же навязывать свою Java-подобную архитектуру с кучей лишнего прокладочного кода. У меня написание GUI перед глазами и я не вижу там ничего скачущего.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, ionoy, Вы писали:

I>>Большинство современного GUI софта написано в асинхронном стиле. Объекты там создаются, скачут между контекстами, а потом, когда все подписчики отработают, подлежат уничтожению. Вручную искать момент завершения работы с объектом значит очень сильно переусложнить код. Никакого скоупа там нет.

_>Вот только не надо опять же навязывать свою Java-подобную архитектуру с кучей лишнего прокладочного кода. У меня написание GUI перед глазами и я не вижу там ничего скачущего.

Поговорим об этом через лет пять

Здравствуйте, ionoy, Вы писали:

I>Как можно всеръёз воспринимать статью, которая в первых строчках показывает javascript как образец safety and productivity?

Ну я всё же прочитал до конца и мне понравилось. А MSфилам могу посоветовать также посмотреть на личность автора — может это поспособствует прочтению статьи. )))

I>Не, я понимаю, яваскрипт реально удобная штука. Мне вот пару дней назад надо было из массива точек отобразить рисунок. На всё про всё ушло минуты, наверное две. В текстовом редакторе подставил перед каждой точкой lineTo, потом это дело скопировал в jsfiddle и отобразил на canvas. Удобно? Очень.

Думаю автор именно это и имел в виду. А под безопасностью он наверное подразумевал (судя по картинке) отсутствие вылетов в случае любых ошибок, а не типобезопасность (которая у JS похуже всех на той картинке). В любом случае эта картинка явно не главное место в статье. )))

Кстати, а я бы для подобных задач использовал Питон. )

I>Но как только от маленькой задачи мы начинаем двигаться к большой, так сразу начинаются проблемы с поддержкой, скоростью разработки, качеством IDE и тд. В крупных проектах javascript и небезопасен, и непродуктивен. Большинство современных языков справляются с его задачами значительно лучше. Его преимущество только в абсолютной распространённости и кроссплатформенности благодаря браузерам.

Да, согласен, на крупных проектах скриптовые языки не удобны. Это и моё мнение. Но насколько я знаю, его разделяют далеко не все. )

Здравствуйте, Sinclair, Вы писали:

S>То, что его нужно избегать.
S>Например, java и C# не копируют строки.
В С++, как ни странно, копирования тоже избегают. В том числе, дешевым перемещением.

S>Однозначнее некуда. То, что в С++ она приводит к плохим последствиям — проблема С++.
Нет никаких проблем.

S>Тогда будут О(N) копирования.
И что? Пусть себе будут. Но мы будем или передавать по ссылке или перемещать, а копировать только тогда, когда без этого никак.

Здравствуйте, Sinclair, Вы писали:

DE>>А зачем нам так оптимизировать копирование?
S>Затем, что у нас очень много передач строк друг другу.
"передач" — это move, а не копирование. Само слово подсказывает даже

Здравствуйте, Sinclair, Вы писали:

S>Тогда будут О(N) копирования.

Я правильно понимаю, что это так страшно закодировано банальное char_traits::copy(stack1, stack2, 16);?)

Здравствуйте, alex_public, Вы писали:

_>Во-первых не получаешь. Правильная формулировка такая: есть шанс, что получишь при определённых условиях работы на определённых java машинах.

На счет условий согласен. Это основная проблема. В Яве есть ряд вещей препятствующих эскейп-анализу.
На счет "на определённых java машинах" — не согласен. Все что ты тут про С++ говоришь тоже только для GCC применимо. Орокловая ява-машина — это стандарт дефакто. Так что это не проблема особо.

_>А во-вторых в чём проблема знать где и сколько будет жить объект? )

Проблемы сразу две.
1. Мозг лучше загружать деталями алгоритма, а не деталями управления памятью.
2. В С++ ошибки в этой области приводят к очень не простой отладке, а зачастую такие баги живут в продуктах по много лет.

Все это снижает скорость разработки.

_>Как бы это нормальная ситуация. ))) Раньше просто в C++ была проблема, что даже если ты знаешь, что объект живёт за пределами данной функции, то передать его выше удобным образом и одновременно с нулевым оверхедом было невозможно. Сейчас эта проблема решена.

Решена одна мелкая частная проблема. Проблема же управления памятью по прежнему лежит на программисте. В купе с другими небезопасными решениями (вроде отсутствия инициализации памяти отводимой под переменные) это усложняет заработку и сопровождение. Баги с памятью часто вылезают при рефакторинге. Когда пишешь ты еще помнишь про время жизни, стратегию и т.п., а при изменении (особенно при массовом) можно спокойно пропустить нюансик. Тем более, что на сях мало кто пишет обходясь только одними типобезопасными методами. Легкодоступность опасных конструкций делает картину совсем печальной. В итоге время разработки сравнимого кона да Шарпе и плюсах сильно отличается и не в пользу С++.

Здравствуйте, VladD2, Вы писали:

VD>На счет условий согласен. Это основная проблема. В Яве есть ряд вещей препятствующих эскейп-анализу.
VD>На счет "на определённых java машинах" — не согласен. Все что ты тут про С++ говоришь тоже только для GCC применимо. Орокловая ява-машина — это стандарт дефакто. Так что это не проблема особо.

Тут поинт был не на "определённых", а на "java машинах". ) Намекая на .net и другие платформы со сборщиком мусора. )

VD>Проблемы сразу две.
VD>1. Мозг лучше загружать деталями алгоритма, а не деталями управления памятью.
VD>2. В С++ ошибки в этой области приводят к очень не простой отладке, а зачастую такие баги живут в продуктах по много лет.

VD>Все это снижает скорость разработки.

Да, есть такое. Но я опять же сказал бы что это скорее вопрос порога вхождения. Т.е. грубо говоря можно научиться (для этого надо соблюдать определённые правила) работать не менее эффективно и тут.

VD>Решена одна мелкая частная проблема. Проблема же управления памятью по прежнему лежит на программисте. В купе с другими небезопасными решениями (вроде отсутствия инициализации памяти отводимой под переменные) это усложняет заработку и сопровождение. Баги с памятью часто вылезают при рефакторинге. Когда пишешь ты еще помнишь про время жизни, стратегию и т.п., а при изменении (особенно при массовом) можно спокойно пропустить нюансик. Тем более, что на сях мало кто пишет обходясь только одними типобезопасными методами. Легкодоступность опасных конструкций делает картину совсем печальной. В итоге время разработки сравнимого кона да Шарпе и плюсах сильно отличается и не в пользу С++.

Ну проблемка то хотя мелкая и частная, но её решение очень существенно меняет весь язык и существенно увеличивает производительность (это при том, что и при старом стандарте никто особо не мог конкурировать по этому параметру). Причём увеличивается производительность даже совсем старого кода, достаточно его просто перекомпилировать по новому (правда при этом скорее всего всплывут разные другие несовместимости (типа nullptr), но это даже полезно).

Ну а в остальном я в общем то согласен. Только вывод бы немного переделал: для достижения одинаковой скорости разработки на C# и C++, требуется чтобы программист C++ был заметно более высокого уровня. И этот вывод конечно же не в пользу C++.

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Во-вторых, совершенно без разницы. Я показываю, что EA тут не даёт никакой type safety. Эта type safety в управляемых языках есть и без EA, а в C++ возможна без EA.
Я понимаю, что вы показываете. Я вам пытаюсь объяснить, что подход управляемых языков — "давайте начнём с корректной программы (т.е. с type safety), а затем сделаем её быстрой (например, снизим нагрузку на GC путём EA)". А в С++ подход "давайте начнём с быстрой программы (т.е. дадим пользователю самому управлять временем жизни объектов), а потом безуспешно будем пытаться сделать её корректной".

EP>Ты говоришь про общий случай. Для общего случая в C++ возможен только conservative GC, что уже обсуждалось выше по топику.
Ну, вот и договорились.

EP>И, конечно же, никаких fixed и unsafe там быть не может, да?
Может, но это не влияет на моё утверждение.

EP>Теоретически.
EP>А практически, для таких сценариев и при необходимости гарантий (например при невозможности достижения их одними guidelines) — можно запретить брать raw указатели на такие GC объекты — частично языком + простейшим внешним верификатором.
У нас с вами противоположные понятия о "теоретически vs практически". Я считаю, что ваша идея про необходимость гарантий — это чистая теория, не подтверждённая на практике. А практика — это наличие а) компиляторов, которые неспособны запрещать брать указатели на особые объекты, в том числе и непреднамеренно, б) библиотек, которые несовместимы с такими ограниченными объектами, и с) наработанной прикладной кодовой базы на основе компиляторов и библиотек, которую никто не возьмётся переписывать в светлое будущее ради того, чтобы получить хоть какие-то гарантии в одном крошечном кусочке нашего проекта с 15-летней историей.
EP>А кто тогда позволяет? ObjectDisposed и OutOfBounds?

Конечно.
EP>Так это реальный C++, удовлетворяющий стандарту, а не аналог

Покажите мне этот "реальный C++". Увы — он существует только в вашем воображении.
EP>Реализации никто не запрещает детектировать dangling pointer и т.п. Наоборот, UB в стандарте как раз позволяет это делать.

EP>shared state — это ref counted объект, грубо говоря std::shared_ptr<bool>. На него ссылаются и сам объект и все указатели.
EP>При разрушения объекта, он всего лишь записывает в этот флаг false.
Да, так будет работать. Интересно, отчего эта техника не применяется в управляемых средах? Двойная ссылка считается слишком медленной?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Ты так говоришь, как-будто проблемы утечек не существует для языков с GC.
EP>Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны

Fault tolerance начинается с fault detection. И управляемые среды в этом смысле дают хорошие гарантии. А С++ — это лотерея.
Ещё раз подчеркну: проблема не в том, что можно написать программу с ошибкой. Проблема — в том, что эта ошибка останется незамеченной, а к моменту, когда она будет обнаружена, у неё будут последствия неизвестной разрушительности.

Здравствуйте, Sinclair, Вы писали:

S>По прежнему не вижу определения понятия "пустой объект".

он имеет в виду объект, *из* которого мувнули.

Здравствуйте, VladD2, Вы писали:

VD>Вообще, если бы без МП нель было бы жить, то дотнет и ява просто бы не взлетели. Сильный программист может повысить свою эффективность применяч МП в некоторых случаях,

но тема кода пишется ручками и МП при этом не сильно помогает.

VD>Более того. Любой код можно написать без МП. Вопрос лишь в трудозатратах. Корпорации типа МС могут выбрасывать мегобаксы на ветер. Низкое КПД компенсируется высоким качеством результата и пиаром (брендом).

_>>А вот на Nemerle уже вполне можно. Только вот где оно готовое?

VD>Свифт — это немерл без макросов, перегрузки методов и с подсчетом ссылок вместо полноценного ЖЦ.

Эдак любой язык с фигурными скобками будет "немерл без ххх"

Здравствуйте, VladD2, Вы писали:

_>>Это не разговор. Нужна целевая ниша.

VD>Не нужна. Достаточно знать ограничения платформы.

Что бы достичь цель, скажем, N процентов от целевой аудитории нужно учитывать особенности эти ниши и аудитории.

Вот тот же JS — язык распространился даже вопреки Микрософту, который боролся с ним в то самое время, когда у IE было 90% аудитории.
Фич около нуля, циклы и те не смогли внятно сделать. Дыр столько, что десяток сайтов навроде wtf.js не могут все это описать. Любые приседания требуют нативных решений.
Однако все сложилось очень даже хорошо — JS распространился и под него запилили столько всяких разных API, что сейчас он практически эталон продуктивности.

Здравствуйте, jazzer, Вы писали:
J>он имеет в виду объект, *из* которого мувнули.
Прекрасно. Что происходит с объектом, из которого мувнули? Он становится пустым. А что такое "пустой объект"? Это объект, из которого мувнули.
Вы Лема недавно перечитывали, да?
Вот, например, в дотнете есть понятие "дефолтной инициализации" — это когда все поля объекта заполняются нулями.
Т.е. все ссылки показывают в null, все целочисленные поля и перечисления содержат 0, вся плавающая запятая — 0.0.
Составные типы — рекурсивно. Именно так гарантированно инициализируется объект в начале жизенного цикла — хоть на стеке, хоть в куче.
Несмотря на это, кстати, сишарп всё ещё требует указывать инициализацию руками — см. тж. definite assignment.
В сишарпе есть даже специальное ключевое слово default, чтобы подчеркнуть, что дополнительной инициализации объекту не требуется.

В С++ я сходу не нашёл понятия "пустой объект".

В справочнике, что характерно, про "пустой объект" ничего нету.
Зато есть сносящая мне крышу штука про то, что аргументом мув-конструктора является rvalue.
Как же так? То есть, если я сделаю так: auto a = std::move(1); то единица превратится в "пустой объект типа int", что бы это ни значило?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, jazzer, Вы писали:
J>>он имеет в виду объект, *из* которого мувнули.
S>Прекрасно. Что происходит с объектом, из которого мувнули? Он становится пустым. А что такое "пустой объект"? Это объект, из которого мувнули.
S>Вы Лема недавно перечитывали, да?
Да нет никакого "пустого объекта", он просто некорректно выразился, а ты докопался. Есть понятие "moved-from state".
Так что объект, из которого мувнули, переходит в состояние moved-from. Каким оно будет? Таким, как ты напишешь перемещающее присваивание/конструирование.

S>Вот, например, в дотнете есть понятие "дефолтной инициализации" — это когда все поля объекта заполняются нулями.
S>Т.е. все ссылки показывают в null, все целочисленные поля и перечисления содержат 0, вся плавающая запятая — 0.0.
S>Составные типы — рекурсивно. Именно так гарантированно инициализируется объект в начале жизенного цикла — хоть на стеке, хоть в куче.
S>Несмотря на это, кстати, сишарп всё ещё требует указывать инициализацию руками — см. тж. definite assignment.
S>В сишарпе есть даже специальное ключевое слово default, чтобы подчеркнуть, что дополнительной инициализации объекту не требуется.

В С++ тоже есть понятия default/value/zero initialization, только тут это рояли не играет.

S>В С++ я сходу не нашёл понятия "пустой объект".
Потому что его нету. Это была кривая формулировка alex_public (или не кривая, а чтоб не грузить дотнетчиков плюсовой терминологией).

S>В справочнике, что характерно, про "пустой объект" ничего нету.
S>Зато есть сносящая мне крышу штука про то, что аргументом мув-конструктора является rvalue.
S>Как же так? То есть, если я сделаю так: auto a = std::move(1); то единица превратится в "пустой объект типа int", что бы это ни значило?

Ни во что она не превратится. Перемещение для фундаментальных типов — это копирование.

Здравствуйте, jazzer, Вы писали:
J>Да нет никакого "пустого объекта", он просто некорректно выразился, а ты докопался. Есть понятие "moved-from state".
А, ок.
J>Так что объект, из которого мувнули, переходит в состояние moved-from. Каким оно будет? Таким, как ты напишешь перемещающее присваивание/конструирование.
Вопрос-то в том, как его нужно писать. Например, в дотнете хеш-код любого объекта — это, по определению, результат вызова GetHashCode(). Такой, каким его напишешь.
Но есть определённые ожидания — например, GetHashCode() должен возвращать одинаковые результаты для объектов, у которых Equals() возвращает true.
J>Ни во что она не превратится. Перемещение для фундаментальных типов — это копирование.
А для нефундаментальных? Я всю жизнь считал rvalue чем-то таким, куда нельзя ничего присваивать.
Однако, выходит так, что move как раз рассчитывает на то, что можно успешно убить оригинальный объект.
В моей картине мира явно наблюдается пробел.

Здравствуйте, Sinclair, Вы писали:

I>>Самые проблемные вещи в перформансе
I>>0. кривые алгоритмы и структуры данных, включая встроеные во фремворк
...
S>Ну так с моей точки зрения, единственный способ борьбы с п.1 — это повышение уровня абстракции

Это слишком очевидно. Здесь был конкретный вопрос "Создание лямбды и её вызов ничтожны по сравнению с асинхронной операцией."
Влад был с этим несогласен, а я привел свой 'хитпарад' что бы показать, на каком месте реально находятся проблемы с лямбдами. 'хитпарад' составлен после нескольких лет профилирования большого проекта, в котором перформанс на первых местах.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, jazzer, Вы писали:
J>>Да нет никакого "пустого объекта", он просто некорректно выразился, а ты докопался. Есть понятие "moved-from state".
S>А, ок.
J>>Так что объект, из которого мувнули, переходит в состояние moved-from. Каким оно будет? Таким, как ты напишешь перемещающее присваивание/конструирование.
S>Вопрос-то в том, как его нужно писать. Например, в дотнете хеш-код любого объекта — это, по определению, результат вызова GetHashCode(). Такой, каким его напишешь.
S>Но есть определённые ожидания — например, GetHashCode() должен возвращать одинаковые результаты для объектов, у которых Equals() возвращает true.

Ну, самое главное требование для состояния moved-from — для него должен корректно срабатывать деструктор.
В принципе, можно этим и ограничиться, но обычно требуют еще и чтоб можно было в него присвоить что-нибудь (и тем самым "вернуть" к жизни), потому что тогда move-swap становится тривиальным:

template< typename T >
void swap(T& a, T& b)
{
  T temp(std::move(a)); // a в moved-from state
  a = std::move(b);     // b в moved-from state, а ожил
  b = std::move(temp);  // temp в moved-from state, b ожил
} // temp (moved-from) выходит из области видимости и умирает, срабатывает его деструктор

J>>Ни во что она не превратится. Перемещение для фундаментальных типов — это копирование.
S>А для нефундаментальных? Я всю жизнь считал rvalue чем-то таким, куда нельзя ничего присваивать.
S>Однако, выходит так, что move как раз рассчитывает на то, что можно успешно убить оригинальный объект.
S>В моей картине мира явно наблюдается пробел.

Если у тебя функция возвращает что-то по значению — это rvalue. Но если она вернула неконстантный объект какого-то класса, у него можно звать неконстантные функции, включая operator=:

std::string f() { return "asd"; }
std::cout << (f() = "zxc");

Это было и в С++98.

Здравствуйте, Sinclair, Вы писали:

S>В моей картине мира явно наблюдается пробел.

Ну ты хоть признаёшь это. ) В отличие от некоторых товарищей, которые так же как и ты давно перешли на .net, но утверждают, что вполне себе знают C++. )

Здравствуйте, Ikemefula, Вы писали:

I>

Сам такой.

I>Эдак любой язык с фигурными скобками будет "немерл без ххх"

Ему для этого 100500 фич нужно иметь. Вот Шарп или С++ этим похвастаться не могут, например.

Здравствуйте, Ikemefula, Вы писали:

I>Вот тот же JS — язык распространился даже вопреки Микрософту, который боролся с ним в то самое время, когда у IE было 90% аудитории.

МС был не первым на рынке. И JS стал к тому времени безальтернативным. МС его поддержал, а VBS никто не поддержал. 90% у IE никогда не было. Максимум было 70% и на не очень большом промежутке времени.

С JS многие стонут, но это единственны доступный везде язык в вебе.

I>Фич около нуля, циклы и те не смогли внятно сделать.

Это ты глупость сморозил. Фич у него хватает. Лябмды, замыкания, прототипное ООП, JSON и много чего еще. Хотя продвинутых возможностей вроде паттерн-матчинга не хватает, но их и в С++ с Шарпом нет.

А, вот что реально плохо, так это кривость языка, отсутствие модульности и дизайн не заточенный на компиляцию. Отсюда тормоза, баги, плохая поддержка IDE.

I>Дыр столько, что десяток сайтов навроде wtf.js не могут все это описать.

+1

I>Любые приседания требуют нативных решений.

Что?

I>Однако все сложилось очень даже хорошо — JS распространился и под него запилили столько всяких разных API, что сейчас он практически эталон продуктивности.

Любой язык завоюет рынок, если алтернативы у него не будет. Яву не включили в броузеры. VBS не поддержали производители браузеров.

Здравствуйте, VladD2, Вы писали:

I>>Вот тот же JS — язык распространился даже вопреки Микрософту, который боролся с ним в то самое время, когда у IE было 90% аудитории.

VD>МС был не первым на рынке. И JS стал к тому времени безальтернативным. МС его поддержал, а VBS никто не поддержал.

Значит, ты не в курсе, что Микрософт усиленно хоронила JS, все хотела заменить его vbs ?

>90% у IE никогда не было. Максимум было 70% и на не очень большом промежутке времени.

А ты, в теме.

was the most widely used web browser during its tenure (surpassing Internet Explorer 5.x), attaining a peak in usage share during 2002 and 2003 in the high 80s, and together with other versions up to 95%.

I>>Фич около нуля, циклы и те не смогли внятно сделать.

VD>Это ты глупость сморозил. Фич у него хватает. Лябмды, замыкания, прототипное ООП, JSON и много чего еще.

JSON, к слову, не везде доступен, прикинь ?
Замыкания тормозные, адски дорогие, настолько, что часто их вообще нельзя использовать.

VD>А, вот что реально плохо, так это кривость языка, отсутствие модульности и дизайн не заточенный на компиляцию. Отсюда тормоза, баги, плохая поддержка IDE.

И это не мешает языку пролазить вообще везде. Он уже давно не только в браузере, а вообще везде.

I>>Любые приседания требуют нативных решений.

VD>Что?

Вроде по русски написано. Ты внятно скажи, с чем не согласен.

I>>Однако все сложилось очень даже хорошо — JS распространился и под него запилили столько всяких разных API, что сейчас он практически эталон продуктивности.

VD>Любой язык завоюет рынок, если алтернативы у него не будет. Яву не включили в броузеры. VBS не поддержали производители браузеров.

У MS, когда IE занимал 95% рынка, не хватило мощи продавить свой VBS.

Кстати говоря, по фичам VBS был ничем не хуже джаваскрипта того времени.

Более того — VBS был реализован не меньшим количеством контор, нежели JS. Ты ведь про это совершенно не в курсе, правильно ?

Здравствуйте, alex_public, Вы писали:

_>Почему высокомерное отношение то? Если я сам не раз писал, что C# великолепно справляется с задачами в своей нише

Он великолепно справляется почти с любыми задачами. Ограничением является невозможность таскать с собой дотнет. Ну, и паталогические случаи битовыжимания.

_>(хотя Java в той же нише пожалуй ещё лучше, по сумме параметров).

Лучше она разве что переносимостью. В остальном сравнимо. В яве лучше джит (ХотСпот). У дотнета лучше возможности по ручной оптимизации (честные дженерики, вэлью-типы, ансэйф).

_>Угу, по аналогичной причине D перестал быть так популярен (не в реальных проектах, где его и не было, а в мечтах о будущем) в последние годы.

Не надо тешить себя сказками и мифами.

Ди не стал популярным. И не стал в те времена когда С++11 еще не было и не ясно будет ли. Причина тут та же что с Немерлом. Отсутствие брэнда с кучей ресурсов (амин, пиар, бабла).

_>Что касается LINQ, то он как раз не прекрасен, а ужасен, если вспомнить о быстродействие. Я это лично замерял несколько лет назад вместе с местными спецами по .net. Так вот там код с linq отставал от C++ аналогов не на традиционные для C# значения, а намного больше. Т.е. дело явно не в недостатках платформы .net, а в реализации самого linq. Ну или если не веришь мне, то вот тебе уже в этой темке коллеги подтвердили. )

Скорость не всегда самое главное. Замыкания и делегаты создаются в хипе, и никаких оптимизаций не делается, так что код с ФВП получается медленнее чем аналогичный императивный. Но обычно его скорости за глаза хватает для большинства применений, а там где не хватает есть императив.

В общем, фича удобная и приемлемая для многих задач.

_>Да, а насчёт лямбд... На C# уже можно написать код аналогичный такому http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc ?

Я не очень понимаю что ты имеешь в виду. Возможность выражения монад или использование дженериков с переменным числом аргументов типов? Если первое, то — да. Если второе, то — нет, так как они не поддерживаются. Вместо этого (как в С++03) придется создать дцать перегрузок.

В немерле для монадных игрушек сделан ComputationExpressions.

Ну, и с переменным число параметров в макросах тоже никаких проблем. Так что твой примерчик переписывается на макрах в разы проще. Я правильно понимаю, что он тупо объединяет кортежи (или что-то на них похожее) в один кортеж?

VD>>Так что можно и производительность улучшить за счет перегрузок, и от использования интерфейсов избавиться.

_>Можно и сделано — это очень разные вещи. )

Главное что есть возможность. В плюсах тоже много чего не сделано. Ты же не расстраиваться от этого?

VD>>Создание альтернативной экосистемы коллекций (например, в стиле stl) поломает совместимость, а большого толку не даст.

_>Ну если говорить о какой-то "нашлёпке" к C#, то безусловно смысла нет. Если же говорить об отдельном новом языке, то совсем другое дело.

А зачем создавать в донте несовместимый со остальными языками дотнета набор коллекций? Ну, разве что для особо требовательных к скорости вычислений коду. Но тут проще взять и написать его с использованием встроенного массива, так как быстрее все равно ничего не будет, а он обеспечивает вполне приличный уровень абстракции для большинства задач.

Потом ты не недооцениваешь влияния массового использования МП. Например, в Найтре мы для записи результатов парсинга используем два массива интов. Работа ведется с сырым (не обернутым) массивом донтена. Но код работающий с ним практически не пишется врунчую. Место этого он генерируется. Это позволяет абстрагироваться от деталей за счет метакода. Другими словами нам не нужны высокоуровневые коллекции. Мы имеем другие методы абстрагирования.

VD>>Все и так не плохо. Хотя идея не лишина смысла. Можешь заняться. Будет еще один плюс и ещё одна альтернатива. Лично меня более–менее устраивает дотнетный подход и есть куча других задач.

_>Не раньше чем Nemerle оторвётся от .net'a. )

Сдается мне, что всю клиенскую часть вы спокойно могли бы писать на дотнете и Моно (если вам важна поддержка Линукса и Макоси).

_>А есть какой-то общий известный каталог таких библиотек для Nemerle? ) Интересно посмотреть что там уже наделали... )

https://github.com/rsdn/nemerle/tree/master/snippets
Правда класть туда проекты не является обязательным, по этому ряд больших проектов лежит в отдельных репозиториях.

_>С F# не игрался, а с Haskell'ем игрался... )

В Хаскеле работа с монадами встроенная но к ней нельзя свой синаксис. В гибридных языках вроде F# и Немерла работа с модадами получается в виде паттернов. Компьютейшон экспрешены позволяют автоматизировать этот процесс и сделать красивый синтаксис.

_>Т.е. получается, что Nemerle всё же не является надмножеством C# (как например у того же C->C++) и не может компилировать его код?

Нет. Есть много общих моментов, но синтаксис другой и фичи не все воспроизведены. Например, не поддерживаются шарповские варианты и те же асинки. В немерле есть альтернативные решения возникшие за долго до появления аналогичных фич в шарпе. Нет особого смысла воспроизводить все фичи шарпа 1 в 1. Хотя в немерле есть плагин шарпа который съедает 95% кода на шарпе бзе каких либо изменений. Так что в проект на немерле можно споконой подключить C#-файл и описанные в нем типы и функции будут доступны в проекте. Сами этим иногда пользуемся. Например, вот кусок кода взятый из шарповского проекта.

_>Как раз главное преимущество реализации этого в C# в том, что позволяет пользоваться этим довольно не простым (внутри) инструментом даже не понимая, как оно в реальности работает.

В немерле тоже самое. Просто пишешь плоский код и он работает. Только в Шарпе это реализовано на базе конечных автоматов, а в немерле на базе монад и прочего CPS.

_>Для небольшого проекта при таких условиях я бы точно выбрал Питон. )

Динамически типизируемый язык для больших проктов? Гы-гы. Разве что проект состоит из кучи мелких слабо связанных друг-другом скриптов (как в вебе).

_>Специализация тоже о многом говорит. ) К примеру если один дизайнер "специализируется" в Фотошопе, а другой в Paint'е, то... )))

Вот это и есть надменность. По факту же Шарп сложнее плюсов. Для того чтобы писать качественный код на нем нужно так же быть профессионалом. при этом у шаприста профессионала будет куда более высока производительность нежели у профи плюсовика. Да, МП нет. Код, при использовании одинаковых алгоритмов, получится чуть быстрее на плюсах. Потребление памяти в разы больше чем на плюсах. Но проект будет сдан значительно раньше (опять же при равном его качестве).

Ну, а в случае использовании не профессионалов на шарпе мы получим медленную, плохоподерживаемую программу с глюками и т.а., а на плюсах, с огромной вероятностью, мы получим вылеты, проходы по памяти и прочие радости.

_>Ты не внимательно читаешь мои фразы. Там же чётко было указано — речь о пороге вхождение. Т.е. вопрос не в том, с чём ты сейчас работаешь (я вот может вообще bat файлик ваяю), а в том с чем ты способен работать.

Ну, вот и не тешь себя сказками, что те кто выбирают другие языки менее профессиональны и у них там какие-то проблемы с порогом вхождения в унылый С++. Таких проблем нет. Просто есть языки на которых мы в разы эффективнее, так как они спроектированы в разы лучше плюсов. Для МП в них применяются специально предназначенные для этого вещи. Память управляется автоматически. Получить неиниализированные данные невозможно в принципе. Типизация строже. Так что ошибок в коде становится намного меньше. Все это позволяет больше времени уделять алгоритмам и фичам. В итоге вместо примитивного Spirit-а мы имеем офигительные Nemerle.PEG и Ninta.

_>Я не про это. Я про организацию кода. Вот на C++ мы можем смешать любые макросы, шаблоны, обычный код в одном файле. Можем конечно и раскидать по отдельным, но это как ты понимаешь будет исключительно наше разделение, а не формальное правило. С другой стороны, в том же упоминаемом выше T4 ситуация обратная и это как раз формальное требование. Так вот вопрос как у нас этим в Nemerle? )

Смешать ты конечно можешь. И именно так обычно и происходит. Это будет смешивание макросов и кода времени компиляции. В прочем, подключив ссылку на библиотеку с макросами к обычному проекту этот код можно будет использовать и в самой программе. Но это уже смешивание мета-кода и обычного кода. Практика показывает, что до добра это не доводит.

_>Соответственно если в Nemerle ситуация с макросами как и в C++, то я не вижу особого смысла в каком-то выделение Nemerle библиотек, содержащих макросы. Ну разве что как раз в том смысле, что их нельзя использовать из других языков... )

Смысл есть. Во-первых, в отличии от плюсов макры немерла полностью компилируются и могут повторно использоваться (в разных проектах) в бинарном виде.

В общем, плюсы следующие:
1. Код получается не отличимый по быстродействию от кода компилятора.
2. Есть четкое разделение на мета-код и обычный код.
3. Код можно отлаживать штатными средствами (отладчиком).
4. Можно генерировать исходники для отладки порождаемого кода.

Из минусов, только невозможность по бырому залудить фиговину прямо по месту. Но это спорный минус, так как наличие слишком большого количества неоправданной "магии" может сослужить нехорошую службу.

_>Не, речь о других вещах. Например различные техники работы с Tuple. В C++ то это всё во время компиляции отрабатывает.

В Немерле кортежи и встроены в язык. Лечить их с помощью других стредств (тем более, с помощью побочных эффектов от не предназначенных для этого средств вроде шаблонов) точно не надо. Так что пихать это в библиотеки нет смысла, а результат получается более качественный.

_>Так что тут именно тонкий вопрос. Я например могу сказать что ничего подобного в C# нет вообще и буду абсолютно прав.

Вообще-то кортежи есть в стандартной библиотеки дотнета. Но работать с ними так же не удобно как и на С++, так как для удобной работы с ними нужен паттерн-матчинг.

_>С другой стороны ты можешь сказать что tuple в C# имеется (только работает во время исполнения, что вообще скучно) и к нему даже не нужные какие-то специльные инструменты. И тоже будешь в какой-то степени прав. )))

Буду.

_>>>Ну а вообще для программирование на Nemerle я бы поискал образцы скорее в стандартной библиотеке D, а не в Boost'e. Всё же в C++ МП слабенькое...
VD>>ОК. И что там?

_>А там всё тоже самое, но по другому. ) Я хочу сказать, что там реализована в общем то обычная функциональность стандартной библиотеки языка, но с изначальной заточкой на использование МП, вычисления во время компиляции и т.п. Итог получился очень приятный.

Ты сильно ошибаешься, если думаешь, что я не смотрю по сторонам. Я смотрел и Ди, и Раст. Но ничего интересного для Немерла там не увидел. Там есть интересные решения, вроде шаблонов с переменным числом параметров, но их нужно не в немерл, а в дотнет добавлять. В немерле же есть макры с переменным числом параметров, что для большинства применений хватает. Во стальном немерл — супер-сет к этим языкам. Все что есть в них, есть и в немерле.

_>А вот в D вполне используют. )

Там где ни хрена нет, там и используют.

_>Хотя от МП там всего лишь "static if" и нужен. )

Гы-гы.

_>А ты статью, на которую я кидал тебе ссылку, посмотрел? ) Ну там где про мобильную разработку и ужасы сборщика мусора в ней...

Статья твоя о JS. Все что там сказано о GC — это, что что для его хорошей работы нужно много памяти, которой на старых айфонах нет.

Там же сказано, что на десктопах системы с GC работают так же как нативные или даже быстрее. Ты сам то статью внимательно читал?

_>Про разные мелкие косяки в дискуссии со мной (типа как с Sign# и т.п.) умолчим.

Не надо умалчивать. Если у тебя есть что возразить, приведи доказательства. Я знаю о чем говорю.

_>Но тебе уже несколько человек в этой темке указывали на то, что ты абсолютно не верно проводишь сравнения с C++.

У меня к этим людям нет особого доверия. Они имеют однобокий опыт в отличии от меня и тех людей мнению которых я доверяю.

_>Ты при этом всё время берёшь код, написанный в лучших традициях Java/C# (кстати, довольно странно для бывшего специалиста в C++

), сравниваешь его прямо такой с аналогами на C# (или Nemerle) и делаешь совершенно предсказуемые выводы. Ну да, C++ язык мультипарадигменный и формально говоря позволяет писать и такую кривизну. Но когда ты на основе подобных кривых реализаций начинаешь делать глобальные выводы об эффективности языков, это вызывает в лучшем случае усмешку...

Давай ты мне ссылок дашь подтверждающих эти домыслы обо мне. Выводы я делаю исключительно на опыте разработки софта и фактах. Все наши приложения работали достаточно быстро и на C, и на C++, и на C# и на Nemerle. Если это было не так, мы брали в руки профайлер и добивались необходимой производительности.

Я не догматик, и если это нужно могу перейти и на небезопасный режим, и на С/С++. Но пока производительности хватает или ее можно улучшить алгоритмически, я это делать не буду. И, о ужас, за последние 10 лет я почти всегда обходился алгоритмическими улучшениями. Так что потребность не очень велика.

И не надо мне пытаться внушить, что у меня задачи какие-то не требовательные. Почти все мои задачи были требовательны к производительности. Даже код пакета подготовки статей для РСДН будучи переписан с С++-ных регекспов и вордовских сктиптов стал в 100 раз быстрее будучи переписаым на немерле. Но не из-за того, что немерл какой-то супер быстрый, а потому, что вместо того чтобы вынимать данные из вордовский файлов через атомйшон, я тупо распарсил его ХМЛ-ник и вынул все нужные данные. Получилось гибче и в сто раз быстрее.

_>Не только, но что можно на скриптах (в каком-то смысле). Дотнету в любом случае тут делать нечего. )

А чего же нечего то? Уверен, что на плюсах вы пишете куда больше чем нужно. Да и у скриптов преимуществ нет.

_>Ммм, там не примитивно, просто как раз там сидят самые нагруженные по быстродействию вещи (те самые "кодеки", вывод на экран и т.п.).

Вывод на экран ни разу не проблема для дотнета. Даже, при использовании WPF, может и по круче получиться. Ну, а "кодеки", если там реально нужны разные SIMD-инструкции и т.п., конечно лучше на плюсах или видеокарте реализовывать. Это то где их ниша пока что свободна.

_>Ну т.е. понятно, что у окружающих "кнопок" никакой нагрузки нет, но это уже совсем извращением будет написать остальной gui на каком-то другом языке и потом как-то интегрировать его с окнами от C++ в единое целое.

А зачем нужны окна от С++? Кодек — это по сути тупая функция. А писать нужно на том, что сокращает твое время и улучшает результат. WPF на винде — это то что доктор прописал для подобных задач. Глядишь и кодеки не придется писать, так как там много всего из коробки поддерживается.

_>Ну и потом с помощью правильных инструментов (весь GUI задаётся в специальном удобном редакторе, который потом автоматически генерирует весь нужный C++ код) GUI легко делается и в C++.

Хреновенький и простенький — возможно. Но с WPF-ом его вряд ли можно сравнить. Плюс пишете вы уже все равно не на С++, а на каком-то другом языке. То что с него генерируется уже рояли не играет.

Здравствуйте, Ikemefula, Вы писали:

I>Значит, ты не в курсе, что Микрософт усиленно хоронила JS, все хотела заменить его vbs ?

Не. Не в курсе... Потому что этого не было. Я в те времена как раз все это видел сам. МС поддерживал и VBS, и JS. Их JS малость отличался (так как бы на их сктиптовом рантайме сделан), но это был именно JS. VBS они предлагали лишь как альтернативу. Заменой они его не делали ни разу.

I>А ты, в теме.
I>

I> was the most widely used web browser during its tenure (surpassing Internet Explorer 5.x), attaining a peak in usage share during 2002 and 2003 in the high 80s, and together with other versions up to 95%.

Думаю, что это некорректные вычисления. Как раз в это время мы мониторили броузеры на РСДН и никаких 90% не был и в помине. В прочем, возможно это специфика ресурса.

Не важно. Важно, что JS уже был в Нетскейпе и на всех парах тащился в стандарт. А VBS был частной игрушкой МС.

I>JSON, к слову, не везде доступен, прикинь ?

JSON — это сабсет JS описывающий JS-объекты. Он не может быть где-то не доступен, так как это просто часть JS.

I>Замыкания тормозные, адски дорогие, настолько, что часто их вообще нельзя использовать.

Весь JS тормозной. Но на безрыбье и раком рыбу. И к отсутствию фич это отношения не имеет. Шарп в те времена замыканий и лямбд не имел, в отличии от.

I>И это не мешает языку пролазить вообще везде. Он уже давно не только в браузере, а вообще везде.

Конечно! Альтернативы то нет.

I>>>Любые приседания требуют нативных решений.

VD>>Что?

I>Вроде по русски написано. Ты внятно скажи, с чем не согласен.

Я не понял о чем речь. Какие на фиг нативные решения в броузерах? Что за приседания?

I>У MS, когда IE занимал 95% рынка, не хватило мощи продавить свой VBS.

Какой смысл одно и тоже повторять? Даже если у них когда-то было 95%, то они давно и безвозвратно кончились. А не долгое лидерсво не дало им ничего. JS был и в Нетскейпе (он там первым появился), и в ИЕ. А VBS только в ИЕ. На практике он так никогда и не использовался. То что было названо "dynamic HTML" раскрутилось уже когда МС начал сдавать свои позиции. Хотя я лично еще VBS использьовал в те времена, так как знал васик лучше чем JS.

I>Кстати говоря, по фичам VBS был ничем не хуже джаваскрипта того времени.

Кое чем он отставал. Например, регексы были не встроенными в язык, а во внешенй библиотеке, но не мудренно, что языки были похоже, они же были реаливаны на одном и том же движке WSH. Причем в JS его уши торчали неприкрыто. Внешние объекты были АктивХ-ами и создавались через специальную функцию. Это было не совместимо с Нетскейпом. Так что даже JS у МС был не стандартный и людям приходилось писать обертки. А тогда никаких джейквери еще не было.

I>Более того — VBS был реализован не меньшим количеством контор, нежели JS. Ты ведь про это совершенно не в курсе, правильно ?

VBS был реализован только МС. Это их игрушка. Не придумывай. И ни один браузер кроме ИЕ не поддерживал его.

Здравствуйте, Sinclair, Вы писали:

EP>>С чего это вдруг O(N)?
EP>>Вот например swap двух строк, это какая сложность по-твоему?
S>В зависимости от того, попали ли мы в SSO — либо о(N),

Имелось в виду O(N)? Если да, то N — это что? Константное и малое значение?

S>либо o(1) + затраты на перещёлкивание ref_count.

При move перещёлкивание ref_count не нужно.

S>Или у нас есть какая-то магия компилятора, которая отличает swap от s3=s1; s1=s2; s2=s3 для произвольных типов?

О чём речь? Под swap, разумеется, имеется в виду не дефолтная реализация, а специальная версия для строк.

S>И благодаря чему здесь компилятор ухитрится соптимизировать move? Вот у меня банальный код вызова:
S>

S>void test()
S>{
S>  string s("test"); // байты для 't','e','s','t','\0' хранятся в stack frame этой функции благодаря SSO
S>  s = f(true);
S>  cout << s; // здесь в SSO-области s уже лежат байты 'f','i','r','s','t','\0'. Каким образом они тут оказались?
S>}
S>

Для SSO (когда строка не превышает threshold), или например std::array<int, N> — move действительно ничем не помогает. Но SSO ведь SSO — то есть там малая константа, что-то вроде нескольких слов. Тебя копия нескольких машинных слов смущает?

Здравствуйте, VladD2, Вы писали:

I>>Значит, ты не в курсе, что Микрософт усиленно хоронила JS, все хотела заменить его vbs ?

VD>Не. Не в курсе... Потому что этого не было. Я в те времена как раз все это видел сам. МС поддерживал и VBS, и JS. Их JS малость отличался (так как бы на их сктиптовом рантайме сделан), но это был именно JS. VBS они предлагали лишь как альтернативу. Заменой они его не делали ни разу.

Ты просто не в курсе. Микрософт рассматривала именно VBS как основной язык, и из IE в планах было выбросить JS.

I>>

I>> was the most widely used web browser during its tenure (surpassing Internet Explorer 5.x), attaining a peak in usage share during 2002 and 2003 in the high 80s, and together with other versions up to 95%.

VD>Думаю, что это некорректные вычисления. Как раз в это время мы мониторили броузеры на РСДН и никаких 90% не был и в помине. В прочем, возможно это специфика ресурса.

Надо понимать пример корректности это экстраполяция рунета на весь инет ?

I>>JSON, к слову, не везде доступен, прикинь ?

VD>JSON — это сабсет JS описывающий JS-объекты. Он не может быть где-то не доступен, так как это просто часть JS.

Ты бы посмотрел, как этот JSON поддерживается. Ключевой функции для него может и не быть в движке, представь себе весь ужас. Скажем, всего месяц назад я писал плагин кое для чего именно на таком движке. В силу проблем с безопасностью eval, JSON.xxx тупо недоступны.

I>>Замыкания тормозные, адски дорогие, настолько, что часто их вообще нельзя использовать.

VD>Весь JS тормозной. Но на безрыбье и раком рыбу. И к отсутствию фич это отношения не имеет. Шарп в те времена замыканий и лямбд не имел, в отличии от.

Это усугубляет отсутствие фич. Ты наверное забыл, но JS существенно ускорился совсем недавно. До того там даже простейшие вычисления безбожно тормозили. И ничего — все равно проник, даже с тормозами.

I>>И это не мешает языку пролазить вообще везде. Он уже давно не только в браузере, а вообще везде.

VD>Конечно! Альтернативы то нет.

По твоему на сервере нет альтернанивы ? Смотри выделеное. Тебе только браузер мерещится, а JS уже давно работает вне браузера.

VD>>>Что?

I>>Вроде по русски написано. Ты внятно скажи, с чем не согласен.

VD>Я не понял о чем речь. Какие на фиг нативные решения в броузерах? Что за приседания?

В браузере вообще всё нативное. Не знал ?

VD>Какой смысл одно и тоже повторять? Даже если у них когда-то было 95%, то они давно и безвозвратно кончились. А не долгое лидерсво не дало им ничего.

Важно, что они хотели выбросить JS из браузера.

I>>Кстати говоря, по фичам VBS был ничем не хуже джаваскрипта того времени.

VD>Кое чем он отставал.

Принципиально ни в чем не отставал.

I>>Более того — VBS был реализован не меньшим количеством контор, нежели JS. Ты ведь про это совершенно не в курсе, правильно ?

VD>VBS был реализован только МС. Это их игрушка. Не придумывай. И ни один браузер кроме ИЕ не поддерживал его.

Придумываешь пока что ты сам. Я, к слову, сказал про языки, а не про браузеры. Вот, скажем, Sax Basic — тот же язык, только от другого производителя. Таких решений было пруд пруди. Все сдохли, что характерно.

Здравствуйте, Sinclair, Вы писали:

EP>>Во-вторых, совершенно без разницы. Я показываю, что EA тут не даёт никакой type safety. Эта type safety в управляемых языках есть и без EA, а в C++ возможна без EA.
S>Я понимаю, что вы показываете. Я вам пытаюсь объяснить, что подход управляемых языков — "давайте начнём с корректной программы (т.е. с type safety), а затем сделаем её быстрой (например, снизим нагрузку на GC путём EA)".

По факту же, когда нужно "сделать быстрой", нагрузку с GC снимают off-heap'ом или подобными костылями. То есть escape в прямом смысле, от слов "рвём когти"

Причём со всеми атрибутами вида "объект под указателем(индексом) уничтожен, и запись по указателю портит новый объект"

S>А в С++ подход "давайте начнём с быстрой программы (т.е. дадим пользователю самому управлять временем жизни объектов), а потом безуспешно будем пытаться сделать её корректной".

Почему безуспешно то? Это какой-то уж совсем жёсткий bias, настолько жёсткий — что даже совсем не интересно

Вообще, это уже пошли попытки натянуть ~~сову~~EA на ~~глобус~~type safety, вместо того чтобы просто признать, что изначальный тезис на поверку оказался неверен:

S>О, ещё немного — и вы изобретёте escape analysis.

EP>>Ты говоришь про общий случай. Для общего случая в C++ возможен только conservative GC, что уже обсуждалось выше по топику.
S>Ну, вот и договорились.

С этим никто и не спорил.

S>>>Разговор о том, что у вас нет никакой гарантии, что "GC использован только для части приложения", из-за потенциальной возможности прикопать указатель где угодно.
EP>>Теоретически.
EP>>А практически, для таких сценариев и при необходимости гарантий (например при невозможности достижения их одними guidelines) — можно запретить брать raw указатели на такие GC объекты — частично языком + простейшим внешним верификатором.
S>У нас с вами противоположные понятия о "теоретически vs практически". Я считаю, что ваша идея про необходимость гарантий — это чистая теория, не подтверждённая на практике. А практика — это наличие а) компиляторов, которые неспособны запрещать брать указатели на особые объекты, в том числе и непреднамеренно,

К Clang'у легко делаются plugin'ом, которые pattern match'ат куски AST. Реализовать PM по использованию конструкций std::addressof и т.п. на gc_ptr<T> — там относительно просто.
А отсутствие готового или малая известность — скорей всего от низкой востребованности

S>б) библиотек, которые несовместимы с такими ограниченными объектами, и с) наработанной прикладной кодовой базы на основе компиляторов и библиотек, которую никто не возьмётся переписывать в светлое будущее ради того, чтобы получить хоть какие-то гарантии в одном крошечном кусочке нашего проекта с 15-летней историей.

То есть проект 15 лет работал себе, без необходимости гарантий, а тут вдруг понадобились?
В любом случае, precise GC — это не единственный способ получить их. Например достаточно упомянутых выше region'ов

EP>>>>По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.
S>>>Совершенно верно. Юмор в том, что С++ не позволяет ни того, ни другого.
EP>>А кто тогда позволяет? ObjectDisposed и OutOfBounds?

S>Конечно.

И как они помогают минимизировать баги?

WH>В случае C# пользователь иногда будет получать сообщение: "Извыни дарагой. Нешмагла. У програмыст рука кривой. В него ужа патинка полетел."

И кстати, на счёт ObjectDisposed — с помощью ref-counted подобная ситуация разгуливается элементарно. Как бы сделать это на C#?

EP>>Так это реальный C++, удовлетворяющий стандарту, а не аналог

S>Покажите мне этот "реальный C++". Увы — он существует только в вашем воображении.

Смотри valgrind и sanitizer'ы.

EP>>shared state — это ref counted объект, грубо говоря std::shared_ptr<bool>. На него ссылаются и сам объект и все указатели.
EP>>При разрушения объекта, он всего лишь записывает в этот флаг false.
S>Да, так будет работать. Интересно, отчего эта техника не применяется в управляемых средах?

От того что там применяется другая техника, с другими характеристиками: "продление жизни объекта до тех пор пока на него есть последняя ссылка", а не "даём возможность узнать при доступе по ссылке — мёртв он или нет".

Точнее для IDisposable — там как раз что-то подобное и применяется. Только считай что shared sate встроен в объект, со всеми вытекающими. Например объект уже Disposed, а память занимаемая им всё ещё держится, так как есть ссылки

Для C++, кстати, тоже можно так сделать, необязательно отдельный shared state — но так будет излишний перерасход памяти

Здравствуйте, Sinclair, Вы писали:

J>>Так что объект, из которого мувнули, переходит в состояние moved-from. Каким оно будет? Таким, как ты напишешь перемещающее присваивание/конструирование.
S>Вопрос-то в том, как его нужно писать. Например, в дотнете хеш-код любого объекта — это, по определению, результат вызова GetHashCode(). Такой, каким его напишешь.
S>Но есть определённые ожидания — например, GetHashCode() должен возвращать одинаковые результаты для объектов, у которых Equals() возвращает true.

Стандартная библиотека описывает эти требования: MoveConstructible, MoveAssignable. И в тех местах где они требуются — указывается явно, например в std::rotate.
http://en.cppreference.com/w/cpp/concept/MoveConstructible
http://en.cppreference.com/w/cpp/concept/MoveAssignable

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Сглаживание последствий багов, никак не отменяет того что это баг.

Зато позволяет не потерять все незаписанные данные от того, что в реализации фичи вызываемой по кнопке закрался баг.

Мы эту проблему еще 10 лет назат с Пашей Кузнецовым обсуждали. Я его так и не смог убедить, что не для всех задач лучшей реакцией на ошибку является немедленное падение с дампом.

EP>Да, для некоторых классов багов, языки с GC и выключенным unsafe — дают определённые гарантии, которых нет в C++ без внешних тулз

WH>>Знаешь, как в яндексе борются с утечками памяти и проездами по памяти?
WH>>Рестартом демона по таймеру. Ну, или по факту выпадения в кору.

EP>Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны

Дык его невозможно гарантировать на не безопасных системах типов. Ведь при испорченной памяти вообще ничего гарантировать нельзя.

EP>Баги есть везде. И да, C++ на некоторые классы багов отвечает очень жёстко, самым низкоуровневым образом. Но это же очевидно, и с этим никто не спорил.

Типобозопасные языки существуют уже более 50 лет.

Здравствуйте, alex_public, Вы писали:

_>Ну а в остальном я в общем то согласен. Только вывод бы немного переделал: для достижения одинаковой скорости разработки на C# и C++, требуется чтобы программист C++ был заметно более высокого уровня.

А если представить обратную ситуацию? Ну, программист на Шарпе заметно более высокого уровня? Что будет?

А если представить, что он не Шарп, а Немарл использует?

Пойми, я решу задаче на любом языке. Даже на ассемблере, если нужно. Но чем выше уровень языка, чем более сложную задачу я смогу решить. Сравнимые же задачи будут решаться быстрее.

Здравствуйте, VladD2, Вы писали:

VD>Он великолепно справляется почти с любыми задачами. Ограничением является невозможность таскать с собой дотнет. Ну, и паталогические случаи битовыжимания.

Безусловно, но это ты описал теоретическую область применимости платформы, а не рыночную нишу. Фокус в том, что ниша определяется не той областью, где язык может решить задачу, а той, где он решает её лучше остальных по сумме параметров. Так вот java/c# очевидно являются лучшими при главном упоре на минимизацию расходов it отдела какой-то корпорации. Это безусловно очень большая ниша, но при этом она всё же намного меньше вышеуказанной области применимости самой платформы.

VD>Не надо тешить себя сказками и мифами.
VD>Ди не стал популярным. И не стал в те времена когда С++11 еще не было и не ясно будет ли. Причина тут та же что с Немерлом. Отсутствие брэнда с кучей ресурсов (амин, пиар, бабла).

Ты не понял мою мысль. ) D конечно же не был популярен в смысле применения в реальных проектах. Но про него многие знали и в головах он вполне чётко держался как потенциальное будущее (типа вот сейчас там инфраструктуру ещё подтянут и точно надо перебираться туда с отсталого C++). А вот в последнее время, в связи с развитием C++, народ уже не особо думает о нём как о явном будущем. Теперь частично такие взгляды кидаются на Rust, а частично и на будущее стандарты самого C++...

VD>Я не очень понимаю что ты имеешь в виду. Возможность выражения монад или использование дженериков с переменным числом аргументов типов? Если первое, то — да. Если второе, то — нет, так как они не поддерживаются. Вместо этого (как в С++03) придется создать дцать перегрузок.

Второе. ) Так получается, что лямбды в C++ мощнее чем в C#?)

VD>В немерле для монадных игрушек сделан ComputationExpressions.

Хм, вообще никакого описания не ставите? А как тогда народу незнакомому с Nemerle оценить его крутизну (она же как раз в таких вещах проявляется)?

VD>Ну, и с переменным число параметров в макросах тоже никаких проблем. Так что твой примерчик переписывается на макрах в разы проще. Я правильно понимаю, что он тупо объединяет кортежи (или что-то на них похожее) в один кортеж?

С помощью нормального МП понятно что можно что угодно сделать. Собственно даже и нормального не требуется, т.к. работа с кортежами есть в C++ давным давно (на базе игр в шаблоны). Фокус в том, что здесь это не МП. )

Ну и да, там объединяются и выводятся кортежи с помощью классических приёмов ФП. Но как бы этот тест был написан не ради кортежей, а ради демонстрации современных возможностей лямбд в C++. Понятно что прямо такой код вряд ли кто-то будет писать на практике, но у подобных лямбд есть очень много интересных способов использования. Кстати, я уже сам натыкался в старом коде на проблему, самым эффективным решением которой, как раз они и были бы.

VD>А зачем создавать в донте несовместимый со остальными языками дотнета набор коллекций? Ну, разве что для особо требовательных к скорости вычислений коду. Но тут проще взять и написать его с использованием встроенного массива, так как быстрее все равно ничего не будет, а он обеспечивает вполне приличный уровень абстракции для большинства задач.

Вообще речь шла не о самих коллекция, а об алгоритмах работы с ними. Т.е. замена linq. Благодаря МП алгоритм может автоматически распознавать тип коллекции (например тот же встроенный массив) и применять соответствующие оптимизации. Конечно подобное можно реализовать и во время выполнения, но понятно, что эффективность такого кода будет совсем низкая.

VD>Сдается мне, что всю клиенскую часть вы спокойно могли бы писать на дотнете и Моно (если вам важна поддержка Линукса и Макоси).

Если ты про мой текущий проект, то его программную часть можно разделить на 3 чёткие части:
1. Реалтайм в микроконтроллерах. Тут просто по условию задачи подходит только C или C++. Мы выбрали C++ (что кстати считается "продвинутым" решением — здесь индустрия только ещё начинает переползать с C).
2. Решение без GUI (собственно у железа даже экрана нет), требующее высокого быстродействия и взаимодействия с драйверами. В качестве платформы Linux. Здесь мог бы подойти любой быстродействующий системный язык (например D). Мы выбрали C++.
3. Решение с GUI, требующее высокого быстродействия. Желательна максимальная кроссплатформенность. Здесь подходит любой быстродействующий язык с наличием удобных GUI библиотек (C++, кто ещё?). Мы выбрали C++.

Куда ты тут предлагаешь засунуть дотнет? )

_>>А есть какой-то общий известный каталог таких библиотек для Nemerle? ) Интересно посмотреть что там уже наделали... )
VD>https://github.com/rsdn/nemerle/tree/master/snippets
VD>Правда класть туда проекты не является обязательным, по этому ряд больших проектов лежит в отдельных репозиториях.

Что-то там в основном просто какие-то примеры тестовых программок на Nemerle, а не библиотеки. А те, что вроде как библиотеки (типа Nemerle.Statechart), вообще без строчки документации. Что-то это как-то не сравнимо с тем же Boost'ом. Я конечно понимаю, что количество разработчиков не сравнимое, но как вообще начать пользоваться такой библиотекой? Бродить по исходникам?

_>>Для небольшого проекта при таких условиях я бы точно выбрал Питон. )
VD>Динамически типизируемый язык для больших проктов? Гы-гы. Разве что проект состоит из кучи мелких слабо связанных друг-другом скриптов (как в вебе).

Гмммм...

_>>Специализация тоже о многом говорит. ) К примеру если один дизайнер "специализируется" в Фотошопе, а другой в Paint'е, то... )))
VD>Вот это и есть надменность. По факту же Шарп сложнее плюсов. Для того чтобы писать качественный код на нем нужно так же быть профессионалом. при этом у шаприста профессионала будет куда более высока производительность нежели у профи плюсовика. Да, МП нет. Код, при использовании одинаковых алгоритмов, получится чуть быстрее на плюсах. Потребление памяти в разы больше чем на плюсах. Но проект будет сдан значительно раньше (опять же при равном его качестве).

Это был пример актуальности информации о специализации, а не аналогия на сравнение натива и .net'a. Если же говорить про последнее, то тут наверное самой корректной аналогией будет старый пример: автомобили с ручной и автоматической коробкой передач. Автоматическая коробка плохо подходит для гонок (быстрого кода) и особого бездорожья (системного кода), но отлично подходит для того, чтобы отвести детей в школу (написать корпоративную формочку), что является намного более востребованной задачей. Это всё очевидно и ты вроде как с этим всем согласен. Но почему-то никак не можешь понять другую простейшую вещь: профессиональный гонщик отвезёт детей в школу на машине с ручной коробкой передач (напишет GUI на C++) не менее безопасно и комфортно. )

VD>Ну, а в случае использовании не профессионалов на шарпе мы получим медленную, плохоподерживаемую программу с глюками и т.а., а на плюсах, с огромной вероятностью, мы получим вылеты, проходы по памяти и прочие радости.

Всё верно.

VD>Ну, вот и не тешь себя сказками, что те кто выбирают другие языки менее профессиональны и у них там какие-то проблемы с порогом вхождения в унылый С++. Таких проблем нет. Просто есть языки на которых мы в разы эффективнее, так как они спроектированы в разы лучше плюсов. Для МП в них применяются специально предназначенные для этого вещи. Память управляется автоматически. Получить неиниализированные данные невозможно в принципе. Типизация строже. Так что ошибок в коде становится намного меньше. Все это позволяет больше времени уделять алгоритмам и фичам. В итоге вместо примитивного Spirit-а мы имеем офигительные Nemerle.PEG и Ninta.

А никто и не говорил о профессиональном уровне отдельных людей — профессионал останется собой и при написание bat файлов. Речь шла о предназначение языка.

Да, и речь тут шла про C#, а не про Nemerle. С позиционированием последнего как раз есть большие вопросы, т.к. на нишу C#/Java он не очень попадает из-за сложности (даже само понятие МП не у всех приживается), а на нишу C++ из-за ограничений .net'a.

VD>Вообще-то кортежи есть в стандартной библиотеки дотнета. Но работать с ними так же не удобно как и на С++, так как для удобной работы с ними нужен паттерн-матчинг.

Я же говорю, там кортежи времени исполнения — это вообще не то (подобную ерунду на любом языке за пару минут можно накидать, но эффективность понятно какая будет). Да, и на C++ действительно не хватает пары синтаксических удобств для работы с кортежами, которые есть в других языках (типа Swift'a). Например для распаковки требуются уже объявленные переменные http://en.cppreference.com/w/cpp/utility/tuple/tie и т.п. мелочи. Но в целом работа как раз вполне удобная.

VD>Ты сильно ошибаешься, если думаешь, что я не смотрю по сторонам. Я смотрел и Ди, и Раст. Но ничего интересного для Немерла там не увидел. Там есть интересные решения, вроде шаблонов с переменным числом параметров, но их нужно не в немерл, а в дотнет добавлять. В немерле же есть макры с переменным числом параметров, что для большинства применений хватает. Во стальном немерл — супер-сет к этим языкам. Все что есть в них, есть и в немерле.

Не, я не про сами языки, а про то, как они распорядились обладанием возможностью МП. К примеру в стандартной библиотеке D (в исходниках, а не в интерфейсе!) есть много любопытных решений... Одно я тут уже упоминал — очень эффективная реализация стандартных алгоритмов работы контейнерами. Так что использование абстракции типа linq (там это Range) не привносит вообще никаких накладных расходов.

VD>Статья твоя о JS. Все что там сказано о GC — это, что что для его хорошей работы нужно много памяти, которой на старых айфонах нет.

Про JS там было только вступление) И достаточно памяти нет не только на старых айфонах, а считай во всей мобильной разработке.

_>>Про разные мелкие косяки в дискуссии со мной (типа как с Sign# и т.п.) умолчим.
VD>Не надо умалчивать. Если у тебя есть что возразить, приведи доказательства. Я знаю о чем говорю.

Просматривал код ядра Singularity? )

_>>Но тебе уже несколько человек в этой темке указывали на то, что ты абсолютно не верно проводишь сравнения с C++.
VD>У меня к этим людям нет особого доверия. Они имеют однобокий опыт в отличии от меня и тех людей мнению которых я доверяю.

Какое отношение имеет опыт работы на .net'е к оценке правильности написания на C++? )

VD>Давай ты мне ссылок дашь подтверждающих эти домыслы обо мне. Выводы я делаю исключительно на опыте разработки софта и фактах. Все наши приложения работали достаточно быстро и на C, и на C++, и на C# и на Nemerle. Если это было не так, мы брали в руки профайлер и добивались необходимой производительности.

Я не знаю какой там у тебя был когда-то код, я вижу твои высказывания по C++ в этой темке. И из них можно сделать только один из следующих выводов:
1. Ты никогда полноценно не знал C++.
2. Знал, но подзабыл в последнее время (переучился на другой стиль).
3. Всё прекрасно знаешь, но специально говоришь о таком коде на C++ (благо язык позволяет и такое писать), в сравнение с которым аналог на Java/C# может оказаться выигрышным.

VD>И не надо мне пытаться внушить, что у меня задачи какие-то не требовательные. Почти все мои задачи были требовательны к производительности. Даже код пакета подготовки статей для РСДН будучи переписан с С++-ных регекспов и вордовских сктиптов стал в 100 раз быстрее будучи переписаым на немерле. Но не из-за того, что немерл какой-то супер быстрый, а потому, что вместо того чтобы вынимать данные из вордовский файлов через атомйшон, я тупо распарсил его ХМЛ-ник и вынул все нужные данные. Получилось гибче и в сто раз быстрее.

А если бы ты на C++ написал с парсингом xml? ) Или на Питоне (в котором парсер xml написанный на C)? )

VD>Вывод на экран ни разу не проблема для дотнета. Даже, при использовании WPF, может и по круче получиться. Ну, а "кодеки", если там реально нужны разные SIMD-инструкции и т.п., конечно лучше на плюсах или видеокарте реализовывать. Это то где их ниша пока что свободна.

Речь про вывод FHD/4K видео с минимальной задержкой. Что-то я сомневаюсь... ) У меня тут в миллисекундах промерен весь тракт до OpenGL/DirectX. )

VD>А зачем нужны окна от С++? Кодек — это по сути тупая функция. А писать нужно на том, что сокращает твое время и улучшает результат. WPF на винде — это то что доктор прописал для подобных задач. Глядишь и кодеки не придется писать, так как там много всего из коробки поддерживается.

Я же говорю, как раз здесь требуется быстродействие. )

_>>Ну и потом с помощью правильных инструментов (весь GUI задаётся в специальном удобном редакторе, который потом автоматически генерирует весь нужный C++ код) GUI легко делается и в C++.
VD>Хреновенький и простенький — возможно. Но с WPF-ом его вряд ли можно сравнить. Плюс пишете вы уже все равно не на С++, а на каком-то другом языке. То что с него генерируется уже рояли не играет.

Интерфейс не пишется, а "рисуется" мышкой в редакторе. ))) После чего генерируется C++ код и остаётся только пронаследоваться от созданного абстрактного класса и реализовать все чистые виртуальные функции (так редактор задаёт обработчики событий, настроенные в нём). В данном случае весьма эффективен и процесс разработки и получаемый результат.

Да, кстати... А что, сложный интерфейс — это теперь стало плюсом ПО? ) На мой взгляд это как раз большой минус и его надо максимально избегать.

Здравствуйте, VladD2, Вы писали:

VD>А если представить обратную ситуацию? Ну, программист на Шарпе заметно более высокого уровня? Что будет?

А такой программист не очень интересен нормальному не it бизнесу (на который и ориентированы java/c#), т.к. слишком дорого стоит (причём речь не столько про зарплату, сколько про заменимость). Так что ему остаётся достаточно специфическая ниша — it компании, которые при этом работают на .net. Обычно это в некотором роде сервисные компании, занимающиеся достраиванием блоков инфраструктуры платформы (библиотеки, инструменты и т.п.). Хотя в последнее время появилась новая ниша для использования java/c# it компаниями — мобильная разработка. Но судя по объёмам и качеству создаваемого ими ПО, там ситуация с уровнем оказалась ещё хуже, чем в корпоративном секторе.

VD>Пойми, я решу задаче на любом языке. Даже на ассемблере, если нужно. Но чем выше уровень языка, чем более сложную задачу я смогу решить. Сравнимые же задачи будут решаться быстрее.

Безусловно. И чем выше уровень языка, тем уже круг решаемых им задач. В идеале приходим к использованию каких-нибудь DSL'ей. )

Так вот на мой взгляд сейчас самым простым и одновременно эффективным вариантом реализации подобного является приложение на C++ (получаем быстродействие) с интегрированным в него скриптовым языком (получаем гибкость и скорость разработки).

Здравствуйте, VladD2, Вы писали:

EP>>Сглаживание последствий багов, никак не отменяет того что это баг.
VD>Зато позволяет не потерять все незаписанные данные от того, что в реализации фичи вызываемой по кнопке закрался баг.

Не, не позволяет в общем случае

Баг может делать что угодно.

VD>Мы эту проблему еще 10 лет назат с Пашей Кузнецовым обсуждали. Я его так и не смог убедить, что не для всех задач лучшей реакцией на ошибку является немедленное падение с дампом.

Зависит от задач. Где-то лучше падение с дампом, где-то лучше попытка сохранить пользовательские данные (например что-то типа std::at_quick_exit), а где-то может и spinning до приезда реанимационной бригады.

EP>>Да, для некоторых классов багов, языки с GC и выключенным unsafe — дают определённые гарантии, которых нет в C++ без внешних тулз

WH>>>Знаешь, как в яндексе борются с утечками памяти и проездами по памяти?
WH>>>Рестартом демона по таймеру. Ну, или по факту выпадения в кору.
EP>>Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны

VD>Дык его невозможно гарантировать на не безопасных системах типов. Ведь при испорченной памяти вообще ничего гарантировать нельзя.

Его нельзя гарантировать вообще нигде

Здравствуйте, alex_public, Вы писали:

_>Это был пример актуальности информации о специализации, а не аналогия на сравнение натива и .net'a. Если же говорить про последнее, то тут наверное самой корректной аналогией будет старый пример: автомобили с ручной и автоматической коробкой передач. Автоматическая коробка плохо подходит для гонок (быстрого кода) и особого бездорожья (системного кода), но отлично подходит для того, чтобы отвести детей в школу (написать корпоративную формочку), что является намного более востребованной задачей. Это всё очевидно и ты вроде как с этим всем согласен. Но почему-то никак не можешь понять другую простейшую вещь: профессиональный гонщик отвезёт детей в школу на машине с ручной коробкой передач (напишет GUI на C++) не менее безопасно и комфортно. )

Опять неверные аналогии. АКПП рулят. В формуле-1 запрещены правилами. А по поводу бездорожья... На джипах и даже танках давно уже устанавливаются.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Не, не позволяет в общем случае

Баг может делать что угодно.

Может. В С++ может по памяти пройтись или свалить все приложение (эксцепшон в деструкторе). В управляемом мире критичным будет только баг в критичном месте. Ошибка в меню копирования не свалит весе приложение, например.

VD>>Мы эту проблему еще 10 лет назат с Пашей Кузнецовым обсуждали. Я его так и не смог убедить, что не для всех задач лучшей реакцией на ошибку является немедленное падение с дампом.

EP>Зависит от задач.

Решил в капитана очевидность поиграть. Или просто так соглашаешься?

EP>Его нельзя гарантировать вообще нигде

Почему же нельзя? Можно. Есть стратегии разработки позволяющие реализовать отказоустойчивые системы. Но это не про плюсы.

Здравствуйте, alex_public, Вы писали:

_>А такой программист не очень интересен нормальному не it бизнесу (на который и ориентированы java/c#),

Я устал тебе повторять, что тебе нужно как-то бороться со своими предрассудкам (уж не знаю, как это назвать, чтобы не обидеть). У нас в конторе сотни программистов в основном пишущих на управляемых языках. Среди них десятки высококлассных специалистов. Да и остальные не ламеры.

Так что этот миф забудь. Ява и шарп — это языки общего назначения пригодные как для бизнеса, так и для разработки любого другого софта, за редким исключением.

_>т.к. слишком дорого стоит (причём речь не столько про зарплату, сколько про заменимость).

Ну, ты вряд ли заменишь наших специалистов. И что? Делаем вывод, что ты неквалифицированный специалист? И зарплаты у них скорее всего выше твоих. Опять делаем вывод о твоей квалификации?

Может тебе стоит сменить позицию на более взвешенную и менее смешную и признать, что класс специалиста никак не зависит от языка? Спецы могут быть и на ПХП. Им даже труднее

.

_>Так что ему остаётся достаточно специфическая ниша — it компании, которые при этом работают на .net. Обычно это в некотором роде сервисные компании, занимающиеся достраиванием блоков инфраструктуры платформы (библиотеки, инструменты и т.п.). Хотя в последнее время появилась новая ниша для использования java/c# it компаниями — мобильная разработка. Но судя по объёмам и качеству создаваемого ими ПО, там ситуация с уровнем оказалась ещё хуже, чем в корпоративном секторе.

Ты сотворил для себя миф и боишься с ним расставаться.

_>Безусловно. И чем выше уровень языка, тем уже круг решаемых им задач.

Вовсе нет.

_>В идеале приходим к использованию каких-нибудь DSL'ей. )

DSL и языки общего назначения (GPL) — это разные вещи. DSL могут прекрасно дополнять GPL-и. Если язык тюринг-полный, то решать на нем можно любые задачи. Просто он может быть не очень удобен или не обладать некими свойствами делающими его применение менее целесообразным чем другим. Но от уровня языка это не зависит.

_>Так вот на мой взгляд сейчас самым простым и одновременно эффективным вариантом реализации подобного является приложение на C++ (получаем быстродействие) с интегрированным в него скриптовым языком (получаем гибкость и скорость разработки).

Ну, да. Любой язык хорош, так как на нем можно реализовать лисп-машину, на которой просто и быстро решить задачу. (ц)

Зачем мне два языка, если используемый мной язык выше уровнем чем используемый тобой скриптовый язык и обеспечивает производительность на уровне мало отличимом от того что предоставляют С++-ные компиляторы?

Как бы производительность ведь не догма. Это всего лишь один из критериев. И максимальная производительность нужна редко. Обычно нужна приемлемая производительность. Скажем мне по фигу будет ли игра обеспечивать 120 FPS или 100500, ведь приемлемым является 60.

Скрипты же это не только тормоза, но и баги. От проходов по памяти они защитят, но от ошибок типов в рантайме — нет. А это очень частая причина ошибок. Пока проект мелкий и кода мало это не заметно и даже кажется (по сравнению с С++), что на скрипте писать быстрее. Но с ростом кодовой базы становится все сложнее поддерживать проект в качественном состоянии.

Так на фиг мне это нужно?

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	30.09.09 19:27
Оценка:	24 (3) +6 -2

От:	VladD2	www.nemerle.org
Дата:	30.09.09 19:38
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	30.09.09 20:24
Оценка:	+2

	От:	Рысцов Денис
	Дата:	01.10.09 02:35
	Оценка:	1 (1) +1

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	23.09.14 05:19
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	24.09.14 19:57
Оценка:	1 (1) +2

	От:	Alexey.Maletin
	Дата:	25.09.14 01:39
	Оценка:	1 (1)

	От:	Evgeny.Panasyuk
	Дата:	28.09.14 07:44
	Оценка:	+1

От:	jazzer	Skype: enerjazzer
Дата:	28.09.14 13:32
Оценка:	+2

	От:	DarthSidius
	Дата:	28.09.14 14:49
	Оценка:	+1 -1

	От:	hi_octane
	Дата:	28.09.14 21:00
	Оценка:	50 (2) +1

	От:	Константин
	Дата:	29.09.14 01:51
	Оценка:

	От:	WolfHound
	Дата:	29.09.14 18:34
	Оценка:	49 (1)

	От:	bazis1
	Дата:	30.09.14 15:54
	Оценка:	99 (1) +1

От:	STDray	http://stdray.livejournal.com
Дата:	30.09.14 16:55
Оценка:

	От:	btn1
	Дата:	26.09.14 21:53
	Оценка:

	От:	btn1
	Дата:	27.09.14 19:19
	Оценка:

	От:	Дьяченко Александр
	Дата:	30.09.14 18:31
	Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	02.10.14 06:12
Оценка:	+2 -2

От:	IT	linq2db.com
Дата:	02.10.14 12:58
Оценка:	+1

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	08.10.14 07:37
Оценка:

От:	ionoy	www.ammyui.com
Дата:	09.10.14 05:11
Оценка:	+1

От:	Mystic	http://mystic2000.newmail.ru
Дата:	10.10.14 07:01
Оценка:

	От:	alex_public
	Дата:	10.10.14 12:35
	Оценка:	+2 -2

От:	Sinclair	https://github.com/evilguest/
Дата:	20.10.14 10:18
Оценка:	3 (1)

От:	мыщъх	http://nezumi-lab.org
Дата:	21.10.14 04:57
Оценка: