Анонсирован проект Topaz — реализация языка Ruby на Python

Функции hist

В чём проблема? Посчитать или отобразить? Посчитать - модуль Math, отобразить - Canvas.

Так что иди, попробуй закопать, приходи, когда обламаешься.

Мне это не нужно. Кому нужно, закопают.

В чём проблема?

Ты невнимателен. Проблема в отсутствии аналогичной функции.

Мне это не нужно. Кому нужно, закопают.

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

JS и Python не умеют не тормозить.

Ты сейчас о V8 и CPython? Или об извратах на уровне сабжа?

Ты опять свою ахинею несешь?

1) Как ты посмел ставить V8 и SpiderMonkey в один ряд с HotSpot? 2) У тебя маниакальная зависимость от скорости в вакууме. Как минимум по следующим причинам: V8/SpiderMonkey однопоточны, как и CPython, и MRI; они получают скорость, от того, что JS минималистичен и ориентирован на встраивание. То что, он не строго типизирован, не усложняет реализацию интерпретатора, так как по дизайну языка видно, что он делался не в угоду пользователей, а в угоду удобства реализации интепрератора.

Если не веришь про многопоточность, то посмотри на мучения MongoDB, которые не могут реализовать человеческий Map/Reduce. Причем проблема наблюдается как с их дефолтным SpiderMonkey, так и при сборке с V8. Помимо этого, там нет никакой речи о JIT, так же как и в браузере.

Единственный проект, из более менее крупных, который использует V8 с JIT - это Node.js. При этом, за все время, он как был середнячком, так и остался, вне зависимости от того, лучше стал интерпретатор или хуже.

3) Почему ты всегда забываешь о Lua, которая еще быстрее JavaScript?

4) Когда ты научишься рассуждать исходя из применимости и ориентированности инструментов, а не исходя из каких-то тестов в вакууме? Смотришь на тесты SpiderMonkey в Кракене, который очевидно заточен на SpiderMonkey, и радуешься как там все быстро. Где твоя логика?

Почему ты всегда забываешь о Lua, которая еще быстрее JavaScript?

Потому что её не встраивают вместо/наряду с JS во второй по популярности в мире рантайм. А почему её не встраивают, кстати?

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

JS уже давно вышел за пределы "простых эффектов в браузерах", это могут не понимать лишь IE-дегенераты. Но тем не менее, что мешает наряду со <script type="text/javascript"> запилить какой-нибудь <script type="text/lua">, не ломая при этом устои, а просто добавляя +1 вариант взаимодействия?

В вбскрипт так уже пробовали, не прокатило.

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

А сейчас тоже не прокатит.

Если во всех браузерных движках одновременно внедрят, прокатит. Другое дело - смысла в этом мало.

во всех браузерных движках одновременно внедрят

Такого не будет.

Ну да, гекарям хоть бы с инпутами разобраться.

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

И я объясню. То, что на JS от безысходности начали писать крупные приложения в браузере, появились разного рода MVC-фреймворки - еще ни о чем не говорит. Это говорит лишь о том, что веб является продуктивной и востребованной средой, и фреймворки появляются на том, что есть.

Но от этого, Javascript не перестал быть языком с отвратительным дизайном и отвратительными решениями, начиная от синтаксиса, кончая реализацией прототипирования и стандартной библиотеки. Доказательством моих слов, может быть также появление различных Data.js, underscore.js, RubyJS, Dart, CoffeeScript и многих других проектов, которые пытаются дать возможность жить со всем этим ужасом в браузере называемом JavaScript. Уже не говоря, о становлении принятым стандартом SourceMap, который направлен не только на препроцессоры CSS, но и на CoffeeScript к примеру.

Говоря о JavaScript вне браузера, вспоминается Node.JS и MongoDB. Это такие самые крупные.

Давай взглянем поближе.

Node.JS. Замеры приложений и сравнение с альтернативами показало, что оно: полностью сливает Erlang по всем показателям (не говоря о языке, а говоря о технической платформе и аналогах написанных на Erlang), оно где-то рядом с EventMachine, Twisted (питоновскому Tornado, оно тоже сливает). Многопоточности нет, интерпретатор однопоточен. Загрузка процессоров полезной работой происходит так же как и на Ruby, и на Python - несколько экземпляром Node.js приложений. Поддержка отвратительна, инструменты еще хуже, а приложения изнутри похожи на callback hell. Это не акторы, а именно куча callbacks, которые очень сложно тестировать, и зачастую очень сложно понять логику, ибо нелинейно.

При разработке на serverside, неоправдана разработка на CoffeeScript. Ну может сейчас только с помощью source map, хоть какая-то отладка появилась. Как рассказывал Ян Йонгбум из Cloud9, они принципиально не используют CoffeeScript по этим причинам.

То есть на лицо огромные проблемы в написании и сопровождении больших ненаколеночных проектов.

Второй проект - MongoDB. Я уже писал о их мучениях выше. Повторяться не стоит.

Вспомним еще приколы последнего времени с sort к примеру. Язык делает вещи, за которые он просто должен быть запрещен. Он нарушает принцип наименьшего удивления. Это должно караться, и караться строго. Отмазки, мол у нас «такой дизайн языка» не катят.

Из того, что я ненавижу, это его неконсистентность, как и в PHP.

Date.getDay() - возвращает день недели, Date.getDate() - возвращает день месяца. Почему не выбраны имена getDayOfWeek, и не getDay соответственн для этих функций я не понимаю.

В итоге я не вижу ни одного плюса, который бы дал возможность рассматривать JS, как что-то серьезное, для хоть какой-то более менее серьезной внебраузерной разработки. Я не отрицаю, что проекты есть, и довольно крупные, типа LinguaLeo, и Cloud9 работающие на нем, но я боюсь подумать, зачем вообще существует Cloud9, и сколько могли бы сэкономить на разработке LinguaLeo, выбери они другой язык/технологию.

