программирование будущего
От: YoungPioneer Россия http://www.cadsofttools.com
Дата: 04.01.09 17:13
Оценка: 3 (1) +1 :))) :))) :))) :))) :))) :))) :)
Просьба оценить идею:

Каждая программа будет состоять из файлов-модулей — похоже на нынешние .dll библиотеки. Главное отличие — интерфейсная часть основных модулей — стандартизована, подобно тому, как сейчас стандартизованы интерфейсы составных частей компьютера — процессор, жесткий диск и т.д.Любой производитель может начать выпуск мониторов, причем работать они будут даже без нового драйвера — в Windows предусмотрен "стандартный монитор".

Также будет и с программами — они будут иметь стандартные и нестандартные модули, причем первые можно будет МЕНЯТЬ. К примеру, если меню программы сделано в Ribbon стиле (современные "ленты"), а пользователь хочет "классические тулбары", то поменяв один модуль, он заменит ribbon на "классические тулбары".
Программистам для написания новой программы не придется мучаться с пользовательским интерфейсом — теми же тулбарами или гридами — достаточно будет воспользоваться готовыми наборами модулей в качестве базы, куда вставится модуль, реализующий лишь логику программы.
Конечно, сейчас можно купить "компоненты" с реализацией ribbon или навороченные Grid, но попробуйте заменить один компонент на другой — от конкурента. Сколько времени на это потребуется? В будущем это будет не сложнее, чем заменить старый CD-ROM на новый. Причем даже программист не понадобится — это можно будет делать на уровне пользователя.
Кроме написания новых программ, программисты смогут писать новые модули по существующим стандартам. Например, некий программист придумал алгоритм сверхбыстрого просмотра jpg файлов. Программист пишет новый модуль на основе интерфейсов текущего jpg_format стандарта, и этот модуль каждый пользователь сможет легко вставить в популярные программы — просмоторщик файлов от windows, броузеры, ACDSee, IrfanView, TotalCommander... По сути, новый модуль является плагином ко всем программам, которые используют jpg и реализовали программу по заданным СТАНДАРТАМ.

Реализована такая модель может быть на уровне com, .net или других системах и языках программирования. Главное — стандартизация, принимаемая большинством.

Заранее благодарен за комментарии.
Всегда готов!
Re: программирование будущего
От: frogkiller Россия  
Дата: 04.01.09 19:15
Оценка: +3 :))) :))) :))
Здравствуйте, YoungPioneer, Вы писали:

YP>Конечно, сейчас можно купить "компоненты" с реализацией ribbon или навороченные Grid, но попробуйте заменить один компонент на другой — от конкурента. Сколько времени на это потребуется? В будущем это будет не сложнее, чем заменить старый CD-ROM на новый. Причем даже программист не понадобится — это можно будет делать на уровне пользователя.


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

YP>Кроме написания новых программ, программисты смогут писать новые модули по существующим стандартам.


Дык, им и сейчас ничто не мешает — стандартов разных ого-го сколько напридумывали — открытых, закрытых — разных. А! Я знаю, нужно чтобы все последователи правильного стандарта собрались и убили всех последователей неправильных — и тогда наступит всеобщее процветание.

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

PPS. Хотя некоторая упорядоченность не повредит. Не следует путать рабочий беспорядок с бардаком
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re: программирование будущего
От: Dufrenite Дания  
Дата: 05.01.09 12:28
Оценка: +1 -2 :))) :))) :))
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


Идея хорошая. Возможно каждому читающему этот форум она в том или ином виде приходила (я, например, на полном серьёзе в своё время прикидывал способы реализации).
Скажу сразу. Главная проблема в том, что индустрия ещё не готова к этому. Пока вершиной программистской мысли считается ФП, ничего не изменится.
Re: TSPL и NIL - языки будущего
От: gyraboo  
Дата: 11.02.09 09:23
Оценка: 96 (2) +1 :))) :)))
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


YP>Каждая программа будет состоять из файлов-модулей — похоже на нынешние .dll библиотеки. Главное отличие — интерфейсная часть основных модулей — стандартизована, подобно тому, как сейчас стандартизованы интерфейсы составных частей компьютера — процессор, жесткий диск и т.д.Любой производитель может начать выпуск мониторов, причем работать они будут даже без нового драйвера — в Windows предусмотрен "стандартный монитор".

...
YP>Реализована такая модель может быть на уровне com, .net или других системах и языках программирования. Главное — стандартизация, принимаемая большинством.

YP>Заранее благодарен за комментарии.


Небольшой оффтоп. Недавно бывал в будущем, правда более отдаленном, чем вы. Не могу не поделится некоторыми впечатлениями.
Особенно понравилась идея распределенных вычислений. В 2874 году, из которого я как раз вернулся, этот метод позволяет с помощью одного обычного x86-процессора добиться мощности и распараллеливания, недостижимого самыми мощными суперкомпьютерами нашего времени. Вы наверное спросите почему в 2874 году используют именно x86 процессоры. Всё очень просто, объясняю: берется оди единственный x86-процессор, экземпляр какого-нибудь 1980 года, и с помощью языка TSPL (Time-Space Processor Language) (это язык программирования пространства-временных характеристик) программируется таким образом, чтобы в течение необходимого для вычислений промежутка времени выполнить задачу. Допустим, мы можем запрограммировать x86 таким образом, чтобы с 1980 по 2100 год, в перерывах между своими прямыми вычислениями, процессор занимался вычислением нужной нам задачи. Владелец x86 обычно ничего не замечает в этом случае.
Результаты вычислений считываются также с помощью средства TSPL и записываются в любые пространственно-временные структуры, чтобы к моменту, когда эти результаты потребуются, их можно было бы легко прочитать. Запись и считывание с помощью пространственно-временных структур — вещь достаточно захватывающая, но на пальцаз её объяснить трудно. Попытаюсь это сделать, приведя несложный пример. Если наш x86 стоит в компьютере верстальщика, то результаты вычислений можно записываться в виде распределения опечаток и отклонений букв в печатных материалах. Главное требование — гарантировать что к моменту считывания результатов эти структуры должны быть доступны (в нашем примере печатные материалы будут в 2874 году доступны в электронных библиотеках всемирной истории и опечатки, а также пространственные микро-отклонения букв можно будет с легкостью считать, зная исходный алгоритм (в TimeLang это называется "матрица считывания")).

Настящие гуру TSPL в 2874 году для записи результатов используют опосредованное программирование нагрузки винчестеров в наших сегодняшних кластерах и как результат — их микро-влияние на климат, а считывание происходит в результате разностного анализа исторических погодных данных (разность ожидаемой рассчитанной погоды погоды и актуальной, вызванной влиянием нагрева винчестеров планеты).

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

Аппаратной платформой для TSPL служит пространственно-временной континуум и небольшая машина времени, способная засылать в прошлое электрические импульсы, которая будет создана в 2554 году. До создания TSPL пройдет ещё несколько сотен лет.

Грандиозным и непостижимым парадоксом использования TSPL является то, что все результаты вычислений этого языка уже записаны в пространстве-времени. В 2874 году исследователи изучают вопрос — не является ли наша Вселенная исключительно агрегированной массой результатов всевозможных вычислений, не является ли каждый проходящий в ней процесс вычислителем, инициированным чьими-то вычислениями? Одна из исследовательских групп, которую я посетил, занимается интересным и захватывающих вопросом — они пытаются раскодировать результаты без использования матрицы считывания (как я говорил выше, такая матрица позволяет вам правильно прочесть результаты ваших вычислений), т.е. анализируя любые-прелюбые всевозможные данные, они пытаются вычислить такие матрицы и на их основе прочесть результаты. Естественно, для своих невероятно громоздких комбинаторных перестановок и вычислений они тоже используют средства TSPL.

Нет сомнений, что какие-то языковые особенности данного текста также являются частью результатов чьих-то TSL-вычислений.

P.S. Кроме TSPL там есть и другие языки. Например NIL (Nature Influence Language) — язык природных влияний. Он позволяет обойтись без процессоров (ибо TSPL ограничен периодов когда первые процессоры были изобретены). NIL позволяет с помощью машины времени засылать в прошлое микро-изменения природных характеристик таким образом, чтобы законы природы сами являлись вычислителем. Принцип считывания остается аналогичным TSPL, но теперь считывать можно не только артефакты работы процессоров, как в случае с TSPL, но и характеристик природных явлений к нужному моменту (например написали программу на NIL в 2874 году, запустили, и сразу же считываем результаты например с географической карты очертаний материка и интерпретируем их с помощью матрицы считывания). Глубже понять суть NIL мне не удалось, поэтому боюсь не смогу объяснить принцип его работы.
Re: программирование будущего
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.01.09 06:23
Оценка: 1 (1) +6
Здравствуйте, YoungPioneer, Вы писали:

Свежая идея. Рекомендую вместо ее детальной проработки сесть и подумать: почему эта идея не сработала за 20 лет, прошедших с появления COM и 15 лет, прошедших с появления Java?

Почему даже насквозь застандартизованный SQL, который посвящен одному очень узкому сегменту приложений, у всех производителей выглядит и работает по-разному?

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

Без этого обсуждать идею имеет смысл не больше, чем мысль "вот пусть все граждане России скинутся мне по 50 копеек. Они ничего даже не заметят, а мне 60 миллионов рублей очень пригодятся".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: программирование будущего
От: Евгений Чужакин Россия http://www.cadsofttools.com
Дата: 04.01.09 21:16
Оценка: -3 :))) :)
Здравствуйте, frogkiller, Вы писали:

F>После того, как стандартизируют последний компонент последнего интерфейса энтропия станет равна нулю и жизнь прекратится.

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

F>Дык, им и сейчас ничто не мешает — стандартов разных ого-го сколько напридумывали — открытых, закрытых — разных. А! Я знаю, нужно чтобы все последователи правильного стандарта собрались и убили всех последователей неправильных — и тогда наступит всеобщее процветание.


Когда-то было много операционных систем. А потом появился стандарт — MS Windows. Убивать никого не надо, надо сделать то, что будет использовать большинство, тогда остальные волей неволей будут использовать именно это. Стандартов не может быть два или три. Стандарт может быть только один.


F>PS. В жизни много всяких нелогичных штуковин, и не всегда это плохо. Иногда они позволяют делать качественный скачок. И я надеюсь, что тотальная стандартизация никогда не наступит и не станет душить в зародыше новые интересные идеи, которые хоть изредка, но ещё появляются.


Тотальная стандартизация уже наступила. И программирование — одна из немногих областей, где стандартов (не рекомендаций, а именно реальных стандартов) по сути пока нет. А что касается идей — ну придумает сейчас гений-программист лучшую в мире систему определения человека по фото. И куда он с ней денется? Обратится в крупные фирмы, которые его либо кинут, либо пошлют. А если он напишет такую систему по стандарту, то сможет предложить её ПОЛЬЗОВАТЕЛЯМ программ, где используются системы от тех самых крупных производителей. Пользователи смогут заменить модуль и получить то что хотели. Как известно, написать программу намного проще, чем продать — в данном примере эта проблема решается.
Всегда готов!
Re[2]: программирование будущего
От: Евгений Чужакин Россия http://www.cadsofttools.com
Дата: 04.01.09 21:01
Оценка: -2 :))
Большое спасибо всем за интересные комментарии!

Пишу статью для rsdn на эту тему, поэтому хочется понять, какие в ней "баги"

C>А зачем всё это пользователю?


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

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

Главная идея даже не в удобстве программирования и использования таких приложений, а в том, что это дорога к полностью автоматическому программированию. Кибермозг сможет заменить программиста-человека и делать программу на основе запроса обычного продвинутого пользователя — собирать программу из существующих модулей.
Например, такой запрос:
"мониторинг параметров станка Hitachi123 с печатью отчетов и экспортом в 1С"
Компьютер сам найдет модуль от производителя станка, выберет совместимую систему мониторинга, печати и модуль экспорта в 1С. На выходе — будет готовая программа.
Конечно, сейчас это кажется невозможным, ведь Человек в любом случае умнее машины и компьютер не сможет полноценно заменить программиста-человека. Правда, двадцать лет назад считали, что компьютер не сможет выиграть у человека в шахматы
Всегда готов!
Re: программирование будущего
От: hattab  
Дата: 04.01.09 18:35
Оценка: +2 :)
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


Идея называется COM в утопическом максимуме.
Re[3]: программирование будущего
От: frogkiller Россия  
Дата: 05.01.09 08:26
Оценка: +3
Здравствуйте, Евгений Чужакин, Вы писали:

