Почему нет? Какая компилятору разница в какой IDE его данные редактируют?
C>"IntelliSense" есть в Eclipse и IDEA, но внутри они реализованы сильно по-разному. И имеют заметно разную функциональность.
Дык как это на язык влияет? Компилятор должен каким то образом "рассказать" IDE о своих возможностях, а IDE должна этот "рассказ" понять и "решить" что из этих возможностей она может использовать. Именно язык для этого "разговора" и предполагается стандартизовать.
C>А ещё сейчас вспомню программы, типа CAD'ов, где вообще могут быть кардинально разные способы представления данных.
Не спорю. Но ведь можно заставить разные системы между собой "договориться". Если у них разные представления данных, это не значит, что их нельзя сконвертировать.
C>Я не вижу смысла делать программы, которые на 100% будут состоять из взаимозаменяемых кубиков. Это невозмонжо, да и не нужно.
Нужно это или не нужно сейчас определённо сказать нельзя. Только тогда, когда это будет возможно технологически можно будет понять как извлечь из этого прибыль. А сейчас хз. Для меня вот выглядит заманчиво.
Здравствуйте, Dufrenite, Вы писали:
C>>Неа. D>Почему нет? Какая компилятору разница в какой IDE его данные редактируют?
Компилятору — никакая. Я говорю про портирование модуля для того, что ты называешь "IntelliSense".
C>>"IntelliSense" есть в Eclipse и IDEA, но внутри они реализованы сильно по-разному. И имеют заметно разную функциональность. D>Дык как это на язык влияет? Компилятор должен каким то образом "рассказать" IDE о своих возможностях, а IDE должна этот "рассказ" понять и "решить" что из этих возможностей она может использовать. Именно язык для этого "разговора" и предполагается стандартизовать.
Ну вот стандартизуй систему для внутренного представления "IntelliSense". Чтобы я мог взять модуль поддержки Nemerle из VisualStudio и воткнуть его в Eclipse простым перетаскиванием мышки.
C>>А ещё сейчас вспомню программы, типа CAD'ов, где вообще могут быть кардинально разные способы представления данных. D>Не спорю. Но ведь можно заставить разные системы между собой "договориться". Если у них разные представления данных, это не значит, что их нельзя сконвертировать.
Можно. Вот у меня есть разреженная карта высот на 2Гб. А плугину нужна регулярная — при конвертировании она будет занимать 20Гб.
Упс.
C>>Я не вижу смысла делать программы, которые на 100% будут состоять из взаимозаменяемых кубиков. Это невозмонжо, да и не нужно. D>Нужно это или не нужно сейчас определённо сказать нельзя. Только тогда, когда это будет возможно технологически можно будет понять как извлечь из этого прибыль. А сейчас хз. Для меня вот выглядит заманчиво.
Это у тебя опыта мало.
Здравствуйте, 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>Это у тебя опыта мало.
Опыт не при чем здесь. Мы же не ТЗ составляем. Форум у нас про философию, вот я и пытаюсь по мере своих скромных способностей рассмотреть заинтересовавшую меня проблему.
T>>С теорией лучше, нес па? D>Зависит от задачи. Чаще всего хватает простого здравого смысла. Опять же, можно подменить реальное условие задачи, имеющее ценность для бизнеса, формулировками красивой теории. Была даже байка о применении сразу нескольких паттернов проектирования в десяти строчках кода.
Шаблоны — это не стройная теория.
D>Я не отрицаю полезность теоретических изысканий, но мой пойнт в том, что даже применение самой современной теории не гарантирует результата. Может оказаться так, что ты ухлопаешь кучу времени на реализацию сложной функциональности, а потом обнаружишь, что существует более простой путь, не предусмотренный теорией.
Выбор которого, обычно, аукается очень сильно.
Ты, как я понимаю, с применением "стройной теории" ничего никогда не писал?
(стройная теория — это что-то уровня хотя бы системы типов Хаскеля)
D>Я сам одно время занимался теоретическими исследованиями по высшей алгебре, но потом понял, что это просто никому не нужно. Между теорией и практикой в подавляющем большинстве случаев лежит пропасть непреодолимая.
Please, reconsider.
T>>А я не вижу никакого способа решить её, не применив функциональную декомпозицию или что нибудь подобное. D>Для решения этой задачи надо применять все известные виды декомпозиции, в том числе и функциональную.
Что подтверждает мои слова.
T>>Для стандартизации компонент типы нужны? Нужны. D>Безусловно. T>>Эффекты надо типизировать? Надо. D>И не только их.
Что ещё?
T>>Вот и пришли к системе типов с типизацией эффектов, самой простой из которых является Хаскельная. D>Хаскель, это чистый функциональный язык (если память не изменяет). Для большинства задач его возможности слишком бедны.
Ты утерял мысль. Мы не про возможности языка, а про систему типов. Вот в Хаскеле есть какая-никакая типизация эффектов.
А надо ещё круче.
Круче — это теория типов (зависимые типы, теория типов Мартина-Лофа).
Вот и пришли, что для реализации твоей (ну, не твоей) идеи необходимо смотреть в её сторону в обязательном порядке.
Вуаля!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Dufrenite, Вы писали:
D>Короче, ничего сложного. Все то же самое, только единый для всех стандарт и способ общения компонентов между собой. Вот от этого никуда.
Мда. Видимо, ты не понимаешь что я имею в виду. Вот у тебя есть язык — Java. Внутреннее представление в редакторе — это AST, который привязан к элементам в редакторе. Действия над AST отражаются в редактируемом тексте (и наоборот).
Так вот, этот AST — он зависит от языка. Для Nemerle дерево будет совсем иное. А уж про С++ я вообще молчу. А ещё нужно разбирать текст с ошибками и неполной информацией.
Вот так и получается, что общей в IDE будет только функциональность примитивного текстового редактора. Соответственно, плугины должны или всё остальное делать самостоятельно, или затачиваться под конкретную IDE.
D>Юзер: Ну не подходит так не подходит. Проверим другой.
Ну и вот такое будет в 99% случаев, если явно не писать и не тестировать плугины под конкретные программы.
C>>Это у тебя опыта мало. D>Опыт не при чем здесь. Мы же не ТЗ составляем. Форум у нас про философию, вот я и пытаюсь по мере своих скромных способностей рассмотреть заинтересовавшую меня проблему.
Опыт нужен, чтобы понять, что эту проблему просто решать не нужно.
Здравствуйте, Cyberax, Вы писали:
C>Вот у тебя есть язык — Java. Внутреннее представление в редакторе — это AST, который привязан к элементам в редакторе. Действия над AST отражаются в редактируемом тексте (и наоборот).
C>Так вот, этот AST — он зависит от языка. Для Nemerle дерево будет совсем иное. А уж про С++ я вообще молчу. А ещё нужно разбирать текст с ошибками и неполной информацией.
Что это меняет?
C>Вот так и получается, что общей в IDE будет только функциональность примитивного текстового редактора. Соответственно, плугины должны или всё остальное делать самостоятельно, или затачиваться под конкретную IDE.
А разве в современных IDE всё по другому происходит? Например рефактоингом Nemerle-кода занимается непосредственно студия или всё таки интеграция?
D>>Юзер: Ну не подходит так не подходит. Проверим другой. C>Ну и вот такое будет в 99% случаев, если явно не писать и не тестировать плугины под конкретные программы.
Это очевидно. Пару постов раньше: D>боюсь что задачка не для нынешнего технологического уровня
C>Опыт нужен, чтобы понять, что эту проблему просто решать не нужно.
Я решаю эту проблему просто как интересную теоретическую задачу. Я ничего не продаю и не предлагаю.
Здравствуйте, Dufrenite, Вы писали:
C>>Так вот, этот AST — он зависит от языка. Для Nemerle дерево будет совсем иное. А уж про С++ я вообще молчу. А ещё нужно разбирать текст с ошибками и неполной информацией. D>Что это меняет?
Всё.
C>>Вот так и получается, что общей в IDE будет только функциональность примитивного текстового редактора. Соответственно, плугины должны или всё остальное делать самостоятельно, или затачиваться под конкретную IDE. D>А разве в современных IDE всё по другому происходит? Например рефактоингом Nemerle-кода занимается непосредственно студия или всё таки интеграция?
Не совсем так. Скажем, в IntelliJ IDEA есть готовая архитектура для работы с AST языка, с поддержкой подсветки ошибок, транзакциями над AST и т.п. В Eclipse есть похожее, но другое.
Здравствуйте, Cyberax, Вы писали:
C>Не совсем так. Скажем, в IntelliJ IDEA есть готовая архитектура для работы с AST языка, с поддержкой подсветки ошибок, транзакциями над AST и т.п. В Eclipse есть похожее, но другое.
Это очевидно. Но мы же говорим о стандартизации. Вот здесь нюансы и появляются.
Здравствуйте, thesz, Вы писали:
T>Шаблоны — это не стройная теория.
По моему мнению, любая теория, это обобщение некоторого опыта. Имперического или умозрительного, сути не меняет. Шаблоны, это тоже обобщение опыта, а значит теория. Стройная или нет, хз. Надо дать определение стройности.
T>Выбор которого, обычно, аукается очень сильно.
T>Ты, как я понимаю, с применением "стройной теории" ничего никогда не писал?
T>(стройная теория — это что-то уровня хотя бы системы типов Хаскеля)
Вот тут то ты меня и поймал . Очень сложно найти программиста хоть раз писавшего что-то по строгой теории. Специфика-с.
T>Please, reconsider.
Уже не получится. Мне гораздо интереснее прикладные задачки решать.
T>Что подтверждает мои слова.
Я не говорил, что не согласен. Изначальная мысль о том, что функционального подхода недостаточно.
T>>>Эффекты надо типизировать? Надо. D>>И не только их.
T>Что ещё?
Для полноценного решения этой задачи вместе с компонентами должна каким то образом поставляться информация о предметной области, точнее о множестве предметных областей. Такого в современных программах просто нет, даже на уровне исходных кодов. Информацией о предметной области владеют только разработчики, а исполняющей системе попадает только то, что она может интерпретировать. Как эту задачу решить технически я не знаю.
T>>>Вот и пришли к системе типов с типизацией эффектов, самой простой из которых является Хаскельная. D>>Хаскель, это чистый функциональный язык (если память не изменяет). Для большинства задач его возможности слишком бедны.
T>Ты утерял мысль. Мы не про возможности языка, а про систему типов. Вот в Хаскеле есть какая-никакая типизация эффектов.
T>А надо ещё круче.
T>Круче — это теория типов (зависимые типы, теория типов Мартина-Лофа).
T>Вот и пришли, что для реализации твоей (ну, не твоей) идеи необходимо смотреть в её сторону в обязательном порядке.
T>Вуаля!
Возможно ты прав. Я не настолько знаком с теорией типов, чтобы на равных этот вопрос обсуждать. К сожалению, такие вещи изучается годами.
T>>Шаблоны — это не стройная теория. D>По моему мнению, любая теория, это обобщение некоторого опыта. Имперического или умозрительного, сути не меняет. Шаблоны, это тоже обобщение опыта, а значит теория. Стройная или нет, хз. Надо дать определение стройности.
Шаблоны, например, не имеют чёткой области определения. Это самое простое.
Поэтому их и пытаются запихнуть в ненужные места.
T>>Что подтверждает мои слова. D>Я не говорил, что не согласен. Изначальная мысль о том, что функционального подхода недостаточно.
По-моему, вполне достаточно. Вот здесь мы и расходимся.
T>>>>Эффекты надо типизировать? Надо. D>>>И не только их. T>>Что ещё? D>Для полноценного решения этой задачи вместе с компонентами должна каким то образом поставляться информация о предметной области, точнее о множестве предметных областей. Такого в современных программах просто нет, даже на уровне исходных кодов. Информацией о предметной области владеют только разработчики, а исполняющей системе попадает только то, что она может интерпретировать. Как эту задачу решить технически я не знаю.
Вот смотри.
Теория типов представляет собой конструктивную формализацию математики. В переводе на русский язык это означает, что любое доказательство существования какого-либо объекта в этой теории представляет собой алгоритм вычислений этого объекта, это раз (прилагательное "конструктивная"). Она может быть проверена или исполнена механически (существительное "формализация"), это два. Третье, и последнее, слово "математика" означает... Ну, например, то, что наверняка есть какая-либо теория под наши текущие нужды, остаётся только её отыскать и записать.
"Под текущие нужды" — это "для нашей предметной области".
Что ещё "нужно растущему организму"?
D>Возможно ты прав. Я не настолько знаком с теорией типов, чтобы на равных этот вопрос обсуждать. К сожалению, такие вещи изучается годами.
Да брось ты!
За полгода наблатыкаешься, будешь круче deniok о холоморфизмах рассуждать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Sinclair, Вы писали:
S>Без этого обсуждать идею имеет смысл не больше, чем мысль "вот пусть все граждане России скинутся мне по 50 копеек. Они ничего даже не заметят, а мне 60 миллионов рублей очень пригодятся".
А что, 10 лимонов ты себе на чай решил прибрать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, YoungPioneer, Вы писали:
YP>Просьба оценить идею:
Заботай MAC OS X, в области Cocao, а MAC OS Classic в области AE... Там нечто очень похожее есть и уже много лет работает...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, thesz, Вы писали:
T>Теория типов представляет собой конструктивную формализацию математики. В переводе на русский язык это означает, что любое доказательство существования какого-либо объекта в этой теории представляет собой алгоритм вычислений этого объекта, это раз (прилагательное "конструктивная"). Она может быть проверена или исполнена механически (существительное "формализация"), это два. Третье, и последнее, слово "математика" означает... Ну, например, то, что наверняка есть какая-либо теория под наши текущие нужды, остаётся только её отыскать и записать.
T>"Под текущие нужды" — это "для нашей предметной области".
T>Что ещё "нужно растущему организму"?
Интересно. Вполне возможно, что поможет в моих исследованиях.
T>Да брось ты!
T>За полгода наблатыкаешься, будешь круче deniok о холоморфизмах рассуждать.
Если не сложно, кинь ссылочку для начинающих. Буду холоморфизмами впечатление на девчОнок производить .
T>>За полгода наблатыкаешься, будешь круче deniok о холоморфизмах рассуждать. D>Если не сложно, кинь ссылочку для начинающих. Буду холоморфизмами впечатление на девчОнок производить .
Здравствуйте, YoungPioneer, Вы писали:
YP>Просьба оценить идею:
22 года назад малоизвестная фирма NeXT Inc. выпустила компьютер NeXT, за названием которого угадывалась аббревиатура New XT. в нём весь системный софт был написан на языке Objective C, главным отличием которого от C++ была возможность динамического диспатчинга вызова методов и благодаря этому — динамической загрузки реализации классов
компьютер был очень тепло встречен оборзевателями и полностью провалился на рынке. позднее идеи динамического связывания на уровне объектов перекочевали в яву, оберон, корбу и COM, а сама среда NeXTStep — в компьютеры Apple
Здравствуйте, thesz, Вы писали:
T>Для стандартизации компонент типы нужны? Нужны.
Вот тут и упираемся, ибо сами типыпринципиально зависят от подробности конкретной задачи. Другое дело, что давно витает в воздухе идея стандартизировать св-ва типов, дабы можно было обобщать алгоритмы, в С++ на шаблонах и в некоторых функциональных это где-то работает на наглядном синтаксическом уровне (хотя на неявном уровне, на уровне ошибок компиляции, если тип не имеет нужного члена, поля или метода). А на популярных .Net или Java даже банальное сложение через контракты выглядит убого и работает так же в плане эффективности.
Тут вот периодически пробегает человек, который разрабатывает некое единое семантическое представление программ, ИМХО, из области попыток решить этот вопрос.