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[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[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[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[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>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.