Мои пять козявок на тему Почему у Nemerle нет будущего - Компьютерные священные войны

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

E>Ой ли? Имхо, она говорит, что "Ребята, вокруг много людей, которые совсем не такие умные как вы. Если вы хотите, чтобы Nemerle пошел дальше, чем научная работа и не повторил судьбу Oberon-ов, Modul-ов и пр., то будьте проще и люди к вам потянуться".

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

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

Причём, умные люди тоже бывают разные. Одни и без инструмента обойдутся — сами себе идеальный инструмент играючи создадут из подножного корма. Другие возьмут Common Lisp или ещё какую подобную тяжелую артиллерию. Те, кто менее опытен, но не менее умён, уже, увы, остаются без игрушки — и как раз им Nemerle и пришелся очень вовремя, как манна небесная. Конечно же приятно помечтать, что все вдруг станут умными и хорошими, такими, как они, и тогда Nemerle и все другие подобные технологии мигом станут популярными (ну, у Nemerle будет шанс исчезнуть в силу резкого падения популярности платформы .NET). Но ведь это только мечты, большинство людей умными не станут никогда. Так зачем же пытаться загнать умных в рамки большинства, отобрать у них хороший инструмент и сделать простую и примитивную долбилку для идиотов?

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

E> Т.е. нужно учится, учится и еще раз учится.

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

E> И может быть кто-то сможет объяснить, какие факторы не позволят функциональность Nemerle употребить во вред?

Такие, что написанную на Nemerle функциональность вредоносные люди будут дёргать из кода, написанного ими на Visual Basic, языке, разработанном специально для таких, как они.

K>>А то что создатели Немерле не выставляют себя умниками и не делают эзотерический язык, лично для меня видно и из материалов сайта и из дизайна самого языка.

E>Про то, что создатели Nemerle выставляю себя умниками я и не утверждал. Мое мнение в том, что они делают язык для людей своего уровня. А таких немного по определению.

И такие, по твоему, и без инструмента обойдутся? Кто-то ведь должен делать НАСТОЯЩИЕ инструменты. Не всем же совковые лопаты лабать.

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

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

А если тебе не нужен язык? Если нужно сразу много языков, и ты не знаешь, каких именно? Как тут без макросов?

G> Инженеры из моего отдела придерживаются такого же мнения.

Они не в теме. Некомпетентны.

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

E>>Про то, что создатели Nemerle выставляю себя умниками я и не утверждал. Мое мнение в том, что они делают язык для людей своего уровня. А таких немного по определению.

W> И такие, по твоему, и без инструмента обойдутся? Кто-то ведь должен делать НАСТОЯЩИЕ инструменты. Не всем же совковые лопаты лабать.

В ответ на это и на предыдущие ваши сообщения: я считаю, что должны быть сложные и мощные инструменты. Я знаю, что успешно, эффективно и без больших проблем такие инструменты будут использоваться небольшими высокопроффесиональными командами (в которых умные люди не могу поглупеть из-за стадного инстинкта). Что для некоторых проектов именно формула "идея + маленькая команда + мощный инструмент" является залогом успеха. Но, такой инструмент не может быть широко распространенным (популярным). По определению. И Nemerle похож на такой мощный но не простой инструмент. А если это действительно так (если, поскольку только время и жизнь расставит все на свои места), то и ему распростаненность и популярность не грозит (но это не есть "отсутствие будущего"). О чем я и сказал в теме, которая была посвящена проблемам будущего Nemerle.

Так что я в большей степени согласен с вашими замечаниями, чем вам это может показаться.

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

G>Если бы "убогость" == "отсутствие макросов" — то я бы сказал, что это возражение. Я не выставлял убогость в качестве свойства, повышающего maintainability. Я выдвинул тезис, что макросы его ухудшат, потому что люди есть люди, они такие, какие есть (криворукие), и что хорошему языку макросы не нужны. Готов поспорить с возражениями к этим тезисам.

