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

> Методология - метаалгоритм?! :-D

Странная лемма )))

Методология (в общем) - наука о методах.

> Нет. "Объекто-ориентированное проектирование с примерами применения", более ранняя (и более полная) книга.

Нет, не читал.

> Это уровень кодирования, а не проектирования. При желании, мультиметоды можно сделать и в Си++

При желании можно и на ассемблере всё писать (в конечном коде всё равно маш.код получается ;) А вот статическая типизация в C++ и динамическая в Smalltalk/CLOS никаких особенностей на проектирование не накладывает? Всё равно по одной бумажке с чётким перечнем действий (aka методика) можно ваять программу?

После такого ответа об уважении к вам речи быть не может. И проблемы это разумеется ваши.

> В цивилизованном мире большее распространение вместо термина "программирование" получил термин "computer science".

А это два _разных_ термина. У них разное содержание.

> Какая такая единая методика может объединять процесс разработки на этих языках? Если можно, то по шагам.

По шагам мы далеко не уйдем. Методики в первую очередь проектирования - нисходящее, восходящее, объектное.

> Например, если в C++ нет дженериков, то шага "создайте мультиметод" для него быть не может.

Это частные способы решения задачи. Вы ведь не будете утверждать что и C и Pascal - это разные методологии программирования, потому что в C нет оператора степени? Разница в синтактсических конструкциях даже не позволяет говорить о разнице методик. )) Только об удобстве реализации конкретной методики.

> А я на вас и не наезжал в своём ответе.

Разумеется у меня и в мыслях не было что вы на меня наезжали. Меня удивило что такой комментарий был ответом мне.

О ваших работах я поинтересовался, т.к. вы в другом трэде этот вопрос проигнорировали. Мне действительно интересно узнать что же за проекты вы разрабатываете, для которых в принципе не подохдит работа в IDE, но подходит работа в emacs. Не может же ваше мнение быть результатом привычки? У вас ведь наверняка есть объективные причины ругать те решения, которыми вы не пользуетесь.

> Всё равно по одной бумажке с чётким перечнем действий (aka методика) можно ваять программу?

В принципе - да. Инструмент, выбранный для решения, влияет лишь на трудозатраты.

Только методика - это не _четкий_ перечень действий (это определение скорее алгоритма), а _обобщенный_ способ решения как правило какого-либо типа/класса задач. Для каждой конкретной задачи методика будет развертываться в разные действия.

> Методики в первую очередь проектирования - нисходящее, восходящее, объектное.

Ну так всё-таки ООП - это метод проектирования или метод производства (технология)?

> Это частные способы решения задачи. Вы ведь не будете утверждать что и C и Pascal - это разные методологии программирования, потому что в C нет оператора степени? Разница в синтактсических конструкциях даже не позволяет говорить о разнице методик. )) Только об удобстве реализации конкретной методики.

В C есть рантаймовый эквивалент для возведения в степень - функция pow. Какой рантаймовый эквивалент есть в C++ для реализации мультиметодов? Нужно добавить новую специализацию в мультиметод, как это сделать?

> В принципе - да. Инструмент, выбранный для решения, влияет лишь на трудозатраты.

Под такой итог что угодно можно подвести. Любая работа - способ получения результата :)

> Только методика - это не _четкий_ перечень действий (это определение скорее алгоритма), а _обобщенный_ способ решения как правило какого-либо типа/класса задач. Для каждой конкретной задачи методика будет развертываться в разные действия.

Ладно, допустим. Пусть ООП будет технологией ;) Но в моём понимании (инженера, не CS) технология гораздо ближе к перечню, а не к идее.

> А вот статическая типизация в C++ и динамическая в Smalltalk/CLOS никаких особенностей на проектирование не накладывает?

Уффф... давно я не брал в руки шашек :) Итак, OOA - дает на выходе абстракции предметной области; OOD - дает диаграмму классов; OOP - готовую программную систему. Где место для учета особенностей языка? Поскольку процесс итеративный, то оно между OOD и OOP - прогеры смотрят на классы и говорят "вот эту фигню мы можем забубенить короче и изящнее с использованием мультиметодов, а вот эти параметризуемые типы нам ваще нинужны, ибо динамическая типизация".

Как-то так :)

> Всё равно по одной бумажке с чётким перечнем действий (aka методика) можно ваять программу?

