Oracle подал в суд на Google за использование Java на Android

>> Надо прикрутить hibernation к Python

А зачем? ORM на питоне есть, да и не один. И еще вопрос у кого лучше: у жабы или питона. К примеру, чем Storm ORM не вариант?

и Beans-ы сделать :)

Ни к чему. :-) С точки питона сие - костыль. Для того что бы несколько классов объединить в один достаточно инъекции методов.

> я считаю, что строгая типизация это такое ограничение,

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

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

>под фрю - вряд ли

есть же слой совместимости

на данный момент M$ её ведь не выпустил

на черный день берегут

>> так строгая типизация или статическая ?

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

Кроме того есть мнение (и это важно), что питон - ЯП с динамической строгой типизацией.

Взгляните сюда: http://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%...

Хотя от себя замечу, что я слышал и об «утиной типизации» («Все что крякает и плавает как утка - есть утка») применительно к питону. Кто тут прав сказать трудно, но кое-какие возможные «финты ушами», я думаю, не совсем подпадают под определение строгой типизации. Но может быть в статье имелся ввиду питон 3 или я чего-то не до конца понимаю.

>>это чтобы на грабли не наступать придумали)

Любой цивилизованный IDE отловит синтаксические ошибки на момент сохранения. А ошибки логические ты так-и-так без юнит-тестирования с гарантией не отловишь. Так что отлов ошибок во время компиляции - достоинство сомнительное.

да и дополнительные оптимизации сделать позволяет во время компиляции

А зачем оптимизация, если нет компилежки кода? Не, ну если R-код можно оптимизировать.... Можно конечно соптимизировать код среды исполнения. То есть сам интерпретатор питона. Это - да. Но лично мне - линиво. Хочешь - компиляй, дело твое.

> А ошибки логические ты так-и-так без юнит-тестирования с гарантией не отловишь.

С гарантией ты их и юнит-тестированием не отловишь...

Так что отлов ошибок во время компиляции - достоинство сомнительное.

...так что юнит-тестирование - достоинство сомнительное.

> А зачем?

Чтобы сотни тысяч явовых программистов…

Ни к чему. :-)

На самом деле к тому же :)

... мать. Все-таки мейнстрим ООП-идеологи убили прогаммистам мозги. В мейнстрим ООПе вся типизация построена исключительно для того, чтобы не было конфликтов интерфейсов объектов. Там вообще понятие типа само по себе не рассматривается без привязки к понятиям «интерфейс» и «поведение».

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

Людям с процедурным мышлением этого не понять. К сожалению большинство языков не то что допускают, а вынуждают использовать процедурную логику пришедшую к нам из далеких времен, когда большинство проблем с котороми сталкивается современный программист просто не стояло. И «динамичесике» языки типа питона, руби и груви, которые помимо всего прочего позовляют в волю издеваться над не самыми плохими принципами ООП, в вопросе процедурной логики стоят на первом месте. Например, в питоне ты *можешь* программировать в комбинаторном стиле. Но через некоторое время, как только количество единиц комбинации перевалит за сотню, твоя прогамма превратится в черт знает что, как раз из-за отстутствия явного контроля типов на уровне языка.

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

> Типы нужны не для того, чтобы чего-то отлавливать.

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

Ловкое жонглирование взаимоисключающими параграфами детектед.