Здравствуйте, 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 для этого используются?
Честно говоря, первая трудность в том, что надо знать, что это за принципы. Я спрошу у нашего эрлангиста, какими принципами он руководствуется — может и OTP. Но когда вот он по какой-то причине недоступен, а мне надо поднять серваки и что-нить подкрутить в удаленной мнезии — то вот тут начинается... Вспомнить куку, запустить эрланг, пингануть ноду (вспомнить как называется), т.к. пока не пинганешь, оболочка мнезии не запустится... Вспомнить какой кракозяблой в консоли надо подцепиться к удаленному процессу и т.п.
Впрочем, по сравнению с бесконечным адом, которым является поддержка питоновых серваков — кто пытался поставить 2.5 и нужные пакеты на него на старую федору или центос, или кто убивал Arch установкой
того-же 2.5, или приводил debian stable в debian-необвновляющася-помойка-непонятно-из-каких-веток-собранная — тот поймет...
Идеал развертывания веб-приложения для меня — это скопировать бинарник (один!) в /usr/local/bin, конфиг — в /etc, скопировать конфиг в /etc/lighttpd/conf* — и все. И, в принципе, хаскелл и окамл подают надежды, что однажды все так и будет.
К>>В чём встретили проблемы с развёртыванием, если не секрет?
К>>Принципы 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, плохо смотрел?
. У Хаскеля вроде чуть получше но по сравнению с питоном тоже очень мало.