хотелось бы узнать ваше мнение. tex -- это плохой язык, или нет?

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

G>Это — минус

+1

G>Ну, я почитал ветку, и типовые вопросы. Из того, что я видел — чаще всего упоминаются именно макросредства, процентов на 99.

+1

Win2k wrote:
> G> Мое мнение другое — *хорошему языку макросы не нужны,* там должно
> быть и без них комфортно. Если от макросов есть заметный плюс — что-то
> не так с самим языком.
> А если тебе не нужен язык? Если нужно сразу много языков, и ты не
> знаешь, каких именно? Как тут без макросов?
Пишешь компилятор — и вперед. А еще лучше — берется какой-нибудь
интерпретатор с гибким синтаксисом и прикручивается.

> G> Инженеры из моего отдела придерживаются такого же мнения.
> Они не в теме. Некомпетентны.
Ага, конечно. Вероятно хорошо развиты телепатические способности.

Posted via RSDN NNTP Server 2.0

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

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

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

W> А если тебе не нужен язык? Если нужно сразу много языков, и ты не знаешь, каких именно? Как тут без макросов?
Честно? Мое ИМХО — если не знаешь, каких именно, но при этом почему-то точно знаешь, что нужно много языков — я бы посоветовал бросить программирование, лучше заняться чем-нибудь другим.

G>> Инженеры из моего отдела придерживаются такого же мнения.
W> Они не в теме. Некомпетентны.

Гхм. Как мне повезло — не часто встретишь в форуме такого компетентного гуру, как Вы.

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

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

G>>Если бы "убогость" == "отсутствие макросов" — то я бы сказал, что это возражение. Я не выставлял убогость в качестве свойства, повышающего maintainability. Я выдвинул тезис, что макросы его ухудшат, потому что люди есть люди, они такие, какие есть (криворукие), и что хорошему языку макросы не нужны. Готов поспорить с возражениями к этим тезисам.

NB>хотелось бы узнать ваше мнение. tex -- это плохой язык, или нет?
Я не оперирую понятиями добра и зла, так что не могу однозначно сказать "плохой" tex язык или нет. Но, скажем, решать на нем численно диффуры я бы не стал, как и писать на нем веб-сервер. Т.е. тех — это не совсем тот язык, который стоило бы приводить в пример. Макроассемблер гораздо лучший пример — на нем много софта писали в 70-е.

Также, хочу заметить, что
1) ядро tex писалось одним человеком (Кнутом), и maintainability тут не особо играет. Ну и кроме того, кнут это кнут. Он, зараза, пишет почти без ошибок на чем угодно.
2) Пользователи теха обычно не определяют своих макросов — все расширения теха стандартизованы (Latex, например, или AMStex).
3) Обработка и генерация текстов по сути своей состоит из [макро]замен и подстановок. Тех имеет больше общего со всякими XSLT, которые при большой фантазии тоже можно назвать "макросами". Когда тех интерпретирует исходный файл, он запускает макросы, преобразуя исходный текст в другой. Когда я пишу в корпоративную вики, я тоже люблю определять макросы, чтобы облегчиь разметку текста. Когда вы пишете статью — пользоваться макросами естественно. Только программная система — не статья.

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

G>>>Если бы "убогость" == "отсутствие макросов" — то я бы сказал, что это возражение. Я не выставлял убогость в качестве свойства, повышающего maintainability. Я выдвинул тезис, что макросы его ухудшат, потому что люди есть люди, они такие, какие есть (криворукие), и что хорошему языку макросы не нужны. Готов поспорить с возражениями к этим тезисам.

NB>>хотелось бы узнать ваше мнение. tex -- это плохой язык, или нет?
G>Я не оперирую понятиями добра и зла, так что не могу однозначно сказать "плохой" tex язык или нет.

Спрошу по-другому, tex -- это хороший язык (учитывая выделенное), или нет?

