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

Что за софт? Браузеры на Perl пишешь?

Не, не впечатляет меня всё это. При ровно том же уровне компетентности на Tcl народ не хуже вещи делал, и столь же быстро.

> У тебя есть некая структура с дестью полями и такаяже + одно поле. Как будешь сохранять их в БД?

В упор не вижу трудностей. Поддержка структур совершенно отдельна от ORM, так что ORM про то, что одна есть потомок другой ничего не знает - если ему этого не сказать явно.

> Дык твой лишний узел и есть костыль ;-)

Вовсе нет. Простые структуры данных - лучше, чем сложные правила. Lisp way, так сказать.

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

А, думал это про ленивое чтение структур. Нет, поля читаются в один запрос, как и простейшие случаи one-to-many.

> Во что ты складываешь большие массивы бинарных данных? ;-)

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

>Кстати, Azureus, как запустится, работает неотличимо от нативной проги, но вот грузится (не VM, а именно сам Azureus - он прогрессбар рисует в процессе) что-то уж больно долго.

yahoo.eu Ты его что, постоянно закрываешь и грузишь, потом грузишь и закрываешь и опять запускаешь? Azureus вообще-то deamon-style прога, типа сервиса

> У меня 2 года опыта разработки фронтэндов к БД на VB. В 1999-2000,
> когда современная джава только начиналась, ВБ уже всё что надо умел.
> И умел неплохо. Другое дело, что "шаг в сторону - расстрел на месте",
> но мало кто хотел этот шаг совершать. Из VB было доступно всё: базы
> данных, все средства оффиса, куча сторонних компонентов, ДиректИкс
> для любителей

Угу... с веб-страницами там что было? (вопрос риторический - я это
помню, у самого по VB с тех времен сертификат от MS лежит ;)

Вообще в VB была просто масса граблей. Та же работа с файлами.
Отсутствие нормального API для работы с графикой (что-то серьезное -
лезем в GDI). Вообще, пользоваться системным API по каждому чиху
(теряя, естетственно, всю "простоту" языка) там было нормой...

Кстати, известный глюк в предлагаемом инсталлере для VB-софта (на VB же
и написаном), который валился, если локаль в системе была не-US и
неевропейская - помнишь? =)

>> У тебя есть некая структура с дестью полями и такаяже + одно поле. Как будешь сохранять их в БД?

>В упор не вижу трудностей. Поддержка структур совершенно отдельна от ORM, так что ORM про то, что одна есть потомок другой ничего не знает - если ему этого не сказать явно.

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


> Дык твой лишний узел и есть костыль ;-)

>Вовсе нет. Простые структуры данных - лучше, чем сложные правила. Lisp way, так сказать.

Правил то нету, ты придумал узел на пустом место, что бы твой ORM (если нет объектов, какой он ORM?) как-то работал.

>> Так что если ты я вынул объект с N полями и по одному начал с ними работать, будет N запросов.
>А, думал это про ленивое чтение структур. Нет, поля читаются в один запрос, как и простейшие случаи one-to-many.

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

>> Во что ты складываешь большие массивы бинарных данных? ;-)
>А к ORM это отношения не имеет.
Ещё как имеет.

>Да и, честно говоря - потребности в BLOB-ах у меня вообще ни разу в жизни не возникало.
А давно живешь?

PS Надеюсь я тебе объяснил, что-то, что ты назвал ORM не делает и 20 ой части того, что сейчас могут Hibernate,JDO,EJB3(aka jsr 220),Toplink
Впредь, мой тебе совет, меньше эмоций больше дела.
Кричать на этом форуме все горазды, мало кто что делает.
Удачи с твоим проектом.

>Вообще в VB была просто масса граблей.
Про мертвых - или хорошо или ничего.

> yahoo.eu Ты его что, постоянно закрываешь и грузишь, потом грузишь и
> закрываешь и опять запускаешь? Azureus вообще-то deamon-style прога,
> типа сервиса

