Динамически типизированные языки в Java

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

Зато один раз и потом оптимизировать по мере надобности, вынося внешний функционал в либки. Идеал - подобно линуховым дистрам типа дебиана или генты, если "lib/proto/http" - то интерфейсы к оному, если system/libc - то базовая либа, т.е. соответствующий код в выделенной либке, а не десятки желдорсоставов с велосипедами для имеющих ноги и костылями для остальных.

> Если +asm , то можно забыть о кроссплатформенности.

#ifdef никто не отменял, glibc в составе имеет море низкоуровневого кода, но, тем не менее, крайне кросплатформенна. Усилий много, но зато - на века. Ядро линуха, Mplayer, Х11 - все имеют в составе асм. Наверное разве что венды без асма обходятся, но там и кроссплатформенность на высоте - аж 2 штуки кодеры асилили ;)

> Я не думаю что java падонковский язык: если управление памятью можно возложить на систему, то почему это не сделать? Тем более gc довольно простой механизм, а упрощает жизнь очень сильно

Если работу моска можно переложить на внешний кластер Cray'ев - то почему бы этого не сделать? А потому, что машина работает - но думает все-же человек (хорошее проектирование экономит 90% времени).

> Но писать на таком для себя - брр.

Стоимость поддержки Вас не интресует, даже для внутреннего продукта? Что будет, если гуру, написавший систему на каком-нибудь Эрланге (подставьте сюда любую немейнстримовскую технологию) уйдет - Вас не интересует? (На всякий случай, я очень уважаю технологический андерграунд, но не надо путать мух с котлетами).

> Убунту можно даже devel пробовать, который edgy. Вроде, живет.

Счас дебьян под амд64 качается, готов к установке sarge 3.0r2, но из-за устарелости оного я и засомневался. Убунту солью, разумеется. Хорошо бы там еще DVD были, с кучей софта, дабы не париться...

> Дык я и не спорю. Просто для этого "кое-как" таки надо приложить некие усилия.

Вилазят же программеры утром из постели и даже в ванную заглядывают! ;)

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

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

> А потому, что машина работает - но думает все-же человек (хорошее проектирование экономит 90% времени).

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

> В любом случае - "count me out", когда речь идет о фильтрации людей (с оргвыводами) по любому произвольно заданному критерию.

Тем и хороши революции, что можно не спрашивать ;) Скатились в оффтопик уже совсем :)

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

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

> в отличие от нативного кода.

Нативный код, написанный "дешевыми" программистами - это кошмар.

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

Да написан уже весь код, для чего угодно и на все случаи жизни. Вона у нас 5+Гб чистых сорцов в продукте, а 3-пати почти на 1.5 развесилась... более того, я уверен что почти всю реальную работу как раз эта 3-пати и делает, а остальное - рюшечки и костыли.

> Тем и хороши революции, что можно не спрашивать ;)

Тем и плохи.

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

Мы явно говорим про linux kernel :)

> Нативный код, написанный "дешевыми" программистами - это кошмар.

OSS-комьюнити? Пионэры сами попадут фтопку, для того есть дистромейкеры и от их решения сие и будет зависеть, так что не аргумент. "Человеко-часы" - давно обсосанная тема, а корреляции качества кода и затрат на него - неа (M$-vs-OSS).

> Тем и плохи.

Иначе - болото и непрерывное увеличение числа на глубиномере...

> Мы явно говорим про linux kernel :)

В известной мере - да. Но никто не сказал, что прослойка должна быть одна. Вон, в стеке OSI аж 7 уровней%)

> OSS-комьюнити?

Мало ль кошмарного кода в OSS? Хотите, я свой покажу?;) Про "дешевых" и "дорогих" разработчиков я, конечно, говорил в контексте оплачиваемого кода. Я надеюсь, Вы меня поняли;)

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

>Стоимость поддержки Вас не интресует, даже для внутреннего продукта? Что будет, если гуру, написавший систему на каком-нибудь Эрланге (подставьте сюда любую немейнстримовскую технологию) уйдет - Вас не интересует? (На всякий случай, я очень уважаю технологический андерграунд, но не надо путать мух с котлетами).

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

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

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

А для чего подходит дотнет-джава, кроме как скорости (!) разработки?

Лисп, например, тоже позволяет быстро разрабатывать приложение. Но его "быстро" очень сильно отличается от "быстро" джавы. (это я опять про "повышение уровня абстракции" 8)

> В известной мере - да. Но никто не сказал, что прослойка должна быть одна. Вон, в стеке OSI аж 7 уровней%)

OSI еще жив? :)

> Мало ль кошмарного кода в OSS?

Мало кошмарного, но повсеместно и широко используемого, тогда как судя по работе кода закрытых прог, написание штатным девелопером подобного "кошмарному OSS-ному" - вообще повод для премии :)

> Хотите, я свой покажу?;)

Покажите, не откажусь :) SwitchIt - вроде бы гномья примочка? И разумеется я тут же отмажусь, сказав про исключение подтверждающее правило :)

> Про "дешевых" и "дорогих" разработчиков я, конечно, говорил в контексте оплачиваемого кода. Я надеюсь, Вы меня поняли;)

Понял, разумеется, указал лишь на отсустствие в общем случае корреляции между деньгами и качеством :) Но тенденции таковы, что и "дорогие" скоро начнут писать на коленке, ибо "опора на толпу влечет"...

> Почему вы передергиваете? Каждой задаче - свой инструмент.

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

