Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Отвязанности от .NET
VD>Мы подумываем сделать следующую версию немерла кросплатформной. Но GC в таких языках нужен по любому. Так что платформы должны поддерживать GC.
VD>Кстати, чем не устраивает https://github.com/dotnet/core ? Теперь донет шагнул в опенс-сорс. Так что в ближайшее время проблемы с переносом дотнета на другие аппаратные платформы должны исчезнуть.
Ну вот когда исчезнут, тогда и будет разговор.
Но я очень не уверен, что GC сможет наравне конкурировать с С++ на моих задачах.
Меня вполне устраивает уровень контроля за управлением памятью в С++. Я прекрасно обхожусь без GC и нет, это ни разу не кактус.
То, что я реально хотел бы — это С++, но с макросами Немерле. Потому что препроцессорное и шаблонное метапрограммирование в С++ — это реально кактус (у меня в проекте и того, и другого очень много, так что я знаю, о чем говорю).
Здравствуйте, DarkEld3r, Вы писали:
DE>Ну а немного "пиара" у вас ведь тоже есть. Да, WolfHound тут говорил, что Немерле никто за зарплату не развивает, но Нитру вы ведь пилите на деньги джетбрейнс. А это тоже известный бренд.
Нитра ещё даже не альфа.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Многовато, но допустим.
Я несколько преувеличиваю, конечно.
ГВ>>И хоть что хочешь делай, но воткнуть в такой процесс новое, малоизученное средство — задача совсем не тривиальная.
EP>Для open-source проектов таких ограничений нет.
А при чём здесь open source?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DE>>Ну а немного "пиара" у вас ведь тоже есть. Да, WolfHound тут говорил, что Немерле никто за зарплату не развивает, но Нитру вы ведь пилите на деньги джетбрейнс. А это тоже известный бренд. WH>Нитра ещё даже не альфа.
Июль 2011 года
Today at the JVM Language Summit, JetBrains is unveiling the new project we’ve been working on for almost a year now. The project is Kotlin, a new statically typed programming language for the JVM.
Right now Kotlin is under active development and nowhere near mature enough to be used by anyone outside of the development team. What you can do today is read the language documentation and leave feedback on the design of the language — what features you like, which ones are missing, what’s confusing and so on.
С тех пор — по два-три поста в блоге на протяжение всего развития. Ой, а в language documentation с самого начала было даже comparison to java, comparison to scala...
Здравствуйте, VladD2, Вы писали:
VD>Вот забавно. C# ты используешь, а не хватает тебе чего-то в Nemerle.
Я так думаю, имеется в виду, что не хватает для того, чтоб перевести проект на него с шарпа. То есть язык, конечно, лучше, но не настолько лучше, чтоб перевесить весь гемор и риски от перевода всего проекта (и кода, и программеров!) на него.
VD>если тебе нравится Немерл, то мог бы спросить нас о том есть ли в нем, что то для Веба. И мы бы дали тебе ссылку на NemerleWeb, который является
Я правильно помню, что вы RSDN планировали переписать на нем? Если да, то как успехи? Был бы killer app: здоровый сайт с развесистой логикой написан на всего ничего кода на Немерле, офигевайте.
В первой ссылке автор жалеет о зелёных потоках, но я бы не сказал, что для системного языка это плохо. Раст сейчас может работать с минимальным тантаймом, а то и вовсе без него. Если же прибивать зелёные потоки гвоздями, то в этом плане всё было бы хуже. При этом в виде отдельной библиотеке они есть.
С unsafe похожая ситуация. Если мы хотим максимум скорости выжимать, то иногда приходится идти на определённые допущения (да банально asm-вставки — как компилятор может контролировать, что ими ничего не испортишь?). Опять же, с логикой в духе "можно выстрелить в ногу — значит это будут делать" категорически не согласен. В конце концов, в менеджед языках есть FFI, в итоге можно ничуть не хуже расстрелять память, но на деле это проблем не вызывает.
Вторая ссылка — тупо наброс, куча воды и повторение прописных истин в духе "новый язык — значит нет инструментов".
Если что, я сам не уверен, что раст взлетит, более того — в нём есть немало раздражающих меня моментов. Тем не менее, внимания язык получает достаточно. Хотелось чтобы хоть какую-то нишу он занял, благо положительных моментов тоже хватает.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, gandjustas, Вы писали:
G>>
G>>handler?.Invoke(this, new SomeEventArgs());
G>>
KV><skipped> G>>Просто? Вроде да. Почему в Nemerle не предлагали такой паттерн еще 5 лет назад?
KV>Почему же не предлагали? Предложили, причем ровно 5 лет назад, день-в-день: https://github.com/rsdn/nemerle/commit/5d6470347342ec2b9d054305dff3cc64849d9881
А где там событие? Я же писал про кейс, а не про фичу языка?.
KV>Чего еще по твоему мнению не предлагали в Nemerle?
Ничего из того, что предлагает c#. Потому что c# делает фичи под конкретные сценарии, а не просто чтобы были.
Здравствуйте, VladD2, Вы писали:
VD> Ну, ди ладно. Он совсем не похож на плюсы. Но Nemerle — это по сути правильно спроектированный C#. C# в котором устранены некоторые проблемы, добавлена отличная поддержка ФП и реализовано МП/DSL-естроение.
Как по мне, так с D/C++ точно так же. Разве что с поправкой, что с момента появления плюсы успели немного наверстать. Ну и плюс ГЦ.
Здравствуйте, gandjustas, Вы писали:
G>Конечно не смотрел, коммит три часа назад был
И дифф ты тоже не смотрел.
Всё что я сделал это выпилил зависимость от не нужной ДЛЛ.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
более правильный вариант предложил — смотреть на количество вакансий в разных городах мира. Только странные выводы сделал, потому как ни Скала, ни тем более этотй твой Elixir, к мэйнстриму отношения не имеет.
Ну это же не абсолютные значения, а пороговые.
Одна-две вакансии в стране — случайность, пять-десять — эксперимент, сотня и больше — язык используется в реальных проектах. Мало и «избранными», но используется (т.е. ты можешь уже а) найти работу и б) сменить её).
10-20 репозиториев на гитхабе — случайность, до сотни — эксперимент; тысячи — значит у языка есть сообщество, давно уже не состоящее только из его создателей.
Аналогично с результатами в гугле: важна не конкретная цифра (и поэтому тиоба — в большой степени бессмысленная штука), а то, что введя «%langname% programming» ты увидишь результаты и на слайдшаре, и на реддите, и туториалы «учим Nim за 5 минут» и статьи «ваш Nim говно, и вот почему...», и тег на стековерфлоу и т.д.
То, что всего этого у Nemerle нету — естественно, НЕ вина его разработчиков, но их беда.
И лично мне например очень интересно «что в таких случаях делают». Об этом я и пытаюсь говорить.
Естественно, если взять за пороговое значение количество программистов на PHP, то вполне очевидно, что до этой планки не допрыгнуть (по крайней мере, в один прыжок). Но утверждать, что кроме этой планки/уровня, других не существует (а значит, все остальные языки кроме топ-5, будь то Руби или Эликсир, находятся на «примерно одном уровне, том же где и Немерле») — это, мне кажется, немножко пораженчество всё же.
То есть, ну, если есть лестница «распространённости» из ста ступенек, где немерл условно на второй, эликсир — на восьмой, скала — на тридцатой, руби — на пятидесятой, питон на шестдесят пятой, джава — на восьмидесятой, с++ — на восемьдесят пятой, .... — то, ну да, со второй на восемьдесят пятую непонятно как (кроме как на вертолёте за миллиард долларов). А на десятую хотя бы почему бы не влезть?..
О каком событии идет речь и какие кейсы не покрывает в данном случае Nemerle по сравнению с C#?
KV>>Чего еще по твоему мнению не предлагали в Nemerle? G>Ничего из того, что предлагает c#. Потому что c# делает фичи под конкретные сценарии, а не просто чтобы были.
Ты это уже говорил выше, но на конкретные примеры увы поскупился. Да и с .? у тебя как-то неудобно получилось. Другие примеры того, что предлагает язык C#, но не предлагает языка Nemerle, озвучишь или признаешь, что погорячился?
Здравствуйте, VladD2, Вы писали:
VD> AB>Как вы ее устраните? Избавитесь от mono? VD> Есть разные пути. Можно использовать https://github.com/dotnet/core , который становится все больше пригодным для использования.
Нельзя
VD> Можно сделать нативный бэкэнд на базе какого-нибудь LLVM. VD> Можно сделать бэкэнд для Явы. VD> Но все это не хилые трудозатраты.
Ну если верить "рекламе", язык N как раз и предназначен для подобных вещей — пусть он сам себя и оттранслирует на Java / C++ / etc — лучшая реклама языку, ИМХО.
VD> А, те кто сейчас отмахивается приводя этот фактор просто найдут еще одну причину и все равно не будут даже смотреть на язык.
Для того, чтобы на продукт хотя бы хотели посмотреть, нужно избавиться от "блокеров" (.NET / mono / windows / неработающий сайт / несобирающийся из за бага в моно компилятор — это все блокеры, которые однозначно не способствуют интересу к языку).
VD> Если бы было желание разобраться и появилась бы заинтересованность, то люди сами предложили бы заняться созданием нативного бэкэнда или бэкэнда на яве.
Современный OpenSource сильно избалован большим количеством качественных продуктов — не они должны заинтересовываться, а их нужно заинтересовывать. Недостаточно просто выложить исходники — таких исходников полный github.
VD> VD>> К тому же то что Немерл — это тольков Виндовс — это не совсем правда. Есть еще NemerleWeb — крутейший веб-рфеймворк. VD> AB>И для того, чтобы он работал, опять нужна Windows (ну это безотносительно качеств самого фреймворка). VD> Для того чтобы написать код — да.
Ну т.е. опять уперлись в Windows-only — никто не будет добавлять лишнюю сущность при разработке под веб, если продукт не под винду (а это в большинстве случаев именно так).
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, gandjustas, Вы писали:
KV>>>Почему же не предлагали? Предложили, причем ровно 5 лет назад, день-в-день: https://github.com/rsdn/nemerle/commit/5d6470347342ec2b9d054305dff3cc64849d9881 G>>А где там событие? Я же писал про кейс, а не про фичу языка?.
KV>О каком событии идет речь и какие кейсы не покрывает в данном случае Nemerle по сравнению с C#?
Ты не понял. Мс предлагает фичу для решения конкретных проблем. Nemerle предлагает фичу просто потому что её можно сделать.
KV>>>Чего еще по твоему мнению не предлагали в Nemerle? G>>Ничего из того, что предлагает c#. Потому что c# делает фичи под конкретные сценарии, а не просто чтобы были.
KV>Ты это уже говорил выше, но на конкретные примеры увы поскупился. Да и с .? у тебя как-то неудобно получилось. Другие примеры того, что предлагает язык C#, но не предлагает языка Nemerle, озвучишь или признаешь, что погорячился?
Я показал конкретный пример с событием, почему у немерле 5 лет назад не было этого примера? фича-то была. Просто никто из авторов не думал о применении фичи. Потенциальные пользователи точно не будут думать о таком.
Здравствуйте, VladD2, Вы писали:
ГВ>>Правильно. Потому что работа инженера на 9/10 — согласования-согласования-согласования. И хоть что хочешь делай, но воткнуть в такой процесс новое, малоизученное средство — задача совсем не тривиальная.
VD>Что мешает изучить новое средство? Тем более, что дотнет и ява абстрагируют от вопросов совместимости и позволяют спокойно вставлять в процесс модули созданные на других языках.
Изучить не мешает ничего. Вопрос и проблема в другом: помимо одного энтузиаста этот же язык должны изучить его коллеги, а у них запросто может быть своё мнение относительно правильного языка, да ещё и у каждого — своё. В корпоративном контексте сюда примешивается необходимость согласовать использование нового языка с начальством/сервисными службами/whatever. Это и есть "процесс" — сумма регламентов, порядков, норм, правил и т.п.
И тут, понимаешь ли... Никто в здравом уме и трезвой памяти не начнёт писать какой-то долгоживущий проект на новом, пусть и распрекрасном языке, если нет уверенности в том, что:
— Всегда найдутся люди, знающие этот язык или способные быстро начать на нём писать (забавно, но ты сам говорил в своей презентации, что систему макросов нужно поизучать несколько месяцев, чтобы что-то там приличное написать);
— Владелец языка не забросит его (см. сообщения Mamut-а, там всё сказано яснее ясного);
— Язык не изменится каким-нибудь очень специфическим образом (а кто вас знает, то об N2 разговоры, то ещё какие-то революции на уме);
— Библиотеки будем писать не только "мы", но их уже кто-то делает и будет делать в будущем.
...и т.п. Короче, ничего нового, о чём бы не говорили раньше. Одного-то человека сложно убедить в преимуществах нового языка, а в случае компании таковая сложность растёт многократно. Ну и добавь сюда, что даже если программист увеличит свою производительность на порядок, это на зарплате порой не скажется, аж никак.
Короче говоря, изучить не мешает ничего. А вот применять может мешать очень многое, притом выгоды могут оказаться очень призрачными. Отсюда люди и не спешат вставлять новые языки и в продукты, и в процессы. Банальная рациональная позиция, а не какая-то "тупость".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
J>Я правильно помню, что вы RSDN планировали переписать на нем? Если да, то как успехи? Был бы killer app: здоровый сайт с развесистой логикой написан на всего ничего кода на Немерле, офигевайте.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не пользоваться же тем, что работает на совершенно не подходящей платформе. EP>...Ещё раз, мне в первую очередь не нужен .NET, а Nemerle уже как следствие из этого.
Ну, ты же пользующийся Шарпом? Пусть для мелочевки, но ведь пользуешся?
VD>>Если отбросить метапрограммирование, то не очень то там много преимуществ по сравнению с дженериками дотнета.
EP>Много + higher-rank polymorphism.
А, для чего ты его на практике (без метапрограммирования) использовать можешь?
VD>>Разве что иногда можно получить более оптимальный код и операторы использовать.
EP>"иногда" — это ты сильно лукавишь,
Ничего я не лукавлю. Проблемы с дженериками реально появляются только, если хранятся вэлью-типы (особенно предопредеделные) и над ними нужно выполнять некие операции которые невозможно описать через констрэйны дженериков (не выражаются в виде интерфейсов). Там, да, приходится таскать с собой лямбды обобщающие вычисления.
EP>либо совершенно не представляешь масштаб. Например C++ скомпилированный в JavaScript (!!!) оказывается в два раза быстрее
А, это не более чем вопрос кодогенерации.
EP>Опять лукавишь. Лямбды/замыкания в C++ лучше зоопарка из C#, могут больше (полиморфные лямбды), и работают быстрее.
Ни фига они больше не могут. Полноценных замыканий нет. Так что или все в рэйдонли, или следи за временем жизни сам. Плюс убогий синтаксис убивающий всю выразительность.
Что до полиморфности, то в Немерле тоже можно сделать полиморфную лямбду. Только по жизни это совершенно не нужно.
VD>>Не натягивай сову на глобус. "type erasure" — это термин из Явы.
EP>type erasure это общий термин, не ограниченный Java'ой.
Приведи мне ссылку на стандарт C# где бы использовался этот термин или его аналог. Ты что-то себе выдумал или не понимаешь значения этого термина. В дотнете все типы жденериков хранятся в метаданных. Никакой потери информации не случается.
VD>>В дотнете его нет.
EP>Есть — сохранение лямбды в Func<...> — это и есть стирание конкретного типа лямбды.
Что за чушь?
EP>И методы компилируются под этот стёртый тип. В то время как в C++, принимая лямбду через шаблон — мы получаем всю информацию необходимую для инлайнинга.
Это никакого отношения к стиранию типов не имеет. Иначе наследование и полиморфизм — это тоже стирание типов.
А, для инлайниннга нужно просто иметь исходник (вернее его AST). В дотнете это вполне возможно, так как код тоже является метаданными и может быть довольно качественно восстановлен из байткода. Плюс инлайнинг возможен на уровне байткода.
Скажем имеем код вроде:
var lst = [1, 2, 3, 4, 5];
var result = lst.Where(x => x % 2 == 0).Sum();
Идет и декомпилируем код
public static IEnumerable<TSource> Where<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
foreach (x in source)
if (predicate(x))
yeild return x;
}
public static int Sum(this IEnumerable<int> source)
{
foreach (int current in source)
num += current;
return num;
}
Делаем анализ, что ссылка на predicate локальна для метода и принимаем решение инлайнить. Получаем:
int result = 0;
foreach (x in source)
if (x % 2 == 0)
result += current;
Другое дело когда ссылка на лямбду пришла из другой библиотеки скомпилированной бинарно и недоступной на момент компиляции. Но, тут и С++ ничего сделать не может.
EP>Передавая две разные лямбды в один и тот же шаблон функции — мы получаим разные воплощения этого шаблона, с разными адресами.
Ну, и тут тоже самое можно делать. Только не париться с ограничениями и кривым синтаксисом.
EP>Если же стирать тип в C++ (например через std::funciton) — то инлайнить такой код точно также намного сложнее.
Это не стирание типа. Ты неверно термин понимаешь. Это всего лишь приведение к абстрактному типу. Тип ничего не значит для инлайнинга. Для него важно наличие кода который можно трансформировать во время компиляции. Если просто сделать специализацию с менее абстрактным типом, то код намного быстрее не станет. Вот если произвести инлайнинг, тогда — да. Но для него нужны не типы, а наличие AST-а.
VD>>Места затрудняющие оптимизации есть, но их не много.
EP>Да они практически пронизывают весь язык.
Это домыслы. Например, для типов в типы параметров которых подставлены вэлью типыавтоматом компилируются специализации. Но, как я уже говорил, это не тоже самое, что инлайнинг.
VD>>Те же лябды не инлайнят не потому что нельзя, а потому что руки до оптимизаций подобного рода не доходят.
EP>Их можно инлайнить, но это намного сложнее.
Я выше показал. Ничего сложного в этом нет. Главное произвести анализ локальности для лямбды переданной в качестве параметра. Если она нигде не "прикапывается", значит можно инлайнить.
VD>>Дотнет все же далет одна команда в Рэдмонде, а С++-ом занимаются вот уже 30 лет десятки команд по всему свету.
EP>Вообще не аргумент — Clang появился позже .NET, и он уделывает C# код даже при компиляции в JavaScript
Это уже демагогия. По жизни грамотно написанный код на дотнете работает не сильно медленее чем тот же на любом супер-оптимизирующем компиляторе. Где-то даже быстрее выходит. Но развивать эту тему мне скучно. Очередной срач получится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alex_public, Вы писали:
_>А здесь речь шла уже не о целевых ОС, а именно о программной платформе. Причём в контексте количества программистов. Вот смотри, если взять разные оценки аудиторий (TIOBE, github и т.п.), то в среднем получаются приблизительно такие цифры:
Не надо их брать, так как это полная чушь, а не цифры. Нельзя по запросам строк судить по частоте использования языка. Как-кой нибудь идиот нагенерит 100500 директорий с именем языка и внезапно получается, что Скала популярнее Шарпа.
_>Смотри, Nemerle нацелен на определённую нишу, а именно на использование возможностей МП.
А, С++ нацелен на использование МП?
Ну, какого хрена загонять язык общего назначения в нишу "использование МП"? Язык по всем критериям лучше C#. Если исключить тулинг, то трудно найти код который бы оказался бы кратче или красивее будучи написанным на Шарпе.
Но, почему-то ниша Шарпа, по твоему, шире чем ниша Немерла.
_>Но само по себе МП — это довольно сложная штука, которая интересует весьма небольшой процент программистов.
И? МП на шаблонах еще более сложная и невнятная штука. Как это тебе мешает использовать Буст и другие библиотеки?
_>Ну скажем каждый пятый в среднем, т.е. уже видна узость ниши...
Уже видно натягивание совы на глобус.
Смотри на мир правильно. Немерл — это C# + МП + DSL-и, плюс расширения языка в виде библиотек.
Какого фига "+" мы рассматриваем как сужение ниши?
_>Но это на самом деле не верные вычисления
Абсолютно согласен!
_>В то время как платформы Java и .Net ориентированны в первую очередь на внутрикорпоративную разработку
И, что? Это заставляет людей отказаться от автоматизации своего труда и повышения уровня кода?
Плюс это не совсем так. На дотнете и яве пишут различнийший софт. Тот же ReSharper и IDEA тому отличный пример. Вы бы назвали эти задачи "системными".
_>с соответствующей ориентацией на использование не самых высокоуровневых разработчиков.
Не самых выдающихся, может быть? Они как раз самые что ни на есть высокоуровневые, так как работают с очень высокоуровневыми моделями. И они как никто другой нуждаются в автоматизации.
_>Кстати говоря, это совсем не минус этих платформ, а как раз их главное преимущество. Только вот с точки зрения распространение МП на них это весьма печально... Сомневаюсь, что даже каждый десятый тут хорошо знаком с концепцией МП.
Да, во всю там МП используется. Мало кто хочет выписывать классы для того же ORM руками.
_>В итоге получаем что если бы Немерле был нативным, то теоретически мог бы заинтересовать каждого десятого разработчика. А при текущем выборе .net'a он хорошо если каждого сотого заинтересует. Надо ли пояснять, что означают такие цифры с точки зрения маркетинга? ) _>P.S. Понятно, что все эти цифры условные. Но я думаю ты прекрасно понимаешь, что реальные цифры всё равно уложатся в описанные тенденции.
Цифры эти не верные. Верно только, что если бы язык охватывал бы больше платформ, то и вероятность заинтересовать больше программистов была бы больше.
Я бы с удовольствием перевел бы немерл на все существующие платформы, но как ты понимаешь, это не простое и не бесплатное удовольствие.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
KV>>О каком событии идет речь и какие кейсы не покрывает в данном случае Nemerle по сравнению с C#? G>Ты не понял.
Возможно, но на всякий случай обновил пример с событиями на сайте: http://www.nemerle.org/About#ID0EIH
G>Мс предлагает фичу для решения конкретных проблем. Nemerle предлагает фичу просто потому что её можно сделать.
Это не так. Могу заверить, что фичи, добавляемые в Nemerle, всегда решают конкретную проблему. В противном случае, они просто не добавляются или улетают в Snippets.
G>Я показал конкретный пример с событием, почему у немерле 5 лет назад не было этого примера? фича-то была. Просто никто из авторов не думал о применении фичи. Потенциальные пользователи точно не будут думать о таком.
Здесь вынужден согласиться со всем, кроме выделенного. Разумеется, авторы думали о применении фичи (собственно, конкретно .? заимствован у Groovy и было бы странно со стороны ее авторов не знать, какие проблемы он решал в том языке). Но только лишь думать и реализовывать здесь мало, нужно работать с сообществом, показывать примеры, регулярно сообщать новости, планировать выступления на конфах, вести сайт и т.п. Этим тупо некому заниматься и здесь я не оправдываюсь, а просто констатирую факт. Увы.
Здравствуйте, alex_public, Вы писали:
_>Тут пропущены требования на быстродействие, а они сильно сужают спектр задач, причём с обеих сторон.
Снобское отношение С++-ников к производительности дотнет-кода — это отдельная тема. По жизни задачи вроде ReSharper-а, IDEA или Eclipse (т.е. высоко интеллектуальные IDE с мощными языковыми сервисами) предъявляют строжайшие требования к производительности, но по жизни сервисы IDE, а теперь и сами IDE пишут именно на управляемых языках.
Так вот, лучше оставить вопросы производительности за бортом. Те же шарпы и явы используют миллионы (чаще чем С++). Значит с аудиторией все ОК.
_>Если требований на быстродействия нет вообще, может быть гораздо эффективнее встроить в приложение высокоуровневый скриптовой язык. Это очень сильно повышает продуктивность (не говоря уже об отсутствие необходимости перекомпиляции и возможности сложной настройки самими пользователями).
Да, ни фига это не повышает производительность того кто пишет на нормальном языке. Уровень кода на Немерле не ниже сктиптового. Это по сравнению с С++ там какой-то выигрышь. Разве что изменять код интерактивнее получится.
Короче, все те же споры пошли по кругу. Причем один в качестве аргумента приводит довод, что неудобно в одном проекте использовать два очень близких языка (Шарпа и Немерле), а другой ратует за внесение в проект совершенно разных языков и за перенос контроля типов на рантайм.
_>Если же требования на быстродействие очень высокие, то Немерле уже просто не подойдёт из-за ограничений .net'a.
Чушь это. Но спорить не хочу. Надоело. Просто ответь себе на простой вопрос. Почему люди пишут на том же Шарпе и Яве вещи дико критичные к скорости (вроде упомянутых IDE).
_>Т.е. в итоге получается что Немерле для сложных задач с наличием требований на быстродействие, но не очень серьёзных. И при этом ещё и обязательно чтобы без GUI и нельзя писать под мобильные платформы. Тебе не кажется, что ниша получается мягко говоря узковатой? )
Снобизм у вас, у сиплюсплсников серьезный. Отсюда и выводы неверные. В серьезных задачах скорость достигается не за счет битовыжимательных способностей языка, а за счет грамотно организации кэшей и их инкрементальный обновлению. Важно, только чтобы отставания от битовыжимателей не было в разы. Вот именно это и происходит.
Вот где дотнет и явва сливают — это в области рачительного использования памяти. Тут, да. Альтернативы ручному выделению памяти нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
