Пишу код и решил проанализировать, почему несмотря на наличие среды разработки, простой язык, всяческие конструкции управления так долго приходится писать вообщем то простые вещи. Пришел к выводу, что большую часть времени занимает написание кода преобразования данных их одних форматов в другие: из полей в таблицы, из массивов в строки и наборот.
Вот получили результат вычисления, но дальше кго надо перепаковать в другой формат и отдать другой процедуре на обработку, определить соответсвие переменных, считай — понятий. Понятия эти проходят НАД программой в момент её проектирования, но прячутся, как жевачка в волосах В ТЕКСТЕ, когда программу пишешь или еще хуже — читаещь чужой код.
Прихожу к выводу, что объекты — это только "часть правды". Объекты, как концентрация нашего "проектного представления" о программе безусловно полезны. Но вот если бы еще вынети ДАННЫЕ на верхушку программы и вынести их как обязательную конструкцию. Данные — унифицировать по строению, — как таблицы в СУБД. А между ними прописать явняе отношения — как особые конструкции вроде 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>Я согласен, есть множество библиотечных реализаций РП (даже моя личная ) разной степени кривизны. Однако хотелось бы поддержки со стороны языков программирования.
Дык за чем дело стало? Есть идеи как это должно выглядеть в ЯП?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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.
Боюсь, что на нем еще очено долго ничего путного не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Dufrenite, Вы писали:
D>>Мне нужна реализация не привязанная к дотнету. Я бы предпочел скорее LLVM.
VD>Боюсь, что на нем еще очено долго ничего путного не будет.
Здравствуйте, Silver_s, Вы писали:
S_> Вот был бы фреймворк хорошо управляющий механизмами таких заморозок, позволяющий и вручную и по таймерам эти заморозки/транзакции проводить.
В Rx много интересного хелперного функционала.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, Dufrenite, Вы писали:
D>Хороший вопрос. Я позаимствовал решение из архитектуры программного пакета 3D моделирования Maya. Оно заключается в принципе "тяни-толкай". Согласно этому принципу, распространение изменений происходит в 2 этапа. На первом этапе информация об изменении "проталкивается" через весь подграф зависимых свойств объектов, которые помечаются как измененные. На втором этапе код который нуждается в новом значении оконечного свойства "вытягивает" это значение из всего измененного подграфа. Попутно, естественно, все пересчитанные свойства помечаются как неизмененные.
Расшифрую выделенное: вытягивание здесь означает перевычисление изменившихся узлов тех и только тех, от которых зависит вычисляемое свойство. Уверен, что подразумевалось именно это, но людьми не знакомыми с Maya это может быть неочевидно.
Прихожу к выводу, что объекты — это только "часть правды". Объекты, как концентрация нашего "проектного представления" о программе безусловно полезны. Но вот если бы еще вынети ДАННЫЕ на верхушку программы и вынести их как обязательную конструкцию. Данные — унифицировать по строению, — как таблицы в СУБД. А между ними прописать явняе отношения — как особые конструкции вроде SQL.
Могу ошибаться, но объектно-ориентированное программирование может решать и такие проблемы. Если я правильно понял вопрос, то классическим решением является декомпозиция входных и выходных данных в объект и добавление в эти объекты методов преобразования откуда надо и во что надо. Например, что-то вроде:
void OnSomethingArrived( XMLStream* incoming )
{
var something = new Something();
something.FromXmlStream( incoming );
ProcessSomething( something ); // <- вот тут у нас логика
var database = GetDatabase();
something.ToDatabase( database ); // <- тут переложили в другой формат.
}
Здравствуйте, Dufrenite, Вы писали:
D>Это не присвоение, а описание потока данных. Полностью декларативное. D>Например, оператор Z <= X + Y; означает, что при каждом изменении входного свойства X или Y, выходное свойство Z автоматически пересчитывается. Сответственно, пересчитываются все зависящие от Z выходные свойства, а это коллекции Ints и Doubles.
D>Можно также добавить внешние зависимости. Например: D>
D>class Class2(obj : Class1)
D>{
D> Sum <= obj.Doubles.Aggregate(0, (sum, d) => sum + d);
D>}
D>
D>Соответственно, при изменении входных свойств объекта obj выходное свойство Sum также автоматически пересчитается.
Здравствуйте, vdimas, Вы писали:
V>Хм, электронщики все-таки повлияли на программистов.
Ухлопал кучу времени, пытаясь понять чего мне не хватает в известных подходах. Придумал реактивное программирование, а оказалось, что изобрел велосипед.
Когда же увидел примеры VHDL, то в очередной раз понял что образование должно включать не только программирование.
V>Когда-то давно на эту тему фантазировал: http://www.rsdn.ru/forum/philosophy/1676773.1.aspx
Мыслим в одном направлении
D>>Мне нужна реализация не привязанная к дотнету. Я бы предпочел скорее LLVM.
V>Эта техника не зависит от платформы, ибо реализация ее тривиальна (кроме циклических случаев и прочих "гонок"), дело в языке описания зависимостей.
Техника то не зависит, а конкретная реализация очень даже зависит.
Здравствуйте, Dufrenite, Вы писали:
D>Ухлопал кучу времени, пытаясь понять чего мне не хватает в известных подходах. Придумал реактивное программирование, а оказалось, что изобрел велосипед. D>Когда же увидел примеры VHDL, то в очередной раз понял что образование должно включать не только программирование.
Дык, вроде программистам электронику и устройства ЭВМ дают непрерывно с 3-го по 5-й курс. Не учат толком — это да.
Там это все было не просто так обсуждение, а часть гораздо более серьезного. Реактивный подход — это одно из немногих направлений, где можно будет значительную часть программы описывать с помощью графических IDE, постепенно отказываясь от "настукивания" плоского текста исходников как основного способа представления программ. (на всякий случай, слово "основного" — ключевое, т.е. полностью отказаться никто не призывает)
Здравствуйте, vdimas, Вы писали:
V>Не учат толком — это да.
VHDL не изучали, это точно. Но жаловаться не буду: рассказывали много интересного, кое что даже пригодилось (МИЭТ).
V>Там это все было не просто так обсуждение, а часть гораздо более серьезного. Реактивный подход — это одно из немногих направлений, где можно будет значительную часть программы описывать с помощью графических IDE, постепенно отказываясь от "настукивания" плоского текста исходников как основного способа представления программ. (на всякий случай, слово "основного" — ключевое, т.е. полностью отказаться никто не призывает)
Пока что, плоский текст, это наиболее дешевое решение. А так, да. Большинство data-flow языков — графические.
Прихожу к выводу, что объекты — это только "часть правды". Объекты, как концентрация нашего "проектного представления" о программе безусловно полезны. Но вот если бы еще вынети ДАННЫЕ на верхушку программы и вынести их как обязательную конструкцию. Данные — унифицировать по строению, — как таблицы в СУБД. А между ними прописать явняе отношения — как особые конструкции вроде SQL.
EOH>Могу ошибаться, но объектно-ориентированное программирование может решать и такие проблемы. Если я правильно понял вопрос, то классическим решением является декомпозиция входных и выходных данных в объект и добавление в эти объекты методов преобразования откуда надо и во что надо. Например, что-то вроде:
EOH>
EOH>void OnSomethingArrived( XMLStream* incoming )
EOH>{
EOH> var something = new Something();
EOH> something.FromXmlStream( incoming );
EOH> ProcessSomething( something ); // <- вот тут у нас логика
EOH> var database = GetDatabase();
EOH> something.ToDatabase( database ); // <- тут переложили в другой формат.
EOH>}
EOH>
Хех, я понимаю, что можно написать "преобразователь". Но акцет был в другом. Сейчас, когда вы читаете программу — в центре внимания — метод, функция, процедуры. Программа начинается с главной процедуры, которая вызывает другие и так далее. Во всех конструкциях управления — вызов функии и процедур — на первом месте. В ООП данные даже предлагается прятатть за свойствами, чтобы их вообще не было. Чтобы был "мир процедур".
А представьте себе язык, который начинается с описания выходных данных, например (это что-то вроде цели), от которых можно оттолкнуться и черех лес отношений с другими данными перейти к пониманию как эта цель достигается и как другие данные, а также отношения меду ними влияют на результат (тяни-толкай). В таком подходе не страдает и процедурная сторона — процедуры по прежнему явно читаемы и их место в общем алгоритме понятно. А в отношении данных, за счет их выставления на показ и возможности проследить все "руки", тянущихся к ним отношений — степень выразительности и понимания программы значительно возрастает. А значит — программы становится и легче читать.
Кроме упомянутых здесть систем реактивного программирования (очень интересно было узнать), есть еще Data-Driver-Design. Тоже советую почитать.
Но возникает проблема: раз данные становятся "общественным достоянием", раз они выходят из под ига объектов, то ООП расслаивается, как растаявшее мороженное: отдельно функции которые несут процедурную, активную, действующую составляющую. И отдельно — данные, которые замыкают на себе систему отношений, концентрируют взаимоотношения процедур и функций и делают это более отчетливо чем управляющие конструкции. Кроме того, мы получаем новые замечательные возможности. Все наверняка знакомы с ситуацией — скачав очередной DataGrid из интернета, обнаруживаем, что в нем есть очень корошие качества (fratures) А и Б, но как назло нет качеств В и Г, которые есть в другом таком же компоненте. Или наконец нам удалось скачать компонент в котормо есть почти все. Но это будет МОНСТР, который пугает сложностью своей настройки и тяжеловесностью. В случае расслоения объектов мы можем получить следующее — вот в этой библиотеке ест замечателная функция размещения ячеек в окне. Эта функция например позволяет делать многоуровневые заголовки. А эта функция позволяет выполнять хитрые сортировки, подсунутых ей в качестве данных колонок, а эта функция позволяет все красиво раскаршивать. В итоге мы получаем композитный объект, скрестив "коня и трепетную лань".
Но, после "расслоения" мы получаем новые проблемы: данные, перестав прятаться в объектах, должны приобрести универсальность для их обработчиков и самопрезентабельность. Они — должны быть такими данными, которые могут обратиться в любую процедуру и быть там обработанными. Функции, будучи написанными разными авторами, тем не менее не должны предъявлять к данным особых требований по структуре — т.е. структура данных не должна быть строго предопеределена.
В технологии COM, когда есть ситуация независимого создания объектов на разных языках разными авторами в разное время независимо друг от друга — предусмотрена обязательная спецификация обмена данными — UDT (или UDF — что то такое).
Универсальная структура данных — какая она?
Можно представить, что все данные — это ассоциативные массивы. Тогда дата это массив:
TDate["day"]
TDate["month"]
TDate["year"]
И мы хотим, чтобы все функции принимали его, как родного.
Но возможно ли это? А если кто-то написал функцию, понимающую дату как количество дней от крещения Руси? Тогда что?
Значит без преобразователей не обойтись?
Хорошо, пусть так, но страшно представить себе количнство перобразователей в большой программе, если разные функции ориентированы на работу с различными типами...
То есть определив в программе основные типы и получив в распоряжение функции исполнители, мы один раз указываем какияи функциями будут селаны преобоазования для входа каждой функции и потом завязывая отношения между функциями посредством связывающих их данных — уже не упоминаем преобразователи, предполагая, что "компилятор" подставит их сам исходя из заданных отношений входов и выходов функций один раз в начале программы. Так? ... А что карсиво получется.
Есть и другой подход — единая библиотека типов и следование ей всех производителей.
А представьте себе язык, который начинается с описания выходных данных, например (это что-то вроде цели), от которых можно оттолкнуться и черех лес отношений с другими данными перейти к пониманию как эта цель достигается и как другие данные, а также отношения меду ними влияют на результат (тяни-толкай).
Функциональные языки так построены. Проблема, на мой взгляд, в том, что это нишевые задачи. А задачи из реальной жизни — "давайте напишем paint". И какие в графическом редакторе будут входные или выходные данные? Или виртуальную машину. Или средство удаленного доступа. Или GUI для системы управления задачами.
А представьте себе язык, который начинается с описания выходных данных, например (это что-то вроде цели), от которых можно оттолкнуться и черех лес отношений с другими данными перейти к пониманию как эта цель достигается и как другие данные, а также отношения меду ними влияют на результат (тяни-толкай).
EOH>Функциональные языки так построены. Проблема, на мой взгляд, в том, что это нишевые задачи. А задачи из реальной жизни — "давайте напишем paint". И какие в графическом редакторе будут входные или выходные данные? Или виртуальную машину. Или средство удаленного доступа. Или GUI для системы управления задачами.
Ну во первых ФЯП в отношении ДАННЫХ тоже построены как Процедурные языки. Вот например из статьи:
"Программа на языке Хаскелл — функция, описывающая процесс вычисления."
Нет там никакого императивно-ведущего описания данных. Переменные путаются под ногами ФУНКЦИЙ — как везде.
А во вторых — никакой нишевости нет. Есть традиции мышления, которые сложно преодолевать. Как бы я писал наинт на ФП:
Тут — если вычислена Функция_определения_кисти и СобытиеКнопкиМыши(), то вычислися функция Функция_Ожидающая_события и быдет определена Точка_области_рисованяи — которая может быть структурой данных непосредственно адресованной на канву рисования.
Здравствуйте, salog, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>Уверен, что основная проблема тут или в языке, или в его знании. Не возьмусь угадать сам язык, но точно сказать, что это классический ООЯ. Причем если это C#, то с LINQ-ом ты незнаком.
S>Спасибо за упоминание. Я слышал естественно, но не вникал. Щас сижу читаю статью.
И даже не только/столько LINQ, как ADO.NET Entity Framework.
Hibernate наверное что-то подобное для Явы.
Здравствуйте, salog, Вы писали:
S>Здравствуйте, Eye of Hell, Вы писали:
S>А во вторых — никакой нишевости нет. Есть традиции мышления, которые сложно преодолевать. Как бы я писал наинт на ФП:
S>Тут — если вычислена Функция_определения_кисти и СобытиеКнопкиМыши(), то вычислися функция Функция_Ожидающая_события и быдет определена Точка_области_рисованяи — которая может быть структурой данных непосредственно адресованной на канву рисования.
Если говорить слегка категорично, то единственная современная проблема программирования — это сложность.
Если я правильно вас понял, то программу в вашем понимании можно представить как совокупность наборов:
ФорматДанных1 < ФункцияПреобразвания + СобытиеЗапускаПреобразования > ФорматДанных2
плюс граф зависимостей таких наборов между собой и средства, которые контролируют "наведенные" преобразования.
Такая модель действительно очень удобная во многих случаях, более того, частные ее случаи реализованы в промышленных языках программирования, датабиндиг, сериализация и т.п.
Хотя, например, в .НЕТ реализовать свой датабиндиг — геморрой конкретный, именно из-за отсутствия встроенных средств контроля неконтролируемых каскадных событий преобразования.
Собственно, то, что вы описываете (опять же, если я правильно понял) — это парадигма/способ/стратегия проектирования и реализации, и применять ее можно даже в С++.
Специализированные языки программирования привносят лишь удобство.
Более того, я не случайно в начале упомянул о сложности.
В сложном приложении потоки событий будут очень сложными и запутанными, и фактически разобраться в них может быть сложнее, в императивном коде.
Более того, на сложность понимания напрямую влияет естественность концепции — к примеру,
для UI наиболее естественной (и поэтому такой распространенной) является модель реакции на события пользовательского ввода.
Данные же как функция от пользовательского интерфейса — согласитесь, это менее очевидная для понимания вещь, хотя и более чистая и абстрактная.
Кроме того, остается вопрос производительности.
К примеру, функциональные языки элегантны во многом за счет иммутабельности данных,
но в то же время — в корне многих оптимизаций производительности лежит именно мутабельность данных.
Здравствуйте, salog, Вы писали:
S>А представьте себе язык, который начинается с описания выходных данных, например (это что-то вроде цели), от которых можно оттолкнуться и черех лес отношений с другими данными перейти к пониманию как эта цель достигается и как другие данные, а также отношения меду ними влияют на результат (тяни-толкай). В таком подходе не страдает и процедурная сторона — процедуры по прежнему явно читаемы и их место в общем алгоритме понятно. А в отношении данных, за счет их выставления на показ и возможности проследить все "руки", тянущихся к ним отношений — степень выразительности и понимания программы значительно возрастает. А значит — программы становится и легче читать.
Вот вы и пришли самостоятельно практически к тому же самому, что написал "Эдсгер Дейкстра в своей книжке "Дисциплина программирования"...
Вывод слабейшего предусловия на основе требуемого постусловия... Он и язык соответствующий там описывает...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
sto>Кроме того, остается вопрос производительности. sto>К примеру, функциональные языки элегантны во многом за счет иммутабельности данных, sto>но в то же время — в корне многих оптимизаций производительности лежит именно мутабельность данных.
Зато в корне других оптимизаций (особенно в многопоточной среде) наоборот лежит иммутабельность данных
) разной степени кривизны. Однако хотелось бы поддержки со стороны языков программирования.
