Re[5]: Языково-ориентированное программирование: следующая п
От: adontz Грузия http://adontz.wordpress.com/
Дата: 16.04.06 16:13
Оценка:
Здравствуйте, Oyster, Вы писали:

O>А вот что мне как раз не нравится, так это странные вроде_бы_как_оппоненты, которые заявляют, что Nemerle есть очередная туфта, даже не удосужившись его попробовать (что совсем несложно) хотя бы на небольшом проектике. Нет, ничего личного, — я вообще говорю...


Нет-нет, не туфта. Конечно же нет. Я ведь не говорю, что Nemerle это плохо, а спрашиваю сможет ли его осилить среднестатистический программист? А ведь это необходимое условие широкого использования языка.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[6]: Языково-ориентированное программирование: следующая п
От: WolfHound  
Дата: 16.04.06 16:49
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Нет-нет, не туфта. Конечно же нет. Я ведь не говорю, что Nemerle это плохо, а спрашиваю сможет ли его осилить среднестатистический программист? А ведь это необходимое условие широкого использования языка.

Может. Если не пытаться писать макросы (а использовать уже готовые. Стандартные или написанные кемто другим не суть важно.) то он не сложнее чем C#.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Языково-ориентированное программирование: следующая п
От: adontz Грузия http://adontz.wordpress.com/
Дата: 16.04.06 17:04
Оценка: -3
Здравствуйте, Oyster, Вы писали:

A>>Зато как я понял так не сделать

A>>
A>>length_t x = 3;
A>>length_t y = 5;
A>>length_t z = 9;
A>>volume_t v = x * y; // упс, забыли z, нихрена не скомпилируется.
A>>

O>Плохо понял — в таком случае именно что не скомпилируется (у величин разные размерности, и проверка этого будет выполняться на этапе компиляции; собственно, задача библиотеки и была вынести подобные проверки на этап компиляции), чего и требуется Ты бы попробовал хоть для начала...

Я как раз хорошо понял. В исходном примере все типы выводились и получалось, что v = x * y — площадь вне зависимости от того, что я имел ввиду. Явно указывать типы это на самом деле очень полезно. А чтобы их указывать явно и гибко нужны нормальные шаблоны.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[7]: Языково-ориентированное программирование: следующая п
От: adontz Грузия http://adontz.wordpress.com/
Дата: 16.04.06 17:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Слабенько? И что слабенько? Сравни чистоту описания и возможность использования просто таки литералов физ.величин с тем что получается на С++.

VD>По-моему, разница настолько очевидна, что и говорить не о чем.

Тут есть ещё и проблемы практического использования. Написать 10 kg то круто, а вот 10kg, а 10кг? А ведь это более естественно Да и где гарантия, что никто не забудет это самое k. Ошибка в 1000 раз на пустом месте.
Мне подход с явным указанием типов, а не суффиксов, нравиться больше. Кроме того, с использованием разного рода typeof (к сожалению он пока не стандартизирован) такие вещи можно делать и в Си++. И, учитывая, что Nemerle язык новый, а Си++ старый, я бы это рассматривал как большой плюс Си++. Хотя конечно на Nemerle всё удобнее.

VD>А ведь С++-решение использует почти 100% языка, то есть идет на грани возоможностей языка. Меж тем результат получается не очень замечательный. Описание физ.величин запутанное и непонятное. О физ. литералах вообще речи не идет.


+1. Обозначения не соответствуют физической номенклатуре. Вопрос в том, хороши ли такое соответствие в программе? Я бы не стал однозначно говорить да или нет.

VD>А сообщения об ошибках?


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

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


Влад, видишь ли какое дело, на все случаи жизни суффиксов не напасёшься. В физике три основополагающие величины — масса, длина, время и через единицы их измерения можно выразить любые другие единицы. И возможность написать value_t<1, 1, -2> для обозначения ньютона ИМХО очень полезно. Не всегда получаются базовые единицы и какие ты суффиксы придумаешь для производной ускорения по расстоянию я не знаю. А выводить тип из выражения, значить по сути лишать себя проверки типов вообще.

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


ИМХО спирит это штука из серии "показать себя", нежели "принести пользу".

VD>Ну, ну... Ты себя оговаривашь. Что-то критики С++-статей от тебя не много.


Да их самих не много
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[4]: Языково-ориентированное программирование: следующая п
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.06 17:38
Оценка:
Здравствуйте, GlebZ, Вы писали:

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

