Mono 1.9 Released

> А не кажется ли Вам, что Вы пишите бред?

У перла есть свои сильные стороны -- в основном интеграция в язык регулярных выражений (о чем собственно и ларри где-то говорил). Я еще отмечу местами чисто синтаксически приятные конструкции, типа неявного $_ и вариации на тему break if $x<0;

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

>> Платформа nono должна обладать какими-то выдающимися преимуществами перед Java

> То что она многоязычная, в отличие от Java, уже достаточно.

Не показатель.

На JavaVM может работать порядка 200 языков:
http://www.robert-tolksdorf.de/vmlanguages.html
(это гораздо больше, чем поддерживают .NET и Mono)

В NetBeans есть стандартные плагины для поддержки разработки на языках Ruby, JRuby, Groovy, JavaFX и др.

>>> Платформа nono должна обладать какими-то выдающимися преимуществами перед Java

>> То что она многоязычная, в отличие от Java, уже достаточно.

> Не показатель. На JavaVM может работать порядка 200 языков: http://www.robert-tolksdorf.de/vmlanguages.html (это гораздо больше, чем поддерживают .NET и Mono)

1. Хорошая ссылка (спасибо)

2. Выдающиеся премущества щас невозожно придумать, достаточно придумать некоторые преимущества.

3. Языками этот сбро^W набор можно достаточно условно назвать, всякие там реализации языка Logo (аж 6 штук) не стоят и одной десятой от Cobra. И разные недоскриптовые языки с семантикой явы и темными местами...

Но правда есть много интересного, о чем я не знал.

4. Сравнивать надо не языки, а VM.

Вот что есть в моно, чего нет в JVM: структуры и делегаты.

Читайте в википедии насчет делегатов, там есть пара интересных ссылок, где сан обсирает делегаты, а МС их защищает. Прочитав обе статьи, я стал на сторону МС -- делегаты это хорошо.

Хорошо знакомится с обоими точками зрения:

Sun's critic of Delegates: http://java.sun.com/docs/white/delegates.html

Microsoft answer to Sun: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvj/html/...

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

> Насчет питона -- вы только думаете. Мигель рассматривает просьбы о введении статической проверки типов

Порвало на части олололо

> Порвало на части олололо

На вот статью Adding Optional Static Typing to Python -- Part II by Guido van Rossum:

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

Да, тут еще разные знатоки динамических языков мне кричали что шаблоны им не нужны... а Гвидо, дурачок, их не спрашивает, и обдумывает параметризованные типы... http://www.artima.com/weblogs/viewpost.jsp?thread=86641

Я вот пример приведу... было время когда на palm был экранчик только 160х160, а на winCE уже 240х320. Так вот сколько было криков от пальмофилов, что вредно для глаз такой мелкий пиксель... Потом пальма разродилась чем-то с разрешением 320х480. Вот тут уже пальмофилы подняли крик что на винЦЕ нет таких суперэкранов... Так же наверно будет, когда в питоне появятся наконец статическая проверка и шабло^Wпараметризованные типы.

> Так же наверно будет, когда в питоне появятся наконец статическая проверка и шабло^Wпараметризованные типы.

Не появятся :( Материалы, ссылки на которые ты давал - 3-летней давности, а воз и ныне там. Не хотят питонисты статической типизации :/

>Так вот сколько было криков от пальмофилов, что вредно для глаз такой мелкий пиксель...

Не... Ты чего-то путаешь :) Наоборот от винцешников наезды были на пальмоводов, что у тех всё квадратиками и глазу такой кубизм вреден. Хорошо помню, ибо сам был обладателем 160x160 девайса (Casio PV-S450) и постоянно на форумах приходилось писать, что нихрена, глаза у меня не устают, зато 160 часов непрерывной работы от двух AAA-батареек рулят :D

это такой тонкий троллинг или ты действительно не читаешь те документы, ссылки на которые даёшь?

>Python's parameterized types will be primarily a run-time construct; they won't be anything like C++ templates

в с++ шаблоны используются для создания (в том числе) типов, в доке по ссылке параметризированные типы используются для контроля типов.

