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

> y=f2(x); > z=f3(x); > t=f4( x, f5(х,y), z ); > можно запустить вычисления f2, f3 параллельно

Неможно, если f2 или f3 привносят side effects, либо зависят от совместно используемых объектов. В приличных учебных заведениях вводят специальные спецкурсы, на которых разъясняют матаппарат, используемый для обеспечения распараллеливания решения задачи :-)

Очень интересная дискуссия (намек, что здесь есть интересующиеся читатели, пишу в "рут" топика, чтобы не создавать оффтоп).

>Вопрос что будет с MySQL?

sqlite же вполне заменит

> sqlite же вполне заменит

А многоюзерность и работа по сети?

>> Но как ты задашь тип такой простой структуры: двоичное дерево - это (левое двоичное дерево, правое двоичное дерево) или лист.

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

Обычный способ сделать класс дерева, что в паскале, что в плюсах -- это такой:

class Tree { Tree* left; Tree* right; Payload* leaf; }

но это совсем не то, что в хаскеле. Никто не мешает глупому юзеру написать функцию, которая будет считать что *одновременно* не NULL все сразу -- left, right, leaf. Хаскель и мой вариант такого не позволяют.

class Tree { Tree* left; Tree* right; Payload* leaf; }

Еще мой вариант ращмещает leaf прямо в классе (считай -- на стэке), а не в куче.

Ну и насчет констаности -- полагаю, у тебя не получится сделать ее правильно, или с получится, но с морокой.

> Неможно, если f2 или f3 привносят side effects

речь шла с самого начала о ФП

> Тут очень интересная штука. Иногда бывает так, что ветка которую будет возвращать выражение будет известна на этапе компилаяции: напр., let blah-blah = Leaf 5. Тогда компилятор может использовать полученную информацию для оптимизации.

Тут хочется увидеть пример. Что касается плюсов, то я не знаю, сможет ли ж++ оптимизировать такое (хотя принципиальная возможность есть):

Parent* obj = new Child(); obj->virtual_method();

s/(считай -- на стэке)/(что экономит одно разыменование и улучшает кэширование)/

Просто у Оракла ничего кроме оракла не выживает толком.

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

>Использовать JIT в Интернете удобнее. Так же как и АОТ удобнее для своих задач.

"Среди значительных обстоятельств мы укажем следующее: Венера находится в доме Меркурия, а Меркурий в доме Венеры. Таким образом, три благотворных влияния объединены, т.е. 1) благотворное влияние Юпитера, 2) благотворное влияние Венеры, 3) благотворное влияние, усвоенное Меркурием от благоприятной двойственности. Это очень необычно."

> Обычный способ сделать класс дерева, что в паскале, что в плюсах -- это такой:

> class Tree { Tree* left; Tree* right; Payload* leaf; }

> но это совсем не то, что в хаскеле. Никто не мешает глупому юзеру написать функцию, которая будет считать что *одновременно* не NULL все сразу -- left, right, leaf. Хаскель и мой вариант такого не позволяют.

В данном утверждении есть противоречия:

1) Чтобы глупый юзер с его функциями ничего лишнего не сделал, можно, во всяком случае в некоторых языках:

1.1) Ограничить права доступа - помещением класса и управление им в пакеты. Сюда же относятся и различные модификаторы доступа.

1.2) Принять параметры. Проверить их на корректность. Запустить рекурсию.

*******

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

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

Отладка конечным пользователем - исходного кода программы, написанного другим автором.

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

> 1) Чтобы глупый юзер с его функциями ничего лишнего не сделал, можно, во всяком случае в некоторых языках:

> 1.1) Ограничить права доступа - помещением класса и управление им в пакеты. Сюда же относятся и различные модификаторы доступа.

В один класс ты все равно не впихнешь все это -- нужны 3. (кстати, на яве вполне возможен аналог, за искючением некоторых траблов с const)

> 1.2) Принять параметры. Проверить их на корректность. Запустить рекурсию.

Проверять надо статически.

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

>> Использовать JIT в Интернете удобнее. Так же как и АОТ удобнее для своих задач.

> "Среди значительных обстоятельств мы укажем следующее: Венера ...

В контексте сказанного - JIT позволяет эффективно кэшировать данные.

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

Возьмите пример с JIT-компилятором и виртуальной машиной ActionScript/Flash - распространенность в Интернете максимальная из возможных.

