Про Cloud9 Вы не совсем правильно поняли. Это IDE не для JavaScript, а для разработки в основном серверной части, изначально на NodeJS, сейчас добавляются и другие языки, например, Python. Есть полезные фичи, например, прозрачный деплоймент на heroku. Доклад был достаточно техническим, если его внимательно слушать.
Не понял почему вы думаете, что два task'a создалось.
Task task создает неинициализированную ссылку, никакого объекта в памяти не создается. task = queue.getTaskBlocking() создает (или просто возвращает) объект и теперь ссылка указывает на него. Компилятор просто убирает лишнее создание ссылок, т.е. даже экономит силы процессора.
Стоит упомянуть что есть еще приквел, т.н. Барочный цикл. Действие происходит в 17 веке, герои — Лейбниц, Ньютон и многие другие + предки героев Криптономикона и Енох Роот (или его предок?). Труд вообще поразительный, 3 первых части тянут на 1000 страниц, а это всего лишь треть всего цикла.
> 1. А ведь такое большое число методов и свойств несет в себе сложность. Во-первых, для программиста. Когда он набирает имя объекта и нажимает точку, то открываются огромные списки, среди которых сложно найти то, что надо. Во-вторых это все занимает память и процессорное время.
Вообще-то чем больше уже реализовано, тем проще писать свою логику. Второе - это далеко не во всех языках так будет да и стоит все ж копейки. Небольшая цена по сравнению с затратами на очередное изобретение колесного транспортного средства.
> 2. Получается очень много классов. Программист, который работает с такими системами, должен держать в голове много информации при построении и сопровождении данной системы. Более того, для согласования абстракций часто приходится использовать неоптимальные методы.
Опять с точностью до обратного. Да, в машине есть руль и 2-3 педали, но это не значит что 100 км проще пройти пешком, так ведь? Про согласование абстракций - тоже как-то все перевернуто с ног на голову. Хорошая абстракция упрощает жизнь.
> 3. Например, создание однообразных страниц, где каждая следующая страница отличается от предыдущей лишь источником или представлением данных. В таких ситуациях часто используется «копи-паст».
Вы привели пример плохого дизайна и плохого стиля кодирования. Ответ лишь один - так делать не надо, более того, ОО подталкивает к code reuse.
Ну и так можно долго продолжать. Резюме таково - хороший класс - а то и целая библиотека - должна делать что-то одно и делать хорошо. Если это не так - это плохой класс и использовать его не надо. Надо брать другой класс. Но это не повод для выводов, сделанных Вами.
Кодогенерация в целом делает тоже, что делает и любой другой подход - OO, AOP - добавьте свое. Иногда внутри применяется кодогенерация, иногда динамические методы (посмотрите разные реализации AOP). Динамические методы (простейший пример - Dynamic proxy в Java) на мой взгляд элегантнее и гораздо проще в поддержке, но сложнее в отладке.
Звучит немного иронично, учитывая, что мейнфреймы построены на идее виртуализации десятки лет назад.
Task task создает неинициализированную ссылку, никакого объекта в памяти не создается. task = queue.getTaskBlocking() создает (или просто возвращает) объект и теперь ссылка указывает на него. Компилятор просто убирает лишнее создание ссылок, т.е. даже экономит силы процессора.
lib.rus.ec/s/2743
Вообще-то чем больше уже реализовано, тем проще писать свою логику. Второе - это далеко не во всех языках так будет да и стоит все ж копейки. Небольшая цена по сравнению с затратами на очередное изобретение колесного транспортного средства.
> 2. Получается очень много классов. Программист, который работает с такими системами, должен держать в голове много информации при построении и сопровождении данной системы. Более того, для согласования абстракций часто приходится использовать неоптимальные методы.
Опять с точностью до обратного. Да, в машине есть руль и 2-3 педали, но это не значит что 100 км проще пройти пешком, так ведь? Про согласование абстракций - тоже как-то все перевернуто с ног на голову. Хорошая абстракция упрощает жизнь.
> 3. Например, создание однообразных страниц, где каждая следующая страница отличается от предыдущей лишь источником или представлением данных. В таких ситуациях часто используется «копи-паст».
Вы привели пример плохого дизайна и плохого стиля кодирования. Ответ лишь один - так делать не надо, более того, ОО подталкивает к code reuse.
Ну и так можно долго продолжать. Резюме таково - хороший класс - а то и целая библиотека - должна делать что-то одно и делать хорошо. Если это не так - это плохой класс и использовать его не надо. Надо брать другой класс. Но это не повод для выводов, сделанных Вами.
Кодогенерация в целом делает тоже, что делает и любой другой подход - OO, AOP - добавьте свое. Иногда внутри применяется кодогенерация, иногда динамические методы (посмотрите разные реализации AOP). Динамические методы (простейший пример - Dynamic proxy в Java) на мой взгляд элегантнее и гораздо проще в поддержке, но сложнее в отладке.