ЕЧ>Когда-то было много операционных систем. А потом появился стандарт — MS Windows. Убивать никого не надо, надо сделать то, что будет использовать большинство, тогда остальные волей неволей будут использовать именно это. Стандартов не может быть два или три. Стандарт может быть только один.


Насмешил. Слушай, а ты часом не тролль? С такими идеями прямая дорога в "Компьютерные Священные Войны", там с радостью тебе расскажут про вендекапец.

ЕЧ>Тотальная стандартизация уже наступила.


Да? Ты видел, что именно специфицируется в технологических стандартах, посмотри на досуге и проведи аналогии на разработку ПО. И вообще — сколько разнообразных стандартов — знаешь?

ЕЧ>И программирование — одна из немногих областей, где стандартов (не рекомендаций, а именно реальных стандартов) по сути пока нет.


Языки программирования — стандарты. Открытые протоколы — стандарты (вон зайди к примеру на w3.org).

ЕЧ>А что касается идей — ну придумает сейчас гений-программист лучшую в мире систему определения человека по фото. И куда он с ней денется? Обратится в крупные фирмы, которые его либо кинут, либо пошлют. А если он напишет такую систему по стандарту, то сможет предложить её ПОЛЬЗОВАТЕЛЯМ программ, где используются системы от тех самых крупных производителей. Пользователи смогут заменить модуль и получить то что хотели. Как известно, написать программу намного проще, чем продать — в данном примере эта проблема решается.


Понятно, тебя интересует только один аспект "стандартизации" — возможность запуска и отображения в пользовательской среде на типичных компьютерах. Причём под типичными ты подразумеваешь десктопы с MS Windows. Ну так для них придумали уже давно технологию OLE. Всё что тебе надо — заставить всех производителей программ включать OLE-контейнер на главную форму приложения

Но вообще — задумайся, сколько различных областей в IT — они не ограничиваются десктопами с виндой. И что хорошо для одной области будет совершенно неприемлимым для других.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[2]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 05.01.09 22:04
Оценка: +2 :)
YP>>Просьба оценить идею:
D>Идея хорошая. Возможно каждому читающему этот форум она в том или ином виде приходила (я, например, на полном серьёзе в своё время прикидывал способы реализации).
D>Скажу сразу. Главная проблема в том, что индустрия ещё не готова к этому. Пока вершиной программистской мысли считается ФП, ничего не изменится.

Па-апрашу развернуть!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 13.01.09 14:10
Оценка: 8 (2)
T>>За полгода наблатыкаешься, будешь круче deniok о холоморфизмах рассуждать.
D>Если не сложно, кинь ссылочку для начинающих. Буду холоморфизмами впечатление на девчОнок производить .

Про теорию типов:
http://www.cs.kent.ac.uk/people/staff/sjt/TTFP/
http://www.cs.chalmers.se/Cs/Research/Logic/book/

Современные исследования находятся в районе товарищей из Epigram:
http://www.cs.nott.ac.uk/~txa/publ/
http://strictlypositive.org/publications.html

Про холо-, ана- и прочие катаморфизмы надо читать в книжках по теории категорий.

Результаты поиска, включают в себя и ссылки на доступные объяснения теории категорий (for beginners, например).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: программирование будущего
От: deniok Россия  
Дата: 04.01.09 17:33
Оценка: +1 -1
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


Оцениваю: кому это принесёт деньги/счастье/удовлетворение? Никому. Такая тотальная стандартизация не имеет особых плюсов ни для кого. Поэтому ее и не будет.
Re[3]: программирование будущего
От: hattab  
Дата: 04.01.09 21:26
Оценка: +1 :)
Здравствуйте, Евгений Чужакин, Вы писали:

ЕЧ>Пишу статью для rsdn на эту тему, поэтому хочется понять, какие в ней "баги"


Вероятно кризис назрел, коли статьи подобной тематики будут публиковаться на RSDN... (ничего личного)

ЕЧ>Пользователь будет видеть едино оформленные программы, с похожим интерфейсом, справкой, плюс схожий функционал начнет работать единообразно. Затраты на обучение новым программам сократятся до минимума.


У меня дежа-ву... Следование гидлайнам уже сегодня решает эту проблему (посмотрите на Mac OS).

ЕЧ> Кибермозг сможет заменить программиста-человека и делать программу на основе запроса обычного продвинутого пользователя — собирать программу из существующих модулей.


Расширенное сознание это конечно хорошо, но немного пугает . А серьезно, как мегамозг будет контролировать корректность реализации черного ящика?

ЕЧ>Правда, двадцать лет назад считали, что компьютер не сможет выиграть у человека в шахматы


Он до сих пор не может, грубая голубая сила в зачет не идет (ибо никаким ИИ тут даже и близко не пахнет).
Re[8]: программирование будущего
От: Young_Pioneer Россия http://www.cadsofttools.com
Дата: 06.01.09 08:44
Оценка: :))
Здравствуйте, deniok, Вы писали:


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


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

D>Что с моей точки зрения действительно повысит лёгкость замены модуля проверки орфографии на другой, но в то же время снизит потенциал развития обоих модулей, поскольку на них налагается необходимость поддержки доп.требований. Что, по-моему, существенно превышает выгоды неустановленных лиц от замены.



Проблема решаема, также как решаема проблема цветной печати на черно-белом принтере — будет работать только то, что поддержано.
К примеру, в стандарте "системе_первода_1" нет поддержки озвучки текста, но некий производитель (пусть будет Promt) его добавил. Его модуль будет работать в старых приложениях (назовем MS Office 2012), хотя без озвучки. Promt обращается в ОРГАНИЗАЦИЮ с предложением расширить стандарт до "система_перевода_2" — с включение озвучки текста. MS Office 2013 поддержит новый интерфейс и озвучка заработает автоматически.
Озвучка текста может быть рекомендуемым, но необязательным интерфейсом "система_перевода_2". В этом случае некая компания SimpleTranslator создает свой модуль на основе "система_перевода_2" без озвучки — и MS Office 20013 будет корректно работать и с ним.

Таким образом, стандарты не станут эдаким "прокрустовым ложем", мешающим нормальному развитию ПО.

Рассмотрите ситуацию: программа не содержит пользовательский интерфейс главной формы "в себе", а выдаёт его в виде xml, при этом модуль, написанный сторонней компанией, СПЕЦИАЛИЗИРУЮЩЕЙСЯ ИМЕННО НА ПОЛЬЗОВАТЕЛЬСКОМ ИНТЕРФЕЙСЕ, создаст на основе этого xml: меню, тулбары, панели. При этом пользователь (не программист, а именно пользователь!) сможет изменить модуль интерфейса на другой — и выбрать ribbon, тулбары, а может ему больше понравится просто дерево вместо меню.
При этом программисты наконец будут создавать новые технологии, а не решать проблемы, которыми в тот же момент занимаются еще тысячи других программистов — вроде правильной расстановки элементов на форме.
Всегда готов!
Re[8]: программирование будущего
От: deniok Россия  
Дата: 06.02.09 13:02
Оценка: 1 (1)
Здравствуйте, vdimas, Вы писали:

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


T>>Для стандартизации компонент типы нужны? Нужны.


V>Вот тут и упираемся, ибо сами типыпринципиально зависят от подробности конкретной задачи. Другое дело, что давно витает в воздухе идея стандартизировать св-ва типов, дабы можно было обобщать алгоритмы, в С++ на шаблонах и в некоторых функциональных это где-то работает на наглядном синтаксическом уровне (хотя на неявном уровне, на уровне ошибок компиляции, если тип не имеет нужного члена, поля или метода). А на популярных .Net или Java даже банальное сложение через контракты выглядит убого и работает так же в плане эффективности.


Дело не в юридической стандартизации, а во внедрениии в прикладное языкостроение достижений теории типов (и связанной с ней теории доменов). Если мы держимся в рамках соответствующей математики, то получаем довольно сильные гарантии правильности программы, прошедшей тайпчекер. Фактически большинство современных теорем-пруверов основаны на какой-то версии типизации лямбда-исчисления; сделать из этого удобный прикладной язык, не потеряв строгих гарантий — вот чэллендж сегодняшнего дня. А у типов современных массовых языков инструментарий их построения слегка бедноват и кривоват.

V>Тут вот периодически пробегает человек, который разрабатывает некое единое семантическое представление программ, ИМХО, из области попыток решить этот вопрос.


Тут опять проблема в кодификации этого семантического единства. На чем она будет основана — на общепринятом (делаем так, поскольку в большинстве современных языков так) или на Карри-Ховарде-Жирарде-Рейнолдсе-etc (делаем так, потому что система типов оказывается изоморфной некоторой богатой логической системе).
Re: программирование будущего
От: Cyberax Марс  
Дата: 04.01.09 18:51
Оценка: +1
Здравствуйте, YoungPioneer, Вы писали:

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

Зевок...

YP>Конечно, сейчас можно купить "компоненты" с реализацией ribbon или навороченные Grid, но попробуйте заменить один компонент на другой — от конкурента. Сколько времени на это потребуется? В будущем это будет не сложнее, чем заменить старый CD-ROM на новый. Причем даже программист не понадобится — это можно будет делать на уровне пользователя.

А зачем всё это пользователю?
Sapienti sat!
Re[3]: программирование будущего
От: deniok Россия  
Дата: 04.01.09 19:07
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>В вебе (HTML+CSS+JS+XML) стандартизация существует и очень успешно. Но все в итоге уприается в реализацию стандартов разными вендорами.

G>ИМХО любая межсистемная (независимая от языка и платформы разработки) стандартизация придет именно к такому.

Я не вижу в программировании выгод от глубокой тотальной стандартизации. Для целей связанных с коммуникациями в широком смысле — да, это полезно. Собственно поэтому веб и имеет более-менее общепризнанные стандарты. (Кстати вопрос об их качестве оставим за скобками). А то о чем говорит топикстартер, по-моему, просто маниловщина. Беспроблемная замена модуля A на модуль B возможна, только если их базовая функциональность идентична, а отличие только в рюшечках. Либо если они практически изолированны от остальной системы; ну так я и нынче могу снести Microsoft Office и поставить Star Office, в чём проблема?
Re[3]: программирование будущего
От: Cyberax Марс  
Дата: 04.01.09 21:12
Оценка: +1
Здравствуйте, Евгений Чужакин, Вы писали:

C>>А зачем всё это пользователю?

ЕЧ>Пользователь будет видеть едино оформленные программы, с похожим интерфейсом, справкой, плюс схожий функционал начнет работать единообразно. Затраты на обучение новым программам сократятся до минимума.
Это несерьёзно. "Автоматически" можно заменить только очень небольшую часть интерфейса. Фактически, только то, что уже и так делается разными стилевыми движками.

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

И нафиг это им надо? Да и мелочи всё это, просто другой вид рюшечек. Ничего существенного заменить не получится.

ЕЧ>Программисты могут поставлять простую систему печати, так как она не есть главное в их приложении, а пользователи заменят её более мощной от другого производителя.

Это только кажется. Например, в более другой системе печати может по-другому работать разбиение на страницы. А это потребует от приложения переразбивки документа и т.п. В общем, ничего сильно сложнее того, что сейчас уже и так делается на уровне драйверов принтера — не сделать.
Sapienti sat!
Re: программирование будущего
От: Mamut Швеция http://dmitriid.com
Дата: 05.01.09 12:58
Оценка: +1
YP>Каждая программа будет состоять из файлов-модулей — похоже на нынешние .dll библиотеки. Главное отличие — интерфейсная часть основных модулей — стандартизована,

Нельзя объять необъятное


dmitriid.comGitHubLinkedIn
Re[7]: программирование будущего
От: deniok Россия  
Дата: 05.01.09 22:44
Оценка: +1
Здравствуйте, Zhendos, Вы писали:

Z>в данном случае проблема уже решена, насколько я помню

Z>openoffice, firefox и компания скооперировались и сделали hunspell
Z>общую систему проверки орфографии

Ну так это же продукт, а не стандарт; в данной дискуссии предполагается что кто-то теперь должен еще совершить какие-то довольно затратные действия по обеспечению фиксирования и стандартизации интерфейса взаимодействия проверялка/проверяемое. Что с моей точки зрения действительно повысит лёгкость замены модуля проверки орфографии на другой, но в то же время снизит потенциал развития обоих модулей, поскольку на них налагается необходимость поддержки доп.требований. Что, по-моему, существенно превышает выгоды неустановленных лиц от замены.
Re[9]: программирование будущего
От: frogkiller Россия  
Дата: 06.01.09 11:17
Оценка: +1
Здравствуйте, Young_Pioneer, Вы писали:

