JRuby 1.0 релиз

> Типа в Питоне есть статическая типизация и проверка типов?

Я этого не говорил вроде

> Или ты в одном топике на Питоне пишешь, а там где не удобно на С++?

Именно так (правда, я не понял, причем тут топики :)). Кстати, если ты такой внимательный, то мог бы заметить, что я часто повторяю фразу "убил бы ради статически типизированного Питона" :)

P.S. а еще я знаю PL/I :D

>> usec - это милисекунды.

> Ты АБСОЛЮТНО уверен в этом?

Я знак вопроса хотел поставить, виноват-с. Я спрашивал.

Но вот отрицательные значения - налицо.

> Ruby компилятором??? кул.

Твое утверждение было настолько общим, что я решил не заморачиваться деталями (кстати, почему Ruby? Там и о Java шла речь).

> а ты не Alonso часом?

Не имею чести знать этого достойного джентльмена :)

Оценивать время Руби кода я бы сейчас никому не рекомендовал ввиду
скорой пересадки Руби на Yarv - с этой машиной время будет сравнимо
со всеми братьями по оружию - python, perl...

> Типа в Питоне есть статическая типизация и проверка типов?

Ну мне же никто не может запретить надеяться на PyPy и ShedSkin? ;)

>в Яве будет выглядеть :)?

Ну приблизительно так:

Time.minutes(5) + Size.megabytes(10) + Length.millimeters(17);

>И кстати у тебя код неправильный как минимум для руби. 

Ща поравняем. Хто ж знал что там не как у людей - общих milliseconds нету, а есть microseconds.

Вот более правильный ответ:
by time 125349

real    2m5.355s
user    1m56.639s
sys     0m0.552s

Лана - отстает от рефлективного метода всего в 2 раза. И в 200 от прямого. 

JRuby:

by time 242026

>PS Интересно, почему у тебя комп в 100 раз быстрее моего? Я в сомнениях.

Панятия не имею: 
CPU: AMD Athlon(tm) 64 Processor 2800+ stepping 00

выключи mysql?:P) Наверное потому что тормозюзя у меня:)

PS: А еще скажите мне почему от такой строки охреневает компилятор:

t = Time.now.usec /1000;

test.rb:1: unterminated string meets end of file
test.rb:1: parse error, unexpected tSTRING_END, expecting tSTRING_CONTENT or tREGEXP_END or tSTRING_DBEG or tSTRING_DVAR

> t = Time.now.usec /1000;

> test.rb:1: unterminated string meets end of file

Ты написал пол-регэкспа :D

/regexp/

>И где теперь Ява?

Ява там не потому что руби хороший, а потому что в ней нету всего одной фичи - переопределения "+". Нахреначить таких классов можно и в жабе. При чем дословно типа: Method m = this.getClass().getMethod("to_" + this.getClass().getName().toLowerCase(), this.getClass(), this.getClass()); return m.invoke(this) + m.invoke(adder);

>Ты написал пол-регэкспа

О как. А то я минут 10 переваривал что не так в этом стринге:

print "by time ", t2.min * 60 * 1000 + t2.sec * 1000 + t2.usec / 1000) - (t.min * 60 * 1000 + t.sec * 1000 + t.usec /1000), "\n";

> Типа в Питоне есть статическая типизация и проверка типов?

Типа есть. В питоне-3000. http://www.python.org/dev/peps/pep-3107/

Цитата из http://www.python.org/dev/peps/pep-3100: Add optional declarations for static typing [done]

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

> уже упомянутые выше полноценные замыкания

ты имеешь ввиду анонимные замыкания появятся???

> после его релиза руби наконец-то умрет в адских муках

до 3000 года еще дожить нужно... :)))

> ты имеешь ввиду анонимные замыкания появятся???

Нет, починят области видимости: http://www.python.org/dev/peps/pep-3104. Точнее, в транке уже починили.

> до 3000 года еще дожить нужно... :)))

Вообще-то я ошибся, правильнее называть Python 3.0, и альфа выйдет уже в этом году, а релиз намечен на следующий год. Да многое уже и сейчас готово: те же области и статическая типизация. Тут вам не Perl 6 ;)

>usec - это милисекунды.

Гы. Т.е. в Руби знаком "мю" стали обозначать "милли"? Ого!

> Ну мне же никто не может запретить надеяться на PyPy и ShedSkin? ;)

Кстати, я на Exception так и не смог объяснить людям, кому и зачем нужна статическая типизация в Python. Пришлось только загадошно улыбаться и говорить, мол, есть такие люди...

>> ты имеешь ввиду анонимные замыкания появятся???

> Нет, починят области видимости: http://www.python.org/dev/peps/pep-3104. Точнее, в транке уже починили.

Не, тогда Руби будет еще жировать долго и счастливо. За подробностями сюда: http://www.linux.org.ru/jump-message.jsp?msgid=1956779#1966806 . Только не спеши отвечать, пока всю ветку не дочитаешь.

Микро, микро, посыпаю голову. И вообще там стоял вопрос, это доли секунды или же полное время.

Из-за невозможности объявить анонимные длинные функции?

