Re[22]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>Если все преобразования являются линейными операторами, их композиция делается тривиально. Надо матрицы перемножить. Нет?

WH>Нет. Есть не линейные преобразования. Например возведение в степень 2.2 и обратно.

И много таких — нелинейных? Кстати, с нелинейными — я что-то не понимаю — простая композиция инлайн-функций для описания преобразования почему не работает?
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 01.08.07 16:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>У run-time кодогенерации тоже есть свои козявки. Приходится использовать абстрактные классы, которые к тому же всегда должны быть публичные. Классы, которые не генерируются, но для которых что-то генерируется тоже должны обязательно быть публичными. Мелочь, а неприятно.

?? Для чего нужны абстрактные классы?

Мой любимый Tapestry в Java, например, использует кодогенерацию для работы с POJO (Plain Old Java Objects) — причем не требует никаких абстрактных классов (хотя в первых версиях библиотеки требовал из-за несовершенства кодогенератора).

А еще есть runtime bytecode instrumentation.
Sapienti sat!
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:29
Оценка: +2
Здравствуйте, IT, Вы писали:

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


G>>1) У тебя там применяются атрибуты. Добавление кастомных атрибутов никак не меняет синтаксис языка, и не увеличивает indirection level языковых конструкций.


IT>В этом смысле да. Но в том же немерле синтаксис атрибутов является лишь одним из форм макросов.


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

IT>Что касается синтаксических конструкций... честно говоря, я пытаюсь понять почему вы считаете это плохой практикой и пока никак не могу понять Почему, например, расширение linq захардкоженное, прибитое гвоздями к C# и VB это хорошо, а набор макросов, делающий тоже самое — это плохо. Почему printf("%d %s", a), убивающий программу или string.Format("{0} {1}", a), приводящий к run-time exception — это хорошо, а $"$a", где просто нет шансов на ошибку — это плохо.


Я тоже никак не могу понять, почему ты думаешь, что я любое захардкоженное языковое расширение считаю хорошим, а любое сделанное на макросах — плохим. Мне как, его пользователю, вообще пофигу, на чем оно сделано. Мне главное, чтобы 1) их было поменьше, и 2) они были хорошо документированы. Я не хочу иметь дело с языком класса PL/1, который умел делать все, и поддерживал абсолютно все на уровне языка, да еще быть лишенным мануала. А если вы не хотите городить второго PL/1, и его лавры дают, так сказать, покой, — так объясните еще раз — зачем нужны меняющие синтаксис макросы?

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

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

IT>Нормальная макросистема может все эти недостатки легко устранить. Но пока что мейнстрим до неё ещё не дорос. Хотя странно это. По-идее, на сегодняшний день это единственный способ существенно увеличить производительность девелоперов.


Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 01.08.07 16:37
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>И много таких — нелинейных?

Хватает.

G>Кстати, с нелинейными — я что-то не понимаю — простая композиция инлайн-функций для описания преобразования почему не работает?

Работает. И именно ее я и использую. Вот только написать и поддерживать несколько сотен этих самых композиций ручками мне мягко говоря влом.
Задача тупая, объемная, требует большого внимания к мелочам и легко алгоритмизируемая. И именно на таких задачах компы по сравнению с людьми рулят.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: Иванков Дмитрий Россия  
Дата: 01.08.07 16:40
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Алгоритм Флойда — Уоршела О(N^3) если нужны только растояния. Мне же нужны сами пути. И если я не разучился считать то изменения которые запоминают пути делают алгоритм О(N^4).


Как N^4?

0) D(i, j) — Floyd
N^3
1) F(i, j) = k | exists E(k, j) & D(i, j) == D(i, k) + D(k, j)
(N^2) * N
2) P(i, j) = P(i, F(i, j)) append F(i, j)->j
(N^2) * N
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>И много таких — нелинейных?

WH>Хватает.

Хватает кому? Скажи плз в цифрах в сравнении с линейными.

G>>Кстати, с нелинейными — я что-то не понимаю — простая композиция инлайн-функций для описания преобразования почему не работает?

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

Пардон?

transform1( transform2( transform3( x ) ) )

Это писать и поддерживать — в лом? А можно поинтересоваться — почему?

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


И как ты ее алгоритмизируешь? В чем проблема-то — ты так и не описал самой задачи.
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

Кажется, понятно.

У тебя каждое преобразование работает в своем цветовом пространстве. (класс со свойством "пространство")

У тебя есть картинка, которая тоже находится в своем цветовом пространстве. (класс со свойством "пространство")

Тебе надо наложить на картинку серию преобразований.