GZ>Пока нету нормального автоматизированного рефакторинга, сравнивать с библиотеками не стоит.

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

Изменения конечно возможны, но многие именения в ДСЛ-е не будут задействовать граматики, а скорее будут расширять семантику или делать ее более строгой.

ДСЛ тем и хорош, что он прост. В простом трудно ошибиться и его легко проверить.

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

Что касается рефакторинга и т.п. Согласен, средства автоматизации всегда полезны. Но не надо их противопоставлять самому принципу. Иначе выходит, что заниматься ООП на VB.NET или VC++ вообще невозможно, так как для оных просто не существует полноценных средств автоматического рефакторинга.

Меж тем код ДСЛ-ей легче поддается неавтоматизированному рефакторингу. Да и реже его требует. Ведь мы уже описываем специфичную и четко ограниченную информацию. Причем описываем явными синтаксическми средствами. Это в большинстве случаев позволяет обходиться банальными заменами по контексту вместо испоьзования умных утилит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Языково-ориентированное программирование: следующая п
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.06 17:38
Оценка:
Здравствуйте, Дарней, Вы писали:

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


Золотые слова! ДСЛ наоборот должен быть максимально декларативе и отражать только специфичную для предметной области инфромацию.

Думаю, самая большая ошибка при использовании ДСЛ-ей будет попытка создания слишком универсального ДСЛ-я. Это приведет к тому, что ДСЛ привратится в пародию на универсальный язык, а это как раз и вызовет проблемы которых так боится Адонц.

Чем более декларативны конструкции ДСЛ-ы, тем более он выразительен!

Д> Он должен всего лишь просто и эффективно решать одну очень узкую и ограниченую задачу. Для понимания сути DSL лучше подумать о регулярных выражениях или XPath.


Ага. И отличный пример тому встравивание регуляных выражений в Немерле.
regexp match (str)
{ | "a+.*" => printf("a\n");
  | @"(?<num : int>\d+)-\w+" => printf("%d\n", num + 3);
  | "(?<name>(Ala|Kasia))? ma kota" =>
     match(name)
     { | Some (n) => printf("%s\n", n)
       | None => printf("noname?\n")
     }
  | _ => printf("default\n");
}


Д>Ситуация, когда разные разработчики решают одну и ту же задачу разными DSL, полностью аналогична ситуации, когда один разработчик использует для построения GUI Qt, а другой wxWindows. И решается она такими же средствами, то есть при помощи стальной линейки или розг — в зависимости от вкусов руководителя проекта


+1
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Языково-ориентированное программирование: следующая п
От: adontz Грузия http://adontz.wordpress.com/
Дата: 16.04.06 17:42
Оценка: +1
Здравствуйте, VladD2, Вы писали:

A>>Аээээ ну так вообще любой конфигурационный файл давай обзовём DSL'ем. А-а-а-а DSL'и нас окружили, они нападают


VD>Дык так оно и есть. Просто те кто не систематизировал свои взгляды этого пока не замечают.


Влад тут дело не в систематизации. От того что я обозвал конфигурационный файл DSL'ом мне ну никаких удобств не добавилось.
Причислять существующую сущность к некоторому классу сущностей полезно всего в одном случае, когда этот класс сущностей хорошо изучен и мы можем использовать для сущности операции определённые над классом.
DSL'и же составляют класс сущностей с которым не ясно что делать и от того что ты туда за уши притянули ещё один DSL никому проще жить не стало.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[5]: Языково-ориентированное программирование: следующая п
От: adontz Грузия http://adontz.wordpress.com/
Дата: 16.04.06 17:50
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

VD>Изменения конечно возможны, но многие именения в ДСЛ-е не будут задействовать граматики, а скорее будут расширять семантику или делать ее более строгой.


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

VD>ДСЛ тем и хорош, что он прост. В простом трудно ошибиться и его легко проверить.


Влад, создаётся впечатление, что DSL это панацея от всех бед. Я не видел ещё ни одного простого и в тоже время эффективного промышленного языка, даже в пределах предметной области.
А наколеночные поделки не интересны — их и так плодят пачками.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[8]: Языково-ориентированное программирование: следующая п
От: WolfHound  
Дата: 16.04.06 18:14
Оценка: +2
Здравствуйте, adontz, Вы писали:

A>Тут есть ещё и проблемы практического использования. Написать 10 kg то круто, а вот 10kg, а 10кг? А ведь это более естественно Да и где гарантия, что никто не забудет это самое k. Ошибка в 1000 раз на пустом месте.

Суффиксы как и вобще вся эта библиотека сделаны по приколу. К томуже суффикс g можно и не вводить...

A>Влад, видишь ли какое дело, на все случаи жизни суффиксов не напасёшься.

A>В физике три основополагающие величины — масса, длина, время
ЙО! Это по меньшей мере на Нобелевскую хотя скорее на Шнобелевскую пермию тянет...
A>и через единицы их измерения можно выразить любые другие единицы. И возможность написать value_t<1, 1, -2> для обозначения ньютона ИМХО очень полезно.
А мне нравится задавать так
[Oyster.Units.Macros.UnitsDefinition([
    // SI
    basisUnits (Si)
    (
        Mass[ kg ],
        Length[ m ],
        Time[ sec ],
        Temperature[ K ],
        CurrentStrength[ A ],
        LightIntensity,
        QuantityOfSubstance
    ),

    basisAliases (Si)
    (
        Area = (Length ^ 2),
        Volume = Area * Length,
        Velocity = Length / Time,
        Acceleration = Velocity / Time,
        AngularVelocity = Velocity,
        AngularAcceleration = Acceleration,
        Density = Mass / Volume,

        Force = Mass * Acceleration,
        SpecificGravity = Mass / (Length ^ 2) / (Time ^ 2),
        Pressure = SpecificGravity * Length,

        LinearMomentum = Mass * Velocity,
        MomentOfInertia = Mass * Area,

        Energy = Force * Length,
        Power = Energy / Time,

        DynamicViscosity = Mass / Length / Time,
        KinematicViscosity = DynamicViscosity,

        HeatCapacity = Energy / Temperature,
        Entropy = HeatCapacity,
        SpecificHeat = HeatCapacity / Mass,
        SpecificEntropy = SpecificHeat,

        Charge = Time * CurrentStrength,
        LinearDensityOfCharge = Charge / Length,
        SurfaceDensityOfCharge = Charge / Area,
        ElectricFluxDensity = SurfaceDensityOfCharge,
        PackedDensityOfCharge = Charge / Volume,

        Voltage = Power / CurrentStrength,
        ElectricForce = Force / CurrentStrength,
        Resistance = Voltage / CurrentStrength,
        SpecificResistance = Resistance * Length,

        Permittance = Time / Resistance,

        CurrentDensity = CurrentStrength / (Length ^ 2)
    ),

    // CGS
    units (Cgs)
    (
        Mass[ g ] - 1.0 / 1000.0,
        Length[ cm ] - 1.0 / 100.0,
        Time,
        Temperature,
        CurrentStrength - 1.0 / 3000000000.0,
        LightIntensity,
        QuantityOfSubstance
    ),

    // Other units
    units (_)
    (
        HorsePower = Power - 1471.0 / 2.0
    )
])]
// Using fake class here otherwise definition won't work - looks like a bug:
// http://nemerle.org/forum/viewtopic.php?t=223
class FakeForDef {}

В прочем на С++ тоже можно задавать велечины в таком стиле... Например так
Автор: WolfHound
Дата: 19.05.05
. Вот только что-то мне подсказывает что понять КОД который делает это возможным смогут единици.
A>Не всегда получаются базовые единицы и какие ты суффиксы придумаешь для производной ускорения по расстоянию я не знаю. А выводить тип из выражения, значить по сути лишать себя проверки типов вообще.
Бред то какой... ты бы хоть в вопросе разобрался чтоли... в Nemerle можно явно задавать типы... Причем ты можешь задавать тип не только переменным но и частям выражения. А параметры методов обязаны быть заданы явно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Языково-ориентированное программирование: следующая п
От: adontz Грузия http://adontz.wordpress.com/
Дата: 16.04.06 18:34
Оценка: :)))
Здравствуйте, WolfHound, Вы писали:

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

WH>ЙО! Это по меньшей мере на Нобелевскую хотя скорее на Шнобелевскую пермию тянет...

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

Ампер равен силе такого постоянного тока, который, будучи пущен по двум прямым параллельным проводникам бесконечной длины и с незначительным поперечным сечением, помещёнными на расстоянии в 1 метр друг от друга в вакууме, создавал бы между этими проводниками силу, равную 2·10-7 ньютонов на метр длины.

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