Можно и так. Все ОО-языки поддерживают некоторое (широкое) общее подмножество.

> Ну так всё-таки ООП - это метод проектирования или метод производства (технология)?

Я немного влезу - это всё-таки и то и другое. Потому как производство программы есть её проектировании и её реализация.

> О ваших работах я поинтересовался, т.к. вы в другом трэде этот вопрос проигнорировали. Мне действительно интересно узнать что же за проекты вы разрабатываете, для которых в принципе не подохдит работа в IDE, но подходит работа в emacs.

Я вопрос в такой разрез не ставил, между прочим.

Для моей работы, за которую платят деньги, больше подходят systemtap и crash. Я не знаю, на сколько полно интегрирован Eclipse с этими утилитами, но Емакс там не нужен ;) Для работы, за которую деньги не платят, лучше slime что-то придумать сложно.

> Не может же ваше мнение быть результатом привычки? У вас ведь наверняка есть объективные причины ругать те решения, которыми вы не пользуетесь.

А что именно я ругал? :)

> Я немного влезу - это всё-таки и то и другое. Потому как производство программы есть её проектировании и её реализация.

Хорошо. Раз ООП запихнули в список к технологиям, пусть подразумевался аспект реализации. Хотя, по-моему мнению, ООП - это атрибут именно проектирования, а не тонкости реализации.

Ок, все на конях остались ;)

> Хотя, по-моему мнению, ООП - это атрибут именно проектирования, а не тонкости реализации.

Ну когда вы конкретно на клавиатуре пишете QWidget.mainprogressbar.setValue(mainprogress); - это вполне себе ООП, и вполне себе реализация того, что в проекте было - "связать отображение прогрессбара mainprogressbar с переменной mainprogress".

Не дописал :)

И соответственно, первое - реализация, второе - проект. И то и другое - ООП.

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

Интересно на чем такая огромная экономия? Случайно не на открытии и создании файлов? А теперь почешите репу и посчитайте сколько времени уходит на переименование переменой, преобразование блока в функцию и прочие преобразования кода. А сколько уходит времени на циклы компиляция /исправление синтаксических ошибок?

Так вот, что я вам скажу дорогой хакер - не ровняйте Eclipse c BC, BCB, VS! Эта среда не просто раскрашивает, а понимает код!

> Под такой итог что угодно можно подвести. Любая работа - способ получения результата :)

Нет, любая _правильно направленная_ работа - способ получения результата. Выкапывание и закапывание одного и того же квадратного метра земли не создаст траншею. )) Основная фишка именно в организации и выборе направления работы ))

> Но в моём понимании (инженера, не CS) технология гораздо ближе к перечню, а не к идее.

Именно по этому лично я пользуюсь термином "методика" ))

> Где место для учета особенностей языка?

ООА - то самое место. В зависимости от возможностей языка (скорее даже особенностей) можно архитектуру "развернуть" на 180 градусов. То есть те сущности которые могли бы производить какие-либо действия в варианте 1, становятся теми, над кем действия производятся и наоборот. А может получиться что вообще нет действий, а есть рекоммендации (EDA). А в результате может оказаться что конечно решение может быть либо проще значительно, либо наоборот черезмерно переусложнено.

Предметную область можно выражать поразительно различными абстракциями и разные языки накладывают на архитектора разные шаблоны мышления.

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

Именно так

>> Где место для учета особенностей языка?

> ООА - то самое место

Позволю себе не согласится. Аналитик может не знать языка программирования, язык может быть даже не выбран еще.

> зависимости от возможностей языка (скорее даже особенностей) можно архитектуру "развернуть" на 180 градусов.

В это я просто не верю. Пример таких языковых возможностей можно?

>Это все, конечно, хорошо, но сколько времени нужно программеру чтобы освоить все эти функции и настроить
редактор под себя, попутно выучив ФП и elisp? Несколько лет? Видел программеров, которые сидят в емаксе и даже не знают что такое ecb.

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

Например - появление окошка со всеми символами кодировки: 

;; print an ascii table
(defun ascii-table ()
  (interactive)
  (switch-to-buffer "*ASCII*")
  (erase-buffer)
  (insert (format "ASCII characters up to number %d.\n" 254))
  (let ((i 0))
    (while (< i 254)
      (setq i (+ i 1))
      (insert (format "%4d %c\n" i i))))
  (beginning-of-buffer))

