Привет.
В целом мне нравится писать на Питоне. Я бы даже сказал, что на нём приятнее писать чем на всех язык, с которыми мне пришлось поработать. Но не даёт покоя один вопрос :) Он появился сразу как я начал использовать динамические языки, и никак не выходит из головы. Я пытался найти ответ в разных обсуждениях/форумах.
Как может разработка на динамических языкак быть быстрой и удобной? Без Code Completion. Т.е. что бы получить список всех методов какого-то объекта, нужно обязательно лезть в справку. Т.е. сначала нужно найти справку на ту библиотеку, которую используешь, а потом, если повезёт, найти справку на предположительно тот объект, который используешь.
Вот для сравнения, хочу в Qt повеситься на событие on click кнопки, которая приходит мне в функцию аргументом. Что я делаю. Пишу arg, ставлю точку, и ничего не вижу, потому IDE не знает какого типа пришедший аргумент. Я ищу справку на Qt, ищу какой же класс отвечает за кнопку, ищу событие поиском по странице по имени click, нахожу. В итоге я потратил минуту-две, выполнив множество действий, не относящихся к решению задачи, для которой программа создаётся.
С другой стороны, в статическом языке я бы (и IDE) знал, какой тип мне пришёл, и по подсказке за 5 секунд нашёл бы нужное событие.
И это не говоря о цепочках вызовов ob1.getSomething().getOther().doSomething(). В статическом языке - секунды на просмотр подсказки и выбор нужного метода/поля, в динамических языках - минуты на поиск по манам.
И вообще вот смотришь ты какой-то код (чужой или свой старый), видишь что там у какого-то объекта вызывается такой-то метод, а потом в цикле перебираются какие-то значения. Хочешь что-то добавить, и не можешь - потому что ну нигде нет описания а какого же типа этот объект. А есть это описание в одном единственном месте в каком-нибудь конструкторе и фик знает в каком файле. Вот и лазаешь по исходникам совсем без подсказок несколько минут, пытаясь отыскать информацию, которая в статических языках всегда перед глазами.
Это ещё без всяких рефакторингов, которые вообще страшно делать. И всякие другие неприятные штуки есть.
Вот и где же тут быстрая и удобная разработка?
Вот с этим и никак не могу определиться. Заставляет задуматься, а верный ли путь я выбрал, выбрав Питон, а не треснет ли крыша от всего этого рантайма, а не загнутся ли динамические языки под весом своих же проблем… :) И настолько ли хороши динамические языки?
Наверное я чего-то не понимаю… Как решили вопрос? :)
Полная версия: "Быстрая" разработка на Python
На счет цепочек и “фабрик” и правда засада. А при простом создании объектов, обычно проблем нет, зависит от выбора IDE. Правда в PyQt поленились сделать докстринги.
Но будем надеяться, что разработчики IDE не сидят на месте. Например в PDE Эклипса приделали служебные комментарии, с описанием возвращаемого класса. Было бы довольно удобно, если бы в докстрингах каким-то образом описывался возвращаемый класс, чтобы IDE могла его прочитать, и приучить всех его там указывать…
Но будем надеяться, что разработчики IDE не сидят на месте. Например в PDE Эклипса приделали служебные комментарии, с описанием возвращаемого класса. Было бы довольно удобно, если бы в докстрингах каким-то образом описывался возвращаемый класс, чтобы IDE могла его прочитать, и приучить всех его там указывать…
race1http://ergosolo.ru/ - реально допомагає;
Как может разработка на динамических языкак быть быстрой и удобной? Без Code Completion.
взагалі не розумію людей які використовують всякі іде; колись користвувався вбудованим редактором MC, потім joe, тепер vim.
race1dir(obj), help(obj), http://pypi.python.org/pypi/see.
Т.е. что бы получить список всех методов какого-то объекта, нужно обязательно лезть в справку.
можете десь тримати собі відкриту пітонівську консоль і набирати ті команди;
IDE не использую. Вот уже много лет как. Память тренирую :) Code Competition - он, кстати, тоже бывает очень разный. Замнем для ясности…
Если смотришь на код и не понимаешь, что он делает - проблема либо в тебе, либо в коде. Какую-то часть нужно усовершенствовать :)
Рефакторинги (как и разработка вообще) должна опираться на тесты. Юниттесты, регрессионные, функциональные… Без них уверенный рефактор все ревно не возможен, и static typing тут не при чем.
Код на Питоне короткий и легко читаемый - именно это для меня дает основание называть его “быстрым языком разработки”. Его быстро писать, а еще быстрее читать чужие исходники. Обычно второе приходится делать гораздо чаще.
И на этом получается реальная “экономия сил и средств”.
Если смотришь на код и не понимаешь, что он делает - проблема либо в тебе, либо в коде. Какую-то часть нужно усовершенствовать :)
Рефакторинги (как и разработка вообще) должна опираться на тесты. Юниттесты, регрессионные, функциональные… Без них уверенный рефактор все ревно не возможен, и static typing тут не при чем.
Код на Питоне короткий и легко читаемый - именно это для меня дает основание называть его “быстрым языком разработки”. Его быстро писать, а еще быстрее читать чужие исходники. Обычно второе приходится делать гораздо чаще.
И на этом получается реальная “экономия сил и средств”.
race1А за такое неплохо бы расстреливать.
И это не говоря о цепочках вызовов ob1.getSomething().getOther().doSomething(). В статическом языке - секунды на просмотр подсказки и выбор нужного метода/поля, в динамических языках - минуты на поиск по манам.
PooHОбоснуйте? :) Как надо писать что бы погладили по головке?
А за такое неплохо бы расстреливать.
crchemistЯ же не говорил что этого нельзя сделать. Я говорил про затраченное время. Затраченное время на Ctrl+Space - 0,1 секунды, затраченное время на dir/help/console - от нескольких секунд до нескольких минут. Умножим разницу во времени на кол-во подобных действий, которых сотни в рабочем дне, и получим, что написать код с подсказками в n раз быстрее и проще, чем без подсказок.
dir(obj), help(obj), http://pypi.python.org/pypi/see.
можете десь тримати собі відкриту пітонівську консоль і набирати ті команди;
race1Ну разработчиков по головке никогда не гладят :(
Как надо писать что бы погладили по головке?
Я имею ввиду, что получается аццкое зацепление классов - мы должны быть уверены в существовании всей цепочки. В идеале должно быть
ob1.getSomething(), а уж в getSomething - getOther и прочие подробности :)
Почитайте про принцип Деметры
PooH
Некоторые классы специально разрабатываются что бы можно было использовать такие цепочки. Т.е. каждый метод что-то делает с объектом и возвращает себя. Например, какой-нибудь AR класс, работающий с данными. myData.addFields('a', ‘b’, ‘c’).addFilter('a=1').select(). Без цепочек убьёшься писать :)
В других случаях, где метод возвращает объект, конечно лучше вынести в отдельную переменную и убедиться, что объект действительно вернулся. try { z = y.getZ(); z.doThis() } Но, с другой стороны, если документация говорит, то getZ в любом случае вернёт объект (а не false или null в некоторых случаях), то почему бы этому не поверить, и не заиспользовать цепочку, сократив и упростив понимание кода?
Так что я думаю расстреливать никого уже не нужно :)
Некоторые классы специально разрабатываются что бы можно было использовать такие цепочки. Т.е. каждый метод что-то делает с объектом и возвращает себя. Например, какой-нибудь AR класс, работающий с данными. myData.addFields('a', ‘b’, ‘c’).addFilter('a=1').select(). Без цепочек убьёшься писать :)
В других случаях, где метод возвращает объект, конечно лучше вынести в отдельную переменную и убедиться, что объект действительно вернулся. try { z = y.getZ(); z.doThis() } Но, с другой стороны, если документация говорит, то getZ в любом случае вернёт объект (а не false или null в некоторых случаях), то почему бы этому не поверить, и не заиспользовать цепочку, сократив и упростив понимание кода?
Так что я думаю расстреливать никого уже не нужно :)