Демон с Gtk-интерфейсом? =)

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

> Про мертвых - или хорошо или ничего.

Если бы. Еще полно кода на этой гадости, причем миграция на VB.Net - не
вариант по причине практически полного отсутствия совместимости
последнего с VB6. Так что нам с этим еще жить и жить, как с COBOL.

> Так что нам с этим еще жить и жить, как с COBOL.

*в догонку, с ехидцей*

... а лет через 5-7 туда же можно будет и жабку записать. ;)

>Зачем оно будет висеть и память мне жрать? ее и так мало...

Бугагага. Устройся на работу наконец, купишь себе память, она сейчас очень дешево стоит

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

основные тормоза когда ты читаешь row, если его нету еще в памяти и база данных читает с диска. Очень редкие записи не помещаются в 8K. Если это блоб, то получаешь blob handle, и читать его все равно надо отдельно.

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

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

это если у тебя структура из примитивных типов,
а если у тебя структура из других структур (хранящихся в других таблицах)?
Ответ - придется делать другой запрос.

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

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

>это если у тебя структура из примитивных типов, >а если у тебя структура из других структур (хранящихся в других >таблицах)? Ответ - придется делать другой запрос.

правильно, но не думаю что в этом случае тянется весь паравоз. А вытаскиваются только id из связанных таблиц. Я честно говоря не знаю точно, потому как не копенгаген в этом продукте, но должно быть так.

> Если не знает, то наплодит он у тебя в базе под каждую "структуру" таблицу(ы).

Схему БД оно у меня не генерит, и не будет. Схему надо делать ручками.

Я и Hibernate всегда использовал только с рукописной схемой, во избежание.

> Правил то нету, ты придумал узел на пустом место, что бы твой ORM (если нет объектов, какой он ORM?) как-то работал.

Объектов нет, есть структуры.

Например, XML infoset - более ограниченная модель данных, чем Лисповские списки. Что проще обрабатывать программно? Правильно - SXML. Так что наложить ограничения на структуры данных иногда бывает разумным.

А ещё я обчитался К. Окасаки, вот. > Значит, что если в "структуре" есть редкоиспользуемые данные, таскаешь ты их из базы каждый раз.

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

> Надеюсь я тебе объяснил, что-то, что ты назвал ORM не делает и 20 ой части того, что сейчас могут Hibernate

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

И, мой подход может кое что гораздо большее, чем Hibernate. У меня полностью статическая компиляция, никакой рефлексии во время выполнения - так что теоретически и производительность должна быть гораздо выше. Пользоваться этим тоже на порядки проще, чем Hibernate.

Я вообще не понимаю, как хоть кто либо может не догонять, что на Лиспе то, что делается на Жабе в десятки тысяч строк, получится в 500-1000 строк кода, и в десятки раз быстрее. Это вообще-то должно быть непререкаемой аксиомой...

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

public class С {
Map m = new HashMap();
//далее getters, setters, все как обычно
}

Как найти все классы С, у которых среди значений m есть определенное значение? Т.е.
"from С where С.m.entrySet() = :str"

Шиш ты это сделаешь, без создания лишнего класса, и соответственно таблицы. Если это, конечно в 3.1 не поменялось.
При том что на SQL это делается тривиально. Но сунув SQL в Java код ты теряешь больше половины всех преимуществ Hibernate.

>Схему БД оно у меня не генерит, и не будет. Схему надо делать ручками. Вот ещё одна "фича" вашего "ORM"

>> Надеюсь я тебе объяснил, что-то, что ты назвал ORM не делает и 20 ой части того, что сейчас могут Hibernate

>Нет. Перечисленные феньки тривиальны, добавить их - не проблема, только вот я не вижу от них никакой пользы.

Ты не видешь в пользе в отношениях M к N в lazy initialization в BLOB в том, что схема должна генерится по требованию сама база данных у тебя одна в избежание дублирования таблиц для схожих структур данных и т.д. и т.п.