Я понимаю, что это недостаток конечно, но его критичность смущает. Если они все равно длинные, ну может объявить уже ее как вложенную?

Кстати, (ко всем:) ) как вы определяете, поддерживать инвариант класса, проверяя "на входе" значения на корректность, или полагаться на разум пользователя класса, который не будет вводить всякую дрянь:) ?

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

Да всё тем же людям, которым нужна статическая типизация в других языках. Чем программы на Питон так отличаются от программ на Си++, Java или Haskell, что для Питона статическая типизация не нужна?

"Giving people dynamically-typed lanhuages doesn't mean that they write dynamically-typed programs"... или как-то так :)

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

Далее имеет место непоследовательность в плане некоторых концепций. Например, вызов 1.__xor__(35) считается синтаксической ошибкой, тогда как, запихни я эту единичку в переменную a, тот же вызов прокатит, хотя и в первом, и во втором случае мы обращаемся к объекту int.

> анонимные функции из нескольких команд не ввели (и не собираются)

4.2, однако...

> анонимные функции из нескольких команд не ввели (и не собираются)

@#$%, а ДРУГИЕ претензии есть? (кроме "у меня 1.__xor__(35) не работает, плохая змея!")

> Чем программы на Питон так отличаются от программ на Си++, Java или Haskell, что для Питона статическая типизация не нужна?

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

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

> Ну вообще отпадает необходимость наследования

/me морщится... ну допустим... хотя зачем это нужно?

> облегчается построение компонентных моделей (типа АОП, если я не ошибаюсь).

Не вижу, как динамическая типизация это облегчает... до сих пор на переднем крае AOP - статически типизированная Java

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

Для меня - да. Причем это мне в разы важнее, чем "отпадение необходимости наследования" и "облегчение AOP" вместе взятые.

> Еще что-то есть?

Возможность генерации эффективного машкода.

> \@\#\$\%, а ДРУГИЕ претензии есть? (кроме "у меня 1.__xor__(35) не работает, плохая змея!") Других нет ))). Хорошая змея.

>> Ну вообще отпадает необходимость наследования

> /me морщится... ну допустим... хотя зачем это нужно?

Устранение двух классических проблем: сильная связность кода и хрупкость базового класса. А с учетом того, что в древовидную таксономию реальная жизнь вписывается крайне похабно, то вообще...

> Не вижу, как динамическая типизация это облегчает...

Не нужно обманывать компилятор.

> до сих пор на переднем крае AOP - статически типизированная Java

Ява обходит это за счет специально введенной разновидности кастрированных классов. Которые, однако, все-равно обладают свойством сильного связывания.

> Возможность генерации эффективного машкода.

С учетом pyrex, psyco и множества других примочек -- думаю, не так уж и нужно. В крайнем случае, есть еще C, а преждевременная оптимизация, как известно, корень всех зол... :-)

> сильная связность кода

Не понял, как это связано с наследованием vs динамический lookup.

> хрупкость базового класса.

Думал, больше никогда не услышу названия этого жупела :) жупел - он и есть жупел.

> С учетом pyrex, psyco и множества других примочек -- думаю, не так уж и нужно

Pyrex - это из другой оперы, а psyco как раз проводит анализ типов, делает type inference и генерирует специальный код, зависящий от типов аргументов.

> преждевременная оптимизация, как известно, корень всех зол... :-)

Если ее проводит программист, который тратит на это свое время... но в рассматриваемом случае этим занимается компилятор.

>Ну вообще отпадает необходимость наследования

class cat = object method say = "мяв" end;;

class dog = object method say = "гав" end;;

let talk a = a#say;;

догадаешься сам что будет в

talk new cat;; talk new dog;;

? OCaml, статика.

В чем еще отпадает необхэодимость?

>которые иначе можно отловить тщательным тестированием. Ну так это уже вроде бы обсуждалось. Еще что-то есть?

НиКто Не Будет ТестиРоВать Все. В основном потому что тесты это тоже код и при долгосрочном проекте его надо поддерживать. А если в проекте пол миллиона строк - офонареешь искать ошибки которые вылетают только на стадии исполнения.

>Например, вызов 1.__xor__(35) считается синтаксической ошибкой

>>> 1 .__xor__(35)
34
>>> (1).__xor__(35)
34
>>> 1.
1.0

Точка после числа - заставляет питона думать, что это будет float, по-этому небольшое неудобство, такое как в случае с туплом из 1 эл-та: (7,)

> Например, анонимные функции из нескольких команд не ввели (и не собираются) только из-за того, что это будет не очень изящно смотреться на фоне прочего смазливого кода.

Не все так просто. На самом деле при существующем питоновском синтаксисе  пока не получилось придумать однозначного, непротиворечивого и действительно "красивого" синтаксиса для многострочных ламбд.

>>которые иначе можно отловить тщательным тестированием. Ну так это уже вроде бы обсуждалось. Еще что-то есть?

>НиКто Не Будет ТестиРоВать Все. В основном потому что тесты это тоже код и при долгосрочном проекте его надо поддерживать. А если в проекте пол миллиона строк - офонареешь искать ошибки которые вылетают только на стадии исполнения

