Где в Google Closure есть Clojurescript? То что Clojurescript тесно интегрирован с Google Closure не значит что Clojurescript используют в гугле.

Где в Google Closure есть Clojurescript? То что Clojurescript тесно интегрирован с Google Closure не значит что Clojurescript используют в гугле.

Так я этого и не утверждал.

Вот что интересно - когда у руби новая версия, петонщики набигают и рассказывают, что руби сосет, а когда у питона новая версия, рубистам вообще насрать, у них никакого батхерта. Забавно, правда?

тогда получается что сlojurescript никто не использует и у js/coffee в браузере нет конкурентов

рубисты набигают к явистам

тогда получается что сlojurescript никто не использует и у js/coffee в браузере нет конкурентов

Нет же. Clojurescript — это новая технология, число пользователей которой стремительно растет за счет преимуществ, которые она предоставляет в сравнении с аналогами: https://github.com/clojure/clojurescript/wiki/Rationale

И какие же такие преимущества?

Ещё раз. Проблемы языка, т.е. javascript'а. В кофескрипте проблем быть не может, это не язык, это попытка исправить перегруженый, но привычный многим js на менее перегруженый и непривычный всем, ни на что не похожий синтаксис.

А какие проблемы в js - ну тут написано так много, что гугл расскажет лучше меня :)

Возможно сейчас у ruby и python есть фишки которых нет в node, но: - либо это не нужно

Таки не нужно?) http://www.ruby-doc.org/core-1.9.3/Array.html http://www.ruby-doc.org/core-1.9.3/Hash.html http://habrahabr.ru/post/140362/

либо это сделают в скором времени

Кстати вот реализация js от mozilla более функциональна https://developer.mozilla.org/en-US/docs/JavaScript/New_in_JavaScript/1.8 https://developer.mozilla.org/en-US/docs/JavaScript/New_in_JavaScript/1.7#Blo...
Никто, не знает, публикуют ли они где-нибудь свою js машину с новым IonMonkey?

- скорость

Ы я тут только что доклад посмотрел http://www.youtube.com/watch?v=tCG0aPNvkTs Внезапно: на js надо писать как на си, прототипирование это плохо, функции лучше помещать в объект, а не прототип и даже О_О копировать текст. Короче, я передумал: к черту v8. Кстати докладчик разрабатывает dart, и говоря о преимущества перед typescript (внезапно) назвал пакетный менеджер :р (который «исторически» нужен -_-)

Там не только js есть. Coffeescript вполне няшный язык.

Coffeescript заточен под кроссбраузерность, которая не нужна на сервере вообще.

А мужики то и не знали, пишут себе на чем-то, а это оказывается и не язык даже.
С++ который раньше в C транслировался тоже не язык?

В чем заточенность под кроссбраузерность? Кофе про дом ничего не знает.

java или js? Что нам к java бегать, у нас jruby есть! Их улучшения ~ наши улучшения)

А мужики то и не знали

The golden rule of CoffeeScript is: «It's just JavaScript». The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime.

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

С++ который раньше в C транслировался тоже не язык?

В чем заточенность под кроссбраузерность? Кофе про дом ничего не знает.

Например тут http://stackoverflow.com/questions/10773769/optimize-coffeescript-generated-j... хотя и сошлись, что все хорошо, но вероятно есть и другие примеры.

И еще раз

http://www.youtube.com/watch?v=tCG0aPNvkTs

Код который генерит coffee не оптимален с точки зрения V8. Наследование (которое киллер фича по сути) - зло. Вложенные функции, которые coffee повсеместно генерит - тоже не очень хорошо. На js, чем проще, тем лучше.

Дико извиняюсь, но не могу найти ни одной новости про ноду)

Позиция гугловцев: на js надо писать как на си, а в остальных случаях можешь не упоминать слово «скорость» ;)

непривычный всем, ни на что не похожий синтаксис.

Ну для тех кто тыкал Clojure или CL вполне привычный, ну или emacs юзал.

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

И какие же такие преимущества?

Я ведь дал ссылку в посте, на который вы отвечаете. Вы по ней сходили?

Там кратко, однако получить представление о подмножестве проблем JS, которые решает Clojurescript и не решает Coffeescript, можно.

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

