Почему ЛОРовцы ненавидят Java?

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

SomeClass obj = new SomeClass(...)

Два раза потому что можно написать SomeClass obj = new SomeDerivedClass(...)

>SomeInterface obj = new SomeClass(...). Вопрос на засыпку: "Какого типа obj?"

Типа SomeClass, сам же прекрасно знаешь, зачем спрашиваешь?

Я оцениваю вещи как инструменты. Мне пофигу что там в 1001 проге внутри. Хоть лисп хоть асм, главное какой функционал она предоставляет.

Другой вопрос, что мне как кодеру не пофигу с чем работать. Ынтерпрайз жава только и хороша, когда уже ты сидишь сверху и погоняешь очередного хуариши за миску вон-тона. А работать в корпорациях вроде IBM и Motorola на больших проектах скучно, муторно и бюрократично, код максимально простой, максимально пухлый, логики мало. Сиди себе выстукивай очередной иф с очередным фором да подключай зумль.

По сему сравнение не корректо по крайней мере для меня.

ППКС, умеешь мысли выражать.

1) вайн ни разу не виртуальная машина
2) в мобильниках точно такая же ява с точно таким же байт-кодом обходится сотней килобайт

>в мобильниках точно такая же ява с точно таким же байт-кодом обходится сотней килобайт

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

> SomeInterface obj = new SomeClass(...). Вопрос на засыпку: "Какого типа obj?"

Я джаву плохо знаю, по работе больше сталкивался с C#, но как понимаю вопрос "Какого типа obj?" если имеем конструкцию obj = new SomeClass(...) однозначного ответа как раз не имеет.

> Интерфейсы... это вообще песня: чтобы соответсвовать какому-либо интерфейсу, я должен явно объявить что соответствую, и реализовать _все_ методы. Нет, чисто с теоретической точки зрения концепция выглядит правильно, если бы не наличие оргомного количества классов-заглушек в реальных проектах. Не лучше ли идти от противного: клас реализует методы такойТо и сякойТо, значит он соответствует интерфейсу такомуТо?

Лучше, но полагаю и накладнее с точки зрения реализации.

> Коллекции в языке со статической типизацией без полиморфных типов данных - песня. В скольких проектах рельные объекты храняться с типом более высокого порядка или вообще Object? А потом преобразуются назад? И сколько глюков и протечек такой подход принес?

Типа ... а в жабе нету женериков ?

>Типа SomeClass, сам же прекрасно знаешь, зачем спрашиваешь?

Угу, а если я захочу вызвать метод, который есть в SomeClass и нет SomeInterface? Понятие "тип" в ООП достаточно сложное, а повсеместное использование интерфейсов еще больше все запутывает.

> 1) вайн ни разу не виртуальная машина

По секрету: жаба тоже уже давно не виртуальная машина. Только тссс.

>Типа ... а в жабе нету женериков ?

Есть, но они не помогут когда, например, я захочу сделать аналог хаскелевского Maybe.

> Конечно, как может шулер ненавидеть колоду карт ....

Я честно говоря вообще не понимаю как можно ненавидеть колоду карт. Если верить тов. Пелевину, смотреть надо не на палку которую кинули в тебя, а на того кто эту палку кинул.

> По секрету: жаба тоже уже давно не виртуальная машина

То есть ей можно подсунуть бинарь с машкодом i386, и она его выполнит? :D

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

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

> Есть, но они не помогут когда, например, я захочу сделать аналог хаскелевского Maybe.

Извиняюсь за некоректный синтаксис. Не знаю я явы. Может быть что-то в этом духе 

template <typename A>
class Maybe 
{
    Object obj 

public:

    bool None() { return obj == nil; }
    A Some()    { return (A)obj; }
}

Конечно некрасиво, но имхо вполне сойдет. 

> То есть ей можно подсунуть бинарь с машкодом i386, и она его выполнит? :D Про JIT - не надо, мы и так знаем.

Если вы про JIT знаете тогда к чему этот вопрос ?

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

Гы. Отличная фраза если вдуматься.

язык не может быть ни плохим , ни хорошим
он либо есть , либо его нет
зы : человек может быть хорошим или плохим
а вино - либо оно есть , либо его нет

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

В общем сравнил пожирание памяти между amaroK и toonel.net . Какие ещё доводы остались в пользу явы?

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4917 user 17 0 260m 25m 12m S 0.0 5.1 0:05.70 java 4987 user 15 0 136m 41m 25m S 0.0 8.3 0:11.53 amarokapp

> Если вы про JIT знаете тогда к чему этот вопрос ?

К тому, что JVM - это таки виртуальная машина, как и подразумевается ее названием. Она может использовать JIT, а может и не использовать. И анонимус, который сказал, что вайн - не виртуальная машина (в отличие от Java), совершенно прав.

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

>Гы. Отличная фраза если вдуматься.

Бессмысленная фраза, если вдуматься. Клинический дебил не знает, что такое "клинический дебил" - ибо он клинический дебил.

