Вышел Boo 0.9

>и что в итоге вернет min("мало",2) ?

2!

>и что в итоге вернет min("мало",2) ?

В PHP выдаст "мало", в других динамических языках может выдать ошибку периода исполнения :)

А факториал откуда?

>в других динамических языках может выдать ошибку периода исполнения :)

Питон думает, что 2 это меньше чем мало. я с ним в принципе согласен, но тут могут быть все таки мнения.

>Питон думает, что 2 это меньше чем мало

Э... И давно он научился строки с числами сравнивать? :)

Compilation error.

> Пардон, но где объекты?

Вот и объекты:
#light
open System

type test(i: int)=
let rec I = i
member x.value = match I with
1 | 2 -> 1
| I -> (new test(I-1)).value + (new test(I-2)).value
;;
Printf.printf "Fibonacci on F# and Mono!\n"
printfn "%a" output_any (DateTime.Now)
let v = test(40)
printfn "%i" (v.value)
printfn "%a" output_any (DateTime.Now)

Mono Linux
01/28/2009 17:49:32
102334155
01/28/2009 17:49:43

.Net
01/28/2009 17:57:32
102334155
01/28/2009 17:57:37

Runtime error.

Для питона - да. Но я в посте имел ввиду аналог со стат. типизацией.

вы оба неправы:

Python 2.5.1 (r251:54863, Dec 1 2008, 17:47:46)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def min(x, y) : return x if x < y else y
...
>>> min("мало",2)
2
>>>

> Mono : 11sec, .Net 5 sec

Да, аллокатор на .НЕТ работает в два раза быстре обезьяньего =/

Нда, любая строка больше любого числа. Интуитивненько =/

Иди сходи на ltu и спроси что они понимают под type system. А потом вякай.

А вот результат для Boo:
01/28/2009 18:10:18
102334155
01/28/2009 18:10:29

для линуха

>>Динамические языки это по сути отсутствие _системы_ типов.

>анонимус, это диагноз.

Зачем к нему придиратся? Вона он 800 PDF хранит на память о заброшенном компиляторе, и на слова "динамическая типизация" нервно реагирует, при этом авторитетно заявляя что времени объяснять свои слова у него нету - т.к. никто его не поймет.

Интересный типаж. Что он ещё тут поведать сможет...

>Нда, любая строка больше любого числа. Интуитивненько =/

Там еще более интересно:

Python 2.5.1 (r251:54863, Dec 1 2008, 17:47:46)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def min(x, y) : return x if x < y else y
...
>>> class F: pass
...
>>> min(F(),3)
<__main__.F instance at 0xb7c5fbcc>
>>>

# let min x y = if (x > y) then x else y;; val min : 'a -> 'a -> 'a = <fun>

BTW, для ликбеза - что будет, если вызвать с объектом типа для которого не определен метод (>) ? В интерпретаторе ясно - ошибку выдаст, а в скомпилированной проге ?

не скомпилируется.

KRoN73
> Ещё важная особенность - нативная для .Net скорость исполнения. Под mono/Linux, на объектах, Boo быстрее Питона в 32 раза и быстрее Python+Psyco в 4 раза

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


нет слоф

> и что в итоге вернет min("мало",2) ?

>>> min("мало",2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < str()

Выполнено на старом Python 3.1a0 (py3k:67586, Dec 5 2008, 19:39:50)

Вставлю свои пять копеек в защиту питона. Главные его преимущества для меня: простота и красота синтаксиса, простой ООП, относительно читабельные внутренности, более-менее нормальныя документация(не так как у руби с рельсами), достаточно красивый C api, большая стандартная библиотека модулей, большая скорость разработки, большое комьюнити, большая распространнённость(в том числе среди крупных компаний типа гугла), активное развитие языка.

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

> BTW, для ликбеза - что будет, если вызвать с объектом типа для которого не определен метод (>) ? В интерпретаторе ясно - ошибку выдаст, а в скомпилированной проге ?

а она не скомпилируется :)

Ну хоть в тройке починили... А так - +1, именно это в нём и нравиться.

по ссылке [почти] не ходил .. и даже настолько обнаглел что не читал все комменты, ...