да, и ещё одна плохая новость. в питоне нет компилятора, поэтому проверять типы надо будет всё-равно в рантайме.

> и ещё одна плохая новость. в питоне нет компилятора

у Питона есть компилятор

> поэтому проверять типы надо будет всё-равно в рантайме.

...но вот заставить этот компилятор проверять типы - довольно сложно. Если вообще возможно без наложения ограничения на язык.

>у Питона есть компилятор

в байт-код? я всегда думал, что он просто текст транслирует в питоновские инструкции.

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

что в прочем, тоже не плохо.

>> у Питона есть компилятор

> в байт-код?

Яволь.

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

Можно делать type inference... другое дело, что для того, чтобы делать это эффективно, придется ограничить язык, наверное.

>> Так же наверно будет, когда в питоне появятся наконец статическая проверка и шабло^Wпараметризованные типы.

>Не появятся :( Материалы, ссылки на которые ты давал - 3-летней давности, а воз и ныне там. Не хотят питонисты статической типизации :/

Я подозреваю, что даже если Гвидо им сделает статическую проверку и параметризованные типы, лемминги его распнут за то, что он их свободу ограничивает :-[

> Можно делать type inference... другое дело, что для того, чтобы делать это эффективно, придется ограничить язык, наверное.

Может и придется... но это только на пользу будет. type inference хорошая вещь.

>Хорошо знакомится с обоими точками зрения:

>Sun's critic of Delegates: http://java.sun.com/docs/white/delegates.html

Чего-то они умалчивают что каждый Inner Class это на самом деле обычный класс с особыми scope rules. А на каждый класс jvm хранит 3K метаинформации. Давайте сравним 32 байта на указатель на метод класса (из-за множественного наследования интерфейсов) + 4 байта на указатель на ипстанс класса против 3k метаиформации + 4 байта на указатель на ипстанс класса. Ну удивительно почему swing такой неторопливый. Да, я согласен, sun обещает внутренние классы оптимизировать. Но до сих пор чего-то они этого не сделали.

> Давайте сравним 32 байта на указатель на метод класса (из-за множественного наследования интерфейсов) + 4 байта на указатель на ипстанс класса против 3k метаиформации + 4 байта на указатель на ипстанс класса.

Это и сказала микрософт в ответ сану. Правда цифр насчет 3к она не приводила... я честно говоря поражен сановской расточительностью.

А ты не ошибаешься? У меня анонимные .class занимают от 497 байт.

>> Давайте сравним 32 байта на указатель на метод класса (из-за множественного наследования интерфейсов) + 4 байта на указатель на ипстанс класса против 3k метаиформации + 4 байта на указатель на ипстанс класса.

>Это и сказала микрософт в ответ сану. Правда цифр насчет 3к она не приводила... я честно говоря поражен сановской расточительностью.

Для лабания ejb на спринге и гибернейте делегаты не нужны -> Походу Сану свинг не нужен. Ынтерпрайз =).

>А ты не ошибаешься? У меня анонимные .class занимают от 497 байт.

В памяти в загруженном виде или на диске?

> На вот статью Adding Optional Static Typing to Python -- Part II by _Guido van Rossum_:

> _Мигель_ рассматривает

Дошло?

>>А ты не ошибаешься? У меня анонимные .class занимают от 497 байт.

>В памяти в загруженном виде или на диске?

На диске. Но сомнение закрадывается -- неужели 3к в памяти, если 0.5к на диске?

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

a = int()

b = str()

c = list()

d = float()

и не парить людям мозги, ибо a = c не вызовет никакой ошибки даже в рантайме. А если сильно боитесь за свой склероз, юзайте паскаль.

>> На вот статью Adding Optional Static Typing to Python -- Part II by _Guido van Rossum_:

>> _Мигель_ рассматривает

>Дошло?

Дошло. Я Гвидо имел в виду. Мигель это в моно, и статическая проверка типов там есть с самого начала, надеюсь все об этом знают.

> Дошло. Я Гвидо имел в виду. Мигель это в моно

А теперь представь, как меня передёрнуло, когда я подумал о Мигеле в качестве разработчика питона :)

> Товарищам, которые прутся от статической типизации

