Чем Ruby лучше Java, в контексте упрощенной разработки

> язычок для мидлетов на маленьких телефончиках (без "Симбиана")

У меня Symbian, но почему-то софта на Java в нём раза в 3 больше, чем нативного. К чему бы это?

> НЕТ УНИВЕРСАЛЬНОГО ЯЗЫКА ПРОГРАММИРОВАНИЯ!

Есть. Java. Сам же сказал - работает от телефончиков до enterprise, от игрушек до огромных корпоративных информационных систем!

Вдогоночку.

По поводу WebSphere. Что-то как-то снова для MOM использовать IBM WS MQ Broker (в ядре своем Си-шный), который НИКАКОГО отношения к JMS WS MQ на тормозах EJB MDB не имеет, кроме как эклипсовой оболочки. Вот и дали команду "фас" бывшим своим коллегам. К skills Тэйта эта статейка тоже никакого отношения не имеет - чистА PR-заказ, подготовка обЧественного мнения.

> Кстати, гневынх реплик вида "Вот могучее приложение XXX, писанное на Руби!" на свой вопрос, кто же его пользует, я тоже не вижу...

http://easinstaller.sourceforge.net/

GUI, threading, i18n, terminal emulation через expect, повышение полномочий через sudo.

>В PHP есть try, catch, throw. А так же "old way" trigger_error и set_error_handler.

А зачем там try / catch ? обьясните

Вопрос не в том, что работает, а КАК работает.

> К чему бы это?

Ню-ню! Количество и качество - разные категории. Давай мне на JSR184 чё-нить слабай с хотя бы двумя десятками мэшей, если ты такой вумный.:)

> Balabol

Это точно!

> От циклов вообще нужно по взоможности отказываться. Есть же рекурсия, она и понятнее и противоречеустойчивее.

А стек, надо понимать, бесконечный?

А у нас хвостовая рекурсия =)

> Есть же рекурсия, она и понятнее и противоречеустойчивее.

И почему тогда в функциональных языках предпочитают использовать всякие комбинаторы да итераторы? foldl там всякие, и прочие map-ы?

Ах да... Я и забыл. А если задача не сводится к хвостовой рекурсии, то что?

> А если задача не сводится к хвостовой рекурсии, то что?

Если она может быть выражена через цикл, то она по определению сводится к хвостовой рекурсии, ламер.

> А если задача не сводится к хвостовой рекурсии, то что?

Тогда она и к циклу не сведется.

> Если она может быть выражена через цикл, то она по определению сводится к хвостовой рекурсии, ламер.

Если кто и ламер, то это ты: любая задача может быть решена через последовательный оператор и цикл while. Так что, обойдемся без хвостовой рекурсии и прочих лишних сущностей.

>Сам ты ламер.

Твоя хвостовая рекурсия нах - не нужно если девелопер ПОНИМАЕТ что он делает. И НИ..РА не поможет если он дебил.

>Если кто и ламер, то это ты: любая задача может быть решена через последовательный оператор и цикл while. Так что, обойдемся без хвостовой рекурсии и прочих лишних сущностей.

:))))))))))))))))))))))))))))

2All: не, таких кадров нужно в цырке показывать и кино о них снимать:)

> Так что, обойдемся без хвостовой рекурсии и прочих лишних сущностей.

И обходимся. Но с ней реально удобнее - можно итераторы удобные делать.

>хвостовая рекурсия нах - не нужно если девелопер ПОНИМАЕТ что он делает. И НИ..РА не поможет если он дебил.

Если "девелопер" не понимает, что такое хвостовая рекурсия, то он не девелопер, а девелОпер:), или, другими словами, как раз дебил:)

> 2All: не, таких кадров нужно в цырке показывать и кино о них снимать:)

Ну ясно, ты, мальчик, книжек классических не читал и теперь умничаешь. Ладно, иди дальше лови хвостовую рекурсию, новый фетиш "мастеров" от программирования ;)

>А у меня есть критика его книги Bitter Java - и что?

У него странные взгляды на то как ускорить работу форума (а точнее одна теория без реальных указаний/ вода одна на эту тему) / странная книга

>Особенно впечатлили сентенции про итерацию массивов... По книге ощущение, что он, мягко говоря, не первый год знает Java;

Вроде там много редакторов и рецензентов книги было (навенно они ему код подравили перед печатью а тут он сам ляпнул что то не то)

представляю если бы он там в примере ассоциативный массив итерировал (на php кстати красивее (foreach) ) тут бы все наверно просто рыдали.

