Статья:
Синтаксический сахар или C++ vs. Nemerle :)

Автор(ы): Чистяков Влад aka VladD2
Дата: 24.05.2006
Данная статья явилось плодом размышлений автора над фразами то и дело произносимыми в отношении C++ «Зачем вводить в язык то, что реализуется библиотекой?» и «Язык должен включать только базовые вещи, а весь синтаксический сахар должен реализоваться в виде библиотек». Эта статья является сравнением того как эти фразы реализуются в языке Nemerle и чем эта реализация отличается от того что сделано в C++.

Авторы:
Чистяков Влад aka VladD2

Аннотация:
Данная статья явилось плодом размышлений автора над фразами то и дело произносимыми в отношении C++ <Зачем вводить в язык то, что реализуется библиотекой?> и <Язык должен включать только базовые вещи, а весь синтаксический сахар должен реализоваться в виде библиотек>. Эта статья является сравнением того как эти фразы реализуются в языке Nemerle и чем эта реализация отличается от того что сделано в C++.

Здравствуйте, Чистяков Влад aka VladD2, Вы писали:

ЧВA>Данная статья явилось плодом размышлений автора над фразами то и дело произносимыми в отношении C++ <Зачем вводить в язык то, что реализуется библиотекой?> и <Язык должен включать только базовые вещи, а весь синтаксический сахар должен реализоваться в виде библиотек>. Эта статья является сравнением того как эти фразы реализуются в языке Nemerle и чем эта реализация отличается от того что сделано в C++.

Влад, вот скажи мне, откуда такая "любовь" к C++? Ведь это язык, только коммерческая эксплуатация которого идет уже двадцать лет, а начал он создаваться еще лет на пять раньше. Какой смысл сравнивать его с только что появившимися на свет языками, в которых на генетическом уровне заложен опыт (в том числе и негативный) C++ и прочих?

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

Я не хочу порождать очередной флейм по обсуждению превосходства Nemerle над C++. Я хочу понять, почему C++ (а не Java, не Eiffel, не Smalltalk, ни Lisp, ни Visual Basic, you name it) является такой раздражающей красной тряпкой?

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

E>Здравствуйте, Чистяков Влад aka VladD2, Вы писали:

ЧВA>>Данная статья явилось плодом размышлений автора над фразами то и дело произносимыми в отношении C++ <Зачем вводить в язык то, что реализуется библиотекой?> и <Язык должен включать только базовые вещи, а весь синтаксический сахар должен реализоваться в виде библиотек>. Эта статья является сравнением того как эти фразы реализуются в языке Nemerle и чем эта реализация отличается от того что сделано в C++.

E>Влад, вот скажи мне, откуда такая "любовь" к C++? Ведь это язык, только коммерческая эксплуатация которого идет уже двадцать лет, а начал он создаваться еще лет на пять раньше. Какой смысл сравнивать его с только что появившимися на свет языками, в которых на генетическом уровне заложен опыт (в том числе и негативный) C++ и прочих?

Это "комплекс эмигранта"

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

E>Здравствуйте, Чистяков Влад aka VladD2, Вы писали:

ЧВA>>Данная статья явилось плодом размышлений автора над фразами то и дело произносимыми в отношении C++ <Зачем вводить в язык то, что реализуется библиотекой?> и <Язык должен включать только базовые вещи, а весь синтаксический сахар должен реализоваться в виде библиотек>. Эта статья является сравнением того как эти фразы реализуются в языке Nemerle и чем эта реализация отличается от того что сделано в C++.

E>Влад, вот скажи мне, откуда такая "любовь" к C++? Ведь это язык, только коммерческая эксплуатация которого идет уже двадцать лет, а начал он создаваться еще лет на пять раньше. Какой смысл сравнивать его с только что появившимися на свет языками, в которых на генетическом уровне заложен опыт (в том числе и негативный) C++ и прочих?

Вот с тем чтобы и показать как учли этот опыт.

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

Дело в том, что Java/C# изначально не рассчитаны на расширение возможностей с помощью метапрограммирования.
В них и нет таких средств.
В то же время в C++ в последнее время как раз активно его (метапрограммирование) используют (boost, особенно boost::lambda), в то же время так как изначально язык на такое применение шаблонов не был рассчитан это происходит достаточно коряво.

E>Я не хочу порождать очередной флейм по обсуждению превосходства Nemerle над C++. Я хочу понять, почему C++ (а не Java, не Eiffel, не Smalltalk, ни Lisp, ни Visual Basic, you name it) является такой раздражающей красной тряпкой?

Из этого списка можно было бы с Lisp только сравнить, наверное, по причинам изложенным выше. Было бы интересно.

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

E>Влад, вот скажи мне, откуда такая "любовь" к C++?

наверно, потому что это единственный мэйнстримный язык, в котором используют метапрограммирование на уровне языка. Ява и сишарп по этому параметру — не конкуренты.

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

E>Здравствуйте, Чистяков Влад aka VladD2, Вы писали:

ЧВA>>Данная статья явилось плодом размышлений автора над фразами то и дело произносимыми в отношении C++ <Зачем вводить в язык то, что реализуется библиотекой?> и <Язык должен включать только базовые вещи, а весь синтаксический сахар должен реализоваться в виде библиотек>. Эта статья является сравнением того как эти фразы реализуются в языке Nemerle и чем эта реализация отличается от того что сделано в C++.

E>Влад, вот скажи мне, откуда такая "любовь" к C++?

Я высказываю свою точку зрения по тем вопросам которые кажутся мне интересными.

А ты умудряшся судить о том, что не читал и вообще в глаза не видел.

E> Ведь это язык, только коммерческая эксплуатация которого идет уже двадцать лет, а начал он создаваться еще лет на пять раньше. Какой смысл сравнивать его с только что появившимися на свет языками, в которых на генетическом уровне заложен опыт (в том числе и негативный) C++ и прочих?

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

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

Потому что Ява и C# не декларировали приципы «Зачем вводить в язык то, что реализуется библиотекой?» и «Язык должен включать только базовые вещи, а весь синтаксический сахар должен реализоваться в виде библиотек» обсуждаемые в этой статье. А апологеты С++ постоянно о них упоминают.

E>Я не хочу порождать очередной флейм

Так за чем дело встало? Не порождай.

E> по обсуждению превосходства Nemerle над C++.

А что есть что обсуждать? По-моему все очевидно.

E> Я хочу понять, почему C++ (а не Java, не Eiffel, не Smalltalk, ни Lisp, ни Visual Basic, you name it) является такой раздражающей красной тряпкой?

Вообще, или применительно к этой статье? Если последнее, то я уже ответил.

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

АХ>Из этого списка можно было бы с Lisp только сравнить, наверное, по причинам изложенным выше. Было бы интересно.

Хорошая идея. Но у меня скил в области Лиспа близок по высоте к плинтусу. Так что это задача для кого-то другого.

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

АХ>>Из этого списка можно было бы с Lisp только сравнить, наверное, по причинам изложенным выше. Было бы интересно.

VD>Хорошая идея. Но у меня скил в области Лиспа близок по высоте к плинтусу.
У меня тоже

VD> Так что это задача для кого-то другого.
Ну вот тут

Автор: fionbio
Дата: 12.07.05

человек интересующийся писал, может поможет ?

Здравствуйте, Чистяков Влад aka VladD2, Вы писали:

ЧВA>Статья:

Не знаю, может быть пример выбран неудачно, может в недоступной части статьи есть объяснение, но... Пример с foreach просто смешон! Ты высказываешь тезис об отсутствии синтаксического сахара в Nemerle и тут же сам опровергаешь его. Мне конструкция с for уже настолько привычна, что вероятность допустить в задании цикла ошибку практически нулевая. Ты же называешь эту конструкцию "свирепой", предлагая взамен другую такую же, чуть короче в байтовом смысле и менее универсальную (что, если я захочу сделать шаг 2?). В чем поинт? Ведь удобство инструмента определяется не этим, верно?

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

O>Не знаю, может быть пример выбран неудачно, может в недоступной части статьи есть объяснение, но... Пример с foreach просто смешон! Ты высказываешь тезис об отсутствии синтаксического сахара в Nemerle и тут же сам опровергаешь его.
А в немерле нет конструкции foreach. Как нет и for и while и много чего другого. За то есть макросы которые это все реализуют те весь сахар (а for несомненно тоже сахар) в бибиотеке.

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

WH>А в немерле нет конструкции foreach. Как нет и for и while и много чего другого. За то есть макросы которые это все реализуют те весь сахар (а for несомненно тоже сахар) в бибиотеке.

Хмм... Но VladD2 указывал именно foreach как одно из преимуществ.

Аргументы в статье не доказывают преимущества Nemerle как инструмента, а лишь показывают какой-то новый [сомнительный] синтаксис.

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

VD>> Так что это задача для кого-то другого.
АХ>Ну вот тут

Автор: fionbio
Дата: 12.07.05

человек интересующийся писал, может поможет ?

Проблема в том, что у Личпарей обычно нулевой скил в области Немерла и нулевое же влечение к дотнету и всем что с ним связано.

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

O>Здравствуйте, Чистяков Влад aka VladD2, Вы писали:

ЧВA>>Статья:

O>Не знаю, может быть пример выбран неудачно, может в недоступной части статьи есть объяснение, но...

Есть еще один варинт. Ты мог невнимательно прочесть или прочтя не понять о чем идет речь.

O> Пример с foreach просто смешон! Ты высказываешь тезис об отсутствии синтаксического сахара в Nemerle и тут же сам опровергаешь его. Мне конструкция с for уже настолько привычна, что вероятность допустить в задании цикла ошибку практически нулевая.

Я думаю, развивать тему возможности допущения ошики не стоит.

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

O> Ты же называешь эту конструкцию "свирепой", предлагая взамен другую такую же, чуть короче в байтовом смысле и менее универсальную (что, если я захочу сделать шаг 2?). В чем поинт? Ведь удобство инструмента определяется не этим, верно?

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

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

VD>Есть еще один варинт. Ты мог невнимательно прочесть или прочтя не понять о чем идет речь.

Пропустим.

VD>Речь в статье и примере идет о другом. Речь идет о том, что все варианты перебор равнозначны и один можно выразить через другой. Ну, а зачем эта мысль высказывается можно понять только прочтя статью до конца.

Не, это конечно хорошо, что можно изобретать свои варианты перебора. Только зачем? Пусть не foreach, рассмотрим пример с хвостовой рекурсией. Какой в ней, собственно, смысл? Чтобы перебрать значения, ты определяешь дополнительную функцию/макрос, тем самым плодя сущности без необходимости. Такой перебор сложнее читается, т. к. визуально перегружен (условный оператор, рекурсивный вызов).

Это я всё не придираюсь, это я просто к тому, что пример плохой. Хотя может мысль, которую он должен выражать, правильная. Я не телепат.

VD>Поинт в том, что ты читая про одно зациклился на посторонеей вещи. Причем ты в общем-то не прав и в сделанном тобой выводе по поводу for-а, но обсуждать эту тему значит уйти совсем в сторону от смысла. В общем, подождем пока статья будет выложена целиком, а там поговорим, если конечно, вопросы еще останутся.

В статье [пока] довольно мало вещей, чтобы можно было на чём-то зациклиться. И уж поверь, человек, незнакомый с Nemerle, понимает начало так: Nemerle лучше, потому что у него больше возможностей для перебора.

ЗЫ. Зачем такую тему, которую обсуждают на форуме, надо было делать закрытой?

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

O>Это я всё не придираюсь, это я просто к тому, что пример плохой. Хотя может мысль, которую он должен выражать, правильная. Я не телепат.

Смысл примера с рекурсией не в его "хорошести", а в том, что без forXXX можно обойтись совсем. Но статья немного о другом и в ней нигде не говорится, что так теперь и надо поступать.

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

E>>Влад, вот скажи мне, откуда такая "любовь" к C++?

VD>Я высказываю свою точку зрения по тем вопросам которые кажутся мне интересными.

Хм. Выглядит это так: "я знаю C++, C# и Nemerle. C# и Nemerle мои любимые языки. C++ отстой. Значит нужно попинать C++."

Спасибо, ответ понятен.

VD>А ты умудряшся судить о том, что не читал и вообще в глаза не видел.

Покажи мне точную цитату, где я что-нибудь из твоей статьи осудил.

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

VD>Речь в статье и примере идет о другом. Речь идет о том, что все варианты перебор равнозначны и один можно выразить через другой. Ну, а зачем эта мысль высказывается можно понять только прочтя статью до конца.

Ну хотя бы намекни...

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

