Технологии, которые задавят Java

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

Не, он _думал_, что пробовал. Ты, конечно, прав. Прочувствовать преимущества ИДЕ можно только в достаточно большом реальном проекте. А на это надо время, которого как всегда нет и т.п.

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

Я понял :) Это называется "больше думать о бизнес-логике, меньше - о коде". Это положительно сказывается на качестве бизнес-логики самого продукта и плохо -- на его технических характеристиках типа объема занимаемой памяти и т.п. Здесь уже кому - что, мы живем в реальном мире.

>Неужели ничего более полезного нельзя запомить

Просто замечание, по ходу дела. Конечно, стоит запоминать несколько другие вещи.

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

>Рефакторинг ... делает их предельно понятными для читателя.

Если получивщийся метод не перегружен непонятными вызовами - мы же решили не помнить используемые интерфейсы.

>Возьмем к примеру SQL ... Но ведь существуют IDE и для него.

Больная тема - прошлую неделю потратил на разгребание смысла чужой pl/sql процедуры на 2.5к-строк. "Повбывав бы". Если бы у автора был _только_ vim хрен бы он такое учудил:-)

>И вообще, извини, но твои аргументы напоминают высказывания некоторых девелоперов 20 летней давности

Это я пытаюсь показать, что люди, говорящие "IDE не нужен", имеют реальное обоснование для такого мнения. Просто нужно не наступать на некоторые грабли слишком часто (как то использование языков без вывода типов или сложным синтаксисом, глубокая классовая иерархия, плохая система модулей, сложные API, copy-paste кусков кода, и т.д.).

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

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

Например в случае питона(язык с наследованием:-) такие изменения чаще всего не требуют изменений использующего кода. Перенос метода туда-сюда == cut+paste. Перенос вложеных в обычные и наоборот - cut+paste+shift(а в руби даже shift не нужен). Убогий вим с этим вполне приемлемо справляется.

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

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

Ок. С наследованием и строгой типизацией. Типизация на мой взгляд - всё-таки плюс.

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

Не уверен. Скорее всего перед тем, как писать код, уже есть представление о том, что он будет делать и что при этом использовать. Раз так - подсказки на бизнес-логику уже не влияют, а только ускоряют уточннение мелких подробностей. Ести же такового(представления) не иметь - это _плохо_ скажется на бизнес-логике:-)

>Не, он _думал_, что пробовал

По моему он все таки летел некоторое, хоть и небольшое, время.

>Ок. С наследованием и строгой типизацией. Типизация на мой взгляд - всё-таки плюс.

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

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

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

>По моему он все таки летел некоторое, хоть и небольшое, время.

И при этом он решил, что то, что он пережил - это и есть "небо", хотя он только немного приподнялся над землей :)

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

Без обязательной декларации, типизацию нельзя считать строгой. ;-)

>Без обязательной декларации, типизацию нельзя считать строгой. ;-)

В словах "декларацией типов переменных" ключевое слово - "переменных". Питон - язык со _строгой_ типизацией (динамической). Хаскель - со строгой и статической. Оба они нормально обходятся без обьявления типов переменных, и таких языков много.

Но это ведь и означает, что ошибки типизации можно отловить только в ран-тайме.

>Но это ведь и означает, что ошибки типизации можно отловить только в ран-тайме.

В хаскеле - во время компиляции. Там вообще рантайм-типы, если уже и есть - то только в виде недавно появившегося расширения.

> Но это ведь и означает, что ошибки типизации можно отловить только в
> ран-тайме.

Предлагается для начала все-таки почитать про type inference:

http://en.wikipedia.org/wiki/Type_inference