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

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

Мой опыт использования Emacs много превосходит ваш использования jEdit. ;)

> Мой опыт использования Emacs много превосходит ваш использования jEdit. ;)

Ну тогда объясните, почему я должен перейти на jedit?

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

Ну если речь зашла о связке CDT + boost - это очень хороший показатель для CDT. Та же MSVS очень сильно начинает сходить с ума, когда к ней попадает STL.


To mv (*) (25.03.2008 21:13:35):

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


To sv75 (*) (25.03.2008 21:54:18):

Может быть вы и правы. Спасибо вам за заботу.

> Насколько я слышал, в Гугле для реализации используются Си++ и Ява
> - каким образом их выбор мог повлиять на использование MapReduce,
> приема из ФП?

Что у них на самом деле происходит внутри знают только те, кто там внутри занимается этим вопросом. По информации от google.com (поисковика) используется haskel.

> Конечно, опыт работы с ФП может подсказать метафору MapReduce, но
> где здесь влияние _языка реализации_?

А отсутствие такового опыта может не подсказать нужную метафору - и система будет построена на несколько иных принципах.

> Поставим впрос по-другому: каким образом учитываются особенности
> языка реализации в OOA

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

2. Особенности языка накладывают на участвующего в анализе определенные шаблонные решения.

> Я вообще не вижу, как MapReduce уровня гугла хоть как-то
> ограничивает выбор языка. Это настолько высокоуровневая абстракция,
> что ни к какому языку не привязана никак.

Еще раз. Речь не об ограничении языка. Все языки у нас пока выполняются CPU и в конечном итоге достаточно родственны.

> ИМХО, метафоры и модули/классы - это продукты разных стадий
> разработки: OOA и OOD

Конечно разных. Вы ведь не будете утверждать что ООА происходит в отрыве от OOD, а OOD от OOP? Если будете, то как быть с итеративностью процесса?

> Она появляется после того, как написаны первые строки кода.

Ну мы ведь на этапах OOA и OOD не доходим еще до написания кода. Зависимость от языка на этапе OOP вполне понятна, хотя тоже не обязательна.

----------------

О чем я говорю - это о том что парадигма OOA -> OOD -> OOP и все независимо работает только в том случае, если язык реализации достаточно низкоуровневый. Собственно этап OOD -> OOP требуется для того чтобы создать промежуточный язык предметной области, на котором можно решать задачу в терминах задачи. Если у нас заведомо есть язык способный решать задачу в родных для нее терминах - то схема перестает работать.

Отсюда и влияние языка на этап ООА. В случае с низкоуровневым языком (C++/Java/C#/etc) мы пишем сначала систему для общения с машиной терминами задачи, а потом решаем задачу. В случае языка высокого уровня - мы решаем задачу в родных терминах сразу.

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

Умно сказано, понравилось, записал в цитатник.

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

Является ли это проблемой emacs - это большой вопрос. Emacs - система вполне себе состоявшаяся и судя по количеству сторонников справляющаяся с задачами перед ней стоящими (чего еще можно требовать от системы?).

Мне emacs кажется неудобным, с другой стороны когда-то и vim казался неудобным - потом стал привычным.

Мне доводилось работать с системами "развивашимися" по нескольку лет до того как я к ним приобщался. Зачастую авторов определенных решений уже бывает даже не найти и понять что имел ввиду автор определенных строк можно только проанализировав код (и часто бывает что автор вообще ничего ввиду не имел - метод банально нигде не вызывается) - тут хороши средства прозрачной навигации по проекту. У vim, eclipse, msvs, eclipse, vslick таковые инструменты есть и в разной степени развиты, но хочется лушче и выше, так вот CDT неплохо продвигается в данном направлении.

Лично мне по большому счету по барабану стрелочками ходить по коду или ctrl+буква надо ли нажимать i для того чтобы начать печатать и какими распальцовками можно, я даже отладчик отдельно запустить могу, а уж рисовать UML так вообще. Есть простой критерий: что мне может позволить определенная среда и что я должен сделать чтобы начать ей пользоваться. А тут:

1. MSVS - для работы с .NET - отлично все работает и нужно только лицензию иметь. Хотя требуется перезапускать ибо ресурсы утекают (2003/2005)

2. Eclipse - неудобный интерфейс, который в принципе настраивается и довольно неплохо умеет работать с C++, а уж с Java вообще весьма и весьма прилично. Требуется скачать, установить и настроить.

3. Vim - сел и работай, но для настройки средств навигации, дополнения (по исходникам) нужно вплагинивать, настраивать итд, а когда плагинов становится много, то интерфейс становится жутко неудобным. Потому vim для проектов из 10 - 20 файлов + простой makefile и плагины в топку.

4. Emacs - набирать текст я в нем умею :), make запускать, а в остальном такой толковой документации как vimtutor нет - да и оценить что же может emacs без человека, который хорошо в нем разбирается невозможно нет таких презенташек как у MSVS :).

