Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 116
почти у каждого скриптового языка есть доменная область знаний для которой он создан, в этой области он обладает более интуитивным удобным функционалом, чем другие скриптовые языки.
осталось только разрабам на этих языках узнать о доменных областях. Ато такое впечатление, что сначала знакомятся с самим языком, а потом только доходят до областей, натыкаясь на сложности. Мне так кажется
ох… доменная область знаний… у языка.
вы имеете ввиду областную отделенную обособленную островную частичную область применения? :)
вы имеете ввиду областную отделенную обособленную островную частичную область применения? :)
Ruby — это просто скриптовый язык. он не лучше и не хуже. он просто есть. так сложилось, что под него сделали rails и растрезвонили.
Смешно
чито вас так рассмешило, господин kossnocorp?
так сложилось, что под него сделали rails и растрезвонили.
и все-же я склонен связывать популярность ruby именно наличием ruby on rails.
было бы оно так популярно и на слуху без этого фреймворка?
было бы оно так популярно и на слуху без этого фреймворка?
А был бы на слуху Rails не будь он таким каким является?… В чем собственно заслуга именно Ruby.
тогда, если я правильно понял, ruby и rails сочетаются. и вся прелесть в этом сочетании.
мой первый комментарий относится именно к языку, а не к сочетанию. ruby, как язык, красивый и лаконичный, я не спорю. но он один из нескольких.
я с ужасом думаю о масштабируемом приложении на js, но, может, просто под него пока нет своего rails? :)
мой первый комментарий относится именно к языку, а не к сочетанию. ruby, как язык, красивый и лаконичный, я не спорю. но он один из нескольких.
я с ужасом думаю о масштабируемом приложении на js, но, может, просто под него пока нет своего rails? :)
Ruby для педиков. Asm on Rails — вот где сила, чувак!
Не нааааадаа! Вот где сила SQL on Rails!!!11
eval, не? :)
Narcissus ;) Тоже, кстати, B. Eich написал.
ошибаетесь, тут недавно выкладывали интерпретатор IL -> JS, а для .NET есть scriptEngine для ява скрипта.
Забыл ссылку на Narcissus — en.wikipedia.org/wiki/Narcissus_(Javascript_engine)
А еще недостатки, кроме того, что они «меееедленные», вы можете привести? А то есть ощущение, что это ваша единственная претензия. Причем в отличие от недавнего топика про скорость скриптов Python, ваши — необоснованны никак
> В начале всех начал был ассемблер
Ну, здрасте! ;) Язык ассемблера — это супер-мега абстракция (относительный сверхвысокий уровень), по сравнению с тем, что «было в начале».
Ну, здрасте! ;) Язык ассемблера — это супер-мега абстракция (относительный сверхвысокий уровень), по сравнению с тем, что «было в начале».
> Теперь прочитайте определение языка программирования и вопрос будет снят.
Да вопрос и не поднимался, чтобы его снимать. Машинные коды — это тоже формальная система записи команд. Тоже, относительно, высокий уровень придуманный человеком — для удобства и структуризации формального алгоритма, мыслительного процесса.
Да вопрос и не поднимался, чтобы его снимать. Машинные коды — это тоже формальная система записи команд. Тоже, относительно, высокий уровень придуманный человеком — для удобства и структуризации формального алгоритма, мыслительного процесса.
Не стоит путать горизонтальный рост (количество скриптовых языков) с вертикальными (01 — asc — c — .net, e.g.). Разумеется какой-то из скриптовых языков в чем-то повыше соседа — но все они на одном уровне абстракции.
Вначале были перфокарты
Я вообще не понимаю, как Вы можете сравнивать Javascript и Ruby. Javascript исполняется на клиенте, а руби на сервере. Как вы замените JS на Ruby? или на PHP?
> Javascript исполняется на клиенте, а руби на сервере
Среда и место исполнения — это мелочи, следствие.
> вообще не понимаю, как Вы можете сравнивать Javascript и Ruby
А что непонятного? Сравниваются сами языки. Кстати, JS, Python и Ruby стоят в одной линейке, у них схожие идеологии.
Среда и место исполнения — это мелочи, следствие.
> вообще не понимаю, как Вы можете сравнивать Javascript и Ruby
А что непонятного? Сравниваются сами языки. Кстати, JS, Python и Ruby стоят в одной линейке, у них схожие идеологии.
ну можно контр аргумент? В .NET можно спокойненько и на js писать. Я не пробовал, но код явно должен исполняться на сервере.
Есть серверный Javascript. Причем, мне известно как минимум две реализации — от Netscape (R.I.P., sweet Netscape), и от MS для платформы .Net
Единственное вакантное место идиота в этой дискуссии уже занято мной! Так что извините, ждите пока оно освободится…
Я не большой специалист по скриптовым языкам. Пожалуйста, покажите мне как сделать eval() в PHP, Ruby, Python. Есть ли там null, обладающий особыми свойствами? Могу ли я работать с переданными аргументами любой функции как с массивом arguments? Могу ли я создать в них объект с данными и методами, написав …
python:
assert eval('1+1') == 2
type(None)
def foo(*args):
return args
class JSObject(object): pass
o = JSObject()
o.animal = 'dog'
o.dead = False
def _kill():
if not o.dead:
o.dead = True
o.kill = _kill
Зря иронизируете насчет бейсика. Вот популярность с tiobe:
eval конечно же есть в перечисленных языках.
обьекты в классовых языках несколько другие. Да, создать и передать синглтон в JS проще, зато наследовать и инкапсулировать в JS сложнее.
В минусы- JS отвратительно работает со строками, по сравнению с перлом или пхп. Напишите что-то типа
print "$var=$value in {$row['field']}", а уж обрабатывать массивы JS можно сказать совсем не умеет:
Попробуйте написать что-то типа простенького перлового преобразования:
$data= join ',' map{"'$_'"} split /[,:]/,$input;
eval конечно же есть в перечисленных языках.
обьекты в классовых языках несколько другие. Да, создать и передать синглтон в JS проще, зато наследовать и инкапсулировать в JS сложнее.
В минусы- JS отвратительно работает со строками, по сравнению с перлом или пхп. Напишите что-то типа
print "$var=$value in {$row['field']}", а уж обрабатывать массивы JS можно сказать совсем не умеет:
Попробуйте написать что-то типа простенького перлового преобразования:
$data= join ',' map{"'$_'"} split /[,:]/,$input;
Я бы выразился так, что Javascript работает со строками концептуально :) То бишь JS их особо не отличает от других объектов, поэтому и не содержит большого числа специальных конструкций.
Согласен к этому можно придраться, но ведь есть и обратное преимущество — код не замусорен странноватыми подстановками, в которых трудно разобраться.
Согласен к этому можно придраться, но ведь есть и обратное преимущество — код не замусорен странноватыми подстановками, в которых трудно разобраться.
Замусоренность кода странноватыми подстановками говорит о его не ооп'шности.
Меня это например в питоне раздражает, почему длину строки я получаю функцией а не методом?
Меня это например в питоне раздражает, почему длину строки я получаю функцией а не методом?
Krovosos ↑: концептуальноНу так можно про все сказать.
Krovosos ↑: код не замусорен странноватыми подстановками, в которых трудно разобраться.как раз наоборот. При этом есть возможность составлять строки как в JS, но подстановки удобнее. При правильном названии переменных вопросов вообще не возникает:
«select $field as $name from $table $where and $conditions $orderby» :) ( это пример, помидорами не кидаться )
> То бишь JS их особо не отличает от других объектов, поэтому и не содержит большого числа специальных конструкций
Строки в JS — это примитивный тип. Объектный тип — только один — Object (не путать с конструктором Object!). Встроенный же конструктор String, создаёт объект типа Object, ставит его внутреннее свойство [[Class]] в «String» и записывает во внутреннее свойство [[value]] соответствующее примитивное значение, т.е. строку.
Строки в JS — это примитивный тип. Объектный тип — только один — Object (не путать с конструктором Object!). Встроенный же конструктор String, создаёт объект типа Object, ставит его внутреннее свойство [[Class]] в «String» и записывает во внутреннее свойство [[value]] соответствующее примитивное значение, т.е. строку.
String.prototype.map = function(f) {
(function® {
f®;
})(this);
}
var a = ['j','s'];
a.join('').map(function(e){alert(e);})
(function® {
f®;
})(this);
}
var a = ['j','s'];
a.join('').map(function(e){alert(e);})
вот уж да — программисты на basic по ходу самые стойкие — если у всех языков наблюдается хоть какая-то тенденция, снижения иди повышения популярности — не важно, то эти застряли на своём и теперь не могут ни на что другое перейти :)
> Кхм. А чего из этого нет в Javascript?
> «примеси»
Примесей, в понимании Ruby, в JS нет; ECMA-262-3 понятия «примесь» не описывает. Расширение объектов, как имитация, является имитацией, поскольку в Ruby, создаётся ссылка на модуль, а не просто копируются все свойство в расширяемый объект. Вот здесь немного писал об этом.
> замыкания с полной привязкой к переменным
В JS this не замыкается, а определяется динамически выражением вызова при входе в контекст. В Ruby self замыкается.
> В Ruby… можно добавлять методы не только в любые классы, но и в любые объекты
Кстати, не совсем верно, относительно Ruby. Там создаётся hidden-класс для каждого объекта, который и хранит методы. В JS — объекты полностью изменяемы (mutable) и могут сами хранить методы.
> покажите мне как сделать eval()
eval — вообще основная функция (всех) скриптовых языков.
> Есть ли там null, обладающий особыми свойствами?
А что за особые свойства? null-ы, nil-ы, None-ы есть во многих языках.
> Могу ли я работать с переданными аргументами любой функции как с массивом arguments?
Да, выше уже был пример на Python-e. Однако, в отличии от JS, можно анализировать не только позиционные аргументы, но и именованные:
В Ruby тоже свободно:
> Могу ли я создать в них объект с данными и методами, написав:
Да, в Python, можно даже использовать для этого литерал словаря (не создавая отдельный класс) — явное сходство с объектами в JS:
> Есть Javascript. Зачем нужны другие скриптовые языки?
Время никого и ничего не щадит. Это как, если бы сказали в советские времена: «Да-а, какой шикарный автомобиль — Москвич 412! Лучше уже вряд ли что-нибудь придумают!» Какие-то новые идеи, архитектурные решения и т.д. появляются в процессе эволюции и развития. Мы можем лишь анализировать их, находить достоинства и недостатки, создавать собственные языки.
ECMAscript, кстати, очень много идей позаимствовал из Python-a. Они очень схожи в идеологии, опять же, в статье об ООП в JS, писал об этом.
> «примеси»
Примесей, в понимании Ruby, в JS нет; ECMA-262-3 понятия «примесь» не описывает. Расширение объектов, как имитация, является имитацией, поскольку в Ruby, создаётся ссылка на модуль, а не просто копируются все свойство в расширяемый объект. Вот здесь немного писал об этом.
> замыкания с полной привязкой к переменным
В JS this не замыкается, а определяется динамически выражением вызова при входе в контекст. В Ruby self замыкается.
> В Ruby… можно добавлять методы не только в любые классы, но и в любые объекты
Кстати, не совсем верно, относительно Ruby. Там создаётся hidden-класс для каждого объекта, который и хранит методы. В JS — объекты полностью изменяемы (mutable) и могут сами хранить методы.
> покажите мне как сделать eval()
eval — вообще основная функция (всех) скриптовых языков.
> Есть ли там null, обладающий особыми свойствами?
А что за особые свойства? null-ы, nil-ы, None-ы есть во многих языках.
> Могу ли я работать с переданными аргументами любой функции как с массивом arguments?
Да, выше уже был пример на Python-e. Однако, в отличии от JS, можно анализировать не только позиционные аргументы, но и именованные:
def a(*args, **kwargs): print(args, kwargs) a(10, 20, b=30, c=40)
В Ruby тоже свободно:
def a(*args) p args end a 1, 2, 3 # [1, 2, 3]
> Могу ли я создать в них объект с данными и методами, написав:
Да, в Python, можно даже использовать для этого литерал словаря (не создавая отдельный класс) — явное сходство с объектами в JS:
obj = {
'a': 10,
'b': 20,
'method': lambda x: x + 10
}
obj['method'](10) # 20> Есть Javascript. Зачем нужны другие скриптовые языки?
Время никого и ничего не щадит. Это как, если бы сказали в советские времена: «Да-а, какой шикарный автомобиль — Москвич 412! Лучше уже вряд ли что-нибудь придумают!» Какие-то новые идеи, архитектурные решения и т.д. появляются в процессе эволюции и развития. Мы можем лишь анализировать их, находить достоинства и недостатки, создавать собственные языки.
ECMAscript, кстати, очень много идей позаимствовал из Python-a. Они очень схожи в идеологии, опять же, в статье об ООП в JS, писал об этом.
чуви, ты шаришь, зря в прошлый раз с тобой цапался
Насчет примесей, все-таки прототипы и классы не очень корректно сравнивать.
>> В Ruby… можно добавлять методы не только в любые классы, но и в любые объекты
>Кстати, не совсем верно, относительно Ruby. Там создаётся hidden-класс для каждого объекта, который и хранит методы.
Извеняюсь за занудство:) Ни неразу не встечал «hidden». SingletonClass или MetaClass.
>> В Ruby… можно добавлять методы не только в любые классы, но и в любые объекты
>Кстати, не совсем верно, относительно Ruby. Там создаётся hidden-класс для каждого объекта, который и хранит методы.
Извеняюсь за занудство:) Ни неразу не встечал «hidden». SingletonClass или MetaClass.
> Насчет примесей, все-таки прототипы и классы не очень корректно сравнивать.
Да, я знаю, что такое класс, и что такое прототип. Опять же, писал и разбирал это подробно в статье об ООП в JS. Почитайте, особенно раздел о динамично-классовой организации.
А что значит не «очень корректно»? А как «очень корректно» будет? Расскажите, интересно.
> Извеняюсь за занудство:) Ни неразу не встечал «hidden». SingletonClass или MetaClass.
Да, в Ruby принята эта терминология, для объектов создаётся SingletonClass, для классов — MetaClass. Однако, обе эти сущности являются терминологическим подмножеством VirtualHiddenClass. При этом, терминология MetaClass, применённая в Ruby, может сбить с толку в классическом понимании этого термина. Хотя, как часть — класс содержащий методы другого класса — можно назвать и метаклассом, как это сделано в Ruby.
Да, я знаю, что такое класс, и что такое прототип. Опять же, писал и разбирал это подробно в статье об ООП в JS. Почитайте, особенно раздел о динамично-классовой организации.
А что значит не «очень корректно»? А как «очень корректно» будет? Расскажите, интересно.
> Извеняюсь за занудство:) Ни неразу не встечал «hidden». SingletonClass или MetaClass.
Да, в Ruby принята эта терминология, для объектов создаётся SingletonClass, для классов — MetaClass. Однако, обе эти сущности являются терминологическим подмножеством VirtualHiddenClass. При этом, терминология MetaClass, применённая в Ruby, может сбить с толку в классическом понимании этого термина. Хотя, как часть — класс содержащий методы другого класса — можно назвать и метаклассом, как это сделано в Ruby.
Корректно, например Ruby с Python или JS с Io. Хоть динамические классовые и близки к прототипам, но сами же указываете в статье их различия. Кстати, статья очень интересная, спасибо.
Хотя, можно эти различия считать несущественными, не буду спорить:)
Хотя, можно эти различия считать несущественными, не буду спорить:)
> Корректно, например Ruby с Python или JS с Io
Почему? Потому что там терминология «класс», а там — «прототип»? Это не существенно. Важным атрибутами для анализа являются «динамика vs. статика» + механизм разрешения характеристик объектов. В Python и JS — они практически идентичны.
> но сами же указываете в статье их различия
Я-то указвыаю. Просто вы сказали, что «не очень корректно сравнивать», думал, тоже укажете на какую-то информацию и внесёте ясность. Ну, да ладно.
Почему? Потому что там терминология «класс», а там — «прототип»? Это не существенно. Важным атрибутами для анализа являются «динамика vs. статика» + механизм разрешения характеристик объектов. В Python и JS — они практически идентичны.
> но сами же указываете в статье их различия
Я-то указвыаю. Просто вы сказали, что «не очень корректно сравнивать», думал, тоже укажете на какую-то информацию и внесёте ясность. Ну, да ладно.
> Примесей, в понимании Ruby, в JS нет
На мой взгляд это без труда обходится с помощью прототипов.
Можете привести «живой» пример примеси?
> В JS this не замыкается, а определяется динамически выражением вызова при входе в контекст. В Ruby self замыкается.
А чем это плохо? Что ссылки вида «this.» отъезжают?
> Какие-то новые идеи, архитектурные решения и т.д. появляются в процессе эволюции и развития.
Вот я и пытался выявить что-то эдакое, чего Javascript не сможет ну никак выжать.
На мой взгляд это без труда обходится с помощью прототипов.
Можете привести «живой» пример примеси?
> В JS this не замыкается, а определяется динамически выражением вызова при входе в контекст. В Ruby self замыкается.
А чем это плохо? Что ссылки вида «this.» отъезжают?
> Какие-то новые идеи, архитектурные решения и т.д. появляются в процессе эволюции и развития.
Вот я и пытался выявить что-то эдакое, чего Javascript не сможет ну никак выжать.
Да, примеси не являются большим отличием Ruby. Схожая функциональность достигается прототипами.
Но опять же, прототипы и классы сравнивать не очень корректно.
Пример примеси:
Но опять же, прототипы и классы сравнивать не очень корректно.
Пример примеси:
module ExtString
def five_times
self*5
end
end
class String
include ExtString
end
puts "asdf".five_times
> Да, примеси не являются большим отличием Ruby
Являются-являются. В Ruby — подмешивание (ссылки на модули, к которым происходит делегация — поменяйте в рантайме значение в модуле, и оно тут же отобразится на всех объектах, которые подмешали эту примесь), в JS — расширение и один прототип для делегации (но, к слову сказать, в некоторых реализациях можно задействовать __noSuchMethod__ и делегировать по альтернативным цепям прототипов, т.е., по сути, организовывать множественное наследование или подмешивание).
Являются-являются. В Ruby — подмешивание (ссылки на модули, к которым происходит делегация — поменяйте в рантайме значение в модуле, и оно тут же отобразится на всех объектах, которые подмешали эту примесь), в JS — расширение и один прототип для делегации (но, к слову сказать, в некоторых реализациях можно задействовать __noSuchMethod__ и делегировать по альтернативным цепям прототипов, т.е., по сути, организовывать множественное наследование или подмешивание).
> На мой взгляд это без труда обходится с помощью прототипов.
А в JS в качестве прототипа может быть указан лишь один объект (в отличии, скажем, от языка Self, от которого JS также вобрал немало идей). Примиси же, в одной из своих особенностей, позиционируются как альтернатива множественному наследованию, т.е. объект может подмешать несколько объектов и делегировать к ним. И, повторю, подмешивание и расширение — это разные вещи. Подмешивая, мы, по сути, создаём ещё один прототип для делегации, а расширяя — просто копируем свойства в объект. Почитайте ещё раз ссылку, которую я давал в предыдущем посте.
> Можете привести «живой» пример примеси?
Данная примесь, кстати, больше относится к штриху.
А Вас что именно интересует? Давайте и Вы пример приведите.
> А чем это плохо? Что ссылки вида «this.» отъезжают?
При чём здесь плохо? В Ruby — всего лишь — своя реализация. В JS — всего лишь своя реализация. Ни больше, ни меньше.
> Вот я и пытался выявить что-то эдакое, чего Javascript не сможет ну никак выжать.
Если видите большой смысл — почему бы не повыяснять? А вообще, тогда надо было спрашивать, «вот чего такого нет в Python-e или Self, или SmallTlak, или… (возьмите любой язык, от которого JS питал идеи), чего надо было делать в JS?». Ответы, кстати, найдёте, поскольку JS базируясь на определённых идеях, вносил и свои особенности. Так же и другие языки.
А в JS в качестве прототипа может быть указан лишь один объект (в отличии, скажем, от языка Self, от которого JS также вобрал немало идей). Примиси же, в одной из своих особенностей, позиционируются как альтернатива множественному наследованию, т.е. объект может подмешать несколько объектов и делегировать к ним. И, повторю, подмешивание и расширение — это разные вещи. Подмешивая, мы, по сути, создаём ещё один прототип для делегации, а расширяя — просто копируем свойства в объект. Почитайте ещё раз ссылку, которую я давал в предыдущем посте.
> Можете привести «живой» пример примеси?
class Age
include Comparable
attr_accessor(:age)
def <=>(cmp)
@age <=> cmp.age
end
end
a, b = Age.new, Age.new
a.age = 10
b.age = 11
a < b # trueДанная примесь, кстати, больше относится к штриху.
А Вас что именно интересует? Давайте и Вы пример приведите.
> А чем это плохо? Что ссылки вида «this.» отъезжают?
При чём здесь плохо? В Ruby — всего лишь — своя реализация. В JS — всего лишь своя реализация. Ни больше, ни меньше.
> Вот я и пытался выявить что-то эдакое, чего Javascript не сможет ну никак выжать.
Если видите большой смысл — почему бы не повыяснять? А вообще, тогда надо было спрашивать, «вот чего такого нет в Python-e или Self, или SmallTlak, или… (возьмите любой язык, от которого JS питал идеи), чего надо было делать в JS?». Ответы, кстати, найдёте, поскольку JS базируясь на определённых идеях, вносил и свои особенности. Так же и другие языки.
А вот если Вы предлагаете использовать свой язык для динамической генерации контента загруженного веб-сайта, то у меня вот есть сильное такое подозрение, что производительность является _самым_важным_ критерием.
Часто основным критерием является скорость разработки и простота поддержки. А железа всегда (почти) можно добавить.
Это такой толстый троллинг рубистов? Или вы серьезно?:)
Если все-таки серьезно, то давайте по пунктикам.
Ruby начал разрабатываться в 1994, релизнулся в 1995 году, в один год с Javascript'ом. Зачем нужен какой-то новый джаваскрипт если есть руби?:)
Скриптовые языки бывают разные. Сравнение Javascript и Ruby нельзя считать корректным, т.к. первый prototype-based, а второй классовый.
Вы как-то странно решили что среда не важна. Всякие ни к месту примеры с вебсервером и думом.
Без среды язык ничто, пусть он хоть в 10 раз лучше всех аналогов(другой вопрос, что если все так хорошо, то и среда быстро появится:))
Опять же возвращаясь к среде, например такой наибанальнейший пример, как работа с файлами. Ruby(как и Perl и PHP и Python(3P!:))) предоставляет вполне удобный функционал для работы с этими файлами.
Что нам в этом случае может предложить Javascript? Я вижу три варианта:
1) Платформо/браузерно(ie!:)) зависимый ActiveX объект.
2) Помеченный как нестабильный(так и есть) модуль к мозиловскому SpiderMonkey, который еще попробуй скомпиль.
3) Вся мощь плотформы Java посредством Rhino.(Вот это уже круто, но, зачем, если есть тот же JRuby?:))
Насчет дума или вебсервера, напишити-ка его без работы с файлами.
Кстати, в дефолтном(браузерном) Javascript среда есть, притом очень специфическая — это DOM.
Теперь про отличия, их кучи! Все даже и не перечислишь.
Первая вкусность руби, которая мне больше всего нравится(не считая сахара) это метапрограммирование.
Я даже статью на эту тему писал http://habrahabr.ru/blogs/ruby/48754/
Попробуйте реализовать что-нибудь похожее в джс.
Вот это настораживает, значит вся статья от вашего незнания?:)
>Я не большой специалист по скриптовым языкам. Пожалуйста, покажите мне как сделать eval() в PHP, Ruby, Python.
Насчет Ruby, из скриптовых языков он предоставляет самые мощные возможности метапрограммирования, по-этому eval'ов различных там много:) Предлагаю обратиться к документации.
Кстати, простой пример, я спокойно могу в динамике оверрайдить методы, классы, модули. Тот же PHP, хоть и имеет eval, этого не может(Правда есть экстеншн на эту тему)
>Есть ли там null, обладающий особыми свойствами?
nil, док по NilClass. Токиеже ответы на остальные вопросы.
Кстати, такая функциональность языка как потоки. Не говорите, что и это среда:) В руби потоки «зеленые», т.е. выполнение на уровне VM. В PHP вобще нет потоков, только форками если эмулировать.
Что насчет Javascript'а?:) Дада, есть функция распоралеливания в SpiderMonkey. Но это очень далеко от понятия «поток».
Насчет тормозов Ruby. В контексте PHP еще куда не шло, а в контексте JS? Поделитесь бенчмарками которыми руководствовались.
Тормоза Ruby, это расплата за большие динамические возможности. Плюс, все намного лучше в JRuby. И намного лучше в Ruby1.9.
Кстати, насчет веб приложений на Ruby и PHP. PHP файл дергается на каждое обращение(если CGI, если FCGI, то да, в памяти). Приложение Rails или Sinatra или еще_что_то_rack_совместимое — всевремя в памяти. Не тратим время на интерпретацию файла.
Правда Rails тормозной, но Ruby, как известно, is not Rails:)
О, кстати, как в JS с базами данных? Ну или банальными сокетами?(тоже несущественная среда?):)
На gluejs ссылки кидать не надо:)
Если все-таки серьезно, то давайте по пунктикам.
Ruby начал разрабатываться в 1994, релизнулся в 1995 году, в один год с Javascript'ом. Зачем нужен какой-то новый джаваскрипт если есть руби?:)
Скриптовые языки бывают разные. Сравнение Javascript и Ruby нельзя считать корректным, т.к. первый prototype-based, а второй классовый.
Вы как-то странно решили что среда не важна. Всякие ни к месту примеры с вебсервером и думом.
Без среды язык ничто, пусть он хоть в 10 раз лучше всех аналогов(другой вопрос, что если все так хорошо, то и среда быстро появится:))
Опять же возвращаясь к среде, например такой наибанальнейший пример, как работа с файлами. Ruby(как и Perl и PHP и Python(3P!:))) предоставляет вполне удобный функционал для работы с этими файлами.
Что нам в этом случае может предложить Javascript? Я вижу три варианта:
1) Платформо/браузерно(ie!:)) зависимый ActiveX объект.
2) Помеченный как нестабильный(так и есть) модуль к мозиловскому SpiderMonkey, который еще попробуй скомпиль.
3) Вся мощь плотформы Java посредством Rhino.(Вот это уже круто, но, зачем, если есть тот же JRuby?:))
Насчет дума или вебсервера, напишити-ка его без работы с файлами.
Кстати, в дефолтном(браузерном) Javascript среда есть, притом очень специфическая — это DOM.
Теперь про отличия, их кучи! Все даже и не перечислишь.
Первая вкусность руби, которая мне больше всего нравится(не считая сахара) это метапрограммирование.
Я даже статью на эту тему писал http://habrahabr.ru/blogs/ruby/48754/
Попробуйте реализовать что-нибудь похожее в джс.
Вот это настораживает, значит вся статья от вашего незнания?:)
>Я не большой специалист по скриптовым языкам. Пожалуйста, покажите мне как сделать eval() в PHP, Ruby, Python.
Насчет Ruby, из скриптовых языков он предоставляет самые мощные возможности метапрограммирования, по-этому eval'ов различных там много:) Предлагаю обратиться к документации.
Кстати, простой пример, я спокойно могу в динамике оверрайдить методы, классы, модули. Тот же PHP, хоть и имеет eval, этого не может(Правда есть экстеншн на эту тему)
>Есть ли там null, обладающий особыми свойствами?
nil, док по NilClass. Токиеже ответы на остальные вопросы.
Кстати, такая функциональность языка как потоки. Не говорите, что и это среда:) В руби потоки «зеленые», т.е. выполнение на уровне VM. В PHP вобще нет потоков, только форками если эмулировать.
Что насчет Javascript'а?:) Дада, есть функция распоралеливания в SpiderMonkey. Но это очень далеко от понятия «поток».
Насчет тормозов Ruby. В контексте PHP еще куда не шло, а в контексте JS? Поделитесь бенчмарками которыми руководствовались.
Тормоза Ruby, это расплата за большие динамические возможности. Плюс, все намного лучше в JRuby. И намного лучше в Ruby1.9.
Кстати, насчет веб приложений на Ruby и PHP. PHP файл дергается на каждое обращение(если CGI, если FCGI, то да, в памяти). Приложение Rails или Sinatra или еще_что_то_rack_совместимое — всевремя в памяти. Не тратим время на интерпретацию файла.
Правда Rails тормозной, но Ruby, как известно, is not Rails:)
О, кстати, как в JS с базами данных? Ну или банальными сокетами?(тоже несущественная среда?):)
На gluejs ссылки кидать не надо:)
js может работать и с файлами и с базадой. jaxer.org
> Это такой толстый троллинг рубистов? Или вы серьезно?:)
Не обязательно рубистов.
Я могу понять почему возник С++ после C.
Я могу понять откуда вырос Perl.
И, разумеется, как родился Javascript.
Я вижу совершенно конкретный прогресс и конкретные полученные преимущества. Области применения.
А когда начинаю сравнивать Ruby и Javascript мне непонятно — где здесь прогресс? В чем сила?
Я для себя ищу ответ на вопрос.
> Сравнение Javascript и Ruby нельзя считать корректным, т.к. первый prototype-based, а второй классовый.
Ну и что? Можно найти библиотеки, которые в JS добавляют стандартное (в понимании C++) наследование. Что это меняет в рассуждениях?
> Без среды язык ничто, пусть он хоть в 10 раз лучше всех аналогов(другой вопрос, что если все так хорошо, то и среда быстро появится:))
А что такое «среда» для скриптового языка? Это VM + библиотеки.
Дайте мне вход в скриптовый язык и библиотеки я напишу сам. А VM пусть умело и быстро выполняет.
И с первым, и со вторым, я так понимаю, проблемы…
> например такой наибанальнейший пример, как работа с файлами.
Ну я могу здесь описать как в моей реализации серверного Javascript организована работа с файлами. Очень просто и удобно.
Я не понимаю — что здесь сложного? Обернуть вызовы «открыть файл», «прочитать», «записать», «закрыть файл»?
> Первая вкусность руби, которая мне больше всего нравится(не считая сахара) это метапрограммирование.
> Я даже статью на эту тему писал habrahabr.ru/blogs/ruby/48754/
> Попробуйте реализовать что-нибудь похожее в джс.
Я вообще не понимаю смысла в статье по ссылке. Уж извините.
var tab = {'ghz':1073741824, 'gb': 1073741824};
function parse(s)
{
var o = {};
var a = s.split(',');
for (var i in a)
{
var item = a[i];
var v = item.split(' ');
var r = 1.0;
for (var k = 1; k < v.length; k++)
{
var n = v[k];
if (tab[n]) n = tab[n]; else n = parseFloat(n);
r *= n;
}
o[v[0]] = r;
}
return o;
}
var o = parse('cpu 1 ghz,hdd 20 gb');
Этот код делает то чего вы хотели.
Он не содержит новых модных слов (DSL), ни примесей, ни замыканий или гипертрансформаций.
Более того, если вдруг по какой-то причине Вы захотите разнообразить описание конфигураций, например, таким вот образом:
«hdd Toshiba 20 ghz»
вы переделаете мой код без особого труда. А вот Ваш пример потребует серьезного вмешательства, я подозреваю.
Извините, если что.
Я не понимаю зачем забивать гвозди электронным молотком под управлением Андроид…
> О, кстати, как в JS с базами данных? Ну или банальными сокетами?(тоже несущественная среда?):)
Да какие проблемы написать реализацию всего этого? Вставить в реализацию, например, SQLAPI?
Не обязательно рубистов.
Я могу понять почему возник С++ после C.
Я могу понять откуда вырос Perl.
И, разумеется, как родился Javascript.
Я вижу совершенно конкретный прогресс и конкретные полученные преимущества. Области применения.
А когда начинаю сравнивать Ruby и Javascript мне непонятно — где здесь прогресс? В чем сила?
Я для себя ищу ответ на вопрос.
> Сравнение Javascript и Ruby нельзя считать корректным, т.к. первый prototype-based, а второй классовый.
Ну и что? Можно найти библиотеки, которые в JS добавляют стандартное (в понимании C++) наследование. Что это меняет в рассуждениях?
> Без среды язык ничто, пусть он хоть в 10 раз лучше всех аналогов(другой вопрос, что если все так хорошо, то и среда быстро появится:))
А что такое «среда» для скриптового языка? Это VM + библиотеки.
Дайте мне вход в скриптовый язык и библиотеки я напишу сам. А VM пусть умело и быстро выполняет.
И с первым, и со вторым, я так понимаю, проблемы…
> например такой наибанальнейший пример, как работа с файлами.
Ну я могу здесь описать как в моей реализации серверного Javascript организована работа с файлами. Очень просто и удобно.
Я не понимаю — что здесь сложного? Обернуть вызовы «открыть файл», «прочитать», «записать», «закрыть файл»?
> Первая вкусность руби, которая мне больше всего нравится(не считая сахара) это метапрограммирование.
> Я даже статью на эту тему писал habrahabr.ru/blogs/ruby/48754/
> Попробуйте реализовать что-нибудь похожее в джс.
Я вообще не понимаю смысла в статье по ссылке. Уж извините.
var tab = {'ghz':1073741824, 'gb': 1073741824};
function parse(s)
{
var o = {};
var a = s.split(',');
for (var i in a)
{
var item = a[i];
var v = item.split(' ');
var r = 1.0;
for (var k = 1; k < v.length; k++)
{
var n = v[k];
if (tab[n]) n = tab[n]; else n = parseFloat(n);
r *= n;
}
o[v[0]] = r;
}
return o;
}
var o = parse('cpu 1 ghz,hdd 20 gb');
Этот код делает то чего вы хотели.
Он не содержит новых модных слов (DSL), ни примесей, ни замыканий или гипертрансформаций.
Более того, если вдруг по какой-то причине Вы захотите разнообразить описание конфигураций, например, таким вот образом:
«hdd Toshiba 20 ghz»
вы переделаете мой код без особого труда. А вот Ваш пример потребует серьезного вмешательства, я подозреваю.
Извините, если что.
Я не понимаю зачем забивать гвозди электронным молотком под управлением Андроид…
> О, кстати, как в JS с базами данных? Ну или банальными сокетами?(тоже несущественная среда?):)
Да какие проблемы написать реализацию всего этого? Вставить в реализацию, например, SQLAPI?
Ну, по сути прогресс языка это либо новая идеология(как си и си++), либо тюнинг старой идеологии(как c++ и java) либо как синтаксический сахар(как python и ruby).
Своими динамическими взможностями ruby превосходит js(по крайней мере в их «сахарности»).
Но все это легко парировать вашим аргументом — «допишу». Нет потоков? Портируем pthreads на SpiderMonkey. Нет сокетов? Напишим обертку. Недостаточно сладкий синтаксис? Пропатчим интерпретатор. Так можно дойти до того, что «ничто» ничем не хуже «супер мега языка»:) Потому как всегда можно дописать.
Может в том, что очень многое уже есть, и не надо дописывать, и есть прогресс?
>Я вообще не понимаю смысла в статье по ссылке. Уж извините.
Смысл, краткая иллюстрация возможностей метапрограммирования. Да, DSL для конфигов это не очень удобно, зато это необыкновенно удобно в контексте какой-либо библиотеки:) Таже синатра например.
>Я не понимаю зачем забивать гвозди электронным молотком под управлением Андроид…
Эм, теперь вы про то что в Ruby избыток функциональности? Или я нетак понял?:)
Своими динамическими взможностями ruby превосходит js(по крайней мере в их «сахарности»).
Но все это легко парировать вашим аргументом — «допишу». Нет потоков? Портируем pthreads на SpiderMonkey. Нет сокетов? Напишим обертку. Недостаточно сладкий синтаксис? Пропатчим интерпретатор. Так можно дойти до того, что «ничто» ничем не хуже «супер мега языка»:) Потому как всегда можно дописать.
Может в том, что очень многое уже есть, и не надо дописывать, и есть прогресс?
>Я вообще не понимаю смысла в статье по ссылке. Уж извините.
Смысл, краткая иллюстрация возможностей метапрограммирования. Да, DSL для конфигов это не очень удобно, зато это необыкновенно удобно в контексте какой-либо библиотеки:) Таже синатра например.
>Я не понимаю зачем забивать гвозди электронным молотком под управлением Андроид…
Эм, теперь вы про то что в Ruby избыток функциональности? Или я нетак понял?:)
> Своими динамическими взможностями ruby превосходит js(по крайней мере в их «сахарности»).
Да тоже спорно, на самом деле ;)
Да тоже спорно, на самом деле ;)
> Смысл, краткая иллюстрация возможностей метапрограммирования. Да, DSL для конфигов это не очень удобно, зато это необыкновенно удобно в контексте какой-либо библиотеки:) Таже синатра например.
Видимо я что-то не понимаю… :)
Видимо я что-то не понимаю… :)
>>Я не понимаю зачем забивать гвозди электронным молотком под управлением Андроид…
>Эм, теперь вы про то что в Ruby избыток функциональности? Или я нетак понял?:)
Я про то, что если можно сделать как я написал — зачем изобретать новое? Что дает это новое?
>Эм, теперь вы про то что в Ruby избыток функциональности? Или я нетак понял?:)
Я про то, что если можно сделать как я написал — зачем изобретать новое? Что дает это новое?
> Я для себя ищу ответ на вопрос.
Вы выбрали неудачную позицию — не анализирующую со стороны, а отстаивающую JS. Смотрите профессиональней, оценивайте, видьте плюсы и минусы. JS написали не Вы, а B. Eich, который заимстовал идеи ещё у кого-то. Он (B. Eich) может, ещё и может холиворить с Guido Van Rossum-ом =) но, уж явно не будет этого делать ;)
Вы выбрали неудачную позицию — не анализирующую со стороны, а отстаивающую JS. Смотрите профессиональней, оценивайте, видьте плюсы и минусы. JS написали не Вы, а B. Eich, который заимстовал идеи ещё у кого-то. Он (B. Eich) может, ещё и может холиворить с Guido Van Rossum-ом =) но, уж явно не будет этого делать ;)
из википедии
по вашим рассуждениям получается что яваскрипт не нужен
Python was conceived in the late 1980s
Javascript was first introduced and deployed in the Netscape browser version 2.0B3 in December 1995
по вашим рассуждениям получается что яваскрипт не нужен
JS прекрасно умеет работать с файлами. и не только с файлами. все зависит от среды/окружения.
взять к примеру WSH, под которым можно «искаропки» крутить VBscript и Jscript, а если захотеть, то, ЕМНИП, и перл с питоном.
(правда, следует отметить, что Jscript — майкрософтовская реализация Javascript'а, и у него есть специфические «особенности»)
взять к примеру WSH, под которым можно «искаропки» крутить VBscript и Jscript, а если захотеть, то, ЕМНИП, и перл с питоном.
(правда, следует отметить, что Jscript — майкрософтовская реализация Javascript'а, и у него есть специфические «особенности»)
> Первая вкусность руби, которая мне больше всего нравится(не считая сахара) это метапрограммирование.
Я даже статью на эту тему писал habrahabr.ru/blogs/ruby/48754/
Попробуйте реализовать что-нибудь похожее в джс.
Статья хорошая, особенно для новичков, а данное метапрограммирование реализуется в JS идентично. JS полностью поддерживает динамическую интроспекцию. Причём, определение новых характеристик там по синтаксису даже удобней.
> Насчет Ruby, из скриптовых языков он предоставляет самые мощные возможности метапрограммирования
Да и JS немалые ;) Такие же, в своём представлении.
Я даже статью на эту тему писал habrahabr.ru/blogs/ruby/48754/
Попробуйте реализовать что-нибудь похожее в джс.
Статья хорошая, особенно для новичков, а данное метапрограммирование реализуется в JS идентично. JS полностью поддерживает динамическую интроспекцию. Причём, определение новых характеристик там по синтаксису даже удобней.
> Насчет Ruby, из скриптовых языков он предоставляет самые мощные возможности метапрограммирования
Да и JS немалые ;) Такие же, в своём представлении.
Ну, в JS все очень от реализации зависит. Тот же аналог method_missing. Или eval в контексте, ниже вы говорите, что есть только в определенных версиях SpiderMonkey.
>Да и JS немалые ;) Такие же, в своём представлении.
Ну да. Вобщем так и есть. Но в данном случае «сахар» решает:) Хотя это конечно субъективно очень.
>Да и JS немалые ;) Такие же, в своём представлении.
Ну да. Вобщем так и есть. Но в данном случае «сахар» решает:) Хотя это конечно субъективно очень.
Уже много раз писали, что пока работа программиста дороже нового дешевого железа (читаем работа китайцев и грузчиков в портах и жд) будут веб-серверы на basic'е ;-)
Доставайте мечи, начинаем очередной HOLYVAR. Ура!
Судя по посту автор глуп и крайне неинформирован.
Во-первых, на фоне остальных языков javascript смотрится вполне «новым» (как раз против чего автор пытается выступать). Python и Perl намного более матёрые «соперники», а тот же Ruby который официально вышел почти одновременно с javascript на том же уровне был несоизмеримо мощнее по функционалу (подозреваю что по скорости тоже, но не уверен). Потому могу предложить автору в начале статьи поменять javascript и Ruby местами, так будет правильнее
Далее по тезисам:
1. Преимуществом любого языка ОДНОЗНАЧНО является наличие уже большого количества готового кода, который можно использовать в программе. Опять же автор упоминал про гипотетический webserver от Ruby, пусть он приведёт пример веб-сервера на JS поддерживающий HTTP 1.1 или его надо с нуля писать чтобы простейший сайт сделать? Сколько ещё велосипедов надо написать тысячу, миллион?
Языки программирования нужны чтобы решать задачи, а если для решения простейшей задачи требуеться написать пару тысяч строк кода только из-за того что данный функционал ещё не реализован (причём есть множество реализаций в других языках), проще выбрать подходящий язык программирования и сделать всё быстро и в срок.
по поводу возможностей языка:
у javascript они ОГРАНИЧЕНЫ, да там есть замыкания, итераторы и некоторые другие фенечки, НО
— нет strict синтаксиса, т.е. любые опечатки в названиях переменных или свойствах объектов и отладка превращается в многочасовой кошмар
— ООП ужасно неудобное, и из-за предыдущего пункта сильно предрасположено к разнообразным глюкам. При создании экземпляров копируются методы и свойства, что сильно засоряет память и бьёт по производительности
— изначально нет никакой найтивной поддержки модульности и нормального наследования, что вполне объясняется предназначением языка — «небольшие скрипты улучшения интерфейса на клиентской стороне»
— невозможность работать с двоичными данными, только с текстовыми, ни о какой серьёзности и гибкости языка после этого говорить уже нельзя
— сетевое взаимодействие только по HTTP протоколу (и о какой производительности автор пытался говорить?)
— нет нормальных средств для написания модулей или каких нибудь расширений на других языках программирования
пунктов ещё могу добавить, но пока хватит и этого
2. что можно написать на других языках и нельзя на javascript?
например в языке Perl не так давно написали новую ООП модель средствами языка, javascript это умеет? НЕТ
в одну строку с консоли обработать файл, тоже нет?
написать многозадачное приложение на JS? НЕТ
а передать или принять данные от другого приложения не по HTTP, тоже никак?
ай-яй-яй… ну тот всё понятно это стандартная болезнь «новых» языков программирования с недостатком готовых модулей
3. про производительность
во первых производительностью JS не блещет,
во вторых нет многозадачности, т.е. чтобы использовать все процессоры, необходимо запускать несколько экземплятор интерпретатора и вручную через HTTP соединения делать велосипедный IPC, про скорость подобного решения вообще лучьше не думать
В общем пост ни о чём
Во-первых, на фоне остальных языков javascript смотрится вполне «новым» (как раз против чего автор пытается выступать). Python и Perl намного более матёрые «соперники», а тот же Ruby который официально вышел почти одновременно с javascript на том же уровне был несоизмеримо мощнее по функционалу (подозреваю что по скорости тоже, но не уверен). Потому могу предложить автору в начале статьи поменять javascript и Ruby местами, так будет правильнее
Далее по тезисам:
1. Преимуществом любого языка ОДНОЗНАЧНО является наличие уже большого количества готового кода, который можно использовать в программе. Опять же автор упоминал про гипотетический webserver от Ruby, пусть он приведёт пример веб-сервера на JS поддерживающий HTTP 1.1 или его надо с нуля писать чтобы простейший сайт сделать? Сколько ещё велосипедов надо написать тысячу, миллион?
Языки программирования нужны чтобы решать задачи, а если для решения простейшей задачи требуеться написать пару тысяч строк кода только из-за того что данный функционал ещё не реализован (причём есть множество реализаций в других языках), проще выбрать подходящий язык программирования и сделать всё быстро и в срок.
по поводу возможностей языка:
у javascript они ОГРАНИЧЕНЫ, да там есть замыкания, итераторы и некоторые другие фенечки, НО
— нет strict синтаксиса, т.е. любые опечатки в названиях переменных или свойствах объектов и отладка превращается в многочасовой кошмар
— ООП ужасно неудобное, и из-за предыдущего пункта сильно предрасположено к разнообразным глюкам. При создании экземпляров копируются методы и свойства, что сильно засоряет память и бьёт по производительности
— изначально нет никакой найтивной поддержки модульности и нормального наследования, что вполне объясняется предназначением языка — «небольшие скрипты улучшения интерфейса на клиентской стороне»
— невозможность работать с двоичными данными, только с текстовыми, ни о какой серьёзности и гибкости языка после этого говорить уже нельзя
— сетевое взаимодействие только по HTTP протоколу (и о какой производительности автор пытался говорить?)
— нет нормальных средств для написания модулей или каких нибудь расширений на других языках программирования
пунктов ещё могу добавить, но пока хватит и этого
2. что можно написать на других языках и нельзя на javascript?
например в языке Perl не так давно написали новую ООП модель средствами языка, javascript это умеет? НЕТ
в одну строку с консоли обработать файл, тоже нет?
написать многозадачное приложение на JS? НЕТ
а передать или принять данные от другого приложения не по HTTP, тоже никак?
ай-яй-яй… ну тот всё понятно это стандартная болезнь «новых» языков программирования с недостатком готовых модулей
3. про производительность
во первых производительностью JS не блещет,
во вторых нет многозадачности, т.е. чтобы использовать все процессоры, необходимо запускать несколько экземплятор интерпретатора и вручную через HTTP соединения делать велосипедный IPC, про скорость подобного решения вообще лучьше не думать
В общем пост ни о чём
за очепятки сильно не пиннать, писал на скорую руку в конце рабочего дня
> Судя по посту автор глуп и крайне неинформирован.
Рыбак рыбака видит издалека! ;-)
> пусть он приведёт пример веб-сервера на JS поддерживающий HTTP 1.1 или его надо с нуля писать чтобы простейший сайт сделать
Берем open-source HTTP-сервер. Берем open-source реализацию Javascript и прикручиваем.
Разумеется, будут проблемы и прочее. Но работать будет. Но «заново» писать ничего не надо.
Вы что хотите сказать, что веб-сервера, использующие php, написаны для этого как-то особенно??
> нет strict синтаксиса, т.е. любые опечатки в названиях переменных или свойствах объектов и отладка превращается в многочасовой кошмар
Да, это плохо. Это плата за расширяемость.
> ООП ужасно неудобное
Спорно. Оно просто другое. Не похожее на обычную парадигму.
> найтивной поддержки модульности и нормального наследования,
Понятия «нормальное» наследования не существует. В реализации JS есть свои плюсы и минусы. Но лучшего-пригодного-навсегда-и-везде механизма наследования — нету в природе.
Модульность спокойно обеспечивается созданием объектов. Можно скрыть все что угодно и все что угодно выставить наружу.
> невозможность работать с двоичными данными, только с текстовыми, ни о какой серьёзности и гибкости языка после этого говорить уже нельзя
С таким подходом боюсь большую часть языков на помойку придется отправить :)
Зачем в скриптовом языке вам понадобилось битами жонглировать?
> сетевое взаимодействие только по HTTP протоколу
Это не ограничение языка. Это не ограничение вообще. Напишите свою реализацию и вперед.
> написать многозадачное приложение на JS? НЕТ
Причем тут Javascript??
> а передать или принять данные от другого приложения не по HTTP, тоже никак?
Ну хорошо вот как в моей среде (которая использует серверный Javascript) можно передать асинхронное сообщение по локальной сети:
transmit_message(address, { what:'data', foo:'blablabla' });
Работает очень быстро, можете поверить. При чем тут ограничения самого Javascript?
> во первых производительностью JS не блещет,
Вы про какую реализацию сейчас говорите?
Рыбак рыбака видит издалека! ;-)
> пусть он приведёт пример веб-сервера на JS поддерживающий HTTP 1.1 или его надо с нуля писать чтобы простейший сайт сделать
Берем open-source HTTP-сервер. Берем open-source реализацию Javascript и прикручиваем.
Разумеется, будут проблемы и прочее. Но работать будет. Но «заново» писать ничего не надо.
Вы что хотите сказать, что веб-сервера, использующие php, написаны для этого как-то особенно??
> нет strict синтаксиса, т.е. любые опечатки в названиях переменных или свойствах объектов и отладка превращается в многочасовой кошмар
Да, это плохо. Это плата за расширяемость.
> ООП ужасно неудобное
Спорно. Оно просто другое. Не похожее на обычную парадигму.
> найтивной поддержки модульности и нормального наследования,
Понятия «нормальное» наследования не существует. В реализации JS есть свои плюсы и минусы. Но лучшего-пригодного-навсегда-и-везде механизма наследования — нету в природе.
Модульность спокойно обеспечивается созданием объектов. Можно скрыть все что угодно и все что угодно выставить наружу.
> невозможность работать с двоичными данными, только с текстовыми, ни о какой серьёзности и гибкости языка после этого говорить уже нельзя
С таким подходом боюсь большую часть языков на помойку придется отправить :)
Зачем в скриптовом языке вам понадобилось битами жонглировать?
> сетевое взаимодействие только по HTTP протоколу
Это не ограничение языка. Это не ограничение вообще. Напишите свою реализацию и вперед.
> написать многозадачное приложение на JS? НЕТ
Причем тут Javascript??
> а передать или принять данные от другого приложения не по HTTP, тоже никак?
Ну хорошо вот как в моей среде (которая использует серверный Javascript) можно передать асинхронное сообщение по локальной сети:
transmit_message(address, { what:'data', foo:'blablabla' });
Работает очень быстро, можете поверить. При чем тут ограничения самого Javascript?
> во первых производительностью JS не блещет,
Вы про какую реализацию сейчас говорите?
> Не похожее на обычную парадигму.
Какую ещё обычную?
> Понятия «нормальное» наследования не существует. В реализации JS есть свои плюсы и минусы
Так в том-то и дело, что JS полностью и насквозь пронизан наследованием ещё до того, как мы напишем сколь-нибудь серьёзные объекты.
Как только вы полностью поймёте эту строку, вопрос о наследовании отпадёт сам собой. И вы увидите, что наследование в JS мало чем отличается от наследования в Python.
Какую ещё обычную?
> Понятия «нормальное» наследования не существует. В реализации JS есть свои плюсы и минусы
Так в том-то и дело, что JS полностью и насквозь пронизан наследованием ещё до того, как мы напишем сколь-нибудь серьёзные объекты.
alert(1..toString());
Как только вы полностью поймёте эту строку, вопрос о наследовании отпадёт сам собой. И вы увидите, что наследование в JS мало чем отличается от наследования в Python.
Какой старый топик Вы подняли, полугодичной давности =)
Это читается следующим образом (позволю процитировать себя же):
Подробней: javascript.ru/blog/Dmitry-A.-Soshnikov/Tonkosti-ECMA-262-3.-CHast-7.-OOP.#nasledovanie
А лучше статью по ссылке прочесть полностью.
Это читается следующим образом (позволю процитировать себя же):
… из примитива 1 создаётся wrapper-объект new Number(1) и у этого wrapper-a вызывается унаследованный метод .toString(). Почему унаследованный? Потому, что объекты в ECMAscript могут иметь собственные (own) свойства, а wrapper-объект, в данном случае, не имеет собственного метода .toString(), соответственно, он наследует его от прототипа, на который, если ничего не менялось, указывает Number.prototype
Обратите внимание, две точки в примере выше — это не ошибка, просто первая точка распознаётся как отделение дробной части числа, а вторая — уже, как выражение доступа к свойству.
Подробней: javascript.ru/blog/Dmitry-A.-Soshnikov/Tonkosti-ECMA-262-3.-CHast-7.-OOP.#nasledovanie
А лучше статью по ссылке прочесть полностью.
>С таким подходом боюсь большую часть языков на помойку придется отправить :)
>Зачем в скриптовом языке вам понадобилось битами жонглировать?
Не все. В Ruby во-первых есть методы pack/unpack для работы с бинарными данными.
А во вторых, просто волшебная библиотека bindata(тоже DSL:))
>Зачем в скриптовом языке вам понадобилось битами жонглировать?
Не все. В Ruby во-первых есть методы pack/unpack для работы с бинарными данными.
А во вторых, просто волшебная библиотека bindata(тоже DSL:))
>Зачем в скриптовом языке вам понадобилось битами жонглировать?
Чтоб упаковывать данные, в файл например или для передачи по сети.
Читать двоичные данные по шаблону.
Чтобы поддерживать разные архитектуры: в одной старший бит находится справа, в другой — слева.
Работать с разными кодировками.
Например, составить слово «тест» в кодировке Windows-1251
В perl будет так: var test = pack('H*', 'F2E5F1F2');
попробуйте тоже само сделать в других языках, не работающих с бинарными данными, вам что исходный код программы надо будет в кодировку windows-1251 переводить? А если понадобиться еще одно слово в другой кодировке.
Чтоб упаковывать данные, в файл например или для передачи по сети.
Читать двоичные данные по шаблону.
Чтобы поддерживать разные архитектуры: в одной старший бит находится справа, в другой — слева.
Работать с разными кодировками.
Например, составить слово «тест» в кодировке Windows-1251
В perl будет так: var test = pack('H*', 'F2E5F1F2');
попробуйте тоже само сделать в других языках, не работающих с бинарными данными, вам что исходный код программы надо будет в кодировку windows-1251 переводить? А если понадобиться еще одно слово в другой кодировке.
Зрите в корень. У JS сейчас ниша занята определённая. При преносе этой нише в то же русло, что и Ruby — дополнительный функционал (соекты, файлы, многопточность и т.д.) допишутся в движок очень быстро. Более того, многие реализации этот функционал имеют (скачайте и скомпиллируйте, например, SpiderMonkey с поддержкой объекта File и ещё много чем).
> — ООП ужасно неудобное
Альтернативная парадигма. Скорее, Вам, «ужасно непривычная».
> При создании экземпляров копируются методы и свойства, что сильно засоряет память и бьёт по производительности
Не возражаете, если я назову это бредом? ;)
— изначально нет никакой найтивной поддержки модульности и нормального наследования, что вполне объясняется предназначением языка — «небольшие скрипты улучшения интерфейса на клиентской стороне»
Тоже, не против, если назову это ерундой? ;)
> — ООП ужасно неудобное
Альтернативная парадигма. Скорее, Вам, «ужасно непривычная».
> При создании экземпляров копируются методы и свойства, что сильно засоряет память и бьёт по производительности
Не возражаете, если я назову это бредом? ;)
— изначально нет никакой найтивной поддержки модульности и нормального наследования, что вполне объясняется предназначением языка — «небольшие скрипты улучшения интерфейса на клиентской стороне»
Тоже, не против, если назову это ерундой? ;)
Зрите в корень. У JS сейчас ниша занята определённая. При преносе этой нише в то же русло, что и Ruby — дополнительный функционал (соекты, файлы, многопточность и т.д.) допишутся в движок очень быстро. Более того, многие реализации этот функционал имеют (скачайте и скомпиллируйте, например, SpiderMonkey с поддержкой объекта File и ещё много чем).
А вот тут мне придёться согласиться с изначальной идеей автора поста:
А ЗАЧЕМ? Если это уже реализовано, причём реализовано хорошо.
> При создании экземпляров копируются методы и свойства, что сильно засоряет память и бьёт по производительности
Не возражаете, если я назову это бредом? ;)
Не возражаю, я поторопился. Я имел в виду ООП в JS основанную на замыканиях, почему именно такая модель более распространена я не помню, ибо в последний раз имел дело с JS ООП более полгода назад, но осадок остался =)
— изначально нет никакой найтивной поддержки модульности и нормального наследования, что вполне объясняется предназначением языка — «небольшие скрипты улучшения интерфейса на клиентской стороне»
Тоже, не против, если назову это ерундой? ;)
А вот тут буду против, но напишу позже, ибо мне надо уходить =)
А вот тут мне придёться согласиться с изначальной идеей автора поста:
А ЗАЧЕМ? Если это уже реализовано, причём реализовано хорошо.
> При создании экземпляров копируются методы и свойства, что сильно засоряет память и бьёт по производительности
Не возражаете, если я назову это бредом? ;)
Не возражаю, я поторопился. Я имел в виду ООП в JS основанную на замыканиях, почему именно такая модель более распространена я не помню, ибо в последний раз имел дело с JS ООП более полгода назад, но осадок остался =)
— изначально нет никакой найтивной поддержки модульности и нормального наследования, что вполне объясняется предназначением языка — «небольшие скрипты улучшения интерфейса на клиентской стороне»
Тоже, не против, если назову это ерундой? ;)
А вот тут буду против, но напишу позже, ибо мне надо уходить =)
> А ЗАЧЕМ? Если это уже реализовано, причём реализовано хорошо.
Всё это и так во всех языках реализовано. Сравнивать нужно архитектурные и идеологически идеи, а не набор стандартной библитеки. «Зрите в корень», как раз относилось к иделогиям, схожим в JS и Ruby, но и имеющим свои особенности.
> Я имел в виду ООП в JS основанную на замыканиях
Ай, опять придётся бредом назвать, уж извините. Почитайте (если конечно интересно ;) статью полностью, чтобы в следующий раз быть подкованней в беседах о JS.
> почему именно такая модель более распространена я не помню, ибо в последний раз имел дело с JS ООП более полгода назад, но осадок остался
ну, тогда простительно ;)
> А вот тут буду против, но напишу позже, ибо мне надо уходить =)
Я подожду, мне интересно.
Всё это и так во всех языках реализовано. Сравнивать нужно архитектурные и идеологически идеи, а не набор стандартной библитеки. «Зрите в корень», как раз относилось к иделогиям, схожим в JS и Ruby, но и имеющим свои особенности.
> Я имел в виду ООП в JS основанную на замыканиях
Ай, опять придётся бредом назвать, уж извините. Почитайте (если конечно интересно ;) статью полностью, чтобы в следующий раз быть подкованней в беседах о JS.
> почему именно такая модель более распространена я не помню, ибо в последний раз имел дело с JS ООП более полгода назад, но осадок остался
ну, тогда простительно ;)
> А вот тут буду против, но напишу позже, ибо мне надо уходить =)
Я подожду, мне интересно.
Статью почитал, очень хорошая статья.
www.webdemon.net/blog/object-oriented-javascript/ вот тут говорится про тот подход что я имел в виду и 2 раза был назван бредом =) (когда я этим занимался, это был самый популярный подход к организации ООП в JS), опять же про наследование почитал, чтобы вести беседу мне надо глубже разобраться в парадигме прототипирования я пока не готов в этом вопросе.
С JS оказывается я имел дело более чем полгода точно =)
По поводу модульности, я имел в виду раздельные области имён для разных файлов с кодом, дабы при подключении нового файла со скриптами ничего не поломалось, ни на уровне языка, ни какого-то общего подхода в JS для этого на данный момент нет насколько я в курсе. Т.е. просто случайно подгружаем файл с подобной уже загруженным областью имён, и без ошибок и.т.п. получаем кучу неработающего кода.
Всё это и так во всех языках реализовано. Сравнивать нужно архитектурные и идеологически идеи, а не набор стандартной библитеки. «Зрите в корень», как раз относилось к иделогиям, схожим в JS и Ruby, но и имеющим свои особенности.
Опять же переиначу вопрос автора: что может Javascript того что не могут другие языки хотя бы из набора (Ruby,Perl,Python)? Потому что мы выяснили что есть вещи которые JS сделать на данный момент не может, или может но намного хуже.
Опять же ЗАЧЕМ его развивать если он не может ничего выдающегося, мало того отстаёт по возможностям, почему бы не развить те языки (более матёрые и гибкие), которые уже есть?
Опять же, никаких революционных идей не видно. JS пытается догнать текущие скриптовые языки по функционалу, но где революция то, где «архитектура»?
Есть какие то тесты в которых только «ИТОГО» в основном, в других с другими языками есть немного сравнений, но все не в пользу JS (честно 15 минут гуглил =) ). Попытался скачать готовый интерпретатор V8( от мозиллы кстати нашёл, причём быстро им зачёт)… за 15 минут не нашёл, буду собирать из исходников, погоняю их.
www.webdemon.net/blog/object-oriented-javascript/ вот тут говорится про тот подход что я имел в виду и 2 раза был назван бредом =) (когда я этим занимался, это был самый популярный подход к организации ООП в JS), опять же про наследование почитал, чтобы вести беседу мне надо глубже разобраться в парадигме прототипирования я пока не готов в этом вопросе.
С JS оказывается я имел дело более чем полгода точно =)
По поводу модульности, я имел в виду раздельные области имён для разных файлов с кодом, дабы при подключении нового файла со скриптами ничего не поломалось, ни на уровне языка, ни какого-то общего подхода в JS для этого на данный момент нет насколько я в курсе. Т.е. просто случайно подгружаем файл с подобной уже загруженным областью имён, и без ошибок и.т.п. получаем кучу неработающего кода.
Всё это и так во всех языках реализовано. Сравнивать нужно архитектурные и идеологически идеи, а не набор стандартной библитеки. «Зрите в корень», как раз относилось к иделогиям, схожим в JS и Ruby, но и имеющим свои особенности.
Опять же переиначу вопрос автора: что может Javascript того что не могут другие языки хотя бы из набора (Ruby,Perl,Python)? Потому что мы выяснили что есть вещи которые JS сделать на данный момент не может, или может но намного хуже.
Опять же ЗАЧЕМ его развивать если он не может ничего выдающегося, мало того отстаёт по возможностям, почему бы не развить те языки (более матёрые и гибкие), которые уже есть?
Опять же, никаких революционных идей не видно. JS пытается догнать текущие скриптовые языки по функционалу, но где революция то, где «архитектура»?
Есть какие то тесты в которых только «ИТОГО» в основном, в других с другими языками есть немного сравнений, но все не в пользу JS (честно 15 минут гуглил =) ). Попытался скачать готовый интерпретатор V8( от мозиллы кстати нашёл, причём быстро им зачёт)… за 15 минут не нашёл, буду собирать из исходников, погоняю их.
> www.webdemon.net/blog/object-oriented-javascript/ вот тут говорится про тот подход что я имел в виду и 2 раза был назван бредом =) (когда я этим занимался, это был самый популярный подход к организации ООП в JS
Ну, обычная прикладная статья, относительно — весьма поверхностная. Ни лучше, ни хуже других (десяти, ста) прикладных статей об ООП в JS. Там «бред» не пишется, но то, что я отметил как «бред» в ваших постах, остаётся бредом. И я говорю это исключительно с благой, образовательной целью. Если нужно пояснить, почему бред, с удовольствием расскажу (если, опять же, интересен сам JS).
> По поводу модульности, я имел в виду раздельные области имён для разных файлов с кодом, дабы при подключении нового файла со скриптами ничего не поломалось, ни на уровне языка, ни какого-то общего подхода в JS для этого на данный момент нет насколько я в курсе. Т.е. просто случайно подгружаем файл с подобной уже загруженным областью имён, и без ошибок и.т.п. получаем кучу неработающего кода.
Ну так это идеология такая — dynamic mutable objects — да, объекты могут быть переопределены, не статика же. Да, текущая версия стандарта понятий пространства имён и модулей не описывает. Однако, можно использовать для неймспейсов отдельные объекты.
> Опять же ЗАЧЕМ его развивать если он не может ничего выдающегося, мало того отстаёт по возможностям, почему бы не развить те языки (более матёрые и гибкие), которые уже есть?
Если вы обратили внимание, моя позиция (в отличии от автора топика) анализирующая. Я не отстаиваю ни один из обсуждаемых языков, хотя и знаю три из них (JS, Ruby, Python) достаточно хорошо (а JS занимаюсь на «академическом» уровне).
Меня, повторю, в большей степени интересует схожесть идеологий этих языков. Стандартная библиотека и «синтаксический сахар» — дописывается «за день», при условии, что JS займёт ещё какую-нибудь альтернативную нишу. При этом я имею в виду, не поделки вроде фреймворков и т.д., а доработку самого языка, ядра, модулей и стандартной библиотеки. Если рассуждать глобально, это мелочи. Важная схожесть идеологий.
> Опять же, никаких революционных идей не видно. JS пытается догнать текущие скриптовые языки по функционалу, но где революция то, где «архитектура»?
Что за революционные идеи ещё? Что вы вкладываете в это определение? Ну ладно, в 60-ые, 70-ые, 80-ые, Simula, SmallTalk, Self — здесь можно ещё говорить о какой-то революции. Более молодые языки, типа Python, Ruby и JS питали идеи уже из них. JS при этом в текущей версии был реализован на базе прототипов, делегирования и динамических объектов — это его архитектура, частью позаимствованная из Self-a, SmallTalk-a и Python-a. Python ввёл понятие класса, но, по большому счёту, класс там можно приравнять к «синтаксическому сахару», т.к. используется та же делегация, что и в прототипировании.
> Есть какие то тесты в которых только «ИТОГО» в основном, в других с другими языками есть немного сравнений, но все не в пользу JS
Ну, это уже дело десятое, в этой беседе — слишком прикладное, не идеологическое. Хотя, конечно, если задаться провидением тестирования схожих языков в схожем функционале — конечно, тесты можно провести (если интересно).
Ну, обычная прикладная статья, относительно — весьма поверхностная. Ни лучше, ни хуже других (десяти, ста) прикладных статей об ООП в JS. Там «бред» не пишется, но то, что я отметил как «бред» в ваших постах, остаётся бредом. И я говорю это исключительно с благой, образовательной целью. Если нужно пояснить, почему бред, с удовольствием расскажу (если, опять же, интересен сам JS).
> По поводу модульности, я имел в виду раздельные области имён для разных файлов с кодом, дабы при подключении нового файла со скриптами ничего не поломалось, ни на уровне языка, ни какого-то общего подхода в JS для этого на данный момент нет насколько я в курсе. Т.е. просто случайно подгружаем файл с подобной уже загруженным областью имён, и без ошибок и.т.п. получаем кучу неработающего кода.
Ну так это идеология такая — dynamic mutable objects — да, объекты могут быть переопределены, не статика же. Да, текущая версия стандарта понятий пространства имён и модулей не описывает. Однако, можно использовать для неймспейсов отдельные объекты.
> Опять же ЗАЧЕМ его развивать если он не может ничего выдающегося, мало того отстаёт по возможностям, почему бы не развить те языки (более матёрые и гибкие), которые уже есть?
Если вы обратили внимание, моя позиция (в отличии от автора топика) анализирующая. Я не отстаиваю ни один из обсуждаемых языков, хотя и знаю три из них (JS, Ruby, Python) достаточно хорошо (а JS занимаюсь на «академическом» уровне).
Меня, повторю, в большей степени интересует схожесть идеологий этих языков. Стандартная библиотека и «синтаксический сахар» — дописывается «за день», при условии, что JS займёт ещё какую-нибудь альтернативную нишу. При этом я имею в виду, не поделки вроде фреймворков и т.д., а доработку самого языка, ядра, модулей и стандартной библиотеки. Если рассуждать глобально, это мелочи. Важная схожесть идеологий.
> Опять же, никаких революционных идей не видно. JS пытается догнать текущие скриптовые языки по функционалу, но где революция то, где «архитектура»?
Что за революционные идеи ещё? Что вы вкладываете в это определение? Ну ладно, в 60-ые, 70-ые, 80-ые, Simula, SmallTalk, Self — здесь можно ещё говорить о какой-то революции. Более молодые языки, типа Python, Ruby и JS питали идеи уже из них. JS при этом в текущей версии был реализован на базе прототипов, делегирования и динамических объектов — это его архитектура, частью позаимствованная из Self-a, SmallTalk-a и Python-a. Python ввёл понятие класса, но, по большому счёту, класс там можно приравнять к «синтаксическому сахару», т.к. используется та же делегация, что и в прототипировании.
> Есть какие то тесты в которых только «ИТОГО» в основном, в других с другими языками есть немного сравнений, но все не в пользу JS
Ну, это уже дело десятое, в этой беседе — слишком прикладное, не идеологическое. Хотя, конечно, если задаться провидением тестирования схожих языков в схожем функционале — конечно, тесты можно провести (если интересно).
все рассуждения о конкретной реализции. про ООП — все от непонимания. писать различные варианты ООП на js просто и приятно. единственный верно подмеченный минус — модульность. (я вообше за python, но js зря обижать тоже не нужно)
холивар
Зачем другие программисты, если есть вы?
Автор — гений, я вам поклоняюсь, вы гуру! Вы — лучше всех, вы всех победили!
только пожалуйста, не пишите больше подобной гуйни.
только пожалуйста, не пишите больше подобной гуйни.
Жалко на хабре нет цитатника:)
>>> Сразу хочется спросить — может надо было бейсик взять? Он тоже скриптовый. И тоже медленно работает…© Krovosos
>>> Сразу хочется спросить — может надо было бейсик взять? Он тоже скриптовый. И тоже медленно работает…© Krovosos
Топик — пук в некуда.
Автор не является ценителем красоты
Интересно как он реализует на JS binding?
А attr_accessor в JS появились совсем недавно
Есть реализация ruby на JS hotruby.yukoba.jp
Автор не является ценителем красоты
Интересно как он реализует на JS binding?
А attr_accessor в JS появились совсем недавно
Есть реализация ruby на JS hotruby.yukoba.jp
> Автор не является ценителем красоты
Кто вам там что навнушал? Какие заголовки статей и чьи-то комментарии о «красоте и элегантности»? =) Оба, Ruby и JS — красивые и элегантные. Цените.
> Интересно как он реализует на JS binding?
Что значит реализует binding? Запомнить текущий лексический контекст? Как в Ruby нельзя, однако, в некоторых реализациях, например, SpiderMonkey до версии 1.7 позволяют eval-у передавать вызывающий контекст, равно как и в Ruby передавать запомненный binding.
> Есть реализация ruby на JS hotruby.yukoba.jp
А вот это интересно, спасибо.
Кто вам там что навнушал? Какие заголовки статей и чьи-то комментарии о «красоте и элегантности»? =) Оба, Ruby и JS — красивые и элегантные. Цените.
> Интересно как он реализует на JS binding?
Что значит реализует binding? Запомнить текущий лексический контекст? Как в Ruby нельзя, однако, в некоторых реализациях, например, SpiderMonkey до версии 1.7 позволяют eval-у передавать вызывающий контекст, равно как и в Ruby передавать запомненный binding.
> Есть реализация ruby на JS hotruby.yukoba.jp
А вот это интересно, спасибо.
>> Есть реализация ruby на JS hotruby.yukoba.jp
Еще есть такая забавная вещь, как red
По сути, то же что и GWT только на Ruby.
Еще есть такая забавная вещь, как red
По сути, то же что и GWT только на Ruby.
Совершенно не важно, каковы возможности синтаксиса и скорость исполнения. В свое время РНР вышел с очень важными фичами: интеграция с веб-сервером и встраивание в HTML код. Этого оказалось достаточно, чтобы положить на лопатки даже царствовавший в то время Перл. И его знаменитые скорстя не спасли и убогость молодого РНР не отвернула.
Я тоже иногда начинаю есть суп ножом, но обычно быстро понимаю, что что-то не так, и беру ложку…
Ну я думаю, что создатель какого-нибудь языка хочет создать что-то своё.
А во-вторых, не всем нравится Javascript.
А во-вторых, не всем нравится Javascript.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Есть Javascript. Зачем нужны другие скриптовые языки?