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

E>>Языку не нужен ни дебагер, ни профайлер, ни класс-браузер, ни еще какая-нибудь приблуда. Языку нужен компилятор или среда выполнения + стандартная библиотека.

ВВ>Извини, но это демагогия.

Не извиню.

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

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

./configure
./make
./make install

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

Средства разработки нужны разработчикам. Большинству разработчиков. Но не языку.

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

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

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

AVK>Здравствуйте, IT, Вы писали:
AVK>Не все так радужно. Как минимум есть еще пара вариантов:
AVK>4. Nemerle так и останется известен в очень узком кругу.
Уже нет.
AVK>5. Когда с его использованием начнут делать большие проекты вылезет какая нибудь доколе неизвестная бяка.
Волков боятся — в лес не ходить.

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

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

E>

E>Например, в K52 была такая обобщенная функция — "повторить операцию N раз". Соответственно, была не нужна специальная команда "Goto line", все обеспечивалось обобщенными средствами. Скажите, можно ли в современном редакторе найти 18-е по счету слово с начала файла? Думаете не надо? А вот надо — это как парадигма в программировании — когда привыкнешь к хорошему, начинаешь критически смотреть на вещи. До сих пор мне подобной простой функции очень не хватает.

E>Так вот в vim команда "повторить операцию N раз" есть! Так же, как и команда "повторить последнюю операцию". Действительно, однажды привыкнув, обойтись без них уже тяжело. И вообще, работа в vim-е иногда напоминает программирование (типа программируешь написание программы). Мне, как заядлому программисту, нравится.

        For i = 1 To 18
            DTE.ActiveDocument.Selection.WordRight()
        Next

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

AVK>>4. Nemerle так и останется известен в очень узком кругу.
_W>Уже нет.

"Огласите весь список, пожалуйста" (с)

AVK>>5. Когда с его использованием начнут делать большие проекты вылезет какая нибудь доколе неизвестная бяка.
_W>Волков боятся — в лес не ходить.

соглашусь

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

E>И как теперь твои слова воспринимать?
E>Речь шла о том, что какой-то безобидный код:
E>

E>namespace X
E>{
E>    using Your.Sugar;
E>    module M
E>    {
E>        f() : void
E>        {
E>            def persistence_marker = 0;
E>            ...
E>        }
E>    }
E>}
E>

E>работал себе нормально до тех пор, пока не обновили версию Your.Sugar, в которой за именем persistence_marker вдруг оказался спрятан синтаксический макрос. И что? Браться за рефакторинг?

Произойдет ошибка компиляции, а что ты ожидал?(кстати почти все макросы которые я приводил содержат в том числе и контроль ошибок, и обычно выводят вполне понятное и читабельное сообщение об ошибке) Ведь persistence_marker это теперь ключевое слово(если это просто имя макроса, то ошибки не будет). Ты ведь не удивляешься если C++ компилятору не понравится что-нибудь вроде int break = 0;

Но у меня есть ряд замечаний и по сути обсуждаемой темы:

Во-первых ты как-то превратно понимаешь термин "синтаксический макрос". В Nemerle практически все макросы можно назвать синтаксическическими(так же как и макросы лиспа и схемы), так как они все могут читать и изменять AST. То, что ты имеешь в виду это не синтаксический макрос, а скорее непосредственное внедрение в логику парсера языка.

Отвлечение от темы:

Есть в Nemerle еще более ужасный ужас — произвольные операторы, переопределение операторов и макро-операторы(вообще работает как убер-переопределение), вот с ними мама не горюй что можно наворотить. Кстати на самом деле существует множество языков с подобными возможностями. Например Prolog или Haskell. Не знаю в чем дело, но на их присутствие никто никогда не жаловался. Возможно потому, что это не так часто используется как ты думаешь и в основном для ряда проверенных временем идиом. Например parser combinators в Haskell или DCG в Прологе.

Есть пара вещей, которые ты возможно не знаешь и потому не берешь в расчет.

1. Сложный макрос не так просто написать и использовать. В C++ ты пишешь макрос непосредственно в единице трансляции и alles kaput, эффект затрагивает весь остальной текст.

В Nemerle ты пишешь макрос обычно отдельно от прикладного кода, компилируешь в отдельную сборку. Т.е. никакого случайного макроса в third-party сборке быть не может(если это не библиотека макросов), конечно если она не не использует весь компилятор Nemerle(и как следствие тащит за собой Nemerle.Compiler.dll, Nemerle.dll, Nemerle.Macros.dll, нехилая зависимость между прочим). Преждая потенциальный вопрос скажу — то, что имена пространств имен могут совпадать в разных сборках это конечно засада, но это неотъемлемая фича.NET. Может быть разработчиком следовало бы пересмотреть модульную систему для макросов.