Взято с http://www.postulate.org/emacs.php

> когда вы конкретно на клавиатуре пишете QWidget.mainprogressbar.setValue(mainprogress); - это вполне себе ООП

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

#include <iostream>

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

процедурный, хоть и использует объект iostream. Так что тут прав mv: ООП - это атрибут именно проектирования, а не тонкости реализации.

> Может мне напомнить "отладка==установка точек останова" (С) alx_me ?

Чтото мне плохо стало, это у меня маразм или у вас? Если не трудно прочитайте мои реплики заново, можете ткнуть меня носом, не обижусь, но я в упор такого сказать не мог.

> Ну так всё-таки ООП - это метод проектирования или метод производства (технология)?

Полностью согласен с Aceler (*) (25.03.2008 19:07:37)

> не ровняйте Eclipse c BC, BCB, VS! Эта среда не просто раскрашивает, а понимает код!

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

Или вы снова демонизируете разработчиков Eclipse? ;-) В BCB тоже есть ~prelinked headers.

> В это я просто не верю. Пример таких языковых возможностей можно?

Повторюсь, prolog это то для чего вам нужно архитектуру вывернуть наизнанку. :-)

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

Разумеется. Я его так поставил. Чтобы вы смогли более точно выразить свою позицию.

> Я не знаю, на сколько полно интегрирован Eclipse с этими утилитами,
> но Емакс там не нужен ;)

Для systemtap есть среда на eclipse сделаная хотя я ее не пробовал :).

Если ваша профессиональная область настолько специфична - мне вдвойне не понятены ваши комментарии о слоях абстракции.

> А что именно я ругал? :)

kdevelop, anjuta, eclipse + могу ошибаться, но msvs

>> не ровняйте Eclipse c BC, BCB, VS! Эта среда не просто раскрашивает, а понимает код!

> Начнём с того, что понимает код только компилятор.

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

>> В это я просто не верю. Пример таких языковых возможностей можно?

> Повторюсь, prolog это то для чего вам нужно архитектуру вывернуть наизнанку. :-)

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

> Для systemtap есть среда на eclipse сделаная хотя я ее не пробовал :).

Честно говоря, не могу представить такую интеграцию (про то, что подсветка синтаксиса не является достаточным атрибутом IDE даже Aceler высказался).

> Если ваша профессиональная область настолько специфична - мне вдвойне не понятены ваши комментарии о слоях абстракции.

Не вижу никаких противоречий. Я стараюсь иметь как можно более широкий кругозор.

> kdevelop, anjuta, eclipse + могу ошибаться, но msvs

В этом треде я вообще ничего не трогал ;) Если где-то в другом месте ругал, то вполне обоснованно.

>> Для systemtap есть среда на eclipse сделаная хотя я ее не пробовал :).

> Честно говоря, не могу представить такую интеграцию

Systemtap - это тот самый трассировщик ядра с мордой на Яве? 8)

> Позволю себе не согласится. Аналитик может не знать языка
> программирования, язык может быть даже не выбран еще.

Теоритически может. Практически не желаю никому сталкиваться с таким аналитиком. По крайней мере без дублёра, хуже понимающего предметную, но хорошо ориентирующегося в архитектуре (т.е. архитектора).

> В это я просто не верю. Пример таких языковых возможностей можно?

Примеров довольно много может быть. Из какой области?

>> Позволю себе не согласится. Аналитик может не знать языка программирования, язык может быть даже не выбран еще.

>Теоритически может. Практически не желаю никому сталкиваться с таким аналитиком.

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

> Примеров довольно много может быть. Из какой области?

Из любой, да побольше 8)

> Не вижу никаких противоречий. Я стараюсь иметь как можно более
> широкий кругозор.

Забавно что вы позволили себе критиковать мое понимание этих вопросов.

> В этом треде я вообще ничего не трогал ;)

Кроме творений столмана. И чем они вам не понравились?

> Если где-то в другом месте ругал, то вполне обоснованно.

Гм. Ладно. Кто старое помянет...

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

Вот например:
http://labs.google.com/papers/mapreduce.html

> Вот например:

> http://labs.google.com/papers/mapreduce.html

Где там зависимость от языка? O_o Это могло быть реализовано на любом языке или их смеси.

>В это я просто не верю. Пример таких языковых возможностей можно?

