Кто сказал, что Ява для обезьян?

1. нет нединамических типов. 2. очень требователен к ресурсам, памяти особенно

а во все остальном он рулез

> 1. нет нединамических типов.

Можно пример, когда динамическая типизация полезнее статической?

Нет хвостовой рекурсии и замыканий. Без них язык - не язык, а дерьмо.

Что мешает добавить хвостовую рекурсию в компилятор явы?
Есть же открытые компиляторы.
Или нужна какая-то поддержка на уровне VM еще?

>Или нужна какая-то поддержка на уровне VM еще?

Нужна. При некоторых условиях ты можешь захвосторекурсить в пределах одного метода. К примеру, если метод - final, хвостовой рекурсивный вызов - это просто переприсваивание параметров метода (если они не final, конечно) и прыжок на на чало функции. Но вот если метод не final или идет хвостовой вызов метода другого класс - не выйдет. Нужна поддержка на уровне JVM.

Сказал В.С.Луговский, великий знаток "English read only", который не участвовал НИ В ОДНОМ серьезном проекте, а работал библиотекарем в Институте Физики Высоких Энергий и немного сопроводителем пакетов в ALT Linux.

> Кто сказал, что Ява для обезьян?

Ява вообще предназначалась для бытовой техники, если мне не изменяет склероз для процессоров с максимум с 4-мя регистрами на все-провсе и еще с каким-то ограничением... не помню, знающие поправят. И смысл ее был в том чтобы язык был легко-осваиваемым и читабельным, и были процессоры поддерживающие ее нативно, как родной байт-код. На бытовой технике это не пошло, но малый размер получавшихся приложений прижился в интернет-технологиях. Удобство и простота разработки привели к нежелательным последствиям тыкать ее стали там где надо и не надо. Появились неучи называющие себя "программистами" (просьба не путать с программистами работающими с явой), у которых вся разработка сводится к сливанию из и-нета готовых классов, кривое их склеивание и оп-ля-ля аппликуха готова. Ткнули работает и хрен с ним, а потом начинаются настоящие проблемы....

> На бытовой технике это не пошло

Разве мобильник не "бытовая техника"?

> там где надо и не надо

и где "не надо"?

> кривое их склеивание

Что такое "склеивание классов"? Ссылочку на такой термин в UML-спецификациях, pls..

> Разве мобильник не "бытовая техника"?

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

> Что такое "склеивание классов"? Ссылочку на такой термин в UML-спецификациях, pls..

Насколько понятно из моего поста, ява интересует меня не более чем исторический факт, и я не знаком с точной терминологией... и кстати каким тут местом UML ? Под склеиванием подразумевался подход к разработке Мол "Это у нас что база ..... ага вот у нас класс ёклмнjdbc а это у нас в почту пойдет.... ага вот у нас тут класс smtpbox чичас мы тут сюда а вот это сюда... все работает. Ах так вам кодировку ? А вот чего-то-там encoder вот сюда его прикрутим"... Вот это я и называю кривым склеиванием.

Вопросы ?

> Насколько понятно из моего поста, ява интересует меня не более чем исторический факт.

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

> Тогда не стоит строить из себя крутого перца и выдумывать, нарушая принцип Оккама, какие-то свои термины

Причем тут Оккам ? Или это вроде как модно стало ссылаться на философов ? Или слово склеивать уже не означает "соединять"?

> а также придумыать мифических горе-"программистов"

Они знаешь ли весьма немифичны.

> и героически с ними бороться.

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

> Cамореализация за счет других весьма сомнительна.

8O И где тут самореализация ?

еще у джавы нет множественного наследования, что иногда порождает некрасивые сущности.

> еще у джавы нет множественного наследования

У джавы нет множественного наследования классов. У джавы есть множественное наследование интерфейсов.

Так, что расти малыш и учись. И малыш твой в памперсе тоже пускай растет.

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

Хм, ты с дельфи точно не перепутал?

Он вообще не знает, чем Java от Delphi/Kylix Pascal отличается. voiD - очередной малолетка на ЛОРе.

Нужна поддержка на уровне VM, такая, как в .NET - там разные инструкции для call и tail call, вторая не пихает контекст в стек.

Если же реализовывать это через инструкции перехода, то будут получаться слишком большие методы (и куча методов будет инлайнится) - что тут не так давно обсуждалось, а JIT очень не дружит с большими методами.

> Нужна поддержка на уровне VM

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

> Хм, ты с дельфи точно не перепутал?

Нет, не перепутал, дельфи вообще отдельный разговор.

> Он вообще не знает, чем Java от Delphi/Kylix Pascal отличается. voiD - очередной малолетка на ЛОРе.

Хмммм!

А на хера мне писать поддержку на уровне JVM, когда у меня есть поддержка на уровне MSIL?

P.S. Во избежание передёргиваний и воплей "Microsoft сасёт" добавлю, что это далеко не единственная VM с нормальной поддержкой хвостовой рекурсии. Пожалуй, наоборот, JVM - досадное исключение.

Виталик, как это тебе не удалось до сих пор убедить в этом твоих коллег, насколько я понял из твоего "ламента" на твоем неподражаемом "пиджин-инглиш"? Неужто все твои коллеги пойдут в биореактор?

Другой Анонимус

Я

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

>У джавы есть множественное наследование интерфейсов

а вот это и есть костыль!

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

То есть разработка хороша, когда миллионы обезьянок на C++ каждый заново изобретают один и тот же велосипед? Модуль интерфейса к БД, модуль GUI etc?

