печальная новость. прощайте, спарки.

>Зато шустрый Ок, как на этом "шустром" VirtualBox'е, запускать системы/софт для ARM, MIPS, PPC, etc?

>Для клиент-банка. Внутри машины ничего лишнего - никто не поломает.

LXC

> Ну ребята из Jane Street насчет write-once не согласны. Да и я тоже, хотя серьезных проектов на функциональных языках не писал...

Смотрел видео-ролик, с конференции осени прошлого года, на русском, одного из популяризатора F#. С блок-схемами, диаграммами и прочим. Ложь на лжи ("не нужно типизировать -> меньше нужно писать кода -> поэтому это лучше"), единственная спекуляция в теме, что из-за экспериментов в поддержке многопоточности F# и решили включить в MSVS 2010. Автор, в этом ролике, сам признался, что "write once".

> мелкая автоматизация помогла мне в использовании таких практик из экстремального программирования как ранние релизиы, подробное комментирование кода и автоматизированное тестирование.

Оно не касается. Все это постигается с годами, с опытом, и с изучением best practics от мировых гуру в проектировании/программировании.

> Идею ФП можно понять очень просто

У меня был опыт ФП программирования, несколько лет. Не на тех ЯП, которые вспоминают чаще всего при этом, но суть дела от этого не сильно меняется. Ухищрений применял много и писал тысячи строк кода. И поддерживал/переписывал написанное другими. И видел потуги людей написавшие такой код - использовать паттерны. Именно потуги, ФП не дает чистоты, ясности и строгости, на котором пишут в полностью ООП-стиле. Достаточно посмотреть С++-код, в котором не все используют ООП, тогда и видно, какое это г. это ФП, извините за эмоции.

> Это наоборот из объекта пытаются сделать функцию. См. шаблон Functor в GoF.

Такого паттерна в GoF нет.

По этой ссылке:

http://carpanta.dc.fi.udc.es/docs/java-courses/sdsu/www.eli.sdsu.edu/courses/...

- видно, что есть:

Design Patterns: Elements of Resuable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides, Addison-Wesley, 1995, pp 233-242, Command Pattern

Advanced C++: Programming Styles and Idioms, James Coplien, Addison Wesley, 1992, pp 165-170, Functor Pattern

Вот по этой ссылке:

http://jamesthornton.com/eckel/TIPatterns/html/TIPatt10.htm

- написано, что:

"Function objects

In Advanced C++:Programming Styles And Idioms (Addison-Wesley, 1992), Jim Coplien coins the term functor which is an object whose sole purpose is to encapsulate a function (since “functor” has a meaning in mathematics, in this book I shall use the more explicit term function object). The point is to decouple the choice of function to be called from the site where that function is called. This term is mentioned but not used in Design Patterns. However, the theme of the function object is repeated in a number of patterns in that book."

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

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

Люди в обычной своей жизни - оперируют понятиями "Дом", "Сад", "Река". Это объекты. Которые описаны классами. Это очень хороший маппинг жизни и программирования.

А если Вы хорошо знаете задачи такой должности как "Аналитик требований" (стандартная вакансия), писали по стандарту use cases и можете сказать в чем отличие модели из объектно-ориентированного анализа и модели из объектно-ориентированного проектирование - то все складывается как 2 + 2. - Почему ФП не нужен. :)))

Callback-функции я использовал очень давно, еще до того, как стал изучать ООП.

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

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

Я Интернет-казино переписывал, сделанное в таком духе... Мрак.

> Я ведь не топменеджер Sun. Откуда мне знать ?

Вдруг были ещё заявления по теме? Вижу, что не было.

> Ок, как на этом "шустром" VirtualBox'е, запускать системы/софт для ARM, MIPS, PPC, etc?

А вот интересно, насколько сложно будет перенести его и его виртуализатор на другие архитектуры? Чтобы эмулировать (или какой здесь правильный термин?) ARM на ARM, MIPS на MIPS, PPC на PPC и т.д.?

> Читаю комменты фанатов венды, запускающих её в VirtualBox, и
> ухохатываюсь!

Не подавись.

> Кстати. А вдруг RedHat решит занять нишу?

Вряд ли. У них своя. Немного другая.

А вот на каких задачах ФП будет проседать уже на самых первых тактах: ;)

"Проблемы моделирования предметных областей в информационных системах"

http://www.codenet.ru/progr/other/modeling-problems/

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

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

Лучше перестраховаться, но решить 1-2 задачи, чем на 25% решить 50 задач когда точно известно что если человек успел на поезда только на 25% то он дает ущерб всей структуре своей деятельности.

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

