Clojure - lisp для JVM

Ура-а!!! Больше жаб, хороших и разных!!!

По существу дела: первый нах!

Попробовал helloworld (http://clojure.sourceforge.net/reference/getting_started.html) - работает. Пытаюсь придумать, где и как это можно использовать. :)

А чо? нынчо шоли модно все в жвм компилить? а нативный код не в моде?

> А чо? нынчо шоли модно все в жвм компилить? а нативный код не в моде?

а подумать не судьба?

> А чо? нынчо шоли модно все в жвм компилить? а нативный код не в моде?

За нативный код откатов не дают. Да и неэффективность нативного кода будет видна невообужённым глазом в то время, как тут все проблемы моно свалить на жабу.

> нынчо шоли модно все в жвм компилить? а нативный код не в моде?

Один и тот же .class у тебя заведется и на луниксе, и на венде, и на солярке со спарком ;) А в нативе ты задолбаешься саппортить миллиард архитектур

(. javax.swing.JOptionPane (showMessageDialog nil "Hello World"))

Ужас... Вот поэтому я и не люблю многоязыковые фреймворки.

Хотя если писать не приложения на Clojure, а модули для программы на настоящей Яве, то покатит.

>> нынчо шоли модно все в жвм компилить? а нативный код не в моде?

> Один и тот же .class у тебя заведется и на луниксе, и на венде, и на солярке со спарком ;) А в нативе ты задолбаешься саппортить миллиард архитектур

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

> (. javax.swing.JOptionPane (showMessageDialog nil "Hello World"))

> Ужас... Вот поэтому я и не люблю многоязыковые фреймворки.

А чего, мне нравится, всё чётко и по полочкам. :))

>задолбаешься саппортить миллиард архитектур

Да? А ты не в курсе, что jedit на какой-нибудь неLinux-неMac-неWin-неСолярис ОС хрен запустишь?! А долбаная Sun официально и своевременно поддерживает FreeBSD, NetBSD, OpenBSD, Tru64, HP-UX, BeOS, NeXTstep, IRIX, AIX и кучу других операционок???? "Кроссплатформенность" Явы - это фикция, пиар, очередное зомбирование народа аля-Майкасофт. И с безопасностью тоже самое. Пустой треп. А те же gcc и clisp работают на таких платформах, которые Sun и не снились. А Qt? Разве не кроссплатформенность? А FreePascal/Lazarus? Фтопку это быдло поделие (тормозное к тому же).

Concurrency and the multi-core support? Как с этим в С/С++? И опять же библиотеки - достаточно гиммора даже на одной платформе, какие-то из них можно использовать в мультипоточных программах, другие можно но нужно помнить о поводных камнях, специфичных именно для этой версии, третьи нельзя ни в коем случае.

Куда катиться мир.....

+1

Java кросплатформена, только по сравнению с .NET

>А ты не в курсе, что jedit на какой-нибудь неLinux-неMac-неWin-неСолярис ОС хрен запустишь?!
Расскажи это моей ОС/2

xterm как всегда прав, хотя я сам предпочитаю aterm ;-) режь её, режь правду-матку!

Ничего, скоро C++ на Java напишут и успокоятся :-(

> Ничего, скоро C++ на Java напишут и успокоятся :-(

Нет, потом биллогвардейцы во главе с команданте Мигелем перепишут Java под .NET и всем будет щастье :)

мля, если бы мне такое приснилось лет 10-15 назад, я бы сам добровольно отправился в дурку на лечение. Маразм крепчает с каждым днем.

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

не хватает еше Java на Java, вот был бы рулез. Как его там JaJa ?

> А чо? нынчо шоли модно все в жвм компилить? а нативный код не в моде?

http://clojure.sourceforge.net/rationale.html

Languages and Platforms

    * VMs, not OSes, are the platforms of the future, providing:
          o Type system
                + Dynamic enforcement and safety
          o Libraries
                + Abstract away OSes
                + Huge set of facilities
                + Built-in and 3rd-party
          o Memory and other resource management
                + GC is platform, not language, facility
          o Bytecode + JIT compilation
                + Abstracts away hardware
    * Language as platform vs. language + platform
          o Old way - each language defines its own runtime
                + GC, bytecode, type system, libraries etc
          o New way (JVM, .Net)
                + Common runtime independent of language
    * Language built for platform vs language ported-to platform
          o Many new languages still take 'Language as platform' approach
          o When ported, have platform-on-platform issues
                + Memory management, type-system, threading issues
                + Library duplication
                + If original language based on C, some extension libraries written in C don't come over
    * Platforms are dictated by clients
          o 'Must run on JVM' or .Net vs 'must run on Unix' or Windows
          o JVM has established track record and trust level
                + Now also open source
          o Interop with other code required
                + C linkage insufficient these days
    * Java/JVM is language + platform
          o Not the original story, but other languages for JVM always existed, now embraced by Sun
          o Java can be tedious, insufficiently expressive
                + Lack of first-class functions, no type inference, etc
          o Ability to call/consume Java is critical
    * Clojure is the language, JVM the platform

>Нет, потом биллогвардейцы во главе с команданте Мигелем перепишут Java под .NET и всем будет щастье :)

http://dev.mainsoft.com/Default.aspx?tabid=130#MS_IL_to_Java_ByteCode_Compila...

http://www.ikvm.net/

> не хватает еше Java на Java, вот был бы рулез. Как его там JaJa ?

