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

VD>Программисты из ВУЗ-ов звучит очень смешно. Не находишь?

Нет я имел в виду, что этим языкам (ML и потомки, Хаскель) обучают в вузах, лиспу кстати тоже, и хоть какие-то поверхностные знания да
и остаются, даже по себе могу судить.

FR>>Но я имел в виду что в мейнстрим так и не прошли даже такие.

VD>Дык, а как они пройдут то когда сами базовые языки (без мета-расширений) в мэйстрим попасть не могут.

А зачем базовые, ладно к C++ прикрутить синтаксический макропроцессор очень сложно, но к той же Ява или Шарпу
вполне реально (для производителей языка) вместо выдумывания гораздо более слабых T4.

VD>Ну, а что ты хочешь? Динамика да еще и лиспоподобная. Хотя выглдяит все же по проще чем Лисп.

Все-таки гибрид, изначально можно задавать типы.
От липсоподобности (синтаксической) там как раз и старались избавится, по моему вполне получилось.

FR>>Там вообще много чего наворочено вплоть до минимальной поддержки зависимых типов http://www.opendylan.org/fragments/limited-types.phtml

VD>Интересно...

Угу, я уже давно поковырял и бросил, язык практически заброшен

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

IT>>Откуда такие сведения? Есть конкретный опыт или это всего-лишь измышлизмы?
G>Отлично можно наблюдать при переходе C#2 -> C#3.

Если ты про Linq Comprehension, то там переход не столько на новый синтаксис, сколько на новую парадигму. А синтаксис как раз всё сильно упрощает. Без него вообще была бы оппа.

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

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

G>>>>А что мешает сделать вызовы лаконичными без изменения синтаксиса?

VD>>>С C#-ом или ВБ знаком? Покажи как сделать объявление и использование зависимых свойств из WPF "лаконичными без изменения синтаксиса".

G>>Я не про C# говорю.

VD>А ты не уходи от ответа.

Я не ухожу от ответа, это ты пытаешься сузить тему обсуждения до удобной тебе.

Кстати своим примером ты не показал изменение синтаксиса.

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

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

IT>>>Откуда такие сведения? Есть конкретный опыт или это всего-лишь измышлизмы?
G>>Отлично можно наблюдать при переходе C#2 -> C#3.

IT>Если ты про Linq Comprehension, то там переход не столько на новый синтаксис, сколько на новую парадигму. А синтаксис как раз всё сильно упрощает. Без него вообще была бы оппа.
Посмотри сколько до сих пор холиваров:
1)Linq Comprehension vs Method Calls
2)Extensions vs Instance methods
3)var vs explicit type declarations

Это все чисто синтаксические примочки, которые на семантику никак не влияют.

К изменению синтаксиса надо подходить очень осторожно.

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

G>Кстати своим примером ты не показал изменение синтаксиса.

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

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

G>>А кто мешает в рантайме переписывать?
WH>И машинный код сгенерировать,... и получишь ты макросы немерла вид в профиль.
Когда в руках молоток — все вокруг кажется гвоздями.

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

IT>>Если ты про Linq Comprehension, то там переход не столько на новый синтаксис, сколько на новую парадигму. А синтаксис как раз всё сильно упрощает. Без него вообще была бы оппа.
G>Посмотри сколько до сих пор холиваров:
G>1)Linq Comprehension vs Method Calls
G>2)Extensions vs Instance methods
G>3)var vs explicit type declarations

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

G>Это все чисто синтаксические примочки, которые на семантику никак не влияют.
G>К изменению синтаксиса надо подходить очень осторожно.

Но подходить нужно. Иначе бы мы все до сих пор на ассемблере писали. Да и осторожность здесь нужна только по причине того, что обратной дороги нет всем пользователям языка. Если же мне дадут возможность расширять язык в моём собственном огороде, то чего мне осторожничать? Но в результате, во-первых, мне не нужно никого ждать годами, а, во-вторых, из таких огородов может произрости и выкристализоваться что-то ценное и полезное для всех.

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

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

G>>Кстати своим примером ты не показал изменение синтаксиса.

VD>Ну, дык хорошему языку это не всегда нужно.
Именно

VD>А вот как их решать с помощью языка который не поддерживает никакого расширения?
А необязательно это делать на уровне языка.

