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

_>Сам макрос выглядит мягко говоря сложно для того, чтобы писать такие в каких-то повседневных целях.

Это грамматика нового языка. Для такой задачи совершенно не сложно. Сложно, в первую очередь, читать непривычный код. Даже мне, знакомому с немерлом, но не пишущему в indent style.

_>Т.е. это похоже инструмент именно для создания DSL, а не для каждодневного MП.

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

_>Но при этом результат очень впечатляет. Особенно интеграция с IDE (кстати, а что за IDE там на скриншотах?) и сообщения об ошибках.

Студия это. Сейчас еще сравнительно слабая интеграция с IDE, ждем вот N2 от JetBrains. Надеюсь они дадут хоть что-то в открытый доступ.

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

Z>Ну да, новый язык встраивают далеко не каждый день. Относительно сложный там только парсинг, назвать реализацию генератора кодв в 20 строк сложной, у меня рука не поднимается. Ну и N2, который пилят ребята, будет поудобнее, подекларативнее.

Я к тому что иногда требуется именно простенькое МП, а не DSL. Т.е. что-то типа макрсов C++, но скажем типизированных и т.п. Интересно насколько возможно подобное в рамках этого проекта.

Z>Студия это. Сейчас еще сравнительно слабая интеграция с IDE, ждем вот N2 от JetBrains. Надеюсь они дадут хоть что-то в открытый доступ.

Хы, что-то я её не узнал. У меня правда только 2010-ая стоит...

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

_>Я к тому что иногда требуется именно простенькое МП, а не DSL. Т.е. что-то типа макрсов C++, но скажем типизированных и т.п. Интересно насколько возможно подобное в рамках этого проекта.

Для этого N2 просто не нужен, Nemerle достаточно умеет. С приходом N2 можно будет, наконец, развивать Nemerle дальше. Например мне бы хотелось иметь макрометоды с интелисенсом и прочими прелестями.

_>Хы, что-то я её не узнал. У меня правда только 2010-ая стоит...

Цветовая схема другая и хинты от немерловой интеграции.

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

Z>Для этого N2 просто не нужен, Nemerle достаточно умеет. С приходом N2 можно будет, наконец, развивать Nemerle дальше. Например мне бы хотелось иметь макрометоды с интелисенсом и прочими прелестями.

Ха, так хочется этого не в Nemerle, а в других языках! WolfHound же писал об альтернативных компиляторах Java, C# (и может когда-нибудь C, C++, D, Go?), которые добавляют подобные макросы, оставляя мощь языка. Вот это был бы очень полезный и реально инновационный продукт. А просто языки с развитым МП уже давно никого не удивляют.

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

Z>Работаю уже превратилось в постоянно работаю? Даже таких я наберу более десятка.

Z>less
Z>scss
Z>haml
Z>xaml
Z>sql
Z>regular expressions
Z>format strings
Z>css selectors
Z>xpath
Z>xsl
Z>cucumber
Z>mongodb query language
Z>knockout bindings syntax

Гы-гы.
Итого, если из твоего списка выкинуть XML-based, или вариации на тему CSS-based, то не наберется даже десятка.
Т.е., как я и говорил, ни о каких нескольких десятков речи быть не может. ЧТД.

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


Z>Это только языки, которые не являются embedded, тех я еще больше наберу.
V>>В сравнении с самописной приблудой — мегаопупительные. Да ещё полно учебников с примерами по Сети.
Z>Что сказать-то хотел? Чем это отличается от самописного фреймворка? Ты ведь сейчас как-то решаешь проблему множества недокументированных самописных фреймворков в проекте от студентов?

Уже говорили тебе — отличается самодокументируемостью любых библиотек на типизированном ЯВУ. Для понимания библиотеки через АПИ достаточно знания ЯЗЫКА, на котором и для которого эта библиотека. Язык — это фундамент. Знание языка — трамплин для понимания любых вещей внутри экосистемы языка.

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

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

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

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

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

Все твои аргументы базируются на том, что твои студенты налепят говна из DSL. Уж извини, это не проблема DSL.