> записал в цитатник.

Не забудьте проставить "c", лицензия BSD. :)

Да.. есть еще netbeans. Но C++ анализатор оного глухо умирает на вложенных namespace + бестолковый генератор makefile'ов, странное дерево проектов. Что понравилось в свежей beta - это автодополнение #include по мере использования библиотечных функций или классов.

> Ну тогда объясните, почему я должен перейти на jedit?

Я разве это утверждал?

> Лично мне по большому счету по барабану стрелочками ходить по коду или ctrl+буква надо ли нажимать i для того чтобы начать печатать и какими распальцовками можно, я даже отладчик отдельно запустить могу, а уж рисовать UML так вообще.

Как говорится, программировать надо головой, а не емаксом. По сему предлагаю выпить за дружбу Eclipse и emacs, благо Столлман тут где-то с нами согласен.

> Да.. есть еще netbeans.

Есть ещё Sun Studio, Kdevelop, Quanta+, Anjuta, Geany, Code::Blocks... :)

> Является ли это проблемой emacs - это большой вопрос

Конечно.

> Мне emacs кажется неудобным, с другой стороны когда-то и vim казался неудобным - потом стал привычным.

Так они реально неудобны. Как с теоретической (usability) так и с практической точки зрения.

> Лично мне по большому счету по барабану стрелочками ходить по коду и

Мне тоже. Тем не менее сторонники Emasc так не считают.

1. Не использовал. + ко всему, несвободна она. 2. Глупости. Самый удобный интерфейс из представленных редакторов/IDE. 3. Режимы и костыли. 4. Костыли и пренебрежительное отношение к GUI.

>> Насколько я слышал, в Гугле для реализации используются Си++ и Ява - каким образом их выбор мог повлиять на использование MapReduce, приема из ФП?

> Что у них на самом деле происходит внутри знают только те, кто там внутри занимается этим вопросом.

И они не молчат - говорят о Яве и Си++, PR-служба Гугла добавляет еще и Python.

> По информации от google.com (поисковика) используется haskel.

Пруфлинк?

>> Конечно, опыт работы с ФП может подсказать метафору MapReduce, но где здесь влияние _языка реализации_?

> А отсутствие такового опыта может не подсказать нужную метафору - и система будет построена на несколько иных принципах.

Конечно. Но язык _реализации_ здесь ни при чем - можно иметь опыт в ФП, проектировать для Си++ и _всё равно_ использовать MapReduce, потому что на таком уровне определенный MapReduce можно реализовать на любом языке без потерь - так же, как map-reduce в Лиспе или Питоне реализуется Си-кодом.

>> ИМХО, метафоры и модули/классы - это продукты разных стадий разработки: OOA и OOD

> Конечно разных. Вы ведь не будете утверждать что ООА происходит в отрыве от OOD, а OOD от OOP?