> You must declare every variable and every parameter, which requires more time for much less benefit than you think, if you accept the idea that automated unit tests should catch many of your mistakes.

То есть, теперь контролировать типы данных на этапе компиляции не модно. Юнит-тесты, видите ли, все поймают. Однако "many" не есть "all", и вот оставшиеся ошибки будут ловиться вручную, долго и увлекательно.

> То есть, теперь контролировать типы данных на этапе компиляции не модно.

Это интересный вопрос. Вообще я пришел к выводу, что явная типизация параметров - это хорошо и правильно, но, строго говоря, должно входить в precondition метода в терминах DbC, а не являться частью сигнатуры. Т.е. ограничение типа 'x is Integer' по сути своей не отличается от 'x != 0', а когда эти проверки выполнять, compile-time или run-time - это отдать на откуп компилятору. Перегрузка функций по типу аргументов - зло, вызванное отсутствием именованных параметров у функций (см. Smalltalk и Objective C для показательного примера, как оно должно бы выглядеть).

А вот нафиг явно типизировать локальные переменные, я вообще не понимаю. О какой-либо доп. безопасности там речь идти не может, тело метода - это вещь в себе. Оптимизация - что, компилятор такой тупой, не выведет тип переменной при ее инициализации?

Кстати, необходимость явной типизации параметров и возвращаемого значения private-методов тоже вызывает сильные сомнения, по схожим причинам.

> любая задача может быть решена через последовательный оператор и цикл while

Не с того конца заходишь. Любой цикл может быть организован последством рекурсии (не обязательно хвостовой), если нет ограничений на размер стека. Рекурсия нынче наличествует в любом хоть сколько-то популярном ЯП. Поэтому как раз всякие for и while - это лишние _базовые_ сущности в языке. Однако они бывают удобны, поэтому их наличие в виде функций или макр полезно. Наглядный пример - Nemerle, где while и for имеют один в один сишный синтаксис, но на самом деле это макры, разворачивающиеся в рекурсивный вызов функции.

А хвостовая рекурсия - это всего лишь оптимизация, имитирующая бесконечную глубину стека для одного наиболее часто используемого случая.

> Это интересный вопрос. Вообще я пришел к выводу,...

sic. под каждым словом подпишусь.

хачу именованные параметры в руби!

Пожалуйста, оставьте в покое for и while. Если мне понядобится в теле метода два и более небольших циклов, мне очень не захочется делать для этого две и более ЛИШНИХ в моей программе СУЩНОСТИ в виде методов. Если нравится хвостовая рекурсия, отстаивайте ее идею в Сети, чтобы разработчики javac/eclipse включили соответствующие оптимизации в компиляторы. Но зачем удалять то, что используется давно и эффективно?

ЗЫ. Рекурсию тяжело читать. Даже хвостовую.

Расскажите, мне пожалуйсата, как запустить, Tomcat на мобильнике(у меня java + 512mb flash) должно хватить.
Вы ведиь такой умный и видимо научились переносить программы между j2ee и j2me.

> Рекурсию тяжело читать. Даже хвостовую.

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

И особенно в J2ME.

Когда это J2ME "Тигру" поддерживать будет?

Даже в WSTK 2.3 beta читаем, (внимательно):

"2.1 Required Software

* Microsoft Windows XP

* JavaTM 2 SDK, Standard Edition (J2SE SDK), version 1.4.2 - if you plan to do actual development, or JavaTM 2, Standard Edition Runtime Environment (JRE), version 1.4.2 - if you only plan to run the demonstration applications."

Заметим! * Microsoft Windows XP - и никаких Ляликсов или Соплярисов. Бета-тестер должен работать на стабильной ОС. Кстати, в релизе 2.2 Линукс юзается на свой страх и риск, причём рекомендуется только RH9:

" One of the following operating environments:

* Microsoft Windows XP * Linux (unsupported)

...

NOTE: The Linux version of the toolkit is unsupported and has undergone only limited testing on the Red Hat 9.0 distribution. "

Достаточно посмотреть, насколько CLDC 1.1 более убога по коллекциям, чем даже J2SE 1.4.2.

Так что место Джавы == это место её родителя Оука. То есть пульты, мобильнички среднего класса и т.п.. Начиная с коммуникаторов - .NET 2.0 будет. Ну и T-SQL, PL/SQL для enterpriZe.

Так что прав B.A.Tate, хочешь баксов - будешь конъюктурщиком.

