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

Прихожу к выводу, что объекты — это только "часть правды". Объекты, как концентрация нашего "проектного представления" о программе безусловно полезны. Но вот если бы еще вынети ДАННЫЕ на верхушку программы и вынести их как обязательную конструкцию. Данные — унифицировать по строению, — как таблицы в СУБД. А между ними прописать явняе отношения — как особые конструкции вроде SQL. Вызова процедур и функций как последовательности операторов избегать совсем. Функция — пусть будет как объект, который может принять на себя ДАННЫЕ, и выдать ДАННЫЕ, которые уже вынесены в отдельную область программы. Функция — по сути носитель отношения. Они могут образовывать суперпозиции — опять аналогия с SQL. Добавить принцип — любые данные могут быть рождены только одной функцией, но потребляться могут несколькими — и программы превратятся в понятные, легко конструируемые графы.
Ваше мнение.

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

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

Уверен, что основная проблема тут или в языке, или в его знании. Не возьмусь угадать сам язык, но точно сказать, что это классический ООЯ. Причем если это C#, то с LINQ-ом ты незнаком.

S> Пришел к выводу, что большую часть времени занимает написание кода преобразования данных их одних форматов в другие: из полей в таблицы, из массивов в строки и наборот...
S>...А между ними прописать явняе отношения — как особые конструкции вроде SQL... Функция — пусть будет как объект, который может принять на себя ДАННЫЕ, и выдать ДАННЫЕ, которые уже вынесены в отдельную область программы. Функция — по сути носитель отношения. Они могут образовывать суперпозиции — опять аналогия с SQL. Добавить принцип — любые данные могут быть рождены только одной функцией, но потребляться могут несколькими — и программы превратятся в понятные, легко конструируемые графы.
S>Ваше мнение.

Поздравляю! Ты близок к изобретению функционального программирования.
В нем, как раз, делается акцент на функциях как на преобразователях одних данных в другие.

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

VD>Уверен, что основная проблема тут или в языке, или в его знании. Не возьмусь угадать сам язык, но точно сказать, что это классический ООЯ. Причем если это C#, то с LINQ-ом ты незнаком.

Спасибо за упоминание. Я слышал естественно, но не вникал. Щас сижу читаю статью.

VD>Поздравляю! Ты близок к изобретению функционального программирования.
VD>В нем, как раз, делается акцент на функциях как на преобразователях одних данных в другие.

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

Акценты в другом:

Данное объявляется не просто как переменная в которую может писать и читать любой желающий (и метод), а:
— это

Объект программы, который исключает синтаксис передачи параметров в функции.

Я предлагаю замкнуть на данных такие же отношения, как методы замыкают на объектах.

"Данное" должно имееть единственного родителя — что обеспечивает единственность его смысловой нагрузки
семантическую чистоту.

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

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

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

S>Вот.
S>Долой переменные.
S>Даешь данные, семантика которых обеспечивается инструментом программирования, а не отвественностью программиста и стилем кодирования.

Вот-вот. Неизменяемые переменные, ФП, декларативность. Не так?

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

S>Вот.
S>Долой переменные.
S>Даешь данные, семантика которых обеспечивается инструментом программирования, а не отвественностью программиста и стилем кодирования.

Речь об реактивном программировании?

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

S> "Данное" должно имееть единственного родителя — что обеспечивает единственность его смысловой нагрузки
S> семантическую чистоту.

Оперировать понятиями "единственность смысловой нагрузки" мне крайне трудно.
Замечу только, что слова "данное" нет. Данные они и в Африке данные, даже если их не много.

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

Методы объектов в общем-то и есть такие каналы. Еще есть иделогия акторов в которой каждая программная сущность замкнута в себе и может общаться с миром только по средствам асинхронных сообщений. Возможно это близко к тому что ты хочешь.

S>Вот.
S>Долой переменные.

Ну, это уже перебор. Локальные переменные никому не мешают. Поля тоже.

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

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

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

VD>Уверен, что основная проблема тут или в языке, или в его знании. Не возьмусь угадать сам язык, но точно сказать, что это классический ООЯ. Причем если это C#, то с LINQ-ом ты незнаком.