E>Хм. Выглядит это так: "я знаю C++, C# и Nemerle. C# и Nemerle мои любимые языки. C++ отстой. Значит нужно попинать C++."

Тебе так хочется видить. А реальность такая. Я заметил интересную вещь и описал ее развернуто. Что касается "любви", то тоже ошибаешся. Я прошел сколу С++, C# и вот сейчас прохожу школу Nemerlr. Каждая мне что-то дала и двинула в перед. Ну, а некоторые сидят на пятой точке и ищут отмазки для того чтобы не отрывать ее от земли.
E>Спасибо, ответ понятен.

E>Покажи мне точную цитату, где я что-нибудь из твоей статьи осудил.

Re: Синтаксический сахар или C++ vs. Nemerle :)

Автор: eao197
Дата: 24.05.06

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

WH>>А в немерле нет конструкции foreach. Как нет и for и while и много чего другого. За то есть макросы которые это все реализуют те весь сахар (а for несомненно тоже сахар) в бибиотеке.

O>Хмм... Но VladD2 указывал именно foreach как одно из преимуществ.

Вот по этомв я и сказал, что нужно читать статью целиком. Возможно ее слишком плохо порезали. Ровно на подходе к проблемной области. Вот и кажется, что рассуждения о каких-то там foreachо-ах.

O>Аргументы в статье не доказывают преимущества Nemerle как инструмента, а лишь показывают какой-то новый [сомнительный] синтаксис.

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

Про сомнительность синтаксиса даже говорить не хочу.

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

VD>Тебе так хочется видить. А реальность такая. Я заметил интересную вещь и описал ее развернуто. Что касается "любви", то тоже ошибаешся. Я прошел сколу С++, C# и вот сейчас прохожу школу Nemerlr. Каждая мне что-то дала и двинула в перед. Ну, а некоторые сидят на пятой точке и ищут отмазки для того чтобы не отрывать ее от земли.

Боюсь, что ты эту школу не прошел, а был просто отчислен за неуспеваемость.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

Ш>Боюсь, что ты эту школу не прошел, а был просто отчислен за неуспеваемость.
А я прошол?

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

E>>Покажи мне точную цитату, где я что-нибудь из твоей статьи осудил.

VD>Re: Синтаксический сахар или C++ vs. Nemerle :)

Автор: eao197
Дата: 24.05.06

Ты дал ссылку на мое сообщение. Но покажи мне слова, в которых я твою статью хоть как то осуждаю?

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

Ш>Боюсь, что ты эту школу не прошел, а был просто отчислен за неуспеваемость.

Я конечно мог бы ответить тебе той же манетой. Но опускаться до такого уровня не считаю нужным.

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

E>Ты дал ссылку на мое сообщение. Но покажи мне слова, в которых я твою статью хоть как то осуждаю?

Зачем цитировать все сообщение?

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

VD>Речь в статье и примере идет о другом. Речь идет о том, что все варианты перебор равнозначны и один можно выразить через другой. Ну, а зачем эта мысль высказывается можно понять только прочтя статью до конца.

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

И еще:

Так в чем же удача Nemerle-овцев и ошибка C++-ников?

Я не очень то согласен что у C++-ников была какая-то ошибка. Не очень хорошая фраза. В чем ошибка? В том, что С++ ники пользуются побочными эффектами С++? Запретим им пользоваться, то будет лучше?

Мне кажется, в определении того, что должно быть базисом, а что надстройкой.

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


ЗЫ. К сожалению, статью полностью прочитать смогу только вечером(сегодня привезут журнальчик). Поэтому это касается только вступления. Слишком уж резануло

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

GZ>Эквивалентность может измеряться по разному. Действительно, если немного подвернуть эти примеры, то можно получить эквивалентные по функциональности подпрограммы. Но можно измерять эквивалентность с помощью генерируемых кодов которые должен выполнять процессор. Числодробилки пока никто не отменял. И тут у меня есть некоторая догадка, что чем больше знает компилятор об обрабатываемых конструктциях, тем больше у него возможностей оптимизации. Ты рассматривал этот вопрос?

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

GZ>И еще:
GZ>

GZ>Так в чем же удача Nemerle-овцев и ошибка C++-ников?

GZ>Я не очень то согласен что у C++-ников была какая-то ошибка. Не очень хорошая фраза. В чем ошибка? В том, что С++ ники пользуются побочными эффектами С++? Запретим им пользоваться, то будет лучше?

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

GZ>

GZ>Мне кажется, в определении того, что должно быть базисом, а что надстройкой.

GZ>В условиях конца 80-ых годов, такой проблемы не стояло. По второй эквивалентности(качеству кодов), он обгонял почти все (что тогда можно было назвать нормальным языком). Да и сейчас не последний.

Вопрос качества кода здесь не рассматривается. Так что не будем обсждать то, что первые компиляторы С++ резко проигрывали в скорости С-компиляторам.

GZ>ЗЫ. К сожалению, статью полностью прочитать смогу только вечером(сегодня привезут журнальчик). Поэтому это касается только вступления. Слишком уж резануло

Ну, вот когда прочтешь до конца, то с удовольствием послушаю мнение о статье. А то споры явно уходят в сторону от сути статьи.

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

E>>Ты дал ссылку на мое сообщение. Но покажи мне слова, в которых я твою статью хоть как то осуждаю?

VD>Зачем цитировать все сообщение?

Если ты в вопросе о выборе C++ в качестве языка, с которым сравнивается Nemerle обнаружил осуждение собственой статьи, то это очень смахивает на паранойю.

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

E>Если ты в вопросе о выборе C++ в качестве языка, с которым сравнивается Nemerle обнаружил осуждение собственой статьи, то это очень смахивает на паранойю.

Ты вообще можешь внятно объяснить о чтом тогда было твое сообщение?

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

VD>Ты вообще можешь внятно объяснить о чтом тогда было твое сообщение?

Я спросил, почему ты сравниваешь Nemerle со старым языком C++, а не с более новыми языками, вроде Java.

Но ответ я уже получил.

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

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

VD>>Ты вообще можешь внятно объяснить о чтом тогда было твое сообщение?

E>Я спросил, почему ты сравниваешь Nemerle со старым языком C++, а не с более новыми языками, вроде Java.

Кстати, да. С С++ некорректно сравнивать, у него предназначение другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все накопившиеся проблемы никакой альтернативы нет.

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

K>Кстати, да. С С++ некорректно сравнивать, у него предназначение другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все накопившиеся проблемы никакой альтернативы нет.
А D?
Да, пока он не доделан. Но в принципе?

Андрей Хропов wrote:
> K>Кстати, да. С С++ некорректно сравнивать, у него предназначение
> другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все
> накопившиеся проблемы никакой альтернативы нет.
> А D?
> Да, пока он не доделан. Но в принципе?
Если доделать, то вполне возможно и будет. Так как задумывался как
замена С++.

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

K>Кстати, да. С С++ некорректно сравнивать, у него предназначение другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все накопившиеся проблемы никакой альтернативы нет.

Сам я автора не читал но как и весь Советский народ....

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

C>Андрей Хропов wrote:
>> K>Кстати, да. С С++ некорректно сравнивать, у него предназначение
>> другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все
>> накопившиеся проблемы никакой альтернативы нет.
>> А D?
>> Да, пока он не доделан. Но в принципе?
C>Если доделать, то вполне возможно и будет. Так как задумывался как
C>замена С++.
Я то с этим согласен. И считаю, что это было бы good.
Это вопрос к тов. Kluev, который говорит, что никаких альтернатив С++ не наблюдается.

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

А ты бы высылал полный текст статьи все потенциальным спорщикам

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

АХ>Здравствуйте, Kluev, Вы писали:

K>>Кстати, да. С С++ некорректно сравнивать, у него предназначение другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все накопившиеся проблемы никакой альтернативы нет.
АХ>А D?
АХ>Да, пока он не доделан. Но в принципе?

Не D не пройдет. Как я понимаю самые главные проблеммы там так и не решены, так сахарком посыпали.

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

Фактически в С++ не добавлять фичи надо, а мусор выкидывать: препроцессор и прочий устаревший стафф.

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

C>Андрей Хропов wrote:
>> K>Кстати, да. С С++ некорректно сравнивать, у него предназначение
>> другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все
>> накопившиеся проблемы никакой альтернативы нет.
>> А D?
>> Да, пока он не доделан. Но в принципе?
C>Если доделать, то вполне возможно и будет. Так как задумывался как
C>замена С++.

Вряд ли, С++ убьет аналогичный низкоуровневый язык в котором будет обеспечена обратная binary compatibility м-ду версиями классов. Тогда будет устранен его единственный недостаток который не позволяет создать стройный framework, т.е. привести зоопарк библиотек к некой общей основе.

Причем добавить это достаточно просто с небольшим оверхедом. Back-end уже есть (за что респект GCC team).

З.Ы. Я периодически начинаю писать и проект у меня лежит (пока только парзер), но мысль об обьеме пугает меня.
Может кто возьмется?

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

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

K>>Кстати, да. С С++ некорректно сравнивать, у него предназначение другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все накопившиеся проблемы никакой альтернативы нет.

VD>Сам я автора не читал но как и весь Советский народ....

Автор выложи статью полностью или выпей ...

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

WH>А я прошол?

Прошёл, но у тебя были проблемы другого плана.

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

ВВ>А ты бы высылал полный текст статьи все потенциальным спорщикам

А не легче ли открыть её? Или журнал понесёт страшные убытки?

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

K>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>Здравствуйте, Kluev, Вы писали:

K>>>Кстати, да. С С++ некорректно сравнивать, у него предназначение другое. И пока никаких альтернатив ему не наблюдается. Несмотря на все накопившиеся проблемы никакой альтернативы нет.
АХ>>А D?
АХ>>Да, пока он не доделан. Но в принципе?

K>Не D не пройдет. Как я понимаю самые главные проблеммы там так и не решены, так сахарком посыпали.
См. Таблица сравнения языков

Автор: VladD2
Дата: 18.05.06

и оригинал здесь.

А так (для меня лично) одно добавление нормального foreach чего стоит!

K>В С++ самый главный недостаток то, что невозможно обеспечить обратную двоичную совместимость м-ду версиями классов. (Виртуальную функцию в dll-класс уже не добавишь без перекомпиляции зависимых от этой dll). Что очень сильно сдерживает развитие билиотек.
Я бы вообще сказал, что это не недостаток языка, а свойство его реализаций
(во многом обусловленное свойствами языка, конечно).

Сейчас даже единого ABI нет (это после стольких-то лет с создания языка!).
Я помню как ковырялся пытаясь из Borland C++ Builder — программы вызывать DLL-ку, скомпилированную VS.
Ничего не вышло!

Но я боюсь, что если делать это по-нормальному, то получится что-то вроде .NET framework , который уже есть.

В общем если за время 20-летнего существования языка этого не сделали, то и вряд ли сделают.

Ну о других недостатках тут уже много говорили.

А вот в D обещают как раз стандартизованный ABI, что сделать проще, так как нет в частности множественного наследования.

K>Фактически в С++ не добавлять фичи надо, а мусор выкидывать: препроцессор и прочий устаревший стафф.
Не, боюсь без препроцессора никуда. Как headerы то вставлять ?
А вот в D это как раз и сделали.
Какой "прочий устаревший стафф"?

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

WH>>А я прошол?
O>Прошёл, но у тебя были проблемы другого плана.
А именно?

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

ВВ>>А ты бы высылал полный текст статьи все потенциальным спорщикам
O>А не легче ли открыть её? Или журнал понесёт страшные убытки?

А я знаю? Лично меня вполне удовлетворит "авторская" копия на любой из моих емейлов

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

O>>Прошёл, но у тебя были проблемы другого плана.
WH>А именно?

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

K>Здравствуйте, Андрей Хропов, Вы писали:

K>В С++ самый главный недостаток то, что невозможно обеспечить обратную двоичную совместимость м-ду версиями классов. (Виртуальную функцию в dll-класс уже не добавишь без перекомпиляции зависимых от этой dll). Что очень сильно сдерживает развитие билиотек.

см. проект DDL.

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

K>Автор выложи статью полностью или выпей ...

Яд который я пью — грузинский коньяк и грузинское вино у нас сегодня отобрали. Так что до тех пор пока он к нам не вернется прийдется влачить существование трезвиника.

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

ВВ>А я знаю? Лично меня вполне удовлетворит "авторская" копия на любой из моих емейлов

Ну, такую наглость нельзя не поощрить.

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