и при этом, ты считаешь, что сделал нечто, что лучше Hibernate (чем же он лучше?! чем Армянский!)

> А ещё я обчитался К. Окасаки, вот.

Это многое объясняет.

>Шиш ты это сделаешь, без создания лишнего класса,
почему же? Класс то который ты в Map кладешь и так уже создан

>и соответственно таблицы

и это правильно, с точки зрения проектирования БД
данные нужно в меру нормализовывать.

PS Я не утверждаю, что Hibernate идеальный ORM
я просто пытался объяснить юноше, что его библиотека ни как не дотягивает и до половины возможностей Hibernate (он уверен в обратном).

Производительность Hibernate на 90% зависит от вещей, не имеющих никакого отношения к runtime-рефлексии.

Для решения специфических задач мы используем специфический инструментарий: для декларативного программирования - drools, для парсинга - javacc, antlr и т.п. Производительность решений на основе приведенного инструментария зависит от теоретических ограничений а не от того, какой язык (java или lisp) используется. Если же кто-то пытается всё писать "с нуля" сам и "всё на джаве", то это его личное предпочтение, далеко не всеми разделяемое :)

>При ровно том же уровне компетентности на Tcl народ не хуже вещи делал, и столь же быстро.

У Tcl в _то_ время были COM-биндинги для дерганья офиса и WinAPI?

Согласен, что на Tcl можно было сделать так же просто, но далеко не то же самое, что и на VB.

Эт точно. Граблей - на каждом шагу. Самое печальное -- никогда не знаешь, как собственные activex-объекты поведут себя на другой машине. Я просто хотел акцентировать внимание на том, что в то время VB очень неплохо автоматизировал решение типовых задач типа создания морд к базам данных. Этих морд, как правило, надо много и делать их надо быстро. VB с этим справлялся очень неплохо.

> 1. Более стройный синтаксис с меньшим количеством "навесных" механизмов. Легче "входить" в коддинг после перерывов по сравнению с Java.

как-то не вяжется это заявление с п. 2.

> 2. Очень большой набор функциональности реализуется на уровне конструкций языка (у Java - библиотеки). Меньшая зависимость от внешних библиотек.

и бОльшая зависимость от реализации языка. несравнимо легче обновить библиотеку.

> 3. Более емкие и краткие языковые конструкции.

очень часто это основная причина полной нечитабельности кода (навеяно воспоминаниями об однострочниках на perl)

> 4. Более "читабельный" код.

может быть... см. п. 3

5. Меньшие затраты на разработку классов.

6. Большая толлерантность к ошибкам в проектировании классов.

7. Возможность динамически изменять свойсва и методы часто спасают при расширении функциональности объектов в процессе жизни кода.

8. Отсутствие строгой типизации объектов упрощает разработку и, как не странно, уменьшает количество ошибок (по крайней мере у меня).

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

9. Динамическое порождение кода (а-la eval) существенно упрощает жизнь в некоторых случаях.

а во многих - существенно усложняет отладку и сопровождение

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

а чем _принципиально_ хуже collections/iterators в java?

> Чего не хватает в Ruby по сравнению с Java: > >1. Хорошего и полноценного IDE (например, пользуемый мной eclipse пока не дотягивает с поддержкой Ruby до Java).

огромный минус для больших проектов. hello, world! можно и в vim/emacs наковырять

>2. Большого набора готовых решений и компонент, как в Java.

то же самое

>3. Библиотек маловато.

так ведь язык-то и так богат! зачем еще какие-то библиотеки? :)

> 4. Почти невозможно работать с низкоуровневыми устройствами и библиотеками (впрочем Ruby в эту сферу и не позиционируется).

а это правда нужно?

> 5. Литературы хотелось бы побольше.

> 6. Хотелось бы иметь вариант с прекомпилированным и хранимым байт-кодом.

> 7. Community маловато.

> 8. Скорости выполнения.

> 9. Хотелось бы иметь поддержку диалекта языка в виде скриптов для браузеров (мечта почти несбыточная).

