Вышел Boo 0.9

>в отличие от Python имеет следующие особенности

Ещё важная особенность - нативная для .Net скорость исполнения. Под mono/Linux, на объектах, Boo быстрее Питона в 32 раза и быстрее Python+Psyco в 4 раза: http://balancer.ru/tech/forum/2008/08/t63003--Proizvoditel~nost~-yazykov.Ob~e...

Интересно померять скорость, когда Воо работает в режиме опциональной динамической типизации (Duck Typing)

Как оно в нём используется? А то я по Boo ни booм-booм :)

static1 as int //type is fixed to be an integer
dynamic1 as duck //can be anything

> А то я по Boo ни booм-booм :)

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

> http://balancer.ru/tech/forum/2008/08/t63003--Proizvoditel~nost~-yazykov.Ob~e.. .

Неплохо бы сделать тест для f# - его предок, Ocaml, был очень быстр.

Ок, сегодня ночью попробую протестировать.

Правда, F# - если он будет по Убунтой. Я на убунтовой машинке тесты гонял и если я разберусь, как в нём с объёктами работать :)

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

Так, пощупал boo.

Система с тех пор пару раз обновлялась и не в пользу boo :)

Сейчас стоят Boo Compiler version 0.8.1.2865 (CLR v2.0.50727.42) с mono 1.9.1

Время теста со статической типизацией увеличилось с 9,8 сек. до 12,1.

Утиная типизация работает много тормознее - 145 секунд.

В два с лишним раза быстрее чистого Питона, и в три с лишним раза медленнее, чем python+psyco.

Какое значение для чисел фибоначи вы ставили?

40-е. По ссылке на тест описано :)

Правда, у меня Убунта на этом ноуте не обновлялась 20 дней. И примерно столько же в гибернации провалялась. Обновлюсь/перезагружусь - проверю ещё. Вдруг что-то изменится :)

ну что за бред... в питоне тоже строгая (strict) типизация, только dynamic, а не static, может это имелось в виду? а глобально - не нужен. допиливайте лучше F# и Nemerle.

ааа, типа динамика по требованию... что-то мне это напоминает, а именно закосы под virtual в с++ (смысл другой, но идеология такая же...)

Дни моно на ЛОРе?

ЗЫ. Жду новость про MonoDevelop 2.0

Статическая типизация в питоне? Какой ужас. Может сначала стоило почитать Гвидо? Он же не просто так сделал питон с динамической типизацией.

Да и скорость статической типизации гораздо выше в любом случае, так что сравнивать это Бу с питоном нет смысла.

> Статическая типизация в питоне? Какой ужас.

Слишком хорошо, чтобы быть правдой.

> Может сначала стоило почитать Гвидо?

Он был не против, но ниасилили.

> Слишком хорошо, чтобы быть правдой.

Может для тебя такой изврат и является чем-то хорошим, всё может быть.

> Он был не против, но ниасилили.

Да, Гвидо недоучка и школьник. Куда там ему.

> ну что за бред... в питоне тоже строгая (strict) типизация, только dynamic, а не static, может это имелось в виду?

Да. Очепятался.

> а глобально - не нужен. допиливайте лучше F# и Nemerle.

Особенно с такой документацией, да. А так - почему не нужен?

> Может для тебя такой изврат и является чем-то хорошим, всё может быть.

"Giving people dynamic languages doesn't mean they write dynamic programs" (c)

> Да, Гвидо недоучка и школьник.

Тебе виднее.

Типичный демагог. Что-то ляпнул якобы в тему, отмазался заезженными цитатами и репликами - и весьма доволен собой. А по сути то явно не читал ничего из того, что Гвидо выкладывал в сеть по теме питона. Даже блог его новый не смотрел, я так думаю. Да фиг с ним с Гвидо. Ты даже не понимаешь, что реализовать динамическую типизацию ГОРАЗДО сложнее, чем статическую. Но свои пять копеек вставил, молодец.