VD>Поздравляю! Ты близок к изобретению функционального программирования.
VD>В нем, как раз, делается акцент на функциях как на преобразователях одних данных в другие.

Кстати, а как в ФП обстоит дело с древовидными данными?
Какие функциональные языки лучше покрывают возможности XSLT ? (такой вопрос потуму что XSLT это все таки не совсем язык программирования). В Nemerle подобные трюки вроде возможны?

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

S_>Кстати, а как в ФП обстоит дело с древовидными данными?

Замечательно.

S_>Какие функциональные языки лучше покрывают возможности XSLT ?

Любые. Вопрос не в языках, а в библиотеках. Такие библиотеки как HaXML для Хаскеля или Linq для дотнет языков с успехом заменяют XSLT.

В прочем, XSLT — это специализированный DSL и по кратности с ним трудно тягаться, но решения получаются вполне себе конкуретно-способные.

S_> (такой вопрос потуму что XSLT это все таки не совсем язык программирования).

Можно сказать смелее — это совсем не язык программирования. Это специализированный язык — DSL.

S_>В Nemerle подобные трюки вроде возможны?

Конечно. Из готовых библиотек доступен только Linq to XML, но ничто не мешает повторить и HaXML.

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

S> Объект программы, который исключает синтаксис передачи параметров в функции.

S> Я предлагаю замкнуть на данных такие же отношения, как методы замыкают на объектах.

Это не понятно.

S> "Данное" должно имееть единственного родителя — что обеспечивает единственность его смысловой нагрузки
S> семантическую чистоту.

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

Это почти описание data-flow или рективного программирования.
На данный момент сильно недооцененная парадигма.
Есть мнение, что к ней начнут переходить, когда наиграются с ФП.

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

D>Это почти описание data-flow или рективного программирования.
D>На данный момент сильно недооцененная парадигма.
D>Есть мнение, что к ней начнут переходить, когда наиграются с ФП.

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

Реактивное же программирование и вовсе доступно как в ФП, так и в ООП. В МС разработали библиотеку RX которая как раз для этого и предназначена.

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

S_>>Какие функциональные языки лучше покрывают возможности XSLT ?

VD>Любые. Вопрос не в языках, а в библиотеках. Такие библиотеки как HaXML для Хаскеля или Linq для дотнет языков с успехом заменяют XSLT.

VD>В прочем, XSLT — это специализированный DSL и по кратности с ним трудно тягаться, но решения получаются вполне себе конкуретно-способные.

Да LINQ to XML по краткости далековато до XSLT.
Причем некоторые трансформации даже в MSDN рекомендуют делать при помощи "костыликов"(Annotations), части вновь создаваемого дерва в Annotations исходного прилеплять, или что-то типа того... что выглядит не очень.

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

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

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

VD>Реактивное же программирование и вовсе доступно как в ФП, так и в ООП.

Я согласен, есть множество библиотечных реализаций РП (даже моя личная ) разной степени кривизны. Однако хотелось бы поддержки со стороны языков программирования.

VD>В МС разработали библиотеку RX которая как раз для этого и предназначена.

Спасибо, посмотрю.

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

S_> Да LINQ to XML по краткости далековато до XSLT.

Да не так чтобы очень.

S_>Причем некоторые трансформации даже в MSDN рекомендуют делать при помощи "костыликов"(Annotations), части вновь создаваемого дерва в Annotations исходного прилеплять, или что-то типа того... что выглядит не очень.

Незнаю. Я таких рекомендаций не видел. А вот синтаксис XSL мне крайне не нравится. Нельзя все же язык для людей на основе ХМЛ-я делать.

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

D>Я согласен, есть множество библиотечных реализаций РП (даже моя личная ) разной степени кривизны. Однако хотелось бы поддержки со стороны языков программирования.

Дык за чем дело стало? Есть идеи как это должно выглядеть в ЯП?

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

VD>Дык за чем дело стало? Есть идеи как это должно выглядеть в ЯП?

Конкретно синтаксис не прорабатывал, но очевидно нужны конструкции наиболее удобные для дата-байндинга.

Например:

class Class1(
  X : int,
  Y : int
  )
{
  Z <= X + Y;
  Ints <= [X, Y, Z];
  Doubles <= from i in Ints select (double)i;
}