> Каждому своё, но последние года два кроме Ruby почти ничего не пользую (разве С иногда или правка чужого кода).

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

> Думаю, что со временем (годиков через 3-5), если не сам Ruby, то нечто на него очень похожее станет достаточно массовым (Python на эту роль не предлагать!!!).

как знать...

> Ах да, еще есть плагин RDT для Eclipse Тут (в контектсе) гораздо > интереснее другой плагин - IDE для RoR http://www.radrails.org/.

А чо ж он на Java написан то?

>А ещё я обчитался К. Окасаки, вот.

Кто это такой с горы? Детские книжки пишет? Почему я никогда о нем ничего не слыхал?

>Я вообще не понимаю, как хоть кто либо может не догонять, что на Лиспе то, что делается на Жабе в десятки тысяч строк, получится в 500-1000 строк кода, и в десятки раз быстрее. Это вообще-то должно быть непререкаемой аксиомой...

Давай наклепай по-быстрому на Лиспе аналог Azureus и RSSOwl, а мы ждем. Судя по твоему каменту у тебя это займет полвечера и ~1000 строк кода. Не наклепаешь - веры тебе не будет

Только не скрипт консольный а с GUI пжлста

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

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

> А чо ж он на Java написан то?

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

> Кто это такой с горы? Детские книжки пишет? Почему я никогда о нем ничего не слыхал?

1. Пейсатель такой. Егойные книжки - признанный фидорулез.

2. Пишет про функциональные структуры данных.

3. Потому как ты - неграмотный мудак.

>>А чо ж он на Java написан то?

>Если ты знаешь способы писать плагины для Eclipse на языке, который не умеет генерить жабский байткод

По-моему, он имел ввиду, что если Руби настолько круче чем Жаба, то зачем вообще цепляться за Eclipse? Сесть да и написать IDE на Ruby за пару вечеров.

> Сесть да и написать IDE на Ruby за пару вечеров.

Хорошему языку костыли (a.k.a. IDE) не нужны.

>Хорошему языку костыли (a.k.a. IDE) не нужны.

Самовнушение помогает не всем.

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

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

Вообщето 2 таблицы(если у тебя в Map не лежит чего-то что в одну нельзя положить, например набор других MAP), и вторая, будет содержать id, fid + поля самого класса.

> Самовнушение помогает не всем.

Да. Жалким, ничтожным людям аутотренинг не помогает. И вообще ничего не помогает.

> Жалким, ничтожным людям аутотренинг не помогает. И вообще ничего не помогает.

похоже, это единственный доступный тебе способ возвыситься -- унизить другого

> По-моему, он имел ввиду, что если Руби настолько круче чем Жаба, то
> зачем вообще цепляться за Eclipse? Сесть да и написать IDE на Ruby за
> пару вечеров.

Mondrian вроде неплох. Впрочем, вопрос явно идиотский - IDE уровня
Eclipse за пару вечеров не напишешь ни на чем. Особенно если учесть,
сколько людей над ним работало (причем не бесплатно!), и сколько сейчас
есть достаточно опытных Ruby-разработчиков, которым за это бы платили.

>Вообщето 2 таблицы(если у тебя в Map не лежит чего-то что в одну нельзя положить, например набор других MAP), и вторая, будет содержать id, fid + поля самого класса.

В том то и дело, что если хочется делать такой HQL запрос как я написал, то приходится заводить лишний класс MapElement, который содержит только String (по-моему, это не нормализация, а идиотизм). Как следствие - ТРИ таблицы.

>>Хорошему языку костыли (a.k.a. IDE) не нужны.

>Самовнушение помогает не всем.

А в самом деле... Хорошему языку оно действительно почти не нужно. Оно нужно пользователям обьемных или многочисленных (т.ч. в память не помещаются) библиотек/фреймворков/пр. Ну, и пользователям плохих языков, тоже.

Помимо поддержки вышеперечисленного - (это вопрос) что в них есть полезного?