Y_P>>>А если они все будут использовать стандартный интерфейс "графический_файл" — то можно будет обойтись ОДНИМ плагином. Причем когда некая компания захочет создать собственный векторный формат, то за базовый интерфейс она возьмёт тот же "графический_файл" — и их формат автоматически будет поддержан популярными программами.

C>>Это уже было давно придумано и даже сделано, и называется OLE
Y_P>То есть можно сделать COM объект, читающий простенький растровый формат '*.abc' и такие программы, как MS Office, Google Chrome, Photoshop, AutoCAD, 1C и другие "поймут" этот COM объект и будут открывать *.abc подобно *.bmp? Один плагин для всех?

"Открывать" — да. А вот рисовать — нет потому что это потребует не только операцию чтения из файла и представлении во внутренних структурах твоего объекта, но и обратного взаимодействия — при рисовании на экране, отображении во внутренних структурах основной программы и тд.

C>>Твоя идея: делаем суперкастомизуемую систему, так чтоб пользователь мог нажать правой клавишей на любое поле ввода и вместо него воткнуть красивое поле ввода с поддержкой векторной графики и встроенным в виде пасхального яйца Doom3, использущим это поле ввода для savegame'ов.


Y_P>"Кастомизация" как раз не главное. И "куда угодно что угодно" воткнуть пользователь не сможет — на это есть программисты. При этом есть некоторые модули программ, которые можно заменить на "более хорошие" либо добавить дополнительные: например, добавлять поддержку новых форматов файлов.

Y_P>Эти модули:
Y_P>-загрузка и сохранение из/в определенный формат (можно добавлять модули)
Y_P>-пользовательский интерфейс (можно заменять модули)
Y_P>- печать (можно добавлять / заменять модули)
Y_P>- общие алгоритмы: перевод, шифрование, векторизация растра и т.д.
Y_P>многие из таких модулей уже сейчас делаются профессионалами и продаются в виде компонентов либо исходников. Только без каких-либо СТАНДАРТОВ.

Y_P>COM даёт богатые возможности совместного использования компонентов программ и иногда методы тотальной "кастомизации" самих программ. Мы тоже делаем COM компоненты, и клиенты-ПРОГРАММИСТЫ легко вставляют их в свои программы. Но НЕТ СТАНДАРТА, чтобы написать компонент, который вставится во все профессиональные программы, которым может понадобится этот функционал. COM, конечно, может быть использован как база для реализации идеи модулей, но лучше создать новую технологию.


А! Наконец-то я понял. Тебе нужна своя открытая операционная система — только так можно встроить что угодно во что угодно. Ну так такие есть давно — тот же линукс в куче разновидностей. (При чём, думаю, возможностей одного только оконного менеджера по типу KDE тебе не хватит, нужна именно OS. Но потом все ненужные функциональные возможности надо будет спрятать этим самым оконным менеджером — по типу того, как это сделано в Xandros и его icewm). Ну а что так сложно — извини, ты сам захотел стандарты для всего. Осталась малость — убедить остальных использовать такой механизм Кстати, сама MS приложит максимум усилий, чтоб такого не случилось — отчасти оттого, что не захочет пускать сторонний народ вглубь своей архитектуры больше, чем это сделано сейчас, отчасти оттого, что тогда она уж точно потеряет доминирующее положение на рынке софта.

PS. Возможно, Oberon BlackBox в действительности то, что ты хочешь. Там много интересных идей, но сомневаюсь, что они когда-нибудь станут стандартами, или просто получать хотя бы небольшое распространение.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[4]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 06.01.09 11:20
Оценка: :)
T>>Па-апрашу развернуть!
D>Не, я не тролль

Лично мне интересно, что же такого ты придумал, что стоит выше уровнем, чем ФП.

В которое ФП входит и <a href=http://en.wikipedia.org/wiki/Martin-Lof_type_theory&gt;теория типов</a>, которая ну очень высокоуровневая.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 07.01.09 18:16
Оценка: :)
T>>Лично мне интересно, что же такого ты придумал, что стоит выше уровнем, чем ФП.
T>>В которое ФП входит и <a href=http://en.wikipedia.org/wiki/Martin-Lof_type_theory&gt;теория типов</a>, которая ну очень высокоуровневая.
D>Да ничего я не придумал. Просто беру конкретную задачу или класс задач и подбираю на мой взгляд оптимальное решение. Это творчество а не теории.

С теорией лучше, нес па?

D>Топикстартер поставил вполне конкретную задачу и я не вижу никакого способа решить её применив функциональную декомпозицию или что нибудь подобное. Здесь совсем другой подход нужен.


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

Для стандартизации компонент типы нужны? Нужны.

Эффекты надо типизировать? Надо.

Вот и пришли к системе типов с типизацией эффектов, самой простой из которых является Хаскельная.

Как-то так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: программирование будущего
От: Dufrenite Дания  
Дата: 08.01.09 18:44
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>С теорией лучше, нес па?


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

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


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

T>Для стандартизации компонент типы нужны? Нужны.


Безусловно.

T>Эффекты надо типизировать? Надо.


И не только их.

T>Вот и пришли к системе типов с типизацией эффектов, самой простой из которых является Хаскельная.


Хаскель, это чистый функциональный язык (если память не изменяет). Для большинства задач его возможности слишком бедны.
Re[9]: программирование будущего
От: Cyberax Марс  
Дата: 08.01.09 19:39
Оценка: +1
Здравствуйте, Dufrenite, Вы писали:

D>Многие крупные приложения позволяет добавлять такие возможности в виде прагинов и стандартизуют соответствующие API. Ничего принципиально нового. Правда у всех, даже похожих по функционалу программ эти API совершенно разные. Если же требовать соблюдения единого стандарта, то можно добиться того, что дополнительные модули, написанные для одного приложения можно использовать в другом и т.п.

Это НЕРЕАЛЬНО. Совсем.

Попробуй, например, переделать модуль поддержки языка для Eclipse в модуль для IDEA.

Упс... Внутренние представления слишком различаются, проще переписать всё.

D>Здесь проблема в другом: неправильный или устаревший стандарт будет просто ярмом на шее у разработчика. Чтобы этого не было надо стандартизовать не интерфейсы а структуры данных, а смысловое значение компонентов. Для этого в компонентную систему каким то образом должны добавляться знания о предметной области.

D>Короче, боюсь что задачка не для нынешнего технологического уровня.
Оно просто-напросто не нужно. Никто не кастомизирует автомобили "Запорожец", ставя туда двигатели от БелАЗа. И аналогия со сторонними производителями деталей тоже не проходит — так как сторонние детали в точности повторяют родные.
Sapienti sat!
Re[11]: программирование будущего
От: Cyberax Марс  
Дата: 08.01.09 20:29
Оценка: +1
Здравствуйте, Dufrenite, Вы писали:

C>>Попробуй, например, переделать модуль поддержки языка для Eclipse в модуль для IDEA.

C>>Упс... Внутренние представления слишком различаются, проще переписать всё.
D>Ага. Вот только смысловая составляющая совершенно одинакова. Если язык один и тот же, компилятор один и тот же, требования к IDE для этого языка такие же.
Неа.

D>Пусть даже IDE по своим возможностям сильно отличаются (скажем нет поддержки интеллисенс в конкретной IDE): хрен бы с ними. Нет объективных причин для невозможности такого встраивания. Только отсутствие технических возможностей.

"IntelliSense" есть в Eclipse и IDEA, но внутри они реализованы сильно по-разному. И имеют заметно разную функциональность.

А ещё сейчас вспомню программы, типа CAD'ов, где вообще могут быть кардинально разные способы представления данных.

D>Поэтому я и говорю, что для решения подобных задач нужно придумать совершенно другие подходы.

Не нужно.

C>>Оно просто-напросто не нужно. Никто не кастомизирует автомобили "Запорожец", ставя туда двигатели от БелАЗа. И аналогия со сторонними производителями деталей тоже не проходит — так как сторонние детали в точности повторяют родные.

D>Ну мы то программы разрабатываем. Нам не впервой ужа с ежом скрестить. Возможностей на порядок больше. Мы ведь с информацией работаем а не с железками.
D>Можем и от белаза мотор поставить, можем от мессершмитта. Главное, чтобы это по смыслу мотор был.
Я не вижу смысла делать программы, которые на 100% будут состоять из взаимозаменяемых кубиков. Это невозмонжо, да и не нужно.
Sapienti sat!
Re[10]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 12.01.09 13:23
Оценка: :)
T>>Шаблоны — это не стройная теория.
D>По моему мнению, любая теория, это обобщение некоторого опыта. Имперического или умозрительного, сути не меняет. Шаблоны, это тоже обобщение опыта, а значит теория. Стройная или нет, хз. Надо дать определение стройности.

Шаблоны, например, не имеют чёткой области определения. Это самое простое.

Поэтому их и пытаются запихнуть в ненужные места.

T>>Что подтверждает мои слова.

D>Я не говорил, что не согласен. Изначальная мысль о том, что функционального подхода недостаточно.

По-моему, вполне достаточно. Вот здесь мы и расходимся.

T>>>>Эффекты надо типизировать? Надо.

D>>>И не только их.
T>>Что ещё?
D>Для полноценного решения этой задачи вместе с компонентами должна каким то образом поставляться информация о предметной области, точнее о множестве предметных областей. Такого в современных программах просто нет, даже на уровне исходных кодов. Информацией о предметной области владеют только разработчики, а исполняющей системе попадает только то, что она может интерпретировать. Как эту задачу решить технически я не знаю.

Вот смотри.

Теория типов представляет собой конструктивную формализацию математики. В переводе на русский язык это означает, что любое доказательство существования какого-либо объекта в этой теории представляет собой алгоритм вычислений этого объекта, это раз (прилагательное "конструктивная"). Она может быть проверена или исполнена механически (существительное "формализация"), это два. Третье, и последнее, слово "математика" означает... Ну, например, то, что наверняка есть какая-либо теория под наши текущие нужды, остаётся только её отыскать и записать.

"Под текущие нужды" — это "для нашей предметной области".

Что ещё "нужно растущему организму"?

D>Возможно ты прав. Я не настолько знаком с теорией типов, чтобы на равных этот вопрос обсуждать. К сожалению, такие вещи изучается годами.


Да брось ты!

За полгода наблатыкаешься, будешь круче deniok о холоморфизмах рассуждать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: программирование будущего
От: iZEN СССР  
Дата: 04.01.09 18:29
Оценка:
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


YP>Каждая программа будет состоять из файлов-модулей — похоже на нынешние .dll библиотеки.


.class

YP>Главное отличие — интерфейсная часть основных модулей — стандартизована, подобно тому, как сейчас стандартизованы интерфейсы составных частей компьютера — процессор, жесткий диск и т.д.Любой производитель может начать выпуск мониторов, причем работать они будут даже без нового драйвера — в Windows предусмотрен "стандартный монитор".


BD-J

YP>Также будет и с программами — они будут иметь стандартные и нестандартные модули, причем первые можно будет МЕНЯТЬ. К примеру, если меню программы сделано в Ribbon стиле (современные "ленты"), а пользователь хочет "классические тулбары", то поменяв один модуль, он заменит ribbon на "классические тулбары".


Swing Look&Feel

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

YP>Конечно, сейчас можно купить "компоненты" с реализацией ribbon или навороченные Grid, но попробуйте заменить один компонент на другой — от конкурента. Сколько времени на это потребуется? В будущем это будет не сложнее, чем заменить старый CD-ROM на новый. Причем даже программист не понадобится — это можно будет делать на уровне пользователя.

JMX

YP>Кроме написания новых программ, программисты смогут писать новые модули по существующим стандартам. Например, некий программист придумал алгоритм сверхбыстрого просмотра jpg файлов. Программист пишет новый модуль на основе интерфейсов текущего jpg_format стандарта, и этот модуль каждый пользователь сможет легко вставить в популярные программы — просмоторщик файлов от windows, броузеры, ACDSee, IrfanView, TotalCommander... По сути, новый модуль является плагином ко всем программам, которые используют jpg и реализовали программу по заданным СТАНДАРТАМ.


JMX

YP>Реализована такая модель может быть на уровне com, .net или других системах и языках программирования. Главное — стандартизация, принимаемая большинством.


Java
Большинство (JCP.org) уже приняло её за отраслевой стандарт.

YP>Заранее благодарен за комментарии.


И вам того же.
Re[2]: программирование будущего
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.01.09 18:36
Оценка:
Здравствуйте, deniok, Вы писали:

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


YP>>Просьба оценить идею:


D>Оцениваю: кому это принесёт деньги/счастье/удовлетворение? Никому. Такая тотальная стандартизация не имеет особых плюсов ни для кого. Поэтому ее и не будет.