> То есть разработка хороша, когда миллионы обезьянок на C++ каждый заново изобретают один и тот же велосипед? Модуль интерфейса к БД, модуль GUI etc?

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

> То есть разработка хороша, когда миллионы обезьянок на C++ каждый заново изобретают один и тот же велосипед? Модуль интерфейса к БД, модуль GUI etc?

В крайности вдаватся не будем, хорошо ? Про модуль интерфейса к бд... вообще-то интерфейсы к бд заново никто не преписывает... они как бы уже идут с бд (хотя некоторые переписать бы стоило...), да и к ГУИ тоже... только в случае с явой загрузки получаются неадекватные поставленной задаче.

>а вот это и есть костыль!

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

Если, например, следовать концепции IoC (Inversion of Control, это практическое применение принципа ООАД DIP, Dependency Inversion Principle), то наследование классов в общем-то и не нужно (разве что для наследования реализации по умолчанию, но это отдельный вопрос). Акцент смешается в сторону интерфейсов, а класс рассматривается лишь как имплементация того или иного интерфейса.

Собственно, я вижу пользу множественного наследования классов в объединении нескольких реализаций по умолчанию. В принципе, это можно решать и на уровне компилятора. AFAIR, мне попадалась реализация этой идеи для Java, вот только вспомнить не могу. Может это был Nice, не помню.

Джаба для обезьян - сказал Howler aka Mauhuur aka Antichrist aka flamer aka vsl aka VSL aka EvilOne aka bonegnasher aka WidowMaker (как его забанят в очередной раз, так и ник новый. Кстати, VSL есть и незабаненый, он про него забыл похоже, а там звездочка зеленая в статусе :-) Холит и лелеет он этот ник, чтобы не забанили :-)

>Нет хвостовой рекурсии и замыканий. Без них язык - не язык, а дерьмо.

Его уже на www.talkaboutprogramming.com http://www.linux.org.ru/jump-message.jsp?msgid=879334 мерикосы поопускали в гумно, он так и смог там ничего возразить по делу.

>а вот это и есть костыль!

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

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

Hybernate - это уже не модуль интерфейса к БД? А с какой БД он поставляется в коробке?

HIbernate (через "ай") это средство для устойчивого (персистентного) хранения объектов в БД. Поддерживает DB2, Oracle, MySQL, PostgreSQL, офтопик SQL & etc..

http://www.hibernate.org

http://www.hibernate.ru (определение, доки, форум)

Позволяет избежать "жесткого кодирования", особенно широко используется совместно со Struts или JSF.

JBoss тоже не остался в стороне:

http://www.jboss.org/docs/index#ejb3

Сам использую и очень рекомендую Hibernate.:)

> Кто сказал, что Ява для обезьян?

Луговский, великий теоретик программирования.

Анонимус-практик

Компания, на которую я работал, ввела новый уровень менеджмента, который был абсолютно излишен. Так что новый менеджер должен был доказать себе, что он делает настоящую работу и потратил много времени в спорах против использования нераспространенных языков . И, в конце концов, сделал невозможным использование чего бы то ни было, кроме Java, после чего много хороших специалистов ушло. И как-то случилось, что Java разработчик серьезно заболел. Менеджер не мог заменить его на протяжении пяти месяцев его отсутствия. Другие Java разработчики не могли сделать эту работу. К изумлению менеджера, выбор языка имел меньшую роль, чем способности программистов. В заключение этой истории менеджер оказался в такой ситуации, что было невыгодно держать квалифицированных программистов - он сам мог принимать архитектурные решения, а программисты просто кодировали это. Он теперь мог вернуться к своему правилу использования только распространенных языков нанимая только неопытных программистов, которые говорили неправду о своем знании языка. Насколько я знаю, ничего интересного не случилось с этой компанией за долгое время.

БАЯН!

АХТУНГ! САМ признал http://www.linux.org.ru/add_comment.jsp?topic=879723&replyto=880097 "Динамическое позднее связывание в серверных задачах таки нужно, тут Жабка слегонца поруливает." что Джава рулит! Ура! Озарение снизошло на Виталика!

Раздвоение личности у господина Луговского.

1.Что касается ФП для JVM, то можно посмотреть язык Camelot.

2.Что касается аспектно-ориентированного программирования, то JBOSS сделал красивое решение; можно также посмотреть Spring.

3. Мнение, что лучше - Hibernate vs. JDO - было бы интересно узнать. Сам я сижу под Hibernate.

Анонимус наверное не знает, что полиморфизм всегда имплицирует late binding. Так штааа, без него ява автоматом становиться чуть чуть лучше чем C (без плюсов).

А какой у вас опыт работы со Smalltalk?

Или, скажем, какие аспектно-ориентированные пакеты вы использовали? (Хоть для Squeak, хоть для Ruby, хоть для Java)

И в каких крупных проектах участвовали?

Или вы только RMI "Hello, World!" вызов на Java написали для лабораторной и уже считаете себя "крутым программулей"?

// Еще один анонимус, который про Hibernate дал ссылку.

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

Hibernate таки суксь... Как обычно - хорошая идея, реализованная через анал. :(

А тогда скажите, ссылка на массив ссылочных типов данных к чему может быть приведена (в Java)? Назовите ВСЕ варианты.

Пять минут на ответ.

// anonymous

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

//

Анонимус-практик, как замутить count(*) в native SQL через hibernate, у меня ругается на отсутствие столбца?