>А в самом деле... Хорошему языку оно действительно почти не нужно. Оно нужно пользователям обьемных или многочисленных [...]

Вот именно: языку оно не нужно. А пользователям языка - нужно. Рано или поздно на любом языке начинают писать вещи сложнее чем "Hell, Wordl", и появляются библиотеки/фреймворков/пр. По мере изменения бизнесс-требований (да, мы живем в реальном мире, и они меняются), с неизбежностью возникнет необходимость рефакторинга. Да, все это можно делать вручную, но зачем, если есть комп?

>появляются библиотеки/фреймворков/пр.

... для людей со слабой памятью ;-)

>возникнет необходимость рефакторинга

... массовые контекстно-зависимые замены.

Это все? Не очень то много для заявлений "пока не появится IDE это неюзабельно".

>>появляются библиотеки/фреймворков/пр.

>... для людей со слабой памятью ;-)

Я не вполне понимаю, о чем ты. Хочешь сказать, что человек не со слабой памятью может запомнить весь api какого-нибудь фреймворка и еще нескольких библиотек? Ну извини, МНЕ на это тратить время жалко. Естесственно я представляю себе, что умеет каждая библиотека/фреймворк с которыми я работаю, но запоминать весь api - это уж слишком. И если кого-нибудь в своей команде застал бы за этим занятием - выразил бы недовольство. Работать надо, а не он@низмом заниматься.

>>возникнет необходимость рефакторинга

>... массовые контекстно-зависимые замены.

... что совсем не тоже самое.

>Это все? Не очень то много для заявлений "пока не появится IDE это неюзабельно".

Во первых - ты это не по адресу. Я таких заявлений не делал. У меня у самого долгое время был один инструмент - emacs. Но попробовав IDE - я увидел, что так работа идет гораздо эффективнее. Поэтому могу сказать, что юзабельно. Но неэффективно в промышленных условиях.

>человек не со слабой памятью может запомнить весь api какого-нибудь фреймворка

Смайлик видел? Это была цитата из "почему настоящие программисты пишут на ...".

>что совсем не тоже самое.

А что? Я как бы не возражаю против их полезности. Но хочется узнать(-:не нанимаясь писать на яве:-), чем _конкретно_ эти самые IDE помогают. Пока моё воображение подсказывает только своевременные подсказки по синтаксису/библиотекам и автогенерацию boilerplate-а. Некоторые упоминают загадочное слово "рефакторинг", но _чем_ может помочь IDE - кроме выделения синтаксических блоков - догадаться не могу. А на распросы обычный ответ - "заменить название метода по всему проекту" - не шибко сложная функция.

>загадочное слово "рефакторинг", но _чем_ может помочь IDE - кроме выделения синтаксических блоков - догадаться не могу.

Например, перенести метод в другой класс/модуль. С учетом того, что метод может зависеть от статических переменных класса. Или классический пример: выделяешь кусок кода, и говоришь - "выделить метод", создается метод, код в этом месте меняется на вызов метода, и если у тебя был еще такой же код в классе (чего конечно быть не должно, но если несколько разных кодеров раздолбаев писали - бывает) - тоже. Выделить из класса интерфейс, и создать везде ссылки на этот интерфейс вместо класса. Извлечь константу (и переместить, если надо в другой класс). Выделить анонимный класс во вложенный. Преобразовать вложенный класс в обычный. Заменить, где это возможно ссылки с класса на его суперкласс. И т.д.

>А на распросы обычный ответ - "заменить название метода по всему проекту" - не шибко сложная функция.

Само собой.

Можеть быть еще удобная контекстно-зависимая навигация по ресурсам проекта и управление таковыми?

А вообще, лучше один раз увидеть, чем 100 раз услышать. :) IDE берет на себя весьма существенную долю "обезьяньей" работы по написанию java-кода: импортирование, setters/getters, сложное форматирование, генерация делегатов, генерация конструкторов из надклассов, контекстно-зависимая подсказка при исправлении ошибок и т.п.