Только не нужно приводить примеры говнокодинга студентов и дизайнеров под Flash - это запретить невозможно, Интернет свободная зона и либеральная к таким вещам. А простота платформы послужила привлечением в нее всех, кто только хотел.

Это - отдельная тема. На плюсах тоже студент может наговнокодить.

> В один класс ты все равно не впихнешь все это -- нужны 3.

Хотя, если все left, right, leaf константны то можно и в один класс с двумя конструкторами, но в случае, когда у нас не две альтернативы (Node|Leaf), а штук 10, из класса получится свалка.

Требуется уточнение к решению данной задаче - а что должен отдавать метод:

Tree getLeft() { ... }

- если left == null

В идеале - что должно быть, какая логика должна быть реализована?

1) Перенаправление на родителя?

2) Отдать null - ?

3) Вбросить исключение о недопустимости данной операции?

4) Дать, пользователю этого класса, решение в виде рекомендации сначала проверить на существование данного узла? Как, например, мы используем при обходе итератором: hasNext() - ?

> но в случае, когда у нас не две альтернативы (Node|Leaf), а штук 10, из класса получится свалка.

Мы можем расширить одну из базовых коллекций, если нам нужна доп. функциональность. Типизируем как <T>, добавляем или переопределяем какие-то методы. Или агрегируем одну из имеющихся коллекций, формируем оболочку, которая обладает нужными свойствами/характеристиками.

Пол годика на ЛОРе и я получу Мастера (по Java) на Brainbench.

:D

;)

(пойду, полистаю про коллекции в Java, пока ж я не "мастер", со всеми вытекающими о пользе листания учебников)

Я вот почему принципиально против ФП. Потому что несколько лет в процедурно-функциональном стиле только и программировал. Язык программирования - ActionScript 1 (Flash 4, это при царе Горохе было). - Тогда там классов так в принципе не было, и активно профессиональные программисты - использовали и хвостовые рекурсии, и другое. А в ActionScript 2 - ввели более-менее классы и интерфейсы, и необходимость в прошлых ухищрениях отпала.

А тут люди, знающие ООП - "идут" в обратном направлении. Типа круто.

Нифига не круто. Жуткий отстой, извините, если кого задел.

2 таких случая:

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

На серверной стороне всевозможные защиты от накруток, в том числе и показ хакеру TOP лучших результатов - в который пробился хакер, но в последний момент, за пару часов до подведения итогов на сайте - хакеру уже показывалась другая инфа. - "Ты - лучший хакер!" (тут особый психологический момент). И нифига он в топе конечно не был. Это его обманывали. Чтобы он реально не успел хакнуть, успокоился раньше времени.

Ну так вот. На клиентской стороне (Flash) - такие же были "завороты". Недокументированные фичи виртуальной машины текущей версии и т.д. и т.п.

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

Так что всю хваленость сайта лично я и не увидел. А проблема была банально в том, что массивы так разрастались при старте, что флеш-машина съедала все ОЗУ на моем тогдашнем компе (комп был около среднего уровня). Люди за оптимизацией - забывали обо всем остальном.

Потом у них, через несколько лет, при смене версии флеш-плейера - интернет-казино некоторые отвалились.

2) Потом еще. Кто-то в мире, из профессионалов по флеш - нашел недокументированное такое одно свойство. Не помню ключевое слово, но придумаю и назову его так - __AS_PAR.

Суть его была в следующем (и на этом тогда и строилась определенная функциональность виртуальной флеш-машины):

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

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

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

*******

А мораль сей басни такова, что в следующей версии языка - ввели классы и интерфейсы. И все это _оказалось не нужным_ .

А это свойство (__AS_PAR) - по сравнению с использованием "новых ООП-решений" - было медленнее их - кажется в 20 раз.

В те времена высокий процент флеш-программистов - это были бывшие сишники. Поэтому не нужно так скептически судить о флеше по тому кол-ву г-на, которое вас окружает. :)

> придумаю и назову его так - __AS_PAR.

- Кажется __resolver. Или __resolver__. Гуглом пользоваться лениво, да и это тут не принципиально.

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

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

Комплекс всего - он обладает и низкоуровневостью, и юзабельностью.

>А мораль сей басни такова, что в следующей версии языка - ввели классы и интерфейсы. И все это _оказалось не нужным_ .