> Странно - такой резкий контраст между этой статьей и его книгой "Горький вкус Java" по уровню профессионализма...

И чего ты в этой книжке нашел, что и так не очевидно? Вот Joshua Bloch или Doug Lea - матерые люди, их почитать одно удовольствие.

спасибо за совет :)

> Если мне понядобится в теле метода два и более небольших циклов, мне очень не захочется делать для этого две и более ЛИШНИХ в моей программе СУЩНОСТИ в виде методов.

Млин, ну хоть читай посты внимательно, а?

Да пусть они там будут, ваши циклы. В стандартной библиотеке, сделанные макрами или еще чем и разворачивающиеся в рекурсию. И пиши себе на здоровье. А вот плодить лишние сущности в семантике языка - нефиг.

И еще раз повторюсь: сходи и почитай о Nemerle. Очень наглядный пример, как из функций и рекурсии можно сделать практически один в один сишный синтаксис, котоый вы все (да и я сам, чего уж там...) так любите.

> Вообще я пришел к выводу, что явная типизация параметров - это хорошо и правильно, но, строго говоря, должно входить в precondition метода в терминах DbC, а не являться частью сигнатуры. Т.е. ограничение типа 'x is Integer' по сути своей не отличается от 'x != 0', а когда эти проверки выполнять, compile-time или run-time - это отдать на откуп компилятору. Перегрузка функций по типу аргументов - зло, вызванное отсутствием именованных параметров у функций (см. Smalltalk и Objective C для показательного примера, как оно должно бы выглядеть).

Это всё воплощено в Perl6. Насколько я знаю, там статические предусловия для параметров функций, как "x is Integer" или "x + y > 2" проверяются в compile-time когда возможно, а когда невозможно, то в run-time.

Вообще, Perl6 делает Ruby менее актуальным, хотя, конечно же, Ruby - язык достойный (в частности, потому как основан на Perl5).

> Это всё воплощено в Perl6. Насколько я знаю, там статические предусловия для параметров функций, как "x is Integer" или "x + y > 2" проверяются в compile-time когда возможно, а когда невозможно, то в run-time.

Я знаю. В Perl6 однако много новых фич весьма сомнительного характера. В частности, местный подход к ООП и мультиметодам мне не очень нравится (хотя, в Ruby их вообще нет - так что...).

> Вообще, Perl6 делает Ruby менее актуальным, хотя, конечно же, Ruby - язык достойный (в частности, потому как основан на Perl5).

С каких пор Ruby основан на Perl? =) Синтаксис разве что кое-где (регэкспы и magic variables), а семантически оно очень похоже на Smalltalk.

O'Reilly Interview: What bits of Perl did you incorporate in Ruby?

Matz: A lot. Ruby's class library is an object-oriented reorganization of Perl functionality--plus some Smalltalk and Lisp stuff. I used too much, I guess. I shouldn't have inherited $_, $&, and the other, ugly style variables.

> (в частности, потому как основан на Perl5).

Matz имел в виду всякого рода стилистические примочки типа $1..$9, %r{}, %w{}, //, etc.. конечно на более глубоком уровне от перла там нет ничего. с тем же успехом можно утверждать что руби от паскаля наследует.

а перл 6.. не берусь судить насколько он хорош или плох по семантике -- апокалипсы внимательно не читал (хотя нагородили они там.. ой-е..). проблема в том что у него есть один фундаментальный недостаток -- его нет, и при нашей жизни его наверное уже не будет.

Ты английский понимаешь? :)

"Ruby's class library is an object-oriented reorganization of Perl functionality" что на русском означает, "Ruby - это объектная реализация/реорганизация функциональности Perl".

Зная все 3 языка, я полностью согласен с автором. Несмотря на то, что Ruby имеет синтакс схожий с Python, идеологически он далек от Python и близок к Perl, TMTOWTDI. Достаточно сказать, что на Ruby можно такие же one-liners писать как и на Perl (програмки в одну строку; да и command line options у них схожи). Python намерено урезан, дабы быть TOORWTDI.

> у [perl6] есть один фундаментальный недостаток -- его нет, и при нашей жизни его наверное уже не будет

pugs можно и сегодня запускать, базисный perl6 определён и осуществлен, хоть и частично, но есть шансы, что при нашей жизни... :)

> Зная все 3 языка, я полностью согласен с автором.

зная еще и схему, я-то знаю откуда ноги растут :-)

> Ruby's class library is an object-oriented reorganization of Perl functionality