2. Если ты хочешь написать нечто гарантированно ломающее компиляцию — ты это напишешь. Я думаю даже на C# можно подсуетиться. Там например есть условная компиляция.

3. Даже макросы внедряющиеся в парсер бывают разные. Например custom-модификатор для классов гарантированно не всплывет в параметрах, объявлениях методов или в теле функций.

4. Даже сами разработчики в большинстве случаев не добавляют custom-синтаксис, а ограничиваются лишь обычным макросом и я с ними полностью солидарен.

Я начал писать макросы еще начиная с лохматой версии 0.2x(кстати до сих пор старый код прекрасно компилируется в текущей версии). За это время я написал лишь один макрос с custom-синтаксисом(да, тот самый var) и то это было в начальной стадии ознакомления с языком, просто mutable изначально вызывало отторжение(да и var является мягко говоря более распространенным ключевым словом среди современных языков). Еще я написал пару макро-операторов, только один из которых использую по сей день(не совсем оператор, скорее моя версия лямбды вместо встроенного макроса(не очень краткого) и анонимных функций. выглядит примерно так: x -> x*x, я даже постил этот код, правда под другим аккаунтом).

Остальные эксперименты и хелперы касаются в первую очередь изменения и генерации типов, поэтому custom-синтаксис там как собаке пятая нога. Что есть он, что его нет — ничего это не меняет и особой погоды не делает. Я пришел к выводу, что в большинстве случаев он не нужен. В том числе и макросы над выражениями прекрасно обходятся без специального синтаксиса(т.е. выглядят как вызов функций) и вызывают значительно меньше потенциальных проблем. Если ты считаешь, что это нужно контроллировать на уровне компилятора — поделись мнением с разработчиками, они очень любят получать feedback на свой mailing list. Отвечают они очень быстро и по существу. И кстати ничуть не стесняются вносить улучшения в язык(правда с недавних пор они следят за тем, чтобы не сломать своими нововведениями уже работающий код на Nemerle, т.е. период глобальных переделок уже практически закончился).

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

AVK>>Чего же тогда не ответил на вопрос, какие есть недостатки у Nemerle как языка?

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

Посмотри есть ли у тебя в GAC нэтивный образ Nemerle.Compiler.dll. Я не инсталлировал новую версию, запускал бинарники из дистрибутива исходников(там есть компилятор для осуществления self-бута). У меня он жутко тормозил, пока я через ngen вручную не сгенерировал образы для Nemerle.Compiler.dll и Nemerle.Macros.dll. Правда обрабатывать Nemerle.dll(стандартная библиотека) он вообще отказался. Возможно он JIT'ит его каждый раз при запуске и это сказывается негативно.

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

VD>Так же мне показалось странным, что в метод с параметром типа IList<T> нельзя передать массив типа T[]. Приходится выполнять приведение типов. Что странно при таком мощьном механизме вывода типов что есть в языке. Возможно это баг.

Возможно это пресловутое отсутствие поддержки ковариантности, меня самого жутко раздражает. Тут лучше спросить у самих разработчиков. Может к версии 1.0 что-нибудь придумают.

В общем ничего удивительного в том, что ты это обнаружил, так как это действительно две самых больших проблемы на текущий момент.

А вообще AVK с его скепсисом определенно прав. У меня например совершенно другие цели в отношении этого языка(и соответственно подход к нему) и мне в общем пока все равно приобретет ли он широкую популярность или нет. Если он продвинется дальше экспериментальной фазы хорошо. Если нет, то ничего страшного. Вообще все зависит от разработчиков и от того сумеет ли они создать community. То, что они сделали мне уже кажется большим достижением(особенно учитывая, что это всего лишь кучка польских студентов, а не какие нибудь уберлюдей ). И если они не дай бог добьются какого-то признания и начнут напрямую конкурировать с C#, то индустрии можно только посочувствовать. Она перевернется с ног на голову, а вместо Страуструпа и Андерса "как-там его" мировой знаменитостью в области дизайна языков станет Москаль(в прямом смысле этого слова). Если хорошенько подумать, то не очень веселая перспектива.

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

WP> Уверяю вас, это вовсе не так. Вам просто не хватило способностей для того чтобы перестроить своё мышление.

