Здравствуйте, Андрей Хропов, Вы писали:
HT>>>>4) Имеет сходный с C++ синтаксис (чтобы быстро перейти на него) VK>>Не имеет. В синтаксисе Nemerle нет практически ничего общего с C++. АХ>-1. С# — родитель Немерле, а С++ — родитель С#, следовательно, прародитель Немерле.
Это из серии докапаться до слов. Ежу же очевидно, что он имел в виду, что шаблоны С++ дико долеки от идиом Немерла. Тут я сним согласен.
Проблема только в том, что автор вопроса не понимает, что его тербования определяются узостью его кругозора.
Если бы он знал о макросах, то возможно он понял бы, что возможностей дженериков за глаза хватает для обобщенного программирования, а для мета-программирования нехватает возможностей шаблонов С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
[поскипано] HT>>1) Позволяет использовать шаблоны классов/функций HT>>2) Имеет быстрый компилятор (Хочу компиляции секунды,а не минуты!) HT>>3) Позволяет подключать к себе C/C++ библиотеки HT>>4) Имеет сходный с C++ синтаксис (чтобы быстро перейти на него) HT>>5) Готовые программы не кушают гигабайты памяти и 100% процессора, когда надо сложит 2+2
[поскипано] VD>Ну, что я говорил? Вот первый же товаришь сразу потребовал от Ди итеропа с С++. VD>Мой тебе совет. Изучи что-то кроме С++.
Изучить это хорошо. Еще лучше, если можно будет на данном языке реализовать реальную задачу (от алгоритмов до GUI). Для общего развития, конечно, тоже не плохо, но хочется и практической ценности от языка. VD>Толко не Паскальевские потомки, а действительно что-то другое. Тогда пункты 3-4 отпадут сами собой, пункт 5 покажется тебе фобией, пункт 2 окажется естественным, а пункт 1 вообще не будет тебе интересен, так как есть куда более эффективные и красивые способы решать твои проблемы.
п.4 — не критично, п.3 — только если на NET есть адекватная замена, п.5 — ну посмотрим, по п.1. — эээ придется менять мышление? VD>Лично я рекомендую следующий список: VD>http://rsdn.ru/Forum/Message.aspx?mid=2331260&only=1
Спасибо за ответ, хотелось бы только уточнить по поводу приведенного списка.
1) Есть ли смысл сначала заняться изучением C# и лишь затем переходить к Nemerle (при том, что про .NET только слышал)?
2) Как продолжение первого — Nemerle все же довольно молод(Version 0.9.3), есть ли смысл новые проекты начинать на C# и затем переводить их на Nemerle после стандартизации оного ? Или все-таки Nemerle уже во вполне рабочем состоянии? Обучающие примеры типа Sioux HTPP Server, конечно, посмотрю, но хотелось бы узнать и мнение бывалых.
Здравствуйте, humanist-TPV-, Вы писали:
HT>Большое спасибо всем ответившим Пошел смотреть D и Nemerle.
HT>P.S. Boost, boost... Куда же я без boost, STL, ACE, SObjectizer и мн.др.? Жизнь кончена???
Если интересует жизнь вне .NET, то лучше учить D и Scala.
Что касается D: вместо ACE там планируется Tango. Тем более, что и SObjectizer туда может подтянуться со временем Какие-то вещи Boost-а в D не нужны просто по определению или уже есть равнозначные замены (lazy параметры, bind в стандартной библиотеке, регулярные выражения там же и пр.).
Scala -- это вообще совсем другой мир, в котором благодоря интеропу с Java проблем с количеством библиотек нет в принципе. Единственное, что сам язык на порядок сложнее D. Однако, если будут пожелания о портировании SObjectizer на Scala, то их так же можно обсудить
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, humanist-TPV-, Вы писали:
HT>Изучить это хорошо. Еще лучше, если можно будет на данном языке реализовать реальную задачу (от алгоритмов до GUI). Для общего развития, конечно, тоже не плохо, но хочется и практической ценности от языка.
Ну, вот Nemerle как раз позволяет делать и GUI и алгоритмы. В любом случае окажется полезно для мировосприятия. Ты даже на С++ после этого писать лучше будешь.
O'Caml тоже может оказаться полезнее. Правда после С++ от него будет сильно "ломать".
HT>п.4 — не критично, п.3 — только если на NET есть адекватная замена, п.5 — ну посмотрим, по п.1. — эээ придется менять мышление?
Зависит от языка. В Хаскеле еще как. В Немерле процесс может быть постеменным, да и синтаксис по привычнее глазу. Так что мышление хоть и будет меняться, но не так радикально и боленеенно. Ну, а само по себе изменение мышления — это очень полезно. Ведь старые взгляды никуда не денутся. Просто можно будет смотреть на вещи шире. Если же ты уже во всю используешь STL и Boost, то все будет еще проще. Так как многие концепции близки. Знакомство же со списками типов Александреску и метапрограммированием на шаблонах может помочь еще больше. За одно оценишь касклько эти подходы угловаты.
HT>Спасибо за ответ, хотелось бы только уточнить по поводу приведенного списка. HT>1) Есть ли смысл сначала заняться изучением C# и лишь затем переходить к Nemerle (при том, что про .NET только слышал)?
Если "лишь за этим", то нет наверно. Немерле можно расценивать как C#++ без некоторых ошибок и с расширениями. Но C# может оказаться ползеным с практической точки зрения, так как все примеры под дотнету идут на нем.
HT>2) Как продолжение первого — Nemerle все же довольно молод(Version 0.9.3), есть ли смысл новые проекты начинать на C# и затем переводить их на Nemerle после стандартизации оного ? Или все-таки Nemerle уже во вполне рабочем состоянии? Обучающие примеры типа Sioux HTPP Server, конечно, посмотрю, но хотелось бы узнать и мнение бывалых.
Это зависит от целей. Вообще, что-то начинать чтобы потом переводить имеет мало смысла. Но с точки зрения обучения концепциям дотнета знание C# будет полезно.
HT>P.S. А еще плохо, что книг по Nemerle нет пока.
Естественно. Вот выйдет 1.0. Тогда и о книгах можно будет поговорить. За то комьюнити уже нехилое. Немерловые компиляторщики очень нехилые программисты. Да и на русском вокруг Немерла сплотились довольно одаренные люди.
Что касается возможнсоти использования на практике, то тут так. Компилятор довольно стабилен. К тому же выяснить в чем проблема не сложно на форумах или в конференции. Ответы дают быстро и если проблема в компиляторе, то баги фиксятся тоже быстро. С приходом опыта баги можно даже самому будет править. По крайней мере Я, IT и многие другие это уже делали. Да и не так много багов. Я в последнее время при работе не чувствую проблем. Единственное что... компилятор надо собирать из исходников, потому как баги устранены именно в SVN.
А вот с Интеграцией для VS дела обстоят хуже. Она находится в альфа-версии. Она позволяет работать, но содержит довольно много багов. Со временем и ее доведем до ума.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Я бы порекомендовал D для изучения. Это очень перспективный язык! И на C++ похож.
Ну а если уж совсем приперло именно на С++ проект делать, то в некоторых случаях очень помогают прекомпилед хидеры (на MSVC++ они есть, на gcc не в курсе, наверное тоже имеются). Чтоб ускорить компиляцию достаточно просто в PCH заинклудить буст и стандартные библиотеки. В иотге PCH будет компилиться минуты 2, зато остальные файлы за секунды.
Здравствуйте, humanist-TPV-, Вы писали:
HT>Здравствуйте, коллеги.
HT>В очередной раз компилируя проект с использованием boost и наблюдая за минутами компиляции, подумалось — А есть ли языки в которых такие же возможности (использование статического полиморфизма) сочитаются с быстротой компиляции? HT>Может ли кто-нибудь назвать идеальный язык, который: HT>1) Позволяет использовать шаблоны классов/функций HT>2) Имеет быстрый компилятор (Хочу компиляции секунды,а не минуты!) HT>3) Позволяет подключать к себе C/C++ библиотеки HT>4) Имеет сходный с C++ синтаксис (чтобы быстро перейти на него) HT>5) Готовые программы не кушают гигабайты памяти и 100% процессора, когда надо сложит 2+2
Под эти требования скорее нужен не новый язык, а быстрый компилятор Си++.
Альтернативный механизм статического полиморфизма функций реализован в языках, поддерживающих автоматический вывод типа (type inference). Например в Haskell и Objective Caml. Особенно интересно это сделано в Haskell.
Здравствуйте, humanist-TPV-, Вы писали:
HT>1) Позволяет использовать шаблоны классов/функций HT>2) Имеет быстрый компилятор (Хочу компиляции секунды,а не минуты!)
OCaml + CamlP4 быстрее всех будет.
HT>3) Позволяет подключать к себе C/C++ библиотеки
С C++ напряг.
HT>4) Имеет сходный с C++ синтаксис (чтобы быстро перейти на него)
Нереально. А что, для вас так важен какой-то там синтаксис? Зря, зря.
Здравствуйте, CrazyClown, Вы писали:
CC> Как так? Я думал что Object Pascal, Оберон и Java родители C#. От C++ в нем только то, что можно увидеть внутри unsafe { ... }
Я не знаю что ты углядел в C# из Object Pascal (собственно такого языка больше нет в природе), и темболее из Оберона (разве что компонентность и ООП, что не является ни отличительной черток Дельфи и Оберона), но отрицать то что C# (опосредовано через Яву, а иногда и напрямую) унаследовал не мало черт (особенно синтаксических) у С++ просто глупо.
Фактически идеи ООП, сборки мусора и многие другие были описаны в Simula. С++ скомуниздил их часть (выбросив тот же сборщик мусора), а Ява и Шарп скомуниздили их из С++, а частично и напрямую из Симулы.
Так что заканчивай столь пахабную рекламу Дельфи и Оберона. Эти языки не привнесли ни грамма нового в область проектирования языков программирования. Что собственно не мешает эффектино использовать их на практике.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CrazyClown, Вы писали:
CC> Нереально. А что, для вас так важен какой-то там синтаксис? Зря, зря.
Если хоть немного углубиться в историю развития языков программирования, то этот вопрос даже не вызовет сомнения.
На протяжении всей истории по сути было два доминирующих синтаксиса С-подобный (самый распростроненный) и Алголо/Паскале-продобный. Остальные виды синтаксиса до сих пор являются аутсадерами. Многие даже без доли иронии считают, что наличие С-подобного синтаксиса является обязательным условием чтобы язык мог притендовать на массовое распространение (мэйснстрим).
Так что может и зня, но это факт с которым глупо спорить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.