Ричард Столлман хочет видеть некоторые возможности Eclipse реализованными в Emacs

> Мы под реверс-инженирингом понимаем одно и тоже? Анализ и декомпозицию исполняемого (байт)кода? Или подразумевалось "чтение исходников"?

Я второе понимал (в данной дискуссии). И, полагаю, не я один.

> в Emacs его изначально тоже нет, а через плагин он (вроде бы) есть и для Eclipse.

Я скорее про M-x, который в Имаксе есть всегда.

> Да путь подумают хотя бы о template

А-а-а!!! Не надо вот этого, а?!!

С уважением, Лёша, второй день описывающий грамматику в терминах boost::spirit

P.S. А CDT в разборе выхлопа из-под g++, выматерившегося на несоответствие типов в spirit-centric коде, не помогает, а скорее даже мешает, т.к. не умеет по-человечьи парсить g++'ный выхлоп. Впрочем, "по-человечьи" для g++'ного выхлопа - это в корне не верно, там как раз нечеловечий выхлоп... Впрочем, не будем о грустном, мир и так полон скорби...

Товарищи! Стране нужен МЕТАН. :)

> Вспоминаю тут чью-то историю с отлавливанием бага, из-за которого программа работала в Debug и крашилась в Release. Баг был отловлен параллельной пошаговой отладкой -00 и -O3 версии программы - это бы выход за границу массива, который проявлялся на девятом уровне вложенности. Программист получил премию в 50K $ за нахождение корня проблемы.

Слово называется valgrind? Нет, возможно, Вы удивитесь, но вот такие ошибки он отлавливает на ура.

P.S. Правда, премию в 50K баков мне за такое никогда не платили. Наверное, недостаточно хорошо изображал моральные и физические мучения в процессе ;-)

valgrind - тоже не панацея, я видел много ошибок, которые он не обнаруживал

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

На самом деле, конечно, "выход за границу массива" - это какой-то привет из 70х. Нонче ошибки уже куда как неуловимее и больнее ;-)

охххх - не надо о больном :-)

но выход за границу случается и сейчас, к сожалению

> но выход за границу случается и сейчас, к сожалению

Особенно забавно смотреть на сегфолт на команде prefetchnta, когда она по спеку никаких сегфолтов не генерит. Ан нет, кое-где генерит... ;)

>Угу. VS как дышала в попу Eclipse, так и до сих пор дышет.

Про Eclipse и VS. Актриса, ессесно, VS: http://jokes.sadovsky.org/index_066752_1.html

>как был UNIX-way так он и остаётся им. Это в MS каждый год революция.

Вы, кстати, заметили, что MS в ходе этих эволюционных революций все больше и больше напоминает Unix? :-) А Java, между прочим, С++...

>Мало чем поможет, если баг вызван определённой последовательностью данных, пришедшими по сети, и хорошо размазанными по времени :)

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

> Для особо упертых я привел выше определение отладки. Какое у вас определение?

Найденное в википедии? При отладке неприменным инструментом является отладчик, уж простите за тавтологию. У Вас же тестирование.

> При отладке неприменным инструментом является отладчик

Это не так. Для некоторых вещей отладчиков просто нет. Что, пока для ядра Линукс не появился отладчик, оно не отлаживалось?

> У Вас же тестирование.

Трудно провести между отладкой и тестированием четкую грань.

> Для того, чтобы прикрутить к emacs новый функционал, достаточно написать пару строк в конфигурационном файле.

А для этого потребуется обложиться кучей книг по elisp, man'a-ми, и и статьями про emacs и.т.д. Сколько времени на это уйдет?

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

Это если только внести изменения в существующий плагин, который, кстати совсем просто написать. Для нового, достаточно одной книги: "Расширения Eclipse. Принципы, шаблоны и подключаемые модули".

Да и не надо это в большинстве случаев. А вот в Emacs постоянно приходится что-то прикручивать самому, что "искаропки" есть в Eclipse.

> Трудно провести между отладкой и тестированием четкую грань.