+inf

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

> Что раздражает в Питоне - его разработчики трясутся над удобочитаемостью как над роженицей

Неудобочитаемых языков у нас навалом, так что оставьте в покое удобочитаемый! ;)

>Что раздражает в Питоне - его разработчики трясутся над удобочитаемостью как над роженицей
Что раздражает в Питоне - то что его "фанатеги" не умеют читать сабжи тредов куда они пишут... Люди вам чё встречаться негде?

Любезный анонимус! Если базары про Питон это оффтопег, то базары про базары про Питон это метаоффтопег, то есть нечто дистанцированное от тазика ещё сильнее. Тезис "всио познаётся в сравнении" как нельзя лучше применим к ЯП (в частности, к Руби), вот вам и ответ.

to_sv75

Ты не обращай внимание из этих 3х примеров сразу видно что "r" теоретик ...

Полное вроемя если что : Time.now.to_i И я не особо помню чтобы в Ruby юзали for тама есть each для этого и пашет он побыстрее ...

Кстати а Yarv - это тот самый компилятор в байт коды ( аля Питон ) который заявлен в Ruby 2.0 ?

> НиКто Не Будет ТестиРоВать Все.

Правильно, зачем тестировать то, что не будет использоваться?

> ...в проекте пол миллиона строк...

bloatware?

Пишите кратко, и будет Вам щасте :-)

> догадаешься сам что будет в

Нет, не догадаюсь. Ибо в Ocaml не силен. Если я правильно понял, то определяется два класса, затем определяется функция, которая по данному классу извлекает метод с заданным именем. Правильно?

Вопросы:

1. Что будет, если talk скормить класс, в котором отсутствует определение метода say? Когда это отлавливается?

2. Существует ли в Ocaml возможность в уже созданный объект добавить новый метод, или переопределить, скажем, метод say по ходу программы в зависимости от внешних условий? Как в таком случае поведет себя функция talk?

2a. Есть ли в Ocaml метаклассы, позволяющие определять новые типы данных уже во время исполнения программы?

> В чем еще отпадает необхэодимость?

См. вопрос 2. Отпадает необходимость топтать "полмиллиона строк", в которых тупо описывать тонны классов, которые могут быть построены на основе десятка базовых функций по принципу Лего. Ясен пень, что в Труъ ООП для облегчения жизни используется наследование, однако это мы уже обсуждали...

Есть, правда, еще один костыль, типа автоматической кодогенерации "полмиллиона строк". Однако, если эти самые "полмиллиона строк" генерируются по шаблону, то нафига тестировать их все? Достаточно протестировать шаблон (хотя с этим и можно спорить).

>Ты не обращай внимание из этих 3х примеров сразу видно что "r" теоретик ...

О - практикующий анонимус:))

>И я не особо помню чтобы в Ruby юзали for тама есть each для этого и пашет он побыстрее ...

Ржунимагу!!!! Эта 5ть!

> Отпадает необходимость топтать "полмиллиона строк", в которых тупо описывать тонны классов, которые могут быть построены на основе десятка базовых функций по принципу Лего.

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

> Ясен пень, что в Труъ ООП для облегчения жизни используется наследование, однако это мы уже обсуждали...

Туманные наезды на ООП - это трендово, я понимаю.

>Правильно, зачем тестировать то, что не будет использоваться?

Ага. Какой длительности проект у вас был самым длинным разрешите поинтересоваться?

>Пишите кратко, и будет Вам щасте :-)

Ага пишите шура пишите. Не все вебпагами на рельсах занимаются.

>1. Что будет, если talk скормить класс, в котором отсутствует определение метода say? Когда это отлавливается?

На стадии компиляции. man type inference.Зато я знаю что будет в динамическом языке.

>2. Существует ли в Ocaml возможность в уже созданный объект добавить новый метод, или переопределить, скажем, метод say по ходу программы в зависимости от внешних условий?

Для подобных задач в статических языках используются несколько иные методы: параметризация типов, функции как first class objects и т.д. Вот там наверху ссылка на какой-то паскалеподобный Seed7, у которого типы - first class object, вот пример декларации for http://seed7.sourceforge.net/examples/for_decl.htm

>2a. Есть ли в Ocaml метаклассы, позволяющие определять новые типы данных уже во время исполнения программы?

Запускай ocaml и определяй что хочешь во время исполнения программы без всяких метаклассов.

>Отпадает необходимость топтать "полмиллиона строк", в которых тупо описывать тонны классов, которые могут быть построены на основе десятка базовых функций по принципу Лего.

Положим так никто не делает, неглупые люди не пишут 20 раз одно и тоже, они пишут DSL, генератор и т.д. Ты что думаешь что больших проектов не бывает?

>Ясен пень, что в Труъ ООП для облегчения жизни используется наследование, однако это мы уже обсуждали...

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things" (C) Guess Who. Где там про наследование?

>Есть, правда, еще один костыль, типа автоматической кодогенерации "полмиллиона строк".

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

>Достаточно протестировать шаблон (хотя с этим и можно спорить).

Достаточно.