В вебе (HTML+CSS+JS+XML) стандартизация существует и очень успешно. Но все в итоге уприается в реализацию стандартов разными вендорами.
ИМХО любая межсистемная (независимая от языка и платформы разработки) стандартизация придет именно к такому.
Re[3]: программирование будущего
От: deniok Россия  
Дата: 04.01.09 21:21
Оценка:
Здравствуйте, Евгений Чужакин, Вы писали:

C>>А зачем всё это пользователю?


ЕЧ>Пользователь будет видеть едино оформленные программы, с похожим интерфейсом, справкой, плюс схожий функционал начнет работать единообразно. Затраты на обучение новым программам сократятся до минимума.


Я, как пользователь, могу лишь заметить, что единообразные программы надоедают до чертиков. Мне разнообразные нравятся, мне уже пора на свалку истории?

ЕЧ>Программисты больше не будут писать тысячапервый "инспектор объектов", а возьмут готовый, причем пользователи смогут его заменить на наиболее удобный для них. Программисты могут поставлять простую систему печати, так как она не есть главное в их приложении, а пользователи заменят её более мощной от другого производителя.


Я что-то не понял, поставляют дистрибьюторы; программисты, по-моему, все же программируют, причем обычно за деньги. При этом мне интересней программировать сложную систему, а не простую, да и денег за это больше заплатят. А писателя "тысяча первого инспектора объектов" и так скоро уволят — кризис же, он такой кому нынче нужен
Re[4]: программирование будущего
От: Евгений Чужакин Россия http://www.cadsofttools.com
Дата: 04.01.09 21:25
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это несерьёзно. "Автоматически" можно заменить только очень небольшую часть интерфейса. Фактически, только то, что уже и так делается разными стилевыми движками.


C>Это только кажется. Например, в более другой системе печати может по-другому работать разбиение на страницы. А это потребует от приложения переразбивки документа и т.п. В общем, ничего сильно сложнее того, что сейчас уже и так делается на уровне драйверов принтера — не сделать.


Безусловно, проблем на этом пути море. Но постепенно они будут решаться. Пока эта идея принципиально реализована на контролах Windows — например, можно улучшать кнопку или richedit, не трогая самого приложения. Я предлагаю дать программистам возможность самостоятельно писать модули, по стандартам, которые будут постепенно расти и включать в себя интерфейсы тысяч модулей.
Всегда готов!
Re[5]: программирование будущего
От: Cyberax Марс  
Дата: 04.01.09 21:34
Оценка:
Здравствуйте, Евгений Чужакин, Вы писали:

ЕЧ>Безусловно, проблем на этом пути море. Но постепенно они будут решаться. Пока эта идея принципиально реализована на контролах Windows — например, можно улучшать кнопку или richedit, не трогая самого приложения.

И нафиг это нужно? Чтобы кнопка была ещё более кнопкистее?

В тот же richedit не получится добавить, скажем, поддержку векторной графики — приложение не поймёт. Так что почти все улучшения будут заключаться в передвижении контролов. Чуть лучше ситуация, если описывать интерфейс декларативным способом (или с помощью развитой системы MVC) — там свободы немного больше (скажем, проще сделать центральный сервис для проверки орфографии в полях ввода, автозаполнение и т.п.). Но всё равно не особо много.

Скажем, в SWING на Java можно рисовать свои Look&Feel'ы, которые могут выглядеть совершенно различными. Причём L&F можно менять хоть во время работы программы одним вызовом функции. В теории. На практике одна и та же программа может выглядеть совершенно уродливо в некоторых L&F, хотя бы из-за несовпадающих цветовых гамм в иконках и оформлении, из-за неожиданных размеров виджетов и т.п.

ЕЧ>Я предлагаю дать программистам возможность самостоятельно писать модули, по стандартам, которые будут постепенно расти и включать в себя интерфейсы тысяч модулей.

Это просто сказки.
Sapienti sat!
Re[4]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 05.01.09 01:16
Оценка:
ЕЧ>>Пользователь будет видеть едино оформленные программы, с похожим интерфейсом, справкой, плюс схожий функционал начнет работать единообразно. Затраты на обучение новым программам сократятся до минимума.
D>Я, как пользователь, могу лишь заметить, что единообразные программы надоедают до чертиков. Мне разнообразные нравятся, мне уже пора на свалку истории?

А ты с более-менее единообразными-то работал?..

(имеется в виду Apple)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 05.01.09 01:21
Оценка:
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


YP>Каждая программа будет состоять из файлов-модулей — похоже на нынешние .dll библиотеки. Главное отличие — интерфейсная часть основных модулей — стандартизована, подобно тому, как сейчас стандартизованы интерфейсы составных частей компьютера — процессор, жесткий диск и т.д.Любой производитель может начать выпуск мониторов, причем работать они будут даже без нового драйвера — в Windows предусмотрен "стандартный монитор".


<b>Intentional programming</b> on the Lambda-the-Ultimate

Рекомендую.

Также рекомендую это дело всяким сторонникам MPS/чего-там-ещё.

С помощью IP была даже сделана одна умеренно большая программа, вроде, Outlook. Большего тормоза на ровном месте ещё поискать надо.

В общем и целом — так себе идея.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: программирование будущего
От: geniepro http://geniepro.livejournal.com/
Дата: 05.01.09 10:17
Оценка:
Здравствуйте, thesz, Вы писали:

ЕЧ>>>Пользователь будет видеть едино оформленные программы, с похожим интерфейсом, справкой, плюс схожий функционал начнет работать единообразно. Затраты на обучение новым программам сократятся до минимума.

D>>Я, как пользователь, могу лишь заметить, что единообразные программы надоедают до чертиков. Мне разнообразные нравятся, мне уже пора на свалку истории?

T>А ты с более-менее единообразными-то работал?..

T>(имеется в виду Apple)

А что, для Apple есть программы?
Re[6]: программирование будущего
От: Mamut Швеция http://dmitriid.com
Дата: 05.01.09 11:14
Оценка:
T>>А ты с более-менее единообразными-то работал?..
T>>(имеется в виду Apple)

G>А что, для Apple есть программы?


сколько угодно


dmitriid.comGitHubLinkedIn
Re[6]: программирование будущего
От: Young_Pioneer Россия http://www.cadsofttools.com
Дата: 05.01.09 12:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Например, в более другой системе печати может по-другому работать разбиение на страницы. А это потребует от приложения переразбивки документа и т.п.


Если система печати будет иметь более развитый интерфейс, чем базовое приложение (например, уметь работать со слоями), то эти функции будут недоступны (disable)При этом программа будет работать. Таким образом навороченная САПР печать может быть использована для печати простых bmp, а сложнейшие САПР файлы будут печататься (с минимальными настройками) даже в таких простых приложениях, как Paint.
То есть модули будут делать свою работу без дополнительной настройки.

C>В тот же richedit не получится добавить, скажем, поддержку векторной графики — приложение не поймёт.


Это потому, что richedit не для того сделан. А вот в броузеры и всевозможные просмоторщики поддержку векторной графики добавить можно.
Сейчас, если мы научились читать векторный формат, к примеру svg, то чтобы добавить его в популярные приложения, нужно писать РАЗНЫЕ плагины к каждому из них. Один плагин для IE, другой для Total Commander, третий для IrfanView, четвертый для ACDSee, пятый для Photoshop.
А если они все будут использовать стандартный интерфейс "графический_файл" — то можно будет обойтись ОДНИМ плагином. Причем когда некая компания захочет создать собственный векторный формат, то за базовый интерфейс она возьмёт тот же "графический_файл" — и их формат автоматически будет поддержан популярными программами.
Всегда готов!
Re[4]: программирование будущего
От: Young_Pioneer Россия http://www.cadsofttools.com
Дата: 05.01.09 12:37
Оценка:
Здравствуйте, deniok, Вы писали:

G>>В вебе (HTML+CSS+JS+XML) стандартизация существует и очень успешно. Но все в итоге уприается в реализацию стандартов разными вендорами.


Данная проблема решается, так как речь идет о создании единой системы под эгидой одной ОРГАНИЗАЦИИ. Программисты будут писать модули "для себя" и "для всех. Модули "для всех" будут проверяться в рамках ОРГАНИЗАЦИИ, подписываться и затем ставится для общего доступа — для продажи или freeware. Впрочем, это уже тонкости.

D>Беспроблемная замена модуля A на модуль B возможна, только если их базовая функциональность идентична, а отличие только в рюшечках. Либо если они практически изолированны от остальной системы; ну так я и нынче могу снести Microsoft Office и поставить Star Office, в чём проблема?


Проблема в том, что MS Office не читает PSD, а Photoshop не читает Doc. Когда будет стандарт модуля проверки офрографии, то можно писать новую программу с его использованием, а затем приобрести готовый модуль, причем для любого языка.
Всегда готов!
Re[5]: программирование будущего
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.01.09 12:47
Оценка:
Здравствуйте, Young_Pioneer, Вы писали:

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


G>>>В вебе (HTML+CSS+JS+XML) стандартизация существует и очень успешно. Но все в итоге уприается в реализацию стандартов разными вендорами.


Y_P>Данная проблема решается, так как речь идет о создании единой системы под эгидой одной ОРГАНИЗАЦИИ. Программисты будут писать модули "для себя" и "для всех. Модули "для всех" будут проверяться в рамках ОРГАНИЗАЦИИ, подписываться и затем ставится для общего доступа — для продажи или freeware. Впрочем, это уже тонкости.


ОК, позволь рассказать тебе "байку из жизни": есть тут фирмочка под названием MS, в конце прошлого века они решили замахнуться на рынок ERP, был у них задуман некий project Green, супермега-ERP, даже речь шла о некоем едином фреймворке для построения разных корпоративных систем. Купили они несколько конторок под это дело (Соломон, Навижн, ГрейтПлейнс и ещё что-то вроде). И пришли в итоге к тому, что стали выпускать чуток допиленные продукты тех конторок, которые они купили (и линейка микрософт динамикс состоит далеко не из одного продукта).
Теперь вопрос — мелкософт — это одна организация или нет?

Y_P>Проблема в том, что MS Office не читает PSD, а Photoshop не читает Doc. Когда будет стандарт модуля проверки офрографии, то можно писать новую программу с его использованием, а затем приобрести готовый модуль, причем для любого языка.


aspell?
Re[5]: программирование будущего
От: deniok Россия  
Дата: 05.01.09 13:02
Оценка:
Здравствуйте, Young_Pioneer, Вы писали:

Y_P>Проблема в том, что MS Office не читает PSD, а Photoshop не читает Doc. Когда будет стандарт модуля проверки офрографии, то можно писать новую программу с его использованием, а затем приобрести готовый модуль, причем для любого языка.


По-моему мир уже ушел существенно дальше твоих грез. Я вот пишу это письмо из-под веб-интерфейса, а firefox проверяет орфографию: русскую, английскую + пункт "добавить словари". Я не понимаю, какую и чью проблему решит такой стандарт?

На всякий случай напомню, что чтобы принять любой международный стандарт надо создать рабочую группу, пройти кучу национальных и наднациональных бюрократий, утрясти массу юридических вопросов, потратить в совокупности миллионы долларов и много человеко-лет. Там, где это реально нужно — стандарты принимаются, несмотря на все эти издержки. Вот ты, скажем, готов потратить волонтером хотя бы полгода своей жизни, чтобы поучаствовать в принятии хотя бы одного из перечисленных стандартов? Или хотя бы отдать на это сумму, эквивалентную твоей полугодовой зарплате?
Re[6]: программирование будущего
От: nikov США http://www.linkedin.com/in/nikov
Дата: 05.01.09 13:17
Оценка:
Здравствуйте, Курилка, Вы писали:

К>ОК, позволь рассказать тебе "байку из жизни": есть тут фирмочка под названием MS, в конце прошлого века они решили замахнуться на рынок ERP, был у них задуман некий project Green, супермега-ERP, даже речь шла о некоем едином фреймворке для построения разных корпоративных систем. Купили они несколько конторок под это дело (Соломон, Навижн, ГрейтПлейнс и ещё что-то вроде). И пришли в итоге к тому, что стали выпускать чуток допиленные продукты тех конторок, которые они купили (и линейка микрософт динамикс состоит далеко не из одного продукта).


Это не значит, что никакой работы по интеграции этих систем не ведется. Просто они изначально были совсем непохожи, и их сведение вместе требует немалой работы. Кое-какие части уже переиспользуются в нескольких проектах.
Re[7]: программирование будущего
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.01.09 13:24
Оценка:
Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Курилка, Вы писали:


К>>ОК, позволь рассказать тебе "байку из жизни": есть тут фирмочка под названием MS, в конце прошлого века они решили замахнуться на рынок ERP, был у них задуман некий project Green, супермега-ERP, даже речь шла о некоем едином фреймворке для построения разных корпоративных систем. Купили они несколько конторок под это дело (Соломон, Навижн, ГрейтПлейнс и ещё что-то вроде). И пришли в итоге к тому, что стали выпускать чуток допиленные продукты тех конторок, которые они купили (и линейка микрософт динамикс состоит далеко не из одного продукта).


N>Это не значит, что никакой работы по интеграции этих систем не ведется. Просто они изначально были совсем непохожи, и их сведение вместе требует немалой работы. Кое-какие части уже переиспользуются в нескольких проектах.


Ну яж вроде не говорил, что работ не было. Просто исходная идея (насколько я понимаю), была как раз близка к заявленной в топике "стандартизации", но вот на практике ситуация оказалась несколько отличной от ожидаемого.
Да и в принципе я очень не уверен, что имеет смысл подводить "под одну гребёнку" автоматизацию какого-нибудь магазана, торгующего водкой, и, скажем, Камаза, хотя некие базовые элементы стандартизовать стоит.
Re: программирование будущего
От: alpha21264 СССР  
Дата: 05.01.09 13:30
Оценка:
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


YP>Каждая программа будет состоять из файлов-модулей — похоже на нынешние .dll библиотеки. Главное отличие — интерфейсная часть основных модулей — стандартизована, подобно тому, как сейчас стандартизованы интерфейсы составных частей компьютера — процессор, жесткий диск и т.д.Любой производитель может начать выпуск мониторов, причем работать они будут даже без нового драйвера — в Windows предусмотрен "стандартный монитор".


[Skip]

YP>Заранее благодарен за комментарии.


Com-модель изобрел. Молодец.
Примерно так же Микулин в свое время изобрел турбореактивный двигатель.
Радостный примчался к своему учителю. Тот его восторга не оценил, и отправил учиться.
Эпизод описан в книжке "Жизнь Бережкова" (в www.lib.ru есть).

Течёт вода Кубань-реки куда велят большевики.
Re[5]: программирование будущего
От: alpha21264 СССР  
Дата: 05.01.09 13:37
Оценка:
Здравствуйте, thesz, Вы писали:

ЕЧ>>>Пользователь будет видеть едино оформленные программы, с похожим интерфейсом, справкой, плюс схожий функционал начнет работать единообразно. Затраты на обучение новым программам сократятся до минимума.

D>>Я, как пользователь, могу лишь заметить, что единообразные программы надоедают до чертиков. Мне разнообразные нравятся, мне уже пора на свалку истории?

T>А ты с более-менее единообразными-то работал?..


T>(имеется в виду Apple)


Я старый человек... нет не так.

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

Течёт вода Кубань-реки куда велят большевики.
Re[6]: программирование будущего
От: Mamut Швеция http://dmitriid.com
Дата: 05.01.09 14:53
Оценка:
A>В свое время пользовалась популярностью библиотека turboVision.
A>Это чтобы окошки-менюшки в ДОС-е рисовать.
A>Программы выглядели настолько одинаково, что пользователь забывал в какой программе он находится.
A>Обучению это не сильно помогало. Ну да, выпадающее меню всегда сверху. Ну и что?
A>Ведь то, что означает каждое действие все равно нужно было учить.

Есть такое понятие — «принцип наиманьшего удивления». Единообразность (не одинкоаовсть!) инетерфейсов как раз способствуе такому принципу


dmitriid.comGitHubLinkedIn
Re[7]: программирование будущего
От: Cyberax Марс  
Дата: 05.01.09 22:14
Оценка:
Здравствуйте, Young_Pioneer, Вы писали:

C>>Например, в более другой системе печати может по-другому работать разбиение на страницы. А это потребует от приложения переразбивки документа и т.п.

Y_P>Если система печати будет иметь более развитый интерфейс, чем базовое приложение (например, уметь работать со слоями), то эти функции будут недоступны (disable)При этом программа будет работать. Таким образом навороченная САПР печать может быть использована для печати простых bmp, а сложнейшие САПР файлы будут печататься (с минимальными настройками) даже в таких простых приложениях, как Paint.
Ну вот. Опять. Ты хочешь сделать заранее самую идеальную возможную печатную систему, у которой просто программы будут отключать ненужные функции.

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

C>>В тот же richedit не получится добавить, скажем, поддержку векторной графики — приложение не поймёт.

Y_P>Это потому, что richedit не для того сделан. А вот в броузеры и всевозможные просмоторщики поддержку векторной графики добавить можно.
Ты опять сбиваешься.

Твоя идея: делаем суперкастомизуемую систему, так чтоб пользователь мог нажать правой клавишей на любое поле ввода и вместо него воткнуть красивое поле ввода с поддержкой векторной графики и встроенным в виде пасхального яйца Doom3, использущим это поле ввода для savegame'ов.

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

Y_P>А если они все будут использовать стандартный интерфейс "графический_файл" — то можно будет обойтись ОДНИМ плагином. Причем когда некая компания захочет создать собственный векторный формат, то за базовый интерфейс она возьмёт тот же "графический_файл" — и их формат автоматически будет поддержан популярными программами.