Согласен, грань размыта (что подтвержтает ваша предыдущая фраза). И тем не менее, во фразе "unit testing" присутствует слово "testing".

> С уважением, Лёша, второй день описывающий грамматику в терминах boost::spirit

А вы stl используйте, и ждите C++ox без тех извращений что сейчас есть в boost. И будет счастье, но я имел в виду: std::cout << anything;

> В Eclipse встроен компилятор Java. А парсер CDT недалеко ушел от front-end компилятора.

1) Не надо смешивать синтаксический анализ и компиляцию.

2) CDT за каких-нибудь 5 лет прошел путь, который другие средства не осилили за 10-15 лет и продолжает развиваться (надеюсь в ближайшие 1-2 года в нем появится такой же Quick Fix, как и у JDT).

PS

Пожалуй единственный недостаток Eclipse - это выбор статически типизированного языка в качестве основного средства разработки. Emacs в этом смысле гораздо практичнее, но его концепция интерфейса проигрывает Eclipse (о чем собственно и задумался Столлман). Взяв современный CommonLisp с его CLOS, CELLS и прочими наработками реально создать совершенно термоядерную среду.

> Найденное в википедии? При отладке неприменным инструментом является отладчик, уж простите за тавтологию. У Вас же тестирование.

Нихрена себе понятия :-) так может ещё скажете что тест состоит из отладочных шагов а не отладка как процесс состоит из тестов и ещё кучи всего. Я уже раз пять подсказывал, что отладчик искажает картину во всех влучаях кроме анатомирования core. см. "микромир и наблюдатель". лог - основной инструмент отладки.

>> В Eclipse встроен компилятор Java. А парсер CDT недалеко ушел от front-end компилятора.

> 1) Не надо смешивать синтаксический анализ и компиляцию.

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

> 2) CDT за каких-нибудь 5 лет прошел путь, который другие средства не осилили за 10-15 лет и продолжает развиваться

Это да. Ждем CDT 5.0

> Пожалуй единственный недостаток Eclipse - это выбор статически типизированного языка в качестве основного средства разработки

.oO( не пофлеймить ли о том, что для больших проектов статика рулит, а динамика сосет? )

> Взяв современный CommonLisp с его CLOS, CELLS и прочими наработками реально создать совершенно термоядерную среду.

Ну так на JVM есть несколько Лиспов.

> Emacs в этом смысле гораздо практичнее, но его концепция интерфейса проигрывает Eclipse

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

> А для этого потребуется обложиться кучей книг по elisp, man'a-ми, и и статьями про emacs и.т.д. Сколько времени на это уйдет?

"Ах как бы так сделать чтобы ничего не делать но чтобы при этом всё делалось?"

Кухарка должна управлять ... (c)

Может мышкой программировать?

Вообще-то все IDE были написаны адкватными людьми, к вам это видимо не относится.

> Речь шла об ООП. На прологе же пишут knowledge-based системы, и выбор там между Прологом, и, скажем, CLIPS и OPS5. Где там переработка архитектуры - мне неведомо.

Ага расскажите это тем что erlang двигают. :-D

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

+1024. google delta debugging

> Ага расскажите это тем что erlang двигают. :-D

Причем Erlang к Прологу?

http://www.st.cs.uni-sb.de/Eclipse/

> Нет, это _использование_ объектных библиотек. Код вида:

> #include <iostream>

> void main() { for(int i=0;i<5;i++) std::cout << i; }

> процедурный, хоть и использует объект iostream.

А у меня код объектный. ООП может быть тонкостью реализации. Я же не говорю - обязан.

> можете ткнуть меня носом, не обижусь, но я в упор такого сказать не мог.

http://www.linux.org.ru/jump-message.jsp?msgid=2605754&cid=2609650

> по этому определению Emacs это IDE похлеще других - много ли IDE имеет такой же список поддерживаемых систем контроля версий как Emacs? это например? или список поддерживаемых отладчиков?

OK. Пусть будет IDE - дальше что? :)