Например в .NET Code Contracts реализованы на уровне IL и к языку не привязаны.

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

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

IT>>>Если ты про Linq Comprehension, то там переход не столько на новый синтаксис, сколько на новую парадигму. А синтаксис как раз всё сильно упрощает. Без него вообще была бы оппа.
G>>Посмотри сколько до сих пор холиваров:
G>>1)Linq Comprehension vs Method Calls
G>>2)Extensions vs Instance methods
G>>3)var vs explicit type declarations

IT>Все эти холивары инициируются как раз людьми, которые пока ещё не в теме и не совсем понимают смысл новых возможностей. После того как они всё осваивают, холиварить уже нет смысла.

Причины не имеют значения. Факты есть. Даже небольшие изменения синтаксиса массового языка очень сильно "аукаются". Поэтому изменение синтаксиса должно быть хорошо продумано. Нельзя этот вопрос давать на откуп каждому разработчику.


G>>Это все чисто синтаксические примочки, которые на семантику никак не влияют.
G>>К изменению синтаксиса надо подходить очень осторожно.

IT>Но подходить нужно. Иначе бы мы все до сих пор на ассемблере писали. Да и осторожность здесь нужна только по причине того, что обратной дороги нет всем пользователям языка. Если же мне дадут возможность расширять язык в моём собственном огороде, то чего мне осторожничать? Но в результате, во-первых, мне не нужно никого ждать годами, а, во-вторых, из таких огородов может произрости и выкристализоваться что-то ценное и полезное для всех.
Программы как всегда пишутся один раз, а читаются гораздо больше.
Если для функции есть intellisense, F1, Goto Definition, то для новых конструкций языка всего этого нет.

Кроме того затрудняется командная разработка. Конфликты имен функций\классов решаются неймспейсами. Как разрешать конфликт расширений синтаксиса?

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

IT>>Все эти холивары инициируются как раз людьми, которые пока ещё не в теме и не совсем понимают смысл новых возможностей. После того как они всё осваивают, холиварить уже нет смысла.

G>Причины не имеют значения. Факты есть. Даже небольшие изменения синтаксиса массового языка очень сильно "аукаются".

Я же говорю. Давайте жить без ауканья и писать на ассемблере.

G>Поэтому изменение синтаксиса должно быть хорошо продумано. Нельзя этот вопрос давать на откуп каждому разработчику.

Каждый разработчик отвечает за себя сам. Ну и за тех, кто от него зависит. Ты, например, от меня никак не зависишь. Я от тебя тоже. Так почему же ты мне или я тебе должен запрещать использовать или создавать под себя такие инструменты, какие мне или тебе хочется? Не надо думать за всё человечество. Оно как-нибудь само обойдётся без такой заботы.

G>Программы как всегда пишутся один раз, а читаются гораздо больше.
G>Если для функции есть intellisense, F1, Goto Definition, то для новых конструкций языка всего этого нет.

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

G>Кроме того затрудняется командная разработка. Конфликты имен функций\классов решаются неймспейсами. Как разрешать конфликт расширений синтаксиса?

Точно так же как и другие конфликты имён. В C#, например, решили же проблему конфликта ключевых слов и идентификаторов.

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

C>Подключаемая грамматика – наподобие подключаемой библиотеки – выглядит очень привлекательной альтернативой полностью определенному языку.
В идеальном мире с идеальными программистами идея, конечно, привлекательная. Но как представлю, что индусы начнут еще и свои языки писать по делу и без дела, становится невесело. Хочешь получить себе на саппорт такой проектик из индийской деревни? Как бы хинди учить не пришлось.

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

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

IT>>>Все эти холивары инициируются как раз людьми, которые пока ещё не в теме и не совсем понимают смысл новых возможностей. После того как они всё осваивают, холиварить уже нет смысла.

G>>Причины не имеют значения. Факты есть. Даже небольшие изменения синтаксиса массового языка очень сильно "аукаются".

IT>Я же говорю. Давайте жить без ауканья и писать на ассемблере.

Не кидайся в крайности.

G>>Поэтому изменение синтаксиса должно быть хорошо продумано. Нельзя этот вопрос давать на откуп каждому разработчику.