Не буду. Но на результаты OOA язык не влияет по простой причине - OOA анализирует предметную область. OOD и OOP просто выявляют недоработки OOA.

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

> О чем я говорю - это о том что парадигма OOA -> OOD -> OOP и все независимо работает только в том случае, если язык реализации достаточно низкоуровневый.

Они могут работать независимо, поскольку by design рассчитаны на объектно-ориентированные языки.

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

Ничего подобного. OOA и OOD появились, когда доминирующего ООП-языка не было вообще: народ писал на чистом Си, Си++, Аде, CLOS, Smalltalk - примеры в книге Буча не просто так приведены.

> Как говорится, программировать надо головой, а не емаксом. По сему предлагаю выпить за дружбу Eclipse и emacs,

emacs пользователи не согласятся.

> благо Столлман тут где-то с нами согласен.

Конечно, это же свободный софт. Помню, на последней его лекции прошедшей недавно в России он одному парню (при мне) дал автограф на распечатке мануала по Vim. :) (Сначала, правда, смутился. Потом, со словами "Well... It's free software." - согласился).

> 2. Глупости. Самый удобный интерфейс из представленных редакторов/IDE.

Медленно работает.

ну а вот что мне делать с вашим гуи, если мне надо писать код на машине, которая находится за несколькими firewall's и X forwarding отсутствует как класс?

емакс (и vim) это нормально обрабатывают, при этом весь функционал (практически) остается доступным

Щас тебе мешок плагинов насоветуют. Ни один, правда, полностью не работает, но если всеми по-очереди пользоваться, то нормально ;) А, да, памятишки ещё два гига докинуть надо будет. Как слоты кончились? Требуй серверную материнку!

> Щас тебе мешок плагинов насоветуют. Ни один, правда, полностью не работает, но если всеми по-очереди пользоваться, то нормально ;) А, да, памятишки ещё два гига докинуть надо будет.

Советовать будешь ты, похоже.

Советовать? Отту? Я?

> Советовать?

Ога. Ты уже это фактически сделал :D

> Отту? Я?

.oO( кто такой Отт и почему простые смертные не могут дать ему совет? O_o )

> .oO( кто такой Отт и почему простые смертные не могут дать ему совет? O_o )

Отт - это человек-полубог. Говорят, что ночью можно увидеть сияние его ауры. Не такая мощная, как у святого IGNUcious'а, конечно, но всё равно советы давать негоже...

:-D

> .oO( кто такой Отт и почему простые смертные не могут дать ему совет? O_o )

Вот один из примеров: заболел Алекс Отт, и у нас почти за тыщу километров уже вторую неделю каждый день снег падает. Начал, вроде, выздоравливать, и снег не так активно валит.

:-D

>> .oO( кто такой Отт и почему простые смертные не могут дать ему совет? O_o )

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

/me на всякий случай кланяется ott

> /me на всякий случай кланяется ott

А ещё я по секрету скажу, что на очень жирных плюсатых файлах Емакс начинает подтормаживать :) У меня за всю практику, правда, такой всего один был, когда портировал одно конторское поделие с BCB на gcc и линукс. По старой доброй привычке, всё было реализовано в одном файле.

>> даже такая обычная по нынешним меркам вещь, как подсветка синтаксиса в эклипсе похожа на полуфабрикат

>Этот полуфабрикат много лучше чем в хваленых emacs и vim. Очень много. Те вообще по сравнению с Eclipse в этом плане ничего не умеют.

Нет, МОЙ папа побьет твоего папу.

http://dima-exe.ru/the-effective-emacs-translation

Emacs—лучший в мире текстовый редактор. Он лучший не только для редактирования исходников программ, он лучший для любого редактирования текста.

Остальным: Я думаю ваш Eclipse наконец загрузился и вы теперь можете вернуться к работе.

>http://dima-exe.ru/the-effective-emacs-translation

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

Красиво сказано)