> Давайте теперь попробуем найти хотя бы одно решение из реального мира, где бы не было завязки на язык?

Из свеженького - Hibernate (два языка), Lucene (десяток языков).

> Если удастся - надо понять какие плюсы получили авторы решения и какие минусы.

Какие плюсы понятно - более широкую область применения. На счёт минусов не знаю - в разработке не участвовал.

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

> с его помощью вам тяжело клепать блоатваре

не надо грязи - с помощью Emacs замечательно клепается блоатваре :D

> не надо грязи - с помощью Emacs замечательно клепается блоатваре :D

Так вот он, корень всех проблем! Запретить поганый Емакс и насильно пересадить их на пресвятой Эклипс, и сразу мировой коммунизм наступит!

>> не надо грязи - с помощью Emacs замечательно клепается блоатваре :D

> Так вот он, корень всех проблем!

Если тебе будет легче, скажу - с помощью Eclipse оно тоже клепается неплохо :)

> Запретить поганый Емакс и насильно пересадить их на пресвятой Эклипс

Ты увидел свет, брат!

:D

Lispers hate Eclipse as I do! :p

http://www.holygoat.co.uk/blog/entry/2008-03-25-1

> Ты увидел свет, брат! :D

Да. И явился ко мне святой IGNUcius и сказал, что выход из Church of Emacs только посмертно.

http://www.stallman.org/saintignucius.jpg

>> Ты увидел свет, брат! :D

> Да. И явился ко мне святой IGNUcius и сказал, что выход из Church of Emacs только посмертно.

Какой-то не тот свет ты увидел, ей-ей :)

> Кухарка должна управлять ... (c)

> Может мышкой программировать?

> Вообще-то все IDE были написаны адкватными людьми, к вам это видимо не относится.

Что здесь имелось ввиду я так и не понял.

> я просто не понимаю, в чем ваши претензии к емаксу

Много у меня было претензий к емаксу? Тред пошёл от того, что в Eclipse есть UML, а в емаксе его нету, ну потом и понеслось на тему кто такой отладчик.

http://cedet.sourceforge.net/cogre2.jpg - вполне себе UML, хоть и не такой красивый

> а ничего - люди на нем работают и довольны. те кто не доволен, те используют что-то другое.

Практика показывает что эти "работающие довольные люди" так же являются самыми воинствующими фанатиками.

> с его помощью вам тяжело клепать блоатваре, но это уже другая проблема.

Bloatware клепать можно на чем угодно, в.т.ч и на Emacs.

> http://cedet.sourceforge.net/cogre2.jpg - вполне себе UML, хоть и не такой красивый

Шикарный пример самой главной проблемы Emacs. Как я говорил, наследие 20-летней давности мешает нормально развивать программу.

Впрочем, это и не нужно. Для любителей "покастамизировать" под себя, есть jEdit.

> Для любителей "покастамизировать" под себя, есть jEdit.

Ещё notepad.exe скажите

что в вашем понимании нормально развивать? обвешивать побрякушками?

> что в вашем понимании нормально развивать? обвешивать побрякушками?

Пользоваться всеми преимуществами графического интерфейса (в данном случае).

> Ещё notepad.exe скажите

Сначала попробуйте jEdit, потом комментируйте.

> http://cedet.sourceforge.net/cogre2.jpg - вполне себе UML, хоть и не такой красивый

Где ж ты был 10 страниц назад? :D

> Шикарный пример самой главной проблемы Emacs. Как я говорил, наследие 20-летней давности мешает нормально развивать программу.

Сильно подозреваю, что это не проблема - если я нарисую UML диаграммку в Eclipse, она прочитается в emacs, ибо стандарт. Другое дело, что в эклипсе или в Ubrello у меня на экран влезет больше графов. Но это зависит от разрешения экрана :D

да я видимо пропустил это обсуждение. а вообще это нашлось первой ссылкой при поиске emacs uml

> Сначала попробуйте jEdit, потом комментируйте.

Сначала попробуйте Emacs, потом комментируйте