Минюст США разрешил Oracle купить Sun Microsystems

>>> it can't VIRTUALISE non-x86 guests

>> Как виртуализатор он бесспорно лучше ;)

> И что же он "виртуализирует"?

x86 guests :)

Вы не поверите. В Java-проекте я использовал динамическое назначение компаратора (были 2 разные его версии).

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

*******

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

:)

P.S. Не сложно представить, на сколько мощным и удобным является в данном случае паттерн Strategy. - Можно хоть 100 стратегий обработки кода вводить, один за одним, на протяжении всего времени существования проекта (для этого создать отдельный пакет; на лицо отличное разнесение кода). Главное - имплементировать одни и те же интерфейсы при этом, чтобы участвующие в сравнениях объекты - могли вызывать метод сравнения двух инстансов.

P.S.2 А конкретно Ваш пример - достаточно поставить ПЕРЕД этим методом, в потоке выполнения программы - какую-то объектную обертку-оболочку, которая принимает на вход - параметр, затипизированный компаратором.

Ваш пример - только лишний раз доказывает, как ООП позволяет легко обходить какие-то нюансы по использованию языка. Синтаксис которого может менять со временем. И как программист, при выборе языка - не привязывается к каком-то одному, из-за "мелкой особенности" в нем. И что достаточно только 1 раз выучить ООП, чтобы потом всегда, в любом ЯП - пользоваться преимуществами его.

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

Согласитесь, что "мои" ООП-решения - НАМНОГО более универсальны и мощны, чем Ваши.

> Интересно, а на яве можно написать интерфейс MyComparable и T max(T a, T b), работающий *всегда*, когда T реализует MyComparable?

Сейчас постараюсь вникнуть по учебнику Хорстмана по Java 6. Там есть нюанс, что, например, если мы имплементируем сразу 2 интерфейса в <T ... ... ...>, то важно - кто идет вторым интерфейсом при этом.

Давайте я "разверну" контекст, покажу его всем читателям дискуссии.

1) Вы привели пример по обобщенному программированию (Generics).

2) ОДНО из плюсов применения обобщенного программирования - как раз в улучшении программирования когда требуется сравнивать объекты (Comparable). Одно из.

3) Вы хотите сказать, что нюансы по использованию Generics, и, теоретически можно допустить, что Generics в Java реализованы не на 100%, а на 95% - что это является несомненным доводом в пользу того, что ФП лучше ООП - ?

Я могу сказать, что ФП - г-но, потому что Марья Ивановна не есть по утрам манную кашу, в таком случае.

*******

Давайте обратимся к Википедии, чтобы понять, есть ли *хоть один шанс* доказать, что ФП лучше.

http://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD...

Характерный цитаты:

"Функциона́льное программи́рование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).[источник не указан 99 дней] Противопоставляется парадигме императивного программирования, которая описывает процесс вычислений как последовательность изменения состояний (в значении, подобном таковому в теории автоматов). Функциональное программирование не предполагает изменяемость данных (в отличие от императивного, где одной из базовых концепций является переменная)."

"Многие нефункциональные языки, такие как C, C++ и C# могут вести себя как функциональные при использовании указателей на функцию"

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

"Привлекательная сторона вычислений без состояний — повышение надёжности кода за счёт чёткой структуризации и отсутствия необходимости отслеживания побочных эффектов. Любая функция работает только с локальными данными"

*******

Очевидно, что ФП и ООП - мягко говоря, слабо совместимы.

Очевидно, что ФП подразумевает, на практике, процедурный подход в программировании. Нюанс, о чем не указано в Википедии - что вы передаете не объекты, а функции, в теле программы, что вы ВЫНУЖДЕНЫ будете использовать подпрограммы.

Давайте уберем из ФП - функции, оставим одни переменные, и тогда получим не 2D-программирование, а 1D-программирование. Вот вам и та часть Ассеммблера, в которой мы присваиваем переменные в регистрах (другие возможности Ассеммблера пока опустим).

> Очевидно, что ФП подразумевает, на практике, процедурный подход в программировании. Нюанс, о чем не указано в Википедии - что вы передаете не объекты, а функции, в теле программы, что вы ВЫНУЖДЕНЫ будете использовать подпрограммы.

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

Это уже вообще НЕЧТО. Это 1D-программирование. Если не заботиться, чтобы некоторые фрагменты кода можно было использовать несколько раз (а тогда получается процедурное программирование).

И это "круто"?!

По моему спор окончен [собирает с поля боя куски панцирей и обломки копий и мечей поверженных противников. Незаметно пару раз пинает Led-а. Потом вспоминает про рекурсии и циклы и пинает еще 8 раз]

> "Многие нефункциональные языки, такие как C, C++ и C# могут вести себя как функциональные при использовании указателей на функцию"

Объекты с типом Function - есть и в текущей версии ActionScript/Flash:

http://help.adobe.com/ru_RU/AS3LCR/Flash_10.0/Function.html

Usage:

function setAndRunOnComplete(callBack:Function):void

{

this.onComplete = callBack;

onComplete.call();

}

//намеренно показан пример говнокодинга, во что выливается, на практике, использование неискушенными ООП программистами - "просто написать и быстренько что-то вызвать".

Вам бы столько лет практики по программированию без использования классов (которых фактически нет в языке), сколько я имел.

Вы бы по другому заговорили...

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

Во флеше 4 был таймлайн, на который можно было "атачить" функции. Таймалайн "проскакивал" стандартно 12 кадров в секунду. Можно было сделать stop для таймлайна. И в этом кадре таймлайна - "положить" кнопочку. На которую "навесить" функцию-обработчик одного из событий.

На флеш-баннерах это удобно. Зачем там классы?

Но при коде за 800 строк - такое размазывание по таймлайну и элементов управления в конкретных кадрах - программировать было затруднительно.

Поэтому, со временем, флеш-сообщество пришло к такой best practics - код и все элементы - должны быть В ОДНОМ кадре. Сначала приложение инициализируем, потом - выполняем. Когда код сосредоточен ИМЕННО в одном месте (именно в кадре, даже не в элементах управления, которые есть в этом кадре - а именно в кадре, в одной области видимости, - списком перечисляем все функции; GOTO нет; поэтому применялись, в том числе, и хвостовые рекурсии, и передача Function в качестве параметра, с активным использованием контекста this; так же отдельные функции-обработчики - атачились-навешивались - на элементы управления, размещенные в этом кадре; но так как код был описан только в одном контексте видимости, в самом кадре ("родителе" для элементов управления, размещенных на нем) - такие атачи-альясы давали и такое свойство - код имел уже 2 области видимости и нужно было хорошо понимать - где в каком месте кода какой именно this).

"Все новое - хорошо забытое старое" (с)

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

Потому что флеш другими вещами добавлял n-мерность (кадры размещались на сцене, но сцена могла содержать элементы, в том числе со своими кадрами и "потоками выполнения". Так же сцена по умолчанию размещалась в __level 0, но были доступны и другие levels; и другие особенности флеша; например были и gotoAndStop() и gotoAndPlay() для каждого таймлайна - таким образом можно было "руководить" запуском кода и показом элементов, в разных под уровнях и областях видимости; можно было и классы в какой-то мере даже создавать, правда их требовалось регистрировать, в общем это было малоудобно и первоначально не было распространено - а вот рекурсии применялись очень широко, правда были ограничения на 256 циклов рекурсии, и при 12 кадрах в секунду - нужно еще следить, чтобы твой код успевал выполниться, иначе нужно "размазывать" выполнение одной функции по таймлайну - ой, столько ухищрений было... профессиональный флеш-программист на данный момент получает ОТ 70.000 руб. в Москве - не каждый сишник доходит до такого ОТ).

>> Очевидно, что ФП подразумевает, на практике, процедурный подход в программировании. Нюанс, о чем не указано в Википедии - что вы передаете не объекты, а функции, в теле программы, что вы ВЫНУЖДЕНЫ будете использовать подпрограммы.

>Можно и не использовать. В таком случае "весь поток выполнения программы" - будет представлять собой постоянное присваивание и рекурсивные вызовы там, где нужно обработать циклом.

>Это уже вообще НЕЧТО. Это 1D-программирование. Если не заботиться, чтобы некоторые фрагменты кода можно было использовать несколько раз (а тогда получается процедурное программирование).

>По моему спор окончен [собирает с поля боя куски панцирей и обломки копий и мечей поверженных противников. Незаметно пару раз пинает Led-а. Потом вспоминает про рекурсии и циклы и пинает еще 8 раз]

У нас есть специалисты по эвтаназии? Усыпите этого субъекта, плиз. Ведь нельзя же без слёз смотреть не сего инвалида :(

А ведь я поначалу даже смеялся над ним... Виноват, каюсь - грешно смеяться над больными/убогими :(

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

По плану твоя тушка должна лежать на поле боя.

Могу бутербродов принести.

http://www.oracle.com/features/sunoraclefaster.html

Oracle and Sun together are hard to match. Just ask IBM. Its fastest server now runs an impressive 6 million TPC-C transactions, but on October 14 at Oracle OpenWorld, we'll reveal the benchmark numbers that prove that even IBM DB2 running on IBM's fastest hardware can't match the speed and performance of Oracle Database on Sun systems. Check back on October 14 as we demonstrate Oracle's commitment to Sun hardware and Sun SPARC.

А то в последнее время слишком много слухов разносится о смерти этого, того, о слиянии железа Солнышка с Высокой Ценой (HP)...

Развитие темы:

http://www.oracle.com/features/suncustomers.html

а соляра(