Это уже было давно придумано и даже сделано, и называется OLE (ещё из подобного OpenDoc на Mac'ах был, ну и HyperCard оттуда же). Там есть и compound document'ы и встраивание приложений, и вообще много чего ещё.
Sapienti sat!
Re[6]: программирование будущего
От: Zhendos  
Дата: 05.01.09 22:31
Оценка:
Здравствуйте, deniok, Вы писали:

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


Y_P>>Проблема в том, что MS Office не читает PSD, а Photoshop не читает Doc. Когда будет стандарт модуля проверки офрографии, то можно писать новую программу с его использованием, а затем приобрести готовый модуль, причем для любого языка.


D>По-моему мир уже ушел существенно дальше твоих грез. Я вот пишу это письмо из-под веб-интерфейса, а firefox проверяет орфографию: русскую, английскую + пункт "добавить словари". Я не понимаю, какую и чью проблему решит такой стандарт?


в данном случае проблема уже решена, насколько я помню
openoffice, firefox и компания скооперировались и сделали hunspell
общую систему проверки орфографии
Re[3]: программирование будущего
От: Dufrenite Дания  
Дата: 06.01.09 09:32
Оценка:
Здравствуйте, thesz, Вы писали:

T>Па-апрашу развернуть!


Не, я не тролль
Re[8]: программирование будущего
От: Young_Pioneer Россия http://www.cadsofttools.com
Дата: 06.01.09 09:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Печатные системы будут делать профессиональные производители печатных систем.
Конкретный пример: есть реальный клиент, который хочет видеть нашу печать в Visio, чтобы можно было печатать большие изображения с разбивкой на листы. В принципе, это можно сделать через драйвер принтера (интерфейс драйвер, несмотря на свою сложность, используется очень часто, например для создания pdf), но в будущем хотелось бы иметь более простой метод.

C>Только проблема-то не в этом. Проблема в том, как сделать так, чтобы дополнительные функции можно было добавлять не изменяя программ.


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

C>Твоя идея: делаем суперкастомизуемую систему, так чтоб пользователь мог нажать правой клавишей на любое поле ввода и вместо него воткнуть красивое поле ввода с поддержкой векторной графики и встроенным в виде пасхального яйца Doom3, использущим это поле ввода для savegame'ов.


"Кастомизация" как раз не главное. И "куда угодно что угодно" воткнуть пользователь не сможет — на это есть программисты. При этом есть некоторые модули программ, которые можно заменить на "более хорошие" либо добавить дополнительные: например, добавлять поддержку новых форматов файлов.
Эти модули:
-загрузка и сохранение из/в определенный формат (можно добавлять модули)
-пользовательский интерфейс (можно заменять модули)
— печать (можно добавлять / заменять модули)
— общие алгоритмы: перевод, шифрование, векторизация растра и т.д.
многие из таких модулей уже сейчас делаются профессионалами и продаются в виде компонентов либо исходников. Только без каких-либо СТАНДАРТОВ.

COM даёт богатые возможности совместного использования компонентов программ и иногда методы тотальной "кастомизации" самих программ. Мы тоже делаем COM компоненты, и клиенты-ПРОГРАММИСТЫ легко вставляют их в свои программы. Но НЕТ СТАНДАРТА, чтобы написать компонент, который вставится во все профессиональные программы, которым может понадобится этот функционал. COM, конечно, может быть использован как база для реализации идеи модулей, но лучше создать новую технологию.

Y_P>>А если они все будут использовать стандартный интерфейс "графический_файл" — то можно будет обойтись ОДНИМ плагином. Причем когда некая компания захочет создать собственный векторный формат, то за базовый интерфейс она возьмёт тот же "графический_файл" — и их формат автоматически будет поддержан популярными программами.


C>Это уже было давно придумано и даже сделано, и называется OLE


То есть можно сделать COM объект, читающий простенький растровый формат '*.abc' и такие программы, как MS Office, Google Chrome, Photoshop, AutoCAD, 1C и другие "поймут" этот COM объект и будут открывать *.abc подобно *.bmp? Один плагин для всех?
Всегда готов!
Re[5]: программирование будущего
От: Dufrenite Дания  
Дата: 06.01.09 13:22
Оценка:
Здравствуйте, thesz, Вы писали:

T>Лично мне интересно, что же такого ты придумал, что стоит выше уровнем, чем ФП.


T>В которое ФП входит и <a href=http://en.wikipedia.org/wiki/Martin-Lof_type_theory&gt;теория типов</a>, которая ну очень высокоуровневая.


Да ничего я не придумал. Просто беру конкретную задачу или класс задач и подбираю на мой взгляд оптимальное решение. Это творчество а не теории.
Топикстартер поставил вполне конкретную задачу и я не вижу никакого способа решить её применив функциональную декомпозицию или что нибудь подобное. Здесь совсем другой подход нужен.
Re[5]: программирование будущего
От: Dufrenite Дания  
Дата: 06.01.09 13:59
Оценка:
Здравствуйте, thesz, Вы писали:

T>стоит выше уровнем, чем ФП.


Вопрос. Зачем такая фиксация на высокоуровневости?
ИМХО, чем выше уровень, тем больше фиксация на какой-то одной стороне задачи. Вот теория типов, она, наверное, описывает задачу с точки зрения типов. Как она мне поможет, если мне надо, например, по алгоритмам протоколы передачи данных генерировать, на С++ и Java. Это очень далеко от проблем, описываемых этой теорией. В данном контексте она практически бесполезна.
Re[9]: программирование будущего
От: Cyberax Марс  
Дата: 07.01.09 01:33
Оценка:
Здравствуйте, 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 и посмотри.
Sapienti sat!
Re[6]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 07.01.09 18:24
Оценка:
T>>стоит выше уровнем, чем ФП.
D>Вопрос. Зачем такая фиксация на высокоуровневости?

Потому, что удобно.

D>ИМХО, чем выше уровень, тем больше фиксация на какой-то одной стороне задачи. Вот теория типов, она, наверное, описывает задачу с точки зрения типов. Как она мне поможет, если мне надо, например, по алгоритмам протоколы передачи данных генерировать, на С++ и Java. Это очень далеко от проблем, описываемых этой теорией. В данном контексте она практически бесполезна.


I beg to differ.

Correct-by-construction concurrency
Embedding a Language with Certified Size Constraints in a Dependently Typed Metalanguage
A Verified Staged Interpreter is a Verified Compiler (Multi-stage Programming with Dependent Types)

Если ты хочешь текст генерировать, то кое-что из теории типов (она же "зависимые типы (данных)") может быть полезно. Причем напрямую.

Что самое интересное, на языке с зависимыми типами данных обычно реализуется описание проблемы, которое потом интерпретируется. Результат интерпретации, в частности, можеть быть и результатом компиляции — путем специализации.

Так что я напрямую вижу, что самое близкое к этой дискуссии находится в районе зависимых типов данных.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: программирование будущего
От: minorlogic Украина  
Дата: 07.01.09 20:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Только оказывается, что это поле ввода используется внутри приложения в текстовом виде. И попытка туда добавить графику приведёт к краху. Вот и закончилась эта история.


Неправда твоя , есть же MPEG7
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[9]: программирование будущего
От: Cyberax Марс  
Дата: 07.01.09 23:11
Оценка:
Здравствуйте, minorlogic, Вы писали:

C>>Только оказывается, что это поле ввода используется внутри приложения в текстовом виде. И попытка туда добавить графику приведёт к краху. Вот и закончилась эта история.

M>Неправда твоя , есть же MPEG7
???
Sapienti sat!
Re[6]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 07.01.09 23:22
Оценка:
A>В свое время пользовалась популярностью библиотека turboVision.
A>Это чтобы окошки-менюшки в ДОС-е рисовать.
A>Программы выглядели настолько одинаково, что пользователь забывал в какой программе он находится.
A>Обучению это не сильно помогало. Ну да, выпадающее меню всегда сверху. Ну и что?
A>Ведь то, что означает каждое действие все равно нужно было учить.

TurboVision и Apple UI Guidelines немного отличаются.

Например, наличием спецпункта меню с названием программы. Тем, что одинаковые действия делаются одинаковыми клавишами и этих клавиш достаточно много.

Наверное, чем-то ещё.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: программирование будущего
От: minorlogic Украина  
Дата: 08.01.09 06:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Только оказывается, что это поле ввода используется внутри приложения в текстовом виде. И попытка туда добавить графику приведёт к краху. Вот и закончилась эта история.

M>>Неправда твоя , есть же MPEG7
C>???

http://en.wikipedia.org/wiki/Mpeg7

Стандарт на взаимодействие медиа данных и пользователя , предусматривает очень богатый набор взаимодействий.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[11]: программирование будущего
От: Cyberax Марс  
Дата: 08.01.09 17:31
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>>>Неправда твоя , есть же MPEG7

C>>???
M>http://en.wikipedia.org/wiki/Mpeg7
M>Стандарт на взаимодействие медиа данных и пользователя , предусматривает очень богатый набор взаимодействий.
Вот блин. Прочитай что я написал.

Твоя программа сможет вдруг обрабатывать Mpeg7 вместо plain text во всех полях ввода?
Sapienti sat!
Re[12]: программирование будущего
От: minorlogic Украина  
Дата: 08.01.09 18:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


M>>>>Неправда твоя , есть же MPEG7

C>>>???
M>>http://en.wikipedia.org/wiki/Mpeg7
M>>Стандарт на взаимодействие медиа данных и пользователя , предусматривает очень богатый набор взаимодействий.
C>Вот блин. Прочитай что я написал.

C>Твоя программа сможет вдруг обрабатывать Mpeg7 вместо plain text во всех полях ввода?


Так и я об этом , если будет потдерживать стандарт Мpeg7 то сможет. Я просто хотел отметить что даже не такой нетривиальный пример может быть стандарт.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[13]: программирование будущего
От: Cyberax Марс  
Дата: 08.01.09 18:45
Оценка:
Здравствуйте, minorlogic, Вы писали:

C>>Вот блин. Прочитай что я написал.

C>>Твоя программа сможет вдруг обрабатывать Mpeg7 вместо plain text во всех полях ввода?
M>Так и я об этом , если будет потдерживать стандарт Мpeg7 то сможет. Я просто хотел отметить что даже не такой нетривиальный пример может быть стандарт.
Торррмозишь опять. Вот у тебя поле ввода — и тебе от него вместо plain text'а вдруг приходит Mpeg7.

Понятно, что если сразу всё поддержать — то оно может будет работать.
Sapienti sat!
Re[7]: программирование будущего
От: Dufrenite Дания  
Дата: 08.01.09 18:51
Оценка:
Здравствуйте, thesz, Вы писали:

T>Correct-by-construction concurrency

T>Embedding a Language with Certified Size Constraints in a Dependently Typed Metalanguage
T>A Verified Staged Interpreter is a Verified Compiler (Multi-stage Programming with Dependent Types)

T>Если ты хочешь текст генерировать, то кое-что из теории типов (она же "зависимые типы (данных)") может быть полезно. Причем напрямую.


T>Что самое интересное, на языке с зависимыми типами данных обычно реализуется описание проблемы, которое потом интерпретируется. Результат интерпретации, в частности, можеть быть и результатом компиляции — путем специализации.


T>Так что я напрямую вижу, что самое близкое к этой дискуссии находится в районе зависимых типов данных.


Спасибо за ссылки. Почитаю.
Жаль, что мой английский немного слабоват
Re[8]: программирование будущего
От: Dufrenite Дания  
Дата: 08.01.09 18:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это уже было давно придумано и даже сделано, и называется OLE (ещё из подобного OpenDoc на Mac'ах был, ну и HyperCard оттуда же). Там есть и compound document'ы и встраивание приложений, и вообще много чего ещё.


Если это было так здорово продумано и сделано, то почему этим практически никто не пользуется?
Может лучше сказать так: OLE, это первые, неуклюжие попытки создания чего-то подобного.
Re[8]: программирование будущего
От: Dufrenite Дания  
Дата: 08.01.09 19:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Только проблема-то не в этом. Проблема в том, как сделать так, чтобы дополнительные функции можно было добавлять не изменяя программ.


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

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

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

Короче, боюсь что задачка не для нынешнего технологического уровня.
Re[10]: программирование будущего
От: Dufrenite Дания  
Дата: 08.01.09 20:11
Оценка:
C>Это НЕРЕАЛЬНО. Совсем.

Дык об этом и говорю.

C>Попробуй, например, переделать модуль поддержки языка для Eclipse в модуль для IDEA.


C>Упс... Внутренние представления слишком различаются, проще переписать всё.


Ага. Вот только смысловая составляющая совершенно одинакова. Если язык один и тот же, компилятор один и тот же, требования к IDE для этого языка такие же. Пусть даже IDE по своим возможностям сильно отличаются (скажем нет поддержки интеллисенс в конкретной IDE): хрен бы с ними. Нет объективных причин для невозможности такого встраивания. Только отсутствие технических возможностей.
Поэтому я и говорю, что для решения подобных задач нужно придумать совершенно другие подходы.

C>Оно просто-напросто не нужно. Никто не кастомизирует автомобили "Запорожец", ставя туда двигатели от БелАЗа. И аналогия со сторонними производителями деталей тоже не проходит — так как сторонние детали в точности повторяют родные.


Ну мы то программы разрабатываем. Нам не впервой ужа с ежом скрестить. Возможностей на порядок больше. Мы ведь с информацией работаем а не с железками.
Можем и от белаза мотор поставить, можем от мессершмитта. Главное, чтобы это по смыслу мотор был.
Re[12]: программирование будущего
От: Dufrenite Дания  
Дата: 08.01.09 21:02
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Неа.


Почему нет? Какая компилятору разница в какой IDE его данные редактируют?

C>"IntelliSense" есть в Eclipse и IDEA, но внутри они реализованы сильно по-разному. И имеют заметно разную функциональность.


Дык как это на язык влияет? Компилятор должен каким то образом "рассказать" IDE о своих возможностях, а IDE должна этот "рассказ" понять и "решить" что из этих возможностей она может использовать. Именно язык для этого "разговора" и предполагается стандартизовать.

C>А ещё сейчас вспомню программы, типа CAD'ов, где вообще могут быть кардинально разные способы представления данных.


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

C>Я не вижу смысла делать программы, которые на 100% будут состоять из взаимозаменяемых кубиков. Это невозмонжо, да и не нужно.


Нужно это или не нужно сейчас определённо сказать нельзя. Только тогда, когда это будет возможно технологически можно будет понять как извлечь из этого прибыль. А сейчас хз. Для меня вот выглядит заманчиво.
Re[13]: программирование будущего
От: Cyberax Марс  
Дата: 08.01.09 22:15
Оценка:
Здравствуйте, Dufrenite, Вы писали:

C>>Неа.

D>Почему нет? Какая компилятору разница в какой IDE его данные редактируют?
Компилятору — никакая. Я говорю про портирование модуля для того, что ты называешь "IntelliSense".

C>>"IntelliSense" есть в Eclipse и IDEA, но внутри они реализованы сильно по-разному. И имеют заметно разную функциональность.

D>Дык как это на язык влияет? Компилятор должен каким то образом "рассказать" IDE о своих возможностях, а IDE должна этот "рассказ" понять и "решить" что из этих возможностей она может использовать. Именно язык для этого "разговора" и предполагается стандартизовать.
Ну вот стандартизуй систему для внутренного представления "IntelliSense". Чтобы я мог взять модуль поддержки Nemerle из VisualStudio и воткнуть его в Eclipse простым перетаскиванием мышки.

C>>А ещё сейчас вспомню программы, типа CAD'ов, где вообще могут быть кардинально разные способы представления данных.

D>Не спорю. Но ведь можно заставить разные системы между собой "договориться". Если у них разные представления данных, это не значит, что их нельзя сконвертировать.
Можно. Вот у меня есть разреженная карта высот на 2Гб. А плугину нужна регулярная — при конвертировании она будет занимать 20Гб.

Упс.

C>>Я не вижу смысла делать программы, которые на 100% будут состоять из взаимозаменяемых кубиков. Это невозмонжо, да и не нужно.

D>Нужно это или не нужно сейчас определённо сказать нельзя. Только тогда, когда это будет возможно технологически можно будет понять как извлечь из этого прибыль. А сейчас хз. Для меня вот выглядит заманчиво.
Это у тебя опыта мало.
Sapienti sat!
Re[14]: программирование будущего
От: Dufrenite Дания  
Дата: 08.01.09 23:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну вот стандартизуй систему для внутренного представления "IntelliSense". Чтобы я мог взять модуль поддержки Nemerle из VisualStudio и воткнуть его в Eclipse простым перетаскиванием мышки.


Если бы точно знать как это сделать можно было бы в лёгкую мульён срубить .
Например, всё то же самое, что и в большинстве современных IDE:
1. Сначала надо понять могут ли в принципе Eclipse и Nemerle общаться.
2. Выбирается наиболее эффективный язык общения. Например Eclipse поддерживает версию стандарта 1.0 и 2.0, а Nemerle 2.0 и 3.0. Выбирается стандарт 2.0.
3. Eclipse выясняет, что Nemerle язык текстовый. У Eclipse установлено несколько текстовых редакторов. Eclipse выбирает редактор в наибольшей степени соответствующий предпочтениям Nemerle. Например редактор с поддержкой регионов.
4. Если, например, в стандарте 2.0 нет понятия регион, то Nemerle об этом просто ничего не говорит. Живём без них.
5. Если пользователь обновляет Eclipse и он начинает понимать стандарт 3.0, то общение повторяется на новом уровне.
6. Eclipse позволяет пользователю самому выбирать, каким редактором ему редактировать Nemerle-программы.
7. То же самое с отладчиком.
8. С рефакторингом всё совсем просто. Nemerle говорит какие функции доступны. IDE позволяет пользователю выбрать функцию и говорит компилятору что ему делать.

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

C>Можно. Вот у меня есть разреженная карта высот на 2Гб. А плугину нужна регулярная — при конвертировании она будет занимать 20Гб.


C>Упс.


Отличный пример. В этом и будет заключаться общение:
CAD: У меня карта высот есть. Разреженная. Площадью 100х100 км.
Плагин: Так посмотрим, могу я с такой картой работать или нет. Ага 20 гигов. Не, не могу.
CAD: Хозяин не подходит плагин.
Юзер: Ну не подходит так не подходит. Проверим другой.

C>Это у тебя опыта мало.


Опыт не при чем здесь. Мы же не ТЗ составляем. Форум у нас про философию, вот я и пытаюсь по мере своих скромных способностей рассмотреть заинтересовавшую меня проблему.
Re[8]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 08.01.09 23:51
Оценка:
T>>С теорией лучше, нес па?
D>Зависит от задачи. Чаще всего хватает простого здравого смысла. Опять же, можно подменить реальное условие задачи, имеющее ценность для бизнеса, формулировками красивой теории. Была даже байка о применении сразу нескольких паттернов проектирования в десяти строчках кода.

Шаблоны — это не стройная теория.

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


Выбор которого, обычно, аукается очень сильно.

Ты, как я понимаю, с применением "стройной теории" ничего никогда не писал?

(стройная теория — это что-то уровня хотя бы системы типов Хаскеля)

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


Please, reconsider.

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

D>Для решения этой задачи надо применять все известные виды декомпозиции, в том числе и функциональную.

Что подтверждает мои слова.

T>>Для стандартизации компонент типы нужны? Нужны.

D>Безусловно.
T>>Эффекты надо типизировать? Надо.
D>И не только их.

Что ещё?

T>>Вот и пришли к системе типов с типизацией эффектов, самой простой из которых является Хаскельная.

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

Ты утерял мысль. Мы не про возможности языка, а про систему типов. Вот в Хаскеле есть какая-никакая типизация эффектов.

А надо ещё круче.

Круче — это теория типов (зависимые типы, теория типов Мартина-Лофа).

Вот и пришли, что для реализации твоей (ну, не твоей) идеи необходимо смотреть в её сторону в обязательном порядке.

Вуаля!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: программирование будущего
От: Cyberax Марс  
Дата: 09.01.09 12:43
Оценка:
Здравствуйте, Dufrenite, Вы писали:

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

Мда. Видимо, ты не понимаешь что я имею в виду. Вот у тебя есть язык — Java. Внутреннее представление в редакторе — это AST, который привязан к элементам в редакторе. Действия над AST отражаются в редактируемом тексте (и наоборот).

Так вот, этот AST — он зависит от языка. Для Nemerle дерево будет совсем иное. А уж про С++ я вообще молчу. А ещё нужно разбирать текст с ошибками и неполной информацией.

Вот так и получается, что общей в IDE будет только функциональность примитивного текстового редактора. Соответственно, плугины должны или всё остальное делать самостоятельно, или затачиваться под конкретную IDE.

D>Юзер: Ну не подходит так не подходит. Проверим другой.

Ну и вот такое будет в 99% случаев, если явно не писать и не тестировать плугины под конкретные программы.

C>>Это у тебя опыта мало.

D>Опыт не при чем здесь. Мы же не ТЗ составляем. Форум у нас про философию, вот я и пытаюсь по мере своих скромных способностей рассмотреть заинтересовавшую меня проблему.
Опыт нужен, чтобы понять, что эту проблему просто решать не нужно.
Sapienti sat!
Re[16]: программирование будущего
От: Dufrenite Дания  
Дата: 09.01.09 13:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вот у тебя есть язык — Java. Внутреннее представление в редакторе — это AST, который привязан к элементам в редакторе. Действия над AST отражаются в редактируемом тексте (и наоборот).


C>Так вот, этот AST — он зависит от языка. Для Nemerle дерево будет совсем иное. А уж про С++ я вообще молчу. А ещё нужно разбирать текст с ошибками и неполной информацией.


Что это меняет?

C>Вот так и получается, что общей в IDE будет только функциональность примитивного текстового редактора. Соответственно, плугины должны или всё остальное делать самостоятельно, или затачиваться под конкретную IDE.


А разве в современных IDE всё по другому происходит? Например рефактоингом Nemerle-кода занимается непосредственно студия или всё таки интеграция?

D>>Юзер: Ну не подходит так не подходит. Проверим другой.

C>Ну и вот такое будет в 99% случаев, если явно не писать и не тестировать плугины под конкретные программы.

Это очевидно. Пару постов раньше:
D>боюсь что задачка не для нынешнего технологического уровня

C>Опыт нужен, чтобы понять, что эту проблему просто решать не нужно.

Я решаю эту проблему просто как интересную теоретическую задачу. Я ничего не продаю и не предлагаю.
Re[17]: программирование будущего
От: Cyberax Марс  
Дата: 09.01.09 20:43
Оценка:
Здравствуйте, Dufrenite, Вы писали:

C>>Так вот, этот AST — он зависит от языка. Для Nemerle дерево будет совсем иное. А уж про С++ я вообще молчу. А ещё нужно разбирать текст с ошибками и неполной информацией.

D>Что это меняет?
Всё.

C>>Вот так и получается, что общей в IDE будет только функциональность примитивного текстового редактора. Соответственно, плугины должны или всё остальное делать самостоятельно, или затачиваться под конкретную IDE.

D>А разве в современных IDE всё по другому происходит? Например рефактоингом Nemerle-кода занимается непосредственно студия или всё таки интеграция?
Не совсем так. Скажем, в IntelliJ IDEA есть готовая архитектура для работы с AST языка, с поддержкой подсветки ошибок, транзакциями над AST и т.п. В Eclipse есть похожее, но другое.
Sapienti sat!
Re[18]: программирование будущего
От: Dufrenite Дания  
Дата: 10.01.09 15:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не совсем так. Скажем, в IntelliJ IDEA есть готовая архитектура для работы с AST языка, с поддержкой подсветки ошибок, транзакциями над AST и т.п. В Eclipse есть похожее, но другое.


Это очевидно. Но мы же говорим о стандартизации. Вот здесь нюансы и появляются.
Re[9]: программирование будущего
От: Dufrenite Дания  
Дата: 10.01.09 15:45
Оценка:
Здравствуйте, thesz, Вы писали:

T>Шаблоны — это не стройная теория.


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

T>Выбор которого, обычно, аукается очень сильно.


T>Ты, как я понимаю, с применением "стройной теории" ничего никогда не писал?


T>(стройная теория — это что-то уровня хотя бы системы типов Хаскеля)


Вот тут то ты меня и поймал . Очень сложно найти программиста хоть раз писавшего что-то по строгой теории. Специфика-с.

T>Please, reconsider.


Уже не получится. Мне гораздо интереснее прикладные задачки решать.

T>Что подтверждает мои слова.


Я не говорил, что не согласен. Изначальная мысль о том, что функционального подхода недостаточно.

T>>>Эффекты надо типизировать? Надо.

D>>И не только их.

T>Что ещё?


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

T>>>Вот и пришли к системе типов с типизацией эффектов, самой простой из которых является Хаскельная.

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

T>Ты утерял мысль. Мы не про возможности языка, а про систему типов. Вот в Хаскеле есть какая-никакая типизация эффектов.


T>А надо ещё круче.


T>Круче — это теория типов (зависимые типы, теория типов Мартина-Лофа).


T>Вот и пришли, что для реализации твоей (ну, не твоей) идеи необходимо смотреть в её сторону в обязательном порядке.


T>Вуаля!


Возможно ты прав. Я не настолько знаком с теорией типов, чтобы на равных этот вопрос обсуждать. К сожалению, такие вещи изучается годами.
Re: программирование будущего
От: Alexander G Украина  
Дата: 10.01.09 17:19
Оценка:
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


...

нет, это не программитрование будущего.

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

интнресно, что из этого
Автор: Shmj
Дата: 06.01.09
Вопрос: Какие технологии и библиотеки для создания пользовательского интерфейса десктопных приложений вы предположительно будете использовать в этом году?
 и этого
Автор: Shmj
Дата: 09.01.09
Вопрос: Укажите технологии, которые вы предположительно будете использовать для работы с базой данных в этом году. Просьба конкретизировать. Максимум 2 ответа -- выберите главное.
 признавать кошерным в случае стандартизации (только одно из каждого списка, остальное выкинуть как не соответствующее стандартам).
Русский военный корабль идёт ко дну!
Re[11]: программирование будущего
От: deniok Россия  
Дата: 12.01.09 18:15
Оценка:
Здравствуйте, thesz, Вы писали:

T>За полгода наблатыкаешься, будешь круче deniok о холоморфизмах рассуждать.


Ох, понаеду двадцать четвертого, наведу у вас порядок!
Re[2]: программирование будущего
От: Erop Россия  
Дата: 12.01.09 22:58
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Без этого обсуждать идею имеет смысл не больше, чем мысль "вот пусть все граждане России скинутся мне по 50 копеек. Они ничего даже не заметят, а мне 60 миллионов рублей очень пригодятся".


А что, 10 лимонов ты себе на чай решил прибрать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: программирование будущего
От: Erop Россия  
Дата: 12.01.09 22:59
Оценка:
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


Заботай MAC OS X, в области Cocao, а MAC OS Classic в области AE... Там нечто очень похожее есть и уже много лет работает...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: программирование будущего
От: Dufrenite Дания  
Дата: 13.01.09 12:22
Оценка:
Здравствуйте, thesz, Вы писали:

T>Теория типов представляет собой конструктивную формализацию математики. В переводе на русский язык это означает, что любое доказательство существования какого-либо объекта в этой теории представляет собой алгоритм вычислений этого объекта, это раз (прилагательное "конструктивная"). Она может быть проверена или исполнена механически (существительное "формализация"), это два. Третье, и последнее, слово "математика" означает... Ну, например, то, что наверняка есть какая-либо теория под наши текущие нужды, остаётся только её отыскать и записать.


T>"Под текущие нужды" — это "для нашей предметной области".


T>Что ещё "нужно растущему организму"?


Интересно. Вполне возможно, что поможет в моих исследованиях.

T>Да брось ты!


T>За полгода наблатыкаешься, будешь круче deniok о холоморфизмах рассуждать.


Если не сложно, кинь ссылочку для начинающих. Буду холоморфизмами впечатление на девчОнок производить .
Re[3]: программирование будущего
От: Dym On Россия  
Дата: 23.01.09 10:15
Оценка:
E>А что, 10 лимонов ты себе на чай решил прибрать?
А это налоги
Счастье — это Glück!
Re[2]: программирование будущего
От: dilmah США  
Дата: 25.01.09 16:30
Оценка:
H>Идея называется COM в утопическом максимуме.

Идея называется http://en.wikipedia.org/wiki/Open_system_(computing)
Re: программирование будущего
От: BulatZiganshin  
Дата: 06.02.09 11:02
Оценка:
Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:


22 года назад малоизвестная фирма NeXT Inc. выпустила компьютер NeXT, за названием которого угадывалась аббревиатура New XT. в нём весь системный софт был написан на языке Objective C, главным отличием которого от C++ была возможность динамического диспатчинга вызова методов и благодаря этому — динамической загрузки реализации классов

компьютер был очень тепло встречен оборзевателями и полностью провалился на рынке. позднее идеи динамического связывания на уровне объектов перекочевали в яву, оберон, корбу и COM, а сама среда NeXTStep — в компьютеры Apple
Люди, я люблю вас! Будьте бдительны!!!
Re[7]: программирование будущего
От: vdimas Россия  
Дата: 06.02.09 12:28
Оценка:
Здравствуйте, thesz, Вы писали:

T>Для стандартизации компонент типы нужны? Нужны.


Вот тут и упираемся, ибо сами типыпринципиально зависят от подробности конкретной задачи. Другое дело, что давно витает в воздухе идея стандартизировать св-ва типов, дабы можно было обобщать алгоритмы, в С++ на шаблонах и в некоторых функциональных это где-то работает на наглядном синтаксическом уровне (хотя на неявном уровне, на уровне ошибок компиляции, если тип не имеет нужного члена, поля или метода). А на популярных .Net или Java даже банальное сложение через контракты выглядит убого и работает так же в плане эффективности.

Тут вот периодически пробегает человек, который разрабатывает некое единое семантическое представление программ, ИМХО, из области попыток решить этот вопрос.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[9]: программирование будущего
От: vdimas Россия  
Дата: 06.02.09 13:23
Оценка:
Здравствуйте, deniok, Вы писали:

D>Дело не в юридической стандартизации,


Пока что вершиной стандартизации является контракт (не обязательно тот, который сущность "interface" из некоторых языков).

D>а во внедрениии в прикладное языкостроение достижений теории типов (и связанной с ней теории доменов). Если мы держимся в рамках соответствующей математики, то получаем довольно сильные гарантии правильности программы, прошедшей тайпчекер.


Нужна идея, как синтаксически красиво объявлять произвольные по-сущности своей контракты. Например, изобрети синтаксис на контракт на банальный оператор + для призвольного типа и рядом — на поддержку некоей произвольной операции, выглядящей как посылка сообщения экземпляру.


D>Фактически большинство современных теорем-пруверов основаны на какой-то версии типизации лямбда-исчисления; сделать из этого удобный прикладной язык, не потеряв строгих гарантий — вот чэллендж сегодняшнего дня.


В непротиворечивый синтаксис всё упирается. Чем больше возможностей в языке (при нашем-то бедном алфавите значков или того хуже — институте ключевых слов), тем больше комбинаторно-вызываемых возможных неоднозначностей. Заметь, нотационный язык математики куда как богаче, чем возможности нашей клавы.

D>А у типов современных массовых языков инструментарий их построения слегка бедноват и кривоват.


Угу, потому как слегка "простоват", и то, в этой простоте стандарт современного развитого языка — это увесистый такой томик. Куда дальше? С этим что делать? Давай ИДЕЮ!


D>Тут опять проблема в кодификации этого семантического единства. На чем она будет основана — на общепринятом (делаем так, поскольку в большинстве современных языков так) или на Карри-Ховарде-Жирарде-Рейнолдсе-etc (делаем так, потому что система типов оказывается изоморфной некоторой богатой логической системе).


У него задумка чуть круче (ибо задумка — минимум ограничений на модель, т.е. при желании много чего сделать можно), мы вот разве что за реализацию боимся, хотя я, лично, может и доживу до первой подобной системы — суть базы знаний нашей многострадальной IT. (интересно, автор это понимает?)
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[10]: программирование будущего
От: deniok Россия  
Дата: 06.02.09 15:42
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Нужна идея, как синтаксически красиво объявлять произвольные по-сущности своей контракты. Например, изобрети синтаксис на контракт на банальный оператор + для призвольного типа и рядом — на поддержку некоей произвольной операции, выглядящей как посылка сообщения экземпляру.


Тут как раз есть масса разных подходов, причем даже известно, как ad hoc полиморфизм сводить к параметрическому (в Хаскелле класс типов транслируется в словарик, передающийся как неявные аргументы функции, типа VTBL, но привязанная не к объекту, а к функции). Вот пример проблемы, в принципе решенной, но требующей использования более богатых систем, чем используемые сейчас в мэйнстриме: написать контракт, гарантирующий на входе функции сортированность массива. Динамическая проверка требует O(N) времени. Поэтому хочется статической — во время компиляции. На зависимых типах такие контракты писать можно, причем не с помощью закулисной машинерии, а от первооснов, на языке типов. Но депендент-тайп-комьюнити пока еще не создало язык, про который бы все сказали "да, это готово к тому, чтобы идти в массы." Ситуация напоминает середину 80-х в функциональном программировании: есть куча очень похожих языков, надо поиграть с деталями и родить общепризнанно хороший результат (так в конце 80-х Хаскелл появился).

V>В непротиворечивый синтаксис всё упирается. Чем больше возможностей в языке (при нашем-то бедном алфавите значков или того хуже — институте ключевых слов), тем больше комбинаторно-вызываемых возможных неоднозначностей. Заметь, нотационный язык математики куда как богаче, чем возможности нашей клавы.


Это не проблема, математики не вырисовывают же квантор общности нигде, кроме как на доске, а пишут в TeX'е \forall. Ну и программисты на Хаскелле пишут forall, а при публикации статей\документации это превращается в квантор общности

D>>А у типов современных массовых языков инструментарий их построения слегка бедноват и кривоват.


V>Угу, потому как слегка "простоват", и то, в этой простоте стандарт современного развитого языка — это увесистый такой томик. Куда дальше? С этим что делать? Давай ИДЕЮ!


Я боюсь меня побьют. Но намекну. Определение бестипового лямбда-исчисления: две операции (аппликация и абстракция) и одно правило редукции (бета, ну можно ещё альфа-редукцию для практических целей). Это дает все исчисление. Типизация исчисления — это ещё несколько правил, порождающих чистую систему типов (PTS). Добавим сюда индуктивные типы (еще несколько правил) и получим уже систему типов, с которой можно жить. В том смысле, что у нас есть универсальное ядро, а все более высокоуровневые конструкции можно декларировать в терминах трансляции в это ядро. Причем заметь, процесс этой трансляции может верифицироваться ядром, как уже рабочей системой.

То есть Стандарт — не юридический текст на человеческом языке, а формальная система с формализованными (а значит верифицируемыми) синтаксисом и семантикой.

Главное, чтобы инженерные вопросы (типа эффективного представления Integer, Float и строк) не шли в ущерб формальной целостности.
Re[10]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 06.02.09 15:47
Оценка:
D>>А у типов современных массовых языков инструментарий их построения слегка бедноват и кривоват.
V>Угу, потому как слегка "простоват", и то, в этой простоте стандарт современного развитого языка — это увесистый такой томик. Куда дальше? С этим что делать? Давай ИДЕЮ!

А ты почитай то, про что deniok пишет. Вот тебе и идея.

Стандарт современного развитого языка как охапка хвороста — объём большой, а весу мало. Тогда, как описание той же теории типов с основными теоремами (но без их доказательств) "уместится на полях этой книги", перефразируя Ферма.

D>>Тут опять проблема в кодификации этого семантического единства. На чем она будет основана — на общепринятом (делаем так, поскольку в большинстве современных языков так) или на Карри-Ховарде-Жирарде-Рейнолдсе-etc (делаем так, потому что система типов оказывается изоморфной некоторой богатой логической системе).


Вот про это и читай, ага.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: программирование будущего
От: thesz Россия http://thesz.livejournal.com
Дата: 06.02.09 15:49
Оценка:
T>>Для стандартизации компонент типы нужны? Нужны.
V>Вот тут и упираемся, ибо сами типыпринципиально зависят от подробности конкретной задачи. Другое дело, что давно витает в воздухе идея стандартизировать св-ва типов, дабы можно было обобщать алгоритмы, в С++ на шаблонах и в некоторых функциональных это где-то работает на наглядном синтаксическом уровне (хотя на неявном уровне, на уровне ошибок компиляции, если тип не имеет нужного члена, поля или метода). А на популярных .Net или Java даже банальное сложение через контракты выглядит убого и работает так же в плане эффективности.

Type erasure спасёт отца русской демократии.

V>Тут вот периодически пробегает человек, который разрабатывает некое единое семантическое представление программ, ИМХО, из области попыток решить этот вопрос.


1972 год.

Ученик Колмогорова Пер Мартин-Лёф разработал первую версию теории типов.

Пер Мартин-Лёф никогда не прибегал на RSDN.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: программирование будущего
От: vdimas Россия  
Дата: 06.02.09 15:55
Оценка:
Здравствуйте, deniok, Вы писали:

V>>В непротиворечивый синтаксис всё упирается. Чем больше возможностей в языке (при нашем-то бедном алфавите значков или того хуже — институте ключевых слов), тем больше комбинаторно-вызываемых возможных неоднозначностей. Заметь, нотационный язык математики куда как богаче, чем возможности нашей клавы.


D>Это не проблема, математики не вырисовывают же квантор общности нигде, кроме как на доске, а пишут в TeX'е \forall. Ну и программисты на Хаскелле пишут forall, а при публикации статей\документации это превращается в квантор общности


<skip>

D>Определение бестипового лямбда-исчисления: две операции (аппликация и абстракция) и одно правило редукции (бета, ну можно ещё альфа-редукцию для практических целей). Это дает все исчисление. Типизация исчисления — это ещё несколько правил, порождающих чистую систему типов (PTS). Добавим сюда индуктивные типы (еще несколько правил) и получим уже систему типов, с которой можно жить. В том смысле, что у нас есть универсальное ядро, а все более высокоуровневые конструкции можно декларировать в терминах трансляции в это ядро. Причем заметь, процесс этой трансляции может верифицироваться ядром, как уже рабочей системой.


D>То есть Стандарт — не юридический текст на человеческом языке, а формальная система с формализованными (а значит верифицируемыми) синтаксисом и семантикой.


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


Вот хороший пример с ТеХ, насколько такие программы будут читабельны?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[12]: программирование будущего
От: deniok Россия  
Дата: 06.02.09 17:58
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Вот хороший пример с ТеХ, насколько такие программы будут читабельны?


Ты о чём? Мне писать удобней и быстрее
forall x . P x

А читать приятнее



Это все настолько эквивалентно, что нет совершенно никакой разницы как писать или читать. Транслируй в то представление, которое сегодня больше нравится и не переживай о читабельности.
Re[13]: программирование будущего
От: vdimas Россия  
Дата: 06.02.09 18:09
Оценка:
Здравствуйте, deniok, Вы писали:

V>>Вот хороший пример с ТеХ, насколько такие программы будут читабельны?


D>Ты о чём? Мне писать удобней и быстрее

D>
D>forall x . P x
D>

D>А читать приятнее

D>


D>Это все настолько эквивалентно, что нет совершенно никакой разницы как писать или читать. Транслируй в то представление, которое сегодня больше нравится и не переживай о читабельности.


Р должно что-то делать с типом (X x), т.е. X должен поддерживать некий контракт, который неплохо как-то продекларировать на уровне Р.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[14]: программирование будущего
От: deniok Россия  
Дата: 06.02.09 18:59
Оценка:
Здравствуйте, vdimas, Вы писали:

D>>


V>Р должно что-то делать с типом (X x), т.е. X должен поддерживать некий контракт, который неплохо как-то продекларировать на уровне Р.


Пока что это не более чем применение терма P к терму x, живущему под квантором общности. Чтобы придать этому какой-то специальный смысл надо определить исчисление, с которым идет работа. Например в Жирарда P будет конструктором типа с кайндом *->*.

Я к тому, что до деклараций контрактов и самого понятия контракта тут далековато. Пропозициональную логику высшего порядка построить можно, да.
Re[15]: программирование будущего
От: vdimas Россия  
Дата: 09.02.09 04:04
Оценка:
Здравствуйте, deniok, Вы писали:

D>Я к тому, что до деклараций контрактов и самого понятия контракта тут далековато.


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

Сдается мне, что нас интересует предпоследнее для фактической применимости в ЯП. Я напираю на контракт лишь потому, что скриптово-динамических языков и так уже хватает. Хочется каким-то образом получить свободу выражения выч.логики в рамках статической типизации. А это означает, что нам нужны ограничения на св-ва типов, то бишь определённого рода контракты.
Re[16]: программирование будущего
От: deniok Россия  
Дата: 09.02.09 14:05
Оценка:
Здравствуйте, vdimas, Вы писали:

V>- аксиомой

V>- условием
V>- операцией
V>- еще что-то

V>Сдается мне, что нас интересует предпоследнее для фактической применимости в ЯП. Я напираю на контракт лишь потому, что скриптово-динамических языков и так уже хватает. Хочется каким-то образом получить свободу выражения выч.логики в рамках статической типизации. А это означает, что нам нужны ограничения на св-ва типов, то бишь определённого рода контракты.


Ну так P x и есть применение P к x, то есть, иными словами, операция. Другое дело, что мы ещё не решили, какие зависимости допустимы. Например, P — терм, x — терм (банально); P — тип, x — тип (слабая лямбда омега, конструируемые типы) ; P — терм, x — тип (явный полиморфизм, то есть лямбда2); и, наконец, P — тип, x — терм (зависимые типы). И еще мы не решили можно ли задавать соответствующие лямбда-абстракции: \тип . тип, скажем.

А что такое "выч.логика" — я не очень понимаю. Если пытаться описать это понятие формально, то мы приходим к какой-то формальной логической системе. Вот как раз разные типизации лямбда-исчисления эквивалентны разным логическим системам. Скажем система лямбда2 эквивалентна пропозициональной логике второго порядка. И в ней можно много чего записать. Скажем, ex falso sequitar quodlibet, то есть "изо лжи следует что угодно". Вводим для обозначения лжи

и получаем

Здесь тип (правые скобки) — теорема, а лямбда-терм с этим типом (левые скобки) — ее конструктивное доказательство. (Если некоторый тип населён, то есть существуют термы с таким типом, то теорема, выраженная типом верна, то есть любой терм этого типа — доказательство).

Системы с зависимыми типами гораздо богаче, поскольку они позволяют выразить естественным образом различные логики предикатов, а не только пропозициональные.
Re[2]: программирование будущего
От: master_of_shadows Беларусь  
Дата: 23.02.09 10:08
Оценка:
Здравствуйте, Erop, Вы писали:

E>Заботай MAC OS X, в области Cocao, а MAC OS Classic в области AE... Там нечто очень похожее есть и уже много лет работает...


А можно хороших ссылок на обзоры/инфу о программирование под Cocoa в частоности и МакОсь в общем? Поиском то ли пользоваться не умею, то ли не везёт: всё время какие-то юзерские странички попадаются, не программерские.
Re: программирование будущего
От: Аем Вопля  
Дата: 27.02.09 20:17
Оценка:
То, что описал YoungPioneer — в принципе, и есть идеал программирования.

Собирать программы из частей как из конструктора — это же и есть идеал компонентной модели, — RAD, то к чему стремится .Net, .Java, объектно-ориентированное программирование вообще.

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

В некоторых конкретных случаях это уже сделано: библиотеки UI Control'ов, plug-in'ы, аудио- и видеофильтры от разных разработчиков (VST, DirectX), которые можно последовательно соединять, получая фильтры любой сложности, еще, наверно, можно найти много примеров.

Но в общем случае это невозможно, не существует соответствующего подхода.

Такой метод, позволяющий любые программы сводить к набору стандартных компонентов, легко соединяющихся друг с другом, несомненно, произвел бы революцию в программировании.
Re[2]: программирование будущего
От: Аем Вопля  
Дата: 27.02.09 20:18
Оценка:
То, что описал YoungPioneer — в принципе, и есть идеал программирования.

Собирать программы из частей как из конструктора — это же и есть идеал компонентной модели, — RAD, то к чему стремится .Net, .Java, объектно-ориентированное программирование вообще.

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

В некоторых конкретных случаях это уже сделано: библиотеки UI Control'ов, plug-in'ы, аудио- и видеофильтры от разных разработчиков (VST, DirectX), которые можно последовательно соединять, получая фильтры любой сложности, еще, наверно, можно найти много примеров.

Но в общем случае это невозможно, не существует соответствующего подхода.

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