[Java][Python] Скорость разработки

>4 фреймворка
откуда там столько? на питоне же только один написан - django

на выходе у ТС получается, что скорость разработки на Java > чем скорость разработки на Python.(при условии, что разрабатывается один и тот же продукт).

все правильно.

Собственно, что это генетическая предрасположенность к языкам с явной типизации или же на Java более качественная литература? (Horstmann vs. Martelli)?

наличие в джаве огромного количества готовых библиотек в отличии от. Как язык, питон может и лучше в чем-то, но по codebase джава выигрывает в скорости разработки.

>откуда там столько?

django, pylons, twisted, web2py
на деле есть еще CherryPy, Flask, Quixote, TurboGears...

наличие в джаве огромного количества готовых библиотек в отличии от. Как язык, питон может и лучше в чем-то, но по codebase джава выигрывает в скорости разработки.

выигрыш в core, до спец. библиотек в Java я еще не дошел.

Сам проанализируй где тормозишь и посмотри от чего так - недостаток опыта или «кривые» инструменты.

М.б. все дело в отступах?

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

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

У java более качественно продуманная архитектура же, за спиной jdk 1.7.0_b128 15 лет разработки и свыше 40 лет исследований

>и свыше 40 лет

proof?

«Sun в жабу синтезировало все лучше что было до нее» погугли и найдешь сотни пруфов

>скорость разработки на Java > чем скорость разработки на Python

Скорость разработки чего, хелловорлдов?

при условии, что разрабатывается один и тот же продукт

Конкретики, больше конкретики

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

По идее на динамических писать проще и быстрее

или же на Java более качественная литература? (Horstmann vs. Martelli)?

Вот это по-моему тут ну вообще ни при чём.

осталось сравнить с C++, CL и Haskell для создания идеально флеймогонной темы

По идее на динамических писать проще и быстрее

За счет чего? Мне интересно. :)

> По идее первый более-менее масштабный рефакторинг кода должен заставить программиста люто срать кирпичами.

Бинго!

>или «кривые» инструменты.

Ну, дык, ТС-же сразу его указал - [Python]

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

Прозреваю обмазывание всеми возможными видами тестов.

худей

>За счет чего? Мне интересно. :)

За счет того, что не надо декларировать типы, очевидно же :] Программирование в дебаггере - очень увлекательный и познавательний экспирьенс

Почитай историю HotSpot. Вот тут, например: http://ru.smalltalk.wikia.com/wiki/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F...

Если кратко, дело было так: Smalltalk 80 -> Self -> Strongtalk -> HotSpot

Есть же автовывод типов и auto! Те указывать типы надо только для входящих/выходящих параметров и полей классов. Правда не знаю есть ли auto в java но оно есть в с++0x

также TC может не метатся в выборе того или иного а писать Jython или java и юзать либы и java и питона.

писать - да, быстрее. А саппортить - невозможно.
Тут возможно два варианта развития событий: либо писать быстро и использую фишки питона, либо писать поддерживаемо и прийти к тому же ООП что в и джаве.

если от питона отнять ооп, то ничего почти и не останется.

Автовывод (если мы думаем об одном и том же - это ведь как var в C#?) - это не то. Я ведь не просто так упомянул программирование в отладчике :)

>худей

учи уроки

во время похудания ещё можно чего-нибудь почитать из худ.лита, для обогащения словарного запаса.

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

иди почитай про тестирование, и конкретно про модульное тестирование

«Sun в жабу синтезировало все лучше что было до нее» погугли и найдешь сотни пруфов

погугли «жаба г@вно» и найдёшь сотни пруфов обратного, и?

Программирование в дебаггере - [..]

если дело дошло до дебаггера - Вы делаете что-то совсем не так

писать - да, быстрее. А саппортить - невозможно.

лжец и девственник, почему «невозможно» сумеете объяснить?

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

Потому что программист должен думать головой, когда пишет. Тогда и рефакторить будет легко.

Да ви просто кардинально не понимаете, о чём речь :] Невозможно это объяснить человеку, который не программировал в дебаггере

Невозможно это объяснить человеку, который не программировал в дебаггере

я свою первую программу написал в 1991 году, поверьте, я и не такое ещё пробовал :)

// man sarcasm не предлагать :)

иди почитай про тестирование, и конкретно про модульное тестирование

И что ты этим хотел сказать? Что ручной контроль типов будет лучше автоматического? Или что он хотя бы не хуже?

>иди почитай про тестирование, и конкретно про модульное тестирование

И что ты этим хотел сказать? Что ручной контроль типов будет лучше автоматического? Или что он хотя бы не хуже?

повторюсь: иди почитай про тестирование, и конкретно про модульное тестирование

повторюсь: иди почитай про тестирование, и конкретно про модульное тестирование

Почитать, это конечно хорошо. Но если ты говоришь с таким умным видом (типа я здесь умный, а вы все дураки), то будь добр, приведи конкретные аргументы, которые можно хоть как-то осмыслить на предмет их корректности. «Поди почитай книжки» - это не аргумент, такой фразой можно играть как угодно.