Собственно, даже у Mail.ru хватает мозгов использовать Rails/Python, наряду с Perl, но никак не JS.

Что касается альтернативных языков в браузере - Firefox умеет Python. Если соберешь с опцией. Но опять таки - зачем? Есть многолетняя инерция, и просто так «запилить» альтернативу было бы решением не просто пустым, но и какой-то мере глупым на данный момент. Так как единственный путь для JS - превращение языка во что-то человеческое и правильное.

Rails/Python Ruby/Python

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

Собрат Анон, ты хотел сказать интепретируемые?

Как ты посмел ставить V8 и SpiderMonkey в один ряд с HotSpot?

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

нет никакой речи о JIT

лол https://wiki.mozilla.org/JaegerMonkey

Почему ты всегда забываешь о Lua, которая еще быстрее JavaScript?

Что такое lua, в каком месте оно быстрее..

Почему ты все время врешь?

_ИМХО_ свободное сообщество не сможет реализовать vm уровня V8, SpiderMonkey, HotSpot (в ближайшее время).

PyPy по принципу работы от V8 и CPython не отличается.

в каком месте оно быстрее..

В таком.

Ты не понимаешь совершенно о чем речь. Ты не делаешь различия в уровне и применимости разных виртуальных машин, аля V8/SpiderMonkey и HotSpot/ErlangVM. Ни зачем они, ни какие у них функции.

Даже не касаясь языка.

JaegerMonkey уже используется в каком-нибудь production решении c включенной JIT-компиляцией? Или это очередной эксперимент Mozilla Foundation?

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

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

Хотя с моей стороны было вообще грубостью назвать V8 и SpiderMonkey виртуальными машинами как такомыми, так как это интерпретаторы.

Ну.. просто ты невменяем) Это вершина достижений человечества в области программирования. Доказательство того, что динамические ЯП могут быть столь же быстры как и статические. Т.к. я являюсь фанатом динамических языков программирования, то для меня это важно.

В том месте точно нет, но мне стало интересно, http://habrahabr.ru/post/113250/ короче нет, не быстрее.

Ладно, убедил. Но это не отменяет того, что JS — говно.

С трансляторами вполне сносен.. без трансляторов пока неудобен.

Во сколько расплодили. http://altjs.org/

Ну а чем это реально плохо?

Смотри Mystra_x64, диалект js с более строгой типизацией. http://ckknight.github.com/gorillascript/#addition

Да какой ты нафиг фанат. Ты кроме Ruby и JS ничего не знаешь. А то что знаешь, знаешь посредственно, ведь даже не можешь понять, когда в Ruby надо использовать include, а когда нет, и для чего оно вообще есть.

А уровень знакомства с другими динамическими языками, оставляет желать лучшего, для «фаната». Ибо доказывать, что в Python нет модулей, и что реальные модули только в Ruby - это простите, полный маразм.

Как после этого относится к тебе, как хотя бы к фанату - не знаю. Ты скорее фанат «графиков сравнения интерпретаторов JS в вакууме со всем, чем угодно».

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

// and for some oddities false + false === 0 false + true === 1 true + true === 2 null + null === 0

Ахах. Вот это консистентность и логичность языка. Вместо присвоения «+» применяемого к двум булевым аргументам, семантики логического сложения, они их приводят к простому арифметическому, показывая мол «данные ничто». Тип данных должен определять допустимые операции, а не операция допускать приведение типов.

пардон за съехавший код выше

// and for some oddities
false + false === 0
false + true === 1
true + true === 2
null + null === 0

когда в Ruby надо использовать include, а когда нет

Этого никто не может понять: http://stackoverflow.com/questions/1282864/ruby-inheritance-vs-mixins http://yehudakatz.com/2009/11/12/better-ruby-idioms/

в Python нет модулей

В аналогии руби - нет, там и классов нет по этой аналогии.

В аналогии руби - нет, там и классов нет по этой аналогии.

Мне нравится система конструирования классов(и => объектов) в руби, в питоне нет ничего подобного (да и почему оно должно там быть..)

Ну что я и говорил. Ты не понимаешь семантики. Модули в Ruby, правильнее называть Mixin, так как это по поведению они и есть. И путаться с их применением негде. Module - это namespace, это аналог статического класса, или синглтона в какой-то мере, и это Mixin, который содержит общий функционал для нескольких классов (но не для разнесения жирного класса по кускам). Всего три применения, и путаться в них негде.

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

Но такое решение и применение, вовсе не делает модули питона неправильными, или то, что в нем отсутствуют классы.

Если вообще говорить о классах, то по каноническому представлению Алана Кея об ООП, настоящим ООП языком можно назвать Erlang, а не C++/Java/Ruby/Python.

И классы в Python, вполне себе классы. И вполне себе похожи на Ruby. Разница лишь в том, что в Ruby private/protected/public более строги, а в Python они лишь как соглашения - чем они по сути и являлись. Это семантические инструменты программиста, а не инструменты языка.

Ты просто Python не знаешь.

настоящим ООП языком можно назвать Erlang

Кому-то от этого стало легче?)

Всем, кто способен разобраться в иронии сего факта. Но ты же даже не знаешь, кто такой Алан Кей, и в чем его понимание ООП, и почему Erlang (при этом сам Erlang как таковой тут не играет никакой роли).

compile-to-JavaScript language

Ещё один велосипед. Похвально, конечно, но, похоже, они изобрели ещё один язык со значащими отступами %)

Нет, именно динамические. С динамической системой типов и с eval().

сначала JRuby, теперь Topaz. осталось реализовать интерпретатор на Haskell или OCaml или вообще под BEAM