G>Но, скажем, решать на нем численно диффуры я бы не стал, как и писать на нем веб-сервер. Т.е. тех — это не совсем тот язык, который стоило бы приводить в пример. Макроассемблер гораздо лучший пример — на нем много софта писали в 70-е.

Спросил про тех, потому что догадываюсь о вашем отношении к ниму

Без макросов он был бы совсем другим.

G>Также, хочу заметить, что
G>1) ядро tex писалось одним человеком (Кнутом), и maintainability тут не особо играет. Ну и кроме того, кнут это кнут. Он, зараза, пишет почти без ошибок на чем угодно.

но используют его не только Кнут.

G>2) Пользователи теха обычно не определяют своих макросов — все расширения теха стандартизованы (Latex, например, или AMStex).

Да. Именно мощьная система макросов позволила создать Латех.
Почемы вы лишаете такой возможности другие языки.
Кстати, только не говорите что у вас нет своих макросов. Их делает каждый, кто прочел "Все про тех"

G>3) Обработка и генерация текстов по сути своей состоит из [макро]замен и подстановок. Тех имеет больше общего со всякими XSLT, которые при большой фантазии тоже можно назвать "макросами". Когда тех интерпретирует исходный файл, он запускает макросы, преобразуя исходный текст в другой. Когда я пишу в корпоративную вики, я тоже люблю определять макросы, чтобы облегчиь разметку текста. Когда вы пишете статью — пользоваться макросами естественно. Только программная система — не статья.

Здесь не спорю. Однако если один подход успешно работает в одной области, почему бы не применить его в другой?

PS: мне не очень нравятся истерические вопли вокруг Nemerle, но сам то язык в этом не виноват. Думается, его проблемы не в макросистеме.

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

>> А если тебе не нужен язык? Если нужно сразу много языков, и ты не
>> знаешь, каких именно? Как тут без макросов?
C>Пишешь компилятор — и вперед.

Долго и дорого. А с макросами у нас уже есть на халяву хороший компилятор.

C> А еще лучше — берется какой-нибудь
C>интерпретатор с гибким синтаксисом и прикручивается.

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

>> G> Инженеры из моего отдела придерживаются такого же мнения.
>> Они не в теме. Некомпетентны.
C>Ага, конечно. Вероятно хорошо развиты телепатические способности.

Весьма хорошо развиты. Вы угодали. Возможно и у вас в своё время проявятся в полную силу.

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

E>Но, такой инструмент не может быть широко распространенным (популярным).

И хвала Аллаху за это.

E> По определению. И Nemerle похож на такой мощный но не простой инструмент.

Не похож. Он таковым просто является.

E> А если это действительно так (если, поскольку только время и жизнь расставит все на свои места), то и ему распростаненность и популярность не грозит (но это не есть "отсутствие будущего").

Не грозит. Если б грозила, я б его и смотреть не стал — зачем вскакивать на поезд, который потом неизбежно пойдёт под откос? Я рад, что с Питона соскочил довольно рано, до того ещё, как пошли разговоры про "на фиг lambda, на фиг reduce".

E>Так что я в большей степени согласен с вашими замечаниями, чем вам это может показаться.

Ok, fixed.

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

NB>Спрошу по-другому, tex -- это хороший язык (учитывая выделенное), или нет?

Да, но это не язык программирования в обычном смысле этого слова, сравнивать некорректно

.

G>>Но, скажем, решать на нем численно диффуры я бы не стал, как и писать на нем веб-сервер. Т.е. тех — это не совсем тот язык, который стоило бы приводить в пример. Макроассемблер гораздо лучший пример — на нем много софта писали в 70-е.

NB>Спросил про тех, потому что догадываюсь о вашем отношении к ниму

NB>Без макросов он был бы совсем другим.

NB>Да. Именно мощьная система макросов позволила создать Латех.
NB>Почемы вы лишаете такой возможности другие языки.