ВВ>>А я знаю? Лично меня вполне удовлетворит "авторская" копия на любой из моих емейлов
VD>Ну, такую наглость нельзя не поощрить.

Тогда на Vasily.Voronkov#bp.com пожалуйста

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

ВВ>Тогда на Vasily.Voronkov#bp.com пожалуйста

И мне тоже интересно! Если можно, на адрес в профиле.

Что же ты ему такое сказал?

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

ВВ>Тогда на Vasily.Voronkov#bp.com пожалуйста
Вот туда я пробовал послать. Только получил:

ailed to deliver to 'Vasily.Voronkov@bp.com'
SMTP module(domain bp.com) reports:
message text rejected by mail37.messagelabs.com:
553 information. (#5.7.1)

Короче, приходи 30-го на User Group.

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

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

O>И мне тоже интересно! Если можно, на адрес в профиле.

Публичного мыла у тебя нет. А чрез форумы атачи не идут. Если москвич, то приходи на User Group 30-го числа. Там будут журналы раздоваться с этой статьей. За одно поглядишь на язык в живую.

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

VD> Короче, приходи 30-го на User Group.
VD> Я туда припру пачку другую журнала и буду халявно раздавать. Для тебя считай журнал зарезервирован.

Я не смогу по причине нахождения в другой стране
А сюда можно — basil#voronkov.name — ?

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

VD>Что же ты ему такое сказал?

Да ничего такого
Я просто вспомнил о своих проблемах с С++, имевших оттенок... гм.. "романтического" характера...

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

ВВ>Я не смогу по причине нахождения в другой стране
ВВ>А сюда можно — basil#voronkov.name — ?

Это что?

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

ВВ>>Я не смогу по причине нахождения в другой стране
ВВ>>А сюда можно — basil#voronkov.name — ?
VD>Это что?

Домен такой. Специально для частных емейлов и хоум-пейджей.

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

VD>Публичного мыла у тебя нет. А чрез форумы атачи не идут. Если москвич, то приходи на User Group 30-го числа. Там будут журналы раздоваться с этой статьей. За одно поглядишь на язык в живую.

Тот, что в профиле (olegator@fromru.com), и есть публичный. Или нужен другой?

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

Ш>Боюсь, что ты эту школу не прошел, а был просто отчислен за неуспеваемость.

Фу, как некрасиво

Kluev wrote:
> Вряд ли, С++ убьет аналогичный низкоуровневый язык в котором будет
> обеспечена обратная binary compatibility м-ду версиями классов. Тогда
> будет устранен его единственный недостаток который не позволяет создать
> стройный framework, т.е. привести зоопарк библиотек к некой общей основе.
Ну в D это возможно — они думают над стандартом на ABI. Если хорошо его
продумать — то вполне такое возможно.

Хотя я бы добавил в D еще умные указатели и более тщательно изолировал
бы GC.

> Причем добавить это достаточно просто с небольшим оверхедом. Back-end
> уже есть (за что респект GCC team).
Угу.

> З.Ы. Я периодически начинаю писать и проект у меня лежит (пока только
> парзер), но мысль об обьеме пугает меня.
> Может кто возьмется?
У меня постоянно такая же мысль. Только вот времени нужно ОЧЕНЬ много.

Андрей Хропов wrote:
> C>Если доделать, то вполне возможно и будет. Так как задумывался как
> C>замена С++.
> Я то с этим согласен. И считаю, что это было бы good.
> Это вопрос к тов. Kluev, который говорит, что никаких альтернатив С++ не
> наблюдается.
Пока D только в далеком будущем планируется

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

K>З.Ы. Я периодически начинаю писать и проект у меня лежит (пока только парзер), но мысль об обьеме пугает меня.

полноценный совместимый со стандартом парсер?

Был кстати еще проект по внедрению полноценной кодогенерации в С++ (в Bell Labs), но он кажется уже загнулся. Хотя если бы они это доделали, то С++ мог бы получить второй шанс

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

VD>Я прошел сколу С++, C# и вот сейчас прохожу школу Nemerlr. Каждая мне что-то дала и двинула в перед.

Суровые школы...

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

C>Kluev wrote:
>> Вряд ли, С++ убьет аналогичный низкоуровневый язык в котором будет
>> обеспечена обратная binary compatibility м-ду версиями классов. Тогда
>> будет устранен его единственный недостаток который не позволяет создать
>> стройный framework, т.е. привести зоопарк библиотек к некой общей основе.
C>Ну в D это возможно — они думают над стандартом на ABI. Если хорошо его
C>продумать — то вполне такое возможно.

ABI это не совсем-то. Это просто формат VMT, где она лежит в классе, как кидаются исключения и т.п.
От изменения VMT в базовом классе это не спасет, прийдется все перекомпилировать. Если язык сразу не спроектировать с учетом таких возможностей то потом уже хрен добавишь.

К примеру если в ДЛЛ

struct Foo
{
   int  x;
};

А в том кто ее линкует
void test()
{
   Foo f; // на стеке
}

То добавить переменную в класс Foo без перекомпиляции всего уже не получится

struct Foo
{
   int x;
   int y;
};

Вместо этого прийдется юзать pImpl

struct Foo
{
  struct FooImpl *impl; // impl меняем как хотим.
};

Для переменных pImpl еще спасет хотя это не маленький оверхед: память выделяется динамически по любому, а вот от добавления виртуальной функции уже не спасет. К тому же паттерн pImpl — неудобен.

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


>> Причем добавить это достаточно просто с небольшим оверхедом. Back-end
>> уже есть (за что респект GCC team).
C>Угу.

>> З.Ы. Я периодически начинаю писать и проект у меня лежит (пока только
>> парзер), но мысль об обьеме пугает меня.
>> Может кто возьмется?
C>У меня постоянно такая же мысль. Только вот времени нужно ОЧЕНЬ много.

Сложно сказать.

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

GZ>>Эквивалентность может измеряться по разному. Действительно, если немного подвернуть эти примеры, то можно получить эквивалентные по функциональности подпрограммы. Но можно измерять эквивалентность с помощью генерируемых кодов которые должен выполнять процессор. Числодробилки пока никто не отменял. И тут у меня есть некоторая догадка, что чем больше знает компилятор об обрабатываемых конструктциях, тем больше у него возможностей оптимизации. Ты рассматривал этот вопрос?

VD>Я уверен в справедливосьи теоремы о том, что эквивалентный код может порождать идентичный машинный код. И в том, что качественный оптимизирующий компилятор будет переписывать конструкции наиболее оптимальным образом и в итоге породит идентичный код.
Я тоже уверен в справедливости этой теоремы. Только я также уверен в том, что sql никогда не преобразуется в действительно оптимальный набор команд, поскольку для этого надо решить по крайней мере 2 NP задачи.

GZ>>И еще:
GZ>>

GZ>>Так в чем же удача Nemerle-овцев и ошибка C++-ников?

GZ>>Я не очень то согласен что у C++-ников была какая-то ошибка. Не очень хорошая фраза. В чем ошибка? В том, что С++ ники пользуются побочными эффектами С++? Запретим им пользоваться, то будет лучше?

VD>Очередной пример того когда люди думаю о чем-то своем и пытаются читать что-то еще.
VD>Ошибка в дизайне языка. В том, что декларируя наличие только необходимого в язык встроены конструкции с идентичными возможностями и отличающиеся только синтаксисом.
Ты забыл сказать унаследованные от предыдущих языков. А во вторых я имел ввиду что это можно назвать ошибкой языка, а не ошибкой C++-ников. Иначе ты людей обижаешь на ровном месте.

GZ>>ЗЫ. К сожалению, статью полностью прочитать смогу только вечером(сегодня привезут журнальчик). Поэтому это касается только вступления. Слишком уж резануло
VD>Ну, вот когда прочтешь до конца, то с удовольствием послушаю мнение о статье. А то споры явно уходят в сторону от сути статьи.
Прочел. Не понравилось. Влад, какого фига ты сравниваешь метапрограммирование с макросами макроассемблера? Макроассемблер родил С, С родил С++. Фича оставалось неизменной. Но сейчас развитие языка (с помощью библиотек) идет на основании шаблонов.(за некоторыми исключениями). Твое сравнение не есть корректно. После публикации главы "Расширение синтаксиса" будет нехилый флейм.

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

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

K>>З.Ы. Я периодически начинаю писать и проект у меня лежит (пока только парзер), но мысль об обьеме пугает меня.

Д>полноценный совместимый со стандартом парсер?

Со стандартом, только со своим.

Д>Был кстати еще проект по внедрению полноценной кодогенерации в С++ (в Bell Labs), но он кажется уже загнулся. Хотя если бы они это доделали, то С++ мог бы получить второй шанс

В С++ сахара и так достаточно. Никудышная модульность, препроцессор, крайняя сложность разработки всяких IDE под него. Вот что его губит. Более того дополнительный сложный сахар — он скорее ускоряет его конец чем оттягивает его. Т.к. при существующей инфраструктуре сырец->препроцессор->единица_трансляции->компилер->обьектник->линкер все становится крайне сложным. Должно быть так:

сырцы->parser->(ast файлы для всяких рефактори-броузеров)->компилер->модуль с интерфейсом на борту.

Никаких хидеров и препроцессора. Вместо препроцессора празер должен давать ast в стандартизованном формате, чтобы IDE писатели не мучались.

P/S/ А всякие рассужедния о том что в С++ не хватает сахарка А или сахарка Б — это просто от непонимания сути воопроса и проблем программирования вообще. Продвигая сахарок народ с мухами сражается, не замечая чудовищных глобальных проблем готорые достались от С

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

K>Единственный выход из это ситуации (если хотим жить без перекомпиляции), создавать VMT и разметку классов динмаически, в процессе загрузки. А если сразу это в язык не заложить то потом уже поезд ушел.
В конце концов у тебя получится жаба или .НЕТ... Так зачем мучаться?

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

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

K>>Единственный выход из это ситуации (если хотим жить без перекомпиляции), создавать VMT и разметку классов динмаически, в процессе загрузки. А если сразу это в язык не заложить то потом уже поезд ушел.
WH>В конце концов у тебя получится жаба или .НЕТ... Так зачем мучаться?

Нет. Ни то и не другое. язык будет такимже низкоуровневым как и С++, просто для классов которые экспортируются из ДЛЛ добавится дополнительный уровень виртуализации.

В С++ чтобы добратся к переменой класс комилер делает:
ptr_to_Field = ptr_to_Object + FieldOffset (где FieldOffset константа)

А нужно сделать чтобы для нектороых классов была возможность FieldOffset сделать переменным (вернее он должен вычислятся в момент инициализации, сразу после загрузки модулей). Тогда изменения в layout-е базовых классов не страшны.

Аналогично для VMT, компилер выбирает функцию из VMT зная ее индекс. Для некоторых классов индекс так же будет динамическим

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

K>Нет. Ни то и не другое. язык будет такимже низкоуровневым как и С++, просто для классов которые экспортируются из ДЛЛ добавится дополнительный уровень виртуализации.
Вот у нас уже появилась метаинформация те один шаг до рефлекшена.
Далие нам понадобится что-то сделать с менеджером памяти... а там глядишь уже и до ГЦ недолеко.
Потом захечется код во время исполнения сгенерить... и вот у нас уже появляется System.Reflection.Emit...
...
Так зачем мучаться?

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

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

K>>Единственный выход из это ситуации (если хотим жить без перекомпиляции), создавать VMT и разметку классов динмаически, в процессе загрузки. А если сразу это в язык не заложить то потом уже поезд ушел.
WH>В конце концов у тебя получится жаба или .НЕТ... Так зачем мучаться?

Необязательно, может получится и что-то совсем другое

WolfHound wrote:
> K>Нет. Ни то и не другое. язык будет такимже низкоуровневым как и С++,
> просто для классов которые экспортируются из ДЛЛ добавится
> дополнительный уровень виртуализации.
> Вот у нас уже появилась метаинформация те один шаг до рефлекшена.
Так как бы с этим никто и не спорит — reflection запросто реализуется и
без VM.

> Далие нам понадобится что-то сделать с менеджером памяти... а там
> глядишь уже и до ГЦ недолеко.
Опциональный GC с тщательной проработкой взаимодействия с другими
менеджерами — тоже нормальная вещь. И делается это намного проще, чем в
C++/CLI если не задумываться о совместимости с .NET.

> Потом захечется код во время исполнения сгенерить... и вот у нас уже
> появляется System.Reflection.Emit...
А вот это уже не нужно. Так же как и JIT-компиляция и байт-код.

> Так зачем мучаться?
В .NET слишком много нужного .НЕТ. И добавить это не ломая самых основ —
не получится.

FR,

K>>>Единственный выход из это ситуации (если хотим жить без перекомпиляции), создавать VMT и разметку классов динмаически, в процессе загрузки. А если сразу это в язык не заложить то потом уже поезд ушел.
WH>>В конце концов у тебя получится жаба или .НЕТ... Так зачем мучаться?

FR>Необязательно, может получится и что-то совсем другое

+1
У других получился Erlang, и ещё у третьих — Java, а у четвёртых вообще попугай (Parrot)

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

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

K>>Нет. Ни то и не другое. язык будет такимже низкоуровневым как и С++, просто для классов которые экспортируются из ДЛЛ добавится дополнительный уровень виртуализации.
WH>Вот у нас уже появилась метаинформация те один шаг до рефлекшена.
WH>Далие нам понадобится что-то сделать с менеджером памяти... а там глядишь уже и до ГЦ недолеко.
WH>Потом захечется код во время исполнения сгенерить... и вот у нас уже появляется System.Reflection.Emit...

Не, GC и Emit у нас не будет. Зачем?

А вот скриптинг будет. Причем в качестве скриптового будет выступать сам основной язык.
Т.к. хидеров нет и информация о типах лежит в модулях, то нет никаких препятствий. Компилим в байткод и запсукаем. Эдакий unsafe скриптинг с указателями, адрессной арифметикой и без GC. И не надо морочится c написанием разных переходников и оберток.

Разработка будет происходить так: пишем скелет основной програмы, запускаем, в него подгружается scrip-runtime. Далее фичи дописываем интерактивно в скриптовом режиме. после того как фича написана и отлажена, просто добавляем файл к основному проекту и он уже компилируется в native.

Kluev,

K>А вот скриптинг будет. Причем в качестве скриптового будет выступать сам основной язык.
K>Т.к. хидеров нет и информация о типах лежит в модулях, то нет никаких препятствий. Компилим в байткод и запсукаем. Эдакий unsafe скриптинг с указателями, адрессной арифметикой и без GC. И не надо морочится c написанием разных переходников и оберток.

K>Разработка будет происходить так: пишем скелет основной програмы, запускаем, в него подгружается scrip-runtime. Далее фичи дописываем интерактивно в скриптовом режиме. после того как фича написана и отлажена, просто добавляем файл к основному проекту и он уже компилируется в native.

REPL захотелось? Всё уже украдено до тебя: LISP, Erlang, Smalltalk.

Теоретически такую инкрементальную разработку можно реализовать на JVM и .NET, только в последних 2х случаях народ пошёл (вернее народ повели) по классическому пути.

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

LCR>Kluev,

K>>А вот скриптинг будет. Причем в качестве скриптового будет выступать сам основной язык.
K>>Т.к. хидеров нет и информация о типах лежит в модулях, то нет никаких препятствий. Компилим в байткод и запсукаем. Эдакий unsafe скриптинг с указателями, адрессной арифметикой и без GC. И не надо морочится c написанием разных переходников и оберток.

K>>Разработка будет происходить так: пишем скелет основной програмы, запускаем, в него подгружается scrip-runtime. Далее фичи дописываем интерактивно в скриптовом режиме. после того как фича написана и отлажена, просто добавляем файл к основному проекту и он уже компилируется в native.

LCR>REPL захотелось? Всё уже украдено до тебя: LISP, Erlang, Smalltalk.

REPL получается на халяву как довесок. Если основные недостатки С++ устранить.

LCR>Теоретически такую инкрементальную разработку можно реализовать на JVM и .NET, только в последних 2х случаях народ пошёл (вернее народ повели) по классическому пути.

Цель не в этом.

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

GZ>Я тоже уверен в справедливости этой теоремы. Только я также уверен в том, что sql никогда не преобразуется в действительно оптимальный набор команд, поскольку для этого надо решить по крайней мере 2 NP задачи.

Не понял.

GZ>Ты забыл сказать унаследованные от предыдущих языков.

Какая разница что кто у кго унаследовал? В Немереле тоже есть и for и if. Но это не значит, что они обязаны быть жестко вмонтированы в компилятор. Если основа языка полноценна, а язык расширяем, то все это можно реализовать на нем самом. Собственно это я слышу о С++ постоянно, и сообственно именно этого я не вижу. И именно об этом статья.

GZ> А во вторых я имел ввиду что это можно назвать ошибкой языка, а не ошибкой C++-ников. Иначе ты людей обижаешь на ровном месте.

Под С++-никами в данном случае пордазумеваются разработчкики языка. Возможно я выразился двусмысленно. К пользователям языка это не относится.

GZ>>>ЗЫ. К сожалению, статью полностью прочитать смогу только вечером(сегодня привезут журнальчик). Поэтому это касается только вступления. Слишком уж резануло
VD>>Ну, вот когда прочтешь до конца, то с удовольствием послушаю мнение о статье. А то споры явно уходят в сторону от сути статьи.
GZ>Прочел. Не понравилось. Влад, какого фига ты сравниваешь метапрограммирование с макросами макроассемблера?

Ты точно ту что нужно статью прочел? Я ни слова в ней ни про ассемблер, ни про его макросы не сказал.

GZ> Макроассемблер родил С, С родил \С++. Фича оставалось неизменной.

Акстись. Макроассемблер появился сильно позже чем С и его маросы. И речь о макросах С в общем-то не идет. Они упамянаются один раз когда речь идет о изменении синтаксиса, так как это единственная возможность изменить именно синтаксис, а не семантику:

Разные хитрые извороты позволяют изменить семантику имеющегося синтаксиса в этом языке, но вы не в силах изменить сам синтаксис.
Конечно, можно реализовать цикл как-то так:

#define while(condition, body) ля-ля-ля

Но тогда и использовать его придется довольно странно:

int i = 0;

while (i < 100, 
  ...
  i++;
)

Но и тут возникнут проблемы, так как в «ля-ля-ля» вы будете вынуждены забить некоторые имена, которые могут пересечься с имеющимися в контексте использования оператора.

GZ> Но сейчас развитие языка (с помощью библиотек) идет на основании шаблонов.(за некоторыми исключениями).

Прочти еще раз выделенное жирным выше. Шаблоны не могут изменить синтаксис языка! В принципе не могут! Об этом и шала речь. В прочем и define-ы тоже это не делают.

GZ> Твое сравнение не есть корректно. После публикации главы "Расширение синтаксиса" будет нехилый флейм.

Ну, то что флэйм будет я даже не сомневаюсь. Жаль что я не смог уберечься от двусмысленных конструкций. Это конечно вызовет некоторые пролемы. Но думаю, основаня проблема в том, что эта статься по сути своей говорит нелицеприятную правду. Именно этим она заденет многих фанатов. Они будут понимать, что именно Неперловый путь верный, а С++ не идет дальше деклараций благих намерений, но в силу привязанности к любимому языку будут стараться защищать его любой ценой.

Тут ничего не поделашь. Эта статья и не имела намерения переметнуть закареневших С++ в иную "веру". Ее цель воздействие на людей которым по душе красивые фундаментальные решения. Я бы сказал она рассчитана на рамантиков со вкусом.

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

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

K>...Должно быть так:

K>сырцы->parser->(ast файлы для всяких рефактори-броузеров)->компилер->модуль с интерфейсом на борту.

K>Никаких хидеров и препроцессора. Вместо препроцессора празер должен давать ast в стандартизованном формате, чтобы IDE писатели не мучались.

Вот в Неперле именно так. Именно по этому через месяц другой у Nemele будет поддержка IDE.

Так что счасливых мечтаний.

K>P/S/ А всякие рассужедния о том что в С++ не хватает сахарка А или сахарка Б — это просто от непонимания сути воопроса и проблем программирования вообще.

Нет. Это от того, что разные люди называют сахаром разные вещи. В С++ 100%-но нехватает многих вещей. Кое что можно сэмулировать его другими средствами, но выходит это очень тяжело, больно и неполноценно.

K> Продвигая сахарок народ с мухами сражается, не замечая чудовищных глобальных проблем готорые достались от С

Тут согласен. Без борьбы с инглюдами и тяжелым препроцессором, короче без модульности, это все как мертвому припарка.

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

FR>>Необязательно, может получится и что-то совсем другое

LCR>+1
LCR>У других получился Erlang, и ещё у третьих — Java, а у четвёртых вообще попугай (Parrot)

Подытожу. У всех получилось нечто уникальное, но в то же время во многом похожее. И все что получилось совсем не похоже на С++.

Выводы... ну, а их каждый как всегда сделает сам.

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

VD>Ну, то что флэйм будет я даже не сомневаюсь. Жаль что я не смог уберечься от двусмысленных конструкций. Это конечно вызовет некоторые пролемы. Но думаю, основаня проблема в том, что эта статься по сути своей говорит нелицеприятную правду. Именно этим она заденет многих фанатов. Они будут понимать, что именно Неперловый путь верный, а С++ не идет дальше деклараций благих намерений, но в силу привязанности к любимому языку будут стараться защищать его любой ценой.

А какие вообще у тебя были причины сравнивать немерле именно с С++ и в таком ключе чтобы обидеть и унизить (как я понял) приверженцев С++?
Хотя конечно большой флейм это неплохой способ пиара

VD>Тут ничего не поделашь. Эта статья и не имела намерения переметнуть закареневших С++ в иную "веру". Ее цель воздействие на людей которым по душе красивые фундаментальные решения. Я бы сказал она рассчитана на рамантиков со вкусом.

Понятно, приятно же пнуть опонентов

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

Original-Recipient: rfc822;<olegator~fromru.com>
Final-Recipient: rfc822;<olegator~fromru.com>
Action: failed
Status: 5.0.0

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

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

VD>>Ну, то что флэйм будет я даже не сомневаюсь. Жаль что я не смог уберечься от двусмысленных конструкций. Это конечно вызовет некоторые пролемы. Но думаю, основаня проблема в том, что эта статься по сути своей говорит нелицеприятную правду. Именно этим она заденет многих фанатов. Они будут понимать, что именно Неперловый путь верный, а С++ не идет дальше деклараций благих намерений, но в силу привязанности к любимому языку будут стараться защищать его любой ценой.

FR>А какие вообще у тебя были причины сравнивать немерле именно с С++ и в таком ключе чтобы обидеть и унизить (как я понял) приверженцев С++?

Сори, если ты читать не умешь, то я помочь ничем не могу.

FR>Понятно, приятно же пнуть опонентов

Рад, что тебе приятно.

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

K>Со стандартом, только со своим.

а на чем парсер делал?

K>В С++ сахара и так достаточно.

Кодогенерация — это как раз радикальное средство избавиться от лишнего сахара в языке.
Хотя в целом правильно мыслишь

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

GZ>>Я тоже уверен в справедливости этой теоремы. Только я также уверен в том, что sql никогда не преобразуется в действительно оптимальный набор команд, поскольку для этого надо решить по крайней мере 2 NP задачи.
VD>Не понял.
Теоретически можно многое обосновать. А практически немногое сделать. В оптимизации sql есть две NP задачи: 1 — упрощение с помощью семантической информации о данных (генереция практически бесконечного количества планов), и нахождение оптимального плана n^m задача. Сомневаюсь что в вопросах оптимизации копилятора нет таких фенек.

GZ>> А во вторых я имел ввиду что это можно назвать ошибкой языка, а не ошибкой C++-ников. Иначе ты людей обижаешь на ровном месте.
VD>Под С++-никами в данном случае пордазумеваются разработчкики языка. Возможно я выразился двусмысленно. К пользователям языка это не относится.


VD>Ты точно ту что нужно статью прочел? Я ни слова в ней ни про ассемблер, ни про его макросы не сказал.
GZ>> Макроассемблер родил С, С родил \С++. Фича оставалось неизменной.
VD>Акстись. Макроассемблер появился сильно позже чем С и его маросы.
Насчет родил — я погорячился(данные из моей памяти оказались недостоверными). А вот макросы уже были:

While wanting to use a higher-level language, he wrote the original Unix system in PDP-7 assembler. At the start, he did not even program on the PDP-7 itself, but instead used a set of macros for the GEMAP assembler on a GE-635 machine. A postprocessor generated a paper tape readable by the PDP-7.

The Development of the C Language

GZ>> Но сейчас развитие языка (с помощью библиотек) идет на основании шаблонов.(за некоторыми исключениями).
VD>Прочти еще раз выделенное жирным выше. Шаблоны не могут изменить синтаксис языка! В принципе не могут! Об этом и шала речь. В прочем и define-ы тоже это не делают.
Я не очень понимаю различие между семантикой и синтаксисом в данном вопросе. Ты завел разговор именно о синтаксическом сахаре. И также написал:

Понял я то, что в C++, при верной, в общем-то, постановке задачи «Ввести в язык базовые вещи, а остальное реализовать на нем», его разработчики поступили в точности наоборот.

Сейчас они думают о boost::lambda. Что это, не синтаксический сахар? Не назвать это полноценным синтаксическим сахаром я не могу. И основан он на свойстве метапрограммирования шаблонов. Там и замыкание делают(хоть и кривое). Именно шаблоны и библиотеки основанные на них развивают язык(как они это делают, красиво или некрасиво — уже второй вопрос). Но это факт.

VD>Тут ничего не поделашь. Эта статья и не имела намерения переметнуть закареневших С++ в иную "веру". Ее цель воздействие на людей которым по душе красивые фундаментальные решения. Я бы сказал она рассчитана на рамантиков со вкусом.
Другая статья про Nemerle понравилась. Хорошо написана. С удовольствием прочитал.

VD>Ну, а политика критиков ради критики иуже ясна. Докапываться до несущественных мелочей панически боясь поднять голову и посмореть на реально затронутую проблему.
Проблема безусловно есть. С++ — это такая старая телега, которая чтобы она не отставала от машин, каждый раз приделывают новый пропеллер. У нее этих пропеллеров — целый ворох. Все в статье верно. Но ты говоришь только о синтаксисе, а не о возможностях. Именно с этим я не согласен.

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

GZ>Теоретически можно многое обосновать. А практически немногое сделать. В оптимизации sql есть две NP задачи: 1 — упрощение с помощью семантической информации о данных (генереция практически бесконечного количества планов), и нахождение оптимального плана n^m задача. Сомневаюсь что в вопросах оптимизации копилятора нет таких фенек.

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

Так что причем тут приведенный тобой пример я не понял.

GZ>Насчет родил — я погорячился(данные из моей памяти оказались недостоверными). А вот макросы уже были:

Да они и до С были. Причем тут этого? Я что где-то утверждал, что макросы — это единственныое средство метапрограммирования в С++?
О чем речь то. Ты онял про что статья?

GZ>Я не очень понимаю различие между семантикой и синтаксисом в данном вопросе.

Нда, похоже я слишком умные слова использовал. Семантика — это поведение, а синтаксис — это внешний вид. Напрммер два макроса (С-шных) могут иметь одинаковый синтаксис и разную семантику.

GZ> Ты завел разговор именно о синтаксическом сахаре.

Ага. Именно, о синтаксичесоком.

GZ> И также написал:
GZ>

Понял я то, что в C++, при верной, в общем-то, постановке задачи «Ввести в язык базовые вещи, а остальное реализовать на нем», его разработчики поступили в точности наоборот.

GZ>Сейчас они думают о boost::lambda. Что это, не синтаксический сахар?

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

Сравни это с примерами немерла, когда средствами метапрограммировния в язык вводятся констркции вроде for, while, foreach и даже средства типизированного доступа к SQL.

GZ> Не назвать это полноценным синтаксическим сахаром я не могу.

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

Ты вон послушай, что думают люди вроде eao197 о подобных попытках.

GZ> И основан он на свойстве метапрограммирования шаблонов. Там и замыкание делают(хоть и кривое). Именно шаблоны и библиотеки основанные на них развивают язык(как они это делают, красиво или некрасиво — уже второй вопрос). Но это факт.

факт только в том, что все потуги вроде буста можно охарактиризовать двумя словами — криво и неполноценно. Вот это факт. Так же факт в том, что синтаксическим сахором является почти все в языке, или ничего.

Статья же как раз демонстрирует полную ошибочность подхода С++. Язык не содержит важных базовых вещей и полноценных средств расширения синтаксиса. Да что повторяться то. Прочти статью еще раз. Там об этом сказано довольно подробно.

GZ>Другая статья про Nemerle понравилась. Хорошо написана. С удовольствием прочитал.

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

GZ>Проблема безусловно есть. С++ — это такая старая телега, которая чтобы она не отставала от машин, каждый раз приделывают новый пропеллер. У нее этих пропеллеров — целый ворох. Все в статье верно. Но ты говоришь только о синтаксисе, а не о возможностях. Именно с этим я не согласен.

Замечательная алегория. С++ это именно телега к которой пытаются приделать пропеллер. Причем даже если это и получается, то смысла в этом нет, так как аэродинамика все равно не для полетов. По этому и нужны новые языки с качественно новой аэродинамикой. Уверен, что и они когда-то устареюти и им на смену прийдут новые с совсем дургой аэродинамикой (а то и вообще без нее, так как будут приспособленны для гипер прыжков в пространстве ). Но цепляться за старые — это глупо. Единственный способ сделать язык современным — это постоянно его модернизировать. Иначе настанет момент когда язык станет той телегой которой никакая модернизация не поможет.

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

VD>Сравни это с примерами немерла, когда средствами метапрограммировния в язык вводятся констркции вроде for, while, foreach и даже средства типизированного доступа к SQL.

Немерл я вообще не знаю (это оговорка), но почему в С++ нельзя этого сделать? Можно назвать программу, использующую Qt, написанной на С++? Конечно! Но Qt дополняет язык, в него вводятся новые возможности, недоступные ранее, он становится именно ОО — объекты получают события, и для программиста это очевидно, а не так как в стандартном С++, где событие это вызов метода. Да, нужен дополнительный moc-компилятор, но что с того — обычное метапрограммирование. Еще раз оговорюсь — не знаю как это реализовано в немерле.
И foreach там есть

GZ>>Проблема безусловно есть. С++ — это такая старая телега, которая чтобы она не отставала от машин, каждый раз приделывают новый пропеллер. У нее этих пропеллеров — целый ворох. Все в статье верно. Но ты говоришь только о синтаксисе, а не о возможностях. Именно с этим я не согласен.

VD>Замечательная алегория. С++ это именно телега к которой пытаются приделать пропеллер. Причем даже если это и получается, то смысла в этом нет, так как аэродинамика все равно не для полетов. По этому и нужны новые языки с качественно новой аэродинамикой.

А вот это уже не очень замечательная аллегория...

VD> Уверен, что и они когда-то устареюти и им на смену прийдут новые с совсем дургой аэродинамикой (а то и вообще без нее, так как будут приспособленны для гипер прыжков в пространстве ). Но цепляться за старые — это глупо. Единственный способ сделать язык современным — это постоянно его модернизировать. Иначе настанет момент когда язык станет той телегой которой никакая модернизация не поможет.

Такой момент для всего сущего неизбежен. Но С++ еще жив и это о чем-тот говорит. А именно о том, что эта "телега" имеет аэродинамику (по твоей аналогии) гораздо более лучшую, чем все современные автомобили, и модернизация этой телеги себя оправдывает.
Впрочем, сколько можно на эту тему спорить

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

VD>>Сравни это с примерами немерла, когда средствами метапрограммировния в язык вводятся констркции вроде for, while, foreach и даже средства типизированного доступа к SQL.

D> Немерл я вообще не знаю (это оговорка),

Тогда возможно для начала лучше осзакомиться с ним? Хотя бы поверхносно?

D> но почему в С++ нельзя этого сделать? Можно назвать программу, использующую Qt, написанной на С++?

Потому что язык это не позволяет сделать.

D> Конечно! Но Qt дополняет язык, в него вводятся новые возможности, недоступные ранее, он становится именно ОО — объекты получают события, и для программиста это очевидно, а не так как в стандартном С++, где событие это вызов метода. Да, нужен дополнительный moc-компилятор, но что с того — обычное метапрограммирование. Еще раз оговорюсь — не знаю как это реализовано в немерле.
D> И foreach там есть

Вот только заслуги С++ тут нет. Тут есть борьба с его проблемами внешними средствами.

К тому же это все детский лепет. Даже C# не нужны подпорки чтобы создать полноценную компонентную систему построения GUI. А уж Nemerle и подавно.

D> Такой момент для всего сущего неизбежен. Но С++ еще жив и это о чем-тот говорит.

Жив, жив. И будет еще долго жить благодоря неумению лдей переучиваться. "С" тоже жив. Да и ассемблер.

D> А именно о том, что эта "телега" имеет аэродинамику (по твоей аналогии) гораздо более лучшую, чем все современные автомобили, и модернизация этой телеги себя оправдывает.
D> Впрочем, сколько можно на эту тему спорить

Это самовнушение. Телега она и в африке телега. Едит конечно, но и только.

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

D>> Немерл я вообще не знаю (это оговорка),

VD>Тогда возможно для начала лучше осзакомиться с ним? Хотя бы поверхносно?

Может быть. Можно левому челу (вроде меня) появиться на встрече usergroup и поучаствовать?

D>> но почему в С++ нельзя этого сделать? Можно назвать программу, использующую Qt, написанной на С++?

VD>Потому что язык это не позволяет сделать.

Станадарт языка. Для немерле есть стандарт? Если нет, то они с плюсами в равных условиях.

D>> Конечно! Но Qt дополняет язык, в него вводятся новые возможности, недоступные ранее, он становится именно ОО — объекты получают события, и для программиста это очевидно, а не так как в стандартном С++, где событие это вызов метода. Да, нужен дополнительный moc-компилятор, но что с того — обычное метапрограммирование. Еще раз оговорюсь — не знаю как это реализовано в немерле.
D>> И foreach там есть

VD>Вот только заслуги С++ тут нет. Тут есть борьба с его проблемами внешними средствами.

Не спорю. Однако приятно писать на С++ и иметь новые клевые фишки И знать, что получится нативный хороший код. Вопрос религии, конечно... (заметь, при этих фишках я пишу на плюсах, а это, как ни крути, язык — про стандарты забудь)

VD>К тому же это все детский лепет. Даже C# не нужны подпорки чтобы создать полноценную компонентную систему построения GUI. А уж Nemerle и подавно.

Блин. Фрэймворк нужен. Впрочем, это уже неважно. Это то же самое что требовать ОС для приложения. Так что опустим. Однако... Ты использовал Delphi? Уж насколько я не люблю дельфи, но там круче!!!! Намного! Возникает ощущение, что популярность дотнета вызвана созвучностью основного языка, продвигаемого микрософтом, с с++

D>> Такой момент для всего сущего неизбежен. Но С++ еще жив и это о чем-тот говорит.

VD>Жив, жив. И будет еще долго жить благодоря неумению лдей переучиваться. "С" тоже жив. Да и ассемблер.

Нет. Я давно уже переучился. Но тянет на С и С++. Очень иногда на асм. На асм из-за ностальгии, на С++ из любви. Я обожаю С++. Ты обожаешь шарп и немерле? Пожалуйста. Я не против. Не буду же я называть тебя как-нить неполиткорректно из-за этого...

D>> А именно о том, что эта "телега" имеет аэродинамику (по твоей аналогии) гораздо более лучшую, чем все современные автомобили, и модернизация этой телеги себя оправдывает.
D>> Впрочем, сколько можно на эту тему спорить

VD>Это самовнушение. Телега она и в африке телега. Едит конечно, но и только.

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

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

VD>Это самовнушение. Телега она и в африке телега. Едит конечно, но и только.

А куда спешить? Сейчас спокойно поедим, спокойно спустимся... (c)

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

>> Так зачем мучаться?
C>В .NET слишком много нужного .НЕТ. И добавить это не ломая самых основ — не получится.

А если абстрагироваться от глупостей в виде основ?

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

VD>>Я прошел сколу С++, C# и вот сейчас прохожу школу Nemerlr. Каждая мне что-то дала и двинула в перед.

ГВ>Суровые школы...

Начинаем приводить в действие непопулярные меры:

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

GZ>Сейчас они думают о boost::lambda. Что это, не синтаксический сахар? Не назвать это полноценным синтаксическим сахаром я не могу. И основан он на свойстве метапрограммирования шаблонов.

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

GZ> Там и замыкание делают(хоть и кривое).

Думаю, ключевых слова здесь два: делают и кривое. Всмысле, так долго делают и так криво.

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

D> Блин. Фрэймворк нужен. Впрочем, это уже неважно. Это то же самое что требовать ОС для приложения. Так что опустим. Однако... Ты использовал Delphi? Уж насколько я не люблю дельфи, но там круче!!!! Намного! Возникает ощущение, что популярность дотнета вызвана созвучностью основного языка, продвигаемого микрософтом, с с++
И чего в дельфе круче чем в .НЕТ?

IT wrote:
>> > Так зачем мучаться?
> C>В .NET слишком много нужного .НЕТ. И добавить это не ломая самых основ
> — не получится.
> А если абстрагироваться от глупостей в виде основ?
Можно. Но получим огромный performance hit.

Тут уже куча примеров была — например, в .NET нет указателей на методы.
Их можно эмулировать, но в нексколько раз медленнее. Нет стековых
объектов — можно использовать GC, но в некоторых случаях будет в разы
медленнее. И т.п.

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

D> Может быть. Можно левому челу (вроде меня) появиться на встрече usergroup и поучаствовать?

Что значит левому?
Конечно можно. Фэйс-контроль никто не устраивает.

D> Станадарт языка. Для немерле есть стандарт?

Язык еще даже до версии 1.0 не дожил, а стандартизация — это процесс на годы.

D>Если нет, то они с плюсами в равных условиях.

И кто влучших?

D> Блин. Фрэймворк нужен. Впрочем, это уже неважно. Это то же самое что требовать ОС для приложения.

Вот-вот. Только "ОС" занимает 20 метров и может быть установлена на очень разные физические ОС. При этом есть большая вероятность, что программа в будующем будет работать там где не работает ее неуправляемый аналог. Учитывая, что на Виндовс и Линукс дотнет или Моно уже ставятся по умолчанию, то и гворить то в общем-то не очем. Да и времена не те, чтобы нельзя было раз в 2-3 года скачать новую версию фрэймворка весом в 20 мег.

D> Так что опустим. Однако... Ты использовал Delphi?

Да, года 3.

D> Уж насколько я не люблю дельфи, но там круче!!!! Намного!

Что круче?

D> Возникает ощущение, что популярность дотнета вызвана созвучностью основного языка, продвигаемого микрософтом, с с++

Вообще-то под дотент можно писать и на Дельфи (для которой теперь это основная платформа), и на С++. В общем, мы уходим от темы.

D> Нет. Я давно уже переучился. Но тянет на С и С++. Очень иногда на асм. На асм из-за ностальгии, на С++ из любви. Я обожаю С++. Ты обожаешь шарп и немерле? Пожалуйста. Я не против.

Я тоже когда-то любил С++, но чем дальше в лес, тем от него больше ташнит.

D>Не буду же я называть тебя как-нить неполиткорректно из-за этого...



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

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

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

У тебя уже развился полноценный комплекс неполноценности на базе борьбы за производительность.

VladD2 wrote:
> У тебя уже развился полноценный комплекс неполноценности на базе борьбы
> за производительность.
Скорее мания величия

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

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

D>> Может быть. Можно левому челу (вроде меня) появиться на встрече usergroup и поучаствовать?

VD>Что значит левому?
VD>Конечно можно. Фэйс-контроль никто не устраивает.

Левому в смысле — левому от дотнета Я даже зарегился специально на годотнете, но вопрос — нормально, если я зарегюсь на встречу, но не приду (мало ли что там на работе случится)?

D>>Если нет, то они с плюсами в равных условиях.

VD>И кто влучших?

Это относительно

D>> Блин. Фрэймворк нужен. Впрочем, это уже неважно. Это то же самое что требовать ОС для приложения.

VD>Вот-вот. Только "ОС" занимает 20 метров и может быть установлена на очень разные физические ОС.

Это здорово. Только уже не верится про разные ОС Рихтер писал, что микрософт будет заниматься "портированием" фрейма только для винды, а остальные пусть сами для себя портируют, благо все спецификации открыты...

VD> При этом есть большая вероятность, что программа в будующем будет работать там где не работает ее неуправляемый аналог. Учитывая, что на Виндовс и Линукс дотнет или Моно уже ставятся по умолчанию, то и гворить то в общем-то не очем. Да и времена не те, чтобы нельзя было раз в 2-3 года скачать новую версию фрэймворка весом в 20 мег.

20 мег это фигня. Дело не в размере

D>> Уж насколько я не люблю дельфи, но там круче!!!! Намного!

VD>Что круче?

Ты же сказал про компонентную разработку гуи? В дельфи это круче реализовано.


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

VD>Это не моя алегория, и я на ее базе ничего не доказывал. Но по-моему она очень хорошо отражает суть дела.

Не твоя, а ты ее используешь Нужно было автору патент брать

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

D> Левому в смысле — левому от дотнета Я даже зарегился специально на годотнете, но вопрос — нормально, если я зарегюсь на встречу, но не приду (мало ли что там на работе случится)?

Ничего страшного.

D> Это здорово. Только уже не верится про разные ОС Рихтер писал, что микрософт будет заниматься "портированием" фрейма только для винды, а остальные пусть сами для себя портируют, благо все спецификации открыты...

Реально одних версий Виндовс уже есть стук 20. Ведь разные ВыньЦЕ сюда тоже входят. Плюс Моно живет уже на немалом количестве платформ. Конечно для очень взыскательных этого может не хватить. Но реально 99% программистов пишут софт под Вынь и Лиь. Причем посленее явно случается реже.

D> 20 мег это фигня. Дело не в размере

Тогда в чем?

D> Ты же сказал про компонентную разработку гуи? В дельфи это круче реализовано.

Серьезно? И можешь даже аргументировать?
За одно расскажи как дельфи живет поверх того самого фрэймворка.

D> Не твоя, а ты ее используешь Нужно было автору патент брать

У автора остался копирайт.

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

D>> Блин. Фрэймворк нужен. Впрочем, это уже неважно. Это то же самое что требовать ОС для приложения. Так что опустим. Однако... Ты использовал Delphi? Уж насколько я не люблю дельфи, но там круче!!!! Намного! Возникает ощущение, что популярность дотнета вызвана созвучностью основного языка, продвигаемого микрософтом, с с++
WH>И чего в дельфе круче чем в .НЕТ?

Прошу прощения, что не ответил, ответ в посте к Владу.

Здравствуйте, Cyberax, Вы писали:
C>Не нравится мне когда за меня решают что нужно использовать, и при этом
C>говорят "это для твоего же блага".
Не волнуйся. Эта проблема была у 100% разработчиков, переходящих из неуправляемого мира в управляемый. В том числе и у меня.

Sinclair wrote:
> C>Не нравится мне когда за меня решают что нужно использовать, и при этом
> C>говорят "это для твоего же блага".
> Не волнуйся. Эта проблема была у 100% разработчиков, переходящих из
> неуправляемого мира в управляемый. В том числе и у меня.
Вообще-то в "управляемый мир" я уже переходил (в Java). Понравилось —
Web-приложения или серверные системы писать самое оно.

Но вот после этого мне С++ стал намного больше нравится как раз из-за
возможностей выбора.

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

WH>>И чего в дельфе круче чем в .НЕТ?

D> Прошу прощения, что не ответил, ответ в посте к Владу.

Откровенно говоря ответя я так и не заметил. То что ты сказал, что Дельфи по-твоему круче для меня аргументацией не является.

Дельфи и дотнет используют одинаковые компонентные принцпы для постоения ГУИ. Это их роднит. Одако дотнет продуман значительно лучше (что не странно, так как одиним из создателей Дельфи был автор C#-а) и позволяет создавать более чистые решения. Главная разница между Дельфи (причем старой) и дотнетом заключается в том, что компонентная модель дельфи довольно убока и догое время была не документирована. Дотнетные же технологии полностью открыты.

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

VD>Так что причем тут приведенный тобой пример я не понял.
Ладно. Проехали, чтобы лишнего флейма не поднимать. В статье и соседних есть ответы на которые я хотел получить ответ.

VD>Да они и до С были. Причем тут этого? Я что где-то утверждал, что макросы — это единственныое средство метапрограммирования в С++?
VD>О чем речь то. Ты онял про что статья?
Да понял, понял. И главное, я понял что мне в ней не нравится.
Первое, ты назвал ее С++ vs Nemerle. Если бы ты ее назвал Nemerle vs Императивщина, то было бы проще. Взял за основу циклы, и стал рассуждать. В функциональный стиле, циклы повторимы через рекурсию и оптимизацию компилятора(кому-то наверно нравится это называть это side эффектом ). Там длинное эссе(и весьма полезное для незнающих функциональные стили программирования) которое я не буду повторять. И делается вывод что базовой вещью должен быть рекурсивный стиль, а циклы могут быть реализуемы. Как бы все правильно и верно. Но проблема в том, что ты это назвал C++ vs Nemerle. В C++ базовой вещью являются циклы. И самая проблема в том, что в нем и функциональный стиль повторим. И замыкания, и кортежи. Если бы ты показал ответ что это кривая реализация, то вопросов бы не было. Но в данном случае, вопрос:"Зачем вводить в язык то, что реализуется библиотекой?" остался открытым. И утверждение:

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

недоказанным.
Это по первой главе.
Вторая глава:
Далее объяснения почему так все круто в Nemerle, и как легко сделать Nemerle императивным. И пример программирования макросов С++ с утверждением о его негигиеничности. Негигиенечность можно обойти (вставить что-нибудь типа __LINE__ и уже хорошо). А вот заменить автоматически statement функторами в теле процедуры, IMHO уже сложней(если не невозможно). Но опять я в ней не нашел выводов по тому кому быть базовым механизмом.
В остальном, абсолютно согласен. Хотя может быть и занимаюсь буквоедством.

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

GZ>> И также написал:
GZ>>

Понял я то, что в C++, при верной, в общем-то, постановке задачи «Ввести в язык базовые вещи, а остальное реализовать на нем», его разработчики поступили в точности наоборот.

GZ>>Сейчас они думают о boost::lambda. Что это, не синтаксический сахар?
VD>Это идиотизм. Создать полноценную лямбду с возможностью синтаксического замыкания на внешний контест нвеозможно в приципе. Все это ужимки от бедности.
Там шарповская система автогенеренных функторов с сохранением локальных переменных. Только в С# есть GC который эти локальные переменные умеет счищать. Вобщем, на мой взгляд, кривизна. И вроде бы ее и сами сишники не очень балуют.

VD>Сравни это с примерами немерла, когда средствами метапрограммировния в язык вводятся констркции вроде for, while, foreach и даже средства типизированного доступа к SQL.
+1. Только я этого не увидел в статье.

GZ>> Не назвать это полноценным синтаксическим сахаром я не могу.
VD>Полноценный? Это попытка использовать умеющиеся синтаксические конструкции для эмуляции других.
VD>Ты вон послушай, что думают люди вроде eao197 о подобных попытках.
И я с ним согласен. Да и с тобой согласен. Токмо я буквоед.

VD>факт только в том, что все потуги вроде буста можно охарактиризовать двумя словами — криво и неполноценно. Вот это факт. Так же факт в том, что синтаксическим сахором является почти все в языке, или ничего.
+1

VD>Это разные статьи. И не нравится эта статья исключительно из религиозных чувств которые она затрагивает.
У меня с религиозными чувствами плоховато. Потому и занимаюсь буквоедством.

VD>Та статья — это введение для начинающих. Эта — анализ. Потому понять эту статья не так просто как ту. В этой нужно думать, сравнивать, анализировать, оценивать. Потму люди которые ее пойму, пусть даже при этом не оценив, уже представляют для меня больший интересе.
А я и есть начинающий. Правда сравнивать с C# мне было сложновато. Плохо клеится в мозгах. А вот сравнение с OCaml по тезисам этой статьи, мне далось легче.

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

IT>Сколько уже можно повторять, основан он не на свойстве метапрограммирования шаблонов, а на сайд эффектах компилятора. Впрочем, возможно это теперь называется "Свойство Метапрограммирования".
Это вопрос относительности. Можно назвать side — эффект. Для других — свойство прекомпиляции заголовочных файлов. Каждому свое.

IT>Думаю, ключевых слова здесь два: делают и кривое. Всмысле, так долго делают и так криво.
Язвительность неконструктивна. По мне криво. Я испорчен языками где это одна из основ, и сделано с соответсвующим качеством.

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

WH>>>И чего в дельфе круче чем в .НЕТ?

D>> Прошу прощения, что не ответил, ответ в посте к Владу.

VD>Откровенно говоря ответя я так и не заметил. То что ты сказал, что Дельфи по-твоему круче для меня аргументацией не является.

А я не говорил ничего про развернутый ответ Сейчас отвечу.

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

D>> Левому в смысле — левому от дотнета Я даже зарегился специально на годотнете, но вопрос — нормально, если я зарегюсь на встречу, но не приду (мало ли что там на работе случится)?

VD>Ничего страшного.

Ок, зарегился

VD>Реально одних версий Виндовс уже есть стук 20. Ведь разные ВыньЦЕ сюда тоже входят. Плюс Моно живет уже на немалом количестве платформ. Конечно для очень взыскательных этого может не хватить. Но реально 99% программистов пишут софт под Вынь и Лиь. Причем посленее явно случается реже.

D>> 20 мег это фигня. Дело не в размере

VD>Тогда в чем?

Ты серьезно ждешь ответ на этот вопрос сексуального характера?

D>> Ты же сказал про компонентную разработку гуи? В дельфи это круче реализовано.

VD>Серьезно? И можешь даже аргументировать?

Серьезно. Аргументировать не могу . Это вопрос вкусов вроде. В делфи (и билдере) довольно хороший интерефейс для создания гуи, возможность наследовать формы, офигенная поддержка разработки своих компонент с возможностью их отладки в design-тайме... В дотнете меня поразил своей убогостью дизайнер и редактор свойств. Да, похоже на то как в делфи (один чувак все же автор ), но не то... Собственно, я об этом. РАД среда никакая для меня.

VD>За одно расскажи как дельфи живет поверх того самого фрэймворка.

Не понял...

VD>>Ничего страшного.

D> Ок, зарегился

Имелась ввиду улыбка, блин...

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

D>>> 20 мег это фигня. Дело не в размере

VD>>Тогда в чем?

D> Ты серьезно ждешь ответ на этот вопрос сексуального характера?

Да, так как одозреваю, что это очередная фобия.

VD>>Серьезно? И можешь даже аргументировать?

D> Серьезно. Аргументировать не могу . Это вопрос вкусов вроде.

Тогда не забывай делая такие заявления добавлять строчку вроде "мне кажется" или "для меня...".
А то вдруг ты носитель тайного знания которое я пропустил.

D> В делфи (и билдере) довольно хороший интерефейс для создания гуи,

Извини, ты VS2005 то видел?

D> возможность наследовать формы,

Есть и в VS 2002.

D> офигенная поддержка разработки своих компонент с возможностью их отладки в design-тайме...

Ну, про отлаку в дизайнтайм ты загнул. Для компонента это уже рантайм. Но в общем и целом разницы в отдадке и разработке компонентов я вилчно не вижу. Или вижу, но точно не в пользу дельфи. К тому же надо понимать, что разработка на безопасном языке с ЖЦ всегда надежнее чем на небезопасном и без ЖЦ. Так что не дотнетная Дельфи отдыхает по любому. А дотнетная мало чем отличается от Шарпа.

D> В дотнете меня поразил своей убогостью дизайнер и редактор свойств.

Это от незнания. На самом деле он значительно лучше расширяется. Ну, а то что он не похож на павлина... дык на то есть C# Builder от Борланда или та же Delphi .NET. Крастоты не писанной как в прочем и глючности редкостной.

D> Да, похоже на то как в делфи (один чувак все же автор ), но не то... Собственно, я об этом. РАД среда никакая для меня.

Извини, но это проявление поверности знаний в данной области. Я как бы был знаком собоими системами. Реально дизайн-тайм в WinForms продуман значительно лучше. Единственная проблема тема эта огромна. По ней можно книги писать.
Для разгона:
.Net – классы, компоненты и контролы

Автор(ы): Владислав Чистяков
Дата: 09.05.2003
Создание ПО из компонентов подразумевает, что компоненты будут добавляться к проекту во время разработки. При этом будет производиться их начальная настройка. Компоненты как таковые не подразумевают (вернее сказать, не обязаны иметь) пользовательского интерфейса (ни для программиста, ни для конечного пользователя). В этом качестве выступают части IDE и дополнительные программные дизайнеры. Первой компонентной средой был продукт, купленный Microsoft на заре своего существования. Впоследствии на его базе родился VB. Далее была Delphi… в общем, к концу двадцатого века компоненты стали поддерживаться почти везде (даже в Visual C++, хотя он и по сей день не очень-то визуальный).

Статьи по Windows Forms

VD>>За одно расскажи как дельфи живет поверх того самого фрэймворка.

D> Не понял...

Ты не в курсе что начиная с Delphi.NET основной платформой для Дельфи является дотнет? Ну, ты что-то очень уж сильно отстал.

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

Долго писал ответ, но у ноутбука кончилась батарейка и он выключился (думл, что он в сети, а шнур был вынут).
В общем, повторять подвиг в лом. Так что твечу только на часть.

В статье в общем-то все сказано. Но при некоторой степени предвзятости в ней всегда можно найти "не то".

GZ>Ладно. Проехали, чтобы лишнего флейма не поднимать. В статье и соседних есть ответы на которые я хотел получить ответ.

Вот вот. Остается только выключить предпочтения и поглядеть на факты и выводы.

GZ>

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

GZ>недоказанным.

Это явная не правда. Все как раз доказано выше крыши. Причем еще не мной, а тем кто придумал лямбда-исчисления .
Функция более общая вещь нежели нежели циклы. С++ все равно содержит функции. Лябда же более универсальная вещь чем функция. По сути фунция — это дямбда с которой ассоциировано некоторое имя. Так почему в С++ нет лямбды и ее унжно пытаться сэмулировать, но есть циклы и глобальные функции? Ответ очевиден — недальновидный дизайн и совместимось с еще более убогим дизайном С.

GZ>Это по первой главе.
GZ>Вторая глава:
GZ>Далее объяснения почему так все круто в Nemerle, и как легко сделать Nemerle императивным. И пример программирования макросов С++ с утверждением о его негигиеничности. Негигиенечность можно обойти (вставить что-нибудь типа __LINE__ и уже хорошо).

Закат солнца в ручную?

GZ> А вот заменить автоматически statement функторами в теле процедуры, IMHO уже сложней(если не невозможно). Но опять я в ней не нашел выводов по тому кому быть базовым механизмом.

Точнее не захотил увидеть. Статья четко подводит к мысли, что функционаьная основа и штатные, полноценные, и удобные средства метапрограммирования как раз и есть правильный дизайн.

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

GZ>В остальном, абсолютно согласен. Хотя может быть и занимаюсь буквоедством.

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

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

VD>>Сравни это с примерами немерла, когда средствами метапрограммировния в язык вводятся констркции вроде for, while, foreach и даже средства типизированного доступа к SQL.
GZ>+1. Только я этого не увидел в статье.

Зашибись! А о чем тогда говорит раздел "Расширение синтаксиса"?
Снова пристум нежелания видеть?

В Nemerle выбран именно второй путь. В него введены синтаксические макросы, позволяющие реально расширять синтаксис языка.
Вот как выглядит реализация цикла while на Nemerle:

macro @while (cond, body)
syntax ("while", "(", cond, ")", body) 
{
  def loop = Nemerle.Macros.Symbol(Util.tmpname("while_"));

  <[ 
    $(PT.Name.Global("_N_break") : name) :
    {
      def $(loop : name)() : void
      {
        when ($cond)
        {
          $(PT.Name.Global("_N_continue") : name) :
          {
            $body 
          }

          $(loop : name)()
        }
      }

      $(loop : name)(); 
    }
  ]>
}

Этот простой макрос позволяет использовать в коде цикл while, полностью аналогичный таковому в C# и C++.
Интересно, что в Nemerle с помощью макросов реализованы return, break, continue, unchecked, checked, yield, if/else, while, repeat (вид цикла), when (замена if без else), for, unless (по сути, when(!...)), оператор using, lock, do/while, foreach, lambda (укороченный синтаксис для анонимных функций), а также операторы &&, ||, %|| (битовое «или» с проверкой на != 0), %&& (битовое «и» с проверкой на != 0), %^^ (XOR с проверкой на != 0), ++, --, +=, -=, *=, /=, <<=, >>=, %=, |=, &=, ^=, <-> (обмен значений переменных), ::= (модифицирующее добавление элемента в начало связанного списка).

В обещем, очереданая неправда.

VD>>Это разные статьи. И не нравится эта статья исключительно из религиозных чувств которые она затрагивает.
GZ>У меня с религиозными чувствами плоховато. Потому и занимаюсь буквоедством.

А чем вызвано буквоедство?

GZ>А я и есть начинающий. Правда сравнивать с C# мне было сложновато. Плохо клеится в мозгах. А вот сравнение с OCaml по тезисам этой статьи, мне далось легче.

Я не знаю ОКамл настолько чтобы делать качественное сравнение с этим языком. Хотя такое сравнение действительно было бы полезно и интересно. В прициипе кое что сравнивается в статье по макросам (сравнивается ОКамловский препроцессор). Сравнение с Шарпом же находится в первой статье (введении в язык). Она практически вся построена на отличиях от Шарпа. Так как основа языка действительно очень близкая. ОКамл тоже во многом близок. Но... в прочем я повторяюсь.

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

D>> Ты серьезно ждешь ответ на этот вопрос сексуального характера?

VD>Да, так как одозреваю, что это очередная фобия.

Да ладно тебе — во всем фобии видеть Ну не нравится мне байт-код и все. Хоть убей. Вопрос религии. Так что, думаю, не стоит джихады устраивать — у каждого же свой вкус, не так ли?

VD>>>Серьезно? И можешь даже аргументировать?

D>> Серьезно. Аргументировать не могу . Это вопрос вкусов вроде.

VD>Тогда не забывай делая такие заявления добавлять строчку вроде "мне кажется" или "для меня...".

В нетикете есть негласное правило — любое сообщение подразумевает, что это "мне кажется", "для меня", "имхо" и так далее..

VD>А то вдруг ты носитель тайного знания которое я пропустил.

Так оно и есть Но не в этой области.

D>> В делфи (и билдере) довольно хороший интерефейс для создания гуи,

VD>Извини, ты VS2005 то видел?

Нет.

D>> возможность наследовать формы,

VD>Есть и в VS 2002.

D>> офигенная поддержка разработки своих компонент с возможностью их отладки в design-тайме...

VD>Ну, про отлаку в дизайнтайм ты загнул. Для компонента это уже рантайм. Но в общем и целом разницы в отдадке и разработке компонентов я вилчно не вижу. Или вижу, но точно не в пользу дельфи. К тому же надо понимать, что разработка на безопасном языке с ЖЦ всегда надежнее чем на небезопасном и без ЖЦ. Так что не дотнетная Дельфи отдыхает по любому. А дотнетная мало чем отличается от Шарпа.

Все понятно. Если в студии все стало так хорошо, то ок. Но неважно. Мне все равно дельфи не нравится Особенно ее компонентная модель. Просто я сравнил реализацию там и в дотнете. В дельфи показалась более прямой.

D>> В дотнете меня поразил своей убогостью дизайнер и редактор свойств.

VD>Это от незнания. На самом деле он значительно лучше расширяется. Ну, а то что он не похож на павлина... дык на то есть C# Builder от Борланда или та же Delphi .NET. Крастоты не писанной как в прочем и глючности редкостной.

Глюки, они на каждом шаге от борладна


D>> Да, похоже на то как в делфи (один чувак все же автор ), но не то... Собственно, я об этом. РАД среда никакая для меня.

VD>Извини, но это проявление поверности знаний в данной области.

Погоди, какие могут быть поверхностные знания в этой области? Дизайнер просто неудобен. Выполнен в стиле микрософт, как редактор ресурса типа "диалог". Всегда плевался от него. Для меня это неприемлемо. Может быть в 2005 студии он уже обрел человеский вид?

VD>>>За одно расскажи как дельфи живет поверх того самого фрэймворка.

D>> Не понял...

VD>Ты не в курсе что начиная с Delphi.NET основной платформой для Дельфи является дотнет? Ну, ты что-то очень уж сильно отстал.

Не, в курсе. Просто я не использовал и, думаю, не буду Дельфи.Нет.
Так может не стоит высказывать такие вещи, что я отстал

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

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

VD>Это явная не правда. Все как раз доказано выше крыши. Причем еще не мной, а тем кто придумал лямбда-исчисления .
VD>Функция более общая вещь нежели нежели циклы. С++ все равно содержит функции. Лябда же более универсальная вещь чем функция. По сути фунция — это дямбда с которой ассоциировано некоторое имя. Так почему в С++ нет лямбды и ее унжно пытаться сэмулировать, но есть циклы и глобальные функции? Ответ очевиден — недальновидный дизайн и совместимось с еще более убогим дизайном С.
+1 Кстати, также камень в Microsoft. В С++, благодаря хреновенькому метапрограммингу и перегрузке скобок, хоть хреновенько но можно сделать. В C# 1.0 — никак. Пользуем только то, что дают. А нормальные лямбды еще не дали.

GZ>>Далее объяснения почему так все круто в Nemerle, и как легко сделать Nemerle императивным. И пример программирования макросов С++ с утверждением о его негигиеничности. Негигиенечность можно обойти (вставить что-нибудь типа __LINE__ и уже хорошо).
VD>Закат солнца в ручную?
Ага. Зато работает.

VD>Приношу свои извинения, что только разжевал и врот не положил. Но я привык ориентироваться на тех кто умеет думать. Хотя бы простейшие выводы точно читатель должен уметь сделать.
Мне это понятно. Но вот программисту С++, который всю жизнь прогорел на императивном языке, не помнит что такое функциональные языки, и который только слышал о boost::lambda — этот вывод может быть непонятен. А таких большинство.

GZ>>В остальном, абсолютно согласен. Хотя может быть и занимаюсь буквоедством.
VD>Даже не буквоедством, а докапыванием.
Maybe. От перемены слов смысл не меняется.

VD>>>Сравни это с примерами немерла, когда средствами метапрограммировния в язык вводятся констркции вроде for, while, foreach и даже средства типизированного доступа к SQL.
GZ>>+1. Только я этого не увидел в статье.
VD>Зашибись! А о чем тогда говорит раздел "Расширение синтаксиса"?
VD>В обещем, очереданая неправда.
Я как раз имел ввиду предыдущий пункт. Три раза каюсь. Неправильно отформатировал. Имелось вот это:

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

Сравнение систем метапрограммирования boost::lambda (для повторения функционального стиля). То бишь если одно умеет повторять другое, почему другое не может повторить первого. И насколько оно шизофренично.

VD>А чем вызвано буквоедство?
Наверно той двухсмысленностью "ошибок C++-ников". На всякий случай довернул по почкам. И вообще у них не было ошибки. Они не делали идеальный язык (иначе нужно было бы забыть о С). Они делали популярный язык. И это им удалось на пять с плюсом.

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

GZ>+1 Кстати, также камень в Microsoft. В С++, благодаря хреновенькому метапрограммингу и перегрузке скобок, хоть хреновенько но можно сделать. В C# 1.0 — никак. Пользуем только то, что дают. А нормальные лямбды еще не дали.

Тут оно как... Ты считашь, что это камень. А я ь(и видимо создатели Шарпа) считаю, что это как раз достоинство. Язык позволят только то, что запланировано. И позволяет это на 5 балов. Метапрограммирования в нем просто нет. Если добавят — будет, но пока нет. И прекрасно, что нет страшных побочных эффектов позволяющих эмулировать отсуствующую функциональность. Иначе когда авторы соберутся ввести ее, то она будет конфликтовать с непродуманной гибкостью.

GZ>>>Далее объяснения почему так все круто в Nemerle, и как легко сделать Nemerle императивным. И пример программирования макросов С++ с утверждением о его негигиеничности. Негигиенечность можно обойти (вставить что-нибудь типа __LINE__ и уже хорошо).
VD>>Закат солнца в ручную?
GZ>Ага. Зато работает.

Не, не работает. Разумный человек просто плюнет чем связаываться с такими извратами.

GZ>Я как раз имел ввиду предыдущий пункт.

Странный ход... Рачленить статью и сетовать на то, что в части "а" чего-то нехватает при том, что в части "б" это есть.

VD>>А чем вызвано буквоедство?
GZ>Наверно той двухсмысленностью "ошибок C++-ников". На всякий случай довернул по почкам. И вообще у них не было ошибки. Они не делали идеальный язык (иначе нужно было бы забыть о С). Они делали популярный язык. И это им удалось на пять с плюсом.

Значит, так. Или надо признать ошибочными (для С++) те лозунги которые были приведены мной в начале статьи, или прийдется признать, что реализация этих лозунгов в С++ весьма посредственна и неполноценна.

ЗЫ

Я и раньше не пог понять почему в С++ нет делегатов. Все доказательства того, что они не нужны в зяке явно выглядили натянуто. Увидив подход Немерловцев я понял, что моя ошибка была в том, что я говорил именно о делегатах. Функции высшего порядка более общая обстракция. Делегаты только один из вариантов ее реализации. Именно их не хватало в С++ (полноценных, а не тех потух в виде С-указателей на функции и весьма странных извращений С++ в вдие указатели на члены).

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

D> Да ладно тебе — во всем фобии видеть Ну не нравится мне байт-код и все. Хоть убей. Вопрос религии.

Вот именно, религии.

D> Так что, думаю, не стоит джихады устраивать — у каждого же свой вкус, не так ли?

Не так. Религия фиговый спутник для IT.

D> В нетикете есть негласное правило — любое сообщение подразумевает, что это "мне кажется", "для меня", "имхо" и так далее..

Ссылку плиз на такое правило.

VD>>Извини, ты VS2005 то видел?

D> Нет.

Тогда что ты сравнивашь? VS6 и Delphi 6?

D> Погоди, какие могут быть поверхностные знания в этой области? Дизайнер просто неудобен. Выполнен в стиле микрософт, как редактор ресурса типа "диалог". Всегда плевался от него. Для меня это неприемлемо. Может быть в 2005 студии он уже обрел человеский вид?

У меня ощущение, что я разговариваю со спящей красавицей которая застула в 1998-ом и проснулась только сейчас. Уже в VS 2002 был очень неплохой дизайнер форм для C# и VB.NET. А в VS 2005 он стал еще лучше.

VD>>Ты не в курсе что начиная с Delphi.NET основной платформой для Дельфи является дотнет? Ну, ты что-то очень уж сильно отстал.

D> Не, в курсе. Просто я не использовал и, думаю, не буду Дельфи.Нет.
D> Так может не стоит высказывать такие вещи, что я отстал

Ты сам это даешь понять. Твои завяления весьма странны. И вообще это уход от темы. Мы говорили о С++ и подпорках которые ему нужны чтобы сделать хотя бы дизайнеры ГУИ. Дельфи и дотнет в таких подпорках не нуждаются, и нет смысла в этом их противопоставлять. Оба продукта исповедуют компонентный подход который отлично ложится на всякого рода дизайнеры.

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

VD>Тут оно как... Ты считашь, что это камень. А я ь(и видимо создатели Шарпа) считаю, что это как раз достоинство. Язык позволят только то, что запланировано. И позволяет это на 5 балов.
Это ты про C#3.0?
VD>Метапрограммирования в нем просто нет. Если добавят — будет, но пока нет. И прекрасно, что нет страшных побочных эффектов позволяющих эмулировать отсуствующую функциональность. Иначе когда авторы соберутся ввести ее, то она будет конфликтовать с непродуманной гибкостью.
В С++ такой проблемы не стоит. А вот нормальную перегрузку операторов сделать, стоило бы.

GZ>>Ага. Зато работает.
VD>Не, не работает. Разумный человек просто плюнет чем связаываться с такими извратами.
Человек разумный пользуется и не такими извратами, лишь бы достичь своей цели.

VD>>>А чем вызвано буквоедство?
GZ>>Наверно той двухсмысленностью "ошибок C++-ников". На всякий случай довернул по почкам. И вообще у них не было ошибки. Они не делали идеальный язык (иначе нужно было бы забыть о С). Они делали популярный язык. И это им удалось на пять с плюсом.
VD>Значит, так. Или надо признать ошибочными (для С++) те лозунги которые были приведены мной в начале статьи, или прийдется признать, что реализация этих лозунгов в С++ весьма посредственна и неполноценна.
Второе.

VD>Я и раньше не пог понять почему в С++ нет делегатов. Все доказательства того, что они не нужны в зяке явно выглядили натянуто. Увидив подход Немерловцев я понял, что моя ошибка была в том, что я говорил именно о делегатах. Функции высшего порядка более общая обстракция. Делегаты только один из вариантов ее реализации. Именно их не хватало в С++ (полноценных, а не тех потух в виде С-указателей на функции и весьма странных извращений С++ в вдие указатели на члены).
Во первых, я бы назвал аналогом функторы. Ну а во вторых, есть идеологическая пропасть между функциональным и императивным программированием. Безусловно, любой функциональный язык должен уметь оптимизировать рекурсию. Процессоры вкупе с OS успешнее работают с последовательными программами. Но для императива такая оптимизация значительно сложней. Трудно раскрутить рекурсию, если у тебя изменяются глобальные данные. Функциональные программы — не поощряют изменения глобальных данных(взять тот же mutable в Nemerle). Для императива это одна из основных особенностей. Поэтому, IMHO, полностью универсального, и функционального и императивного, эффективного компилятора не может быть. И функции высшего порядка, в основном, в императивных языках так и останутся по сложности на уровне Fold.

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

VD>Здравствуйте, Андрей Хропов, Вы писали:

VD>>> Так что это задача для кого-то другого.
АХ>>Ну вот тут

Автор: fionbio
Дата: 12.07.05

человек интересующийся писал, может поможет ?

VD>Проблема в том, что у Личпарей обычно нулевой скил в области Немерла и нулевое же влечение к дотнету и всем что с ним связано.

Что-то я не вник, кого с кем надо сравнивать. Если C++ с CL, то пожалуйста.

По поводу дотнета — я профессиональный дотнетчик, и чем больше с годами набираюсь опыта по работе
с этой платформой, тем с большим презрением к ней отношусь Такое чувство, что изначально
было задумано сравнительно не плохо (хотя лучше бы не задумывалось вообще), а потом посадили толпу
обезьян, дали им нереальные сроки и вперёд... (кто не верит, больше юзайте Рефлектор )

VD>Яд который я пью — грузинский коньяк и грузинское вино у нас сегодня отобрали. Так что до тех пор пока он к нам не вернется прийдется влачить существование трезвиника.

Могу привезти, у нас тут ентого добра — полно

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

F>По поводу дотнета — я профессиональный дотнетчик, и чем больше с годами набираюсь опыта по работе с этой платформой, тем с большим презрением к ней отношусь Такое чувство, что изначально было задумано сравнительно не плохо (хотя лучше бы не задумывалось вообще), а потом посадили толпу обезьян, дали им нереальные сроки и вперёд... (кто не верит, больше юзайте Рефлектор )

Есть такое дело. Но, надо признать, платформа держит пока даже толпы обезъян и пока живёт. В любом случае, будущее за управляющими средами.

А по поводу рефлектора... Не надо туда смотреть без нужны. Не для слабонервных это

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

IT>>Сколько уже можно повторять, основан он не на свойстве метапрограммирования шаблонов, а на сайд эффектах компилятора. Впрочем, возможно это теперь называется "Свойство Метапрограммирования".
GZ>Это вопрос относительности. Можно назвать side — эффект.

Ты знаешь, здесь я встану на сторону VladD2, IT и прочих апологетов дот-нетщины. Шаблоны — это замечательно и я их вполне успешно использую. Но вот буст — не понимаю. Не имеет он для меня ни малейшей пректической ценности. В качестве головоломных упражнений — замечательно, но не более того. Когда ради какой-то приблуды типа boost::tuple написано пару тыщ строк кода, которые со скрипом компилируются, значит что-то здесь не то. Это явный признак того, что язык используется не по назначению. Буст давно превратился в помойку, в которй многократно превышен разумный предел терпимости. Более-менее сложные проекты с бустом собираются часами — и это уже ни в какие ворота не лезет.

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

IT>Есть такое дело. Но, надо признать, платформа держит пока даже толпы обезъян и пока живёт. В любом случае, будущее за управляющими средами.

"... а идея, брошеная в массы,
это девка, брошеная в полк..."
И. Губерман

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

MS>Шаблоны — это замечательно и я их вполне успешно использую. Но вот буст — не понимаю. Не имеет он для меня ни малейшей пректической ценности. В качестве головоломных упражнений — замечательно, но не более того.

Высокоуровневые абстракции == головоломные упражнения. Отличное сравнение! Мне на работе тоже один маньяк выговорил за использование ScopeGuard вместо ручного управления ресурсами. Подавай ему "if (FAILED(hr)) goto error; error: LocalFree(...)" и всё тут! Не будем фигурять!

> Когда ради какой-то приблуды типа boost::tuple написано пару тыщ строк кода, которые со скрипом компилируются, значит что-то здесь не то. Это явный признак того, что язык используется не по назначению. Буст давно превратился в помойку, в которй многократно превышен разумный предел терпимости. Более-менее сложные проекты с бустом собираются часами — и это уже ни в какие ворота не лезет.

Tuple включён в TR1, а от туда и в C++0x Standard Library. Пугаться нужно было раньше, где-то с момента появления на свет STL. Если по ночам снятся кошмары, может стоит сменить язык программирования?