Ruby vs Python vs Tcl
Victor Bazhenov
Hе ради флейма... :) Поделитесь опытом, кто пользовался всем перечисленным.
Какому скриптовому языку отдать предпочтение? Пока склоняюсь к Ruby. :)
Или тут дело только вкуса? Может быть все же есть явные плюсы или минусы?
--
Best regards
Ruslan Kosolapov
VB> Hе ради флейма... :) Поделитесь опытом, кто пользовался всем
VB> перечисленным. Какому скриптовому языку отдать предпочтение?
VB> Пока склоняюсь к Ruby. :) Или тут дело только вкуса? Может быть
VB> все же есть явные плюсы или минусы?
Что писать будешь?
--
rk
Dmitry Karasik
Victor> Hello All. Hе ради флейма... :) Поделитесь опытом, кто
Victor> пользовался всем перечисленным. Какому скриптовому языку отдать
Victor> предпочтение? Пока склоняюсь к Ruby. :) Или тут дело только вкуса?
Victor> Может быть все же есть явные плюсы или минусы?
perl6 :)
http://www.perl.com/pub/a/2007/12/06/soto-11.html
--
Sincerely,
Dmitry Karasik
Victor Bazhenov
Fri, 07 Dec 2007 09:32:12, Ruslan Kosolapov wrote:
VB>> Hе ради флейма... :) Поделитесь опытом, кто пользовался всем
VB>> перечисленным. Какому скриптовому языку отдать предпочтение?
VB>> Пока склоняюсь к Ruby. :) Или тут дело только вкуса? Может быть
VB>> все же есть явные плюсы или минусы?
RK> Что писать будешь?
General purpose. :) Hу разве что веб не нужен пока. А так - все для чего
предназначен scripting language.
--
Best regards
Ruslan Kosolapov
VB>>> Hе ради флейма... :) Поделитесь опытом, кто пользовался всем
VB>>> перечисленным. Какому скриптовому языку отдать предпочтение?
VB>>> Пока склоняюсь к Ruby. :) Или тут дело только вкуса? Может быть
VB>>> все же есть явные плюсы или минусы?
RK>> Что писать будешь?
VB> General purpose. :) Hу разве что веб не нужен пока. А так - все
VB> для чего предназначен scripting language.
python, как наиболее мейнстримный из всех.
PS: tcl очень хорош, но его надо уметь :)
--
rk
Victor Bazhenov
Mon, 10 Dec 2007 15:40:52, Ruslan Kosolapov wrote:
VB>>>> Hе ради флейма... :) Поделитесь опытом, кто пользовался всем
VB>>>> перечисленным. Какому скриптовому языку отдать предпочтение?
VB>>>> Пока склоняюсь к Ruby. :) Или тут дело только вкуса? Может быть
VB>>>> все же есть явные плюсы или минусы?
RK>>> Что писать будешь?
VB>> General purpose. :) Hу разве что веб не нужен пока. А так - все
VB>> для чего предназначен scripting language.
RK> python, как наиболее мейнстримный из всех.
RK> PS: tcl очень хорош, но его надо уметь :)
Расскажешь как? :)
--
Best regards
Ruslan Kosolapov
VB>>>>> Hе ради флейма... :) Поделитесь опытом, кто пользовался всем
VB>>>>> перечисленным. Какому скриптовому языку отдать предпочтение?
VB>>>>> Пока склоняюсь к Ruby. :) Или тут дело только вкуса? Может
VB>>>>> быть все же есть явные плюсы или минусы?
RK>>>> Что писать будешь?
VB>>> General purpose. :) Hу разве что веб не нужен пока. А так - все
VB>>> для чего предназначен scripting language.
RK>> python, как наиболее мейнстримный из всех.
RK>> PS: tcl очень хорош, но его надо уметь :)
VB> Расскажешь как? :)
А я не умею :) Я tcl знаю на уровне синтаксиса/семантики, больших
проектов на нём не писал, но видел, что на нём делают те, кто умеет
:)
Мне вообще scheme и common lisp нравятся сильно больше всех других.
Для лёгких процессов - самое то.
tcl в отличие от python мне кажется слишком свободным. Это хорошо
только тогда, когда умеешь :)
--
rk
Serguey Zefirov
RK> Для лёгких процессов - самое то.
Agile methodologies?
TDD, TFD, PP, etc?
Если это так, то...
Yours truly, Serguey Zefirov (thesz AT mail DOT ru)
Ruslan Kosolapov
RK>> Мне вообще scheme и common lisp нравятся сильно больше всех
RK>> других. Для лёгких процессов - самое то.
SZ> Agile methodologies?
SZ> TDD, TFD, PP, etc?
По духу, но не по букве. TDD вообще можно считать тяжёлым
процессом, просто вместо SRS, SAD, STP и прочего пишется большой
набор тестов, который точно так же, как и в тяжёлых процессах, надо
переписывать не только при изменении требований, но и при изменении
дизайна или даже просто при рефакторинге. Заменили одно на
эквивалентное другое, и назвали лёгким процессом, а на деле те же
яйца ;)
У меня примерно так, как gaperton недавно писал в ЖЖ. Делается
только то, не делание чего дороже, чем делание. "Дороже/дешевле"
выявлено практикой конкретно для данной группы программистов и
данного софта.
SZ> Если это так, то...
haskell мне не нравится :) Там императивщины нет, и состояний тоже
нет. А я хочу :)
--
rk
Victor Bazhenov
Tue, 11 Dec 2007 10:13:10, Ruslan Kosolapov wrote:
RK>>> PS: tcl очень хорош, но его надо уметь :)
VB>> Расскажешь как? :)
RK> А я не умею :) Я tcl знаю на уровне синтаксиса/семантики, больших
RK> проектов на нём не писал, но видел, что на нём делают те, кто умеет
RK> :)
А примеры можешь привести - чего на нем делают такого, кто умеет? :)
--
Best regards
Ruslan Kosolapov
RK>>>> PS: tcl очень хорош, но его надо уметь :)
VB>>> Расскажешь как? :)
RK>> А я не умею :) Я tcl знаю на уровне синтаксиса/семантики,
RK>> больших проектов на нём не писал, но видел, что на нём делают
RK>> те, кто умеет :)
VB> А примеры можешь привести - чего на нем делают такого, кто умеет? :)
Hу я видел очень такую симпатичную систему тестирования. Софт в
принципе довольно простой - отказоустойчивые распределённые
хранилища данных (для MS Exchange, например), но тем не менее. Это
закрытая разработка. Regression tests, functional tests (которые в
большинстве своём stress/load tests), составление отчётов (с
группировкой по типам проблем). Эту внутри практически не видел, в
основном сужу по словам тех, кто работал с ней.
Также видел программку для автоматического написания release notes
(информация вытягивается из разных источников, группируется,
дубликаты детектятся и отсеиваются (ну там как-то по ключевым словам
сделано), формируется английский текст, в нём пишется whats new,
known problems, changelog, howto и прочие вещи). Также внутренняя
разработка. Вычитка, конечно, требуется, но обычно правки делаются
с помощью кнопочки delete.
photo.net на tcl написан вроде как.
tkabber мне понравился изнутри. Это из открытого.
Все вещи характерны высокой степенью расширяемости и
конфигуряемости. Hу и кода относительно немного, и он довольно
понятный.
--
rk
Serguey Zefirov
RK>>> других. Для лёгких процессов - самое то.
SZ>> Agile methodologies?
SZ>> TDD, TFD, PP, etc?
Зачем тогда вообще про это упоминать?
Я по духу дзен-буддист просто потому, что любой человек дзен-буддист.
RK> У меня примерно так, как gaperton недавно писал в ЖЖ. Делается
RK> только то, не делание чего дороже, чем делание. "Дороже/дешевле"
RK> выявлено практикой конкретно для данной группы программистов и
RK> данного софта.
Если как у lj user=gaperton, то тем более не стоит называть это agile.
SZ>> Если это так, то...
RK> haskell мне не нравится :) Там императивщины нет, и состояний тоже
RK> нет. А я хочу :)
Есть там состояния.
Учись готовить. ;)
Ruslan Kosolapov
RK>>>> Мне вообще scheme и common lisp нравятся сильно больше всех
RK>>>> других. Для лёгких процессов - самое то.
SZ>>> Agile methodologies?
SZ>>> TDD, TFD, PP, etc?
RK>> По духу, но не по букве.
SZ> Зачем тогда вообще про это упоминать?
Hе понял вопроса твоего я.
SZ> Я по духу дзен-буддист просто потому, что любой человек дзен-буддист.
RK>> У меня примерно так, как gaperton недавно писал в ЖЖ. Делается
RK>> только то, не делание чего дороже, чем делание.
RK>> "Дороже/дешевле" выявлено практикой конкретно для данной группы
RK>> программистов и данного софта.
SZ> Если как у lj user=gaperton, то тем более не стоит называть это
SZ> agile.
Я не называю это agile, я называю это лёгким процесом. И я не знаю,
как у gaperton в реальности, я знаю, как он это описал. И описал он
лёгкий процесс.
Если пропустить цепочку причин/следствий, то получится, что можно
сказать, что лёгкий процесс отличается от тяжёлого тем, что сильно
зависит от качества исполнителей. Тяжёлый же - это методики,
которые позволяют не зависеть от качества исполнителей. Поэтому в
тяжёлых довольно большой оверхед на всякие формальности (например,
документ по code convention - у меня его нет, просто потому, что все
интуитивно понимают, как надо). У меня этого оверхеда нет, как нет
и бардака XP. btw, у TDD тоже нехилый оверхед на написание тестов,
и у меня его тоже нет. Выделенной фазы тестирования у меня нет,
каким образом девелопер будет выдавать работающий хороший код - это
его проблема, как хочет, так и решает.
SZ>>> Если это так, то...
RK>> haskell мне не нравится :) Там императивщины нет, и состояний
RK>> тоже нет. А я хочу :)
SZ> Есть там состояния.
То говоришь "нельзя смешивать парадигмы" и "хаскель - чист", то
оказывается там состояния есть (и императивщина получается тоже
есть, если я правильно понял, про какие состояния ты говоришь).
Хотя да, состояния в принципе можно засчитать. Hе знаю правда,
насколько это удобно там.
Про императивщину возражений нет, что её там нет?
--
rk
Serguey Zefirov
RK>>> haskell мне не нравится :) Там императивщины нет, и состояний
RK>>> тоже нет. А я хочу :)
SZ>> Есть там состояния.
RK> То говоришь "нельзя смешивать парадигмы" и "хаскель - чист", то
RK> оказывается там состояния есть (и императивщина получается тоже
RK> есть, если я правильно понял, про какие состояния ты говоришь).
Да, при желании. Во многих видах - композиционно чистом, и нет и даже можно
сделать что-то посередине.
Ведь Хаскель - это самый лучший императивный язык программирования.
RK> Хотя да, состояния в принципе можно засчитать. Hе знаю правда,
RK> насколько это удобно там.
Удобно, удобно.
Про удобство и быстроту работы с состояниями (правда, ML):
http://lambda-the-ultimate.org/node/2443
RK> Про императивщину возражений нет, что её там нет?
У тебя или у меня?