Конечно. Макросы и [макро]замена — естественная вещь для обработки текста, к этому сводится сама суть его обработки. Слава богу, на семантику самого текста макросы теха не влияют, не так-ли (поэтому на его понимании не сказываются)? Этим они и отличаются от макросов в языках программирования.

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

G>>3) Обработка и генерация текстов по сути своей состоит из [макро]замен и подстановок. Тех имеет больше общего со всякими XSLT, которые при большой фантазии тоже можно назвать "макросами". Когда тех интерпретирует исходный файл, он запускает макросы, преобразуя исходный текст в другой. Когда я пишу в корпоративную вики, я тоже люблю определять макросы, чтобы облегчиь разметку текста. Когда вы пишете статью — пользоваться макросами естественно. Только программная система — не статья.

NB>Здесь не спорю. Однако если один подход успешно работает в одной области, почему бы не применить его в другой?
Ну вот это и есть ответ на ваши вопросы — почему я возражаю против аналогии с тех-ом, вроде вы с этим согласны. Конкретные примеры я привел в http://rsdn.ru/Forum/Message.aspx?mid=2050485&only=1

NB>PS: мне не очень нравятся истерические вопли вокруг Nemerle, но сам то язык в этом не виноват. Думается, его проблемы не в макросистеме.
Не знаю, в чем его проблемы, и это не особенно мне интересно. Я возражаю против конкретного пункта, вокруг которого истерика — макросы.

Win2k wrote:
>> > А если тебе не нужен язык? Если нужно сразу много языков, и ты не
>> > знаешь, каких именно? Как тут без макросов?
> C>Пишешь компилятор — и вперед.
> Долго и дорого. А с макросами у нас уже есть на халяву хороший компилятор.
Не "на халяву". С помощью макросов просто можно сделать только
простенькие примеры. Чего-то нестандартное (типа создания логического
языка, например) будет уже того же порядка сложности, что и написание
отдельного компилятора.

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

> C> А еще лучше — берется какой-нибудь
> C>интерпретатор с гибким синтаксисом и прикручивается.
> То есть — таки макросы, да? Да и медленно это, не всегда интерпретатор
> выдюжит задачу.
Не макросы, просто интерпретатор. Это проще и быстрее.

Может для каких-то очень специфичных задач макросы и подходят, но я их
пока что-то не вижу.

Posted via RSDN NNTP Server 2.0

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

NB>>Да. Именно мощьная система макросов позволила создать Латех.
NB>>Почемы вы лишаете такой возможности другие языки.

G>Конечно. Макросы и [макро]замена — естественная вещь для обработки текста, к этому сводится сама суть его обработки.

Тогда еще вопрос. Зачем нужны макросы.
ИМХО, они позволяют
1. избежать дублирования кода.
2. описывать проблему в терминах этой самой проблемы.

Что из перечисленного мешает сопровождению кода.

G>Слава богу, на семантику самого текста макросы теха не влияют, не так-ли (поэтому на его понимании не сказываются)? Этим они и отличаются от макросов в языках программирования.

Тут не совсем ясно, что есть семантика теховского текста.
Например пакет listings меняет семантику, или нет?

G>>>3) Обработка и генерация текстов по сути своей состоит из [макро]замен и подстановок. Тех имеет больше общего со всякими XSLT, которые при большой фантазии тоже можно назвать "макросами". Когда тех интерпретирует исходный файл, он запускает макросы, преобразуя исходный текст в другой. Когда я пишу в корпоративную вики, я тоже люблю определять макросы, чтобы облегчиь разметку текста. Когда вы пишете статью — пользоваться макросами естественно. Только программная система — не статья.

NB>>Здесь не спорю. Однако если один подход успешно работает в одной области, почему бы не применить его в другой?
G>Ну вот это и есть ответ на ваши вопросы — почему я возражаю против аналогии с тех-ом, вроде вы с этим согласны. Конкретные примеры я привел в http://rsdn.ru/Forum/Message.aspx?mid=2050485&only=1

я наверное тупой.

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

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

