Потому что уже плотно пересел на .NET и F#. И теперь в жабий мир возврата нет, там слишком всё уныло даже при наличии такой всей из себя красивой Scala.
Есть mono. Более чем приличный. Всякая идиотская гуйня мне даром не нужна, от ASP.NET нужна самая базовая функциональность (аналогичная жабским сервлетам). Всё это Mono умеет.
> Есть mono. Более чем приличный. Всякая идиотская гуйня мне даром не нужна, от ASP.NET нужна самая базовая функциональность (аналогичная жабским сервлетам). Всё это Mono умеет.
ТоварищЪ, предлагаю вам идти и писать на моно замечательные программы. Мы говорим о жабе в контексте gnu/linux (хотя для жабы, в отличие от всяких поделок, вроде дотнета, контекст редко имеет значение).
Да кстати, раз уж вы все равно зашли в мою тему... киньте ссылки на success story использования моно в промышленной разработке (на новелл ссылки кидать не надо (если они есть)).
Мне плевать, о чем вы там "говорите", в том сообщении, на которое я отвечал, контекст не был указан.
И жаба лично меня абсолютно не интересует - слишком убогая и глупая, бесперспективная технология. И, да, мнение всяких недоумков, считающих иначе, меня абсолютно не колышет. Я верю деньгам, а не недоумкам.
> А если нет, то хотелось бы услышать почему (естественно только в том случае, если вы о нем вообше слышали).
Слышали и он мне очень нравится. Основная причина — средняя квалификация сотрудников в той компании, где я сейчас работаю. Т.е. код будет невозможно поддерживать после меня. Второстепенная — наработанная инфраструктура вроде Hibernate, Spring, J2EE. Можно конечно делать половину на Java, половину на Scala, но это слишком хлопотно. Ну и ещё хотелось бы хорошую поддержку в Eclipse.
>Есть mono. Более чем приличный. Всякая идиотская гуйня мне даром не нужна, от ASP.NET нужна самая базовая функциональность (аналогичная жабским сервлетам). Всё это Mono умеет.
То есть ты лабаешь под ASP.NET и как же в этом тебе помогает F#? Серьезно, чего в жабе для JSP/JSF не хватает, что есть в .NET и F#?
По теме: не думаю, что в xСССР наберется хотя бы 5 фирм, использующих Scala в продакшене. Скорее все сейчас пробуют на зуб, изучают, да и знаюищх ФП в достаточном для использования Scala объеме не найти, а все знающие, как vsl, работают на запад.
>И жаба лично меня абсолютно не интересует - слишком убогая и глупая, бесперспективная технология.
И .NET серьезных людей и меня не интересуют, слишком убогая и глупая, БЕСПЕРСПЕКТИВНАЯ УМИРАЮЩАЯ технология. Перспектива есть у жабы в контексте развития платформ Nokia J2ME, Android и написания одинаковых приложений под десктопы и мобилки
> То есть ты лабаешь под ASP.NET и как же в этом тебе помогает F#?
Лабаю. Помогает.
> Серьезно, чего в жабе для JSP/JSF не хватает, что есть в .NET и F#?
Нормального языка не хватает. Жаба убога и ублюдочна. А на F# тривиально пишутся декларативные EDSL. Мне от ASP.NET ни хрена не надо кроме поддержки сессий и сервлетоподобного интерфейса. Раньше я всё то же самое делал на Java + SISC, но меня это достало. Теперь и язык хороший и мощный, и дурного наследия паршивой VM не чувствуется.
> По теме: не думаю, что в xСССР
Кого вообще интересут загнившие страны третьего мира? Им и положено отставать лет на 20-30 от цивилизации.
> И .NET серьезных людей и меня не интересуют
Ты к серьёзным людям никак не относишься.
> Перспектива есть у жабы
Нет никаких перспектив у VM, заточенной под один единственный (и откровенно ублюдочный) язычок. Только мультипарадигменные VM и рулят.
> И, видно, тебя тоже - иначе ты бы тут не тусовался.
Из того, что меня интересуют рускоязычные собеседники, не следует, что меня интересует экономика бСССР. На этих странах давно можно ставить крест, ничего кроме деградации им не светит.
>Конкретно для уеб-программирования это декларативные языки для описания workflow и ORM, и тому подобный высокий уровень.
Вообще-то Spring уже написан, а в нем и ORM есть и workflow, так что накой нужно еще раз их на EDSL писать, ума не приложу. Наверное просто чтобы Газпромовский бюджет подоить?
Это реализация .net-а. Интересно насколько качественная? Например в яве, которую ты не любишь(и на которую мне пофиг) есть хороший сборщик мусора. В 7 так вообще космический.
Потом прелести .net-а для разных языков идут от реализации виртуальной машины. Я верю, что микрософт могли сделать ее гибкой. Но не известно насколько моно удалось повторить их результат? Тот же DLR например.
ЗЫ: а почему не взять Ocaml вместо F#? Тем более с Ocsigen там даже больше чем сессии и сервлеты, да и бегать оно будет пошустрее F# на моно.
> Это реализация .net-а. Интересно насколько качественная?
Достаточно качественная. Для моих задач хватает.
> Например в яве, которую ты не любишь(и на которую мне пофиг) есть хороший сборщик мусора. В 7 так вообще космический.
Это так. Особенно завидую class GC. Но все остальные недостатки убогой JVM перевешивают это единственное преимущество.
> Потом прелести .net-а для разных языков идут от реализации виртуальной машины.
Не от реализации, а от самой спецификации. Отсутствие жесткого лимита на размер метода, префикс .tail, явный боксинг-анбоксинг, unsafe-инструкции, указатели на функции (тип IntPtr) - всего этого достаточно для эффективной реализации весьма широкого диапазона языков.
> Тот же DLR например
Вот уж этого то как раз мне даром не надо.
> ЗЫ: а почему не взять Ocaml вместо F#?
Так я код в рантайме генерю, для этого пришлось бы использовать байткодовую версию ocaml, которая тормознее.
> Не от реализации, а от самой спецификации. Отсутствие жесткого лимита на размер метода, префикс .tail, явный боксинг-анбоксинг, unsafe-инструкции, указатели на функции (тип IntPtr) - всего этого достаточно для эффективной реализации весьма широкого диапазона языков.
Ага, понял. Виталик помнится на sql.ru много про это писал.
>> ЗЫ: а почему не взять Ocaml вместо F#?
> Так я код в рантайме генерю, для этого пришлось бы использовать байткодовую версию ocaml, которая тормознее.
А как сам F#, сильно от камля отличается? А то есть одна задачка и может получиться, что mono-вская VM хорошо на нее ляжет. Особенно интересует поддержка ocamlyacc/ocamllex?
Отсутствуют такие операции, как dup, swap, и т.д. - произвольная работа со стеком не допускается. Соответственно, байткод в .NET - это просто "плоский" вариант для AST, тривиально восстанавливаемый в нормальное дерево. Это очень упрощает (и ускоряет) JIT-компиляцию, даёт больше возможностей для опимизации при этом.
В общем, при разработке IL они явно очень серьёзно проанализировали все недостатки JVM, это реально следующее поколение виртуальных машин, на голову превосходящее предыдущие.
> А как сам F#, сильно от камля отличается?
Теперь уже да. Много экспериментальных фичей (те же banana brackets, например), оказавшихся дюже удобными. Don Syme - умный дядька.
> Особенно интересует поддержка ocamlyacc/ocamllex?
Почти один в один, код можно без изменений переносить.
> Теперь уже да. Много экспериментальных фичей (те же banana brackets, например), оказавшихся дюже удобными. Don Syme - умный дядька.
Ну так даже интереснее будет. Главное чтобы он в mono был полностью реализован.
> Почти один в один, код можно без изменений переносить.
Отлично.
> Отсутствуют такие операции, как dup, swap, и т.д. - произвольная работа со стеком не допускается. Соответственно, байткод в .NET - это просто "плоский" вариант для AST, тривиально восстанавливаемый в нормальное дерево. Это очень упрощает (и ускоряет) JIT-компиляцию, даёт больше возможностей для опимизации при этом.
Кстати, в SecondLife mono используют как VM для своего языка. Теперь понятно, почему они выбрали его, а не ява-машину.
Вобщем, спасибо за информацию, буду знать куда дальше копать.
> Главное чтобы он в mono был полностью реализован
Эпизодически с новыми версиями возникают мелкие проблемы с работой в Mono, но к чести Microsoft, решаются они очень оперативно. Так что, да, принципиальных трудностей с F# в Mono нет.
> Теперь понятно, почему они выбрали его, а не ява-машину.
Конкретно mono ещё и очень удобно встраивать в приложения, см. примеры в исходниках. Пара строк на всю инициализацию VM, легко делать биндинги к Си - ни в какое сравнение не идёт с кошмарным JNI.
>Оно там настолько через жопу, что лучше бы его и не было.
Ага,ага, а ты у нас светоч, пришел дать огонь людям и научить их правильно ORM использовать. Что-то таким залихватским заявам я еще в 5-м классе верить разучился.
>А делать в три строчки то, что на Spring + Hibernate делается в сотню килобайт корявых XML-ных конфигов - это выгодно, удобно, надёжно.
Примеров "трех строчек на F#" мы, естественно, не дождемся. Вообще это мое любимое занятие макать питонистов и монокодеров в их вранье про уанлайнеры, которые они так и не могут продемонстрировать
>Оно там настолько через жопу, что лучше бы его и не было.
Ага,ага, а ты у нас светоч, пришел дать огонь людям и научить их правильно ORM использовать. Что-то таким залихватским заявам я еще в 5-м классе верить разучился.
>А делать в три строчки то, что на Spring + Hibernate делается в сотню килобайт корявых XML-ных конфигов - это выгодно, удобно, надёжно.
Примеров "трех строчек на F#" мы, естественно, не дождемся. Вообще это мое любимое занятие макать питонистов и монокодеров в их вранье про уанлайнеры, которые они так и не могут продемонстрировать
>В общем, при разработке IL они явно очень серьёзно проанализировали все недостатки JVM, это реально следующее поколение виртуальных машин, на голову превосходящее предыдущие.
Java 7 VM уделает все написанные до нее VM.Это будет реально следующее поколение виртуальных машин. Не сцы.
>Теперь уже да. Много экспериментальных фичей (те же banana brackets, например), оказавшихся дюже удобными.
Дюже удобное я видел, FoxPro 2.6 называлось. Вот только как приспичит за рамки этой FoxPro выйти, так тут же удобства оборачиваются ограничениями
>Конкретно mono ещё и очень удобно встраивать в приложения, см. примеры в исходниках. Пара строк на всю инициализацию VM, легко делать биндинги к Си - ни в какое сравнение не идёт с кошмарным JNI.
Вот только "упс!", клоун забыл, что для Solaris и zOS Mono не сделано и не будет сделано никогда. Прежде всего по политическим соображениям, дабы избежать вендор лок-ин