К>В чём встретили проблемы с развёртыванием, если не секрет?
К>Принципы OTP для этого используются?
Честно говоря, первая трудность в том, что надо знать, что это за принципы. Я спрошу у нашего эрлангиста, какими принципами он руководствуется — может и OTP. Но когда вот он по какой-то причине недоступен, а мне надо поднять серваки и что-нить подкрутить в удаленной мнезии — то вот тут начинается... Вспомнить куку, запустить эрланг, пингануть ноду (вспомнить как называется), т.к. пока не пинганешь, оболочка мнезии не запустится... Вспомнить какой кракозяблой в консоли надо подцепиться к удаленному процессу и т.п.
Впрочем, по сравнению с бесконечным адом, которым является поддержка питоновых серваков — кто пытался поставить 2.5 и нужные пакеты на него на старую федору или центос, или кто убивал Arch установкой
того-же 2.5, или приводил debian stable в debian-необвновляющася-помойка-непонятно-из-каких-веток-собранная — тот поймет...
Идеал развертывания веб-приложения для меня — это скопировать бинарник (один!) в /usr/local/bin, конфиг — в /etc, скопировать конфиг в /etc/lighttpd/conf* — и все. И, в принципе, хаскелл и окамл подают надежды, что однажды все так и будет.
metalua видел? почитай metalua-manual.pdf в http://metalua.luaforge.net/metalua-0.4.1-rc1.tgz
наиболее ФП из всех скриптовых языков, с расширяемым синтаксисом
dmz>Основное, пожалуй — по моему, время, требуемое на разработку и поддержку юнит-тестов, без которых что-то делать на языках с динамической типизацией стрёмно, начиная с какого-то момента начисто сжирает все преимущество в скорости разработки. К тому же, с теми сроками, которые у нас бывают, у разработчиков есть соблазн вообще их не писать, или писать минимально, таким образом косяки, которые неизбежно возникают в динамических языках, имеют все шансы пролезть в продакшн. Что и случается.
конечно, каждый должен самостоятельно наступить на жэти грабли. мне нравился перл лет 10 назад, когда единственной алтернативой был С++, и скриптовые языки позвояли на порядок быстрее разрабатывать программы. но — только до определённого объёма. когда дело доходит до больших программных комплексов, то ты начинаешь люить строгую типизацию как мать родную особенно если она такая мощная, как в хаскеле. строгая типизация + вывод типов — это золотой стандарт, не надо выписывать ручками все эти витиеватые типы и в то же время не чуствуешь себя сидящим на пороховой бочке. 90% ошибок отсекаются на стадии компиляции программы
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Аноним, Вы писали:
C>>>Ну, если кто-то ещё не видел — сегодня вышел финальный релиз Python 3 (aka "Python 3000"). А>>GIL так и не убрали? Эх... C>Ага. Максимум что могу предложить — это http://docs.python.org/dev/library/multiprocessing.html
Я не думаю что GIL вобще когда либо починят. Для этого придется переписать пол интерпретатора. И плюс будет сомнительный ведь придется создавать по менаджеру памяти и GC на поток. Кроме того придется чтото делать с глобальными переменными. В общем даже не представляю как это победить в питоне.
Да и не особо страшен этот GIL. Например если ваш тред висит и ожидает предположим сокет, то замедления производительности не будет. В остальных случаях многопоточная программа будет выполняться как однопоточная, без замедления по крайней мере. Модуль multiprocessing нужен для тех случаев когда питон обрабатывает кучу данных и очень надо чтобы оно работало быстрее. Но если такая ситуация приключилась с вами, то скорее всего не верно выбран инструмент... на сишке такое писать надобно.
Кстати говоря интересно, что проблема GIL остро стоит только в питоне, больше нигде я такого не видел, хотя в тех же php и ruby тот же самый GIL.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>metalua видел? почитай metalua-manual.pdf в http://metalua.luaforge.net/metalua-0.4.1-rc1.tgz BZ>наиболее ФП из всех скриптовых языков, с расширяемым синтаксисом
Я готов поспорить, что "наиболее ФП из всех скриптовых языков, с расширяемым синтаксисом" — это Scheme
Применительно к вебу, конкретно — PLT Scheme.
Я люблю луа, но функциональный язык без списков — нонсенс
Автор металуа, кстати, писал:
Here's a remark for functional programmers: this API is very imperative; you might cringe at seeing the `Call nodes transformed in-place. Well, I tend to agree but it's generally counter-productive to work against the grain of the wood: Lua is imperative at heart, and design attempts at doing this functionally sucked more than approaches that embraced imperativeness.
Здравствуйте, Mamut, Вы писали:
M>Кстати, есть еще parse tools: http://www.erlang.org/doc/apps/parsetools/index.html Они, в теории, могут позволить написать парсер любого языка, грамматику которого можно записать в BNF
Здравствуйте, achmed, Вы писали:
FR>>Ну туплы в параметрах функций можно подставлять, плюс раскрытие кортежей (улучшенное в 3.0) в общем скорее в зачаточном состоянии. Ну и при желании на метаклассах и декораторах можно соорудить достаточно мощные вещи близкие к PM в функциональных языках — http://peak.telecommunity.com/PyProtocols.html
A>В PyProtocols не нашел ничего похожего на PM, плохо смотрел?
Parse transformations are used if a programmer wants to use Erlang syntax, but with different semantics. The original Erlang code is then transformed into other Erlang code.
Note
Programmers are strongly advised not to engage in parse transformations and no support is offered for problems encountered.
Здравствуйте, Critical Error, Вы писали:
C>>Без проблем всё работает. И по куче на поток не требуется, естественно (точнее, такая оптимизация может использоваться, но она нифига не обязательна). CE>А как???
Ну блин... Тут писать можно...
CE>На ум приходит только одно: менаджер памяти и GC защищен мьютексом.
Это как вариант. Ещё часто используют комбинированный способ — небольшие thread-local арены для мелких объектов и специальная куча для больших.
CE>Ну и чем это отличается от GIL???
Всем.
GIL захватывается на все инструкции. Т.е. у меня в Java если не происходит аллокация памяти, то потоки гарантированно будут спокойно работать параллельно на нескольких ядрах (если stop-the-world GC не активен, конечно). В Питоне захватывается GIL вообще для всех операций (кроме некоторых простейших арифметических).
CE>Разве что может быть несколько пулов обьектов и соответсвенно несколько мьютексов. Это оптимизация, но не большая... Может быть также что менаджер памяти глобальный, а вот GC какойнибудь хитро-локалный для треда. Хотя в принципе 2 мьютекса — это уже не GIL, а Half-IL
Там всё сложнее... Обычно используется generational GC, который позволяет минимизировать потери на него.
В общем, Питон тут в каменном веке по уровню развития.
Здравствуйте, Cyberax, Вы писали:
C>В Питоне захватывается GIL вообще для всех операций (кроме некоторых простейших арифметических).
Ого, если это действительно так, то все и правда очень плохо. Интересно зачем понадобилось лочить интерпретатор для каждой инструкции?...
C>В общем, Питон тут в каменном веке по уровню развития.
Да я говорю нужно переписывать его... Но задача эта трудна, я б не смог по крайней мере. Но язык сам по себе классный. Из всех существующих по моему мнению лучший в плане синтаксиса.
FR>Я с вебом (на сервере) дел практически не имел, но для десктопных приложений линкер заменяется одним дополнительным скриптом который все и собирает и если надо даже делает тестовую установку.
py2exe ? Не поручусь точно, но по-моему, на линуксе не его аналог давно забили. Плюс, питон предоставляет много средств, что бы прострелить себе голову, например динамическая загрузка.
Уф, я примерно знаю, как решать проблемы, которые возникают при развертывании питоновых приложений. В принципе, все способы уже перечислены в этом треде. Хочется сделать так, что бы решать их в принципе не приходилось. Естественно, это не единственное соображение, из-за которого с питона хочется съехать.
Конечно, на любую озвученную проблему найдется возражение. Нет средства автоматической линковки в некие бандлы? Можно сделать самим десятком способов.
Медленный (по сравнению) — а куда нам спешить, все равно все упрется в базу
Нет и не будет concurrency? Ну и что, все равно с одного сервера снимаем 1500 RPS, это 129600000 хитов в сутки, столько не бывает
Ну и так далее — могу написать еще десяток пунктов с контр-доводами.
Думаю, что в той команде, которая сложилась у нас, будет правильнее перейти на другие средства, учитывая специфику проектов.
Основное, пожалуй — по моему, время, требуемое на разработку и поддержку юнит-тестов, без которых что-то делать на языках с динамической типизацией стрёмно, начиная с какого-то момента начисто сжирает все преимущество в скорости разработки. К тому же, с теми сроками, которые у нас бывают, у разработчиков есть соблазн вообще их не писать, или писать минимально, таким образом косяки, которые неизбежно возникают в динамических языках, имеют все шансы пролезть в продакшн. Что и случается.
Здравствуйте, dmz, Вы писали:
dmz>Нет и не будет concurrency? Ну и что, все равно с одного сервера снимаем 1500 RPS, это 129600000 хитов в сутки, столько не бывает
Вот кстати очень интересный проект, привносящий новые фичи по поддержке конкурентности в питон: http://www.stackless.com/
Проект существует уже давно и используется в основном в играх, например в известной онлайновой игре EVE Online. Там сервер написан с применением stackless.
Здравствуйте, FR, Вы писали:
FR>Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.
по моим наблюдениям хаскел как раз очень хорош для описания сложных алгоритмов
Очередной пророк?
Скажи мне лучше, каким образом оно к Эрлангу относится?
Тем более ещё объектно-ориентированное к "традиционному" функциональному языку?
Класс. дождались таки. День сегодня неплохой, день рождения у товарища, пару новостей хороших с работы
Когда появится wxPython под него и Blender3d перенесут, тогда и попробую. Пока 2,5 продолжу юзать.
Здравствуйте, Аноним, Вы писали:
C>>Ну, если кто-то ещё не видел — сегодня вышел финальный релиз Python 3 (aka "Python 3000"). А>GIL так и не убрали? Эх...
Ага. Максимум что могу предложить — это http://docs.python.org/dev/library/multiprocessing.html
Здравствуйте, Critical Error, Вы писали:
CE>Я не думаю что GIL вобще когда либо починят. Для этого придется переписать пол интерпретатора. И плюс будет сомнительный ведь придется создавать по менаджеру памяти и GC на поток. Кроме того придется чтото делать с глобальными переменными. В общем даже не представляю как это победить в питоне.
Ну это, всё делается как в куче других языков с многопоточностью и GC.
CE>Да и не особо страшен этот GIL. Например если ваш тред висит и ожидает предположим сокет, то замедления производительности не будет. В остальных случаях многопоточная программа будет выполняться как однопоточная, без замедления по крайней мере. Модуль multiprocessing нужен для тех случаев когда питон обрабатывает кучу данных и очень надо чтобы оно работало быстрее. Но если такая ситуация приключилась с вами, то скорее всего не верно выбран инструмент... на сишке такое писать надобно.
Сейчас типа процессоры на 32 ядра будут в кофеварки ставить. Хотелось бы иметь реальную многопоточность.
CE>Кстати говоря интересно, что проблема GIL остро стоит только в питоне, больше нигде я такого не видел, хотя в тех же php и ruby тот же самый GIL.
Изначально добавили, а потом сил не хватило переписать.
Здравствуйте, Cyberax, Вы писали:
C>Ну это, всё делается как в куче других языков с многопоточностью и GC.
Я не спец, поэтому могу ошибаться, но единственный язык без проблемы с GIL — это erlang. И то по той лишь причине, что там нельзя созать тред ОС, хотя сейчас менаджер потоков VM erlang-а может создавать несколько тредов для выполнения на них легковесных процессов. Но даже там по менаджеру памяти и GC на поток ОС.
Есть еще правда куча "мелких" языков навроде lua. Там нельзя создавать треды из языка, но зато можно наплодить сколько угодно инстансов интерпретатора. Каждый естесственно со своей кучей и конечно изолирован от остальных инстансов. Вот в таких языках тоже нет проблемы GIL.
Здравствуйте, Critical Error, Вы писали:
C>>Ну это, всё делается как в куче других языков с многопоточностью и GC. CE>Я не спец, поэтому могу ошибаться, но единственный язык без проблемы с GIL — это erlang. И то по той лишь причине, что там нельзя созать тред ОС, хотя сейчас менаджер потоков VM erlang-а может создавать несколько тредов для выполнения на них легковесных процессов. Но даже там по менаджеру памяти и GC на поток ОС.
Вообще-то, без всяких проблем с потоками работает GC и в Java, .NET, Ruby и даже в старом добром С (Boehm GC)!
CE>Есть еще правда куча "мелких" языков навроде lua. Там нельзя создавать треды из языка, но зато можно наплодить сколько угодно инстансов интерпретатора. Каждый естесственно со своей кучей и конечно изолирован от остальных инстансов. Вот в таких языках тоже нет проблемы GIL. CE>А еще? java? .NET? Там как?
Без проблем всё работает. И по куче на поток не требуется, естественно (точнее, такая оптимизация может использоваться, но она нифига не обязательна).
Здравствуйте, Cyberax, Вы писали:
C>Вообще-то, без всяких проблем с потоками работает GC и в Java, .NET, Ruby и даже в старом добром С (Boehm GC)!
CE>>А еще? java? .NET? Там как? C>Без проблем всё работает. И по куче на поток не требуется, естественно (точнее, такая оптимизация может использоваться, но она нифига не обязательна).
А как??? На ум приходит только одно: менаджер памяти и GC защищен мьютексом. Ну и чем это отличается от GIL??? Разве что может быть несколько пулов обьектов и соответсвенно несколько мьютексов. Это оптимизация, но не большая... Может быть также что менаджер памяти глобальный, а вот GC какойнибудь хитро-локалный для треда. Хотя в принципе 2 мьютекса — это уже не GIL, а Half-IL
Здравствуйте, Critical Error, Вы писали:
C>>В Питоне захватывается GIL вообще для всех операций (кроме некоторых простейших арифметических). CE>Ого, если это действительно так, то все и правда очень плохо. Интересно зачем понадобилось лочить интерпретатор для каждой инструкции?...
Внутренности интерпретатора — не thread-safe. Скажем, там счётчики ссылок не thread-safe'ные, что когда-то давало неплохое ускорение.
C>>В общем, Питон тут в каменном веке по уровню развития. CE>Да я говорю нужно переписывать его... Но задача эта трудна, я б не смог по крайней мере. Но язык сам по себе классный. Из всех существующих по моему мнению лучший в плане синтаксиса.
JPython рулит
CE>Кстати говоря интересно, что проблема GIL остро стоит только в питоне, больше нигде я такого не видел, хотя в тех же php и ruby тот же самый GIL.
Скорее всего потому что питон в отличии от этих родственных языков, намного чаще используется как язык общего назначения, например на нем в отличии от них пишут и десктопные приложения.
В общем-то, я и раньше читал whatznew, но если резюмировать: второстепенной важности изменения синтаксиса, GIL остается (навечно), никаких подвижек в сторону concurrency (в то время, как космические корабли бороздят...) и и про развертывание хвостовой рекурсии не слышно.
Судя по списку, это все можно охарактеризовать скорее как рефакториг потрохов, т.е. сугубо внутреннее дело разработчиков, который, однако привел к несовместимостям; чем стало по сути лучше — я не вижу.
Предвижу также, что ветка 2.X развиваться не будет, или будет плохо.
Короче, мы переходить на 3.0 в новых проектах не будем, и вероятно, вообще не будем, по возможности, использовать питон в новых проектах — нет смысла.
CE>Я не думаю что GIL вобще когда либо починят. Для этого придется переписать пол интерпретатора. И плюс будет сомнительный ведь придется создавать по менаджеру памяти и GC на поток. Кроме того придется чтото делать с глобальными переменными. В общем даже не представляю как это победить в питоне.
В тикле потоки имеют свои собственные иерархии интерпретаторов. Нет одного основного.
В результате малое взаимодействие между потоками во время GC, отсутствие глобальных переменных и (!) если написанное на C(++) расширение умеет работать с несколькими интерпретаторами (хранит данные в ClientData указателе), то оно умеет работать и с несколькими потоками.
CE>Кстати говоря интересно, что проблема GIL остро стоит только в питоне, больше нигде я такого не видел, хотя в тех же php и ruby тот же самый GIL.
php живёт внутри apache, который делает fork. Поэтому там одна задача и один же интерпретатор, никаких потоков.
А вот AOLserver с тиклем внутри изначально был многопоточный.
Резюмируя: решения есть, давнишние, проверенные.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, dmz, Вы писали:
dmz>Короче, мы переходить на 3.0 в новых проектах не будем, и вероятно, вообще не будем, по возможности, использовать питон в новых проектах — нет смысла.
А какую технологию/язык вы предпочтете на место питона?
Здравствуйте, Daevaorn, Вы писали:
D>А какую технологию/язык вы предпочтете на место питона?
Scala?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[2]: Вышел релиз Python 3000!
От:
Аноним
Дата:
05.12.08 12:59
Оценка:
Здравствуйте, dmz, Вы писали:
dmz>В общем-то, я и раньше читал whatznew, но если резюмировать: второстепенной важности изменения синтаксиса, GIL остается (навечно), никаких подвижек в сторону concurrency (в то время, как космические корабли бороздят...) и и про развертывание хвостовой рекурсии не слышно.
Про хвостовую рекурсию, кстати, уже давно сказали -- "нету и не будет".
Здравствуйте, dmz, Вы писали:
dmz>В общем-то, я и раньше читал whatznew, но если резюмировать: второстепенной важности изменения синтаксиса, GIL остается (навечно), никаких подвижек в сторону concurrency (в то время, как космические корабли бороздят...) и и про развертывание хвостовой рекурсии не слышно.
Да меня в общем то тоже удивило и огорчило, что автор языка несколько отстал развития... 4х-ядерные процы уже давно появились как-никак. Да и фичи из ФП навроде оптимизации хвостовой рекурсии не повредили бы. Паттерн-матчинг довести до ума не помешало бы... Но видать не судьба.
dmz>Короче, мы переходить на 3.0 в новых проектах не будем, и вероятно, вообще не будем, по возможности, использовать питон в новых проектах — нет смысла.
Как мрачно! Вот отказываться от питона не есть гуд решение. Все же ничего лучше и удобнее не найдете (после питона любой язык покажется унылым и неудобным). Поступайте как все умные питонисты — пишите критичные по производительности куски приложений на С, благо C-API у питона отменное, да еще и CPP-API имеется, ну где вы еще такое найдете?
Здравствуйте, dmz, Вы писали:
dmz>В общем-то, я и раньше читал whatznew, но если резюмировать: второстепенной важности изменения синтаксиса, GIL остается (навечно), никаких подвижек в сторону concurrency (в то время, как космические корабли бороздят...) и и про развертывание хвостовой рекурсии не слышно.
dmz>Судя по списку, это все можно охарактеризовать скорее как рефакториг потрохов, т.е. сугубо внутреннее дело разработчиков, который, однако привел к несовместимостям; чем стало по сути лучше — я не вижу.
Угу согласен.
Но вообще под питон есть очень интересная штучка http://www.fiber-space.de/EasyExtend/doc/EE.html
В общем вводит в питон макросы типа немерловских, при желании можно наваять почти любой нужный
язычок.
dmz>Предвижу также, что ветка 2.X развиваться не будет, или будет плохо.
Да ну ближайшие несколько лет точно будет нормально развиватся, на ней очень даже немелкие конторы сидят.
dmz>>Придется сделать несколько прототипов, по результатам смотреть.
FR>С функциональщиной (если не под NET или Java) почти наверняка помешает FR>практически полное отсутствие библиотек по сравнению с питоном.
Насчет "полного" не согласен. Т.е. для тех областей, где мы что-то делаем — веб, сетевые приложения (не связанные с веб) и embedded — все необходимое есть везде, в том или ином виде. Более того, даже для питона пришлось собрать свой набор компонентов + glue, которые и таскаются из проекта в проект. Некоторые, причем, разработчики официально забросили — и нам пришлось саппортить и развивать их дальше самостоятельно. Так что большой разницы портировать наш багаж под Python 3000 или уже забить на питон и взять более правильную платформу — разница минимальная.
FR>Угу согласен. FR>Но вообще под питон есть очень интересная штучка http://www.fiber-space.de/EasyExtend/doc/EE.html FR>В общем вводит в питон макросы типа немерловских, при желании можно наваять почти любой нужный FR>язычок.
Так оно и для других языков есть такое; впрочем для erlang — не знаю, есть или нет.
dmz>Насчет "полного" не согласен. Т.е. для тех областей, где мы что-то делаем — веб, сетевые приложения (не связанные с веб) и embedded — все необходимое есть везде, в том или ином виде. Более того, даже для питона пришлось собрать свой набор компонентов + glue, которые и таскаются из проекта в проект. Некоторые, причем, разработчики официально забросили — и нам пришлось саппортить и развивать их дальше самостоятельно. Так что большой разницы портировать наш багаж под Python 3000 или уже забить на питон и взять более правильную платформу — разница минимальная.
Ну я когда к Ocaml'у присматривался то видел практически полное отсутствие . У Хаскеля вроде чуть получше но по сравнению с питоном тоже очень мало.
FR>Ну я когда к Ocaml'у присматривался то видел практически полное отсутствие . У Хаскеля вроде чуть получше но по сравнению с питоном тоже очень мало.
Ну тут надо смотреть не со стороны количества, а со стороны есть то, что нужно или нет. Как бы это сказать. Чем язык проще, тем больше под него пишут, но не все написанное, стоит того, что бы его гордо демонстрировать миру. Ну вот например, web-фреймворков под питон написана уйма. Но что — от этого стало кому-то легче? Пришлось, например, собрать свой, т.к. те, что есть для наших целей подходили очень слабо. А потом один из компонентов этого фреймворка официально умер, хотя был ничем не плох — так что приходится его самим саппортить.
Или вот, например, была такая тема, как поиск данных, которые возвращают POST-запросы. Ну, то, что гордо именуется deep web search. Под питон есть такая клевая штука, как BeautufulSoup — устойчивый к ошибкам HTML парсер. Не везде он есть, например, для эрланга ничего подобного нет и близко. Но вот выяснилась какая штука — при обобщении частного поиска по одному сайту до поиска по множеству сайтов — завязываться вообще ни на что, что имеет отношение к HTML нельзя — т.е. вообще никак. Дизайн сайтов плывет со временем, если у вас их сто — то еще можно как-то поддерживать, если 5'000 — то уже нет. Плюс значимая информация может тоже быть где угодно — в атрибутах тегов, например. И что получается — при переходе от ad-hoc алгоритмов к эвристикам — никакие библиотеки не нужны — т.е. надо обдирать HTML до голого текста, включать туда же значение атрибутов и javascript — и работать с текстовым потоком исключительно на уровне самих данных. А это можно элементарно сделать вообще на любом языке; причем чисто функциональные тут удобнее по ряду причин, в которые не буду вдаваться. Так вот, BeautifulSoup — без всякой иронии замечательный продукт который даже съэкономил много временени, но вот лучше бы он нам не попадался — тогда бы сразу пришлось все делать правильно.
По настоящему фундаментальных вещей, без которых плохо — не так-то много. Реализация алгоритмов и структур данных, GUI, коннекторы к базам... Т.е. то, чего не может не быть в серьезном языке.
Здравствуйте, Critical Error, Вы писали:
CE>Да меня в общем то тоже удивило и огорчило, что автор языка несколько отстал развития... 4х-ядерные процы уже давно появились как-никак. Да и фичи из ФП навроде оптимизации хвостовой рекурсии не повредили бы. Паттерн-матчинг довести до ума не помешало бы... Но видать не судьба.
FR>>Ну я когда к Ocaml'у присматривался то видел практически полное отсутствие . У Хаскеля вроде чуть получше но по сравнению с питоном тоже очень мало.
dmz>Ну тут надо смотреть не со стороны количества, а со стороны есть то, что нужно или нет. Как бы это сказать. Чем язык проще, тем больше под него пишут, но не все написанное, стоит того, что бы его гордо демонстрировать миру. Ну вот например, web-фреймворков под питон написана уйма. Но что — от этого стало кому-то легче? Пришлось, например, собрать свой, т.к. те, что есть для наших целей подходили очень слабо. А потом один из компонентов этого фреймворка официально умер, хотя был ничем не плох — так что приходится его самим саппортить.
Ну это не особенность питона, любой open source таким страдает.
dmz>Или вот, например, была такая тема, как поиск данных, которые возвращают POST-запросы. Ну, то, что гордо именуется deep web search. Под питон есть такая клевая штука, как BeautufulSoup — устойчивый к ошибкам HTML парсер. Не везде он есть, например, для эрланга ничего подобного нет и близко. Но вот выяснилась какая штука — при обобщении частного поиска по одному сайту до поиска по множеству сайтов — завязываться вообще ни на что, что имеет отношение к HTML нельзя — т.е. вообще никак. Дизайн сайтов плывет со временем, если у вас их сто — то еще можно как-то поддерживать, если 5'000 — то уже нет. Плюс значимая информация может тоже быть где угодно — в атрибутах тегов, например. И что получается — при переходе от ad-hoc алгоритмов к эвристикам — никакие библиотеки не нужны — т.е. надо обдирать HTML до голого текста, включать туда же значение атрибутов и javascript — и работать с текстовым потоком исключительно на уровне самих данных. А это можно элементарно сделать вообще на любом языке; причем чисто функциональные тут удобнее по ряду причин, в которые не буду вдаваться. Так вот, BeautifulSoup — без всякой иронии замечательный продукт который даже съэкономил много временени, но вот лучше бы он нам не попадался — тогда бы сразу пришлось все делать правильно.
Кстати занимался очень похожим, выдергиванием данных и трансформацией html, правда на C++ и тоже оказалось что самое лучшее свой парсер и свой DOM. Просто похоже специфичная область без готовых инструментов.
Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.
dmz>По настоящему фундаментальных вещей, без которых плохо — не так-то много. Реализация алгоритмов и структур данных, GUI, коннекторы к базам... Т.е. то, чего не может не быть в серьезном языке.
Угу и вот этих фундаментальных вещей в том же Ocaml'е и нету.
Здравствуйте, achmed, Вы писали:
A>А что, какой то паттерн-матчинг уже есть?
Ну туплы в параметрах функций можно подставлять, плюс раскрытие кортежей (улучшенное в 3.0) в общем скорее в зачаточном состоянии. Ну и при желании на метаклассах и декораторах можно соорудить достаточно мощные вещи близкие к PM в функциональных языках — http://peak.telecommunity.com/PyProtocols.html
dmz>>По настоящему фундаментальных вещей, без которых плохо — не так-то много. Реализация алгоритмов и структур данных, GUI, коннекторы к базам... Т.е. то, чего не может не быть в серьезном языке.
FR>Угу и вот этих фундаментальных вещей в том же Ocaml'е и нету.
FastCGI, SCGI, AJP коннекторы присутствуют как бы не в стандартной библиотеке.
Это даже не заходя на Hump. У хаскелла — дела обстоят еще лучше. Да и потом, если чего-то действительно не хватает — есть де эффективный интерфейс для нативных вызовов.
Впрочем, что конечный выбор будет на стороне ocaml — я не уверен.
Угу а потом начинаешь смотреть и все как ты выше описал вроде бы и есть но или не доделано или давно заброшенно
dmz>FastCGI, SCGI, AJP коннекторы присутствуют как бы не в стандартной библиотеке.
dmz>Это даже не заходя на Hump. У хаскелла — дела обстоят еще лучше. Да и потом, если чего-то действительно не хватает — есть де эффективный интерфейс для нативных вызовов.
Угу я тоже думаю если использовать без связки с C/C++ никак.
Для Ocaml'а вообще можно swig для этого использовать.
dmz>Впрочем, что конечный выбор будет на стороне ocaml — я не уверен.
dmz>>Впрочем, что конечный выбор будет на стороне ocaml — я не уверен.
FR>А какие еще кандидаты?
Ну, для нашей специфики подходят еще haskell и эрланг; правда есть мнение, что более-менее универсального решения не выйдет — т.е. придется использовать эрланг + что-то. На стороне эрланга его легкая изучаемость — т.е. перспективы его изучения новыми людьми в команде не вызывает особых сомнений; т.е. у нас на нем уже два проекта, написаны человеком, который увидел его в первый раз — однако уже через неделю на нем бодро писал, теперь вообще ничего кроме эрланга видеть не хочет. Минусы эрлангу — некоторая тормознутость, и скудость библиотек с перекосом в телеком, а так же достаточно сложное развертывание приложений на нем (но зато богатая инфраструктура, если приспособиться ее использовать).
По легкости изучения ocaml сложнее эрланга, но много проще хаскелла, так что боюсь выбора-то по сути и нет; плюс после питона очень радует скорость, с которой стартуют приложения на нем — причем, даже когда они скомпилированы в байткод, а не нативные; а так же чрезвычано радует такая вещь, как ocamlmktop.
dmz>>>Впрочем, что конечный выбор будет на стороне ocaml — я не уверен.
FR>>А какие еще кандидаты?
dmz>Ну, для нашей специфики подходят еще haskell и эрланг; правда есть мнение, что более-менее универсального решения не выйдет — т.е. придется использовать эрланг + что-то. На стороне эрланга его легкая изучаемость — т.е. перспективы его изучения новыми людьми в команде не вызывает особых сомнений; т.е. у нас на нем уже два проекта, написаны человеком, который увидел его в первый раз — однако уже через неделю на нем бодро писал, теперь вообще ничего кроме эрланга видеть не хочет. Минусы эрлангу — некоторая тормознутость, и скудость библиотек с перекосом в телеком, а так же достаточно сложное развертывание приложений на нем (но зато богатая инфраструктура, если приспособиться ее использовать).
В чём встретили проблемы с развёртыванием, если не секрет? Принципы OTP для этого используются?
К>>В чём встретили проблемы с развёртыванием, если не секрет?
К>>Принципы OTP для этого используются?
dmz>Честно говоря, первая трудность в том, что надо знать, что это за принципы. Я спрошу у нашего эрлангиста, какими принципами он руководствуется — может и OTP. Но когда вот он по какой-то причине недоступен, а мне надо поднять серваки и что-нить подкрутить в удаленной мнезии — то вот тут начинается... Вспомнить куку, запустить эрланг, пингануть ноду (вспомнить как называется), т.к. пока не пинганешь, оболочка мнезии не запустится... Вспомнить какой кракозяблой в консоли надо подцепиться к удаленному процессу и т.п.
Про принципы мы оф. доку переводили в своё время. Вся инфраструктура есть уже давно (приложения, релизы и т.п.)
Про куки и пинги — не проще иметь готовый скрипт?
dmz>Идеал развертывания веб-приложения для меня — это скопировать бинарник (один!) в /usr/local/bin, конфиг — в /etc, скопировать конфиг в /etc/lighttpd/conf* — и все. И, в принципе, хаскелл и окамл подают надежды, что однажды все так и будет.
Ну если простые приложения которые можно "холодно" рестартить, не использующие распределённость, то нормальный вариант.
С одиним бинарником фокус на эрланге не получится, скорее всего
Другое дело, что апдейтить можно без прерывания работы сервера, вопрос только нужно ли оно вам.
К>Про куки и пинги — не проще иметь готовый скрипт?
Оно надо пару-тройку раз в год. Да не то, что бы это прям большая проблема — но просто иногда вот напарываюсь. Ну и вообще — некоторые сложности есть. То, что надо читать про принципы OTP — уже проблема — когда все просто, то читать ничего не надо
К>Ну если простые приложения которые можно "холодно" рестартить, не использующие распределённость, то нормальный вариант.
Ну я не видел еще веб-приложения, которое прямо вот ни на полминуты не остановить. Это ж не процессинг платежей какой. Впрочем, если у нас кластер хотя бы из двух нод и балансировщика — то ничего не мешает менять приложение на каждой ноде по отдельности — одну ноду стопаем и обновляем, вторая работает.
К>Другое дело, что апдейтить можно без прерывания работы сервера, вопрос только нужно ли оно вам.
К>>Про куки и пинги — не проще иметь готовый скрипт?
dmz>Оно надо пару-тройку раз в год. Да не то, что бы это прям большая проблема — но просто иногда вот напарываюсь. Ну и вообще — некоторые сложности есть. То, что надо читать про принципы OTP — уже проблема — когда все просто, то читать ничего не надо
Ну дак просто исходные вещи разные, просто "налабать" приложение — это одно, а замутить приложение 24х7 с горячим обновлением, распределённостью и т.п. — это немного другое.
Если во втором случае ваять, не разобравшись, т.е. хотяб не заглянув в доки, то яб такое решение не рискнул бы использовать.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, achmed, Вы писали:
A>>А что, какой то паттерн-матчинг уже есть?
FR>Ну туплы в параметрах функций можно подставлять, плюс раскрытие кортежей (улучшенное в 3.0) в общем скорее в зачаточном состоянии. Ну и при желании на метаклассах и декораторах можно соорудить достаточно мощные вещи близкие к PM в функциональных языках — http://peak.telecommunity.com/PyProtocols.html
В PyProtocols не нашел ничего похожего на PM, плохо смотрел?
Здравствуйте, dmz, Вы писали:
dmz>Впрочем, по сравнению с бесконечным адом, которым является поддержка питоновых серваков — кто пытался поставить 2.5 и нужные пакеты на него на старую федору или центос, или кто убивал Arch установкой dmz>того-же 2.5, или приводил debian stable в debian-необвновляющася-помойка-непонятно-из-каких-веток-собранная — тот поймет...
Странный у тебя опыт... Питон вполне нормально встаёт параллельно с существующим, на Debian Etch версия 2.5 ставится без всяких проблем. Ну в крайнем случае скомпилить самому и запихать в /usr/local.
А дальше прописываешь Web-приложение в /etc/lighttpd/conf-*, и оно работает.
C>Странный у тебя опыт... Питон вполне нормально встаёт параллельно с существующим, на Debian Etch версия C>2.5 ставится без всяких проблем.
Ну на дебиане проблемы были, может не из самого питона, а из-за каких-то модулей — точно не помню. Пришлось прописать нестабильные репозитарии, и понеслось по зависимостям.
А вот федоре, центосе и arch проблемы были вполне неиллюзорные, особенно пострадал в свое время арч. Некоторое время проблем действительно нет, но только на дебиане и убунту.
C>Ну в крайнем случае скомпилить самому и запихать в /usr/local.
Ага. А еще лучше — собрать фейковое окружение, собрать там питон со всеми нужными пакетами, даром что они одни и те-же от проекта к проекту, и туда-же засунуть лайти до кучи. И запускать лайти из чрута. Работать будет — вообще везде, и ставиться парой кликов. Только лень.
C>А дальше прописываешь Web-приложение в /etc/lighttpd/conf-*, и оно работает.
Ну как бы я примерно знаю, что куда надо прописать — благо десяток питоновских проектов крутится, только вот бывают проблемы, особенно на всяких RH-образиях, которые почему-то очень любят провайдеры.
Здравствуйте, dmz, Вы писали:
C>>Странный у тебя опыт... Питон вполне нормально встаёт параллельно с существующим, на Debian Etch версия C>2.5 ставится без всяких проблем. dmz>Ну на дебиане проблемы были, может не из самого питона, а из-за каких-то модулей — точно не помню. Пришлось прописать нестабильные репозитарии, и понеслось по зависимостям.
Так кто мешал руками воткнуть нужные модули в /usr/local/lib/python? И в backport'ах их тоже не было?
dmz>А вот федоре, центосе и arch проблемы были вполне неиллюзорные, особенно пострадал в свое время арч. Некоторое время проблем действительно нет, но только на дебиане и убунту.
Вполне верю.
C>>Ну в крайнем случае скомпилить самому и запихать в /usr/local. dmz>Ага. А еще лучше — собрать фейковое окружение, собрать там питон со всеми нужными пакетами, даром что они одни и те-же от проекта к проекту, и туда-же засунуть лайти до кучи. И запускать лайти из чрута. Работать будет — вообще везде, и ставиться парой кликов. Только лень.
Ну для больших веб-приложений без проблем.
C>>А дальше прописываешь Web-приложение в /etc/lighttpd/conf-*, и оно работает. dmz>Ну как бы я примерно знаю, что куда надо прописать — благо десяток питоновских проектов крутится, только вот бывают проблемы, особенно на всяких RH-образиях, которые почему-то очень любят провайдеры.
Выбирай нормальных провайдеров На "enterprise" дистрибутивах обычно всё вообще очень древнее.
По опыту, Python-приложения у меня ставились проще всего. Следом идёт Ruby по удобству установки. Примерно на равных с ним — приложения на Java. А сложнее всего бороться с PHP.
Здравствуйте, Critical Error, Вы писали: CE>Да меня в общем то тоже удивило и огорчило, что автор языка несколько отстал развития
Угу. По-моему, Гвидо зарубил все полезные фичи с резолюцией "нет и не будет". До кучи даже анпакинг туплов выкинули (pep-3113 без слез читать невозможно)
Зато деловитым видом творится какая-то колбасня со списками-генераторами-представлениями, исключениями и прочий мелкий рефокторинг языка. А, ну да, ввели повсеместный юникод, что, в принципе, неплохо.
Здравствуйте, Mr.Cat, Вы писали:
MC>Угу. По-моему, Гвидо зарубил все полезные фичи с резолюцией "нет и не будет". До кучи даже анпакинг туплов выкинули (pep-3113 без слез читать невозможно)
Анпакинг тупл-параметров для вас полезная фича? О_о
C>Так кто мешал руками воткнуть нужные модули в /usr/local/lib/python? И в backport'ах их тоже не было?
Это был девелоперский сервер, и там я стараюсь делать так, что бы все нужные пакеты ставились apt-ом, причем, желательно, из репозитариев по умолчанию. Так что сюда же следует задать вопрос, почему мы не не собрали все пакеты с нужными версиями, не подняли свой репозитарий. Ну вот, не собрали. Это все требует времени и сил, ресурсов на это особо нет.
C>Ну для больших веб-приложений без проблем.
C>Выбирай нормальных провайдеров На "enterprise" дистрибутивах обычно всё вообще очень древнее.
Да как бы уже выбрали, называется collocation. Но почему-то некоторым клиентам хочется, что бы софт ставили на их серверы или к их провайдерам, и там выбирать особо не из чего.
C>По опыту, Python-приложения у меня ставились проще всего. Следом идёт Ruby по удобству установки. Примерно на равных с ним — приложения на Java. А сложнее всего бороться с PHP.
Ну а вот представь, что весь дистрибутив твоего приложения — это один бинарник и один конфиг, ну и секция конфига для веб-сервера, который используется как реверс-прокси. Можно даже сделать инсталлятор для любой платформы, причем это просто.
Здравствуйте, dmz, Вы писали:
dmz>Да как бы уже выбрали, называется collocation. Но почему-то некоторым клиентам хочется, что бы софт ставили на их серверы или к их провайдерам, и там выбирать особо не из чего.
Для таких клиентов можно сделать бандл, устанавливающийся в /opt.
dmz>Ну а вот представь, что весь дистрибутив твоего приложения — это один бинарник и один конфиг, ну и секция конфига для веб-сервера, который используется как реверс-прокси. Можно даже сделать инсталлятор для любой платформы, причем это просто.
Ну нафиг такое счастье. А если что-то поправить в нём нужно будет? Со скриптами всё просто.
И с зависимостями тоже что делать? Всё вкомпиливать статически?
C>Ну нафиг такое счастье. А если что-то поправить в нём нужно будет? Со скриптами всё просто.
Что значит "подправить" ? Подправлять ничего нельзя, можно только выпустить патч.
C>И с зависимостями тоже что делать? Всё вкомпиливать статически?
Если их не много, то по моему — лучший вариант. Причем, имея бинарник версии X, мы гарантируем, что он собран именно с теми библиотеками (и с теми патчами, что мы наложили, если вдруг), с которыми и у нас на стенде. Отдаем админу клиента бинарник — и он ничего не может сломать, даже если захочет.
В общем, с питоном все эти проблемы решается путем сборки своего бандла, да. Только вот что бы его сделать, надо приложить немало усилий. А так за тебя это делает линкер.
Здравствуйте, dmz, Вы писали:
C>>Ну нафиг такое счастье. А если что-то поправить в нём нужно будет? Со скриптами всё просто. dmz>Что значит "подправить" ? Подправлять ничего нельзя, можно только выпустить патч.
У меня объём приложения вместе с ресурсами — около 100Мб. Будем каждый раз новые 100Мб выкладывать? И вообще, как будем ресурсы отдавать — lighty использовать не получится, так как он только файлы понимает.
dmz>В общем, с питоном все эти проблемы решается путем сборки своего бандла, да. Только вот что бы его сделать, надо приложить немало усилий. А так за тебя это делает линкер.
Это только кажется...
Здравствуйте, dmz, Вы писали:
dmz>В общем, с питоном все эти проблемы решается путем сборки своего бандла, да. Только вот что бы его сделать, надо приложить немало усилий. А так за тебя это делает линкер.
Я с вебом (на сервере) дел практически не имел, но для десктопных приложений линкер заменяется одним дополнительным скриптом который все и собирает и если надо даже делает тестовую установку.
Здравствуйте, Mr.Cat, Вы писали:
MC>Угу. По-моему, Гвидо зарубил все полезные фичи с резолюцией "нет и не будет". До кучи даже анпакинг туплов выкинули (pep-3113 без слез читать невозможно) MC>Зато деловитым видом творится какая-то колбасня со списками-генераторами-представлениями, исключениями и прочий мелкий рефокторинг языка. А, ну да, ввели повсеместный юникод, что, в принципе, неплохо.
Ну по моему почти все нововведения питона 3000 полезны, ну или по крайней мере являются логическим продолжением (завершением) развития питона в том виде в каком мы его знаем. Будь я автором языка, я бы тоже пошел именно этим путем. А вот по части новых фич навроде паттерн-матчинга, оптимизации хвостовой рекурсии или поддержки конкурентности я думаю так: автор наиграется с генераторами и итераторами и таки займется расширением синтаксиса. Ведь от этого никуда не денешься...
Здравствуйте, Critical Error, Вы писали:
CE>Да и не особо страшен этот GIL. Например если ваш тред висит и ожидает предположим сокет, то замедления производительности не будет. В остальных случаях многопоточная программа будет выполняться как однопоточная, без замедления по крайней мере. Модуль multiprocessing нужен для тех случаев когда питон обрабатывает кучу данных и очень надо чтобы оно работало быстрее. Но если такая ситуация приключилась с вами, то скорее всего не верно выбран инструмент... на сишке такое писать надобно.
я использовал хаскел для организации потоков, в каждом из которых выпоонялся сишный код. как инструмент лёгкого создания потоков и организации связи между ними в/у язык куда удобней c/c++
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Critical Error, Вы писали:
CE>>Да и не особо страшен этот GIL. Например если ваш тред висит и ожидает предположим сокет, то замедления производительности не будет. В остальных случаях многопоточная программа будет выполняться как однопоточная, без замедления по крайней мере. Модуль multiprocessing нужен для тех случаев когда питон обрабатывает кучу данных и очень надо чтобы оно работало быстрее. Но если такая ситуация приключилась с вами, то скорее всего не верно выбран инструмент... на сишке такое писать надобно.
BZ>я использовал хаскел для организации потоков, в каждом из которых выпоонялся сишный код. как инструмент лёгкого создания потоков и организации связи между ними в/у язык куда удобней c/c++
А есть какие-нибудь стоящие линки про организацию потоков в хаскеле?
(до соотв. в главы в Real World Haskell ещё не добрался )
Здравствуйте, BulatZiganshin, Вы писали:
FR>>Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.
BZ>по моим наблюдениям хаскел как раз очень хорош для описания сложных алгоритмов
Угу так и есть, но если за день выхлоп 30 — 100 отлаженных строк то от того что при той же функциональности строк станет 20 — 50 не тепло не холодно
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, BulatZiganshin, Вы писали:
FR>>>Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.
BZ>>по моим наблюдениям хаскел как раз очень хорош для описания сложных алгоритмов
FR>Угу так и есть, но если за день выхлоп 30 — 100 отлаженных строк то от того что при той же функциональности строк станет 20 — 50 не тепло не холодно
Т.е. если производительность увеличится в 2 раза, то ни тепло ни холодно?
Или я не понял какие цифры к чему ты относишь
Здравствуйте, Курилка, Вы писали:
FR>>Угу так и есть, но если за день выхлоп 30 — 100 отлаженных строк то от того что при той же функциональности строк станет 20 — 50 не тепло не холодно
К>Т.е. если производительность увеличится в 2 раза, то ни тепло ни холодно?
А с чего ты взял что производительность увиличится в два раза?
Если в день пишется 50 строк вместо 100 на одинаковую функциональность то это в лучшем случае
увеличит производительность на доли процента.
К>Или я не понял какие цифры к чему ты относишь
Конечно не понял основная работа именно разработать алгоритм, затраты на кодирование стремятся к
нулю.
Здравствуйте, FR, Вы писали: FR>Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.
Ну тут все от алгоритмов зависит и от того, как Вы их будете реализовывать. В конце концов, тот же хаскель позволяет загнать все под IO или ST — и вовсю "императивничать". Если совсем припрет — критичные куски кода можнопереписать на C, а хаскель использовать как удобный скриптовый язык.
Здравствуйте, Mr.Cat, Вы писали:
MC>Ну тут все от алгоритмов зависит и от того, как Вы их будете реализовывать. В конце концов, тот же хаскель позволяет загнать все под IO или ST — и вовсю "императивничать". Если совсем припрет — критичные куски кода можнопереписать на C, а хаскель использовать как удобный скриптовый язык.
Я тут пытаюсь объяснить что есть задачи для которых язык (практически любой высокого уровня) не важен. У меня они в недавнем прошлом были у тех кто не понимает похоже нет.
Если за день пишется 100 строк на си то хаскель на котором пусть будет даже 20 строк ничего ни изменит.
Здравствуйте, FR, Вы писали: Z>>Я люблю луа, но функциональный язык без списков — нонсенс FR>Рефал
Рефал, скорее, терм-рерайтер, типа Q или Maude. Да и эта их главная датаструктура, которую можно матчить в двух концов — явно не массив (кстати что?).
Я под впечатлением от Рефала и Tom'a сделал для луа паттерн-матчинг, который может матчить array с обоих концов, и, конечно, быстро обнаружил, что для мутабельной структуры данных это практически ничего не дает.
Здравствуйте, z00n, Вы писали:
Z>Рефал, скорее, терм-рерайтер, типа Q или Maude. Да и эта их главная датаструктура, которую можно матчить в двух концов — явно не массив (кстати что?).
Структурное дерево.
Z>Я под впечатлением от Рефала и Tom'a сделал для луа паттерн-матчинг, который может матчить array с обоих концов, и, конечно, быстро обнаружил, что для мутабельной структуры данных это практически ничего не дает.
Так там не просто с двух концов можно матчить, а сразу структурой, это намного мощнее и списков и массивов.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
FR>>>Угу так и есть, но если за день выхлоп 30 — 100 отлаженных строк то от того что при той же функциональности строк станет 20 — 50 не тепло не холодно
К>>Т.е. если производительность увеличится в 2 раза, то ни тепло ни холодно?
FR>А с чего ты взял что производительность увиличится в два раза? FR>Если в день пишется 50 строк вместо 100 на одинаковую функциональность то это в лучшем случае FR>увеличит производительность на доли процента.
Только вот согласно исследованиям как раз выхлоп меряется как раз в строчках (ну или в более внятных единицах, аля операторы и т.п.), без заметного влияния языка программирования.
Т.е. если у тебя было раньше 100 строчек, а теперь станет 50 строчек, то сделаешь ты их как минимум быстрее.
К>>Или я не понял какие цифры к чему ты относишь
FR>Конечно не понял основная работа именно разработать алгоритм, затраты на кодирование стремятся к FR>нулю.
Если ты о затратах набирания букв на клавиатуре — безусловно, только к сути вопроса это не относится. Речь же идёт по-моему о решении задачи в рамках средств, предоставляемых языком (вместе с принятыми для него приёмами, парадигмами и т.п.)
Здравствуйте, Курилка, Вы писали:
FR>>А с чего ты взял что производительность увиличится в два раза? FR>>Если в день пишется 50 строк вместо 100 на одинаковую функциональность то это в лучшем случае FR>>увеличит производительность на доли процента.
К>Только вот согласно исследованиям как раз выхлоп меряется как раз в строчках (ну или в более внятных единицах, аля операторы и т.п.), без заметного влияния языка программирования. К>Т.е. если у тебя было раньше 100 строчек, а теперь станет 50 строчек, то сделаешь ты их как минимум быстрее.
Выхлоп меняется в функциональности. Закодировать эту функциональность на языке си займет скажем полчаса, найти способ как это сделать 7.5 часов. Если я использую хаскель то закодирую за 15 минут, спасибо очень большая экономия.
К>>>Или я не понял какие цифры к чему ты относишь
FR>>Конечно не понял основная работа именно разработать алгоритм, затраты на кодирование стремятся к FR>>нулю.
К>Если ты о затратах набирания букв на клавиатуре — безусловно, только к сути вопроса это не относится. Речь же идёт по-моему о решении задачи в рамках средств, предоставляемых языком (вместе с принятыми для него приёмами, парадигмами и т.п.)
А если для решения задачи более чем достаточно средств представляемых любым высокоуровневым языком?
Ладно похоже бесполезно, мы просто не понимаем друг друга
Здравствуйте, z00n, Вы писали:
FR>>Так там не просто с двух концов можно матчить, а сразу структурой, это намного мощнее и списков и массивов.
Z>Можно развернуть? Что значит "сразу структурой".
В рефале скобки в выражении задают сразу структуру дерева.
Например выражение
((a + b) * (c + d))
в языке со списками невозможно разобрать одним сопоставлением,
в рефале же легко:
Здравствуйте, FR, Вы писали:
FR>А если для решения задачи более чем достаточно средств представляемых любым высокоуровневым языком? FR>Ладно похоже бесполезно, мы просто не понимаем друг друга
Укажу ещё на гипотезу Сепира-Уорфа.
В принципе ты можешь и на ассемблере писать, только вот на языке более высокого уровня будет удобнее и проще, в следствие как раз более высокого уровня.
Т.е. у тебя выходит, что у нас есть алгорим "в голове" А. Потом алгоритмы на языке программирования, скажем Я1 (на Си) и Я2 (скажем, на хаскеле).
Ты утверждаешь, что разница между процессами кодирования А->Я1 и А->Я2 не имеет значения.
Я же говорю о том, что:
1) у 2 программистов на разных языках будут разные А1 и А2;
2) сами процессы А->Я1 и А->Я2 могут иметь разные лишние "заморочки" не относящиеся к задаче, вплоть до фиговой выразимости идеи программиста в коде;
3) на правах гипотезе: скорее всего в голове у программиста будет некая "смесь" А1/Я1 или А2/Я2, и программист будет или одновременно с решением алгоритма думать о том можно ли его в коде реализовать, или непосредственно уже представлять себе решение в рамках идиом языка.
Плюс это всё ещё будет заметно по-разному сказываться для программистов разного уровня (скажем между владеющими одним или парой языков и владеющими многими языками и знакомыми с множеством разных парадигм)
Как это всё выражается конкретно во времени у меня даже предположений нет (не то что статистики), но всёж думаю, что если язык вставляет минимум палок в колёса работе программирующего на нём, то это не может не играть положительную роль в производительности этого программирующего.
Здравствуйте, Курилка, Вы писали:
FR>>А если для решения задачи более чем достаточно средств представляемых любым высокоуровневым языком? FR>>Ладно похоже бесполезно, мы просто не понимаем друг друга
К>Укажу ещё на гипотезу Сепира-Уорфа.
Мне ближе гипотеза Эйнштейна, которая утверждает что мы мыслим не словами.
К>В принципе ты можешь и на ассемблере писать, только вот на языке более высокого уровня будет удобнее и проще, в следствие как раз более высокого уровня. К>Т.е. у тебя выходит, что у нас есть алгорим "в голове" А. Потом алгоритмы на языке программирования, скажем Я1 (на Си) и Я2 (скажем, на хаскеле). К>Ты утверждаешь, что разница между процессами кодирования А->Я1 и А->Я2 не имеет значения. К>Я же говорю о том, что: К>1) у 2 программистов на разных языках будут разные А1 и А2; К>2) сами процессы А->Я1 и А->Я2 могут иметь разные лишние "заморочки" не относящиеся к задаче, вплоть до фиговой выразимости идеи программиста в коде;
На деле все еще запущеней, два разных программиста используя один и тот же язык для одной и той же задачи могут выдать решение на порядок отличающееся в объеме кода и сложности реализации.
Так что дело не только в языке.
К>3) на правах гипотезе: скорее всего в голове у программиста будет некая "смесь" А1/Я1 или А2/Я2, и программист будет или одновременно с решением алгоритма думать о том можно ли его в коде реализовать, или непосредственно уже представлять себе решение в рамках идиом языка.
Да такое явление есть. Но есть задачи которым все это фиолетово. При их решении можно совершенно не учитывать на каком языке они будут кодироватся.
К>Плюс это всё ещё будет заметно по-разному сказываться для программистов разного уровня (скажем между владеющими одним или парой языков и владеющими многими языками и знакомыми с множеством разных парадигм) К>Как это всё выражается конкретно во времени у меня даже предположений нет (не то что статистики), но всёж думаю, что если язык вставляет минимум палок в колёса работе программирующего на нём, то это не может не играть положительную роль в производительности этого программирующего.
По моему опыт и знание парадигм влияет на результат намного сильнее чем язык реализации.
Здравствуйте, FR, Вы писали:
FR>Например выражение
FR>((a + b) * (c + d))
FR>в языке со списками невозможно разобрать одним сопоставлением, FR>в рефале же легко: FR>
Здравствуйте, Курилка, Вы писали:
К>Согласен, только хороший специалист, использующий неэффективный инструмент для меня выглядит по меньшей мере странно...
Я бы понял если это сказал Влад у которого программирование в общем-то ближе к хобби чем к работе.
Ты разбираешь список я дерево.
Тебе тут конкретно помог сахар,(кстати у тебя ошибка внешние скобки тоже значущие)
без него (например на чистом лиспе) пришлось бы разбор разбивать.
Ну и так как дерево в общем случае нельзя заменить списком рано или поздно ты не сможешь
повторить, например:
CE>>Да меня в общем то тоже удивило и огорчило, что автор языка несколько отстал развития
MC>До кучи даже анпакинг туплов выкинули (pep-3113 без слез читать невозможно)
Да. Ну. Нафиг
Блин. Почитать, что ли PEP 3113... Потому что полезная фича была...
FR>>Угу согласен. FR>>Но вообще под питон есть очень интересная штучка http://www.fiber-space.de/EasyExtend/doc/EE.html FR>>В общем вводит в питон макросы типа немерловских, при желании можно наваять почти любой нужный FR>>язычок.
dmz>Так оно и для других языков есть такое; впрочем для erlang — не знаю, есть или нет.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, z00n, Вы писали:
Z>>
Z>> fun foo
Z>> | (a :: "+" :: b :: []) :: "*" :: (c :: "+" :: d :: []) :: [] -> 1
Z>> | x -> 0
Z>> end
Z>> print$ foo([ [1,"+",2],"*",[3,"+",4] ]) ---> 1
Z>> print$ foo([1,"+",2]) ---> 0
Z>>
FR>Ты разбираешь список я дерево.
Я тоже дерево
FR>Тебе тут конкретно помог сахар,(кстати у тебя ошибка внешние скобки тоже значущие) FR>без него (например на чистом лиспе) пришлось бы разбор разбивать.
Разбивать- не разбивать — это не принципиально, особенно в лиспе, поскольку всегда можно подкрутить компилятор макросами. Я видел паттерн-матчер для Scheme, который был бы даже круче: он позволял помечать переменные особым образом, в результате чего их рекурсивно гоняли через функцию до победного конца (там это называлось катаморфизм — наверное так оно и есть ). Скобки я вроде не забыл — выделил болдом.
FR>Ну и так как дерево в общем случае нельзя заменить списком рано или поздно ты не сможешь FR>повторить, например:
FR>
FR>которому будет удовлетворять любое выражение типа: FR>((<выражение>)<может быть куча символов> (<выражение>) <может быть куча символов> (<выражение>))
Согласен. Предлагаю обобщить:
Списки: (<выражение>)<может быть куча чего-то>
Refal: (<выражение>)<может быть куча чего-то>(<выражение>)
Я собственно это и сказал 3 поста назад
И, добавлю — не совсем правильно говорить, что в Рефале нет списков — там есть их надмножество.
В луа, же никакой "функциональной" сруктуры данных нет, а то что можно сделать из того, что под рукой намного хуже списков в хорошей имплементации Схемы.
Здравствуйте, Курилка, Вы писали:
К>Скажи мне лучше, каким образом оно к Эрлангу относится? К>Тем более ещё объектно-ориентированное к "традиционному" функциональному языку?
OMETA можно реализовать на любом нормальном языке, сейчас она есть на Smalltalk, JavaScript, Scheme. Насчет Эрланга тоже были планы:
FROM: http://vpri.org/pipermail/ometa/2008-June/000010.html
> Finally, if I wanted to target a different VM, such as the Erlang VM,
>> would it make sense to use the Cola version of OMeta to compile to Erlang
>> bytecode, or would you recommend I reimplement OMeta in Erlang for that?
XOC тоже хорош, только они зачем-то взяли GLR парсер вместо PEG.
Здравствуйте, z00n, Вы писали:
FR>>Ты разбираешь список я дерево. Z>Я тоже дерево
Угу распечатаную картинку дерева
FR>>Тебе тут конкретно помог сахар,(кстати у тебя ошибка внешние скобки тоже значущие) FR>>без него (например на чистом лиспе) пришлось бы разбор разбивать. Z>Разбивать- не разбивать — это не принципиально, особенно в лиспе, поскольку всегда можно подкрутить компилятор макросами. Я видел паттерн-матчер для Scheme, который был бы даже круче: он позволял помечать переменные особым образом, в результате чего их рекурсивно гоняли через функцию до победного конца (там это называлось катаморфизм — наверное так оно и есть ). Скобки я вроде не забыл — выделил болдом.
В общем-то может и непринципиально, то что получается в рефале естественно в языках со списками можно делать только с помощью сахара.
FR>>которому будет удовлетворять любое выражение типа: FR>>((<выражение>)<может быть куча символов> (<выражение>) <может быть куча символов> (<выражение>))
Z>Согласен. Предлагаю обобщить: Z>Списки: (<выражение>)<может быть куча чего-то> Z>Refal: (<выражение>)<может быть куча чего-то>(<выражение>) Z>Я собственно это и сказал 3 поста назад
Нет у рефала нет ограничения только на голову и хвост, вон выше у меня и в середку выражение затесалось. Так что это именно произвольное дерево.
Z>И, добавлю — не совсем правильно говорить, что в Рефале нет списков — там есть их надмножество.
Угу.
Z>В луа, же никакой "функциональной" сруктуры данных нет, а то что можно сделать из того, что под рукой намного хуже списков в хорошей имплементации Схемы.
Здравствуйте, Курилка, Вы писали:
К>Очередной пророк? К>Скажи мне лучше, каким образом оно к Эрлангу относится? К>Тем более ещё объектно-ориентированное к "традиционному" функциональному языку?
Так тема вообще-то про питон и к нему должно нармально пришится.
Здравствуйте, Critical Error, Вы писали:
CE>Как мрачно! Вот отказываться от питона не есть гуд решение. Все же ничего лучше и удобнее не найдете (после питона любой язык покажется унылым и неудобным). Поступайте как все умные питонисты — пишите критичные по производительности куски приложений на С, благо C-API у питона отменное, да еще и CPP-API имеется, ну где вы еще такое найдете?
Ну, это конечно банальность, но по обоим выделенным параметрам Руби вполне конкурентоспособен /Что не отменяет наличия у Руби других проблем/
Здравствуйте, Гест, Вы писали:
Г>Ну, это конечно банальность, но по обоим выделенным параметрам Руби вполне конкурентоспособен /Что не отменяет наличия у Руби других проблем/
Угу только почему-то руби в отличии от питона на десктопах и как язык расширения приложений не прижился.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Гест, Вы писали:
Г>>Ну, это конечно банальность, но по обоим выделенным параметрам Руби вполне конкурентоспособен /Что не отменяет наличия у Руби других проблем/
FR>Угу только почему-то руби в отличии от питона на десктопах и как язык расширения приложений не прижился.
Ну, во-первых "не то чтобы совсем не попал". В смысле не то, чтобы вообще не прижился (сходу могу вспомнить SketchUp, где он таки язык расширений). Во-вторых, процесс продолжает идти — одна из громко развивающихся библиотек в руби-сообществе — библиотека Shoes для кросс-платформенного десктопного GUI. Еще есть, к примеру, такая милая и довольно популярная штучка как WaTiR — скриптование тестирования веб-сайтов через браузер.
Ну и наконец, я вообще не совсем понимаю, какое этот аргумент имеет отношение к делу
Здравствуйте, Гест, Вы писали:
FR>>Угу только почему-то руби в отличии от питона на десктопах и как язык расширения приложений не прижился.
Г>Ну, во-первых "не то чтобы совсем не попал". В смысле не то, чтобы вообще не прижился (сходу могу вспомнить SketchUp, где он таки язык расширений). Во-вторых, процесс продолжает идти — одна из громко развивающихся библиотек в руби-сообществе — библиотека Shoes для кросс-платформенного десктопного GUI. Еще есть, к примеру, такая милая и довольно популярная штучка как WaTiR — скриптование тестирования веб-сайтов через браузер.
Ну так это и есть не прижился, в сравнении с питоном или луа
Г>Ну и наконец, я вообще не совсем понимаю, какое этот аргумент имеет отношение к делу
Очень даже по делу, тут вроде еще не было флемов питон vs руби
особенно если она такая мощная, как в хаскеле. строгая типизация + вывод типов — это золотой стандарт, не надо выписывать ручками все эти витиеватые типы и в то же время не чуствуешь себя сидящим на пороховой бочке. 90% ошибок отсекаются на стадии компиляции программы