IT>Каждый разработчик отвечает за себя сам. Ну и за тех, кто от него зависит. Ты, например, от меня никак не зависишь. Я от тебя тоже. Так почему же ты мне или я тебе должен запрещать использовать или создавать под себя такие инструменты, какие мне или тебе хочется? Не надо думать за всё человечество. Оно как-нибудь само обойдётся без такой заботы.
Так создавай, только сначала подумай чтобы твои инструменты не мешали другим. Вот именно в синтаксисе языка это очень непросто.


G>>Программы как всегда пишутся один раз, а читаются гораздо больше.
G>>Если для функции есть intellisense, F1, Goto Definition, то для новых конструкций языка всего этого нет.

IT>Почему же? Немерле при наведении мышкой на синтаксический макрос выводится код, который он генерирует. Если над этим поработать, то можно и Goto Definition нормальный сделать. В общем, дело техники, никаких концептуальных проблем.
А еще бы ограничить немного, чтобы синтаксис был не произвольный, а укладывался в какие-то рамки, тогда отличия от вызовов функций будут минимальны.
В идеале хорошо бы иметь возможность часть вычислений перенести из runtime в compiletime, не выписывая сложные конструкции в виде макросов. Пусть все выглядит как вызовы функций. Давать каждому менять синтаксис не стоит.


G>>Кроме того затрудняется командная разработка. Конфликты имен функций\классов решаются неймспейсами. Как разрешать конфликт расширений синтаксиса?
IT>Точно так же как и другие конфликты имён. В C#, например, решили же проблему конфликта ключевых слов и идентификаторов.
Ввели contextual keywords и символ @. Но если все подряд начнут менять синтаксис этого явно будет недостаточно.

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

VD>>А вот как их решать с помощью языка который не поддерживает никакого расширения?
G>А необязательно это делать на уровне языка.

G>Например в .NET Code Contracts реализованы на уровне IL и к языку не привязаны.

Не надо трепаться. Ты реализуй, и посмотрим что у тебя получилось.

Пойми, приведенный мной код был написан вот так же между двумя сообщениями (т.е. он совершенно не напряг писавшего).

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

G>А еще бы ограничить немного, чтобы синтаксис был не произвольный, а укладывался в какие-то рамки, тогда отличия от вызовов функций будут минимальны.
G>В идеале хорошо бы иметь возможность часть вычислений перенести из runtime в compiletime, не выписывая сложные конструкции в виде макросов. Пусть все выглядит как вызовы функций. Давать каждому менять синтаксис не стоит.

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

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

EOH>Не-е-е-е, тут, ИМХО, мы не создаем свой язык — мы создаем абстракции на базе известного программистам языка/технологии. Если у меня архитектура actor model на Qt, то знающий C++ и Qt человек ее поймет, потому что все примитивы и приемы кодирования ему известны. А вот если я под эту actor model наваяю собственный синтаксис, который уменьшит количество моего кода в пару-тройку раз, то с этим синтаксисом новому человеку будет разобраться намного сложнее. А уж поменять что-нибудь — большой проблемой.
Не согласен. Взять тот же Qt — это своего рода язык, который надо отдельно изучать. Я знаю С++, но покажи мне программу на Qt — с ходу не разберусь. А почему? Qt не знаю.

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

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

G>>А еще бы ограничить немного, чтобы синтаксис был не произвольный, а укладывался в какие-то рамки, тогда отличия от вызовов функций будут минимальны.
G>>В идеале хорошо бы иметь возможность часть вычислений перенести из runtime в compiletime, не выписывая сложные конструкции в виде макросов. Пусть все выглядит как вызовы функций. Давать каждому менять синтаксис не стоит.

IT>Макросы могут принимать вид синтаксического расширения, функций и атрибутов. Например, можно написать макрос-аттрибут уровня сборки, который будет запрещать создавать синтаксические макросы

Давайте отделять мух от котлет. Несмотря на то что в nemerle "синтаксические расширения, функции и атрибуты" реализованы одним механизмом макросов это совсем не значит что только так и стоит делать.
Яркий пример — code contracts в .NET, реализованы IL-реврайтером и не привязаны к языку. Причем Code Contracts состоят как из "функций", так и из "атрибутов".