Я вообще не понимаю какого некоторые наезжают на динамическую типизацию. я участвовал в довольно не маленьком проекте на питоне (команда из 45 человек в разных странах) и проблем с типами не было никогда. Просто есть стандарт, который каждый участник прочитал и следует ему (например документирование функций). За 3 года не было ни одной проблемы из-за типов данных.

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

только ерунда какая-то получается со всей этой статической типизацией. зачем нужна вторая джава/с++ с синтаксическим сахаром?

> проблем с типами не было никогда. Просто есть стандарт, который каждый участник прочитал и следует ему (например документирование функций)

Вопрос:

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

>>>А ты не ошибаешься? У меня анонимные .class занимают от 497 байт.

>>В памяти в загруженном виде или на диске?

>На диске. Но сомнение закрадывается -- неужели 3к в памяти, если 0.5к на диске?

В инете можно найти sizeof() для Java который рекурсивно раскручивает все дерево объектов через reflection api. Можно натравить его на java.lang.Class. Я думаю, вполне реально ему раздуться в 6 раз учитывая отсутствие структур (+ 4 байта указателя на каждый вложенний объект) и выравнивание byte и short по границе в 32 бита.

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

Да. Только так. Иначе могут быть накладки. То что эти два класса предоставляют интерфейc I -- это НЕДОКУМЕНТИРОВАННАЯ ОСОБЕННОСТЬ.

Приведу пример php. Там функция count("abc") дает 1 (или 0, не помню), а count(array(1,2,3)) дает 3. Вроде общий интерфейс, да? А логика очень разная.

Если отвлечься от php, то в твоем случае автор класса В может его подредактировать, и даже при сохранении названия методов логика развалится. Автор В не связан ничем -- он ведь не написал implements I.

>> и ещё одна плохая новость. в питоне нет компилятора

>у Питона есть компилятор

А в Parrot компиляция работает? Насколько я понял из документации к parrot он возник в качестве эксперимента по приведению Перла и Питона к общему знаменателю

> выведение типов - интересная штука. только я слабо представляю как это сделать не убив утиную типизацию.

Я лично "утиную типизацию" считаю гениальным пропагандистcким ходом в духе "я всегда был <...> и стеснялся этого, но теперь я посещаю психоаналитика, и горжусь тем, что я <...>"

> если у меня есть классы А и Б, которые не имеют между собой ничего общего кроме object, но предоставляющие правильный интерфейс, то мне надо этот интерфейс явно выделять?

AFAIK, нет.

> только ерунда какая-то получается со всей этой статической типизацией. зачем нужна вторая джава/с++ с синтаксическим сахаром?

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

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

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

> Каким образом ты определяешь, это проблема с типами или какая-то иная проблема?

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

>>у Питона есть компилятор

> А в Parrot компиляция работает?

Стандартный? С чего бы? 8) А так - какое-то подмножество Питона компилируется для Паррота каким-то левым компилятором, но им никто не пользуется :)

>> если у меня есть классы А и Б, которые не имеют между собой ничего общего кроме object, но предоставляющие правильный интерфейс, то мне надо этот интерфейс явно выделять?

>AFAIK, нет.

На самом деле бывают *очень редко* случаи, когда нужно что-то типа union.

>> только ерунда какая-то получается со всей этой статической типизацией. зачем нужна вторая джава/с++ с синтаксическим сахаром?

>Потому что Си++ переусложнен до крайности, небезопасен и не имеет многих удобных вещей, а Ява - весьма средненький язычок, который тащит за собой жирную претенциозную VM и плохо интегрируется с Си.

Полностью согласен.