WH>так
Автор: WolfHound
Дата: 19.05.05
. Вот только что-то мне подсказывает что понять КОД который делает это возможным смогут единицы.


Это не аргумент. Ты сам говоришь что макросы Nemerle не все смогут понять. Так что шило на мыло. Да и не думаю я что с приходом нового языка ситуация с разделением на тех кто пишет прикладные библиотеки и тех кто их использует изменится.

WH>Бред то какой... ты бы хоть в вопросе разобрался чтоли... в Nemerle можно явно задавать типы... Причем ты можешь задавать тип не только переменным но и частям выражения. А параметры методов обязаны быть заданы явно.


Да, я понимаю, что можно. Вопрос в другом. Если написать что-то вроде
"auto_type v = x * y", то v будет иметь тип x * y. А если написать "volume_t v = x * y", то всё очень замечательно, до тех пор пока слева у тебя базовые типы, а если нет? В Nemerle есть шаблоны параметризуемые не типами?
template <int length, int mass, int time>
class physical_value
{
}

Бывает?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Языково-ориентированное программирование: следующая
От: WolfHound  
Дата: 16.04.06 19:22
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Это не аргумент. Ты сам говоришь что макросы Nemerle не все смогут понять.

Не понять макросы Nemerle может только конченый Гашиш Кумар.
A>Так что шило на мыло. Да и не думаю я что с приходом нового языка ситуация с разделением на тех кто пишет прикладные библиотеки и тех кто их использует изменится.
Тут сложность неколько разного порядка. Я понимаю то что написал Oyster в своей библиотеке довольно легко. И это при том что с Nemerle я не работал. Так пару раз компилятор запускал для мелких эксперементов и все.
В то же время я с большим трудом понимаю как работает мой код который я ниписал по ссылке. И это при том что С++ я знаю очень хорошо. И написал на нем не один проект.

WH>>Бред то какой... ты бы хоть в вопросе разобрался чтоли... в Nemerle можно явно задавать типы... Причем ты можешь задавать тип не только переменным но и частям выражения. А параметры методов обязаны быть заданы явно.

A>Да, я понимаю, что можно. Вопрос в другом. Если написать что-то вроде
A>"auto_type v = x * y", то v будет иметь тип x * y. А если написать "volume_t v = x * y", то всё очень замечательно, до тех пор пока слева у тебя базовые типы, а если нет? В Nemerle есть шаблоны параметризуемые не типами?
Нет. И не надо. Учи матчасть. Посмотри как это реализовано и не говори глупостей.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Языково-ориентированное программирование: следующая п
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.06 19:32
Оценка:
Здравствуйте, adontz, Вы писали:

A>Я как раз хорошо понял. В исходном примере все типы выводились и получалось, что v = x * y — площадь вне зависимости от того, что я имел ввиду. Явно указывать типы это на самом деле очень полезно. А чтобы их указывать явно и гибко нужны нормальные шаблоны.


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

Еще раз, последний. На Немерле обеспечивается олный контроль типов. Немерл без проблем позволяет как задавать типы явно, так и выводить и автоматически. Если у гого-то возникает параноя, то он всегда может добавить к любому выражению конструкцию " : тип" и компилятор будет контролировать тип выражения. Это же справидливо и для объявления переменной:
def x : int = любое_выражение;

"x" будет иметь тип int независимо от того, что за тип выводится из "любое_выражение". Если тип несовместим или требует рантайм-приведения, то компилятор просто откажется компилитовать код.

Надесь, на этом данная дискусиия будет закрыта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Языково-ориентированное программирование: следующая п
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.06 19:32
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Тут есть ещё и проблемы практического использования. Написать 10 kg то круто, а вот 10kg, а 10кг?


Пошли поиски заусенцев для придирок. Ничего более существенного в голову не пришло?

Ладно отвечу. "kg" для языка — это оператор. Так что как ты его напишешь "10 kg" или "10kg" роли играть не должно (я прав? это я к автору библиотеки обращаюсь). А вот "кг" конечно не пройдет. Но не потому, что есть фзические окраничения, а просто потому, что "кг" не описан. Опиши его и будет прохдить и он.

A> А ведь это более естественно Да и где гарантия, что никто не забудет это самое k. Ошибка в 1000 раз на пустом месте.


