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

WH>>Это ложь. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.

LVV>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл.
LVV>Глава 12. Пишем макросы. Страница 418.

Если мне не изменяет память, там можно было писать макросы на VB и extensions на .net

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

WH>>Это ложь. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.
LVV>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл.
LVV>Глава 12. Пишем макросы. Страница 418.
Это макросы внутри самой среды. API студии всегда доступен был через COM/.NET, так что расширения можно было хоть на ActivePerl писать (у меня парочка таких была).

Здравствуйте, Hobot Bobot, Вы писали:

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

WH>>>Это ложь. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.

LVV>>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл.
LVV>>Глава 12. Пишем макросы. Страница 418.

HB>Если мне не изменяет память, там можно было писать макросы на VB и extensions на .net
Да, вы правы. Макросы и надстройки различаются. У них два разных механизма и два разных языка.
И вот что интересно: с механизмом расширения разбирается практически сразу любой. Ибо — ПРОСТО. И единообразно.
А с механизмами расширения Студии — без специального изучения не обойтись.
Например, надо знать структуру надстройки...

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

LVV>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл.
LVV>Глава 12. Пишем макросы. Страница 418.
А интеграция немерла написанная на немерле мне приснилась.
https://github.com/rsdn/nemerle/downloads
Я тебя правильно понял?
Плюс если мне не изменяет склероз я когда в Парусе работал под 2003 расширения на .НЕТ писал. Под 2005 точно писал.
К остальному как я понимаю вопросов нет.

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

LVV>>Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл.
LVV>>Глава 12. Пишем макросы. Страница 418.
WH>А интеграция немерла написанная на немерле мне приснилась.
WH>https://github.com/rsdn/nemerle/downloads
WH>Я тебя правильно понял?
WH>Плюс если мне не изменяет склероз я когда в Парусе работал под 2003 расширения на .НЕТ писал. Под 2005 точно писал.
Я в соседнем ответе написал уже, что два механизма.
WH>К остальному как я понимаю вопросов нет.
Вопросов нет, ибо Блэкбоксовики перечисленных тобой траблов — НЕ ИМЕЮТ.
Не веришь — сходи на оберонский форум и поинтересуйся, как это они без всех тобой перечисленных проблем обходятся?

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

WH>>К остальному как я понимаю вопросов нет.
LVV>Вопросов нет, ибо Блэкбоксовики перечисленных тобой траблов — НЕ ИМЕЮТ.
Имеют.

LVV>Не веришь — сходи на оберонский форум и поинтересуйся, как это они без всех тобой перечисленных проблем обходятся? \
Да очень просто — не пишут чего-либо серьёзного.

Такой вот вид ленивого программирования.

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

LVV>Вопросов нет, ибо Блэкбоксовики перечисленных тобой траблов — НЕ ИМЕЮТ.
LVV>Не веришь — сходи на оберонский форум и поинтересуйся, как это они без всех тобой перечисленных проблем обходятся?
Это по тому, что в их блекбоксах крутятся только стандартные и их модули.
А если блекбокс довести до полноценной ОС и загрузить туда десятки программ от разных производителей начнется, то, что я написал.

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

U>Удаление открывающей скобки удаляет и закрывающюю. Я же говорю, emacs редактирует код на лиспе таким образом, что все скобки всегда сбалансированны.

Задам глупый вопрос. Как там выглядит перенос скобки с места на место?

(1 2 3 (4 5))

хочется превратить в

(1 2 (3 4 5))

оставляя скобки всегда сбалансированными. Перенос тройки не предлагать.

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

LVV>Фишка ББ в том, что любой модуль, написанный на компонентном паскале становится частью среды.
LVV>И его можно запускать и использовать совершенно так же, как и любой стандартный.
LVV>То есть компонентный паскаль — это не только язык программирования, но и внутренний язык развития системы.

Для построения динамической системы используется язык с полным отсутствием динамических возможностей. (Component Pascal, грубо говоря, по возможностям мало чем отличается от C.) Результат, как не трудно догадаться, получился плачевный. Мало того, что этот блэкбокс очень неудобно использовать как таковой, его возможности расширения не позволяют ему сделать тривиальных вещей, как например, автоматическая подсветка кода (epic fail оберонщиков, которые смогли написать для блэкбокса только полу-автоматическую подсветку, т.е. написал код, нажал на hotkey, код подсветился). Об более серьезных расширениях речи вообще идти не может.

Для сравнения, Emacs: написан по большой части на лиспе (elisp), расширяется через тот же лисп. Динамический язык и более грамотная архитектура emacs-а позволяет легко изменять любую часть этого редактора. Количество всяких расширений написанных для emacs-а поражает воображение. От простейших, до таких монстров, как cedet. ББ здесь и рядом не стоял. Более того в ББ нет ничего нового, что уже не было в emacs-е десятилетия назад.

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

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

U>>Удаление открывающей скобки удаляет и закрывающюю. Я же говорю, emacs редактирует код на лиспе таким образом, что все скобки всегда сбалансированны.

Z>Задам глупый вопрос. Как там выглядит перенос скобки с места на место?

Z>

Z>(1 2 3 (4 5))
Z>

Z>хочется превратить в
Z>

Z>(1 2 (3 4 5))
Z>

Z>оставляя скобки всегда сбалансированными. Перенос тройки не предлагать.

http://www.emacswiki.org/emacs/PareditCheatsheet

(1 2 3 (4| 5)) ; | — положение курсора

нажимаем C-(, C-M-left

(1 2 (3 4 5))

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

Ну то, что программа — это многомерная штука, и программируя в текстовых файлах, мы работаем с проекциями этой многомерной структуры на текст — это очевидно. Всякое АОП это как раз добавление размерностей к программному коду. Очевидно и то, что в будущем появятся более удобные способы манипулирования кодом. Но насчет языков вообще сложно что-то прогнозировать. Может взлететь какая-то совершенно темная лошадка, если её использование будет сильно удешевлять разработку. А может и сишарп еще 40 лет будем использовать как одно из самых выразительных средств (при условии что Хейлсберг продолжит его развивать, а майкрософт выложат в открытый доступ).

Имхо появится несколько программерских топовых инструментов, каждый из которых будет наиболее удобен для своей области применения (что-то для многопоточной обработки данных, что-то для client-side, что-то для алгоритмизации, что-то для метапрограммирования), которые будут между собой легко соединяться и без проблем взаимодействовать. А программистам останется лишь придумать архитектуру и на каждом уровне применить то, что больше подходит. Сейчас мы этот процесс уже наблюдаем, но в топы инструменты еще не вышли, и из-за этого взаимодействовать между собой не так просто. Когда останутся буквально 10-20 общепризнанных лучших инструментов, тогда и будет счастье: то, как спроектировать "несложную" систему типа ютьюба,- будут проходить на 2 курсе университета.

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

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

LVV>Я в соседнем ответе написал уже, что два механизма.

Механизм один, просто способы регистрации и стартапа разные. Причем не 2, а 3 — макросы, расширения и пакеты (и еще MEF-расширения в 2010). Но API самой студии там единое.

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

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

LVV>>Я в соседнем ответе написал уже, что два механизма.

AVK>Механизм один, просто способы регистрации и стартапа разные. Причем не 2, а 3 — макросы, расширения и пакеты (и еще MEF-расширения в 2010). Но API самой студии там единое.
Вот и я о том же...
Один простой-простой и ВСЕМИ понятый механизм или три, из которых как минимум два — не очень простых.

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

LVV>Один простой-простой и ВСЕМИ понятый механизм

Он вовсе не простой и решает разные задачи.