То есть, получается, на lambdatheultimate делать нечего?

Есть несколько направлений в программировании, с которыми лично я пока не совсем знаком.

Примеры:

1) Lua. 2) OLAP, Data Mining. 2) JavaFX Script. 3) Offtop Workflow Foundation.

Без хорошего понимания этих тем, а вернее - опыта применения их и самоличного копания как там что лучше - у меня нет всей исходной информации для ответа на Ваш вопрос.

lambdatheultimate это сайт такой, об ФП. http://lambda-the-ultimate.org/

Да, спасибо, я его "вычислил" через 4 секунды обдумывания Вашего вопроса + 5 сек на гугл + 20 сек на просмотр главной страницы.

Вы интересно пишите на лоре, наверное, задавая этот вопрос, что-то "за рубахой" прячете... ;)

>А мораль сей басни такова, что в следующей версии языка - ввели классы и интерфейсы. И все это _оказалось не нужным_ .

Так получается что весь шум, который в инете по поводу ФП, собсно ниачем. Если у нас УЖЕ есть классы и интерфейсы, то всякие лямбды, хвостовые рекурсии и т.п. ничего не дают, по вашему опыту ведь выходит так?

> Так получается что весь шум, который в инете по поводу ФП, собсно ниачем.

Возможно, причина этого шума в том, что, как написали специалисты из IBM в одной из своих книг (http://www.books.ru/shop/books/569002 - комментарий к этой книге там - мой, вообще на этом же сайте есть несколько ссылок на эту же книгу, где больше комментариев, очевидно это модель их закупок, или еще что-то) - как написали в ней, цитата (гугл рулит, не пришлось искать и набирать из книги):

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

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

К тому же многие начинающие программисты - в лучше случае изучат несколько паттернов GoF.

У них остаются целый области "непонимания", как что сложить.

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

Почему опытные люди за ФП - не знаю. Возможно, что за десятилетия - в языки с ФП - были "добавлены" многие вещи. Весьма полезные сами по себе (графы, например). Возникли, на базе ФП языков - целые эко-системы в программировании. Если так можно сказать. Где многое связано и переплетено.

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

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

Вместе с тем, лично мне - интересен комплекс таких знаний, в сочетании с "3D".

Могу ошибаться. Так думаю на сегодняшний день. Разберу, когда-нибудь, темы, про которые упомянул выше - возможно мое мнение изменится.

> К тому же многие начинающие программисты - в лучше случае изучат несколько паттернов GoF.

> У них остаются целые области "непонимания", как что сложить.

- Я когда-то что-то читал по объектно-ориентированному анализу, а так же разобрал "низкоуровневые" паттерны проектирования GRASP (по ним хорошо пишет Крэг Ларман).

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

В результате "вакуума" у меня не было.

А недавно разбирал примеры на С++ (в DirectX) - аж дрожь берет, от такого процедурно-функционального программирования - вспомнил весь свой предыдущий опыт...

>>Ил-2 рассмытривали вариант с пре-компиляцией

> А какого рода была прекомпиляция? Игровые скрипты?

нет, код самой игры в exe (на пальцах). Но отказались ибо exe не так секурен как работа JVM.

Чуть-чуть придать вес флешу, а то я тут чаще критикую. Только что попалась ссылка, прикольно:

http://flash.maxipack.ru/games/Sport/89/MiniBall_Futbol_yurskogo_perioda.html

(сорри за офтоп, но чуть акцентов подправить, не так уж он совсем плох)

>>>Что, VirtualBox уже умеет что-то, кроме x86?

>>Нашли о чем спорить.

>VB основан на QEMU.

А я с этим и не спорил - я это и так знаю. А школота на спорит, потому как об этом не знает:)

И тем не менее: покажет мне кто-то VirtualBox для не-x86-"гостей"?

>>>>Что, VirtualBox уже умеет что-то, кроме x86?

>>>Нашли о чем спорить.

>>VB основан на QEMU.

>А я с этим и не спорил - я это и так знаю. А школота на спорит, потому как об этом не знает:)

>И тем не менее: покажет мне кто-то VirtualBox для не-x86-"гостей"?

Наткнулся на ВБоксовском форуме

"virtualbox is not an emulator, it can't VIRTUALISE non-x86 guests. for debian arm you need to use the qemu EMULATOR."