Рассмотрим конкретный случай. Есть класс, который надо разделить на два. Будем считать, что расщепление функционала улучшит архитектуру программы. Этот класс был узловым и использовался во многих местах. Стоит задача найти все эти места и поправить их с учетом расщепления класса на два. В языках со строгой типизацией задача решается довольно просто. Как тоже самое сделать в питоне?

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

Почитать, это конечно хорошо.

не просто хорошо, а весьма полезно, причём даже со второго раза до Вас это так и не дошло, увы

ты говоришь с таким умным видом (типа я здесь умный, а вы все дураки)

не надо мне приписывать свои мысли

Рассмотрим конкретный случай. Есть класс, который надо разделить на два. Будем считать, что расщепление функционала улучшит архитектуру программы. Этот класс был узловым и использовался во многих местах. Стоит задача найти все эти места и поправить их с учетом расщепления класса на два. В языках со строгой типизацией задача решается довольно просто. Как тоже самое сделать в питоне?

начнём с того что не вижу здесь какой-то неземной проблемы связанной конкретно с типизацией, едем далее - как в случае кода на ЯП со строгой типизацией, так и в случае кода на ЯП с динамической типизацией (ну Вы поняли), за контроль работы кода отвечают тесты, и типизация тут ни при чём

comprende?

Вкратце, тесты здесь мало чем помогут. .

немотивированный вывод

Проще грепнуть все объявления переменных расщеплённого класса и изменить их имена, скомпилить и ходить по ошибкам и менять имена там, наткнулись на вызов функции, изменить не только имя параметра, но и сигнатуру функции и т.д. - по всему дереву использования.

индусам такой подход очень нравится, а вот сами индусы ПМ'ам уже не очень

> как в случае кода на ЯП со строгой типизацией, так и в случае кода на ЯП с динамической типизацией (ну Вы поняли

как я ненавижу тех, кто путает статическую/динамическую и строгую/слабую типизацию.

> Рассмотрим конкретный случай. Есть класс, который надо разделить на два. Будем считать, что расщепление функционала улучшит архитектуру программы. Этот класс был узловым и использовался во многих местах. Стоит задача найти все эти места и поправить их с учетом расщепления класса на два. В языках со строгой типизацией задача решается довольно просто. Как тоже самое сделать в питоне?

rope в руки и пошел.

> покрытие тестами должно быть стопроцентным.

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

> как в случае кода на ЯП со строгой типизацией, так и в случае кода на ЯП с динамической типизацией (ну Вы поняли

как я ненавижу тех, кто путает статическую/динамическую и строгую/слабую типизацию.

ну, простите великодушно :)

попробую отмазаться: я всё же параллельно работать пытаюсь, а работаю над статическим анализатором кода - видимо просочилось

Стоит задача найти все эти места

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

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

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

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

2. также хочу заметить что основывать суждение о невозможности сопровождения ПО написанного на питоне используя вышеприведённый факт - некорректно

3. всё же, как-то борются с такими вещами и побеждают, ведь правда?

Я всегда считал, что unit тесты не предполагают сверх высокую надежность, то есть они не могут защитить от 99,99% всех нарушений логики программы.

предложите альтернативу, только не надо говорить про типизацию, плиз, ибо это из области вопросов - что лучше windows или assembler

Слишком высокое покрытие кода тестами, чтобы оно защищало на 99,99%, должно стоить не оправдано дорого.

всё так :)

также хочу заметить что основывать суждение о невозможности сопровождения ПО написанного

Я говорил конкретно про некоторые серьезные проблемы с рефакторингом.

предложите альтернативу, только не надо говорить про типизацию, плиз, ибо это из области вопросов

В том конкретном случае, что я привел, строгая типизация помогает решить поставленную задачу очень хорошо. В этом я убедился на практике многократно. Я бы при этом не сказал, что достигается гарантия 100%, скорее гарантия 99,9%. В общем, для применения на практике вполне приемлемо.

и найдёшь сотни пруфов обратного, и?

это не пруфы а высеры. не путай

>также хочу заметить что основывать суждение о невозможности сопровождения ПО написанного

Я говорил конкретно про некоторые серьезные проблемы с рефакторингом.

ORLY? цитирую дословно:

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

и теперь смотрим на SQLAlchemy (и ещё +100500 проектов), улыбаемся и машем ручкой

так что же делают не так те у кого большие проекты работают (и, соответственно, рефакторятся)?

> и найдёшь сотни пруфов обратного, и?

это не пруфы а высеры. не путай

обоснуй

ORLY? цитирую дословно:

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

К.О. подсказывает, что они четко разделяют на модули проект, четко определяют внешний API модулей,пишут подробную доку->????->PROFIT!! Глобально в алхимии три модуля, а внутри них еще множество других

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

Да так же как и везде :) В С++ Вы думаете легче разгребать тонны кода? Нифига подобного! И типизация тут не поможет, честно. :) Да типизация - это, если хотите, вообще не проблема. А то что Вы упорно под неё подводите - это банальное управление сложностью проекта.