> Писать на джаве-дотнете для своих нужд плохо даже из-за большой вероятности изменения апи

????? Апи в жабе - весьма стабилен. Иногда даже огорчающе стабилен. Как раз экзотические технологии (более динамичные) гораздо чаще меняют свои интерфейсы.

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

??? ЕJB вам не компоненты? Веб-сервисы? Банальные JavaBeans?

> Создаваемое ими ПО имеет монолитную структуру.

На жабе мало библиотек? Жабское ПО имеет монолитную структуру, когда речь идет о РЕШЕНИИ. И вот каждое конкретное РЕШЕНИЕ - действительно монолитно. Но сколько библиотек использует каждое решение?

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

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

> А для чего подходит дотнет-джава, кроме как скорости (!) разработки?

Дело даже не в скорости. Скорость - вторичная, производная характеристика. Первичная характеристика - стоимость. Или Вас интересуют конкретные ниши?

> OSI еще жив? :)

Формально, вроде, ISO его не объявила устаревшим;) Вообще, идея даже не плохая была - если б только оно было хоть сколько-нибудь жызненно;)

> Мало кошмарного, но повсеместно и широко используемого

apt-get source firefox ;) шутка, конечно, но в каждой шутке...;)

> Покажите, не откажусь :)

сvs.gnome.org, cvs.freedesktop.org. Самый кошмар - код виртуального модуля libgswitchit. Вот эту маленькую авгиевую конюшню давно пора того...

> Но тенденции таковы, что и "дорогие" скоро начнут писать на коленке, ибо "опора на толпу влечет"...

Вот это будет действительно беда. Надеюсь не дожить;)

>> Создаваемое ими ПО имеет монолитную структуру.
> ... Жабское ПО имеет монолитную структуру, когда речь идет о РЕШЕНИИ. И вот каждое конкретное РЕШЕНИЕ - действительно монолитно.

Я, именно, говорил про решение 8)

>> А для чего подходит дотнет-джава, кроме как скорости (!) разработки?
> Дело даже не в скорости. Скорость - вторичная, производная характеристика. Первичная характеристика - стоимость. Или Вас интересуют конкретные ниши?

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

Благодаря таким технологиям идет замедление развития ИТ. Джава-дотнет напоминает фэстфуды: быстро и дешево, красиво и хорошо пахнет. Быстро утолить голод - да. Но для нормального здорового развития организма уже не пойдет.

БРЕД

Это не фастфуд. По-вашему EE решение - фастфуд? Его делают под заказ - это рестаранное блюдо. И стоит оно не мало. Отнюдь. Но сложность его настолько велика, что по-просту не на джаве его не реализовать. Вот простое объснение.

Жаба хороша тем, что из нее МОЖНО сделать фастфуд. И даже некоторое время им питаться. Другое дело, что при злоупотреблении ... в общем, посмотрите фильм "Supersize me". Но из жабы можно делают и деликатесы. Дорогие и качественные. Но при этом повара не заставляют лично ловить рыбу, растить памыдоры, выкапывать из земли трюфеля и добывать соль на руднике.

> Формально, вроде, ISO его не объявила устаревшим;) Вообще, идея даже не плохая была - если б только оно было хоть сколько-нибудь жызненно;)

%)

> apt-get source firefox ;) шутка, конечно, но в каждой шутке...;)

Да не такой уж он и кошмарный, что с учетом стремления опенсорцных прог от изначального бардака и хаоса к светлому будущему и упорядоченности - вовсе и не недостаток ;)

> сvs.gnome.org, cvs.freedesktop.org. Самый кошмар - код виртуального модуля libgswitchit. Вот эту маленькую авгиевую конюшню давно пора того...

Вопрос снят, cvs.gnome.org - это Ад %)

> Вот это будет действительно беда. Надеюсь не дожить;)

Та уже - Санки сиим страдают зело, тот же OOo, та же Жаба - без слез не взглянуть на завалы сего объектно-ориентированного беспредела :) Оракел - куча хлама до самого последнего момента остававшаяся в несоотвествии никаким стандартам на кодинг, помимо SQL-92 :)

Ну давай, накодь мне вот эту штуку http://kgs.kiseido.com/en_US/download.xhtml на C+asm. Только чтобы я под любой системой мог запустить игру, нажав на ссылку и имея у себя runtime

См. "Manual Installation", ничего сложного, можно даже на серваке проверять платформу и предлагать нужный rpm/deb, особенно если кодить под стандартные интерфейсы типа X11/OGL.

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

Класс-файлы содержат код, который и выполняет одну задачу и делает это хорошо в агрегате с кодом других класс-файлов. Класс-файл — это "атом функциональной абтракции", это больше чем функция в UNIX. Классы имеют чёткий интерфейс private, protected, public и, часто упускаемый из виду, - package protected.

Код, как правило, документируется и из исходников можно получить стандартно оформленную документацию, из которой понятно, как класс взаимодействует с окружением.

>Создаваемое ими ПО имеет монолитную структуру. Хотя юникс представляет собой прекрасную платформу для создания красивых прозрачных решений?

Бред. Нормальное Java ПО не монолитно. Пример: Eclipse Platform, NetBeans Platform, проприетарный JBuilder "разделяется" на функциональные части.

>А для чего подходит дотнет-джава, кроме как скорости (!) разработки?

Для сохранения мыслей и идей в прозрачном программном коде без машинно-ориентированных инструкций.

----- iZEN