>"virtualbox is not an emulator, it can't VIRTUALISE non-x86 guests. for debian arm you need to use the qemu EMULATOR."

Ок, и каким боком здесь "VirtualBox лучше, чем QEMU":)

> и тут вырисовывается ФП... с относительно низким порогом вхождения в его...

шаблоны + функциональщина мощнее, чем ООП, и это имхо общепризнано.

>> и тут вырисовывается ФП... с относительно низким порогом вхождения в его...

>шаблоны + функциональщина мощнее, чем ООП, и это имхо общепризнано.

Вроде бы уже всем понятно, что мега-ламер EugenyN не знает что такое ФП и путает его с процедурным?

> шаблоны + функциональщина мощнее, чем ООП, и это имхо общепризнано.

Приведите use cases. Для каких именно задач мощнее.

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

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

Пример:

1) В стране есть несколько операторов сотовой связи. Годами, годами, складывается такое положение, что софт для них - находится в плачевном состоянии. Требуется обеспечить поддержку и учет большого кол-ва тарифных планов, которые имеют тенденцию добавляться, отменяться, тарификация может иметь характер наложения - например одновременно учитывается льготное время звонка первой минуты разговора + это звонок на другого оператора сотовой связи + ночное время звонка с летними скидками по ним + услуга "любимый номер". Требуется найти такое проектное решение, или целый комплекс решений, которые позволяют хорошо справиться с этой задачей.

ФП позволяет это сделать следующим образом:

1) ...

2) ...

3) ...

Аналогичные ООП-решения - не позволит так гибко манипулировать этим, потому что:

1) ООП-решение 1. Паттерны - "", "", "". Недостатки -...

2) ООП-решение 2. Паттерны - "", "", "", "". Недостатки -...

P.S. Можно привести другие use case и методы их решения, тут без разницы - покажите, докажите, сравнительным анализом, на примерах, что ФП лучше чем ООП. Пока это "просто слова".

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

Я работал у одного из провайдеров, правда занимался не именно этим, но о проблеме знаю хорошо.

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

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

1) Eclipse plug-ins. Высокотехнологичный Java-фреймворк. Использует спецификации, применяемые не только в нем, служащие для эффективной защиты кода и др.

Характерные паттерны проектирования, применяемые в самом фреймворке: Lazy Load, IoC.

2) JBoss Frameworks. Очень хорошо спроектированные JEE-фреймворки и решения. Характерные особенности: IoC, двунаправленная инъекция, "низкогранулированность", очень эффективное использование аннотаций. Все это относится больше к JBoss Seam, но там и мегапопулярное решение JBoss Hibernate, и очень удачный фреймворк JBoss RichFaces. И др.

3) JSF. - Это уже немного устаревшая JEE-технология, по сравнению с JBoss Seam. Характерная особенность, в контексте обсуждаемого - помогал доводить один веб-проект, построенный на JSF + EJB 3.0, по моим оценкам на каждый клик юзера по кнопке - обрабатывалось примерно 5000 строк Java-кода МОЕГО ПРИЛОЖЕНИЯ (которое мне подсунули для доводки его), и это без учета того кода, который есть в стандартных фреймворках.

Знаете, я справился. Даже при такой сложности. И даже когда был команда - целый месяц добавлять в веб-проект - только фичи. И только потом исправлять баги. А баги были. Они могли происходить после 5-ого или 7-ого или 32-го клика юзером по кнопке на сайте.

Умножьте это на то кол-во кода _приложения_, в котором я должен был разбираться при этом, _и созданном не мною_ .

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

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

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

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

Кстати, скоро у меня заканчивается отпуск (той фирме помог и расстался с ними).

Никому не нужен такой супер-зубр как я? :D (без сертификата мастера по Java на Brainbench)? :)

Из "аналогичных подвигов" - как-то водил без прав (без прав вообще) - не полностью собранный МАЗ по территории предприятия, на 4-ой передаче, зимой, с ледком на асфальте, на машине не было ГУРа (гидроусилителя руля), не было зеркал, были утечки в пневматике и гидравлике. На 4-ой скорости, без прав (прав нет и сейчас) - лихо вписывался в повороты внутренних дорог предприятия, на котором работало 20.000 человек. При этом начальство (главный конструктор одного из подразделений предприятия) - хвалило, жало руку, давало премии и отгулы. За успехи в доводке автомобилей (конструкторов и специалистов по САПРУ, как вот меня - временно кинули на доводку и сдачу автомобилей, завод - МАЗ, г. Минск, разъезжали на МАЗах, права были у единиц да и то на легковые автомобили, ставили карданные валы, если их не было, закручивали гайки, искали утечки и т.п.)

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