> Даже блог его новый не смотрел, я так думаю.

Телепай лучше.

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

Я читал его планы насчет опциональной статической типизации для Py3k, но ее не сделали.

> Ты даже не понимаешь, что реализовать динамическую типизацию ГОРАЗДО сложнее, чем статическую

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

> я не собираюсь спорить об этом.

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

> Ты даже не понимаешь, что реализовать динамическую типизацию ГОРАЗДО сложнее, чем статическую.

да, и хаскель - это самый просто язык, типизация же статическая:)

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

Бред о сравнительной сложности реализации динамической и статической типизации начал нести ты. Я всего лишь сказал, что статическая типизация в Питоне была бы полезна.

> и, подозреваю, не знаешь вообще.

Какие подозрительные телепаты пошли.

Я поддерживаю tailgunner'а. Статическая типизация сильно увеличивает читабельность кода, позволяет исправить большинство ошибок еще на фазе компиляции, ну и работает быстрее. Динамическая типизация подходит разве что для маленьких скриптиков, ну или опционально для парочки переменных.

>динамическую типизацию ГОРАЗДО сложнее, чем статическую

Динамическая типизация - это от бессилия. Не можете сделать нормальную статическую типизацию - ну так не надо этим гордиться. Пример хорошей стат. типизации нету. Хоть чуть-чуть смотрящая в сторону правильной - в XSD (XML Scheme Definition).

З.Ы. Да, я знаю, что XML не язык программирования.

> Статическая типизация сильно увеличивает читабельность кода

Сравни читабельность С/С++ с питоновским кодом. Ни разу она сама по себе не увеличивает читабельность.

> позволяет исправить большинство ошибок еще на фазе компиляции

Да, в этом её плюс.

> ну и работает быстрее

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

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

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

Minsc will lead with blade and boot! Boo will take care of the details.

"программист на БУ" - звучит :)

>Ни разу она сама по себе не увеличивает читабельность.

Сама по себе нет. Но добавляет ясности, особенно когда код видешь впервые.

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

Ну и посмотри на них. Тот же gajim. В 90% случаев хватило бы type inference, а в остальных - уж лучше явно сказать что ты хочешь, чем "ну ты так сделай, я сам проконтролирую что всё будет правильно".

зачем плодить ненужное недоезыки, есть же JavaScript для .NET, Nemerle, сокро F# будет

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

насчёт "допилить немерле" - а чем таким немерле лучше?

> Сама по себе нет. Но добавляет ясности, особенно когда код видешь впервые.

На уровне холловорлда может и добавляет. Если говорить о серьёзных проектах, то там ясность вносит строгая документация на каждый файл, функцию, класс, иногда и переменную. И тут статическая типизация никак не помогает улучшить читаемость кода. Особенно это видно в С++.

> Ну и посмотри на них. Тот же gajim

У нас наверное разное понимание словосочетания "большой проект"...

это как же звучать то будет БУсник, БУсист

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

Вам уже сказали, что телепат из Вас никудышный. Зачем опять позоритесь?

>Сравни читабельность С/С++ с питоновским кодом

Не надо сравнивать шило с мылом. Сравнивай Питон с высокоуровневыми статическими языками.

А вот результат f# на винде+моно. Я не знаток Ocaml или F#, потому не пинайте.

open System;;

let rec fib i = // рекурсивная функция от одного аргумента
match i with // которая смотрит на что похож этот аргумент
| 1 | 2 -> 1 // если он 1 или 2, то возвращаем 1
| i -> fib(i-1) + fib(i-2);; // если он похож только на себя - то рекурсивно вызываем эту же функцию

// смотрим, что у нас получилось
printfn "%a" output_any (DateTime.Now);;
printfn "%i" (fib 40);;
printfn "%a" output_any (DateTime.Now);;

Mono и нативный .Net считают за 1 секунду.