В IBM ему скучно работать, я чуть не сдох от хохота!! Люди годами ждут, чтобы попасть на работу в IBM.

>>Люди годами ждут, чтобы попасть на работу в IBM.

Ты годами ждешь, чтобы попасть на работу в IBM?

> К тому, что JVM - это таки виртуальная машина, как и подразумевается ее названием. Она может использовать JIT, а может и не использовать.

Ну это спор в стиле ЛОРа, на уровне базовых определений - может ли виртуальная машина назвываться виртуальной машиной если она на самом деле использует JIT ? На мой взгляд следует провести черту между вирутальной машиной, выполняющей интерпретацию байткода, и компилятором этого кода в код реальной машины в процессе выполнения.

> Бессмысленная фраза, если вдуматься.

Эта фраза была выдержана в духе логических загадок. Типа: "Кто кого дебилом обозвал?". Мне она понравилась.

> Ты годами ждешь, чтобы попасть на работу в IBM?

В чикаге такие ацкие пробки ?

Расскажи мне пожалуйста как круто жабокодером в айбиэме работать. Ато я не знаю. У меня совсем нет около 10 друзей с потока, которые там работают.

Бедный-бедный оппеареный Саныч.

> Да просто ява взяла все самое худешее от C++

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

> Начнем с того, что SomeClass мы пишем два раза

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

> И еще более классная конструкция SomeClass obj1 = (SomeClass) obj.

Детская болезнь, большей частью исправленная в жабке 5 - там появились дженерики, поэтому приводить типы надо гораздо реже. Кстати, неявные правила приведения в плюсах - намного хуже. Жабка неявностями не занимается - И ЭТО ПРАВИЛЬНО.

> Не лучше ли идти от противного: клас реализует методы такойТо и сякойТо, значит он соответствует интерфейсу такомуТо?

Не лучше. Потому что одинаковость сигнатуры метода не означает одинаковость семантики. Так что если какой-то класс (в 3rd party library, допустим) реализует методы, описанные (=с той же сигнатурой) в моем интерфейсе - это еще не повод считать этот класс реализующим мой интерфейс. Есть, например, спец интерфейс Cloneable. При том, что clone описан в базовом Object - вроде все объекты должны быть таковыми. А вот нет. Надо явно implements этот интерфейс (и переопределить сам метод), чтобы сериализаторы с ним работали. Морал - наличие всех методов необходимое, но недостаточное условие реализации интерфейса. Важна семантика - именно об этом говорит явное указание implements Cloneable. Программист декларирует, что _семантически_ этот класс определяет соотв. интерфейс.

> В скольких проектах рельные объекты храняться с типом более высокого порядка

Все контейнеры до жабки 5 ТОЛЬКО так и работали. Да, был геморрой. В жабке 5 появились дженерики - больше этого геморроя нет.

> Связи устанавливаются ввиде XML файла, показывая всю импотенцию явы

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

> Вообще практика XML конфигурационных файлов просто поражает.

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

> То же можно сказать и про довольно широкую практику использования "ассемблера".

????? translate please

> Разобраться во всем этом многообразии за какой-то более-менее приличный срок невозможно

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

> рефакторинг и т.п,

Дожили. Рефакторинг запихали в "заглаживание неровностей языка". Про XP слыхали?

> система iBank от Бифита написана на Л И С П Е (!), интерпритатор которого написан на JVM

Круто. Завидую. Программистам. Но не менеджерам. Ибо если команда программистом снимется и улетит в жаркие страны - найти замену будет непросто и дорого. Кстати, а JScheme чем не угодила?

> В IBM ему скучно работать, я чуть не сдох от хохота!! Люди годами ждут, чтобы попасть на работу в IBM.

Гхм... У моей половины на это ушло 2-3 недели, кажется;)

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

Тут возникает только ещё один вопрос, как качественно можно решить данную задачу с помощью данного языка (в данном контексте под языком я имею ввиду также компилятор и виртуальную машину). Приведу такой пример. Требуется написать "быдлопрограмму" по решению конкретной задачи. С одной стороны можно сразу написать на java или на c++ со всякими оптимизациями и врезками на ассемблере. Первая программа требует более мощное железо, вторая будет работать на текущем железе без модернизации. Если рабочих мест, скажем 10, то вариант на яве явно дешевле, т.к. java + железо дешевле, чем разработка и отладка такой же программы на с (с++). А вот если рабочих место 1000 или 100000 (это справедливо для любой десктопной программы, т.к. пользователей по всему миру - миллионы), то уже c(++) решает, т.к. дешевле. В этом случае java-программист, конечно, не получит выигрыша в доходе, т.к. все деньги бедных пользователей уйдут производителям железа.

Вряд ли ее сразу взяли начальником отдела.

Архитектором.

Очень быстро, учитывая что тут они иногда по 2 месяца тесты обрабатывают.

Просто тут IBM прикупила местную контору и начала активно набирать штат.