- тут не дописал, что крайне сомнительно на счет - ФП.

> Кстати, скоро у меня заканчивается отпуск (той фирме помог и расстался с ними).

Уточню, что есть отличные рекомендации с двух последних мест работы (как раз это провайдер, упоминаемый выше, и фирма, которой помогал несколько месяцев с их JSF + EJB 3.0)

Извините за злостный оффтоп.

>> шаблоны + функциональщина мощнее, чем ООП, и это имхо общепризнано.

> Приведите use cases. Для каких именно задач мощнее.

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

( Алекс Степанов приводил хороший пример -- любители ООП приводят аналогии с классификацией животного мира, так вот: у наст есть функция "спариваться", которая в качестве аргументов берет двух животных одного вида. И как такое сделать на ООП? )

> Простейший пример -- функции min и max.

А чем не устраивает стандартная практика сравнения объектов в Java?

Или простые типы нужно сравнивать?

Или и те, и те?

По коллекции нужно вычесть max и min, или между двумя значениями, передаваемыми параметрами?

По коллекциям есть свои эффективные методы, уже реализованные, написанные, часто, на нативном коде.

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

Тогда пишите не только кратко, но и емко. Фразы, допускающие 100 толкований - это растягивать диалог на недели, лишнее отнятие ресурсов у всех.

> ( Алекс Степанов приводил хороший пример -- любители ООП приводят аналогии с классификацией животного мира, так вот: у наст есть функция "спариваться", которая в качестве аргументов берет двух животных одного вида. И как такое сделать на ООП? )

После слов "любители ООП" вообще не стал первоначально дальше читать.

Спаривать, минимально, максимально? Это как - кто сильнее, тот и имеет того?

Оцениваем 2 объекта по параметру мускулатура.

Можно еще ввести проверку - не убежит ли объект, обладающий менее мощной мускулатурой.

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

Свойство "пол" объекта нужно учитывать. Хотя и самка изнасиловать может.

И т.д.

А без шуток - уточнение прояснило, что два аргумента. Слова min, max и "спариваться" - как-то не пересекаются.

Чувствую, это еще на пару недель.

Возьмите примеры из школьных учебников, если так не можете придумать:

1) У пионера А было 1 яблоко.

2) У пионера Б было 2 яблока.

Вопрос: Сколько яблок у Маши, которая отдалась пионеру А и пионеру Б, если "красная цена" Маше - 1 яблоко?

> А чем не устраивает стандартная практика сравнения объектов в Java?

public static <T> T max(Collection<? extends T> coll, Comparator<? super T> comp)

Returns the maximum element of the given collection, according to the order induced by the specified comparator. All elements in the collection __must__ be mutually comparable by the specified comparator (that is, comp.compare(e1, e2) must not throw a ClassCastException for any elements e1 and e2 in the collection).

В хорошем языке такие вот "must" проверяет компилятор.

___________________________________

Я имел в виду всего лишь T max(T a, T b) -- его не написать на ООП (точнее, не написать без использования параметрического полиморфизма).

> Вроде бы уже всем понятно, что мега-ламер EugenyN не знает что такое ФП и путает его с процедурным?

Но польза от него есть. Я споря с ним перечитал public static <T> T max(Collection<? extends T> coll, Comparator<? super T> comp) и ужаснулся... теперь буду разбирать, почему они там в Sun не осилили нормальный max.

> 1) ООП-решение 1. Паттерны - "", "", "".

Задолбали твои паттерны.

ИМХО, если язык не позволяет *ЛЮБОЙ* паттерн параметризовать и выразить в виде готового к использованию интерфейса/класса_типов/you_name_it..., то этот язык говно.

> А чем не устраивает стандартная практика сравнения объектов в Java?

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

>>"virtualbox is not an emulator, it can't VIRTUALISE non-x86 guests. for debian arm you need to use the qemu EMULATOR."

>Ок, и каким боком здесь "VirtualBox лучше, чем QEMU":)

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

> it can't VIRTUALISE non-x86 guests

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

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