Нда. Тяжолый случай. Рассуждения без малейшено понимания о предмете рассуждения. Еше раж. "10" и "10 kg" разные типы данных для языка. "10" — это int, а "10 kg" это 10 килограм, то есть другой тип данных. Так как нет неявного приведения, то они несовместимы и компилятор выдаст ошибку.

A>Мне подход с явным указанием типов, а не суффиксов, нравиться больше.


Используй его. Ты единственный кому это нравится, но это не проблема. Первая версия именно так и делала. Но нашелся орел вроде тебя кому показалось, что "10 kg" более понятно.

A> Кроме того, с использованием разного рода typeof (к сожалению он пока не стандартизирован) такие вещи можно делать и в Си++.


Языком. А на Немерле можно сейчас и довольно просто.

A>И, учитывая, что Nemerle язык новый, а Си++ старый, я бы это рассматривал как большой плюс Си++. Хотя конечно на Nemerle всё удобнее.


Логика изумительная. Нет слов! Тогда давай PL1 рассматр как идеальный язык. Оно ведь куда старше.

Короче, мне все меньше и меньеш интересен этот разговр. Стоять на своем морьщась от боли ты можешь в грдом одиночисте.

VD>>А сообщения об ошибках?


A>Тут ты не прав.


Только тут? И на том спасибо.

A> Сообщения посредством некоторых техник можно сделать вполне внятными.


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

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


A>Влад, видишь ли какое дело, на все случаи жизни суффиксов не напасёшься.


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

A> В физике три основополагающие величины — масса, длина, время и через единицы их измерения можно выразить любые другие единицы. И возможность написать value_t<1, 1, -2> для обозначения ньютона ИМХО очень полезно.


"value_t<1, 1, -2>"- это бред сивой кобылы. Эта строчка только в очень багатом воображении может оказаться осмысленной. Между тем имея полноценный ДСЛ описывающий взамиоотношения типов ты в силах описать любую комбинацию очень кратко и понятно.

A> Не всегда получаются базовые единицы и какие ты суффиксы придумаешь для производной ускорения по расстоянию я не знаю. А выводить тип из выражения, значить по сути лишать себя проверки типов вообще.


Ясно. "Сам я автора не читал, но как и весь Советский народ...". Читайте автора, сэр.

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


A>ИМХО спирит это штука из серии "показать себя", нежели "принести пользу".


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

VD>>Ну, ну... Ты себя оговаривашь. Что-то критики С++-статей от тебя не много.


A>Да их самих не много


Их как раз не мало.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Языково-ориентированное программирование: следующая п
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.06 19:32
Оценка:
Здравствуйте, adontz, Вы писали:

A>В какой момент ты поймёшь что язык ошибочен?


Когда попробуешь скомпилировать первые строчки кода. А может и при попытке их написать.

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


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

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

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


Какие на фиг приоритеты в ДСЛ-я? Снова ведешь разговор о том, что не доконца понимашь. Вот тебе пример ДЧЛ-я вводящего синтаксическую конструкцию упрощающую работу с регулярными выражениями:
regexp match (str)
{ | "a+.*" => printf("a\n");
  | @"(?<num : int>\d+)-\w+" => printf("%d\n", num + 3);
  | "(?<name>(Ala|Kasia))? ma kota" =>
     match(name)
     { | Some (n) => printf("%s\n", n)
       | None => printf("noname?\n")
     }
  | _ => printf("default\n");
}

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

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

Если в ДСЛ появляются приоритеты — это это уже путь в неверном направлении. ДЧЛ должен максимально декларативно описывать суть задачи, а макросы превращать это описание в реальный код отрабатывающий ее решение.

Так что ошибиться в описании ДСЛ-я куад сложенее чем при проектировании библиотеки.

VD>>ДСЛ тем и хорош, что он прост. В простом трудно ошибиться и его легко проверить.


A>Влад, создаётся впечатление, что DSL это панацея от всех бед. Я не видел ещё ни одного простого и в тоже время эффективного промышленного языка, даже в пределах предметной области.

A>А наколеночные поделки не интересны — их и так плодят пачками.

Нда. И где я уже видил эту аргументацию? А, у АВК. Когда аргументы по делу кончаются, то почему-то сразу начинаются "аргументы" вроде "Это что серебрянная пуля? Их не быват... Не пудрите мне мозги...".