Поясните для Gentoo'шника.

НЕНАВИСТЬ! Почему до сих пор не напишут автоупаковку gem'ов в deb'ы? Нахрена мне в одной ОС разводить бардак двумя системами установки пакетов?

Порядочные FreeBSD-шники устанавливают gem из портов.

Поясните для гентушника. Это выглядит примерно как emerge «ruby-on-rails-gem»? Если так, то годно.

Запили APT.

Потому что система пакетов ruby более совершенна. В дистрибутиве мэнтейнеры следят за версиями пакетов, и для дистрибутива верна только одна версия пакета. В руби же ты можешь использовать разные версии пакетов, bundler подберет тебе неконфликтное сочетание. В каждом отдельном приложении может быть свой перечень библиотек. Нафига завязываться на deb? bundle install как-то проще в 1000000 раз.

Так почему же на эту более совершенную систему пакетов ни один дистрибутив не перешёл?

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

Я не работаю на Mac/Win.

Один гем работает для Mac/Linux(/win...?). deb работает в Ubuntu/Debian. И усьо.

Я не работаю на Mac/Win. Я хочу чтобы у меня в Ubunt'е ПО ставилось однообразно, через apt-get. То что в ШINDOШS MacOS'ах до сих пор нет нормальных средств управления ПО — проблема негров.

Экосистема gem'ов вторгается в мою экосистему deb'ов и разрушает её. Одна ОС — один пакетный менеджер, иначе бардак и хана.

Вот что интересно - когда у руби новая версия, петонщики набигают и рассказывают, что руби сосет, а когда у питона новая версия, рубистам вообще насрать, у них никакого батхерта. Забавно, правда?

Поддерживаю!

Я не работаю на Mac/Win. Я хочу чтобы у меня в Ubunt'е ПО ставилось однообразно, через apt-get.

OKAY, ppa:ubuntu-ruby/ppa

Экосистема gem'ов вторгается в мою экосистему deb'ов и разрушает её. Одна ОС — один пакетный менеджер, иначе бардак и хана.

Если в репозитории той же Ubuntu добавить все gem'ы, то он прилично возрастет.
Зачет это простым людея? Конечно же не надо, поэтому у рубистов свой подход, не зависящий от установленной ОС.
Также это очень удобно при деплое web-приложения.
PS: На rubygems насчитывает 46566 gem файлов. Поэтому не говори ерунды.

Ответ очевиден. Никто не будет поддерживать 46к+ пакетов руби, 20к+ пакетов питона и т.д. То что ставится аптом - это то, что поддерживают мантейнеры, за что они более-менее готовы отвечать, что они смогут более-менее пофиксить в случае багов и т.п.

Обычному пользователю ничего этого не нужно. Такие инструменты как gem, bundler, rvm - нужны разработчику.

Но, с другой стороны даже обычному пользователю это может быть нужно, например аддоны к фф/хрому/опере: апт не умеет их ставить, пользователю приходится ставить их самостоятельно (тебе в том числе), «разводить помойку». Если бы apt умел бы делегировать установку специфичных библиотек, то помойки было бы меньше, а так ее только больше: он что-то ставит(по усмотрению мантейнеров), а что-то нет. Но еще раз, обычных пользователей эта ситуация устраивает, разработчиков нет, потому что им надо больше, больше чем умеет апт.

Да пусть заходят, чо..

Непонятными программы делают кривые руки программистов, перед которым все языки равны )

Друг заценил технологию RoR и порекомендовал её как стоящую для разработки софта. Я начал читать книжку по Ruby и после того, как я увидел, что есть 4(!) способа присвоить значение переменной, я понял, что Ruby — не мой путь. Я больше смотрю на вопросы поддержки, чем писания. А программа, написанная на языке, дающем делать такие вольности — это кошмар для поддержки.

Ничего не хочу сказать против Ruby, но даже послушав интервью с Matz, я вижу, что данный язык создавался больше как проект, не имеющий четких целей — реальный just for fun. Matz сам не ожидал, как будет использоваться его язык, но что самое плохо для меня — у него даже сейчас, после нескольких лет после создания языка, (как мне показалось по интервью) нет четкой картины по дизайну языка.