ну взял и засунул Matz практически целиком perldoc perlfunc в набор из Kernel, File, Dir, сотоварищи. именно так эту фразу и следует читать, и больше из нее решительно ничего не следует.

> pugs можно и сегодня запускать

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

> но есть шансы, что при нашей жизни... :)

да разве-ж я против? :-)

другое дело что та же rite будет во вполне обозримом будущем. смотрю вот временами на http://atdot.net/viewcvs.cgi/yarv/trunk/ и радуюсь.

> зная еще и схему, я-то знаю откуда ноги растут :-)

И откуда же? :) Что лиспового есть в Ruby чего он не взял из Perl?

> ну взял и засунул Matz практически целиком perldoc perlfunc в набор из Kernel, File, Dir, сотоварищи. именно так эту фразу и следует читать, и больше из нее решительно ничего не следует

Подозреваю, что ты не знаешь Perl на высоком уровне, иначе бы перловый look-and-feel просто бросался бы тебе в глаза, абсолютно во всем, от синтаксиса и флагов, до функциональности, идиом и идеологии. :)

Так ведь Matz и не скрывает, прямо говорит, что ему кое-что в Perl не понравилось в 1993 и он решил его улучшить.

> И откуда же? :) Что лиспового есть в Ruby чего он не взял из Perl?

lisp != schema

по существу. самое главное свойство по которому можно классифицировать языки скриптовые -- то как хранятся переменные и как передаются параметры. я имею в виду не то как оно в синтаксисе выглядит, а то как оно с памятью общается. к примеру, в php по умолчанию все передается по значению. то есть если я сделаю func(array(1, 2, ... 100000)) функция получит не тот же экземпляр массива, а его копию. то есть func($a) {$a[0] = 'aaa';} сделает совсем не то что следовало бы ожидать человеку, который знает о строгом, в стиле схемы, разделении между контейнерными типами и иммедиатами (как блин это по русски?). правильно, в перле та же фигня -- что бы передать указатель на объект, это надо указывать специально.

в отличие от, в руби такое строгое различие есть. все что не помещается в Fixnum передается как указатель (включая Bignum). и если честно, не так уж много есть кандидатов на отцовство для руби по этому признаку.

еще: строгая динамическая типизация.

еще: first-class functions.

еще: call-ec (исключения и catch/throw)

еще: call-cc

относительно уровня знания perl-а -- нуу.. хитрозадые клозурки в перемешку с егойными объектами я как-то (давно правда) довольно плотно пользовал. :-)

а что касается поверхностного look&feel -- это, применительно к языкам дело десятое.

кстати, есть такая вещь, которая есть в перле и схеме, но отсутствует в (базисном) руби -- флюиды. так что можешь начинать утверждать что перл от схемы произошел :-)

блин, слишком дидактически получилось и не вполне точно. но по существу, в контексте дискуссии -- верно.

В том случае, если я всё же ошибся, и ты знаешь Перл превосходно, то давай будем считать по-твоему, что это два независимых языка. :)

ruby -ne 'print if /GNU/' COPYING

perl -ne 'print if /GNU/' COPYING

ruby -le 'hash = { "sud" => 1, "pop" => 2, "oku" => 3 }; print hash.keys.grep(/u/)'

perl -le '$hash = { sud => 1, pop => 2, oku => 3 }; print grep /u/, keys %$hash'

> В том случае, если я всё же ошибся, и ты знаешь Перл превосходно, то давай будем считать по-твоему, что это два независимых языка. :)

я всего-лишь хотел сказать что такие примеры не имеют значения..

утонченное различие:

ruby -e 'def f(p1,p2);p1.sub(/A/,"B");p2.sub!(/A/,"B");end;p1="A&quo t;;p2="A";f(p1,p2);puts p1+p2'

perl -e 'sub a{$_[0]=~s/A/B/;$_[1]=~s/A/B/;};$p1="A";$p2="A";a($p1,$p2);p rint $p1.$p2."\n";'

> в перле та же фигня -- что бы передать указатель на объект, это надо указывать специально

Почему ты так решил? Вовсе даже наоборот. Всё, кроме базисных типов (string, number) передаётся как reference. Как и в Ruby.

> еще: строгая динамическая типизация

Приведи пример, что именно ты имеешь ввиду.

> еще: first-class functions

Ты имеешь ввиду: my $func = sub { $_[0] + 1 }; или что-то другое?

> исключения

die/eval :)

> можешь начинать утверждать что перл от схемы произошел

Так ведь Larry Wall и не скрывает этого, как и "man perlsyn" (хоть ты и не приравниваешь Lisp и Scheme).

