Здравствуйте, 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;
}
моё сообщение, но при этом ни один не смог представить ни одного аргументированного возражения. В общем то совсем не удивительно...
В этом обсуждении я тут скорее "на твоей стороне", да и фанатом немерле никогда не был. Но с утверждением "дотнетовские либы так же (не)удобны для немерле как сишные для плюсовых" не согласен. Я бы скорее с С++03/С++11 сравнил. То есть — кое-что (пусть даже многое) стало удобнее, но с использованием "старых" либ никаких проблем нет, ведь многие неудобства спрятаны внутри реализации.
Ну и ещё немного офтопа — чем тебя свифт зацепил ума не приложу. По моему, унылый язычок, сравнивать его с Д/Растом/Немерле не стал бы. Всё, что у него есть — это поддержка. Другое дело, что этого, в данном случае, достаточно...
Если что я "болею" именно за раст.
Re[58]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, 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>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[58]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, 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) явно не могут перекрыть эту нишу именно в силу ограничений платформы.
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, jazzer, Вы писали:
J>Оно, конечно, так, но важнейщей фичей С++ на ранних порах была именно совместимость с Си и то, что из С++ можно напрямую использовать сишные библиотеки. J>Так что тут Немерле по отношению к C# (вернее, к .NET) ровно в такой же позиции.
Так я именно про это и говорю, что ситуация полностью аналогичная. И соответственно пока на Nemerle не напишут свой "Boost", говорить о развитых библиотеках странно.
J>И обрати внимание, с теми же граблями. J>Как С++ никак не может отделаться от "плохих" сишных вещей из-за требований совместимости, которая изначально его продвинула, так и Немерле остается привязанным к дотнету и плакала его кроссплатформенность.
Видимо зависит от уровня этой совместимости. Т.к. скажем D, Rust, Swift без проблем работают с C библиотеками, но при этом внутри у них нет никаких намёков на "ужасы C". )
J>Хотя у обоих языков какие-то шансы вырваться есть. У Немерле — упрятать все еще один слой макросов, который инкапсулирует дотнет (тут я не копенгаген, но то, что я помню из статей Влада про макросы Немерле, было сильно завязано на рефлексию дотнета). У С++ — ты и сам в курсе как последних, так и планируемых изменений (например, модулей, чтобы наконец выкинуть #include на свалку истории), которые делают древние сишные конструкции либо вообще ненужными, либо явно огороженными проверками времени компиляции.
Для всего этого надо:
1. Целенаправленное желание
2. Ресурсы для реализации
И насколько я вижу у Nemerle и C++ тут совсем разные расклады.
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, 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>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[57]: Nemerle через 5 лет - выстрелит или скончается?
моё сообщение, но при этом ни один не смог представить ни одного аргументированного возражения.
Ты уж меня прости, но я тут отдыхаю в Египте и читаю рсдн с телефона. По сему развернуто отвечать на прстыни текста нет ни возможнести, ни желания. К тому же ты, в своей аргементации, стремительно скатываешься к уровню зверька из известной башни. Ты, наверное, не прохой сиплюсплюсние, но за его пределами, ты явно ничего не видел. Опронировать к твоим абсурдным заявлениям без смеха сложно. Мой тебе совет — ты или освой, как следует, то о чем высказываешься, или просто молчи. А то, твой авторитет стремительно таит в глазах тех, кто разбирается в вопросах.
Еще один совет — по осторожнее с экстрополяцией. Не стоит переносить опыт из С/С++ на другие области и языки. С/С++ имеют кучу проблем вызванных тем, что эти языки одного возраста с говном мамонта.
Например, в мире С++не принято брать чужих библиотек без исходников. Есть проблемы с совмещением разных библиотек. С–шные библиотеки имеют процедерный дизайн и (зачастую) слабую типизацию. В мире дотнета и явы все иначе. Дизай систем и зашитые в них стандарты нацелены на массовое совместное испльзование библиотек. Причем в бинарном виде.
По этому твоя экстрополяцтя опыта использования сишных библиотек на дотнет не верна. Дотнетные библиотеки имеют довольно высокое качество и не требуют пнреписывания для использования в немерле или любом другом языке.
Твои рассуждениия о системности языков на основании наличия в них указателей ничего кроме смеха не вызывает, так как в том же шарпе указатели тоже имеются.
В общем, оппонировать к твоим словам сложно, так как они (если речь идет о чем–то отличном от С++), в основном, является набором домыслов и предрассудков.
Хочешь говорить серьезно? Разберись в технологиях о которых рассуждаешь. Правда, при этом, скорее всего спорить уже будет не о чем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[57]: Nemerle через 5 лет - выстрелит или скончается?
_>Кстати, а вот если бы Nemerle был кроссплатформенным системным языком, то я обязательно бы его
Может ты уже ответишь, как те задачи вы решаете на работе? Зачем тебе "системный" язык и что ты в это вкладываешь, наоми указателей которые есть и в шарпе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
_>Не согласен, т.к. в C++03 уже было МП на шаблонах, пусть и менее эффективное. И в Nemerle МП есть. А вот в C и C# ничего подобного.
Дык, в большинстве бустовых либ МП "внутри". А интерфейс обычный.
Но вообще, я скорее про другое. Между С++ и С разница огромна, а между дотнетовыми либами и немерле такой разницы нет.
Опять же, в дотнете есть много всего "для всех случаев жизни", пусть и "под одну платформу" (условно). Это в С++ ничего такого не было, потому и есть отдельные огромные либы/фреймворки. Это примерно как если бы в стандарте языка был пусть не буст, но какое-нибудь Qt. Придумывать ещё один уровень абстракции поверх? Зачем?
Пишу я на С++, если что.
Re[44]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, 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.
А когда мы стали запускать это в продакшн, все особенности такой архитектуры сразу выбежали на передний план.
К чему это я рассказываю? Да к тому, что под профайлером эту консольку явно не запускали ни разу в жизни. А ведь без профайлера никто в своём уме не полезет менять аллокатор.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, 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) явно не могут перекрыть эту нишу именно в силу ограничений платформы.
Что за ниша то? Какие ограничения то?
Вы тут все драйвера пишите, кодеки или ОСы?
Еще раз спрашиваю — что за софт вы пишите на С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[60]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, 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 обменяться, а не напрягаться с построением чужих библиотек).
Re[58]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Ты уж меня прости, но я тут отдыхаю в Египте и читаю рсдн с телефона. По сему развернуто отвечать на прстыни текста нет ни возможнести, ни желания. К тому же ты, в своей аргементации, стремительно скатываешься к уровню зверька из известной башни. Ты, наверное, не прохой сиплюсплюсние, но за его пределами, ты явно ничего не видел. Опронировать к твоим абсурдным заявлениям без смеха сложно. Мой тебе совет — ты или освой, как следует, то о чем высказываешься, или просто молчи. А то, твой авторитет стремительно таит в глазах тех, кто разбирается в вопросах.
Вообще то на простыни текста тебя как раз хватает. Только твои простыни стараются держаться подальше от обсуждения собственно профессиональных вопросов, которые затрагиваю я, и упорно пытаются перейти к обсуждению моей личности. ) Догадываешься какие из этого следуют выводы? )
VD>Например, в мире С++не принято брать чужих библиотек без исходников. Есть проблемы с совмещением разных библиотек. С–шные библиотеки имеют процедерный дизайн и (зачастую) слабую типизацию. В мире дотнета и явы все иначе. Дизай систем и зашитые в них стандарты нацелены на массовое совместное испльзование библиотек. Причем в бинарном виде.
У тебя постоянная путаница между C и C++. Про C++ написано верно, а вот C библиотеки как раз частенько передают в скомпилированном виде. Собственно в этом смысле C# как раз ближе к C, чем к C++. А вот Nemerle с его макросами уже ближе к C++, т.к. без исходников просто не выйдет.
VD>По этому твоя экстрополяцтя опыта использования сишных библиотек на дотнет не верна. Дотнетные библиотеки имеют довольно высокое качество и не требуют пнреписывания для использования в немерле или любом другом языке.
Естественно не требуют. Как и C библиотеки не требуют переписывания для использования их в C++ (или D, Rust, Swift и т.п.). Но при таком раскладе у тебя получается использование убогой библиотеки из красивого языка. И соответственно в точке использования ты теряешь все преимущества использования своего красивого языка. Т.е. использовать то безусловно можно, но лучше бы всё же переписать по родному... )
VD>Твои рассуждениия о системности языков на основании наличия в них указателей ничего кроме смеха не вызывает, так как в том же шарпе указатели тоже имеются.
Не забудь ещё отправить в топку обязательный сборщик мусора и посмотрим что останется от C#. )
VD>В общем, оппонировать к твоим словам сложно, так как они (если речь идет о чем–то отличном от С++), в основном, является набором домыслов и предрассудков.
Любые домыслы легко опровергаются тестовыми примерами или ссылками на спецификации. Но я уже понял что от тебя мы дождёмся только очередного обсуждения моей персоны, но никак и не кода/документации.
Re[60]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
J>>Так что тут Немерле по отношению к C# (вернее, к .NET) ровно в такой же позиции.
Для кроссплатформности есть Моно. Не венец твореня, но говоря, что кросплатформности нет человек явно лукавит.
_>Так я именно про это и говорю, что ситуация полностью аналогичная. И соответственно пока на Nemerle не напишут свой "Boost", говорить о развитых библиотеках странно.
Буст — это библиотека залатывающая дыры стандарта С++. Аналогичные возможности или уже есть в библиотеках дотнета, или она не нужна, так как является костылями для плюсов.
Что, за исключением спорита (превосходящих его аналогов макросов сразу два) , есть в тесте, что нет в библиотеках дотнета или в самом дотнете? Только конкретно.
_>Видимо зависит от уровня этой совместимости. Т.к. скажем D, Rust, Swift без проблем работают с C библиотеками, но при этом внутри у них нет никаких намёков на "ужасы C". )
Все языки дотнета отлично работают с С–библиотеками даже без ансейфа. Кури interop. Этому в дотнете посвящено очень многое. В Шарпе и Немерле еще можно и указатели использовать.
У Раста совместимость с С не лучше. У Свифта (судя по бокам) кроме указателей и импорта простых дефайнутых констант ничего и нет. С Ли все по веселее, но тоже примерно на том же уровне.
Ну, и как и в случае с С++ сишные либы будут выглядеть убого без оберток. Так что смысл их использования исчезающе мал.
_>Для всего этого надо: _>1. Целенаправленное желание _>2. Ресурсы для реализации
А можно узнать реализации чего ты ждешь?
_>И насколько я вижу у Nemerle и C++ тут совсем разные расклады.
А можно о расскладах по по подробнее?
Вот нормальная IDE для плюсов за 30 лет уже появилась?
А когда буст.спирит дотянет хотя бы до немерле.ПЕГ? А когда Qt дотянет до WPF?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[60]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, DarkEld3r, Вы писали:
DE>Дык, в большинстве бустовых либ МП "внутри". А интерфейс обычный.
Мммм оно может быть и внутри, но работает в процессе сборки приложения, а не библиотеки. Т.е. требуется именно компилятор с шаблонами для сборки самого приложения — не получится собрать библиотеку, а потом использовать её в компиляторе без шаблонов. И как я понимаю у Nemerle аналогичная ситуация.
DE>Но вообще, я скорее про другое. Между С++ и С разница огромна, а между дотнетовыми либами и немерле такой разницы нет.
Для того, чтобы так говорить, надо в начале глянуть на канонические (с полноценным использование макросов и т.п.) библиотеки Nemerle. Т.е. посмотреть на какой-то местный аналог Boost'a. Что-то мне кажется, что там код будет весьма отличаться от обычного C#.
DE>Опять же, в дотнете есть много всего "для всех случаев жизни", пусть и "под одну платформу" (условно). Это в С++ ничего такого не было, потому и есть отдельные огромные либы/фреймворки. Это примерно как если бы в стандарте языка был пусть не буст, но какое-нибудь Qt. Придумывать ещё один уровень абстракции поверх? Зачем?
. Понятно что при самом старте языка использование готовой чужой инфраструктуры — это абсолютно правильное решение. Собственно C++ так и поднялся на базе C. Но со временем обязательно надо создавать свою инфраструктуру.
Re[61]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
DE>>Дык, в большинстве бустовых либ МП "внутри". А интерфейс обычный. _>Мммм оно может быть и внутри, но работает в процессе сборки приложения, а не библиотеки. Т.е. требуется именно компилятор с шаблонами для сборки самого приложения — не получится собрать библиотеку, а потом использовать её в компиляторе без шаблонов. И как я понимаю у Nemerle аналогичная ситуация.
В Nemerle библиотека с макросами — это фактически плагин к компилятору, распространяемый в виде динамической библиотеки (бинарной).
Re[45]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, 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>К чему это я рассказываю? Да к тому, что под профайлером эту консольку явно не запускали ни разу в жизни. А ведь без профайлера никто в своём уме не полезет менять аллокатор.
В данном случае и профайлер не нужен был. Скорее вопрос к организации тестирования ПО. )
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
_>Вообще то на простыни текста тебя как раз хватает.
К сожалению, нет. И твои простыни тут не в одиночестве.
Попробуй ответить хотя бы на одно сообщение с телефона.
_>Только твои простыни стараются держаться подальше от обсуждения собственно профессиональных вопросов, которые затрагиваю я, и упорно пытаются перейти к обсуждению моей личности. ) Догадываешься какие из этого следуют выводы? )
Когда я виде некомпетентнось и домыслы, то так и говорю. По началу твои сообщения выглядили достойно, но сейчас уже вызывают смех.
VD>>Например, в мире С++не принято брать чужих библиотек без исходников. Есть проблемы с совмещением разных библиотек. С–шные библиотеки имеют процедерный дизайн и (зачастую) слабую типизацию. В мире дотнета и явы все иначе. Дизай систем и зашитые в них стандарты нацелены на массовое совместное испльзование библиотек. Причем в бинарном виде.
_>У тебя постоянная путаница между C и C++. _>Про C++ написано верно, а вот C библиотеки как раз частенько передают в скомпилированном виде.
Во как? А может ты читаешь плохо или фантазия у тебя разыгралась? А ну–ка покажи где я утверждал, что сишные библиотеки передаются только в исходниках?
Я говорю о том, что ваши тараканы не приминимы к другим мирам.
И ты уже малость задрал мне рассказывать о моем плохом знании С++. Давай лучше поговорим о твоей почти полной не компетенции в области дотнета, который ты тут критикуешь и котором ты здесь делаешь заявления.
_>Собственно в этом смысле C# как раз ближе к C, чем к C++.
Шарп далек от них обоих, так как имеет полноценный бинарный модульный формат и отличную стандартную библиотеку. Да и не Шарп, а дотнет, т.е. все его языки.
_>А вот Nemerle с его макросами уже ближе к C++, т.к. без исходников просто не выйдет.
Это ты тоже от незнания говоришь. (ну как тут не говорить о твоей компетенции?)
У немерла есть библиотеки, которые обратно совместимы с дотнетными и есть макро–библиотеки, которые уникальны для немерла. Так вот, библиотеки дотнета являются для немерла родными. Никаких приседаний для их использования делать не надо. Аналогия с С/С++ не верна. И об этом тебе сказали даже ярые противники немерла (и мои).
_>Естественно не требуют. Как и C библиотеки не требуют переписывания для использования их в C++ (или D, Rust, Swift и т.п.). Но при таком раскладе у тебя получается использование убогой библиотеки из красивого языка.
Это ты экстраполируешь свой опыт работы на убогих языках один из которых ты считаешь красивым.
С и С++ имеют разный набор поддерживаемых парадигм. В С нет классов и шаблонов. Естественно это приводит к дизайну либ не свойственному плюсам.
В Шарпе же (на котором пишется подавляющее большинство либ) есть и клаввы, и дженерики и функци высшего порядка. В нем нет только макросов и не принято писать код в функциональном стиле. Это усложняет написание кода, но этотне проблема для их использования.
_>И соответственно в точке использования ты теряешь все преимущества использования своего красивого языка.
Ничего я не тиряю. Наоборот, иногда там где на шарпе использование либ бывает громоздко, на немерле оно становится элегантно из–за ивпользования макр или фич языка.
Например, для библиотеки xlinq в немерле есть макра позволяющая описывать хмл квази–цитатами хмл–я, а не в виде иерархии объектов (АСТа).
_>Т.е. использовать то безусловно можно, но лучше бы всё же переписать по родному... )
Это твои домыслы.
_>Не забудь ещё отправить в топку обязательный сборщик мусора и посмотрим что останется от C#. )
Его не надо никуда отправлять. Указатели работают паралельно с ним. Просто безопасность кода снижается.
Боле того для совместимости с С—либами доже указатели не нужны. Дотнет позволяет проецировать сишные структуры данных на свои.
_>Любые домыслы легко опровергаются тестовыми примерами или ссылками на спецификации.
Их очень много. Мне за твое образование не платят. Да и как домысел вроде "в немерле дотнетные библиотеки не родные и их нужно переписать, потому что я имел опыт с С и С++ говорящий об этом" можно опровергнуть ссылкой? Это очевидный бред, но очевидно он только тем кто серьезно использовал, хотябы, шарп. Рассказывать кучу мелких деталей устройства дотнета, чтобы переубедить одного некомпетентного человека — явный оверкил.
Так, что или ты слушаешь и веришь компетентным в вопросах людям, или идешь изучать матчасть самостоятельно. Третьего не дано. Ты же продолжаешь обосновывать одними домыслами другие.
_>Но я уже понял что от тебя мы дождёмся только очередного обсуждения моей персоны, но никак и не кода/документации.
Я незнаю как эфимерные понятия и домыслы опровергать документацией.
По поводу "системности" языка я попросил от тебя определение. Ты сказазал, что системный язык — это язык с указателями. Я тебе ответил, что они есть в шарпе и немерле.
Казалось бы вопрос исчерпан, но ты продолжаешь гнуть линию не приводя ни одного разумного аргумента. Не считать же чешь вроде "Не забудь ещё отправить в топку обязательный сборщик мусора" аргументом? С какого перепуга надо выбрасывать сборщик? Как это опровергает факт поддержки указателей в дотнетных языках?
В общем, ты или меняй свое определение системности на "не использует сборщик мусора", или просто признай, что не прав.
Я уверен, что не признаешь. А ведь факт не опровержимые я тебе привел уже давно. Есть минимум две ОС написанныз на языках с ЖС: Сингулярити и Оберон ОС. Более системных задач чем написание ОС я не знаю. Но ты продолжай спорить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, alex_public, Вы писали:
_>Превозносить безусловно можно. Но это уже не будет зазнайством, в котором ты меня обвинил. ) Кстати, а вот когда ты говоришь аналогичное про Nemerle, то...
Собственно проблема не в том, что ты превозносишь плюсы. Проблема в том, что ты, при этом, надменно и снисходительно относишся к другим. Это ошибка. Все остальные твои рассуждения — ее следствие.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
