Здравствуйте, anonymous, Вы писали:
F>>>у кого больше шансов: django или ruby on rails ?. К>>Больше шансов в чём? К>>Я вот тоже с PHP хочу уйти, пока тоже django самый интересный вариант. К>>Про руби к примеру здесь
A>Django и RoR тут всё таки оффтопик, с ними в веб программирование.
A>Предлагаю другое обсудить. Имеют ли вообще Python и Ruby шансы без Django и RoR?
AFAIK, Руби имеет не только шансы ("потенциальную" энергию), но и достаточно обширное применение ("кинетическую"). Плюс, даже на вебе, на RoR свет клином не сходится (есть несколько концептуально интересных фреймворков — от супер-легкого Camping до Seaside-образного continuation-based Borges). При этом, заметим, RoR — далеко-далеко не самая клевая штука, которая может быть на Руби.
Здравствуйте, Nuald, Вы писали:
N>>> — perl — нечитабельный и способствует к тому чтобы программист писал нечитабельные скрипты; N>>> — ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности; A>>Это проблемы программиста, а не языка. N>Если бы все программисты были бы идеальными, тогда даже разговора бы не было. В реальных условиях чем больше язык и стандарты кодирования ограничивают программиста, тем обычно получается лучше, т.к. код прежде всего создается для людей, а не для машин. Конечно, имеются в виду промышленное программирование в командах, писать для себя на один раз — это совершенно другая тема.
(:
[r'% r',][~0] % {(): '''^''' uR'|' in 2**2*__name__[::-8//(lambda _:~_)(3 or 2)]*2}<2>3j,(`3`) is ([])
Да-да, это Python. Вердикт: "нечитабельный и способствует тому, чтобы программист писал нечитабельные скрипты".
N>>> — php — даже разговоров быть не может, странно что вообще его кто-то использует; A>>Низкий порог вхождения. N>И что? Из этого следует что он лучше? В Basic тоже низкий порог вхождения — это автоматом делает его лучшим?
Здравствуйте, anonymous, Вы писали:
A>А по умолчанию в браузере и не нужна ФС, и БД не нужна. А там, где нужны, все необходимые интерфейсы присутствуют.
Блин, я не понимаю — вы пытаетесь защитить javascript? Но ведь и так понятно, что как язык программирования он достаточно слаб. Простейший пример — реализация классов. Только не надо говорить, что классы не нужны — мало ли какие случаи бывают. Когда под боком есть достаточно мощные и удобные ЯП, зачем использовать более слабые альтернативы?
Здравствуйте, Nuald, Вы писали:
A>>А по умолчанию в браузере и не нужна ФС, и БД не нужна. А там, где нужны, все необходимые интерфейсы присутствуют. N>Блин, я не понимаю — вы пытаетесь защитить javascript? Но ведь и так понятно, что как язык программирования он достаточно слаб. Простейший пример — реализация классов. Только не надо говорить, что классы не нужны — мало ли какие случаи бывают. Когда под боком есть достаточно мощные и удобные ЯП, зачем использовать более слабые альтернативы?
В JavaScript нет классов вообще, это прототип-ориентированный язык, а не класс-ориентированный. Видимо, именно об этом Вас спрашивал Гест в сообщении выше. Вообще, понимание используемой в JavaScript парадигмы ООП — основы понимания этого языка. Отсюда можно сделать вывод, что с JavaScript Вы знакомы только понаслышке и, в общем-то, не можете судить о его слабых и сильных сторонах.
Здравствуйте, anonymous, Вы писали:
A>Perl нужно уметь готовить, и употреблять его тоже нужно уметь. Трудности чтения говорят о том, что недостаточно практики, а не о том, что язык нечитаемый. (Если конечно не касаться кода, специально сделанного нечитаемым.)
Вот часть моего кода, который натравливает Perl::Critic на все скрипты в каталогах и подкаталогах (соотвественно, сам скрипт тоже проходит валидацию Perl::Critic, т.е. считается анализатором достаточно качественным):
my @folders;
foreach (@both) {
next if /^(\.|\.\.)$/;
if (-d) {
push(@folders, $_);
} else {
push(@all, $_) if /.+\.(pl|cgi|pm)$/;
}
}
Вроде бы все просто, и нормально читается. Но если писать (или читать) на Perl-е достаточно редко, то сразу в этот код и не вникнуть. А ведь это еще хороший пример. И такое я вижу сплошь и рядом — Perl способствует к тому, что код получается не особо многословный, и надо иметь большую силу духа, чтобы заставить себя не пользоваться возможностями по умолчанию.
A>Перечисленные выше конструкции скорее можно отнести к синтаксическому сахару. Трудность их чтения проистекает исключительно из отсутствия аналогов в других распростанённых языках.
Не спорю, но нужны ли такие аналоги большинству? Сильно сомневаюсь, что для обычного программиста читать конструкцию if (-d) будет проще чем if (os.path.isdir(directory_name)) — особенно если ты не гуру перла (а во втором случае даже не надо знать питон, чтобы догадаться о чем речь).
Здравствуйте, Nuald, Вы писали:
A>>В JavaScript нет классов вообще, это прототип-ориентированный язык, а не класс-ориентированный. Видимо, именно об этом Вас спрашивал Гест в сообщении выше. Вообще, понимание используемой в JavaScript парадигмы ООП — основы понимания этого языка. Отсюда можно сделать вывод, что с JavaScript Вы знакомы только понаслышке и, в общем-то, не можете судить о его слабых и сильных сторонах. N>Ну если использование во всю jQuery можно назвать "знакомством понаслышке", тогда я умываю руки.
О, это всё равно что сказать, я использовал Django и теперь в совершенстве владею Python. Написать $('block').show() не значит понять как устроен язык.
N>И из того, что javascript является прототип-ориентированным языком, автоматически не следует, что он чем-то лучше других.
Здравствуйте, Гест, Вы писали:
Г>Вы сейчас, конечно же, станете ссылаться на фразу "выскажу свою скромную точку зрения", но она очевидно не оправдывает поверхностность вашего анализа.
Г>Я в данном случае защищаю не Руби или JS, а более внимательное отношение к анализу и бережное — к фактам, простите уж за занудство.
Когда задаются такого рода провакационные вопросы ("что лучше?"), анализ фактов не имеет такого уж решающего значения, потому что каждый выбирает все-таки больше по своему субъективному суждению, для кого-то важно только какое-то собственное подмножество фактов, а не вся их совокупность. Например, как бы с пеной у рта мне не доказывали преимущество Win2k3 перед RHEL, мне будет абсолютно фиолетово, т.к. для меня главное — удобство развертывания и настройки, а перспектива вручную качать софт с инета и кликать какие-то галочки меня совершенно не устраивает.
А всякого рода глубокие анализы фактов, вы уж извините, я оставлю академической среде и бездельникам. Мне нужно работать здесь и сейчас, и выбирать инструмент не по совокупному анализу, а по преимуществам в данной конкретной задаче:
— если нужно писать enterprise-level решение, выбираю Java (потому что есть богатые библиотеки и статическая типизация);
— если нужно склепать сайт небольшого размера — Django (потому что есть автоматическая админка и хорошая ORM-модель);
— если написать скрипт — Python (потому что он есть практически везде).
Конечно, есть и другие факторы, влияющие на выбор, но не думаю, что это особенно интересно. Возможно, в будущем мнение изменится, возможно я найду что-то уникальное в Ruby, что полностью перейду на него, но пока не вижу никаких причин этого делать.
Здравствуйте, Nuald, Вы писали:
N>Да что вы все так боитесь отступов?
Это чисто психологический момент, какая-то подсознательная боязнь, что незаметно для глаза перепутаются пробелы и табы, в результате я буду видеть одно, а компилятор — другое.
Здравствуйте, Nuald, Вы писали:
Г>>Вы сейчас, конечно же, станете ссылаться на фразу "выскажу свою скромную точку зрения", но она очевидно не оправдывает поверхностность вашего анализа.
Г>>Я в данном случае защищаю не Руби или JS, а более внимательное отношение к анализу и бережное — к фактам, простите уж за занудство.
N>Когда задаются такого рода провакационные вопросы ("что лучше?"), анализ фактов не имеет такого уж решающего значения, потому что каждый выбирает все-таки больше по своему субъективному суждению, для кого-то важно только какое-то собственное подмножество фактов, а не вся их совокупность. Например, как бы с пеной у рта мне не доказывали преимущество Win2k3 перед RHEL, мне будет абсолютно фиолетово, т.к. для меня главное — удобство развертывания и настройки, а перспектива вручную качать софт с инета и кликать какие-то галочки меня совершенно не устраивает.
Еще раз — я не убеждаю "попробовать Ruby". Я просто не люблю "случайных аргументов" в дискуссии (т.е. когда все альтернативы описываются одной строчкой, "однозначно дающей понять все недостатки"). А вы занимались именно этим — ваш пост с "описанием всех языков" более похож на неудачное тролление (хотя в последующих постах вы показали себя существенно лучше разбирающимся в предложенной теме).
Ну а если конкретно про Ruby vs. Python — "за" Руби стройное ООП и довольно широкие функциональные возможности (приводящие к "естественному" метапрограммированию); "против" — ужасы реализации. По категории "против" Питон точно лучше; а что там с категорией "за" — мне кажется, что Питон таки проигрывает. Если продемонстрируете обратное, это уже будет весомым вкладом в дискуссию.
ЗЫ: а вот аргументы типа "в Питоне отступы, ыыыы!" и "в Руби у программиста слишком опасные возможности, ыыы!" мне кажутся ващебессмысленными. И непригодными ни для чего, даже для тролления.
Начнем с СВ
Претенденты:
Perl
Python
Ruby
PHP
ктотоеще
а вообще.. скажите, кто пробовал django?.
мне советуют для разработки веб-движка вместо php использовать django, но никто из советчиков его не использовал толком..
у кого больше шансов: django или ruby on rails ?.
Здравствуйте, neFormal, Вы писали:
F>Начнем с СВ F>Претенденты: F>Perl F>Python F>Ruby F>PHP F>ктотоеще
Erlang? Tcl? Lua?
F>а вообще.. скажите, кто пробовал django?. F>мне советуют для разработки веб-движка вместо php использовать django, но никто из советчиков его не использовал толком.. F>у кого больше шансов: django или ruby on rails ?.
Больше шансов в чём?
Я вот тоже с PHP хочу уйти, пока тоже django самый интересный вариант.
Про руби к примеру здесь
Здравствуйте, Курилка, Вы писали:
F>>у кого больше шансов: django или ruby on rails ?. К>Больше шансов в чём? К>Я вот тоже с PHP хочу уйти, пока тоже django самый интересный вариант. К>Про руби к примеру здесь
Django и RoR тут всё таки оффтопик, с ними в веб программирование.
Предлагаю другое обсудить. Имеют ли вообще Python и Ruby шансы без Django и RoR?
Здравствуйте, anonymous, Вы писали:
A>Предлагаю другое обсудить. Имеют ли вообще Python и Ruby шансы без Django и RoR?
Если вопрос о фрэймворках вообще, то они, конечно, как и библиотеки, добавляют
ценности любому языку и без них чем будет язык — кусочками синтаксиса, связывающими
встроенные объекты ? Хотя, даже в этом случае, Python, например, замечательно
интегрируется в приложение для его скриптования. Ну и, то, что сразу вспоминают —
административные скрипты !
Если же вопрос именно про Django конкретно, то и без него других фрэймворков — куча,
вот например, рекомендую, собственной разработки: Питомник: http://www.pythomnic.org/
И ведь работает, обрабатывает платежи
Здравствуйте, anonymous, Вы писали:
Г>>При этом, заметим, RoR — далеко-далеко не самая клевая штука, которая может быть на Руби.
A>Но, мне кажется, RoR в популяризации Ruby сыграл огромную роль.
Безусловно. Я лишь про то, что Рельса — это не "великолепная идея, раскрутившая посредственный язык", и даже не "крайняя демонстранция возможностей неплохого языка", а лишь "неплохой (но и не гениальный) пример, какие возможности дает язык".
Здравствуйте, neFormal, Вы писали:
F>Начнем с СВ F>Претенденты: F>Perl F>Python F>Ruby F>PHP F>ктотоеще
Это бессмысленно — никто имхо не знает настолько хорошо все языки, чтобы мог сделать хотя бы полуобъективный вывод.
Так сложилось, что я, например, уже почти год изучаю (в смысле применяю в работе) перл — и чем больше его узнаю, тем больше понимаю, что ничего не понимаю. На нём такие штуки можно крутить — закачаешься.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, neFormal, Вы писали:
F>а вообще.. скажите, кто пробовал django?.
Пробовал, и написал на нем уже немало сайтов.
F>мне советуют для разработки веб-движка вместо php использовать django, но никто из советчиков его не использовал толком.. F>у кого больше шансов: django или ruby on rails ?.
У Django однозначно — он более mature и используется в крупных компаниях (например, в таких стартапах как Google и Yandex )
Ну а если говорить про ЯП, какие лучше, то выскажу свою скромную точку зрения:
— perl — нечитабельный и способствует к тому чтобы программист писал нечитабельные скрипты;
— ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности;
— php — даже разговоров быть не может, странно что вообще его кто-то использует;
— bash — слишком ограниченный, и тоже не особо читабельный;
— javascript — слишком убоговатый и малофункциональный;
— vbscript — это basic, так что тут говорить не о чем;
— powershell — тока винда и дотнет, мне лично не подходит, ибо винду давно уже не наблюдал в обозримом пространстве;
— python — есть свои недостатки, но несомненный лидер на фоне остальных.
То, что mod_python не предоставляют какие-то там провайдеры, уже давно не проблема — сейчас выделенный хостинг стоит копейки, ну и не говоря о Google Web Apps, где тоже можно размещать свои приложения (как раз GWA практически аналог Django, и юзает его подсистемы). Ну и конечно, можно прикрутить fastcgi или fcgid на shared хостингах.
Здравствуйте, Nuald, Вы писали:
N>Ну а если говорить про ЯП, какие лучше, то выскажу свою скромную точку зрения:
[...] N> — ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности;
много кода на руби видели?
N> — javascript — слишком убоговатый и малофункциональный;
в чем "убоговатый"? какой функциональности не хватает?
вопрос на засыпку: какая парадигма у js?
Здравствуйте, Гест, Вы писали:
N>> — ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности; Г>много кода на руби видели?
Это вообще к чему? Код на руби конечно я видел, и плохой и хороший, как и на всех языках программирования. Я говорю про то, что руби позволяет делать довольно-таки опасные вещи, и некоторые "эстеты" от программирования могут так исковеркать встроенный синтаксис, переопределив все что можно, что потом код станет невозможно читать.
N>> — javascript — слишком убоговатый и малофункциональный; Г>в чем "убоговатый"? какой функциональности не хватает?
Работы с файлами и базами данных
Г>вопрос на засыпку: какая парадигма у js?
Здравствуйте, Nuald, Вы писали:
N>>> — javascript — слишком убоговатый и малофункциональный; Г>>в чем "убоговатый"? какой функциональности не хватает? N>Работы с файлами и базами данных
А какой из выше перечисленных имеет встроенную функциональность работы с БД? Зачем скрипту в браузере уметь работать с файлами?
Здравствуйте, Nuald, Вы писали:
N>Ну а если говорить про ЯП, какие лучше, то выскажу свою скромную точку зрения: N> — perl — нечитабельный и способствует к тому чтобы программист писал нечитабельные скрипты; N> — ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности;
Это проблемы программиста, а не языка.
N> — php — даже разговоров быть не может, странно что вообще его кто-то использует;
Низкий порог вхождения.
N> — python — есть свои недостатки, но несомненный лидер на фоне остальных.
Здравствуйте, anonymous, Вы писали:
N>> — perl — нечитабельный и способствует к тому чтобы программист писал нечитабельные скрипты; N>> — ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности;
A>Это проблемы программиста, а не языка.
Если нечитабельность и вольность отрицательно сказываются на популярности языка, то это именно его проблема, а не тех, кто его не использует.
Здравствуйте, anonymous, Вы писали:
N>>>> — javascript — слишком убоговатый и малофункциональный; Г>>>в чем "убоговатый"? какой функциональности не хватает? N>>Работы с файлами и базами данных
A>А какой из выше перечисленных имеет встроенную функциональность работы с БД? Зачем скрипту в браузере уметь работать с файлами?
Никто не говорит о браузерах. Просто был вопрос какой из динамических языков лучше, и я не мог пропустить javascript, т.к. он все-таки является динамическим языком, используемым программистами. Конечно, как динамический язык общего назначения он не подходит, т.к. работает только внутри песочницы браузера, и по умолчанию не имеет доступа к внешним ресурсам.
Здравствуйте, anonymous, Вы писали:
N>> — perl — нечитабельный и способствует к тому чтобы программист писал нечитабельные скрипты; N>> — ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности;
A>Это проблемы программиста, а не языка.
Если бы все программисты были бы идеальными, тогда даже разговора бы не было. В реальных условиях чем больше язык и стандарты кодирования ограничивают программиста, тем обычно получается лучше, т.к. код прежде всего создается для людей, а не для машин. Конечно, имеются в виду промышленное программирование в командах, писать для себя на один раз — это совершенно другая тема.
N>> — php — даже разговоров быть не может, странно что вообще его кто-то использует;
A>Низкий порог вхождения.
И что? Из этого следует что он лучше? В Basic тоже низкий порог вхождения — это автоматом делает его лучшим?
N>> — python — есть свои недостатки, но несомненный лидер на фоне остальных.
A>Из чего это следует?
Был поставлен вопрос "что лучше?" Я на него ответил — конечно, со своей колокольни, и претендовать ни на что не хочу.
Здравствуйте, Nuald, Вы писали:
N>>>>> — javascript — слишком убоговатый и малофункциональный; Г>>>>в чем "убоговатый"? какой функциональности не хватает? N>>>Работы с файлами и базами данных A>>А какой из выше перечисленных имеет встроенную функциональность работы с БД? Зачем скрипту в браузере уметь работать с файлами? N>Никто не говорит о браузерах. Просто был вопрос какой из динамических языков лучше, и я не мог пропустить javascript, т.к. он все-таки является динамическим языком, используемым программистами. Конечно, как динамический язык общего назначения он не подходит, т.к. работает только внутри песочницы браузера, и по умолчанию не имеет доступа к внешним ресурсам.
В WSH используется JavaScript, а это далеко не браузер. Да и в браузерах через COM JavaScript умеет работать и с БД, и с ФС.
Здравствуйте, VoidEx, Вы писали:
N>>> — perl — нечитабельный и способствует к тому чтобы программист писал нечитабельные скрипты; N>>> — ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности; A>>Это проблемы программиста, а не языка. VE>Если нечитабельность и вольность отрицательно сказываются на популярности языка, то это именно его проблема, а не тех, кто его не использует.
Всё сложное непопулярно, вот PHP простой, рекомендую.
Здравствуйте, anonymous, Вы писали:
N>>Никто не говорит о браузерах. Просто был вопрос какой из динамических языков лучше, и я не мог пропустить javascript, т.к. он все-таки является динамическим языком, используемым программистами. Конечно, как динамический язык общего назначения он не подходит, т.к. работает только внутри песочницы браузера, и по умолчанию не имеет доступа к внешним ресурсам.
A>В WSH используется JavaScript, а это далеко не браузер. Да и в браузерах через COM JavaScript умеет работать и с БД, и с ФС.
Угумс, знаю, поэтому и написал, что по умолчанию (выделил жирным). А вы пробовали отлаживать WSH? Да я бы и не сказал, что с COM удобно работать, особенно если нужны нетривиальные вещи. И вообще, мне WSH как-то побоку, а всем его использующим, если уж застряли на винде, мог бы только посоветать юзать powershell — в принципе, мне кажется, и в Microsoft так думают, иначе бы не делали новый скриптовый язык.
A>[r'% r',][~0] % {(): '''^''' uR'|' in 2**2*__name__[::-8//(lambda _:~_)(3 or 2)]*2}<2>3j,(`3`) is ([])
A>
A>Да-да, это Python. Вердикт: "нечитабельный и способствует тому, чтобы программист писал нечитабельные скрипты".
Я и не говорил, что он идеален. А нечитабельный код при старании можно написать на любом языке программирования. Ну и конечно, не буду говорить, что вышеприведенный код высосан из пальца и смысла не имеет, и такой код нормальные программисты не пишут — ибо это фактически объявление кортежа (False, False). А вот для того же Perl-а, конструкции c использование $_, @_, <>, \$ и т.п. вполне в порядке вещей, и без бутылки чая иногда в коде не разберешься (хотя и не буду спорить, что иногда пишут и достойный код, но это обычно исключение).
N>>>> — php — даже разговоров быть не может, странно что вообще его кто-то использует; A>>>Низкий порог вхождения. N>>И что? Из этого следует что он лучше? В Basic тоже низкий порог вхождения — это автоматом делает его лучшим?
A>Это был ответ на вопрос о его популярности.
А, ну это да. Это же и объясняет популярность бейсика, не лучшего, но очень популярного ЯП.
Здравствуйте, anonymous, Вы писали:
VE>>Если нечитабельность и вольность отрицательно сказываются на популярности языка, то это именно его проблема, а не тех, кто его не использует.
A>Всё сложное непопулярно, вот PHP простой, рекомендую.
Python сложный?? Ой, умоляю — не надо смешить мои тапочки
Если не углублять в метапрограммирование, всякого рода list comprehensions, декораторы и остальные фичи, то программировать на нем легко и просто (если конечно, привыкнешь к отступам).
Вот то, что он не такой популярный — это другой вопрос. ИМХО, вижу две основные причины:
— нет хорошего встроенного GUI-фреймворка (tk все-таки не то);
— нет настолько же простой схемы деплоймента на веб-серверах как в том же PHP.
Но с другой стороны, только PHP имеет такую простую схему деплоймента, за что его и обожают всякого рода хакеры — залил через дырку на сайте какой-нить шелл и хакаешь себе дальше сайт в свое удовольствие Так что за удобным деплойментом скрываются всякого рода security vulnerabilities.
А про GUI — это вообще отдельная песня. Я, например, использую у себя PyGtk, и уже запарился собираться инсталляки под винду — Gtk за собой столько всего тянет Потом может посмотрю на PyQT, но пока нет надобности.
A>>[r'% r',][~0] % {(): '''^''' uR'|' in 2**2*__name__[::-8//(lambda _:~_)(3 or 2)]*2}<2>3j,(`3`) is ([])
A>>
A>>Да-да, это Python. Вердикт: "нечитабельный и способствует тому, чтобы программист писал нечитабельные скрипты". N>Я и не говорил, что он идеален. А нечитабельный код при старании можно написать на любом языке программирования. Ну и конечно, не буду говорить, что вышеприведенный код высосан из пальца и смысла не имеет, и такой код нормальные программисты не пишут — ибо это фактически объявление кортежа (False, False).
Вообще да, код придуман специально. Но ведь можно писать так, а можно так не писать. С Perl то же самое.
N>А вот для того же Perl-а, конструкции c использование $_, @_, <>, \$ и т.п. вполне в порядке вещей, и без бутылки чая иногда в коде не разберешься (хотя и не буду спорить, что иногда пишут и достойный код, но это обычно исключение).
Perl нужно уметь готовить, и употреблять его тоже нужно уметь. Трудности чтения говорят о том, что недостаточно практики, а не о том, что язык нечитаемый. (Если конечно не касаться кода, специально сделанного нечитаемым.)
Перечисленные выше конструкции скорее можно отнести к синтаксическому сахару. Трудность их чтения проистекает исключительно из отсутствия аналогов в других распростанённых языках.
Здравствуйте, Nuald, Вы писали:
N>>>Никто не говорит о браузерах. Просто был вопрос какой из динамических языков лучше, и я не мог пропустить javascript, т.к. он все-таки является динамическим языком, используемым программистами. Конечно, как динамический язык общего назначения он не подходит, т.к. работает только внутри песочницы браузера, и по умолчанию не имеет доступа к внешним ресурсам. A>>В WSH используется JavaScript, а это далеко не браузер. Да и в браузерах через COM JavaScript умеет работать и с БД, и с ФС. N>Угумс, знаю, поэтому и написал, что по умолчанию (выделил жирным).
А по умолчанию в браузере и не нужна ФС, и БД не нужна. А там, где нужны, все необходимые интерфейсы присутствуют.
N>А вы пробовали отлаживать WSH? Да я бы и не сказал, что с COM удобно работать, особенно если нужны нетривиальные вещи. И вообще, мне WSH как-то побоку, а всем его использующим, если уж застряли на винде, мог бы только посоветать юзать powershell — в принципе, мне кажется, и в Microsoft так думают, иначе бы не делали новый скриптовый язык.
Да, я на WSH даже утилиты писал. Ничего так, немного практики и отладка идёт.
Здравствуйте, Nuald, Вы писали:
VE>>>Если нечитабельность и вольность отрицательно сказываются на популярности языка, то это именно его проблема, а не тех, кто его не использует. A>>Всё сложное непопулярно, вот PHP простой, рекомендую. N>Python сложный?? Ой, умоляю — не надо смешить мои тапочки
Вообще мы Perl обсуждали.
N>Если не углублять в метапрограммирование, всякого рода list comprehensions, декораторы и остальные фичи, то программировать на нем легко и просто (если конечно, привыкнешь к отступам).
Если не использовать регулярные выражения, встроенные переменные и прочие фичи, то Perl вполне читаемый и не сложный. Имеет ли смысл тогда сравнивать языки без этих фич?
Здравствуйте, anonymous, Вы писали:
N>>Если не углублять в метапрограммирование, всякого рода list comprehensions, декораторы и остальные фичи, то программировать на нем легко и просто (если конечно, привыкнешь к отступам).
A>Если не использовать регулярные выражения, встроенные переменные и прочие фичи, то Perl вполне читаемый и не сложный. Имеет ли смысл тогда сравнивать языки без этих фич?
А никто и не сравнивает. Я имел в виду, что Python достаточно простой, и можно его использовать даже не зная всяких мудреных фич. А в Perl-е даже функцию с параметрами нельзя использовать не зная о существовании @_.
Здравствуйте, Nuald, Вы писали:
N>>>Если не углублять в метапрограммирование, всякого рода list comprehensions, декораторы и остальные фичи, то программировать на нем легко и просто (если конечно, привыкнешь к отступам). A>>Если не использовать регулярные выражения, встроенные переменные и прочие фичи, то Perl вполне читаемый и не сложный. Имеет ли смысл тогда сравнивать языки без этих фич? N>А никто и не сравнивает. Я имел в виду, что Python достаточно простой, и можно его использовать даже не зная всяких мудреных фич. А в Perl-е даже функцию с параметрами нельзя использовать не зная о существовании @_.
Ну да, а в Python нельзя функцию с параметрами использовать, не зная, что такое аргументы. Можно ли из этого сделать вывод, что плохо всё непривычное Вам?
Здравствуйте, anonymous, Вы писали:
A>В JavaScript нет классов вообще, это прототип-ориентированный язык, а не класс-ориентированный. Видимо, именно об этом Вас спрашивал Гест в сообщении выше. Вообще, понимание используемой в JavaScript парадигмы ООП — основы понимания этого языка. Отсюда можно сделать вывод, что с JavaScript Вы знакомы только понаслышке и, в общем-то, не можете судить о его слабых и сильных сторонах.
Ну если использование во всю jQuery можно назвать "знакомством понаслышке", тогда я умываю руки. И из того, что javascript является прототип-ориентированным языком, автоматически не следует, что он чем-то лучше других. Для эстетов — может да, для мейнстрима — скорее нет. Конечно, есть всякие фреймворки, типа того же jQuery, которые облегчают написание скриптов, но ведь не зря Google разработала GWT — значит не все так гладко со яваскриптом, если им проще писать на чистой Java, а потом транслировать код в JS.
Здравствуйте, anonymous, Вы писали:
A>Ну да, а в Python нельзя функцию с параметрами использовать, не зная, что такое аргументы. Можно ли из этого сделать вывод, что плохо всё непривычное Вам?
В принципе да — большую часть времени код читается, а не пишится, и если мне синтаксис непривычен, или не хочется держать в голове какие умолчания предполагает данный ЯП, то я автоматом считаю такой код малочитабельным. Вот такой я старый маразматик И думаю, со мной согласятся многие team leader-ы или PM-ы, которым приходится делать codereview большого количества кода. Что ни говори, питоновский синтаксис ближе к естественному языку, чем того же Perl-а. И опять-таки не буду утверждать, что Python — серебряная пуля, в нем много недостатков, просто из того разнообразия, с которым я работал, он мне большего всего по душе.
Здравствуйте, anonymous, Вы писали:
A>Всё сложное непопулярно, вот PHP простой, рекомендую.
Очевидно, сложность является недостатком. Хотя я не согласен, что сложное непопулярно. От PHP воздержусь, спасибо.
Здравствуйте, Nuald, Вы писали:
N>Вроде бы все просто, и нормально читается. Но если писать (или читать) на Perl-е достаточно редко, то сразу в этот код и не вникнуть. А ведь это еще хороший пример.
Если долго не писать на любом языке, потом трудно его читать.
N>И такое я вижу сплошь и рядом — Perl способствует к тому, что код получается не особо многословный, и надо иметь большую силу духа, чтобы заставить себя не пользоваться возможностями по умолчанию.
Ну вот мы и пришли к тому, что всё зависит от программиста, а не от языка.
A>>Перечисленные выше конструкции скорее можно отнести к синтаксическому сахару. Трудность их чтения проистекает исключительно из отсутствия аналогов в других распростанённых языках. N>Не спорю, но нужны ли такие аналоги большинству? Сильно сомневаюсь, что для обычного программиста читать конструкцию if (-d) будет проще чем if (os.path.isdir(directory_name)) — особенно если ты не гуру перла (а во втором случае даже не надо знать питон, чтобы догадаться о чем речь).
Большинство вообще программировать не умеет.
Про -X достаточно знать, что эти операторы предназначены для тестирования файлов, а то, что "d" значит "directory", по-моему достаточно очевидно. Но это опять же синтаксический сахар. В Python, к примеру, вообще нет подобного, os.path.isdir это уже библиотеки, для Perl тоже есть библиотека с "простым" синтаксисом.
Здравствуйте, Nuald, Вы писали:
N>Что ни говори, питоновский синтаксис ближе к естественному языку, чем того же Perl-а.
Вы удивитесь, но Perl был создан профессиональным лингвистом. И сложность его синтаксиса как раз и проистекает из того, что он более похож на естественные языки, чем другие языки программирования.
Здравствуйте, Nuald, Вы писали:
N>Python сложный?? Ой, умоляю — не надо смешить мои тапочки N>Если не углублять в метапрограммирование, всякого рода list comprehensions, декораторы и остальные фичи, то программировать на нем легко и просто (если конечно, привыкнешь к отступам). N>Вот то, что он не такой популярный — это другой вопрос. ИМХО, вижу две основные причины:
Меня вот именно отступы больше всего отпугнули от изучения Питона. Подозреваю, что я не один такой, так что это может быть одна из основных причин его относительно небольшой популярности. В этом смысле Руби заметно привлекательней, но у него есть большой недостаток — фиговые реализации (скорость, память).
Здравствуйте, Nuald, Вы писали:
N>Здравствуйте, Гест, Вы писали:
N>>> — ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности; Г>>много кода на руби видели?
N>Это вообще к чему? Код на руби конечно я видел, и плохой и хороший, как и на всех языках программирования. Я говорю про то, что руби позволяет делать довольно-таки опасные вещи, и некоторые "эстеты" от программирования могут так исковеркать встроенный синтаксис, переопределив все что можно, что потом код станет невозможно читать.
Это к тому, что краткое заявление в контексте "ruby — позволяет слишком много вольностей, что в итоге опять-таки может привести к нечитабельности" ===> "python — есть свои недостатки, но несомненный лидер на фоне остальных" может претендовать на обоснование личного выбора (да и то, достаточно слабенькое), но не на более-менее общее суждение. Например, мне (основной инструмент как раз Руби) открытые классы кажутся одной из очень полезных и приятных фич. И тем не менее, я не готов заявить "язык ХХХ — нет открытых классов — в топку".
Вы сейчас, конечно же, станете ссылаться на фразу "выскажу свою скромную точку зрения", но она очевидно не оправдывает поверхностность вашего анализа.
Я в данном случае защищаю не Руби или JS, а более внимательное отношение к анализу и бережное — к фактам, простите уж за занудство.
Здравствуйте, Nuald, Вы писали:
A>>Perl нужно уметь готовить, и употреблять его тоже нужно уметь. Трудности чтения говорят о том, что недостаточно практики, а не о том, что язык нечитаемый. (Если конечно не касаться кода, специально сделанного нечитаемым.)
N>Вот часть моего кода, который натравливает Perl::Critic на все скрипты в каталогах и подкаталогах (соотвественно, сам скрипт тоже проходит валидацию Perl::Critic, т.е. считается анализатором достаточно качественным):
N>
N>my @folders;
N>foreach (@both) {
N> next if /^(\.|\.\.)$/;
N> if (-d) {
N> push(@folders, $_);
N> } else {
N> push(@all, $_) if /.+\.(pl|cgi|pm)$/;
N> }
N>}
N>
N>Вроде бы все просто, и нормально читается. Но если писать (или читать) на Perl-е достаточно редко, то сразу в этот код и не вникнуть. А ведь это еще хороший пример. И такое я вижу сплошь и рядом — Perl способствует к тому, что код получается не особо многословный, и надо иметь большую силу духа, чтобы заставить себя не пользоваться возможностями по умолчанию.
Это, в общем-то, достаточно специфический аргумент. Честно говоря, из более-менее распространенных языков я не могу читать Haskell и с ОГРОМНЫМ трудом читаю Python — в основном, из-за особенностей реализации ООП — которую я примерно представляю, но приличную ментальную модель составить не могу. В этом смысле, несколько специфичное именование переменных/аргументов из Perl для "забарывания" требует лишь справочника — в смысле "ментальной модели" здесь никаких проблем нету.
Здравствуйте, anonymous, Вы писали:
A>Вы удивитесь, но Perl был создан профессиональным лингвистом. И сложность его синтаксиса как раз и проистекает из того, что он более похож на естественные языки, чем другие языки программирования.
Регулярная грамматика регексов больше похожа на естественные языки, нежели LL/LR грамматики?
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
A>>Вы удивитесь, но Perl был создан профессиональным лингвистом. И сложность его синтаксиса как раз и проистекает из того, что он более похож на естественные языки, чем другие языки программирования. AVK>Регулярная грамматика регексов больше похожа на естественные языки, нежели LL/LR грамматики?
Регулярные выражения придумали до Perl, да и в Perl реализация от Генри Спенсера, а не от Ларри Уолла. Так что они вошли в язык как есть. А под похожестью на естественный язык понимались такие вещи, как постфиксные варианты условных операторов, например.
Здравствуйте, D. Mon, Вы писали:
DM>Меня вот именно отступы больше всего отпугнули от изучения Питона. Подозреваю, что я не один такой, так что это может быть одна из основных причин
Да что вы все так боитесь отступов?
В любом нормальной уважающей себя компании есть стандарты кодирования, которые так или иначе тоже декларируют всякого рода отступы. В любом случае их приходится соблюдать, так в чем проблема соблюдать их в языке, который жестко заставляет это делать, а не через следование стандартам?
Здравствуйте, AndrewVK, Вы писали:
N>>Gtk за собой столько всего тянет
AVK>Сколько? Под винду, емнип, десяток dll'ек, не требующих специальной инсталляции.
Не только — надо еще тянуть локализацию, темы и какие-то конфиги. Если просто положить dll-ки около приложения, то оно не будет выглядеть кошерно, и не будет полностью локализировано.
Здравствуйте, D. Mon, Вы писали:
DM>Это чисто психологический момент, какая-то подсознательная боязнь, что незаметно для глаза перепутаются пробелы и табы, в результате я буду видеть одно, а компилятор — другое.
Если соблюдать правило не использовать табы, то проблем от оступов нет. Во всяком случае у меня за несколько лет плотной работы с питоном было всего один раз и именно из-за табов.
Здравствуйте, anonymous, Вы писали:
A>Регулярные выражения придумали до Perl
Пофик. Главное — автор Перла выбрал их в качестве ключевой особенности языка, и ряд синтаксических конструкций Перла явно испирирован регексами. Наконец, имхо, наибольшие притензии к синтаксису вызывают именно регескы и регексоподобные конструкции.
Вобщем, ИМХО, Перл уверенно держит серебро (золото за брейнфаком) по неестественности синтаксиса.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
A>>Регулярные выражения придумали до Perl AVK>Пофик. Главное — автор Перла выбрал их в качестве ключевой особенности языка,
Так язык был предназначен изначально для обработки текстовых данных.
AVK>и ряд синтаксических конструкций Перла явно испирирован регексами.
Каких?
AVK>Наконец, имхо, наибольшие притензии к синтаксису вызывают именно регескы и регексоподобные конструкции.
Какие?
AVK>Вобщем, ИМХО, Перл уверенно держит серебро (золото за брейнфаком) по неестественности синтаксиса.
Почему не золото? Синтаксис Perl даже с помощью БНФ нельзя описать.
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Сергей, Вы писали:
A>>>Вы удивитесь, но Perl был создан профессиональным лингвистом. С>>Я удивился, да. Пруфлинк в студию.
A>Ларри Уолл.
Вроде там написано, что он лингвист по образованию. Плюс нигде не написано, что он эти навыки при создании как-то использовал. Так что это так, просто факт из жизни, к перлу не имеющий скорее всего никакого отношения.
Здравствуйте, AndrewVK, Вы писали:
A>>Так язык был предназначен изначально для обработки текстовых данных. AVK>Пофик
Конструктивно, да.
AVK>>>и ряд синтаксических конструкций Перла явно испирирован регексами. A>>Каких? AVK>Например, указание типа при помощи односимвольного префикса, всякие @_ и $_.
Сигилы (односимвольные префиксы) — наследие командных оболочек, а встроенные переменные просто получили как можно более короткие имена. К регулярным выражениям это отношения не имеет.
Сигилы позволяют иметь переменные разных типов с одинаковыми именами. Вот что Дамиан Конвей говорит о сигилах (к вопросу о естественности языка):
В Perl это было с самых ранних времен, и с этим всегда была проблема. Проблема была в том, что это как формы слов в грамматике: если у меня есть массив, то я записываю перед его именем @, и это примерно то же, что сказать: «эти вещи». Но когда нужно сказать об одной из них, вы говорите: «эта вещь», вы не можете сказать «эти вещь». Так, в Perl 5, что вы делали, чтобы сослаться на один элемент массива, так это меняли сигил. Вы меняли его с символа @, который означает «эти», на символ доллара, который означает «этот». И тогда вы добавляете квадратные скобки, чтобы указать, какой нужен индекс. С лингвистической точки зрения это очень остроумная идея, и она дает возможность ввести тонкие различия в поведении. Но на деле выходит, что девяносто процентов программирующего населения просто не может понять такую идею. И это не оттого, что они тупые. Просто это не их естественный ход мысли. Естественный ход мысли в отношении сигилов такой: если тут доллар, то это скаляр; если массив, то должен быть знак @; если тут знак процента, то это должен быть хеш. И проблема смены сигила для другого использования слова в том, что это сбивает людей с толку, особенно англоговорящих — нам это не очень хорошо дается.
В других языках гораздо сильнее проявляется смена формы, когда меняется то, как используется слово, не то что в английском. Таким образом, мы обнаружили, что множество пользователей просто не могут иметь дело с «Ой! Вы должны изменить сигил, даже если это та же самая переменная».
Поэтому в Perl 6 использование сигилов будет изменено, на более ожидаемое программистами.
А встроенные переменные имеют мнемоники: $_, @_ — подчёркивание используемого операнда, $@ — в каком месте (at) была ошибка, и т. п.
Здравствуйте, VoidEx, Вы писали:
VE>Вроде там написано, что он лингвист по образованию. Плюс нигде не написано, что он эти навыки при создании как-то использовал. Так что это так, просто факт из жизни, к перлу не имеющий скорее всего никакого отношения.
Возможно, главная заслуга Ларри как автора Perl заключается в том, что ему удалось создать язык, учитывающий свойства и принципы естественного языка: ситуативную многозначность конструкций, разумную избыточность (и за счет этого стилевое разнообразие), максимальную адаптированность к различному уровню знаний носителей языка, гибкость и выразительность синтаксических средств. [...] При разработке языка Perl были использованы многие лингвистические принципы. Перечислим наиболее важные из них.
Важное значение имеет принцип повторного использования. Человеческие языки тяготеют к использованию ограниченного набора конструкций для выражения разных значений и их повторному применению в различных контекстах. В соответствии с этим принципом, в Perl одни и те же конструкции языка имеют различный смысл, а их однозначное понимание определяется контекстом использования.
Принцип контекста тесно связан с предыдущим. Контекст используется в естественных языках для правильной интерпретации смысла выражения. Подчиняясь этому принципу, в языке Perl, например, многие функции возвращают одно значение или список в зависимости от контекста вызова: требует ли синтаксис выражения единичного или множественного значения.
Принцип смыслового подчеркивания в естественных языках служит для привлечения внимания к важной части высказывания. При этом выделяемая часть обычно ставится в начало предложения. В Perl программист может воспользоваться этим принципом для акцентирования смысла, выбрав простое предложение с модификатором или условную конструкцию. [...]
Принцип свободы в естественных языках предполагает, что всегда есть несколько вариантов выражения одной и той же мысли. Как и в естественных языках, в Perl одного и того же результата можно достичь несколькими способами, используя различные выразительные средства языка. Это так называемый принцип TIMTOWTDI. В соответствии с ним каждый разработчик выбирает тот вариант языковой конструкции, который больше подходит ему в конкретной ситуации, больше соответствует его стилю или уровню знания языка.
Подобный подход полностью противоположен строго формальному взгляду на языки программирования, когда главными целями разработки становятся однозначность и минимизация языковых конструкций.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Nuald, Вы писали:
N>>Да что вы все так боитесь отступов?
DM>Это чисто психологический момент, какая-то подсознательная боязнь, что незаметно для глаза перепутаются пробелы и табы, в результате я буду видеть одно, а компилятор — другое.
Кстати, интерпретатор Руби 1.9 с недавних пор выдает предупреждение про неправильные отступы:
def meth1
if Time.now.hours > 12
puts "Afternoon"end
— я на таком много раз накалывался, перейдя с C++ — поскольку в С-подобных языках if с одним оператором в теле не требует "скобок", а в Руби — требует. Т.е. правильно:
def meth1
if Time.now.hours > 12
puts "Afternoon"end
end
Проблема этой ошибки в том, что парсер-то конечно заругается, но не там, где действительно пропущен end, а в самом конце файла (что-то end'ов маловато). Так вот в новых версиях он скажет "warning: mismatched indentations at 'end' with 'if' at 2".
В комментариях к блоговой записи, сообщающей об этом, слово "python" встречается чуть менее, чем в каждом
Ну, это просто удобная эвристика для для лучшего сообщения об ошибке. Сама ошибка тут допущена программистом и отлично видна глазу. Это совсем не то же, что возможность изменения поведения программы из-за того, что текстовый редактор где-то поменял пробелы и табы.
Здравствуйте, Wolverrum, Вы писали:
A>>Почему не золото? Синтаксис Perl даже с помощью БНФ нельзя описать. W>ЕЯ можно, а перловку уже и нельзя?!
perldoc perlfaq7:
Can I get a BNF/yacc/RE for the Perl language?
There is no BNF, but you can paw your way through the yacc grammar in
perly.y in the source distribution if you're particularly brave. The
grammar relies on very smart tokenizing code, so be prepared to venture
into toke.c as well.
In the words of Chaim Frenkel: "Perl's grammar can not be reduced to
BNF. The work of parsing perl is distributed between yacc, the lexer,
smoke and mirrors."
— "за" Руби стройное ООП и довольно широкие функциональные возможности (приводящие к "естественному" метапрограммированию); "против" — ужасы реализации. По категории "против" Питон точно лучше; а что там с категорией "за" — мне кажется, что Питон таки проигрывает. Если продемонстрируете обратное, это уже будет весомым вкладом в дискуссию.
Потом может посмотрю на PyQT, но пока нет надобности.