Perl borrows syntax and concepts from many languages: awk, sed, C, Bourne Shell, Smalltalk, Lisp and even English. Other languages have borrowed syntax from Perl... :-)

или:

perl -e 'sub f{my @a=shift;$a[0]=~s/A/B/;$a[1]=~s/A/B/;};@a=("A","A");f(@a);pr int $a[0].$a[1]."\n";'

ruby -e 'def f(a);a[0].sub(/A/,"B");a[1].sub!(/A/,"B");end;a=["A&quo t;,"A"];f(a);puts a[0]+a[1]'

> ruby -e 'def f(p1, p2); p1.sub(/A/, "B"); p2.sub!(/A/, "B"); end; p1 = "A"; p2 = "A"; f(p1, p2); puts p1 + p2'

Ну, вот эта разница как раз и не важна, мы же про объекты говорили? Ну ладно, в perl ты можешь и на оригинальное значение воздействовать и на копию, даже если это и базисные string/number.

perl -le 'sub f ($$) { my ($p1, $p2) = @_; $p1 =~ s/A/B/; $_[1] =~ s/A/B/ }; $p1 = "A"; $p2 = "A"; f($p1, $p2); print $p1, $p2'

> ruby -e 'def f(a); a[0].sub(/A/, "B"); a[1].sub!(/A/, "B"); end; a= ["A", "A"]; f(a); puts a[0] + a[1]'

Всё что не базисный тип, работает через reference. Так же, как и в Ruby.

perl -le 'sub f ($) { $a = shift; $a->[1] = "B" }; $a = [ "A", "B" ]; f($a); print @$a'

Мне кажется, тебе надо подучить perl, если ты пишешь такое: @a=shift.

> Всё, кроме базисных типов (string, number) передаётся как reference.

а что делает оператор '='? и что это имеет общего с руби?

>> еще: строгая динамическая типизация

perl -e 'print 1=="1","\n"'

ruby -e 'p 1=="1"'

ruby -e 'p 1=="1".to_i'

> my $func = sub { $_[0] + 1 };

да, это ты прав конечно (как бы иначе можно было бы клозурки сочинять :-)

> die/eval :)

это сильно не то же самое.

> Perl borrows syntax...

:-) короче все от фон Неймана растут. это-то понятно.

> Ну, вот эта разница как раз и не важна, мы же про объекты говорили?

нет ничего кроме объектов..

> Всё что не базисный тип, работает через reference. Так же, как и в Ruby.

:-) ну более чем не так же.

> Мне кажется, тебе надо подучить perl, если ты пишешь такое: @a=shift.

вернее подвспоминать.. впрочем, да. спешу забыть как страшный сон.

короче, давай завязывать :-) все равно ты не прав.

> > Всё, кроме базисных типов (string, number) передаётся как reference.

> а что делает оператор '='? и что это имеет общего с руби?

В третий раз: нет принципиальной разницы между Ruby и Perl. Ты вообще работал с reference в Perl? Ну, это такие [ 1 .. 10 ] или { 1 => 2 }. :)

>> еще: строгая динамическая типизация

> perl -le 'print 1=="1"'

> ruby -e 'p 1=="1".to_i'

Да, сам постоянно ругаюсь, очень неудобно в Ruby, когда 1 не есть 1. :)

> > die/eval :)

> это сильно не то же самое.

Поверь моим рогам, кроме как синтактического сахара разницы особо никакой, тем более, что die может и объект вызывать, не только string кидать.

(завязываю)

боюсь что ты немножко не понимаешь где синтаксис а где семантика. настоятельно рекомендую http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs.html ибо это должен знать каждый.

Ты бы всё-таки уточнил, что именно я не понимаю, хотелось бы подучить, если так. :)

Просто в Perl есть понятия, не существующие в Ruby (и даже Scheme), и, мне кажется, ты путаешься в них.

Например, в Perl есть array @a и arrayref $a, а в Ruby лишь arrayref a. В Perl есть листовые и скаларные контексты выражений (почти нигде такого нет, хотя в Ruby есть некоторые приведения при инитиализации array). В Perl всё кроме undef, string и number есть reference, а в Ruby всё есть объект, хотя FixNum и исключение при работе с функциями. В функцию Perl, параметры передаются через магический @_, при присваивании через который изменяется все lvalue параметры, даже базисные. При копировании, references или объекты Perl ведут себя как объекты Ruby, нужно делать dereference, чтобы они вели себя иначе.