Двоякое впечатление.
С одной стороны: зачем все это рисовать, если такие вещи не имеют отношения ни к сегодняшнему дню ни к завтрашнему? Ведь внешний вид интерфейса определяется прагматикой задачи для которой он создавался. В то время как в «киношных» интерфейсах прагматика, если она вообще очерчена приносится в жертву в угоду, как автор верно подчеркнул, эффектности. Вот если бы действительно усидеть на двух стульчиках и добиться соответствия интерфейса прагматике, сохранив зрелищность.
С другой стороны человеко-машинные интерфейсы действительно переживают кризис жанра и это хорошая попытка хотя бы попытаться заглянуть в будущее, хотя бы чистохудожественными средствами. Меня поражает обмен человека и машины старой доброй текстовой информацией (также во всех этих навороченных «киношных» визуализациях присутствует текст). Не уж то ничего лучше чем текст для восприятия быть не может? (это я клоню к тому, что будущее, возможно, за нейроинтерфейсами). А рабочее место программиста и форма представления программы все те же уже больше чем пол века спустя. Закрадывается интересный вопрос: может ли оно быть другим?
Мысль проста: там где возможно и разумно, почему бы не использовать композиционный подход, который может дать преимущества, описанные в статье. Это больше чем преимущества при просто применении функционального языка. В первую очередь, это иной подход к конструированию ПО, который заключается в абстрагировании от синтаксиса конкретного языка, а так же в автоматизированной поддержке (про средства поддержки позже напишу) мыслительного процесса человека, если он мыслит композициями. Моя вина, что как раз эту самую интересную тему в этом материале не задел. Так бы еще бы понятней было.
А если от компьютера нужна не математика, то надо либо начинать делать грязные функции, либо «потребности не-в-математике на сегодня не имеется».
Естественно, но вместе с этим я ж не стремлюсь абсолютизировать, это было бы неправильно.
Благо корректность такого «переводчика», надо доказывать один раз. А корректность конкретной переведенной программы будет наследоваться от корректности построенной функции (тут поправьте, если не прав).
Насчет третьего пункта, то в с генерированном коде важна только интерфейсная часть, т.к. с учетом того, что он предположительно корректен, никто туда лезть не будет. Ну кроме того случая, когда надо внести улучшения, но это приводит к необходимости доказывать корректность еще раз.
Насчет тонкостей языка, то не обязательно опускаться на такой низкий уровень, когда надо считать нули вначале. Хотя в целом, действительно, много нюансов, но из-за этого не особо переживают разработчики GHC. Конечно, это не повод следовать их примеру, но единственное, что мы можем сделать в этом случае, так это лучше анализировать код, находить эвристики.
Также можно пофантазировать и представить сообщество, которое добавляет в общую базу кода код с «вручную» доказанной корректностью.
Справедливо всё замечено.
P.S. Собственно, всё и начиналось с того, что я пришел к своему научруку и сказал, что круто было бы делать «кастомные» вычислители на ПЛИС, максимально автоматизировав процесс генерации решения, а он доктор физико-математических наук и про ПЛИС и электронику в общем он мало чего знал, но сказал что может помочь заложить под это теоретический базис.
Совершенно верно. Более того, согласитесь, ведь такую запись можно перевести в любой язык программирования машинным способом, так как алгоритм становится полностью формализованным. А разработчик потом ее доработает, добавив ввод-вывод, события, интерфейсы и т.д.
Все зависит от уровня абстракции, на котором работаем. Если мы записываем композиции, то X не нужен, так как функции выполняют роль аргумента. Но как только композицию применили, то X появляется. Так как примененная композиция над заданными функциями в результате дает тоже функцию. Надеюсь помогло. Может, картинку надо нарисовать, не знаю :)
Нет, кто-то пишет вступительный раздел диссертации и хочет при этом провести время с пользой.
Под анализом программы имеется в виду нахождения способа ее разбития. «Грязные» функции пусть остаются грязными. Дело в том, что, как писалось ранее, всезаменяющее решение не предлагается. Тут скорее хотелось бы предложить средство проектирования именно вычислительных задач, забыв при этом что «грязные функции» существуют. Собственно, как я себе представляю это:
1. Человек строит композиционное представление решения задачи, разбивая ее на композиции.
2. Решение задачи автоматически конвертируется в один из языков программирования, да и не только программирования. Я, например, разработал конвертер такого решения в Verilog.
3. Дописывается все остальное прямо не имеющее отношение к вычислениям ввод-вывод, например.
Чем кардинально отличается? Я в статье ответил, может, надо было еще более ярко подчеркнуть. Я не видел средств порождения новых композиций. Собственно это и хотелось бы предложить в своей работе.
Выяснилось, что политиков, которых показывают по телевизору, на самом деле не существует. Их создают с помощью сверхмощного американского компьютера. Чем выше пост виртуального политика, тем лучше 3D графика.
Ведь писал «красивый», да и насчет экономичности не уверен. Можно было бы сравнить, например, со скутером. Экономный, перевозит из A в B, не дорог в обслуживании, стоит сам не дорого. Просто что бы исправно делал свою работу.
Поразительно, но подсветка нужна, чтобы можно было пользоваться часами в темноте :)
Я не хочу что бы подсветка была нужна, что бы часами можно было пользоваться на солнце.
2) Зачем?
Мне хватает того, что я думаю о том, что бы не забыть зарядить смартфон и планшет.
Впрочем согласен насчет секундомера, будильника, таймера обратного отсчета. Идеологически они должны быть в часах, да и есть, если взглянуть на G-shock от Casio. Но ведь тот самый G-shock держит батарею нормально и информацию с него считывать удобно.
Если нет — зачем они вообще нужны?
Красивый аксессуар, по которому можно узнать время и дату. Вроде справляются.
С одной стороны: зачем все это рисовать, если такие вещи не имеют отношения ни к сегодняшнему дню ни к завтрашнему? Ведь внешний вид интерфейса определяется прагматикой задачи для которой он создавался. В то время как в «киношных» интерфейсах прагматика, если она вообще очерчена приносится в жертву в угоду, как автор верно подчеркнул, эффектности. Вот если бы действительно усидеть на двух стульчиках и добиться соответствия интерфейса прагматике, сохранив зрелищность.
С другой стороны человеко-машинные интерфейсы действительно переживают кризис жанра и это хорошая попытка хотя бы попытаться заглянуть в будущее, хотя бы чистохудожественными средствами. Меня поражает обмен человека и машины старой доброй текстовой информацией (также во всех этих навороченных «киношных» визуализациях присутствует текст). Не уж то ничего лучше чем текст для восприятия быть не может? (это я клоню к тому, что будущее, возможно, за нейроинтерфейсами). А рабочее место программиста и форма представления программы все те же уже больше чем пол века спустя. Закрадывается интересный вопрос: может ли оно быть другим?
Естественно, но вместе с этим я ж не стремлюсь абсолютизировать, это было бы неправильно.
Насчет третьего пункта, то в с генерированном коде важна только интерфейсная часть, т.к. с учетом того, что он предположительно корректен, никто туда лезть не будет. Ну кроме того случая, когда надо внести улучшения, но это приводит к необходимости доказывать корректность еще раз.
Насчет тонкостей языка, то не обязательно опускаться на такой низкий уровень, когда надо считать нули вначале. Хотя в целом, действительно, много нюансов, но из-за этого не особо переживают разработчики GHC. Конечно, это не повод следовать их примеру, но единственное, что мы можем сделать в этом случае, так это лучше анализировать код, находить эвристики.
Также можно пофантазировать и представить сообщество, которое добавляет в общую базу кода код с «вручную» доказанной корректностью.
Справедливо всё замечено.
P.S. Собственно, всё и начиналось с того, что я пришел к своему научруку и сказал, что круто было бы делать «кастомные» вычислители на ПЛИС, максимально автоматизировав процесс генерации решения, а он доктор физико-математических наук и про ПЛИС и электронику в общем он мало чего знал, но сказал что может помочь заложить под это теоретический базис.
Совершенно верно. Более того, согласитесь, ведь такую запись можно перевести в любой язык программирования машинным способом, так как алгоритм становится полностью формализованным. А разработчик потом ее доработает, добавив ввод-вывод, события, интерфейсы и т.д.
Под анализом программы имеется в виду нахождения способа ее разбития. «Грязные» функции пусть остаются грязными. Дело в том, что, как писалось ранее, всезаменяющее решение не предлагается. Тут скорее хотелось бы предложить средство проектирования именно вычислительных задач, забыв при этом что «грязные функции» существуют. Собственно, как я себе представляю это:
1. Человек строит композиционное представление решения задачи, разбивая ее на композиции.
2. Решение задачи автоматически конвертируется в один из языков программирования, да и не только программирования. Я, например, разработал конвертер такого решения в Verilog.
3. Дописывается все остальное прямо не имеющее отношение к вычислениям ввод-вывод, например.
Чем кардинально отличается? Я в статье ответил, может, надо было еще более ярко подчеркнуть. Я не видел средств порождения новых композиций. Собственно это и хотелось бы предложить в своей работе.
Могу подписать
Hash: SHA512
— -----BEGIN PGP MESSAGE-----
Version: Keybase OpenPGP v1.0.5
Comment: keybase.io/crypto
wcBMAyG4iIfOSoU/AQf/Q1vuzTch6NiaXLtt0pymsxTOjub/Cg22f2jTPb+sHoqK
/o5D6nqTkQc7+FN6XiKoO0M+D1lSry195W96U2vguHTNkGuiTyTP//aE8EA+yXSd
4FNqARCrvwMxOZSf5Ny3VAaYy4IiIdYwXFqcRXrLbSd5oPzNSDHydFyJXRbExND/
A3AGoAoYYKSNIh21c8wY1hqr8MIMHbwK4sS51j+gzzNLT+86ICisWaXLdKoA+9hN
bz3NzXgrW+Gdne/Cu01s3ZxEtP9FkckUDU630dXse7EW+HtDaOvM/JGvChm7j2O9
ukwMzDPUS7bGe9AzCPngnJGKJGykVK2MGcwFVhFyStJhAW7+ltZcLVlzDks7MkMB
6Z9gasToCP0RLU2Zo9XvVCkw0w0dvRMt3c8Yy0/cMlM13+YQruLzruITZoGpBTsV
ONPzQQZs2AoY4JCeGEjPZowWJK9ObB3+JbfbRkoEWEODEA==
=WbbC
— -----END PGP MESSAGE-----
-----BEGIN PGP SIGNATURE-----
Version: Keybase OpenPGP v1.0.5
Comment: keybase.io/crypto
wsBcBAABCgAGBQJUJWTVAAoJEJEvdB/dJj8izy8IAJpZgAKnOZ0VqovY503EjguC
wCatrtIq0f2Hsqwk7immQYb0s0AqQ3n1B921QOU4UyUKZY32hwNqVtWqPKZyUdki
ZiPpaVCr/MMmiIHwT2VguDd6xHPqY1enNELHtJegim8984IJu9AcABsc9JvHL2qh
V2tC56JZWnaIZPyOc1WhSVH7Jts2U7EmgnUpXkr44bZhf1Yr2E9vbLVNoaHOjuOQ
tQ+t7XQ2cBkbzhH9otUVSuq8lqPJB880HP7Di8V16vKVDXdQVibVQFD0IZtD0N0V
pViWc9yxItBI5ptB1yz8erfYXtwxxOEoulnLKuES5k0uw9lvK/mg/RXwTr1cxZg=
=OKoh
-----END PGP SIGNATURE-----
«Generation P»
Я не хочу что бы подсветка была нужна, что бы часами можно было пользоваться на солнце.
Мне хватает того, что я думаю о том, что бы не забыть зарядить смартфон и планшет.
Впрочем согласен насчет секундомера, будильника, таймера обратного отсчета. Идеологически они должны быть в часах, да и есть, если взглянуть на G-shock от Casio. Но ведь тот самый G-shock держит батарею нормально и информацию с него считывать удобно.
Красивый аксессуар, по которому можно узнать время и дату. Вроде справляются.
Ну хотя бы так. Просто вроде как собирались расширять функционал. С этой точки зрения цвета были бы кстати.