ketamin

Впрочем, как и мне так и не стали понятны трудности вашего "среднего уровня".

Откуда? Вы .Net формошлеп мастер по накладыванию формочек не имеющий даже теоритической базы, но рассуждаете о "накладных инструментах" (мем). Наверно распечатали мануал по скале и вы уже на них писали)))? Кстати Вы инструмент накладываете когда код пишите копипастите? Ленивость от жопы отличить не может...

Жги)

Так это все же имитация функционального программирования.

как и скала))

В том и дело, что сейчас есть 2 более менее ненакладных инструмента для таких целей (т.е. без танцов со сторонними "подключателями")- это Scala и Java 8.

Ок 

А вы пробовали писать это на настоящем функциональном языке, а потом подрубать его с помощью инструментов вроде wxWidgets?

В Erlang ничего никуда подрубать не нужно все из коробки)
 

ЗЫ кстати Scala с акторами работает куда как попроще, чем Java.

ЗЫ кстати акторы скалы (Akka) после Erlang'а убогое говно да и после JActor

Что Вы понимаете под термином накладные расходы?
 

И с помощью чего вы реализовали логику в многопоточной среде?

Java7 + функциональная парадигма, пришлось писать аналог JActor.

ketamin сказал(а) 09 Июл 2014 - 01:05: JVM прежде всего пилится для императивной Java поэтому приходится мириться с кривым выводом типов, отсутствием оптимизации рекурсии и ленивости. Ленивость вроде и была, но в виде JIT-компиляции. Хотя может тут все еще круче должно быть.

иди почитай теорию по функциональным языкам
 

ketamin сказал(а) 09 Июл 2014 - 01:05: Было на уровне языка а теперь на уровне JVM т.е. теперь стало возможно оперировать функциями а не функциональными обьектами так же получили полноценные замыкания. И в тоже время JVM все еще не оптимизирована под функциональное программирование? Не понимаю.

отвечал выше...
 

Java более менее знаю

как джуниор а Java. андроид это не джава это частичная имплементация API из джавы, по другому работает с метоинформацией (рефлексия), отсутствие JMM (не могу гарантировать что мои оптимизации многопоточного кода будут работать корректно). Ну и специфика разработки другая.
 

Все-таки накладные расходы на такое сопряжение- не всегда удобно.

тебе не похрен или ты графику рендерить собрался? )))

Мне функциональное программирование нафиг было не нужно пока не пришлось строить сложную логику в многопоточной среде. 

Если интересует язык на JVM посмотри в сторону Clojure, правда первое время смайлики могут раздражать (у нас британцы на ней пишут).

Была имитация функциональности- те же Comparator-s.

Было на уровне языка а теперь на уровне JVM т.е. теперь стало возможно оперировать функциями а не функциональными обьектами так же получили полноценные замыкания.
 

Насчет "незаточенности" не знаю- а какие требования выставляются к среде исполнения, чтобы она считалась "заточенной" под функционалку? И где в Scala костыли?

JVM прежде всего пилится для императивной Java поэтому приходится мириться с кривым выводом типов, отсутствием оптимизации рекурсии и ленивости.
 

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

Так может скала вам ненужна и хватит восьмой джавы? Посмотрите в сторону стримов.

Разделение формочек от вычислений больше от фреймворка зависит, это если у Вас локальное приложение и платформа Java, то что вам нужно, можете написать не только на скала а на любом JVM языке… Erlang дружит с wxWidgets - тожке не проблема... Если Апп большой и толстый разные части будут на языках которые больше подходят для задачи. Вы просто так активно пиарите скалу, а в ней плюсов то не осталось после Java 8 да еще отсутствующая транзитивность с последней требует отказаться от JEE и Spring и перелезть на Play… шаблонизатор на scala скажи привет JRebel ($) иначе повесишься… а нужно права настроить с авторизацией нужно спринг тащить…