Лишь бы глупость какую-нибудь написать. Java (язык) компилируется в байткод Java VM - Java на Java - чего не хватает?

> Куда катиться мир.....

К логопеду...

Я бы вместо New и Old, был бы более скромным, и написал standart и experimental, или original и extended.

>> Нет, потом биллогвардейцы во главе с команданте Мигелем перепишут Java под .NET и всем будет щастье :)

> http://dev.mainsoft.com/Default.aspx?tabid=130#MS_IL_to_Java_ByteCode_Compila.. . http://www.ikvm.net/

Уй, блиаааа... Спасите мой моск!

> По сути это диалект лиспа, компилируемый прямо в JVM bytecode, оставаясь прои этом полностью динамическим языком.

А вот опциональную типизацию могли бы и оставить... :)

Жабу не люблю, но определённый смысл в ней вижу. Равно как и рациональную нишу в пром.использование. Лисп на жабе - а почему бы и нет?

> Лисп на жабе - а почему бы и нет?

"Хороший" лисп - да, а вот таких и так "вагон и маленькая тележка"

find ./develop -iname \*cpp -exec wc -l '{}' ';' | awk 'BEGIN{a=0} a=a+$1 ; END{print a}'

155205 ;-)

>Ты хоть одну программу в жизни написал больше 10 тысю строк?

2400 строк. Правда на Perl'е. Если хочешь - пришлю)

>155205 ;-)

Это ты их написал, или kdevelop/qt uic? ;)

>Ты хоть одну программу в жизни написал больше 10 тысю строк?

Ну ты то их пишешь каждый день. Пшел нах зассаныч!

> find ./develop -iname \*cpp -exec wc -l '{}' ';' | awk 'BEGIN{a=0} a=a+$1 ; END{print a}'

find ./develop -iname \*cpp -exec cat '{}' \; | wc -l

так короче :)

>gcc очень сильно завязан на библиотеки, особенности управления памятью, реализацию потоков и прочего добра.

Ява тоже завязана, притом трижды и через задницу, в лучших традициях кришны.

точно ;-) это наш шлюзик VoIP, не kdevelop точно find . -iname '*.cpp' -or -iname '*.cxx' -or -iname '*.h' -exec cat '{}' \; | wc -l 149218

gcc и qt, конечно, кроссплатформенные. Но вот бинарники, которые они собирают, работают только на той же платформе, на которой их собрали. Это если не учитывать мелкие особенности архитектур, следить за которыми всё равно необходимо. А тут преимущество в том, что единжоды написанная программа запустится на любой архитектуре, на которой запускается jvm.

Разве так сложно поддерживать бинарники для трех-четырех платформ, на которых работает JRE?

find . \( -iname '*.cpp' -or -iname '*.cxx' -or -iname '*.h' \) -exec cat '{}' \; | wc -l

а вот так 478022 :-)

Это не преимущество по нескольким причинам. Во первых компиляторы улучшаются и модернизируются что приводит к разным по эффективности машинным кодам эквивалентным исходникам. Во вторых исходники видно и их можно менять без извращений любому кто хочет. В третьих с чего вы взяли что на любой jvm? ...

> find . \( -iname '*.cpp' -or -iname '*.cxx' -or -iname '*.h' \) -exec cat '{}' \; | wc -l

> а вот так 478022 :-)

рекомендую попробовать while true; do echo "hello";done | wc -l , получится побольше :)

Может быть и не сложно, но всё равно это дополнительная трата времени программиста. Имхо, скорость разработки сейчас всё же важнее (я не имею ввиду критичные к скорости приложения).

>В третьих с чего вы взяли что на любой jvm?

Так заявляет Sun :)

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

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

>А долбаная Sun официально и своевременно поддерживает FreeBSD, NetBSD, OpenBSD, Tru64, HP-UX, BeOS, NeXTstep, IRIX, AIX и кучу других операционок????

А Sun и не обязана поддерживать Java на этих ОС. Этим занимаются разработчики этих ОС. Так например для AIX, OS/290, OS/400 существует IBM Java SDK, для HP-UX есть Java от HP, и т.д. Sun для этих ОС лишь сертифицирует JVM на совместимость со стандартом. Конечно есть проблема не очень качественных JVM для BSD и других не очень распространенных ОС. Причем сами эти ОС уже заброшены самими их производителями.

Могу перечислить ОС для которых существуют современные JVM на которых трудятся промышленные решения: Windows, Linux x86, Linux x86-64, Linux PPC, Solaris x86, Solaris x86-64, Solaris SPARC, AIX, OS/390, OS/400, HP-UX (Itanium), QNX, Mac OS X. Может и еще для чего-то есть, но про это у меня нет информации. Так что не нужно говорить что у Java нет кросплатформенности. Причем на всех этих платформах твое Java приложением действительно будет работать одинаково.

а вы думаете что вообще чего-нить выдет?

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

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

Наверно я нечётко указал, к чему относился мой пост. Я предлагал при написании новых языков программирования компилировать их не в код Java-машины, а транслировать в сишный код, который потом можно скомпилить любым коспилятором на любой платформе. А об утечках памяти и работоспособности пусть заботятся авторы транслятора.

> а вы думаете что вообще чего-нить выдет?

Должно выдать \infnty. Правда за бесконечное время :)

Да. Очень неплохой подход.

Пример: http://live.gnome.org/Vala

вам поможет backtrace_this и libsegfault