Если мозги не повисли на середине статьи, и если даже не подвисли на половине моих комментариев к ней - значит Вы приходите к выводу, что, черт, лучше в самом деле сделать, иметь - максимально "широкий" 3D-канал, а не узкий 2D, в котором все подвиснет если не в первую секунду, то на 2-3 секунде точно...

;) ;P

>По мне так JIT - гораздо лучше. То что и есть.

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

>Как с помощью AOT подгрузить код, скомпилированный на другой машине в Интернете, уже с оптимизированный под другой процессор?

Элементарно, AOT используется только локально, а инета подгружается всё тот же байт код.

> Элементарно, AOT используется только локально

Для некоторых задач. То что и у меня написано.

Пока читал прочитал 5-ую строчку, забыл 1-ую?

> Убейся лучше.

Придурок, как ты комп включаешь? Это же многоходовая шахматная комбинация.

>Придурок, как ты комп включаешь? Это же многоходовая шахматная комбинация.

Тебе задрот лучше молчать пока дяди уши не пооборвали.

Был опыт? Долго обрывали?

Был опыт? Долго обрывали?Re: Минюст США разрешил Oracle купить Sun Microsystems

>Был опыт? Долго обрывали?

Что тёлки не дают так хоть на форуме выипнуться решил?

Так, так, так. Уши обрывали, телки не дают. Чем еще повеселите?

Какое-то на редкость бодрое молчание... Ау...

А что отвечать? ФП ты "ниасилил", весь мир видишь через призму ООП, соответственно пытаться с тобой спорить - всё равно что учить собаку таблице умножения: можно но нахер не нужно.

О Господи, они убили солярку! (они ведь убили солярку, да?)

>А вот на каких задачах ФП будет проседать уже на самых первых тактах

> http://www.codenet.ru/progr/other/modeling-problems/

Статью писал похоже птица-говорун

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

1. По каким причинам над одной и той же областью физического мира может быть выделено множество различных предметных областей <...>

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

Вопрос "почему область физического мира плохо пересекается с предметной областью" совсем детский.

_________________________________

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

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

Прошу заметить "было бы".

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

Хорошо бы явакапец :} Глядишь, нормальные IDE появятся :|

>VirtualBox можно закапывать - не нужно.

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

>Зачем нужен VirtualBox? Игрушки с фотошопами запускать?

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

>прощай mysql

не сцы. форк сваяют. лицензия GPL вполне это допускает ;)

>Прощай openoffice.org

ну что за пораженческие настроения ?!? почему сразу прощай ? читаем - своюодная лицензия, форк, go-oo. читаем, делаем выводы и радуемся. ну если ларри сделает-таки финт ушами и прекратит разработку ООО, я буду искренне удивлён. ведь это очень популярный и нужный продукт.

>>Зачем нужен VirtualBox? Игрушки с фотошопами запускать?

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

Ещё VirtualBox идеально подходит для программирования под винду, включая системное программирование и работу с отладчиком.

>А вот реализовать любой ML-подобный язык под JVM - крайне сложно.

Scala ? http://torrents.ru/forum/viewtopic.php?t=1657675

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

Sun сами виноваты, что наняли херовых маркетологов. Да и распылились слишком(JavaME, JavaFX - тупиковые ветви).

> И судя по всему, яве придет полный конец. Что Оракл, что ИБМ, не заинтересованы в качественном развитии JVM. Им это не нужно. Для их индусокодеров она просто идеальна. А то что M$ пытается выводить свой .NET на качественно новый уровень, их это не колышет. Они думают, раз они такие крутые, яву будут пользовать в "нагрузку" к тем же самым БД, серверам приложений и прочей хрени.

В чём "качественно новый уровень" развития .NET? Groovy, JRuby, Scala, Clojure - языки, которые _уже_ используются в production(за примерами на InfoQ). Что-то про Boo, IronRuby, Nemerle(он вроде вообще перестал развиваться) пока такого не слышно. JVM тоже развивается: поддержка динамических языков и multi-core уже есть в OpenJDK.

> Тот же Новелл с явы мигрирует. У них есть моно и бумажка, которой можно прикрыть свою голую задницу. И кстати, Новелл по всем параметрам прав. Процесс развития явы обюрокрачен и непрозрачен (см. историю Сан vs. Apache). Сделать свою реализацию на партитетных началах крайне сложно, особенно J2EE. И с одной стороны весьма сомнительные патентные угрозы от M$, а с другой стороны сановская бюрократия.

Novell никогда не был Java-вендором! Sun, SAP, Oracle, IBM, JBoss, Apache = шесть сертифицированных реализаций Java EE. В Java EE 6 к ним вероятно присоединится VMware, недавно купившая SpringSource. Процесс развития другим быть и не может в текущих реалиях. Что касается "Sun vs Apache", то там дело в лицнезировании, и на развитии это Java особо не сказалось. Java EE 5&6 вообще развивается под воздействием Spring&Hibernate, а не вымышленных бюрократов.