... но так как тут собралось [наверно] куча .NET специалистов , то можно спросить?:

там (в .NET или MONO) НЕЗАВИСИМО от архитектуры выполнения и от параметров компеляции -- СЁРАВНО ВСЕГДА 32-разрядная (а не 64 ....или 16 :-)) целочисленная арифметика?

std::cout << "я лох: " << ((sizeof(int) == 4)?"ДА":"НЕТ") << std::endl;

и поэтому НЕЛЬЗЯ положить в массив (так как он индексируется int'ом) больше 4 милиардов элементов (даже если они однобайтны, или однобитны) -- независимо от крутизны архитектуры компа???

????????

>Да, не самый быстрый ЯП в силу своей интерпретируемой природы

Ну мало осталось сегодня интерпретируемых реализаций ЯП :)

Даже PHP компилируется в байткод перед исполнением.

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

>и поэтому НЕЛЬЗЯ положить в массив (так как он индексируется int'ом) больше 4 милиардов элементов

А что, индекс long'ом быть не может? :)

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

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

>>> def min (x,y): return x if x < y else y

>> print (min ("много","немного"))

много

>>> print (min ("мало","совсем мало"))

мало

Зашибись...

> Ну мало осталось сегодня интерпретируемых реализаций ЯП :)

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

Надеюсь, мы под интерпретируемостью одно и то же подразумеваем? Я имею в виду то что питон(C/Python-реализация) не генерит нативный для процессора код. Вместо этого он его запускает в, как это сейчас модно говорить, виртуальной машине (виртуальном "процессоре" со своей системой комманд).

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

? Всё правильно.

>Если в нём нет указателей, то почему?

Потому что как раз для указателей разрядность важна :D А вот для обычных типов - нет.

>максимальным значением инта почти не пользуются

Кто не пользуется, а кто и пользуется.

Напишет кто-то целочисленное вычисление расстояний по sqrt(dx²+dy²) и потом будет удивляться, что у него расстояния больше 65536 не считаются :)

Я уже не говорю про то, что программа, написанная под int64 потом на int32 легко не заработает. Или заработает, но откажет в самый неподходящий момент...

> Зашибись...

В питоне сравнение строк выполняется схожим с strcmp образом. man strcmp

>имею в виду то что питон(C/Python-реализация) не генерит нативный для процессора код.

О, боже... :)

> Почему нельзя говорить об интерпретируемости реализации языка я не понял.

У Крона пунктик на эту тему %)

Кстати, KRoN73, я вот такой код запустил и он у меня всё мгновенно считает(а нерекурсивный вариант ещё быстрее).
Или я чего-то не понял в тестах на числа фибоначи?


def fib(num):
    if num < 2:
        return 1
    n = fib(num-1) + (fib(num-2))
    print (n)
    return n

> О, боже... :)

> У Крона пунктик на эту тему %)

Я чего-то не понимаю и щас на весь рунет опозорился? :). Вы мне лучше щас расскажите, а то вдруг кому-нить ещё такое ляпну...

/me забалтался .. удалил коммент

>У Крона пунктик на эту тему %)

Да нет, ломает по 10-му разу читать лекции по длинным цепочкам сегодняшнего исполнения ЯВУ-шных программ :)

> Я чего-то не понимаю и щас на весь рунет опозорился? :)

Нет, но Крон любит разобрать "правильные" определения компилятора и интерпретатора ;)

>Или я чего-то не понял в тестах на числа фибоначи?

По ссылке сходи, описания почитай, сорцы посмотри :)

...

Речь не о вычислении Фибоначчи как самоцели (тогда это лучше сделать итеративно), а о тестировании производительности объектной подсистемы.

Не объектной системы, а скорости аллокирования. А "производительность объектной системы" - это насколько дорого вызываются вирт. функции и не инлайнятся ли они.

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

а иначе -- будет плохо с абстрактностью ...

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

а иначе тогда этот язык (со своими типами) -- обрекает себя на ВРЕМЕННОЕ существование .. сейчас 4 милиарда кажется нормальным (точнеее не сейчас на года 3 назад) . а давно давно реньше казалось что 65 тысяч (2^16) это норимально ....