NB>Тогда еще вопрос. Зачем нужны макросы.
NB>ИМХО, они позволяют
NB>1. избежать дублирования кода.
Самые обычные функции с этим прекрасно справляются.

NB>2. описывать проблему в терминах этой самой проблемы.
Адекватный выбор идентификаторов прекрасно позволяет это сделать.

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

NB>Что из перечисленного мешает сопровождению кода.

Примеры мои смотрел? Или я впустую пишу?

NB>>>Здесь не спорю. Однако если один подход успешно работает в одной области, почему бы не применить его в другой?
G>>Ну вот это и есть ответ на ваши вопросы — почему я возражаю против аналогии с тех-ом, вроде вы с этим согласны. Конкретные примеры я привел в http://rsdn.ru/Forum/Message.aspx?mid=2050485&only=1

NB>я наверное тупой.

NB>не понимаю, что мешает перенести плюсы теха на другие языки.
Нет, это я, наверное, тупой. Либо ты не внимательно читал пример. И так уже все разжевал настолько, насколько это ИМХО возможно, больше не могу, извини.

NB>гибкость теха позволяет писать запутанный текст. но это не делает его плохим языком.
NB>сообщество выработало стиль, устраняющий эту проблему.
NB>что препятствут другим пойти этим путем?
Ничего. Иди этим путем. В третий раз подряд объяснять разницу между тех-ом и языками программирования у меня нет сил, извини. Пиши с макросами, я не против.

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

NB>>Тогда еще вопрос. Зачем нужны макросы.
NB>>ИМХО, они позволяют
NB>>1. избежать дублирования кода.
G>Самые обычные функции с этим прекрасно справляются.

ну вот из последнего

#define MAKE_BINARY_OP(NAME,name,T1,OP,T2,RET) \
  struct NAME : lambda::Lambda<NAME>           \
  {                                            \
...
  } const name = NAME ();                      \
                                               \
  template< typename T1,typename T2 >          \
  lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > operator OP ( T1 const & x, T2 const & y ) { \
    return lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > ( name, lambda::make_tuple (x,y) ); \
  }

MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)

как сделать с помощью функций?

NB>>2. описывать проблему в терминах этой самой проблемы.
G>Адекватный выбор идентификаторов прекрасно позволяет это сделать.

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

NB>>Что из перечисленного мешает сопровождению кода.

G>Примеры мои смотрел? Или я впустую пишу?

ладно, давай рассмотрим.

a = b + c + d

что предлагается взамен?

NB>>гибкость теха позволяет писать запутанный текст. но это не делает его плохим языком.
NB>>сообщество выработало стиль, устраняющий эту проблему.
NB>>что препятствут другим пойти этим путем?
G>Ничего. Иди этим путем. В третий раз подряд объяснять разницу между тех-ом и языками программирования у меня нет сил, извини. Пиши с макросами, я не против.

спасибо тебе, добрый человек.

у меня без твоего разрешения работа стояла...

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

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

NB>>>Тогда еще вопрос. Зачем нужны макросы.
NB>>>ИМХО, они позволяют
NB>>>1. избежать дублирования кода.
G>>Самые обычные функции с этим прекрасно справляются.

NB>ну вот из последнего
NB>

NB>#define MAKE_BINARY_OP(NAME,name,T1,OP,T2,RET) \
NB>  struct NAME : lambda::Lambda<NAME>           \
NB>  {                                            \
NB>...
NB>  } const name = NAME ();                      \
NB>                                               \
NB>  template< typename T1,typename T2 >          \
NB>  lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > operator OP ( T1 const & x, T2 const & y ) { \
NB>    return lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > ( name, lambda::make_tuple (x,y) ); \
NB>  }

NB>MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
NB>MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)
NB>

NB>как сделать с помощью функций?

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

NB>>>Что из перечисленного мешает сопровождению кода.

G>>Примеры мои смотрел? Или я впустую пишу?

NB>ладно, давай рассмотрим.
NB>