>ну что за пораженческие настроения ?!? почему сразу прощай ? читаем - своюодная лицензия, форк, go-oo. читаем, делаем выводы и радуемся. ну если ларри сделает-таки финт ушами и прекратит разработку ООО, я буду искренне удивлён. ведь это очень популярный и нужный продукт.

Меня скорее не радует перспектива быть переписанным на java

>И видел потуги людей написавшие такой код - использовать паттерны.

Какие-такие паттерны? Из GoF? Ржу под столом.

>Такого паттерна в GoF нет.

Мне об этом рассказывать не нужно. На книжной полке стоит книжка, где этот паттерн есть. Functor - это объект с определенным operator() и можно Functor f = new Functor(); f(blah-blah);

Вот смотри. Значит ты пишешь что де есть объекты реального мира, которые могут описываться в терминах ООП. На самом деле, между объектами реального мира и объектами ООП существует нехилый impedance mismatch.

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

Так с чего ты взял, что объекты предментной области не могут декомпозироваться каки-то другим способом?

Далее, каждый класс является носителем части поведения объекта. И в общем случае это поведение атомарно: ты либо наследуешь его целиком и полностью, либо не наследуешь вообще.

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

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

В ФП ты комбинируешь поведение из кусочков программ с помощью комбинаторов. По сути дела f(g(h(blah-blah))). Только поскольку комбинаторы являются операторами функциональной композиции, записывается это немножко в другой нотаци.

Традиционный ООП не может работать с рекурсивными структурами данных. Это не значит, что с помощью ООП-языков из нельзя обрабатывать. Просто это сложно, без какой-то типизации, а в случае если нет сборщика мусора, так еще и нетривиальное управление памятью.

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

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

А в ФП подходе ты отдельно можешь оперировать понятиями "тип", "интерфейс" и "поведение".

В ФП нет никаких callback-функций. Нужно убивать в себе вредные идеи, почерпнутые из ассемблера. В ФП програма вычисляется, а не исполняется. В ФП ты управляешь потоком вычислений. Причем иногда ты это делаешь _неявно_. Те же самые "монады" в хаскеле - типичный пример такого управления. ООП в какой-то мере создано для неявного управления потоком вычислений, но без гибкости, присущей ФП. Кстати, традиционный подход, основанный на обработке сообщений, применяемый в С++, Java, you name it, еще менее гибкий, чем подход, основанный на обощенных функциях в каком-нибудь CLOS.

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

ФП математически обоснован, и для его освоения приходится читать достаточно нетривиальные тексты на математическом языке. Если ООП можно понять "интуитивно", то с ФП, а тем более с чистым ФП языком типа Хаскеля такие номера не прокатывают.

> А вот солярис неплохо бы закопать, наконец %)

С какой стати?

Ответ в вашем стиле:

Для всего прогрессивного человечества и мира было бы больше пользы и эффективности, если все разрабы плюнули на Линукс и начали развивать на выбор из следующего списка: *BSD, Haiku, Minix, (Open)Solaris, Plan 9.

То есть у нас остался x86(_64), Arm и Cell?

>В чём "качественно новый уровень" развития .NET?

F#. Увы, он перевешивает Scala. Scala - очень хороший объектно ориентрированный язык. Но не более того. Clojure - нишевое решение.

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

M$ постарается сдвинуть парадигму во-первых, в область ФП, во-вторых в область моделирования предметной области. И чем же ответит ява? Тем что под нее есть туева хуча реализаций вышеперечисленного? Своими зубодробительными спецификациями, с тоннами TBA и XML'а?

>Novell никогда не был Java-вендором!

Зато все его флагманские продукты на ней написаны.

>А вот реализовать любой ML-подобный язык под JVM - крайне сложно.

http://community.livejournal.com/ru_scala/6279.html Ы? ML-язык вроде.

>Можно говорить про оптимизации на уровне IL.

А не лучше ли говорить об оптимизации в ран-тайм на уровне JIT?

>Можно говорить про компиляцию IL -> машинный код целевого процессора (ребята из Mono хорошо отожгли c MonoTouch)

Йа уверен, что дальше чем написать на iPhone пару томбоев дело у MonoTouch не пойдет. Зато под андроид на JavaFX будут написаны сотни утилит. Хотя мне и трудно представить, каких еще программ не хватает на мобильниках? Вроде заметки/напоминалки/медиаплееры на любой вкус и размер уже написаны, что можно нового придумать?

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

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

VB основан на QEMU. Оттуда выпилили все, что могли, чтобы его ускорить, сделали guest tools и нормальный интерфейс для создания машин.

