Здравствуйте, thesz, Вы писали:
T>Лично мне интересно, что же такого ты придумал, что стоит выше уровнем, чем ФП.
T>В которое ФП входит и <a href=http://en.wikipedia.org/wiki/Martin-Lof_type_theory>теория типов</a>, которая ну очень высокоуровневая.
Да ничего я не придумал. Просто беру конкретную задачу или класс задач и подбираю на мой взгляд оптимальное решение. Это творчество а не теории.
Топикстартер поставил вполне конкретную задачу и я не вижу никакого способа решить её применив функциональную декомпозицию или что нибудь подобное. Здесь совсем другой подход нужен.
Здравствуйте, thesz, Вы писали:
T>стоит выше уровнем, чем ФП.
Вопрос. Зачем такая фиксация на высокоуровневости?
ИМХО, чем выше уровень, тем больше фиксация на какой-то одной стороне задачи. Вот теория типов, она, наверное, описывает задачу с точки зрения типов. Как она мне поможет, если мне надо, например, по алгоритмам протоколы передачи данных генерировать, на С++ и Java. Это очень далеко от проблем, описываемых этой теорией. В данном контексте она практически бесполезна.
Здравствуйте, Young_Pioneer, Вы писали:
C>>Ну вот. Опять. Ты хочешь сделать заранее самую идеальную возможную печатную систему, у которой просто программы будут отключать ненужные функции. Y_P>Печатные системы будут делать профессиональные производители печатных систем.
Ну сделают, и что дальше?
Y_P>Конкретный пример: есть реальный клиент, который хочет видеть нашу печать в Visio, чтобы можно было печатать большие изображения с разбивкой на листы. В принципе, это можно сделать через драйвер принтера (интерфейс драйвер, несмотря на свою сложность, используется очень часто, например для создания pdf), но в будущем хотелось бы иметь более простой метод.
А в Visio есть все нужные примитивы? Например, в Visio могут быть только квадратичные сплайны, а вам потребуются кубические. И упс. Всё.
C>>Только проблема-то не в этом. Проблема в том, как сделать так, чтобы дополнительные функции можно было добавлять не изменяя программ. Y_P>Если мы меняем слабую печать на более мощную, то чем это не улучшение. Сейчас программы улучшаются с помощью плагинов. По сути, я предлагаю те же плагины, только стандартизованные.
Стандартизовать (с трудом) можно только такой интерфейс:
interface IPlugin
{
String getName();
}
C>>Твоя идея: делаем суперкастомизуемую систему, так чтоб пользователь мог нажать правой клавишей на любое поле ввода и вместо него воткнуть красивое поле ввода с поддержкой векторной графики и встроенным в виде пасхального яйца Doom3, использущим это поле ввода для savegame'ов. Y_P>"Кастомизация" как раз не главное. И "куда угодно что угодно" воткнуть пользователь не сможет — на это есть программисты.
Ну ладно, это сделал программист. Что дальше? Работать-то всё равно не будет.
Y_P>Эти модули: Y_P>-загрузка и сохранение из/в определенный формат (можно добавлять модули) Y_P>-пользовательский интерфейс (можно заменять модули) Y_P>- печать (можно добавлять / заменять модули) Y_P>- общие алгоритмы: перевод, шифрование, векторизация растра и т.д. Y_P>многие из таких модулей уже сейчас делаются профессионалами и продаются в виде компонентов либо исходников. Только без каких-либо СТАНДАРТОВ.
Даже этот список не подлежит нормальной компонентизации.
Y_P>COM даёт богатые возможности совместного использования компонентов программ и иногда методы тотальной "кастомизации" самих программ. Мы тоже делаем COM компоненты, и клиенты-ПРОГРАММИСТЫ легко вставляют их в свои программы. Но НЕТ СТАНДАРТА, чтобы написать компонент, который вставится во все профессиональные программы, которым может понадобится этот функционал. COM, конечно, может быть использован как база для реализации идеи модулей, но лучше создать новую технологию.
Вообще-то, есть OLE.
C>>Это уже было давно придумано и даже сделано, и называется OLE Y_P>То есть можно сделать COM объект, читающий простенький растровый формат '*.abc' и такие программы, как MS Office, Google Chrome, Photoshop, AutoCAD, 1C и другие "поймут" этот COM объект и будут открывать *.abc подобно *.bmp? Один плагин для всех?
Примерно так. Можно вставить документ *.abc как объект в документ Word'а и прямо внутри Word'а его редактировать с помощью твоего приложения. Попробуй сам — из Visio сделай cut&paste в Word и посмотри.
T>>Лично мне интересно, что же такого ты придумал, что стоит выше уровнем, чем ФП. T>>В которое ФП входит и <a href=http://en.wikipedia.org/wiki/Martin-Lof_type_theory>теория типов</a>, которая ну очень высокоуровневая. D>Да ничего я не придумал. Просто беру конкретную задачу или класс задач и подбираю на мой взгляд оптимальное решение. Это творчество а не теории.
С теорией лучше, нес па?
D>Топикстартер поставил вполне конкретную задачу и я не вижу никакого способа решить её применив функциональную декомпозицию или что нибудь подобное. Здесь совсем другой подход нужен.
А я не вижу никакого способа решить её, не применив функциональную декомпозицию или что нибудь подобное.
Для стандартизации компонент типы нужны? Нужны.
Эффекты надо типизировать? Надо.
Вот и пришли к системе типов с типизацией эффектов, самой простой из которых является Хаскельная.
Как-то так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>стоит выше уровнем, чем ФП. D>Вопрос. Зачем такая фиксация на высокоуровневости?
Потому, что удобно.
D>ИМХО, чем выше уровень, тем больше фиксация на какой-то одной стороне задачи. Вот теория типов, она, наверное, описывает задачу с точки зрения типов. Как она мне поможет, если мне надо, например, по алгоритмам протоколы передачи данных генерировать, на С++ и Java. Это очень далеко от проблем, описываемых этой теорией. В данном контексте она практически бесполезна.
Если ты хочешь текст генерировать, то кое-что из теории типов (она же "зависимые типы (данных)") может быть полезно. Причем напрямую.
Что самое интересное, на языке с зависимыми типами данных обычно реализуется описание проблемы, которое потом интерпретируется. Результат интерпретации, в частности, можеть быть и результатом компиляции — путем специализации.
Так что я напрямую вижу, что самое близкое к этой дискуссии находится в районе зависимых типов данных.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Cyberax, Вы писали:
C>Только оказывается, что это поле ввода используется внутри приложения в текстовом виде. И попытка туда добавить графику приведёт к краху. Вот и закончилась эта история.
Здравствуйте, minorlogic, Вы писали:
C>>Только оказывается, что это поле ввода используется внутри приложения в текстовом виде. И попытка туда добавить графику приведёт к краху. Вот и закончилась эта история. M>Неправда твоя , есть же MPEG7
???
A>В свое время пользовалась популярностью библиотека turboVision. A>Это чтобы окошки-менюшки в ДОС-е рисовать. A>Программы выглядели настолько одинаково, что пользователь забывал в какой программе он находится. A>Обучению это не сильно помогало. Ну да, выпадающее меню всегда сверху. Ну и что? A>Ведь то, что означает каждое действие все равно нужно было учить.
TurboVision и Apple UI Guidelines немного отличаются.
Например, наличием спецпункта меню с названием программы. Тем, что одинаковые действия делаются одинаковыми клавишами и этих клавиш достаточно много.
Наверное, чем-то ещё.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, minorlogic, Вы писали:
C>>>Только оказывается, что это поле ввода используется внутри приложения в текстовом виде. И попытка туда добавить графику приведёт к краху. Вот и закончилась эта история. M>>Неправда твоя , есть же MPEG7 C>???
Здравствуйте, minorlogic, Вы писали:
M>>>Неправда твоя , есть же MPEG7 C>>??? M>http://en.wikipedia.org/wiki/Mpeg7 M>Стандарт на взаимодействие медиа данных и пользователя , предусматривает очень богатый набор взаимодействий.
Вот блин. Прочитай что я написал.
Твоя программа сможет вдруг обрабатывать Mpeg7 вместо plain text во всех полях ввода?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, minorlogic, Вы писали:
M>>>>Неправда твоя , есть же MPEG7 C>>>??? M>>http://en.wikipedia.org/wiki/Mpeg7 M>>Стандарт на взаимодействие медиа данных и пользователя , предусматривает очень богатый набор взаимодействий. C>Вот блин. Прочитай что я написал.
C>Твоя программа сможет вдруг обрабатывать Mpeg7 вместо plain text во всех полях ввода?
Так и я об этом , если будет потдерживать стандарт Мpeg7 то сможет. Я просто хотел отметить что даже не такой нетривиальный пример может быть стандарт.
Здравствуйте, thesz, Вы писали:
T>С теорией лучше, нес па?
Зависит от задачи. Чаще всего хватает простого здравого смысла. Опять же, можно подменить реальное условие задачи, имеющее ценность для бизнеса, формулировками красивой теории. Была даже байка о применении сразу нескольких паттернов проектирования в десяти строчках кода.
Я не отрицаю полезность теоретических изысканий, но мой пойнт в том, что даже применение самой современной теории не гарантирует результата. Может оказаться так, что ты ухлопаешь кучу времени на реализацию сложной функциональности, а потом обнаружишь, что существует более простой путь, не предусмотренный теорией.
Я сам одно время занимался теоретическими исследованиями по высшей алгебре, но потом понял, что это просто никому не нужно. Между теорией и практикой в подавляющем большинстве случаев лежит пропасть непреодолимая.
Хотя, конечно, ты прав. Если область хорошо изучена то порыться в публикациях стоит.
T>А я не вижу никакого способа решить её, не применив функциональную декомпозицию или что нибудь подобное.
Для решения этой задачи надо применять все известные виды декомпозиции, в том числе и функциональную.
T>Для стандартизации компонент типы нужны? Нужны.
Безусловно.
T>Эффекты надо типизировать? Надо.
И не только их.
T>Вот и пришли к системе типов с типизацией эффектов, самой простой из которых является Хаскельная.
Хаскель, это чистый функциональный язык (если память не изменяет). Для большинства задач его возможности слишком бедны.
Здравствуйте, minorlogic, Вы писали:
C>>Вот блин. Прочитай что я написал. C>>Твоя программа сможет вдруг обрабатывать Mpeg7 вместо plain text во всех полях ввода? M>Так и я об этом , если будет потдерживать стандарт Мpeg7 то сможет. Я просто хотел отметить что даже не такой нетривиальный пример может быть стандарт.
Торррмозишь опять. Вот у тебя поле ввода — и тебе от него вместо plain text'а вдруг приходит Mpeg7.
Понятно, что если сразу всё поддержать — то оно может будет работать.
Здравствуйте, Cyberax, Вы писали:
C>Это уже было давно придумано и даже сделано, и называется OLE (ещё из подобного OpenDoc на Mac'ах был, ну и HyperCard оттуда же). Там есть и compound document'ы и встраивание приложений, и вообще много чего ещё.
Если это было так здорово продумано и сделано, то почему этим практически никто не пользуется?
Может лучше сказать так: OLE, это первые, неуклюжие попытки создания чего-то подобного.
Здравствуйте, Cyberax, Вы писали:
C>Только проблема-то не в этом. Проблема в том, как сделать так, чтобы дополнительные функции можно было добавлять не изменяя программ.
Для этого программа должна поддерживать такую модульность, чтобы была возможность часть компонентов подменять компонентами от других производителей, или самописными. Это как с неоригинальными запчастями у автомобилей. Например, берём программу, которая выводит на печать отчёты и подменяем у неё компонент, отвечающий за формирование самого отчёта. Данные на входе стандартизованы. Данные на выходе: тоже, там ведь стандартизованная система вывода на печать. Новый компонент устанавливается и формирует отчёты с вензелями или ещё как то.
Многие крупные приложения позволяет добавлять такие возможности в виде прагинов и стандартизуют соответствующие API. Ничего принципиально нового. Правда у всех, даже похожих по функционалу программ эти API совершенно разные. Если же требовать соблюдения единого стандарта, то можно добиться того, что дополнительные модули, написанные для одного приложения можно использовать в другом и т.п.
Здесь проблема в другом: неправильный или устаревший стандарт будет просто ярмом на шее у разработчика. Чтобы этого не было надо стандартизовать не интерфейсы а структуры данных, а смысловое значение компонентов. Для этого в компонентную систему каким то образом должны добавляться знания о предметной области.
Короче, боюсь что задачка не для нынешнего технологического уровня.
Здравствуйте, Dufrenite, Вы писали:
D>Многие крупные приложения позволяет добавлять такие возможности в виде прагинов и стандартизуют соответствующие API. Ничего принципиально нового. Правда у всех, даже похожих по функционалу программ эти API совершенно разные. Если же требовать соблюдения единого стандарта, то можно добиться того, что дополнительные модули, написанные для одного приложения можно использовать в другом и т.п.
Это НЕРЕАЛЬНО. Совсем.
Попробуй, например, переделать модуль поддержки языка для Eclipse в модуль для IDEA.
Упс... Внутренние представления слишком различаются, проще переписать всё.
D>Здесь проблема в другом: неправильный или устаревший стандарт будет просто ярмом на шее у разработчика. Чтобы этого не было надо стандартизовать не интерфейсы а структуры данных, а смысловое значение компонентов. Для этого в компонентную систему каким то образом должны добавляться знания о предметной области. D>Короче, боюсь что задачка не для нынешнего технологического уровня.
Оно просто-напросто не нужно. Никто не кастомизирует автомобили "Запорожец", ставя туда двигатели от БелАЗа. И аналогия со сторонними производителями деталей тоже не проходит — так как сторонние детали в точности повторяют родные.
Дык об этом и говорю.
C>Попробуй, например, переделать модуль поддержки языка для Eclipse в модуль для IDEA.
C>Упс... Внутренние представления слишком различаются, проще переписать всё.
Ага. Вот только смысловая составляющая совершенно одинакова. Если язык один и тот же, компилятор один и тот же, требования к IDE для этого языка такие же. Пусть даже IDE по своим возможностям сильно отличаются (скажем нет поддержки интеллисенс в конкретной IDE): хрен бы с ними. Нет объективных причин для невозможности такого встраивания. Только отсутствие технических возможностей.
Поэтому я и говорю, что для решения подобных задач нужно придумать совершенно другие подходы.
C>Оно просто-напросто не нужно. Никто не кастомизирует автомобили "Запорожец", ставя туда двигатели от БелАЗа. И аналогия со сторонними производителями деталей тоже не проходит — так как сторонние детали в точности повторяют родные.
Ну мы то программы разрабатываем. Нам не впервой ужа с ежом скрестить. Возможностей на порядок больше. Мы ведь с информацией работаем а не с железками.
Можем и от белаза мотор поставить, можем от мессершмитта. Главное, чтобы это по смыслу мотор был.
Здравствуйте, Dufrenite, Вы писали:
C>>Попробуй, например, переделать модуль поддержки языка для Eclipse в модуль для IDEA. C>>Упс... Внутренние представления слишком различаются, проще переписать всё. D>Ага. Вот только смысловая составляющая совершенно одинакова. Если язык один и тот же, компилятор один и тот же, требования к IDE для этого языка такие же.
Неа.
D>Пусть даже IDE по своим возможностям сильно отличаются (скажем нет поддержки интеллисенс в конкретной IDE): хрен бы с ними. Нет объективных причин для невозможности такого встраивания. Только отсутствие технических возможностей.
"IntelliSense" есть в Eclipse и IDEA, но внутри они реализованы сильно по-разному. И имеют заметно разную функциональность.
А ещё сейчас вспомню программы, типа CAD'ов, где вообще могут быть кардинально разные способы представления данных.
D>Поэтому я и говорю, что для решения подобных задач нужно придумать совершенно другие подходы.
Не нужно.
C>>Оно просто-напросто не нужно. Никто не кастомизирует автомобили "Запорожец", ставя туда двигатели от БелАЗа. И аналогия со сторонними производителями деталей тоже не проходит — так как сторонние детали в точности повторяют родные. D>Ну мы то программы разрабатываем. Нам не впервой ужа с ежом скрестить. Возможностей на порядок больше. Мы ведь с информацией работаем а не с железками. D>Можем и от белаза мотор поставить, можем от мессершмитта. Главное, чтобы это по смыслу мотор был.
Я не вижу смысла делать программы, которые на 100% будут состоять из взаимозаменяемых кубиков. Это невозмонжо, да и не нужно.