Попробую пальцем в небо :)

Java vs C# с точки зрения доступа к БД.

В Java мы можем решить использовать, скажем, Hibernate. Получаем автоматом ленивую подгрузку коллекций и связанных объектов. Грузим сущность, а потом бегаем по ссылкам сколько хочется.

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

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

> Где там зависимость от языка? O_o Это могло быть реализовано на
> любом языке или их смеси.

Эээ... кто-то из нас потерял ход обсуждения. Речь была не о том что на каком-то языке что-то сделать нельзя, а о том что выбор языка значительно влияет на архитектуру приложения. То есть влияет на то что именно _нужно_ будет получить на выходе.

1. набор каких метафор
2. набор каких модулей
3. набор каких классов

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

MapReduce - значительно меняет терминологию работы с данными (считай что метафоры стали другими).

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

> Java vs C# с точки зрения доступа к БД.

> В Java мы можем решить использовать, скажем, Hibernate. Получаем [...]

> А в C# целесообразней было бы использование, скажем, LINQ

Это не вопрос OOA - это деталь реализации :)

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

Да понятное дело, но 1) eXOR замахнулся даже не на проектирование, а на анализ; 2) я же не спорю с тем, что вообще всё можно завязать на используемый язык - можно, но по разным причинам учебники это не рекомендуют.

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

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

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

Аналогия такая - механизм работы компилятора C++ не зависит от того в инструкции какого процессора он компилирует (подтверждение см. gcc).

> Да понятное дело, но 1) eXOR замахнулся даже не на проектирование,
> а на анализ;

Процесс у нас итеративный, а потому анализ бывает даже на этапе установки на платформу заказчика - так? :).

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

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

> Забавно что вы позволили себе критиковать мое понимание этих вопросов.

А что забавного? И почему я не могу позволить себе критиковать?

> Кроме творений столмана. И чем они вам не понравились?

Мне??

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

Потому что:
1. мы не знакомы, а вам не известно что я знаю, а чего нет.
2. это не ваша специализация.

>> Кроме творений столмана. И чем они вам не понравились?
>Мне??

Ок. Значит вы и этого ввиду не имели.

> Эээ... кто-то из нас потерял ход обсуждения.

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

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

>1. набор каких метафор

>2. набор каких модулей

>3. набор каких классов

ИМХО, метафоры и модули/классы - это продукты разных стадий разработки: OOA и OOD, причем на набор метафор может повлиять уйма факторов, от жизненного опыта до полученного образования. Конечно, опыт работы с ФП может подсказать метафору MapReduce, но где здесь влияние _языка реализации_?

Поставим впрос по-другому: каким образом учитываются особенности языка реализации в OOA? Это ограничивает возможности эффективной реализации на другом языке?

Да, и хотелось бы всё же пример, когда реальная особенность целевого языка повлияла на результаты OOA - с MapReduce не катит, потому что MapReduce - это не особенность целевого языка.

> Выбирают mapreduce в связке с языком для которого такое решение было бы максимально родственным

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

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

Зависимость _чего_? Проекта? Она появляется после того, как написаны первые строки кода. Результатов OOA? При желании можно сделать, но можно и не делать.

Пример с компилятором Си++ ниасилил - он вообще что должен был доказать?

> 1. мы не знакомы, а вам не известно что я знаю, а чего нет.

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

> 2. это не ваша специализация.

Вы, наверное, из тех, кто считает, что программирование придумали программисты?

> Ок. Значит вы и этого ввиду не имели.

А что ВЫ имеете в виду? Я вижу, что вы несёте несвязанный бред, т.к. ни на Столлмэна, ни на его продукты я не наезжал. Если вы увидели противоположное, то покажите хотя бы ссылки на мои ответы, которые показались вам агрессивными по отношению к Столлмэну и его продуктам.

>> Реверс-инжиниринг кода с построением UML -- это вообще бредни, модные некогда.

> Можно на такое пруфлинк? Ибо UML не видел. Вот граф вызовов - это да. И совсем не бредни, весьма полезная штука для реверса.

Ну к примеру: http://www.linuxdevices.com/news/NS5840286073.html

Оно?

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

Hint: объяснять все "юношеским максимализмом" вместо аргументов == переход на личности

Так что теперь -- получите.

> Ну к примеру: .... Оно?

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

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

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