Почему же тогда, к примеру, Пол Грэхэм, один из великих евангелистов Лиспа, считает, что синтаксис таки нужен (в своих размышлениях об Arc)?

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

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

AVK>Ты? Ничего. А вот если нарисуется какой нибудь очередной Александреску и будет утверждать что вот это нагромождение символов — на самом деле легкочитаемая программа — будет страшно.

Тогда должно быть страшно прямо сейчас. Уже сейчас многие хотят метапрограммирование в .NET, но использовать для этого приходится Reflection.Emit (ну некоторые ещё R# для этого пишут или уже "писали"?...). И вот код для runtime code generation на C# имхо получается гораздо страшнее, чем макросы Nemerle... про отладку я вообще молчу.

Я это к тому, что люди всё равно хотят обобщать и будут это делать любыми доступными средствами. Так что Nemerle даже с точки зрения красоты "кода, генерирующего код" получается гораздо приятнее того же C#.

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

ВВ>>Как грамматика английского языка может быть сложнее в С++ там или в выбенет?
VD>В С++ грамматика С++, а не английского.

А в выбенет — английского значит? Ты или шутишь или я уже не знаю что..
Фича о которой я говорю в выбенет проверяет например грамотность текста написанного в комментариях.

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

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

Да не случится этого, не случится. Те, кто хотят метапрограммирование и прямо сейчас, используют Emit несмотря ни на что. Те, кто этого не хотят (или боятся) — не используют. Такая же ситуация будет и в Nemerle.

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

И то, что в Nemerle этих возможностей больше, никак не может спровоцировать "рассыпание культуры", как это не случилось с теми же C++ (шаблоны) и C# (runtime code generation).

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

_W>

_W>        For i = 1 To 18
_W>            DTE.ActiveDocument.Selection.WordRight()
_W>        Next
_W>

Сравним?

18w

это все.

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

_>Вообще-то такая фукциональность доступна в виде библиотек. Да и в коммерческих реализициях есть подобная фунциональность.

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

_>Я не утверждал, что Lisp лучше или хуже Нэмерле, но доступ к семантической информации в Lisp точно есть.

Да она сама в Лиспе под большим вопросом. Язык то по сути динамически типизированный. Ну, как ты сможешь определить что некий парамерт это получает INT если в него передано сложное выражение?

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

VK>Произойдет ошибка компиляции, а что ты ожидал?(кстати почти все макросы которые я приводил содержат в том числе и контроль ошибок, и обычно выводят вполне понятное и читабельное сообщение об ошибке)

Я ожидал, что случайно залетевший дятел не вызовет гибель всей цивилизации

В C++ я так же получил вполне понятное сообщение и сразу понял, что произошло. Проблема была в том, что был взят корректный и работающий код A (мой) и корректный работающий код B (библиотека ACE). Но вот простая компиляция A вместе с B привела к ошибке. Ошибке, которую никто не ждал и не предполагал. В результате мне пришлось переделывать мой код из-за того, что какой-то дятел в ACE сделал main макросом.

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

Все в истории развивается по спирали.

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

ВВ>>Извини, но это демагогия.
E>Не извиню.

Тогда требую ответных наездов

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

E>./configure
E>./make
E>./make install
E>

E>и дальше пользуюсь программой. Для этого процесса не нужен ни дебаггер, ни профайлер, ни редактор, ни хелп. Вот тебе применение инструмента. Есть язык (в виде компилятора и стандартной библиотеки) и есть программа на этом языке. Все.

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

E>Средства разработки нужны разработчикам. Большинству разработчиков. Но не языку.

А кому нужен язык?

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

ВВ>Тогда требую ответных наездов

Не дождетесь! ((C) Рабинович)


ВВ>Интересно конечно. А когда ты так делаешь тебе вообще не фиолетово на каком языке это приложение написано?

Практически фиолетово. Даже если этого языка у меня нет сразу, я скачиваю tgz с его исходниками, выполняю три ранее означенные команды, получаю нужный язык и возвращаюсь к предыдущему пункту.

ВВ>В общем пользоваться программой написанной на неком языке и пользоваться самим языком вещи немножко разные.

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

E>>Средства разработки нужны разработчикам. Большинству разработчиков. Но не языку.

ВВ>А кому нужен язык?

Разработчикам. Но здесь получается достаточно длинная цепочка зависимостей.
Но моя исходная мысль была в другом. Когда появляется интересный и удобный язык (именно язык), обычно для него нет IDE и продвинутых инструментов (насколько помню, даже с Java у Sun была подобная ситуация). Сначала язык пробуют разработчики-экстремалы (может быть в чем-то типа меня). Если им язык начинает нравится, они приделывают к языку необходимые инструменты. Вокруг языка начинается копошение, интерес, для более широких масс заинтересовавшихся разработчиков требуются более удобные инструменты (чтобы снизить порог вхождения) и вот здесь возникает спрос на IDE. А раз есть спрос -- есть и предложение.

Пример с C#, имхо, чуть выбивается из общей массы. Но он и не такой уж типичный. Ведь со одной стороны, C# толкала Microsoft со всеми ее возможностями и опытом в средствах разработки. С другой стороны, C# не настолько уж сильно отличается от C++ и Java, что так же способствует более быстрому возникновению спроса на IDE. И, кстати, для C# есть автономная IDE не от MS?

Здравствуйте, IT, Вы писали:
что-то вас языки программирования сильно беспокоят. Вот на Cobol-е и на еще программеры требуются, 1200+ в США:

http://seeker.dice.com/jobsearch/servlet/JobSearch?op=101&amp;dockey=xml/7/a/7a699556faee88cd572eaf289de59e81@activejobs0&amp;c=1&amp;source=1

я думаю, они получают раза в два поболее чем Java программеры. Их не трясет что уже C/C++, COM и Java, и C# и давно устарели, как вы утверждали.

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

E>Разработчикам. Но здесь получается достаточно длинная цепочка зависимостей.
E>Но моя исходная мысль была в другом. Когда появляется интересный и удобный язык (именно язык), обычно для него нет IDE и продвинутых инструментов (насколько помню, даже с Java у Sun была подобная ситуация). Сначала язык пробуют разработчики-экстремалы (может быть в чем-то типа меня).

Вот интересно получается. О чем вы тогда с Владом спорите? Влад тоже экстремал который пробует новый язык Nemerle, не имеющий на настоящий момент времени IDE и даже не особенно законченный. Сдается мне что "эффект пандоры" здесь коренится в самом понятии "пробовать". Пробовать — не значит использовать. С удовольствием пробовал/пробую экспериментальные языки программирования. Да и "блокнотом с подсветкой" я не прочь иногда попользоваться, чтобы потестировать какие-нибудь алгоритмы — причем это зачастую бывает куда удобнее чем возиться с тяжелой и неповоротливой студией. Однако я никогда стану воспринимать язык программирования "всерьез" пока вокруг него не образуется так называемая "development environment", которая — хорошо ли это или плохо — необходима разработчикам для продуктивного использования этого языка.
Т.е. можно сказать, что есть 1) разработчик, вполне конкретный человек со своими вкусами, предпочтениями и "тараканами" в голове, а есть 2) разработчикам, серая масса, "community", приведенная к некоему общему знаменателю, которой нужен и дебагер, и студия, и двадцать четыре других удобства — и промышленное распространение языка возможно лишь в том случае, когда получится угодить не просто разработчику, а именно разработчикам. В противном случае у нас останется просто диздок или слегка глючащий компилятор, с которым мы будем играться в свободное от работы время.