>Вроде заметки/напоминалки/медиаплееры на любой вкус и размер уже написаны, что можно нового придумать?

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

А игры - у-у-у...

>http://www.codenet.ru/progr/other/modeling-problems/

Интересная статья. Правда парсер чуть-чуть подглюкивал. Но меня этим не проймешь. Я читал статьи по теории категорий :).

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

Правда про ООП в статье не слова. А объекты, которые там поминаются это т.н. объекты предментной области, и к объектам из ООП они не имеют никакого отношения.

Строго говоря, ООП не является формальной системой. И то что написано в статье очень далеко выходит за рамки ООП. И как-то мне слабо представляется как написанное в статье можно реализовать в рамках парадигмы ООП.

А вот ФП - вполне себе формальная система, основанная на лямбда-исчислении и положениях теории категорий.

>http://community.livejournal.com/ru_scala/6279.html Ы? ML-язык вроде.

Ну по синтаксису на ML-подобные не похожа. Да и вообще Скала - т.н. чистый объектно-оринетированный язык. Всмысле там все - есть объект. Только кроме классов, но это не особенно важно, поскольку мы можем средствами языка создавать отдельностоящие объекты.

>А не лучше ли говорить об оптимизации в ран-тайм на уровне JIT?

Может и лучше. Только не всегда возможно, т.к. требует много ресурсов.

>Йа уверен, что дальше чем написать на iPhone пару томбоев дело у MonoTouch не пойдет.

А я уверен, что с помощью моно будет можно делать нативные приложения под андроид. Или сделать компиляцию CIL -> JVM. Т.е. без проблем портировать любое приложение под андроид не затрагивая компиляторы языков высокого уровня.

Хотя с нетерпением жду Cortex-A9 вообще, и Ti OMAP4 в частности. Он может аппаратно исполнять ява-байткод.

> F#. Увы, он перевешивает Scala. Scala - очень хороший объектно ориентрированный язык. Но не более того. Clojure - нишевое решение.

Перевешивает в вакууме? http://www.scala-lang.org/node/1658

> В .NET есть доступ на уровень IL. Это проще, чем уровень явского байт-кода. Поддержка динамических языков - крайне сомнительное приобретение.

JVM создавалась как single language vm, поэтому вероятно каких-то вещей в ней нет. А в чём преимущество CIL над JVM Bytecode?

> M$ постарается сдвинуть парадигму во-первых, в область ФП, во-вторых в область моделирования предметной области. И чем же ответит ява? Тем что под нее есть туева хуча реализаций вышеперечисленного? Своими зубодробительными спецификациями, с тоннами TBA и XML'а?

В 10 раз? ФП = Scala & Clojure. Моделирование = Jetbrains MPS, Spring Roo, IBM Rational. ..

Всё это рабочие продукты, которыми люди пользуются. А вы пока что троллите словами "зубодробительными спецификациями, с тоннами TBA и XML".

> Зато все его флагманские продукты на ней написаны.

Вам перечислить компании которые, наоборот, с .NET мигрируют на Java? Ах, да Novell со своими партнёрскими соглашениями с MS - это конечно же беспристрастная лакмусовая бумажка!

>А в чём преимущество CIL над JVM Bytecode?

Посмотри например на LLVM. Или дизайн 4-й версии GCC. IL позволяет разделять уровни компиляции. Особенно это жизненно необходимо, когда есть система компиляторов, как например в GCC.

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

C байткодом, конечно же можно тоже работать, но сложнее и намного неблагодарнее.

>ФП = Scala & Clojure.

Ага, и еще питон - ФП язык. Scala - объектно-оринетированный язык. Насчет clojure, увы не знаю, но если он похож на лисп/схему, то в нем динамическая типизация, а это совсе не то что нужно.

>Ах, да Novell со своими партнёрскими соглашениями с MS - это конечно же беспристрастная лакмусовая бумажка!

Это - показатель. И очень серьезный. Но время покажет, конечно.

>А вы пока что троллите словами "зубодробительными спецификациями, с тоннами TBA и XML".

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

>ФП математически обоснован,

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

>Вендекапец отменяеца? о_О

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

Единственным показателем успешности той или иной технологии для всех нас является количество вакансий и средняя зарплата. По обоим пунктам Java стабильно обгоняет C# последние N лет и никаких обратных тенденций не намечается.

Вы толком не ответили ни на 1 вопрос. Всего доброго.

>Что QEmu уже стал удобнее?

неудобно шубу в трусы заправлять (с)

удобство - понятие относительное. в отличии от функциональности

>В этой сделке виден четкий удар по MySQL.

миллионы говно-сайтов в опасности

а серьезным решениям плевать

>прощай mysql

это недоразумение вообще давно было пора закопать