когда повсеместно (и у меня дома, тоже :-) ) будут полноценные 64-разрядные компы .. для которых 4 милиарда элементов массивов это совсем пустяг . то как быть? выкидывать на свалку стырые языки а программы сделанные на них -- переписывать на НОВЫЕ языки (в которых int побольше) ?

(ну для тех кто хочет ИМЕННО 32 и 64 бита -- есть же разные int32_t, int64_t . вот она и проблемма с переносимостью :-) :-))

> А что, индекс long'ом быть не может? :)

ну тогда уж придётся Поиск/Заменой искать ВСЕ int и ЗАМЕНЯТЬ на long... так как с индэксом производятся тоже-и-разные арифметические операции , а значит всё (ну или просто -- многое) -- взаимосвязанно и савакупно.

и тогда встаёт вопрос -- а нафиг вооще int тогда?

вот только это может и не по требуется для 32-хразрядной архитектуры ...(неужеле писать ДВЕ разных программы -- в одной использовать только int и говорить что это версия-проги для 32-разрадной машины . во второй АВТОЗАМЕНОЙ менять int на long и говорить что она для 64-рахрядной архитектуры ???????)

(а может и ТРИ версии .. если вдруг ещё какая архитектура стане доступной O___ooo)

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

А как тебе "БУ-шные программисты"?! :)

Бубунтоводам, наверное :)

Есть отличный яз, Немерле, трижды превосходящий эти Бу0, Шарп5 и жабу7

>Не объектной системы, а скорости аллокирования.

Не только. Один цикл - два аллокирования, два вызова методов, три арифметических действия.

Вполне адекватный бенч для оценки объектной системы :)

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

...

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

Python 2.6 (r26:66714, Dec 3 2008, 10:55:18)
[GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def min1(x, y) : return x if x < y else y
...
>>> min1("мало",2)
2
>>> class F: pass
...
>>> min1(F(),3)
<__main__.F instance at 0x7f35db85fa70>
>>> min(F(),3)
<__main__.F instance at 0x7f35db85fab8>
>>> class F1(object):pass
...
>>> min(F1(),3)
3
>>> min1(F1(),3)
3
>>>

новые классы значительно меньше трёх :D

>если программист думает про Int , то он должен щитать что это некое целочисленное число нормального (с точки зрения выполняемой среды) размера .

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

Так что в высокоуровневых языках типы должны быть независимы от платформы. В низкоуровневых - могут быть зависимы.

>а иначе тогда этот язык (со своими типами) -- обрекает себя на ВРЕМЕННОЕ существование .. сейчас 4 милиарда кажется нормальным

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

А то, вот, использует он char для того, чтобы символы записывать, а назавтра char будет не 4 байта, как он полагал, думая, что этого хватит, а один символ начнут описывать несколькими char'ами :)

>и тогда встаёт вопрос -- а нафиг вооще int тогда?

int - это сокращение от integer. Целое число. Естественное математическое понятие.

>неужеле писать ДВЕ разных программы -- в одной использовать только int и говорить что это версия-проги для 32-разрадной машины . во второй АВТОЗАМЕНОЙ менять int на long и говорить что она для 64-рахрядной архитектуры ???????

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

>Есть отличный яз, Немерле, трижды превосходящий эти Бу0, Шарп5 и жабу7

По какому критерию? :)

> ну тогда уж придётся Поиск/Заменой искать ВСЕ int и ЗАМЕНЯТЬ на long... так как с индэксом производятся тоже-и-разные арифметические операции , а значит всё (ну или просто -- многое) -- взаимосвязанно и савакупно.

ты наркоман чтоле ?

Если ты сам привязался к особенностям архитектуры - ССЗБ, вдобавок management модель выполнения кода сводит к минимуму необходимость гуляния по каким-то там индексам в массивах памяти.

К примеру пишется foreach (var e in arr) { bla bla } и плевать сколько там миллиардов элементов в массиве arr.

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

> По какому критерию? :)

дык цэж фанатики :) а вообще немерле бы устаканить апи компилера и причесать макросы - было бы совсем неплохо, а то сейчас там несколько мутновато всё сделано.

> Есть отличный яз, Немерле

Это на него забили его создатели?