NB>a = b + c + d
NB>

NB>что предлагается взамен?
Ты объясни по человечески, что ты от меня хочешь, ок? Пока я вижу, что ты вырываешь фразы из контекста (вне контекста они теряют смысл), и задаешь короткие вопросы, которые мне кажутся глупыми, их смысл мне не понятен. Дурацкие споры я уже год как вести устал, и спорить с тобой не буду.

NB>>>гибкость теха позволяет писать запутанный текст. но это не делает его плохим языком.
NB>>>сообщество выработало стиль, устраняющий эту проблему.
NB>>>что препятствут другим пойти этим путем?
G>>Ничего. Иди этим путем. В третий раз подряд объяснять разницу между тех-ом и языками программирования у меня нет сил, извини. Пиши с макросами, я не против.

NB>спасибо тебе, добрый человек.

NB>у меня без твоего разрешения работа стояла...

Так ты обращайся почаще с вопросами "что препятствует идти путем", я тебе завсегда отвечу.

Мне совершенно все равно, каким путем тебе идти — зачем мне об этом спорить?

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

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

VD>Ява отнюдь не примитивный язык. Ява 1.5 вообще-то еще тот монстрик. Вложенные классы с замыканиями, безымянные классы, дженерики, сахар вроде foreach...

Вложенные классы и анонимные классы были в Java очень давно, чуть ли не с рождения.

VD>Простой пример (чтобы не быть голословным). Оператор foreach в Немерле несомненно позаимтвован из C# (и опосредовано из Питона). Однако гибкость макросов позволила со временем расширить функциональность foreach сделав его в разы мощьнее. Так foreach в руби позволяет осуществлять сопоставление с образцом и даже вводить допольнительные проверки для элемента перебераемой последовательности.

забавная описка, однако.

VD>

VD>// Вариант сопоставления с образцом со множеством образцов.
VD>foreach (x in collection) 
VD>{
VD>    | SomeVariant.Value1("SomeName", AnotherVariant.Some2(weight)) as x =>
VD>        WriteLine($"x containes name="SomeName" weight=$weight");
        
VD>    | SomeVariant.Value1(name, AnotherVariant.Some1(size)) as x =>
VD>        WriteLine($"x containes name=$name size=$size");
VD>    | => ()
VD>}        
VD>

понятность этого фрагмента лично у меня вызывает большие сомнения

E>> Сборную солянку из императивных, функциональных и объектно-ориентированных возможностей, да еще и с супер-мета-программированием в придачу.

VD>Конечно можно подходить и с этой стороны. Тогда правда все языки которые ты лично исползуешь (С++ и Руби) являются классическими представителями таких сборных солянок. Так что тебя это так возмущает в Немерле и совем не трогает в С++ и Руби?

Кто тебе сказал, что не трогает. Очень даже трогает. C++ и Ruby -- это языки для маленьких команд, на них удобно делать проекты в одиночку или с двумя-тремя коллегами. Но, как только в команду попадает слабый разработчик или кто-то помещает в проект отстойный (например, из-за нехватки времени) код, то все, приплыздец натупает.

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

Правда действительно тривиальна. К Nemerle я уже давно отношусь очень спокойно. Из-за своей .NET-овской привязки он просто-напросто лежит в стороне от моих интересов.

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

VD>Ну, что скажите мне на милость, плохого в том, что я могу выбрать наиболее подходящий стиль для той или иной задачи. Задача хорошо решается методами ООП? Отлично! У нас есть классы, интерфейсы, наследование и инкапсуляция. Задачу тяготеет к обработке иерархий или списков? Тогдща в нашем распоряжении варианты и паттерн-матчинг. Задача требует кучи монотонной тупой ручной работы? Метапрограммирование в нашем распоряжении.

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

K>>>Вы считаете, что Oberon не получил распространение тоже потому, что он для сильно умных?

