>> А какие именно фразы говорят про "перл наоборот"? Неужели "Beatiful is better
>> than ugly"? ;)
> И эта тоже. А что, скажете, нет?Простите, правильно ли я понимаю, что из этого непосредственно и бесспорно следует, что принцип Perl обратен этому, то есть у него "Ugly is better than beatiful"? ;)
Если я неправильно Вас понял, то уточните. А то тут слишком сложно понять как-то иначе.
>> Не так. Перед майнстримом есть огромное количество народу, который экспериментирует со
>> всем. И уже по их результатам что-то попадает в майнстрим. Так
>> вот - их любовь к тому же Ruby подозрительно быстро прошла
>> в последнее время.
> Что значит "не так"? Вы не натыкались на подобные обсуждения, почему мейнстрим
> столь ограниченно мыслит? Но давайте всё же не будем поднимать тему,
> она ещё более холиварная, нежели ущербности питона. Я даже боюсь подумать
> о том, в чём меня начнут подозревать, если я влезу в
> эту тему: в мейнстримности головного мозга? Или наоборот в непонимании всей
> мудрости и профессионализма мейнстрим-разработчика? Или в чём-то третьем?
Майнстрим мыслит не ограниченно, а очень разнообразно. Он может содержать и Java, и C#, и Transact-SQL, и ассемблер, и Кобол, и Лисп. Но ему довлеет проблема сохранения совместимости с уже существующим, а это значит, что новое может в него активно проникать только в том случае, если оно заведомо лучше прежнего (по каким именно критериям - очень сильно зависит от конкретной области). И критерии сравнения никак не индивидуальны, а должны быть существенны для широкого спектра пользователей (включая необразованных и предвзятых).
В случае Ruby - у него нет никакого реального преимущества перед ближайшими популярными конкурентами. Например, у Perl уже большая база старых проектов (меня регулярно дёргают предложениями типа Senior Perl developer, а когда говорю, что больше им не занимаюсь - "Как, и Вы тоже?") У Python лёгкость вхождения, опять-таки база проектов, и некоторые характерные ускорители вроде Django. А что у Ruby? Был RoR, да как-то подозрительно кончился - то, что я вижу, это что народ мигрирует на то же Django.
>>> Явно надо указывать, что создавая объект надо выделять его из SHM кучи,
>>> а не из локальной.
>> Это проблема? Мне кажется, это скорее преимущество.
> Ключевое слово "кажется". Тогда и файловый дескриптор -- сплошное преимущество перед std::stream:
> файловый дескриптор даёт удивительно тонкий контроль над ситуацией, и, главное --
> всё наглядно. Читая код, всегда будешь в курсе какая стратегия буферизации
> используется, всегда будет понятно, какой формат вывода числовых данных активен в
> данный момент. И никаких сбивающих с толку неявностей.
Я с Вами категорически согласен. Во-первых, для C++ iostream абсолютно не специфицировано несколько аспектов поведения: например, взаимодействие с сигналами (сигнал невовремя и EINTR на операцию - что сделает iostream? я не знаю, и не видел никакого чёткого ответа на это). Когда это становится важным, переходят, например, на sfio, или даже stdio, для Unix реализаций которого этот вопрос решён. Во-вторых, он не решает вопрос асинхронной работы. В-третьих, его система форматтеров - адское зло. Начинать каждый вывод с resetiosflags - громоздко, а сохранять старый режим - чревато боком (неизвестно, что и как будет введено или выведено). А промежуточный хранитель контекста не придумали, хотя решение напрашивается само собой.
Два реальных преимущества iostream как подхода - логическое замыкание вокруг понятия абстрактного потока (когда использующему коду неважно, куда оно реально выводится или откуда вводится), и это колоссальная недоработка стандарта C, что такие средства (как fopencookie в Glibc или funopen в BSD) не были приняты в стандарт; и перегрузка операций для кастомных типов. И то - второе достаточно редко оказывается полезным. В итоге я даже на C++ предпочту stdio для текстового общения: оно не страдает ерундой на ровном месте.
>> Кстати, мультитрединг в Perl такой же - взаимодействие между нитями только явное.
> Ну это вам виднее. В перле я не писатель, в перле я
> читатель.
> Но при чём тут перл?
Ну мы же в данной подветке в основном сравниваем Perl и Python, который, по-Вашему, делался где-то в направлении "посмотри на Perl и сделай наоборот".
> Это в к тому, что реализовывая мультитрединг
> Python пошёл не в абсолютно противоположную сторону? Может быть. Но что
> нашему диалогу даёт понимание этого факта?
Оно даёт то, что я хочу уже третье письмо показать - что Python в своём развитии не отталкивался от Perl, он шёл своей дорогой.
>>> При необходимости передать открытый файловый дескриптор надо
>>> прибить дочерний процесс и создать новый.
>> Вообще-то передача дескриптора между процессами работала через Unix sockets ещё в 80-х
>> годах. Да, это может потребовать вспомогательного модуля на Си, но это
>> ничтожная плата в большинстве случаев.
> Вы не могли бы привести здесь кусочек кода на Python, который продемонстрирует
> передачу открытого файла между процессами?
http://code.google.com/p/python-passfd/ (BSD sockets style)
https://groups.google.com/forum/?fromgroups=#!msg/comp.lang.... (SysV STREAMS style)
нагуглил менее чем за минуту, Вы это отлично могли сделать сами.
>> Ну Вы как-то уж очень агитировали за него.
> Вам опять "кажется". Я никого ни на что не агитирую. Уверен твёрдо,
> что каждый сам кузнец своего счастья, и мои подсказки не требуются.
> Вот представьте, на секундочку, а если я займусь агитацией, но ошибусь
> с выбором предмета агитации. И представьте, что мне случится убедить окружающих
> в том, что дерьмо сладкое и вкусное. Они же наевшись дерьма,
> меня обвинят в том, что я насильно им дерьмо в рот
> засовывал. Зачем мне это надо?
Зачем агитировать за дерьмо, я таки не знаю:) А вот зачем агитировать за апельсин, картошку или говяжий стейк, я могу себе представить без проблем.
Главное - чтобы это была агитация, а не впихивание в рот:)
> Я не агитирую, лишь рассказываю, что мне не нравится в питоне. А
> руби, перл, C, и все прочие языки, что я упоминал --
> это лишь примеры, приведённые для пояснения различных моих высказываний.
Вы слишком несистемно поясняете, и это сильно мешает понять основную идею.
