Собственно показалась интересной вот эта заметка, где упоминается про то, что IronPython после 3 версий компилятора был написан на C#. И основная мысль о том, что статика больше подходит для крупных проектов/команд.
Здравствуйте, Курилка, Вы писали:
К>Собственно показалась интересной вот эта заметка, где упоминается про то, что IronPython после 3 версий компилятора был написан на C#. И основная мысль о том, что статика больше подходит для крупных проектов/команд.
Здравствуйте, squiz, Вы писали:
S>Как что??? Новый топик! Вперед по новой флеймить!
а толку то. Всё равно закончится "у нас в нашей мега-команде из двух девелоперов никаких проблем с динамикой нет, поэтому никаких проблем не может быть никогда, а если у вас они есть, то вы просто позорные ламеры"
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, squiz, Вы писали:
S>>Как что??? Новый топик! Вперед по новой флеймить!
Д>а толку то. Всё равно закончится "у нас в нашей мега-команде из двух девелоперов никаких проблем с динамикой нет, поэтому никаких проблем не может быть никогда, а если у вас они есть, то вы просто позорные ламеры"
Здравствуйте, Курилка, Вы писали:
К>Собственно показалась интересной вот эта заметка, где упоминается про то, что IronPython после 3 версий компилятора был написан на C#. И основная мысль о том, что статика больше подходит для крупных проектов/команд.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>Собственно показалась интересной вот эта заметка, где упоминается про то, что IronPython после 3 версий компилятора был написан на C#. И основная мысль о том, что статика больше подходит для крупных проектов/команд.
FR>Есть противоположное мнение http://codespeak.net/pypy/dist/pypy/doc/architecture.html
Блин, почему нет кнопки отменить оценку?
Вопрос-то был не в том, на чём компилятор питона писать, а в корелляции между применением статики/динамики и размером проектов.
И подскажи тогда — почему IronPython не на PyPy написан?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, Курилка, Вы писали:
К>>>Собственно показалась интересной вот эта заметка, где упоминается про то, что IronPython после 3 версий компилятора был написан на C#. И основная мысль о том, что статика больше подходит для крупных проектов/команд.
FR>>Есть противоположное мнение http://codespeak.net/pypy/dist/pypy/doc/architecture.html
К>Блин, почему нет кнопки отменить оценку? К>Вопрос-то был не в том, на чём компилятор питона писать, а в корелляции между применением статики/динамики и размером проектов. К>И подскажи тогда — почему IronPython не на PyPy написан?
Потому что PyPy пока очень далек от завершения.
А на вопрос про кореляцию там тоже ответ есть, сам PyPy гораздо более сложный и объемный проект чем IronPython, однако вполне успешно пишется на динамическом языке.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>И подскажи тогда — почему IronPython не на PyPy написан?
FR>Кстати вся функцианальность IronPython эта часть PyPy, так как он может транслировать и в CLI
А мужики-то не знают! (ц)
BTW ты не в курсе там из МС в комманде этого железного питона нет людей?
Здравствуйте, Курилка, Вы писали:
FR>>Кстати вся функцианальность IronPython эта часть PyPy, так как он может транслировать и в CLI
К>А мужики-то не знают! (ц) К>BTW ты не в курсе там из МС в комманде этого железного питона нет людей?
Не знаю, но у ms уже была одна попытка написать питон под NET, которая с успехом провалилась. Ну автору JPython не без помощи ms теперь это удалось.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
FR>>>Кстати вся функцианальность IronPython эта часть PyPy, так как он может транслировать и в CLI
К>>А мужики-то не знают! (ц) К>>BTW ты не в курсе там из МС в комманде этого железного питона нет людей?
FR>Не знаю, но у ms уже была одна попытка написать питон под NET, которая с успехом провалилась. Ну автору JPython не без помощи ms теперь это удалось.
Ммм, ты про Jim Hugunin? Кстати буковку P оттуда в 2000-м году убрали
А Jython вообще не пойму в каком состоянии находится, последняя новость за март прошлого года и роадмэп на 2005-й год написан...
Не зря значит сан деньги не в питон а в руби направила?
FR>>Не знаю, но у ms уже была одна попытка написать питон под NET, которая с успехом провалилась. Ну автору JPython не без помощи ms теперь это удалось.
К>Ммм, ты про Jim Hugunin? Кстати буковку P оттуда в 2000-м году убрали
Угу, когда P убрали он уже ушел.
К>А Jython вообще не пойму в каком состоянии находится, последняя новость за март прошлого года и роадмэп на 2005-й год написан...
Они вообще сильно тормозят, вроде уже был один такой переиод полного затишья.
К>Не зря значит сан деньги не в питон а в руби направила?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>Не зря значит сан деньги не в питон а в руби направила?
FR>Вроде она никогда и не финансировола Jython.
Дак я про то и не говорил...
Просто, думаю, что у них был выбор — Jython, JRuby или Groovy. Выбрали второй. При том, что в Jython никакой активности, странно было бы если они его выбрали...
Здравствуйте, Курилка, Вы писали:
К>Вопрос-то был не в том, на чём компилятор питона писать, а в корелляции между применением статики/динамики и размером проектов.
Имхо, корреляцию нужно искать между статикой и размером команды, а не размером проекта.
Если не ошибаюсь, здесь мелькали упоминания проектов на TCL в полмиллиона строк и на Erlang-овые системы в сотни тысяч строк. Промышленные системы на Smalltalk так же, наверняка, содержат сотни тысяч строк кода. Если учесть, что динамически типизированный код во многих случаях оказывается компактнее аналогичного статически типизированного, то такие проекты сравнимы с аналогами на статически типизированных языках с два-три раза большим количеством строк. (Здесь нужно ожидать возражений со стороны приверженцов статически типизированных языков с автоматическим выводом типов, в первую очередь, как ты понимаешь, Nemerle. Но и Scala, и OCaml здесь так же выглядят совсем не плохо. Приношу извинения сторонникам других языков с аналогичной возможностью, но я говорю лишь о том, что знаю. Это всего лишь мои субъективные впечатления от сравнения кода C++/Java с Ruby/Python и, отчасти, впечатления от Smalltalk и Scala.)
А вот важность статической типизации с ростом количества работающих над общим кодом разработчиков возрастает, имхо, по очень простой причине: важность коммуникаций и сложность их осуществления. Наличие дополнительной информации в коде в виде анотаций типов и спецификаций доступных операций в декларациях типов сильно сокращает время ознакомления с чужим кодом. В небольшой команде нет проблем получить консультацию у автора кода, тем более, что в небольших командах, имхо, не так уж часто приходится браться за чужой код. Но вот если команда из десятков человек и если над фрагментом уже успело поработать несколько авторов... Тогда самый достоверный источник -- это сам код, и чем больше он снабжен полезной информацией (в виде деклараций типов), тем лучше.
Вообще-то все это уже неоднократно обговаривалось. Зачем еще раз подобное обсуждение затевать? Складывается впечатление, что ты пытаешься выработать у себя какое-то мнение по этому вопросу, но пока не получается.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Курилка, Вы писали:
К>Дак я про то и не говорил... К>Просто, думаю, что у них был выбор — Jython, JRuby или Groovy. Выбрали второй. При том, что в Jython никакой активности, странно было бы если они его выбрали...
Наверно просто сейчас Руби более модный вот его и взяли
А для ms важнее было сделать именно питон, так как они еще до выхода NET, в качестве рекламы подержки разных языков платформой, использовали Python.NET который так и не был реализован.
Здравствуйте, FR, Вы писали:
К>>И подскажи тогда — почему IronPython не на PyPy написан? FR>Кстати вся функцианальность IronPython эта часть PyPy, так как он может транслировать и в CLI
Здравствуйте, ie, Вы писали:
ie>Здравствуйте, FR, Вы писали:
К>>>И подскажи тогда — почему IronPython не на PyPy написан? FR>>Кстати вся функцианальность IronPython эта часть PyPy, так как он может транслировать и в CLI
ie>IronPython в CLI?! Расскажите как
PyPy умеет компилировать не только в нативный код но и в CLI.