Цветовое пространство описываем классом с двумя функциями — преобразования в и из одного базового цветового пространства. Которое всегда одно и то же, например, RGB.

Функция преобразования из произвольного в произвольное пространство конструируется как композиция двух таких преобразований — "в" и "из".

Собственно, все. Можно сделать чтобы работало как в статике, так и в динамике. Без макросов. Где у нас подвох?
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


Пример пожалуйста.

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


VD>Хватит, или сможешь решать задачи компактнее, быстрее и порождая более производительный код? Если говорить о "хватит" в общем-то С для любой задачи хватит. Вот только паттерны от этого не исчезнут. Они просто будут строиться на базе ФВП и паттернматчинга.


Приведи мне пример паттерна, который будет строиться на базе ФВП и паттернматчинга, и покажи, как ты его макросом обернешь.
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 01.08.07 17:13
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Хватает кому? Скажи плз в цифрах в сравнении с линейными.

Примерно 50/50.
Но в любом случае необходим контроль компилятора над типами цветов.
Иначе в случае опечатки артефакты ловить задолбаешься.

G>Это писать и поддерживать — в лом? А можно поинтересоваться — почему?

По тому что таких цепочек СОТНИ. Я нарвался на комбинаторный взрыв с которым справится не получается.
И при добавлении нового пространства и/или преобразования есть не нулевая вероятность что гдето можно срезать углы.
Те нужно просмотреть все цепочки и поправить их.
Это занимает очень много времени.
А мне хитромудровывернутые алгоритмамы писать надо, а не обезьяней работой заниматься.

G>И как ты ее алгоритмизируешь?

Написал поиск кратчайших путей из каждого пространства до каждого.

G>В чем проблема-то —

В тонне ручной работы.

G>ты так и не описал самой задачи.

Гм. Вроде тут
Автор: WolfHound
Дата: 31.07.07
описал.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 01.08.07 17:22
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Собственно, все. Можно сделать чтобы работало как в статике, так и в динамике. Без макросов. Где у нас подвох?

Подвох в том что базового пространства нет.
И завести его без потери точности и эффективности невозможно.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 17:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>?? Для чего нужны абстрактные классы?


Если ты определяешь абстрактное свойство или метод, которое собираешься сгенерировать в рантайм, то класс должен быть абстрактным. По крайней мере в .NET.

C>А еще есть runtime bytecode instrumentation.


Это аналог emit'a?
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 01.08.07 17:59
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Индустрия имела макросы в далеких 70-х.


Ну-ка, поподробнее об этом. Первый раз такое слышу.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 18:40
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>В этом смысле да. Но в том же немерле синтаксис атрибутов является лишь одним из форм макросов.


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


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

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


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

G>Я не хочу иметь дело с языком класса PL/1, который умел делать все, и поддерживал абсолютно все на уровне языка, да еще быть лишенным мануала. А если вы не хотите городить второго PL/1, и его лавры дают, так сказать, покой, — так объясните еще раз — зачем нужны меняющие синтаксис макросы?


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

Вообще, я пока не разделяю твоих опасений по поводу PL/1. Всё это пока не более чем домысла. Насколько это будет или не будет реальной проблемой покажет только время и практика.

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


С этим я не спорю. Необходимость действительно возникает не часто. Но что делать когда она возникает, а такой возможности нет?

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


Дело конечно твоё. Я использую много генерируемого кода, поэтому для меня довольно важно насколько язык/платформа поддерживает средства метапрограммирования и насколько эти средства высокоуровневы.

G>Что пользователю не все равно — так это встречать недокументированные языковые расширения самоделкиных, сделанные на каждый чих. Это — плохо. Это — убивает maintainability.


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

G>А для редких случаев вполне сгодятся тулы вроде яка с лексом.


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

G>Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.


Я не уверен в том, что макросы имела именно индустрия. Отдельные исследовательские проекты возможно. Но насчёт всей индустрии я бы не стал утверждать. Вообще, востребованность инструмента напрямую зависит от сложности вхождения в него. Если сложность вхождения в те макросы была запредельной, то результат вполне закономерный.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: Mikl Kurkov Россия  
Дата: 01.08.07 19:22
Оценка: 36 (1) +1
Здравствуйте, konsoletyper, Вы писали:

G>>Индустрия имела макросы в далеких 70-х.


K>Ну-ка, поподробнее об этом. Первый раз такое слышу.


Ну вот лежит книга Брауна "Макропроцессоры и мобильность ПО".
Подробно рассматриваются разные типы макропроцессоров и способы их применения. Связанные с этим преимущества и сложности.
Цитата:

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