E>Пример с C#, имхо, чуть выбивается из общей массы. Но он и не такой уж типичный. Ведь со одной стороны, C# толкала Microsoft со всеми ее возможностями и опытом в средствах разработки. С другой стороны, C# не настолько уж сильно отличается от C++ и Java, что так же способствует более быстрому возникновению спроса на IDE. И, кстати, для C# есть автономная IDE не от MS?

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

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

E>Пример с C#, имхо, чуть выбивается из общей массы.

Да не особо — первые беты C# выкладывались без студии, да и студия была не сильно далеко ушедшей от текстового редактора с подсветкой синтаксиса.

E> И, кстати, для C# есть автономная IDE не от MS?

SharpDevelop, C# Builder, Delphi, Eclipse + Improve C# Plugin, X-Develop

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

AVK>>Да ничего страшного вобщем то. Другое дело что они не возьмутся. Я не таких соколов боюсь, им что скажут то они и будут делать. Я боюсь молодых да зеленых, которые получают игрушку в руки и начинают ее крутить.
WH>За молодыми и зелеными нужно в любом случае глаз да глаз. Они и без таких игрушек дров наломать могут буд здоров.

Глаз вот только всего два. Согласись — последствия запускания козла в огород, в котором на грядки высажен C#, и онного же, но с высаженным C++, разительно отличаются. Вопрос в том куда ближе Nemerle