Соответственно, X и Y, это входные свойства, а Z, Ints и Doubles — выходные.
Примерно так.

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

D>Например:
D>

D>class Class1(
D>  X : int,
D>  Y : int
D>  )
D>{
D>  Z <= X + Y;
D>  Ints <= [X, Y, Z];
D>  Doubles <= from i in Ints select (double)i;
D>}
D>

D>Соответственно, X и Y, это входные свойства, а Z, Ints и Doubles — выходные.
D>Примерно так.

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

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

VD>Не очень понял чем это отличается от того же присвоения.

Это не присвоение, а описание потока данных. Полностью декларативное.
Например, оператор Z <= X + Y; означает, что при каждом изменении входного свойства X или Y, выходное свойство Z автоматически пересчитывается. Сответственно, пересчитываются все зависящие от Z выходные свойства, а это коллекции Ints и Doubles.

Можно также добавить внешние зависимости. Например:

class Class2(obj : Class1)
{
  Sum <= obj.Doubles.Aggregate(0, (sum, d) => sum + d);
}

Соответственно, при изменении входных свойств объекта obj выходное свойство Sum также автоматически пересчитается.

VD>Но подобное можно оформить в виде макросов Nemerle.

Макросы Немерла, это отдельная болезненная тема.

VD>Так что если есть идеи и желание можно осуществить их на практике своими руками, а не ждать от моря погоды.

Мне нужна реализация не привязанная к дотнету. Я бы предпочел скорее LLVM.

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

VD>>Реактивное же программирование и вовсе доступно как в ФП, так и в ООП.
D>Я согласен, есть множество библиотечных реализаций РП (даже моя личная ) разной степени кривизны. Однако хотелось бы поддержки со стороны языков программирования.

VD>>В МС разработали библиотеку RX которая как раз для этого и предназначена.

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

На таком условном примере: В UI лежит 1000 элементов, при изменении каждого сам перерисовывается. Чтобы изменения всех элементов не зависло, нужно заморозить, pending изменения кешируются, при разморозки все скопом применяются. Если этого не делать, то не поможет даже то что каждый элемент не весь экран перерисовывает а только свой охватывающий прямоугольник.
Не знаю в деталях как в WPF все сделано, но что-то не очень впечатляет.
Теже проблемы и с вычислительными реактивными задачами.

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

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

S_>С реактивными библиотеками практически не знаком, поэтому это скорее вопрос.
S_>ИМХО, в реактивных моделях, когда выстраиваются большие реактивные цепочки, графы. Очень важный вопрос это хороший механизм заморозки передачи изменений (или некие транзакции). Связано это с тем что все изменения не всегда нужны мгновенно, и с тем что изменения от нескольких источников чаще эффективнее обрабатывать пачками.

S_>На таком условном примере: В UI лежит 1000 элементов, при изменении каждого сам перерисовывается. Чтобы изменения всех элементов не зависло, нужно заморозить, pending изменения кешируются, при разморозки все скопом применяются. Если этого не делать, то не поможет даже то что каждый элемент не весь экран перерисовывает а только свой охватывающий прямоугольник.
S_> Не знаю в деталях как в WPF все сделано, но что-то не очень впечатляет.
S_>Теже проблемы и с вычислительными реактивными задачами.

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

Хороший вопрос. Я позаимствовал решение из архитектуры программного пакета 3D моделирования Maya. Оно заключается в принципе "тяни-толкай". Согласно этому принципу, распространение изменений происходит в 2 этапа. На первом этапе информация об изменении "проталкивается" через весь подграф зависимых свойств объектов, которые помечаются как измененные. На втором этапе код который нуждается в новом значении оконечного свойства "вытягивает" это значение из всего измененного подграфа. Попутно, естественно, все пересчитанные свойства помечаются как неизмененные.

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

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

D>Макросы Немерла, это отдельная болезненная тема.

Болезненная?

VD>>Так что если есть идеи и желание можно осуществить их на практике своими руками, а не ждать от моря погоды.

D>Мне нужна реализация не привязанная к дотнету. Я бы предпочел скорее LLVM.

Боюсь, что на нем еще очено долго ничего путного не будет.