V>Уже говорили тебе — отличается самодокументируемостью любых библиотек на типизированном ЯВУ. Для понимания библиотеки через АПИ достаточно знания ЯЗЫКА, на котором и для которого эта библиотека. Язык — это фундамент. Знание языка — трамплин для понимания любых вещей внутри экосистемы языка.

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

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

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

Z>Не понял мысль. Ты не показал, чем .should.have для разработчика лучше should have.

Лучше тем, что задается в некоторых рамках валидного уже известного языка.

I>>>А что тогда появилось в 93м году ?
M>>Распределенный процессинг. В общем, читай еще раз, что писал ты, и что писал Синклер.

I>Вообще то Синклер именно против этого и возражал — http://rsdn.ru/forum/philosophy/5113486.1

Автор: Sinclair
Дата: 26.03.13

1. Он не возражал против этого
2. Хватит уводить разговор в сторону

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

M>1. Он не возражал против этого
M>2. Хватит уводить разговор в сторону

Раз ты так хорошо понимаешь Синклера,

1 то переведи, что же он хотел сказать, ибо я понимаю выделенное именно как возражение именно на счет распределенного процессинга
2 покажи, куда я, по твоему, перевожу разговор

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

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

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

_>Ха, так хочется этого не в Nemerle, а в других языках! WolfHound же писал об альтернативных компиляторах Java, C# (и может когда-нибудь C, C++, D, Go?), которые добавляют подобные макросы, оставляя мощь языка. Вот это был бы очень полезный и реально инновационный продукт. А просто языки с развитым МП уже давно никого не удивляют.

Если цель не макросы, а "не в Nemerle", тут я ничем помочь не могу. Если именно макросы — то альтернативный компилятор C# работает. В нем доступны все макросы кроме расширяющих синтаксис, если хочется МП, то нет проблем, берите, пишите. Только сами макросы придется писать все таки на Nemerle.

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

Z>Если цель не макросы, а "не в Nemerle", тут я ничем помочь не могу. Если именно макросы — то альтернативный компилятор C# работает. В нем доступны все макросы кроме расширяющих синтаксис, если хочется МП, то нет проблем, берите, пишите. Только сами макросы придется писать все таки на Nemerle.

На самом деле хочется следующего:

1. Добавления удобного МП в мощные мейнстримовые языки. В идеале в C++ и Java, как обладающие самой развитой сейчас инфраструктурой.
2. Способ добавление (препроцессор, фронтенд к существующему компилятору, альтернативный компилятор) значения не имеет. Хотя в случае C++ третий вариант вряд ли возможно сделать сравнимым по эффективности с существующими монстрами.
3. Макросы обязательно должны работать с исходниками не как с текстом, а разбирая конструкции языка. Это естественно ключевой пункт, т.к. текстовых вариантов уже давным давно полно.
4. Чтобы ключевые IDE не тошнило от этих макросов (плагины к ним или что-то подобное). В принципе это пункт опциональный, но очень очень желаемый...
5. Язык самих макросов не принципиален. Но хочется что-то позволяющее одновременно и ненапряжно делать простейшие вещи (типа макросов C++) и создавать целые DSL при надобности.

Вот такие скромные хотелки. За их реализацию в принципе и не жалко денег заплатить. В смысле за готовый продукт, а не за разработку. )))

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

_>На самом деле хочется следующего:

_>1. Добавления удобного МП в мощные мейнстримовые языки. В идеале в C++ и Java, как обладающие самой развитой сейчас инфраструктурой.
_>2. Способ добавление (препроцессор, фронтенд к существующему компилятору, альтернативный компилятор) значения не имеет. Хотя в случае C++ третий вариант вряд ли возможно сделать сравнимым по эффективности с существующими монстрами.
_>3. Макросы обязательно должны работать с исходниками не как с текстом, а разбирая конструкции языка. Это естественно ключевой пункт, т.к. текстовых вариантов уже давным давно полно.
_>4. Чтобы ключевые IDE не тошнило от этих макросов (плагины к ним или что-то подобное). В принципе это пункт опциональный, но очень очень желаемый...
_>5. Язык самих макросов не принципиален. Но хочется что-то позволяющее одновременно и ненапряжно делать простейшие вещи (типа макросов C++) и создавать целые DSL при надобности.