>http://dima-exe.ru/assets/2007/4/1/01.png

че за шрифт?

Looks like Consolas (by Microsoft)

> ну а вот что мне делать с вашим гуи, если мне надо писать код на машине, которая находится за несколькими firewall's и X forwarding отсутствует как класс?

Eclipse Remote system access.

Ну и чтоб два раза не вставать - линк:

http://download.eclipse.org/dsdp/tm/downloads/

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

>>http://dima-exe.ru/assets/2007/4/1/01.png

>че за шрифт?

Линуксовое субпиксельное не пригодно для применения на цветах фона отличных от белого. (

Теоретически да - SSH же никто не отменял. Но это уже не будет интегрировано в среду.

Впрочем, задачка из разряда "доктор, если я делаю вот так - у меня вот тут болит".

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

>>> Конечно, опыт работы с ФП может подсказать метафору MapReduce, но где здесь влияние _языка реализации_?

>> А отсутствие такового опыта может не подсказать нужную метафору - и система будет построена на несколько иных принципах.

>Конечно. Но язык _реализации_ здесь ни при чем - можно иметь опыт в ФП, проектировать для Си++ и _всё равно_ использовать MapReduce, потому что на таком уровне определенный MapReduce можно реализовать на любом языке без потерь - так же, как map-reduce в Лиспе или Питоне реализуется Си-кодом.

Более того, для Qt MapReduce реализован в компоненте QtConcurrent, а на Ruby - в 36 строчках http://romeda.org/blog/2007/04/mapreduce-in-36-lines-of-ruby.html

Но про метафору -- верно.

> ну почему же?

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

ну это у тебя нет емакса под виндами, а у меня он есть

а насчет удаленной разработки - у многих юниксовых программистов такая ситуация встречается

> а насчет удаленной разработки - у многих юниксовых программистов такая ситуация встречается

Рад за них. А у меня гораздо чаще встречается задача по разработке UML диаграмм.

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

Если переходим на конкретные итерации, то давайте уж перейдем и на конкретный проект. :).

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

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

Лично я всегда считал наоборот - преимущество емакса перед другими приложениями - это работа со всеми объектами как с текстом (хотя изображения emacs тоже прекрасно показывает).

> Например, интерфейс в LiveJournal кракозябрил при редакторовании старых записей.

Кстати это fixed. Только ненадо говорить "не прошло и года", оно не фиксилось потомучто просто никому ненадо было, комуто понадобилось - пофиксили.

На заголовок новости и на саму новость так и хочется ответить - компилятор и флаг ему в руки.

сходил по ссылке. с первых строк первое впечатление подтвердилось

http://www.linux.org.ru/view-message.jsp?msgid=2513634&lastmod=1206733097...

RIP

Покойся с миром

Ну наконец-то, не прошло и года!

Да нах*й нужен ваш emacs. Дебильный интерфейс, кривой шрифт и прочие радости. И хелп - это п*здец, несколько десятков страниц описывают как заменять мышь и стрелки комбинациями клавиш. Браво! Апплодисменты! Похоже, Emacs создал какой-то однорукий дебил, которой никак не мог дотянуться до стрелок. Если захочешь что-нибудь изменить в emacs - ищи нужную строчку конфигурации среди тысяч, а лучше сразу учи второй язык - Lisp. Короче, ебитесь сами со своим емаксом.

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

Хе... Ребенку показали серьезный инструмент, он не справился и обиженно заплакал! :)))

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

Реально таких красивых и законченных программ я больше не встречал.

А я выбрал Kate. Самый-самый оптимальный редактор, особенно для небольших программ и веб-девелопинга. И возможностей много, и осваивать годами не нужно. Емаксы с Еклипсами идут в биореактор - первый уж очень древний и примитивненький по интерфейсу, был написан еще при динозаврах, а второй сам как динозавр.

> Реально таких красивых и законченных программ я больше не встречал.

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