> Сила жабки (в отличие от плюсов) в довольно простом (хотя и многословном) синтаксе.

Синтаксис Явы настолько многословен, что это нельзя назвать "силой". Причем он по-дурному многословен: пример с SomeClass это хорошо показывает - в подавляющем большистве случаев имеется в виду именно SomeClass obj = new SomeClass();

> Так что если какой-то класс (в 3rd party library, допустим) реализует методы, описанные (=с той же сигнатурой) в моем интерфейсе - это еще не повод считать этот класс реализующим мой интерфейс. Есть, например, спец интерфейс Cloneable.

А кроме Cloneable примеры есть?

Неплохо =)

Вообще ИМХО IBM ни какой не идол и ангел. Обычный корп. Хозяин первой работы (некто профессор Филипяк) рассказывал как МежДелМаш прокатили одного местного интегратора, а потом купили его с потрохами.

> Синтаксис Явы настолько многословен, что это нельзя назвать "силой".

Многословие - да, слабость. Сила - в простоте и однозначности. Увы, в жабке второе достигается первым.

> А кроме Cloneable примеры есть?

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

>>Вообще ИМХО IBM ни какой не идол и ангел.

Гы. Вообще-то, в старом хакерском фольклоре оно занимало примерно-же то место, которое нынче перешло к M$.

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

В ынтерпрайз жабе без громоздких IDE работать чудовищно трудно. Это таки очень сильный показатель.

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

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

> Простота полезна только манагерам при замене одного кодера другим

Welcome to the world of industrial software development.

> В ынтерпрайз жабе без громоздких IDE работать чудовищно трудно.

Ну ужас. Но не "ужас-ужас-ужас". Но ведется работа по упрощению j2ee... Первые ejb ИМХО были монстрее (по удобству разработки) современных, хотя и менее мощные по функциям.

См. выше про welcome.

>Есть, например, спец интерфейс Cloneable. При том, что clone описан в базовом Object - вроде все объекты должны быть таковыми. А вот нет.

И поимели нарушение принципа Лисковой в полном объеме.

В данном случае интерфейсы - очень неудачная попытка определить полиморфный тип данных.

>Да, был геморрой. В жабке 5 появились дженерики - больше этого геморроя нет.

Согласен, дженерики очень сильно облегчили жизнь, но невозможно в одной коллекиции хранить разные типы данных: типизация у явы статическая. Вот очень показательный пример http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-core.html

>Возьмите себя в руки. Нужно разделять код (тем более откомпилированный в байткод) и конфигурацию.

Конфигурацию - да да и еще раз да! Но не то что вытворяют в рамках IoC Spring и т.п. фреймворки.

>Ибо если команда программистом снимется

Если манагеров не будет душить жаба, то никуда не снимется и не улетит. Тем более в полном объеме.

>Кстати, а JScheme чем не угодила?

Без понятия. Думаю что когда разработка начиналась и JScheme-то никакой не было...

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

>Welcome to the world of industrial software development.

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

> И поимели нарушение принципа Лисковой в полном объеме.

Почему это?? Можно пример кода, где бы он нарушался?

> но невозможно в одной коллекиции хранить разные типы данных:

А надо? Что-то мне не очень нравятся такие коллекции. Можно пример удачного применения? Да, типизация статическая. Чтобы облегчить жизнь компилятору, JVM и программисту. Чтоб ошибок было меньше и ловились они раньше.

> Но не то что вытворяют в рамках IoC Spring и т.п. фреймворки.

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

> Если манагеров не будет душить жаба, то никуда не снимется и не улетит

Мало кто из менеджеров обладает станком для печатанья денег. Это рынок, dude...

> Думаю что когда разработка начиналась и JScheme-то никакой не было...

Вообще-то, она довольно древняя...

> Согласен, дженерики очень сильно облегчили жизнь, но невозможно в 
одной коллекиции хранить разные типы данных: типизация у явы 
статическая. Вот очень показательный пример 
http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-core.html

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

type something = 
  | Int of int 
  | Float of float
  | String of string 

Аналогично надо сделать и в си (с помощью юниона) и в жабе с помощью приведения к Object-у 

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

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

В свободном коде жабки не слишком много - но java.apache.org таки живет и процветает. А также всякие эклипсы и пр.

Потому что Java - это не РНР. А РНР - это надёжно и глобально!

>>электронной

Это вы про незабвенного Томми? По-моему, там как-то и без Джавы обходятся.

>>развлекательной

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

>>банковской

Вот это правильно. Пусть больше денег печатают.

>>java.apache.org таки живет и процветает
Ладно, убедили ApacheDS заруливает. Но и то, кастомеру предварительно нужно объяснить, почему ему не нужен OpenLDAP.

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

Правильно, всех обделали, никого не забыли.

По теме. "Без джавы" - про java card слыхали, про рантаймовскую жабку читали? "Казино" - про blue ray Вам известно? Про банки, печатающие деньги - даже как-то, извините, сказать нечего. Растерялся...

Она убила Томми, сволочь!