_>Вот такие скромные хотелки. За их реализацию в принципе и не жалко денег заплатить. В смысле за готовый продукт, а не за разработку. )))

Для C# почти все это уже есть. Правда IDE легко свести с ума макросами. В отличии от Nemerl'овой, интеграция C# ничего не знает про возможность МП. Но и третий пункт вроде опциональный.

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

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

I>>>А что значит "распределенный однопроцессорный" ?

M>>В нем не было поддержки SMP, например. Что не мешало ему быть распределенным. В общем, Sinclair уже все

Автор: Sinclair
Дата: 26.03.13

сказал

Автор: Sinclair
Дата: 27.03.13

I>Вообще то он перепрыгнул с распределенного процессинга на многопроцессорный.

Не "перепрыгнул", а добавил, если уж придираться. Многонодовые фишки и объединение в кластера никто не отменял.

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

WH>>Ты хочешь сказать, что правки ядра лежат не в git'е и мержаться с обновлением, а вот прямо так на лету, перед тем как скормить их gcc патчаться каким то кодом?

DG>на vcs лежат отдельно исходные исходники, и отдельно патчи. С vcs-а выдергивает и то, и другое, а дальше make накладывает одно на другое.
DG>Обновлении версии ядра линукса сводится к закидыванию новой версии, и проверке, что patch-и продолжают накладываться в нужные места.

DG>Если делать по твоему, то при каждом обновлении — попадаешь на кучу ручной работы.

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

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

Z>>Что сказать-то хотел? Чем это отличается от самописного фреймворка? Ты ведь сейчас как-то решаешь проблему множества недокументированных самописных фреймворков в проекте от студентов?
V>Уже говорили тебе — отличается самодокументируемостью любых библиотек на типизированном ЯВУ. Для понимания библиотеки через АПИ достаточно знания ЯЗЫКА, на котором и для которого эта библиотека.

Уже смешно. Например, как понимание того, что зовётся createFoo(x), поможет знанию того, что этот вызов одновременно инициализирует подсистему bar? Или что до createFoo() должно быть setFooRange()?

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

V> Язык — это фундамент. Знание языка — трамплин для понимания любых вещей внутри экосистемы языка.

Осталось показать, как бизнес-логика является компонентом экосистемы языка.

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

I>>Вообще то он перепрыгнул с распределенного процессинга на многопроцессорный.

N>Не "перепрыгнул", а добавил, если уж придираться. Многонодовые фишки и объединение в кластера никто не отменял.

Годная отмазка

Здравствуйте, Ikemefula, Вы писали:
I>2 покажи, куда я, по твоему, перевожу разговор
А чего тут показывать. Ты ж не то выделяешь. Вот что надо выделять:
I>

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

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

Теперь понятно?

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

S>А чего тут показывать. Ты ж не то выделяешь. Вот что надо выделять:
I>>

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

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

S>Теперь понятно?

Тогда расскажи, про какой из всех возможных видов роутинга ты конкретно имел ввиду ?

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

I>Тогда расскажи, про какой из всех возможных видов роутинга ты конкретно имел ввиду ?
про тот, который в AXD-301
Кстати, веб-сервер на эрланге гнёт в дугу сервера на православных императивных ОО-языках только в путь — и в первую очередь на одном процессоре и ограниченной памяти.
Это к вопросу о распределённости и "на одном проце".

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

I>>Тогда расскажи, про какой из всех возможных видов роутинга ты конкретно имел ввиду ?
S>про тот, который в AXD-301

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

S>Кстати, веб-сервер на эрланге гнёт в дугу сервера на православных императивных ОО-языках только в путь — и в первую очередь на одном процессоре и ограниченной памяти.
S>Это к вопросу о распределённости и "на одном проце".

Ждём, когда этот сервер вытеснит "сервера на православных императивных ОО-языках ".