1974 год.
--
Mikl
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 19:25
Оценка: +1
Здравствуйте, Mikl Kurkov, Вы писали:

G>>>Индустрия имела макросы в далеких 70-х.

MK>Ну вот лежит книга Брауна "Макропроцессоры и мобильность ПО".

И где здесь про всю индустрию?
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 01.08.07 20:46
Оценка:
Здравствуйте, IT, Вы писали:

C>>?? Для чего нужны абстрактные классы?

IT>Если ты определяешь абстрактное свойство или метод, которое собираешься сгенерировать в рантайм, то класс должен быть абстрактным. По крайней мере в .NET.
Так определяй конкретное свойство — а в рантайме генерируй классы-аксессоры (вместо тупого использования reflection'а).

C>>А еще есть runtime bytecode instrumentation.

IT>Это аналог emit'a?
Нет. Это ты загружаешь класс, и прямо при его загрузке происходит его инструментация. Например, у меня прямо так в рантайме вставляются хуки для системы безопасности. В JBoss в JBossCache инструментация используется для прозрачного кэширования сложных объектов (http://www.onjava.com/pub/a/onjava/2005/11/09/jboss-pojo-cache.html?page=3).

В Java для этого полно инструментов, в .NET знаю только: http://rail.dei.uc.pt/project_overview.htm
Sapienti sat!
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 21:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

IT>>Если ты определяешь абстрактное свойство или метод, которое собираешься сгенерировать в рантайм, то класс должен быть абстрактным. По крайней мере в .NET.

C>Так определяй конкретное свойство — а в рантайме генерируй классы-аксессоры (вместо тупого использования reflection'а).

Ты не внимательно читал. Такое тоже делается, но в данном случае речь о другом. А именно, имея декларацию свойства или метода необходимо сгенерировать его тело. Т.е. в датааксессоре мне достаточно просто объявить метода, а генератор доделает остальное. Такой метод должен быть абстрактным.

C>В Java для этого полно инструментов, в .NET знаю только: http://rail.dei.uc.pt/project_overview.htm


Понятно. Судя по ссылки для .NET у них пока тоже ничего нет. Чем-то подобным занимаются в MS Research в проекте феникс, но пака это только рисёч.

В принципе, это всё можно делать и без инструментации. Достаточно объявлять нужные методы виртуальными и создавать объекты специальными методами, которые будут генерировать всё что нужно. В BLToolkit такое поддерживается (см. аспекты Log, Cache), но класс всё же должен быть абстрактным. Хотя это ограничение введено чисто искуственно, т.к. смысла в неабстрактном классе просто нет, а ошибки могут возникать.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 02.08.07 02:26
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Если ты определяешь абстрактное свойство или метод, которое собираешься сгенерировать в рантайм, то класс должен быть абстрактным. По крайней мере в .NET.

C>>Так определяй конкретное свойство — а в рантайме генерируй классы-аксессоры (вместо тупого использования reflection'а).
IT>Ты не внимательно читал. Такое тоже делается, но в данном случае речь о другом. А именно, имея декларацию свойства или метода необходимо сгенерировать его тело. Т.е. в датааксессоре мне достаточно просто объявить метода, а генератор доделает остальное. Такой метод должен быть абстрактным.
Я понял. В Java это делается так — объявляешь обычные get/set-методы, а в рантайме он их тебе или строит наследника с переопределенными методами (они виртуальные) или прямо инструментируют сам класс, добавляя нужную функциональность в get/set.

C>>В Java для этого полно инструментов, в .NET знаю только: http://rail.dei.uc.pt/project_overview.htm

IT>Понятно. Судя по ссылки для .NET у них пока тоже ничего нет. Чем-то подобным занимаются в MS Research в проекте феникс, но пака это только рисёч.
IT>В принципе, это всё можно делать и без инструментации. Достаточно объявлять нужные методы виртуальными и создавать объекты специальными методами, которые будут генерировать всё что нужно. В BLToolkit такое поддерживается (см. аспекты Log, Cache), но класс всё же должен быть абстрактным. Хотя это ограничение введено чисто искуственно, т.к. смысла в неабстрактном классе просто нет, а ошибки могут возникать.
В Java стараются сейчас все делать конкретными классами — их можно легко использовать при тестировании (mock objects и все такое...).
Sapienti sat!
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 02.08.07 02:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В Java стараются сейчас все делать конкретными классами...

Java — суксь Немерля — the dest
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.08.07 02:42
Оценка:
Здравствуйте, IT, Вы писали:

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


C>>В Java стараются сейчас все делать конкретными классами...

IT>Java — суксь Немерля — the dest

От destiny?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.