расскажите про проекты на пайтоне прикладные и не из веба и чтоб известные. Это не побег это специфичность задач.

Blade of Darkness — ничего круче во время её выхода не было. Написана была на python 1.5.

Разнообразие хуже безобразия.

Если в репозитории той же Ubuntu добавить все gem'ы, то он прилично возрастет.

Если добавить репозитарий свободного ПО той же ШINDOШS, то он прилично возрастёт. Зачем простым людям Firefox, Gimp, Gajim, VLC. Поэтому не говори ерудны.

В ubuntu-ruby/ppa с некоторой задержкой попадают все gem'ы? Если так, то это примерно то что нужно. И таки я не согласен, что добавление gem-deb'ов в основной репозитарий зло. Пользователь набирает apt-get install gimp и получает Gimp, набирает apt-get install some-ruby-application и получает это application. Почему мы должны ограждать пользователя от использования некоторого ПО просто потому что мы не считает его рубистом? Тем более, что всякая рубятина поставится только если будет нужна по зависимостям.

у рубистов свой подход, не зависящий от установленной ОС.

Иногда я начинаю сомневаться в неадекватности людей утверждающих, что все «рубисты» brain damaged.

PPA.

Ответ очевиден. Никто не будет поддерживать 46к+ пакетов руби, 20к+ пакетов питона и т.д. То что ставится аптом - это то, что поддерживают мантейнеры, за что они более-менее готовы отвечать, что они смогут более-менее пофиксить в случае багов и т.п.

PPA ответ на этот вызов. То что в основном репозитарии Ubunt'ы поддерживается мэнтейнерами Ubunt'ы, то что в Ruby PPA поддерживается мэнтейнерами Ruby PPA. Убедили. Все 100500+ gem'ов и pyp'ов (или как они там называются) в основной репозитарий пока добавить не получится.

Два пакета, которые я пишу используют разные версии одной и той же библиотеки, что делать?

По мне так надо в первую очередь задать вопрос: «А нахрена две версии одного и того же?».

Во-вторую очередь задаться вопросом: «А можно ли на одной версии поехать?».

Множить сущности — вносить ненужные ошибки и точки отказа.

Делать сложные вещи — легко, простые — сложно.

В любом случае нода летает по сравнению с вашими рубями и питонами.

Blade of Darkness — ничего круче во время её выхода не было. Написана была на python 1.5.

Я тоже люблю BoD, но там было ядро на Си или Си++, и скриптовая обвязка на Питоне.

Как-то пытался выучить ruby, чуть не блеванул от синтаксиса, остался на perl...

!!!! ЭТО ПЯТЬ !!!! :))))

Однозначно в квотезы!

PPA ответ на этот вызов.

Если apt действительно умеет одновременно держать в системе много(5-6) версий одной либы (чего я, честно говоря, не видел), то теоретически можно. Это можно генерировать автоматически.. Вопрос будет ли кто-то рад выкачивать ppa про 46к пакетов.. Вот тут-то и будет уместна фраза «более совершенная система» :)

А нахрена две версии одного и того же?

Рубисты не задают себе этот вопрос потому что проблемы нет. Но.. например, недавно пришлось заняться старым проектом, выкачал, «bundle install» и поехали.

А можно ли на одной версии поехать?

Это очень гипотетический вопрос. Ну нафига мне стараться ехать на одной либе в разных проектах.. Пакеты обычно содержат множество зависимостей, соответственно где-то что-то может конфликтовать. У раилз там одни зависимости, у голиафа другие (разработчики поставили и друг с другом не советовались), ну вот к чему мне париться.. Сейчас уже практически невозможно не пользоваться bundler, а главное незачем. Тут нет сложного, тут все очень просто, как при написании, так и при установке.

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

Вообще в руби есть акцент, на мой взгляд, на удобство в ущерб производительности, т.е. писать криво ради небольшого ускорение кода в руби не приветствуется.

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

Ты часто опираешься на порядок «именованных аргументов»? хрен-два, все ручками по элементу чекают «аргументы», а не итерируются по ним. Кейсы, когда упорядоченность реально нужна - 1-2% от общей массы кейсов использования хеша. А это значит, что разумный человек ввёл бы новую сущность для этих 1-2%, вместо того, чтобы замедлять остальные 98%.