Ну и, конечно же, рефакторинг отдельным пунктом. :) Он позволяет исправить неверно принятые на начальном этапе проектирования (вовсе не ошибочные!!!) решения. В экстремальном программировании рефакторинг вообще является одним из основных элементов процесса проектирования.

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

Спасибо, я уж лучше послушаю:-).

Спасибо.

Снова про рефакторинг

Помедитировав понял, что ответ порождает новые вопросы.

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

Это должно означать, что оно(IDE) потащит туда все методы/аттрибуты/и т.д., использованые в данном методе, но не существующие в классе/модуле "назначения"? Вряд ли это кошерно. Предупредит о проблемах? Это сделает и компилятор/unit test, минутой позже.

>"выделить метод" ... если у тебя был еще такой же код в классе - тоже

Обычно в copy-paste используется, если нужно иметь какое-то незначительное отличие между блоками(типа другое условие/действие в паре строк). Оно догадается параметризовать "выделяемый" метод функцией, возвращающей/повторяющей результат этой пары строк? Иначе все равно руками/глазами делать/искать.

>Выделить из класса интерфейс, и создать везде ссылки на этот интерфейс вместо класса... Выделить анонимный класс во вложенный... Преобразовать вложенный класс в обычный...Заменить, где это возможно ссылки с класса на его суперкласс

Этого питонщики не оценят:-) На первый взгляд всякие функциональщики тоже. Похоже это борьба с дизайном Явы.

Я же говорю, лучше один раз попробовать, чем 100 раз услышать... :)

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

>чтобы не выглядеть ужом

Насколько я помню, тот как раз попробовал:-).

IMO описаные прелести(большинство) нельзя почувствовать, не зарывшись в Яву довольно глубоко и не начав писать и переписывать на ней "неправильный" код. Я не способен на такие подвиги ради "увидеть преимущества работы с IDE":-)

Что до свойств, выглядящих полезными _без_ явы(в противогазе бегать очень неприятно, если не разбрызгать вокруг яду:-):

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

2. Борьба с кривостями языка. не лучше ли менять/править язык?

Таким образом из бесспорных достоинств - только нормальная работа с синтаксическими конструкциями/блоками. в случае "человеческого" синтаксиса [-;ява и sgml-и, видимо не из таких;-] может эмулироваться простыми макросами/регекспами - не очень качественно, но некоторые вопросы решает.

>Это должно означать, что оно(IDE) потащит туда все методы/аттрибуты/и т.д., использованые в данном методе, но не существующие в классе/модуле "назначения"? Вряд ли это кошерно.

Может потащить, может параметризовать. IDE может делать то, что можно сделать формально.

>>Выделить из класса интерфейс, и создать везде ссылки на этот интерфейс вместо класса... Выделить анонимный класс во вложенный... Преобразовать вложенный класс в обычный...Заменить, где это возможно ссылки с класса на его суперкласс

>Этого питонщики не оценят:-) На первый взгляд всякие функциональщики тоже. Похоже это борьба с дизайном Явы.

Не вижу проблемы в Яве. Генерализация может потребоваться в любом языке с наследованием.

>Подсказки. упрощают работу с документацией. расслабляют память(её таки нужно тренировать).

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

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

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

>2. Борьба с кривостями языка. не лучше ли менять/править язык?

Это ортогональные понятия. Возьмем к примеру SQL - язык написанный математиками, и для доступа к данным ничего лучше пока что не придумали. Но ведь существуют IDE и для него.

И вообще, извини, но твои аргументы напоминают высказывания некоторых девелоперов 20 летней давности по поводу редакторов текста. Говорили они тогда, что пользоваться нужно исключительно ed'ом, поскольку все визуальные редакторы расслабляют. А тут - сплошная тренировка, и занешь всегда какой номер строки и номер символа в строке ты хочешь редактировать. Ну и где сейчас люди, пользующиеся ed'ом?

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