28.01.2009 14:23:31
102334155
28.01.2009 14:23:32

>строгая документация на каждый файл

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

>У нас наверное разное понимание словосочетания "большой проект"...

Ну давайте поговорим о больших. Django?

Не, это не интересно. Лучше возьмы чтонить с debian-shootout, Это будет хоть немного показательно.

> Вам уже сказали, что телепат из Вас никудышный. Зачем опять позоритесь?

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

> Не надо сравнивать шило с мылом. Сравнивай Питон с высокоуровневыми статическими языками.

С++ - язык высокого уровня, это в любой книжке написано. У тебя явный пробел в образовании. Хотя я не настаиваю, можно взять ту же жабу - ничего кардинально в читаемости кода не изменится. Везде нужно документировать.

Mono/Boo/.NET/Java, а также всё на них основанное - говно. Python - это хорошо.

> можно взять ту же жабу

Жаба устарела еще при создании. Возьми что-нибудь с type-inference - *ML, например.

> Дадада, программисты очень любят писать документации, по этому всегда все методы хорошо документированы, и документаци конечноже up-to-date, ведь всякий уважающий себя программист сначала пишет документаци, потом код. И всё равно, функции в питоне часто жду конкретный класс или его наследник, и в доку так и написано - ждём строку, число, или ещё что. Когда это на уровне языка, это удобнее.

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

> Ну давайте поговорим о больших. Django?

А что о них говорить? Они все вполне успешные.

>Когда пишешь на питоне, в голове сидят не типы, а алгоритмы. Все эти мелочи вторичны и уделять им нужно как можно меньше времени, и наоборот - проектирование должно быть продумано до мелочей. Динамическая типизация способствует такому подходу.

Куча красивых слов. Вы про type inference в боле менее приличных языках слышали? Вот на хаскеле недавно писал - типы специализировал в паре хитрых слуачаев. и всё.

>А вот результат f# на винде+моно.

Пардон, но где объекты? :) Тест по ссылке измеряет именно генерацию объектов и скорость доступа к методам. Числодробильные тесты я раньше тоже делал, но они мало интересны, так как нужны только под очень узкий класс задач :)

> А что о них говорить? Они все вполне успешные.

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

>Лучше возьмы чтонить с debian-shootout, Это будет хоть немного показательно.

Там все тесты сугубо числодробильные. К реальной жизни малоприменимы :)

>Хотя может быть ты их и увидел, но зачем-то умолчал

Я работал с Common Lisp и Perl. Преимущества конечно были, но они несущественны. Например, во многих ООП языках можно объявить переменную с типом Object, и вот тебе почти динамическая типизация - практически любой тип туда суй. Но на практике такое редко требуется. Обычно тип переменной заведомо известен или же он наследуется от какого-то абстрактного класса. Если же у тебя контейнер содержит кучу разнотипного хлама, включая функции, объекты, классы, числа, и т.п. - то это неправильная архитектура проекта.

Я задолбался отлавливать в рантайме ошибки вида "данный объект не поддерживает этот метод". Задолбался писать кучи уродливых деклараций для опциональной почтистатической типизации (которая статической от этого не становится).

>Хотя я не настаиваю, можно взять ту же жабу

А ты сравни Питон с Boo ;)

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

> А я не не оспариваю. Но это пример, где нужна не динамичность, а хорошая декларативная модель.

Если ты упомянул Django, то там как раз на динамичности языка всё и закручено. Я не представляю джангу на Java в том виде, в котором она сейчас существует.

Хорошо. Давай чуть более популярный Scala. AFAIK используется в яндексе, например. неплохая система type inference. Но к сожалению, всё таки я не могу написать как в хаскеле - min(x, y) = x < y ? x : y, надо указывать типы. Но дело то не в этом. Я привёл пример где система типов почти не мешает (у хасклея заскок с Integer != Int). Но это решаемые проблемы. Это не проблемы статической типизации как подхода.