Здравствуйте, 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>У меня пока меленький был тоже падали. Уверен, что и у тебя падали.
Когда я был маленький, я и в таблице умножения путался. Только вот какое это имеет отношение к продакшену, который, вроде как, пилится профессионалами

You will always get what you always got
  If you always do  what you always did

Здравствуйте, 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>Привлекать мартышек себе дороже.

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

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

STD>Немерл не является надмножеством шарпа.

Он даже не является надмножеством самой самой основы шарпа. В этом и проблема.

STD>Надо понимать, что ядро Немерле — минималистичный ML

Есть одна проблемка — минималистичный ML нужен только гикам.

STD>, но возможности его макросистемы позволяют создать диалект достаточно близкий к C#.

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

STD>Это, имхо, знатное чсв, что можно взять шарп и что-то там убрать или добавить.

Как любит говорить один старый пользователь RSDN — перешел на личности значит слил.

STD> Шарп делают умнейшие люди

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

STD>Ну микроядро языка позволяет строить разные языки.

Опять позволяет. Все разговоры в будущем времени.

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

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

Это практически точная цитата.

I>а в том, что мы банально не могли договориться о каких-то очевидных вещах.

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

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

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

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

J>Я не прошу тебя приводить весь код, просто объясни, зачем там вообще нужно создание временного объекта, да еще и в куче? Для чего нужны приседания с локальной переменной (указателем?), если она первой же строчкой уезжает(?) в поле класса?
Ты вообще читал, на что отвечаешь?
Или ты предпочитаешь чтобы я на тебя сейчас вывалил мегабайт кода в котором без ГЦ вообще не разобраться?

J>Уволь меня от погружения в тонкости .НЕТ, плиз. Объясни нормальным сиплюсовым языком.
Я просто показал в каком месте С++у нужна синхронизация, а .НЕТу нет.

J> Вот это новости от знатока. Похоже, ты знаешь о нем что-то не то.
Всё я о нём знаю. Переменная d1 в этом случае разрушается.
А это далеко не всегда приемлемо.

J>Когда я был маленький, я и в таблице умножения путался. Только вот какое это имеет отношение к продакшену, который, вроде как, пилится профессионалами
И сколько лет практики должно быть у человека, прежде чем он станет профессионалом?
По моим наблюдениям 5-10 лет в зависимости от таланта.

Здравствуйте, 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 объект. Фейерверк?
Нет. Обычное исключение.

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

EP>В случае же Nemerle — макрос даже и сослаться на эту функцию не может, так как нет соответствующей сборки, а появится она когда макрос уже не будет работать.
Может. И на функции. И на типы. И на всё остальное.

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

EP>>В случае же Nemerle — макрос даже и сослаться на эту функцию не может, так как нет соответствующей сборки, а появится она когда макрос уже не будет работать.
WH>Может. И на функции. И на типы. И на всё остальное.

Естественно имелась в виду не просто "forward" ссылка, а именно использование.
Если это доступно — то в двух словах какой механизм?

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

EP>Естественно имелась в виду не просто "forward" ссылка, а именно использование.
EP>Если это доступно — то в двух словах какой механизм?
Это и шаблоны не могут.

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

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

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

Это явление малость под утомило. Мартышек много и они активны. Ответить на все глупости которые они говорят не хватит и всей жизни. Проводить остаток жизни в споре с ними нет никакого желания.