> Из-за типов данных нестыковок не было ни разу (по крайней мере я вообще не сталкивался с таким

А тебе приходилось _переделывать_ чужие большие куски?

> Я лично "утиную типизацию" считаю гениальным пропагандистcким ходом в духе "я всегда был <...> и стеснялся этого, но теперь я посещаю психоаналитика, и горжусь тем, что я <...>"

не буду спорить. мне нравится писать не академически правильно, а так, как я считаю нужным и я рад, что есть такой язык, который мне это позволяет. интерфейсы самодельные я тоже иногда делаю в виде raise Exception('not implemented'). но то такое..

на питоне можно просто писать, не задумываясь о типах, интерфейсах, и прочей ерунде. можно исправить когда сломается. programming is fun again. http://xkcd.com/353/

> Потому что Си++ переусложнен до крайности, небезопасен и не имеет многих удобных вещей, а Ява - весьма средненький язычок, который тащит за собой жирную претенциозную VM и плохо интегрируется с Си.

в следующем году, вроде бы, будет следующая редакция стандарта с++. в котором будет тип auto, который, если я не путаю, реализует выведение типов :) ещё есть D, и наверняка ещё что-то. незачем питон портить. вон есть джава, которой тоже не нравилось, что с++ небезопасен.

> А тебе приходилось _переделывать_ чужие большие куски?

на сколько большие? ошибки, да, исправлял. да и пришел в команду, когда проект уже достаточно вырос и начинал работать уже над чужим куском, а не над своим "с нуля".

>> Каким образом ты определяешь, это проблема с типами или какая-то иная проблема?

>не понял вопроса.

Ты пишешь "Из-за типов данных нестыковок не было ни разу" -- так ЗНАЧИТ ТЫ КАК-ТО ОПРЕДЕЛЯЕШЬ ЧТО ОНИ БЫЛИ ИЗ-ЗА ИЛИ НЕ ИЗ-ЗА ТИПОВ ДАННЫХ? КАК???

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

А если она не будет кортежом 1 раз в 100 запусков программы? А в остальные 99 будет кортежом? Питон такое позволяет, а языки со статической типизацией -- нет.

> Каждая функция и каждый класс документировались в момент написания и что функция принимает в качесвте параметра так же в документации. С этим было все строго. Именно это позволяло быстро разобраться с проектом, а не носиться с вопросами, а что вот это делает, а почему это тут падает и что за класс тут передается.

Статическая типизация -- это именно такая документация, причем ее соблюдение проверяется компилятором.

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

>> А тебе приходилось _переделывать_ чужие большие куски?

> на сколько большие?

2к строк и выше

> ошибки, да, исправлял

Это не то.

> да и пришел в команду, когда проект уже достаточно вырос и начинал работать уже над чужим куском

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

> Exception('not implemented')

pydoc NotImplementedError

>NotImplementedError

а смысл? правильно поймать и обработать?

>в следующем году, вроде бы, будет следующая редакция стандарта с++. в котором будет тип auto, который, если я не путаю, реализует выведение типов :)

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

> на сколько большие? ошибки, да, исправлял. да и пришел в команду, когда проект уже достаточно вырос и начинал работать уже над чужим куском, а не над своим "с нуля".

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

> Ты пишешь "Из-за типов данных нестыковок не было ни разу" -- так ЗНАЧИТ ТЫ КАК-ТО ОПРЕДЕЛЯЕШЬ ЧТО ОНИ БЫЛИ ИЗ-ЗА ИЛИ НЕ ИЗ-ЗА ТИПОВ ДАННЫХ? КАК???

У меня есть переменная a = A()

я вызываю метод a.afunc1()

что будет есть я вызову a.func1(), если a не будет экземпляром A?

> А если она не будет кортежом 1 раз в 100 запусков программы?

с какого вдруг перепугу? если функцию вызывали всегда с кортежем, то почему 1 раз из 100 она вызовется не с кортежем?

>>в следующем году, вроде бы, будет следующая редакция стандарта с++. в котором будет тип auto, который, если я не путаю, реализует выведение типов :)

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

Это ты зря. Даже гнутый компилятор уже не знаю сколько лет поддерживает typeof, и вообще у них там куча полезных расширений С была, которые позволяли делать многое из того, для чего был сделан С++.

> тип auto, который, если я не путаю, реализует выведение типов

Это детский сад, а не выведение типов. Когда я смогу объявить функцию типа auto f(auto x, auto y), тогда поговорим, а пока даже не смешно.

> смысл? правильно поймать и обработать?

А зачем, к примеру, принято здороваться правой рукой, а не левой? Правила хорошего тона.