(там где через ssh сервер пингуется) ты еще с руками ходишь.
И что тебе там не нравится?
E>Если эта функциональность входит в ядро языка, то она и должна затрагивать всех.
А ты уверен что аналог макроса Late должен входить в ядро?
Я нет.
E>По мне, так это только плюс для универсального языка.
Неумение пользоваться чем-то еще не означает его ненужности.
(С) Сам знаешь кто.
E>А какие гарантии предоставляет Memoize в многопоточной программе?
[Memoize(Synchronized = true)] E>А по исключениям? А если мне нужны другие гарантии?
А тебе не нужна безопасность по отношения к исключениям? Интересное жилание. E>Собственный макрос делать? Тогда зачем Memoize в стандартной поставке языка?
Притензия из серии: Мне не нравится std::map! Зачем ее засунули в stl?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
(там где через ssh сервер пингуется) ты еще с руками ходишь. WH>И что тебе там не нравится?
По мне, так там сильно много разнообразных действий в одном месте намешано, злоупотребление локальными функциями.
E>>Если эта функциональность входит в ядро языка, то она и должна затрагивать всех. WH>А ты уверен что аналог макроса Late должен входить в ядро? WH>Я нет.
На счет макроса Late не могу сказать, т.к. не знаю, что это такое. А вот Memoize, в отличии от Design By Contract в ядре точно не место. Разве что в стандартной библиотеке.
E>>По мне, так это только плюс для универсального языка. WH>Неумение пользоваться чем-то еще не означает его ненужности. WH>(С) Сам знаешь кто.
Речь идет не о неумении, а о том, чтобы велосипедостроители различных мастей и самомнений не расширяли язык под свои задачи.
E>>А какие гарантии предоставляет Memoize в многопоточной программе? WH>[Memoize(Synchronized = true)] E>>А по исключениям? А если мне нужны другие гарантии? WH>А тебе не нужна безопасность по отношения к исключениям? Интересное жилание. E>>Собственный макрос делать? Тогда зачем Memoize в стандартной поставке языка? WH>Притензия из серии: Мне не нравится std::map! Зачем ее засунули в stl?
Согласен, здесь я привел неудачный пример.
В D, думаю, аналог Memoize, можно сделать как шаблонную обертку над методом. И вызвать потом не сам метод, а его обертку. Так же можно поступать и в Nice, хотя здесь могут быть сложности с переменным числом аргументов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Всего EiffelStudio (опять же по словам Мейера) была продана в количестве десятков тысяч копий (причем каждая копия стоит значительно дороже $1000).
Анекдот в тему.
............
— Доктор! У меня проблемы с женщинами в постели.
— Так что же вы хотите, голубчик, в ваши то 78 лет?
— Так у меня соседу вообще 80, а он говорит, что еще ОГО-ГО!
— Ну, так и Вы говорите...
Думаю, в современных условиях он вообще мало что смог бы продать. А $10 за десятки лет — это не доход. Он ведь не все в корман кладет? Ему же надо с работниками делиться и т.п.
Я сужу о распространенности продукта по спросу на него. Покажи мне хотя бы один вопрос по этому замечательному языку у нас на форуме. Нет? А на другом не принадлежащем ему?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Файберы тоже частный случай.
В чем их частность?
VD>>Какого к черту объявления? У тебя сборка может динамически подгрузиться. И в ней может быть расширение мультиметода. В общем, не веди беседы о том, в чем ни в зуб ногой. VD>>Кроме не однозначностей я тебе еще две проблемы раскро: VD>>1. Производительность мультиметодов обратно пропорционально количеству параметров. Хроший универсальный алгоритм тут не существует. VD>>2. Проблемы с днимической загрузкой и безопастностью.
FR>Ну значит запишем тогда что фиг реализуешь на макросах
Пиши что хочешь. Тебе ведь вообще пофигу что и где писать. Адью.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>При чем тут реализация?
Притом, что если плевать на все (в том числе на производительность), то реализовать можно почти все.
FR>Тот же call/cc интересен тем что через него легко реализуются такие вещи которые в языках не подерживающих продолжения можно только хардкорно сделать.
Ну, хотя бы один пример можно привести чтобы он на файберах при этом не воспроизводился и за одно нес хотя бы что-то полезное, а не был бы самоцелью?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>Тогда два вопроса: E>* если все это можно сделать без макросов, на анотациях, то зачем макросы? E>* что делать с макросами, которые в анотации не засунуть? Насколько я понимаю, вещи типа using и for в Nemerle -- это макросы. Они так же функциями заменяются?
Мне кажется, что самое время хочть чуть-чуть почитатиь о премете обсуждения. Если ты дилетант в данной области, то не лезь с суждениями и верь тому что тебе говорят, а если хочушь судить, то разберись в вопросе. А то на подобные вопросы тебе уже раз 10 отвечали, но ты задаеш их снова и снова.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>По мне, так там сильно много разнообразных действий в одном месте намешано
А что там намешано?
Там по уже распарсеному конфигу строятся необходимые структуры данных и запускаются необходимые для работы демоны.
E>, злоупотребление локальными функциями.
И что бы по твоему изменилось если бы я их не использовал?
А я тебе скажу: Пришлось бы завести еще пару классов. И раздуть код раза в 2. Минимум.
E>На счет макроса Late не могу сказать, т.к. не знаю, что это такое. А вот Memoize, в отличии от Design By Contract в ядре точно не место. Разве что в стандартной библиотеке.
Так они там и находится.
E>Речь идет не о неумении, а о том, чтобы велосипедостроители различных мастей и самомнений не расширяли язык под свои задачи.
А в чем проблема?
Ибо библиотеками особенно под С/С++ дров можно наломать как минимум не меньше.
E>Согласен, здесь я привел неудачный пример. E>В D, думаю, аналог Memoize, можно сделать как шаблонную обертку над методом. И вызвать потом не сам метод, а его обертку. Так же можно поступать и в Nice, хотя здесь могут быть сложности с переменным числом аргументов.
В том то и прелесть макросов что я написал и отладил этот код (Problem178)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Всего EiffelStudio (опять же по словам Мейера) была продана в количестве десятков тысяч копий (причем каждая копия стоит значительно дороже $1000).
VD>Думаю, в современных условиях он вообще мало что смог бы продать. А $10 за десятки лет — это не доход. Он ведь не все в корман кладет? Ему же надо с работниками делиться и т.п.
Какие $10? Ты бредишь? На цены посмотри
VD>Я сужу о распространенности продукта по спросу на него. Покажи мне хотя бы один вопрос по этому замечательному языку у нас на форуме. Нет? А на другом не принадлежащем ему?
Блин, Влад, раскрой глаза! Ты серьезно думаешь, что RSDN является объективным отражением того, что творится в мире? Актись. Я прекрасно помню, как два года назад ты спрашивал "Какой-такой Ruby?" А сейчас вы статьи о нем публикуете.
Eiffel же стоит столько, что в бывшем Союзе мало кто может себе его позволить использовать в разработках. Так что же ты хотел на русскоязычном форуме?
Я задавал вопросы по Eiffel здесь: eiffel_software -- отвечали достаточно грамотно и оперативно. Хотя и фанатики типа тебя, там так же встречались.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, eao197, Вы писали:
E>>, злоупотребление локальными функциями. WH>И что бы по твоему изменилось если бы я их не использовал?
По мне, так логика была бы разбита на уровне и каждый уровень располагался бы отдельно, не смешиваясь с другими.
WH>А я тебе скажу: Пришлось бы завести еще пару классов. И раздуть код раза в 2. Минимум.
У меня, наверное, воспитание другое. Но по мне, более объемый но простой код гораздо лучше компактного, но более сложного.
E>>Речь идет не о неумении, а о том, чтобы велосипедостроители различных мастей и самомнений не расширяли язык под свои задачи. WH>А в чем проблема? WH>Ибо библиотеками особенно под С/С++ дров можно наломать как минимум не меньше.
Ну не про C/C++ сейчас речь, я так думаю.
Речь о другом -- по-моему, сопровождать и развивать библиотеку проще, чем язык (пусть даже и DSL). И если язык не предоставляет своим пользователям возможности для своего расширения (а только за счет библиотек функций и классов), то в долгосрочной перспективе это окупается простотой сопровождения, переработки и перехода на другие библиотеки.
E>>Согласен, здесь я привел неудачный пример. E>>В D, думаю, аналог Memoize, можно сделать как шаблонную обертку над методом. И вызвать потом не сам метод, а его обертку. Так же можно поступать и в Nice, хотя здесь могут быть сложности с переменным числом аргументов. WH>В том то и прелесть макросов что я написал и отладил этот код (Problem178)
Здравствуйте, eao197, Вы писали:
E>У меня, наверное, воспитание другое. Но по мне, более объемый но простой код гораздо лучше компактного, но более сложного.
Куда уж проще?
Код прост как пробка.
E>Речь о другом -- по-моему, сопровождать и развивать библиотеку проще, чем язык (пусть даже и DSL). И если язык не предоставляет своим пользователям возможности для своего расширения (а только за счет библиотек функций и классов), то в долгосрочной перспективе это окупается простотой сопровождения, переработки и перехода на другие библиотеки.
Я плакал.
Ибо если у нас в 10 раз больше кода то у нас минимум в 10 раз больше гемороя при поддержке.
А правильный макрос в правильном месте может дать и больше.
Конечно не на всех задачах но иногда такие встречаются.
E>Думаю, что если бы Memoize был реализован на D-шных шаблонах, эффект получился практически таким же. Было бы что-то вроде:
1)Это называется через зад автогеном.
2)Эта штука будет различать static и instance методы?
3)А можно таки посмотреть на этот самый шаблон memoize?
E>Кстати, по ходу вопрос -- Memoize на локальные функции распространяется?
В текущей реализации нет.
Нужно просто определиться как он будет вести себя для локльных функций.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Ну, хотя бы один пример можно привести чтобы он на файберах при этом не воспроизводился и за одно нес хотя бы что-то полезное, а не был бы самоцелью?
Тебе кучу раз приводили continuation-сервера. Ну, не делается оно полноценно на фиберах.
Здравствуйте, lomeo, Вы писали:
VD>>Сравнивл. Разницы не обнаружил. Просто другие умолчания. В нем по умолчанию все лениво, а в Немерле нет. Вот тормозит Хаскель по черному (чтобы его фанаты не говорили) — это да.
L>Насколько ленивый код в Немерле быстрее, чем аналогичный ленивый код в Хаскель?
Думаю, что завист от ситуации. Может и не на сколько. Вот то что сам Хаскель порой в 10, 100, а то и в 1000 раз медленнее это факт. А пользователя его не трогает мегакрутость ззыка. Ему ехать надо.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А что с функциями, которые вызываются из данной функции. Их нужно переписывать или нет?
Как резонно заметили некоторые товарищи Итераторы не полноценные континюэшоны. Это скажем так их сабсэт. Итераторы "замыкают" только локальные переменный метода. Так что переписывать вызваемые методы нет смысла.
Вот если скажем делать что-то более мощьное. Например, Итераторы замыкающиеся на класс или даже группу классов, то наверно прийдется.
Я уже много раз говорил, что в компилируемомо статически типизированном языке смысла делать полноценные континюэшоны не много. Они не будут быстрее тех же файберов. Но вот сделать нечто большее чем Итераторы было бы не плохо. Как минимум разные воркылоу-задачи решать было бы удобнее.
Вот это сделать на макросах можно. В прочем можно, наверно и полные континюэшоны залудить. Вот только почти уверен, что объем сохраняемой информции будет велик и стало быть выхлоп будет холостым.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>Я правильно понял, что по реализуемости мультиметодов и т.п. вопрос отпал?
L>На самом деле спор совершенно дурацкий. Началось с заявления, что на макросах можно сделать всё (я утрирую, но это можно было так понять).
А зачем утрировать? Покажи, плиз то заявление. Рассмотрим его по внимательнее. А то у меня создается четкое впечатление, что это такой прием софистики с целью уйти от исходного посыла.
Я помню, что Вольфхаудн высказал резнонное, на мой взгляд, мнение о том, что языки резонно создавать на безе сикроядра, а остальные фичи наворачивать на чем-то вроде мощьной макросистемы. И сказал, что мол по его ИМХУ за таким подходом будущее. Ну, и пошло поехало. Основную мысль никто не осприл. Зато спор перешел в разряд абсурдного.
L> Когда были предъявлены варианты того, что сделать нельзя, то, разумеется, в ответ получили недоумение на фига это делать.
Ну, начнем с того, в общем-то можно. Смысл нет, но можно. А зкончим тем, что если что-то нельзя, то это что-то просто должно отнаситься к тому самому микроядру. Ну, вот нельзя в микроядерной ОС организовать передачу информации в обход микроядра, ну, так это зе не значит, что сам подход не приемлем. Правда?
Наши заслуженные демогоги FR & eao197 в очередной раз сделали логический подлог, а вы поддержали их почин.
По крайней мере мне так показалось.
L>1. Либо доказать WolfHound-у (и компании), что на макросах сделать всё нельзя, но я думаю, он это и так понимает. L>2. Либо доказать FR (и компании), что мультиметоды Немерле не нужны. Но его это тоже мало интересует.
Ну, и погляди на результат разговора.
Вольфхаунд:
— Я считаю, что за подходом микроядро плюс равитие на макросах будущее.
FR:
— А мультиметоды можно сдлать?
— Можно, но не нужно.
— А почему не нужно? Значит нельзя, а это доказывает, что подход плохой.
...
L>Остальное — детали. Коротко — о разном говорят, IMHO.
По-моему, они вообще не говорят, а защищают позиции. FR отстаивает све болото. Он не приемлет тот же Немерле по причинам к дизайнерским решениям принятым в языке не относящимся, а Вольфхаунд начав спорить с ним ушел в нервану, забыл о предмете разговора и начал говорить не самые разумные вещи.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>С последней мыслью немного не согласен. Хардкодить в компиляторе, наверное, да, не стоит. На все случаи не напасёшься. Однако, если есть фича, смотрящаяся достаточно стройно в языке, то это лучше, чем макрос в языке, где этой фичи нет.
Дык не вопрос. Понятие "в языке" довольно гибкое. Это может быть стандартная макробиблиотека. 90% Немерла и лежит в макросах. Более того некоторые фундаментальные фичи, например, поддщержка делегатов, хотя и лежит в коде компилятора, но создано на базе макросного АПИ. Так что я с тобой и не спорю. Я говорю о дизайне компилятора, а не настаиваю на том, что все надо под одну гребенку. В тех же ОС частенько переносят в ядро то что не следовало бы только из соображений скорости. С компиляторами та же фигня.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Не смеши, текущими макросами LINQ не сделаешь, хоть убейся, я в курсе почему. Либо другой синтаксис, либо <# #> (что тоже другой синтаксис) или еще какие костыли. Надо систему макросов менять.
Надо будет, поменяем. А ты можещь продолжать жевать, что жевать и заниматься демагогий.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Если говорить откровенно, то я этого момента не помню. Напомни, плз, что за конкретные места и что за анализ, для которых нужна генерация кода? Или ссылку дай на сообщение.
Код доступен http://nemerle.org/svn/nemerle/trunk/macros/compiler.n изучай.
L>А так — да, если обязательно нужна кодогенерация (т.е. язык не может предложить лучшее решение), то макросы рулят. С этим никто не спорит.
Ну, может в некотором проценте случае тот или иной язык предложить не то что бы лучшее, но хоть какое-то решение. И что это основание пользователям других языков говорить о ненужности макросов? Есть хоть один язык который идеально решает все встающие перед программистом задачи? Ну, тогда о чем речь? Ну, есть в Хаскеле 5-10 классных фич и решений? Но мн с того не жарко не холодно. Писать на нем сожно. Код получается, зачастую, неприемлемо медленным. Кривая изучения языка выше Монблана.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
WH>>Все что нужно это запомнить аргументы функции до вызова body и передать их в check. WH>>Думаю с этим даже ты справишься.
E>Если уж разработчики Nemerle с их гениальными идеями не смогли это сделать, то я даже и пытаться не буду.
Слушай. Ты форумом ошибся. Тут не демогогический клуб, а технический. Кончай упражняться.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Что-то мне подсказывет, что сейчас будут искаться еще какие-то бредовые отговорки, но признания твоего заблуждения в данном вопросе мы так и не услышим. Хотя оно столь очевидно.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