Ты проверяешь порядок определения методов по результату #methods ? Порядок определения констант по #constants ? Когда ты делаешь

array1 - array2

Если уж OrderedHash.new для тебя слишком громоздко, можно было просто добавить ещё один префикс, аналогично %w, %r и прочим:

my_ordered_hash = %o{first: :arg, second: :arg}

А обычный хэш нужно было оптимизировать максимально, вплоть до смены его структуры... Но, разработчики Matz Ruby действительно излишне предпочитают удобство в ущерб производительности.

А почему бы не maglev? У него же вон какая классная фича есть - никакого session_store не надо..

Ты используешь maglev ? Кто вообще использует maglev ? Возможно я отстал, упустил что-то, но мне кажется, что в данный момент он вообще не юзается, а главное, до сих пор не догнал Matz Ruby по производительности, в то время как JRuby уже давно не мендленнее, а JRuby 1.7 становится намного быстрее.

А то, что «session_store» не надо, так это сомнительное удовольствие... Тем более, что по сути там такая же DB (реализованная на файлах berkleydb, если мне память не изменяет). <trololo-mode> Так что, вряд ли он легко выдержит горизонтальное масштабирование. </trololo-mode>

Впрочем, возможно я ошибаюсь, и вы гораздо подробнее можете рассказать о возможностях и опыте использования maglev.

«А нахрена две версии одного и того же?».

Потому что в новых версиях добавляют новые фичи и иногда ломают старые. Соответственно старый код, полагающийся на них, тоже сломается. А переписывать проект под каждую новую версию библиотеки невозможно, если проект чуть сложнее, чем hello world. Золотое правило: работает - не трогай!

Ты часто опираешься на порядок «именованных аргументов»?

Да, но какая при этом потеря производительности? Крохотная. Потеря производительности должна быть в больших хэшах, а этих еще нужно найти где применить (и там сильно оптимизированных хэш как раз очень пригодится).

Ты используешь maglev?

Я планирую) Просто, если задуматься, то будущее за реализациями на вм, т.е. за jruby, maglev и rubinius. Но rubinius.. не знаю, может быть только если все сообщество бросит mri и начнет пилить вм рубиниуса.. если это вообще по силам открытому сообществу.. Так что остается jruby и maglev. Скажем так, у maglev идеология правильная. К тому же под ним язык близкий к руби.

до сих пор не догнал Matz Ruby по производительности

Вообще я тестил, у меня был побыстрее процентов на 10-20%. Сам посмотри.. rvm install maglev.

А то, что «session_store» не надо

Вот уж хз... минус многочисленная сериализация-десериализация, думается, очень хорошо скажется на производительности. К тому же будет доступно то, что раньше не было, например, хранить невалидный объект AR, а не генерить каждый раз заново. У нас же CGI по сути сейчас: запрос - нагенерил кучу объектов, назапрашивал данные из бд, нагенерил еще объектов, отдал. Никакого состояния => куча лишних действий.

реализованная на файлах berkleydb

http://gemstone.com/products/gemstone

Именно так: впролете)

[trolmode] Просто тут же не си, тут думать надо) Язык медленный => мы должны за счет правильной архитектуры вытягивать[/trolmode]

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

То, что идёт в ущерб удобству языка, идёт в ущерб языку, ограничивая область его применения. Ассемблер производителен, но неудобен, его область применения узка. Производительность или удобство - это компромисс, баланс между ними зависит от назначения языка. Интерпретируемые языки занимают свою нишу, в которой важнее удобство. Они нужны для того, чтобы писать быстро и просто, а не заниматься преждевременной оптимизацией. Когда появляется нагрузка, можно начинать профилировать, оптимизировать и переписывать проблемные куски на других языках. Всякой задаче свой инструмент.

Анон незнает что рубисто можно тролить только по вопросам удобности, особенно тех кто начинал до 1.9.

У нас же CGI по сути сейчас...

А конкретно на рельсах так еще в один поток.

да.. школьник какой-то)

Я как-то поставил джем rails второй и третей версии в одном окружении, не работали ни вторые, ни третьи рельсы)

Это печально.

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