E>>Нет. Есть такой феномен: популярность получают языки, которые создаются для работы, для удовлетворения своих собственных сиюминутных нужд. C, C++, Perl, Python, Ruby, Java (наверное и C# сюда же попадает). Как только к языку прикладывается какая-то наука (Pascal, Oberon) или комитет (Ada), как все сразу портится.

VD>Ну, вторую версию (ту что вошла в стандарт) С++ как раз разрабатывал комит.

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

VD>Да и Паскаль сыскал невероятную популярность в свое время. Так что ты лукавишь.

Тот паскаль, который стал популярным в виде Turbo Pascal/Borland Pascal/Dephi и Object Pascal на MacOS был очень сильно модернизированным вариантом исходного Виртовского паскаля. И эти модернезированные варианты отнюдь не коммитеты и не ученые делали.

VD>Но главное заключается в том, что ты уходишь от смысла вопроса. Смысл этого вопроса я вижу в том, что Оберон как раз замечательно удовлетворяет вашему с Гапертоном мнению о том, что в языке не должно быть ничего что может быть неоднозначно истолковано и что может запутать код. Оберон прост как три копейки. Напротив C++, Perl, Python, Ruby, Java и C# (без каких бы то нибыло наверное) как раз не удовлетворяют вашим критериям. И они как не странно популярны. Причем до сих пор популярность С++ очень высока, а уж этот язык точно обладает массой средств запутывания не говоря уже об откровенных граблях и просчетах.

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

E>>Чем это объясняется я не знаю, но факты упрямая вещь.

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

Тогда объясни, что произошло с Ada. И с Eiffel.

VD>Они неплохо программируют на МЛ. Так что язык подходящий им уже был. Просто они увидили реальные потребности программистов (по крайней мере немалой их части) и попытались сделать язык так как они это видят. Мне кажется у них получилась очень неплохая работа.

Еще раз. Речь не о том, плохо ли у них получилось или хорошо. Речь о том, будет ли результат их труда широко востребован или нет. Как показывает практика, качество самого языка при этом играет не столь существенную роль.

NB>#define MAKE_BINARY_OP(NAME,name,T1,OP,T2,RET) \
NB>  struct NAME : lambda::Lambda<NAME>           \
NB>  {                                            \
NB>...
NB>  } const name = NAME ();                      \
NB>                                               \
NB>  template< typename T1,typename T2 >          \
NB>  lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > operator OP ( T1 const & x, T2 const & y ) { \
NB>    return lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > ( name, lambda::make_tuple (x,y) ); \
NB>  }

NB>MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
NB>MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)
NB>

NB>как сделать с помощью функций?

Лямбда должна поддерживаться языком. И тогда этот ужас просто не нужен. Тем более, что нормальную лямбду ты все равно не сделаешь, хоть обложись макросами — все равно в мало-мальски сложном случае придется объявлять функтор. Пример твоего кода — это как раз такой код, которого в продакшне я видеть не хочу ни под каким видом. Тебя же я переубеждать не собираюсь — это твое дело, как писать. Спорить я с тобой тоже не буду, я уже объяснил, чем такой код с моей точки зрения плох, достаточно доходчиво, чтобы не отвечать в десятый раз на вопросы "почему" — кому надо тот поймет. Ты не обижайся, ничего личного. Это нормально, когда кто-то несогласен со мной или с тобой. Я тебя понимаю прекрасно, возможно и ты поймешь меня когда-нибудь.

От:	Gaperton	http://gaperton.livejournal.com
Дата:	17.08.06 21:47
Оценка:	+2 -1

	От:	Win2k
	Дата:	17.08.06 23:50
	Оценка:

	От:	Win2k
	Дата:	17.08.06 23:58
	Оценка:

	От:	Win2k
	Дата:	18.08.06 00:01
	Оценка:	-1

От:	eao197	http://eao197.blogspot.com
Дата:	18.08.06 04:04
Оценка:

	От:	Cyberax
	Дата:	21.08.06 08:19
	Оценка:	+2