Это следующий шаг в развитии индустрии программировния. Сама по себе концпция ДСЛ-ей не избавит от решения задач. Но во многих случаях она позволит решать задачи более просто, а значит решать более сложные задачи и решать их быстрее. Как ООП, ФП и другие парадигмы эта позволяет увеличить сложность решаемых задач впихнув их в довольно скудные возможности мозга человека.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Языково-ориентированное программирование: следующая п
От: Oyster Украина https://github.com/devoyster
Дата: 16.04.06 19:37
Оценка: +2
Здравствуйте, adontz, Вы писали:

A>Я как раз хорошо понял. В исходном примере все типы выводились и получалось, что v = x * y — площадь вне зависимости от того, что я имел ввиду. Явно указывать типы это на самом деле очень полезно. А чтобы их указывать явно и гибко нужны нормальные шаблоны.


Так ты указывай в коде, что ты имеешь в виду. Конкретно для моей библиотеки такой вот код:

def a : Si.Area = 10 m * 15 m

Приведёт к ошибке во время компиляции, т.к. площадь — это не объём. Насколько я понимаю, это именно то, что тебе нужно?
Re[8]: Языково-ориентированное программирование: следующая п
От: Oyster Украина https://github.com/devoyster
Дата: 16.04.06 19:37
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Тут есть ещё и проблемы практического использования. Написать 10 kg то круто, а вот 10kg, а 10кг? А ведь это более естественно Да и где гарантия, что никто не забудет это самое k. Ошибка в 1000 раз на пустом месте.


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

Кстати, если не нравятся физические литералы, то пиши явно:

def m = Si.Mass(10)

В общем, опять началась охота на ведьм Советую снова — попробуй Nemerle и мою библиотеку в действии, прежде чем критиковать их.

A>Мне подход с явным указанием типов, а не суффиксов, нравиться больше.


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

A>Кроме того, с использованием разного рода typeof (к сожалению он пока не стандартизирован) такие вещи можно делать и в Си++. И, учитывая, что Nemerle язык новый, а Си++ старый, я бы это рассматривал как большой плюс Си++. Хотя конечно на Nemerle всё удобнее.


Тут вообще не понял, о чём ты — какие вещи можно делать с использованием typeof на C++? Вообще исходная библиотека была написана на C++ и так, если ты об этом, вот только мне лично её исходники не очень по душе...

VD>>А ведь С++-решение использует почти 100% языка, то есть идет на грани возоможностей языка. Меж тем результат получается не очень замечательный. Описание физ.величин запутанное и непонятное. О физ. литералах вообще речи не идет.


A>+1. Обозначения не соответствуют физической номенклатуре. Вопрос в том, хороши ли такое соответствие в программе? Я бы не стал однозначно говорить да или нет.


Ты всё про физические литералы? А Влад больше об описании физических величин
Автор: Oyster
Дата: 10.04.06
.

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


A>Влад, видишь ли какое дело, на все случаи жизни суффиксов не напасёшься. В физике три основополагающие величины — масса, длина, время и через единицы их измерения можно выразить любые другие единицы. И возможность написать value_t<1, 1, -2> для обозначения ньютона ИМХО очень полезно. Не всегда получаются базовые единицы и какие ты суффиксы придумаешь для производной ускорения по расстоянию я не знаю. А выводить тип из выражения, значить по сути лишать себя проверки типов вообще.


Да причём тут суффиксы!!!

Кстати, ты всерьёз считаешь, что value_t<1, 1, -2> удобнее хоть в каком-то случае? кстати, тебе бы пришлось писать value_t<1, 1, -2, 0, 0, 0, 0>, т.к. ортов 7. Я это к тому, что для ситуации, когда полезно указывать скалярные параметры типов явно, лучше написать соответствующее расширение — у моей библиотеки цели другие.
Re[10]: Языково-ориентированное программирование: следующая
От: Oyster Украина https://github.com/devoyster
Дата: 16.04.06 19:37
Оценка:
Здравствуйте, adontz, Вы писали:

A>Да, я понимаю, что можно. Вопрос в другом. Если написать что-то вроде

A>"auto_type v = x * y", то v будет иметь тип x * y. А если написать "volume_t v = x * y", то всё очень замечательно, до тех пор пока слева у тебя базовые типы, а если нет?

А если нет, то всё тоже замечательно сработает:

def v = Si.Volume(Si.Velocity(30) * Si.Time(20) * 100 cm)