Единственное что привязано к языку в указанной выше тройке — синтаксические расширения. Вот именно они вызывают наибольшие сомнения.

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

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

C>>Подключаемая грамматика – наподобие подключаемой библиотеки – выглядит очень привлекательной альтернативой полностью определенному языку.
O>В идеальном мире с идеальными программистами идея, конечно, привлекательная. Но как представлю, что индусы начнут еще и свои языки писать по делу и без дела, становится невесело. Хочешь получить себе на саппорт такой проектик из индийской деревни? Как бы хинди учить не пришлось.

Думаю, дело привычки.
Вы ведь не отказываете индусам в праве писать собственные классы или библиотеки?
Хотя в природе есть такие стандартизированные и всеохватывающие мегамонстры как .net framework, MFC, stl. Почему бы не заставить своих коллег использовать только определенные в них классы и методы?

Отвечаю на цитаты по отношению ко мне .

>>но тем сложнее и дольше его поддерживать другим людям.
Это заблуждение обычно муссируют те, кто "знаком" с проблемой теоретически. На практике же как раз поддерживать ДСЛ-и куда проще. Обычно ДСЛ-и весьма просты и очень легко осваиваются (намного проще нежели код решающий ту же задачу).

Владислав, вы меня пугаете O_O. Ну давайте померяемся, мне не жалко. У меня больше 10 лет в коммерческой разработке, из крупных проектов в которых участвовал — например, Radmin. Делал много кодегенерации и DSL: XSLT, TT, lisp, python. Последние несколько лет — Ruby. того достаточно, чтобы считать меня знакомым с проблемой практически? Если угостите кофе — могу зайти в гости, убедитесь в моей квалификации лично . Поддержка DSL — плевое дело, пока рядом есть автор. А вот если автор йок, то с DSL очень большие проблемы.

> Соответственно, это не так популярно потому как компании хотят защититься от эффекта падающего кирпича.
Можно описание этого эффекта?

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

> Если архитектор DSL покинет компанию или даже заболеет — будут большие проблемы. ОЧЕНЬ большие проблемы.
Чушь полнейшая. Как минимум есть множество примеров ДСЛ-ей широко используемых на практике (BNF, ASP/JSP, Regex). Никаких отличий у доморощенных ДСЛ-ей нет и быть не может.

Есть некая разница между широко распространенным DSL типа rake и тем, что мы сделали сами, нэ?
Если Вы считаете, что в DSL прямо вот так легко разобраться — возьмити любой проект Ruby on Rails и загляните внутрь. Будете приятно удивлены лаконичности кода и полным непонимаем как "это" работает "внутри". И это еще популярный DSL. А если кто такое сам напишет?

Неужели перспектива сократить код в 2-3 раза
не сподвигнет вас на изучение небольшого расширения синтаксиса?

Меня — может быть. Но как team lead я еще должен заботиться о тех, кто этот код будет поддерживать в будующем. Поэтому считаю что чем проще — тем лучше. И стараюсь выбрать разумные рамки. Активное использование DSL на мой взгляд за рамки выходит.

Если синтаксис действительно настолько крут, что настолько уменьшает количество кода, то затраты на обучение ему (совсем не такие большие как кажутся) окупаются скоростью разработки и качеством результата.

Увы, практика показывает что код больше читается / поддерживается, нежели пишется. Я не считаю, что введение нового языка программирования ради сокращения кода при написании стоит того, чтобы увольнение / найм людей постоянно давали проблемы. Посмотрите в сетевой стек FreeBSD — там как раз собственны DSL на базе C. Это НЕВОЗМОЖНО ни читать, ни поддерживать. Хотя писалось, наверное, быстро. Лично я не хочу тратить лишние 2-3 недели на то, чтобы разработчик ознакомился с дополнительным парком велосипедов. Мне и существующих хватает.

>>А уж поменять что-нибудь — большой проблемой.
А от это уже зависит от качества реализации "собственного синтаксиса".

Согласен. Но сделать хороший DSL — трудно. Поэтому лучше не злоупотреблять. Генерить биндинги — это клево. Но вот писать на собственном синтаксисе ядро программы — это может очень болезненно отразиться в будущем.

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

Именно поэтому я ратую за использование стандартных библиотек. Вот такой я ретроград ^_^.