Ты бы хоть попробовал, всё-таки, чтобы больше говорить по существу.

A> В Nemerle есть шаблоны параметризуемые не типами?

A>
A>template <int length, int mass, int time>
A>class physical_value
A>{
A>}
A>

A>Бывает?

Ты, как и vdimas когда-то
Автор: vdimas
Дата: 29.03.06
, всё не можешь понять, что я на Nemerle решил точно ту же задачу, но без скалярных параметров шаблонов, и что скалярные параметры шаблонов для решения этой задачи совсем не нужны. vdimas-а я смог переубедить
Автор: vdimas
Дата: 14.04.06
. Надеюсь, что смогу и тебя
Re[6]: Языково-ориентированное программирование: следующая п
От: Oyster Украина https://github.com/devoyster
Дата: 16.04.06 19:37
Оценка: 36 (1) +1
Здравствуйте, adontz, Вы писали:

A>Нет-нет, не туфта. Конечно же нет. Я ведь не говорю, что Nemerle это плохо, а спрашиваю сможет ли его осилить среднестатистический программист? А ведь это необходимое условие широкого использования языка.


WolfHound в принципе уже ответил
Автор: WolfHound
Дата: 16.04.06
, что на Nemerle можно писать точно как на C#.

Вот насчёт функциональных возможностей и макросов, честно говоря, не знаю. До сих пор языки вроде Ocaml и Schema не пользовались особой популярностью; с другой стороны, создателям Nemerle удалось красиво интегрировать все эти фичи вместе, да ещё и оформить всё это как .NET-язык (что тоже дорогого стоит).

В общем, как минимум пользоваться Nemerle как C# можно, а потом людям, может, самим надоест забивать гвозди микроскопом и они начнут пользовать нетипичные для C# возможности языка. А может, Nemerle просто тихо пройдёт мимо ("зачем нам клон C#?"), оставшись незамеченным (мне бы очень этого не хотелось, но я не исключаю такой возможности). Who knows
Re[9]: Языково-ориентированное программирование: следующая п
От: Oyster Украина https://github.com/devoyster
Дата: 16.04.06 19:47
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ладно отвечу. "kg" для языка — это оператор. Так что как ты его напишешь "10 kg" или "10kg" роли играть не должно (я прав? это я к автору библиотеки обращаюсь).


Естественно — оно роли и не играет. Можно спокойно писать 10kg (только что проверил даже — компилится).

VD>А вот "кг" конечно не пройдет. Но не потому, что есть фзические окраничения, а просто потому, что "кг" не описан. Опиши его и будет прохдить и он.


+1

A>>Мне подход с явным указанием типов, а не суффиксов, нравиться больше.


VD>Используй его. Ты единственный кому это нравится, но это не проблема. Первая версия именно так и делала. Но нашелся орел вроде тебя кому показалось, что "10 kg" более понятно.


На самом деле, можно и сейчас писать Si.Mass(10), как и раньше, конечно.

Вообще идею с "физическими литералами" придумал я но вот очень-очень её захотел видеть vdimas.
Re[11]: Языково-ориентированное программирование: следующая
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.06 20:21
Оценка: 7 (1)
Здравствуйте, Oyster, Вы писали:

O>А если нет, то всё тоже замечательно сработает:

O>
O>def v = Si.Volume(Si.Velocity(30) * Si.Time(20) * 100 cm)
O>


Кстаити, прведи сообщение компилятора в случае ошибки типов, плиз.

O>Ты, как и vdimas когда-то
Автор: vdimas
Дата: 29.03.06
, всё не можешь понять, что я на Nemerle решил точно ту же задачу, но без скалярных параметров шаблонов, и что скалярные параметры шаблонов для решения этой задачи совсем не нужны. vdimas-а я смог переубедить
Автор: vdimas
Дата: 14.04.06
. Надеюсь, что смогу и тебя


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

А вот чтобы объяснить остальным было бы неплохо написать статейку которая:
1. Просто и доходчиво описывала бы суть проблемы.
2. Описывало принцип решения задачи на С++.
3. Описывала бы логику и принцыпы решения задачи на Немерле.
4. Демонстрировала бы положительные моменты решения на Немерле.

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

С удовольствием помгу с языком и формулировками, но писать тебе, так как я скорее принадлежу той массе для которого все это далекий спор о высоких материях разбираться в которых сложно и неохота.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.